[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191128064056.GA19822@lst.de>
Date: Thu, 28 Nov 2019 07:40:56 +0100
From: Christoph Hellwig <hch@....de>
To: David Rientjes <rientjes@...gle.com>
Cc: Christoph Hellwig <hch@....de>,
"Lendacky, Thomas" <Thomas.Lendacky@....com>,
Keith Busch <kbusch@...nel.org>, Jens Axboe <axboe@...nel.dk>,
"Singh, Brijesh" <brijesh.singh@....com>,
Ming Lei <ming.lei@...hat.com>,
Peter Gonda <pgonda@...gle.com>,
Jianxiong Gao <jxgao@...gle.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"x86@...nel.org" <x86@...nel.org>,
"iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>
Subject: Re: [bug] __blk_mq_run_hw_queue suspicious rcu usage
On Wed, Nov 27, 2019 at 02:11:28PM -0800, David Rientjes wrote:
> So we're left with making dma_pool_alloc(GFP_ATOMIC) actually be atomic
> even when the DMA needs to be unencrypted for SEV. Christoph's suggestion
> was to wire up dmapool in kernel/dma/remap.c for this. Is that necessary
> to be done for all devices that need to do dma_pool_alloc(GFP_ATOMIC) or
> can we do it within the DMA API itself so it's transparent to the driver?
It needs to be transparent to the driver. Lots of drivers use GFP_ATOMIC
dma allocations, and all of them are broken on SEV setups currently.
Powered by blists - more mailing lists