Re: [PATCH] drivers/scsi/ipr.c: reorder error handling code to includeiounmap

From: Wayne Boyer
Date: Thu Jun 09 2011 - 11:52:16 EST


On 05/31/2011 07:16 AM, Julia Lawall wrote:
> From: Julia Lawall <julia@xxxxxxx>
>
> The out_msi_disable label should be before cleanup_nomem to additionally
> benefit from the call to iounmap.

Yes, this is a problem. I propose the following patch instead.

---

In the case where ipr_test_msi returns an error that is not -EOPNOTSUPP, the
execution jumps to the out_msi_disable label. This misses the call to iounmap
for ipr_regs which was initialized earlier.

The fix is to do the call to pci_disable_msi when the error case is detected
and then goto the cleanup_nomem label if the error is not -EOPNOTSUPP.

Signed-off-by: Wayne Boyer <wayneb@xxxxxxxxxxxxxxxxxx>
---

drivers/scsi/ipr.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)

Index: b/drivers/scsi/ipr.c
===================================================================
--- a/drivers/scsi/ipr.c 2011-06-09 08:14:44.927740117 -0700
+++ b/drivers/scsi/ipr.c 2011-06-09 08:50:10.105630466 -0700
@@ -8763,11 +8763,11 @@ static int __devinit ipr_probe_ioa(struc
/* Enable MSI style interrupts if they are supported. */
if (ioa_cfg->ipr_chip->intr_type == IPR_USE_MSI && !pci_enable_msi(pdev)) {
rc = ipr_test_msi(ioa_cfg, pdev);
- if (rc == -EOPNOTSUPP)
+ if (rc) {
pci_disable_msi(pdev);
- else if (rc)
- goto out_msi_disable;
- else
+ if (rc != -EOPNOTSUPP)
+ goto cleanup_nomem;
+ } else
dev_info(&pdev->dev, "MSI enabled with IRQ: %d\n", pdev->irq);
} else if (ipr_debug)
dev_info(&pdev->dev, "Cannot enable MSI.\n");
@@ -8847,8 +8847,6 @@ cleanup_nolog:
ipr_free_mem(ioa_cfg);
cleanup_nomem:
iounmap(ipr_regs);
-out_msi_disable:
- pci_disable_msi(pdev);
out_release_regions:
pci_release_regions(pdev);
out_scsi_host_put:


--
Wayne Boyer
IBM - Beaverton, Oregon
LTC S/W Development
(503) 578-5236, T/L 775-5236
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/