linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH -next v2] scsi: efct: don't use GFP_KERNEL under spin lock
@ 2022-01-11  1:24 Yang Yingliang
  2022-01-12 19:28 ` James Smart
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: Yang Yingliang @ 2022-01-11  1:24 UTC (permalink / raw)
  To: linux-kernel, target-devel, linux-scsi; +Cc: hch, james.smart, martin.petersen

GFP_KERNEL/GFP_DMA can't be used under a spin lock, according the
comment of els_ios_lock, it's used to protect els ios list, so we
can move down the spin lock to avoid using this flag under the lock.

Reported-by: Hulk Robot <hulkci@huawei.com>
Fixes: 8f406ef72859 ("scsi: elx: libefc: Extended link Service I/O handling")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
---
v2:
  move up unlock to just protect list_add_tail()
---
 drivers/scsi/elx/libefc/efc_els.c | 8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/scsi/elx/libefc/efc_els.c b/drivers/scsi/elx/libefc/efc_els.c
index 7bb4f9aad2c8..84bc81d7ce76 100644
--- a/drivers/scsi/elx/libefc/efc_els.c
+++ b/drivers/scsi/elx/libefc/efc_els.c
@@ -46,18 +46,14 @@ 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);
 		return NULL;
 	}
 
 	els = mempool_alloc(efc->els_io_pool, GFP_ATOMIC);
 	if (!els) {
 		atomic_add_return(1, &efc->els_io_alloc_failed_count);
-		spin_unlock_irqrestore(&node->els_ios_lock, flags);
 		return NULL;
 	}
 
@@ -74,7 +70,6 @@ efc_els_io_alloc_size(struct efc_node *node, u32 reqlen, u32 rsplen)
 					      &els->io.req.phys, GFP_KERNEL);
 	if (!els->io.req.virt) {
 		mempool_free(els, efc->els_io_pool);
-		spin_unlock_irqrestore(&node->els_ios_lock, flags);
 		return NULL;
 	}
 
@@ -94,10 +89,11 @@ efc_els_io_alloc_size(struct efc_node *node, u32 reqlen, u32 rsplen)
 
 		/* add els structure to ELS IO list */
 		INIT_LIST_HEAD(&els->list_entry);
+		spin_lock_irqsave(&node->els_ios_lock, flags);
 		list_add_tail(&els->list_entry, &node->els_ios_list);
+		spin_unlock_irqrestore(&node->els_ios_lock, flags);
 	}
 
-	spin_unlock_irqrestore(&node->els_ios_lock, flags);
 	return els;
 }
 
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH -next v2] scsi: efct: don't use GFP_KERNEL under spin lock
  2022-01-11  1:24 [PATCH -next v2] scsi: efct: don't use GFP_KERNEL under spin lock Yang Yingliang
@ 2022-01-12 19:28 ` James Smart
  2022-01-19  3:26 ` Martin K. Petersen
  2022-01-25  5:40 ` Martin K. Petersen
  2 siblings, 0 replies; 4+ messages in thread
From: James Smart @ 2022-01-12 19:28 UTC (permalink / raw)
  To: Yang Yingliang, linux-kernel, target-devel, linux-scsi
  Cc: hch, james.smart, martin.petersen

On 1/10/2022 5:24 PM, Yang Yingliang wrote:
> GFP_KERNEL/GFP_DMA can't be used under a spin lock, according the
> comment of els_ios_lock, it's used to protect els ios list, so we
> can move down the spin lock to avoid using this flag under the lock.
> 
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Fixes: 8f406ef72859 ("scsi: elx: libefc: Extended link Service I/O handling")
> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
> ---
> v2:
>    move up unlock to just protect list_add_tail()
> ---
>   drivers/scsi/elx/libefc/efc_els.c | 8 ++------
>   1 file changed, 2 insertions(+), 6 deletions(-)
> 

Looks fine.

Reviewed-by: James Smart <jsmart2021@gmail.com>

-- james

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH -next v2] scsi: efct: don't use GFP_KERNEL under spin lock
  2022-01-11  1:24 [PATCH -next v2] scsi: efct: don't use GFP_KERNEL under spin lock Yang Yingliang
  2022-01-12 19:28 ` James Smart
@ 2022-01-19  3:26 ` Martin K. Petersen
  2022-01-25  5:40 ` Martin K. Petersen
  2 siblings, 0 replies; 4+ messages in thread
From: Martin K. Petersen @ 2022-01-19  3:26 UTC (permalink / raw)
  To: Yang Yingliang
  Cc: linux-kernel, target-devel, linux-scsi, hch, james.smart,
	martin.petersen


Yang,

> GFP_KERNEL/GFP_DMA can't be used under a spin lock, according the
> comment of els_ios_lock, it's used to protect els ios list, so we
> can move down the spin lock to avoid using this flag under the lock.

Applied to 5.17/scsi-staging, thanks!

-- 
Martin K. Petersen	Oracle Linux Engineering

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH -next v2] scsi: efct: don't use GFP_KERNEL under spin lock
  2022-01-11  1:24 [PATCH -next v2] scsi: efct: don't use GFP_KERNEL under spin lock Yang Yingliang
  2022-01-12 19:28 ` James Smart
  2022-01-19  3:26 ` Martin K. Petersen
@ 2022-01-25  5:40 ` Martin K. Petersen
  2 siblings, 0 replies; 4+ messages in thread
From: Martin K. Petersen @ 2022-01-25  5:40 UTC (permalink / raw)
  To: linux-kernel, linux-scsi, Yang Yingliang, target-devel
  Cc: Martin K . Petersen, hch, james.smart

On Tue, 11 Jan 2022 09:24:41 +0800, Yang Yingliang wrote:

> GFP_KERNEL/GFP_DMA can't be used under a spin lock, according the
> comment of els_ios_lock, it's used to protect els ios list, so we
> can move down the spin lock to avoid using this flag under the lock.
> 
> 

Applied to 5.17/scsi-fixes, thanks!

[1/1] scsi: efct: don't use GFP_KERNEL under spin lock
      https://git.kernel.org/mkp/scsi/c/61263b3a11a2

-- 
Martin K. Petersen	Oracle Linux Engineering

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2022-01-25  5:44 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-11  1:24 [PATCH -next v2] scsi: efct: don't use GFP_KERNEL under spin lock Yang Yingliang
2022-01-12 19:28 ` James Smart
2022-01-19  3:26 ` Martin K. Petersen
2022-01-25  5:40 ` Martin K. Petersen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).