linux-kernel - Re: [PATCH] Silence 'ignoring return value' warnings in drivers/video/aty/radeon

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: <20080506213717.725784ec@infradead.org>
Date:	Tue, 6 May 2008 21:37:17 -0700
From:	Arjan van de Ven <arjan@...radead.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	David Miller <davem@...emloft.net>, tony@...eyournoodle.com,
	linux-kernel@...r.kernel.org, benh@...nel.crashing.org
Subject: Re: [PATCH] Silence 'ignoring return value' warnings in
 drivers/video/aty/radeon_base.c

On Tue, 6 May 2008 21:23:14 -0700
Andrew Morton <akpm@...ux-foundation.org> wrote:

> On Tue, 6 May 2008 21:15:52 -0700 Arjan van de Ven
> <arjan@...radead.org> wrote:
> 
> > On Tue, 6 May 2008 21:12:33 -0700
> > 
> > > > can we make it a WARN_ON() as well? that way we'll see it in
> > > > various kerneloops.org stats etc etc.. and we also get a nice
> > > > backtrace for free to go with it....
> > > > 
> > > > (rationale: users tend to not read their dmesg much, but
> > > > WARN_ON()'s do get noticed)
> > > 
> > > OK by me, although if we're going to do much more of this it
> > > might be time to add a WARN_ON which takes (fmt, args...).
> > 
> > totally; I was just talking to some others about doing just this.
> 
> The challenge will be to minimise the code footprint.

the meat of WARN_ON() is already out of line; so all the vararg stuff
is just going to be one function out of line, if we really care about
the last 20 bytes we can even implement WARN_ON() using an empty string.

I suspect it's not all that bad.
(but gcc is still churning, so no hard data yet)
 
> otcompletelyoh, perhaps we could generate a backtrace from within
> printk() itself for when it sees messages which have KERN_ERR or some
> other suitably-chosen (and probably configurable) facility level.

interesting thought. Only thing is that this won't give the option to
have a condition there, or to compile it out for those folks who care
about squeezing the last bytes out by disabling such debug messages.


> 
> That'll generate false positives and will reveal dubious choices, but
> we can fix those up.

I'm not all that worried about that; if we introduce a new flag that is
it'll be explicit and fine.
--
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/