Re: [PATCH v2] xhci: dbgtty: fix device unregister

[Jiri Slaby <jirislaby@kernel.org>]

On 24. 11. 25, 8:48, Mathias Nyman wrote:
> On 11/24/25 08:42, Jiri Slaby wrote:
>> Hmm, CCing TTY MAINTAINERS entry would not hurt.
>>
>> On 19. 11. 25, 22:29, Łukasz Bartosik wrote:
>>> From: Łukasz Bartosik <ukaszb@chromium.org>
>>>
>>> When DbC is disconnected then xhci_dbc_tty_unregister_device()
>>> is called. However if there is any user space process blocked
>>> on write to DbC terminal device then it will never be signalled
>>> and thus stay blocked indifinitely.
>>
>> indefinitely
>>
>>> This fix adds a tty_vhangup() call in xhci_dbc_tty_unregister_device().
>>> The tty_vhangup() wakes up any blocked writers and causes subsequent
>>> write attempts to DbC terminal device to fail.
>>>
>>> Cc: stable@vger.kernel.org
>>> Fixes: dfba2174dc42 ("usb: xhci: Add DbC support in xHCI driver")
>>> Signed-off-by: Łukasz Bartosik <ukaszb@chromium.org>
>>> ---
>>> Changes in v2:
>>> - Replaced tty_hangup() with tty_vhangup()
>>
>> Why exactly?
> 
> I recommended using tty_vhangup(), well actually tty_port_tty_vhangup() 
> to solve
> issue '2' you pointed out.
> To me it looks like tty_vhangup() is synchronous so it won't schedule 
> hangup work
> and should be safe to call right before we destroy the port.

Oops, right, my cscope DB was old and lead me to tty_hangup() instead 
(that schedules).

>> 2) you schedule a tty hangup work and destroy the port right after:
>>>       tty_unregister_device(dbc_tty_driver, port->minor);
>>>       xhci_dbc_tty_exit_port(port);
>>>       port->registered = false;
>> You should to elaborate how this is supposed to work?
> 
> Does tty_port_tty_vhangup() work here? it
> 1. checks if tty is NULL
> 2. is synchronous and should be safe to call before tty_unregister_device()

Yes, this works for me.

thanks,
-- 
js
suse labs