All of lore.kernel.org
 help / color / mirror / Atom feed
From: Amir Goldstein <amir73il@gmail.com>
To: "Jérémy Jean" <jeremy.jean@oss.cyber.gouv.fr>
Cc: Christian Brauner <brauner@kernel.org>,
	miklos@szeredi.hu, linux-unionfs@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/3] ovl: disable nfs_export for same-sb lower layers with different idmaps
Date: Mon, 9 Nov 2026 15:51:49 +0100	[thread overview]
Message-ID: <avHeBTeJlQfrSIPa@amir-ThinkPad-T480> (raw)
In-Reply-To: <5e8dff576ead72fa502b7cd38889e780@oss.cyber.gouv.fr>

On Sun, Nov 08, 2026 at 08:12:49PM +0100, Jérémy Jean wrote:
> On 2026-09-25 16:17, Amir Goldstein wrote:
> > On Fri, Sep 25, 2026 at 3:51 PM Christian Brauner <brauner@kernel.org>
> > wrote:
> > > 
> > > On Mon, Sep 21, 2026 at 10:10:28AM +0200, Amir Goldstein wrote:
> > > > On Sun, Sep 20, 2026 at 10:33 PM Jérémy Jean
> > > > <Jeremy.Jean@oss.cyber.gouv.fr> wrote:
> > > > >
> > > > > Overlay file handles identify a backing filesystem, but not the lower
> > > > > mount used to decode it. If lower layers share a superblock and use
> > > > > different idmaps, a file handle can decode through the wrong layer and
> > > > > initialize the overlay inode with the wrong owner.
> > > > >
> > > > > Track the first lower idmap seen for each ovl_sb and disable nfs_export
> > > > > when another lower layer on the same backing superblock uses a different
> > > > > idmap. Keep index enabled: copy up starts from the overlay dentry selected
> > > > > by lookup and does not need to decode a lower file handle through another
> > > > > layer.
> > > > >
> > > > > Fixes: bc70682a497c ("ovl: support idmapped layers")
> > > > > Assisted-by: Codex:gpt-5
> > > > > Signed-off-by: Jérémy Jean <Jeremy.Jean@oss.cyber.gouv.fr>
> > > > > ---
...
> > > > > +/*
> > > > > + * Lower file handles identify a lower fs, but not the mount whose idmap was
> > > > > + * used to decode them.  Remember the first lower idmap seen for each fs so
> > > > > + * decodable export handles can be disabled if another one appears.
> > > 
> > > I find this behavior counterintuitive. Shouldn't we just fail the
> > > mount then?
> > 
> > I would love to fail the mount if you confirm that setting up an ovl
> > with several
> > lower layers some on the same fs with different idmap, is a non-feature.
> > 
> > I don't know can't /home/amir and /home/brauner be on the same fs with
> > different idmapping?
> > 
> > Could it ever make sense to compose an overlay from two such
> > directories?
> > If not then I would gladly remove this setup from the test matrix.
> > 
> > Thanks,
> > Amir.
> 
> Hello,
> 
> I'm digging this up: should I investigate to prepare a new version that
> simply fails the mount?

Yes, please.

Thanks,
Amir.

  reply	other threads:[~2026-11-09 14:51 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-20 20:32 [PATCH v2 0/3] ovl: disable nfs_export for mixed-idmap same-sb lower layers Jérémy Jean
2026-09-20 20:32 ` [PATCH v2 1/3] ovl: disable nfs_export for same-sb lower layers with different idmaps Jérémy Jean
2026-09-21  8:10   ` Amir Goldstein
2026-09-25 13:51     ` Christian Brauner
2026-09-25 14:17       ` Amir Goldstein
2026-11-08 19:12         ` Jérémy Jean
2026-11-09 14:51           ` Amir Goldstein [this message]
2026-09-20 20:32 ` [PATCH v2 2/3] selftests: overlayfs: reject handles for mixed lower idmaps Jérémy Jean
2026-09-21  8:14   ` Amir Goldstein
2026-09-20 20:32 ` [PATCH v2 3/3] selftests: overlayfs: keep index copy up with " Jérémy Jean
2026-09-21  8:18   ` Amir Goldstein
2026-09-21  8:03 ` [PATCH v2 0/3] ovl: disable nfs_export for mixed-idmap same-sb lower layers Amir Goldstein
2026-09-21  8:22   ` Jérémy Jean

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=avHeBTeJlQfrSIPa@amir-ThinkPad-T480 \
    --to=amir73il@gmail.com \
    --cc=brauner@kernel.org \
    --cc=jeremy.jean@oss.cyber.gouv.fr \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.