[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <44ff658e-4a00-ee5b-1f84-fa89f9b9291f@huawei.com>
Date: Thu, 23 Dec 2021 11:56:08 +0800
From: Yang Yingliang <yangyingliang@...wei.com>
To: Christoph Hellwig <hch@....de>
CC: <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 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:
--- a/drivers/scsi/elx/libefc/efc_els.c
+++ b/drivers/scsi/elx/libefc/efc_els.c
@@ -46,8 +46,6 @@ efc_els_io_alloc_size(struct efc_node *node, u32
reqlen, u32 rsplen)
efc = node->efc;
- spin_lock_irqsave(&node->els_ios_lock, flags);
-
if (!node->els_io_enabled) {
efc_log_err(efc, "els io alloc disabled\n");
spin_unlock_irqrestore(&node->els_ios_lock, flags);
@@ -88,6 +86,8 @@ efc_els_io_alloc_size(struct efc_node *node, u32
reqlen, u32 rsplen)
els = NULL;
}
+ spin_lock_irqsave(&node->els_ios_lock, flags);
+
if (els) {
/* initialize fields */
els->els_retries_remaining = EFC_FC_ELS_DEFAULT_RETRIES;
Powered by blists - more mailing lists