[lkml]   [2010]   [Jul]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 2.6.35-rc4-git3: Reported regressions from 2.6.34

* Linus Torvalds <> wrote:

> > Bug-Entry ? ? ? :
> > Subject ? ? ? ? : 2.6.35-rc3-git8 - include/linux/fdtable.h:88 invoked rcu_dereference_check() without protection!
> > Submitter ? ? ? : Miles Lane <>
> > Date ? ? ? ? ? ?: 2010-07-04 22:04 (5 days old)
> > Message-ID ? ? ?: <>
> > References ? ? ?:
> 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).


 \ /
  Last update: 2010-07-09 09:15    [W:0.181 / U:1.952 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site