From: Sasha Levin <sasha.levin@oracle.com>
To: "Steinar H. Gunderson" <sesse@google.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
stern@rowland.harvard.edu
Subject: Re: [PATCH] Add support for usbfs zerocopy.
Date: Wed, 24 Feb 2016 14:30:08 -0500 [thread overview]
Message-ID: <56CE04C0.4050603@oracle.com> (raw)
In-Reply-To: <E1aGbQq-0000sS-SM@pannekake.samfundet.no>
On 11/25/2015 07:19 PM, Steinar H. Gunderson wrote:
> Add a new interface for userspace to preallocate memory that can be
> used with usbfs. This gives two primary benefits:
>
> - Zerocopy; data no longer needs to be copied between the userspace
> and the kernel, but can instead be read directly by the driver from
> userspace's buffers. This works for all kinds of transfers (even if
> nonsensical for control and interrupt transfers); isochronous also
> no longer need to memset() the buffer to zero to avoid leaking kernel data.
>
> - Once the buffers are allocated, USB transfers can no longer fail due to
> memory fragmentation; previously, long-running programs could run into
> problems finding a large enough contiguous memory chunk, especially on
> embedded systems or at high rates.
>
> Memory is allocated by using mmap() against the usbfs file descriptor,
> and similarly deallocated by munmap(). Once memory has been allocated,
> using it as pointers to a bulk or isochronous operation means you will
> automatically get zerocopy behavior. Note that this also means you cannot
> modify outgoing data until the transfer is complete. The same holds for
> data on the same cache lines as incoming data; DMA modifying them at the
> same time could lead to your changes being overwritten.
>
> There's a new capability USBDEVFS_CAP_MMAP that userspace can query to see
> if the running kernel supports this functionality, if just trying mmap() is
> not acceptable.
>
> Largely based on a patch by Markus Rechberger with some updates. The original
> patch can be found at:
>
> http://sundtek.de/support/devio_mmap_v0.4.diff
>
> Signed-off-by: Steinar H. Gunderson <sesse@google.com>
> Signed-off-by: Markus Rechberger <mrechberger@gmail.com>
> Acked-by: Alan Stern <stern@rowland.harvard.edu>
Hi,
I'm seeing the following warning while fuzzing:
[ 1595.188189] WARNING: CPU: 3 PID: 26063 at mm/page_alloc.c:3207 __alloc_pages_nodemask+0x960/0x29e0()
[ 1595.188287] Modules linked in:
[ 1595.188316] CPU: 3 PID: 26063 Comm: syz-executor Not tainted 4.5.0-rc5-next-20160223-sasha-00022-g03b30f1-dirty #2982
[ 1595.188362] 1ffff1001460ce89 ffff8800a30674d0 ffffffffa03cecad ffffffff00000003
[ 1595.188380] fffffbfff5829420 0000000041b58ab3 ffffffffabb334e2 ffffffffa03ceb15
[ 1595.188395] ffffffff9e5964c0 0000000041b58ab3 ffffffffabb4e542 ffffffff9e6ee830
[ 1595.188401] Call Trace:
[ 1595.188445] dump_stack (lib/dump_stack.c:53)
[ 1595.188529] warn_slowpath_common (kernel/panic.c:483)
[ 1595.188552] warn_slowpath_null (kernel/panic.c:517)
[ 1595.188561] __alloc_pages_nodemask (mm/page_alloc.c:3207 mm/page_alloc.c:3467)
[ 1595.188768] alloc_pages_current (mm/mempolicy.c:2088)
[ 1595.188784] alloc_kmem_pages (mm/page_alloc.c:3648)
[ 1595.188802] kmalloc_order (mm/slab_common.c:1014)
[ 1595.188819] __kmalloc (include/linux/slab.h:397 include/linux/slab.h:404 mm/slub.c:3573)
[ 1595.188870] hcd_buffer_alloc (include/linux/slab.h:477 drivers/usb/core/buffer.c:130)
[ 1595.188934] usb_alloc_coherent (drivers/usb/core/usb.c:736)
[ 1595.188941] usbdev_mmap (drivers/usb/core/devio.c:243)
[ 1595.189014] mmap_region (mm/mmap.c:1502)
[ 1595.189335] do_mmap (mm/mmap.c:1282)
[ 1595.189352] vm_mmap_pgoff (mm/util.c:335)
[ 1595.189384] SyS_mmap_pgoff (mm/mmap.c:1331 mm/mmap.c:1289)
[ 1595.189429] SyS_mmap (arch/x86/kernel/sys_x86_64.c:86)
[ 1595.189437] entry_SYSCALL_64_fastpath (arch/x86/entry/entry_64.S:200)
Thanks,
Sasha
next prev parent reply other threads:[~2016-02-24 19:30 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.LNX.4.44L0.1601051024110.1666-100000@iolanthe.rowland.org>
2016-01-05 16:27 ` Does vm_operations_struct require a .owner field? Alan Stern
2016-01-05 20:58 ` Kirill A. Shutemov
2016-01-05 21:31 ` Alan Stern
2015-11-26 0:19 ` [PATCH] Add support for usbfs zerocopy Steinar H. Gunderson
2016-01-06 0:11 ` Greg Kroah-Hartman
2015-11-26 0:19 ` [PATCH v2] " Steinar H. Gunderson
2016-01-07 2:01 ` Lingzhu Xiang
2016-01-07 15:40 ` Alan Stern
2016-01-11 11:08 ` Oliver Neukum
[not found] ` <20160111161504.GG10641@char.us.oracle.com>
2016-01-12 10:00 ` Oliver Neukum
2016-01-09 4:00 ` Lingzhu Xiang
2016-01-09 10:57 ` Steinar H. Gunderson
2016-01-24 21:12 ` Greg Kroah-Hartman
2016-01-25 8:03 ` Steinar H. Gunderson
2016-02-02 10:34 ` Steinar H. Gunderson
2016-02-03 21:23 ` Greg Kroah-Hartman
2016-02-03 21:58 ` [PATCH v4] " Steinar H. Gunderson
2016-02-03 22:09 ` [PATCH v2] " Steinar H. Gunderson
2016-02-03 22:15 ` Felipe Balbi
2016-02-03 23:40 ` Steinar H. Gunderson
2016-02-04 10:17 ` Bjørn Mork
2016-02-04 10:26 ` Steinar H. Gunderson
2016-02-12 20:55 ` Steinar H. Gunderson
2016-01-06 0:24 ` [PATCH] " Steinar H. Gunderson
2016-01-06 6:49 ` Christoph Hellwig
2016-01-06 14:45 ` Steinar H. Gunderson
2016-01-06 15:22 ` Peter Stuge
2016-01-06 15:36 ` Steinar H. Gunderson
2016-01-06 15:39 ` Alan Stern
2016-01-06 15:35 ` Alan Stern
2016-01-08 9:45 ` Christoph Hellwig
2016-01-08 10:22 ` David Laight
2016-01-08 16:02 ` Oliver Neukum
2016-01-12 21:26 ` Steinar H. Gunderson
2016-01-12 22:05 ` Alan Stern
2016-01-13 6:59 ` Lingzhu Xiang
2016-01-13 17:21 ` Greg Kroah-Hartman
2016-01-08 9:43 ` Christoph Hellwig
2016-02-24 19:30 ` Sasha Levin [this message]
2016-02-24 19:33 ` Steinar H. Gunderson
2016-01-05 23:54 ` Does vm_operations_struct require a .owner field? Steinar H. Gunderson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56CE04C0.4050603@oracle.com \
--to=sasha.levin@oracle.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=sesse@google.com \
--cc=stern@rowland.harvard.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).