linux-kernel - Re: [PATH v2] NVMe: init nvme queue before enabling irq

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, 11 May 2016 15:16:33 -0400
From:	Keith Busch <keith.busch@...el.com>
To:	Johannes Thumshirn <jthumshirn@...e.de>
Cc:	Wenbo Wang <mail_weber_wang@....com>, axboe@...com,
	stable@...r.kernel.org, wenwei.tao@...blaze.com,
	linux-kernel@...r.kernel.org, linux-nvme@...ts.infradead.org,
	Wenbo Wang <wenbo.wang@...blaze.com>
Subject: Re: [PATH v2] NVMe: init nvme queue before enabling irq

On Wed, May 11, 2016 at 11:25:16AM +0200, Johannes Thumshirn wrote:
> What ever happened to this patch?
> I can easily reproduce the bug using
> while [ true ]; do rmmod nvme nvme_core; modprobe nvme; done

This patch was supposed to fix using a doorbell between resets when the
driver had BAR0 unmapped. We don't ever unmap the bar anymore, so this
patch shouldn't be necessary: the doorbell is already set during queue
allocation before requset_irq.

The test doesn't seem like this patch would help either. It sounds
more like you're hitting somethine else if you don't have this fix:

  https://git.kernel.org/cgit/linux/kernel/git/axboe/linux-block.git/commit/?h=for-linus&id=9bf2b972afeaffd173fe2ce211ebc555ea7e8a87

If you do have that fix already, I'd like to see the panic stack trace
(assuming that's what happened).