Re: [PATCH]: ufs: ufs_get_locked_patch race fix

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Andrew Morton wrote:

On Mon, 31 Jul 2006 16:57:02 +0400
Evgeniy Dushistov <[email protected]> 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 <[email protected]>


---


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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux