Re: [PATCH] usb: gadget: serial: fix Tx stall after buffer overflow

From: Sergey Organov <sorganov@gmail.com>
To: "Michał Mirosław" <mirq-linux@rere.qmqm.pl>
Cc: linux-usb@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Felipe Balbi <balbi@kernel.org>,
	linux-serial@vger.kernel.org
Subject: Re: [PATCH] usb: gadget: serial: fix Tx stall after buffer overflow
Date: Mon, 20 Jan 2020 09:06:18 +0300	[thread overview]
Message-ID: <87sgkak6g5.fsf@osv.gnss.ru> (raw)
In-Reply-To: <20200117203414.GA11783@qmqm.qmqm.pl> (=?utf-8?Q?=22Micha?= =?utf-8?Q?=C5=82_Miros=C5=82aw=22's?= message of "Fri, 17 Jan 2020 21:34:14 +0100")

Michał Mirosław <mirq-linux@rere.qmqm.pl> writes:

> On Fri, Jan 17, 2020 at 08:29:33AM +0300, Sergey Organov wrote:
> [...]
>> NOTE: current version of the driver leaks data from one connection to
>> another through its internal circular buffer. It might be a good idea
>> to clear the buffer on open/close/connect/disconnect, in which case
>> the problem this patch solves would have been fixed in a different
>> manner. However, not only that's a more dramatic change, but to do it
>> right TTY-layer buffers are to be considered as well.
>
> This is normal for serial devices, as they don't have any means to
> signal connection and will usually transmit anyway when not connected.
> In case of a console on the USB gadget-emulated serial port, it might
> actually be convenient that the data is kept until connection.

Yeah, just wanted to make sure I did select the right way of fixing the
issue.

>
>> --- a/drivers/usb/gadget/function/u_serial.c
>> +++ b/drivers/usb/gadget/function/u_serial.c
>> @@ -563,6 +563,8 @@ static int gs_start_io(struct gs_port *port)
>>  
>>         /* unblock any pending writes into our circular buffer */
>>         if (started) {
>> +               pr_debug("gs_start_tx: ttyGS%d\n", port->port_num);
>> +               gs_start_tx(port);
>>                 tty_wakeup(port->port.tty);
>
> The tty_wakeup() will be called from gs_start_tx(), so should be removed
> from here.

Not exactly. tty_wakeup() will be called from gs_start_tx() only when
there has been something actually transferred from the buffer. I didn't
want to change behavior when the buffer is empty, so I kept the explicit
tty_wakeup() call in place, intentionally. Please let me know if you
still think it should be removed.

> The pr_debug() in other callers of gs_start_tx() say:
> "caller: start ttyGS%d".

???

$ git co gregkh/tty-next && grep -r 'caller: start tty' .
HEAD is now at 7788f54... serial_core: Remove unused member in uart_port
$ 

-- Sergey