From: Minghao Chi <chi.minghao@zte.com.cn>

The might_sleep_if function in the mempool_alloc
may cause a sleep lock.We can't mempool_alloc()
with a spin lock held, so bring it up front.

Reported-by: Zeal Robot <zealci@zte.com.cn>
Signed-off-by: Minghao Chi <chi.minghao@zte.com.cn>
Signed-off-by: CGEL ZTE <cgel.zte@gmail.com>
---
 drivers/scsi/csiostor/csio_attr.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/csiostor/csio_attr.c b/drivers/scsi/csiostor/csio_attr.c
index 200e50089711..3d4ab439c756 100644
--- a/drivers/scsi/csiostor/csio_attr.c
+++ b/drivers/scsi/csiostor/csio_attr.c
@@ -424,8 +424,8 @@ csio_fcoe_alloc_vnp(struct csio_hw *hw, struct csio_lnode *ln)
 
 	/* Issue VNP cmd to alloc vport */
 	/* Allocate Mbox request */
-	spin_lock_irq(&hw->lock);
 	mbp = mempool_alloc(hw->mb_mempool, GFP_ATOMIC);
+	spin_lock_irq(&hw->lock);
 	if (!mbp) {
 		CSIO_INC_STATS(hw, n_err_nomem);
 		ret = -ENOMEM;
@@ -505,8 +505,8 @@ csio_fcoe_free_vnp(struct csio_hw *hw, struct csio_lnode *ln)
 	/* Issue VNP cmd to free vport */
 	/* Allocate Mbox request */
 
-	spin_lock_irq(&hw->lock);
 	mbp = mempool_alloc(hw->mb_mempool, GFP_ATOMIC);
+	spin_lock_irq(&hw->lock);
 	if (!mbp) {
 		CSIO_INC_STATS(hw, n_err_nomem);
 		ret = -ENOMEM;
-- 
2.25.1

On 1/19/22 14:59, cgel.zte@gmail.com wrote:
> From: Minghao Chi <chi.minghao@zte.com.cn>
> 
> The might_sleep_if function in the mempool_alloc
> may cause a sleep lock.We can't mempool_alloc()
> with a spin lock held, so bring it up front.

But the allocation is GFP_ATOMIC, which does not have
__GFP_DIRECT_RECLAIM, so how come mempool_alloc() triggers the
might_sleep() warning ?

> 
> Reported-by: Zeal Robot <zealci@zte.com.cn>
> Signed-off-by: Minghao Chi <chi.minghao@zte.com.cn>
> Signed-off-by: CGEL ZTE <cgel.zte@gmail.com>
> ---
>  drivers/scsi/csiostor/csio_attr.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/scsi/csiostor/csio_attr.c b/drivers/scsi/csiostor/csio_attr.c
> index 200e50089711..3d4ab439c756 100644
> --- a/drivers/scsi/csiostor/csio_attr.c
> +++ b/drivers/scsi/csiostor/csio_attr.c
> @@ -424,8 +424,8 @@ csio_fcoe_alloc_vnp(struct csio_hw *hw, struct csio_lnode *ln)
>  
>  	/* Issue VNP cmd to alloc vport */
>  	/* Allocate Mbox request */
> -	spin_lock_irq(&hw->lock);
>  	mbp = mempool_alloc(hw->mb_mempool, GFP_ATOMIC);
> +	spin_lock_irq(&hw->lock);
>  	if (!mbp) {
>  		CSIO_INC_STATS(hw, n_err_nomem);
>  		ret = -ENOMEM;
> @@ -505,8 +505,8 @@ csio_fcoe_free_vnp(struct csio_hw *hw, struct csio_lnode *ln)
>  	/* Issue VNP cmd to free vport */
>  	/* Allocate Mbox request */
>  
> -	spin_lock_irq(&hw->lock);
>  	mbp = mempool_alloc(hw->mb_mempool, GFP_ATOMIC);
> +	spin_lock_irq(&hw->lock);
>  	if (!mbp) {
>  		CSIO_INC_STATS(hw, n_err_nomem);
>  		ret = -ENOMEM;


-- 
Damien Le Moal
Western Digital Research

The might_sleep_if(gfp_mask & __GFP_DIRECT_RECLAIM) in the 
mempool_alloc function uses __GFP_DIRECT_RECLAIM.

On 1/19/22 17:57, cgel.zte@gmail.com wrote:
> 
> The might_sleep_if(gfp_mask & __GFP_DIRECT_RECLAIM) in the 
> mempool_alloc function uses __GFP_DIRECT_RECLAIM.

But the call to mempool_alloc() specifies GFP_ATOMIC, which does not
have __GFP_DIRECT_RECLAIM, so "gfp_mask & __GFP_DIRECT_RECLAIM" should
be false, and the might_sleep_if() not triggering. How can you see the
might sleep warning ?

-- 
Damien Le Moal
Western Digital Research

Sorry, GFP_ATOMIC&__GFP_DIRECT_RECLAIM are indeed false