lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <00d901ccfd0a$3c268740$b47395c0$@lge.com>
Date:	Thu, 8 Mar 2012 18:02:48 +0900
From:	"Kim, Jong-Sung" <neidhard.kim@....com>
To:	"'Chanho Min'" <chanho0207@...il.com>,
	"'Russell King'" <linux@....linux.org.uk>,
	"'Alan Cox'" <alan@...ux.intel.com>,
	"'Greg Kroah-Hartman'" <gregkh@...uxfoundation.org>,
	"'Linus Walleij'" <linus.walleij@...aro.org>,
	"'Shreshtha Kumar Sahu'" <shreshthakumar.sahu@...ricsson.com>
Cc:	<linux-kernel@...r.kernel.org>, <linux-serial@...r.kernel.org>
Subject: RE: [PATCH] Clear previous interrupts after fifo is disabled

> -----Original Message-----
> From: Chanho Min [mailto:chanho0207@...il.com]
> Sent: Monday, February 27, 2012 6:30 PM
> To: Russell King; Alan Cox; Greg Kroah-Hartman; Linus Walleij; Shreshtha
> Kumar Sahu; Kim, Jong-Sung
> Cc: linux-kernel@...r.kernel.org; linux-serial@...r.kernel.org
> Subject: [PATCH] Clear previous interrupts after fifo is disabled
> 
> This is another workaroud of  'https://lkml.org/lkml/2012/1/17/104'
> with additional analysis.Bootloader can transfer control to kernel and
there
> are some pending interrupts. In this case, RXFE of the flag register is
set
> by clearing FEN(LCRH) even if rx data remains in the fifo. It seems that
the
> fifo's status is initiailized. Interrupt handler can not get any data from
> data register because of the below break condtion.
> 
> pl011_fifo_to_tty
>  while (max_count--) {
>    if (status & UART01x_FR_RXFE)
> 	break;
> 
> Then, Rx interrupt is never cleared. cpu is looping in ISR. System is
hang.
> If we don't guarantee that no interrupt is pended until fifo is disabled
by
> calling 'writew(0, uap->port.membase + uap->lcrh_rx)', this misbehave of
the
> interrupt handelr can be occurred. So, All pending interrupts should be
> cleared just after fifo is disabled under the protection from interrupt.
> Also,'clear error interrupts' routine can be removed becuase all
interrupts
> are cleared before.
> 
> Signed-off-by: Chanho Min <chanho.min@....com>

May I suggest another approach at this point? The problematic condition you
reported could be considered as an exceptional Rx interrupt status. So, we
can handle it in the Rx ISR. Simply:

diff --git a/drivers/tty/serial/amba-pl011.c
b/drivers/tty/serial/amba-pl011.c
index 6800f5f..5b5358705 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -224,6 +224,10 @@ static int pl011_fifo_to_tty(struct uart_amba_port
*uap)
                uart_insert_char(&uap->port, ch, UART011_DR_OE, ch, flag);
        }
 
+       /* RXIS but RXFE? Just clear the interrupt */
+       if(unlikely(fifotaken == 0))
+               writew(UART011_RXIS, uap->port.membase + UART01x_ICR);
+
        return fifotaken;
 }


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ