netdev - Re: [patch 11/11] netfilter warning fix

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: <20070206210250.GB25430@elte.hu>
Date:	Tue, 6 Feb 2007 22:02:51 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	David Miller <davem@...emloft.net>
Cc:	akpm@...ux-foundation.org, netdev@...r.kernel.org, kaber@...sh.net,
	dipankar@...ibm.com, paulmck@...ibm.com
Subject: Re: [patch 11/11] netfilter warning fix

* David Miller <davem@...emloft.net> wrote:

> > that was pretty much the only place in the whole kernel that got hit 
> > by some rcu-preempt side-effect - and even this appears to show that 
> > it's a real bug that was in hiding.
> 
> No, rather, it's the only location that triggered an automated 
> debugging check.  The very first set of code paths we checked, in 
> response to the bug trigger, showed beyond a shadow of a doubt that 
> this assumption is pervasive and in many locations that none of the 
> automated debugging checks live.
> 
> The tree should be fully audited before such a huge semantic change 
> gets added into the tree.

i'd like to add more automated checks to the tree. 'naked' 
smp_processor_id() use is one telltale sign of such a problem - what 
other instances could you suggest me to check? The thing is, in 99% of 
the cases the smp_processor_id() check caught such assumptions in other 
code because 'preempt off' is inextricably connected to /some/ use of 
smp_processor_id() - be it get_cpu_var() or any other derivative 
interface. So i'm wondering what other assumptions there are (or can be) 
about rcu_read_lock() also being a preempt-off point. Thanks!

(btw., i always argued that neither preempt_disable() nor 
rcu_read_lock() is an ideal interface for locking because both hide 
critical assumptions and dependencies - and they both are able to create 
little versions of the 'big BKL mess' that we had to fight a few years 
ago. (and that we still have to fight today, in certain areas of code.))

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