With this, the pty dentry is dropped once we d_delete it. This makes
sense since in devpts_pty_new we always create a new dentry with
d_alloc_name(). Previously, without providing a .op_delete, we would
end up leaving garbage in dentry_hashtable.
As a matter of fact, the d_hash of the garbage are likely to collide
because pty numebers are allocated as mall integers. Therefore, a few
chains in the hashtable get polluted more easily and path lookups
hitting them get slowed down. In a long running system which has an
application that frequently creates and destroys ptys, those chains can
get very long (thousands or millions of unused dentry), which seriously
hurts d_alloc_parallel() in which there is a seq based retry logic.
Specifically, we have seen a system that has accumulated 7 million pty
dentries (for /dev/pts/5) in a single chain, in dentry_hashtable. Some
other system monitoring progresses keep scanning /proc to get process
information, and occasionally a certain /proc/$pid path lookup made by
tem hits that long chain, making d_alloc_parallel stalled. In this case,
soft lockups are observed.
To emulate such a workload, do this:
while echo > /dev/ptmx; true; done
In a few minutes the system will have a very unbalanced
dentry_hashtable.
This patch fixes the above issue.
Signed-off-by: Fam Zheng <zhengfeiran@xxxxxxxxxxxxx>
---
fs/devpts/inode.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/devpts/inode.c b/fs/devpts/inode.c
index c53814539070..ce43301f1219 100644
--- a/fs/devpts/inode.c
+++ b/fs/devpts/inode.c
@@ -456,6 +456,7 @@ devpts_fill_super(struct super_block *s, void *data, int silent)
s->s_magic = DEVPTS_SUPER_MAGIC;
s->s_op = &devpts_sops;
s->s_time_gran = 1;
+ s->s_d_op = &simple_dentry_operations;
error = -ENOMEM;
s->s_fs_info = new_pts_fs_info(s);
--
2.11.0
