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 <[email protected]>
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;
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: <[email protected]> #2.6.38+
> Signed-off-by: Dan Carpenter <[email protected]>
Signed-off-by: Steffen Maier <[email protected]>
>
> 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
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
>>>>> "Steffen" == Steffen Maier <[email protected]> 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
On 10/14/2016 10:21 PM, Martin K. Petersen wrote:
>>>>>> "Steffen" == Steffen Maier <[email protected]> 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.
On 10/24/2016 10:18 AM, Christian Borntraeger wrote:
> On 10/14/2016 10:21 PM, Martin K. Petersen wrote:
>>>>>>> "Steffen" == Steffen Maier <[email protected]> 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 <[email protected]>