Re: [bug] __blk_mq_run_hw_queue suspicious rcu usage

From: David Rientjes
Date: Thu Dec 12 2019 - 19:11:11 EST

On Thu, 28 Nov 2019, Christoph Hellwig 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.

Not my area, so bear with me.

Since all DMA must be unencrypted in this case, what happens if all
dma_direct_alloc_pages() calls go through the DMA pool in
kernel/dma/remap.c when force_dma_unencrypted(dev) == true since
__PAGE_ENC is cleared for these ptes? (Ignoring for a moment that this
special pool should likely be a separate dma pool.)

I assume a general depletion of that atomic pool so
DEFAULT_DMA_COHERENT_POOL_SIZE becomes insufficient. I'm not sure what
size any DMA pool wired up for this specific purpose would need to be
sized at, so I assume dynamic resizing is required.

It shouldn't be *that* difficult to supplement kernel/dma/remap.c with the
ability to do background expansion of the atomic pool when nearing its
capacity for this purpose? I imagine that if we just can't allocate pages
within the DMA mask that it's the only blocker to dynamic expansion and we
don't oom kill for lowmem. But perhaps vm.lowmem_reserve_ratio is good
enough protection?

Beyond that, I'm not sure what sizing would be appropriate if this is to
be a generic solution in the DMA API for all devices that may require
unecrypted memory.