[lkml]   [2000]   [Sep]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Still ext2-corruption in test8-pre5 (incl. OOPS)

--On 09/05/00 18:13:53 -0700 Linus Torvalds <> wrote:

> On Wed, 6 Sep 2000, Udo A. Steinberg wrote:
>> I'm still experiencing ext2 corruption even with the newest patch
>> test8-pre5. I'm not using bugtraq, mutt or pine and I'm fairly sure
>> it's not caused by a badly written application or strange input.
> Interesting oops.
> Basically your "page->buffers" thing seems to be NULL.
> Which is certainly interesting. And, thinking about it, quite legal. The
> page can have been up-to-date a long time ago, and we ended up pruning the
> buffers away in order to be able to free the page later - so when truncate
> comes along and wants to look at the buffers they don't exist any more.
> This is basically all due to the fact that the new truncate logic does a
> "__block_commit_write()" without ever having itself called any of the
> routines that establish the buffers (a regular write will always have
> called "__block_prepare_write()" first, for example.)
> We really should have done a true "block_truncate_write()", but it looked
> so clever to just re-use the existing code. Fair enough.
> Still willing to test?

Ok, hopefully this will make sense...

__block_commit_write calls balance_dirty, which might wait on bdflush,
running all the io on the page. The async_end_io handlers will unlock the
page once io on all the buffer heads is done.

So, by the time generic_file_write (or the new truncate code) calls
UnlockPage, the page could have been unlocked by i/o, and relocked by
another process.

Or am I missing something?


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:38    [W:0.228 / U:0.092 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site