Re: [PATCH v3 00/21] ovl: narrow regions protected by i_rw_sem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 16 Jul 2025, Amir Goldstein wrote:
> On Wed, Jul 16, 2025 at 2:47 AM NeilBrown <neil@xxxxxxxxxx> wrote:
> >
> > More excellent review feedback - more patches :-)
> >
> > I've chosen to use ovl_parent_lock() here as a temporary and leave the
> > debate over naming for the VFS version of the function until all the new
> > names are introduced later.
> 
> Perfect.
> 
> Please push v3 patches to branch pdirops, or to a clean branch
> based on vfs-6.17.file, so I can test them.

There is a branch "ovl" which is based on vfs.all as I depend on a
couple of other vfs changes.

Thanks,
NeilBrown


> 
> Thanks,
> Amir.
> 
> 
> >
> >
> > Original description:
> >
> > This series of patches for overlayfs is primarily focussed on preparing
> > for some proposed changes to directory locking.  In the new scheme we
> > will lock individual dentries in a directory rather than the whole
> > directory.
> >
> > ovl currently will sometimes lock a directory on the upper filesystem
> > and do a few different things while holding the lock.  This is
> > incompatible with the new scheme.
> >
> > This series narrows the region of code protected by the directory lock,
> > taking it multiple times when necessary.  This theoretically open up the
> > possibilty of other changes happening on the upper filesytem between the
> > unlock and the lock.  To some extent the patches guard against that by
> > checking the dentries still have the expect parent after retaking the
> > lock.  In general, I think ovl would have trouble if upperfs were being
> > changed independantly, and I don't think the changes here increase the
> > problem in any important way.
> >
> > After this series (with any needed changes) lands I will resubmit my
> > change to vfs_rmdir() behaviour to have it drop the lock on error.  ovl
> > will be much better positioned to handle that change.  It will come with
> > the new "lookup_and_lock" API that I am proposing.
> >
> > Thanks,
> > NeilBrown
> >
> >  [PATCH v3 01/21] ovl: simplify an error path in ovl_copy_up_workdir()
> >  [PATCH v3 02/21] ovl: change ovl_create_index() to take dir locks
> >  [PATCH v3 03/21] ovl: Call ovl_create_temp() without lock held.
> >  [PATCH v3 04/21] ovl: narrow the locked region in
> >  [PATCH v3 05/21] ovl: narrow locking in ovl_create_upper()
> >  [PATCH v3 06/21] ovl: narrow locking in ovl_clear_empty()
> >  [PATCH v3 07/21] ovl: narrow locking in ovl_create_over_whiteout()
> >  [PATCH v3 08/21] ovl: simplify gotos in ovl_rename()
> >  [PATCH v3 09/21] ovl: narrow locking in ovl_rename()
> >  [PATCH v3 10/21] ovl: narrow locking in ovl_cleanup_whiteouts()
> >  [PATCH v3 11/21] ovl: narrow locking in ovl_cleanup_index()
> >  [PATCH v3 12/21] ovl: narrow locking in ovl_workdir_create()
> >  [PATCH v3 13/21] ovl: narrow locking in ovl_indexdir_cleanup()
> >  [PATCH v3 14/21] ovl: narrow locking in ovl_workdir_cleanup_recurse()
> >  [PATCH v3 15/21] ovl: change ovl_workdir_cleanup() to take dir lock
> >  [PATCH v3 16/21] ovl: narrow locking on ovl_remove_and_whiteout()
> >  [PATCH v3 17/21] ovl: change ovl_cleanup_and_whiteout() to take
> >  [PATCH v3 18/21] ovl: narrow locking in ovl_whiteout()
> >  [PATCH v3 19/21] ovl: narrow locking in ovl_check_rename_whiteout()
> >  [PATCH v3 20/21] ovl: change ovl_create_real() to receive dentry
> >  [PATCH v3 21/21] ovl: rename ovl_cleanup_unlocked() to ovl_cleanup()
> 





[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux