[dm-devel] dm-rq: don't queue request during suspend

Ming Lei ming.lei at redhat.com
Thu Oct 7 07:06:53 UTC 2021


On Wed, Oct 06, 2021 at 10:15:58AM -0400, Mike Snitzer wrote:
> On Thu, Sep 23 2021 at  5:11P -0400,
> Ming Lei <ming.lei at redhat.com> wrote:
> 
> > DM uses blk-mq's quiesce/unquiesce to stop/start device mapper queue.
> > 
> > But blk-mq's unquiesce may come from outside events, such as elevator
> > switch, updating nr_requests or others, and request may come during
> > suspend, so simply ask for blk-mq to requeue it.
> > 
> > Fixes one kernel panic issue when running updating nr_requests and
> > dm-mpath suspend/resume stress test.
> > 
> > Signed-off-by: Ming Lei <ming.lei at redhat.com>
> > ---
> >  drivers/md/dm-rq.c | 8 ++++++++
> >  1 file changed, 8 insertions(+)
> > 
> > diff --git a/drivers/md/dm-rq.c b/drivers/md/dm-rq.c
> > index 5b95eea517d1..a896dea9750e 100644
> > --- a/drivers/md/dm-rq.c
> > +++ b/drivers/md/dm-rq.c
> > @@ -490,6 +490,14 @@ static blk_status_t dm_mq_queue_rq(struct blk_mq_hw_ctx *hctx,
> >  	struct mapped_device *md = tio->md;
> >  	struct dm_target *ti = md->immutable_target;
> >  
> > +	/*
> > +	 * blk-mq's unquiesce may come from outside events, such as
> > +	 * elevator switch, updating nr_requests or others, and request may
> > +	 * come during suspend, so simply ask for blk-mq to requeue it.
> > +	 */
> > +	if (unlikely(test_bit(DMF_BLOCK_IO_FOR_SUSPEND, &md->flags)))
> > +		return BLK_STS_RESOURCE;
> > +
> >  	if (unlikely(!ti)) {
> >  		int srcu_idx;
> >  		struct dm_table *map = dm_get_live_table(md, &srcu_idx);
> > -- 
> > 2.31.1
> > 
> 
> Hey Ming,
> 
> I've marked this for stable@ and queued this up.  BUT this test is
> racey, could easily be that device gets suspended just after your
> test.

Hello Mike,

I understand the device shouldn't be suspended after the test given
it is just like the following two tasks running contiguously in the
test:

1) task1
- suspend device mapper
- resume device mapper

2) task2
- updating nr_requests of the device mapper

BTW, it is reported as RH BZ1891486 in which it is easily reproduced,
however, seems device suspended isn't observed.

thanks, 
Ming




More information about the dm-devel mailing list