linux-kernel - Re: [PATCH] net/packet: remove dead code and unneeded variable from prb_setup_retire_blk

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: <4EC1A65E.5040607@gmail.com>
Date:	Tue, 15 Nov 2011 10:38:06 +1100
From:	Ryan Mallon <rmallon@...il.com>
To:	Jesper Juhl <jj@...osbits.net>
CC:	"David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Eric Dumazet <eric.dumazet@...il.com>,
	Changli Gao <xiaosuo@...il.com>,
	Ben Greear <greearb@...delatech.com>,
	Chetan Loke <loke.chetan@...il.com>,
	waltje@...lt.NL.Mugnet.ORG, gw4pts@...pts.ampr.org,
	waltje@...ux.com, ross.biro@...il.com, alan@...ux.intel.com
Subject: Re: [PATCH] net/packet: remove dead code and unneeded variable from
 prb_setup_retire_blk_timer()

On 15/11/11 10:37, Jesper Juhl wrote:

> On Mon, 14 Nov 2011, Ryan Mallon wrote:
> 
>> On 14/11/11 08:55, Jesper Juhl wrote:
>>
>>> We test for 'tx_ring' being != zero and BUG() if that's the case. So after
>>> that check there is no way that 'tx_ring' could be anything _but_ zero, so
>>> testing it again is just dead code. Once that dead code is removed, the
>>> 'pkc' local variable becomes entirely redundant, so remove that as well.
>>
>>
>> What if CONFIG_BUG=n?
>>
> 
> Arrgh, I didn't consider that (should have, but didn't).. In that case 
> we'll have 
> #define BUG() do {} while(0)
> which is not going to work all that peachy with my change...
> 
> David: You may want to pass on this one. I obviously didn't think it 
> through properly - sorry :-(
> 


It's something I've never been entirely clear on. How are you meant to
handle something which really is a fatal bug if CONFIG_BUG=n?

I think there are several places in the kernel where the expectation is
that BUG() causes a panic that probably don't behave nicely at all
(though I guess that might be the expected behaviour) if CONFIG_BUG=n.

~Ryan

--
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/