linux-kernel - Re: [BUG 4.15-rc7] IRQ matrix management errors

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 15 Jan 2018 10:13:29 +0100 (CET)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Keith Busch <keith.busch@...el.com>
cc:     LKML <linux-kernel@...r.kernel.org>
Subject: Re: [BUG 4.15-rc7] IRQ matrix management errors

On Sun, 14 Jan 2018, Keith Busch wrote:

> I hoped to have a better report before the weekend, but I've run out of
> time and without my machine till next week, so sending what I have and
> praying someone more in the know will have a better clue.
> 
> I've a few NVMe drives and occasionally the IRQ teardown and bring-up
> is failing. Resetting the controllers to re-run interrupt allocation
> results in device interrupts from not occuring at all.
> 
> It appears I need at least 2 NVMe drives for the problem. The NVMe
> driver initializes controllers in parallel, and multiple threads calling
> pci_alloc_irq_vectors and/or pci_free_vectors at about the same time
> seems required to trigger the issue.
> 
> Here are the relavent warnings. I also have trace events from irq_matrix
> and irq_vectors, but from a different run that won't match up to the
> timestamps below, but can send if that's helpful.

The dmesg is not that interesting. The traces definitely are if you can
identify the point where it goes into lala land.

Thanks,

	tglx