Re: Still ext2-corruption in test8-pre5 (incl. OOPS)

From: Chris Mason (mason@suse.com)
Date: Tue Sep 05 2000 - 20:35:13 EST


--On 09/05/00 18:13:53 -0700 Linus Torvalds <torvalds@transmeta.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
another process.

Or am I missing something?

-chris

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.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