There is something strange going on in drivers/scsi/dpt_i2o.c in both
2.4 and 2.5. adpt_i2o_reset_hba() function allocates 4 bytes
for "status" stuff, then tries to reset controller, then
if timeout on first reset stage is reached, frees "status" and returns,
otherwise it proceeds to monitor "status" (which is modified by hardware
now, btw), and if timeout is reached, just exits.
On the first thought I just thought it is trivial memleak that can be
fixed with patch below, but after some more thining I just thought
"what if after some time controller awakes and modifies status,
but it is already allocated for other purposes", scary eh?
So may be we shold not free those four bytes on timeout at all just
for safeness reasons?
Found with help of smatch + enhanced unfree script.
Bye,
Oleg
===== drivers/scsi/dpt_i2o.c 1.9 vs edited =====
--- 1.9/drivers/scsi/dpt_i2o.c Wed Jan 8 18:26:13 2003
+++ edited/drivers/scsi/dpt_i2o.c Thu Mar 13 21:17:10 2003
@@ -1336,6 +1336,7 @@
}
if(time_after(jiffies,timeout)){
printk(KERN_ERR "%s:Timeout waiting for IOP Reset.\n",pHba->name);
+ kfree(status);
return -ETIMEDOUT;
}
} while (m == EMPTY_QUEUE);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/