From: Christoph Hellwig <hch@lst.de>
To: David Rientjes <rientjes@google.com>
Cc: Jens Axboe <axboe@kernel.dk>,
Tom Lendacky <thomas.lendacky@amd.com>,
Brijesh Singh <brijesh.singh@amd.com>,
x86@kernel.org, linux-kernel@vger.kernel.org,
Ming Lei <ming.lei@redhat.com>,
iommu@lists.linux-foundation.org, Peter Gonda <pgonda@google.com>,
Christoph Hellwig <hch@lst.de>, Jianxiong Gao <jxgao@google.com>
Subject: Re: [bug] __blk_mq_run_hw_queue suspicious rcu usage
Date: Thu, 5 Sep 2019 08:06:27 +0200 [thread overview]
Message-ID: <20190905060627.GA1753@lst.de> (raw)
In-Reply-To: <alpine.DEB.2.21.1909041434580.160038@chino.kir.corp.google.com>
On Wed, Sep 04, 2019 at 02:40:44PM -0700, David Rientjes wrote:
> Hi Christoph, Jens, and Ming,
>
> While booting a 5.2 SEV-enabled guest we have encountered the following
> WARNING that is followed up by a BUG because we are in atomic context
> while trying to call set_memory_decrypted:
Well, this really is a x86 / DMA API issue unfortunately. Drivers
are allowed to do GFP_ATOMIC dma allocation under locks / rcu critical
sections and from interrupts. And it seems like the SEV case can't
handle that. We have some semi-generic code to have a fixed sized
pool in kernel/dma for non-coherent platforms that have similar issues
that we could try to wire up, but I wonder if there is a better way
to handle the issue, so I've added Tom and the x86 maintainers.
Now independent of that issue using DMA coherent memory for the nvme
PRPs/SGLs doesn't actually feel very optional. We could do with
normal kmalloc allocations and just sync it to the device and back.
I wonder if we should create some general mempool-like helpers for that.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: David Rientjes <rientjes@google.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>,
Brijesh Singh <brijesh.singh@amd.com>,
Christoph Hellwig <hch@lst.de>, Jens Axboe <axboe@kernel.dk>,
Ming Lei <ming.lei@redhat.com>, Peter Gonda <pgonda@google.com>,
Jianxiong Gao <jxgao@google.com>,
linux-kernel@vger.kernel.org, x86@kernel.org,
iommu@lists.linux-foundation.org
Subject: Re: [bug] __blk_mq_run_hw_queue suspicious rcu usage
Date: Thu, 5 Sep 2019 08:06:27 +0200 [thread overview]
Message-ID: <20190905060627.GA1753@lst.de> (raw)
In-Reply-To: <alpine.DEB.2.21.1909041434580.160038@chino.kir.corp.google.com>
On Wed, Sep 04, 2019 at 02:40:44PM -0700, David Rientjes wrote:
> Hi Christoph, Jens, and Ming,
>
> While booting a 5.2 SEV-enabled guest we have encountered the following
> WARNING that is followed up by a BUG because we are in atomic context
> while trying to call set_memory_decrypted:
Well, this really is a x86 / DMA API issue unfortunately. Drivers
are allowed to do GFP_ATOMIC dma allocation under locks / rcu critical
sections and from interrupts. And it seems like the SEV case can't
handle that. We have some semi-generic code to have a fixed sized
pool in kernel/dma for non-coherent platforms that have similar issues
that we could try to wire up, but I wonder if there is a better way
to handle the issue, so I've added Tom and the x86 maintainers.
Now independent of that issue using DMA coherent memory for the nvme
PRPs/SGLs doesn't actually feel very optional. We could do with
normal kmalloc allocations and just sync it to the device and back.
I wonder if we should create some general mempool-like helpers for that.
next prev parent reply other threads:[~2019-09-05 6:06 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-04 21:40 [bug] __blk_mq_run_hw_queue suspicious rcu usage David Rientjes
2019-09-05 6:06 ` Christoph Hellwig [this message]
2019-09-05 6:06 ` Christoph Hellwig
2019-09-05 22:37 ` David Rientjes via iommu
2019-09-05 22:37 ` David Rientjes
2019-09-16 23:45 ` David Rientjes via iommu
2019-09-16 23:45 ` David Rientjes
2019-09-17 18:23 ` David Rientjes via iommu
2019-09-17 18:23 ` David Rientjes
2019-09-17 18:32 ` Jens Axboe
2019-09-17 18:32 ` Jens Axboe
2019-09-17 18:41 ` Lendacky, Thomas
2019-09-17 18:41 ` Lendacky, Thomas
2019-09-18 13:22 ` Christoph Hellwig
2019-09-18 13:22 ` Christoph Hellwig
2019-11-27 22:11 ` David Rientjes via iommu
2019-11-27 22:11 ` David Rientjes
2019-11-28 6:40 ` Christoph Hellwig
2019-11-28 6:40 ` Christoph Hellwig
2019-12-13 0:07 ` David Rientjes via iommu
2019-12-13 0:07 ` David Rientjes
2019-12-13 9:33 ` David Rientjes via iommu
2019-12-13 9:33 ` David Rientjes
2019-12-15 5:38 ` David Rientjes via iommu
2019-12-15 5:38 ` David Rientjes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190905060627.GA1753@lst.de \
--to=hch@lst.de \
--cc=axboe@kernel.dk \
--cc=brijesh.singh@amd.com \
--cc=iommu@lists.linux-foundation.org \
--cc=jxgao@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ming.lei@redhat.com \
--cc=pgonda@google.com \
--cc=rientjes@google.com \
--cc=thomas.lendacky@amd.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.