Re: [PATCH v3] hid-sony: Prevent crash when rumble effects are still loaded at USB disconnect

[Manuel Reimer <mail+linux-input@m-reimer.de>]

On 06/11/2016 09:15 PM, Cameron Gutman wrote:
> Sorry, I misremembered what I thought I read in your email - you said you didn't see a call to ml_ff_destroy()
> in the disconnect case.

I also don't see this call with the xpad driver!

> Though that is quite strange to me, as the comments on ff_device indicate that it should be the right spot:
>
> 483  * @destroy: called by input core when parent input device is being
> 484  *      destroyed

What does "input device is being destroyed" actually mean in this case?

I tried with the xpad driver and as long as fftest is running (it will 
keep running until it detects that the device has been disconnected) 
there is no ml_ff_destroy event. So, if I want, there can be hours 
between actual USB disconnect and ml_ff_destroy.

So what does it mean to the kernel that fftest is keeping an open file 
handle to this input device? Is it really gone if there is at least one 
process still holding a reference to it?


And. It actually seems possible to trigger the bug with the xpad driver. 
I didn't have the crash, but there is a good chance to get it. This is 
what I managed to get:

[  267.006873] ml_effect_timer start
[  267.256399] ml_effect_timer end
[  268.286814] xpad 1-2:1.0: xpad_try_sending_next_out_packet - 
usb_submit_urb failed with result -19
[  268.331112] xpad 1-2:1.0: xpad_try_sending_next_out_packet - 
usb_submit_urb failed with result -19
[  268.384689] xpad 1-2:1.0: xpad_try_sending_next_out_packet - 
usb_submit_urb failed with result -19
[  268.452146] xpad 1-2:1.0: xpad_try_sending_next_out_packet - 
usb_submit_urb failed with result -19
[  273.813537] ml_effect_timer start
[  273.816845] usb ȵ�<: xpad_try_sending_next_out_packet - 
usb_submit_urb failed with result -19
[  274.400668] ml_effect_timer end


Starting with 268.286814 the USB device is gone! That's why the xpad 
driver is throwing errors.

Some time later at 273.813537 (USB device is gone!) there is a new call 
to the timer callback. "Unfortunately" no crash.

> I want to be sure we're on the right track though. Can you please resolve the address in the RIP register to a
> line number in hid-sony.c?

Can you point me to some instructions on how to do this? The only way to 
debug things, I currently know, is the "good old print(f/k)" debugging...

Manuel
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html