1. 02 Jan, 2017 18 commits
    • Alan Stern's avatar
      USB: gadgetfs: fix use-after-free bug · add333a8
      Alan Stern authored
      Andrey Konovalov reports that fuzz testing with syzkaller causes a
      KASAN use-after-free bug report in gadgetfs:
      
      BUG: KASAN: use-after-free in gadgetfs_setup+0x208a/0x20e0 at addr ffff88003dfe5bf2
      Read of size 2 by task syz-executor0/22994
      CPU: 3 PID: 22994 Comm: syz-executor0 Not tainted 4.9.0-rc7+ #16
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
       ffff88006df06a18 ffffffff81f96aba ffffffffe0528500 1ffff1000dbe0cd6
       ffffed000dbe0cce ffff88006df068f0 0000000041b58ab3 ffffffff8598b4c8
       ffffffff81f96828 1ffff1000dbe0ccd ffff88006df06708 ffff88006df06748
      Call Trace:
       <IRQ> [  201.343209]  [<     inline     >] __dump_stack lib/dump_stack.c:15
       <IRQ> [  201.343209]  [<ffffffff81f96aba>] dump_stack+0x292/0x398 lib/dump_stack.c:51
       [<ffffffff817e4dec>] kasan_object_err+0x1c/0x70 mm/kasan/report.c:159
       [<     inline     >] print_address_description mm/kasan/report.c:197
       [<ffffffff817e5080>] kasan_report_error+0x1f0/0x4e0 mm/kasan/report.c:286
       [<     inline     >] kasan_report mm/kasan/report.c:306
       [<ffffffff817e562a>] __asan_report_load_n_noabort+0x3a/0x40 mm/kasan/report.c:337
       [<     inline     >] config_buf drivers/usb/gadget/legacy/inode.c:1298
       [<ffffffff8322c8fa>] gadgetfs_setup+0x208a/0x20e0 drivers/usb/gadget/legacy/inode.c:1368
       [<ffffffff830fdcd0>] dummy_timer+0x11f0/0x36d0 drivers/usb/gadget/udc/dummy_hcd.c:1858
       [<ffffffff814807c1>] call_timer_fn+0x241/0x800 kernel/time/timer.c:1308
       [<     inline     >] expire_timers kernel/time/timer.c:1348
       [<ffffffff81482de6>] __run_timers+0xa06/0xec0 kernel/time/timer.c:1641
       [<ffffffff814832c1>] run_timer_softirq+0x21/0x80 kernel/time/timer.c:1654
       [<ffffffff84f4af8b>] __do_softirq+0x2fb/0xb63 kernel/softirq.c:284
      
      The cause of the bug is subtle.  The dev_config() routine gets called
      twice by the fuzzer.  The first time, the user data contains both a
      full-speed configuration descriptor and a high-speed config
      descriptor, causing dev->hs_config to be set.  But it also contains an
      invalid device descriptor, so the buffer containing the descriptors is
      deallocated and dev_config() returns an error.
      
      The second time dev_config() is called, the user data contains only a
      full-speed config descriptor.  But dev->hs_config still has the stale
      pointer remaining from the first call, causing the routine to think
      that there is a valid high-speed config.  Later on, when the driver
      dereferences the stale pointer to copy that descriptor, we get a
      use-after-free access.
      
      The fix is simple: Clear dev->hs_config if the passed-in data does not
      contain a high-speed config descriptor.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Reported-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Tested-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      CC: <stable@vger.kernel.org>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      add333a8
    • Alan Stern's avatar
      USB: gadgetfs: fix unbounded memory allocation bug · faab5098
      Alan Stern authored
      Andrey Konovalov reports that fuzz testing with syzkaller causes a
      KASAN warning in gadgetfs:
      
      BUG: KASAN: slab-out-of-bounds in dev_config+0x86f/0x1190 at addr ffff88003c47e160
      Write of size 65537 by task syz-executor0/6356
      CPU: 3 PID: 6356 Comm: syz-executor0 Not tainted 4.9.0-rc7+ #19
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
       ffff88003c107ad8 ffffffff81f96aba ffffffff3dc11ef0 1ffff10007820eee
       ffffed0007820ee6 ffff88003dc11f00 0000000041b58ab3 ffffffff8598b4c8
       ffffffff81f96828 ffffffff813fb4a0 ffff88003b6eadc0 ffff88003c107738
      Call Trace:
       [<     inline     >] __dump_stack lib/dump_stack.c:15
       [<ffffffff81f96aba>] dump_stack+0x292/0x398 lib/dump_stack.c:51
       [<ffffffff817e4dec>] kasan_object_err+0x1c/0x70 mm/kasan/report.c:159
       [<     inline     >] print_address_description mm/kasan/report.c:197
       [<ffffffff817e5080>] kasan_report_error+0x1f0/0x4e0 mm/kasan/report.c:286
       [<ffffffff817e5705>] kasan_report+0x35/0x40 mm/kasan/report.c:306
       [<     inline     >] check_memory_region_inline mm/kasan/kasan.c:308
       [<ffffffff817e3fb9>] check_memory_region+0x139/0x190 mm/kasan/kasan.c:315
       [<ffffffff817e4044>] kasan_check_write+0x14/0x20 mm/kasan/kasan.c:326
       [<     inline     >] copy_from_user arch/x86/include/asm/uaccess.h:689
       [<     inline     >] ep0_write drivers/usb/gadget/legacy/inode.c:1135
       [<ffffffff83228caf>] dev_config+0x86f/0x1190 drivers/usb/gadget/legacy/inode.c:1759
       [<ffffffff817fdd55>] __vfs_write+0x5d5/0x760 fs/read_write.c:510
       [<ffffffff817ff650>] vfs_write+0x170/0x4e0 fs/read_write.c:560
       [<     inline     >] SYSC_write fs/read_write.c:607
       [<ffffffff81803a5b>] SyS_write+0xfb/0x230 fs/read_write.c:599
       [<ffffffff84f47ec1>] entry_SYSCALL_64_fastpath+0x1f/0xc2
      
      Indeed, there is a comment saying that the value of len is restricted
      to a 16-bit integer, but the code doesn't actually do this.
      
      This patch fixes the warning.  It replaces the comment with a
      computation that forces the amount of data copied from the user in
      ep0_write() to be no larger than the wLength size for the control
      transfer, which is a 16-bit quantity.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Reported-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Tested-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      CC: <stable@vger.kernel.org>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      faab5098
    • Baolin Wang's avatar
      usb: gadget: f_fs: Fix possibe deadlock · b3ce3ce0
      Baolin Wang authored
      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: [<ffffffc00065aeec>]
      		usb_gadget_unregister_driver+0x3c/0xc8
      [   52.642272] c1  but task is already holding lock:
      [   52.642283] c0  (ffs_lock){+.+.+.}, at: [<ffffffc00066b244>]
      		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        [<ffffffc00012340c>] __lock_acquire+0x20f0/0x2238
      [   52.642314] c0        [<ffffffc000123b54>] lock_acquire+0xe4/0x298
      [   52.642322] c0        [<ffffffc000aaf6e8>] mutex_lock_nested+0x7c/0x3cc
      [   52.642328] c0        [<ffffffc00066f7bc>] ffs_func_bind+0x504/0x6e8
      [   52.642334] c0        [<ffffffc000654004>] usb_add_function+0x84/0x184
      [   52.642340] c0        [<ffffffc000658ca4>] configfs_composite_bind+0x264/0x39c
      [   52.642346] c0        [<ffffffc00065b348>] udc_bind_to_driver+0x58/0x11c
      [   52.642352] c0        [<ffffffc00065b49c>] usb_udc_attach_driver+0x90/0xc8
      [   52.642358] c0        [<ffffffc0006598e0>] gadget_dev_desc_UDC_store+0xd4/0x128
      [   52.642369] c0        [<ffffffc0002c14e8>] configfs_write_file+0xd0/0x13c
      [   52.642376] c0        [<ffffffc00023c054>] vfs_write+0xb8/0x214
      [   52.642381] c0        [<ffffffc00023cad4>] SyS_write+0x54/0xb0
      [   52.642388] c0        [<ffffffc000085ff0>] el0_svc_naked+0x24/0x28
      [   52.642395] c0
                    -> #0 (udc_lock){+.+.+.}:
      [   52.642401] c0        [<ffffffc00011e3d0>] print_circular_bug+0x84/0x2e4
      [   52.642407] c0        [<ffffffc000123454>] __lock_acquire+0x2138/0x2238
      [   52.642412] c0        [<ffffffc000123b54>] lock_acquire+0xe4/0x298
      [   52.642420] c0        [<ffffffc000aaf6e8>] mutex_lock_nested+0x7c/0x3cc
      [   52.642427] c0        [<ffffffc00065aeec>] usb_gadget_unregister_driver+0x3c/0xc8
      [   52.642432] c0        [<ffffffc00065995c>] unregister_gadget_item+0x28/0x44
      [   52.642439] c0        [<ffffffc00066b34c>] ffs_data_clear+0x138/0x140
      [   52.642444] c0        [<ffffffc00066b374>] ffs_data_reset+0x20/0x6c
      [   52.642450] c0        [<ffffffc00066efd0>] ffs_data_closed+0xac/0x12c
      [   52.642454] c0        [<ffffffc00066f070>] ffs_ep0_release+0x20/0x2c
      [   52.642460] c0        [<ffffffc00023dbe4>] __fput+0xb0/0x1f4
      [   52.642466] c0        [<ffffffc00023dd9c>] ____fput+0x20/0x2c
      [   52.642473] c0        [<ffffffc0000ee944>] task_work_run+0xb4/0xe8
      [   52.642482] c0        [<ffffffc0000cd45c>] do_exit+0x360/0xb9c
      [   52.642487] c0        [<ffffffc0000cf228>] do_group_exit+0x4c/0xb0
      [   52.642494] c0        [<ffffffc0000dd3c8>] get_signal+0x380/0x89c
      [   52.642501] c0        [<ffffffc00008a8f0>] do_signal+0x154/0x518
      [   52.642507] c0        [<ffffffc00008af00>] do_notify_resume+0x70/0x78
      [   52.642512] c0        [<ffffffc000085ee8>] 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: [<ffffffc00066b244>]
      		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 [<ffffffc00008b430>] dump_backtrace+0x0/0x170
      [   52.642577] c1 [<ffffffc00008b5c0>] show_stack+0x20/0x28
      [   52.642583] c1 [<ffffffc000422694>] dump_stack+0xa8/0xe0
      [   52.642587] c1 [<ffffffc00011e548>] print_circular_bug+0x1fc/0x2e4
      [   52.642591] c1 [<ffffffc000123454>] __lock_acquire+0x2138/0x2238
      [   52.642595] c1 [<ffffffc000123b54>] lock_acquire+0xe4/0x298
      [   52.642599] c1 [<ffffffc000aaf6e8>] mutex_lock_nested+0x7c/0x3cc
      [   52.642604] c1 [<ffffffc00065aeec>] usb_gadget_unregister_driver+0x3c/0xc8
      [   52.642608] c1 [<ffffffc00065995c>] unregister_gadget_item+0x28/0x44
      [   52.642613] c1 [<ffffffc00066b34c>] ffs_data_clear+0x138/0x140
      [   52.642618] c1 [<ffffffc00066b374>] ffs_data_reset+0x20/0x6c
      [   52.642621] c1 [<ffffffc00066efd0>] ffs_data_closed+0xac/0x12c
      [   52.642625] c1 [<ffffffc00066f070>] ffs_ep0_release+0x20/0x2c
      [   52.642629] c1 [<ffffffc00023dbe4>] __fput+0xb0/0x1f4
      [   52.642633] c1 [<ffffffc00023dd9c>] ____fput+0x20/0x2c
      [   52.642636] c1 [<ffffffc0000ee944>] task_work_run+0xb4/0xe8
      [   52.642640] c1 [<ffffffc0000cd45c>] do_exit+0x360/0xb9c
      [   52.642644] c1 [<ffffffc0000cf228>] do_group_exit+0x4c/0xb0
      [   52.642647] c1 [<ffffffc0000dd3c8>] get_signal+0x380/0x89c
      [   52.642651] c1 [<ffffffc00008a8f0>] do_signal+0x154/0x518
      [   52.642656] c1 [<ffffffc00008af00>] do_notify_resume+0x70/0x78
      [   52.642659] c1 [<ffffffc000085ee8>] work_pending+0x1c/0x20
      Acked-by: default avatarMichal Nazarewicz <mina86@mina86.com>
      Signed-off-by: default avatarBaolin Wang <baolin.wang@linaro.org>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      b3ce3ce0
    • Janusz Dziedzic's avatar
      usb: dwc3: skip interrupt when ep disabled · d7fd41c6
      Janusz Dziedzic authored
      In case EP disabled pass only EPCPLT command
      to be handled. In other case we could hit
      Bug like below.
      
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000003
      IP:
      [<ffffffff81673428>] dwc3_thread_interrupt+0x11c8/0x1790
      
      while dep->endpoint.desc is NULL.
      Signed-off-by: default avatarJanusz Dziedzic <januszx.dziedzic@linux.intel.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      d7fd41c6
    • Greg Kroah-Hartman's avatar
      usb: gadgetfs: restrict upper bound on device configuration size · 0994b0a2
      Greg Kroah-Hartman authored
      Andrey Konovalov reported that we were not properly checking the upper
      limit before of a device configuration size before calling
      memdup_user(), which could cause some problems.
      
      So set the upper limit to PAGE_SIZE * 4, which should be good enough for
      all devices.
      Reported-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      0994b0a2
    • Alan Stern's avatar
      USB: dummy-hcd: fix bug in stop_activity (handle ep0) · bcdbeb84
      Alan Stern authored
      The stop_activity() routine in dummy-hcd is supposed to unlink all
      active requests for every endpoint, among other things.  But it
      doesn't handle ep0.  As a result, fuzz testing can generate a WARNING
      like the following:
      
      WARNING: CPU: 0 PID: 4410 at drivers/usb/gadget/udc/dummy_hcd.c:672 dummy_free_request+0x153/0x170
      Modules linked in:
      CPU: 0 PID: 4410 Comm: syz-executor Not tainted 4.9.0-rc7+ #32
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
       ffff88006a64ed10 ffffffff81f96b8a ffffffff41b58ab3 1ffff1000d4c9d35
       ffffed000d4c9d2d ffff880065f8ac00 0000000041b58ab3 ffffffff8598b510
       ffffffff81f968f8 0000000041b58ab3 ffffffff859410e0 ffffffff813f0590
      Call Trace:
       [<     inline     >] __dump_stack lib/dump_stack.c:15
       [<ffffffff81f96b8a>] dump_stack+0x292/0x398 lib/dump_stack.c:51
       [<ffffffff812b808f>] __warn+0x19f/0x1e0 kernel/panic.c:550
       [<ffffffff812b831c>] warn_slowpath_null+0x2c/0x40 kernel/panic.c:585
       [<ffffffff830fcb13>] dummy_free_request+0x153/0x170 drivers/usb/gadget/udc/dummy_hcd.c:672
       [<ffffffff830ed1b0>] usb_ep_free_request+0xc0/0x420 drivers/usb/gadget/udc/core.c:195
       [<ffffffff83225031>] gadgetfs_unbind+0x131/0x190 drivers/usb/gadget/legacy/inode.c:1612
       [<ffffffff830ebd8f>] usb_gadget_remove_driver+0x10f/0x2b0 drivers/usb/gadget/udc/core.c:1228
       [<ffffffff830ec084>] usb_gadget_unregister_driver+0x154/0x240 drivers/usb/gadget/udc/core.c:1357
      
      This patch fixes the problem by iterating over all the endpoints in
      the driver's ep array instead of iterating over the gadget's ep_list,
      which explicitly leaves out ep0.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Reported-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      CC: <stable@vger.kernel.org>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      bcdbeb84
    • Vincent Pelletier's avatar
      usb: gadget: f_fs: Fix ExtCompat descriptor validation · 354bc45b
      Vincent Pelletier authored
      Reserved1 is documented as expected to be set to 0, but this test fails
      when it it set to 0. Reverse the condition.
      Signed-off-by: default avatarVincent Pelletier <plr.vincent@gmail.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      354bc45b
    • Vincent Pelletier's avatar
      usb: gadget: f_fs: Document eventfd effect on descriptor format. · 96a420d2
      Vincent Pelletier authored
      When FUNCTIONFS_EVENTFD flag is set, __ffs_data_got_descs reads a 32bits,
      little-endian value right after the fixed structure header, and passes it
      to eventfd_ctx_fdget. Document this.
      
      Also, rephrase a comment to be affirmative about the role of string
      descriptor at index 0. Ref: USB 2.0 spec paragraph "9.6.7 String", and
      also checked to still be current in USB 3.0 spec paragraph "9.6.9 String".
      Signed-off-by: default avatarVincent Pelletier <plr.vincent@gmail.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      96a420d2
    • Krzysztof Opasiak's avatar
      usb: gadget: composite: Test get_alt() presence instead of set_alt() · 7e4da3fc
      Krzysztof Opasiak authored
      By convention (according to doc) if function does not provide
      get_alt() callback composite framework should assume that it has only
      altsetting 0 and should respond with error if host tries to set
      other one.
      
      After commit dd4dff8b ("USB: composite: Fix bug: should test
      set_alt function pointer before use it")
      we started checking set_alt() callback instead of get_alt().
      This check is useless as we check if set_alt() is set inside
      usb_add_function() and fail if it's NULL.
      
      Let's fix this check and move comment about why we check the get
      method instead of set a little bit closer to prevent future false
      fixes.
      
      Fixes: dd4dff8b ("USB: composite: Fix bug: should test set_alt function pointer before use it")
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarKrzysztof Opasiak <k.opasiak@samsung.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      7e4da3fc
    • Hans de Goede's avatar
      usb: dwc3: pci: Fix dr_mode misspelling · 51c1685d
      Hans de Goede authored
      usb_get_dr_mode() expects the device-property to be spelled
      "dr_mode" not "dr-mode".
      
      Spelling it properly fixes the following warning showing up in dmesg:
      [ 8704.500545] dwc3 dwc3.2.auto: Configuration mismatch. dr_mode forced to gadget
      
      Signed-off-by: Hans de Goede <hdegoede@redhat.com
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      51c1685d
    • Felipe Balbi's avatar
      usb: dwc3: core: avoid Overflow events · e71d363d
      Felipe Balbi authored
      Now that we're handling so many transfers at a time
      and for some dwc3 revisions LPM events *must* be
      enabled, we can fall into a situation where too many
      events fire and we start receiving Overflow events.
      
      Let's do what XHCI does and allocate a full page for
      the Event Ring, this will avoid any future issues.
      
      Cc: <stable@vger.kernel.org> # v4.9
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      e71d363d
    • Felipe Balbi's avatar
      usb: dwc3: gadget: always unmap EP0 requests · d6214592
      Felipe Balbi authored
      commit 0416e494 ("usb: dwc3: ep0: correct cache
      sync issue in case of ep0_bounced") introduced a bug
      where we would leak DMA resources which would cause
      us to starve the system of them resulting in failing
      DMA transfers.
      
      Fix the bug by making sure that we always unmap EP0
      requests since those are *always* mapped.
      
      Fixes: 0416e494 ("usb: dwc3: ep0: correct cache
      	sync issue in case of ep0_bounced")
      Cc: <stable@vger.kernel.org>
      Tested-by: default avatarTomasz Medrek <tomaszx.medrek@intel.com>
      Reported-by: default avatarJanusz Dziedzic <januszx.dziedzic@linux.intel.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      d6214592
    • Felipe Balbi's avatar
      usb: dwc3: ep0: explicitly call dwc3_ep0_prepare_one_trb() · 19ec3123
      Felipe Balbi authored
      Let's call dwc3_ep0_prepare_one_trb() explicitly
      because there are occasions where we will need more
      than one TRB to handle an EP0 transfer.
      
      A follow-up patch will fix one bug related to
      multiple-TRB Data Phases when it comes to
      mapping/unmapping requests for DMA.
      
      Cc: <stable@vger.kernel.org>
      Reported-by: default avatarJanusz Dziedzic <januszx.dziedzic@linux.intel.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      19ec3123
    • Felipe Balbi's avatar
      usb: dwc3: ep0: add dwc3_ep0_prepare_one_trb() · 7931ec86
      Felipe Balbi authored
      For now this is just a cleanup patch, no functional
      changes. We will be using the new function to fix a
      bug introduced long ago by commit 0416e494
      ("usb: dwc3: ep0: correct cache sync issue in case
      of ep0_bounced") and further worsened by commit
      c0bd5456 ("usb: dwc3: ep0: handle non maxpacket
      aligned transfers > 512")
      
      Cc: <stable@vger.kernel.org>
      Reported-by: default avatarJanusz Dziedzic <januszx.dziedzic@linux.intel.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      7931ec86
    • Stefan Wahren's avatar
      usb: dwc2: gadget: fix default value for gadget-dma-desc · efc95b2c
      Stefan Wahren authored
      The current default for gadget DMA descriptor results on bcm2835 in a
      unnecessary error message:
      
        Invalid value 1 for param gadget-dma-desc
      
      So fix this by using hw->dma_desc_enable as default value.
      
      Fixes: dec4b556 ("usb: dwc2: gadget: Add descriptor DMA parameter")
      Acked-by: default avatarJohn Youn <johnyoun@synopsys.com>
      Signed-off-by: default avatarStefan Wahren <stefan.wahren@i2se.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      efc95b2c
    • Stefan Wahren's avatar
      usb: dwc2: fix default value for DMA support · 6118d064
      Stefan Wahren authored
      The current defaults for DMA results on a non-DMA platform in a unnecessary
      error message:
      
        Invalid value 0 for param gadget-dma
      
      So fix this by using dma_capable as default value.
      
      Fixes: 9962b62f ("usb: dwc2: Deprecate g-use-dma binding")
      Acked-by: default avatarJohn Youn <johnyoun@synopsys.com>
      Signed-off-by: default avatarStefan Wahren <stefan.wahren@i2se.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      6118d064
    • Stefan Wahren's avatar
      usb: dwc2: fix dwc2_get_device_property for u8 and u16 · de02238d
      Stefan Wahren authored
      According to the Devicetree ePAPR [1] the datatypes u8 and u16 are
      not defined. So using device_property_read_u16() would result in
      a partial read of a 32-bit big-endian integer which is not intended.
      So we better read the complete 32-bit value. This fixes a regression
      on bcm2835 where the values for g-rx-fifo-size and g-np-tx-fifo-size
      always read as zero:
      
        Invalid value 0 for param g-rx-fifo-size
        Invalid value 0 for param g-np-tx-fifo-size
      
      [1] - http://elinux.org/images/c/cf/Power_ePAPR_APPROVED_v1.1.pdf
      
      Fixes: 05ee799f ("usb: dwc2: Move gadget settings into core_params")
      Acked-by: default avatarJohn Youn <johnyoun@synopsys.com>
      Signed-off-by: default avatarStefan Wahren <stefan.wahren@i2se.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      de02238d
    • Stefan Wahren's avatar
      usb: dwc2: Do not set host parameter in peripheral mode · f3419735
      Stefan Wahren authored
      Since commit "usb: dwc2: Improve handling of host and device hwparams" the
      host mode specific hardware parameter aren't initialized in peripheral mode
      from the register settings anymore. So we better do not set them in this
      case which avoids the following warnings on bcm2835:
      
        256 invalid for host_nperio_tx_fifo_size. Check HW configuration.
        512 invalid for host_perio_tx_fifo_size. Check HW configuration.
      
      Fixes: 55e1040e ("usb: dwc2: Improve handling of host and device hwparams")
      Acked-by: default avatarJohn Youn <johnyoun@synopsys.com>
      Signed-off-by: default avatarStefan Wahren <stefan.wahren@i2se.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      f3419735
  2. 01 Jan, 2017 2 commits
    • Linus Torvalds's avatar
      Linux 4.10-rc2 · 0c744ea4
      Linus Torvalds authored
      0c744ea4
    • Linus Torvalds's avatar
      Merge branch 'libnvdimm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm · 4759d386
      Linus Torvalds authored
      Pull DAX updates from Dan Williams:
       "The completion of Jan's DAX work for 4.10.
      
        As I mentioned in the libnvdimm-for-4.10 pull request, these are some
        final fixes for the DAX dirty-cacheline-tracking invalidation work
        that was merged through the -mm, ext4, and xfs trees in -rc1. These
        patches were prepared prior to the merge window, but we waited for
        4.10-rc1 to have a stable merge base after all the prerequisites were
        merged.
      
        Quoting Jan on the overall changes in these patches:
      
           "So I'd like all these 6 patches to go for rc2. The first three
            patches fix invalidation of exceptional DAX entries (a bug which
            is there for a long time) - without these patches data loss can
            occur on power failure even though user called fsync(2). The other
            three patches change locking of DAX faults so that ->iomap_begin()
            is called in a more relaxed locking context and we are safe to
            start a transaction there for ext4"
      
        These have received a build success notification from the kbuild
        robot, and pass the latest libnvdimm unit tests. There have not been
        any -next releases since -rc1, so they have not appeared there"
      
      * 'libnvdimm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm:
        ext4: Simplify DAX fault path
        dax: Call ->iomap_begin without entry lock during dax fault
        dax: Finish fault completely when loading holes
        dax: Avoid page invalidation races and unnecessary radix tree traversals
        mm: Invalidate DAX radix tree entries only if appropriate
        ext2: Return BH_New buffers for zeroed blocks
      4759d386
  3. 30 Dec, 2016 2 commits
  4. 29 Dec, 2016 2 commits
    • Olof Johansson's avatar
      mm/filemap: fix parameters to test_bit() · 98473f9f
      Olof Johansson authored
       mm/filemap.c: In function 'clear_bit_unlock_is_negative_byte':
        mm/filemap.c:933:9: error: too few arguments to function 'test_bit'
          return test_bit(PG_waiters);
               ^~~~~~~~
      
      Fixes: b91e1302 ('mm: optimize PageWaiters bit use for unlock_page()')
      Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
      Brown-paper-bag-by: default avatarLinus Torvalds <dummy@duh.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      98473f9f
    • Linus Torvalds's avatar
      mm: optimize PageWaiters bit use for unlock_page() · b91e1302
      Linus Torvalds authored
      In commit 62906027 ("mm: add PageWaiters indicating tasks are
      waiting for a page bit") Nick Piggin made our page locking no longer
      unconditionally touch the hashed page waitqueue, which not only helps
      performance in general, but is particularly helpful on NUMA machines
      where the hashed wait queues can bounce around a lot.
      
      However, the "clear lock bit atomically and then test the waiters bit"
      sequence turns out to be much more expensive than it needs to be,
      because you get a nasty stall when trying to access the same word that
      just got updated atomically.
      
      On architectures where locking is done with LL/SC, this would be trivial
      to fix with a new primitive that clears one bit and tests another
      atomically, but that ends up not working on x86, where the only atomic
      operations that return the result end up being cmpxchg and xadd.  The
      atomic bit operations return the old value of the same bit we changed,
      not the value of an unrelated bit.
      
      On x86, we could put the lock bit in the high bit of the byte, and use
      "xadd" with that bit (where the overflow ends up not touching other
      bits), and look at the other bits of the result.  However, an even
      simpler model is to just use a regular atomic "and" to clear the lock
      bit, and then the sign bit in eflags will indicate the resulting state
      of the unrelated bit #7.
      
      So by moving the PageWaiters bit up to bit #7, we can atomically clear
      the lock bit and test the waiters bit on x86 too.  And architectures
      with LL/SC (which is all the usual RISC suspects), the particular bit
      doesn't matter, so they are fine with this approach too.
      
      This avoids the extra access to the same atomic word, and thus avoids
      the costly stall at page unlock time.
      
      The only downside is that the interface ends up being a bit odd and
      specialized: clear a bit in a byte, and test the sign bit.  Nick doesn't
      love the resulting name of the new primitive, but I'd rather make the
      name be descriptive and very clear about the limitation imposed by
      trying to work across all relevant architectures than make it be some
      generic thing that doesn't make the odd semantics explicit.
      
      So this introduces the new architecture primitive
      
          clear_bit_unlock_is_negative_byte();
      
      and adds the trivial implementation for x86.  We have a generic
      non-optimized fallback (that just does a "clear_bit()"+"test_bit(7)"
      combination) which can be overridden by any architecture that can do
      better.  According to Nick, Power has the same hickup x86 has, for
      example, but some other architectures may not even care.
      
      All these optimizations mean that my page locking stress-test (which is
      just executing a lot of small short-lived shell scripts: "make test" in
      the git source tree) no longer makes our page locking look horribly bad.
      Before all these optimizations, just the unlock_page() costs were just
      over 3% of all CPU overhead on "make test".  After this, it's down to
      0.66%, so just a quarter of the cost it used to be.
      
      (The difference on NUMA is bigger, but there this micro-optimization is
      likely less noticeable, since the big issue on NUMA was not the accesses
      to 'struct page', but the waitqueue accesses that were already removed
      by Nick's earlier commit).
      Acked-by: default avatarNick Piggin <npiggin@gmail.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Bob Peterson <rpeterso@redhat.com>
      Cc: Steven Whitehouse <swhiteho@redhat.com>
      Cc: Andrew Lutomirski <luto@kernel.org>
      Cc: Andreas Gruenbacher <agruenba@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Mel Gorman <mgorman@techsingularity.net>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b91e1302
  5. 28 Dec, 2016 2 commits
    • Linus Torvalds's avatar
      Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 · 2d706e79
      Linus Torvalds authored
      Pull crypto fix from Herbert Xu:
       "This fixes a hash corruption bug in the marvell driver"
      
      * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
        crypto: marvell - Copy IVDIG before launching partial DMA ahash requests
      2d706e79
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net · 8f18e4d0
      Linus Torvalds authored
      Pull networking fixes from David Miller:
      
       1) Various ipvlan fixes from Eric Dumazet and Mahesh Bandewar.
      
          The most important is to not assume the packet is RX just because
          the destination address matches that of the device. Such an
          assumption causes problems when an interface is put into loopback
          mode.
      
       2) If we retry when creating a new tc entry (because we dropped the
          RTNL mutex in order to load a module, for example) we end up with
          -EAGAIN and then loop trying to replay the request. But we didn't
          reset some state when looping back to the top like this, and if
          another thread meanwhile inserted the same tc entry we were trying
          to, we re-link it creating an enless loop in the tc chain. Fix from
          Daniel Borkmann.
      
       3) There are two different WRITE bits in the MDIO address register for
          the stmmac chip, depending upon the chip variant. Due to a bug we
          could set them both, fix from Hock Leong Kweh.
      
       4) Fix mlx4 bug in XDP_TX handling, from Tariq Toukan.
      
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net:
        net: stmmac: fix incorrect bit set in gmac4 mdio addr register
        r8169: add support for RTL8168 series add-on card.
        net: xdp: remove unused bfp_warn_invalid_xdp_buffer()
        openvswitch: upcall: Fix vlan handling.
        ipv4: Namespaceify tcp_tw_reuse knob
        net: korina: Fix NAPI versus resources freeing
        net, sched: fix soft lockup in tc_classify
        net/mlx4_en: Fix user prio field in XDP forward
        tipc: don't send FIN message from connectionless socket
        ipvlan: fix multicast processing
        ipvlan: fix various issues in ipvlan_process_multicast()
      8f18e4d0
  6. 27 Dec, 2016 14 commits