linux-unionfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Amir Goldstein <amir73il@gmail.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	overlayfs <linux-unionfs@vger.kernel.org>,
	Vivek Goyal <vgoyal@redhat.com>
Subject: Re: overlayfs: overlapping upperdir path
Date: Thu, 1 Apr 2021 18:19:53 +0300	[thread overview]
Message-ID: <CAOQ4uxjogAWRoVBDKJ85DOW6p9BbL__tZ3ApSbGiCFsWYoJdJQ@mail.gmail.com> (raw)
In-Reply-To: <CAJfpegvRr0dy=dfLA_NM+UMYi_jqOeGf=KsS=Pjf5dn-X6nt5A@mail.gmail.com>

On Thu, Apr 1, 2021 at 6:09 PM Miklos Szeredi <miklos@szeredi.hu> wrote:
>
> On Thu, Apr 1, 2021 at 4:30 PM Amir Goldstein <amir73il@gmail.com> wrote:
> >
> > On Thu, Apr 1, 2021 at 4:37 PM Miklos Szeredi <miklos@szeredi.hu> wrote:
> > >
> > > Commit 146d62e5a586 ("ovl: detect overlapping layers") made sure we
> > > don't have overapping layers, but it also broke the arguably valid use
> > > case of
> > >
> > >  mount -olowerdir=/,upperdir=/subdir,..
> > >
> > > where subdir also resides on the root fs.
> >
> > How is 'ls /merged/subdir' expected to behave in that use case?
> > Error?
>
> -ELOOP is the error returned.
>
> >
> > >
> > > I also see that we check for a trap at lookup time, so the question is
> > > what does the up-front layer check buy us?
> > >
> >
> > I'm not sure. I know it bought us silence from syzbot that started
> > mutating many overlapping layers repos....
> > Will the lookup trap have stopped it too? maybe. We did not try.
> >
> > In general I think that if we can error out to user on mount time
> > it is preferred, but if we need to make that use case work, I'd try
> > to relax as minimum as possible from the check.
>
> Certainly.  Like lower inside upper makes zero sense, OTOH upper
> inside lower does.   So I think we just need to relax the
> upperdir/workdir layer check in this case.
>
> Like attached patch.
>

Fine by me.
Let's let syzbot have fun ;-)

Thanks,
Amir.

      reply	other threads:[~2021-04-01 17:46 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-01 13:37 overlayfs: overlapping upperdir path Miklos Szeredi
2021-04-01 14:30 ` Amir Goldstein
2021-04-01 15:09   ` Miklos Szeredi
2021-04-01 15:19     ` Amir Goldstein [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=CAOQ4uxjogAWRoVBDKJ85DOW6p9BbL__tZ3ApSbGiCFsWYoJdJQ@mail.gmail.com \
    --to=amir73il@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=vgoyal@redhat.com \
    /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).