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-next>] [day] [month] [year] [list]
Date:	Mon,  8 Sep 2008 18:10:09 +0900
From:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
To:	linux-kernel@...r.kernel.org
Cc:	mingo@...hat.com, joerg.roedel@....com, tony.luck@...el.com,
	linux-ia64@...r.kernel.org, iommu@...ts.linux-foundation.org,
	fujita.tomonori@....ntt.co.jp
Subject: [PATCH 0/5] fix exhaustion of ZONE_DMA with swiotlb (in x86 tree)

This patchset (against tip/master) fixes the problem that swiotlb
exhausts ZONE_DMA:

http://lkml.org/lkml/2008/8/31/16

The root problem is that swiotlb_alloc_coherent always use ZONE_DMA,
which is fine for IA64 but not for x86_64.

This patchset makes the callers set up the gfp flags so that
swiotlb_alloc_coherent can stop playing with the gfp flags.

I think that it would be better to remove the allocation code in
swiotlb_alloc_coherent theoretically (what swiotlb should do is taking
care of the swiotlb memory. And swiotlb_alloc_coherent is not useful
since we use it only when we can't allocate memory reachable by the
device or we are in out of memory). But that code works for both x86
and IA64 so it's not so bad, I guess.

#1 is for IA64, #2-4 for x86, and #5 is for swiotlb.

=
 arch/ia64/include/asm/dma-mapping.h |    4 ++-
 arch/x86/kernel/pci-nommu.c         |   21 +------------------
 include/asm-x86/dma-mapping.h       |   37 +++++++++++++++++++++++++++++++---
 lib/swiotlb.c                       |    7 ------
 4 files changed, 37 insertions(+), 32 deletions(-)


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