Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1500110 > unrolled thread

[patch] zfcp: spin_lock_irqsave() is not nestable

Back to article view | Back to linux.kernel

Contents

  [patch] zfcp: spin_lock_irqsave() is not nestable Dan Carpenter <dan.carpenter@oracle.com> - 2016-10-13 11:00 +0200
    Re: [patch] zfcp: spin_lock_irqsave() is not nestable Steffen Maier <maier@linux.vnet.ibm.com> - 2016-10-13 12:50 +0200
      Re: [patch] zfcp: spin_lock_irqsave() is not nestable Dan Carpenter <dan.carpenter@oracle.com> - 2016-10-13 13:30 +0200
      Re: [patch] zfcp: spin_lock_irqsave() is not nestable "Martin K. Petersen" <martin.petersen@oracle.com> - 2016-10-14 22:30 +0200
        Re: [patch] zfcp: spin_lock_irqsave() is not nestable Christian Borntraeger <borntraeger@de.ibm.com> - 2016-10-24 10:20 +0200
          Re: [patch] zfcp: spin_lock_irqsave() is not nestable Christian Borntraeger <borntraeger@de.ibm.com> - 2016-10-25 09:30 +0200

#1500110 — [patch] zfcp: spin_lock_irqsave() is not nestable

We accidentally overwrite the original saved value of "flags" so that
we can't re-enable IRQs at the end of the function.  Presumably this
function is mostly called with IRQs disabled or it would be obvious in
testing.

Fixes: aceeffbb59bb ("zfcp: trace full payload of all SAN records (req,resp,iels)")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>

diff --git a/drivers/s390/scsi/zfcp_dbf.c b/drivers/s390/scsi/zfcp_dbf.c
index 637cf89..5810019 100644
--- a/drivers/s390/scsi/zfcp_dbf.c
+++ b/drivers/s390/scsi/zfcp_dbf.c
@@ -384,7 +384,7 @@ void zfcp_dbf_san(char *tag, struct zfcp_dbf *dbf,
 	/* if (len > rec_len):
 	 * dump data up to cap_len ignoring small duplicate in rec->payload
 	 */
-	spin_lock_irqsave(&dbf->pay_lock, flags);
+	spin_lock(&dbf->pay_lock);
 	memset(payload, 0, sizeof(*payload));
 	memcpy(payload->area, paytag, ZFCP_DBF_TAG_LEN);
 	payload->fsf_req_id = req_id;

[toc] | [next] | [standalone]

#1500157

Dan, many thanks for catching this! Sparse did not notice, is there 
other tooling that would find such things?

James, Martin, could you please queue this as fix for one of my patches 
that went into the 4.9 merge window, so for 4.9-rc I guess?
https://lkml.kernel.org/r/20161013085358.GH16198@mwanda
or
https://lkml.org/lkml/2016/10/13/94

On 10/13/2016 10:53 AM, Dan Carpenter wrote:
> We accidentally overwrite the original saved value of "flags" so that
> we can't re-enable IRQs at the end of the function.  Presumably this
> function is mostly called with IRQs disabled or it would be obvious in
> testing.
>
> Fixes: aceeffbb59bb ("zfcp: trace full payload of all SAN records (req,resp,iels)")

Cc: <stable@vger.kernel.org> #2.6.38+

> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>

Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>

>
> diff --git a/drivers/s390/scsi/zfcp_dbf.c b/drivers/s390/scsi/zfcp_dbf.c
> index 637cf89..5810019 100644
> --- a/drivers/s390/scsi/zfcp_dbf.c
> +++ b/drivers/s390/scsi/zfcp_dbf.c
> @@ -384,7 +384,7 @@ void zfcp_dbf_san(char *tag, struct zfcp_dbf *dbf,
>  	/* if (len > rec_len):
>  	 * dump data up to cap_len ignoring small duplicate in rec->payload
>  	 */
> -	spin_lock_irqsave(&dbf->pay_lock, flags);
> +	spin_lock(&dbf->pay_lock);
>  	memset(payload, 0, sizeof(*payload));
>  	memcpy(payload->area, paytag, ZFCP_DBF_TAG_LEN);
>  	payload->fsf_req_id = req_id;
>

-- 
Mit freundlichen Grüßen / Kind regards
Steffen Maier

Linux on z Systems Development

IBM Deutschland Research & Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschaeftsfuehrung: Dirk Wittkopp
Sitz der Gesellschaft: Boeblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294

[toc] | [prev] | [next] | [standalone]

#1500186

On Thu, Oct 13, 2016 at 12:49:18PM +0200, Steffen Maier wrote:
> Dan, many thanks for catching this! Sparse did not notice, is there
> other tooling that would find such things?

This was a Smatch warning.

regards,
dan carpenter

[toc] | [prev] | [next] | [standalone]

#1501181

>>>>> "Steffen" == Steffen Maier <maier@linux.vnet.ibm.com> writes:

Steffen> could you please queue this as fix for one of my patches that
Steffen> went into the 4.9 merge window, so for 4.9-rc I guess?

Applied to 4.9/scsi-fixes.

-- 
Martin K. Petersen	Oracle Linux Engineering

[toc] | [prev] | [next] | [standalone]

#1506985

On 10/14/2016 10:21 PM, Martin K. Petersen wrote:
>>>>>> "Steffen" == Steffen Maier <maier@linux.vnet.ibm.com> writes:
> 
> Steffen> could you please queue this as fix for one of my patches that
> Steffen> went into the 4.9 merge window, so for 4.9-rc I guess?
> 
> Applied to 4.9/scsi-fixes.
> 

FWIW, I do see rcu stall errors with 4.9-rc1 from time to time, so I assume
that this fix is not only theoretical but fixes a real life issue.

[toc] | [prev] | [next] | [standalone]

#1508030

On 10/24/2016 10:18 AM, Christian Borntraeger wrote:
> On 10/14/2016 10:21 PM, Martin K. Petersen wrote:
>>>>>>> "Steffen" == Steffen Maier <maier@linux.vnet.ibm.com> writes:
>>
>> Steffen> could you please queue this as fix for one of my patches that
>> Steffen> went into the 4.9 merge window, so for 4.9-rc I guess?
>>
>> Applied to 4.9/scsi-fixes.
>>
> 
> FWIW, I do see rcu stall errors with 4.9-rc1 from time to time, so I assume
> that this fix is not only theoretical but fixes a real life issue.

Yes, with that patch the rcu stalls are gone, I assume its already on a branch
that does not rebase, otherwise feel free to add

Tested-by: Christian Borntraeger <borntraeger@de.ibm.com>

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web