[PATCH 5.10 0/3] wbt stable patches

[PATCH 5.10 0/3] wbt stable patches

[Yu Kuai]

From: Yu Kuai <yukuai3@huawei.com>

Lei Chen (1):
  block: wbt: Remove unnecessary invoking of wbt_update_limits in
    wbt_init

Yu Kuai (2):
  blk-wbt: call rq_qos_add() after wb_normal is initialized
  blk-wbt: fix that 'rwb->wc' is always set to 1 in wbt_init()

 block/blk-wbt.c | 11 ++++-------
 1 file changed, 4 insertions(+), 7 deletions(-)

-- 
2.31.1

[PATCH 5.10 1/3] block: wbt: Remove unnecessary invoking of wbt_update_limits in wbt_init

[Yu Kuai]

From: Lei Chen <lennychen@tencent.com>

commit 5a20d073ec54a72d9a732fa44bfe14954eb6332f upstream.

It's unnecessary to call wbt_update_limits explicitly within wbt_init,
because it will be called in the following function wbt_queue_depth_changed.

Signed-off-by: Lei Chen <lennychen@tencent.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Yu Kuai <yukuai3@huawei.com>
---
 block/blk-wbt.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/block/blk-wbt.c b/block/blk-wbt.c
index 35d81b5deae1..4ec0a018a2ad 100644
--- a/block/blk-wbt.c
+++ b/block/blk-wbt.c
@@ -840,7 +840,6 @@ int wbt_init(struct request_queue *q)
 	rwb->enable_state = WBT_STATE_ON_DEFAULT;
 	rwb->wc = 1;
 	rwb->rq_depth.default_depth = RWB_DEF_DEPTH;
-	wbt_update_limits(rwb);
 
 	/*
 	 * Assign rwb and add the stats callback.
-- 
2.31.1

[PATCH 5.10 2/3] blk-wbt: call rq_qos_add() after wb_normal is initialized

[Yu Kuai]

From: Yu Kuai <yukuai3@huawei.com>

commit 8c5035dfbb9475b67c82b3fdb7351236525bf52b upstream.

Our test found a problem that wbt inflight counter is negative, which
will cause io hang(noted that this problem doesn't exist in mainline):

t1: device create	t2: issue io
add_disk
 blk_register_queue
  wbt_enable_default
   wbt_init
    rq_qos_add
    // wb_normal is still 0
			/*
			 * in mainline, disk can't be opened before
			 * bdev_add(), however, in old kernels, disk
			 * can be opened before blk_register_queue().
			 */
			blkdev_issue_flush
                        // disk size is 0, however, it's not checked
                         submit_bio_wait
                          submit_bio
                           blk_mq_submit_bio
                            rq_qos_throttle
                             wbt_wait
			      bio_to_wbt_flags
                               rwb_enabled
			       // wb_normal is 0, inflight is not increased

    wbt_queue_depth_changed(&rwb->rqos);
     wbt_update_limits
     // wb_normal is initialized
                            rq_qos_track
                             wbt_track
                              rq->wbt_flags |= bio_to_wbt_flags(rwb, bio);
			      // wb_normal is not 0，wbt_flags will be set
t3: io completion
blk_mq_free_request
 rq_qos_done
  wbt_done
   wbt_is_tracked
   // return true
   __wbt_done
    wbt_rqw_done
     atomic_dec_return(&rqw->inflight);
     // inflight is decreased

commit 8235b5c1e8c1 ("block: call bdev_add later in device_add_disk") can
avoid this problem, however it's better to fix this problem in wbt:

1) Lower kernel can't backport this patch due to lots of refactor.
2) Root cause is that wbt call rq_qos_add() before wb_normal is
initialized.

Fixes: e34cbd307477 ("blk-wbt: add general throttling mechanism")
Cc: <stable@vger.kernel.org>
Signed-off-by: Yu Kuai <yukuai3@huawei.com>
Link: https://lore.kernel.org/r/20220913105749.3086243-1-yukuai1@huaweicloud.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
---
 block/blk-wbt.c | 9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/block/blk-wbt.c b/block/blk-wbt.c
index 4ec0a018a2ad..bafdb8098893 100644
--- a/block/blk-wbt.c
+++ b/block/blk-wbt.c
@@ -840,6 +840,10 @@ int wbt_init(struct request_queue *q)
 	rwb->enable_state = WBT_STATE_ON_DEFAULT;
 	rwb->wc = 1;
 	rwb->rq_depth.default_depth = RWB_DEF_DEPTH;
+	rwb->min_lat_nsec = wbt_default_latency_nsec(q);
+
+	wbt_queue_depth_changed(&rwb->rqos);
+	wbt_set_write_cache(q, test_bit(QUEUE_FLAG_WC, &q->queue_flags));
 
 	/*
 	 * Assign rwb and add the stats callback.
@@ -847,10 +851,5 @@ int wbt_init(struct request_queue *q)
 	rq_qos_add(q, &rwb->rqos);
 	blk_stat_add_callback(q, rwb->cb);
 
-	rwb->min_lat_nsec = wbt_default_latency_nsec(q);
-
-	wbt_queue_depth_changed(&rwb->rqos);
-	wbt_set_write_cache(q, test_bit(QUEUE_FLAG_WC, &q->queue_flags));
-
 	return 0;
 }
-- 
2.31.1

[PATCH 5.10 3/3] blk-wbt: fix that 'rwb->wc' is always set to 1 in wbt_init()

[Yu Kuai]

From: Yu Kuai <yukuai3@huawei.com>

commit 285febabac4a16655372d23ff43e89ff6f216691 upstream.

commit 8c5035dfbb94 ("blk-wbt: call rq_qos_add() after wb_normal is
initialized") moves wbt_set_write_cache() before rq_qos_add(), which
is wrong because wbt_rq_qos() is still NULL.

Fix the problem by removing wbt_set_write_cache() and setting 'rwb->wc'
directly. Noted that this patch also remove the redundant setting of
'rab->wc'.

Fixes: 8c5035dfbb94 ("blk-wbt: call rq_qos_add() after wb_normal is initialized")
Reported-by: kernel test robot <yujie.liu@intel.com>
Link: https://lore.kernel.org/r/202210081045.77ddf59b-yujie.liu@intel.com
Signed-off-by: Yu Kuai <yukuai3@huawei.com>
Reviewed-by: Ming Lei <ming.lei@redhat.com>
Link: https://lore.kernel.org/r/20221009101038.1692875-1-yukuai1@huaweicloud.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
---
 block/blk-wbt.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/block/blk-wbt.c b/block/blk-wbt.c
index bafdb8098893..6f63920f073c 100644
--- a/block/blk-wbt.c
+++ b/block/blk-wbt.c
@@ -838,12 +838,11 @@ int wbt_init(struct request_queue *q)
 	rwb->last_comp = rwb->last_issue = jiffies;
 	rwb->win_nsec = RWB_WINDOW_NSEC;
 	rwb->enable_state = WBT_STATE_ON_DEFAULT;
-	rwb->wc = 1;
+	rwb->wc = test_bit(QUEUE_FLAG_WC, &q->queue_flags);
 	rwb->rq_depth.default_depth = RWB_DEF_DEPTH;
 	rwb->min_lat_nsec = wbt_default_latency_nsec(q);
 
 	wbt_queue_depth_changed(&rwb->rqos);
-	wbt_set_write_cache(q, test_bit(QUEUE_FLAG_WC, &q->queue_flags));
 
 	/*
 	 * Assign rwb and add the stats callback.
-- 
2.31.1

Re: [PATCH 5.10 2/3] blk-wbt: call rq_qos_add() after wb_normal is initialized

[Greg KH]

On Tue, Oct 18, 2022 at 09:43:25AM +0800, Yu Kuai wrote:
> From: Yu Kuai <yukuai3@huawei.com>
> 
> commit 8c5035dfbb9475b67c82b3fdb7351236525bf52b upstream.

I need a 5.15 version of this, and the 3/3 patch in order to be able to
apply the 5.10.y version.

Can you please send that, and then resend the remaining patches here for
5.10.y?

thanks,

greg k-h

Re: [PATCH 5.10 2/3] blk-wbt: call rq_qos_add() after wb_normal is initialized

[Yu Kuai]

Hi,

在 2022/10/27 0:47, Greg KH 写道:
> On Tue, Oct 18, 2022 at 09:43:25AM +0800, Yu Kuai wrote:
>> From: Yu Kuai <yukuai3@huawei.com>
>>
>> commit 8c5035dfbb9475b67c82b3fdb7351236525bf52b upstream.
> 
> I need a 5.15 version of this, and the 3/3 patch in order to be able to
> apply the 5.10.y version.
> 
> Can you please send that, and then resend the remaining patches here for
> 5.10.y?

Yes, I can do that. By the way, just to confirm:

I already saw that patch 2,3 is queued:

[PATCH 5.15 122/530] blk-wbt: call rq_qos_add() after wb_normal is 
initialized
[PATCH 5.15 519/530] blk-wbt: fix that rwb->wc is always set to 1 in 
wbt_init()

Do I still need to send a 5.15 version?

Thanks,
Kuai
> 
> thanks,
> 
> greg k-h
> .
> 

Re: [PATCH 5.10 2/3] blk-wbt: call rq_qos_add() after wb_normal is initialized

[Greg KH]

On Thu, Oct 27, 2022 at 07:28:26PM +0800, Yu Kuai wrote:
> Hi,
> 
> 在 2022/10/27 0:47, Greg KH 写道:
> > On Tue, Oct 18, 2022 at 09:43:25AM +0800, Yu Kuai wrote:
> > > From: Yu Kuai <yukuai3@huawei.com>
> > > 
> > > commit 8c5035dfbb9475b67c82b3fdb7351236525bf52b upstream.
> > 
> > I need a 5.15 version of this, and the 3/3 patch in order to be able to
> > apply the 5.10.y version.
> > 
> > Can you please send that, and then resend the remaining patches here for
> > 5.10.y?
> 
> Yes, I can do that. By the way, just to confirm:
> 
> I already saw that patch 2,3 is queued:
> 
> [PATCH 5.15 122/530] blk-wbt: call rq_qos_add() after wb_normal is
> initialized
> [PATCH 5.15 519/530] blk-wbt: fix that rwb->wc is always set to 1 in
> wbt_init()
> 
> Do I still need to send a 5.15 version?

Not if it is already in the tree, no.

thanks,

greg k-h