public inbox for linux-block@vger.kernel.org
 help / color / mirror / Atom feed
From: alan.adamson@oracle.com
To: Shinichiro Kawasaki <shinichiro.kawasaki@wdc.com>,
	Jens Axboe <axboe@kernel.dk>
Cc: "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>
Subject: Re: [PATCH] block: cleanup and fix batch completion adding conditions
Date: Wed, 19 Feb 2025 17:04:18 -0800	[thread overview]
Message-ID: <b31cff79-cb81-4792-b700-b55a83637aad@oracle.com> (raw)
In-Reply-To: <92239c7c-e7e8-494c-9bf9-59a855d70952@oracle.com>


On 2/19/25 11:17 AM, alan.adamson@oracle.com wrote:
>
> On 2/18/25 11:26 PM, Shinichiro Kawasaki wrote:
>> CC+: Alan,
>>
>> On Feb 13, 2025 / 08:18, Jens Axboe wrote:
>>> The conditions for whether or not a request is allowed adding to a
>>> completion batch are a bit hard to read, and they also have a few
>>> issues. One is that ioerror may indeed be a random value on 
>>> passthrough,
>>> and it's being checked unconditionally of whether or not the given
>>> request is a passthrough request or not.
>>>
>>> Rewrite the conditions to be separate for easier reading, and only 
>>> check
>>> ioerror for non-passthrough requests. This fixes an issue with bio
>>> unmapping on passthrough, where it fails getting added to a batch. This
>>> both leads to suboptimal performance, and may trigger a potential
>>> schedule-under-atomic condition for polled passthrough IO.
>>>
>>> Fixes: f794f3351f26 ("block: add support for 
>>> blk_mq_end_request_batch()")
>>> Signed-off-by: Jens Axboe <axboe@kernel.dk>
>> I observed the blktests test case nvme/039 failure with v6.14-rc3 
>> kernel. I
>> bisected and found that this patch in the v6.14-rc3 is the trigger.
>>
>> The test run output is as follows:
>>
>> nvme/039 => nvme0n1 (test error logging) [failed]
>>      runtime  5.378s  ...  5.354s
>>      --- tests/nvme/039.out      2024-09-20 11:20:26.405380875 +0900
>>      +++ 
>> /home/shin/Blktests/blktests/results/nvme0n1/nvme/039.out.bad 
>> 2025-02-19 16:13:05.061387179 +0900
>>      @@ -1,7 +1,3 @@
>>       Running nvme/039
>>      - Read(0x2) @ LBA 0, 1 blocks, Unrecovered Read Error (sct 0x2 / 
>> sc 0x81) DNR
>>      - Read(0x2) @ LBA 0, 1 blocks, Unknown (sct 0x3 / sc 0x75) DNR
>>      - Write(0x1) @ LBA 0, 1 blocks, Write Fault (sct 0x2 / sc 0x80) DNR
>>        Identify(0x6), Access Denied (sct 0x2 / sc 0x86) DNR cdw10=0x1 
>> cdw11=0x0 cdw12=0x0 cdw13=0x0 cdw14=0x0 cdw15=0x0
>>      - Read(0x2), Invalid Command Opcode (sct 0x0 / sc 0x1) DNR 
>> cdw10=0x0 cdw11=0x0 cdw12=0x1 cdw13=0x0 cdw14=0x0 cdw15=0x0
>>       Test complete
>>
>>
>> The test case does error injection. Test method requires 
>> reconsideration to
>> adjust to this kernel change, probably. Help for fix will be 
>> appreciated.
>
> Not really an issue with the test, rather the error injector is 
> broken. I'll investigate.

The following change allows the test to pass.

- The check of (ioerror < 0) should be (ioerror != 0)

- passthroughs can also have ioerror set, so false needs to be returned. 
This needs to be resolved.


diff --git a/include/linux/blk-mq.h b/include/linux/blk-mq.h
index fa2a76cc2f73..b2bd2ac40441 100644
--- a/include/linux/blk-mq.h
+++ b/include/linux/blk-mq.h
@@ -865,17 +865,17 @@ static inline bool blk_mq_add_to_batch(struct 
request *req,
          * 1) No batch container
          * 2) Has scheduler data attached
          * 3) Not a passthrough request and end_io set
-        * 4) Not a passthrough request and an ioerror
+        * 4) An ioerror
          */
         if (!iob)
                 return false;
         if (req->rq_flags & RQF_SCHED_TAGS)
                 return false;
+       if (ioerror)
+               return false;
         if (!blk_rq_is_passthrough(req)) {
                 if (req->end_io)
                         return false;
-               if (ioerror < 0)
-                       return false;
         }

Alan



  reply	other threads:[~2025-02-20  1:04 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-13 15:18 [PATCH] block: cleanup and fix batch completion adding conditions Jens Axboe
2025-02-19  7:26 ` Shinichiro Kawasaki
2025-02-19 19:17   ` alan.adamson
2025-02-20  1:04     ` alan.adamson [this message]
2025-02-20  7:28       ` Shinichiro Kawasaki
2025-02-28 11:59 ` Ondrej Kozina
2025-02-28 14:08   ` Jens Axboe
2025-02-28 14:32     ` Ondrej Kozina
2025-03-04  9:25       ` Milan Broz
2025-03-11  3:03         ` Shinichiro Kawasaki
2025-03-11 14:59           ` Milan Broz
2025-03-11 15:00             ` Jens Axboe
2025-03-19 18:54               ` Milan Broz
2025-03-12 11:17           ` Ondrej Kozina

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=b31cff79-cb81-4792-b700-b55a83637aad@oracle.com \
    --to=alan.adamson@oracle.com \
    --cc=axboe@kernel.dk \
    --cc=linux-block@vger.kernel.org \
    --cc=shinichiro.kawasaki@wdc.com \
    /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