[CHECKER] 32 Memory Leaks on Error Paths
Valdis.Kletnieks at vt.edu
Valdis.Kletnieks at vt.edu
Tue Sep 16 11:04:21 EDT 2003
On Tue, 16 Sep 2003 10:52:06 EDT, Timothy Miller said:
>
> >> 276: /* OK, it's not open. Create cache info for it */
> >>START -->
> >> 277: mtdblk = kmalloc(sizeof(struct mtdblk_dev), GFP_KERNEL);
> >> 278: if (!mtdblks)
> >>END -->
> >> 279: return -ENOMEM;
>
> >
> > Invalid. This is quite an obvious false positive, at least if your
> > algorithm checks for possible value ranges.
>
> Wait... one is "mtdblk", and the other is "mtdblks". One has an extra
> 's' on it. Unless there is some kind of aliasing going on, they would
> appear to be different variables. Naturally, I didn't check the
> original code, so I could be full of it. :)
On the other hand, even if the report was invalid (which another posting says isn't
the case), this code is just *begging* for somebody to "fix the typo", due to how
much the kernel uses
foo = function(..)
if (!foo)
Yeah, they're different variables - but we alloc mktblk and then return -ENOMEM
if the OTHER variable is null?? ;)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20030916/29181473/attachment.bin
More information about the linux-mtd
mailing list