Alexander Viro wrote:
>
> On Thu, 2 May 2002, Andrew Morton wrote:
> > A few things..
> >
> [snip]
>
> Andrew, judging by the filenames he'd mentioned, I suspect that he runs
> innd. I.e. one of the very few programs heavily using truncate(). And
> no, it doesn't promise anything good - last time we had crap in truncate/mmap
> interaction it was a hell to fix.
>
> I suspect that you had screwed the truncate exclusion warranties up. If
> _any_ IO happens in the area currently manipulated by ->truncate() - you
> are screwed and results would look pretty much like the things mentioned
> in bug report.
OK, thanks. That's something to go on.
The only change which comes to mind is discard_buffer() - it's
no longer clearing BH_Uptodate. Because for the partial page
at the end of the mapping, buffers outside i_size were zeroed
in truncate_partial_page(). But with (presumed) 4k blocksize,
it can't be that.
ext3_writepage() can hold a reference against the buffers
after the page has come unlocked, so a try_to_free in the
right window will fail, which will leave the page floating
about on the page LRU, not mapped into any address_space,
clean, not uptodate, but with uptodate buffers. Nobody
but the VM should ever find that page, but it does make more
sense to mark that buffer not uptodate. This would only
happen on super-heavy SMP loads.
So hmm.
There's a small SMP-only race in truncate_list_pages:
the test for PageWriteback happens against an unlocked
page. There's a three-instruction window where writeback
could start up. That won't be it, but I'll fix that.
-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue May 07 2002 - 22:00:16 EST