From: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
To: Pavel Tatashin <pasha.tatashin@soleen.com>,
Tyler Hicks <tyhicks@linux.microsoft.com>,
Petr Vorel <pvorel@suse.cz>, Christoph Hellwig <hch@lst.de>
Cc: Jens Axboe <axboe@kernel.dk>,
Stefan Haberland <sth@linux.ibm.com>,
Jan Hoeppner <hoeppner@linux.ibm.com>,
linux-block <linux-block@vger.kernel.org>,
syzbot <syzbot+61e04e51b7ac86930589@syzkaller.appspotmail.com>,
Tejun Heo <tj@kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Dmitry Vyukov <dvyukov@google.com>
Subject: Re: [syzbot] possible deadlock in del_gendisk
Date: Sun, 13 Jun 2021 20:01:58 +0900 [thread overview]
Message-ID: <c18d05a0-335f-260b-67ac-1ba28814f703@i-love.sakura.ne.jp> (raw)
In-Reply-To: <b817de92-668a-de29-0a81-eecc4124130b@i-love.sakura.ne.jp>
On 2021/06/12 11:35, Tetsuo Handa wrote:
> On 2021/06/12 0:49, Tetsuo Handa wrote:
>> On 2021/06/12 0:18, Pavel Tatashin wrote:
>>>>> Well, I made commit 310ca162d779efee ("block/loop: Use global lock for ioctl() operation.")
>>>>> because per device lock was not sufficient. Did commit 6cc8e7430801fa23 ("loop: scale loop
>>>>> device by introducing per device lock") take this problem into account?
>>>>
>>>> This was my intention when I wrote 6cc8e7430801fa23 ("loop: scale loop
>>>> device by introducing per device lock"). This is why this change does
>>>> not simply revert 310ca162d779efee ("block/loop: Use global lock for
>>>> ioctl() operation."), but keeps loop_ctl_mutex to protect the global
>>>> accesses. loop_control_ioctl() is still locked by global
>>>> loop_ctl_mutex.
>>
>> No, loop_control_ioctl() (i.e. /dev/loop-control) is irrelevant here.
>> What 310ca162d779efee addressed but (I worry) 6cc8e7430801fa23 broke is
>> lo_ioctl() (i.e. /dev/loop$num).
>>
>> syzbot was reporting NULL pointer dereference which is caused by
>> race condition between ioctl(loop_fd, LOOP_CLR_FD, 0) versus
>> ioctl(other_loop_fd, LOOP_SET_FD, loop_fd) due to traversing other
>> loop devices at loop_validate_file() without holding corresponding
>> lo->lo_mutex lock.
>
> Here is a reproducer and a race window widening patch.
> Since loop_validate_file() traverses on other loop devices,
> changing fd of loop device needs to be protected using a global lock.
>
At least LOOP_SET_FD, LOOP_CONFIGURE, LOOP_CHANGE_FD, LOOP_CLR_FD needs to be
serialized using a global lock because loop_validate_file() traverses on other
loop devices which can cause NULL pointer dereference like syzbot has reported
in the past.
And I think LOOP_SET_CAPACITY, LOOP_SET_DIRECT_IO, LOOP_SET_BLOCK_SIZE also
needs to be serialized using a global lock because loop_change_fd() checks
capacity and dio state of other loop device which is not serialized.
I'd like to apply
[PATCH] loop: drop loop_ctl_mutex around del_gendisk() in loop_remove()
as soon as possible because it is current top crasher (crashing on every 39 seconds).
I suggest simply reverting commit 6cc8e7430801fa23 ("loop: scale loop device by
introducing per device lock") for now. Do you want to revert 6cc8e7430801fa23
before my patch? If yes, I'll update my patch. If no, I'll just ask Jens to send
my patch to Linus.
prev parent reply other threads:[~2021-06-13 11:02 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-13 17:33 [syzbot] possible deadlock in del_gendisk syzbot
2021-04-13 17:41 ` Steven Rostedt
2021-04-13 17:43 ` Steven Rostedt
2021-04-13 18:24 ` Dmitry Vyukov
2021-04-13 18:40 ` Steven Rostedt
2021-04-13 18:43 ` Steven Rostedt
2021-04-16 7:51 ` Bisections with different bug manifestations Dmitry Vyukov
2021-04-16 13:13 ` Steven Rostedt
2021-04-16 13:26 ` Dmitry Vyukov
2021-04-16 13:48 ` Dmitry Vyukov
2021-06-07 10:56 ` [syzbot] possible deadlock in del_gendisk Tetsuo Handa
2021-06-09 16:31 ` Tetsuo Handa
2021-06-09 16:46 ` Tyler Hicks
2021-06-10 13:37 ` Tetsuo Handa
2021-06-11 6:46 ` Tetsuo Handa
2021-06-11 15:14 ` [PATCH] loop: drop loop_ctl_mutex around del_gendisk() in loop_remove() Tetsuo Handa
2021-06-15 5:30 ` Tetsuo Handa
2021-06-15 5:31 ` syzbot
2021-06-15 9:04 ` Jan Kara
2021-06-11 14:47 ` [syzbot] possible deadlock in del_gendisk Tetsuo Handa
2021-06-11 15:11 ` Pavel Tatashin
2021-06-11 15:18 ` Pavel Tatashin
2021-06-11 15:49 ` Tetsuo Handa
2021-06-12 2:35 ` Tetsuo Handa
2021-06-13 11:01 ` Tetsuo Handa [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=c18d05a0-335f-260b-67ac-1ba28814f703@i-love.sakura.ne.jp \
--to=penguin-kernel@i-love.sakura.ne.jp \
--cc=axboe@kernel.dk \
--cc=dvyukov@google.com \
--cc=hch@lst.de \
--cc=hoeppner@linux.ibm.com \
--cc=linux-block@vger.kernel.org \
--cc=pasha.tatashin@soleen.com \
--cc=pvorel@suse.cz \
--cc=sth@linux.ibm.com \
--cc=syzbot+61e04e51b7ac86930589@syzkaller.appspotmail.com \
--cc=tj@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=tyhicks@linux.microsoft.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).