linux-toradex.git/drivers/usb/gadget/function, branch v4.4.77

usb: gadget: f_fs: Fix possibe deadlock

2017-07-05T12:37:16+00:00

commit b3ce3ce02d146841af012d08506b4071db8ffde3 upstream.

When system try to close /dev/usb-ffs/adb/ep0 on one core, at the same
time another core try to attach new UDC, which will cause deadlock as
below scenario. Thus we should release ffs lock before issuing
unregister_gadget_item().

[   52.642225] c1 ======================================================
[   52.642228] c1 [ INFO: possible circular locking dependency detected ]
[   52.642236] c1 4.4.6+ #1 Tainted: G        W  O
[   52.642241] c1 -------------------------------------------------------
[   52.642245] c1 usb ffs open/2808 is trying to acquire lock:
[   52.642270] c0  (udc_lock){+.+.+.}, at: []
		usb_gadget_unregister_driver+0x3c/0xc8
[   52.642272] c1  but task is already holding lock:
[   52.642283] c0  (ffs_lock){+.+.+.}, at: []
		ffs_data_clear+0x30/0x140
[   52.642285] c1 which lock already depends on the new lock.
[   52.642287] c1
               the existing dependency chain (in reverse order) is:
[   52.642295] c0
	       -> #1 (ffs_lock){+.+.+.}:
[   52.642307] c0        [] __lock_acquire+0x20f0/0x2238
[   52.642314] c0        [] lock_acquire+0xe4/0x298
[   52.642322] c0        [] mutex_lock_nested+0x7c/0x3cc
[   52.642328] c0        [] ffs_func_bind+0x504/0x6e8
[   52.642334] c0        [] usb_add_function+0x84/0x184
[   52.642340] c0        [] configfs_composite_bind+0x264/0x39c
[   52.642346] c0        [] udc_bind_to_driver+0x58/0x11c
[   52.642352] c0        [] usb_udc_attach_driver+0x90/0xc8
[   52.642358] c0        [] gadget_dev_desc_UDC_store+0xd4/0x128
[   52.642369] c0        [] configfs_write_file+0xd0/0x13c
[   52.642376] c0        [] vfs_write+0xb8/0x214
[   52.642381] c0        [] SyS_write+0x54/0xb0
[   52.642388] c0        [] el0_svc_naked+0x24/0x28
[   52.642395] c0
              -> #0 (udc_lock){+.+.+.}:
[   52.642401] c0        [] print_circular_bug+0x84/0x2e4
[   52.642407] c0        [] __lock_acquire+0x2138/0x2238
[   52.642412] c0        [] lock_acquire+0xe4/0x298
[   52.642420] c0        [] mutex_lock_nested+0x7c/0x3cc
[   52.642427] c0        [] usb_gadget_unregister_driver+0x3c/0xc8
[   52.642432] c0        [] unregister_gadget_item+0x28/0x44
[   52.642439] c0        [] ffs_data_clear+0x138/0x140
[   52.642444] c0        [] ffs_data_reset+0x20/0x6c
[   52.642450] c0        [] ffs_data_closed+0xac/0x12c
[   52.642454] c0        [] ffs_ep0_release+0x20/0x2c
[   52.642460] c0        [] __fput+0xb0/0x1f4
[   52.642466] c0        [] ____fput+0x20/0x2c
[   52.642473] c0        [] task_work_run+0xb4/0xe8
[   52.642482] c0        [] do_exit+0x360/0xb9c
[   52.642487] c0        [] do_group_exit+0x4c/0xb0
[   52.642494] c0        [] get_signal+0x380/0x89c
[   52.642501] c0        [] do_signal+0x154/0x518
[   52.642507] c0        [] do_notify_resume+0x70/0x78
[   52.642512] c0        [] work_pending+0x1c/0x20
[   52.642514] c1
              other info that might help us debug this:
[   52.642517] c1  Possible unsafe locking scenario:
[   52.642518] c1        CPU0                    CPU1
[   52.642520] c1        ----                    ----
[   52.642525] c0   lock(ffs_lock);
[   52.642529] c0                                lock(udc_lock);
[   52.642533] c0                                lock(ffs_lock);
[   52.642537] c0   lock(udc_lock);
[   52.642539] c1
                      *** DEADLOCK ***
[   52.642543] c1 1 lock held by usb ffs open/2808:
[   52.642555] c0  #0:  (ffs_lock){+.+.+.}, at: []
		ffs_data_clear+0x30/0x140
[   52.642557] c1 stack backtrace:
[   52.642563] c1 CPU: 1 PID: 2808 Comm: usb ffs open Tainted: G
[   52.642565] c1 Hardware name: Spreadtrum SP9860g Board (DT)
[   52.642568] c1 Call trace:
[   52.642573] c1 [] dump_backtrace+0x0/0x170
[   52.642577] c1 [] show_stack+0x20/0x28
[   52.642583] c1 [] dump_stack+0xa8/0xe0
[   52.642587] c1 [] print_circular_bug+0x1fc/0x2e4
[   52.642591] c1 [] __lock_acquire+0x2138/0x2238
[   52.642595] c1 [] lock_acquire+0xe4/0x298
[   52.642599] c1 [] mutex_lock_nested+0x7c/0x3cc
[   52.642604] c1 [] usb_gadget_unregister_driver+0x3c/0xc8
[   52.642608] c1 [] unregister_gadget_item+0x28/0x44
[   52.642613] c1 [] ffs_data_clear+0x138/0x140
[   52.642618] c1 [] ffs_data_reset+0x20/0x6c
[   52.642621] c1 [] ffs_data_closed+0xac/0x12c
[   52.642625] c1 [] ffs_ep0_release+0x20/0x2c
[   52.642629] c1 [] __fput+0xb0/0x1f4
[   52.642633] c1 [] ____fput+0x20/0x2c
[   52.642636] c1 [] task_work_run+0xb4/0xe8
[   52.642640] c1 [] do_exit+0x360/0xb9c
[   52.642644] c1 [] do_group_exit+0x4c/0xb0
[   52.642647] c1 [] get_signal+0x380/0x89c
[   52.642651] c1 [] do_signal+0x154/0x518
[   52.642656] c1 [] do_notify_resume+0x70/0x78
[   52.642659] c1 [] work_pending+0x1c/0x20

Acked-by: Michal Nazarewicz 
Signed-off-by: Baolin Wang 
Signed-off-by: Felipe Balbi 
Cc: Jerry Zhang 
Signed-off-by: Greg Kroah-Hartman

usb: gadget: f_fs: avoid out of bounds access on comp_desc

2017-06-29T10:48:53+00:00

commit b7f73850bb4fac1e2209a4dd5e636d39be92f42c upstream.

Companion descriptor is only used for SuperSpeed endpoints,
if the endpoints are HighSpeed or FullSpeed, the Companion
descriptor will not allocated, so we can only access it if
gadget is SuperSpeed.

I can reproduce this issue on Rockchip platform rk3368 SoC
which supports USB 2.0, and use functionfs for ADB. Kernel
build with CONFIG_KASAN=y and CONFIG_SLUB_DEBUG=y report
the following BUG:

==================================================================
BUG: KASAN: slab-out-of-bounds in ffs_func_set_alt+0x224/0x3a0 at addr ffffffc0601f6509
Read of size 1 by task swapper/0/0
============================================================================
BUG kmalloc-256 (Not tainted): kasan: bad access detected
----------------------------------------------------------------------------

Disabling lock debugging due to kernel taint
INFO: Allocated in ffs_func_bind+0x52c/0x99c age=1275 cpu=0 pid=1
alloc_debug_processing+0x128/0x17c
___slab_alloc.constprop.58+0x50c/0x610
__slab_alloc.isra.55.constprop.57+0x24/0x34
__kmalloc+0xe0/0x250
ffs_func_bind+0x52c/0x99c
usb_add_function+0xd8/0x1d4
configfs_composite_bind+0x48c/0x570
udc_bind_to_driver+0x6c/0x170
usb_udc_attach_driver+0xa4/0xd0
gadget_dev_desc_UDC_store+0xcc/0x118
configfs_write_file+0x1a0/0x1f8
__vfs_write+0x64/0x174
vfs_write+0xe4/0x200
SyS_write+0x68/0xc8
el0_svc_naked+0x24/0x28
INFO: Freed in inode_doinit_with_dentry+0x3f0/0x7c4 age=1275 cpu=7 pid=247
...
Call trace:
[] dump_backtrace+0x0/0x230
[] show_stack+0x14/0x1c
[] dump_stack+0xa0/0xc8
[] print_trailer+0x188/0x198
[] object_err+0x3c/0x4c
[] kasan_report+0x324/0x4dc
[] __asan_load1+0x24/0x50
[] ffs_func_set_alt+0x224/0x3a0
[] composite_setup+0xdcc/0x1ac8
[] android_setup+0x124/0x1a0
[] _setup+0x54/0x74
[] handle_ep0+0x3288/0x4390
[] dwc_otg_pcd_handle_out_ep_intr+0x14dc/0x2ae4
[] dwc_otg_pcd_handle_intr+0x1ec/0x298
[] dwc_otg_pcd_irq+0x10/0x20
[] handle_irq_event_percpu+0x124/0x3ac
[] handle_irq_event+0x60/0xa0
[] handle_fasteoi_irq+0x10c/0x1d4
[] generic_handle_irq+0x30/0x40
[] __handle_domain_irq+0xac/0xdc
[] gic_handle_irq+0x64/0xa4
...
Memory state around the buggy address:
  ffffffc0601f6400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  ffffffc0601f6480: 00 00 00 00 00 00 00 00 00 00 06 fc fc fc fc fc
 >ffffffc0601f6500: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
                       ^
  ffffffc0601f6580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
  ffffffc0601f6600: fc fc fc fc fc fc fc fc 00 00 00 00 00 00 00 00
==================================================================

Signed-off-by: William Wu 
Signed-off-by: Felipe Balbi 
Cc: Jerry Zhang 
Signed-off-by: Greg Kroah-Hartman

usb: gadget: f_mass_storage: Serialize wake and sleep execution

2017-06-14T11:16:22+00:00

commit dc9217b69dd6089dcfeb86ed4b3c671504326087 upstream.

f_mass_storage has a memorry barrier issue with the sleep and wake
functions that can cause a deadlock. This results in intermittent hangs
during MSC file transfer. The host will reset the device after receiving
no response to resume the transfer. This issue is seen when dwc3 is
processing 2 transfer-in-progress events at the same time, invoking
completion handlers for CSW and CBW. Also this issue occurs depending on
the system timing and latency.

To increase the chance to hit this issue, you can force dwc3 driver to
wait and process those 2 events at once by adding a small delay (~100us)
in dwc3_check_event_buf() whenever the request is for CSW and read the
event count again. Avoid debugging with printk and ftrace as extra
delays and memory barrier will mask this issue.

Scenario which can lead to failure:
-----------------------------------
1) The main thread sleeps and waits for the next command in
   get_next_command().
2) bulk_in_complete() wakes up main thread for CSW.
3) bulk_out_complete() tries to wake up the running main thread for CBW.
4) thread_wakeup_needed is not loaded with correct value in
   sleep_thread().
5) Main thread goes to sleep again.

The pattern is shown below. Note the 2 critical variables.
 * common->thread_wakeup_needed
 * bh->state

	CPU 0 (sleep_thread)		CPU 1 (wakeup_thread)
	==============================  ===============================

					bh->state = BH_STATE_FULL;
					smp_wmb();
	thread_wakeup_needed = 0;	thread_wakeup_needed = 1;
	smp_rmb();
	if (bh->state != BH_STATE_FULL)
		sleep again ...

As pointed out by Alan Stern, this is an R-pattern issue. The issue can
be seen when there are two wakeups in quick succession. The
thread_wakeup_needed can be overwritten in sleep_thread, and the read of
the bh->state maybe reordered before the write to thread_wakeup_needed.

This patch applies full memory barrier smp_mb() in both sleep_thread()
and wakeup_thread() to ensure the order which the thread_wakeup_needed
and bh->state are written and loaded.

However, a better solution in the future would be to use wait_queue
method that takes care of managing memory barrier between waker and
waiter.

Acked-by: Alan Stern 
Signed-off-by: Thinh Nguyen 
Signed-off-by: Felipe Balbi 
Signed-off-by: Greg Kroah-Hartman

usb: gadget: f_midi: Fixed a bug when buflen was smaller than wMaxPacketSize

2017-05-03T04:19:50+00:00

commit 03d27ade4941076b34c823d63d91dc895731a595 upstream.

buflen by default (256) is smaller than wMaxPacketSize (512) in high-speed
devices.

That caused the OUT endpoint to freeze if the host send any data packet of
length greater than 256 bytes.

This is an example dump of what happended on that enpoint:
HOST:   [DATA][Length=260][...]
DEVICE: [NAK]
HOST:   [PING]
DEVICE: [NAK]
HOST:   [PING]
DEVICE: [NAK]
...
HOST:   [PING]
DEVICE: [NAK]

This patch fixes this problem by setting the minimum usb_request's buffer size
for the OUT endpoint as its wMaxPacketSize.

Acked-by: Michal Nazarewicz 
Signed-off-by: Felipe F. Tonello 
Signed-off-by: Felipe Balbi 
Cc: Julia Lawall 
Signed-off-by: Greg Kroah-Hartman

usb: gadget: f_uvc: Fix SuperSpeed companion descriptor's wBytesPerInterval

2017-03-30T07:35:16+00:00

commit 09424c50b7dff40cb30011c09114404a4656e023 upstream.

The streaming_maxburst module parameter is 0 offset (0..15)
so we must add 1 while using it for wBytesPerInterval
calculation for the SuperSpeed companion descriptor.

Without this host uvcvideo driver will always see the wrong
wBytesPerInterval for SuperSpeed uvc gadget and may not find
a suitable video interface endpoint.
e.g. for streaming_maxburst = 0 case it will always
fail as wBytePerInterval was evaluating to 0.

Reviewed-by: Laurent Pinchart 
Signed-off-by: Roger Quadros 
Signed-off-by: Felipe Balbi 
Signed-off-by: Greg Kroah-Hartman

ACM gadget: fix endianness in notifications

2017-03-30T07:35:16+00:00

commit cdd7928df0d2efaa3270d711963773a08a4cc8ab upstream.

The gadget code exports the bitfield for serial status changes
over the wire in its internal endianness. The fix is to convert
to little endian before sending it over the wire.

Signed-off-by: Oliver Neukum 
Tested-by: 家瑋 
Signed-off-by: Greg Kroah-Hartman

usb: gadget: function: f_fs: pass companion descriptor along

2017-03-18T11:09:57+00:00

commit 2bfa0719ac2a9b2f3c91345873d3cdebd0296ba9 upstream.

If we're dealing with SuperSpeed endpoints, we need
to make sure to pass along the companion descriptor
and initialize fields needed by the Gadget
API. Eventually, f_fs.c should be converted to use
config_ep_by_speed() like all other functions,
though.

Signed-off-by: Felipe Balbi 
Signed-off-by: Greg Kroah-Hartman

usb: gadget: f_fs: Assorted buffer overflow checks.

2017-02-09T07:02:46+00:00

commit 83e526f2a2fa4b2e82b6bd3ddbb26b70acfa8947 upstream.

OS descriptor head, when flagged as provided, is accessed without
checking if it fits in provided buffer. Verify length before access.
Also, there are other places where buffer length it checked
after accessing offsets which are potentially past the end. Check
buffer length before as well to fail cleanly.

Signed-off-by: Vincent Pelletier 
Acked-by: Felipe Balbi 
Signed-off-by: Greg Kroah-Hartman

usb: gadget: composite: always set ep->mult to a sensible value

2017-01-12T10:22:51+00:00

commit eaa496ffaaf19591fe471a36cef366146eeb9153 upstream.

ep->mult is supposed to be set to Isochronous and
Interrupt Endapoint's multiplier value. This value
is computed from different places depending on the
link speed.

If we're dealing with HighSpeed, then it's part of
bits [12:11] of wMaxPacketSize. This case wasn't
taken into consideration before.

While at that, also make sure the ep->mult defaults
to one so drivers can use it unconditionally and
assume they'll never multiply ep->maxpacket to zero.

Signed-off-by: Felipe Balbi 
Signed-off-by: Greg Kroah-Hartman

Revert "usb: gadget: composite: always set ep->mult to a sensible value"

2017-01-12T10:22:51+00:00

This reverts commit c53af76d5de1af844a71e673ae4a02f1786c1b9c which is
commit eaa496ffaaf19591fe471a36cef366146eeb9153 upstream as it was
incorrect.

Reported-by: Bin Liu 
Cc: Felipe Balbi 
Signed-off-by: Greg Kroah-Hartman