Re: [PATCH 3/3] ovl: Use real disk UUID for origin file handles

[André Almeida]

Em 28/01/2026 08:49, Amir Goldstein escreveu:
> On Sat, Jan 24, 2026 at 11:45 AM Amir Goldstein <amir73il@xxxxxxxxx> wrote:
> > On Fri, Jan 23, 2026 at 9:08 PM André Almeida <andrealmeid@xxxxxxxxxx> wrote:
> > > Em 23/01/2026 10:24, André Almeida escreveu:
> > > > Em 22/01/2026 17:07, Amir Goldstein escreveu:
> > > > > On Tue, Jan 20, 2026 at 4:12 PM Amir Goldstein <amir73il@xxxxxxxxx>
> > > > > wrote:
> > > > > > On Mon, Jan 19, 2026 at 5:56 PM André Almeida
> > > > > > <andrealmeid@xxxxxxxxxx> wrote:
> > > > > > >
> > > > > ...
> > > > > > > Actually they are not in the same fs, upper and lower are coming from
> > > > > > > different fs', so when trying to mount I get the fallback to
> > > > > > > `uuid=null`. A quick hack circumventing this check makes the mount
> > > > > > > work.
> > > > > > >
> > > > > > > If you think this is the best way to solve this issue (rather than
> > > > > > > following the VFS helper path for instance),
> > > > > >
> > > > > > That's up to you if you want to solve the "all lower layers on same fs"
> > > > > > or want to also allow lower layers on different fs.
> > > > > > The former could be solved by relaxing the ovl rules.
> > > > > >
> > > > > > > please let me know how can
> > > > > > > I safely lift this restriction, like maybe adding a new flag for this?
> > > > > >
> > > > > > I think the attached patch should work for you and should not
> > > > > > break anything.
> > > > > >
> > > > > > It's only sanity tested and will need to write tests to verify it.
> > > > >
> > > > > Andre,
> > > > >
> > > > > I tested the patch and it looks good on my side.
> > > > > If you want me to queue this patch for 7.0,
> > > > > please let me know if it addresses your use case.
> > > >
> > > > Hi Amir,
> > > >
> > > > I'm still testing it to make sure it works my case, I will return to you
> > > > ASAP. Thanks for the help!
> > >
> > > So, your patch wasn't initially working in my setup here, and after some
> > > debugging it turns out that on ovl_verify_fh() *fh would have a NULL
> > > UUID, but *ofh would have a valid UUID, so the compare would then fail.
> > >
> > > Adding this line at ovl_get_fh() fixed the issue for me and made the
> > > patch work as I was expecting:
> > >
> > > +       if (!ovl_origin_uuid(ofs))
> > > +               fh->fb.uuid = uuid_null;
> > > +
> > >           return fh;
> > >
> > > Please let me know if that makes sense to you.
> >
> > It does not make sense to me.
> > I think you may be using the uuid=off feature in the wrong way.
> > What you did was to change the stored UUID, but this NOT the
> > purpose of uuid=off.
> >
> > The purpose of uuid=off is NOT to allow mounting an overlayfs
> > that was previously using a different lower UUID.
> > The purpose is to mount overlayfs the from the FIRST time with
> > uuid=off so that ovl_verify_origin_fh() gets null uuid from the
> > first call that sets the ORIGIN xattr.
> >
> > IOW, if user want to be able to change underlying later UUID
> > user needs to declare from the first overlayfs mount that this
> > is expected to happen, otherwise, overlayfs will assume that
> > an unintentional wrong configuration was used.
> >
> > I updated the documentation to try to explain this better:
> >
> > Is my understanding of the problems you had correct?
> > Is my solution understood and applicable to your use case?
>
> Hi Andre,
>
> Sorry to nag you, but if you'd like me to queue the suggested change to 7.0,
> I would need your feedback soon.

Hey Amir, sorry for my delay. I just had a week out of the office and 
just got back to this.

Our initial test case worked great! We managed to mount both images and 
use overlayfs without a problem after your clarification of where to use 
uuid=off, which should be on the first mount.

However, when rebooting to the other partition, the mount failed with 
"failed to verify upper root origin" again, but I believe that I forgot 
to add `uuid=off` somewhere in the mount scripts. I'm still debugging this.

Anyhow, I see that we are now too close to the merge window, and from my 
side we can delay this for 7.1 and merge it when it gets 100% clear that 
this is the solution that we are looking for.

Thanks again for your help!
	André

> FWIW, I think that this change of restrictions for uuid=null could be backported
> to stable kernels, but I am not going to mark it for auto select, because
> I'd rather see if anyone shouts with upstream kernel first when (if) we make
> this change and manually backport later per demand.
>
> Thanks,
> Amir.