* [PATCH] mpx5200_uart: drop port lock across tty_flip_buffer() call
@ 2007-07-25 19:10 Thomas Gleixner
2007-07-25 19:42 ` Grant Likely
0 siblings, 1 reply; 6+ messages in thread
From: Thomas Gleixner @ 2007-07-25 19:10 UTC (permalink / raw)
To: linuxppc-embedded
The port lock needs to be dropped across the tty_flip_buffer call, as it
would lead to a deadlock with the spin_lock(&port->lock) in uart_start()
Uncovered by lockdep / preempt-rt
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Index: linux-2.6.22/drivers/serial/mpc52xx_uart.c
===================================================================
--- linux-2.6.22.orig/drivers/serial/mpc52xx_uart.c 2007-07-09 01:32:17.000000000 +0200
+++ linux-2.6.22/drivers/serial/mpc52xx_uart.c 2007-07-25 21:06:11.000000000 +0200
@@ -501,7 +501,9 @@ mpc52xx_uart_int_rx_chars(struct uart_po
}
}
+ spin_unlock(&port->lock);
tty_flip_buffer_push(tty);
+ spin_lock(&port->lock);
return in_be16(&PSC(port)->mpc52xx_psc_status) & MPC52xx_PSC_SR_RXRDY;
}
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] mpx5200_uart: drop port lock across tty_flip_buffer() call
2007-07-25 19:10 [PATCH] mpx5200_uart: drop port lock across tty_flip_buffer() call Thomas Gleixner
@ 2007-07-25 19:42 ` Grant Likely
2007-07-25 19:47 ` Thomas Gleixner
0 siblings, 1 reply; 6+ messages in thread
From: Grant Likely @ 2007-07-25 19:42 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: linuxppc-embedded
On 7/25/07, Thomas Gleixner <tglx@linutronix.de> wrote:
> The port lock needs to be dropped across the tty_flip_buffer call, as it
> would lead to a deadlock with the spin_lock(&port->lock) in uart_start()
>
> Uncovered by lockdep / preempt-rt
>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Instead of dropping the lock and reclaiming it, would it be better for
me to rework the driver to only grab the lock in the 'meat' of
mpc52xx_uart_int_rx_chars() and mpc52xx_uart_int_tx_chars()? (As
opposed to holding the lock for the entirety of mpc52xx_uart_int())
What convention is used in other drivers?
Cheers,
g.
>
>
> Index: linux-2.6.22/drivers/serial/mpc52xx_uart.c
> ===================================================================
> --- linux-2.6.22.orig/drivers/serial/mpc52xx_uart.c 2007-07-09 01:32:17.000000000 +0200
> +++ linux-2.6.22/drivers/serial/mpc52xx_uart.c 2007-07-25 21:06:11.000000000 +0200
> @@ -501,7 +501,9 @@ mpc52xx_uart_int_rx_chars(struct uart_po
> }
> }
>
> + spin_unlock(&port->lock);
> tty_flip_buffer_push(tty);
> + spin_lock(&port->lock);
>
> return in_be16(&PSC(port)->mpc52xx_psc_status) & MPC52xx_PSC_SR_RXRDY;
> }
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] mpx5200_uart: drop port lock across tty_flip_buffer() call
2007-07-25 19:42 ` Grant Likely
@ 2007-07-25 19:47 ` Thomas Gleixner
2007-07-25 19:54 ` Grant Likely
2007-07-26 9:25 ` Daniel Schnell
0 siblings, 2 replies; 6+ messages in thread
From: Thomas Gleixner @ 2007-07-25 19:47 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
On Wed, 2007-07-25 at 13:42 -0600, Grant Likely wrote:
> On 7/25/07, Thomas Gleixner <tglx@linutronix.de> wrote:
> > The port lock needs to be dropped across the tty_flip_buffer call, as it
> > would lead to a deadlock with the spin_lock(&port->lock) in uart_start()
> >
> > Uncovered by lockdep / preempt-rt
> >
> > Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
>
> Instead of dropping the lock and reclaiming it, would it be better for
> me to rework the driver to only grab the lock in the 'meat' of
> mpc52xx_uart_int_rx_chars() and mpc52xx_uart_int_tx_chars()? (As
> opposed to holding the lock for the entirety of mpc52xx_uart_int())
No, it's not worth the trouble. You need to protect the hardware access.
> What convention is used in other drivers?
The same.
tglx
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] mpx5200_uart: drop port lock across tty_flip_buffer() call
2007-07-25 19:47 ` Thomas Gleixner
@ 2007-07-25 19:54 ` Grant Likely
2007-07-26 9:25 ` Daniel Schnell
1 sibling, 0 replies; 6+ messages in thread
From: Grant Likely @ 2007-07-25 19:54 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: Paul Mackerras, linuxppc-embedded
On 7/25/07, Thomas Gleixner <tglx@linutronix.de> wrote:
> On Wed, 2007-07-25 at 13:42 -0600, Grant Likely wrote:
> > On 7/25/07, Thomas Gleixner <tglx@linutronix.de> wrote:
> > > The port lock needs to be dropped across the tty_flip_buffer call, as it
> > > would lead to a deadlock with the spin_lock(&port->lock) in uart_start()
> > >
> > > Uncovered by lockdep / preempt-rt
> > >
> > > Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> >
> > Instead of dropping the lock and reclaiming it, would it be better for
> > me to rework the driver to only grab the lock in the 'meat' of
> > mpc52xx_uart_int_rx_chars() and mpc52xx_uart_int_tx_chars()? (As
> > opposed to holding the lock for the entirety of mpc52xx_uart_int())
>
> No, it's not worth the trouble. You need to protect the hardware access.
>
> > What convention is used in other drivers?
>
> The same.
Okay, thanks.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Kumar, this is a bug fix, can you pick it up please?
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: [PATCH] mpx5200_uart: drop port lock across tty_flip_buffer() call
2007-07-25 19:47 ` Thomas Gleixner
2007-07-25 19:54 ` Grant Likely
@ 2007-07-26 9:25 ` Daniel Schnell
2007-07-26 9:41 ` Thomas Gleixner
1 sibling, 1 reply; 6+ messages in thread
From: Daniel Schnell @ 2007-07-26 9:25 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: linuxppc-embedded
Thomas Gleixner wrote:
> On Wed, 2007-07-25 at 13:42 -0600, Grant Likely wrote:
>> On 7/25/07, Thomas Gleixner <tglx@linutronix.de> wrote:
>>> The port lock needs to be dropped across the tty_flip_buffer call,
>>> as it would lead to a deadlock with the spin_lock(&port->lock) in
>>> uart_start()=20
>>>=20
>>> Uncovered by lockdep / preempt-rt
>>>=20
>>> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
While you are at it 8=B0> ... the mpc5200-fec driver has serious =
problems with preempt-rt, similar to what the IBM emac had ....
Best regards,
Daniel Schnell.
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: [PATCH] mpx5200_uart: drop port lock across tty_flip_buffer() call
2007-07-26 9:25 ` Daniel Schnell
@ 2007-07-26 9:41 ` Thomas Gleixner
0 siblings, 0 replies; 6+ messages in thread
From: Thomas Gleixner @ 2007-07-26 9:41 UTC (permalink / raw)
To: Daniel Schnell; +Cc: linuxppc-embedded
On Thu, 2007-07-26 at 09:25 +0000, Daniel Schnell wrote:
> Thomas Gleixner wrote:
>
> > On Wed, 2007-07-25 at 13:42 -0600, Grant Likely wrote:
> >> On 7/25/07, Thomas Gleixner <tglx@linutronix.de> wrote:
> >>> The port lock needs to be dropped across the tty_flip_buffer call,
> >>> as it would lead to a deadlock with the spin_lock(&port->lock) in
> >>> uart_start()
> >>>
> >>> Uncovered by lockdep / preempt-rt
> >>>
> >>> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
>
> While you are at it 8°> ... the mpc5200-fec driver has serious
> problems with preempt-rt, similar to what the IBM emac had ....
Care to whip up a patch ?
tglx
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2007-07-26 9:41 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-07-25 19:10 [PATCH] mpx5200_uart: drop port lock across tty_flip_buffer() call Thomas Gleixner
2007-07-25 19:42 ` Grant Likely
2007-07-25 19:47 ` Thomas Gleixner
2007-07-25 19:54 ` Grant Likely
2007-07-26 9:25 ` Daniel Schnell
2007-07-26 9:41 ` Thomas Gleixner
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).