Messages in this thread | | | Subject | Re: [PATCH] printk: fix pr_debug and pr_devel to elide function calls | From | Joe Perches <> | Date | Fri, 04 Dec 2015 08:46:35 -0800 |
| |
On Fri, 2015-12-04 at 11:38 -0500, Aaron Conole wrote: > Jason Baron <jbaron@akamai.com> writes: > > On 12/03/2015 05:45 PM, Aaron Conole wrote: > > > Currently, pr_debug and pr_devel will not elide function call arguments > > > appearing in calls to no_printk for these macros. This is because all > > > side effects must be honored before proceeding to the 0-value assignment > > > in no_printk. > > > > > > The behavior is contrary to documentation found in the CodingStyle and > > > header file where these functions are declared. > > > > > > This patch corrects that behavior by shunting out the call to no_printk > > > completely. The format string is still checked by gcc for correctness, but > > > no code seems to be emitted in common cases. > > > > > > fixes commit 5264f2f75d86 ("include/linux/printk.h: use and neaten > > > no_printk") > > > > > > Signed-off-by: Aaron Conole <aconole@redhat.com> > > > Reported-by: Dmitry Vyukov <dvyukov@google.com> > > > Cc: Joe Perches <joe@perches.com> > > > > I think we should just convert no_printk() to not emit anything. This > > will avoid us adding unwrapped calls to 'no_printk()' in the future, and > > I think makes the code more readable. Based on Joe's previous > > 'eliminated_printk()' thing. IE: > > > > diff --git a/include/linux/printk.h b/include/linux/printk.h > > index 9729565..58632bf 100644 > > --- a/include/linux/printk.h > > +++ b/include/linux/printk.h > > @@ -108,11 +108,11 @@ struct va_format { > > * Dummy printk for disabled debugging statements to use whilst maintaining > > * gcc's format and side-effect checking. > > */ > > -static inline __printf(1, 2) > > -int no_printk(const char *fmt, ...) > > -{ > > - return 0; > > -} > > +#define no_printk(fmt, ...) \ > > +do { \ > > + if (0) \ > > + printk(fmt, ##__VA_ARGS__); \ > > +} while (0) > > > > #ifdef CONFIG_EARLY_PRINTK > > extern asmlinkage __printf(1, 2) > > > > Thanks, > > > > -Jason > > I like this fix the best, but reading some other upstream mails it seems > like that approach isn't likely to be accepted? I'll happily respin to > have your proposed code because it makes the most sense, if no one else > has any objections.
I have no objections. 1995 was a good year.
| |