1. 31 May, 2019 40 commits
    • Sebastian Andrzej Siewior's avatar
      smpboot: Place the __percpu annotation correctly · a5f3559f
      Sebastian Andrzej Siewior authored
      [ Upstream commit d4645d30 ]
      
      The test robot reported a wrong assignment of a per-CPU variable which
      it detected by using sparse and sent a report. The assignment itself is
      correct. The annotation for sparse was wrong and hence the report.
      The first pointer is a "normal" pointer and points to the per-CPU memory
      area. That means that the __percpu annotation has to be moved.
      
      Move the __percpu annotation to pointer which points to the per-CPU
      area. This change affects only the sparse tool (and is ignored by the
      compiler).
      Reported-by: default avatarkbuild test robot <lkp@intel.com>
      Signed-off-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul E. McKenney <paulmck@linux.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Fixes: f97f8f06 ("smpboot: Provide infrastructure for percpu hotplug threads")
      Link: http://lkml.kernel.org/r/20190424085253.12178-1-bigeasy@linutronix.deSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      a5f3559f
    • Kees Cook's avatar
      x86/build: Move _etext to actual end of .text · 87386764
      Kees Cook authored
      [ Upstream commit 392bef70 ]
      
      When building x86 with Clang LTO and CFI, CFI jump regions are
      automatically added to the end of the .text section late in linking. As a
      result, the _etext position was being labelled before the appended jump
      regions, causing confusion about where the boundaries of the executable
      region actually are in the running kernel, and broke at least the fault
      injection code. This moves the _etext mark to outside (and immediately
      after) the .text area, as it already the case on other architectures
      (e.g. arm64, arm).
      Reported-and-tested-by: default avatarSami Tolvanen <samitolvanen@google.com>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/20190423183827.GA4012@beastSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      87386764
    • Arnd Bergmann's avatar
      bcache: avoid clang -Wunintialized warning · 56df2dbe
      Arnd Bergmann authored
      [ Upstream commit 78d4eb8a ]
      
      clang has identified a code path in which it thinks a
      variable may be unused:
      
      drivers/md/bcache/alloc.c:333:4: error: variable 'bucket' is used uninitialized whenever 'if' condition is false
            [-Werror,-Wsometimes-uninitialized]
                              fifo_pop(&ca->free_inc, bucket);
                              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      drivers/md/bcache/util.h:219:27: note: expanded from macro 'fifo_pop'
       #define fifo_pop(fifo, i)       fifo_pop_front(fifo, (i))
                                      ^~~~~~~~~~~~~~~~~~~~~~~~~
      drivers/md/bcache/util.h:189:6: note: expanded from macro 'fifo_pop_front'
              if (_r) {                                                       \
                  ^~
      drivers/md/bcache/alloc.c:343:46: note: uninitialized use occurs here
                              allocator_wait(ca, bch_allocator_push(ca, bucket));
                                                                        ^~~~~~
      drivers/md/bcache/alloc.c:287:7: note: expanded from macro 'allocator_wait'
                      if (cond)                                               \
                          ^~~~
      drivers/md/bcache/alloc.c:333:4: note: remove the 'if' if its condition is always true
                              fifo_pop(&ca->free_inc, bucket);
                              ^
      drivers/md/bcache/util.h:219:27: note: expanded from macro 'fifo_pop'
       #define fifo_pop(fifo, i)       fifo_pop_front(fifo, (i))
                                      ^
      drivers/md/bcache/util.h:189:2: note: expanded from macro 'fifo_pop_front'
              if (_r) {                                                       \
              ^
      drivers/md/bcache/alloc.c:331:15: note: initialize the variable 'bucket' to silence this warning
                              long bucket;
                                         ^
      
      This cannot happen in practice because we only enter the loop
      if there is at least one element in the list.
      
      Slightly rearranging the code makes this clearer to both the
      reader and the compiler, which avoids the warning.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: default avatarColy Li <colyli@suse.de>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      56df2dbe
    • Coly Li's avatar
      bcache: add failure check to run_cache_set() for journal replay · 282ae1e8
      Coly Li authored
      [ Upstream commit ce3e4cfb ]
      
      Currently run_cache_set() has no return value, if there is failure in
      bch_journal_replay(), the caller of run_cache_set() has no idea about
      such failure and just continue to execute following code after
      run_cache_set().  The internal failure is triggered inside
      bch_journal_replay() and being handled in async way. This behavior is
      inefficient, while failure handling inside bch_journal_replay(), cache
      register code is still running to start the cache set. Registering and
      unregistering code running as same time may introduce some rare race
      condition, and make the code to be more hard to be understood.
      
      This patch adds return value to run_cache_set(), and returns -EIO if
      bch_journal_rreplay() fails. Then caller of run_cache_set() may detect
      such failure and stop registering code flow immedidately inside
      register_cache_set().
      
      If journal replay fails, run_cache_set() can report error immediately
      to register_cache_set(). This patch makes the failure handling for
      bch_journal_replay() be in synchronized way, easier to understand and
      debug, and avoid poetential race condition for register-and-unregister
      in same time.
      Signed-off-by: default avatarColy Li <colyli@suse.de>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      282ae1e8
    • Tang Junhui's avatar
      bcache: fix failure in journal relplay · abc77ba7
      Tang Junhui authored
      [ Upstream commit 63120731 ]
      
      journal replay failed with messages:
      Sep 10 19:10:43 ceph kernel: bcache: error on
      bb379a64-e44e-4812-b91d-a5599871a3b1: bcache: journal entries
      2057493-2057567 missing! (replaying 2057493-20766016), disabling
      caching
      
      The reason is in journal_reclaim(), when discard is enabled, we send
      discard command and reclaim those journal buckets whose seq is old
      than the last_seq_now, but before we write a journal with last_seq_now,
      the machine is restarted, so the journal with the last_seq_now is not
      written to the journal bucket, and the last_seq_wrote in the newest
      journal is old than last_seq_now which we expect to be, so when we doing
      replay, journals from last_seq_wrote to last_seq_now are missing.
      
      It's hard to write a journal immediately after journal_reclaim(),
      and it harmless if those missed journal are caused by discarding
      since those journals are already wrote to btree node. So, if miss
      seqs are started from the beginning journal, we treat it as normal,
      and only print a message to show the miss journal, and point out
      it maybe caused by discarding.
      
      Patch v2 add a judgement condition to ignore the missed journal
      only when discard enabled as Coly suggested.
      
      (Coly Li: rebase the patch with other changes in bch_journal_replay())
      Signed-off-by: default avatarTang Junhui <tang.junhui.linux@gmail.com>
      Tested-by: default avatarDennis Schridde <devurandom@gmx.net>
      Signed-off-by: default avatarColy Li <colyli@suse.de>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      abc77ba7
    • Coly Li's avatar
      bcache: return error immediately in bch_journal_replay() · e7321da1
      Coly Li authored
      [ Upstream commit 68d10e69 ]
      
      When failure happens inside bch_journal_replay(), calling
      cache_set_err_on() and handling the failure in async way is not a good
      idea. Because after bch_journal_replay() returns, registering code will
      continue to execute following steps, and unregistering code triggered
      by cache_set_err_on() is running in same time. First it is unnecessary
      to handle failure and unregister cache set in an async way, second there
      might be potential race condition to run register and unregister code
      for same cache set.
      
      So in this patch, if failure happens in bch_journal_replay(), we don't
      call cache_set_err_on(), and just print out the same error message to
      kernel message buffer, then return -EIO immediately caller. Then caller
      can detect such failure and handle it in synchrnozied way.
      Signed-off-by: default avatarColy Li <colyli@suse.de>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.com>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      e7321da1
    • Corentin Labbe's avatar
      crypto: sun4i-ss - Fix invalid calculation of hash end · 2ed24236
      Corentin Labbe authored
      [ Upstream commit f8739155 ]
      
      When nbytes < 4, end is wronlgy set to a negative value which, due to
      uint, is then interpreted to a large value leading to a deadlock in the
      following code.
      
      This patch fix this problem.
      
      Fixes: 6298e948 ("crypto: sunxi-ss - Add Allwinner Security System crypto accelerator")
      Signed-off-by: default avatarCorentin Labbe <clabbe.montjoie@gmail.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      2ed24236
    • Kangjie Lu's avatar
      net: cw1200: fix a NULL pointer dereference · 2f3201b2
      Kangjie Lu authored
      [ Upstream commit 0ed2a005 ]
      
      In case create_singlethread_workqueue fails, the fix free the
      hardware and returns NULL to avoid NULL pointer dereference.
      Signed-off-by: default avatarKangjie Lu <kjlu@umn.edu>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      2f3201b2
    • Dan Carpenter's avatar
      mwifiex: prevent an array overflow · bc2c8535
      Dan Carpenter authored
      [ Upstream commit b4c35c17 ]
      
      The "rate_index" is only used as an index into the phist_data->rx_rate[]
      array in the mwifiex_hist_data_set() function.  That array has
      MWIFIEX_MAX_AC_RX_RATES (74) elements and it's used to generate some
      debugfs information.  The "rate_index" variable comes from the network
      skb->data[] and it is a u8 so it's in the 0-255 range.  We need to cap
      it to prevent an array overflow.
      
      Fixes: cbf6e055 ("mwifiex: add rx histogram statistics support")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      bc2c8535
    • Daniel Baluta's avatar
      ASoC: fsl_sai: Update is_slave_mode with correct value · 043a7a24
      Daniel Baluta authored
      [ Upstream commit ddb35114 ]
      
      is_slave_mode defaults to false because sai structure
      that contains it is kzalloc'ed.
      
      Anyhow, if we decide to set the following configuration
      SAI slave -> SAI master, is_slave_mode will remain set on true
      although SAI being master it should be set to false.
      
      Fix this by updating is_slave_mode for each call of
      fsl_sai_set_dai_fmt.
      Signed-off-by: default avatarDaniel Baluta <daniel.baluta@nxp.com>
      Acked-by: default avatarNicolin Chen <nicoleotsuka@gmail.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      043a7a24
    • Sergey Matyukevich's avatar
      mac80211/cfg80211: update bss channel on channel switch · e5c17240
      Sergey Matyukevich authored
      [ Upstream commit 5dc8cdce ]
      
      FullMAC STAs have no way to update bss channel after CSA channel switch
      completion. As a result, user-space tools may provide inconsistent
      channel info. For instance, consider the following two commands:
      $ sudo iw dev wlan0 link
      $ sudo iw dev wlan0 info
      The latter command gets channel info from the hardware, so most probably
      its output will be correct. However the former command gets channel info
      from scan cache, so its output will contain outdated channel info.
      In fact, current bss channel info will not be updated until the
      next [re-]connect.
      
      Note that mac80211 STAs have a workaround for this, but it requires
      access to internal cfg80211 data, see ieee80211_chswitch_work:
      
      	/* XXX: shouldn't really modify cfg80211-owned data! */
      	ifmgd->associated->channel = sdata->csa_chandef.chan;
      
      This patch suggests to convert mac80211 workaround into cfg80211 behavior
      and to update current bss channel in cfg80211_ch_switch_notify.
      Signed-off-by: default avatarSergey Matyukevich <sergey.matyukevich.os@quantenna.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      e5c17240
    • Sugar Zhang's avatar
      dmaengine: pl330: _stop: clear interrupt status · ab53d054
      Sugar Zhang authored
      [ Upstream commit 2da254cc ]
      
      This patch kill instructs the DMAC to immediately terminate
      execution of a thread. and then clear the interrupt status,
      at last, stop generating interrupts for DMA_SEV. to guarantee
      the next dma start is clean. otherwise, one interrupt maybe leave
      to next start and make some mistake.
      
      we can reporduce the problem as follows:
      
      DMASEV: modify the event-interrupt resource, and if the INTEN sets
      function as interrupt, the DMAC will set irq<event_num> HIGH to
      generate interrupt. write INTCLR to clear interrupt.
      
      	DMA EXECUTING INSTRUCTS		DMA TERMINATE
      		|				|
      		|				|
      	       ...			      _stop
      		|				|
      		|			spin_lock_irqsave
      	     DMASEV				|
      		|				|
      		|			    mask INTEN
      		|				|
      		|			     DMAKILL
      		|				|
      		|			spin_unlock_irqrestore
      
      in above case, a interrupt was left, and if we unmask INTEN, the DMAC
      will set irq<event_num> HIGH to generate interrupt.
      
      to fix this, do as follows:
      
      	DMA EXECUTING INSTRUCTS		DMA TERMINATE
      		|				|
      		|				|
      	       ...			      _stop
      		|				|
      		|			spin_lock_irqsave
      	     DMASEV				|
      		|				|
      		|			     DMAKILL
      		|				|
      		|			   clear INTCLR
      		|			    mask INTEN
      		|				|
      		|			spin_unlock_irqrestore
      Signed-off-by: default avatarSugar Zhang <sugar.zhang@rock-chips.com>
      Signed-off-by: default avatarVinod Koul <vkoul@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ab53d054
    • Mariusz Bialonczyk's avatar
      w1: fix the resume command API · 1f7f676b
      Mariusz Bialonczyk authored
      [ Upstream commit 62909da8 ]
      
      >From the DS2408 datasheet [1]:
      "Resume Command function checks the status of the RC flag and, if it is set,
       directly transfers control to the control functions, similar to a Skip ROM
       command. The only way to set the RC flag is through successfully executing
       the Match ROM, Search ROM, Conditional Search ROM, or Overdrive-Match ROM
       command"
      
      The function currently works perfectly fine in a multidrop bus, but when we
      have only a single slave connected, then only a Skip ROM is used and Match
      ROM is not called at all. This is leading to problems e.g. with single one
      DS2408 connected, as the Resume Command is not working properly and the
      device is responding with failing results after the Resume Command.
      
      This commit is fixing this by using a Skip ROM instead in those cases.
      The bandwidth / performance advantage is exactly the same.
      
      Refs:
      [1] https://datasheets.maximintegrated.com/en/ds/DS2408.pdfSigned-off-by: default avatarMariusz Bialonczyk <manio@skyboo.net>
      Reviewed-by: default avatarJean-Francois Dagenais <jeff.dagenais@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      1f7f676b
    • Sven Van Asbroeck's avatar
      rtc: 88pm860x: prevent use-after-free on device remove · 8685a298
      Sven Van Asbroeck authored
      [ Upstream commit f22b1ba1 ]
      
      The device's remove() attempts to shut down the delayed_work scheduled
      on the kernel-global workqueue by calling flush_scheduled_work().
      
      Unfortunately, flush_scheduled_work() does not prevent the delayed_work
      from re-scheduling itself. The delayed_work might run after the device
      has been removed, and touch the already de-allocated info structure.
      This is a potential use-after-free.
      
      Fix by calling cancel_delayed_work_sync() during remove(): this ensures
      that the delayed work is properly cancelled, is no longer running, and
      is not able to re-schedule itself.
      
      This issue was detected with the help of Coccinelle.
      Signed-off-by: default avatarSven Van Asbroeck <TheSven73@gmail.com>
      Signed-off-by: default avatarAlexandre Belloni <alexandre.belloni@bootlin.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      8685a298
    • Johannes Berg's avatar
      iwlwifi: pcie: don't crash on invalid RX interrupt · af73fb33
      Johannes Berg authored
      [ Upstream commit 30f24eab ]
      
      If for some reason the device gives us an RX interrupt before we're
      ready for it, perhaps during device power-on with misconfigured IRQ
      causes mapping or so, we can crash trying to access the queues.
      
      Prevent that by checking that we actually have RXQs and that they
      were properly allocated.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      af73fb33
    • Bart Van Assche's avatar
      scsi: qla2xxx: Fix a qla24xx_enable_msix() error path · 9375939f
      Bart Van Assche authored
      [ Upstream commit 24afabdb ]
      
      Make sure that the allocated interrupts are freed if allocating memory for
      the msix_entries array fails.
      
      Cc: Himanshu Madhani <hmadhani@marvell.com>
      Cc: Giridhar Malavali <gmalavali@marvell.com>
      Signed-off-by: default avatarBart Van Assche <bvanassche@acm.org>
      Acked-by: default avatarHimanshu Madhani <hmadhani@marvell.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      9375939f
    • Viresh Kumar's avatar
      sched/cpufreq: Fix kobject memleak · 4e0c06e0
      Viresh Kumar authored
      [ Upstream commit 9a4f26cc ]
      
      Currently the error return path from kobject_init_and_add() is not
      followed by a call to kobject_put() - which means we are leaking
      the kobject.
      
      Fix it by adding a call to kobject_put() in the error path of
      kobject_init_and_add().
      Signed-off-by: default avatarTobin C. Harding <tobin@kernel.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Tobin C. Harding <tobin@kernel.org>
      Cc: Vincent Guittot <vincent.guittot@linaro.org>
      Cc: Viresh Kumar <viresh.kumar@linaro.org>
      Link: http://lkml.kernel.org/r/20190430001144.24890-1-tobin@kernel.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      4e0c06e0
    • Qian Cai's avatar
      arm64: Fix compiler warning from pte_unmap() with -Wunused-but-set-variable · b5b14bf2
      Qian Cai authored
      [ Upstream commit 74dd022f ]
      
      When building with -Wunused-but-set-variable, the compiler shouts about
      a number of pte_unmap() users, since this expands to an empty macro on
      arm64:
      
        | mm/gup.c: In function 'gup_pte_range':
        | mm/gup.c:1727:16: warning: variable 'ptem' set but not used
        | [-Wunused-but-set-variable]
        | mm/gup.c: At top level:
        | mm/memory.c: In function 'copy_pte_range':
        | mm/memory.c:821:24: warning: variable 'orig_dst_pte' set but not used
        | [-Wunused-but-set-variable]
        | mm/memory.c:821:9: warning: variable 'orig_src_pte' set but not used
        | [-Wunused-but-set-variable]
        | mm/swap_state.c: In function 'swap_ra_info':
        | mm/swap_state.c:641:15: warning: variable 'orig_pte' set but not used
        | [-Wunused-but-set-variable]
        | mm/madvise.c: In function 'madvise_free_pte_range':
        | mm/madvise.c:318:9: warning: variable 'orig_pte' set but not used
        | [-Wunused-but-set-variable]
      
      Rewrite pte_unmap() as a static inline function, which silences the
      warnings.
      Signed-off-by: default avatarQian Cai <cai@lca.pw>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      b5b14bf2
    • Marc Zyngier's avatar
      ARM: vdso: Remove dependency with the arch_timer driver internals · 79940ddb
      Marc Zyngier authored
      [ Upstream commit 1f5b62f0 ]
      
      The VDSO code uses the kernel helper that was originally designed
      to abstract the access between 32 and 64bit systems. It worked so
      far because this function is declared as 'inline'.
      
      As we're about to revamp that part of the code, the VDSO would
      break. Let's fix it by doing what should have been done from
      the start, a proper system register access.
      Reviewed-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      79940ddb
    • Dan Carpenter's avatar
      brcm80211: potential NULL dereference in brcmf_cfg80211_vndr_cmds_dcmd_handler() · 146579dd
      Dan Carpenter authored
      [ Upstream commit e025da3d ]
      
      If "ret_len" is negative then it could lead to a NULL dereference.
      
      The "ret_len" value comes from nl80211_vendor_cmd(), if it's negative
      then we don't allocate the "dcmd_buf" buffer.  Then we pass "ret_len" to
      brcmf_fil_cmd_data_set() where it is cast to a very high u32 value.
      Most of the functions in that call tree check whether the buffer we pass
      is NULL but there are at least a couple places which don't such as
      brcmf_dbg_hex_dump() and brcmf_msgbuf_query_dcmd().  We memcpy() to and
      from the buffer so it would result in a NULL dereference.
      
      The fix is to change the types so that "ret_len" can't be negative.  (If
      we memcpy() zero bytes to NULL, that's a no-op and doesn't cause an
      issue).
      
      Fixes: 1bacb048 ("brcmfmac: replace cfg80211 testmode with vendor command")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      146579dd
    • Flavio Suligoi's avatar
      spi: pxa2xx: fix SCR (divisor) calculation · 0f31932a
      Flavio Suligoi authored
      [ Upstream commit 29f21337 ]
      
      Calculate the divisor for the SCR (Serial Clock Rate), avoiding
      that the SSP transmission rate can be greater than the device rate.
      
      When the division between the SSP clock and the device rate generates
      a reminder, we have to increment by one the divisor.
      In this way the resulting SSP clock will never be greater than the
      device SPI max frequency.
      
      For example, with:
      
       - ssp_clk  = 50 MHz
       - dev freq = 15 MHz
      
      without this patch the SSP clock will be greater than 15 MHz:
      
       - 25 MHz for PXA25x_SSP and CE4100_SSP
       - 16,56 MHz for the others
      
      Instead, with this patch, we have in both case an SSP clock of 12.5MHz,
      so the max rate of the SPI device clock is respected.
      Signed-off-by: default avatarFlavio Suligoi <f.suligoi@asem.it>
      Reviewed-by: default avatarJarkko Nikula <jarkko.nikula@linux.intel.com>
      Reviewed-by: default avatarJarkko Nikula <jarkko.nikula@linux.intel.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      0f31932a
    • Arnd Bergmann's avatar
      ASoC: imx: fix fiq dependencies · 68f630d8
      Arnd Bergmann authored
      [ Upstream commit ea751227 ]
      
      During randconfig builds, I occasionally run into an invalid configuration
      of the freescale FIQ sound support:
      
      WARNING: unmet direct dependencies detected for SND_SOC_IMX_PCM_FIQ
        Depends on [m]: SOUND [=y] && !UML && SND [=y] && SND_SOC [=y] && SND_IMX_SOC [=m]
        Selected by [y]:
        - SND_SOC_FSL_SPDIF [=y] && SOUND [=y] && !UML && SND [=y] && SND_SOC [=y] && SND_IMX_SOC [=m]!=n && (MXC_TZIC [=n] || MXC_AVIC [=y])
      
      sound/soc/fsl/imx-ssi.o: In function `imx_ssi_remove':
      imx-ssi.c:(.text+0x28): undefined reference to `imx_pcm_fiq_exit'
      sound/soc/fsl/imx-ssi.o: In function `imx_ssi_probe':
      imx-ssi.c:(.text+0xa64): undefined reference to `imx_pcm_fiq_init'
      
      The Kconfig warning is a result of the symbol being defined inside of
      the "if SND_IMX_SOC" block, and is otherwise harmless. The link error
      is more tricky and happens with SND_SOC_IMX_SSI=y, which may or may not
      imply FIQ support. However, if SND_SOC_FSL_SSI is set to =m at the same
      time, that selects SND_SOC_IMX_PCM_FIQ as a loadable module dependency,
      which then causes a link failure from imx-ssi.
      
      The solution here is to make SND_SOC_IMX_PCM_FIQ built-in whenever
      one of its potential users is built-in.
      
      Fixes: ff40260f ("ASoC: fsl: refine DMA/FIQ dependencies")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      68f630d8
    • Bo YU's avatar
      powerpc/boot: Fix missing check of lseek() return value · bfcbe505
      Bo YU authored
      [ Upstream commit 5d085ec0 ]
      
      This is detected by Coverity scan: CID: 1440481
      Signed-off-by: default avatarBo YU <tsu.yubo@gmail.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      bfcbe505
    • Jerome Brunet's avatar
      ASoC: hdmi-codec: unlock the device on startup errors · da8db898
      Jerome Brunet authored
      [ Upstream commit 30180e84 ]
      
      If the hdmi codec startup fails, it should clear the current_substream
      pointer to free the device. This is properly done for the audio_startup()
      callback but for snd_pcm_hw_constraint_eld().
      
      Make sure the pointer cleared if an error is reported.
      Signed-off-by: default avatarJerome Brunet <jbrunet@baylibre.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      da8db898
    • Sameeh Jubran's avatar
      net: ena: gcc 8: fix compilation warning · 7b4ff6ae
      Sameeh Jubran authored
      [ Upstream commit f9133088 ]
      
      GCC 8 contains a number of new warnings as well as enhancements to existing
      checkers. The warning - Wstringop-truncation - warns for calls to bounded
      string manipulation functions such as strncat, strncpy, and stpncpy that
      may either truncate the copied string or leave the destination unchanged.
      
      In our case the destination string length (32 bytes) is much shorter than
      the source string (64 bytes) which causes this warning to show up. In
      general the destination has to be at least a byte larger than the length
      of the source string with strncpy for this warning not to showup.
      
      This can be easily fixed by using strlcpy instead which already does the
      truncation to the string. Documentation for this function can be
      found here:
      
      https://elixir.bootlin.com/linux/latest/source/lib/string.c#L141
      
      Fixes: 1738cd3e ("net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)")
      Signed-off-by: default avatarSameeh Jubran <sameehj@amazon.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      7b4ff6ae
    • Sameer Pujar's avatar
      dmaengine: tegra210-dma: free dma controller in remove() · 12ada5b2
      Sameer Pujar authored
      [ Upstream commit f030e419 ]
      
      Following kernel panic is seen during DMA driver unload->load sequence
      ==========================================================================
      Unable to handle kernel paging request at virtual address ffffff8001198880
      Internal error: Oops: 86000007 [#1] PREEMPT SMP
      CPU: 0 PID: 5907 Comm: HwBinder:4123_1 Tainted: G C 4.9.128-tegra-g065839f
      Hardware name: galen (DT)
      task: ffffffc3590d1a80 task.stack: ffffffc3d0678000
      PC is at 0xffffff8001198880
      LR is at of_dma_request_slave_channel+0xd8/0x1f8
      pc : [<ffffff8001198880>] lr : [<ffffff8008746f30>] pstate: 60400045
      sp : ffffffc3d067b710
      x29: ffffffc3d067b710 x28: 000000000000002f
      x27: ffffff800949e000 x26: ffffff800949e750
      x25: ffffff800949e000 x24: ffffffbefe817d84
      x23: ffffff8009f77cb0 x22: 0000000000000028
      x21: ffffffc3ffda49c8 x20: 0000000000000029
      x19: 0000000000000001 x18: ffffffffffffffff
      x17: 0000000000000000 x16: ffffff80082b66a0
      x15: ffffff8009e78250 x14: 000000000000000a
      x13: 0000000000000038 x12: 0101010101010101
      x11: 0000000000000030 x10: 0101010101010101
      x9 : fffffffffffffffc x8 : 7f7f7f7f7f7f7f7f
      x7 : 62ff726b6b64622c x6 : 0000000000008064
      x5 : 6400000000000000 x4 : ffffffbefe817c44
      x3 : ffffffc3ffda3e08 x2 : ffffff8001198880
      x1 : ffffffc3d48323c0 x0 : ffffffc3d067b788
      
      Process HwBinder:4123_1 (pid: 5907, stack limit = 0xffffffc3d0678028)
      Call trace:
      [<ffffff8001198880>] 0xffffff8001198880
      [<ffffff80087459f8>] dma_request_chan+0x50/0x1f0
      [<ffffff8008745bc0>] dma_request_slave_channel+0x28/0x40
      [<ffffff8001552c44>] tegra_alt_pcm_open+0x114/0x170
      [<ffffff8008d65fa4>] soc_pcm_open+0x10c/0x878
      [<ffffff8008d18618>] snd_pcm_open_substream+0xc0/0x170
      [<ffffff8008d1878c>] snd_pcm_open+0xc4/0x240
      [<ffffff8008d189e0>] snd_pcm_playback_open+0x58/0x80
      [<ffffff8008cfc6d4>] snd_open+0xb4/0x178
      [<ffffff8008250628>] chrdev_open+0xb8/0x1d0
      [<ffffff8008246fdc>] do_dentry_open+0x214/0x318
      [<ffffff80082485d0>] vfs_open+0x58/0x88
      [<ffffff800825bce0>] do_last+0x450/0xde0
      [<ffffff800825c718>] path_openat+0xa8/0x368
      [<ffffff800825dd84>] do_filp_open+0x8c/0x110
      [<ffffff8008248a74>] do_sys_open+0x164/0x220
      [<ffffff80082b66dc>] compat_SyS_openat+0x3c/0x50
      [<ffffff8008083040>] el0_svc_naked+0x34/0x38
      ---[ end trace 67e6d544e65b5145 ]---
      Kernel panic - not syncing: Fatal exception
      ==========================================================================
      
      In device probe(), of_dma_controller_register() registers DMA controller.
      But when driver is removed, this is not freed. During driver reload this
      results in data abort and kernel panic. Add of_dma_controller_free() in
      driver remove path to fix the issue.
      
      Fixes: f46b1957 ("dmaengine: tegra-adma: Add support for Tegra210 ADMA")
      Signed-off-by: default avatarSameer Pujar <spujar@nvidia.com>
      Reviewed-by: default avatarJon Hunter <jonathanh@nvidia.com>
      Signed-off-by: default avatarVinod Koul <vkoul@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      12ada5b2
    • Raul E Rangel's avatar
      mmc: core: Verify SD bus width · 48b759f4
      Raul E Rangel authored
      [ Upstream commit 9e4be8d0 ]
      
      The SD Physical Layer Spec says the following: Since the SD Memory Card
      shall support at least the two bus modes 1-bit or 4-bit width, then any SD
      Card shall set at least bits 0 and 2 (SD_BUS_WIDTH="0101").
      
      This change verifies the card has specified a bus width.
      
      AMD SDHC Device 7806 can get into a bad state after a card disconnect
      where anything transferred via the DATA lines will always result in a
      zero filled buffer. Currently the driver will continue without error if
      the HC is in this condition. A block device will be created, but reading
      from it will result in a zero buffer. This makes it seem like the SD
      device has been erased, when in actuality the data is never getting
      copied from the DATA lines to the data buffer.
      
      SCR is the first command in the SD initialization sequence that uses the
      DATA lines. By checking that the response was invalid, we can abort
      mounting the card.
      Reviewed-by: default avatarAvri Altman <avri.altman@wdc.com>
      Signed-off-by: default avatarRaul E Rangel <rrangel@chromium.org>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      48b759f4
    • YueHaibing's avatar
      cxgb4: Fix error path in cxgb4_init_module · af763226
      YueHaibing authored
      [ Upstream commit a3147770 ]
      
      BUG: unable to handle kernel paging request at ffffffffa016a270
      PGD 3270067 P4D 3270067 PUD 3271063 PMD 230bbd067 PTE 0
      Oops: 0000 [#1
      CPU: 0 PID: 6134 Comm: modprobe Not tainted 5.1.0+ #33
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014
      RIP: 0010:atomic_notifier_chain_register+0x24/0x60
      Code: 1f 80 00 00 00 00 55 48 89 e5 41 54 49 89 f4 53 48 89 fb e8 ae b4 38 01 48 8b 53 38 48 8d 4b 38 48 85 d2 74 20 45 8b 44 24 10 <44> 3b 42 10 7e 08 eb 13 44 39 42 10 7c 0d 48 8d 4a 08 48 8b 52 08
      RSP: 0018:ffffc90000e2bc60 EFLAGS: 00010086
      RAX: 0000000000000292 RBX: ffffffff83467240 RCX: ffffffff83467278
      RDX: ffffffffa016a260 RSI: ffffffff83752140 RDI: ffffffff83467240
      RBP: ffffc90000e2bc70 R08: 0000000000000000 R09: 0000000000000001
      R10: 0000000000000000 R11: 00000000014fa61f R12: ffffffffa01c8260
      R13: ffff888231091e00 R14: 0000000000000000 R15: ffffc90000e2be78
      FS:  00007fbd8d7cd540(0000) GS:ffff888237a00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: ffffffffa016a270 CR3: 000000022c7e3000 CR4: 00000000000006f0
      Call Trace:
       register_inet6addr_notifier+0x13/0x20
       cxgb4_init_module+0x6c/0x1000 [cxgb4
       ? 0xffffffffa01d7000
       do_one_initcall+0x6c/0x3cc
       ? do_init_module+0x22/0x1f1
       ? rcu_read_lock_sched_held+0x97/0xb0
       ? kmem_cache_alloc_trace+0x325/0x3b0
       do_init_module+0x5b/0x1f1
       load_module+0x1db1/0x2690
       ? m_show+0x1d0/0x1d0
       __do_sys_finit_module+0xc5/0xd0
       __x64_sys_finit_module+0x15/0x20
       do_syscall_64+0x6b/0x1d0
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      If pci_register_driver fails, register inet6addr_notifier is
      pointless. This patch fix the error path in cxgb4_init_module.
      
      Fixes: b5a02f50 ("cxgb4 : Update ipv6 address handling api")
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      af763226
    • Ross Lagerwall's avatar
      gfs2: Fix lru_count going negative · b568ed38
      Ross Lagerwall authored
      [ Upstream commit 7881ef3f ]
      
      Under certain conditions, lru_count may drop below zero resulting in
      a large amount of log spam like this:
      
      vmscan: shrink_slab: gfs2_dump_glock+0x3b0/0x630 [gfs2] \
          negative objects to delete nr=-1
      
      This happens as follows:
      1) A glock is moved from lru_list to the dispose list and lru_count is
         decremented.
      2) The dispose function calls cond_resched() and drops the lru lock.
      3) Another thread takes the lru lock and tries to add the same glock to
         lru_list, checking if the glock is on an lru list.
      4) It is on a list (actually the dispose list) and so it avoids
         incrementing lru_count.
      5) The glock is moved to lru_list.
      5) The original thread doesn't dispose it because it has been re-added
         to the lru list but the lru_count has still decreased by one.
      
      Fix by checking if the LRU flag is set on the glock rather than checking
      if the glock is on some list and rearrange the code so that the LRU flag
      is added/removed precisely when the glock is added/removed from lru_list.
      Signed-off-by: default avatarRoss Lagerwall <ross.lagerwall@citrix.com>
      Signed-off-by: default avatarAndreas Gruenbacher <agruenba@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      b568ed38
    • David Sterba's avatar
      Revert "btrfs: Honour FITRIM range constraints during free space trim" · abc261c8
      David Sterba authored
      This reverts commit 038ec2c1.
      
      There is currently no corresponding patch in master due to additional
      changes that would be significantly different from plain revert in the
      respective stable branch.
      
      The range argument was not handled correctly and could cause trim to
      overlap allocated areas or reach beyond the end of the device. The
      address space that fitrim normally operates on is in logical
      coordinates, while the discards are done on the physical device extents.
      This distinction cannot be made with the current ioctl interface and
      caused the confusion.
      
      The bug depends on the layout of block groups and does not always
      happen. The whole-fs trim (run by default by the fstrim tool) is not
      affected.
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      abc261c8
    • Arnaldo Carvalho de Melo's avatar
      tools include: Adopt linux/bits.h · 2f6644ff
      Arnaldo Carvalho de Melo authored
      commit ba4aa02b upstream.
      
      So that we reduce the difference of tools/include/linux/bitops.h to the
      original kernel file, include/linux/bitops.h, trying to remove the need
      to define BITS_PER_LONG, to avoid clashes with asm/bitsperlong.h.
      
      And the things removed from tools/include/linux/bitops.h are really in
      linux/bits.h, so that we can have a copy and then
      tools/perf/check_headers.sh will tell us when new stuff gets added to
      linux/bits.h so that we can check if it is useful and if any adjustment
      needs to be done to the tools/{include,arch}/ copies.
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexander Sverdlin <alexander.sverdlin@nokia.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: https://lkml.kernel.org/n/tip-y1sqyydvfzo0bjjoj4zsl562@git.kernel.orgSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      [bwh: Backported to 4.9 as dependency of "x86/msr-index: Cleanup bit defines";
       adjusted context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2f6644ff
    • Arnaldo Carvalho de Melo's avatar
      perf tools: No need to include bitops.h in util.h · d31e3e39
      Arnaldo Carvalho de Melo authored
      commit 6dcca6df upstream.
      
      When we switched to the kernel's roundup_pow_of_two we forgot to remove
      this include from util.h, do it now.
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Wang Nan <wangnan0@huawei.com>
      Fixes: 91529834 ("perf evlist: Use roundup_pow_of_two")
      Link: http://lkml.kernel.org/n/tip-kfye5rxivib6155cltx0bw4h@git.kernel.orgSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      [bwh: Backported to 4.9 as dependency of "tools include: Adopt linux/bits.h";
       adjusted context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d31e3e39
    • YueHaibing's avatar
      at76c50x-usb: Don't register led_trigger if usb_register_driver failed · a186a933
      YueHaibing authored
      commit 09ac2694 upstream.
      
      Syzkaller report this:
      
      [ 1213.468581] BUG: unable to handle kernel paging request at fffffbfff83bf338
      [ 1213.469530] #PF error: [normal kernel read fault]
      [ 1213.469530] PGD 237fe4067 P4D 237fe4067 PUD 237e60067 PMD 1c868b067 PTE 0
      [ 1213.473514] Oops: 0000 [#1] SMP KASAN PTI
      [ 1213.473514] CPU: 0 PID: 6321 Comm: syz-executor.0 Tainted: G         C        5.1.0-rc3+ #8
      [ 1213.473514] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
      [ 1213.473514] RIP: 0010:strcmp+0x31/0xa0
      [ 1213.473514] Code: 00 00 00 00 fc ff df 55 53 48 83 ec 08 eb 0a 84 db 48 89 ef 74 5a 4c 89 e6 48 89 f8 48 89 fa 48 8d 6f 01 48 c1 e8 03 83 e2 07 <42> 0f b6 04 28 38 d0 7f 04 84 c0 75 50 48 89 f0 48 89 f2 0f b6 5d
      [ 1213.473514] RSP: 0018:ffff8881f2b7f950 EFLAGS: 00010246
      [ 1213.473514] RAX: 1ffffffff83bf338 RBX: ffff8881ea6f7240 RCX: ffffffff825350c6
      [ 1213.473514] RDX: 0000000000000000 RSI: ffffffffc1ee19c0 RDI: ffffffffc1df99c0
      [ 1213.473514] RBP: ffffffffc1df99c1 R08: 0000000000000001 R09: 0000000000000004
      [ 1213.473514] R10: 0000000000000000 R11: ffff8881de353f00 R12: ffff8881ee727900
      [ 1213.473514] R13: dffffc0000000000 R14: 0000000000000001 R15: ffffffffc1eeaaf0
      [ 1213.473514] FS:  00007fa66fa01700(0000) GS:ffff8881f7200000(0000) knlGS:0000000000000000
      [ 1213.473514] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [ 1213.473514] CR2: fffffbfff83bf338 CR3: 00000001ebb9e005 CR4: 00000000007606f0
      [ 1213.473514] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [ 1213.473514] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [ 1213.473514] PKRU: 55555554
      [ 1213.473514] Call Trace:
      [ 1213.473514]  led_trigger_register+0x112/0x3f0
      [ 1213.473514]  led_trigger_register_simple+0x7a/0x110
      [ 1213.473514]  ? 0xffffffffc1c10000
      [ 1213.473514]  at76_mod_init+0x77/0x1000 [at76c50x_usb]
      [ 1213.473514]  do_one_initcall+0xbc/0x47d
      [ 1213.473514]  ? perf_trace_initcall_level+0x3a0/0x3a0
      [ 1213.473514]  ? kasan_unpoison_shadow+0x30/0x40
      [ 1213.473514]  ? kasan_unpoison_shadow+0x30/0x40
      [ 1213.473514]  do_init_module+0x1b5/0x547
      [ 1213.473514]  load_module+0x6405/0x8c10
      [ 1213.473514]  ? module_frob_arch_sections+0x20/0x20
      [ 1213.473514]  ? kernel_read_file+0x1e6/0x5d0
      [ 1213.473514]  ? find_held_lock+0x32/0x1c0
      [ 1213.473514]  ? cap_capable+0x1ae/0x210
      [ 1213.473514]  ? __do_sys_finit_module+0x162/0x190
      [ 1213.473514]  __do_sys_finit_module+0x162/0x190
      [ 1213.473514]  ? __ia32_sys_init_module+0xa0/0xa0
      [ 1213.473514]  ? __mutex_unlock_slowpath+0xdc/0x690
      [ 1213.473514]  ? wait_for_completion+0x370/0x370
      [ 1213.473514]  ? vfs_write+0x204/0x4a0
      [ 1213.473514]  ? do_syscall_64+0x18/0x450
      [ 1213.473514]  do_syscall_64+0x9f/0x450
      [ 1213.473514]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
      [ 1213.473514] RIP: 0033:0x462e99
      [ 1213.473514] Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
      [ 1213.473514] RSP: 002b:00007fa66fa00c58 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
      [ 1213.473514] RAX: ffffffffffffffda RBX: 000000000073bf00 RCX: 0000000000462e99
      [ 1213.473514] RDX: 0000000000000000 RSI: 0000000020000300 RDI: 0000000000000003
      [ 1213.473514] RBP: 00007fa66fa00c70 R08: 0000000000000000 R09: 0000000000000000
      [ 1213.473514] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fa66fa016bc
      [ 1213.473514] R13: 00000000004bcefa R14: 00000000006f6fb0 R15: 0000000000000004
      
      If usb_register failed, no need to call led_trigger_register_simple.
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Fixes: 1264b951 ("at76c50x-usb: add driver")
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a186a933
    • YueHaibing's avatar
      ssb: Fix possible NULL pointer dereference in ssb_host_pcmcia_exit · 2c815115
      YueHaibing authored
      commit b2c01aab upstream.
      
      Syzkaller report this:
      
      kasan: GPF could be caused by NULL-ptr deref or user memory access
      general protection fault: 0000 [#1] SMP KASAN PTI
      CPU: 0 PID: 4492 Comm: syz-executor.0 Not tainted 5.0.0-rc7+ #45
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
      RIP: 0010:sysfs_remove_file_ns+0x27/0x70 fs/sysfs/file.c:468
      Code: 00 00 00 41 54 55 48 89 fd 53 49 89 d4 48 89 f3 e8 ee 76 9c ff 48 8d 7d 30 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 75 2d 48 89 da 48 b8 00 00 00 00 00 fc ff df 48 8b 6d
      RSP: 0018:ffff8881e9d9fc00 EFLAGS: 00010206
      RAX: dffffc0000000000 RBX: ffffffff900367e0 RCX: ffffffff81a95952
      RDX: 0000000000000006 RSI: ffffc90001405000 RDI: 0000000000000030
      RBP: 0000000000000000 R08: fffffbfff1fa22ed R09: fffffbfff1fa22ed
      R10: 0000000000000001 R11: fffffbfff1fa22ec R12: 0000000000000000
      R13: ffffffffc1abdac0 R14: 1ffff1103d3b3f8b R15: 0000000000000000
      FS:  00007fe409dc1700(0000) GS:ffff8881f1200000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000001b2d721000 CR3: 00000001e98b6005 CR4: 00000000007606f0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      PKRU: 55555554
      Call Trace:
       sysfs_remove_file include/linux/sysfs.h:519 [inline]
       driver_remove_file+0x40/0x50 drivers/base/driver.c:122
       pcmcia_remove_newid_file drivers/pcmcia/ds.c:163 [inline]
       pcmcia_unregister_driver+0x7d/0x2b0 drivers/pcmcia/ds.c:209
       ssb_modexit+0xa/0x1b [ssb]
       __do_sys_delete_module kernel/module.c:1018 [inline]
       __se_sys_delete_module kernel/module.c:961 [inline]
       __x64_sys_delete_module+0x3dc/0x5e0 kernel/module.c:961
       do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x462e99
      Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
      RSP: 002b:00007fe409dc0c58 EFLAGS: 00000246 ORIG_RAX: 00000000000000b0
      RAX: ffffffffffffffda RBX: 000000000073bf00 RCX: 0000000000462e99
      RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00000000200000c0
      RBP: 0000000000000002 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe409dc16bc
      R13: 00000000004bccaa R14: 00000000006f6bc8 R15: 00000000ffffffff
      Modules linked in: ssb(-) 3c59x nvme_core macvlan tap pata_hpt3x3 rt2x00pci null_blk tsc40 pm_notifier_error_inject notifier_error_inject mdio cdc_wdm nf_reject_ipv4 ath9k_common ath9k_hw ath pppox ppp_generic slhc ehci_platform wl12xx wlcore tps6507x_ts ioc4 nf_synproxy_core ide_gd_mod ax25 can_dev iwlwifi can_raw atm tm2_touchkey can_gw can sundance adp5588_keys rt2800mmio rt2800lib rt2x00mmio rt2x00lib eeprom_93cx6 pn533 lru_cache elants_i2c ip_set nfnetlink gameport tipc hampshire nhc_ipv6 nhc_hop nhc_udp nhc_fragment nhc_routing nhc_mobility nhc_dest 6lowpan silead brcmutil nfc mt76_usb mt76 mac80211 iptable_security iptable_raw iptable_mangle iptable_nat nf_nat_ipv4 nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_filter bpfilter ip6_vti ip_gre sit hsr veth vxcan batman_adv cfg80211 rfkill chnl_net caif nlmon vcan bridge stp llc ip6_gre ip6_tunnel tunnel6 tun joydev mousedev serio_raw ide_pci_generic piix floppy ide_core sch_fq_codel ip_tables x_tables ipv6
       [last unloaded: 3c59x]
      Dumping ftrace buffer:
         (ftrace buffer empty)
      ---[ end trace 3913cbf8011e1c05 ]---
      
      In ssb_modinit, it does not fail SSB init when ssb_host_pcmcia_init failed,
      however in ssb_modexit, ssb_host_pcmcia_exit calls pcmcia_unregister_driver
      unconditionally, which may tigger a NULL pointer dereference issue as above.
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Fixes: 399500da ("ssb: pick PCMCIA host code support from b43 driver")
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2c815115
    • Alexander Potapenko's avatar
      media: vivid: use vfree() instead of kfree() for dev->bitmap_cap · 5c6631b4
      Alexander Potapenko authored
      commit dad7e270 upstream.
      
      syzkaller reported crashes on kfree() called from
      vivid_vid_cap_s_selection(). This looks like a simple typo, as
      dev->bitmap_cap is allocated with vzalloc() throughout the file.
      
      Fixes: ef834f78 ("[media] vivid: add the video capture and output
      parts")
      Signed-off-by: default avatarAlexander Potapenko <glider@google.com>
      Reported-by: default avatarSyzbot <syzbot+6c0effb5877f6b0344e2@syzkaller.appspotmail.com>
      Signed-off-by: default avatarHans Verkuil <hverkuil-cisco@xs4all.nl>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5c6631b4
    • YueHaibing's avatar
      media: cpia2: Fix use-after-free in cpia2_exit · 14734c3c
      YueHaibing authored
      commit dea37a97 upstream.
      
      Syzkaller report this:
      
      BUG: KASAN: use-after-free in sysfs_remove_file_ns+0x5f/0x70 fs/sysfs/file.c:468
      Read of size 8 at addr ffff8881f59a6b70 by task syz-executor.0/8363
      
      CPU: 0 PID: 8363 Comm: syz-executor.0 Not tainted 5.0.0-rc8+ #3
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
      Call Trace:
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0xfa/0x1ce lib/dump_stack.c:113
       print_address_description+0x65/0x270 mm/kasan/report.c:187
       kasan_report+0x149/0x18d mm/kasan/report.c:317
       sysfs_remove_file_ns+0x5f/0x70 fs/sysfs/file.c:468
       sysfs_remove_file include/linux/sysfs.h:519 [inline]
       driver_remove_file+0x40/0x50 drivers/base/driver.c:122
       usb_remove_newid_files drivers/usb/core/driver.c:212 [inline]
       usb_deregister+0x12a/0x3b0 drivers/usb/core/driver.c:1005
       cpia2_exit+0xa/0x16 [cpia2]
       __do_sys_delete_module kernel/module.c:1018 [inline]
       __se_sys_delete_module kernel/module.c:961 [inline]
       __x64_sys_delete_module+0x3dc/0x5e0 kernel/module.c:961
       do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x462e99
      Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
      RSP: 002b:00007f86f3754c58 EFLAGS: 00000246 ORIG_RAX: 00000000000000b0
      RAX: ffffffffffffffda RBX: 000000000073bf00 RCX: 0000000000462e99
      RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000020000300
      RBP: 0000000000000002 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 00007f86f37556bc
      R13: 00000000004bcca9 R14: 00000000006f6b48 R15: 00000000ffffffff
      
      Allocated by task 8363:
       set_track mm/kasan/common.c:85 [inline]
       __kasan_kmalloc.constprop.3+0xa0/0xd0 mm/kasan/common.c:495
       kmalloc include/linux/slab.h:545 [inline]
       kzalloc include/linux/slab.h:740 [inline]
       bus_add_driver+0xc0/0x610 drivers/base/bus.c:651
       driver_register+0x1bb/0x3f0 drivers/base/driver.c:170
       usb_register_driver+0x267/0x520 drivers/usb/core/driver.c:965
       0xffffffffc1b4817c
       do_one_initcall+0xfa/0x5ca init/main.c:887
       do_init_module+0x204/0x5f6 kernel/module.c:3460
       load_module+0x66b2/0x8570 kernel/module.c:3808
       __do_sys_finit_module+0x238/0x2a0 kernel/module.c:3902
       do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Freed by task 8363:
       set_track mm/kasan/common.c:85 [inline]
       __kasan_slab_free+0x130/0x180 mm/kasan/common.c:457
       slab_free_hook mm/slub.c:1430 [inline]
       slab_free_freelist_hook mm/slub.c:1457 [inline]
       slab_free mm/slub.c:3005 [inline]
       kfree+0xe1/0x270 mm/slub.c:3957
       kobject_cleanup lib/kobject.c:662 [inline]
       kobject_release lib/kobject.c:691 [inline]
       kref_put include/linux/kref.h:67 [inline]
       kobject_put+0x146/0x240 lib/kobject.c:708
       bus_remove_driver+0x10e/0x220 drivers/base/bus.c:732
       driver_unregister+0x6c/0xa0 drivers/base/driver.c:197
       usb_register_driver+0x341/0x520 drivers/usb/core/driver.c:980
       0xffffffffc1b4817c
       do_one_initcall+0xfa/0x5ca init/main.c:887
       do_init_module+0x204/0x5f6 kernel/module.c:3460
       load_module+0x66b2/0x8570 kernel/module.c:3808
       __do_sys_finit_module+0x238/0x2a0 kernel/module.c:3902
       do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      The buggy address belongs to the object at ffff8881f59a6b40
       which belongs to the cache kmalloc-256 of size 256
      The buggy address is located 48 bytes inside of
       256-byte region [ffff8881f59a6b40, ffff8881f59a6c40)
      The buggy address belongs to the page:
      page:ffffea0007d66980 count:1 mapcount:0 mapping:ffff8881f6c02e00 index:0x0
      flags: 0x2fffc0000000200(slab)
      raw: 02fffc0000000200 dead000000000100 dead000000000200 ffff8881f6c02e00
      raw: 0000000000000000 00000000800c000c 00000001ffffffff 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffff8881f59a6a00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
       ffff8881f59a6a80: 00 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc
      >ffff8881f59a6b00: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
                                                                   ^
       ffff8881f59a6b80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff8881f59a6c00: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
      
      cpia2_init does not check return value of cpia2_init, if it failed
      in usb_register_driver, there is already cleanup using driver_unregister.
      No need call cpia2_usb_cleanup on module exit.
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Signed-off-by: default avatarHans Verkuil <hverkuil-cisco@xs4all.nl>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      14734c3c
    • Jiufei Xue's avatar
      fbdev: fix WARNING in __alloc_pages_nodemask bug · d0c04be9
      Jiufei Xue authored
      commit 8c40292b upstream.
      
      Syzkaller hit 'WARNING in __alloc_pages_nodemask' bug.
      
      WARNING: CPU: 1 PID: 1473 at mm/page_alloc.c:4377
      __alloc_pages_nodemask+0x4da/0x2130
      Kernel panic - not syncing: panic_on_warn set ...
      
      Call Trace:
       alloc_pages_current+0xb1/0x1e0
       kmalloc_order+0x1f/0x60
       kmalloc_order_trace+0x1d/0x120
       fb_alloc_cmap_gfp+0x85/0x2b0
       fb_set_user_cmap+0xff/0x370
       do_fb_ioctl+0x949/0xa20
       fb_ioctl+0xdd/0x120
       do_vfs_ioctl+0x186/0x1070
       ksys_ioctl+0x89/0xa0
       __x64_sys_ioctl+0x74/0xb0
       do_syscall_64+0xc8/0x550
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      This is a warning about order >= MAX_ORDER and the order is from
      userspace ioctl. Add flag __NOWARN to silence this warning.
      Signed-off-by: default avatarJiufei Xue <jiufei.xue@linux.alibaba.com>
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d0c04be9
    • Mike Kravetz's avatar
      hugetlb: use same fault hash key for shared and private mappings · f0539c70
      Mike Kravetz authored
      commit 1b426bac upstream.
      
      hugetlb uses a fault mutex hash table to prevent page faults of the
      same pages concurrently.  The key for shared and private mappings is
      different.  Shared keys off address_space and file index.  Private keys
      off mm and virtual address.  Consider a private mappings of a populated
      hugetlbfs file.  A fault will map the page from the file and if needed
      do a COW to map a writable page.
      
      Hugetlbfs hole punch uses the fault mutex to prevent mappings of file
      pages.  It uses the address_space file index key.  However, private
      mappings will use a different key and could race with this code to map
      the file page.  This causes problems (BUG) for the page cache remove
      code as it expects the page to be unmapped.  A sample stack is:
      
      page dumped because: VM_BUG_ON_PAGE(page_mapped(page))
      kernel BUG at mm/filemap.c:169!
      ...
      RIP: 0010:unaccount_page_cache_page+0x1b8/0x200
      ...
      Call Trace:
      __delete_from_page_cache+0x39/0x220
      delete_from_page_cache+0x45/0x70
      remove_inode_hugepages+0x13c/0x380
      ? __add_to_page_cache_locked+0x162/0x380
      hugetlbfs_fallocate+0x403/0x540
      ? _cond_resched+0x15/0x30
      ? __inode_security_revalidate+0x5d/0x70
      ? selinux_file_permission+0x100/0x130
      vfs_fallocate+0x13f/0x270
      ksys_fallocate+0x3c/0x80
      __x64_sys_fallocate+0x1a/0x20
      do_syscall_64+0x5b/0x180
      entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      There seems to be another potential COW issue/race with this approach
      of different private and shared keys as noted in commit 8382d914
      ("mm, hugetlb: improve page-fault scalability").
      
      Since every hugetlb mapping (even anon and private) is actually a file
      mapping, just use the address_space index key for all mappings.  This
      results in potentially more hash collisions.  However, this should not
      be the common case.
      
      Link: http://lkml.kernel.org/r/20190328234704.27083-3-mike.kravetz@oracle.com
      Link: http://lkml.kernel.org/r/20190412165235.t4sscoujczfhuiyt@linux-r8p5
      Fixes: b5cec28d ("hugetlbfs: truncate_hugepages() takes a range of pages")
      Signed-off-by: default avatarMike Kravetz <mike.kravetz@oracle.com>
      Reviewed-by: default avatarNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Reviewed-by: default avatarDavidlohr Bueso <dbueso@suse.de>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>
      Cc: Michal Hocko <mhocko@kernel.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f0539c70
    • Shile Zhang's avatar
      fbdev: fix divide error in fb_var_to_videomode · 45dbaee4
      Shile Zhang authored
      commit cf84807f upstream.
      
      To fix following divide-by-zero error found by Syzkaller:
      
        divide error: 0000 [#1] SMP PTI
        CPU: 7 PID: 8447 Comm: test Kdump: loaded Not tainted 4.19.24-8.al7.x86_64 #1
        Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014
        RIP: 0010:fb_var_to_videomode+0xae/0xc0
        Code: 04 44 03 46 78 03 4e 7c 44 03 46 68 03 4e 70 89 ce d1 ee 69 c0 e8 03 00 00 f6 c2 01 0f 45 ce 83 e2 02 8d 34 09 0f 45 ce 31 d2 <41> f7 f0 31 d2 f7 f1 89 47 08 f3 c3 66 0f 1f 44 00 00 0f 1f 44 00
        RSP: 0018:ffffb7e189347bf0 EFLAGS: 00010246
        RAX: 00000000e1692410 RBX: ffffb7e189347d60 RCX: 0000000000000000
        RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffb7e189347c10
        RBP: ffff99972a091c00 R08: 0000000000000000 R09: 0000000000000000
        R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000100
        R13: 0000000000010000 R14: 00007ffd66baf6d0 R15: 0000000000000000
        FS:  00007f2054d11740(0000) GS:ffff99972fbc0000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        CR2: 00007f205481fd20 CR3: 00000004288a0001 CR4: 00000000001606a0
        Call Trace:
         fb_set_var+0x257/0x390
         ? lookup_fast+0xbb/0x2b0
         ? fb_open+0xc0/0x140
         ? chrdev_open+0xa6/0x1a0
         do_fb_ioctl+0x445/0x5a0
         do_vfs_ioctl+0x92/0x5f0
         ? __alloc_fd+0x3d/0x160
         ksys_ioctl+0x60/0x90
         __x64_sys_ioctl+0x16/0x20
         do_syscall_64+0x5b/0x190
         entry_SYSCALL_64_after_hwframe+0x44/0xa9
        RIP: 0033:0x7f20548258d7
        Code: 44 00 00 48 8b 05 b9 15 2d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 89 15 2d 00 f7 d8 64 89 01 48
      
      It can be triggered easily with following test code:
      
        #include <linux/fb.h>
        #include <fcntl.h>
        #include <sys/ioctl.h>
        int main(void)
        {
                struct fb_var_screeninfo var = {.activate = 0x100, .pixclock = 60};
                int fd = open("/dev/fb0", O_RDWR);
                if (fd < 0)
                        return 1;
      
                if (ioctl(fd, FBIOPUT_VSCREENINFO, &var))
                        return 1;
      
                return 0;
        }
      Signed-off-by: default avatarShile Zhang <shile.zhang@linux.alibaba.com>
      Cc: Fredrik Noring <noring@nocrew.org>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Reviewed-by: default avatarMukesh Ojha <mojha@codeaurora.org>
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      45dbaee4
    • Tobin C. Harding's avatar
      btrfs: sysfs: don't leak memory when failing add fsid · e0c26e8a
      Tobin C. Harding authored
      commit e3277335 upstream.
      
      A failed call to kobject_init_and_add() must be followed by a call to
      kobject_put().  Currently in the error path when adding fs_devices we
      are missing this call.  This could be fixed by calling
      btrfs_sysfs_remove_fsid() if btrfs_sysfs_add_fsid() returns an error or
      by adding a call to kobject_put() directly in btrfs_sysfs_add_fsid().
      Here we choose the second option because it prevents the slightly
      unusual error path handling requirements of kobject from leaking out
      into btrfs functions.
      
      Add a call to kobject_put() in the error path of kobject_add_and_init().
      This causes the release method to be called if kobject_init_and_add()
      fails.  open_tree() is the function that calls btrfs_sysfs_add_fsid()
      and the error code in this function is already written with the
      assumption that the release method is called during the error path of
      open_tree() (as seen by the call to btrfs_sysfs_remove_fsid() under the
      fail_fsdev_sysfs label).
      
      Cc: stable@vger.kernel.org # v4.4+
      Reviewed-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarTobin C. Harding <tobin@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>
      e0c26e8a