Re: Would the father of init_mem_lth please stand up

Eric Lammerts
2001-12-08T11:47:37Z

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