lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 27 Jan 2014 10:23:42 -0500
From:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To:	Marek Szyprowski <m.szyprowski@...sung.com>
Cc:	Akinobu Mita <akinobu.mita@...il.com>,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	David Woodhouse <dwmw2@...radead.org>,
	Don Dutile <ddutile@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, Andi Kleen <andi@...stfloor.org>,
	x86@...nel.org, iommu@...ts.linux-foundation.org
Subject: Re: [PATCH v2 1/5] x86: make dma_alloc_coherent() return zeroed
 memory if CMA is enabled

On Mon, Jan 27, 2014 at 02:54:47PM +0100, Marek Szyprowski wrote:
> Hello,
> 
> On 2014-01-14 15:13, Akinobu Mita wrote:
> >Calling dma_alloc_coherent() with __GFP_ZERO must return zeroed memory.
> >
> >But when the contiguous memory allocator (CMA) is enabled on x86 and
> >the memory region is allocated by dma_alloc_from_contiguous(), it
> >doesn't return zeroed memory.  Because dma_generic_alloc_coherent()
> >forgot to fill the memory region with zero if it was allocated by
> >dma_alloc_from_contiguous()
> 
> I just wonder how it will work with high mem? I've didn't check the x86
> dma mapping code yet, but page_address() works only for pages, which comes
> from low memory. In other patches you have added an option to place CMA
> area anywhere in the memory. Is the x86 pci dma code ready for the case
> when cma area is put into high mem and direct mappings are not available?

Yes and no. The swiotbl_bounce does have the code to take that into account.
But that is it - nothing else does - so I think you would run in the 
possiblity of 'page_address' not providing an correct virtual address.

> 
> >Most implementations of dma_alloc_coherent() return zeroed memory
> >regardless of whether __GFP_ZERO is specified.  So this fixes it by
> >unconditionally zeroing the allocated memory region.
> >
> >Cc: Marek Szyprowski <m.szyprowski@...sung.com>
> >Cc: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
> >Cc: David Woodhouse <dwmw2@...radead.org>
> >Cc: Don Dutile <ddutile@...hat.com>
> >Cc: Thomas Gleixner <tglx@...utronix.de>
> >Cc: Ingo Molnar <mingo@...hat.com>
> >Cc: "H. Peter Anvin" <hpa@...or.com>
> >Cc: Andi Kleen <andi@...stfloor.org>
> >Cc: x86@...nel.org
> >Cc: iommu@...ts.linux-foundation.org
> >Signed-off-by: Akinobu Mita <akinobu.mita@...il.com>
> >---
> >New patch from this version
> >
> >  arch/x86/kernel/pci-dma.c | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> >
> >diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c
> >index 872079a..9644405 100644
> >--- a/arch/x86/kernel/pci-dma.c
> >+++ b/arch/x86/kernel/pci-dma.c
> >@@ -97,7 +97,6 @@ void *dma_generic_alloc_coherent(struct device *dev, size_t size,
> >  	dma_mask = dma_alloc_coherent_mask(dev, flag);
> >-	flag |= __GFP_ZERO;
> >  again:
> >  	page = NULL;
> >  	if (!(flag & GFP_ATOMIC))
> >@@ -118,7 +117,7 @@ again:
> >  		return NULL;
> >  	}
> >-
> >+	memset(page_address(page), 0, size);
> >  	*dma_addr = addr;
> >  	return page_address(page);
> >  }
> 
> Best regards
> -- 
> Marek Szyprowski, PhD
> Samsung R&D Institute Poland
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ