1. 27 Jul, 2016 19 commits
    • Sergei Shtylyov's avatar
      of: irq: fix of_irq_get[_byname]() kernel-doc · c5f2e833
      Sergei Shtylyov authored
      commit 39935466 upstream.
      
      The kernel-doc for the of_irq_get[_byname]()  is clearly inadequate in
      describing the return values -- of_irq_get_byname() is documented better
      than of_irq_get() but it  still doesn't mention that 0 is returned iff
      irq_create_of_mapping() fails (it doesn't return an error code in this
      case). Document all possible return value variants, making the writing
      of the word "IRQ" consistent, while at it...
      
      Fixes: 9ec36caf ("of/irq: do irq resolution in platform_get_irq")
      Fixes: ad69674e ("of/irq: do irq resolution in platform_get_irq_byname()")
      Signed-off-by: default avatarSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Signed-off-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c5f2e833
    • Wolfram Sang's avatar
      of: fix autoloading due to broken modalias with no 'compatible' · 6d58954b
      Wolfram Sang authored
      commit b3c0a4da upstream.
      
      Because of an improper dereference, a stray 'C' character was output to
      the modalias when no 'compatible' was specified. This is the case for
      some old PowerMac drivers which only set the 'name' property. Fix it to
      let them match again.
      Reported-by: default avatarMathieu Malaterre <malat@debian.org>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      Tested-by: default avatarMathieu Malaterre <malat@debian.org>
      Cc: Philipp Zabel <p.zabel@pengutronix.de>
      Cc: Andreas Schwab <schwab@linux-m68k.org>
      Fixes: 6543becf ("mod/file2alias: make modalias generation safe for cross compiling")
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6d58954b
    • Eric W. Biederman's avatar
      mnt: If fs_fully_visible fails call put_filesystem. · a400a793
      Eric W. Biederman authored
      commit 97c1df3e upstream.
      
      Add this trivial missing error handling.
      
      Fixes: 1b852bce ("mnt: Refactor the logic for mounting sysfs and proc in a user namespace")
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a400a793
    • Eric W. Biederman's avatar
      mnt: Account for MS_RDONLY in fs_fully_visible · 6256d2f5
      Eric W. Biederman authored
      commit 695e9df0 upstream.
      
      In rare cases it is possible for s_flags & MS_RDONLY to be set but
      MNT_READONLY to be clear.  This starting combination can cause
      fs_fully_visible to fail to ensure that the new mount is readonly.
      Therefore force MNT_LOCK_READONLY in the new mount if MS_RDONLY
      is set on the source filesystem of the mount.
      
      In general both MS_RDONLY and MNT_READONLY are set at the same for
      mounts so I don't expect any programs to care.  Nor do I expect
      MS_RDONLY to be set on proc or sysfs in the initial user namespace,
      which further decreases the likelyhood of problems.
      
      Which means this change should only affect system configurations by
      paranoid sysadmins who should welcome the additional protection
      as it keeps people from wriggling out of their policies.
      
      Fixes: 8c6cf9cc ("mnt: Modify fs_fully_visible to deal with locked ro nodev and atime")
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6256d2f5
    • Eric W. Biederman's avatar
      mnt: fs_fully_visible test the proper mount for MNT_LOCKED · 57eb6e3d
      Eric W. Biederman authored
      commit d71ed6c9 upstream.
      
      MNT_LOCKED implies on a child mount implies the child is locked to the
      parent.  So while looping through the children the children should be
      tested (not their parent).
      
      Typically an unshare of a mount namespace locks all mounts together
      making both the parent and the slave as locked but there are a few
      corner cases where other things work.
      
      Fixes: ceeb0e5d ("vfs: Ignore unlocked mounts in fs_fully_visible")
      Reported-by: default avatarSeth Forshee <seth.forshee@canonical.com>
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      57eb6e3d
    • Oscar's avatar
      usb: common: otg-fsm: add license to usb-otg-fsm · 67799eb4
      Oscar authored
      commit ea1d39a3 upstream.
      
      Fix warning about tainted kernel because usb-otg-fsm has no license.
      WARNING: with this patch usb-otg-fsm module can be loaded
      but then the kernel will hang. Tested with a udoo quad board.
      Signed-off-by: default avatarOscar <oscar@naiandei.net>
      Signed-off-by: default avatarPeter Chen <peter.chen@nxp.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      67799eb4
    • Alan Stern's avatar
      USB: EHCI: declare hostpc register as zero-length array · 7577b854
      Alan Stern authored
      commit 7e8b3dfe upstream.
      
      The HOSTPC extension registers found in some EHCI implementations form
      a variable-length array, with one element for each port.  Therefore
      the hostpc field in struct ehci_regs should be declared as a
      zero-length array, not a single-element array.
      
      This fixes a problem reported by UBSAN.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Reported-by: default avatarWilfried Klaebe <linux-kernel@lebenslange-mailadresse.de>
      Tested-by: default avatarWilfried Klaebe <linux-kernel@lebenslange-mailadresse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7577b854
    • Arnd Bergmann's avatar
      usb: dwc2: fix regression on big-endian PowerPC/ARM systems · 7b74d56f
      Arnd Bergmann authored
      commit 23e34392 upstream.
      
      A patch that went into Linux-4.4 to fix big-endian mode on a Lantiq
      MIPS system unfortunately broke big-endian operation on PowerPC
      APM82181 as reported by Christian Lamparter, and likely other
      systems.
      
      It actually introduced multiple issues:
      
      - it broke big-endian ARM kernels: any machine that was working
        correctly with a little-endian kernel is no longer using byteswaps
        on big-endian kernels, which clearly breaks them.
      - On PowerPC the same thing must be true: if it was working before,
        using big-endian kernels is now broken. Unlike ARM, 32-bit PowerPC
        usually uses big-endian kernels, so they are likely all broken.
      - The barrier for dwc2_writel is on the wrong side of the __raw_writel(),
        so the MMIO no longer synchronizes with DMA operations.
      - On architectures that require specific CPU instructions for MMIO
        access, using the __raw_ variant may turn this into a pointer
        dereference that does not have the same effect as the readl/writel.
      
      This patch is a simple revert for all architectures other than MIPS,
      in the hope that we can more easily backport it to fix the regression
      on PowerPC and ARM systems without breaking the Lantiq system again.
      
      We should follow this up with a more elaborate change to add runtime
      detection of endianness, to make sure it also works on all other
      combinations of architectures and implementations of the usb-dwc2
      device. That patch however will be fairly large and not appropriate
      for backports to stable kernels.
      
      Felipe suggested a different approach, using an endianness switching
      register to always put the device into LE mode, but unfortunately
      the dwc2 hardware does not provide a generic way to do that. Also,
      I see no practical way of addressing the problem more generally by
      patching architecture specific code on MIPS.
      
      Fixes: 95c8bc36 ("usb: dwc2: Use platform endianness when accessing registers")
      Acked-by: default avatarJohn Youn <johnyoun@synopsys.com>
      Tested-by: default avatarChristian Lamparter <chunkeey@googlemail.com>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7b74d56f
    • Cyril Bur's avatar
      powerpc/tm: Always reclaim in start_thread() for exec() class syscalls · 5a35d2f9
      Cyril Bur authored
      commit 8e96a87c upstream.
      
      Userspace can quite legitimately perform an exec() syscall with a
      suspended transaction. exec() does not return to the old process, rather
      it load a new one and starts that, the expectation therefore is that the
      new process starts not in a transaction. Currently exec() is not treated
      any differently to any other syscall which creates problems.
      
      Firstly it could allow a new process to start with a suspended
      transaction for a binary that no longer exists. This means that the
      checkpointed state won't be valid and if the suspended transaction were
      ever to be resumed and subsequently aborted (a possibility which is
      exceedingly likely as exec()ing will likely doom the transaction) the
      new process will jump to invalid state.
      
      Secondly the incorrect attempt to keep the transactional state while
      still zeroing state for the new process creates at least two TM Bad
      Things. The first triggers on the rfid to return to userspace as
      start_thread() has given the new process a 'clean' MSR but the suspend
      will still be set in the hardware MSR. The second TM Bad Thing triggers
      in __switch_to() as the processor is still transactionally suspended but
      __switch_to() wants to zero the TM sprs for the new process.
      
      This is an example of the outcome of calling exec() with a suspended
      transaction. Note the first 700 is likely the first TM bad thing
      decsribed earlier only the kernel can't report it as we've loaded
      userspace registers. c000000000009980 is the rfid in
      fast_exception_return()
      
        Bad kernel stack pointer 3fffcfa1a370 at c000000000009980
        Oops: Bad kernel stack pointer, sig: 6 [#1]
        CPU: 0 PID: 2006 Comm: tm-execed Not tainted
        NIP: c000000000009980 LR: 0000000000000000 CTR: 0000000000000000
        REGS: c00000003ffefd40 TRAP: 0700   Not tainted
        MSR: 8000000300201031 <SF,ME,IR,DR,LE,TM[SE]>  CR: 00000000  XER: 00000000
        CFAR: c0000000000098b4 SOFTE: 0
        PACATMSCRATCH: b00000010000d033
        GPR00: 0000000000000000 00003fffcfa1a370 0000000000000000 0000000000000000
        GPR04: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
        GPR08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
        GPR12: 00003fff966611c0 0000000000000000 0000000000000000 0000000000000000
        NIP [c000000000009980] fast_exception_return+0xb0/0xb8
        LR [0000000000000000]           (null)
        Call Trace:
        Instruction dump:
        f84d0278 e9a100d8 7c7b03a6 e84101a0 7c4ff120 e8410170 7c5a03a6 e8010070
        e8410080 e8610088 e8810090 e8210078 <4c000024> 48000000 e8610178 88ed023b
      
        Kernel BUG at c000000000043e80 [verbose debug info unavailable]
        Unexpected TM Bad Thing exception at c000000000043e80 (msr 0x201033)
        Oops: Unrecoverable exception, sig: 6 [#2]
        CPU: 0 PID: 2006 Comm: tm-execed Tainted: G      D
        task: c0000000fbea6d80 ti: c00000003ffec000 task.ti: c0000000fb7ec000
        NIP: c000000000043e80 LR: c000000000015a24 CTR: 0000000000000000
        REGS: c00000003ffef7e0 TRAP: 0700   Tainted: G      D
        MSR: 8000000300201033 <SF,ME,IR,DR,RI,LE,TM[SE]>  CR: 28002828  XER: 00000000
        CFAR: c000000000015a20 SOFTE: 0
        PACATMSCRATCH: b00000010000d033
        GPR00: 0000000000000000 c00000003ffefa60 c000000000db5500 c0000000fbead000
        GPR04: 8000000300001033 2222222222222222 2222222222222222 00000000ff160000
        GPR08: 0000000000000000 800000010000d033 c0000000fb7e3ea0 c00000000fe00004
        GPR12: 0000000000002200 c00000000fe00000 0000000000000000 0000000000000000
        GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
        GPR20: 0000000000000000 0000000000000000 c0000000fbea7410 00000000ff160000
        GPR24: c0000000ffe1f600 c0000000fbea8700 c0000000fbea8700 c0000000fbead000
        GPR28: c000000000e20198 c0000000fbea6d80 c0000000fbeab680 c0000000fbea6d80
        NIP [c000000000043e80] tm_restore_sprs+0xc/0x1c
        LR [c000000000015a24] __switch_to+0x1f4/0x420
        Call Trace:
        Instruction dump:
        7c800164 4e800020 7c0022a6 f80304a8 7c0222a6 f80304b0 7c0122a6 f80304b8
        4e800020 e80304a8 7c0023a6 e80304b0 <7c0223a6> e80304b8 7c0123a6 4e800020
      
      This fixes CVE-2016-5828.
      
      Fixes: bc2a9408 ("powerpc: Hook in new transactional memory code")
      Signed-off-by: default avatarCyril Bur <cyrilbur@gmail.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5a35d2f9
    • Michael Ellerman's avatar
      powerpc/pseries: Fix IBM_ARCH_VEC_NRCORES_OFFSET since POWER8NVL was added · 044af1b0
      Michael Ellerman authored
      commit 2c2a63e3 upstream.
      
      The recent commit 7cc85103 ("powerpc/pseries: Add POWER8NVL support
      to ibm,client-architecture-support call") added a new PVR mask & value
      to the start of the ibm_architecture_vec[] array.
      
      However it missed the fact that further down in the array, we hard code
      the offset of one of the fields, and then at boot use that value to
      patch the value in the array. This means every update to the array must
      also update the #define, ugh.
      
      This means that on pseries machines we will misreport to firmware the
      number of cores we support, by a factor of threads_per_core.
      
      Fix it for now by updating the #define.
      
      Fixes: 7cc85103 ("powerpc/pseries: Add POWER8NVL support to ibm,client-architecture-support call")
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      044af1b0
    • Gavin Shan's avatar
      powerpc/pseries: Fix PCI config address for DDW · 3abd809e
      Gavin Shan authored
      commit 8a934efe upstream.
      
      In commit 8445a87f "powerpc/iommu: Remove the dependency on EEH
      struct in DDW mechanism", the PE address was replaced with the PCI
      config address in order to remove dependency on EEH. According to PAPR
      spec, firmware (pHyp or QEMU) should accept "xxBBSSxx" format PCI config
      address, not "xxxxBBSS" provided by the patch. Note that "BB" is PCI bus
      number and "SS" is the combination of slot and function number.
      
      This fixes the PCI address passed to DDW RTAS calls.
      
      Fixes: 8445a87f ("powerpc/iommu: Remove the dependency on EEH struct in DDW mechanism")
      Reported-by: default avatarGuilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com>
      Signed-off-by: default avatarGavin Shan <gwshan@linux.vnet.ibm.com>
      Tested-by: default avatarGuilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3abd809e
    • Guilherme G. Piccoli's avatar
      powerpc/iommu: Remove the dependency on EEH struct in DDW mechanism · 6bd26f4c
      Guilherme G. Piccoli authored
      commit 8445a87f upstream.
      
      Commit 39baadbf ("powerpc/eeh: Remove eeh information from pci_dn")
      changed the pci_dn struct by removing its EEH-related members.
      As part of this clean-up, DDW mechanism was modified to read the device
      configuration address from eeh_dev struct.
      
      As a consequence, now if we disable EEH mechanism on kernel command-line
      for example, the DDW mechanism will fail, generating a kernel oops by
      dereferencing a NULL pointer (which turns to be the eeh_dev pointer).
      
      This patch just changes the configuration address calculation on DDW
      functions to a manual calculation based on pci_dn members instead of
      using eeh_dev-based address.
      
      No functional changes were made. This was tested on pSeries, both
      in PHyp and qemu guest.
      
      Fixes: 39baadbf ("powerpc/eeh: Remove eeh information from pci_dn")
      Reviewed-by: default avatarGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: default avatarGuilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6bd26f4c
    • Jason Gunthorpe's avatar
      IB/mlx4: Properly initialize GRH TClass and FlowLabel in AHs · 75012a88
      Jason Gunthorpe authored
      commit 8c5122e4 upstream.
      
      When this code was reworked for IBoE support the order of assignments
      for the sl_tclass_flowlabel got flipped around resulting in
      TClass & FlowLabel being permanently set to 0 in the packet headers.
      
      This breaks IB routers that rely on these headers, but only affects
      kernel users - libmlx4 does this properly for user space.
      
      Fixes: fa417f7b ("IB/mlx4: Add support for IBoE")
      Signed-off-by: default avatarJason Gunthorpe <jgunthorpe@obsidianresearch.com>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      75012a88
    • Bart Van Assche's avatar
      IB/cm: Fix a recently introduced locking bug · abb24acc
      Bart Van Assche authored
      commit 943f44d9 upstream.
      
      ib_cm_notify() can be called from interrupt context. Hence do not
      reenable interrupts unconditionally in cm_establish().
      
      This patch avoids that lockdep reports the following warning:
      
      WARNING: CPU: 0 PID: 23317 at kernel/locking/lockdep.c:2624 trace _hardirqs_on_caller+0x112/0x1b0
      DEBUG_LOCKS_WARN_ON(current->hardirq_context)
      Call Trace:
       <IRQ>  [<ffffffff812bd0e5>] dump_stack+0x67/0x92
       [<ffffffff81056f21>] __warn+0xc1/0xe0
       [<ffffffff81056f8a>] warn_slowpath_fmt+0x4a/0x50
       [<ffffffff810a5932>] trace_hardirqs_on_caller+0x112/0x1b0
       [<ffffffff810a59dd>] trace_hardirqs_on+0xd/0x10
       [<ffffffff815992c7>] _raw_spin_unlock_irq+0x27/0x40
       [<ffffffffa0382e9c>] ib_cm_notify+0x25c/0x290 [ib_cm]
       [<ffffffffa068fbc1>] srpt_qp_event+0xa1/0xf0 [ib_srpt]
       [<ffffffffa04efb97>] mlx4_ib_qp_event+0x67/0xd0 [mlx4_ib]
       [<ffffffffa034ec0a>] mlx4_qp_event+0x5a/0xc0 [mlx4_core]
       [<ffffffffa03365f8>] mlx4_eq_int+0x3d8/0xcf0 [mlx4_core]
       [<ffffffffa0336f9c>] mlx4_msi_x_interrupt+0xc/0x20 [mlx4_core]
       [<ffffffff810b0914>] handle_irq_event_percpu+0x64/0x100
       [<ffffffff810b09e4>] handle_irq_event+0x34/0x60
       [<ffffffff810b3a6a>] handle_edge_irq+0x6a/0x150
       [<ffffffff8101ad05>] handle_irq+0x15/0x20
       [<ffffffff8101a66c>] do_IRQ+0x5c/0x110
       [<ffffffff8159a2c9>] common_interrupt+0x89/0x89
       [<ffffffff81297a17>] blk_run_queue_async+0x37/0x40
       [<ffffffffa0163e53>] rq_completed+0x43/0x70 [dm_mod]
       [<ffffffffa0164896>] dm_softirq_done+0x176/0x280 [dm_mod]
       [<ffffffff812a26c2>] blk_done_softirq+0x52/0x90
       [<ffffffff8105bc1f>] __do_softirq+0x10f/0x230
       [<ffffffff8105bec8>] irq_exit+0xa8/0xb0
       [<ffffffff8103653e>] smp_trace_call_function_single_interrupt+0x2e/0x30
       [<ffffffff81036549>] smp_call_function_single_interrupt+0x9/0x10
       [<ffffffff8159a959>] call_function_single_interrupt+0x89/0x90
       <EOI>
      
      Fixes: commit be4b4993 (IB/cm: Do not queue work to a device that's going away)
      Signed-off-by: default avatarBart Van Assche <bart.vanassche@sandisk.com>
      Cc: Erez Shitrit <erezsh@mellanox.com>
      Cc: Sean Hefty <sean.hefty@intel.com>
      Cc: Nikolay Borisov <kernel@kyup.com>
      Acked-by: default avatarErez Shitrit <erezsh@mellanox.com>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      abb24acc
    • Tony Luck's avatar
      EDAC, sb_edac: Fix rank lookup on Broadwell · 7bf50606
      Tony Luck authored
      commit c7103f65 upstream.
      
      Broadwell made a small change to the rank target register moving the
      target rank ID field up from bits 16:19 to bits 20:23.
      
      Also found that the offset field grew by one bit in the IVY_BRIDGE to
      HASWELL transition, so fix the RIR_OFFSET() macro too.
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      Cc: Aristeu Rozanski <arozansk@redhat.com>
      Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
      Cc: linux-edac <linux-edac@vger.kernel.org>
      Link: http://lkml.kernel.org/r/2943fb819b1f7e396681165db9c12bb3df0e0b16.1464735623.git.tony.luck@intel.comSigned-off-by: default avatarBorislav Petkov <bp@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7bf50606
    • Jouni Malinen's avatar
      mac80211: Fix mesh estab_plinks counting in STA removal case · 96d50acb
      Jouni Malinen authored
      commit 126e7557 upstream.
      
      If a user space program (e.g., wpa_supplicant) deletes a STA entry that
      is currently in NL80211_PLINK_ESTAB state, the number of established
      plinks counter was not decremented and this could result in rejecting
      new plink establishment before really hitting the real maximum plink
      limit. For !user_mpm case, this decrementation is handled by
      mesh_plink_deactive().
      
      Fix this by decrementing estab_plinks on STA deletion
      (mesh_sta_cleanup() gets called from there) so that the counter has a
      correct value and the Beacon frame advertisement in Mesh Configuration
      element shows the proper value for capability to accept additional
      peers.
      Signed-off-by: default avatarJouni Malinen <j@w1.fi>
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      96d50acb
    • Martin Willi's avatar
      mac80211_hwsim: Add missing check for HWSIM_ATTR_SIGNAL · 43e319d7
      Martin Willi authored
      commit 62397da5 upstream.
      
      A wmediumd that does not send this attribute causes a NULL pointer
      dereference, as the attribute is accessed even if it does not exist.
      
      The attribute was required but never checked ever since userspace frame
      forwarding has been introduced. The issue gets more problematic once we
      allow wmediumd registration from user namespaces.
      
      Fixes: 7882513b ("mac80211_hwsim driver support userspace frame tx/rx")
      Signed-off-by: default avatarMartin Willi <martin@strongswan.org>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      43e319d7
    • Bob Copeland's avatar
      mac80211: mesh: flush mesh paths unconditionally · 7b90e041
      Bob Copeland authored
      commit fe7a7c57 upstream.
      
      Currently, the mesh paths associated with a nexthop station are cleaned
      up in the following code path:
      
          __sta_info_destroy_part1
          synchronize_net()
          __sta_info_destroy_part2
           -> cleanup_single_sta
             -> mesh_sta_cleanup
               -> mesh_plink_deactivate
                 -> mesh_path_flush_by_nexthop
      
      However, there are a couple of problems here:
      
      1) the paths aren't flushed at all if the MPM is running in userspace
         (e.g. when using wpa_supplicant or authsae)
      
      2) there is no synchronize_rcu between removing the path and readers
         accessing the nexthop, which means the following race is possible:
      
      CPU0                            CPU1
      ~~~~                            ~~~~
                                      sta_info_destroy_part1()
                                      synchronize_net()
      rcu_read_lock()
      mesh_nexthop_resolve()
        mpath = mesh_path_lookup()
                                      [...] -> mesh_path_flush_by_nexthop()
        sta = rcu_dereference(
          mpath->next_hop)
                                      kfree(sta)
        access sta <-- CRASH
      
      Fix both of these by unconditionally flushing paths before destroying
      the sta, and by adding a synchronize_net() after path flush to ensure
      no active readers can still dereference the sta.
      
      Fixes this crash:
      
      [  348.529295] BUG: unable to handle kernel paging request at 00020040
      [  348.530014] IP: [<f929245d>] ieee80211_mps_set_frame_flags+0x40/0xaa [mac80211]
      [  348.530014] *pde = 00000000
      [  348.530014] Oops: 0000 [#1] PREEMPT
      [  348.530014] Modules linked in: drbg ansi_cprng ctr ccm ppp_generic slhc ipt_MASQUERADE nf_nat_masquerade_ipv4 8021q ]
      [  348.530014] CPU: 0 PID: 20597 Comm: wget Tainted: G           O 4.6.0-rc5-wt=V1 #1
      [  348.530014] Hardware name: To Be Filled By O.E.M./To be filled by O.E.M., BIOS 080016  11/07/2014
      [  348.530014] task: f64fa280 ti: f4f9c000 task.ti: f4f9c000
      [  348.530014] EIP: 0060:[<f929245d>] EFLAGS: 00010246 CPU: 0
      [  348.530014] EIP is at ieee80211_mps_set_frame_flags+0x40/0xaa [mac80211]
      [  348.530014] EAX: f4ce63e0 EBX: 00000088 ECX: f3788416 EDX: 00020008
      [  348.530014] ESI: 00000000 EDI: 00000088 EBP: f6409a4c ESP: f6409a40
      [  348.530014]  DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
      [  348.530014] CR0: 80050033 CR2: 00020040 CR3: 33190000 CR4: 00000690
      [  348.530014] Stack:
      [  348.530014]  00000000 f4ce63e0 f5f9bd80 f6409a64 f9291d80 0000ce67 f5d51e00 f4ce63e0
      [  348.530014]  f3788416 f6409a80 f9291dc1 f4ce8320 f4ce63e0 f5d51e00 f4ce63e0 f4ce8320
      [  348.530014]  f6409a98 f9277f6f 00000000 00000000 0000007c 00000000 f6409b2c f9278dd1
      [  348.530014] Call Trace:
      [  348.530014]  [<f9291d80>] mesh_nexthop_lookup+0xbb/0xc8 [mac80211]
      [  348.530014]  [<f9291dc1>] mesh_nexthop_resolve+0x34/0xd8 [mac80211]
      [  348.530014]  [<f9277f6f>] ieee80211_xmit+0x92/0xc1 [mac80211]
      [  348.530014]  [<f9278dd1>] __ieee80211_subif_start_xmit+0x807/0x83c [mac80211]
      [  348.530014]  [<c04df012>] ? sch_direct_xmit+0xd7/0x1b3
      [  348.530014]  [<c022a8c6>] ? __local_bh_enable_ip+0x5d/0x7b
      [  348.530014]  [<f956870c>] ? nf_nat_ipv4_out+0x4c/0xd0 [nf_nat_ipv4]
      [  348.530014]  [<f957e036>] ? iptable_nat_ipv4_fn+0xf/0xf [iptable_nat]
      [  348.530014]  [<c04c6f45>] ? netif_skb_features+0x14d/0x30a
      [  348.530014]  [<f9278e10>] ieee80211_subif_start_xmit+0xa/0xe [mac80211]
      [  348.530014]  [<c04c769c>] dev_hard_start_xmit+0x1f8/0x267
      [  348.530014]  [<c04c7261>] ?  validate_xmit_skb.isra.120.part.121+0x10/0x253
      [  348.530014]  [<c04defc6>] sch_direct_xmit+0x8b/0x1b3
      [  348.530014]  [<c04c7a9c>] __dev_queue_xmit+0x2c8/0x513
      [  348.530014]  [<c04c7cfb>] dev_queue_xmit+0xa/0xc
      [  348.530014]  [<f91bfc7a>] batadv_send_skb_packet+0xd6/0xec [batman_adv]
      [  348.530014]  [<f91bfdc4>] batadv_send_unicast_skb+0x15/0x4a [batman_adv]
      [  348.530014]  [<f91b5938>] batadv_dat_send_data+0x27e/0x310 [batman_adv]
      [  348.530014]  [<f91c30b5>] ? batadv_tt_global_hash_find.isra.11+0x8/0xa [batman_adv]
      [  348.530014]  [<f91b63f3>] batadv_dat_snoop_outgoing_arp_request+0x208/0x23d [batman_adv]
      [  348.530014]  [<f91c0cd9>] batadv_interface_tx+0x206/0x385 [batman_adv]
      [  348.530014]  [<c04c769c>] dev_hard_start_xmit+0x1f8/0x267
      [  348.530014]  [<c04c7261>] ?  validate_xmit_skb.isra.120.part.121+0x10/0x253
      [  348.530014]  [<c04defc6>] sch_direct_xmit+0x8b/0x1b3
      [  348.530014]  [<c04c7a9c>] __dev_queue_xmit+0x2c8/0x513
      [  348.530014]  [<f80cbd2a>] ? igb_xmit_frame+0x57/0x72 [igb]
      [  348.530014]  [<c04c7cfb>] dev_queue_xmit+0xa/0xc
      [  348.530014]  [<f843a326>] br_dev_queue_push_xmit+0xeb/0xfb [bridge]
      [  348.530014]  [<f843a35f>] br_forward_finish+0x29/0x74 [bridge]
      [  348.530014]  [<f843a23b>] ? deliver_clone+0x3b/0x3b [bridge]
      [  348.530014]  [<f843a714>] __br_forward+0x89/0xe7 [bridge]
      [  348.530014]  [<f843a336>] ? br_dev_queue_push_xmit+0xfb/0xfb [bridge]
      [  348.530014]  [<f843a234>] deliver_clone+0x34/0x3b [bridge]
      [  348.530014]  [<f843a68b>] ? br_flood+0x95/0x95 [bridge]
      [  348.530014]  [<f843a66d>] br_flood+0x77/0x95 [bridge]
      [  348.530014]  [<f843a809>] br_flood_forward+0x13/0x1a [bridge]
      [  348.530014]  [<f843a68b>] ? br_flood+0x95/0x95 [bridge]
      [  348.530014]  [<f843b877>] br_handle_frame_finish+0x392/0x3db [bridge]
      [  348.530014]  [<c04e9b2b>] ? nf_iterate+0x2b/0x6b
      [  348.530014]  [<f843baa6>] br_handle_frame+0x1e6/0x240 [bridge]
      [  348.530014]  [<f843b4e5>] ? br_handle_local_finish+0x6a/0x6a [bridge]
      [  348.530014]  [<c04c4ba0>] __netif_receive_skb_core+0x43a/0x66b
      [  348.530014]  [<f843b8c0>] ? br_handle_frame_finish+0x3db/0x3db [bridge]
      [  348.530014]  [<c023cea4>] ? resched_curr+0x19/0x37
      [  348.530014]  [<c0240707>] ? check_preempt_wakeup+0xbf/0xfe
      [  348.530014]  [<c0255dec>] ? ktime_get_with_offset+0x5c/0xfc
      [  348.530014]  [<c04c4fc1>] __netif_receive_skb+0x47/0x55
      [  348.530014]  [<c04c57ba>] netif_receive_skb_internal+0x40/0x5a
      [  348.530014]  [<c04c61ef>] napi_gro_receive+0x3a/0x94
      [  348.530014]  [<f80ce8d5>] igb_poll+0x6fd/0x9ad [igb]
      [  348.530014]  [<c0242bd8>] ? swake_up_locked+0x14/0x26
      [  348.530014]  [<c04c5d29>] net_rx_action+0xde/0x250
      [  348.530014]  [<c022a743>] __do_softirq+0x8a/0x163
      [  348.530014]  [<c022a6b9>] ? __hrtimer_tasklet_trampoline+0x19/0x19
      [  348.530014]  [<c021100f>] do_softirq_own_stack+0x26/0x2c
      [  348.530014]  <IRQ>
      [  348.530014]  [<c022a957>] irq_exit+0x31/0x6f
      [  348.530014]  [<c0210eb2>] do_IRQ+0x8d/0xa0
      [  348.530014]  [<c058152c>] common_interrupt+0x2c/0x40
      [  348.530014] Code: e7 8c 00 66 81 ff 88 00 75 12 85 d2 75 0e b2 c3 b8 83 e9 29 f9 e8 a7 5f f9 c6 eb 74 66 81 e3 8c 005
      [  348.530014] EIP: [<f929245d>] ieee80211_mps_set_frame_flags+0x40/0xaa [mac80211] SS:ESP 0068:f6409a40
      [  348.530014] CR2: 0000000000020040
      [  348.530014] ---[ end trace 48556ac26779732e ]---
      [  348.530014] Kernel panic - not syncing: Fatal exception in interrupt
      [  348.530014] Kernel Offset: disabled
      Reported-by: default avatarFred Veldini <fred.veldini@gmail.com>
      Tested-by: default avatarFred Veldini <fred.veldini@gmail.com>
      Signed-off-by: default avatarBob Copeland <me@bobcopeland.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7b90e041
    • Felix Fietkau's avatar
      mac80211: fix fast_tx header alignment · 9dcbb4d9
      Felix Fietkau authored
      commit 6fe04128 upstream.
      
      The header field is defined as u8[] but also accessed as struct
      ieee80211_hdr. Enforce an alignment of 2 to prevent unnecessary
      unaligned accesses, which can be very harmful for performance on many
      platforms.
      
      Fixes: e495c247 ("mac80211: extend fast-xmit for more ciphers")
      Signed-off-by: default avatarFelix Fietkau <nbd@nbd.name>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9dcbb4d9
  2. 11 Jul, 2016 21 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.4.15 · 35467dc7
      Greg Kroah-Hartman authored
      35467dc7
    • Steinar H. Gunderson's avatar
      usb: dwc3: exynos: Fix deferred probing storm. · 36fc1c1e
      Steinar H. Gunderson authored
      commit 4879efb3 upstream.
      
      dwc3-exynos has two problems during init if the regulators are slow
      to come up (for instance if the I2C bus driver is not on the initramfs)
      and return probe deferral. First, every time this happens, the driver
      leaks the USB phys created; they need to be deallocated on error.
      
      Second, since the phy devices are created before the regulators fail,
      this means that there's a new device to re-trigger deferred probing,
      which causes it to essentially go into a busy loop of re-probing the
      device until the regulators come up.
      
      Move the phy creation to after the regulators have succeeded, and also
      fix cleanup on failure. On my ODROID XU4 system (with Debian's initramfs
      which doesn't contain the I2C driver), this reduces the number of probe
      attempts (for each of the two controllers) from more than 2000 to eight.
      Signed-off-by: default avatarSteinar H. Gunderson <sesse@google.com>
      Reviewed-by: default avatarKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Reviewed-by: default avatarVivek Gautam <gautam.vivek@samsung.com>
      Fixes: d720f057 ("usb: dwc3: exynos: add nop transceiver support")
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      36fc1c1e
    • Thierry Reding's avatar
      usb: host: ehci-tegra: Grab the correct UTMI pads reset · 89c18f10
      Thierry Reding authored
      commit f8a15a96 upstream.
      
      There are three EHCI controllers on Tegra SoCs, each with its own reset
      line. However, the first controller contains a set of UTMI configuration
      registers that are shared with its siblings. These registers will only
      be reset as part of the first controller's reset. For proper operation
      it must be ensured that the UTMI configuration registers are reset
      before any of the EHCI controllers are enabled, irrespective of the
      probe order.
      
      Commit a47cc24c ("USB: EHCI: tegra: Fix probe order issue leading to
      broken USB") introduced code that ensures the first controller is always
      reset before setting up any of the controllers, and is never again reset
      afterwards.
      
      This code, however, grabs the wrong reset. Each EHCI controller has two
      reset controls attached: 1) the USB controller reset and 2) the UTMI
      pads reset (really the first controller's reset). In order to reset the
      UTMI pads registers the code must grab the second reset, but instead it
      grabbing the first.
      
      Fixes: a47cc24c ("USB: EHCI: tegra: Fix probe order issue leading to broken USB")
      Acked-by: default avatarJon Hunter <jonathanh@nvidia.com>
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      89c18f10
    • Bin Liu's avatar
      usb: gadget: fix spinlock dead lock in gadgetfs · e845e8b6
      Bin Liu authored
      commit d246dcb2 upstream.
      
      [   40.467381] =============================================
      [   40.473013] [ INFO: possible recursive locking detected ]
      [   40.478651] 4.6.0-08691-g7f3db9a #37 Not tainted
      [   40.483466] ---------------------------------------------
      [   40.489098] usb/733 is trying to acquire lock:
      [   40.493734]  (&(&dev->lock)->rlock){-.....}, at: [<bf129288>] ep0_complete+0x18/0xdc [gadgetfs]
      [   40.502882]
      [   40.502882] but task is already holding lock:
      [   40.508967]  (&(&dev->lock)->rlock){-.....}, at: [<bf12a420>] ep0_read+0x20/0x5e0 [gadgetfs]
      [   40.517811]
      [   40.517811] other info that might help us debug this:
      [   40.524623]  Possible unsafe locking scenario:
      [   40.524623]
      [   40.530798]        CPU0
      [   40.533346]        ----
      [   40.535894]   lock(&(&dev->lock)->rlock);
      [   40.540088]   lock(&(&dev->lock)->rlock);
      [   40.544284]
      [   40.544284]  *** DEADLOCK ***
      [   40.544284]
      [   40.550461]  May be due to missing lock nesting notation
      [   40.550461]
      [   40.557544] 2 locks held by usb/733:
      [   40.561271]  #0:  (&f->f_pos_lock){+.+.+.}, at: [<c02a6114>] __fdget_pos+0x40/0x48
      [   40.569219]  #1:  (&(&dev->lock)->rlock){-.....}, at: [<bf12a420>] ep0_read+0x20/0x5e0 [gadgetfs]
      [   40.578523]
      [   40.578523] stack backtrace:
      [   40.583075] CPU: 0 PID: 733 Comm: usb Not tainted 4.6.0-08691-g7f3db9a #37
      [   40.590246] Hardware name: Generic AM33XX (Flattened Device Tree)
      [   40.596625] [<c010ffbc>] (unwind_backtrace) from [<c010c1bc>] (show_stack+0x10/0x14)
      [   40.604718] [<c010c1bc>] (show_stack) from [<c04207fc>] (dump_stack+0xb0/0xe4)
      [   40.612267] [<c04207fc>] (dump_stack) from [<c01886ec>] (__lock_acquire+0xf68/0x1994)
      [   40.620440] [<c01886ec>] (__lock_acquire) from [<c0189528>] (lock_acquire+0xd8/0x238)
      [   40.628621] [<c0189528>] (lock_acquire) from [<c06ad6b4>] (_raw_spin_lock_irqsave+0x38/0x4c)
      [   40.637440] [<c06ad6b4>] (_raw_spin_lock_irqsave) from [<bf129288>] (ep0_complete+0x18/0xdc [gadgetfs])
      [   40.647339] [<bf129288>] (ep0_complete [gadgetfs]) from [<bf10a728>] (musb_g_giveback+0x118/0x1b0 [musb_hdrc])
      [   40.657842] [<bf10a728>] (musb_g_giveback [musb_hdrc]) from [<bf108768>] (musb_g_ep0_queue+0x16c/0x188 [musb_hdrc])
      [   40.668772] [<bf108768>] (musb_g_ep0_queue [musb_hdrc]) from [<bf12a944>] (ep0_read+0x544/0x5e0 [gadgetfs])
      [   40.678963] [<bf12a944>] (ep0_read [gadgetfs]) from [<c0284470>] (__vfs_read+0x20/0x110)
      [   40.687414] [<c0284470>] (__vfs_read) from [<c0285324>] (vfs_read+0x88/0x114)
      [   40.694864] [<c0285324>] (vfs_read) from [<c0286150>] (SyS_read+0x44/0x9c)
      [   40.702051] [<c0286150>] (SyS_read) from [<c0107820>] (ret_fast_syscall+0x0/0x1c)
      
      This is caused by the spinlock bug in ep0_read().
      Fix the two other deadlock sources in gadgetfs_setup() too.
      Signed-off-by: default avatarBin Liu <b-liu@ti.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e845e8b6
    • Sudip Mukherjee's avatar
      USB: mos7720: delete parport · 30f07618
      Sudip Mukherjee authored
      commit dcb21ad4 upstream.
      
      parport subsystem has introduced parport_del_port() to delete a port
      when it is going away. Without parport_del_port() the registered port
      will not be unregistered.
      To reproduce and verify the error:
      Command to be used is : ls /sys/bus/parport/devices
      1) without the device attached there is no output as there is no
      registered parport.
      2) Attach the device, and the command will show "parport0".
      3) Remove the device and the command still shows "parport0".
      4) Attach the device again and we get "parport1".
      
      With the patch applied:
      1) without the device attached there is no output as there is no
      registered parport.
      2) Attach the device, and the command will show "parport0".
      3) Remove the device and there is no output as "parport0" is now
      removed.
      4) Attach device again to get "parport0" again.
      Signed-off-by: default avatarSudip Mukherjee <sudip.mukherjee@codethink.co.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      30f07618
    • Mathias Nyman's avatar
      xhci: Fix handling timeouted commands on hosts in weird states. · a20257e3
      Mathias Nyman authored
      commit 3425aa03 upstream.
      
      If commands timeout we mark them for abortion, then stop the command
      ring, and turn the commands to no-ops and finally restart the command
      ring.
      
      If the host is working properly the no-op commands will finish and
      pending completions are called.
      If we notice the host is failing, driver clears the command ring and
      completes, deletes and frees all pending commands.
      
      There are two separate cases reported where host is believed to work
      properly but is not. In the first case we successfully stop the ring
      but no abort or stop command ring event is ever sent and host locks up.
      
      The second case is if a host is removed, command times out and driver
      believes the ring is stopped, and assumes it will be restarted, but
      actually ends up timing out on the same command forever.
      If one of the pending commands has the xhci->mutex held it will block
      xhci_stop() in the remove codepath which otherwise would cleanup pending
      commands.
      
      Add a check that clears all pending commands in case host is removed,
      or we are stuck timing out on the same command. Also restart the
      command timeout timer when stopping the command ring to ensure we
      recive an ring stop/abort event.
      Tested-by: default avatarJoe Lawrence <joe.lawrence@stratus.com>
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a20257e3
    • Hans de Goede's avatar
      USB: xhci: Add broken streams quirk for Frescologic device id 1009 · 4582ddf7
      Hans de Goede authored
      commit d95815ba upstream.
      
      I got one of these cards for testing uas with, it seems that with streams
      it dma-s all over the place, corrupting memory. On my first tests it
      managed to dma over the BIOS of the motherboard somehow and completely
      bricked it.
      
      Tests on another motherboard show that it does work with streams disabled.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4582ddf7
    • Thomas Petazzoni's avatar
      usb: xhci-plat: properly handle probe deferral for devm_clk_get() · c5b32273
      Thomas Petazzoni authored
      commit de95c40d upstream.
      
      On some platforms, the clocks might be registered by a platform
      driver. When this is the case, the clock platform driver may very well
      be probed after xhci-plat, in which case the first probe() invocation
      of xhci-plat will receive -EPROBE_DEFER as the return value of
      devm_clk_get().
      
      The current code handles that as a normal error, and simply assumes
      that this means that the system doesn't have a clock for the XHCI
      controller, and continues probing without calling
      clk_prepare_enable(). Unfortunately, this doesn't work on systems
      where the XHCI controller does have a clock, but that clock is
      provided by another platform driver. In order to fix this situation,
      we handle the -EPROBE_DEFER error condition specially, and abort the
      XHCI controller probe(). It will be retried later automatically, the
      clock will be available, devm_clk_get() will succeed, and the probe()
      will continue with the clock prepared and enabled as expected.
      
      In practice, such issue is seen on the ARM64 Marvell 7K/8K platform,
      where the clocks are registered by a platform driver.
      Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c5b32273
    • Gabriel Krisman Bertazi's avatar
      xhci: Cleanup only when releasing primary hcd · e424caf5
      Gabriel Krisman Bertazi authored
      commit 27a41a83 upstream.
      
      Under stress occasions some TI devices might not return early when
      reading the status register during the quirk invocation of xhci_irq made
      by usb_hcd_pci_remove.  This means that instead of returning, we end up
      handling this interruption in the middle of a shutdown.  Since
      xhci->event_ring has already been freed in xhci_mem_cleanup, we end up
      accessing freed memory, causing the Oops below.
      
      commit 8c24d6d7 ("usb: xhci: stop everything on the first call to
      xhci_stop") is the one that changed the instant in which we clean up the
      event queue when stopping a device.  Before, we didn't call
      xhci_mem_cleanup at the first time xhci_stop is executed (for the shared
      HCD), instead, we only did it after the invocation for the primary HCD,
      much later at the removal path.  The code flow for this oops looks like
      this:
      
      xhci_pci_remove()
      	usb_remove_hcd(xhci->shared)
      	        xhci_stop(xhci->shared)
       			xhci_halt()
      			xhci_mem_cleanup(xhci);  // Free the event_queue
      	usb_hcd_pci_remove(primary)
      		xhci_irq()  // Access the event_queue if STS_EINT is set. Crash.
      		xhci_stop()
      			xhci_halt()
      			// return early
      
      The fix modifies xhci_stop to only cleanup the xhci data when releasing
      the primary HCD.  This way, we still have the event_queue configured
      when invoking xhci_irq.  We still halt the device on the first call to
      xhci_stop, though.
      
      I could reproduce this issue several times on the mainline kernel by
      doing a bind-unbind stress test with a specific storage gadget attached.
      I also ran the same test over-night with my patch applied and didn't
      observe the issue anymore.
      
      [  113.334124] Unable to handle kernel paging request for data at address 0x00000028
      [  113.335514] Faulting instruction address: 0xd00000000d4f767c
      [  113.336839] Oops: Kernel access of bad area, sig: 11 [#1]
      [  113.338214] SMP NR_CPUS=1024 NUMA PowerNV
      
      [c000000efe47ba90] c000000000720850 usb_hcd_irq+0x50/0x80
      [c000000efe47bac0] c00000000073d328 usb_hcd_pci_remove+0x68/0x1f0
      [c000000efe47bb00] d00000000daf0128 xhci_pci_remove+0x78/0xb0
      [xhci_pci]
      [c000000efe47bb30] c00000000055cf70 pci_device_remove+0x70/0x110
      [c000000efe47bb70] c00000000061c6bc __device_release_driver+0xbc/0x190
      [c000000efe47bba0] c00000000061c7d0 device_release_driver+0x40/0x70
      [c000000efe47bbd0] c000000000619510 unbind_store+0x120/0x150
      [c000000efe47bc20] c0000000006183c4 drv_attr_store+0x64/0xa0
      [c000000efe47bc60] c00000000039f1d0 sysfs_kf_write+0x80/0xb0
      [c000000efe47bca0] c00000000039e14c kernfs_fop_write+0x18c/0x1f0
      [c000000efe47bcf0] c0000000002e962c __vfs_write+0x6c/0x190
      [c000000efe47bd90] c0000000002eab40 vfs_write+0xc0/0x200
      [c000000efe47bde0] c0000000002ec85c SyS_write+0x6c/0x110
      [c000000efe47be30] c000000000009260 system_call+0x38/0x108
      Signed-off-by: default avatarGabriel Krisman Bertazi <krisman@linux.vnet.ibm.com>
      Cc: Roger Quadros <rogerq@ti.com>
      Cc: joel@jms.id.au
      Reviewed-by: default avatarRoger Quadros <rogerq@ti.com>
      Tested-by: default avatarJoel Stanley <joel@jms.id.au>
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e424caf5
    • Bin Liu's avatar
      usb: musb: host: correct cppi dma channel for isoch transfer · faa1dbbe
      Bin Liu authored
      commit 04471eb8 upstream.
      
      Incorrect cppi dma channel is referenced in musb_rx_dma_iso_cppi41(),
      which causes kernel NULL pointer reference oops later when calling
      cppi41_dma_channel_program().
      
      Fixes: 069a3fd1 (usb: musb: Remove ifdefs for musb_host_rx in musb_host.c
      part1)
      Reported-by: default avatarMatwey V. Kornilov <matwey@sai.msu.ru>
      Acked-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarBin Liu <b-liu@ti.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      faa1dbbe
    • Andrew Goodbody's avatar
      usb: musb: Ensure rx reinit occurs for shared_fifo endpoints · a8f7a6d2
      Andrew Goodbody authored
      commit f3eec0cf upstream.
      
      shared_fifo endpoints would only get a previous tx state cleared
      out, the rx state was only cleared for non shared_fifo endpoints
      Change this so that the rx state is cleared for all endpoints.
      This addresses an issue that resulted in rx packets being dropped
      silently.
      Signed-off-by: default avatarAndrew Goodbody <andrew.goodbody@cambrionix.com>
      Signed-off-by: default avatarBin Liu <b-liu@ti.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a8f7a6d2
    • Andrew Goodbody's avatar
      usb: musb: Stop bulk endpoint while queue is rotated · a2cf3427
      Andrew Goodbody authored
      commit 7b2c17f8 upstream.
      
      Ensure that the endpoint is stopped by clearing REQPKT before
      clearing DATAERR_NAKTIMEOUT before rotating the queue on the
      dedicated bulk endpoint.
      This addresses an issue where a race could result in the endpoint
      receiving data before it was reprogrammed resulting in a warning
      about such data from musb_rx_reinit before it was thrown away.
      The data thrown away was a valid packet that had been correctly
      ACKed which meant the host and device got out of sync.
      Signed-off-by: default avatarAndrew Goodbody <andrew.goodbody@cambrionix.com>
      Signed-off-by: default avatarBin Liu <b-liu@ti.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a2cf3427
    • Bin Liu's avatar
      usb: musb: only restore devctl when session was set in backup · 089a2d84
      Bin Liu authored
      commit 84ac5d11 upstream.
      
      If the session bit was not set in the backup of devctl register,
      restoring devctl would clear the session bit. Therefor, only restore
      devctl register when the session bit was set in the backup.
      
      This solves the device enumeration failure in otg mode exposed by commit
      56f487c7 (PM / Runtime: Update last_busy in rpm_resume).
      Signed-off-by: default avatarBin Liu <b-liu@ti.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      089a2d84
    • Hans de Goede's avatar
      usb: quirks: Add no-lpm quirk for Acer C120 LED Projector · 4fe6d4b4
      Hans de Goede authored
      commit 32cb0b37 upstream.
      
      The Acer C120 LED Projector is a USB-3 connected pico projector which
      takes both its power and video data from USB-3.
      
      In combination with some hubs this device does not play well with
      lpm, so disable lpm for it.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4fe6d4b4
    • Hans de Goede's avatar
      usb: quirks: Fix sorting · c56eeffc
      Hans de Goede authored
      commit 81099f97 upstream.
      
      Properly sort all the entries by vendor id.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c56eeffc
    • Hans de Goede's avatar
      USB: uas: Fix slave queue_depth not being set · b66baf41
      Hans de Goede authored
      commit 593224ea upstream.
      
      Commit 198de51d ("USB: uas: Limit qdepth at the scsi-host level")
      removed the scsi_change_queue_depth() call from uas_slave_configure()
      assuming that the slave would inherit the host's queue_depth, which
      that commit sets to the same value.
      
      This is incorrect, without the scsi_change_queue_depth() call the slave's
      queue_depth defaults to 1, introducing a performance regression.
      
      This commit restores the call, fixing the performance regression.
      
      Fixes: 198de51d ("USB: uas: Limit qdepth at the scsi-host level")
      Reported-by: default avatarTom Yan <tom.ty89@gmail.com>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b66baf41
    • Mathias Krause's avatar
      crypto: user - re-add size check for CRYPTO_MSG_GETALG · ce1abd25
      Mathias Krause authored
      commit 055ddaac upstream.
      
      Commit 9aa867e4 ("crypto: user - Add CRYPTO_MSG_DELRNG")
      accidentally removed the minimum size check for CRYPTO_MSG_GETALG
      netlink messages. This allows userland to send a truncated
      CRYPTO_MSG_GETALG message as short as a netlink header only making
      crypto_report() operate on uninitialized memory by accessing data
      beyond the end of the netlink message.
      
      Fix this be re-adding the minimum required size of CRYPTO_MSG_GETALG
      messages to the crypto_msg_min[] array.
      
      Fixes: 9aa867e4 ("crypto: user - Add CRYPTO_MSG_DELRNG")
      Signed-off-by: default avatarMathias Krause <minipli@googlemail.com>
      Cc: Steffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ce1abd25
    • Linus Walleij's avatar
      crypto: ux500 - memmove the right size · 5ae68873
      Linus Walleij authored
      commit 19ced623 upstream.
      
      The hash buffer is really HASH_BLOCK_SIZE bytes, someone
      must have thought that memmove takes n*u32 words by mistake.
      Tests work as good/bad as before after this patch.
      
      Cc: Joakim Bech <joakim.bech@linaro.org>
      Reported-by: default avatarDavid Binderman <linuxdev.baldrick@gmail.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5ae68873
    • Anton Blanchard's avatar
      crypto: vmx - Increase priority of aes-cbc cipher · f6d06f1d
      Anton Blanchard authored
      commit 12d3f49e upstream.
      
      All of the VMX AES ciphers (AES, AES-CBC and AES-CTR) are set at
      priority 1000. Unfortunately this means we never use AES-CBC and
      AES-CTR, because the base AES-CBC cipher that is implemented on
      top of AES inherits its priority.
      
      To fix this, AES-CBC and AES-CTR have to be a higher priority. Set
      them to 2000.
      
      Testing on a POWER8 with:
      
      cryptsetup benchmark --cipher aes --key-size 256
      
      Shows decryption speed increase from 402.4 MB/s to 3069.2 MB/s,
      over 7x faster. Thanks to Mike Strosaker for helping me debug
      this issue.
      
      Fixes: 8c755ace ("crypto: vmx - Adding CBC routines for VMX module")
      Signed-off-by: default avatarAnton Blanchard <anton@samba.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f6d06f1d
    • Basil Gunn's avatar
      AX.25: Close socket connection on session completion · eda89513
      Basil Gunn authored
      [ Upstream commit 4a7d99ea ]
      
      A socket connection made in ax.25 is not closed when session is
      completed.  The heartbeat timer is stopped prematurely and this is
      where the socket gets closed. Allow heatbeat timer to run to close
      socket. Symptom occurs in kernels >= 4.2.0
      
      Originally sent 6/15/2016. Resend with distribution list matching
      scripts/maintainer.pl output.
      Signed-off-by: default avatarBasil Gunn <basil@pacabunga.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      eda89513
    • Daniel Borkmann's avatar
      bpf: try harder on clones when writing into skb · b30cc5b1
      Daniel Borkmann authored
      [ Upstream commit 3697649f ]
      
      When we're dealing with clones and the area is not writeable, try
      harder and get a copy via pskb_expand_head(). Replace also other
      occurences in tc actions with the new skb_try_make_writable().
      Reported-by: default avatarAshhad Sheikh <ashhadsheikh394@gmail.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b30cc5b1