linux-kernel - Re: [PATCH] dmaengine: plx_dma: Fix potential deadlock on &plxdev->ring

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: <46ceea13-c8ba-8d67-604e-b761feabc50c@sw-optimization.com>
Date:   Thu, 27 Jul 2023 11:45:42 +0200
From:   Eric Schwarz <eas@...optimization.com>
To:     Chengfeng Ye <dg573847474@...il.com>
Cc:     Christophe JAILLET <christophe.jaillet@...adoo.fr>,
        vkoul@...nel.org, Yunbo Yu <yuyunbo519@...il.com>,
        dmaengine@...r.kernel.org, linux-kernel@...r.kernel.org,
        Logan Gunthorpe <logang@...tatee.com>
Subject: Re: [PATCH] dmaengine: plx_dma: Fix potential deadlock on
 &plxdev->ring_lock

Hello,

Am 27.07.2023 um 08:48 schrieb Chengfeng Ye:
> Hi Logan and Christophe,
> 
> Thanks much for the reply and reminder, and yes, spin_lock_bh() should
> be better.
> 
> When I wrote the patch I thought the spin_lock_bh() cannot be nested,
> and afraid that if some outside callers called .dma_tx_status() callback
> with softirq already disable, then spin_unlock_bh() would unintentionally
> re-enable softirq(). spin_lock_irqsave() is always safer in general thus I
> used it.
> 
> But I just check the document [1] about these API and found that _bh()
> can be nested. Then use spin_lock_bh() should be better due to
> performance concern.
> 
> 
>> So perhaps we should just revert 1d05a0bdb420?
> Then for this one I think revert 1d05a0bdb420 should be enough. May I
> ask to revert that patch, should I do anything further? (like sending
> a new patch).
> 
>> as explained in another reply [1], would spin_lock_bh() be enough in
>> such a case?
> For the another one [2], I would send a v2 patch to change to spin_lock_bh()
> 
> [1] http://books.gigatux.nl/mirror/kerneldevelopment/0672327201/ch07lev1sec6.html
> [2] https://lore.kernel.org/all/5125e39b-0faf-63fc-0c51-982b2a567e21@wanadoo.fr/

For uniformity reason across drivers and also that not something else 
gets missed please compare your requirements and solution to the 
implementation of the "altera-msgdma" driver (altera-msgdma.c).

W/ special emphasis on commit edf10919e5fc ("dmaengine: altera: fix 
spinlock usage")

spin_lock_bh was changed to spin_lock_irqsave w/ this patch.

Cheers
Eric