linux-kernel - Re: [PATCH 10/10] check 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: <20060908164908.abb98076.akpm@osdl.org>
Date:	Fri, 8 Sep 2006 16:49:08 -0700
From:	Andrew Morton <akpm@...l.org>
To:	Zach Brown <zach.brown@...cle.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 10/10] check pr_debug() arguments

On Fri,  8 Sep 2006 15:55:29 -0700 (PDT)
Zach Brown <zach.brown@...cle.com> wrote:

> check pr_debug() arguments
> 
> When DEBUG isn't defined pr_debug() is defined away as an empty macro.  By
> throwing away the arguments we allow completely incorrect code to build.
> 
> Instead let's make it an empty inline which checks arguments and mark it so gcc
> can check the format specification.

Desirable.

> This results in a seemingly insignificant code size increase.  A x86-64
> allyesconfig:
> 
>    text    data     bss     dec     hex filename
> 25354768        7191098 4854720 37400586        23ab00a vmlinux.before
> 25354945        7191138 4854720 37400803        23ab0e3 vmlinux

Which would indicate that we might have expressions-with-side-effects
inside pr_debug() statements somewhere, which is risky.  I wonder where?

It looks like the version of gcc which you used is correctly discarding the
pr_debug() format string.  gcc hasn't always done that, and there's a risk
of bloatiness on older gccs.  I checked gcc-3.3.2/x86 and it does the right
thing, so...

btw, what's up with aio.c using a combination of pr_debug() and dprintk(),
and a combination of `#ifdef DEBUG' and `#if DEBUG > 1'?  Confusing.

It would be nice to have a single way of doing developer-debug in-tree.  We
have 182(!) different definitions of dprintk().  Please nobody cc me on that
discussion though ;)
-
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/