Re: [PATCH]: ufs: ufs_get_locked_patch race fix

From: Nick Piggin
Date: Tue Aug 01 2006 - 03:16:05 EST


Andrew Morton wrote:

On Mon, 31 Jul 2006 16:57:02 +0400
Evgeniy Dushistov <dushistov@xxxxxxx> wrote:


As discussed earlier:
http://lkml.org/lkml/2006/6/28/136
this patch fixes such issue:
`ufs_get_locked_page' takes page from cache
after that `vmtruncate' takes page and deletes it from cache
`ufs_get_locked_page' locks page, and reports about EIO error.

Also because of find_lock_page always return valid page or NULL,
we have no need check it if page not NULL.

Signed-off-by: Evgeniy Dushistov <dushistov@xxxxxxx>


---


Index: linux-2.6.18-rc2-mm1/fs/ufs/util.c
===================================================================
--- linux-2.6.18-rc2-mm1.orig/fs/ufs/util.c
+++ linux-2.6.18-rc2-mm1/fs/ufs/util.c
@@ -257,6 +257,7 @@ try_again:
page = read_cache_page(mapping, index,
(filler_t*)mapping->a_ops->readpage,
NULL);
+
if (IS_ERR(page)) {
printk(KERN_ERR "ufs_change_blocknr: "
"read_cache_page error: ino %lu, index: %lu\n",
@@ -266,6 +267,13 @@ try_again:

lock_page(page);

+ if (unlikely(page->mapping != mapping ||
+ page->index != index)) {
+ unlock_page(page);
+ page_cache_release(page);
+ goto try_again;
+ }
+
if (!PageUptodate(page) || PageError(page)) {
unlock_page(page);
page_cache_release(page);


Looks good to me.

Is there any need to be checking ->index? Normally we simply use the
sequence:

lock_page(page);
if (page->mapping == NULL)
/* truncate got there first */

to handle this case.


If you already have a reference on the page, I believe no. We have to
be a bit careful about it in the core vm now that splice can move
pages between different parts of the same mapping, but any code outside
mm/ shouldn't need to worry (exactly because they should have a ref
before doing the lock_page).
--

Send instant messages to your online friends http://au.messenger.yahoo.com -
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/