Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 3 Feb 2020 09:36:22 -0800
From: Christoph Hellwig <>
To: Christian Borntraeger <>
Cc: Christoph Hellwig <>,
	Christopher Lameter <>,
	Kees Cook <>, Jiri Slaby <>,
	Julian Wiedmann <>,
	Ursula Braun <>,
	Alexander Viro <>,, David Windsor <>,
	Pekka Enberg <>,
	David Rientjes <>,
	Joonsoo Kim <>,
	Andrew Morton <>,,,
	Linus Torvalds <>,
	Andy Lutomirski <>,
	"David S. Miller" <>,
	Laura Abbott <>,
	Mark Rutland <>,
	"Martin K. Petersen" <>,
	Paolo Bonzini <>,
	Christoffer Dall <>,
	Dave Kleikamp <>, Jan Kara <>,
	Luis de Bethencourt <>,
	Marc Zyngier <>, Rik van Riel <>,
	Matthew Garrett <>,,,,,
	Vlastimil Babka <>, Michal Kubecek <>
Subject: Re: [PATCH 09/38] usercopy: Mark kmalloc caches
 as usercopy caches

On Wed, Jan 29, 2020 at 06:19:56PM +0100, Christian Borntraeger wrote:
> There is not necessarily a device for that. It is a hypervisor interface (an
> instruction that is interpreted by z/VM). We do have the netiucv driver that
> creates a virtual nic, but there is also AF_IUCV which works without a device.
> But back to the original question: If we mark kmalloc caches as usercopy caches,
> we should do the same for DMA kmalloc caches. As outlined by Christoph, this has
> nothing to do with device DMA.

Oh well, s/390 with its weird mix of cpu and I/O again.  Everywhere else
where we have addressing limits we do treat that as a DMA address.

We've also had a bit of a lose plan to force ZONE_DMA as a public
interface out, as it is generally the wrong thing to do for drivers.
A ZONE_32 and/or ZONE_31 makes some sense as the backing for the
dma allocator, but it mostly shouldn't be exposed, especially not to
the slab allocator.

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.