On Mon, 2007-04-02 at 14:09 +0200, Nick Piggin wrote: > Updated aops patchset against 2.6.21-rc5. > > http://www.kernel.org/pub/linux/kernel/people/npiggin/patches/new-aops/ > > Files/dirs are 2.6.21-rc5-new-aops* > > Contains numerous fixes from Mark and myself -- I'd say the core code is > getting reasonably stable at this point. > > New stuff: patches from Mark and Steve for the cluster filesystems. > > (compile only) patches for NFS, XFS, FUSE, eCryptfs. OK, they're untested, > but I have tried to put some effort in, so if maintainers would kindly > take a look... ext3 still needs review and porting to ext4, which I hope > someone will do eventually (I presume ext3 is still maintained)... does NFS > have a lock_page vs lock_kernel deadlock in its commit_write? (if yes, this > is fixable with the new write aops). In case of error, write_begin() is *supposed* to unlock and release the page it locked. Right ? If so, ext3 error handling is not quite right :( Here is the fix. Thanks, Badari --- fs/ext3/inode.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) Index: linux-2.6.21-rc5.aop/fs/ext3/inode.c =================================================================== --- linux-2.6.21-rc5.aop.orig/fs/ext3/inode.c 2007-04-02 10:21:44.000000000 -0700 +++ linux-2.6.21-rc5.aop/fs/ext3/inode.c 2007-04-02 13:08:41.000000000 -0700 @@ -1236,8 +1236,11 @@ retry: *pagep = page; handle = ext3_journal_start(inode, needed_blocks); - if (IS_ERR(handle)) + if (IS_ERR(handle)) { + unlock_page(page); + page_cache_release(page); return PTR_ERR(handle); + } ret = block_write_begin(file, mapping, pos, len, flags, pagep, fsdata, ext3_get_block); if (ret) @@ -1246,9 +1249,12 @@ retry: if (ext3_should_journal_data(inode)) { ret = walk_page_buffers(handle, page_buffers(page), start, end, NULL, do_journal_get_write_access); - if (ret) + if (ret) { /* fatal error, just put the handle and return */ + unlock_page(page); + page_cache_release(page); journal_stop(handle); + } } return ret; - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
