linux-kernel - Re: [PATCH v3 2/3] softirq: Provide a handshake for canceling tasklets via polling

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250918134753.7122-1-hdanton@sina.com>
Date: Thu, 18 Sep 2025 21:47:52 +0800
From: Hillf Danton <hdanton@...a.com>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: linux-rt-devel@...ts.linux.dev,
	linux-kernel@...r.kernel.org,
	Takashi Iwai <tiwai@...e.de>,
	Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH v3 2/3] softirq: Provide a handshake for canceling tasklets via polling

On Mon, 15 Sep 2025 09:39:33 +0200 Sebastian Andrzej Siewior wrote:
>On 2025-09-05 18:15:01 [+0800], Hillf Danton wrote:
>> 	CPU0			CPU1
>> 	----			----
>> 	lock A
>> 				tasklet C callback
>> 				lock A
>> 	cancel tasklet B
>> 	DEADLOCK-01
>> 
>> After this work could DEADLOCK-01 be triggered, given no chance for DEADLOCK-02 ?
>> 
>> 	CPU2			CPU3
>> 	----			----
>> 	lock A
>> 				timer C callback
>> 				lock A
>> 	timer_delete_sync(timer B)
>> 	DEADLOCK-02
>
> You are not supposed to acquire the lock, that is also acquired in the
> callback, while canceling the timer/ tasklet.
> Tell me please, how is this relevant?
> 
> If lock A is acquired on CPU0/ 2 then tasklet/ timer on CPU1/ 3 can't
> make progress. Now CPU0/ 2 waits for the callback to complete. This
> deadlocks as of today regardless of PREEMPT_RT and this change.
> 
In case of !RT, the chance for DEADLOCK-02 is zero because deadlock is
detected based on per-timer instead of per-cpu.

> The difference is that !RT requires two CPU for this to happen while RT
> is efficient and can trigger this with just one CPU.

In case of RT OTOH, false positive deadlock could be triggered because
canceling taskletB has nothing to do with the callback of taskletC.

In short I am highlighting the gap between per-timer/tasklet and per-cpu.