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

Message-ID: <20211221142859.GA30187@lst.de>
Date:   Tue, 21 Dec 2021 15:28:59 +0100
From:   Christoph Hellwig <hch@....de>
To:     Yang Yingliang <yangyingliang@...wei.com>
Cc:     linux-kernel@...r.kernel.org, target-devel@...r.kernel.org,
        linux-scsi@...r.kernel.org, hch@....de, james.smart@...adcom.com,
        martin.petersen@...cle.com
Subject: Re: [PATCH -next] scsi: efct: Use GFP_ATOMIC under spin lock

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.