linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Luis Chamberlain <mcgrof@kernel.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: axboe@kernel.dk, viro@zeniv.linux.org.uk, bvanassche@acm.org,
	gregkh@linuxfoundation.org, rostedt@goodmis.org,
	mingo@redhat.com, jack@suse.cz, ming.lei@redhat.com,
	nstange@suse.de, akpm@linux-foundation.org, mhocko@suse.com,
	yukuai3@huawei.com, linux-block@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, Omar Sandoval <osandov@fb.com>,
	Hannes Reinecke <hare@suse.com>, Michal Hocko <mhocko@kernel.org>
Subject: Re: [PATCH 3/5] blktrace: refcount the request_queue during ioctl
Date: Wed, 15 Apr 2020 06:16:49 +0000	[thread overview]
Message-ID: <20200415061649.GS11244@42.do-not-panic.com> (raw)
In-Reply-To: <20200414154044.GB25765@infradead.org>

On Tue, Apr 14, 2020 at 08:40:44AM -0700, Christoph Hellwig wrote:
> On Tue, Apr 14, 2020 at 04:19:00AM +0000, Luis Chamberlain wrote:
> > Ensure that the request_queue is refcounted during its full
> > ioctl cycle. This avoids possible races against removal, given
> > blk_get_queue() also checks to ensure the queue is not dying.
> > 
> > This small race is possible if you defer removal of the request_queue
> > and userspace fires off an ioctl for the device in the meantime.
> 
> Hmm, where exactly does the race come in so that it can only happen
> after where you take the reference, but not before it?  I'm probably
> missing something, but that just means it needs to be explained a little
> better :)

From the trace on patch 2/5:

    BLKTRACE_SETUP(loop0) #2
    [   13.933961] == blk_trace_ioctl(2, BLKTRACESETUP) start
    [   13.936758] === do_blk_trace_setup(2) start
    [   13.938944] === do_blk_trace_setup(2) creating directory
    [   13.941029] === do_blk_trace_setup(2) using what debugfs_lookup() gave
    
    ---> From LOOP_CTL_DEL(loop0) #2
    [   13.971046] === blk_trace_cleanup(7) end
    [   13.973175] == __blk_trace_remove(7) end
    [   13.975352] == blk_trace_shutdown(7) end
    [   13.977415] = __blk_release_queue(7) calling blk_mq_debugfs_unregister()
    [   13.980645] ==== blk_mq_debugfs_unregister(7) begin
    [   13.980696] ==== blk_mq_debugfs_unregister(7) debugfs_remove_recursive(q->debugfs_dir)
    [   13.983118] ==== blk_mq_debugfs_unregister(7) end q->debugfs_dir is NULL
    [   13.986945] = __blk_release_queue(7) blk_mq_debugfs_unregister() end
    [   13.993155] = __blk_release_queue(7) end
    
    ---> From BLKTRACE_SETUP(loop0) #2
    [   13.995928] === do_blk_trace_setup(2) end with ret: 0
    [   13.997623] == blk_trace_ioctl(2, BLKTRACESETUP) end

The BLKTRACESETUP above works on request_queue which later
LOOP_CTL_DEL races on and sweeps the debugfs dir underneath us.
If you use this commit alone though, this doesn't fix the race issue
however, and that's because of both still the debugfs_lookup() use
and that we're still using asynchronous removal at this point.

refcounting will just ensure we don't take the request_queue underneath
our noses.

Should I just add this to the commit log?

  Luis


  reply	other threads:[~2020-04-15  6:16 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-14  4:18 [PATCH 0/5] blktrace: fix use after free Luis Chamberlain
2020-04-14  4:18 ` [PATCH 1/5] block: move main block debugfs initialization to its own file Luis Chamberlain
2020-04-14  7:35   ` Greg KH
2020-04-15  2:44   ` Bart Van Assche
2020-04-14  4:18 ` [PATCH 2/5] blktrace: fix debugfs use after free Luis Chamberlain
2020-04-14  7:37   ` Greg KH
2020-04-14 15:38   ` Christoph Hellwig
2020-04-15  2:46   ` Bart Van Assche
2020-04-15 17:38   ` Eric Sandeen
2020-04-15 21:48     ` Bart Van Assche
2020-04-16  0:56     ` Luis Chamberlain
2020-04-16  1:02       ` Eric Sandeen
2020-04-16  1:20         ` Luis Chamberlain
2020-04-16  2:10   ` Ming Lei
2020-04-16  5:25     ` Luis Chamberlain
2020-04-16  5:47       ` Ming Lei
2020-04-16  6:09         ` Ming Lei
2020-04-16  6:22           ` Luis Chamberlain
2020-04-16  6:20         ` Luis Chamberlain
2020-04-16  6:28           ` Ming Lei
2020-04-17  4:09             ` Luis Chamberlain
2020-04-14  4:19 ` [PATCH 3/5] blktrace: refcount the request_queue during ioctl Luis Chamberlain
2020-04-14 15:40   ` Christoph Hellwig
2020-04-15  6:16     ` Luis Chamberlain [this message]
2020-04-15  7:14       ` Christoph Hellwig
2020-04-15 12:34         ` Luis Chamberlain
2020-04-15 12:39           ` Christoph Hellwig
2020-04-15 13:25             ` Luis Chamberlain
2020-04-15 14:18           ` Bart Van Assche
2020-04-16  1:12             ` Luis Chamberlain
2020-04-16  3:43               ` Bart Van Assche
2020-04-16  5:29                 ` Luis Chamberlain
2020-04-15 14:45       ` Bart Van Assche
2020-04-16  1:17         ` Luis Chamberlain
2020-04-16  2:31   ` Ming Lei
2020-04-16  5:36     ` Luis Chamberlain
2020-04-14  4:19 ` [PATCH 4/5] mm/swapfile: refcount block and queue before using blkcg_schedule_throttle() Luis Chamberlain
2020-04-14 15:44   ` Christoph Hellwig
2020-04-15  5:42     ` Luis Chamberlain
2020-04-15  7:27       ` Christoph Hellwig
2020-04-15  7:34         ` Christoph Hellwig
2020-04-15 13:19           ` Luis Chamberlain
2020-04-16  6:10             ` Christoph Hellwig
2020-04-16  6:22   ` Ming Lei
2020-04-16  6:25     ` Luis Chamberlain
2020-04-16  6:34       ` Ming Lei
2020-04-14  4:19 ` [PATCH 5/5] block: revert back to synchronous request_queue removal Luis Chamberlain
2020-04-14 15:47   ` Christoph Hellwig
2020-04-14 20:58     ` Luis Chamberlain
2020-04-15  6:46       ` Christoph Hellwig
2020-04-15 13:20         ` Luis Chamberlain
2020-04-16  2:36   ` Ming Lei
2020-04-14  7:38 ` [PATCH 0/5] blktrace: fix use after free Greg KH

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=20200415061649.GS11244@42.do-not-panic.com \
    --to=mcgrof@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=axboe@kernel.dk \
    --cc=bvanassche@acm.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hare@suse.com \
    --cc=hch@infradead.org \
    --cc=jack@suse.cz \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.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 \
    --cc=yukuai3@huawei.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).