linux-kernel - [PATCH 0/2] serial: imx: Backport fixes for irq handling to v4.14

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-next>] [day] [month] [year] [list]

Message-ID: <20200217140740.29743-1-frieder.schrempf@kontron.de>
Date:   Mon, 17 Feb 2020 14:08:00 +0000
From:   Schrempf Frieder <frieder.schrempf@...tron.de>
To:     "u.kleine-koenig@...gutronix.de" <u.kleine-koenig@...gutronix.de>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>
CC:     "shawnguo@...nel.org" <shawnguo@...nel.org>,
        Schrempf Frieder <frieder.schrempf@...tron.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-serial@...r.kernel.org" <linux-serial@...r.kernel.org>
Subject: [PATCH 0/2] serial: imx: Backport fixes for irq handling to v4.14

From: Frieder Schrempf <frieder.schrempf@...tron.de>

A customer of ours has problems with RS485 on i.MX6UL with the latest v4.14
kernel. They get an exception like below from time to time (the trace is
from an older kernel, but the problem also exists in v4.14.170).

As the cpuidle state 2 causes large delays for the interrupt that controls the
RS485 RTS signal (which can lead to collisions on the bus), cpuidle state 2 was
disabled on this system. This aspect might cause the exception happening more
often on this system than on other systems with default cpuidle settings.

Looking for solutions I found Uwe's patches that were applied in v4.17 being
mentioned here [1] and here [2]. In [1] Uwe notes that backporting these fixes
to v4.14 might not be trivial, but I tried and in my opinion found it not to be
too problematic either.

With the backported patches applied, our customer reports that the exceptions
stopped occuring. Given this and the fact that the problem seems to be known
and quite common, it would be nice to get this into the v4.14 stable tree. 

[1] https://patchwork.kernel.org/patch/11342831/
[2] https://community.nxp.com/thread/481000

Stack trace:

Unhandled fault: external abort on non-linefetch (0x1008) at 0x90928000
pgd = 8ce1c000
[90928000] *pgd=8d806811, *pte=021ec653, *ppte=021ec453
Internal error: : 1008 [#1] PREEMPT SMP ARM
Modules linked in: usb_f_ecm g_ether usb_f_rndis u_ether libcomposite xt_tcpudp iptable_filter ip_tables x_tables spidev
CPU: 0 PID: 277 Comm: mtiosSys5.elf Not tainted 4.14.89-exceet #4015
Hardware name: Freescale i.MX6 Ultralite (Device Tree)
task: 8da9de00 task.stack: 8cd50000
PC is at imx_rxint+0x58/0x298
LR is at _raw_spin_lock_irqsave+0x18/0x5c
pc : [<8044fa08>]    lr : [<80711208>]    psr: 20070193
sp : 8cd51ce0  ip : 8d400234  fp : 8da94010
r10: 80957900  r9 : 80c3e7ed  r8 : 00000004
r7 : 80c02d00  r6 : 00000000  r5 : 8dae49f0  r4 : 00000001
r3 : 0000e38e  r2 : 00021500  r1 : 90928000  r0 : 40070193
Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment none
Control: 10c5387d  Table: 8ce1c06a  DAC: 00000051
Process mtiosSys5.elf (pid: 277, stack limit = 0x8cd50210)
Stack: (0x8cd51ce0 to 0x8cd52000)
[...]
[<8044fa08>] (imx_rxint) from [<80450c1c>] (imx_int+0x124/0x20c)
[<80450c1c>] (imx_int) from [<8015ea94>] (__handle_irq_event_percpu+0x50/0x11c)
[<8015ea94>] (__handle_irq_event_percpu) from [<8015eb7c>] (handle_irq_event_percpu+0x1c/0x58)
[<8015eb7c>] (handle_irq_event_percpu) from [<8015ebf0>] (handle_irq_event+0x38/0x5c)
[<8015ebf0>] (handle_irq_event) from [<801621d4>] (handle_fasteoi_irq+0xb8/0x16c)
[<801621d4>] (handle_fasteoi_irq) from [<8015dd98>] (generic_handle_irq+0x24/0x34)
[<8015dd98>] (generic_handle_irq) from [<8015e2c0>] (__handle_domain_irq+0x7c/0xec)
[<8015e2c0>] (__handle_domain_irq) from [<80101448>] (gic_handle_irq+0x4c/0x90)
[<80101448>] (gic_handle_irq) from [<8010bf4c>] (__irq_svc+0x6c/0xa8)
[...]
[<8010bf4c>] (__irq_svc) from [<80711580>] (_raw_spin_unlock_irqrestore+0x20/0x54)
[<80711580>] (_raw_spin_unlock_irqrestore) from [<8044baf4>] (uart_write+0x110/0x178)
[<8044baf4>] (uart_write) from [<804339b8>] (n_tty_write+0x350/0x440)
[<804339b8>] (n_tty_write) from [<8042fbe8>] (tty_write+0x180/0x354)
[<8042fbe8>] (tty_write) from [<801f93bc>] (__vfs_write+0x1c/0x120)
[<801f93bc>] (__vfs_write) from [<801f9634>] (vfs_write+0xa4/0x168)
[<801f9634>] (vfs_write) from [<801f97f8>] (SyS_write+0x3c/0x90)
[<801f97f8>] (SyS_write) from [<80107900>] (ret_fast_syscall+0x0/0x54)
Code: e59b2074 e59b1008 e2822001 e58b2074 (e591a000)

Uwe Kleine-König (2):
  serial: imx: ensure that RX irqs are off if RX is off
  serial: imx: Only handle irqs that are actually enabled

 drivers/tty/serial/imx.c | 169 +++++++++++++++++++++++++++------------
 1 file changed, 117 insertions(+), 52 deletions(-)

-- 
2.17.1