linux-kernel - Re: [PATCH -next] blk-mq: fix tag

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:   Wed, 10 Nov 2021 15:33:35 +0800
From:   QiuLaibin <qiulaibin@...wei.com>
To:     <ming.lei@...hat.com>, <axboe@...nel.dk>,
        <linux-kernel@...r.kernel.org>, <linux-block@...r.kernel.org>
CC:     <martin.petersen@...cle.com>, <hare@...e.de>,
        <asml.silence@...il.com>, <bvanassche@....org>
Subject: Re: [PATCH -next] blk-mq: fix tag_get wait task can't be awakened


Hi Ming,

On 2021/09/26 20:48, Ming Lei wrote:
 > Hi Laibin,
 >
 > On Mon, Sep 13, 2021 at 04:12:48PM +0800, Laibin Qiu wrote:
 >> When multiple hctx share one tagset. The wake_batch is calculated
 >> during initialization by queue_depth. But when multiple hctx share one
 >> tagset. The queue depth assigned to each user may be smaller than
 >> wakeup_batch. This may cause the waiting queue to fail to wakup and
 >> leads to Hang.
 > In case of shared tags, there might be more than one hctx which 
allocates tag from single tags, and each hctx is limited to allocate at 
most:
 >
 > hctx_max_depth = max((bt->sb.depth + users - 1) / users, 4U);
 >
 > and
 >
 > users = atomic_read(&hctx->tags->active_queues)
 >
 > See hctx_may_queue().
 >
 > tag idle detection is lazy, and may be delayed for 30sec, so there 
could be just one real active hctx(queue) but all others are actually 
idle and still accounted as active because of the lazy idle detection. 
Then if wake_batch is > hctx_max_depth, driver tag allocation may wait 
forever on this real active hctx.
 >
 > Correct me if my understanding is wrong.

Your understanding is right. When we add lots of users for one shared 
tag, it will make wake_batch > hctx_max_dept. So driver tag allocation 
may wait forever on this real active hctx.

 >> Fix this by recalculating wake_batch when inc or dec active_queues.
 >>
 >> Fixes: 0d2602ca30e41 ("blk-mq: improve support for shared tags maps")
 >> Signed-off-by: Laibin Qiu <qiulaibin@...wei.com>
 >> ---
 >> block/blk-mq-tag.c | 44 +++++++++++++++++++++++++++++++++++++++--
 >> include/linux/sbitmap.h | 8 ++++++++
 >> lib/sbitmap.c | 3 ++-
 >> 3 files changed, 52 insertions(+), 3 deletions(-)
 >>
 >> diff --git a/block/blk-mq-tag.c b/block/blk-mq-tag.c index
 >> 86f87346232a..d02f5ac0004c 100644
 >> --- a/block/blk-mq-tag.c
 >> +++ b/block/blk-mq-tag.c
 >> @@ -16,6 +16,27 @@
 >> #include "blk-mq-sched.h"
 >> #include "blk-mq-tag.h"
 >> +static void bt_update_wake_batch(struct sbitmap_queue *bt, unsigned
 >> +int users) {
 >> + unsigned int depth;
 >> +
 >> + depth = max((bt->sb.depth + users - 1) / users, 4U);
 >> + sbitmap_queue_update_wake_batch(bt, depth);
 > Use the hctx's max queue depth could reduce wake_batch a lot, then 
performance may be degraded.
 >
 > Just wondering why not set sbq->wake_batch as hctx_max_depth if
 > sbq->wake_batch is < hctx_max_depth?
 >

__blk_mq_tag_busy() will add Users and __blk_mq_tag_idle() will decrease 
Users. Only changes in Users will affect each user's max depth. So we 
recalculate the matching wake_batch by 
sbitmap_queue_update_wake_batch(). sbitmap_queue_update_wake_batch() 
will calculate wake_batch by incoming depth. The value of 
sbq->wake_batch will only be changed when the calculated wake_batch changes.

static void sbitmap_queue_update_wake_batch(struct sbitmap_queue *sbq,
                                             unsigned int depth)
{
         unsigned int wake_batch = sbq_calc_wake_batch(sbq, depth);
^^^^^^^^^^^^^^^^^
         int i;
         if (sbq->wake_batch != wake_batch) {
             ^^^^^^^^^^^^^^^^^^
                 WRITE_ONCE(sbq->wake_batch, wake_batch);
                 /*
                  * Pairs with the memory barrier in sbitmap_queue_wake_up()
                  * to ensure that the batch size is updated before the wait
                  * counts.
                  */
                 smp_mb();
                 for (i = 0; i < SBQ_WAIT_QUEUES; i++)
                         atomic_set(&sbq->ws[i].wait_cnt, 1);
         }
}

 >
 > Thanks,
 > Ming

Thanks
Laibin