Re: Would the father of init_mem_lth please stand up

[Eric Lammerts]

On Fri, 7 Dec 2001, Pete Zaitcev wrote:
> drivers/scsi/sd.c:sd_init()
>
>         /* allocate memory */
> #define init_mem_lth(x,n)       x = kmalloc((n) * sizeof(*x), GFP_ATOMIC)
> #define zero_mem_lth(x,n)       memset(x, 0, (n) * sizeof(*x))
>
>         init_mem_lth(rscsi_disks, sd_template.dev_max);
>         init_mem_lth(sd_sizes, maxparts);
>         init_mem_lth(sd_blocksizes, maxparts);
>         init_mem_lth(sd, maxparts);
>         init_mem_lth(sd_gendisks, N_USED_SD_MAJORS);
>         init_mem_lth(sd_max_sectors, sd_template.dev_max << 4);
>
>         if (!rscsi_disks || !sd_sizes || !sd_blocksizes || !sd || !sd_gendisks)
>                 goto cleanup_mem;
> #undef init_mem_lth
> #undef zero_mem_lth
> .....................
> cleanup_mem:
>         kfree(sd_gendisks);
>         kfree(sd);
>         kfree(sd_blocksizes);
>         kfree(sd_sizes);
>         kfree(rscsi_disks);
>
>
> However, it's not only about the puking and keyboard cleanups.
> The code is buggy as well. Scenario:
>
>  0. User inserts a large number of FC-AL adapters with 56 disks each
>  1. modprobe sd_mod
>     No SCSI hosts, sd_init() is NOT called.
>  2. modprobe qla_something
>     sd_init is called and fails on sd_gendisks. modprobe fails.
>     sd_sizes, sd_blocksizes, etc. are LEFT DANGLING
>  3. modprobe qla_something
>     sd_init is called and fails on sd_sizes.
>     kfree is called with a bunch of dangling pointers

I agree it's ugly, but why would kfree be called on dangling pointers?
All those pointers are initialized again on every sd_init() call. And
there are no "goto cleanup_mem"s between the kmallocs.

Eric