1. 06 Jun, 2016 19 commits
    • Guilherme G. Piccoli's avatar
      Revert "powerpc/eeh: Fix crash in eeh_add_device_early() on Cell" · deee8f00
      Guilherme G. Piccoli authored
      [ Upstream commit c2078d9e ]
      
      This reverts commit 89a51df5.
      
      The function eeh_add_device_early() is used to perform EEH
      initialization in devices added later on the system, like in
      hotplug/DLPAR scenarios. Since the commit 89a51df5 ("powerpc/eeh:
      Fix crash in eeh_add_device_early() on Cell") a new check was introduced
      in this function - Cell has no EEH capabilities which led to kernel oops
      if hotplug was performed, so checking for eeh_enabled() was introduced
      to avoid the issue.
      
      However, in architectures that EEH is present like pSeries or PowerNV,
      we might reach a case in which no PCI devices are present on boot time
      and so EEH is not initialized. Then, if a device is added via DLPAR for
      example, eeh_add_device_early() fails because eeh_enabled() is false,
      and EEH end up not being enabled at all.
      
      This reverts the aforementioned patch since a new verification was
      introduced by the commit d91dafc0 ("powerpc/eeh: Delay probing EEH
      device during hotplug") and so the original Cell issue does not happen
      anymore.
      
      Cc: stable@vger.kernel.org # v4.1+
      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 avatarSasha Levin <sasha.levin@oracle.com>
      deee8f00
    • Gavin Shan's avatar
      powerpc/eeh: Restore initial state in eeh_pe_reset_and_recover() · 75d03a9e
      Gavin Shan authored
      [ Upstream commit 5a0cdbfd ]
      
      The function eeh_pe_reset_and_recover() is used to recover EEH
      error when the passthrou device are transferred to guest and
      backwards. The content in the device's config space will be lost
      on PE reset issued in the middle of the recovery. The function
      saves/restores it before/after the reset. However, config access
      to some adapters like Broadcom BCM5719 at this point will causes
      fenced PHB. The config space is always blocked and we save 0xFF's
      that are restored at late point. The memory BARs are totally
      corrupted, causing another EEH error upon access to one of the
      memory BARs.
      
      This restores the config space on those adapters like BCM5719
      from the content saved to the EEH device when it's populated,
      to resolve above issue.
      
      Fixes: 5cfb20b9 ("powerpc/eeh: Emulate EEH recovery for VFIO devices")
      Cc: stable@vger.kernel.org #v3.18+
      Signed-off-by: default avatarGavin Shan <gwshan@linux.vnet.ibm.com>
      Reviewed-by: default avatarRussell Currey <ruscur@russell.cc>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      75d03a9e
    • Gavin Shan's avatar
      powerpc/eeh: Don't report error in eeh_pe_reset_and_recover() · b7ccd2a2
      Gavin Shan authored
      [ Upstream commit affeb0f2 ]
      
      The function eeh_pe_reset_and_recover() is used to recover EEH
      error when the passthrough device are transferred to guest and
      backwards, meaning the device's driver is vfio-pci or none.
      When the driver is vfio-pci that provides error_detected() error
      handler only, the handler simply stops the guest and it's not
      expected behaviour. On the other hand, no error handlers will
      be called if we don't have a bound driver.
      
      This ignores the error handler in eeh_pe_reset_and_recover()
      that reports the error to device driver to avoid the exceptional
      behaviour.
      
      Fixes: 5cfb20b9 ("powerpc/eeh: Emulate EEH recovery for VFIO devices")
      Cc: stable@vger.kernel.org #v3.18+
      Signed-off-by: default avatarGavin Shan <gwshan@linux.vnet.ibm.com>
      Reviewed-by: default avatarRussell Currey <ruscur@russell.cc>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      b7ccd2a2
    • Sasha Levin's avatar
      sched/loadavg: Fix loadavg artifacts on fully idle and on fully loaded systems · 18fc6569
      Sasha Levin authored
      [ Upstream commit 20878232 ]
      
      Systems show a minimal load average of 0.00, 0.01, 0.05 even when they
      have no load at all.
      
      Uptime and /proc/loadavg on all systems with kernels released during the
      last five years up until kernel version 4.6-rc5, show a 5- and 15-minute
      minimum loadavg of 0.01 and 0.05 respectively. This should be 0.00 on
      idle systems, but the way the kernel calculates this value prevents it
      from getting lower than the mentioned values.
      
      Likewise but not as obviously noticeable, a fully loaded system with no
      processes waiting, shows a maximum 1/5/15 loadavg of 1.00, 0.99, 0.95
      (multiplied by number of cores).
      
      Once the (old) load becomes 93 or higher, it mathematically can never
      get lower than 93, even when the active (load) remains 0 forever.
      This results in the strange 0.00, 0.01, 0.05 uptime values on idle
      systems.  Note: 93/2048 = 0.0454..., which rounds up to 0.05.
      
      It is not correct to add a 0.5 rounding (=1024/2048) here, since the
      result from this function is fed back into the next iteration again,
      so the result of that +0.5 rounding value then gets multiplied by
      (2048-2037), and then rounded again, so there is a virtual "ghost"
      load created, next to the old and active load terms.
      
      By changing the way the internally kept value is rounded, that internal
      value equivalent now can reach 0.00 on idle, and 1.00 on full load. Upon
      increasing load, the internally kept load value is rounded up, when the
      load is decreasing, the load value is rounded down.
      
      The modified code was tested on nohz=off and nohz kernels. It was tested
      on vanilla kernel 4.6-rc5 and on centos 7.1 kernel 3.10.0-327. It was
      tested on single, dual, and octal cores system. It was tested on virtual
      hosts and bare hardware. No unwanted effects have been observed, and the
      problems that the patch intended to fix were indeed gone.
      Tested-by: default avatarDamien Wyart <damien.wyart@free.fr>
      Signed-off-by: default avatarVik Heyndrickx <vik.heyndrickx@veribox.net>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: <stable@vger.kernel.org>
      Cc: Doug Smythies <dsmythies@telus.net>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Fixes: 0f004f5a ("sched: Cure more NO_HZ load average woes")
      Link: http://lkml.kernel.org/r/e8d32bff-d544-7748-72b5-3c86cc71f09f@veribox.netSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      18fc6569
    • Sasha Levin's avatar
      rtlwifi: pci: use dev_kfree_skb_irq instead of kfree_skb in rtl_pci_reset_trx_ring · fa5c124f
      Sasha Levin authored
      [ Upstream commit cf968937 ]
      
      We can't use kfree_skb in irq disable context, because spin_lock_irqsave
      make sure we are always in irq disable context, use dev_kfree_skb_irq
      instead of kfree_skb is better than dev_kfree_skb_any.
      
      This patch fix below kernel warning:
      [ 7612.095528] ------------[ cut here ]------------
      [ 7612.095546] WARNING: CPU: 3 PID: 4460 at kernel/softirq.c:150 __local_bh_enable_ip+0x58/0x80()
      [ 7612.095550] Modules linked in: rtl8723be x86_pkg_temp_thermal btcoexist rtl_pci rtlwifi rtl8723_common
      [ 7612.095567] CPU: 3 PID: 4460 Comm: ifconfig Tainted: G        W       4.4.0+ #4
      [ 7612.095570] Hardware name: LENOVO 20DFA04FCD/20DFA04FCD, BIOS J5ET48WW (1.19 ) 08/27/2015
      [ 7612.095574]  00000000 00000000 da37fc70 c12ce7c5 00000000 da37fca0 c104cc59 c19d4454
      [ 7612.095584]  00000003 0000116c c19d4784 00000096 c10508a8 c10508a8 00000200 c1b42400
      [ 7612.095594]  f29be780 da37fcb0 c104ccad 00000009 00000000 da37fcbc c10508a8 f21f08b8
      [ 7612.095604] Call Trace:
      [ 7612.095614]  [<c12ce7c5>] dump_stack+0x41/0x5c
      [ 7612.095620]  [<c104cc59>] warn_slowpath_common+0x89/0xc0
      [ 7612.095628]  [<c10508a8>] ? __local_bh_enable_ip+0x58/0x80
      [ 7612.095634]  [<c10508a8>] ? __local_bh_enable_ip+0x58/0x80
      [ 7612.095640]  [<c104ccad>] warn_slowpath_null+0x1d/0x20
      [ 7612.095646]  [<c10508a8>] __local_bh_enable_ip+0x58/0x80
      [ 7612.095653]  [<c16b7d34>] destroy_conntrack+0x64/0xa0
      [ 7612.095660]  [<c16b300f>] nf_conntrack_destroy+0xf/0x20
      [ 7612.095665]  [<c1677565>] skb_release_head_state+0x55/0xa0
      [ 7612.095670]  [<c16775bb>] skb_release_all+0xb/0x20
      [ 7612.095674]  [<c167760b>] __kfree_skb+0xb/0x60
      [ 7612.095679]  [<c16776f0>] kfree_skb+0x30/0x70
      [ 7612.095686]  [<f81b869d>] ? rtl_pci_reset_trx_ring+0x22d/0x370 [rtl_pci]
      [ 7612.095692]  [<f81b869d>] rtl_pci_reset_trx_ring+0x22d/0x370 [rtl_pci]
      [ 7612.095698]  [<f81b87f9>] rtl_pci_start+0x19/0x190 [rtl_pci]
      [ 7612.095705]  [<f81970e6>] rtl_op_start+0x56/0x90 [rtlwifi]
      [ 7612.095712]  [<c17e3f16>] drv_start+0x36/0xc0
      [ 7612.095717]  [<c17f5ab3>] ieee80211_do_open+0x2d3/0x890
      [ 7612.095725]  [<c16820fe>] ? call_netdevice_notifiers_info+0x2e/0x60
      [ 7612.095730]  [<c17f60bd>] ieee80211_open+0x4d/0x50
      [ 7612.095736]  [<c16891b3>] __dev_open+0xa3/0x130
      [ 7612.095742]  [<c183fa53>] ? _raw_spin_unlock_bh+0x13/0x20
      [ 7612.095748]  [<c1689499>] __dev_change_flags+0x89/0x140
      [ 7612.095753]  [<c127c70d>] ? selinux_capable+0xd/0x10
      [ 7612.095759]  [<c1689589>] dev_change_flags+0x29/0x60
      [ 7612.095765]  [<c1700b93>] devinet_ioctl+0x553/0x670
      [ 7612.095772]  [<c12db758>] ? _copy_to_user+0x28/0x40
      [ 7612.095777]  [<c17018b5>] inet_ioctl+0x85/0xb0
      [ 7612.095783]  [<c166e647>] sock_ioctl+0x67/0x260
      [ 7612.095788]  [<c166e5e0>] ? sock_fasync+0x80/0x80
      [ 7612.095795]  [<c115c99b>] do_vfs_ioctl+0x6b/0x550
      [ 7612.095800]  [<c127c812>] ? selinux_file_ioctl+0x102/0x1e0
      [ 7612.095807]  [<c10a8914>] ? timekeeping_suspend+0x294/0x320
      [ 7612.095813]  [<c10a256a>] ? __hrtimer_run_queues+0x14a/0x210
      [ 7612.095820]  [<c1276e24>] ? security_file_ioctl+0x34/0x50
      [ 7612.095827]  [<c115cef0>] SyS_ioctl+0x70/0x80
      [ 7612.095832]  [<c1001804>] do_fast_syscall_32+0x84/0x120
      [ 7612.095839]  [<c183ff91>] sysenter_past_esp+0x36/0x55
      [ 7612.095844] ---[ end trace 97e9c637a20e8348 ]---
      Signed-off-by: default avatarWang YanQing <udknight@gmail.com>
      Cc: Stable <stable@vger.kernel.org>
      Acked-by: default avatarLarry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      fa5c124f
    • Sasha Levin's avatar
      rtlwifi: Fix logic error in enter/exit power-save mode · 5de658d6
      Sasha Levin authored
      [ Upstream commit 873ffe15 ]
      
      In commit a269913c ("rtlwifi: Rework rtl_lps_leave() and
      rtl_lps_enter() to use work queue"), the tests for enter/exit
      power-save mode were inverted. With this change applied, the
      wifi connection becomes much more stable.
      
      Fixes: a269913c ("rtlwifi: Rework rtl_lps_leave() and rtl_lps_enter() to use work queue")
      Signed-off-by: default avatarWang YanQing <udknight@gmail.com>
      CC: Stable <stable@vger.kernel.org> [3.10+]
      Acked-by: default avatarLarry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      5de658d6
    • Arnd Bergmann's avatar
      kbuild: move -Wunused-const-variable to W=1 warning level · 4cfbd219
      Arnd Bergmann authored
      [ Upstream commit c9c6837d ]
      
      gcc-6 started warning by default about variables that are not
      used anywhere and that are marked 'const', generating many
      false positives in an allmodconfig build, e.g.:
      
      arch/arm/mach-davinci/board-da830-evm.c:282:20: warning: 'da830_evm_emif25_pins' defined but not used [-Wunused-const-variable=]
      arch/arm/plat-omap/dmtimer.c:958:34: warning: 'omap_timer_match' defined but not used [-Wunused-const-variable=]
      drivers/bluetooth/hci_bcm.c:625:39: warning: 'acpi_bcm_default_gpios' defined but not used [-Wunused-const-variable=]
      drivers/char/hw_random/omap-rng.c:92:18: warning: 'reg_map_omap4' defined but not used [-Wunused-const-variable=]
      drivers/devfreq/exynos/exynos5_bus.c:381:32: warning: 'exynos5_busfreq_int_pm' defined but not used [-Wunused-const-variable=]
      drivers/dma/mv_xor.c:1139:34: warning: 'mv_xor_dt_ids' defined but not used [-Wunused-const-variable=]
      
      This is similar to the existing -Wunused-but-set-variable warning
      that was added in an earlier release and that we disable by default
      now and only enable when W=1 is set, so it makes sense to do
      the same here. Once we have eliminated the majority of the
      warnings for both, we can put them back into the default list.
      
      We probably want this in backport kernels as well, to allow building
      them with gcc-6 without introducing extra warnings.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarOlof Johansson <olof@lixom.net>
      Acked-by: default avatarLee Jones <lee.jones@linaro.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMichal Marek <mmarek@suse.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      4cfbd219
    • Marc Zyngier's avatar
      irqchip/gic-v3: Configure all interrupts as non-secure Group-1 · 10443b37
      Marc Zyngier authored
      [ Upstream commit 7c9b9730 ]
      
      The GICv3 driver wrongly assumes that it runs on the non-secure
      side of a secure-enabled system, while it could be on a system
      with a single security state, or a GICv3 with GICD_CTLR.DS set.
      
      Either way, it is important to configure this properly, or
      interrupts will simply not be delivered on this HW.
      
      Cc: stable@vger.kernel.org
      Reported-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      Tested-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      10443b37
    • Will Deacon's avatar
      irqchip/gic: Ensure ordering between read of INTACK and shared data · bfc9ab72
      Will Deacon authored
      [ Upstream commit f86c4fbd ]
      
      When an IPI is generated by a CPU, the pattern looks roughly like:
      
        <write shared data>
        smp_wmb();
        <write to GIC to signal SGI>
      
      On the receiving CPU we rely on the fact that, once we've taken the
      interrupt, then the freshly written shared data must be visible to us.
      Put another way, the CPU isn't going to speculate taking an interrupt.
      
      Unfortunately, this assumption turns out to be broken.
      
      Consider that CPUx wants to send an IPI to CPUy, which will cause CPUy
      to read some shared_data. Before CPUx has done anything, a random
      peripheral raises an IRQ to the GIC and the IRQ line on CPUy is raised.
      CPUy then takes the IRQ and starts executing the entry code, heading
      towards gic_handle_irq. Furthermore, let's assume that a bunch of the
      previous interrupts handled by CPUy were SGIs, so the branch predictor
      kicks in and speculates that irqnr will be <16 and we're likely to
      head into handle_IPI. The prefetcher then grabs a speculative copy of
      shared_data which contains a stale value.
      
      Meanwhile, CPUx gets round to updating shared_data and asking the GIC
      to send an SGI to CPUy. Internally, the GIC decides that the SGI is
      more important than the peripheral interrupt (which hasn't yet been
      ACKed) but doesn't need to do anything to CPUy, because the IRQ line
      is already raised.
      
      CPUy then reads the ACK register on the GIC, sees the SGI value which
      confirms the branch prediction and we end up with a stale shared_data
      value.
      
      This patch fixes the problem by adding an smp_rmb() to the IPI entry
      code in gic_handle_irq. As it turns out, the combination of a control
      dependency and an ISB instruction from the EOI in the GICv3 driver is
      enough to provide the ordering we need, so we add a comment there
      justifying the absence of an explicit smp_rmb().
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      bfc9ab72
    • Arnd Bergmann's avatar
      gcov: disable tree-loop-im to reduce stack usage · ff0ee291
      Arnd Bergmann authored
      [ Upstream commit c87bf431 ]
      
      Enabling CONFIG_GCOV_PROFILE_ALL produces us a lot of warnings like
      
      lib/lz4/lz4hc_compress.c: In function 'lz4_compresshcctx':
      lib/lz4/lz4hc_compress.c:514:1: warning: the frame size of 1504 bytes is larger than 1024 bytes [-Wframe-larger-than=]
      
      After some investigation, I found that this behavior started with gcc-4.9,
      and opened https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69702.
      A suggested workaround for it is to use the -fno-tree-loop-im
      flag that turns off one of the optimization stages in gcc, so the
      code runs a little slower but does not use excessive amounts
      of stack.
      
      We could make this conditional on the gcc version, but I could not
      find an easy way to do this in Kbuild and the benefit would be
      fairly small, given that most of the gcc version in production are
      affected now.
      
      I'm marking this for 'stable' backports because it addresses a bug
      with code generation in gcc that exists in all kernel versions
      with the affected gcc releases.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarPeter Oberparleiter <oberpar@linux.vnet.ibm.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMichal Marek <mmarek@suse.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      ff0ee291
    • James Hogan's avatar
      MIPS: KVM: Fix timer IRQ race when writing CP0_Compare · 456b98fe
      James Hogan authored
      [ Upstream commit b45bacd2 ]
      
      Writing CP0_Compare clears the timer interrupt pending bit
      (CP0_Cause.TI), but this wasn't being done atomically. If a timer
      interrupt raced with the write of the guest CP0_Compare, the timer
      interrupt could end up being pending even though the new CP0_Compare is
      nowhere near CP0_Count.
      
      We were already updating the hrtimer expiry with
      kvm_mips_update_hrtimer(), which used both kvm_mips_freeze_hrtimer() and
      kvm_mips_resume_hrtimer(). Close the race window by expanding out
      kvm_mips_update_hrtimer(), and clearing CP0_Cause.TI and setting
      CP0_Compare between the freeze and resume. Since the pending timer
      interrupt should not be cleared when CP0_Compare is written via the KVM
      user API, an ack argument is added to distinguish the source of the
      write.
      
      Fixes: e30492bb ("MIPS: KVM: Rewrite count/compare timer emulation")
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: "Radim KrčmáÅ" <rkrcmar@redhat.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      Cc: kvm@vger.kernel.org
      Cc: <stable@vger.kernel.org> # 3.16.x-
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      456b98fe
    • James Hogan's avatar
      MIPS: KVM: Fix timer IRQ race when freezing timer · 8106278c
      James Hogan authored
      [ Upstream commit 4355c44f ]
      
      There's a particularly narrow and subtle race condition when the
      software emulated guest timer is frozen which can allow a guest timer
      interrupt to be missed.
      
      This happens due to the hrtimer expiry being inexact, so very
      occasionally the freeze time will be after the moment when the emulated
      CP0_Count transitions to the same value as CP0_Compare (so an IRQ should
      be generated), but before the moment when the hrtimer is due to expire
      (so no IRQ is generated). The IRQ won't be generated when the timer is
      resumed either, since the resume CP0_Count will already match CP0_Compare.
      
      With VZ guests in particular this is far more likely to happen, since
      the soft timer may be frozen frequently in order to restore the timer
      state to the hardware guest timer. This happens after 5-10 hours of
      guest soak testing, resulting in an overflow in guest kernel timekeeping
      calculations, hanging the guest. A more focussed test case to
      intentionally hit the race (with the help of a new hypcall to cause the
      timer state to migrated between hardware & software) hits the condition
      fairly reliably within around 30 seconds.
      
      Instead of relying purely on the inexact hrtimer expiry to determine
      whether an IRQ should be generated, read the guest CP0_Compare and
      directly check whether the freeze time is before or after it. Only if
      CP0_Count is on or after CP0_Compare do we check the hrtimer expiry to
      determine whether the last IRQ has already been generated (which will
      have pushed back the expiry by one timer period).
      
      Fixes: e30492bb ("MIPS: KVM: Rewrite count/compare timer emulation")
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: "Radim KrčmáÅ" <rkrcmar@redhat.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      Cc: kvm@vger.kernel.org
      Cc: <stable@vger.kernel.org> # 3.16.x-
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      8106278c
    • Catalin Vasile's avatar
      crypto: caam - fix caam_jr_alloc() ret code · ceee7b2f
      Catalin Vasile authored
      [ Upstream commit e930c765 ]
      
      caam_jr_alloc() used to return NULL if a JR device could not be
      allocated for a session. In turn, every user of this function used
      IS_ERR() function to verify if anything went wrong, which does NOT look
      for NULL values. This made the kernel crash if the sanity check failed,
      because the driver continued to think it had allocated a valid JR dev
      instance to the session and at some point it tries to do a caam_jr_free()
      on a NULL JR dev pointer.
      This patch is a fix for this issue.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarCatalin Vasile <cata.vasile@nxp.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      ceee7b2f
    • Johan Hovold's avatar
      USB: serial: quatech2: fix use-after-free in probe error path · 7124f5df
      Johan Hovold authored
      [ Upstream commit 028c49f5 ]
      
      The interface read URB is submitted in attach, but was only unlinked by
      the driver at disconnect.
      
      In case of a late probe error (e.g. due to failed minor allocation),
      disconnect is never called and we would end up with active URBs for an
      unbound interface. This in turn could lead to deallocated memory being
      dereferenced in the completion callback.
      
      Fixes: f7a33e60 ("USB: serial: add quatech2 usb to serial driver")
      Cc: stable <stable@vger.kernel.org>	# v3.5: 40d04738Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      7124f5df
    • Johan Hovold's avatar
      USB: serial: mxuport: fix use-after-free in probe error path · 17e958ca
      Johan Hovold authored
      [ Upstream commit 9e452849 ]
      
      The interface read and event URBs are submitted in attach, but were
      never explicitly unlinked by the driver. Instead the URBs would have
      been killed by usb-serial core on disconnect.
      
      In case of a late probe error (e.g. due to failed minor allocation),
      disconnect is never called and we could end up with active URBs for an
      unbound interface. This in turn could lead to deallocated memory being
      dereferenced in the completion callbacks.
      
      Fixes: ee467a1f ("USB: serial: add Moxa UPORT 12XX/14XX/16XX
      driver")
      Cc: stable <stable@vger.kernel.org>	# v3.14
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      17e958ca
    • Johan Hovold's avatar
      USB: serial: keyspan: fix use-after-free in probe error path · d2e9eeb2
      Johan Hovold authored
      [ Upstream commit 35be1a71 ]
      
      The interface instat and indat URBs were submitted in attach, but never
      unlinked in release before deallocating the corresponding transfer
      buffers.
      
      In the case of a late probe error (e.g. due to failed minor allocation),
      disconnect would not have been called before release, causing the
      buffers to be freed while the URBs are still in use. We'd also end up
      with active URBs for an unbound interface.
      
      Fixes: f9c99bb8 ("USB: usb-serial: replace shutdown with disconnect,
      release")
      Cc: stable <stable@vger.kernel.org>	# v2.6.31
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      d2e9eeb2
    • Johan Hovold's avatar
      USB: serial: io_edgeport: fix memory leaks in probe error path · 90eb29f5
      Johan Hovold authored
      [ Upstream commit c8d62957 ]
      
      URBs and buffers allocated in attach for Epic devices would never be
      deallocated in case of a later probe error (e.g. failure to allocate
      minor numbers) as disconnect is then never called.
      
      Fix by moving deallocation to release and making sure that the
      URBs are first unlinked.
      
      Fixes: f9c99bb8 ("USB: usb-serial: replace shutdown with disconnect,
      release")
      Cc: stable <stable@vger.kernel.org>	# v2.6.31
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      90eb29f5
    • Johan Hovold's avatar
      USB: serial: io_edgeport: fix memory leaks in attach error path · 7bbc1379
      Johan Hovold authored
      [ Upstream commit c5c0c555 ]
      
      Private data, URBs and buffers allocated for Epic devices during
      attach were never released on errors (e.g. missing endpoints).
      
      Fixes: 6e8cf775 ("USB: add EPIC support to the io_edgeport driver")
      Cc: stable <stable@vger.kernel.org>	# v2.6.21
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      7bbc1379
    • Roger Quadros's avatar
      mfd: omap-usb-tll: Fix scheduling while atomic BUG · ec391566
      Roger Quadros authored
      [ Upstream commit b49b927f ]
      
      We shouldn't be calling clk_prepare_enable()/clk_prepare_disable()
      in an atomic context.
      
      Fixes the following issue:
      
      [    5.830970] ehci-omap: OMAP-EHCI Host Controller driver
      [    5.830974] driver_register 'ehci-omap'
      [    5.895849] driver_register 'wl1271_sdio'
      [    5.896870] BUG: scheduling while atomic: udevd/994/0x00000002
      [    5.896876] 4 locks held by udevd/994:
      [    5.896904]  #0:  (&dev->mutex){......}, at: [<c049597c>] __driver_attach+0x60/0xac
      [    5.896923]  #1:  (&dev->mutex){......}, at: [<c049598c>] __driver_attach+0x70/0xac
      [    5.896946]  #2:  (tll_lock){+.+...}, at: [<c04c2630>] omap_tll_enable+0x2c/0xd0
      [    5.896966]  #3:  (prepare_lock){+.+...}, at: [<c05ce9c8>] clk_prepare_lock+0x48/0xe0
      [    5.897042] Modules linked in: wlcore_sdio(+) ehci_omap(+) dwc3_omap snd_soc_ts3a225e leds_is31fl319x bq27xxx_battery_i2c tsc2007 bq27xxx_battery bq2429x_charger ina2xx tca8418_keypad as5013 leds_tca6507 twl6040_vibra gpio_twl6040 bmp085_i2c(+) palmas_gpadc usb3503 palmas_pwrbutton bmg160_i2c(+) bmp085 bma150(+) bmg160_core bmp280 input_polldev snd_soc_omap_mcbsp snd_soc_omap_mcpdm snd_soc_omap snd_pcm_dmaengine
      [    5.897048] Preemption disabled at:[<  (null)>]   (null)
      [    5.897051]
      [    5.897059] CPU: 0 PID: 994 Comm: udevd Not tainted 4.6.0-rc5-letux+ #233
      [    5.897062] Hardware name: Generic OMAP5 (Flattened Device Tree)
      [    5.897076] [<c010e714>] (unwind_backtrace) from [<c010af34>] (show_stack+0x10/0x14)
      [    5.897087] [<c010af34>] (show_stack) from [<c040aa7c>] (dump_stack+0x88/0xc0)
      [    5.897099] [<c040aa7c>] (dump_stack) from [<c020c558>] (__schedule_bug+0xac/0xd0)
      [    5.897111] [<c020c558>] (__schedule_bug) from [<c06f3d44>] (__schedule+0x88/0x7e4)
      [    5.897120] [<c06f3d44>] (__schedule) from [<c06f46d8>] (schedule+0x9c/0xc0)
      [    5.897129] [<c06f46d8>] (schedule) from [<c06f4904>] (schedule_preempt_disabled+0x14/0x20)
      [    5.897140] [<c06f4904>] (schedule_preempt_disabled) from [<c06f64e4>] (mutex_lock_nested+0x258/0x43c)
      [    5.897150] [<c06f64e4>] (mutex_lock_nested) from [<c05ce9c8>] (clk_prepare_lock+0x48/0xe0)
      [    5.897160] [<c05ce9c8>] (clk_prepare_lock) from [<c05d0e7c>] (clk_prepare+0x10/0x28)
      [    5.897169] [<c05d0e7c>] (clk_prepare) from [<c04c2668>] (omap_tll_enable+0x64/0xd0)
      [    5.897180] [<c04c2668>] (omap_tll_enable) from [<c04c1728>] (usbhs_runtime_resume+0x18/0x17c)
      [    5.897192] [<c04c1728>] (usbhs_runtime_resume) from [<c049d404>] (pm_generic_runtime_resume+0x2c/0x40)
      [    5.897202] [<c049d404>] (pm_generic_runtime_resume) from [<c049f180>] (__rpm_callback+0x38/0x68)
      [    5.897210] [<c049f180>] (__rpm_callback) from [<c049f220>] (rpm_callback+0x70/0x88)
      [    5.897218] [<c049f220>] (rpm_callback) from [<c04a0a00>] (rpm_resume+0x4ec/0x7ec)
      [    5.897227] [<c04a0a00>] (rpm_resume) from [<c04a0f48>] (__pm_runtime_resume+0x4c/0x64)
      [    5.897236] [<c04a0f48>] (__pm_runtime_resume) from [<c04958dc>] (driver_probe_device+0x30/0x70)
      [    5.897246] [<c04958dc>] (driver_probe_device) from [<c04959a4>] (__driver_attach+0x88/0xac)
      [    5.897256] [<c04959a4>] (__driver_attach) from [<c04940f8>] (bus_for_each_dev+0x50/0x84)
      [    5.897267] [<c04940f8>] (bus_for_each_dev) from [<c0494e40>] (bus_add_driver+0xcc/0x1e4)
      [    5.897276] [<c0494e40>] (bus_add_driver) from [<c0496914>] (driver_register+0xac/0xf4)
      [    5.897286] [<c0496914>] (driver_register) from [<c01018e0>] (do_one_initcall+0x100/0x1b8)
      [    5.897296] [<c01018e0>] (do_one_initcall) from [<c01c7a54>] (do_init_module+0x58/0x1c0)
      [    5.897304] [<c01c7a54>] (do_init_module) from [<c01c8a3c>] (SyS_finit_module+0x88/0x90)
      [    5.897313] [<c01c8a3c>] (SyS_finit_module) from [<c0107120>] (ret_fast_syscall+0x0/0x1c)
      [    5.912697] ------------[ cut here ]------------
      [    5.912711] WARNING: CPU: 0 PID: 994 at kernel/sched/core.c:2996 _raw_spin_unlock+0x28/0x58
      [    5.912717] DEBUG_LOCKS_WARN_ON(val > preempt_count())
      
      Cc: <stable@vger.kernel.org>
      Reported-by: default avatarH. Nikolaus Schaller <hns@goldelico.com>
      Tested-by: default avatarH. Nikolaus Schaller <hns@goldelico.com>
      Signed-off-by: default avatarRoger Quadros <rogerq@ti.com>
      Signed-off-by: default avatarLee Jones <lee.jones@linaro.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      ec391566
  2. 04 Jun, 2016 1 commit
  3. 03 Jun, 2016 20 commits
    • James Hogan's avatar
      MIPS: Avoid using unwind_stack() with usermode · c2915ee9
      James Hogan authored
      [ Upstream commit 81a76d71 ]
      
      When showing backtraces in response to traps, for example crashes and
      address errors (usually unaligned accesses) when they are set in debugfs
      to be reported, unwind_stack will be used if the PC was in the kernel
      text address range. However since EVA it is possible for user and kernel
      address ranges to overlap, and even without EVA userland can still
      trigger an address error by jumping to a KSeg0 address.
      
      Adjust the check to also ensure that it was running in kernel mode. I
      don't believe any harm can come of this problem, since unwind_stack() is
      sufficiently defensive, however it is only meant for unwinding kernel
      code, so to be correct it should use the raw backtracing instead.
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Reviewed-by: default avatarLeonid Yegoshin <Leonid.Yegoshin@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Cc: <stable@vger.kernel.org> # 3.15+
      Patchwork: https://patchwork.linux-mips.org/patch/11701/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      (cherry picked from commit d2941a975ac745c607dfb590e92bb30bc352dad9)
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      c2915ee9
    • James Hogan's avatar
      MIPS: Don't unwind to user mode with EVA · dd95033f
      James Hogan authored
      [ Upstream commit a816b306 ]
      
      When unwinding through IRQs and exceptions, the unwinding only continues
      if the PC is a kernel text address, however since EVA it is possible for
      user and kernel address ranges to overlap, potentially allowing
      unwinding to continue to user mode if the user PC happens to be in the
      kernel text address range.
      
      Adjust the check to also ensure that the register state from before the
      exception is actually running in kernel mode, i.e. !user_mode(regs).
      
      I don't believe any harm can come of this problem, since the PC is only
      output, the stack pointer is checked to ensure it resides within the
      task's stack page before it is dereferenced in search of the return
      address, and the return address register is similarly only output (if
      the PC is in a leaf function or the beginning of a non-leaf function).
      
      However unwind_stack() is only meant for unwinding kernel code, so to be
      correct the unwind should stop there.
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Reviewed-by: default avatarLeonid Yegoshin <Leonid.Yegoshin@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Cc: <stable@vger.kernel.org> # 3.15+
      Patchwork: https://patchwork.linux-mips.org/patch/11700/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      dd95033f
    • James Hogan's avatar
      MIPS: Fix siginfo.h to use strict posix types · 22a4a259
      James Hogan authored
      [ Upstream commit 5daebc47 ]
      
      Commit 85efde6f ("make exported headers use strict posix types")
      changed the asm-generic siginfo.h to use the __kernel_* types, and
      commit 3a471cbc ("remove __KERNEL_STRICT_NAMES") make the internal
      types accessible only to the kernel, but the MIPS implementation hasn't
      been updated to match.
      
      Switch to proper types now so that the exported asm/siginfo.h won't
      produce quite so many compiler errors when included alone by a user
      program.
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: Christopher Ferris <cferris@google.com>
      Cc: linux-mips@linux-mips.org
      Cc: <stable@vger.kernel.org> # 2.6.30-
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/12477/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      22a4a259
    • Oliver Hartkopp's avatar
      can: fix handling of unmodifiable configuration options · 5b59ae1e
      Oliver Hartkopp authored
      [ Upstream commit bb208f14 ]
      
      As described in 'can: m_can: tag current CAN FD controllers as non-ISO'
      (6cfda7fb) it is possible to define fixed configuration options by
      setting the according bit in 'ctrlmode' and clear it in 'ctrlmode_supported'.
      This leads to the incovenience that the fixed configuration bits can not be
      passed by netlink even when they have the correct values (e.g. non-ISO, FD).
      
      This patch fixes that issue and not only allows fixed set bit values to be set
      again but now requires(!) to provide these fixed values at configuration time.
      A valid CAN FD configuration consists of a nominal/arbitration bittiming, a
      data bittiming and a control mode with CAN_CTRLMODE_FD set - which is now
      enforced by a new can_validate() function. This fix additionally removed the
      inconsistency that was prohibiting the support of 'CANFD-only' controller
      drivers, like the RCar CAN FD.
      
      For this reason a new helper can_set_static_ctrlmode() has been introduced to
      provide a proper interface to handle static enabled CAN controller options.
      Reported-by: default avatarRamesh Shanmugasundaram <ramesh.shanmugasundaram@bp.renesas.com>
      Signed-off-by: default avatarOliver Hartkopp <socketcan@hartkopp.net>
      Reviewed-by: default avatarRamesh Shanmugasundaram  <ramesh.shanmugasundaram@bp.renesas.com>
      Cc: <stable@vger.kernel.org> # >= 3.18
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      5b59ae1e
    • Catalin Marinas's avatar
      arm64: Ensure pmd_present() returns false after pmd_mknotpresent() · 0839058a
      Catalin Marinas authored
      [ Upstream commit 5bb1cc0f ]
      
      Currently, pmd_present() only checks for a non-zero value, returning
      true even after pmd_mknotpresent() (which only clears the type bits).
      This patch converts pmd_present() to using pte_present(), similar to the
      other pmd_*() checks. As a side effect, it will return true for
      PROT_NONE mappings, though they are not yet used by the kernel with
      transparent huge pages.
      
      For consistency, also change pmd_mknotpresent() to only clear the
      PMD_SECT_VALID bit, even though the PMD_TABLE_BIT is already 0 for block
      mappings (no functional change). The unused PMD_SECT_PROT_NONE
      definition is removed as transparent huge pages use the pte page prot
      values.
      
      Fixes: 9c7e535f ("arm64: mm: Route pmd thp functions through pte equivalents")
      Cc: <stable@vger.kernel.org> # 3.15+
      Reviewed-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      0839058a
    • Nicolai Stange's avatar
      ext4: silence UBSAN in ext4_mb_init() · 7346b874
      Nicolai Stange authored
      [ Upstream commit 935244cd ]
      
      Currently, in ext4_mb_init(), there's a loop like the following:
      
        do {
          ...
          offset += 1 << (sb->s_blocksize_bits - i);
          i++;
        } while (i <= sb->s_blocksize_bits + 1);
      
      Note that the updated offset is used in the loop's next iteration only.
      
      However, at the last iteration, that is at i == sb->s_blocksize_bits + 1,
      the shift count becomes equal to (unsigned)-1 > 31 (c.f. C99 6.5.7(3))
      and UBSAN reports
      
        UBSAN: Undefined behaviour in fs/ext4/mballoc.c:2621:15
        shift exponent 4294967295 is too large for 32-bit type 'int'
        [...]
        Call Trace:
         [<ffffffff818c4d25>] dump_stack+0xbc/0x117
         [<ffffffff818c4c69>] ? _atomic_dec_and_lock+0x169/0x169
         [<ffffffff819411ab>] ubsan_epilogue+0xd/0x4e
         [<ffffffff81941cac>] __ubsan_handle_shift_out_of_bounds+0x1fb/0x254
         [<ffffffff81941ab1>] ? __ubsan_handle_load_invalid_value+0x158/0x158
         [<ffffffff814b6dc1>] ? kmem_cache_alloc+0x101/0x390
         [<ffffffff816fc13b>] ? ext4_mb_init+0x13b/0xfd0
         [<ffffffff814293c7>] ? create_cache+0x57/0x1f0
         [<ffffffff8142948a>] ? create_cache+0x11a/0x1f0
         [<ffffffff821c2168>] ? mutex_lock+0x38/0x60
         [<ffffffff821c23ab>] ? mutex_unlock+0x1b/0x50
         [<ffffffff814c26ab>] ? put_online_mems+0x5b/0xc0
         [<ffffffff81429677>] ? kmem_cache_create+0x117/0x2c0
         [<ffffffff816fcc49>] ext4_mb_init+0xc49/0xfd0
         [...]
      
      Observe that the mentioned shift exponent, 4294967295, equals (unsigned)-1.
      
      Unless compilers start to do some fancy transformations (which at least
      GCC 6.0.0 doesn't currently do), the issue is of cosmetic nature only: the
      such calculated value of offset is never used again.
      
      Silence UBSAN by introducing another variable, offset_incr, holding the
      next increment to apply to offset and adjust that one by right shifting it
      by one position per loop iteration.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=114701
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=112161
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarNicolai Stange <nicstange@gmail.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      7346b874
    • Nicolai Stange's avatar
      ext4: address UBSAN warning in mb_find_order_for_block() · 76caa717
      Nicolai Stange authored
      [ Upstream commit b5cb316c ]
      
      Currently, in mb_find_order_for_block(), there's a loop like the following:
      
        while (order <= e4b->bd_blkbits + 1) {
          ...
          bb += 1 << (e4b->bd_blkbits - order);
        }
      
      Note that the updated bb is used in the loop's next iteration only.
      
      However, at the last iteration, that is at order == e4b->bd_blkbits + 1,
      the shift count becomes negative (c.f. C99 6.5.7(3)) and UBSAN reports
      
        UBSAN: Undefined behaviour in fs/ext4/mballoc.c:1281:11
        shift exponent -1 is negative
        [...]
        Call Trace:
         [<ffffffff818c4d35>] dump_stack+0xbc/0x117
         [<ffffffff818c4c79>] ? _atomic_dec_and_lock+0x169/0x169
         [<ffffffff819411bb>] ubsan_epilogue+0xd/0x4e
         [<ffffffff81941cbc>] __ubsan_handle_shift_out_of_bounds+0x1fb/0x254
         [<ffffffff81941ac1>] ? __ubsan_handle_load_invalid_value+0x158/0x158
         [<ffffffff816e93a0>] ? ext4_mb_generate_from_pa+0x590/0x590
         [<ffffffff816502c8>] ? ext4_read_block_bitmap_nowait+0x598/0xe80
         [<ffffffff816e7b7e>] mb_find_order_for_block+0x1ce/0x240
         [...]
      
      Unless compilers start to do some fancy transformations (which at least
      GCC 6.0.0 doesn't currently do), the issue is of cosmetic nature only: the
      such calculated value of bb is never used again.
      
      Silence UBSAN by introducing another variable, bb_incr, holding the next
      increment to apply to bb and adjust that one by right shifting it by one
      position per loop iteration.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=114701
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=112161
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarNicolai Stange <nicstange@gmail.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      76caa717
    • Jan Kara's avatar
      ext4: fix oops on corrupted filesystem · f245ed01
      Jan Kara authored
      [ Upstream commit 74177f55 ]
      
      When filesystem is corrupted in the right way, it can happen
      ext4_mark_iloc_dirty() in ext4_orphan_add() returns error and we
      subsequently remove inode from the in-memory orphan list. However this
      deletion is done with list_del(&EXT4_I(inode)->i_orphan) and thus we
      leave i_orphan list_head with a stale content. Later we can look at this
      content causing list corruption, oops, or other issues. The reported
      trace looked like:
      
      WARNING: CPU: 0 PID: 46 at lib/list_debug.c:53 __list_del_entry+0x6b/0x100()
      list_del corruption, 0000000061c1d6e0->next is LIST_POISON1
      0000000000100100)
      CPU: 0 PID: 46 Comm: ext4.exe Not tainted 4.1.0-rc4+ #250
      Stack:
       60462947 62219960 602ede24 62219960
       602ede24 603ca293 622198f0 602f02eb
       62219950 6002c12c 62219900 601b4d6b
      Call Trace:
       [<6005769c>] ? vprintk_emit+0x2dc/0x5c0
       [<602ede24>] ? printk+0x0/0x94
       [<600190bc>] show_stack+0xdc/0x1a0
       [<602ede24>] ? printk+0x0/0x94
       [<602ede24>] ? printk+0x0/0x94
       [<602f02eb>] dump_stack+0x2a/0x2c
       [<6002c12c>] warn_slowpath_common+0x9c/0xf0
       [<601b4d6b>] ? __list_del_entry+0x6b/0x100
       [<6002c254>] warn_slowpath_fmt+0x94/0xa0
       [<602f4d09>] ? __mutex_lock_slowpath+0x239/0x3a0
       [<6002c1c0>] ? warn_slowpath_fmt+0x0/0xa0
       [<60023ebf>] ? set_signals+0x3f/0x50
       [<600a205a>] ? kmem_cache_free+0x10a/0x180
       [<602f4e88>] ? mutex_lock+0x18/0x30
       [<601b4d6b>] __list_del_entry+0x6b/0x100
       [<601177ec>] ext4_orphan_del+0x22c/0x2f0
       [<6012f27c>] ? __ext4_journal_start_sb+0x2c/0xa0
       [<6010b973>] ? ext4_truncate+0x383/0x390
       [<6010bc8b>] ext4_write_begin+0x30b/0x4b0
       [<6001bb50>] ? copy_from_user+0x0/0xb0
       [<601aa840>] ? iov_iter_fault_in_readable+0xa0/0xc0
       [<60072c4f>] generic_perform_write+0xaf/0x1e0
       [<600c4166>] ? file_update_time+0x46/0x110
       [<60072f0f>] __generic_file_write_iter+0x18f/0x1b0
       [<6010030f>] ext4_file_write_iter+0x15f/0x470
       [<60094e10>] ? unlink_file_vma+0x0/0x70
       [<6009b180>] ? unlink_anon_vmas+0x0/0x260
       [<6008f169>] ? free_pgtables+0xb9/0x100
       [<600a6030>] __vfs_write+0xb0/0x130
       [<600a61d5>] vfs_write+0xa5/0x170
       [<600a63d6>] SyS_write+0x56/0xe0
       [<6029fcb0>] ? __libc_waitpid+0x0/0xa0
       [<6001b698>] handle_syscall+0x68/0x90
       [<6002633d>] userspace+0x4fd/0x600
       [<6002274f>] ? save_registers+0x1f/0x40
       [<60028bd7>] ? arch_prctl+0x177/0x1b0
       [<60017bd5>] fork_handler+0x85/0x90
      
      Fix the problem by using list_del_init() as we always should with
      i_orphan list.
      
      CC: stable@vger.kernel.org
      Reported-by: default avatarVegard Nossum <vegard.nossum@oracle.com>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      f245ed01
    • Konstantin Shkolnyy's avatar
      USB: serial: cp210x: fix hardware flow-control disable · e4e59834
      Konstantin Shkolnyy authored
      [ Upstream commit a377f9e9 ]
      
      A bug in the CRTSCTS handling caused RTS to alternate between
      
      CRTSCTS=0 => "RTS is transmit active signal" and
      CRTSCTS=1 => "RTS is used for receive flow control"
      
      instead of
      
      CRTSCTS=0 => "RTS is statically active" and
      CRTSCTS=1 => "RTS is used for receive flow control"
      
      This only happened after first having enabled CRTSCTS.
      Signed-off-by: default avatarKonstantin Shkolnyy <konstantin.shkolnyy@gmail.com>
      Fixes: 39a66b8d ("[PATCH] USB: CP2101 Add support for flow control")
      Cc: stable <stable@vger.kernel.org>
      [johan: reword commit message ]
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      e4e59834
    • Konstantin Shkolnyy's avatar
      USB: cp210x: relocate private data from USB interface to port · f26c00e6
      Konstantin Shkolnyy authored
      [ Upstream commit e2ae67a3 ]
      
      This change is preparation for implementing a cp2108 bug workaround.
      The workaround requires storing some private data. Right now the data is
      attached to the USB interface and allocated in the attach() callback.
      The bug detection requires USB I/O which is done easier from port_probe()
      callback rather than attach(). Since the USB access functions take port
      as a parameter, and since the private data is used exclusively by these
      functions, it can be allocated in port_probe(). Also, all cp210x devices
      have exactly 1 port per USB iterface, so moving private data from the USB
      interface to port is trivial.
      Signed-off-by: default avatarKonstantin Shkolnyy <konstantin.shkolnyy@gmail.com>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      f26c00e6
    • Lv Zheng's avatar
      ACPI / osi: Fix an issue that acpi_osi=!* cannot disable ACPICA internal strings · 18a64704
      Lv Zheng authored
      [ Upstream commit 30c9bb0d ]
      
      The order of the _OSI related functionalities is as follows:
      
        acpi_blacklisted()
          acpi_dmi_osi_linux()
            acpi_osi_setup()
          acpi_osi_setup()
            acpi_update_interfaces() if "!*"
            <<<<<<<<<<<<<<<<<<<<<<<<
        parse_args()
          __setup("acpi_osi=")
            acpi_osi_setup_linux()
              acpi_update_interfaces() if "!*"
              <<<<<<<<<<<<<<<<<<<<<<<<
        acpi_early_init()
          acpi_initialize_subsystem()
            acpi_ut_initialize_interfaces()
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        acpi_bus_init()
          acpi_os_initialize1()
            acpi_install_interface_handler(acpi_osi_handler)
            acpi_osi_setup_late()
              acpi_update_interfaces() for "!"
              >>>>>>>>>>>>>>>>>>>>>>>>
        acpi_osi_handler()
      
      Since acpi_osi_setup_linux() can override acpi_dmi_osi_linux(), the command
      line setting can override the DMI detection. That's why acpi_blacklisted()
      is put before __setup("acpi_osi=").
      
      Then we can notice the following wrong invocation order. There are
      acpi_update_interfaces() (marked by <<<<) calls invoked before
      acpi_ut_initialize_interfaces() (marked by ^^^^). This makes it impossible
      to use acpi_osi=!* correctly from OSI DMI table or from the command line.
      The use of acpi_osi=!* is meant to disable both ACPICA
      (acpi_gbl_supported_interfaces) and Linux specific strings
      (osi_setup_entries) while the ACPICA part should have stopped working
      because of the order issue.
      
      This patch fixes this issue by moving acpi_update_interfaces() to where
      it is invoked for acpi_osi=! (marked by >>>>) as this is ensured to be
      invoked after acpi_ut_initialize_interfaces() (marked by ^^^^). Linux
      specific strings are still handled in the original place in order to make
      the following command line working: acpi_osi=!* acpi_osi="Module Device".
      
      Note that since acpi_osi=!* is meant to further disable linux specific
      string comparing to the acpi_osi=!, there is no such use case in our bug
      fixing work and hence there is no one using acpi_osi=!* either from the
      command line or from the DMI quirks, this issue is just a theoretical
      issue.
      
      Fixes: 741d8128 (ACPI: Add facility to remove all _OSI strings)
      Cc: 3.12+ <stable@vger.kernel.org> # 3.12+
      Tested-by: default avatarLukas Wunner <lukas@wunner.de>
      Tested-by: default avatarChen Yu <yu.c.chen@intel.com>
      Signed-off-by: default avatarLv Zheng <lv.zheng@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      18a64704
    • Lei Liu's avatar
      USB: serial: option: add even more ZTE device ids · 4d5aaca6
      Lei Liu authored
      [ Upstream commit 74d2a91a ]
      
      Add even more ZTE device ids.
      Signed-off-by: default avatarlei liu <liu.lei78@zte.com.cn>
      Cc: stable <stable@vger.kernel.org>
      [johan: rebase and replace commit message ]
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      4d5aaca6
    • lei liu's avatar
      USB: serial: option: add more ZTE device ids · feb49862
      lei liu authored
      [ Upstream commit f0d09463 ]
      
      More ZTE device ids.
      Signed-off-by: default avatarlei liu <liu.lei78@zte.com.cn>
      Cc: stable <stable@vger.kernel.org>
      [properly sort them - gregkh]
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      feb49862
    • Andreas Werner's avatar
      mcb: Fixed bar number assignment for the gdd · 39a8fc74
      Andreas Werner authored
      [ Upstream commit f75564d3 ]
      
      The bar number is found in reg2 within the gdd. Therefore
      we need to change the assigment from reg1 to reg2 which
      is the correct location.
      Signed-off-by: default avatarAndreas Werner <andreas.werner@men.de>
      Fixes: '3764e82e' drivers: Introduce MEN Chameleon Bus
      Cc: stable@vger.kernel.org # v3.15+
      Signed-off-by: default avatarJohannes Thumshirn <jthumshirn@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      39a8fc74
    • Mathias Nyman's avatar
      usb: misc: usbtest: fix pattern tests for scatterlists. · 27094468
      Mathias Nyman authored
      [ Upstream commit cdc77c82 ]
      
      The current implemenentation restart the sent pattern for each entry in
      the sg list. The receiving end expects a continuous pattern, and test
      will fail unless scatterilst entries happen to be aligned with the
      pattern
      
      Fix this by calculating the pattern byte based on total sent size
      instead of just the current sg entry.
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Fixes: 8b524901 ("[PATCH] USB: usbtest: scatterlist OUT data pattern testing")
      Cc: <stable@vger.kernel.org> # v2.6.18+
      Acked-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      27094468
    • Alan Stern's avatar
      usb: misc: usbtest: format the data pattern according to max packet size · cf2f44dd
      Alan Stern authored
      [ Upstream commit b9a6e8e1 ]
      
      With this change, the host and gadget doesn't need to agree with transfer
      length for comparing the data, since they doesn't know each other's
      transfer size, but know max packet size.
      Signed-off-by: default avatarPeter Chen <peter.chen@freescale.com>
      Acked-by: default avatarMichal Nazarewicz <mina86@mina86.com>
      (Fixed the 'line over 80 characters warning' by Peter Chen)
      Tested-by: default avatarPeter Chen <peter.chen@freescale.com>
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      cf2f44dd
    • Alan Stern's avatar
      USB: leave LPM alone if possible when binding/unbinding interface drivers · d0270cd8
      Alan Stern authored
      [ Upstream commit 6fb650d4 ]
      
      When a USB driver is bound to an interface (either through probing or
      by claiming it) or is unbound from an interface, the USB core always
      disables Link Power Management during the transition and then
      re-enables it afterward.  The reason is because the driver might want
      to prevent hub-initiated link power transitions, in which case the HCD
      would have to recalculate the various LPM parameters.  This
      recalculation takes place when LPM is re-enabled and the new
      parameters are sent to the device and its parent hub.
      
      However, if the driver does not want to prevent hub-initiated link
      power transitions then none of this work is necessary.  The parameters
      don't need to be recalculated, and LPM doesn't need to be disabled and
      re-enabled.
      
      It turns out that disabling and enabling LPM can be time-consuming,
      enough so that it interferes with user programs that want to claim and
      release interfaces rapidly via usbfs.  Since the usbfs kernel driver
      doesn't set the disable_hub_initiated_lpm flag, we can speed things up
      and get the user programs to work by leaving LPM alone whenever the
      flag isn't set.
      
      And while we're improving the way disable_hub_initiated_lpm gets used,
      let's also fix its kerneldoc.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Tested-by: default avatarMatthew Giassa <matthew@giassa.net>
      CC: Mathias Nyman <mathias.nyman@intel.com>
      CC: <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      d0270cd8
    • Schemmel Hans-Christoph's avatar
      USB: serial: option: add support for Cinterion PH8 and AHxx · 38f005d9
      Schemmel Hans-Christoph authored
      [ Upstream commit 444f94e9 ]
      
      Added support for Gemalto's Cinterion PH8 and AHxx products
      with 2 RmNet Interfaces and products with 1 RmNet + 1 USB Audio interface.
      
      In addition some minor renaming and formatting.
      Signed-off-by: default avatarHans-Christoph Schemmel <hans-christoph.schemmel@gemalto.com>
      [johan: sort current entries and trim trailing whitespace ]
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      38f005d9
    • Andreas Noever's avatar
      thunderbolt: Fix double free of drom buffer · 1dab35a8
      Andreas Noever authored
      [ Upstream commit 2ffa9a5d ]
      
      If tb_drom_read() fails, sw->drom is freed but not set to NULL.  sw->drom
      is then freed again in the error path of tb_switch_alloc().
      
      The bug can be triggered by unplugging a thunderbolt device shortly after
      it is detected by the thunderbolt driver.
      
      Clear sw->drom if tb_drom_read() fails.
      
      [bhelgaas: add Fixes:, stable versions of interest]
      Fixes: 343fcb8c ("thunderbolt: Fix nontrivial endpoint devices.")
      Signed-off-by: default avatarAndreas Noever <andreas.noever@gmail.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      CC: stable@vger.kernel.org	# v3.17+
      CC: Lukas Wunner <lukas@wunner.de>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      1dab35a8
    • Zhao Qiang's avatar
      QE-UART: add "fsl,t1040-ucc-uart" to of_device_id · 4efcad52
      Zhao Qiang authored
      [ Upstream commit 11ca2b7a ]
      
      New bindings use "fsl,t1040-ucc-uart" as the compatible for qe-uart.
      So add it.
      Signed-off-by: default avatarZhao Qiang <qiang.zhao@nxp.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      4efcad52