On Wed, Sep 03, 2014 at 01:45:32PM -0400, Alan Stern wrote: > On Wed, 3 Sep 2014, Peter Chen wrote: > > > > PS: I also have an old patch that adds a reset callback to > > > g-mass-storage. Peter asked for this around the same time the other > > > work was done. The idea was that disconnect must flush the buffers to > > > the backing storage device, whereas a reset could avoid flushing > > > anything -- Peter found that the flushing was taking so long, the > > > gadget might not be able to carry out a reset quickly enough if it used > > > the disconnect callback. > > > > > > The version I have of this patch is incomplete; it requires a reset > > > callback to be added to the composite driver. Peter, do you still want > > > to make this change to g-mass-storage? > > > > > > > Alan, this problem seems not to be existed at g_mass_storage, g_mass_storage > > has not .disconnect API and only fsg_disable will be called when bus reset > > occurs. > > That sounds like a bug. Shouldn't there be a disconnect callback? > Don't we want to flush the dirty buffers when a disconnect occurs? > Maybe the dirty buffers are expected to discard if it is a sudden disconnect. I tried at add debug message before fsg_lun_fsync_sub at f_mass_storage, below are some findings: Windows7: - click cancel button during the transfer: [ 766.500854] do_prevent_allow:1383 [ 766.569848] do_prevent_allow:1383 [ 766.587965] do_synchronize_cache:957 - sudden disconnect fsg_lun_fsync_sub is not called linux pc (Linux version 3.16.0-031600-generic) - click cancel button during the transfer: fsg_lun_fsync_sub is not called - sudden disconnect fsg_lun_fsync_sub is not called I think Linux should be improved for the behaviour when click cancel during the transfer. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
