Re: [PATCH] Add support for usbfs zerocopy.

Re: [PATCH] Add support for usbfs zerocopy.

[Christoph Hellwig]

On Wed, Jan 06, 2016 at 10:35:05AM -0500, Alan Stern wrote:
> Indeed, the I/O operations we are using with mmap here are not reads or 
> writes; they are ioctls.  As far as I know, the kernel doesn't have any 
> defined interface for zerocopy ioctls.

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.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

RE: [PATCH] Add support for usbfs zerocopy.

[David Laight]

From: Christoph Hellwig
> Sent: 08 January 2016 09:46
> On Wed, Jan 06, 2016 at 10:35:05AM -0500, Alan Stern wrote:
> > Indeed, the I/O operations we are using with mmap here are not reads or
> > writes; they are ioctls.  As far as I know, the kernel doesn't have any
> > defined interface for zerocopy ioctls.
> 
> 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.

Indeed, and never is the case when mmap() is processed by a
driver rather than a filesystem.

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

Opening a driver often allocates kernel memory, not a big deal.

	David

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] Add support for usbfs zerocopy.

[Oliver Neukum]

On Fri, 2016-01-08 at 01:45 -0800, Christoph Hellwig wrote:
> On Wed, Jan 06, 2016 at 10:35:05AM -0500, Alan Stern wrote:
> > Indeed, the I/O operations we are using with mmap here are not reads or 
> > writes; they are ioctls.  As far as I know, the kernel doesn't have any 
> > defined interface for zerocopy ioctls.
> 
> 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.

That won't work because we need the ability to determine the chunk size
IO is done in. USB devices don't map to files, yet the memory they can
operate on depends on the device, so allocation in the kernel for
a specific device is a necessity.

	Regards
		Oliver


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] Add support for usbfs zerocopy.

[Steinar H. Gunderson]

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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] Add support for usbfs zerocopy.

[Alan Stern]

On Tue, 12 Jan 2016, Steinar H. Gunderson wrote:

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

To me (and others on the mailing list), it appears that Christoph was
thinking of mmap as applied to a normal file, whereas the patch
concerns mmap applied to a device file.  One need not behave like
the other, which means the criticism was inappropriate.

Unless there are any other issues connected to this, I'm okay with the 
current version of the patch.

Alan Stern

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>