On 2/22/21 9:50 PM, Oliver Neukum wrote:
Am Montag, den 22.02.2021, 21:02 +0800 schrieb Hui Wang:
On 2/22/21 8:51 PM, Oliver Neukum wrote:
Am Montag, den 22.02.2021, 20:40 +0800 schrieb Hui Wang:
On 2/22/21 3:59 PM, Oliver Neukum wrote:
OK, will find a UAS device to do the test.
Hi,
do you have a design at all?
No, so far what I could find is all driven by usb-storage, I tested a
couple of usb-sdcard-readers and usb-scsi/ata disk adapters, they all
belong to USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, USB_SC_SCSI,
USB_PR_BULK) instead of USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE,
USB_SC_SCSI, USB_PR_UAS). I plan to go to the office to find some usb
storage devices to test.
Hi,
please wait. First of all, you are making the assumption that all
resets originate from the SCSI layer. You cannot make that assumption.
Secondly, yes, ideally we should not pretend that a disconnect has
happened, when it hasn't happened, but what is your alternative.
What exactly do you want to test? You have not even defined the
desirable behavior and the problem you are seeing with the current
behavior.
I planed to forcibly (simulate) trigger calling
eh_device_reset_handler() from scsi layer and let pre_reset() or
post_reset() return a non-zero, and test if there is use-after-free
issue in the rest part of eh_device_reset_handler() and its callers. But
after thinking of your comment, looks like I was wrong. Thanks for your
instructions on this issue.
Thanks,
Hui.
Regards
Oliver
