linux-usb.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Oliver Neukum <oneukum@suse.com>
To: "Ji-Ze Hong \(Peter Hong\)" <hpeter@gmail.com>,
	peter_hong@fintek.com.tw, johan@kernel.org,
	gregkh@linuxfoundation.org
Cc: "Ji-Ze Hong \(Peter Hong\)" <hpeter+linux_kernel@gmail.com>,
	linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org
Subject: [V4,1/3] USB: serial: f81232: clear overrun flag
Date: Tue, 02 Apr 2019 14:37:54 +0200	[thread overview]
Message-ID: <1554208674.6310.33.camel@suse.com> (raw)

On Di, 2019-04-02 at 13:26 +0800,  Ji-Ze Hong (Peter Hong)  wrote:
> The F81232 will report data and LSR with bulk like following format:
> bulk-in data: [LSR(1Byte)+DATA(1Byte)][LSR(1Byte)+DATA(1Byte)]...
> 
> LSR will auto clear frame/parity/break error flag when reading by H/W,
> but overrrun will only cleared when reading LSR. So this patch add a
> worker to read LSR when overrun and flush the worker on close() &
> suspend().

Hi,

I really hate doing this to you, but you are exchanging one race
condition for another race. Exact explanation below.

> @@ -315,6 +319,7 @@ static void f81232_process_read_urb(struct urb *urb)
>  
>  			if (lsr & UART_LSR_OE) {
>  				port->icount.overrun++;
> +				schedule_work(&priv->lsr_work);

Again you schedule the work. It may run anytime.
The check you put into the work item needs to go here.
 
> +static void f81232_lsr_worker(struct work_struct *work)
> +{
> +	struct f81232_private *priv;
> +	struct usb_serial_port *port;
> +	struct usb_serial *serial;
> +	int status;
> +	u8 tmp;
> +
> +	priv = container_of(work, struct f81232_private, lsr_work);
> +	port = priv->port;
> +	serial = port->serial;
> +
> +	if (serial->suspending) {

There is no locking. f81232_resume() can run here.
This test
if (port_priv->lsr_work_resched) {
will evaluate to false

> +		priv->lsr_work_resched = true;
> +		return;
> +	}
> +
> +	status = f81232_get_register(port, LINE_STATUS_REGISTER, &tmp);
> +	if (status)
> +		dev_warn(&port->dev, "read LSR failed: %d\n", status);
> +}
> +
>  static int f81232_port_probe(struct usb_serial_port *port)
>  {
>  	struct f81232_private *priv;
> @@ -613,6 +643,7 @@ static int f81232_port_probe(struct usb_serial_port *port)
>  
>  	mutex_init(&priv->lock);
>  	INIT_WORK(&priv->interrupt_work,  f81232_interrupt_work);
> +	INIT_WORK(&priv->lsr_work, f81232_lsr_worker);
>  
>  	usb_set_serial_port_data(port, priv);
>  
> @@ -632,6 +663,30 @@ static int f81232_port_remove(struct usb_serial_port *port)
>  	return 0;
>  }
>  
> +static int f81232_suspend(struct usb_serial *serial, pm_message_t message)
> +{
> +	struct f81232_private *port_priv;
> +
> +	port_priv = usb_get_serial_port_data(serial->port[0]);
> +	flush_work(&port_priv->lsr_work);

Strictly speaking useless.

> +
> +	return 0;
> +}
> +
> +static int f81232_resume(struct usb_serial *serial)
> +{
> +	struct f81232_private *port_priv;
> +
> +	port_priv = usb_get_serial_port_data(serial->port[0]);
> +
> +	if (port_priv->lsr_work_resched) {
> +		port_priv->lsr_work_resched = false;

Strictly speaking even that is a race, as you have no guarantee that
your work queue is run before the system is suspended again. You
are in a task context. There is no reason to defer action.

> +		schedule_work(&port_priv->lsr_work);
> +	}
> +
> +	return usb_serial_generic_resume(serial);
> +}

	Regards
		Oliver

             reply	other threads:[~2019-04-02 12:37 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-02 12:37 Oliver Neukum [this message]
  -- strict thread matches above, loose matches on Subject: below --
2019-04-02  5:26 [V4,1/3] USB: serial: f81232: clear overrun flag Ji-Ze Hong (Peter Hong)

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=1554208674.6310.33.camel@suse.com \
    --to=oneukum@suse.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hpeter+linux_kernel@gmail.com \
    --cc=hpeter@gmail.com \
    --cc=johan@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=peter_hong@fintek.com.tw \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).