* [RFC] guarantee inode of alias's parent
@ 2017-07-07 13:28 Gioh Kim
2017-07-07 14:16 ` Al Viro
0 siblings, 1 reply; 2+ messages in thread
From: Gioh Kim @ 2017-07-07 13:28 UTC (permalink / raw)
To: viro; +Cc: linux-fsdevel, linux-kernel, Gioh Kim
Hi,
My server with v4.4 generated panic at __d_unalias() function.
It is following line.
if (!mutex_trylock(&alias->d_parent->d_inode->i_mutex))
I checked panic message and found i_mutex pointer was garbage value.
Call trace is like following:
[<ffffffff811ae628>] d_splice_alias+0x148/0x2a0
[<ffffffff81209231>] kernfs_iop_lookup+0x91/0xc0
[<ffffffff8119fe08>] lookup_real+0x18/0x60
[<ffffffff811a0193>] __lookup_hash+0x33/0x40
[<ffffffff811a2bb8>] walk_component+0x238/0x500
[<ffffffff811a2fec>] link_path_walk+0x16c/0x580
[<ffffffff811a1987>] ? path_init+0x1f7/0x3c0
[<ffffffff811a43bb>] path_openat+0xab/0x14c0
[<ffffffff811a6a8c>] do_filp_open+0x7c/0xd0
[<ffffffff811b345a>] ? __alloc_fd+0x3a/0x170
[<ffffffff81195c52>] do_sys_open+0x132/0x220
[<ffffffff81195d59>] SyS_open+0x19/0x20
[<ffffffff81804997>] entry_SYSCALL_64_fastpath+0x12/0x6a
Before __d_unalias(), the dentry and parent of the dentry
are locked. But I wonder how I can assure of existence of the
alias and the parent of the alias.
Where is the code to lock alias and alias->d_parent?
What will happend if alias->d_parent be deleted by another process?
I checked kernel code of v4.10. It also does not have any lock before
accessing alias->d_parent. Therefore I'm attaching a patch to show my idea,
not solve a problem.
This patch is based on v4.10.0
Signed-off-by: Gioh Kim <gi-oh.kim@profitbricks.com>
---
fs/dcache.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/fs/dcache.c b/fs/dcache.c
index 95d71eda8142..f7909447849e 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -2899,6 +2899,7 @@ static int __d_unalias(struct inode *inode,
struct mutex *m1 = NULL;
struct rw_semaphore *m2 = NULL;
int ret = -ESTALE;
+ struct dentry *alias_parent;
/* If alias and dentry share a parent, then no extra locks required */
if (alias->d_parent == dentry->d_parent)
@@ -2908,6 +2909,9 @@ static int __d_unalias(struct inode *inode,
if (!mutex_trylock(&dentry->d_sb->s_vfs_rename_mutex))
goto out_err;
m1 = &dentry->d_sb->s_vfs_rename_mutex;
+ alias_parent = dget_parent(alias->d_parent);
+ if (!alias_parent)
+ goto out_err;
if (!inode_trylock_shared(alias->d_parent->d_inode))
goto out_err;
m2 = &alias->d_parent->d_inode->i_rwsem;
@@ -2919,6 +2923,7 @@ static int __d_unalias(struct inode *inode,
up_read(m2);
if (m1)
mutex_unlock(m1);
+ dput(alias_parent);
return ret;
}
--
2.11.0
^ permalink raw reply related [flat|nested] 2+ messages in thread
* Re: [RFC] guarantee inode of alias's parent
2017-07-07 13:28 [RFC] guarantee inode of alias's parent Gioh Kim
@ 2017-07-07 14:16 ` Al Viro
0 siblings, 0 replies; 2+ messages in thread
From: Al Viro @ 2017-07-07 14:16 UTC (permalink / raw)
To: Gioh Kim; +Cc: linux-fsdevel, linux-kernel
On Fri, Jul 07, 2017 at 03:28:11PM +0200, Gioh Kim wrote:
> Before __d_unalias(), the dentry and parent of the dentry
> are locked. But I wonder how I can assure of existence of the
> alias and the parent of the alias.
>
> Where is the code to lock alias and alias->d_parent?
Nowhere. Why the hell would you want to lock them?
> What will happend if alias->d_parent be deleted by another process?
Huh? As soon as you've grabbed ->s_vfs_rename_mutex, ->d_parent of everything on
that filesystem is stable - and positive. Moreover, any positive dentry with
references held (in particular, anyone's parent) is going to remain such for
as long as those references are held.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2017-07-07 14:16 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-07-07 13:28 [RFC] guarantee inode of alias's parent Gioh Kim
2017-07-07 14:16 ` Al Viro
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox