From: Vivek Goyal <vgoyal@redhat.com>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
linux-unionfs@vger.kernel.org, syzkaller-bugs@googlegroups.com
Subject: Re: [PATCH] ovl: relax WARN_ON() for overlapping layers use case
Date: Thu, 28 Mar 2019 17:40:08 -0400 [thread overview]
Message-ID: <20190328214008.GB3559@redhat.com> (raw)
In-Reply-To: <20190328153829.729-1-amir73il@gmail.com>
On Thu, Mar 28, 2019 at 05:38:29PM +0200, Amir Goldstein wrote:
> This nasty little syzbot repro:
> https://syzkaller.appspot.com/x/repro.syz?x=12c7a94f400000
>
> Creates overlay mounts where the same directory is both in upper
> and lower layers. Simplified example:
>
> mkdir foo work
> mount -t overlay none foo -o"lowerdir=.,upperdir=foo,workdir=work"
>
> The repro runs several threads in parallel that attempt to chdir
> into foo and attempt to symlink/rename/exec/mkdir the file bar.
>
> The repro hits a WARN_ON() I placed in ovl_instantiate(), which
> suggests that an overlay inode already exists in cache and is hashed
> by the pointer of the real upper dentry that ovl_create_real() has
> just created. At the point of the WARN_ON(), for overlay dir inode
> lock is held and upper dir inode lock, so at first, I did not see how
> this was possible.
>
> On a closer look, I see that after ovl_create_real(), because of the
> overlapping upper and lower layers, a lookup by another thread can
> find the file foo/bar that was just created in upper layer, at overlay
> path foo/foo/bar and hash the an overlay inode with the new real dentry
> as lower dentry. This is possible because the overlay directory
> foo/foo is not locked and the upper dentry foo/bar is in dcache, so
> ovl_lookup() can find it without taking upper dir inode shared lock.
>
> Overlapping layers is considered a wrong setup which would result in
> unexpected behavior, but it shouldn't crash the kernel and it shouldn't
> trigger WARN_ON() either,
Hi Amir,
Is it possible detect this overlapping layer configuration and fail the
mount instead (is_subdir())?
Vivek
next prev parent reply other threads:[~2019-03-28 21:40 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-28 15:38 [PATCH] ovl: relax WARN_ON() for overlapping layers use case Amir Goldstein
2019-03-28 21:40 ` Vivek Goyal [this message]
2019-03-28 22:20 ` Amir Goldstein
2019-03-29 15:40 ` Vivek Goyal
2019-03-29 19:43 ` Amir Goldstein
2019-03-30 19:44 ` Miklos Szeredi
2019-03-31 5:41 ` Amir Goldstein
2019-04-02 6:46 ` Amir Goldstein
2019-05-08 11:03 ` Amir Goldstein
2019-05-08 11:26 ` Miklos Szeredi
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=20190328214008.GB3559@redhat.com \
--to=vgoyal@redhat.com \
--cc=amir73il@gmail.com \
--cc=linux-unionfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=syzkaller-bugs@googlegroups.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 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.