LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* [PATCH RFC] dma-direct: Try reallocation with GFP_DMA32 if possible
@ 2018-04-16 15:18 Takashi Iwai
  2018-04-20  9:47 ` Christoph Hellwig
  0 siblings, 1 reply; 4+ messages in thread
From: Takashi Iwai @ 2018-04-16 15:18 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: iommu, linux-kernel

As the recent swiotlb bug revealed, we seem to have given up the
direct DMA allocation too early and felt back to swiotlb allocation.
The reason is that swiotlb allocator expected that dma_direct_alloc()
would try harder to get pages even below 64bit DMA mask with
GFP_DMA32, but the function doesn't do that but only deals with
GFP_DMA case.

This patch adds a similar fallback reallocation with GFP_DMA32 as
we've done with GFP_DMA.  The condition is that the coherent mask is
smaller than 64bit (i.e. some address limitation), and neither GFP_DMA
nor GFP_DMA32 is set beforehand.

Signed-off-by: Takashi Iwai <tiwai@suse.de>

---

This is a resend of a test patch included in the previous thread
("swiotlb: Fix unexpected swiotlb_alloc_coherent() failures").

 lib/dma-direct.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/lib/dma-direct.c b/lib/dma-direct.c
index bbfb229aa067..970d39155618 100644
--- a/lib/dma-direct.c
+++ b/lib/dma-direct.c
@@ -84,6 +84,13 @@ void *dma_direct_alloc(struct device *dev, size_t size, dma_addr_t *dma_handle,
 		__free_pages(page, page_order);
 		page = NULL;
 
+		if (IS_ENABLED(CONFIG_ZONE_DMA32) &&
+		    dev->coherent_dma_mask < DMA_BIT_MASK(64) &&
+		    !(gfp & (GFP_DMA32 | GFP_DMA))) {
+			gfp |= GFP_DMA32;
+			goto again;
+		}
+
 		if (IS_ENABLED(CONFIG_ZONE_DMA) &&
 		    dev->coherent_dma_mask < DMA_BIT_MASK(32) &&
 		    !(gfp & GFP_DMA)) {
-- 
2.16.3

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH RFC] dma-direct: Try reallocation with GFP_DMA32 if possible
  2018-04-16 15:18 [PATCH RFC] dma-direct: Try reallocation with GFP_DMA32 if possible Takashi Iwai
@ 2018-04-20  9:47 ` Christoph Hellwig
  2018-04-20  9:58   ` Takashi Iwai
  0 siblings, 1 reply; 4+ messages in thread
From: Christoph Hellwig @ 2018-04-20  9:47 UTC (permalink / raw)
  To: Takashi Iwai; +Cc: Christoph Hellwig, iommu, linux-kernel

On Mon, Apr 16, 2018 at 05:18:19PM +0200, Takashi Iwai wrote:
> As the recent swiotlb bug revealed, we seem to have given up the
> direct DMA allocation too early and felt back to swiotlb allocation.
> The reason is that swiotlb allocator expected that dma_direct_alloc()
> would try harder to get pages even below 64bit DMA mask with
> GFP_DMA32, but the function doesn't do that but only deals with
> GFP_DMA case.
> 
> This patch adds a similar fallback reallocation with GFP_DMA32 as
> we've done with GFP_DMA.  The condition is that the coherent mask is
> smaller than 64bit (i.e. some address limitation), and neither GFP_DMA
> nor GFP_DMA32 is set beforehand.
> 
> Signed-off-by: Takashi Iwai <tiwai@suse.de>
> 
> ---
> 
> This is a resend of a test patch included in the previous thread
> ("swiotlb: Fix unexpected swiotlb_alloc_coherent() failures").

I like the patch, but as-is it doesn't apply.  Can you resend it against
latest Linus' tree?

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH RFC] dma-direct: Try reallocation with GFP_DMA32 if possible
  2018-04-20  9:47 ` Christoph Hellwig
@ 2018-04-20  9:58   ` Takashi Iwai
  2018-04-20 10:06     ` Christoph Hellwig
  0 siblings, 1 reply; 4+ messages in thread
From: Takashi Iwai @ 2018-04-20  9:58 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: iommu, linux-kernel

On Fri, 20 Apr 2018 11:47:02 +0200,
Christoph Hellwig wrote:
> 
> On Mon, Apr 16, 2018 at 05:18:19PM +0200, Takashi Iwai wrote:
> > As the recent swiotlb bug revealed, we seem to have given up the
> > direct DMA allocation too early and felt back to swiotlb allocation.
> > The reason is that swiotlb allocator expected that dma_direct_alloc()
> > would try harder to get pages even below 64bit DMA mask with
> > GFP_DMA32, but the function doesn't do that but only deals with
> > GFP_DMA case.
> > 
> > This patch adds a similar fallback reallocation with GFP_DMA32 as
> > we've done with GFP_DMA.  The condition is that the coherent mask is
> > smaller than 64bit (i.e. some address limitation), and neither GFP_DMA
> > nor GFP_DMA32 is set beforehand.
> > 
> > Signed-off-by: Takashi Iwai <tiwai@suse.de>
> > 
> > ---
> > 
> > This is a resend of a test patch included in the previous thread
> > ("swiotlb: Fix unexpected swiotlb_alloc_coherent() failures").
> 
> I like the patch, but as-is it doesn't apply.  Can you resend it against
> latest Linus' tree?

It's because it's written on the tree with another fix patch I sent
beforehand ("[PATCH 1/2] dma-direct: Don't repeat allocation for no-op
GFP_DMA").

Could you check that one at first?  I'm fine to rebase and resubmit
this one, if still preferred, though.


thanks,

Takashi

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH RFC] dma-direct: Try reallocation with GFP_DMA32 if possible
  2018-04-20  9:58   ` Takashi Iwai
@ 2018-04-20 10:06     ` Christoph Hellwig
  0 siblings, 0 replies; 4+ messages in thread
From: Christoph Hellwig @ 2018-04-20 10:06 UTC (permalink / raw)
  To: Takashi Iwai; +Cc: Christoph Hellwig, iommu, linux-kernel

On Fri, Apr 20, 2018 at 11:58:58AM +0200, Takashi Iwai wrote:
> It's because it's written on the tree with another fix patch I sent
> beforehand ("[PATCH 1/2] dma-direct: Don't repeat allocation for no-op
> GFP_DMA").
> 
> Could you check that one at first?  I'm fine to rebase and resubmit
> this one, if still preferred, though.

That one looks fine, too.  I'll add it to my patch queue.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2018-04-20 10:05 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-04-16 15:18 [PATCH RFC] dma-direct: Try reallocation with GFP_DMA32 if possible Takashi Iwai
2018-04-20  9:47 ` Christoph Hellwig
2018-04-20  9:58   ` Takashi Iwai
2018-04-20 10:06     ` Christoph Hellwig

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).