Re: [PATCH 1/1] dm-delay: fix hung task introduced by kthread mode

From: Joel Colledge <joel.colledge@linbit.com>
To: Christian Loehle <christian.loehle@arm.com>
Cc: Mikulas Patocka <mpatocka@redhat.com>,
	Alasdair Kergon <agk@redhat.com>,
	 Mike Snitzer <snitzer@kernel.org>,
	dm-devel@lists.linux.dev
Subject: Re: [PATCH 1/1] dm-delay: fix hung task introduced by kthread mode
Date: Tue, 30 Apr 2024 16:44:25 +0200	[thread overview]
Message-ID: <CAGNP_+Uocb_8YtY9P3EuMQ8sQwWaQtqEMszqbGZrVyrKw-udRg@mail.gmail.com> (raw)
In-Reply-To: <71a31fdb-fad6-4ce9-bda0-2f86633d23a3@arm.com>

On Tue, 30 Apr 2024 at 16:28, Christian Loehle <christian.loehle@arm.com> wrote:
> Is this an issue for delay > 0 too somehow?

I believe it is. If there is simply no IO to the delay device, then
nothing will wake the new thread and the same issue will occur.

I haven't yet reproduced this case, because the system I am testing on
submits reads on any new block device and I don't know offhand how to
disable them. I think the reads are from scans for multipathd,
bcachefs or similar.

> Indeed if we don't have a delay the process will never be woken up,
> but in that case, why create the worker in the first place?

I agree. If this were only an issue with delay == 0, it would make
more sense not to create the worker at all.

As mentioned above, I believe the issue can occur with delay > 0. So
not creating the worker in the delay == 0 case is an additional
optimization and out of the scope of this change.

> You're missing lkml as recipient btw.

Thanks for the pointer and thanks for your response!

Best regards,
Joel