From: "NeilBrown" <neil@brown.name>
To: "Amir Goldstein" <amir73il@gmail.com>
Cc: "Miklos Szeredi" <miklos@szeredi.hu>,
linux-unionfs@vger.kernel.org,
"Alexander Viro" <viro@zeniv.linux.org.uk>,
"Christian Brauner" <brauner@kernel.org>,
"Jan Kara" <jack@suse.cz>,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 00/12] ovl: narrow regions protected by directory i_rw_sem
Date: Thu, 26 Jun 2025 07:35:27 +1000 [thread overview]
Message-ID: <175088732709.2280845.16573886517114282970@noble.neil.brown.name> (raw)
In-Reply-To: <CAOQ4uxhZbfg-u0w8uRVYPkNe+GXcragA5hwtZrc1_RJ5qznVeg@mail.gmail.com>
On Thu, 26 Jun 2025, Amir Goldstein wrote:
> On Wed, Jun 25, 2025 at 1:07 AM NeilBrown <neil@brown.name> wrote:
> >
> > This series of patches for overlayfs is primarily focussed on preparing
> > for some proposed changes to directory locking. In the new scheme we
> > wil 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.
> >
> > The first patch in this series doesn't exactly match the above, but it
> > does relate to directory locking and I think it is a sensible
> > simplificaiton.
> >
> > I have tested this with fstests, both generic and unionfs tests. I
> > wouldn't be surprised if I missed something though, so please review
> > carefully.
>
> Can you share a git branch for me to pull and test?
My current work tree can be found at
https://github.com/neilbrown/linux/tree/pdirops
or branch "pdirops" of
https://github.com/neilbrown/linux.git
Thanks for the thorough review - I'll work through it and respond over
coming days.
Thanks,
NeilBrown
prev parent reply other threads:[~2025-06-25 21:35 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-24 22:54 [PATCH 00/12] ovl: narrow regions protected by directory i_rw_sem NeilBrown
2025-06-24 22:54 ` [PATCH 01/12] ovl: use is_subdir() for testing if one thing is a subdir of another NeilBrown
2025-06-25 14:54 ` Amir Goldstein
2025-06-25 21:45 ` NeilBrown
2025-06-24 22:54 ` [PATCH 02/12] ovl: Call ovl_create_temp() and ovl_create_index() without lock held NeilBrown
2025-06-25 15:44 ` Amir Goldstein
2025-06-25 16:02 ` Amir Goldstein
2025-06-28 3:08 ` Dan Carpenter
2025-06-24 22:54 ` [PATCH 03/12] ovl: narrow the locked region in ovl_copy_up_workdir() NeilBrown
2025-06-25 19:07 ` Amir Goldstein
2025-06-24 22:55 ` [PATCH 04/12] ovl: narrow locking in ovl_create_upper() NeilBrown
2025-06-25 17:55 ` Amir Goldstein
2025-06-25 18:17 ` Amir Goldstein
2025-06-24 22:55 ` [PATCH 05/12] ovl: narrow locking in ovl_clear_empty() NeilBrown
2025-06-25 18:22 ` Amir Goldstein
2025-06-24 22:55 ` [PATCH 06/12] ovl: narrow locking in ovl_create_over_whiteout() NeilBrown
2025-06-25 19:08 ` Amir Goldstein
2025-06-24 22:55 ` [PATCH 07/12] ovl: narrow locking in ovl_rename() NeilBrown
2025-06-25 18:30 ` Amir Goldstein
2025-07-02 2:16 ` NeilBrown
2025-06-24 22:55 ` [PATCH 08/12] ovl: narrow locking in ovl_cleanup_whiteouts() NeilBrown
2025-06-25 18:35 ` Amir Goldstein
2025-06-24 22:55 ` [PATCH 09/12] ovl: whiteout locking changes NeilBrown
2025-06-25 18:54 ` Amir Goldstein
2025-07-02 2:21 ` NeilBrown
2025-06-24 22:55 ` [PATCH 10/12] ovl: narrow locking in ovl_check_rename_whiteout() NeilBrown
2025-06-25 19:04 ` Amir Goldstein
2025-07-02 2:41 ` NeilBrown
2025-07-02 10:04 ` Amir Goldstein
2025-07-02 10:23 ` Amir Goldstein
2025-06-24 22:55 ` [PATCH 11/12] ovl: change ovl_create_real() to receive dentry parent NeilBrown
2025-06-25 19:05 ` Amir Goldstein
2025-06-24 22:55 ` [PATCH 12/12] ovl: rename ovl_cleanup_unlocked() to ovl_cleanup() NeilBrown
2025-06-25 18:57 ` Amir Goldstein
2025-06-25 14:56 ` [PATCH 00/12] ovl: narrow regions protected by directory i_rw_sem Amir Goldstein
2025-06-25 21:35 ` NeilBrown [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=175088732709.2280845.16573886517114282970@noble.neil.brown.name \
--to=neil@brown.name \
--cc=amir73il@gmail.com \
--cc=brauner@kernel.org \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-unionfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).