mirror of
https://github.com/torvalds/linux.git
synced 2026-11-06 21:58:01 +01:00
0ddc887102
Please consider pulling these changes from the signed vfs-7.4-rc1.kernfs tag. Thanks! Christian -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQRAhzRXHqcMeLMyaSiRxhvAZXjcogUCatHrlgAKCRCRxhvAZXjc ojr5AP42ZHmQU1u1W2WZvSp0d7z2i9Hp9j5ezK1JJjZQSE6FcgD+KalCPX7v9jB8 OQ0fQnauE2Ji3+qXO0tbIwij7gWP2wc= =9ucf -----END PGP SIGNATURE----- Merge tag 'vfs-7.4-rc1.kernfs' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs Pull kernfs updates from Christian Brauner: "This contains kernfs scalability work from Shakeel driven by what Meta sees in their fleet. kernfs_rwsem is per kernfs root, so sysfs and cgroupfs each have one for the whole machine, and every create, remove and rename takes it for writing. rwsems don't let readers steal the lock once a writer is queued, so one cgroup being created or a device being renamed parks the entire incoming reader stream in uninterruptible sleep. Daemons that poll cgroup files in a loop turn that into a convoy and the two that hurt most, oomd and below, are the ones that are supposed to relieve memory pressure and record what happened. kernfs_dop_revalidate() took kernfs_rwsem for read once per path component of every walk into a kernfs mount. Nothing it reads needs the semaphore. kn->active is an atomic_t, kn->__parent and kn->name are rcu pointers, kn->ns can be compared instead of dereferenced and the directory revision is a plain counter. The callback runs under rcu now. Readers walking cgroupfs and sysfs while another thread churns cgroups, renames netdevs and plugs devices went from 48,593,360 read acquisitions and 1,744,517 contentions to 1,280,280 and 429,846 on an 8-CPU VM and path walk throughput improved 35-53%. LOOKUP_RCU still returns ECHILD because kernfs_iop_permission() forces every walk out of rcu-walk anyway. That is left for later. kernfs_fop_readdir() held the semaphore across dir_emit(). dir_emit() copies to userspace and under memory pressure that fault goes to reclaim with the lock every create, remove and rename needs held for reading. Meta sees 120 second allocation stalls in filldir64() from below and systemd-oomd stuck behind it. The lock is dropped around dir_emit() now. Since the entry the listing stopped on can disappear in that window and two entries can share a hash, readdir resumes on the full (hash, ns, name) key and the fallback search lands after the missing entry instead of repeating or skipping one. The repeat was a pre-existing bug between two getdents(2) calls. Three more lock holds are shortened. kernfs_notify_workfn() no longer holds kernfs_rwsem across fsnotify() which allocates against the memcg of the watching cgroup that is already under pressure. The open node is allocated outside the hashed open file mutex, the most contended lock in kernfs on their fleet with 2.19M waiters over 29 days and a 77ms median hold. A new node is activated without dropping and retaking the write lock, lock_stat says 1200 -> 830 write acquisitions for five dummy netdevs, and kernfs_rename_ns() allocates the new name before and frees the old one after the lock so a rename can't enter reclaim or wait out a grace period with it held. Three standalone fixes come with selftests. Same-parent renames take kernfs_rename_lock too so kernfs_path_from_node() can't build a path that never existed. Decoding a file handle takes the semaphore so a decode racing rmdir() can't hash an inode after the removal's ilookup() pass and lose IN_DELETE_SELF. And kernfs_create_link() reads the target's uid and gid under kernfs_iattr_rwsem so a chown in between can't give the link an owner the target never had. The kernfs selftests grew from two xattr checks to coverage of dentry revalidation, rename, namespace tagging, file handles and readdir under churn" * tag 'vfs-7.4-rc1.kernfs' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs: kernfs: free the old name outside kernfs_rwsem kernfs: allocate the new name outside kernfs_rwsem kernfs: activate a new node without dropping kernfs_rwsem selftests: cover readdir resuming at a removed entry kernfs: don't hold kernfs_rwsem across dir_emit() kernfs: resume readdir on the full entry key kernfs: don't repeat or skip an entry when readdir resumes kernfs: don't hold kernfs_rwsem across notification delivery kernfs: allocate the open node outside the open file mutex kernfs: fix up the unlocked attribute reads on the creation paths kernfs: don't lose IN_DELETE_SELF when decoding a file handle kernfs: take kernfs_rename_lock for same-parent renames too selftests: cover kernfs file handles and same-parent rename selftests: cover kernfs dentry revalidation kernfs: Remove kernfs_rwsem from dentry revalidation kernfs: Avoid namespace dereference in d_revalidate() kernfs: Prepare directory revisions for lockless reads kernfs: Use VFS lookup context in d_revalidate() |
||
|---|---|---|
| .. | ||
| dir.c | ||
| file.c | ||
| inode.c | ||
| Kconfig | ||
| kernfs-internal.h | ||
| Makefile | ||
| mount.c | ||
| symlink.c | ||