Re: [PATCH v4 02/15] crypto: ti - Fix spinlock inconsistency in DTHEv2

[T Pratham]

On 9/18/26 14:39, Herbert Xu wrote:
> On Thu, Sep 10, 2026 at 11:26:06PM +0530, T Pratham wrote:
>> Probe and remove functions use spin_(un)lock for acquiring the
>> dthe_dev_list.lock. But dthe_get_dev uses the bh variant. Change
>> spin_(un)lock_bh to spin_(un)lock to avoid potential deadlock when a
>> softIRQ process tries to acquire the already held lock.
>>
>> Fixes: 52f641bc63a46 ("crypto: ti - Add driver for DTHE V2 AES Engine (ECB, CBC)")
>> Signed-off-by: T Pratham <t-pratham@xxxxxx>
>> ---
>>  drivers/crypto/ti/dthev2-common.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/crypto/ti/dthev2-common.c b/drivers/crypto/ti/dthev2-common.c
>> index cc02449382673..4c6b72ba104ec 100644
>> --- a/drivers/crypto/ti/dthev2-common.c
>> +++ b/drivers/crypto/ti/dthev2-common.c
>> @@ -39,11 +39,11 @@ struct dthe_data *dthe_get_dev(struct dthe_tfm_ctx *ctx)
>>  	if (ctx->dev_data)
>>  		return ctx->dev_data;
>>  
>> -	spin_lock_bh(&dthe_dev_list.lock);
>> +	spin_lock(&dthe_dev_list.lock);
> 
> This makes no sense.  The only time you can use a plain spin lock
> is if all callers are from the same context, e.g., all with BH off
> or all with BH on.
> 
> Because this function is called from the Crypto API, which allows
> mixed BH context, you cannot safely use spin_lock.
> 
> In fact Sashiko reported this issue too:
> 
> https://sashiko.dev/#/patchset/20260910175619.2122149-1-t-pratham%40ti.com
> 
> Cheers,

Reading it carefully, looks like I messed up reading the Sashiko comment
the first time I read it on another patch. It makes much more sense now,
to not downgrade _bh to regular spinlock. Will fix and send.

-- 
Regards
T Pratham <t-pratham@xxxxxx>