linux-kernel - Re: [PATCH] Add support for usbfs zerocopy.

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]

Message-ID: <20160112212644.GA6172@imap.gmail.com>
Date:	Tue, 12 Jan 2016 22:26:48 +0100
From:	"Steinar H. Gunderson" <sesse@...gle.com>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	Alan Stern <stern@...land.harvard.edu>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org
Subject: Re: [PATCH] Add support for usbfs zerocopy.

On Fri, Jan 08, 2016 at 01:45:35AM -0800, Christoph Hellwig wrote:
> IF it was using mmap for I/O it would read in through the page fault
> handler an then mark the page dirty for writeback by the VM.  Thats
> clearly not the case.
> 
> Instead it's using mmap on a file as a pecial purpose anonymous
> memory allocator, bypassing the VM and VM policies, including
> allowing to pin kernel memory that way.

FWIW, the allocated memory counts against the usbfs limits, so there's
no unbounded allocation opportunity here.

How do you suggest we proceed here? If mmap really is the wrong interface
(which is a bit frustrating after going through so many people :-) ),
what does the correct interface look like?

/* Steinar */
-- 
Software Engineer, Google Switzerland