From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755657AbcBXTaR (ORCPT ); Wed, 24 Feb 2016 14:30:17 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:16525 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752316AbcBXTaP (ORCPT ); Wed, 24 Feb 2016 14:30:15 -0500 Subject: Re: [PATCH] Add support for usbfs zerocopy. To: "Steinar H. Gunderson" , Greg Kroah-Hartman References: Cc: linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, stern@rowland.harvard.edu From: Sasha Levin Message-ID: <56CE04C0.4050603@oracle.com> Date: Wed, 24 Feb 2016 14:30:08 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Source-IP: userv0022.oracle.com [156.151.31.74] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > Signed-off-by: Markus Rechberger > Acked-by: Alan Stern 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