Thread (16 messages) 16 messages, 4 authors, 2026-05-22

Re: [PATCH v2 2/3] md/raid1,raid10: fix error-path detection with md_cloned_bio()

From: Abd-Alrhman Masalkhi <hidden>
Date: 2026-05-22 11:02:24
Also in: lkml

On Fri, May 22, 2026 at 12:23 +0800, Yu Kuai wrote:
Hi,

在 2026/5/21 17:14, Abd-Alrhman Masalkhi 写道:
quoted
The original bio resubmitted via bio_list is not executing in the raid1d
thread context, so blocking on is_suspended() is correct and will not
cause a deadlock. The suspension deadlock risk only exists for
md_cloned_bio executing in the raid1d thread context in the error path.
And in this case it is always true that if we are executing in the
raid1d thread context the bio will already be a md_cloned_bio on entry
to md_handle_request(), even if current->bio_list was set, because (and as
@Xiao has mentioned) every time we split a bio in the error path we are
resubmitting the md_cloned_bio remainder, never the original bio.
I do understand this, if original bio or resubmitted bio only split at
raid1_read_request, there is no problem. What I feel is not safe is that
bio can split somewhere else.

This is possible for raid5, However, take a closer look at raid1/10, I
feel it's not possible for resubmitted io to split in bio_split_to_limits.
Even if it happens, it's probably someone else to blame.
Agreed. Since bio_split_to_limits() has been mentioned, I am wondering
whether a resubmitted md_cloned_bio could end up being split there for
raid456. I have not looked into the raid456 code yet; after finishing
raid1 and raid10, I will move on to the others.
I am considering skipping the redundant call to bio_split_to_limits()
when md_cloned_bio() is true. However, I am not sure whether this would
be safe for raid456.
-- 
Thansk,
Kuai
-- 
Best Regards,
Abd-Alrhman
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help