On Wed, Jul 21, 2021 at 5:33 PM Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
>
> On Wed, 21 Jul 2021 at 16:17, Amir Goldstein <amir73il@xxxxxxxxx> wrote:
> >
> > On Wed, Jul 21, 2021 at 4:10 PM Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
> > >
> > > On Tue, 27 Apr 2021 at 12:28, Amir Goldstein <amir73il@xxxxxxxxx> wrote:
> > > >
> > > > We get occasional reports of lookup errors due to mismatched
> > > > origin ftype from users that re-format a lower squashfs image.
> > > >
> > > > Commit 13c6ad0f45fd ("ovl: document lower modification caveats")
> > > > tries to discourage the practice of re-formating lower layers and
> > > > describes the expected behavior as undefined.
> > > >
> > > > Commit b0e0f69731cd ("ovl: restrict lower null uuid for "xino=auto"")
> > > > limits the configurations in which origin file handles are followed.
> > > >
> > > > In addition to these measures, change the behavior in case of detecting
> > > > a mismatch origin ftype in lookup to issue a warning, not follow origin,
> > > > but not fail the lookup operation either.
> > > >
> > > > That should make overall more users happy without any big consequences.
> > > >
> > > > Link: https://lore.kernel.org/linux-unionfs/CAOQ4uxgPq9E9xxwU2CDyHy-_yCZZeymg+3n+-6AqkGGE1YtwvQ@xxxxxxxxxxxxxx/
> > > > Signed-off-by: Amir Goldstein <amir73il@xxxxxxxxx>
> > > > ---
> > > >
> > > > Miklos,
> > > >
> > > > I am getting tired of dealing with lower squashfs related reports.
> > > > How about this?
> > > >
> > > > It passes the xfstests quick tests and no, I do not have a reproducer
> > > > for origin mismatch, so will wait for Byron to test the patch.
> > >
> > > Pushed a simplified variant that just changes the
> > > ovl_check_origin_fh() return value from -EIO to -ESTALE. Do you see
> > > a problem with this?
> > >
> >
> > The only difference is if ovl_fh_to_dentry() also emits a warning,
> > but since ovl_check_origin_fh() already has a warning I think that
> > your simplified version is fine.
>
> Yeah, you are right, new version could have one less warning in the
> ->fh_to_dentry() case, but I agree that that should not be a problem.
>
Technically, there is also a change in vfs api in the error returned to
exportfs_decode_fh_raw(), but both callers seem to convert EINVAL
to ESTALE anyway...
Thanks,
Amir.
