On Wed, Aug 08, 2012 at 03:24:53PM -0300, Herton Ronaldo Krzesinski wrote:
> While looking at commit 3f9a5aa ("floppy: Cleanup disk->queue before
> caling put_disk() if add_disk() was never called") I noticed some
> problems with the error handling and cleanup:
>
> * missing cleanup (put_disk) if blk_init_queue fails, dr is decremented
> first in the error handling loop
> * if something fails in the add_disk loop, there is no cleanup of
> previous iterations in the error handling.
> * "if (disks[dr]->queue)" check is bogus, when reaching there for each
> dr should exist an queue allocated, and it doesn't take into account
> iterations where add_disk wasn't done, if failure happens in add_disk
> loop.
> * floppy_module_exit doesn't reset queue pointer if add_disk wasn't
> done.
Hey, these seem to be multiple cleanups. Can you break these down into
individual patches. Review becomes easy.
[..]
> + blk_cleanup_queue(disks[dr]->queue);
> + /*
> + * put_disk() may not be paired with add_disk() and
> + * will put queue reference one extra time. fix it.
> + */
> + if (dr > registered || !(allowed_drive_mask & (1 << dr)) ||
> + fdc_state[FDC(dr)].version == FDC_NONE)
> disks[dr]->queue = NULL;
I think checking for FDC_NONE and allowed_drive_mask() in multiple places
is becoming unreadable now. Can we just maintain a separate array to keep
track of disks on which we have called add_disk() and do the cleanup
accordingly.
static unsigned short disk_registered[N_DRIVE];
/* do add_disk */
disk_registered[drive] = 1;
out_put_disk:
while(dr--) {
if (disks[dr]->queue && !disk_registered[dr]) {
blk_cleanup_queue()
disks[dr]->queue = NULL;
}
}
Same disk_registered[] can be used for your other loop of remove drives.
Also it can be used in cleaning up code in floppy_module_exit().
I think this will make code much more readable. Right now this error
handling loop is just getting too complicated.
Thanks
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
