linux-serial.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 1/1] Xilinx uartlite serial driver: Add lock in isr to avoid SMP race condition
@ 2014-09-17  0:18 Kris Modrak
  2014-09-17 11:29 ` Peter Hurley
  0 siblings, 1 reply; 2+ messages in thread
From: Kris Modrak @ 2014-09-17  0:18 UTC (permalink / raw)
  To: Peter Korsgaard, Greg Kroah-Hartman, Jiri Slaby; +Cc: linux-serial, Kris Modrak

Trasmitted characters could be lost or written twice due to a missing lock
in the critical section of the isr. The missing lock causes a race condition
on SMP systems between ulite_transmit when called from the isr and
ulite_start_tx as they can execute simultaneously on separate cores. The call
from ulite_start_tx is made from serial_core.c with the lock taken.

Signed-off-by: Kris Modrak <krismodrak@hotmail.com>
---
 drivers/tty/serial/uartlite.c |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/drivers/tty/serial/uartlite.c b/drivers/tty/serial/uartlite.c
index 9fc22f4..ee151a2 100644
--- a/drivers/tty/serial/uartlite.c
+++ b/drivers/tty/serial/uartlite.c
@@ -196,9 +196,13 @@ static irqreturn_t ulite_isr(int irq, void *dev_id)
 	int busy, n = 0;
 
 	do {
-		int stat = uart_in32(ULITE_STATUS, port);
+		int stat;
+
+		spin_lock(&port->lock);
+		stat = uart_in32(ULITE_STATUS, port);
 		busy  = ulite_receive(port, stat);
 		busy |= ulite_transmit(port, stat);
+		spin_unlock(&port->lock);
 		n++;
 	} while (busy);
 
-- 
1.7.5.4


^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [PATCH 1/1] Xilinx uartlite serial driver: Add lock in isr to avoid SMP race condition
  2014-09-17  0:18 [PATCH 1/1] Xilinx uartlite serial driver: Add lock in isr to avoid SMP race condition Kris Modrak
@ 2014-09-17 11:29 ` Peter Hurley
  0 siblings, 0 replies; 2+ messages in thread
From: Peter Hurley @ 2014-09-17 11:29 UTC (permalink / raw)
  To: Kris Modrak, Peter Korsgaard, Greg Kroah-Hartman, Jiri Slaby; +Cc: linux-serial

Hi Kris,

On 09/16/2014 08:18 PM, Kris Modrak wrote:
> Trasmitted characters could be lost or written twice due to a missing lock
> in the critical section of the isr. The missing lock causes a race condition
> on SMP systems between ulite_transmit when called from the isr and
> ulite_start_tx as they can execute simultaneously on separate cores. The call
> from ulite_start_tx is made from serial_core.c with the lock taken.
> 
> Signed-off-by: Kris Modrak <krismodrak@hotmail.com>
> ---
>  drivers/tty/serial/uartlite.c |    6 +++++-
>  1 files changed, 5 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/tty/serial/uartlite.c b/drivers/tty/serial/uartlite.c
> index 9fc22f4..ee151a2 100644
> --- a/drivers/tty/serial/uartlite.c
> +++ b/drivers/tty/serial/uartlite.c
> @@ -196,9 +196,13 @@ static irqreturn_t ulite_isr(int irq, void *dev_id)
>  	int busy, n = 0;
>  
>  	do {
> -		int stat = uart_in32(ULITE_STATUS, port);
> +		int stat;
> +
> +		spin_lock(&port->lock);
> +		stat = uart_in32(ULITE_STATUS, port);
>  		busy  = ulite_receive(port, stat);
>  		busy |= ulite_transmit(port, stat);
> +		spin_unlock(&port->lock);
>  		n++;
>  	} while (busy);

Might as well take the spinlock for the entire loop.
A nice upgrade here would be to limit the loop to a fixed number of
iterations as well (in a separate patch).

Regards,
Peter Hurley

PS - That ISR has some odd logic; if data was only transmitted but not
     received, it still submits input work even though there is no work
     to perform (ie., tty_flip_buffer_push() should only be called if
     ulite_receive() returned non-zero).


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2014-09-17 11:29 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-09-17  0:18 [PATCH 1/1] Xilinx uartlite serial driver: Add lock in isr to avoid SMP race condition Kris Modrak
2014-09-17 11:29 ` Peter Hurley

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).