Messages in this thread |  | | Date | Tue, 05 Sep 2000 21:35:13 -0400 | From | Chris Mason <> | Subject | Re: Still ext2-corruption in test8-pre5 (incl. OOPS) |
| |
--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/
|  |