lkml.org 
[lkml]   [2019]   [Dec]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [bug] __blk_mq_run_hw_queue suspicious rcu usage
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.

\
 
 \ /
  Last update: 2019-12-13 01:11    [W:0.045 / U:1.412 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site