linux-block.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pavel Tatashin <pasha.tatashin@soleen.com>
To: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: Tyler Hicks <tyhicks@linux.microsoft.com>,
	Petr Vorel <pvorel@suse.cz>, Christoph Hellwig <hch@lst.de>,
	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>
Subject: Re: [syzbot] possible deadlock in del_gendisk
Date: Fri, 11 Jun 2021 11:18:50 -0400	[thread overview]
Message-ID: <CA+CK2bBe5muuGbHgfK7JjbzRE5ogf1oeD1iYeY6eJB046p9_ZQ@mail.gmail.com> (raw)
In-Reply-To: <CA+CK2bDWb2=bsoacY-eqZExObBpXuZE0a3Mr18_FXmGZTC5GnQ@mail.gmail.com>

On Fri, Jun 11, 2021 at 11:11 AM Pavel Tatashin
<pasha.tatashin@soleen.com> wrote:
>
> On Fri, Jun 11, 2021 at 10:47 AM Tetsuo Handa
> <penguin-kernel@i-love.sakura.ne.jp> wrote:
> >
> > On 2021/06/10 1:46, Tyler Hicks wrote:
> > > Thanks for doing this. I haven't had a chance to retry this commit with
> > > lockdep but I did re-review it and didn't think that it would be the
> > > cause of this lockdep report since it strictly reduced the usage of the
> > > loop_ctl_mutex.
> >
> > 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.

From commit log of:
 310ca162d779efee ("block/loop: Use global lock for ioctl() operation.")

    Since ioctl() request on loop devices is not frequent operation, we don't
    need fine grained locking. Let's use global lock in order to allow safe
    traversal at loop_validate_file().

Unfortunately using a global lock is not scalable here. At Microsoft
we had a slow startup issue because we have several loop devices per
every container. Also, this report:
https://lore.kernel.org/lkml/20210217145629.GA4503@xsang-OptiPlex-9020/

Pasha

  reply	other threads:[~2021-06-11 15:19 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 [this message]
2021-06-11 15:49             ` Tetsuo Handa
2021-06-12  2:35               ` Tetsuo Handa
2021-06-13 11:01                 ` Tetsuo Handa

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=CA+CK2bBe5muuGbHgfK7JjbzRE5ogf1oeD1iYeY6eJB046p9_ZQ@mail.gmail.com \
    --to=pasha.tatashin@soleen.com \
    --cc=axboe@kernel.dk \
    --cc=hch@lst.de \
    --cc=hoeppner@linux.ibm.com \
    --cc=linux-block@vger.kernel.org \
    --cc=penguin-kernel@i-love.sakura.ne.jp \
    --cc=pvorel@suse.cz \
    --cc=sth@linux.ibm.com \
    --cc=syzbot+61e04e51b7ac86930589@syzkaller.appspotmail.com \
    --cc=tj@kernel.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).