linux-kernel - Re: [RFC] On the Current Troubles of Mainlining Loongson Platform Drivers

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]

Date:   Wed, 22 Jan 2020 16:20:26 -0800
From:   Matt Turner <mattst88@...il.com>
To:     Aaro Koskinen <aaro.koskinen@....fi>
Cc:     "Maciej W. Rozycki" <macro@...ux-mips.org>,
        Alexandre Oliva <lxoliva@...la.org>, Tom Li <tomli@...li.me>,
        James Hogan <jhogan@...nel.org>,
        Jiaxun Yang <jiaxun.yang@...goat.com>,
        Huacai Chen <chenhc@...ote.com>,
        Ralf Baechle <ralf@...ux-mips.org>, linux-mips@...r.kernel.org,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] On the Current Troubles of Mainlining Loongson Platform Drivers

On Wed, Jun 12, 2019 at 12:25 PM Aaro Koskinen <aaro.koskinen@....fi> wrote:
>
> Hi,
>
> On Wed, Jun 12, 2019 at 06:55:28AM +0100, Maciej W. Rozycki wrote:
> > On Tue, 11 Jun 2019, Aaro Koskinen wrote:
> >
> > > However, with your patch the "nobody cared" is never reached so all is
> > > good. I tried 10 boots with the patch and all were successful. Without
> > > the patch 8 out of 10 failed with the "nobody cared" warning.
> >
> >  I wouldn't call it "good", just less obvious or painful.  This is still
> > causing wasted CPU cycles that are used for taking the phantom interrupts.
> >
> >  There is clearly a completion barrier missing somewhere that causes the
> > interrupt request to linger beyond the point interrupts are reenabled at
> > the CPU.
> >
> >  One way to attempt to narrow it down might be taking a backtrace from
> > where IRQ 14 is found to be spurious.  This would indicate the offending
> > interrupt unmask action.  E.g. I see no explicit completion barrier
>
> The first spurious IRQ is right after the driver registers:
>
> [    4.732000] [<ffffffff8020efac>] show_stack+0x90/0x140
> [    4.732000] [<ffffffff8052850c>] ata_bmdma_interrupt+0x2b4/0x39c
> [    4.732000] [<ffffffff80260368>] __handle_irq_event_percpu+0xb0/0x178
> [    4.732000] [<ffffffff80260464>] handle_irq_event_percpu+0x34/0x9c
> [    4.732000] [<ffffffff80260508>] handle_irq_event+0x3c/0x74
> [    4.732000] [<ffffffff80264d28>] handle_level_irq+0x118/0x154
> [    4.732000] [<ffffffff8025f978>] generic_handle_irq+0x34/0x50
> [    4.732000] [<ffffffff806b9600>] do_IRQ+0x18/0x24
> [    4.732000] [<ffffffff80208ce4>] handle_int+0x17c/0x188
> [    4.732000] [<ffffffff806b30c8>] arch_local_irq_restore+0x18/0x30
> [    4.732000] [<ffffffff802621f0>] __setup_irq+0x660/0x7a0
> [    4.732000] [<ffffffff80262798>] request_threaded_irq+0x114/0x19c
> [    4.732000] [<ffffffff80265d7c>] devm_request_threaded_irq+0xa0/0x10c
> [    4.732000] [<ffffffff80527f00>] ata_pci_sff_activate_host+0x1c0/0x274
> [    4.732000] [<ffffffff80528a30>] ata_pci_init_one+0x170/0x1c4
> [    4.732000] [<ffffffff8052a288>] cs5536_init_one+0x94/0xb8
>
> and the following ones do not seem to provide much info as I can only
> see the IRQ stack:
>
> [    4.736000] [<ffffffff8020efac>] show_stack+0x90/0x140
> [    4.736000] [<ffffffff8052850c>] ata_bmdma_interrupt+0x2b4/0x39c
> [    4.736000] [<ffffffff80260368>] __handle_irq_event_percpu+0xb0/0x178
> [    4.736000] [<ffffffff80260464>] handle_irq_event_percpu+0x34/0x9c
> [    4.736000] [<ffffffff80260508>] handle_irq_event+0x3c/0x74
> [    4.736000] [<ffffffff80264d28>] handle_level_irq+0x118/0x154
> [    4.736000] [<ffffffff8025f978>] generic_handle_irq+0x34/0x50
> [    4.736000] [<ffffffff806b9600>] do_IRQ+0x18/0x24
> [    4.736000] [<ffffffff80208ce4>] handle_int+0x17c/0x188
> [    4.736000] [<ffffffff8022f330>] irq_exit+0x68/0xcc
>
> > between the final `outb' in `mask_and_ack_8259A' and the following call to
> > `raw_spin_unlock_irqrestore', which are obviously otherwise unordered WRT
> > each other (because `outb' is I/O or MMIO and `raw_spin_unlock_irqrestore'
> > is contained within the CPU on UP).  I can see provisions however for
> > issuing an architecture-specific barrier in `do_raw_spin_unlock', which is
> > the workhorse for `raw_spin_unlock_irqrestore', so maybe this is the place
> > to look into?
> >
> >  Also how's IRQ 14 registered as indicated by /proc/interrupts?
>
> Not sure what you mean but here's the output:
>
> $ cat /proc/interrupts
>            CPU0
>   2:          0    XT-PIC   2  cascade
>   3:         20    XT-PIC   3  ttyS0
>   5:     543358    XT-PIC   5  timer
>  11:          0    XT-PIC  11  ehci_hcd:usb1, ohci_hcd:usb2
>  14:     100000    XT-PIC  14  pata_cs5536
>  18:          0      MIPS   2  cascade
>  22:          0      MIPS   6  cascade
>  36:       3052  bonito_irq      eth0
> ERR:          0
>
> A.

Has any more progress been made?

Thanks,
Matt