dpt_i2o.c memleak/incorrectness

[Oleg Drokin <green@linuxhacker.ru>]

Hello!

   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);