Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1301673 > unrolled thread

Does vm_operations_struct require a .owner field?

Started byAlan Stern <stern@rowland.harvard.edu>
First post2016-01-05 17:30 +0100
Last post2016-01-08 10:50 +0100
Articles 8 on this page of 28 — 9 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Does vm_operations_struct require a .owner field? Alan Stern <stern@rowland.harvard.edu> - 2016-01-05 17:30 +0100
    Re: Does vm_operations_struct require a .owner field? "Kirill A. Shutemov" <kirill@shutemov.name> - 2016-01-05 22:00 +0100
      Re: Does vm_operations_struct require a .owner field? Alan Stern <stern@rowland.harvard.edu> - 2016-01-05 22:40 +0100
        Re: Does vm_operations_struct require a .owner field? "Steinar H. Gunderson" <sesse@google.com> - 2016-01-06 01:00 +0100
        [PATCH] Add support for usbfs zerocopy. "Steinar H. Gunderson" <sesse@google.com> - 2016-01-06 01:00 +0100
          Re: [PATCH] Add support for usbfs zerocopy. Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-01-06 01:20 +0100
            Re: [PATCH] Add support for usbfs zerocopy. "Steinar H. Gunderson" <sesse@google.com> - 2016-01-06 01:30 +0100
            [PATCH v2] Add support for usbfs zerocopy. "Steinar H. Gunderson" <sesse@google.com> - 2016-01-06 01:30 +0100
              Re: [PATCH v2] Add support for usbfs zerocopy. Lingzhu Xiang <lingzhu.xiang@mail.utoronto.ca> - 2016-01-07 03:40 +0100
                Re: [PATCH v2] Add support for usbfs zerocopy. Alan Stern <stern@rowland.harvard.edu> - 2016-01-07 16:50 +0100
                  Re: [PATCH v2] Add support for usbfs zerocopy. Oliver Neukum <oneukum@suse.com> - 2016-01-11 12:20 +0100
                    Re: [PATCH v2] Add support for usbfs zerocopy. Oliver Neukum <oneukum@suse.com> - 2016-01-12 11:10 +0100
              Re: [PATCH v2] Add support for usbfs zerocopy. Lingzhu Xiang <lingzhu.xiang@mail.utoronto.ca> - 2016-01-09 05:20 +0100
                Re: [PATCH v2] Add support for usbfs zerocopy. "Steinar H. Gunderson" <sesse@google.com> - 2016-01-09 12:00 +0100
          Re: [PATCH] Add support for usbfs zerocopy. Christoph Hellwig <hch@infradead.org> - 2016-01-06 07:50 +0100
            Re: [PATCH] Add support for usbfs zerocopy. "Steinar H. Gunderson" <sesse@google.com> - 2016-01-06 15:50 +0100
              Re: [PATCH] Add support for usbfs zerocopy. Peter Stuge <peter@stuge.se> - 2016-01-06 16:30 +0100
                Re: [PATCH] Add support for usbfs zerocopy. "Steinar H. Gunderson" <sesse@google.com> - 2016-01-06 16:40 +0100
                Re: [PATCH] Add support for usbfs zerocopy. Alan Stern <stern@rowland.harvard.edu> - 2016-01-06 16:40 +0100
              Re: [PATCH] Add support for usbfs zerocopy. Alan Stern <stern@rowland.harvard.edu> - 2016-01-06 16:40 +0100
                Re: [PATCH] Add support for usbfs zerocopy. Christoph Hellwig <hch@infradead.org> - 2016-01-08 10:50 +0100
                  RE: [PATCH] Add support for usbfs zerocopy. David Laight <David.Laight@ACULAB.COM> - 2016-01-08 11:30 +0100
                  Re: [PATCH] Add support for usbfs zerocopy. Oliver Neukum <oneukum@suse.com> - 2016-01-08 17:10 +0100
                  Re: [PATCH] Add support for usbfs zerocopy. "Steinar H. Gunderson" <sesse@google.com> - 2016-01-12 22:30 +0100
                    Re: [PATCH] Add support for usbfs zerocopy. Alan Stern <stern@rowland.harvard.edu> - 2016-01-12 23:10 +0100
                      Re: [PATCH] Add support for usbfs zerocopy. Lingzhu Xiang <lingzhu.xiang@mail.utoronto.ca> - 2016-01-13 08:10 +0100
                        Re: [PATCH] Add support for usbfs zerocopy. Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-01-13 18:30 +0100
              Re: [PATCH] Add support for usbfs zerocopy. Christoph Hellwig <hch@infradead.org> - 2016-01-08 10:50 +0100

Page 2 of 2 — ← Prev page 1 [2]

#1304316 — Re: [PATCH] Add support for usbfs zerocopy.

FromChristoph Hellwig <hch@infradead.org>
Date2016-01-08 10:50 +0100
SubjectRe: [PATCH] Add support for usbfs zerocopy.
Message-ID<qOBQe-4Sr-27@gated-at.bofh.it>
In reply to#1302857
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.

[toc] | [prev] | [next] | [standalone]

#1304343 — RE: [PATCH] Add support for usbfs zerocopy.

FromDavid Laight <David.Laight@ACULAB.COM>
Date2016-01-08 11:30 +0100
SubjectRE: [PATCH] Add support for usbfs zerocopy.
Message-ID<qOCsW-5li-23@gated-at.bofh.it>
In reply to#1304316
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

[toc] | [prev] | [next] | [standalone]

#1304687 — Re: [PATCH] Add support for usbfs zerocopy.

FromOliver Neukum <oneukum@suse.com>
Date2016-01-08 17:10 +0100
SubjectRe: [PATCH] Add support for usbfs zerocopy.
Message-ID<qOHLZ-DI-27@gated-at.bofh.it>
In reply to#1304316
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

[toc] | [prev] | [next] | [standalone]

#1307844 — Re: [PATCH] Add support for usbfs zerocopy.

From"Steinar H. Gunderson" <sesse@google.com>
Date2016-01-12 22:30 +0100
SubjectRe: [PATCH] Add support for usbfs zerocopy.
Message-ID<qQeFQ-6D6-23@gated-at.bofh.it>
In reply to#1304316
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

[toc] | [prev] | [next] | [standalone]

#1307869 — Re: [PATCH] Add support for usbfs zerocopy.

FromAlan Stern <stern@rowland.harvard.edu>
Date2016-01-12 23:10 +0100
SubjectRe: [PATCH] Add support for usbfs zerocopy.
Message-ID<qQfiz-7aq-31@gated-at.bofh.it>
In reply to#1307844
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

[toc] | [prev] | [next] | [standalone]

#1308104 — Re: [PATCH] Add support for usbfs zerocopy.

FromLingzhu Xiang <lingzhu.xiang@mail.utoronto.ca>
Date2016-01-13 08:10 +0100
SubjectRe: [PATCH] Add support for usbfs zerocopy.
Message-ID<qQnJ8-4Cb-21@gated-at.bofh.it>
In reply to#1307869
On Tue, Jan 12, 2016 at 5:05 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
> Unless there are any other issues connected to this, I'm okay with the
> current version of the patch.

Any chance of this getting merged for 4.5?

Tested-by: Lingzhu Xiang <lingzhu.xiang@mail.utoronto.ca>

ACKs?

Regards,
Lingzhu

[toc] | [prev] | [next] | [standalone]

#1308659 — Re: [PATCH] Add support for usbfs zerocopy.

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2016-01-13 18:30 +0100
SubjectRe: [PATCH] Add support for usbfs zerocopy.
Message-ID<qQxp9-2W5-31@gated-at.bofh.it>
In reply to#1308104
On Wed, Jan 13, 2016 at 01:59:54AM -0500, Lingzhu Xiang wrote:
> On Tue, Jan 12, 2016 at 5:05 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
> > Unless there are any other issues connected to this, I'm okay with the
> > current version of the patch.
> 
> Any chance of this getting merged for 4.5?

No way, it's too late and hasn't been in linux-next for a while.  I will
merge this to my tree after 4.5-rc1 is out to give it lots of time for
testing.

thanks,

greg k-h

[toc] | [prev] | [next] | [standalone]

#1304314 — Re: [PATCH] Add support for usbfs zerocopy.

FromChristoph Hellwig <hch@infradead.org>
Date2016-01-08 10:50 +0100
SubjectRe: [PATCH] Add support for usbfs zerocopy.
Message-ID<qOBQe-4Sr-13@gated-at.bofh.it>
In reply to#1302826
On Wed, Jan 06, 2016 at 03:45:12PM +0100, Steinar H. Gunderson wrote:
> On Tue, Jan 05, 2016 at 10:49:49PM -0800, Christoph Hellwig wrote:
> > This is a completely broken usage of the mmap interface.  if you use
> > mmap on a device file you must use the actual mmap for the data
> > transfer.
> 
> Really? V4L does exactly the same thing, from what I can see. It's just a way
> of allocating memory with specific properties, roughly similar to hugetlbfs.

V4l is generally speaking never an example for good practices.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web