From: Chengming Zhou <chengming.zhou@linux.dev>
To: Christoph Hellwig <hch@lst.de>
Cc: Friedrich Weber <f.weber@proxmox.com>,
axboe@kernel.dk, ming.lei@redhat.com, bvanassche@acm.org,
linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
zhouchengming@bytedance.com
Subject: Re: [PATCH v4 4/4] blk-flush: reuse rq queuelist in flush state machine
Date: Fri, 31 May 2024 16:16:37 +0800 [thread overview]
Message-ID: <e437a447-33ac-465e-ac9b-7b9a9005c24e@linux.dev> (raw)
In-Reply-To: <20240531061708.GB18075@lst.de>
On 2024/5/31 14:17, Christoph Hellwig wrote:
> On Wed, May 29, 2024 at 04:50:02PM +0800, Chengming Zhou wrote:
>> Yes, because we use list_move_tail() in the flush sequences. Maybe we can
>> just use list_add_tail() so we don't need the queuelist initialized. It
>> should be ok since rq can't be on any list when PREFLUSH or POSTFLUSH,
>> so there isn't any move actually.
>
> Sounds good.
Ok, I could send a fix that changes to use list_add_tail() later.
>
>> But now I'm concerned that rq->queuelist maybe changed by driver after
>> request end?
>
> How could the driver change it?
I don't know much about drivers. Normally, they will detach rq->queuelist
from their internal list and do blk_mq_end_request(), in which we reuse
this queuelist to add rq to the post-flush list.
Strictly speaking, that rq's ownership still belongs to the drivers until
they call blk_mq_free_request(), right? So I'm not sure if the drivers
would touch rq->queuelist after blk_mq_end_request(). If the drivers don't
have such behaviors, then we are good.
>
>>> Also, just out of interest: Can you estimate whether this issue is
>>> specific to software RAID setups, or could similar NULL pointer
>>> dereferences also happen in setups without software RAID?
>>
>> I think it can also happen without software RAID.
>
> Seems to be about batch allocation. So you either need a plug in
> the stacking device, or io_uring. I guess people aren't using the
> io_uring high performance options on devices with a write cache
> all that much, as that should immediately reproduce the problem.
>
next prev parent reply other threads:[~2024-05-31 8:17 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-17 4:00 [PATCH v4 0/4] blk-mq: optimize flush and request size chengming.zhou
2023-07-17 4:00 ` [PATCH v4 1/4] blk-mq: use percpu csd to remote complete instead of per-rq csd chengming.zhou
2023-07-17 4:00 ` [PATCH v4 2/4] blk-flush: fix rq->flush.seq for post-flush requests chengming.zhou
2023-07-17 4:00 ` [PATCH v4 3/4] blk-flush: count inflight flush_data requests chengming.zhou
2023-07-17 4:00 ` [PATCH v4 4/4] blk-flush: reuse rq queuelist in flush state machine chengming.zhou
2024-05-24 16:07 ` Friedrich Weber
2024-05-27 5:09 ` Chengming Zhou
2024-05-27 16:04 ` Friedrich Weber
2024-05-27 23:34 ` Chengming Zhou
2024-05-27 23:50 ` Chengming Zhou
2024-05-28 0:12 ` Chengming Zhou
2024-05-28 8:42 ` Friedrich Weber
2024-05-28 9:09 ` Chengming Zhou
2024-05-28 14:40 ` Friedrich Weber
2024-05-29 8:50 ` Chengming Zhou
2024-05-31 6:17 ` Christoph Hellwig
2024-05-31 8:16 ` Chengming Zhou [this message]
2023-07-17 14:18 ` [PATCH v4 0/4] blk-mq: optimize flush and request size Jens Axboe
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=e437a447-33ac-465e-ac9b-7b9a9005c24e@linux.dev \
--to=chengming.zhou@linux.dev \
--cc=axboe@kernel.dk \
--cc=bvanassche@acm.org \
--cc=f.weber@proxmox.com \
--cc=hch@lst.de \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ming.lei@redhat.com \
--cc=zhouchengming@bytedance.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