From: Miklos Szeredi <miklos@szeredi.hu>
To: Amir Goldstein <amir73il@gmail.com>
Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
syzkaller-bugs@googlegroups.com,
Al Viro <viro@zeniv.linux.org.uk>,
syzbot <syzbot+31d8b84465a7cbfd8515@syzkaller.appspotmail.com>,
overlayfs <linux-unionfs@vger.kernel.org>
Subject: Re: possible deadlock in pipe_lock (2)
Date: Mon, 11 Feb 2019 13:06:34 +0100 [thread overview]
Message-ID: <CAJfpegvjLgXa1HOCZkz6RKup7UdioMGyY7W4miyqcRtn9PL4QA@mail.gmail.com> (raw)
In-Reply-To: <CAOQ4uxhhRs6kBH2rgbPyjd=tXoxxuJG76Y2vpCYmD0c0HzLwhA@mail.gmail.com>
On Mon, Feb 11, 2019 at 8:38 AM Amir Goldstein <amir73il@gmail.com> wrote:
>
> On Sun, Feb 10, 2019 at 8:23 PM syzbot
> <syzbot+31d8b84465a7cbfd8515@syzkaller.appspotmail.com> wrote:
> > -> #1 (&ovl_i_mutex_key[depth]){+.+.}:
> > down_write+0x38/0x90 kernel/locking/rwsem.c:70
> > inode_lock include/linux/fs.h:757 [inline]
> > ovl_write_iter+0x148/0xc20 fs/overlayfs/file.c:231
> > call_write_iter include/linux/fs.h:1863 [inline]
> > new_sync_write fs/read_write.c:474 [inline]
> > __vfs_write+0x613/0x8e0 fs/read_write.c:487
> > kobject: 'loop4' (000000009e2b886d): kobject_uevent_env
> > __kernel_write+0x110/0x3b0 fs/read_write.c:506
> > write_pipe_buf+0x15d/0x1f0 fs/splice.c:797
> > splice_from_pipe_feed fs/splice.c:503 [inline]
> > __splice_from_pipe+0x39a/0x7e0 fs/splice.c:627
> > splice_from_pipe+0x108/0x170 fs/splice.c:662
> > default_file_splice_write+0x3c/0x90 fs/splice.c:809
Irrelevant to the lockdep splat, but why isn't there an
ovl_splice_write() that just recurses into realfile->splice_write()?
Sounds like a much more efficient way to handle splice read and
write...
[...]
> Miklos,
>
> Its good that this report popped up again, because I went to
> look back at my notes from previous report [1].
> If I was right in my previous analysis then we must have a real
> deadlock in current "lazy copy up" WIP patches. Right?
Hmm, AFAICS this circular dependency translated into layman's terms:
pipe lock -> ovl inode lock (splice to ovl file)
ovl inode lock -> upper freeze lock (truncate of ovl file)
upper freeze lock -> pipe lock (splice to upper file)
> "This looks like a false positive because lockdep is not aware of
> s_stack_depth of the file (fs) associated with the pipe.
But AFAICS the above dependency doesn't include copy up or stacked
overlay, so looks like a real deadlock.
Am I missing something?
Thanks,
Miklos
next prev parent reply other threads:[~2019-02-11 12:06 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-10 18:23 possible deadlock in pipe_lock (2) syzbot
2019-02-11 7:38 ` Amir Goldstein
2019-02-11 12:06 ` Miklos Szeredi [this message]
2019-02-11 12:37 ` Miklos Szeredi
2019-02-11 13:08 ` Amir Goldstein
2019-02-11 14:33 ` Miklos Szeredi
2019-02-11 15:06 ` Amir Goldstein
2019-02-11 15:40 ` Miklos Szeredi
2019-02-11 17:04 ` Amir Goldstein
2019-02-12 11:14 ` Jan Kara
2019-02-12 13:39 ` Amir Goldstein
2019-02-12 14:19 ` Miklos Szeredi
2019-02-12 16:11 ` Jan Kara
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=CAJfpegvjLgXa1HOCZkz6RKup7UdioMGyY7W4miyqcRtn9PL4QA@mail.gmail.com \
--to=miklos@szeredi.hu \
--cc=amir73il@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-unionfs@vger.kernel.org \
--cc=syzbot+31d8b84465a7cbfd8515@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
--cc=viro@zeniv.linux.org.uk \
/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).