On Mon, 18 Dec 2006, Peter Zijlstra wrote:
> >
> > Or maybe the WARN_ON() just points out _why_ somebody would want to do
> > something this insane. Right now I just can't see why it's a valid thing
> > to do.
>
> Maybe, but I think Nick's mail here:
> http://lkml.org/lkml/2006/12/18/59
>
> shows a trace like that.
Sure, but I actually think that "try_to_free_buffers()" was buggy in the
first place, shouldn't have done what it did at all (it has NO business
clearing dirty data), and should be fixed with my other simple and clean
patch that just removes the crap.
But sadly, Andrei said that he still saw data corruption, which implies
that the problem had nothing to do with "try_to_free_buffers()" at all.
(On that note: Andrei - if you do test this out, I'd suggest applying my
patch too - the one that you already tested. It won't apply cleanly on top
of Andrew's patch, but it should be trivial to apply by hand, since you
really just want to remove the whole "if (ret) {...}" sequence. I realize
that it didn't make any difference for you, but applying that patch is
probably a good idea just to remove the noise for a codepath that you
already showed to not matter)
> I'm guessing that if we do the WARN_ON() some folks might get a lot of
> output, perhaps WARN_ON_ONCE() ?
Well, I'd rather get lots of noise to see all the paths that can cause
this. We've been concentrating mainly on one (try_to_free_buffers()), but
that one was already shown not to matter or at least not to be the _whole_
issue, so..
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
