[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8f426702-4897-4177-aeae-4fe2b7155fae@arm.com>
Date: Tue, 16 Sep 2025 17:42:07 +0100
From: Suzuki K Poulose <suzuki.poulose@....com>
To: Leo Yan <leo.yan@....com>
Cc: Sean Anderson <sean.anderson@...ux.dev>, coresight@...ts.linaro.org,
linux-arm-kernel@...ts.infradead.org, Yeoreum Yun <yeoreum.yun@....com>,
Mike Leach <mike.leach@...aro.org>, Linu Cherian <lcherian@...vell.com>,
linux-kernel@...r.kernel.org,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
James Clark <james.clark@...aro.org>
Subject: Re: [PATCH v3] coresight: Fix possible deadlock in coresight_panic_cb
On 16/09/2025 17:38, Leo Yan wrote:
> On Tue, Sep 16, 2025 at 05:09:01PM +0100, Suzuki Kuruppassery Poulose wrote:
>
> [...]
>
>>> From ea78dd22cbdd97f709c5991d5bd3be97be6e137e Mon Sep 17 00:00:00 2001
>>> From: Sean Anderson <sean.anderson@...ux.dev>
>>> Date: Tue, 16 Sep 2025 16:03:58 +0100
>>> Subject: [PATCH] coresight: Fix possible deadlock in coresight_panic_cb()
>>>
>>> coresight_panic_cb() is called during a panic. It invokes
>>> bus_for_each_dev(), which then calls bus_to_subsys() and takes the
>>> 'bus_kset->list_lock'. If a panic occurs after the lock has been
>>> acquired, it can lead to a deadlock.
>>>
>>> Instead of using a common panic notifier to iterate the bus, this commit
>>> directly registers the TMC device's panic notifier. This avoids bus
>>> iteration and effectively eliminates the race condition that could cause
>>> the deadlock.
>>
>> Well, if you are going that far, why not register the notifier from
>> coresight-core ?
>
> I have thought this but gave up.
>
> When register a panic's notifier, it does not provide an argument for
> passing a private data. So the code below uses container_of() to convert
> notifier block pointer to the TMC driver data, as a result, the code is
> specific to TMC driver.
notifier_block in csdev ?
Powered by blists - more mailing lists