Messages in this thread Patch in this message | | | Subject | Re: [PATCH -next] scsi: efct: Use GFP_ATOMIC under spin lock | From | Yang Yingliang <> | Date | Thu, 23 Dec 2021 11:56:08 +0800 |
| |
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;
| |