netdev - 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]

Date:	Tue, 15 Nov 2011 00:48:43 +0100 (CET)
From:	Jesper Juhl <jj@...osbits.net>
To:	Ryan Mallon <rmallon@...il.com>
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 Tue, 15 Nov 2011, Ryan Mallon wrote:

> 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.
> 
You have a point. Perhaps the proper solution would be to remove 
CONFIG_BUG so that it is always enabled...?  As you say, if something is a 
fatal bug there is no sane way to continue, so why do we even allow 
people/systems to try???
That way lies madness it would seem...


-- 
Jesper Juhl <jj@...osbits.net>       http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html