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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 29 Jan 2014 08:20:45 +0900
From:	Akinobu Mita <akinobu.mita@...il.com>
To:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
Cc:	Marek Szyprowski <m.szyprowski@...sung.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <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

2014-01-28 Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>:
> 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.

Thanks for spotting the issue.  I haven't much tested on x86_32.
I'll go through it and try to find the solution.

>>
>> >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