All of lore.kernel.org
 help / color / mirror / Atom feed
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> ("Michał Mirosław"'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

  reply	other threads:[~2020-01-20  6:06 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-17  5:29 [PATCH] usb: gadget: serial: fix Tx stall after buffer overflow Sergey Organov
2020-01-17 20:34 ` Michał Mirosław
2020-01-20  6:06   ` Sergey Organov [this message]
2020-01-20  9:45     ` Michał Mirosław
2020-01-20 13:38       ` Sergey Organov
2020-01-20 14:05         ` Michał Mirosław
2020-01-21  6:41           ` Sergey Organov
2020-01-21  4:42 ` [PATCH v2] " Sergey Organov
2020-01-21 16:39   ` Michał Mirosław
2020-01-29 11:21 ` [PATCH v3] " Sergey Organov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87sgkak6g5.fsf@osv.gnss.ru \
    --to=sorganov@gmail.com \
    --cc=balbi@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mirq-linux@rere.qmqm.pl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.