1. 17 Dec, 2019 40 commits
    • Johan Hovold's avatar
      media: bdisp: fix memleak on release · 2f86d5af
      Johan Hovold authored
      commit 11609a7e upstream.
      
      If a process is interrupted while accessing the video device and the
      device lock is contended, release() could return early and fail to free
      related resources.
      
      Note that the return value of the v4l2 release file operation is
      ignored.
      
      Fixes: 28ffeebb ("[media] bdisp: 2D blitter driver using v4l2 mem2mem framework")
      Cc: stable <stable@vger.kernel.org>     # 4.2
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Reviewed-by: default avatarFabien Dessenne <fabien.dessenne@st.com>
      Signed-off-by: default avatarHans Verkuil <hverkuil-cisco@xs4all.nl>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2f86d5af
    • Gerald Schaefer's avatar
      s390/mm: properly clear _PAGE_NOEXEC bit when it is not supported · 4ca41aa4
      Gerald Schaefer authored
      commit ab874f22 upstream.
      
      On older HW or under a hypervisor, w/o the instruction-execution-
      protection (IEP) facility, and also w/o EDAT-1, a translation-specification
      exception may be recognized when bit 55 of a pte is one (_PAGE_NOEXEC).
      
      The current code tries to prevent setting _PAGE_NOEXEC in such cases,
      by removing it within set_pte_at(). However, ptep_set_access_flags()
      will modify a pte directly, w/o using set_pte_at(). There is at least
      one scenario where this can result in an active pte with _PAGE_NOEXEC
      set, which would then lead to a panic due to a translation-specification
      exception (write to swapped out page):
      
      do_swap_page
        pte = mk_pte (with _PAGE_NOEXEC bit)
        set_pte_at   (will remove _PAGE_NOEXEC bit in page table, but keep it
                      in local variable pte)
        vmf->orig_pte = pte (pte still contains _PAGE_NOEXEC bit)
        do_wp_page
          wp_page_reuse
            entry = vmf->orig_pte (still with _PAGE_NOEXEC bit)
            ptep_set_access_flags (writes entry with _PAGE_NOEXEC bit)
      
      Fix this by clearing _PAGE_NOEXEC already in mk_pte_phys(), where the
      pgprot value is applied, so that no pte with _PAGE_NOEXEC will ever be
      visible, if it is not supported. The check in set_pte_at() can then also
      be removed.
      
      Cc: <stable@vger.kernel.org> # 4.11+
      Fixes: 57d7f939 ("s390: add no-execute support")
      Signed-off-by: default avatarGerald Schaefer <gerald.schaefer@de.ibm.com>
      Signed-off-by: default avatarVasily Gorbik <gor@linux.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4ca41aa4
    • Denis Efremov's avatar
      ar5523: check NULL before memcpy() in ar5523_cmd() · 0cc303ba
      Denis Efremov authored
      commit 315cee42 upstream.
      
      memcpy() call with "idata == NULL && ilen == 0" results in undefined
      behavior in ar5523_cmd(). For example, NULL is passed in callchain
      "ar5523_stat_work() -> ar5523_cmd_write() -> ar5523_cmd()". This patch
      adds ilen check before memcpy() call in ar5523_cmd() to prevent an
      undefined behavior.
      
      Cc: Pontus Fuchs <pontus.fuchs@gmail.com>
      Cc: Kalle Valo <kvalo@codeaurora.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: David Laight <David.Laight@ACULAB.COM>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDenis Efremov <efremov@linux.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0cc303ba
    • Aleksa Sarai's avatar
      cgroup: pids: use atomic64_t for pids->limit · a1de70aa
      Aleksa Sarai authored
      commit a713af39 upstream.
      
      Because pids->limit can be changed concurrently (but we don't want to
      take a lock because it would be needlessly expensive), use atomic64_ts
      instead.
      
      Fixes: commit 49b786ea ("cgroup: implement the PIDs subsystem")
      Cc: stable@vger.kernel.org # v4.3+
      Signed-off-by: default avatarAleksa Sarai <cyphar@cyphar.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a1de70aa
    • Ming Lei's avatar
      blk-mq: avoid sysfs buffer overflow with too many CPU cores · 317c80c6
      Ming Lei authored
      commit 8962842c upstream.
      
      It is reported that sysfs buffer overflow can be triggered if the system
      has too many CPU cores(>841 on 4K PAGE_SIZE) when showing CPUs of
      hctx via /sys/block/$DEV/mq/$N/cpu_list.
      
      Use snprintf to avoid the potential buffer overflow.
      
      This version doesn't change the attribute format, and simply stops
      showing CPU numbers if the buffer is going to overflow.
      
      Cc: stable@vger.kernel.org
      Fixes: 676141e4("blk-mq: don't dump CPU -> hw queue map on driver load")
      Signed-off-by: default avatarMing Lei <ming.lei@redhat.com>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      317c80c6
    • David Jeffery's avatar
      md: improve handling of bio with REQ_PREFLUSH in md_flush_request() · a12c768d
      David Jeffery authored
      commit 775d7831 upstream.
      
      If pers->make_request fails in md_flush_request(), the bio is lost. To
      fix this, pass back a bool to indicate if the original make_request call
      should continue to handle the I/O and instead of assuming the flush logic
      will push it to completion.
      
      Convert md_flush_request to return a bool and no longer calls the raid
      driver's make_request function.  If the return is true, then the md flush
      logic has or will complete the bio and the md make_request call is done.
      If false, then the md make_request function needs to keep processing like
      it is a normal bio. Let the original call to md_handle_request handle any
      need to retry sending the bio to the raid driver's make_request function
      should it be needed.
      
      Also mark md_flush_request and the make_request function pointer as
      __must_check to issue warnings should these critical return values be
      ignored.
      
      Fixes: 2bc13b83 ("md: batch flush requests.")
      Cc: stable@vger.kernel.org # # v4.19+
      Cc: NeilBrown <neilb@suse.com>
      Signed-off-by: default avatarDavid Jeffery <djeffery@redhat.com>
      Reviewed-by: default avatarXiao Ni <xni@redhat.com>
      Signed-off-by: default avatarSong Liu <songliubraving@fb.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a12c768d
    • Pawel Harlozinski's avatar
      ASoC: Jack: Fix NULL pointer dereference in snd_soc_jack_report · d88d9321
      Pawel Harlozinski authored
      commit 8f157d4f upstream.
      
      Check for existance of jack before tracing.
      NULL pointer dereference has been reported by KASAN while unloading
      machine driver (snd_soc_cnl_rt274).
      Signed-off-by: default avatarPawel Harlozinski <pawel.harlozinski@linux.intel.com>
      Link: https://lore.kernel.org/r/20191112130237.10141-1-pawel.harlozinski@linux.intel.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d88d9321
    • Jacob Rasmussen's avatar
      ASoC: rt5645: Fixed typo for buddy jack support. · 29674d00
      Jacob Rasmussen authored
      commit fe23be2d upstream.
      
      Had a typo in e7cfd867 that resulted in buddy jack support not being
      fixed.
      
      Fixes: e7cfd867 ("ASoC: rt5645: Fixed buddy jack support.")
      Signed-off-by: default avatarJacob Rasmussen <jacobraz@google.com>
      Reviewed-by: default avatarRoss Zwisler <zwisler@google.com>
      Cc: <jacobraz@google.com>
      CC: stable@vger.kernel.org
      Link: https://lore.kernel.org/r/20191114232011.165762-1-jacobraz@google.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      29674d00
    • Jacob Rasmussen's avatar
      ASoC: rt5645: Fixed buddy jack support. · fcea88b2
      Jacob Rasmussen authored
      commit e7cfd867 upstream.
      
      The headphone jack on buddy was broken with the following commit:
      commit 6b5da663 ("ASoC: rt5645: read jd1_1 status for jd
      detection").
      This changes the jd_mode for buddy to 4 so buddy can read from the same
      register that was used in the working version of this driver without
      affecting any other devices that might use this, since no other device uses
      jd_mode = 4. To test this I plugged and uplugged the headphone jack, verifying
      audio works.
      Signed-off-by: default avatarJacob Rasmussen <jacobraz@google.com>
      Reviewed-by: default avatarRoss Zwisler <zwisler@google.com>
      Link: https://lore.kernel.org/r/20191111185957.217244-1-jacobraz@google.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fcea88b2
    • Tejun Heo's avatar
      workqueue: Fix pwq ref leak in rescuer_thread() · ebd9fbf9
      Tejun Heo authored
      commit e66b39af upstream.
      
      008847f6 ("workqueue: allow rescuer thread to do more work.") made
      the rescuer worker requeue the pwq immediately if there may be more
      work items which need rescuing instead of waiting for the next mayday
      timer expiration.  Unfortunately, it doesn't check whether the pwq is
      already on the mayday list and unconditionally gets the ref and moves
      it onto the list.  This doesn't corrupt the list but creates an
      additional reference to the pwq.  It got queued twice but will only be
      removed once.
      
      This leak later can trigger pwq refcnt warning on workqueue
      destruction and prevent freeing of the workqueue.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Cc: "Williams, Gerald S" <gerald.s.williams@intel.com>
      Cc: NeilBrown <neilb@suse.de>
      Cc: stable@vger.kernel.org # v3.19+
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ebd9fbf9
    • Tejun Heo's avatar
      workqueue: Fix spurious sanity check failures in destroy_workqueue() · 7c43540e
      Tejun Heo authored
      commit def98c84 upstream.
      
      Before actually destrying a workqueue, destroy_workqueue() checks
      whether it's actually idle.  If it isn't, it prints out a bunch of
      warning messages and leaves the workqueue dangling.  It unfortunately
      has a couple issues.
      
      * Mayday list queueing increments pwq's refcnts which gets detected as
        busy and fails the sanity checks.  However, because mayday list
        queueing is asynchronous, this condition can happen without any
        actual work items left in the workqueue.
      
      * Sanity check failure leaves the sysfs interface behind too which can
        lead to init failure of newer instances of the workqueue.
      
      This patch fixes the above two by
      
      * If a workqueue has a rescuer, disable and kill the rescuer before
        sanity checks.  Disabling and killing is guaranteed to flush the
        existing mayday list.
      
      * Remove sysfs interface before sanity checks.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Reported-by: default avatarMarcin Pawlowski <mpawlowski@fb.com>
      Reported-by: default avatar"Williams, Gerald S" <gerald.s.williams@intel.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7c43540e
    • Dmitry Fomichev's avatar
      dm zoned: reduce overhead of backing device checks · 56a83024
      Dmitry Fomichev authored
      commit e7fad909 upstream.
      
      Commit 75d66ffb added backing device health checks and as a part
      of these checks, check_events() block ops template call is invoked in
      dm-zoned mapping path as well as in reclaim and flush path. Calling
      check_events() with ATA or SCSI backing devices introduces a blocking
      scsi_test_unit_ready() call being made in sd_check_events(). Even though
      the overhead of calling scsi_test_unit_ready() is small for ATA zoned
      devices, it is much larger for SCSI and it affects performance in a very
      negative way.
      
      Fix this performance regression by executing check_events() only in case
      of any I/O errors. The function dmz_bdev_is_dying() is modified to call
      only blk_queue_dying(), while calls to check_events() are made in a new
      helper function, dmz_check_bdev().
      Reported-by: default avatarzhangxiaoxu <zhangxiaoxu5@huawei.com>
      Fixes: 75d66ffb ("dm zoned: properly handle backing device failure")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDmitry Fomichev <dmitry.fomichev@wdc.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      56a83024
    • Maged Mokhtar's avatar
      dm writecache: handle REQ_FUA · 10b9bf59
      Maged Mokhtar authored
      commit c1005322 upstream.
      
      Call writecache_flush() on REQ_FUA in writecache_map().
      
      Cc: stable@vger.kernel.org # 4.18+
      Signed-off-by: default avatarMaged Mokhtar <mmokhtar@petasan.org>
      Acked-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      10b9bf59
    • Sumit Garg's avatar
      hwrng: omap - Fix RNG wait loop timeout · 7c07d026
      Sumit Garg authored
      commit be867f98 upstream.
      
      Existing RNG data read timeout is 200us but it doesn't cover EIP76 RNG
      data rate which takes approx. 700us to produce 16 bytes of output data
      as per testing results. So configure the timeout as 1000us to also take
      account of lack of udelay()'s reliability.
      
      Fixes: 38321242 ("hwrng: omap - Add device variant for SafeXcel IP-76 found in Armada 8K")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarSumit Garg <sumit.garg@linaro.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7c07d026
    • Amir Goldstein's avatar
      ovl: relax WARN_ON() on rename to self · f785f33c
      Amir Goldstein authored
      commit 6889ee5a upstream.
      
      In ovl_rename(), if new upper is hardlinked to old upper underneath
      overlayfs before upper dirs are locked, user will get an ESTALE error
      and a WARN_ON will be printed.
      
      Changes to underlying layers while overlayfs is mounted may result in
      unexpected behavior, but it shouldn't crash the kernel and it shouldn't
      trigger WARN_ON() either, so relax this WARN_ON().
      
      Reported-by: syzbot+bb1836a212e69f8e201a@syzkaller.appspotmail.com
      Fixes: 804032fa ("ovl: don't check rename to self")
      Cc: <stable@vger.kernel.org> # v4.9+
      Signed-off-by: default avatarAmir Goldstein <amir73il@gmail.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f785f33c
    • Amir Goldstein's avatar
      ovl: fix corner case of non-unique st_dev;st_ino · 3e929ddf
      Amir Goldstein authored
      commit 9c6d8f13 upstream.
      
      On non-samefs overlay without xino, non pure upper inodes should use a
      pseudo_dev assigned to each unique lower fs and pure upper inodes use the
      real upper st_dev.
      
      It is fine for an overlay pure upper inode to use the same st_dev;st_ino
      values as the real upper inode, because the content of those two different
      filesystem objects is always the same.
      
      In this case, however:
       - two filesystems, A and B
       - upper layer is on A
       - lower layer 1 is also on A
       - lower layer 2 is on B
      
      Non pure upper overlay inode, whose origin is in layer 1 will have the same
      st_dev;st_ino values as the real lower inode. This may result with a false
      positive results of 'diff' between the real lower and copied up overlay
      inode.
      
      Fix this by using the upper st_dev;st_ino values in this case.  This breaks
      the property of constant st_dev;st_ino across copy up of this case. This
      breakage will be fixed by a later patch.
      
      Fixes: 5148626b ("ovl: allocate anon bdev per unique lower fs")
      Cc: stable@vger.kernel.org # v4.17+
      Signed-off-by: default avatarAmir Goldstein <amir73il@gmail.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3e929ddf
    • Greg Kroah-Hartman's avatar
      lib: raid6: fix awk build warnings · 458f77a4
      Greg Kroah-Hartman authored
      commit 702600ee upstream.
      
      Newer versions of awk spit out these fun warnings:
      	awk: ../lib/raid6/unroll.awk:16: warning: regexp escape sequence `\#' is not a known regexp operator
      
      As commit 700c1018 ("x86/insn: Fix awk regexp warnings") showed, it
      turns out that there are a number of awk strings that do not need to be
      escaped and newer versions of awk now warn about this.
      
      Fix the string up so that no warning is produced.  The exact same kernel
      module gets created before and after this patch, showing that it wasn't
      needed.
      
      Link: https://lore.kernel.org/r/20191206152600.GA75093@kroah.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      458f77a4
    • Larry Finger's avatar
      rtlwifi: rtl8192de: Fix missing enable interrupt flag · 4ee6af20
      Larry Finger authored
      commit 330bb711 upstream.
      
      In commit 38506ece ("rtlwifi: rtl_pci: Start modification for
      new drivers"), the flag that indicates that interrupts are enabled was
      never set.
      
      In addition, there are several places when enable/disable interrupts
      were commented out are restored. A sychronize_interrupts() call is
      removed.
      
      Fixes: 38506ece ("rtlwifi: rtl_pci: Start modification for new drivers")
      Cc: Stable <stable@vger.kernel.org>	# v3.18+
      Signed-off-by: default avatarLarry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4ee6af20
    • Larry Finger's avatar
      rtlwifi: rtl8192de: Fix missing callback that tests for hw release of buffer · 0aa25709
      Larry Finger authored
      commit 3155db76 upstream.
      
      In commit 38506ece ("rtlwifi: rtl_pci: Start modification for
      new drivers"), a callback needed to check if the hardware has released
      a buffer indicating that a DMA operation is completed was not added.
      
      Fixes: 38506ece ("rtlwifi: rtl_pci: Start modification for new drivers")
      Cc: Stable <stable@vger.kernel.org>	# v3.18+
      Signed-off-by: default avatarLarry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0aa25709
    • Larry Finger's avatar
      rtlwifi: rtl8192de: Fix missing code to retrieve RX buffer address · 56a35a3f
      Larry Finger authored
      commit 0e531cc5 upstream.
      
      In commit 38506ece ("rtlwifi: rtl_pci: Start modification for
      new drivers"), a callback to get the RX buffer address was added to
      the PCI driver. Unfortunately, driver rtl8192de was not modified
      appropriately and the code runs into a WARN_ONCE() call. The use
      of an incorrect array is also fixed.
      
      Fixes: 38506ece ("rtlwifi: rtl_pci: Start modification for new drivers")
      Cc: Stable <stable@vger.kernel.org> # 3.18+
      Signed-off-by: default avatarLarry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      56a35a3f
    • Josef Bacik's avatar
      btrfs: record all roots for rename exchange on a subvol · 8862b80b
      Josef Bacik authored
      commit 3e174099 upstream.
      
      Testing with the new fsstress support for subvolumes uncovered a pretty
      bad problem with rename exchange on subvolumes.  We're modifying two
      different subvolumes, but we only start the transaction on one of them,
      so the other one is not added to the dirty root list.  This is caught by
      btrfs_cow_block() with a warning because the root has not been updated,
      however if we do not modify this root again we'll end up pointing at an
      invalid root because the root item is never updated.
      
      Fix this by making sure we add the destination root to the trans list,
      the same as we do with normal renames.  This fixes the corruption.
      
      Fixes: cdd1fedf ("btrfs: add support for RENAME_EXCHANGE and RENAME_WHITEOUT")
      CC: stable@vger.kernel.org # 4.9+
      Reviewed-by: default avatarFilipe Manana <fdmanana@suse.com>
      Signed-off-by: default avatarJosef Bacik <josef@toxicpanda.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8862b80b
    • Filipe Manana's avatar
      Btrfs: send, skip backreference walking for extents with many references · f8031853
      Filipe Manana authored
      commit fd0ddbe2 upstream.
      
      Backreference walking, which is used by send to figure if it can issue
      clone operations instead of write operations, can be very slow and use
      too much memory when extents have many references. This change simply
      skips backreference walking when an extent has more than 64 references,
      in which case we fallback to a write operation instead of a clone
      operation. This limit is conservative and in practice I observed no
      signicant slowdown with up to 100 references and still low memory usage
      up to that limit.
      
      This is a temporary workaround until there are speedups in the backref
      walking code, and as such it does not attempt to add extra interfaces or
      knobs to tweak the threshold.
      Reported-by: default avatarAtemu <atemu.main@gmail.com>
      Link: https://lore.kernel.org/linux-btrfs/CAE4GHgkvqVADtS4AzcQJxo0Q1jKQgKaW3JGp3SGdoinVo=C9eQ@mail.gmail.com/T/#me55dc0987f9cc2acaa54372ce0492c65782be3fa
      CC: stable@vger.kernel.org # 4.4+
      Reviewed-by: default avatarQu Wenruo <wqu@suse.com>
      Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f8031853
    • Qu Wenruo's avatar
      btrfs: Remove btrfs_bio::flags member · dc2a320d
      Qu Wenruo authored
      commit 34b127ae upstream.
      
      The last user of btrfs_bio::flags was removed in commit 326e1dbb
      ("block: remove management of bi_remaining when restoring original
      bi_end_io"), remove it.
      
      (Tagged for stable as the structure is heavily used and space savings
      are desirable.)
      
      CC: stable@vger.kernel.org # 4.4+
      Signed-off-by: default avatarQu Wenruo <wqu@suse.com>
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dc2a320d
    • Tejun Heo's avatar
      btrfs: Avoid getting stuck during cyclic writebacks · dfca82a7
      Tejun Heo authored
      commit f7bddf1e upstream.
      
      During a cyclic writeback, extent_write_cache_pages() uses done_index
      to update the writeback_index after the current run is over.  However,
      instead of current index + 1, it gets to to the current index itself.
      
      Unfortunately, this, combined with returning on EOF instead of looping
      back, can lead to the following pathlogical behavior.
      
      1. There is a single file which has accumulated enough dirty pages to
         trigger balance_dirty_pages() and the writer appending to the file
         with a series of short writes.
      
      2. balance_dirty_pages kicks in, wakes up background writeback and sleeps.
      
      3. Writeback kicks in and the cursor is on the last page of the dirty
         file.  Writeback is started or skipped if already in progress.  As
         it's EOF, extent_write_cache_pages() returns and the cursor is set
         to done_index which is pointing to the last page.
      
      4. Writeback is done.  Nothing happens till balance_dirty_pages
         finishes, at which point we go back to #1.
      
      This can almost completely stall out writing back of the file and keep
      the system over dirty threshold for a long time which can mess up the
      whole system.  We encountered this issue in production with a package
      handling application which can reliably reproduce the issue when
      running under tight memory limits.
      
      Reading the comment in the error handling section, this seems to be to
      avoid accidentally skipping a page in case the write attempt on the
      page doesn't succeed.  However, this concern seems bogus.
      
      On each page, the code either:
      
      * Skips and moves onto the next page.
      
      * Fails issue and sets done_index to index + 1.
      
      * Successfully issues and continue to the next page if budget allows
        and not EOF.
      
      IOW, as long as it's not EOF and there's budget, the code never
      retries writing back the same page.  Only when a page happens to be
      the last page of a particular run, we end up retrying the page, which
      can't possibly guarantee anything data integrity related.  Besides,
      cyclic writes are only used for non-syncing writebacks meaning that
      there's no data integrity implication to begin with.
      
      Fix it by always setting done_index past the current page being
      processed.
      
      Note that this problem exists in other writepages too.
      
      CC: stable@vger.kernel.org # 4.19+
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dfca82a7
    • Filipe Manana's avatar
      Btrfs: fix negative subv_writers counter and data space leak after buffered write · 8155dbe0
      Filipe Manana authored
      commit a0e248bb upstream.
      
      When doing a buffered write it's possible to leave the subv_writers
      counter of the root, used for synchronization between buffered nocow
      writers and snapshotting. This happens in an exceptional case like the
      following:
      
      1) We fail to allocate data space for the write, since there's not
         enough available data space nor enough unallocated space for allocating
         a new data block group;
      
      2) Because of that failure, we try to go to NOCOW mode, which succeeds
         and therefore we set the local variable 'only_release_metadata' to true
         and set the root's sub_writers counter to 1 through the call to
         btrfs_start_write_no_snapshotting() made by check_can_nocow();
      
      3) The call to btrfs_copy_from_user() returns zero, which is very unlikely
         to happen but not impossible;
      
      4) No pages are copied because btrfs_copy_from_user() returned zero;
      
      5) We call btrfs_end_write_no_snapshotting() which decrements the root's
         subv_writers counter to 0;
      
      6) We don't set 'only_release_metadata' back to 'false' because we do
         it only if 'copied', the value returned by btrfs_copy_from_user(), is
         greater than zero;
      
      7) On the next iteration of the while loop, which processes the same
         page range, we are now able to allocate data space for the write (we
         got enough data space released in the meanwhile);
      
      8) After this if we fail at btrfs_delalloc_reserve_metadata(), because
         now there isn't enough free metadata space, or in some other place
         further below (prepare_pages(), lock_and_cleanup_extent_if_need(),
         btrfs_dirty_pages()), we break out of the while loop with
         'only_release_metadata' having a value of 'true';
      
      9) Because 'only_release_metadata' is 'true' we end up decrementing the
         root's subv_writers counter to -1 (through a call to
         btrfs_end_write_no_snapshotting()), and we also end up not releasing the
         data space previously reserved through btrfs_check_data_free_space().
         As a consequence the mechanism for synchronizing NOCOW buffered writes
         with snapshotting gets broken.
      
      Fix this by always setting 'only_release_metadata' to false at the start
      of each iteration.
      
      Fixes: 8257b2dc ("Btrfs: introduce btrfs_{start, end}_nocow_write() for each subvolume")
      Fixes: 7ee9e440 ("Btrfs: check if we can nocow if we don't have data space")
      CC: stable@vger.kernel.org # 4.4+
      Reviewed-by: default avatarJosef Bacik <josef@toxicpanda.com>
      Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8155dbe0
    • Filipe Manana's avatar
      Btrfs: fix metadata space leak on fixup worker failure to set range as delalloc · 9d0e32f0
      Filipe Manana authored
      commit 53687007 upstream.
      
      In the fixup worker, if we fail to mark the range as delalloc in the io
      tree, we must release the previously reserved metadata, as well as update
      the outstanding extents counter for the inode, otherwise we leak metadata
      space.
      
      In pratice we can't return an error from btrfs_set_extent_delalloc(),
      which is just a wrapper around __set_extent_bit(), as for most errors
      __set_extent_bit() does a BUG_ON() (or panics which hits a BUG_ON() as
      well) and returning an -EEXIST error doesn't happen in this case since
      the exclusive bits parameter always has a value of 0 through this code
      path. Nevertheless, just fix the error handling in the fixup worker,
      in case one day __set_extent_bit() can return an error to this code
      path.
      
      Fixes: f3038ee3 ("btrfs: Handle btrfs_set_extent_delalloc failure in fixup worker")
      CC: stable@vger.kernel.org # 4.19+
      Reviewed-by: default avatarNikolay Borisov <nborisov@suse.com>
      Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9d0e32f0
    • Josef Bacik's avatar
      btrfs: use refcount_inc_not_zero in kill_all_nodes · eda96b24
      Josef Bacik authored
      commit baf320b9 upstream.
      
      We hit the following warning while running down a different problem
      
      [ 6197.175850] ------------[ cut here ]------------
      [ 6197.185082] refcount_t: underflow; use-after-free.
      [ 6197.194704] WARNING: CPU: 47 PID: 966 at lib/refcount.c:190 refcount_sub_and_test_checked+0x53/0x60
      [ 6197.521792] Call Trace:
      [ 6197.526687]  __btrfs_release_delayed_node+0x76/0x1c0
      [ 6197.536615]  btrfs_kill_all_delayed_nodes+0xec/0x130
      [ 6197.546532]  ? __btrfs_btree_balance_dirty+0x60/0x60
      [ 6197.556482]  btrfs_clean_one_deleted_snapshot+0x71/0xd0
      [ 6197.566910]  cleaner_kthread+0xfa/0x120
      [ 6197.574573]  kthread+0x111/0x130
      [ 6197.581022]  ? kthread_create_on_node+0x60/0x60
      [ 6197.590086]  ret_from_fork+0x1f/0x30
      [ 6197.597228] ---[ end trace 424bb7ae00509f56 ]---
      
      This is because the free side drops the ref without the lock, and then
      takes the lock if our refcount is 0.  So you can have nodes on the tree
      that have a refcount of 0.  Fix this by zero'ing out that element in our
      temporary array so we don't try to kill it again.
      
      CC: stable@vger.kernel.org # 4.14+
      Reviewed-by: default avatarNikolay Borisov <nborisov@suse.com>
      Signed-off-by: default avatarJosef Bacik <josef@toxicpanda.com>
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.com>
      [ add comment ]
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      eda96b24
    • Josef Bacik's avatar
      btrfs: check page->mapping when loading free space cache · 6e3b9068
      Josef Bacik authored
      commit 3797136b upstream.
      
      While testing 5.2 we ran into the following panic
      
      [52238.017028] BUG: kernel NULL pointer dereference, address: 0000000000000001
      [52238.105608] RIP: 0010:drop_buffers+0x3d/0x150
      [52238.304051] Call Trace:
      [52238.308958]  try_to_free_buffers+0x15b/0x1b0
      [52238.317503]  shrink_page_list+0x1164/0x1780
      [52238.325877]  shrink_inactive_list+0x18f/0x3b0
      [52238.334596]  shrink_node_memcg+0x23e/0x7d0
      [52238.342790]  ? do_shrink_slab+0x4f/0x290
      [52238.350648]  shrink_node+0xce/0x4a0
      [52238.357628]  balance_pgdat+0x2c7/0x510
      [52238.365135]  kswapd+0x216/0x3e0
      [52238.371425]  ? wait_woken+0x80/0x80
      [52238.378412]  ? balance_pgdat+0x510/0x510
      [52238.386265]  kthread+0x111/0x130
      [52238.392727]  ? kthread_create_on_node+0x60/0x60
      [52238.401782]  ret_from_fork+0x1f/0x30
      
      The page we were trying to drop had a page->private, but had no
      page->mapping and so called drop_buffers, assuming that we had a
      buffer_head on the page, and then panic'ed trying to deref 1, which is
      our page->private for data pages.
      
      This is happening because we're truncating the free space cache while
      we're trying to load the free space cache.  This isn't supposed to
      happen, and I'll fix that in a followup patch.  However we still
      shouldn't allow those sort of mistakes to result in messing with pages
      that do not belong to us.  So add the page->mapping check to verify that
      we still own this page after dropping and re-acquiring the page lock.
      
      This page being unlocked as:
      btrfs_readpage
        extent_read_full_page
          __extent_read_full_page
            __do_readpage
              if (!nr)
      	   unlock_page  <-- nr can be 0 only if submit_extent_page
      			    returns an error
      
      CC: stable@vger.kernel.org # 4.4+
      Reviewed-by: default avatarFilipe Manana <fdmanana@suse.com>
      Reviewed-by: default avatarNikolay Borisov <nborisov@suse.com>
      Signed-off-by: default avatarJosef Bacik <josef@toxicpanda.com>
      [ add callchain ]
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6e3b9068
    • Yoshihiro Shimoda's avatar
      phy: renesas: rcar-gen3-usb2: Fix sysfs interface of "role" · 80c291c1
      Yoshihiro Shimoda authored
      commit 4bd5ead8 upstream.
      
      Since the role_store() uses strncmp(), it's possible to refer
      out-of-memory if the sysfs data size is smaller than strlen("host").
      This patch fixes it by using sysfs_streq() instead of strncmp().
      Reported-by: default avatarPavel Machek <pavel@denx.de>
      Fixes: 9bb86777 ("phy: rcar-gen3-usb2: add sysfs for usb role swap")
      Cc: <stable@vger.kernel.org> # v4.10+
      Signed-off-by: default avatarYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Reviewed-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Acked-by: default avatarPavel Machek <pavel@denx.de>
      Signed-off-by: default avatarKishon Vijay Abraham I <kishon@ti.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      80c291c1
    • Thinh Nguyen's avatar
      usb: dwc3: ep0: Clear started flag on completion · c6f58dcd
      Thinh Nguyen authored
      commit 2d7b78f5 upstream.
      
      Clear ep0's DWC3_EP_TRANSFER_STARTED flag if the END_TRANSFER command is
      completed. Otherwise, we can't start control transfer again after
      END_TRANSFER.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarThinh Nguyen <thinhn@synopsys.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c6f58dcd
    • Tejas Joglekar's avatar
      usb: dwc3: gadget: Fix logical condition · 16831495
      Tejas Joglekar authored
      commit 8c7d4b7b upstream.
      
      This patch corrects the condition to kick the transfer without
      giving back the requests when either request has remaining data
      or when there are pending SGs. The && check was introduced during
      spliting up the dwc3_gadget_ep_cleanup_completed_requests() function.
      
      Fixes: f38e35dd ("usb: dwc3: gadget: split dwc3_gadget_ep_cleanup_completed_requests()")
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarTejas Joglekar <joglekar@synopsys.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      16831495
    • Heikki Krogerus's avatar
      usb: dwc3: pci: add ID for the Intel Comet Lake -H variant · 6aa56f58
      Heikki Krogerus authored
      commit 3c3caae4 upstream.
      
      The original ID that was added for Comet Lake PCH was
      actually for the -LP (low power) variant even though the
      constant for it said CMLH. Changing that while at it.
      Signed-off-by: default avatarHeikki Krogerus <heikki.krogerus@linux.intel.com>
      Acked-by: default avatarFelipe Balbi <balbi@kernel.org>
      Cc: stable <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20191212093713.60614-1-heikki.krogerus@linux.intel.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6aa56f58
    • David Hildenbrand's avatar
      virtio-balloon: fix managed page counts when migrating pages between zones · 472f9483
      David Hildenbrand authored
      commit 63341ab0 upstream.
      
      In case we have to migrate a ballon page to a newpage of another zone, the
      managed page count of both zones is wrong. Paired with memory offlining
      (which will adjust the managed page count), we can trigger kernel crashes
      and all kinds of different symptoms.
      
      One way to reproduce:
      1. Start a QEMU guest with 4GB, no NUMA
      2. Hotplug a 1GB DIMM and online the memory to ZONE_NORMAL
      3. Inflate the balloon to 1GB
      4. Unplug the DIMM (be quick, otherwise unmovable data ends up on it)
      5. Observe /proc/zoneinfo
        Node 0, zone   Normal
          pages free     16810
                min      24848885473806
                low      18471592959183339
                high     36918337032892872
                spanned  262144
                present  262144
                managed  18446744073709533486
      6. Do anything that requires some memory (e.g., inflate the balloon some
      more). The OOM goes crazy and the system crashes
        [  238.324946] Out of memory: Killed process 537 (login) total-vm:27584kB, anon-rss:860kB, file-rss:0kB, shmem-rss:00
        [  238.338585] systemd invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0
        [  238.339420] CPU: 0 PID: 1 Comm: systemd Tainted: G      D W         5.4.0-next-20191204+ #75
        [  238.340139] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu4
        [  238.341121] Call Trace:
        [  238.341337]  dump_stack+0x8f/0xd0
        [  238.341630]  dump_header+0x61/0x5ea
        [  238.341942]  oom_kill_process.cold+0xb/0x10
        [  238.342299]  out_of_memory+0x24d/0x5a0
        [  238.342625]  __alloc_pages_slowpath+0xd12/0x1020
        [  238.343024]  __alloc_pages_nodemask+0x391/0x410
        [  238.343407]  pagecache_get_page+0xc3/0x3a0
        [  238.343757]  filemap_fault+0x804/0xc30
        [  238.344083]  ? ext4_filemap_fault+0x28/0x42
        [  238.344444]  ext4_filemap_fault+0x30/0x42
        [  238.344789]  __do_fault+0x37/0x1a0
        [  238.345087]  __handle_mm_fault+0x104d/0x1ab0
        [  238.345450]  handle_mm_fault+0x169/0x360
        [  238.345790]  do_user_addr_fault+0x20d/0x490
        [  238.346154]  do_page_fault+0x31/0x210
        [  238.346468]  async_page_fault+0x43/0x50
        [  238.346797] RIP: 0033:0x7f47eba4197e
        [  238.347110] Code: Bad RIP value.
        [  238.347387] RSP: 002b:00007ffd7c0c1890 EFLAGS: 00010293
        [  238.347834] RAX: 0000000000000002 RBX: 000055d196a20a20 RCX: 00007f47eba4197e
        [  238.348437] RDX: 0000000000000033 RSI: 00007ffd7c0c18c0 RDI: 0000000000000004
        [  238.349047] RBP: 00007ffd7c0c1c20 R08: 0000000000000000 R09: 0000000000000033
        [  238.349660] R10: 00000000ffffffff R11: 0000000000000293 R12: 0000000000000001
        [  238.350261] R13: ffffffffffffffff R14: 0000000000000000 R15: 00007ffd7c0c18c0
        [  238.350878] Mem-Info:
        [  238.351085] active_anon:3121 inactive_anon:51 isolated_anon:0
        [  238.351085]  active_file:12 inactive_file:7 isolated_file:0
        [  238.351085]  unevictable:0 dirty:0 writeback:0 unstable:0
        [  238.351085]  slab_reclaimable:5565 slab_unreclaimable:10170
        [  238.351085]  mapped:3 shmem:111 pagetables:155 bounce:0
        [  238.351085]  free:720717 free_pcp:2 free_cma:0
        [  238.353757] Node 0 active_anon:12484kB inactive_anon:204kB active_file:48kB inactive_file:28kB unevictable:0kB iss
        [  238.355979] Node 0 DMA free:11556kB min:36kB low:48kB high:60kB reserved_highatomic:0KB active_anon:152kB inactivB
        [  238.358345] lowmem_reserve[]: 0 2955 2884 2884 2884
        [  238.358761] Node 0 DMA32 free:2677864kB min:7004kB low:10028kB high:13052kB reserved_highatomic:0KB active_anon:0B
        [  238.361202] lowmem_reserve[]: 0 0 72057594037927865 72057594037927865 72057594037927865
        [  238.361888] Node 0 Normal free:193448kB min:99395541895224kB low:73886371836733356kB high:147673348131571488kB reB
        [  238.364765] lowmem_reserve[]: 0 0 0 0 0
        [  238.365101] Node 0 DMA: 7*4kB (U) 5*8kB (UE) 6*16kB (UME) 2*32kB (UM) 1*64kB (U) 2*128kB (UE) 3*256kB (UME) 2*512B
        [  238.366379] Node 0 DMA32: 0*4kB 1*8kB (U) 2*16kB (UM) 2*32kB (UM) 2*64kB (UM) 1*128kB (U) 1*256kB (U) 1*512kB (U)B
        [  238.367654] Node 0 Normal: 1985*4kB (UME) 1321*8kB (UME) 844*16kB (UME) 524*32kB (UME) 300*64kB (UME) 138*128kB (B
        [  238.369184] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB
        [  238.369915] 130 total pagecache pages
        [  238.370241] 0 pages in swap cache
        [  238.370533] Swap cache stats: add 0, delete 0, find 0/0
        [  238.370981] Free swap  = 0kB
        [  238.371239] Total swap = 0kB
        [  238.371488] 1048445 pages RAM
        [  238.371756] 0 pages HighMem/MovableOnly
        [  238.372090] 306992 pages reserved
        [  238.372376] 0 pages cma reserved
        [  238.372661] 0 pages hwpoisoned
      
      In another instance (older kernel), I was able to observe this
      (negative page count :/):
        [  180.896971] Offlined Pages 32768
        [  182.667462] Offlined Pages 32768
        [  184.408117] Offlined Pages 32768
        [  186.026321] Offlined Pages 32768
        [  187.684861] Offlined Pages 32768
        [  189.227013] Offlined Pages 32768
        [  190.830303] Offlined Pages 32768
        [  190.833071] Built 1 zonelists, mobility grouping on.  Total pages: -36920272750453009
      
      In another instance (older kernel), I was no longer able to start any
      process:
        [root@vm ~]# [  214.348068] Offlined Pages 32768
        [  215.973009] Offlined Pages 32768
        cat /proc/meminfo
        -bash: fork: Cannot allocate memory
        [root@vm ~]# cat /proc/meminfo
        -bash: fork: Cannot allocate memory
      
      Fix it by properly adjusting the managed page count when migrating if
      the zone changed. The managed page count of the zones now looks after
      unplug of the DIMM (and after deflating the balloon) just like before
      inflating the balloon (and plugging+onlining the DIMM).
      
      We'll temporarily modify the totalram page count. If this ever becomes a
      problem, we can fine tune by providing helpers that don't touch
      the totalram pages (e.g., adjust_zone_managed_page_count()).
      
      Please note that fixing up the managed page count is only necessary when
      we adjusted the managed page count when inflating - only if we
      don't have VIRTIO_BALLOON_F_DEFLATE_ON_OOM. With that feature, the
      managed page count is not touched when inflating/deflating.
      Reported-by: default avatarYumei Huang <yuhuang@redhat.com>
      Fixes: 3dcc0571 ("mm: correctly update zone->managed_pages")
      Cc: <stable@vger.kernel.org> # v3.11+
      Cc: "Michael S. Tsirkin" <mst@redhat.com>
      Cc: Jason Wang <jasowang@redhat.com>
      Cc: Jiang Liu <liuj97@gmail.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Igor Mammedov <imammedo@redhat.com>
      Cc: virtualization@lists.linux-foundation.org
      Signed-off-by: default avatarDavid Hildenbrand <david@redhat.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      472f9483
    • Miquel Raynal's avatar
      mtd: spear_smi: Fix Write Burst mode · 37b8438a
      Miquel Raynal authored
      commit 69c7f461 upstream.
      
      Any write with either dd or flashcp to a device driven by the
      spear_smi.c driver will pass through the spear_smi_cpy_toio()
      function. This function will get called for chunks of up to 256 bytes.
      If the amount of data is smaller, we may have a problem if the data
      length is not 4-byte aligned. In this situation, the kernel panics
      during the memcpy:
      
          # dd if=/dev/urandom bs=1001 count=1 of=/dev/mtd6
          spear_smi_cpy_toio [620] dest c9070000, src c7be8800, len 256
          spear_smi_cpy_toio [620] dest c9070100, src c7be8900, len 256
          spear_smi_cpy_toio [620] dest c9070200, src c7be8a00, len 256
          spear_smi_cpy_toio [620] dest c9070300, src c7be8b00, len 233
          Unhandled fault: external abort on non-linefetch (0x808) at 0xc90703e8
          [...]
          PC is at memcpy+0xcc/0x330
      
      The above error occurs because the implementation of memcpy_toio()
      tries to optimize the number of I/O by writing 4 bytes at a time as
      much as possible, until there are less than 4 bytes left and then
      switches to word or byte writes.
      
      Unfortunately, the specification states about the Write Burst mode:
      
              "the next AHB Write request should point to the next
      	incremented address and should have the same size (byte,
      	half-word or word)"
      
      This means ARM architecture implementation of memcpy_toio() cannot
      reliably be used blindly here. Workaround this situation by update the
      write path to stick to byte access when the burst length is not
      multiple of 4.
      
      Fixes: f18dbbb1 ("mtd: ST SPEAr: Add SMI driver for serial NOR flash")
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Boris Brezillon <boris.brezillon@collabora.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMiquel Raynal <miquel.raynal@bootlin.com>
      Reviewed-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      37b8438a
    • Tadeusz Struk's avatar
      tpm: add check after commands attribs tab allocation · 2e0e2b48
      Tadeusz Struk authored
      commit f1689114 upstream.
      
      devm_kcalloc() can fail and return NULL so we need to check for that.
      
      Cc: stable@vger.kernel.org
      Fixes: 58472f5c ("tpm: validate TPM 2.0 commands")
      Signed-off-by: default avatarTadeusz Struk <tadeusz.struk@intel.com>
      Reviewed-by: default avatarJerry Snitselaar <jsnitsel@redhat.com>
      Reviewed-by: default avatarJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
      Tested-by: default avatarJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
      Signed-off-by: default avatarJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2e0e2b48
    • Pete Zaitcev's avatar
      usb: mon: Fix a deadlock in usbmon between mmap and read · 3757e381
      Pete Zaitcev authored
      commit 19e6317d upstream.
      
      The problem arises because our read() function grabs a lock of the
      circular buffer, finds something of interest, then invokes copy_to_user()
      straight from the buffer, which in turn takes mm->mmap_sem. In the same
      time, the callback mon_bin_vma_fault() is invoked under mm->mmap_sem.
      It attempts to take the fetch lock and deadlocks.
      
      This patch does away with protecting of our page list with any
      semaphores, and instead relies on the kernel not close the device
      while mmap is active in a process.
      
      In addition, we prohibit re-sizing of a buffer while mmap is active.
      This way, when (now unlocked) fault is processed, it works with the
      page that is intended to be mapped-in, and not some other random page.
      Note that this may have an ABI impact, but hopefully no legitimate
      program is this wrong.
      Signed-off-by: default avatarPete Zaitcev <zaitcev@redhat.com>
      Reported-by: syzbot+56f9673bb4cdcbeb0e92@syzkaller.appspotmail.com
      Reviewed-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Fixes: 46eb14a6 ("USB: fix usbmon BUG trigger")
      Cc: <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20191204203941.3503452b@suzdal.zaitcev.lanSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3757e381
    • Emiliano Ingrassia's avatar
      usb: core: urb: fix URB structure initialization function · cf6a2fbc
      Emiliano Ingrassia authored
      commit 1cd17f7f upstream.
      
      Explicitly initialize URB structure urb_list field in usb_init_urb().
      This field can be potentially accessed uninitialized and its
      initialization is coherent with the usage of list_del_init() in
      usb_hcd_unlink_urb_from_ep() and usb_giveback_urb_bh() and its
      explicit initialization in usb_hcd_submit_urb() error path.
      Signed-off-by: default avatarEmiliano Ingrassia <ingrassia@epigenesys.com>
      Cc: stable <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20191127160355.GA27196@ingrassia.epigenesys.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cf6a2fbc
    • Johan Hovold's avatar
      USB: adutux: fix interface sanity check · 8ae04b7d
      Johan Hovold authored
      commit 3c11c4be upstream.
      
      Make sure to use the current alternate setting when verifying the
      interface descriptors to avoid binding to an invalid interface.
      
      Failing to do so could cause the driver to misbehave or trigger a WARN()
      in usb_submit_urb() that kernels with panic_on_warn set would choke on.
      
      Fixes: 03270634 ("USB: Add ADU support for Ontrak ADU devices")
      Cc: stable <stable@vger.kernel.org>     # 2.6.19
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Link: https://lore.kernel.org/r/20191210112601.3561-3-johan@kernel.orgSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8ae04b7d
    • Wen Yang's avatar
      usb: roles: fix a potential use after free · c3dde738
      Wen Yang authored
      commit 1848a543 upstream.
      
      Free the sw structure only after we are done using it.
      This patch just moves the put_device() down a bit to avoid the
      use after free.
      
      Fixes: 5c54fcac ("usb: roles: Take care of driver module reference counting")
      Signed-off-by: default avatarWen Yang <wenyang@linux.alibaba.com>
      Reviewed-by: default avatarHeikki Krogerus <heikki.krogerus@linux.intel.com>
      Reviewed-by: default avatarPeter Chen <peter.chen@nxp.com>
      Cc: stable <stable@vger.kernel.org>
      Cc: Hans de Goede <hdegoede@redhat.com>
      Cc: Chunfeng Yun <chunfeng.yun@mediatek.com>
      Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
      Cc: linux-usb@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Link: https://lore.kernel.org/r/20191124142236.25671-1-wenyang@linux.alibaba.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c3dde738
    • Johan Hovold's avatar
      USB: serial: io_edgeport: fix epic endpoint lookup · 3d1eef38
      Johan Hovold authored
      commit 7c5a2df3 upstream.
      
      Make sure to use the current alternate setting when looking up the
      endpoints on epic devices to avoid binding to an invalid interface.
      
      Failing to do so could cause the driver to misbehave or trigger a WARN()
      in usb_submit_urb() that kernels with panic_on_warn set would choke on.
      
      Fixes: 6e8cf775 ("USB: add EPIC support to the io_edgeport driver")
      Cc: stable <stable@vger.kernel.org>     # 2.6.21
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Link: https://lore.kernel.org/r/20191210112601.3561-5-johan@kernel.orgSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3d1eef38