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: <0256a0a0139c56db75cffa4fe14079ad@kernel.org>
Date:   Wed, 18 Nov 2020 09:08:36 +0000
From:   Marc Zyngier <maz@...nel.org>
To:     Naresh Kamboju <naresh.kamboju@...aro.org>
Cc:     open list <linux-kernel@...r.kernel.org>,
        linux- stable <stable@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Sasha Levin <sashal@...nel.org>
Subject: Re: WARNING: kernel/irq/chip.c:242 __irq_startup+0xa8/0xb0

Naresh,

On 2020-11-18 06:11, Naresh Kamboju wrote:
> On Tue, 13 Oct 2020 at 11:09, Naresh Kamboju 
> <naresh.kamboju@...aro.org> wrote:
>> 
>> On stable rc  5.8.15 the following kernel warning was noticed once
>> while boot and this is hard to reproduce.
> 
> This is now reproduciable on arm64 NXP ls2088 device

How reproducible? On demand? Once in a while?

> 
> [   19.980839] ------------[ cut here ]------------
> [   19.985468] WARNING: CPU: 1 PID: 441 at kernel/irq/chip.c:242
> __irq_startup+0x9c/0xa8
> [   19.985472] Modules linked in: rfkill lm90 ina2xx crct10dif_ce
> qoriq_thermal fuse
> [   20.000773] CPU: 1 PID: 441 Comm: (agetty) Not tainted 5.4.78-rc1 #2

Can you please try and reproduce this on mainline?

> [   20.000775] Hardware name: Freescale Layerscape 2088A RDB Board (DT)
> [   20.000779] pstate: 60000085 (nZCv daIf -PAN -UAO)
> [   20.018253] pc : __irq_startup+0x9c/0xa8
> [   20.018256] lr : irq_startup+0x64/0x130
> [   20.018259] sp : ffff80001122f8e0
> [   20.029303] x29: ffff80001122f8e0 x28: ffff0082c242d400
> [   20.029306] x27: ffffdd0f47234768 x26: 0000000000020902
> [   20.029309] x25: ffffdd0f461a6f10 x24: ffffdd0f461a6bc8
> [   20.029311] x23: 0000000000000000 x22: 0000000000000001
> [   20.029314] x21: 0000000000000001 x20: ffff0082c22f8780
> [   20.029316] x19: ffff0082c1060800 x18: 0000000000000001
> [   20.029318] x17: 0000000000000000 x16: ffff8000114a0000
> [   20.029321] x15: 0000000000000000 x14: ffff0082c0e92f90
> [   20.071738] x13: ffff0082c0e93080 x12: ffff800011460000
> [   20.071741] x11: dead000000000100 x10: 0000000000000040
> [   20.071743] x9 : ffffdd0f47093ba8 x8 : ffffdd0f47093ba0
> [   20.087653] x7 : ffff0082a00002b0 x6 : ffffdd0f47074958
> [   20.087655] x5 : ffffdd0f47074000 x4 : ffff800011230000
> [   20.087657] x3 : 0000000000000504 x2 : 0000000000000001
> [   20.103567] x1 : 0000000003032004 x0 : ffff0082c1060858
> [   20.103570] Call trace:
> [   20.103573]  __irq_startup+0x9c/0xa8
> [   20.103577]  irq_startup+0x64/0x130
> [   20.118359]  __enable_irq+0x7c/0x88
> [   20.118362]  enable_irq+0x54/0xa8
> [   20.118367]  serial8250_do_startup+0x658/0x718
> [   20.118371]  serial8250_startup+0x38/0x48

Looking at the DT:

                 serial0: serial@...0500 {
                         interrupts = <0 32 0x4>; /* Level high type */

                 serial1: serial@...0600 {
                         interrupts = <0 32 0x4>; /* Level high type */

                 serial2: serial@...0500 {
                         interrupts = <0 33 0x4>; /* Level high type */

                 serial3: serial@...0600 {
                         interrupts = <0 33 0x4>; /* Level high type */


The UART interrupt lines are shared. Braindead, 1980 style.

Which UART is agetty trying to use? Is there any other process using
another UART concurrently? We could have a race between the line being
shut down on one device, and activated from the other, but I can't
spot it right away.

If you can reproduce it easily enough, it shouldn't be too hard to trace
what happens around the activation of the shared interrupt (assuming 
that
this is where the problem is).

         M.
-- 
Jazz is not dead. It just smells funny...

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ