linux-kernel - Re: [PATCH -next] scsi: efct: Use GFP

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] [day] [month] [year] [list]

Message-ID: <20220110085441.GB6124@lst.de>
Date:   Mon, 10 Jan 2022 09:54:41 +0100
From:   Christoph Hellwig <hch@....de>
To:     Yang Yingliang <yangyingliang@...wei.com>
Cc:     Christoph Hellwig <hch@....de>, linux-kernel@...r.kernel.org,
        target-devel@...r.kernel.org, linux-scsi@...r.kernel.org,
        james.smart@...adcom.com, martin.petersen@...cle.com
Subject: Re: [PATCH -next] scsi: efct: Use GFP_ATOMIC under spin lock

On Thu, Dec 23, 2021 at 11:56:08AM +0800, Yang Yingliang wrote:
>
> On 2021/12/21 22:28, Christoph Hellwig wrote:
>> On Tue, Dec 21, 2021 at 07:37:06PM +0800, Yang Yingliang wrote:
>>> A spin lock is taken here so we should use GFP_ATOMIC.
>>>
>>> Fixes: efac162a4e4d ("scsi: efct: Don't pass GFP_DMA to dma_alloc_coherent()")
>> No, it does not fix that commit.  The driver did sleeping allocations
>> even before the commit.
>>
>> But wher is "here"?  Can we look into not holding that lock over an
>> allocation if it is preferable?  If not we should at least pass down
>> the gfp_flags so that only the caller(s) that can't sleep pass GFP_ATOMIC.
>
> According the comment of els_ios_lock, it's used to protect els ios list, I 
> think we
>
> can move down the spin lock like this:

This looks sensible to me.  Please submit it to the maintainer as a proper
patch.