Hi Dan, On Thu, Jul 19, 2012 at 6:20 PM, Dan Carpenter <[email protected]> wrote: > Cleanup means there are no behavior changes. This is a bug fix. > Thanks Dan, i will put a proper subject line in commit. > On Thu, Jul 19, 2012 at 06:00:01PM +0530, Devendra Naga wrote: >> a) if alloc_hdlcdev fails, we are going into the free_regions, >> and returning out the err (which is 0 by the prev call), >> return -ENOMEM if this function fail. >> >> b) setup_device also can fail, as it calls around the register_hdlc_dev >> which >> is again a macro of the register_netdev. >> >> take the error from the setup_device and return it out in error >> condition >> >> c) request_irq when fails, we are freeing requested mem regions and >> disabling >> the pci device(?) and returning err which is agian 0 here. >> >> take the error from request_irq and err path will take care of >> returning it. >> >> as if we return 0 , at the init function, t3e3_init_card, we have a success >> case >> and if there are two channels we call this function again, having the result >> of >> it completely unknown. >> >> This result in having the probe return 0, unloading the driver may (not) >> cause >> ambigous result. > > These bugs were there before your patch, but we should also be doing > an unregister_hdlc_device() and a free_netdev(). > t3e3_remove_channel is called when channel init of channel2 fails, and i think this cause the double call to pci_release_region and pci_disable_device,
so i think its better to follow your approach and remove the call to t3e3_remove_channel and clean all the things we allocated at the init path itself, rather cleaning them up when call and a subsequent call to the t3e3_init_channel fails? > regards, > dan carpenter > Thanks, Devendra -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
