* d_add and dentry leak
@ 2019-02-21 7:45 Fam Zheng
2019-02-21 8:30 ` Al Viro
0 siblings, 1 reply; 3+ messages in thread
From: Fam Zheng @ 2019-02-21 7:45 UTC (permalink / raw)
To: linux-fsdevel
Cc: Fam Zheng, Alexander Viro, Fam Zheng, 段熊春,
Shine Liu
We’ve noticed an issue that frequent open,close,open,close... of /dev/ptmx eventually causes soft lockup.
Here is a summary of what happened.
Upon user opening /dev/ptmx, devpts_pty_new calls d_alloc_name and d_add, the new dentry is inserted into dcache_hashtable.
Later when closing, devpts_pty_kill calls d_delete and dput, but per the conditionals in them, neither calls __d_drop:
- d_delete sees “dentry->d_lockref.count == 1” and takes the “dentry_unlink_inode” branch, avoiding __d_drop.
- dput takes the “likely(fast_dput(dentry))” branch and skips dentry_kill() altogether (which would have called __d_drop).
The problem is that each devpts_pty_new creates a new dentry, which as a result stays in the hashtable forever. Reuse cannot happen because the devpts always uses d_add instead of d_alloc_parallel.
This can be a problem if a user has a loop to open/close /dev/ptmx, because a specific link in the hash is hit, making it ever grow longer.
In a system that has an unfortunate application that spawns a lot of short living processes and allocates ttys for each, such stale dentries accumulate, which are hashed the same, making a million elem long hash chain. In this case, d_alloc_parallel will more often than not need a few retries due to seq change because one __d_lookup_rcu call can take a second or so.
Reproducer:
while echo >/dev/ptmx; :; done
Overtime, one of your unlucky path lookups (that hits the same hash bucket as affected by above) will slow down significantly.
Should devpts clean up differently? Or should d_delete be fixed?
Thanks,
Fam
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: d_add and dentry leak
2019-02-21 7:45 d_add and dentry leak Fam Zheng
@ 2019-02-21 8:30 ` Al Viro
2019-02-21 9:13 ` Fam Zheng
0 siblings, 1 reply; 3+ messages in thread
From: Al Viro @ 2019-02-21 8:30 UTC (permalink / raw)
To: Fam Zheng; +Cc: linux-fsdevel, Fam Zheng, 段熊春, Shine Liu
On Thu, Feb 21, 2019 at 03:45:06PM +0800, Fam Zheng wrote:
> We’ve noticed an issue that frequent open,close,open,close... of /dev/ptmx eventually causes soft lockup.
>
> Here is a summary of what happened.
>
> Upon user opening /dev/ptmx, devpts_pty_new calls d_alloc_name and d_add, the new dentry is inserted into dcache_hashtable.
>
> Later when closing, devpts_pty_kill calls d_delete and dput,
... since it looks like a normal negative dentry, to be eventually
evicted upon memory pressure. That's not the worst problem in
there, actually - consider
touch /tmp/a
mount --bind /tmp/a /dev/pts/<number>
followed by devpts_pty_kill() taking that sucker out...
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: d_add and dentry leak
2019-02-21 8:30 ` Al Viro
@ 2019-02-21 9:13 ` Fam Zheng
0 siblings, 0 replies; 3+ messages in thread
From: Fam Zheng @ 2019-02-21 9:13 UTC (permalink / raw)
To: Al Viro; +Cc: Fam Zheng, linux-fsdevel, 段熊春, Shine Liu
> On Feb 21, 2019, at 16:30, Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> On Thu, Feb 21, 2019 at 03:45:06PM +0800, Fam Zheng wrote:
>> We’ve noticed an issue that frequent open,close,open,close... of /dev/ptmx eventually causes soft lockup.
>>
>> Here is a summary of what happened.
>>
>> Upon user opening /dev/ptmx, devpts_pty_new calls d_alloc_name and d_add, the new dentry is inserted into dcache_hashtable.
>>
>> Later when closing, devpts_pty_kill calls d_delete and dput,
>
> ... since it looks like a normal negative dentry, to be eventually
> evicted upon memory pressure. That's not the worst problem in
> there, actually - consider
> touch /tmp/a
> mount --bind /tmp/a /dev/pts/<number>
> followed by devpts_pty_kill() taking that sucker out...
I think then the pty dentry stops us from operating the real mount point, is that what you mean? Once devpts_pty_kill() returns, I’ll have no way to unmount the bind mount...
Fam
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2019-02-21 9:13 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-02-21 7:45 d_add and dentry leak Fam Zheng
2019-02-21 8:30 ` Al Viro
2019-02-21 9:13 ` Fam Zheng
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.