From: Andy Whitcroft There's a spot in i2o where we deliberately leak some memory when the hardware plays up. The alternative is to let the hardware scribble on it at some unknown time in the future. Things like the Stanford checker keep alleging that this is a bug. So shut them up with a comment drivers/message/i2o/i2o_core.c | 8 +++++++- 1 files changed, 7 insertions(+), 1 deletion(-) diff -puN drivers/message/i2o/i2o_core.c~i2o-leak-comment drivers/message/i2o/i2o_core.c --- 25/drivers/message/i2o/i2o_core.c~i2o-leak-comment 2003-05-25 22:57:54.000000000 -0700 +++ 25-akpm/drivers/message/i2o/i2o_core.c 2003-05-25 22:57:54.000000000 -0700 @@ -1690,7 +1690,9 @@ static int i2o_reset_controller(struct i if((jiffies-time)>=20*HZ) { printk(KERN_ERR "IOP reset timeout.\n"); - // Better to leak this for safety: - status; + /* The controller still may respond and overwrite + * status_phys, LEAK it to prevent memory corruption. + */ return -ETIMEDOUT; } schedule(); @@ -1719,6 +1721,10 @@ static int i2o_reset_controller(struct i { printk(KERN_ERR "%s: Timeout waiting for IOP reset.\n", c->name); + /* The controller still may respond and + * overwrite status_phys, LEAK it to prevent + * memory corruption. + */ return -ETIMEDOUT; } schedule(); _