netdev - Re: 2.6.35-rc4-git3: Reported regressions from 2.6.34

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: <20100709071131.GB10743@elte.hu>
Date:	Fri, 9 Jul 2010 09:11:31 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>,
	"Paul E. McKenney" <paulmck@...ibm.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Thomas Gleixner <tglx@...utronix.de>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Maciej Rutecki <maciej.rutecki@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Kernel Testers List <kernel-testers@...r.kernel.org>,
	Network Development <netdev@...r.kernel.org>,
	Linux ACPI <linux-acpi@...r.kernel.org>,
	Linux PM List <linux-pm@...ts.linux-foundation.org>,
	Linux SCSI List <linux-scsi@...r.kernel.org>,
	Linux Wireless List <linux-wireless@...r.kernel.org>,
	DRI <dri-devel@...ts.sourceforge.net>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Al Viro <viro@...iv.linux.org.uk>,
	Shawn Starr <shawn.starr@...ers.com>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Dave Airlie <airlied@...hat.com>,
	"David S. Miller" <davem@...emloft.net>,
	Patrick McHardy <kaber@...sh.net>, Jens Axboe <axboe@...nel.dk>
Subject: Re: 2.6.35-rc4-git3: Reported regressions from 2.6.34


* Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> > Bug-Entry ? ? ? : http://bugzilla.kernel.org/show_bug.cgi?id=16346
> > Subject ? ? ? ? : 2.6.35-rc3-git8 - include/linux/fdtable.h:88 invoked rcu_dereference_check() without protection!
> > Submitter ? ? ? : Miles Lane <miles.lane@...il.com>
> > Date ? ? ? ? ? ?: 2010-07-04 22:04 (5 days old)
> > Message-ID ? ? ?: <AANLkTinof0k28rk4rMr66aubxcRL2rFa5ZEArj1lqD3o@...l.gmail.com>
> > References ? ? ?: http://marc.info/?l=linux-kernel&m=127828107815930&w=2
> 
> I'm not entirely sure if these RCU proving things should count as 
> regressions.

Generally not - and we've delayed at least one more complex (cgroups) fix to 
v2.6.36 because the patch itself was riskier than the warning.

Still most of the warning fixes turned out to be simple, so we merged the 
very-low-risk ones and right now we seem to be on top of them.

But in general the default rule is that we delay these fixes to v2.6.36.

> Sure, the option to enable RCU proving is new, but the things it reports 
> about generally are not new - and they are usually not even bugs in the 
> sense that they necessarily cause any real problems.
> 
> That particular one is in the single-thread optimizated case for fget_light, ie
> 
>         if (likely((atomic_read(&files->count) == 1))) {
>                 file = fcheck_files(files, fd);
> 
> where I think it should be entirely safe in all ways without any locking. So 
> I think it's a false positive too.

Yeah, it's a bit like with lockdep (and it's a bit like with compiler warning 
fixes): we had to punch through a large stack of false positives that 
accumulated in the past 10 years.

( Because real bugs eventually get fixed, while false positives always just
  accumulate. So almost by definition we always start with a very assymetric
  collection of warnings and a large stack of false positives. )

Having said that, it appears we got most of the false positives and are 
beginning to be in a more representative equilibrium now. If v2.6.35 isnt 
going to be warning-free then v2.6.36 certainly will be and new warnings will 
have a much higher likelyhood of being real (and new) bugs (not just 
accumulated false-positives).

	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