Messages in this thread | | | From | Miklos Szeredi <> | Date | Fri, 11 Jun 2021 15:11:48 +0200 | Subject | Re: [PATCH v6 5/7] kernfs: use i_lock to protect concurrent inode updates |
| |
On Wed, 9 Jun 2021 at 10:52, Ian Kent <raven@themaw.net> wrote: > > The inode operations .permission() and .getattr() use the kernfs node > write lock but all that's needed is to keep the rb tree stable while > updating the inode attributes as well as protecting the update itself > against concurrent changes. > > And .permission() is called frequently during path walks and can cause > quite a bit of contention between kernfs node operations and path > walks when the number of concurrent walks is high. > > To change kernfs_iop_getattr() and kernfs_iop_permission() to take > the rw sem read lock instead of the write lock an additional lock is > needed to protect against multiple processes concurrently updating > the inode attributes and link count in kernfs_refresh_inode(). > > The inode i_lock seems like the sensible thing to use to protect these > inode attribute updates so use it in kernfs_refresh_inode(). > > The last hunk in the patch, applied to kernfs_fill_super(), is possibly > not needed but taking the lock was present originally and I prefer to > continue to take it so the rb tree is held stable during the call to > kernfs_refresh_inode() made by kernfs_get_inode(). > > Signed-off-by: Ian Kent <raven@themaw.net>
Reviewed-by: Miklos Szeredi <mszeredi@redhat.com>
| |