linux-kernel - Re: [PATCH] printk: fix pr_debug and pr

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1449247595.8611.1.camel@perches.com>
Date:	Fri, 04 Dec 2015 08:46:35 -0800
From:	Joe Perches <joe@...ches.com>
To:	Aaron Conole <aconole@...hat.com>, Jason Baron <jbaron@...mai.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] printk: fix pr_debug and pr_devel to elide function
 calls

On Fri, 2015-12-04 at 11:38 -0500, Aaron Conole wrote:
> Jason Baron <jbaron@...mai.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@...hat.com>
> > > Reported-by: Dmitry Vyukov <dvyukov@...gle.com>
> > > Cc: Joe Perches <joe@...ches.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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/