It is actually a VFS bug. A brand new one. Here's a fix, but we should
check that it still gets all the LTP writev cases right.
A couple of ext3 bugs in -mm2 have been fixed so please don't spend time
stresstesting it until mm3.
Thanks.
The recent writev() fix broke the invariant that ->commit_write _must_ be
called after a successful ->prepare_write(). It leaves ext3 with a
transaction stuck open and the filesystem locks up.
mm/filemap.c | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff -puN mm/filemap.c~generic_file_write-commit_write-fix mm/filemap.c
--- 25/mm/filemap.c~generic_file_write-commit_write-fix 2003-05-30 04:01:19.000000000 -0700
+++ 25-akpm/mm/filemap.c 2003-05-30 04:04:11.000000000 -0700
@@ -1718,10 +1718,9 @@ generic_file_aio_write_nolock(struct kio
copied = filemap_copy_from_user_iovec(page, offset,
cur_iov, iov_base, bytes);
flush_dcache_page(page);
+ status = a_ops->commit_write(file, page, offset,
+ offset + copied);
if (likely(copied > 0)) {
- status = a_ops->commit_write(file, page, offset,
- offset + copied);
-
if (!status)
status = copied;
_
-
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/