From: "Arnd Bergmann" <arnd@arndb.de>
To: "Christophe Leroy" <christophe.leroy@csgroup.eu>,
"Michael Ellerman" <mpe@ellerman.id.au>,
"Adrian Hunter" <adrian.hunter@intel.com>
Cc: "Peter Zijlstra" <peterz@infradead.org>,
"Dave Hansen" <dave.hansen@linux.intel.com>,
"John Stultz" <jstultz@google.com>,
"H. Peter Anvin" <hpa@zytor.com>,
"Alexander Gordeev" <agordeev@linux.ibm.com>,
"Vincenzo Frascino" <vincenzo.frascino@arm.com>,
"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
"Naresh Kamboju" <naresh.kamboju@linaro.org>,
"x86@kernel.org" <x86@kernel.org>,
"Aneesh Kumar K.V" <aneesh.kumar@kernel.org>,
"Ingo Molnar" <mingo@redhat.com>,
"Naveen N. Rao" <naveen.n.rao@linux.ibm.com>,
"Christian Borntraeger" <borntraeger@linux.ibm.com>,
"Vasily Gorbik" <gor@linux.ibm.com>,
"Heiko Carstens" <hca@linux.ibm.com>,
"Nicholas Piggin" <npiggin@gmail.com>,
"Borislav Petkov" <bp@alien8.de>,
"Andy Lutomirski" <luto@kernel.org>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Anna-Maria Gleixner" <anna-maria@linutronix.de>,
"Stephen Boyd" <sboyd@kernel.org>,
"Randy Dunlap" <rdunlap@infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Sven Schnelle" <svens@linux.ibm.com>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH] bug: Fix no-return-statement warning with !CONFIG_BUG
Date: Mon, 15 Apr 2024 19:32:43 +0200 [thread overview]
Message-ID: <fcc44b2a-4540-435f-aa93-8e36903ccc2b@app.fastmail.com> (raw)
In-Reply-To: <a87bed5b-edb7-4ba2-bdd1-88fcd1da7b69@csgroup.eu>
On Mon, Apr 15, 2024, at 19:07, Christophe Leroy wrote:
> Le 15/04/2024 à 17:35, Arnd Bergmann a écrit :
>>
>> I haven't seen a good solution here. Ideally we'd just define
>> the functions unconditionally and have IS_ENABLED() take care
>> of letting the compiler drop them silently, but that doesn't
>> build because of missing struct members.
>>
>> I won't object to either an 'extern' declaration or the
>> 'BUILD_BUG_ON()' if you and others prefer that, both are better
>> than BUG() here. I still think my suggestion would be a little
>> simpler.
>
> The advantage of the BUILD_BUG() against the extern is that the error
> gets detected at buildtime. With the extern it gets detected only at
> link-time.
>
> But agree with you, the missing struct members defeats the advantages of
> IS_ENABLED().
>
> At the end, how many instances of struct timekeeper do we have in the
> system ? With a quick look I see only two instances: tkcore.timekeeper
> and shadow_timekeeper. If I'm correct, wouldn't it just be simpler to
> have the three debug struct members defined at all time ?
Sure, this version looks fine to me, and passes a simple build
test without CONFIG_DEBUG_TIMEKEEPING.
Arnd
diff --git a/include/linux/timekeeper_internal.h b/include/linux/timekeeper_internal.h
index 84ff2844df2a..485677a98b0b 100644
--- a/include/linux/timekeeper_internal.h
+++ b/include/linux/timekeeper_internal.h
@@ -124,7 +124,6 @@ struct timekeeper {
u32 ntp_err_mult;
/* Flag used to avoid updating NTP twice with same second */
u32 skip_second_overflow;
-#ifdef CONFIG_DEBUG_TIMEKEEPING
long last_warning;
/*
* These simple flag variables are managed
@@ -135,7 +134,6 @@ struct timekeeper {
*/
int underflow_seen;
int overflow_seen;
-#endif
};
#ifdef CONFIG_GENERIC_TIME_VSYSCALL
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 4e18db1819f8..17f7aed807e1 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -195,7 +195,6 @@ static inline u64 tk_clock_read(const struct tk_read_base *tkr)
return clock->read(clock);
}
-#ifdef CONFIG_DEBUG_TIMEKEEPING
#define WARNING_FREQ (HZ*300) /* 5 minute rate-limiting */
static void timekeeping_check_update(struct timekeeper *tk, u64 offset)
@@ -276,15 +275,6 @@ static inline u64 timekeeping_debug_get_ns(const struct tk_read_base *tkr)
/* timekeeping_cycles_to_ns() handles both under and overflow */
return timekeeping_cycles_to_ns(tkr, now);
}
-#else
-static inline void timekeeping_check_update(struct timekeeper *tk, u64 offset)
-{
-}
-static inline u64 timekeeping_debug_get_ns(const struct tk_read_base *tkr)
-{
- BUG();
-}
-#endif
/**
* tk_setup_internals - Set up internals to use clocksource clock.
@@ -2173,7 +2163,8 @@ static bool timekeeping_advance(enum timekeeping_adv_mode mode)
goto out;
/* Do some additional sanity checking */
- timekeeping_check_update(tk, offset);
+ if (IS_ENABLED(CONFIG_DEBUG_TIMEKEEPING))
+ timekeeping_check_update(tk, offset);
/*
* With NO_HZ we may have to accumulate many cycle_intervals
WARNING: multiple messages have this Message-ID (diff)
From: "Arnd Bergmann" <arnd@arndb.de>
To: "Christophe Leroy" <christophe.leroy@csgroup.eu>,
"Michael Ellerman" <mpe@ellerman.id.au>,
"Adrian Hunter" <adrian.hunter@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
John Stultz <jstultz@google.com>,
"H. Peter Anvin" <hpa@zytor.com>,
Alexander Gordeev <agordeev@linux.ibm.com>,
Vincenzo Frascino <vincenzo.frascino@arm.com>,
"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
Naresh Kamboju <naresh.kamboju@linaro.org>,
"x86@kernel.org" <x86@kernel.org>,
"Aneesh Kumar K.V" <aneesh.kumar@kernel.org>,
Ingo Molnar <mingo@redhat.com>,
"Naveen N. Rao" <naveen.n.rao@linux.ibm.com>,
Christian Borntraeger <borntraeger@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Heiko Carstens <hca@linux.ibm.com>,
Nicholas Piggin <npiggin@gmail.com>,
Borislav Petkov <bp@alien8.de>, Andy Lutomirski <luto@kernel.org>,
Bjorn Helgaas <bhelgaas@google.com>,
Thomas Gleixner <tglx@linutronix.de>,
Anna-Maria Gleixner <anna-maria@linutronix.de>,
Stephen Boyd <sboyd@kernel.org>,
Randy Dunlap <rdunlap@infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Sven Sch nelle <svens@linux.ibm.com>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH] bug: Fix no-return-statement warning with !CONFIG_BUG
Date: Mon, 15 Apr 2024 19:32:43 +0200 [thread overview]
Message-ID: <fcc44b2a-4540-435f-aa93-8e36903ccc2b@app.fastmail.com> (raw)
In-Reply-To: <a87bed5b-edb7-4ba2-bdd1-88fcd1da7b69@csgroup.eu>
On Mon, Apr 15, 2024, at 19:07, Christophe Leroy wrote:
> Le 15/04/2024 à 17:35, Arnd Bergmann a écrit :
>>
>> I haven't seen a good solution here. Ideally we'd just define
>> the functions unconditionally and have IS_ENABLED() take care
>> of letting the compiler drop them silently, but that doesn't
>> build because of missing struct members.
>>
>> I won't object to either an 'extern' declaration or the
>> 'BUILD_BUG_ON()' if you and others prefer that, both are better
>> than BUG() here. I still think my suggestion would be a little
>> simpler.
>
> The advantage of the BUILD_BUG() against the extern is that the error
> gets detected at buildtime. With the extern it gets detected only at
> link-time.
>
> But agree with you, the missing struct members defeats the advantages of
> IS_ENABLED().
>
> At the end, how many instances of struct timekeeper do we have in the
> system ? With a quick look I see only two instances: tkcore.timekeeper
> and shadow_timekeeper. If I'm correct, wouldn't it just be simpler to
> have the three debug struct members defined at all time ?
Sure, this version looks fine to me, and passes a simple build
test without CONFIG_DEBUG_TIMEKEEPING.
Arnd
diff --git a/include/linux/timekeeper_internal.h b/include/linux/timekeeper_internal.h
index 84ff2844df2a..485677a98b0b 100644
--- a/include/linux/timekeeper_internal.h
+++ b/include/linux/timekeeper_internal.h
@@ -124,7 +124,6 @@ struct timekeeper {
u32 ntp_err_mult;
/* Flag used to avoid updating NTP twice with same second */
u32 skip_second_overflow;
-#ifdef CONFIG_DEBUG_TIMEKEEPING
long last_warning;
/*
* These simple flag variables are managed
@@ -135,7 +134,6 @@ struct timekeeper {
*/
int underflow_seen;
int overflow_seen;
-#endif
};
#ifdef CONFIG_GENERIC_TIME_VSYSCALL
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 4e18db1819f8..17f7aed807e1 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -195,7 +195,6 @@ static inline u64 tk_clock_read(const struct tk_read_base *tkr)
return clock->read(clock);
}
-#ifdef CONFIG_DEBUG_TIMEKEEPING
#define WARNING_FREQ (HZ*300) /* 5 minute rate-limiting */
static void timekeeping_check_update(struct timekeeper *tk, u64 offset)
@@ -276,15 +275,6 @@ static inline u64 timekeeping_debug_get_ns(const struct tk_read_base *tkr)
/* timekeeping_cycles_to_ns() handles both under and overflow */
return timekeeping_cycles_to_ns(tkr, now);
}
-#else
-static inline void timekeeping_check_update(struct timekeeper *tk, u64 offset)
-{
-}
-static inline u64 timekeeping_debug_get_ns(const struct tk_read_base *tkr)
-{
- BUG();
-}
-#endif
/**
* tk_setup_internals - Set up internals to use clocksource clock.
@@ -2173,7 +2163,8 @@ static bool timekeeping_advance(enum timekeeping_adv_mode mode)
goto out;
/* Do some additional sanity checking */
- timekeeping_check_update(tk, offset);
+ if (IS_ENABLED(CONFIG_DEBUG_TIMEKEEPING))
+ timekeeping_check_update(tk, offset);
/*
* With NO_HZ we may have to accumulate many cycle_intervals
next prev parent reply other threads:[~2024-04-15 17:33 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-10 15:32 [PATCH] bug: Fix no-return-statement warning with !CONFIG_BUG Adrian Hunter
2024-04-10 15:32 ` Adrian Hunter
2024-04-10 17:02 ` Naresh Kamboju
2024-04-10 17:02 ` Naresh Kamboju
2024-04-10 20:05 ` [tip: timers/urgent] " tip-bot2 for Adrian Hunter
2024-04-11 7:04 ` [PATCH] " Arnd Bergmann
2024-04-11 7:04 ` Arnd Bergmann
2024-04-11 7:16 ` Adrian Hunter
2024-04-11 7:16 ` Adrian Hunter
2024-04-11 7:56 ` Arnd Bergmann
2024-04-11 9:03 ` Adrian Hunter
2024-04-11 10:27 ` David Laight
2024-04-11 8:13 ` Christophe Leroy
2024-04-11 8:13 ` Christophe Leroy
2024-04-11 8:22 ` Christophe Leroy
2024-04-11 8:22 ` Christophe Leroy
2024-04-11 9:27 ` Adrian Hunter
2024-04-11 9:27 ` Adrian Hunter
2024-04-11 11:26 ` Arnd Bergmann
2024-04-11 11:26 ` Arnd Bergmann
2024-04-15 2:19 ` Michael Ellerman
2024-04-15 15:35 ` Arnd Bergmann
2024-04-15 15:35 ` Arnd Bergmann
2024-04-15 17:07 ` Christophe Leroy
2024-04-15 17:32 ` Arnd Bergmann [this message]
2024-04-15 17:32 ` Arnd Bergmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fcc44b2a-4540-435f-aa93-8e36903ccc2b@app.fastmail.com \
--to=arnd@arndb.de \
--cc=adrian.hunter@intel.com \
--cc=agordeev@linux.ibm.com \
--cc=aneesh.kumar@kernel.org \
--cc=anna-maria@linutronix.de \
--cc=bhelgaas@google.com \
--cc=borntraeger@linux.ibm.com \
--cc=bp@alien8.de \
--cc=christophe.leroy@csgroup.eu \
--cc=dave.hansen@linux.intel.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=hpa@zytor.com \
--cc=jstultz@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=mpe@ellerman.id.au \
--cc=naresh.kamboju@linaro.org \
--cc=naveen.n.rao@linux.ibm.com \
--cc=npiggin@gmail.com \
--cc=peterz@infradead.org \
--cc=rdunlap@infradead.org \
--cc=sboyd@kernel.org \
--cc=svens@linux.ibm.com \
--cc=tglx@linutronix.de \
--cc=vincenzo.frascino@arm.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.