linux-kernel - Re: [PATCH v2] Add support for usbfs zerocopy.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACnaKDT4C28f4iWhYpav2VEYU8f9GtNyJBVxtqJ=srd6Dks8YA@mail.gmail.com>
Date:	Wed, 6 Jan 2016 21:01:11 -0500
From:	Lingzhu Xiang <lingzhu.xiang@...l.utoronto.ca>
To:	"Steinar H. Gunderson" <sesse@...gle.com>
CC:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	<linux-usb@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<stern@...land.harvard.edu>
Subject: Re: [PATCH v2] Add support for usbfs zerocopy.

On Wed, Nov 25, 2015 at 7:19 PM, Steinar H. Gunderson <sesse@...gle.com> wrote:
> Add a new interface for userspace to preallocate memory that can be
> used with usbfs. This gives two primary benefits:

I got this when trying to allocate a little bit large buffer (~4MB)
using the new userspace libusb_dev_mem_alloc():

> [ 1706.212407] usb 2-1.1: reset SuperSpeed USB device number 3 using xhci_hcd
> [ 1706.234823] xhci_hcd 0000:00:14.0: swiotlb buffer is full (sz: 4325376 bytes)
> [ 1706.234827] swiotlb: coherent allocation failed for device 0000:00:14.0 size=4325376
> [ 1706.234830] CPU: 1 PID: 3233 Comm: Protonect Tainted: G     U  W       4.4.0-rc8-amd64 #1 Debian 4.4~rc8-1~exp1
> [ 1706.234831] Hardware name: LENOVO 20ALCTO1WW/20ALCTO1WW, BIOS GIET76WW (2.26 ) 08/27/2014
> [ 1706.234833]  0000000000000000 000000000f50c266 ffffffff812e6019 ffffffffffffffff
> [ 1706.234836]  ffffffff8130dc45 ffff88020000000b 0000000000420000 ffffffff81a2a0e0
> [ 1706.234838]  ffff880206263d80 0000000000000000 ffff88021c892f40 0000000000420040
> [ 1706.234841] Call Trace:
> [ 1706.234847]  [<ffffffff812e6019>] ? dump_stack+0x40/0x57
> [ 1706.234851]  [<ffffffff8130dc45>] ? swiotlb_alloc_coherent+0x135/0x150
> [ 1706.234867]  [<ffffffffa021deb1>] ? hcd_buffer_alloc+0xb1/0x130 [usbcore]
> [ 1706.234875]  [<ffffffffa0221ab5>] ? usbdev_mmap+0xa5/0x1b0 [usbcore]
> [ 1706.234880]  [<ffffffff813bbc25>] ? tty_insert_flip_string_fixed_flag+0x85/0xe0
> [ 1706.234885]  [<ffffffff8119af87>] ? mmap_region+0x3e7/0x660
> [ 1706.234888]  [<ffffffff8119b536>] ? do_mmap+0x336/0x420
> [ 1706.234892]  [<ffffffff8118213f>] ? vm_mmap_pgoff+0xaf/0xf0
> [ 1706.234895]  [<ffffffff811999dd>] ? SyS_mmap_pgoff+0x1ad/0x270
> [ 1706.234898]  [<ffffffff811d53b6>] ? SyS_write+0x76/0xc0
> [ 1706.234903]  [<ffffffff815829f2>] ? system_call_fast_compare_end+0xc/0x67

I understand there are some requirements on the allocation such that
large blocks are not always available. But what is the proper way to
determine the upper limit of the size such that the user can avoid
generating warnings like this? (Also, the application really wants to
be able to allocate large buffers, maybe tune swiotlb=?.)

Test results:

Basic testing with smaller buffer size shows the patch works well with
Kinect v2 (~260MB/s isochronous). Tests were performed on top of
4.4-rc8 with Debian config.

I'm still trying to verify whether this patch fixes page allocation
failure, but is having some trouble reproducing memory fragmentation.
I will later test it on the original machine which had the problem.

Regards,
Lingzhu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/