On 19.02.2016 17:23, Anand Moon wrote: > Hi Krzysztof, > > On 19 February 2016 at 13:14, Krzysztof Kozlowski > <[email protected]> wrote: >> On 19.02.2016 15:51, Anand Moon wrote: >>> Hi Krzysztof, >>> >>> On 19 February 2016 at 11:39, Krzysztof Kozlowski >>> <[email protected]> wrote: >>>> 2016-02-19 4:14 GMT+09:00 Anand Moon <[email protected]>: >>>>> Hi Peter, >>>>> >>>>> On 18 February 2016 at 23:18, Peter Hurley <[email protected]> >>>>> wrote: >>>>>> Hi Anand, >>>>>> >>>>>> On 02/18/2016 09:40 AM, Anand Moon wrote: >>>>>>> From: Anand Moon <[email protected]> >>>>>>> >>>>>>> changes fix the correct order of the spin_lock_irqrestore/save. >>>>>>> >>>>>>> Signed-off-by: Anand Moon <[email protected]> >>>>>>> --- >>>>>>> drivers/tty/serial/samsung.c | 4 ++-- >>>>>>> 1 file changed, 2 insertions(+), 2 deletions(-) >>>>>>> >>>>>>> diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c >>>>>>> index d72cd73..96fe14d 100644 >>>>>>> --- a/drivers/tty/serial/samsung.c >>>>>>> +++ b/drivers/tty/serial/samsung.c >>>>>>> @@ -759,9 +759,9 @@ static irqreturn_t s3c24xx_serial_tx_chars(int irq, >>>>>>> void *id) >>>>>>> } >>>>>>> >>>>>>> if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS) { >>>>>>> - spin_unlock(&port->lock); >>>>>>> + spin_unlock_irqrestore(&port->lock, flags); >>>>>>> uart_write_wakeup(port); >>>>>>> - spin_lock(&port->lock); >>>>>>> + spin_lock_irqsave(&port->lock, flags); >>>>>> >>>>>> This driver shouldn't be dropping the spin lock at for write wakeup. >>>>>> If this is causing lock-ups in a line discipline, the line discipline >>>>>> needs fixed. >>>>>> >>>>> >>>>> Thanks for pointing out. >>>>> Their is no lock up, just the inconstancy of the spin_lock. >>>>> Then I will resend this patch dropping the spin_unlock/spin_lock >>>>> around uart_write_wakeup. >>>>> Is that ok with you. >>>> >>>> Anand, before doing that, can you check Peter's second sentence? I >>>> mean the "If this is causing lock-ups in a line discipline, the line >>>> discipline needs fixed.". >>>> Don't drop the spin-locks "just because". I would be happy to see more >>>> detailed explanation in changelog. >>>> >>>> Best regards, >>>> Krzysztof >>> >>> Yes I understood the meaning of the sentence. Already the >>> s3c24xx_serial_tx_chars function. >>> holds the lock port->lock for safe IRQ execution. >> >> I am sorry but I don't get your explanation. I mentioned Peter's >> thoughts about lockups after adding locking over uart_write(). However >> you are referring to s3c24xx_serial_tx_chars() holding the spin lock... >> I am missing the point... >> >> Best regards, >> Krzysztof >> > > I should be sorry I could not explain you in technical terms. > Interrupt routine already hold the port->lock > > s3c24xx_serial_tx_chars > \ > spin_lock_irqsave(&port->lock, flags); > \... > spin_unlock(&port->lock); > uart_write_wakeup(port); > spin_lock(&port->lock); > \ > spin_unlock_irqrestore(&port->lock, flags); >
This is obvious. > In my next patch I have tried to remove the spin_unlock/spin_lock over > uart_write_wakeup(port); Which may create lockups. Previously there was no port locking around uart_write_wakeup. Now there will be. You are effectively adding locking over uart_write_wakeup(). Again, we are back at the Peter's message - just check the damned lockups... BR, Krzysztof BR
