All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ming Lei <ming.lei@redhat.com>
To: John Garry <john.garry@huawei.com>
Cc: Bart Van Assche <bvanassche@acm.org>,
	axboe@kernel.dk, linux-block@vger.kernel.org,
	linux-kernel@vger.kernel.org, hch@lst.de, hare@suse.de,
	kashyap.desai@broadcom.com, linuxarm@huawei.com
Subject: Re: [RFC PATCH v2 2/2] blk-mq: Lockout tagset iter when freeing rqs
Date: Tue, 22 Dec 2020 21:24:28 +0800	[thread overview]
Message-ID: <20201222132428.GA2938310@T590> (raw)
In-Reply-To: <2d985fbd-7a22-6399-e214-8052604a2a65@huawei.com>

On Tue, Dec 22, 2020 at 11:22:19AM +0000, John Garry wrote:
> Resend without ppvk@codeaurora.org, which bounces for me
> 
> On 22/12/2020 02:13, Bart Van Assche wrote:
> > On 12/21/20 10:47 AM, John Garry wrote:
> >> Yes, I agree, and I'm not sure what I wrote to give that impression.
> >>
> >> About "root partition", above, I'm just saying that / is mounted on a
> >> sda partition:
> >>
> >> root@ubuntu:/home/john# mount | grep sda
> >> /dev/sda2 on / type ext4 (rw,relatime,errors=remount-ro,stripe=32)
> >> /dev/sda1 on /boot/efi type vfat
> >> (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
> > Hi John,
> >
> 
> Hi Bart, Ming,
> 
> > Thanks for the clarification. I want to take back my suggestion about
> > adding rcu_read_lock() / rcu_read_unlock() in blk_mq_tagset_busy_iter()
> > since it is not allowed to sleep inside an RCU read-side critical
> > section, since blk_mq_tagset_busy_iter() is used in request timeout
> > handling and since there may be blk_mq_ops.timeout implementations that
> > sleep.
> 
> Yes, that's why I was going with atomic, rather than some synchronization
> primitive which may sleep.
> 
> >
> > Ming's suggestion to serialize blk_mq_tagset_busy_iter() and
> > blk_mq_free_rqs() looks interesting to me.
> >
> 
> So then we could have something like this:
> 
> ---8<---
> 
>  -435,9 +444,13 @@ void blk_mq_queue_tag_busy_iter(struct request_queue *q,
> busy_iter_fn *fn,
>     if (!blk_mq_hw_queue_mapped(hctx))
>             continue;
> 
> +    while (!atomic_inc_not_zero(&tags->iter_usage_counter));
> +
>     if (tags->nr_reserved_tags)
>         bt_for_each(hctx, tags->breserved_tags, fn, priv, true);
>     bt_for_each(hctx, tags->bitmap_tags, fn, priv, false);
> 
> +    atomic_dec(&tags->iter_usage_counter);
> }

Then it is just one spin_lock variant, and you may have to consider
lock validation.

For example, scsi_host_busy() is called from scsi_log_completion()<-scsi_softirq_done(),
which may be run in irq context, then dead lock can be triggered when the irq
is fired during freeing request.

thanks,
Ming


      reply	other threads:[~2020-12-22 13:26 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-17 11:07 [RFC PATCH v2 0/2] blk-mq: Avoid use-after-free for accessing old requests John Garry
2020-12-17 11:07 ` [RFC PATCH v2 1/2] blk-mq: Clean up references to old requests when freeing rqs John Garry
2020-12-17 11:07 ` [RFC PATCH v2 2/2] blk-mq: Lockout tagset iter " John Garry
2020-12-18  1:55   ` Bart Van Assche
2020-12-18  9:30     ` John Garry
2020-12-18  3:31   ` Ming Lei
2020-12-18 10:01     ` John Garry
2020-12-18 22:43   ` Bart Van Assche
2020-12-21 12:06     ` John Garry
2020-12-21 18:09       ` Bart Van Assche
2020-12-21 18:47         ` John Garry
2020-12-22  2:13           ` Bart Van Assche
2020-12-22 11:15             ` John Garry
2020-12-22 16:16               ` Bart Van Assche
2020-12-23 11:10                 ` John Garry
2020-12-23 11:40                   ` John Garry
2020-12-23 15:47                     ` Bart Van Assche
2021-01-04 15:33                       ` John Garry
2021-01-04 17:22                         ` Bart Van Assche
2021-01-04 18:43                           ` John Garry
     [not found]                           ` <760304b3-dcbc-5b9d-0c70-627b7ff5b4eb@huawei.com>
2021-02-10 14:39                             ` John Garry
2020-12-22 11:22             ` John Garry
2020-12-22 13:24               ` Ming Lei [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=20201222132428.GA2938310@T590 \
    --to=ming.lei@redhat.com \
    --cc=axboe@kernel.dk \
    --cc=bvanassche@acm.org \
    --cc=hare@suse.de \
    --cc=hch@lst.de \
    --cc=john.garry@huawei.com \
    --cc=kashyap.desai@broadcom.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxarm@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.