On Sun, 23 Nov 2014, Jia-Ju Bai wrote: > Dear Sir, > I'm very sorry to trouble you. > Recently I test 15 linux device drivers in runtime and find some potential > bugs both in Linux 3.8.6 and Linux 3.17.2. > > The target file is drivers/usb/storage/usb.c, which is used to build > usb_storage.ko. I hope you can help me check my findings: > [1] In the normal process of usb_storage, INIT_DELAYED_WORK in > usb_stor_probe1 (in storage_probe) and cancel_delayed_work_sync in > quiesce_and_remove_host (in usb_stor_disconnect) is called in pairs.
No, that's wrong. INIT_DELAYED_WORK does nothing but initialize a data structure. queue_delayed_work and cancel_delayed_work_sync are called in pairs. > However, when INIT_DELAYED_WORK has been called and associate_dev is failed > in usb_stor_probe1, "BadDevice" segment is executed immediately to halt the > process, but cancel_delayed_work_sync is not called. > [2] The same situation with [1] will happen, when usb_alloc_coherent in > associate_dev in usb_stor_probe1 is failed. > [3] The same situation with [1] will happen, when kmalloc in associate_dev > in usb_stor_probe1 is failed. > [4] The same situation with [1] will happen, when get_device_info in > usb_stor_probe1 is failed. > [5] The same situation with [1] will happen, when get_pipes in > usb_stor_probe2 is failed. > [6] The same situation with [1] will happen, when usb_alloc_urb in > usb_stor_acquire_resources is failed. > [7] The same situation with [1] will happen, when scsi_add_host in > usb_stor_probe2 is failed. > > Could you help me check these findings? Thank you very much, and I'm looking > forward to your reply. queue_delayed_work is not called until after [2] - [7] have all succeeded. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
