* Re: [PATCH v2] blk-wbt: remove WARN_ON_ONCE from wbt_init_enable_default()
2026-03-16 7:03 [PATCH v2] blk-wbt: remove WARN_ON_ONCE from wbt_init_enable_default() Yuto Ohnuki
@ 2026-03-16 9:32 ` Nilay Shroff
2026-03-23 4:30 ` Yu Kuai
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: Nilay Shroff @ 2026-03-16 9:32 UTC (permalink / raw)
To: Yuto Ohnuki, Jens Axboe
Cc: Yu Kuai, Ming Lei, linux-block, linux-kernel,
syzbot+71fcf20f7c1e5043d78c
On 3/16/26 12:33 PM, Yuto Ohnuki wrote:
> wbt_init_enable_default() uses WARN_ON_ONCE to check for failures from
> wbt_alloc() and wbt_init(). However, both are expected failure paths:
>
> - wbt_alloc() can return NULL under memory pressure (-ENOMEM)
> - wbt_init() can fail with -EBUSY if wbt is already registered
>
> syzbot triggers this by injecting memory allocation failures during MTD
> partition creation via ioctl(BLKPG), causing a spurious warning.
>
> wbt_init_enable_default() is a best-effort initialization called from
> blk_register_queue() with a void return type. Failure simply means the
> disk operates without writeback throttling, which is harmless.
>
> Replace WARN_ON_ONCE with plain if-checks, consistent with how
> wbt_set_lat() in the same file already handles these failures. Add a
> pr_warn() for the wbt_init() failure to retain diagnostic information
> without triggering a full stack trace.
>
> Reported-by:syzbot+71fcf20f7c1e5043d78c@syzkaller.appspotmail.com
> Closes:https://syzkaller.appspot.com/bug?extid=71fcf20f7c1e5043d78c
> Fixes: 41afaeeda509 ("blk-wbt: fix possible deadlock to nest pcpu_alloc_mutex under q_usage_counter")
> Signed-off-by: Yuto Ohnuki<ytohnuki@amazon.com>
Looks good to me:
Reviewed-by: Nilay Shroff <nilay@linux.ibm.com>
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [PATCH v2] blk-wbt: remove WARN_ON_ONCE from wbt_init_enable_default()
2026-03-16 7:03 [PATCH v2] blk-wbt: remove WARN_ON_ONCE from wbt_init_enable_default() Yuto Ohnuki
2026-03-16 9:32 ` Nilay Shroff
@ 2026-03-23 4:30 ` Yu Kuai
2026-04-04 14:56 ` Yuto Ohnuki
2026-04-06 19:03 ` Jens Axboe
3 siblings, 0 replies; 5+ messages in thread
From: Yu Kuai @ 2026-03-23 4:30 UTC (permalink / raw)
To: Yuto Ohnuki, Jens Axboe, yukuai
Cc: Nilay Shroff, Ming Lei, linux-block, linux-kernel,
syzbot+71fcf20f7c1e5043d78c
在 2026/3/16 15:03, Yuto Ohnuki 写道:
> wbt_init_enable_default() uses WARN_ON_ONCE to check for failures from
> wbt_alloc() and wbt_init(). However, both are expected failure paths:
>
> - wbt_alloc() can return NULL under memory pressure (-ENOMEM)
> - wbt_init() can fail with -EBUSY if wbt is already registered
>
> syzbot triggers this by injecting memory allocation failures during MTD
> partition creation via ioctl(BLKPG), causing a spurious warning.
>
> wbt_init_enable_default() is a best-effort initialization called from
> blk_register_queue() with a void return type. Failure simply means the
> disk operates without writeback throttling, which is harmless.
>
> Replace WARN_ON_ONCE with plain if-checks, consistent with how
> wbt_set_lat() in the same file already handles these failures. Add a
> pr_warn() for the wbt_init() failure to retain diagnostic information
> without triggering a full stack trace.
>
> Reported-by:syzbot+71fcf20f7c1e5043d78c@syzkaller.appspotmail.com
> Closes:https://syzkaller.appspot.com/bug?extid=71fcf20f7c1e5043d78c
> Fixes: 41afaeeda509 ("blk-wbt: fix possible deadlock to nest pcpu_alloc_mutex under q_usage_counter")
> Signed-off-by: Yuto Ohnuki<ytohnuki@amazon.com>
> ---
> Changes in v2:
> - Add pr_warn() for wbt_init() failure as suggested by Yu Kuai
> - Link to v1:https://lore.kernel.org/all/20260315143137.13547-2-ytohnuki@amazon.com/
> ---
> block/blk-wbt.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
Reviewed-by: Yu Kuai <yukuai@fnnas.com>
--
Thansk,
Kuai
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [PATCH v2] blk-wbt: remove WARN_ON_ONCE from wbt_init_enable_default()
2026-03-16 7:03 [PATCH v2] blk-wbt: remove WARN_ON_ONCE from wbt_init_enable_default() Yuto Ohnuki
2026-03-16 9:32 ` Nilay Shroff
2026-03-23 4:30 ` Yu Kuai
@ 2026-04-04 14:56 ` Yuto Ohnuki
2026-04-06 19:03 ` Jens Axboe
3 siblings, 0 replies; 5+ messages in thread
From: Yuto Ohnuki @ 2026-04-04 14:56 UTC (permalink / raw)
To: Jens Axboe
Cc: Yu Kuai, Nilay Shroff, Ming Lei, linux-block, linux-kernel,
syzbot+71fcf20f7c1e5043d78c
On Mon, Mar 16, 2026 at 07:03:59AM +0000, Yuto Ohnuki wrote:
> wbt_init_enable_default() uses WARN_ON_ONCE to check for failures from
> wbt_alloc() and wbt_init(). However, both are expected failure paths:
>
> - wbt_alloc() can return NULL under memory pressure (-ENOMEM)
> - wbt_init() can fail with -EBUSY if wbt is already registered
>
> syzbot triggers this by injecting memory allocation failures during MTD
> partition creation via ioctl(BLKPG), causing a spurious warning.
>
> wbt_init_enable_default() is a best-effort initialization called from
> blk_register_queue() with a void return type. Failure simply means the
> disk operates without writeback throttling, which is harmless.
>
> Replace WARN_ON_ONCE with plain if-checks, consistent with how
> wbt_set_lat() in the same file already handles these failures. Add a
> pr_warn() for the wbt_init() failure to retain diagnostic information
> without triggering a full stack trace.
>
> Reported-by: syzbot+71fcf20f7c1e5043d78c@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=71fcf20f7c1e5043d78c
> Fixes: 41afaeeda509 ("blk-wbt: fix possible deadlock to nest pcpu_alloc_mutex under q_usage_counter")
> Signed-off-by: Yuto Ohnuki <ytohnuki@amazon.com>
> ---
> Changes in v2:
> - Add pr_warn() for wbt_init() failure as suggested by Yu Kuai
> - Link to v1: https://lore.kernel.org/all/20260315143137.13547-2-ytohnuki@amazon.com/
> ---
> block/blk-wbt.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/block/blk-wbt.c b/block/blk-wbt.c
> index 33006edfccd4..dcc2438ca16d 100644
> --- a/block/blk-wbt.c
> +++ b/block/blk-wbt.c
> @@ -782,10 +782,11 @@ void wbt_init_enable_default(struct gendisk *disk)
> return;
>
> rwb = wbt_alloc();
> - if (WARN_ON_ONCE(!rwb))
> + if (!rwb)
> return;
>
> - if (WARN_ON_ONCE(wbt_init(disk, rwb))) {
> + if (wbt_init(disk, rwb)) {
> + pr_warn("%s: failed to enable wbt\n", disk->disk_name);
> wbt_free(rwb);
> return;
> }
> --
> 2.50.1
>
>
>
>
> Amazon Web Services EMEA SARL, 38 avenue John F. Kennedy, L-1855 Luxembourg, R.C.S. Luxembourg B186284
>
> Amazon Web Services EMEA SARL, Irish Branch, One Burlington Plaza, Burlington Road, Dublin 4, Ireland, branch registration number 908705
>
>
>
Gentle ping on this patch.
It has a Reviewed-by from Nilay Shroff and Yu Kuai.
Please let me know if there is anything else needed for this
to be applied.
Thank you in advance,
Yuto
Amazon Web Services EMEA SARL, 38 avenue John F. Kennedy, L-1855 Luxembourg, R.C.S. Luxembourg B186284
Amazon Web Services EMEA SARL, Irish Branch, One Burlington Plaza, Burlington Road, Dublin 4, Ireland, branch registration number 908705
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [PATCH v2] blk-wbt: remove WARN_ON_ONCE from wbt_init_enable_default()
2026-03-16 7:03 [PATCH v2] blk-wbt: remove WARN_ON_ONCE from wbt_init_enable_default() Yuto Ohnuki
` (2 preceding siblings ...)
2026-04-04 14:56 ` Yuto Ohnuki
@ 2026-04-06 19:03 ` Jens Axboe
3 siblings, 0 replies; 5+ messages in thread
From: Jens Axboe @ 2026-04-06 19:03 UTC (permalink / raw)
To: Yuto Ohnuki
Cc: Yu Kuai, Nilay Shroff, Ming Lei, linux-block, linux-kernel,
syzbot+71fcf20f7c1e5043d78c
On Mon, 16 Mar 2026 07:03:59 +0000, Yuto Ohnuki wrote:
> wbt_init_enable_default() uses WARN_ON_ONCE to check for failures from
> wbt_alloc() and wbt_init(). However, both are expected failure paths:
>
> - wbt_alloc() can return NULL under memory pressure (-ENOMEM)
> - wbt_init() can fail with -EBUSY if wbt is already registered
>
> syzbot triggers this by injecting memory allocation failures during MTD
> partition creation via ioctl(BLKPG), causing a spurious warning.
>
> [...]
Applied, thanks!
[1/1] blk-wbt: remove WARN_ON_ONCE from wbt_init_enable_default()
commit: e9b004ff83067cdf96774b45aea4b239ace99a2f
Best regards,
--
Jens Axboe
^ permalink raw reply [flat|nested] 5+ messages in thread