1. 21 Jul, 2019 40 commits
    • Dave Airlie's avatar
      drm/udl: move to embedding drm device inside udl device. · a5fb6a7e
      Dave Airlie authored
      commit 6ecac85eadb9d4065b9038fa3d3c66d49038e14b upstream.
      
      This should help with some of the lifetime issues, and move us away
      from load/unload.
      
      [rez] Regarding the backport to v4.14.y, the only difference is due to
      the fact that in v4.14.y the udl_usb_probe() function still uses
      drm_dev_unref() instead of drm_dev_put().
      
      Backport notes:
      
      On Mon, Jul 15, 2019 at 09:13:08PM -0400, Sasha Levin wrote:
      > Hm, we don't need ac3b35f11a06 here? Why not? I'd love to document that
      > with the backport.
      
      Nope, we don't need that patch in the v4.14 backport.
      
      In v4.19.y we have two functions, drm_dev_put() and drm_dev_unref(), which are
      aliases for one another (drm_dev_unref() just calls drm_dev_put()).
      drm_dev_unref() is the older of the two, and was introduced back in v4.0.
      drm_dev_put() was introduced in v4.15 with
      
      9a96f550 drm: introduce drm_dev_{get/put} functions
      
      and slowly callers were moved from the old name (_unref) to the new name
      (_put).  The patch you mentioned, ac3b35f11a06, is one such patch where we are
      replacing a drm_dev_unref() call with a drm_dev_put() call.  This doesn't have
      a functional change, but was necessary so that the third patch in the v4.19.y
      series I sent would apply cleanly.
      
      For the v4.14.y series, though, the drm_dev_put() function hasn't yet been
      defined and everyone is still using drm_dev_unref().  So, we don't need a
      backport of ac3b35f11a06, and I also had a small backport change in the last
      patch of the v4.14.y series where I had to change a drm_dev_put() call with a
      drm_dev_unref() call.
      
      Just for posterity, the drm_dev_unref() calls were eventually all changed to
      drm_dev_put() in v5.0, and drm_dev_unref() was removed entirely.  That
      happened with the following two patches:
      
      808bad32ea423 drm: replace "drm_dev_unref" function with "drm_dev_put"
      ba1d345401476 drm: remove deprecated "drm_dev_unref" function
      Acked-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190405031715.5959-4-airlied@gmail.comSigned-off-by: default avatarRoss Zwisler <zwisler@google.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      a5fb6a7e
    • Dave Airlie's avatar
      drm/udl: introduce a macro to convert dev to udl. · 24cb483b
      Dave Airlie authored
      commit fd96e0dba19c53c2d66f2a398716bb74df8ca85e upstream.
      
      This just makes it easier to later embed drm into udl.
      
      [rez] Regarding the backport to v4.14.y, the only difference is due to
      the fact that in v4.14.y the udl_gem_mmap() function doesn't have a
      local 'struct udl_device' pointer so it didn't need to be converted.
      Reviewed-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190405031715.5959-3-airlied@gmail.comSigned-off-by: default avatarRoss Zwisler <zwisler@google.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      24cb483b
    • Haren Myneni's avatar
      crypto/NX: Set receive window credits to max number of CRBs in RxFIFO · 772cabe2
      Haren Myneni authored
      commit e52d484d9869eb291140545746ccbe5ffc7c9306 upstream.
      
      System gets checkstop if RxFIFO overruns with more requests than the
      maximum possible number of CRBs in FIFO at the same time. The max number
      of requests per window is controlled by window credits. So find max
      CRBs from FIFO size and set it to receive window credits.
      
      Fixes: b0d6c9ba ("crypto/nx: Add P9 NX support for 842 compression engine")
      CC: stable@vger.kernel.org # v4.14+
      Signed-off-by: default avatarHaren Myneni <haren@us.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      772cabe2
    • Julian Wiedmann's avatar
      s390/qdio: don't touch the dsci in tiqdio_add_input_queues() · 9583ec77
      Julian Wiedmann authored
      commit ac6639cd3db607d386616487902b4cc1850a7be5 upstream.
      
      Current code sets the dsci to 0x00000080. Which doesn't make any sense,
      as the indicator area is located in the _left-most_ byte.
      
      Worse: if the dsci is the _shared_ indicator, this potentially clears
      the indication of activity for a _different_ device.
      tiqdio_thinint_handler() will then have no reason to call that device's
      IRQ handler, and the device ends up stalling.
      
      Fixes: d0c9d4a8 ("[S390] qdio: set correct bit in dsci")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: default avatarVasily Gorbik <gor@linux.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9583ec77
    • Julian Wiedmann's avatar
      s390/qdio: (re-)initialize tiqdio list entries · a25b1a8f
      Julian Wiedmann authored
      commit e54e4785cb5cb4896cf4285964aeef2125612fb2 upstream.
      
      When tiqdio_remove_input_queues() removes a queue from the tiq_list as
      part of qdio_shutdown(), it doesn't re-initialize the queue's list entry
      and the prev/next pointers go stale.
      
      If a subsequent qdio_establish() fails while sending the ESTABLISH cmd,
      it calls qdio_shutdown() again in QDIO_IRQ_STATE_ERR state and
      tiqdio_remove_input_queues() will attempt to remove the queue entry a
      second time. This dereferences the stale pointers, and bad things ensue.
      Fix this by re-initializing the list entry after removing it from the
      list.
      
      For good practice also initialize the list entry when the queue is first
      allocated, and remove the quirky checks that papered over this omission.
      Note that prior to
      commit e5218134 ("s390/qdio: fix access to uninitialized qdio_q fields"),
      these checks were bogus anyway.
      
      setup_queues_misc() clears the whole queue struct, and thus needs to
      re-init the prev/next pointers as well.
      
      Fixes: 779e6e1c ("[S390] qdio: new qdio driver.")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: default avatarVasily Gorbik <gor@linux.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a25b1a8f
    • Heiko Carstens's avatar
      s390: fix stfle zero padding · 6f477767
      Heiko Carstens authored
      commit 4f18d869ffd056c7858f3d617c71345cf19be008 upstream.
      
      The stfle inline assembly returns the number of double words written
      (condition code 0) or the double words it would have written
      (condition code 3), if the memory array it got as parameter would have
      been large enough.
      
      The current stfle implementation assumes that the array is always
      large enough and clears those parts of the array that have not been
      written to with a subsequent memset call.
      
      If however the array is not large enough memset will get a negative
      length parameter, which means that memset clears memory until it gets
      an exception and the kernel crashes.
      
      To fix this simply limit the maximum length. Move also the inline
      assembly to an extra function to avoid clobbering of register 0, which
      might happen because of the added min_t invocation together with code
      instrumentation.
      
      The bug was introduced with commit 14375bc4 ("[S390] cleanup
      facility list handling") but was rather harmless, since it would only
      write to a rather large array. It became a potential problem with
      commit 3ab121ab ("[S390] kernel: Add z/VM LGR detection"). Since
      then it writes to an array with only four double words, while some
      machines already deliver three double words. As soon as machines have
      a facility bit within the fifth double a crash on IPL would happen.
      
      Fixes: 14375bc4 ("[S390] cleanup facility list handling")
      Cc: <stable@vger.kernel.org> # v2.6.37+
      Reviewed-by: default avatarVasily Gorbik <gor@linux.ibm.com>
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: default avatarVasily Gorbik <gor@linux.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6f477767
    • Arnd Bergmann's avatar
      ARC: hide unused function unw_hdr_alloc · 7498108f
      Arnd Bergmann authored
      commit fd5de2721ea7d16e2b16c4049ac49f229551b290 upstream.
      
      As kernelci.org reports, this function is not used in
      vdk_hs38_defconfig:
      
      arch/arc/kernel/unwind.c:188:14: warning: 'unw_hdr_alloc' defined but not used [-Wunused-function]
      
      Fixes: bc79c9a7 ("ARC: dw2 unwind: Reinstante unwinding out of modules")
      Link: https://kernelci.org/build/id/5d1cae3f59b514300340c132/logs/
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarVineet Gupta <vgupta@synopsys.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7498108f
    • Vinod Koul's avatar
      linux/kernel.h: fix overflow for DIV_ROUND_UP_ULL · 6ad56d51
      Vinod Koul authored
      [ Upstream commit 8f9fab480c7a87b10bb5440b5555f370272a5d59 ]
      
      DIV_ROUND_UP_ULL adds the two arguments and then invokes
      DIV_ROUND_DOWN_ULL.  But on a 32bit system the addition of two 32 bit
      values can overflow.  DIV_ROUND_DOWN_ULL does it correctly and stashes
      the addition into a unsigned long long so cast the result to unsigned
      long long here to avoid the overflow condition.
      
      [akpm@linux-foundation.org: DIV_ROUND_UP_ULL must be an rval]
      Link: http://lkml.kernel.org/r/20190625100518.30753-1-vkoul@kernel.orgSigned-off-by: default avatarVinod Koul <vkoul@kernel.org>
      Reviewed-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      6ad56d51
    • Eiichi Tsukata's avatar
      cpu/hotplug: Fix out-of-bounds read when setting fail state · 8f5e9235
      Eiichi Tsukata authored
      [ Upstream commit 33d4a5a7a5b4d02915d765064b2319e90a11cbde ]
      
      Setting invalid value to /sys/devices/system/cpu/cpuX/hotplug/fail
      can control `struct cpuhp_step *sp` address, results in the following
      global-out-of-bounds read.
      
      Reproducer:
      
        # echo -2 > /sys/devices/system/cpu/cpu0/hotplug/fail
      
      KASAN report:
      
        BUG: KASAN: global-out-of-bounds in write_cpuhp_fail+0x2cd/0x2e0
        Read of size 8 at addr ffffffff89734438 by task bash/1941
      
        CPU: 0 PID: 1941 Comm: bash Not tainted 5.2.0-rc6+ #31
        Call Trace:
         write_cpuhp_fail+0x2cd/0x2e0
         dev_attr_store+0x58/0x80
         sysfs_kf_write+0x13d/0x1a0
         kernfs_fop_write+0x2bc/0x460
         vfs_write+0x1e1/0x560
         ksys_write+0x126/0x250
         do_syscall_64+0xc1/0x390
         entry_SYSCALL_64_after_hwframe+0x49/0xbe
        RIP: 0033:0x7f05e4f4c970
      
        The buggy address belongs to the variable:
         cpu_hotplug_lock+0x98/0xa0
      
        Memory state around the buggy address:
         ffffffff89734300: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 00 00
         ffffffff89734380: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 00 00
        >ffffffff89734400: 00 00 00 00 fa fa fa fa 00 00 00 00 fa fa fa fa
                                                ^
         ffffffff89734480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
         ffffffff89734500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      
      Add a sanity check for the value written from user space.
      
      Fixes: 1db49484 ("smp/hotplug: Hotplug state fail injection")
      Signed-off-by: default avatarEiichi Tsukata <devel@etsukata.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: peterz@infradead.org
      Link: https://lkml.kernel.org/r/20190627024732.31672-1-devel@etsukata.comSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      8f5e9235
    • Kirill A. Shutemov's avatar
      x86/boot/64: Fix crash if kernel image crosses page table boundary · 1642b93f
      Kirill A. Shutemov authored
      [ Upstream commit 81c7ed296dcd02bc0b4488246d040e03e633737a ]
      
      A kernel which boots in 5-level paging mode crashes in a small percentage
      of cases if KASLR is enabled.
      
      This issue was tracked down to the case when the kernel image unpacks in a
      way that it crosses an 1G boundary. The crash is caused by an overrun of
      the PMD page table in __startup_64() and corruption of P4D page table
      allocated next to it. This particular issue is not visible with 4-level
      paging as P4D page tables are not used.
      
      But the P4D and the PUD calculation have similar problems.
      
      The PMD index calculation is wrong due to operator precedence, which fails
      to confine the PMDs in the PMD array on wrap around.
      
      The P4D calculation for 5-level paging and the PUD calculation calculate
      the first index correctly, but then blindly increment it which causes the
      same issue when a kernel image is located across a 512G and for 5-level
      paging across a 46T boundary.
      
      This wrap around mishandling was introduced when these parts moved from
      assembly to C.
      
      Restore it to the correct behaviour.
      
      Fixes: c88d7150 ("x86/boot/64: Rewrite startup_64() in C")
      Signed-off-by: default avatarKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: https://lkml.kernel.org/r/20190620112345.28833-1-kirill.shutemov@linux.intel.comSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      1642b93f
    • Milan Broz's avatar
      dm verity: use message limit for data block corruption message · e5516f59
      Milan Broz authored
      [ Upstream commit 2eba4e640b2c4161e31ae20090a53ee02a518657 ]
      
      DM verity should also use DMERR_LIMIT to limit repeat data block
      corruption messages.
      Signed-off-by: default avatarMilan Broz <gmazyland@gmail.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      e5516f59
    • Sébastien Szymanski's avatar
      ARM: dts: imx6ul: fix PWM[1-4] interrupts · 387decd6
      Sébastien Szymanski authored
      [ Upstream commit 3cf10132ac8d536565f2c02f60a3aeb315863a52 ]
      
      According to the i.MX6UL/L RM, table 3.1 "ARM Cortex A7 domain interrupt
      summary", the interrupts for the PWM[1-4] go from 83 to 86.
      
      Fixes: b9901fe8 ("ARM: dts: imx6ul: add pwm[1-4] nodes")
      Signed-off-by: default avatarSébastien Szymanski <sebastien.szymanski@armadeus.com>
      Reviewed-by: default avatarFabio Estevam <festevam@gmail.com>
      Signed-off-by: default avatarShawn Guo <shawnguo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      387decd6
    • Sergej Benilov's avatar
      sis900: fix TX completion · d2bbc75a
      Sergej Benilov authored
      [ Upstream commit 8ac8a01092b2added0749ef937037bf1912e13e3 ]
      
      Since commit 605ad7f1 "tcp: refine TSO autosizing",
      outbound throughput is dramatically reduced for some connections, as sis900
      is doing TX completion within idle states only.
      
      Make TX completion happen after every transmitted packet.
      
      Test:
      netperf
      
      before patch:
      > netperf -H remote -l -2000000 -- -s 1000000
      MIGRATED TCP STREAM TEST from 0.0.0.0 () port 0 AF_INET to 95.223.112.76 () port 0 AF_INET : demo
      Recv   Send    Send
      Socket Socket  Message  Elapsed
      Size   Size    Size     Time     Throughput
      bytes  bytes   bytes    secs.    10^6bits/sec
      
       87380 327680 327680    253.44      0.06
      
      after patch:
      > netperf -H remote -l -10000000 -- -s 1000000
      MIGRATED TCP STREAM TEST from 0.0.0.0 () port 0 AF_INET to 95.223.112.76 () port 0 AF_INET : demo
      Recv   Send    Send
      Socket Socket  Message  Elapsed
      Size   Size    Size     Time     Throughput
      bytes  bytes   bytes    secs.    10^6bits/sec
      
       87380 327680 327680    5.38       14.89
      
      Thx to Dave Miller and Eric Dumazet for helpful hints
      Signed-off-by: default avatarSergej Benilov <sergej.benilov@googlemail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      d2bbc75a
    • Takashi Iwai's avatar
      ppp: mppe: Add softdep to arc4 · 297ab0a0
      Takashi Iwai authored
      [ Upstream commit aad1dcc4f011ea409850e040363dff1e59aa4175 ]
      
      The arc4 crypto is mandatory at ppp_mppe probe time, so let's put a
      softdep line, so that the corresponding module gets prepared
      gracefully.  Without this, a simple inclusion to initrd via dracut
      failed due to the missing dependency, for example.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      297ab0a0
    • Petr Oros's avatar
      be2net: fix link failure after ethtool offline test · 67320a0d
      Petr Oros authored
      [ Upstream commit 2e5db6eb3c23e5dc8171eb8f6af7a97ef9fcf3a9 ]
      
      Certain cards in conjunction with certain switches need a little more
      time for link setup that results in ethtool link test failure after
      offline test. Patch adds a loop that waits for a link setup finish.
      
      Changes in v2:
      - added fixes header
      
      Fixes: 4276e47e ("be2net: Add link test to list of ethtool self tests.")
      Signed-off-by: default avatarPetr Oros <poros@redhat.com>
      Reviewed-by: default avatarIvan Vecera <ivecera@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      67320a0d
    • Arnd Bergmann's avatar
      ARM: omap2: remove incorrect __init annotation · 3ef2115d
      Arnd Bergmann authored
      [ Upstream commit 27e23d8975270df6999f8b5b3156fc0c04927451 ]
      
      omap3xxx_prm_enable_io_wakeup() is marked __init, but its caller is not, so
      we get a warning with clang-8:
      
      WARNING: vmlinux.o(.text+0x343c8): Section mismatch in reference from the function omap3xxx_prm_late_init() to the function .init.text:omap3xxx_prm_enable_io_wakeup()
      The function omap3xxx_prm_late_init() references
      the function __init omap3xxx_prm_enable_io_wakeup().
      This is often because omap3xxx_prm_late_init lacks a __init
      annotation or the annotation of omap3xxx_prm_enable_io_wakeup is wrong.
      
      When building with gcc, omap3xxx_prm_enable_io_wakeup() is always
      inlined, so we never noticed in the past.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Acked-by: default avatarTony Lindgren <tony@atomide.com>
      Reviewed-by: default avatarAndrew Murray <andrew.murray@arm.com>
      Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      3ef2115d
    • Peter Zijlstra's avatar
      perf/core: Fix perf_sample_regs_user() mm check · a68c5a52
      Peter Zijlstra authored
      [ Upstream commit 085ebfe937d7a7a5df1729f35a12d6d655fea68c ]
      
      perf_sample_regs_user() uses 'current->mm' to test for the presence of
      userspace, but this is insufficient, consider use_mm().
      
      A better test is: '!(current->flags & PF_KTHREAD)', exec() clears
      PF_KTHREAD after it sets the new ->mm but before it drops to userspace
      for the first time.
      
      Possibly obsoletes: bf05fc25 ("powerpc/perf: Fix oops when kthread execs user process")
      Reported-by: default avatarRavi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
      Reported-by: default avatarYoung Xiao <92siuyang@gmail.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Fixes: 4018994f ("perf: Add ability to attach user level registers dump to sample")
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      a68c5a52
    • Hans de Goede's avatar
      efi/bgrt: Drop BGRT status field reserved bits check · 555c2ac6
      Hans de Goede authored
      [ Upstream commit a483fcab38b43fb34a7f12ab1daadd3907f150e2 ]
      
      Starting with ACPI 6.2 bits 1 and 2 of the BGRT status field are no longer
      reserved. These bits are now used to indicate if the image needs to be
      rotated before being displayed.
      
      The first device using these bits has now shown up (the GPD MicroPC) and
      the reserved bits check causes us to reject the valid BGRT table on this
      device.
      
      Rather then changing the reserved bits check, allowing only the 2 new bits,
      instead just completely remove it so that we do not end up with a similar
      problem when more bits are added in the future.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      555c2ac6
    • Tony Lindgren's avatar
      clk: ti: clkctrl: Fix returning uninitialized data · 01894d27
      Tony Lindgren authored
      [ Upstream commit 41b3588dba6ef4b7995735a97e47ff0aeea6c276 ]
      
      If we do a clk_get() for a clock that does not exists, we have
      _ti_omap4_clkctrl_xlate() return uninitialized data if no match
      is found. This can be seen in some cases with SLAB_DEBUG enabled:
      
      Unable to handle kernel paging request at virtual address 5a5a5a5a
      ...
      clk_hw_create_clk.part.33
      sysc_notifier_call
      notifier_call_chain
      blocking_notifier_call_chain
      device_add
      
      Let's fix this by setting a found flag only when we find a match.
      Reported-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      Fixes: 88a17252 ("clk: ti: add support for clkctrl clocks")
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      Tested-by: default avatarPeter Ujfalusi <peter.ujfalusi@ti.com>
      Tested-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      Signed-off-by: default avatarStephen Boyd <sboyd@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      01894d27
    • Sean Young's avatar
      MIPS: Remove superfluous check for __linux__ · 8fe38c0e
      Sean Young authored
      commit 1287533d3d95d5ad8b02773733044500b1be06bc upstream.
      
      When building BPF code using "clang -target bpf -c", clang does not
      define __linux__.
      
      To build BPF IR decoders the include linux/lirc.h is needed which
      includes linux/types.h. Currently this workaround is needed:
      
      https://git.linuxtv.org/v4l-utils.git/commit/?id=dd3ff81f58c4e1e6f33765dc61ad33c48ae6bb07
      
      This check might otherwise be useful to stop users from using a non-linux
      compiler, but if you're doing that you are going to have a lot more
      trouble anyway.
      Signed-off-by: default avatarSean Young <sean@mess.org>
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/21149/
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Cc: Hauke Mehrtens <hauke@hauke-m.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8fe38c0e
    • Vishnu DASA's avatar
      VMCI: Fix integer overflow in VMCI handle arrays · 17fcbc4a
      Vishnu DASA authored
      commit 1c2eb5b2853c9f513690ba6b71072d8eb65da16a upstream.
      
      The VMCI handle array has an integer overflow in
      vmci_handle_arr_append_entry when it tries to expand the array. This can be
      triggered from a guest, since the doorbell link hypercall doesn't impose a
      limit on the number of doorbell handles that a VM can create in the
      hypervisor, and these handles are stored in a handle array.
      
      In this change, we introduce a mandatory max capacity for handle
      arrays/lists to avoid excessive memory usage.
      Signed-off-by: default avatarVishnu Dasa <vdasa@vmware.com>
      Reviewed-by: default avatarAdit Ranadive <aditr@vmware.com>
      Reviewed-by: default avatarJorgen Hansen <jhansen@vmware.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      17fcbc4a
    • Christian Lamparter's avatar
      carl9170: fix misuse of device driver API · e178cbbc
      Christian Lamparter authored
      commit feb09b2933275a70917a869989ea2823e7356be8 upstream.
      
      This patch follows Alan Stern's recent patch:
      "p54: Fix race between disconnect and firmware loading"
      
      that overhauled carl9170 buggy firmware loading and driver
      unbinding procedures.
      
      Since the carl9170 code was adapted from p54 it uses the
      same functions and is likely to have the same problem, but
      it's just that the syzbot hasn't reproduce them (yet).
      
      a summary from the changes (copied from the p54 patch):
       * Call usb_driver_release_interface() rather than
         device_release_driver().
      
       * Lock udev (the interface's parent) before unbinding the
         driver instead of locking udev->parent.
      
       * During the firmware loading process, take a reference
         to the USB interface instead of the USB device.
      
       * Don't take an unnecessary reference to the device during
         probe (and then don't drop it during disconnect).
      
      and
      
       * Make sure to prevent use-after-free bugs by explicitly
         setting the driver context to NULL after signaling the
         completion.
      
      Cc: <stable@vger.kernel.org>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarChristian Lamparter <chunkeey@gmail.com>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e178cbbc
    • Todd Kjos's avatar
      binder: fix memory leak in error path · 67f6f4a6
      Todd Kjos authored
      commit 1909a671dbc3606685b1daf8b22a16f65ea7edda upstream.
      
      syzkallar found a 32-byte memory leak in a rarely executed error
      case. The transaction complete work item was not freed if put_user()
      failed when writing the BR_TRANSACTION_COMPLETE to the user command
      buffer. Fixed by freeing it before put_user() is called.
      
      Reported-by: syzbot+182ce46596c3f2e1eb24@syzkaller.appspotmail.com
      Signed-off-by: default avatarTodd Kjos <tkjos@google.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      67f6f4a6
    • Ian Abbott's avatar
      staging: comedi: amplc_pci230: fix null pointer deref on interrupt · cea29db6
      Ian Abbott authored
      commit 7379e6baeddf580d01feca650ec1ad508b6ea8ee upstream.
      
      The interrupt handler `pci230_interrupt()` causes a null pointer
      dereference for a PCI260 card.  There is no analog output subdevice for
      a PCI260.  The `dev->write_subdev` subdevice pointer and therefore the
      `s_ao` subdevice pointer variable will be `NULL` for a PCI260.  The
      following call near the end of the interrupt handler results in the null
      pointer dereference for a PCI260:
      
      	comedi_handle_events(dev, s_ao);
      
      Fix it by only calling the above function if `s_ao` is valid.
      
      Note that the other uses of `s_ao` in the calls
      `pci230_handle_ao_nofifo(dev, s_ao);` and `pci230_handle_ao_fifo(dev,
      s_ao);` will never be reached for a PCI260, so they are safe.
      
      Fixes: 39064f23 ("staging: comedi: amplc_pci230: use comedi_handle_events()")
      Cc: <stable@vger.kernel.org> # v3.19+
      Signed-off-by: default avatarIan Abbott <abbotti@mev.co.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cea29db6
    • Ian Abbott's avatar
      staging: comedi: dt282x: fix a null pointer deref on interrupt · a1fcfe09
      Ian Abbott authored
      commit b8336be66dec06bef518030a0df9847122053ec5 upstream.
      
      The interrupt handler `dt282x_interrupt()` causes a null pointer
      dereference for those supported boards that have no analog output
      support.  For these boards, `dev->write_subdev` will be `NULL` and
      therefore the `s_ao` subdevice pointer variable will be `NULL`.  In that
      case, the following call near the end of the interrupt handler results
      in a null pointer dereference:
      
      	comedi_handle_events(dev, s_ao);
      
      Fix it by only calling the above function if `s_ao` is valid.
      
      (There are other uses of `s_ao` by the interrupt handler that may or may
      not be reached depending on values of hardware registers.  Trust that
      they are reliable for now.)
      
      Note:
      commit 4f6f009b ("staging: comedi: dt282x: use comedi_handle_events()")
      propagates an earlier error from
      commit f21c74fa ("staging: comedi: dt282x: use cfc_handle_events()").
      
      Fixes: 4f6f009b ("staging: comedi: dt282x: use comedi_handle_events()")
      Cc: <stable@vger.kernel.org> # v3.19+
      Signed-off-by: default avatarIan Abbott <abbotti@mev.co.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a1fcfe09
    • Yoshihiro Shimoda's avatar
      usb: renesas_usbhs: add a workaround for a race condition of workqueue · 769b7aa4
      Yoshihiro Shimoda authored
      commit b2357839c56ab7d06bcd4e866ebc2d0e2b7997f3 upstream.
      
      The old commit 6e4b74e4 ("usb: renesas: fix scheduling in atomic
      context bug") fixed an atomic issue by using workqueue for the shdmac
      dmaengine driver. However, this has a potential race condition issue
      between the work pending and usbhsg_ep_free_request() in gadget mode.
      When usbhsg_ep_free_request() is called while pending the queue,
      since the work_struct will be freed and then the work handler is
      called, kernel panic happens on process_one_work().
      
      To fix the issue, if we could call cancel_work_sync() at somewhere
      before the free request, it could be easy. However,
      the usbhsg_ep_free_request() is called on atomic (e.g. f_ncm driver
      calls free request via gether_disconnect()).
      
      For now, almost all users are having "USB-DMAC" and the DMAengine
      driver can be used on atomic. So, this patch adds a workaround for
      a race condition to call the DMAengine APIs without the workqueue.
      
      This means we still have TODO on shdmac environment (SH7724), but
      since it doesn't have SMP, the race condition might not happen.
      
      Fixes: ab330cf3 ("usb: renesas_usbhs: add support for USB-DMAC")
      Cc: <stable@vger.kernel.org> # v4.1+
      Signed-off-by: default avatarYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      769b7aa4
    • Kiruthika Varadarajan's avatar
      usb: gadget: ether: Fix race between gether_disconnect and rx_submit · 052a14ec
      Kiruthika Varadarajan authored
      commit d29fcf7078bc8be2b6366cbd4418265b53c94fac upstream.
      
      On spin lock release in rx_submit, gether_disconnect get a chance to
      run, it makes port_usb NULL, rx_submit access NULL port USB, hence null
      pointer crash.
      
      Fixed by releasing the lock in rx_submit after port_usb is used.
      
      Fixes: 2b3d942c ("usb ethernet gadget: split out network core")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarKiruthika Varadarajan <Kiruthika.Varadarajan@harman.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      052a14ec
    • Alan Stern's avatar
      p54usb: Fix race between disconnect and firmware loading · c760ecb7
      Alan Stern authored
      commit 6e41e2257f1094acc37618bf6c856115374c6922 upstream.
      
      The syzbot fuzzer found a bug in the p54 USB wireless driver.  The
      issue involves a race between disconnect and the firmware-loader
      callback routine, and it has several aspects.
      
      One big problem is that when the firmware can't be loaded, the
      callback routine tries to unbind the driver from the USB _device_ (by
      calling device_release_driver) instead of from the USB _interface_ to
      which it is actually bound (by calling usb_driver_release_interface).
      
      The race involves access to the private data structure.  The driver's
      disconnect handler waits for a completion that is signalled by the
      firmware-loader callback routine.  As soon as the completion is
      signalled, you have to assume that the private data structure may have
      been deallocated by the disconnect handler -- even if the firmware was
      loaded without errors.  However, the callback routine does access the
      private data several times after that point.
      
      Another problem is that, in order to ensure that the USB device
      structure hasn't been freed when the callback routine runs, the driver
      takes a reference to it.  This isn't good enough any more, because now
      that the callback routine calls usb_driver_release_interface, it has
      to ensure that the interface structure hasn't been freed.
      
      Finally, the driver takes an unnecessary reference to the USB device
      structure in the probe function and drops the reference in the
      disconnect handler.  This extra reference doesn't accomplish anything,
      because the USB core already guarantees that a device structure won't
      be deallocated while a driver is still bound to any of its interfaces.
      
      To fix these problems, this patch makes the following changes:
      
      	Call usb_driver_release_interface() rather than
      	device_release_driver().
      
      	Don't signal the completion until after the important
      	information has been copied out of the private data structure,
      	and don't refer to the private data at all thereafter.
      
      	Lock udev (the interface's parent) before unbinding the driver
      	instead of locking udev->parent.
      
      	During the firmware loading process, take a reference to the
      	USB interface instead of the USB device.
      
      	Don't take an unnecessary reference to the device during probe
      	(and then don't drop it during disconnect).
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Reported-and-tested-by: syzbot+200d4bb11b23d929335f@syzkaller.appspotmail.com
      CC: <stable@vger.kernel.org>
      Acked-by: default avatarChristian Lamparter <chunkeey@gmail.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c760ecb7
    • Oliver Barta's avatar
      Revert "serial: 8250: Don't service RX FIFO if interrupts are disabled" · 658a16c5
      Oliver Barta authored
      commit 3f2640ed7be838c3f05c0d2b0f7c7508e7431e48 upstream.
      
      This reverts commit 2e9fe539.
      
      Reading LSR unconditionally but processing the error flags only if
      UART_IIR_RDI bit was set before in IIR may lead to a loss of transmission
      error information on UARTs where the transmission error flags are cleared
      by a read of LSR. Information are lost in case an error is detected right
      before the read of LSR while processing e.g. an UART_IIR_THRI interrupt.
      Signed-off-by: default avatarOliver Barta <o.barta89@gmail.com>
      Reviewed-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Fixes: 2e9fe539 ("serial: 8250: Don't service RX FIFO if interrupts are disabled")
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      658a16c5
    • Jörgen Storvist's avatar
      USB: serial: option: add support for GosunCn ME3630 RNDIS mode · 771340b0
      Jörgen Storvist authored
      commit aed2a26283528fb69c38e414f649411aa48fb391 upstream.
      
      Added USB IDs for GosunCn ME3630 cellular module in RNDIS mode.
      
      T:  Bus=03 Lev=01 Prnt=01 Port=01 Cnt=03 Dev#= 18 Spd=480 MxCh= 0
      D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
      P:  Vendor=19d2 ProdID=0601 Rev=03.18
      S:  Manufacturer=Android
      S:  Product=Android
      S:  SerialNumber=b950269c
      C:  #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA
      I:  If#=0x0 Alt= 0 #EPs= 1 Cls=e0(wlcon) Sub=01 Prot=03 Driver=rndis_host
      I:  If#=0x1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=rndis_host
      I:  If#=0x2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
      I:  If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      Signed-off-by: default avatarJörgen Storvist <jorgen.storvist@gmail.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      771340b0
    • Andreas Fritiofson's avatar
      USB: serial: ftdi_sio: add ID for isodebug v1 · 5b549d50
      Andreas Fritiofson authored
      commit f8377eff548170e8ea8022c067a1fbdf9e1c46a8 upstream.
      
      This adds the vid:pid of the isodebug v1 isolated JTAG/SWD+UART. Only the
      second channel is available for use as a serial port.
      Signed-off-by: default avatarAndreas Fritiofson <andreas.fritiofson@unjo.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5b549d50
    • Brian Norris's avatar
      mwifiex: Don't abort on small, spec-compliant vendor IEs · ced121ed
      Brian Norris authored
      commit 63d7ef36103d26f20325a921ecc96a3288560146 upstream.
      
      Per the 802.11 specification, vendor IEs are (at minimum) only required
      to contain an OUI. A type field is also included in ieee80211.h (struct
      ieee80211_vendor_ie) but doesn't appear in the specification. The
      remaining fields (subtype, version) are a convention used in WMM
      headers.
      
      Thus, we should not reject vendor-specific IEs that have only the
      minimum length (3 bytes) -- we should skip over them (since we only want
      to match longer IEs, that match either WMM or WPA formats). We can
      reject elements that don't have the minimum-required 3 byte OUI.
      
      While we're at it, move the non-standard subtype and version fields into
      the WMM structs, to avoid this confusion in the future about generic
      "vendor header" attributes.
      
      Fixes: 685c9b7750bf ("mwifiex: Abort at too short BSS descriptor element")
      Cc: Takashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarBrian Norris <briannorris@chromium.org>
      Reviewed-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ced121ed
    • Takashi Iwai's avatar
      mwifiex: Fix heap overflow in mwifiex_uap_parse_tail_ies() · b1459fb3
      Takashi Iwai authored
      commit 69ae4f6aac1578575126319d3f55550e7e440449 upstream.
      
      A few places in mwifiex_uap_parse_tail_ies() perform memcpy()
      unconditionally, which may lead to either buffer overflow or read over
      boundary.
      
      This patch addresses the issues by checking the read size and the
      destination size at each place more properly.  Along with the fixes,
      the patch cleans up the code slightly by introducing a temporary
      variable for the token size, and unifies the error path with the
      standard goto statement.
      Reported-by: default avatarhuangwen <huangwen@venustech.com.cn>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b1459fb3
    • Takashi Iwai's avatar
      mwifiex: Abort at too short BSS descriptor element · ebd45bdd
      Takashi Iwai authored
      commit 685c9b7750bfacd6fc1db50d86579980593b7869 upstream.
      
      Currently mwifiex_update_bss_desc_with_ie() implicitly assumes that
      the source descriptor entries contain the enough size for each type
      and performs copying without checking the source size.  This may lead
      to read over boundary.
      
      Fix this by putting the source size check in appropriate places.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ebd45bdd
    • Tim Chen's avatar
      Documentation: Add section about CPU vulnerabilities for Spectre · d30cb648
      Tim Chen authored
      commit 6e88559470f581741bcd0f2794f9054814ac9740 upstream.
      
      Add documentation for Spectre vulnerability and the mitigation mechanisms:
      
      - Explain the problem and risks
      - Document the mitigation mechanisms
      - Document the command line controls
      - Document the sysfs files
      Co-developed-by: default avatarAndi Kleen <ak@linux.intel.com>
      Signed-off-by: default avatarAndi Kleen <ak@linux.intel.com>
      Co-developed-by: default avatarTim Chen <tim.c.chen@linux.intel.com>
      Signed-off-by: default avatarTim Chen <tim.c.chen@linux.intel.com>
      Reviewed-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Reviewed-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJonathan Corbet <corbet@lwn.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d30cb648
    • Dianzhang Chen's avatar
      x86/tls: Fix possible spectre-v1 in do_get_thread_area() · 30a9b8b4
      Dianzhang Chen authored
      commit 993773d11d45c90cb1c6481c2638c3d9f092ea5b upstream.
      
      The index to access the threads tls array is controlled by userspace
      via syscall: sys_ptrace(), hence leading to a potential exploitation
      of the Spectre variant 1 vulnerability.
      
      The index can be controlled from:
              ptrace -> arch_ptrace -> do_get_thread_area.
      
      Fix this by sanitizing the user supplied index before using it to access
      the p->thread.tls_array.
      Signed-off-by: default avatarDianzhang Chen <dianzhangchen0@gmail.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: bp@alien8.de
      Cc: hpa@zytor.com
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/1561524630-3642-1-git-send-email-dianzhangchen0@gmail.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      30a9b8b4
    • Dianzhang Chen's avatar
      x86/ptrace: Fix possible spectre-v1 in ptrace_get_debugreg() · f41c1f4e
      Dianzhang Chen authored
      commit 31a2fbb390fee4231281b939e1979e810f945415 upstream.
      
      The index to access the threads ptrace_bps is controlled by userspace via
      syscall: sys_ptrace(), hence leading to a potential exploitation of the
      Spectre variant 1 vulnerability.
      
      The index can be controlled from:
          ptrace -> arch_ptrace -> ptrace_get_debugreg.
      
      Fix this by sanitizing the user supplied index before using it access
      thread->ptrace_bps.
      Signed-off-by: default avatarDianzhang Chen <dianzhangchen0@gmail.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: bp@alien8.de
      Cc: hpa@zytor.com
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/1561476617-3759-1-git-send-email-dianzhangchen0@gmail.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f41c1f4e
    • Douglas Anderson's avatar
      block, bfq: NULL out the bic when it's no longer valid · 340a4da3
      Douglas Anderson authored
      commit dbc3117d4ca9e17819ac73501e914b8422686750 upstream.
      
      In reboot tests on several devices we were seeing a "use after free"
      when slub_debug or KASAN was enabled.  The kernel complained about:
      
        Unable to handle kernel paging request at virtual address 6b6b6c2b
      
      ...which is a classic sign of use after free under slub_debug.  The
      stack crawl in kgdb looked like:
      
       0  test_bit (addr=<optimized out>, nr=<optimized out>)
       1  bfq_bfqq_busy (bfqq=<optimized out>)
       2  bfq_select_queue (bfqd=<optimized out>)
       3  __bfq_dispatch_request (hctx=<optimized out>)
       4  bfq_dispatch_request (hctx=<optimized out>)
       5  0xc056ef00 in blk_mq_do_dispatch_sched (hctx=0xed249440)
       6  0xc056f728 in blk_mq_sched_dispatch_requests (hctx=0xed249440)
       7  0xc0568d24 in __blk_mq_run_hw_queue (hctx=0xed249440)
       8  0xc0568d94 in blk_mq_run_work_fn (work=<optimized out>)
       9  0xc024c5c4 in process_one_work (worker=0xec6d4640, work=0xed249480)
       10 0xc024cff4 in worker_thread (__worker=0xec6d4640)
      
      Digging in kgdb, it could be found that, though bfqq looked fine,
      bfqq->bic had been freed.
      
      Through further digging, I postulated that perhaps it is illegal to
      access a "bic" (AKA an "icq") after bfq_exit_icq() had been called
      because the "bic" can be freed at some point in time after this call
      is made.  I confirmed that there certainly were cases where the exact
      crashing code path would access the "bic" after bfq_exit_icq() had
      been called.  Sspecifically I set the "bfqq->bic" to (void *)0x7 and
      saw that the bic was 0x7 at the time of the crash.
      
      To understand a bit more about why this crash was fairly uncommon (I
      saw it only once in a few hundred reboots), you can see that much of
      the time bfq_exit_icq_fbqq() fully frees the bfqq and thus it can't
      access the ->bic anymore.  The only case it doesn't is if
      bfq_put_queue() sees a reference still held.
      
      However, even in the case when bfqq isn't freed, the crash is still
      rare.  Why?  I tracked what happened to the "bic" after the exit
      routine.  It doesn't get freed right away.  Rather,
      put_io_context_active() eventually called put_io_context() which
      queued up freeing on a workqueue.  The freeing then actually happened
      later than that through call_rcu().  Despite all these delays, some
      extra debugging showed that all the hoops could be jumped through in
      time and the memory could be freed causing the original crash.  Phew!
      
      To make a long story short, assuming it truly is illegal to access an
      icq after the "exit_icq" callback is finished, this patch is needed.
      
      Cc: stable@vger.kernel.org
      Reviewed-by: default avatarPaolo Valente <paolo.valente@unimore.it>
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      340a4da3
    • Kailang Yang's avatar
      ALSA: hda/realtek - Headphone Mic can't record after S3 · 1f1d1d8e
      Kailang Yang authored
      commit d07a9a4f66e944fcc900812cbc2f6817bde6a43d upstream.
      
      Dell headset mode platform with ALC236.
      It doesn't recording after system resume from S3.
      S3 mode was deep. s2idle was not has this issue.
      S3 deep will cut of codec power. So, the register will back to default
      after resume back.
      This patch will solve this issue.
      Signed-off-by: default avatarKailang Yang <kailang@realtek.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1f1d1d8e
    • Steven J. Magnani's avatar
      udf: Fix incorrect final NOT_ALLOCATED (hole) extent length · 541cb89c
      Steven J. Magnani authored
      commit fa33cdbf3eceb0206a4f844fe91aeebcf6ff2b7a upstream.
      
      In some cases, using the 'truncate' command to extend a UDF file results
      in a mismatch between the length of the file's extents (specifically, due
      to incorrect length of the final NOT_ALLOCATED extent) and the information
      (file) length. The discrepancy can prevent other operating systems
      (i.e., Windows 10) from opening the file.
      
      Two particular errors have been observed when extending a file:
      
      1. The final extent is larger than it should be, having been rounded up
         to a multiple of the block size.
      
      B. The final extent is not shorter than it should be, due to not having
         been updated when the file's information length was increased.
      
      [JK: simplified udf_do_extend_final_block(), fixed up some types]
      
      Fixes: 2c948b3f ("udf: Avoid IO in udf_clear_inode")
      CC: stable@vger.kernel.org
      Signed-off-by: default avatarSteven J. Magnani <steve@digidescorp.com>
      Link: https://lore.kernel.org/r/1561948775-5878-1-git-send-email-steve@digidescorp.comSigned-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      541cb89c