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
WARNING: multiple messages have this Message-ID (diff)
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: Re: [PATCH 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)
In-Reply-To: <1554182797-12815-1-git-send-email-hpeter+linux_kernel@gmail.com>
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
next reply other threads:[~2019-04-02 12:37 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-02 12:37 Oliver Neukum [this message]
2019-04-02 12:37 ` [PATCH V4 1/3] USB: serial: f81232: clear overrun flag Oliver Neukum
-- strict thread matches above, loose matches on Subject: below --
2019-04-02 5:26 [V4,3/3] USB: serial: f81232: implement break control Ji-Ze Hong (Peter Hong)
2019-04-02 5:26 ` [PATCH V4 3/3] " Ji-Ze Hong (Peter Hong)
2019-04-02 5:26 [V4,2/3] USB: serial: f81232: add high baud rate support Ji-Ze Hong (Peter Hong)
2019-04-02 5:26 ` [PATCH V4 2/3] " Ji-Ze Hong (Peter Hong)
2019-04-02 5:26 [V4,1/3] USB: serial: f81232: clear overrun flag Ji-Ze Hong (Peter Hong)
2019-04-02 5:26 ` [PATCH V4 1/3] " 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 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.