The patch titled
Subject: autofs4: use ACCESS_ONCE rather than rcu_dereference for dentry->d_inode
has been removed from the -mm tree. Its filename was
autofs4-d_manage-should-return-eisdir-when-appropriate-in-rcu-walk-mode-fix.patch
This patch was dropped because it was folded into autofs4-d_manage-should-return-eisdir-when-appropriate-in-rcu-walk-mode.patch
------------------------------------------------------
From: NeilBrown <neilb@xxxxxxx>
Subject: autofs4: use ACCESS_ONCE rather than rcu_dereference for dentry->d_inode
As the kbuild test robot reports, rcu_dereference() isn't really
appropriate here - we don't need a memory barrier, just a guard
against accidentally dereferencing NULL.
This can be merged into
autofs4: d_manage() should return -EISDIR when appropriate in rcu-walk mod=
e.
in 'mm'.
Signed-off-by: NeilBrown <neilb@xxxxxxx>
Cc: Ian Kent <raven@xxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
fs/autofs4/root.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN fs/autofs4/root.c~autofs4-d_manage-should-return-eisdir-when-appropriate-in-rcu-walk-mode-fix fs/autofs4/root.c
--- a/fs/autofs4/root.c~autofs4-d_manage-should-return-eisdir-when-appropriate-in-rcu-walk-mode-fix
+++ a/fs/autofs4/root.c
@@ -463,7 +463,7 @@ static int autofs4_d_manage(struct dentr
return 0;
if (d_mountpoint(dentry))
return 0;
- inode = rcu_dereference(dentry->d_inode);
+ inode = ACCESS_ONCE(dentry->d_inode);
if (inode && S_ISLNK(inode->i_mode))
return -EISDIR;
if (list_empty(&dentry->d_subdirs))
_
Patches currently in -mm which might be from neilb@xxxxxxx are
origin.patch
autofs4-allow-rcu-walk-to-walk-through-autofs4.patch
autofs4-factor-should_expire-out-of-autofs4_expire_indirect.patch
autofs4-make-autofs4_can_expire-idempotent.patch
autofs4-avoid-taking-fs_lock-during-rcu-walk.patch
autofs4-d_manage-should-return-eisdir-when-appropriate-in-rcu-walk-mode.patch
autofs-the-documentation-i-wanted-to-read.patch
--
To unsubscribe from this list: send the line "unsubscribe mm-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
