1. 29 Jun, 2017 21 commits
  2. 26 Jun, 2017 19 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.4.74 · 22da7ca8
      Greg Kroah-Hartman authored
      22da7ca8
    • Hugh Dickins's avatar
      mm: fix new crash in unmapped_area_topdown() · 1f2284fa
      Hugh Dickins authored
      commit f4cb767d upstream.
      
      Trinity gets kernel BUG at mm/mmap.c:1963! in about 3 minutes of
      mmap testing.  That's the VM_BUG_ON(gap_end < gap_start) at the
      end of unmapped_area_topdown().  Linus points out how MAP_FIXED
      (which does not have to respect our stack guard gap intentions)
      could result in gap_end below gap_start there.  Fix that, and
      the similar case in its alternative, unmapped_area().
      
      Fixes: 1be7107f ("mm: larger stack guard gap, between vmas")
      Reported-by: default avatarDave Jones <davej@codemonkey.org.uk>
      Debugged-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarHugh Dickins <hughd@google.com>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1f2284fa
    • Helge Deller's avatar
      Allow stack to grow up to address space limit · f41512c6
      Helge Deller authored
      commit bd726c90 upstream.
      
      Fix expand_upwards() on architectures with an upward-growing stack (parisc,
      metag and partly IA-64) to allow the stack to reliably grow exactly up to
      the address space limit given by TASK_SIZE.
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Acked-by: default avatarHugh Dickins <hughd@google.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f41512c6
    • Hugh Dickins's avatar
      mm: larger stack guard gap, between vmas · 4b359430
      Hugh Dickins authored
      commit 1be7107f upstream.
      
      Stack guard page is a useful feature to reduce a risk of stack smashing
      into a different mapping. We have been using a single page gap which
      is sufficient to prevent having stack adjacent to a different mapping.
      But this seems to be insufficient in the light of the stack usage in
      userspace. E.g. glibc uses as large as 64kB alloca() in many commonly
      used functions. Others use constructs liks gid_t buffer[NGROUPS_MAX]
      which is 256kB or stack strings with MAX_ARG_STRLEN.
      
      This will become especially dangerous for suid binaries and the default
      no limit for the stack size limit because those applications can be
      tricked to consume a large portion of the stack and a single glibc call
      could jump over the guard page. These attacks are not theoretical,
      unfortunatelly.
      
      Make those attacks less probable by increasing the stack guard gap
      to 1MB (on systems with 4k pages; but make it depend on the page size
      because systems with larger base pages might cap stack allocations in
      the PAGE_SIZE units) which should cover larger alloca() and VLA stack
      allocations. It is obviously not a full fix because the problem is
      somehow inherent, but it should reduce attack space a lot.
      
      One could argue that the gap size should be configurable from userspace,
      but that can be done later when somebody finds that the new 1MB is wrong
      for some special case applications.  For now, add a kernel command line
      option (stack_guard_gap) to specify the stack gap size (in page units).
      
      Implementation wise, first delete all the old code for stack guard page:
      because although we could get away with accounting one extra page in a
      stack vma, accounting a larger gap can break userspace - case in point,
      a program run with "ulimit -S -v 20000" failed when the 1MB gap was
      counted for RLIMIT_AS; similar problems could come with RLIMIT_MLOCK
      and strict non-overcommit mode.
      
      Instead of keeping gap inside the stack vma, maintain the stack guard
      gap as a gap between vmas: using vm_start_gap() in place of vm_start
      (or vm_end_gap() in place of vm_end if VM_GROWSUP) in just those few
      places which need to respect the gap - mainly arch_get_unmapped_area(),
      and and the vma tree's subtree_gap support for that.
      Original-patch-by: default avatarOleg Nesterov <oleg@redhat.com>
      Original-patch-by: default avatarMichal Hocko <mhocko@suse.com>
      Signed-off-by: default avatarHugh Dickins <hughd@google.com>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Tested-by: Helge Deller <deller@gmx.de> # parisc
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      [wt: backport to 4.11: adjust context]
      [wt: backport to 4.9: adjust context ; kernel doc was not in admin-guide]
      [wt: backport to 4.4: adjust context ; drop ppc hugetlb_radix changes]
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      [gkh: minor build fixes for 4.4]
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4b359430
    • Thomas Gleixner's avatar
      alarmtimer: Rate limit periodic intervals · 26605a06
      Thomas Gleixner authored
      commit ff86bf0c upstream.
      
      The alarmtimer code has another source of potentially rearming itself too
      fast. Interval timers with a very samll interval have a similar CPU hog
      effect as the previously fixed overflow issue.
      
      The reason is that alarmtimers do not implement the normal protection
      against this kind of problem which the other posix timer use:
      
        timer expires -> queue signal -> deliver signal -> rearm timer
      
      This scheme brings the rearming under scheduler control and prevents
      permanently firing timers which hog the CPU.
      
      Bringing this scheme to the alarm timer code is a major overhaul because it
      lacks all the necessary mechanisms completely.
      
      So for a quick fix limit the interval to one jiffie. This is not
      problematic in practice as alarmtimers are usually backed by an RTC for
      suspend which have 1 second resolution. It could be therefor argued that
      the resolution of this clock should be set to 1 second in general, but
      that's outside the scope of this fix.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Kostya Serebryany <kcc@google.com>
      Cc: syzkaller <syzkaller@googlegroups.com>
      Cc: John Stultz <john.stultz@linaro.org>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Link: http://lkml.kernel.org/r/20170530211655.896767100@linutronix.deSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      26605a06
    • Paul Burton's avatar
      MIPS: Fix bnezc/jialc return address calculation · c24159ad
      Paul Burton authored
      commit 1a73d931 upstream.
      
      The code handling the pop76 opcode (ie. bnezc & jialc instructions) in
      __compute_return_epc_for_insn() needs to set the value of $31 in the
      jialc case, which is encoded with rs = 0. However its check to
      differentiate bnezc (rs != 0) from jialc (rs = 0) was unfortunately
      backwards, meaning that if we emulate a bnezc instruction we clobber $31
      & if we emulate a jialc instruction it actually behaves like a jic
      instruction.
      
      Fix this by inverting the check of rs to match the way the instructions
      are actually encoded.
      Signed-off-by: default avatarPaul Burton <paul.burton@imgtec.com>
      Fixes: 28d6f93d ("MIPS: Emulate the new MIPS R6 BNEZC and JIALC instructions")
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/16178/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c24159ad
    • Shuah Khan's avatar
      usb: dwc3: exynos fix axius clock error path to do cleanup · 94695386
      Shuah Khan authored
      commit 8ae584d1 upstream.
      
      Axius clock error path returns without disabling clock and suspend clock.
      Fix it to disable them before returning error.
      Reviewed-by: default avatarJavier Martinez Canillas <javier@osg.samsung.com>
      Signed-off-by: default avatarShuah Khan <shuahkh@osg.samsung.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      94695386
    • Thomas Gleixner's avatar
      alarmtimer: Prevent overflow of relative timers · aac7fa21
      Thomas Gleixner authored
      commit f4781e76 upstream.
      
      Andrey reported a alartimer related RCU stall while fuzzing the kernel with
      syzkaller.
      
      The reason for this is an overflow in ktime_add() which brings the
      resulting time into negative space and causes immediate expiry of the
      timer. The following rearm with a small interval does not bring the timer
      back into positive space due to the same issue.
      
      This results in a permanent firing alarmtimer which hogs the CPU.
      
      Use ktime_add_safe() instead which detects the overflow and clamps the
      result to KTIME_SEC_MAX.
      Reported-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Kostya Serebryany <kcc@google.com>
      Cc: syzkaller <syzkaller@googlegroups.com>
      Cc: John Stultz <john.stultz@linaro.org>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Link: http://lkml.kernel.org/r/20170530211655.802921648@linutronix.deSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      aac7fa21
    • Heiner Kallweit's avatar
      genirq: Release resources in __setup_irq() error path · 4d4d501c
      Heiner Kallweit authored
      commit fa07ab72 upstream.
      
      In case __irq_set_trigger() fails the resources requested via
      irq_request_resources() are not released.
      
      Add the missing release call into the error handling path.
      
      Fixes: c1bacbae ("genirq: Provide irq_request/release_resources chip callbacks")
      Signed-off-by: default avatarHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/655538f5-cb20-a892-ff15-fbd2dd1fa4ec@gmail.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4d4d501c
    • Yu Zhao's avatar
      swap: cond_resched in swap_cgroup_prepare() · 6af90091
      Yu Zhao authored
      commit ef707629 upstream.
      
      I saw need_resched() warnings when swapping on large swapfile (TBs)
      because continuously allocating many pages in swap_cgroup_prepare() took
      too long.
      
      We already cond_resched when freeing page in swap_cgroup_swapoff().  Do
      the same for the page allocation.
      
      Link: http://lkml.kernel.org/r/20170604200109.17606-1-yuzhao@google.comSigned-off-by: default avatarYu Zhao <yuzhao@google.com>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Acked-by: default avatarVladimir Davydov <vdavydov.dev@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6af90091
    • James Morse's avatar
      mm/memory-failure.c: use compound_head() flags for huge pages · bfbd244c
      James Morse authored
      commit 7258ae5c upstream.
      
      memory_failure() chooses a recovery action function based on the page
      flags.  For huge pages it uses the tail page flags which don't have
      anything interesting set, resulting in:
      
      > Memory failure: 0x9be3b4: Unknown page state
      > Memory failure: 0x9be3b4: recovery action for unknown page: Failed
      
      Instead, save a copy of the head page's flags if this is a huge page,
      this means if there are no relevant flags for this tail page, we use the
      head pages flags instead.  This results in the me_huge_page() recovery
      action being called:
      
      > Memory failure: 0x9b7969: recovery action for huge page: Delayed
      
      For hugepages that have not yet been allocated, this allows the hugepage
      to be dequeued.
      
      Fixes: 524fca1e ("HWPOISON: fix misjudgement of page_action() for errors on mlocked pages")
      Link: http://lkml.kernel.org/r/20170524130204.21845-1-james.morse@arm.comSigned-off-by: default avatarJames Morse <james.morse@arm.com>
      Tested-by: default avatarPunit Agrawal <punit.agrawal@arm.com>
      Acked-by: default avatarPunit Agrawal <punit.agrawal@arm.com>
      Acked-by: default avatarNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bfbd244c
    • Alan Stern's avatar
      USB: gadgetfs, dummy-hcd, net2280: fix locking for callbacks · f5dc6175
      Alan Stern authored
      commit f16443a0 upstream.
      
      Using the syzkaller kernel fuzzer, Andrey Konovalov generated the
      following error in gadgetfs:
      
      > BUG: KASAN: use-after-free in __lock_acquire+0x3069/0x3690
      > kernel/locking/lockdep.c:3246
      > Read of size 8 at addr ffff88003a2bdaf8 by task kworker/3:1/903
      >
      > CPU: 3 PID: 903 Comm: kworker/3:1 Not tainted 4.12.0-rc4+ #35
      > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
      > Workqueue: usb_hub_wq hub_event
      > Call Trace:
      >  __dump_stack lib/dump_stack.c:16 [inline]
      >  dump_stack+0x292/0x395 lib/dump_stack.c:52
      >  print_address_description+0x78/0x280 mm/kasan/report.c:252
      >  kasan_report_error mm/kasan/report.c:351 [inline]
      >  kasan_report+0x230/0x340 mm/kasan/report.c:408
      >  __asan_report_load8_noabort+0x19/0x20 mm/kasan/report.c:429
      >  __lock_acquire+0x3069/0x3690 kernel/locking/lockdep.c:3246
      >  lock_acquire+0x22d/0x560 kernel/locking/lockdep.c:3855
      >  __raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
      >  _raw_spin_lock+0x2f/0x40 kernel/locking/spinlock.c:151
      >  spin_lock include/linux/spinlock.h:299 [inline]
      >  gadgetfs_suspend+0x89/0x130 drivers/usb/gadget/legacy/inode.c:1682
      >  set_link_state+0x88e/0xae0 drivers/usb/gadget/udc/dummy_hcd.c:455
      >  dummy_hub_control+0xd7e/0x1fb0 drivers/usb/gadget/udc/dummy_hcd.c:2074
      >  rh_call_control drivers/usb/core/hcd.c:689 [inline]
      >  rh_urb_enqueue drivers/usb/core/hcd.c:846 [inline]
      >  usb_hcd_submit_urb+0x92f/0x20b0 drivers/usb/core/hcd.c:1650
      >  usb_submit_urb+0x8b2/0x12c0 drivers/usb/core/urb.c:542
      >  usb_start_wait_urb+0x148/0x5b0 drivers/usb/core/message.c:56
      >  usb_internal_control_msg drivers/usb/core/message.c:100 [inline]
      >  usb_control_msg+0x341/0x4d0 drivers/usb/core/message.c:151
      >  usb_clear_port_feature+0x74/0xa0 drivers/usb/core/hub.c:412
      >  hub_port_disable+0x123/0x510 drivers/usb/core/hub.c:4177
      >  hub_port_init+0x1ed/0x2940 drivers/usb/core/hub.c:4648
      >  hub_port_connect drivers/usb/core/hub.c:4826 [inline]
      >  hub_port_connect_change drivers/usb/core/hub.c:4999 [inline]
      >  port_event drivers/usb/core/hub.c:5105 [inline]
      >  hub_event+0x1ae1/0x3d40 drivers/usb/core/hub.c:5185
      >  process_one_work+0xc08/0x1bd0 kernel/workqueue.c:2097
      >  process_scheduled_works kernel/workqueue.c:2157 [inline]
      >  worker_thread+0xb2b/0x1860 kernel/workqueue.c:2233
      >  kthread+0x363/0x440 kernel/kthread.c:231
      >  ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:424
      >
      > Allocated by task 9958:
      >  save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
      >  save_stack+0x43/0xd0 mm/kasan/kasan.c:513
      >  set_track mm/kasan/kasan.c:525 [inline]
      >  kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:617
      >  kmem_cache_alloc_trace+0x87/0x280 mm/slub.c:2745
      >  kmalloc include/linux/slab.h:492 [inline]
      >  kzalloc include/linux/slab.h:665 [inline]
      >  dev_new drivers/usb/gadget/legacy/inode.c:170 [inline]
      >  gadgetfs_fill_super+0x24f/0x540 drivers/usb/gadget/legacy/inode.c:1993
      >  mount_single+0xf6/0x160 fs/super.c:1192
      >  gadgetfs_mount+0x31/0x40 drivers/usb/gadget/legacy/inode.c:2019
      >  mount_fs+0x9c/0x2d0 fs/super.c:1223
      >  vfs_kern_mount.part.25+0xcb/0x490 fs/namespace.c:976
      >  vfs_kern_mount fs/namespace.c:2509 [inline]
      >  do_new_mount fs/namespace.c:2512 [inline]
      >  do_mount+0x41b/0x2d90 fs/namespace.c:2834
      >  SYSC_mount fs/namespace.c:3050 [inline]
      >  SyS_mount+0xb0/0x120 fs/namespace.c:3027
      >  entry_SYSCALL_64_fastpath+0x1f/0xbe
      >
      > Freed by task 9960:
      >  save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
      >  save_stack+0x43/0xd0 mm/kasan/kasan.c:513
      >  set_track mm/kasan/kasan.c:525 [inline]
      >  kasan_slab_free+0x72/0xc0 mm/kasan/kasan.c:590
      >  slab_free_hook mm/slub.c:1357 [inline]
      >  slab_free_freelist_hook mm/slub.c:1379 [inline]
      >  slab_free mm/slub.c:2961 [inline]
      >  kfree+0xed/0x2b0 mm/slub.c:3882
      >  put_dev+0x124/0x160 drivers/usb/gadget/legacy/inode.c:163
      >  gadgetfs_kill_sb+0x33/0x60 drivers/usb/gadget/legacy/inode.c:2027
      >  deactivate_locked_super+0x8d/0xd0 fs/super.c:309
      >  deactivate_super+0x21e/0x310 fs/super.c:340
      >  cleanup_mnt+0xb7/0x150 fs/namespace.c:1112
      >  __cleanup_mnt+0x1b/0x20 fs/namespace.c:1119
      >  task_work_run+0x1a0/0x280 kernel/task_work.c:116
      >  exit_task_work include/linux/task_work.h:21 [inline]
      >  do_exit+0x18a8/0x2820 kernel/exit.c:878
      >  do_group_exit+0x14e/0x420 kernel/exit.c:982
      >  get_signal+0x784/0x1780 kernel/signal.c:2318
      >  do_signal+0xd7/0x2130 arch/x86/kernel/signal.c:808
      >  exit_to_usermode_loop+0x1ac/0x240 arch/x86/entry/common.c:157
      >  prepare_exit_to_usermode arch/x86/entry/common.c:194 [inline]
      >  syscall_return_slowpath+0x3ba/0x410 arch/x86/entry/common.c:263
      >  entry_SYSCALL_64_fastpath+0xbc/0xbe
      >
      > The buggy address belongs to the object at ffff88003a2bdae0
      >  which belongs to the cache kmalloc-1024 of size 1024
      > The buggy address is located 24 bytes inside of
      >  1024-byte region [ffff88003a2bdae0, ffff88003a2bdee0)
      > The buggy address belongs to the page:
      > page:ffffea0000e8ae00 count:1 mapcount:0 mapping:          (null)
      > index:0x0 compound_mapcount: 0
      > flags: 0x100000000008100(slab|head)
      > raw: 0100000000008100 0000000000000000 0000000000000000 0000000100170017
      > raw: ffffea0000ed3020 ffffea0000f5f820 ffff88003e80efc0 0000000000000000
      > page dumped because: kasan: bad access detected
      >
      > Memory state around the buggy address:
      >  ffff88003a2bd980: fb fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      >  ffff88003a2bda00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      > >ffff88003a2bda80: fc fc fc fc fc fc fc fc fc fc fc fc fb fb fb fb
      >                                                                 ^
      >  ffff88003a2bdb00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      >  ffff88003a2bdb80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      > ==================================================================
      
      What this means is that the gadgetfs_suspend() routine was trying to
      access dev->lock after it had been deallocated.  The root cause is a
      race in the dummy_hcd driver; the dummy_udc_stop() routine can race
      with the rest of the driver because it contains no locking.  And even
      when proper locking is added, it can still race with the
      set_link_state() function because that function incorrectly drops the
      private spinlock before invoking any gadget driver callbacks.
      
      The result of this race, as seen above, is that set_link_state() can
      invoke a callback in gadgetfs even after gadgetfs has been unbound
      from dummy_hcd's UDC and its private data structures have been
      deallocated.
      
      include/linux/usb/gadget.h documents that the ->reset, ->disconnect,
      ->suspend, and ->resume callbacks may be invoked in interrupt context.
      In general this is necessary, to prevent races with gadget driver
      removal.  This patch fixes dummy_hcd to retain the spinlock across
      these calls, and it adds a spinlock acquisition to dummy_udc_stop() to
      prevent the race.
      
      The net2280 driver makes the same mistake of dropping the private
      spinlock for its ->disconnect and ->reset callback invocations.  The
      patch fixes it too.
      
      Lastly, since gadgetfs_suspend() may be invoked in interrupt context,
      it cannot assume that interrupts are enabled when it runs.  It must
      use spin_lock_irqsave() instead of spin_lock_irq().  The patch fixes
      that bug as well.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Reported-and-tested-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Acked-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f5dc6175
    • Corentin Labbe's avatar
      usb: xhci: ASMedia ASM1042A chipset need shorts TX quirk · 89c15994
      Corentin Labbe authored
      commit d2f48f05 upstream.
      
      When plugging an USB webcam I see the following message:
      [106385.615559] xhci_hcd 0000:04:00.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk?
      [106390.583860] handle_tx_event: 913 callbacks suppressed
      
      With this patch applied, I get no more printing of this message.
      Signed-off-by: default avatarCorentin Labbe <clabbe.montjoie@gmail.com>
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      89c15994
    • Dan Carpenter's avatar
      drivers/misc/c2port/c2port-duramar2150.c: checking for NULL instead of IS_ERR() · 5efd37fe
      Dan Carpenter authored
      commit 8128a31e upstream.
      
      c2port_device_register() never returns NULL, it uses error pointers.
      
      Link: http://lkml.kernel.org/r/20170412083321.GC3250@mwanda
      Fixes: 65131cd5 ("c2port: add c2port support for Eurotech Duramar 2150")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Acked-by: default avatarRodolfo Giometti <giometti@linux.it>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5efd37fe
    • Chris Brandt's avatar
      usb: r8a66597-hcd: decrease timeout · ab29b21a
      Chris Brandt authored
      commit dd14a3e9 upstream.
      
      The timeout for BULK packets was 300ms which is a long time if other
      endpoints or devices are waiting for their turn. Changing it to 50ms
      greatly increased the overall performance for multi-endpoint devices.
      
      Fixes: 5d304358 ("usb: r8a66597-hcd: host controller driver for R8A6659")
      Signed-off-by: default avatarChris Brandt <chris.brandt@renesas.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ab29b21a
    • Chris Brandt's avatar
      usb: r8a66597-hcd: select a different endpoint on timeout · 4c7a6dd2
      Chris Brandt authored
      commit 1f873d85 upstream.
      
      If multiple endpoints on a single device have pending IN URBs and one
      endpoint times out due to NAKs (perfectly legal), select a different
      endpoint URB to try.
      The existing code only checked to see another device address has pending
      URBs and ignores other IN endpoints on the current device address. This
      leads to endpoints never getting serviced if one endpoint is using NAK as
      a flow control method.
      
      Fixes: 5d304358 ("usb: r8a66597-hcd: host controller driver for R8A6659")
      Signed-off-by: default avatarChris Brandt <chris.brandt@renesas.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4c7a6dd2
    • Johan Hovold's avatar
      USB: gadget: dummy_hcd: fix hub-descriptor removable fields · 42c8b4b5
      Johan Hovold authored
      commit d81182ce upstream.
      
      Flag the first and only port as removable while also leaving the
      remaining bits (including the reserved bit zero) unset in accordance
      with the specifications:
      
      	"Within a byte, if no port exists for a given location, the bit
      	field representing the port characteristics shall be 0."
      
      Also add a comment marking the legacy PortPwrCtrlMask field.
      
      Fixes: 1cd8fd28 ("usb: gadget: dummy_hcd: add SuperSpeed support")
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Cc: Tatyana Brokhman <tlinder@codeaurora.org>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      42c8b4b5
    • Arnd Bergmann's avatar
      pvrusb2: reduce stack usage pvr2_eeprom_analyze() · dc6ecba3
      Arnd Bergmann authored
      commit 6830733d upstream.
      
      The driver uses a relatively large data structure on the stack, which
      showed up on my radar as we get a warning with the "latent entropy"
      GCC plugin:
      
      drivers/media/usb/pvrusb2/pvrusb2-eeprom.c:153:1: error: the frame size of 1376 bytes is larger than 1152 bytes [-Werror=frame-larger-than=]
      
      The warning is usually hidden as we raise the warning limit to 2048
      when the plugin is enabled, but I'd like to lower that again in the
      future, and making this function smaller helps to do that without
      build regressions.
      
      Further analysis shows that putting an 'i2c_client' structure on
      the stack is not really supported, as the embedded 'struct device'
      is not initialized here, and we are only saved by the fact that
      the function that is called here does not use the pointer at all.
      
      Fixes: d855497e ("V4L/DVB (4228a): pvrusb2 to kernel 2.6.18")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dc6ecba3
    • Anton Bondarenko's avatar
      usb: core: fix potential memory leak in error path during hcd creation · e33e866d
      Anton Bondarenko authored
      commit 1a744d2e upstream.
      
      Free memory allocated for address0_mutex if allocation of bandwidth_mutex
      failed.
      
      Fixes: feb26ac3 ("usb: core: hub: hub_port_init lock controller instead of bus")
      Signed-off-by: default avatarAnton Bondarenko <anton.bondarenko.sama@gmail.com>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e33e866d