[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.44L0.1601121702040.1319-100000@iolanthe.rowland.org>
Date: Tue, 12 Jan 2016 17:05:27 -0500 (EST)
From: Alan Stern <stern@...land.harvard.edu>
To: "Steinar H. Gunderson" <sesse@...gle.com>
cc: Christoph Hellwig <hch@...radead.org>,
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 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
Powered by blists - more mailing lists