Re: [PATCH -next] scsi: efct: Use GFP_ATOMIC under spin lock

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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;




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]

  Powered by Linux