From: "Jackie Liu" <liu.yun@linux.dev>
To: "Damien Le Moal" <dlemoal@kernel.org>, axboe@kernel.dk
Cc: linux-block@vger.kernel.org
Subject: Re: [PATCH] block: clear zone write plugging flag before failing rejected BIOs
Date: Tue, 09 Jun 2026 00:36:39 +0000 [thread overview]
Message-ID: <d99eb11c43be22184bd044a16c5968f93b082d3e@linux.dev> (raw)
In-Reply-To: <33035623-1f1b-4391-9212-e2af5fd9457f@kernel.org>
2026年6月8日 19:42, "Damien Le Moal" <dlemoal@kernel.org mailto:dlemoal@kernel.org?to=%22Damien%20Le%20Moal%22%20%3Cdlemoal%40kernel.org%3E > 写到:
>
> On 2026/06/07 11:18, Jackie Liu wrote:
>
> >
> > From: Jackie Liu <liuyun01@kylinos.cn>
> >
> > Commit fe0418eb9bd6 ("block: Prevent potential deadlocks in zone write plug
> > error recovery") changed blk_zone_wplug_handle_write() to fail BIOs
> > directly when blk_zone_wplug_prepare_bio() rejects them, for example
> > because the write is not aligned to the cached write pointer or the plug
> > needs a write pointer update. However, the BIO is already marked with
> > BIO_ZONE_WRITE_PLUGGING at that point even though it is not issued.
> >
> > Completing such a BIO with bio_io_error() makes bio_endio() call
> > blk_zone_write_plug_bio_endio(), which treats the completion as a failed
> > device write and may poison the cached zone write pointer state by setting
> > BLK_ZONE_WPLUG_NEED_WP_UPDATE.
> >
> Yes, true. But you did not explain clearly why that is a problem. After all, if
> we hit this case, the user issued an unaligned BIO, and so forcing it to do a
> report zones to get everything in sync and the correct write pointer is not a
> bad thing.
>
> If fe0418eb9bd6 change is actually causing you problems, please describe that
> problem clearly. But ideally, I do not want to special case some error
> completions over others and prefer to have a single error path that result in
> the same state for the zone write plugs, regardless of a write error root cause.
Thanks for the review. I agree that the changelog did not describe a
concrete user-visible problem clearly enough.
I was treating NEED_WP_UPDATE on a BIO rejected before submission as stale
state poisoning, because no device write was actually issued. But as you
pointed out, for an invalid/non-sequential write, forcing the user to
resynchronize the write pointer through report zones is consistent with the
current conservative recovery model.
I do not have a concrete regression from fe0418eb9bd6 beyond that extra
recovery requirement, so please drop this patch for now.
Thanks.
Jackie
>
> >
> > Clear BIO_ZONE_WRITE_PLUGGING and drop the zone write plug reference before
> > failing the rejected BIO.
> >
> > Fixes: fe0418eb9bd6 ("block: Prevent potential deadlocks in zone write plug error recovery")
> > Cc: stable@vger.kernel.org # 6.13+
> > Signed-off-by: Jackie Liu <liuyun01@kylinos.cn>
> > ---
> > block/blk-zoned.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/block/blk-zoned.c b/block/blk-zoned.c
> > index 6a221c180889..855767d8bfc1 100644
> > --- a/block/blk-zoned.c
> > +++ b/block/blk-zoned.c
> > @@ -1502,7 +1502,9 @@ static bool blk_zone_wplug_handle_write(struct bio *bio, unsigned int nr_segs)
> > goto queue_bio;
> >
> > if (!blk_zone_wplug_prepare_bio(zwplug, bio)) {
> > + bio_clear_flag(bio, BIO_ZONE_WRITE_PLUGGING);
> > spin_unlock_irqrestore(&zwplug->lock, flags);
> > + disk_put_zone_wplug(zwplug);
> > bio_io_error(bio);
> > return true;
> > }
> >
> --
> Damien Le Moal
> Western Digital Research
>
prev parent reply other threads:[~2026-06-09 0:36 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-07 3:18 [PATCH] block: clear zone write plugging flag before failing rejected BIOs Jackie Liu
2026-06-08 11:42 ` Damien Le Moal
2026-06-09 0:36 ` Jackie Liu [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=d99eb11c43be22184bd044a16c5968f93b082d3e@linux.dev \
--to=liu.yun@linux.dev \
--cc=axboe@kernel.dk \
--cc=dlemoal@kernel.org \
--cc=linux-block@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox