From: Luis Chamberlain <mcgrof@kernel.org>
To: Nicolai Stange <nstange@suse.de>
Cc: Bart Van Assche <bvanassche@acm.org>,
axboe@kernel.dk, viro@zeniv.linux.org.uk,
gregkh@linuxfoundation.org, rostedt@goodmis.org,
mingo@redhat.com, jack@suse.cz, ming.lei@redhat.com,
mhocko@suse.com, linux-block@vger.kernel.org,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
Omar Sandoval <osandov@fb.com>, Hannes Reinecke <hare@suse.com>,
Michal Hocko <mhocko@kernel.org>
Subject: Re: [RFC 3/3] block: avoid deferral of blk_release_queue() work
Date: Thu, 9 Apr 2020 18:11:11 +0000 [thread overview]
Message-ID: <20200409181111.GJ11244@42.do-not-panic.com> (raw)
In-Reply-To: <87o8saj62m.fsf@suse.de>
On Thu, Apr 02, 2020 at 04:49:37PM +0200, Nicolai Stange wrote:
> Bart Van Assche <bvanassche@acm.org> writes:
>
> > On 2020-04-01 17:00, Luis Chamberlain wrote:
> > The description of this patch mentions a single blk_release_queue() call
> > that happened in the past from a context from which sleeping is not
> > allowed and from which sleeping is allowed today. Have all other
> > blk_release_queue() / blk_put_queue() calls been verified to see whether
> > none of these happens from a context from which sleeping is not allowed?
>
> I've just done this today and found the following potentially
> problematic call paths to blk_put_queue().
>
> 1.) mem_cgroup_throttle_swaprate() takes a spinlock and
> calls blkcg_schedule_throttle()->blk_put_queue().
>
> Also note that AFAICS mem_cgroup_try_charge_delay() can be called
> with GFP_ATOMIC.
I have a solution to this which would avoid having to deal with the
concern completely. I'll post in my follow up.
> 2.) scsi_unblock_requests() gets called from a lot of drivers and
> invoke blk_put_queue() through
> scsi_unblock_requests() -> scsi_run_host_queues() ->
> scsi_starved_list_run() -> blk_put_queue().
sd_probe() calls device_add_disk(), and the scsi lib also has its
own refcounting for scsi, but unless you call sd_remove() you'll be
protecting the underlying block disk and request_queue, as sd_remove()
calls the del_gendisk() which would in call call blk_unregister_queue()
which calls the last blk_put_queue(). If sd_remove() can be called from
atomic context we can also fix this, and this should be evident how in
my next follow up series of patches.
Luis
next prev parent reply other threads:[~2020-04-09 18:11 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-01 23:59 [RFC 0/3] block: address blktrace use-after-free Luis Chamberlain
2020-04-02 0:00 ` [RFC 1/3] block: move main block debugfs initialization to its own file Luis Chamberlain
2020-04-05 3:12 ` Bart Van Assche
2020-04-06 14:23 ` Luis Chamberlain
2020-04-02 0:00 ` [RFC 2/3] blktrace: fix debugfs use after free Luis Chamberlain
2020-04-02 1:57 ` Eric Sandeen
2020-04-02 16:14 ` Luis Chamberlain
2020-04-05 3:39 ` Bart Van Assche
2020-04-06 1:27 ` Eric Sandeen
2020-04-06 4:25 ` Bart Van Assche
2020-04-06 9:18 ` Nicolai Stange
2020-04-06 15:19 ` Luis Chamberlain
2020-04-07 8:15 ` Luis Chamberlain
2020-04-06 14:29 ` Eric Sandeen
2020-04-07 8:09 ` Luis Chamberlain
2020-04-06 15:14 ` Luis Chamberlain
2020-04-02 0:00 ` [RFC 3/3] block: avoid deferral of blk_release_queue() work Luis Chamberlain
2020-04-02 3:39 ` Bart Van Assche
2020-04-02 14:49 ` Nicolai Stange
2020-04-06 9:11 ` Nicolai Stange
2020-04-09 18:11 ` Luis Chamberlain [this message]
2020-04-02 7:44 ` [RFC 0/3] block: address blktrace use-after-free Greg KH
2020-04-03 8:19 ` Ming Lei
2020-04-03 14:06 ` Luis Chamberlain
2020-04-03 14:13 ` Bart Van Assche
2020-04-03 19:49 ` Luis Chamberlain
2020-04-07 2:47 ` yukuai (C)
2020-04-07 19:00 ` Luis Chamberlain
2020-04-09 20:59 ` Luis Chamberlain
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=20200409181111.GJ11244@42.do-not-panic.com \
--to=mcgrof@kernel.org \
--cc=axboe@kernel.dk \
--cc=bvanassche@acm.org \
--cc=gregkh@linuxfoundation.org \
--cc=hare@suse.com \
--cc=jack@suse.cz \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mhocko@kernel.org \
--cc=mhocko@suse.com \
--cc=ming.lei@redhat.com \
--cc=mingo@redhat.com \
--cc=nstange@suse.de \
--cc=osandov@fb.com \
--cc=rostedt@goodmis.org \
--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).