Linux block layer
 help / color / mirror / Atom feed
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
>

      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