--On 09/05/00 18:13:53 -0700 Linus Torvalds <email@example.com> 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
Or am I missing something?
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Sep 07 2000 - 21:00:24 EST