On 09/10/14 13:56, Greg KH wrote:
> On Thu, Oct 09, 2014 at 11:23:59AM +1100, Andre Wolokita wrote:
>> Issuing a modprobe -r g_serial command to the target
>> over the gadget serial communications line causes
>> modprobe to enter uninterruptable sleep, leaving the
>> system in an unstable state.
>>
>> The associated tty_port.count won't drop to 0 because
>> the command is issued over the very line being removed.
>>
>> Destroying the tty_port will ensure that resources are
>> freed and modprobe will not hang.
>>
>> Signed-off-by: Andre Wolokita <andre.wolok...@analog.com>
>> ---
>> drivers/usb/gadget/function/u_serial.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/usb/gadget/function/u_serial.c
>> b/drivers/usb/gadget/function/u_serial.c
>> index ad0aca8..db631c4 100644
>> --- a/drivers/usb/gadget/function/u_serial.c
>> +++ b/drivers/usb/gadget/function/u_serial.c
>> @@ -1074,10 +1074,10 @@ static int gs_closed(struct gs_port *port)
>> static void gserial_free_port(struct gs_port *port)
>> {
>> tasklet_kill(&port->push);
>> + tty_port_destroy(&port->port);
>> /* wait for old opens to finish */
>> wait_event(port->port.close_wait, gs_closed(port));
>
> Isn't this now a "use-after-free" issue?
>
Are you referring to the subsequent call to wait event() on gs_closed()?
Testing the use-case with this patch applied seemed to work without any
issues. The ttyGS0 reference in /dev/ is gone after running modprobe -r
but I'm just a newbie, so I could be doing sometime horrible here.
--
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
