commit e132c8d7b58d8dc2c1888f5768454550d1f3ea7b
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Oct 11 18:18:50 2019 +0200

    Linux 4.14.149

commit a61e5804ef08f20e9bea8ad8c069e6a1f4a40523
Author: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
Date:   Wed Oct 9 14:38:41 2019 +0000

    ASoC: sgtl5000: Improve VAG power and mute control
    
    [ Upstream commit b1f373a11d25fc9a5f7679c9b85799fe09b0dc4a ]
    
    VAG power control is improved to fit the manual [1]. This patch fixes as
    minimum one bug: if customer muxes Headphone to Line-In right after boot,
    the VAG power remains off that leads to poor sound quality from line-in.
    
    I.e. after boot:
      - Connect sound source to Line-In jack;
      - Connect headphone to HP jack;
      - Run following commands:
      $ amixer set 'Headphone' 80%
      $ amixer set 'Headphone Mux' LINE_IN
    
    Change VAG power on/off control according to the following algorithm:
      - turn VAG power ON on the 1st incoming event.
      - keep it ON if there is any active VAG consumer (ADC/DAC/HP/Line-In).
      - turn VAG power OFF when there is the latest consumer's pre-down event
        come.
      - always delay after VAG power OFF to avoid pop.
      - delay after VAG power ON if the initiative consumer is Line-In, this
        prevents pop during line-in muxing.
    
    According to the data sheet [1], to avoid any pops/clicks,
    the outputs should be muted during input/output
    routing changes.
    
    [1] https://www.nxp.com/docs/en/data-sheet/SGTL5000.pdf
    
    Cc: stable@vger.kernel.org
    Fixes: 9b34e6cc3bc2 ("ASoC: Add Freescale SGTL5000 codec support")
    Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
    Reviewed-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
    Reviewed-by: Fabio Estevam <festevam@gmail.com>
    Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
    Link: https://lore.kernel.org/r/20190719100524.23300-3-oleksandr.suvorov@toradex.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 01ec813e457954d8eeaf768d57d625752d245bc9
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Fri Sep 20 21:54:17 2019 +0200

    nl80211: validate beacon head
    
    commit f88eb7c0d002a67ef31aeb7850b42ff69abc46dc upstream.
    
    We currently don't validate the beacon head, i.e. the header,
    fixed part and elements that are to go in front of the TIM
    element. This means that the variable elements there can be
    malformed, e.g. have a length exceeding the buffer size, but
    most downstream code from this assumes that this has already
    been checked.
    
    Add the necessary checks to the netlink policy.
    
    Cc: stable@vger.kernel.org
    Fixes: ed1b6cc7f80f ("cfg80211/nl80211: add beacon settings")
    Link: https://lore.kernel.org/r/1569009255-I7ac7fbe9436e9d8733439eab8acbbd35e55c74ef@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cd813e524abcf7dc89231930858f1ac3af372af9
Author: Jouni Malinen <j@w1.fi>
Date:   Mon Feb 11 16:29:04 2019 +0200

    cfg80211: Use const more consistently in for_each_element macros
    
    commit 7388afe09143210f555bdd6c75035e9acc1fab96 upstream.
    
    Enforce the first argument to be a correct type of a pointer to struct
    element and avoid unnecessary typecasts from const to non-const pointers
    (the change in validate_ie_attr() is needed to make this part work). In
    addition, avoid signed/unsigned comparison within for_each_element() and
    mark struct element packed just in case.
    
    Signed-off-by: Jouni Malinen <j@w1.fi>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1b1e2db0298a0ac7e57f744c3b3bd280273fe6ea
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Thu Feb 7 21:44:41 2019 +0100

    cfg80211: add and use strongly typed element iteration macros
    
    commit 0f3b07f027f87a38ebe5c436490095df762819be upstream.
    
    Rather than always iterating elements from frames with pure
    u8 pointers, add a type "struct element" that encapsulates
    the id/datalen/data format of them.
    
    Then, add the element iteration macros
     * for_each_element
     * for_each_element_id
     * for_each_element_extid
    
    which take, as their first 'argument', such a structure and
    iterate through a given u8 array interpreting it as elements.
    
    While at it and since we'll need it, also add
     * for_each_subelement
     * for_each_subelement_id
     * for_each_subelement_extid
    
    which instead of taking data/length just take an outer element
    and use its data/datalen.
    
    Also add for_each_element_completed() to determine if any of
    the loops above completed, i.e. it was able to parse all of
    the elements successfully and no data remained.
    
    Use for_each_element_id() in cfg80211_find_ie_match() as the
    first user of this.
    
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 64e0dc34362707070420490a6f0d5716f61d3b27
Author: Andrew Murray <andrew.murray@arm.com>
Date:   Thu Aug 29 14:28:35 2019 -0600

    coresight: etm4x: Use explicit barriers on enable/disable
    
    commit 1004ce4c255fc3eb3ad9145ddd53547d1b7ce327 upstream.
    
    Synchronization is recommended before disabling the trace registers
    to prevent any start or stop points being speculative at the point
    of disabling the unit (section 7.3.77 of ARM IHI 0064D).
    
    Synchronization is also recommended after programming the trace
    registers to ensure all updates are committed prior to normal code
    resuming (section 4.3.7 of ARM IHI 0064D).
    
    Let's ensure these syncronization points are present in the code
    and clearly commented.
    
    Note that we could rely on the barriers in CS_LOCK and
    coresight_disclaim_device_unlocked or the context switch to user
    space - however coresight may be of use in the kernel.
    
    On armv8 the mb macro is defined as dsb(sy) - Given that the etm4x is
    only used on armv8 let's directly use dsb(sy) instead of mb(). This
    removes some ambiguity and makes it easier to correlate the code with
    the TRM.
    
    Signed-off-by: Andrew Murray <andrew.murray@arm.com>
    Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    [Fixed capital letter for "use" in title]
    Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
    Link: https://lore.kernel.org/r/20190829202842.580-11-mathieu.poirier@linaro.org
    Cc: stable@vger.kernel.org # 4.9+
    Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4b1101a262af382e18d1f4d8a93c09c782a43842
Author: Eric Sandeen <sandeen@redhat.com>
Date:   Wed Oct 2 16:17:54 2019 -0500

    vfs: Fix EOVERFLOW testing in put_compat_statfs64
    
    commit cc3a7bfe62b947b423fcb2cfe89fcba92bf48fa3 upstream.
    
    Today, put_compat_statfs64() disallows nearly any field value over
    2^32 if f_bsize is only 32 bits, but that makes no sense.
    compat_statfs64 is there for the explicit purpose of providing 64-bit
    fields for f_files, f_ffree, etc.  And f_bsize is always only 32 bits.
    
    As a result, 32-bit userspace gets -EOVERFLOW for i.e.  large file
    counts even with -D_FILE_OFFSET_BITS=64 set.
    
    In reality, only f_bsize and f_frsize can legitimately overflow
    (fields like f_type and f_namelen should never be large), so test
    only those fields.
    
    This bug was discussed at length some time ago, and this is the proposal
    Al suggested at https://lkml.org/lkml/2018/8/6/640.  It seemed to get
    dropped amid the discussion of other related changes, but this
    part seems obviously correct on its own, so I've picked it up and
    sent it, for expediency.
    
    Fixes: 64d2ab32efe3 ("vfs: fix put_compat_statfs64() does not handle errors")
    Signed-off-by: Eric Sandeen <sandeen@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2680daf4c6051bfa697997fd7478260df5561c83
Author: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Date:   Wed Sep 4 15:17:37 2019 +0530

    perf stat: Reset previous counts on repeat with interval
    
    [ Upstream commit b63fd11cced17fcb8e133def29001b0f6aaa5e06 ]
    
    When using 'perf stat' with repeat and interval option, it shows wrong
    values for events.
    
    The wrong values will be shown for the first interval on the second and
    subsequent repetitions.
    
    Without the fix:
    
      # perf stat -r 3 -I 2000 -e faults -e sched:sched_switch -a sleep 5
    
         2.000282489                 53      faults
         2.000282489                513      sched:sched_switch
         4.005478208              3,721      faults
         4.005478208              2,666      sched:sched_switch
         5.025470933                395      faults
         5.025470933              1,307      sched:sched_switch
         2.009602825 1,84,46,74,40,73,70,95,47,520      faults              <------
         2.009602825 1,84,46,74,40,73,70,95,49,568      sched:sched_switch  <------
         4.019612206              4,730      faults
         4.019612206              2,746      sched:sched_switch
         5.039615484              3,953      faults
         5.039615484              1,496      sched:sched_switch
         2.000274620 1,84,46,74,40,73,70,95,47,520      faults              <------
         2.000274620 1,84,46,74,40,73,70,95,47,520      sched:sched_switch  <------
         4.000480342              4,282      faults
         4.000480342              2,303      sched:sched_switch
         5.000916811              1,322      faults
         5.000916811              1,064      sched:sched_switch
      #
    
    prev_raw_counts is allocated when using intervals. This is used when
    calculating the difference in the counts of events when using interval.
    
    The current counts are stored in prev_raw_counts to calculate the
    differences in the next iteration.
    
    On the first interval of the second and subsequent repetitions,
    prev_raw_counts would be the values stored in the last interval of the
    previous repetitions, while the current counts will only be for the
    first interval of the current repetition.
    
    Hence there is a possibility of events showing up as big number.
    
    Fix this by resetting prev_raw_counts whenever perf stat repeats the
    command.
    
    With the fix:
    
      # perf stat -r 3 -I 2000 -e faults -e sched:sched_switch -a sleep 5
    
         2.019349347              2,597      faults
         2.019349347              2,753      sched:sched_switch
         4.019577372              3,098      faults
         4.019577372              2,532      sched:sched_switch
         5.019415481              1,879      faults
         5.019415481              1,356      sched:sched_switch
         2.000178813              8,468      faults
         2.000178813              2,254      sched:sched_switch
         4.000404621              7,440      faults
         4.000404621              1,266      sched:sched_switch
         5.040196079              2,458      faults
         5.040196079                556      sched:sched_switch
         2.000191939              6,870      faults
         2.000191939              1,170      sched:sched_switch
         4.000414103                541      faults
         4.000414103                902      sched:sched_switch
         5.000809863                450      faults
         5.000809863                364      sched:sched_switch
      #
    
    Committer notes:
    
    This was broken since the cset introducing the --interval feature, i.e.
    --repeat + --interval wasn't tested at that point, add the Fixes tag so
    that automatic scripts can pick this up.
    
    Fixes: 13370a9b5bb8 ("perf stat: Add interval printing")
    Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
    Acked-by: Jiri Olsa <jolsa@kernel.org>
    Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Tested-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
    Cc: Stephane Eranian <eranian@google.com>
    Cc: stable@vger.kernel.org # v3.9+
    Link: http://lore.kernel.org/lkml/20190904094738.9558-2-srikar@linux.vnet.ibm.com
    [ Fixed up conflicts with libperf, i.e. some perf_{evsel,evlist} lost the 'perf' prefix ]
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e46cea226e1019af83598a52acfb4fd782b92f3b
Author: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Date:   Wed Sep 4 15:17:38 2019 +0530

    perf stat: Fix a segmentation fault when using repeat forever
    
    [ Upstream commit 443f2d5ba13d65ccfd879460f77941875159d154 ]
    
    Observe a segmentation fault when 'perf stat' is asked to repeat forever
    with the interval option.
    
    Without fix:
    
      # perf stat -r 0 -I 5000 -e cycles -a sleep 10
      #           time             counts unit events
           5.000211692  3,13,89,82,34,157      cycles
          10.000380119  1,53,98,52,22,294      cycles
          10.040467280       17,16,79,265      cycles
      Segmentation fault
    
    This problem was only observed when we use forever option aka -r 0 and
    works with limited repeats. Calling print_counter with ts being set to
    NULL, is not a correct option when interval is set. Hence avoid
    print_counter(NULL,..)  if interval is set.
    
    With fix:
    
      # perf stat -r 0 -I 5000 -e cycles -a sleep 10
       #           time             counts unit events
           5.019866622  3,15,14,43,08,697      cycles
          10.039865756  3,15,16,31,95,261      cycles
          10.059950628     1,26,05,47,158      cycles
           5.009902655  3,14,52,62,33,932      cycles
          10.019880228  3,14,52,22,89,154      cycles
          10.030543876       66,90,18,333      cycles
           5.009848281  3,14,51,98,25,437      cycles
          10.029854402  3,15,14,93,04,918      cycles
           5.009834177  3,14,51,95,92,316      cycles
    
    Committer notes:
    
    Did the 'git bisect' to find the cset introducing the problem to add the
    Fixes tag below, and at that time the problem reproduced as:
    
      (gdb) run stat -r0 -I500 sleep 1
      <SNIP>
      Program received signal SIGSEGV, Segmentation fault.
      print_interval (prefix=prefix@entry=0x7fffffffc8d0 "", ts=ts@entry=0x0) at builtin-stat.c:866
      866           sprintf(prefix, "%6lu.%09lu%s", ts->tv_sec, ts->tv_nsec, csv_sep);
      (gdb) bt
      #0  print_interval (prefix=prefix@entry=0x7fffffffc8d0 "", ts=ts@entry=0x0) at builtin-stat.c:866
      #1  0x000000000041860a in print_counters (ts=ts@entry=0x0, argc=argc@entry=2, argv=argv@entry=0x7fffffffd640) at builtin-stat.c:938
      #2  0x0000000000419a7f in cmd_stat (argc=2, argv=0x7fffffffd640, prefix=<optimized out>) at builtin-stat.c:1411
      #3  0x000000000045c65a in run_builtin (p=p@entry=0x6291b8 <commands+216>, argc=argc@entry=5, argv=argv@entry=0x7fffffffd640) at perf.c:370
      #4  0x000000000045c893 in handle_internal_command (argc=5, argv=0x7fffffffd640) at perf.c:429
      #5  0x000000000045c8f1 in run_argv (argcp=argcp@entry=0x7fffffffd4ac, argv=argv@entry=0x7fffffffd4a0) at perf.c:473
      #6  0x000000000045cac9 in main (argc=<optimized out>, argv=<optimized out>) at perf.c:588
      (gdb)
    
    Mostly the same as just before this patch:
    
      Program received signal SIGSEGV, Segmentation fault.
      0x00000000005874a7 in print_interval (config=0xa1f2a0 <stat_config>, evlist=0xbc9b90, prefix=0x7fffffffd1c0 "`", ts=0x0) at util/stat-display.c:964
      964           sprintf(prefix, "%6lu.%09lu%s", ts->tv_sec, ts->tv_nsec, config->csv_sep);
      (gdb) bt
      #0  0x00000000005874a7 in print_interval (config=0xa1f2a0 <stat_config>, evlist=0xbc9b90, prefix=0x7fffffffd1c0 "`", ts=0x0) at util/stat-display.c:964
      #1  0x0000000000588047 in perf_evlist__print_counters (evlist=0xbc9b90, config=0xa1f2a0 <stat_config>, _target=0xa1f0c0 <target>, ts=0x0, argc=2, argv=0x7fffffffd670)
          at util/stat-display.c:1172
      #2  0x000000000045390f in print_counters (ts=0x0, argc=2, argv=0x7fffffffd670) at builtin-stat.c:656
      #3  0x0000000000456bb5 in cmd_stat (argc=2, argv=0x7fffffffd670) at builtin-stat.c:1960
      #4  0x00000000004dd2e0 in run_builtin (p=0xa30e00 <commands+288>, argc=5, argv=0x7fffffffd670) at perf.c:310
      #5  0x00000000004dd54d in handle_internal_command (argc=5, argv=0x7fffffffd670) at perf.c:362
      #6  0x00000000004dd694 in run_argv (argcp=0x7fffffffd4cc, argv=0x7fffffffd4c0) at perf.c:406
      #7  0x00000000004dda11 in main (argc=5, argv=0x7fffffffd670) at perf.c:531
      (gdb)
    
    Fixes: d4f63a4741a8 ("perf stat: Introduce print_counters function")
    Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
    Acked-by: Jiri Olsa <jolsa@kernel.org>
    Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Tested-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
    Cc: stable@vger.kernel.org # v4.2+
    Link: http://lore.kernel.org/lkml/20190904094738.9558-3-srikar@linux.vnet.ibm.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit de04f6c61eff68ac6cde899ecd16aa44f86d5a33
Author: Jiri Olsa <jolsa@kernel.org>
Date:   Thu Sep 12 12:52:35 2019 +0200

    perf tools: Fix segfault in cpu_cache_level__read()
    
    [ Upstream commit 0216234c2eed1367a318daeb9f4a97d8217412a0 ]
    
    We release wrong pointer on error path in cpu_cache_level__read
    function, leading to segfault:
    
      (gdb) r record ls
      Starting program: /root/perf/tools/perf/perf record ls
      ...
      [ perf record: Woken up 1 times to write data ]
      double free or corruption (out)
    
      Thread 1 "perf" received signal SIGABRT, Aborted.
      0x00007ffff7463798 in raise () from /lib64/power9/libc.so.6
      (gdb) bt
      #0  0x00007ffff7463798 in raise () from /lib64/power9/libc.so.6
      #1  0x00007ffff7443bac in abort () from /lib64/power9/libc.so.6
      #2  0x00007ffff74af8bc in __libc_message () from /lib64/power9/libc.so.6
      #3  0x00007ffff74b92b8 in malloc_printerr () from /lib64/power9/libc.so.6
      #4  0x00007ffff74bb874 in _int_free () from /lib64/power9/libc.so.6
      #5  0x0000000010271260 in __zfree (ptr=0x7fffffffa0b0) at ../../lib/zalloc..
      #6  0x0000000010139340 in cpu_cache_level__read (cache=0x7fffffffa090, cac..
      #7  0x0000000010143c90 in build_caches (cntp=0x7fffffffa118, size=<optimiz..
      ...
    
    Releasing the proper pointer.
    
    Fixes: 720e98b5faf1 ("perf tools: Add perf data cache feature")
    Signed-off-by: Jiri Olsa <jolsa@kernel.org>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Michael Petlan <mpetlan@redhat.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: stable@vger.kernel.org: # v4.6+
    Link: http://lore.kernel.org/lkml/20190912105235.10689-1-jolsa@kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a990caf9f6e68e04f142734bacccb5ffb51da623
Author: Balasubramani Vivekanandan <balasubramani_vivekanandan@mentor.com>
Date:   Thu Sep 26 15:51:01 2019 +0200

    tick: broadcast-hrtimer: Fix a race in bc_set_next
    
    [ Upstream commit b9023b91dd020ad7e093baa5122b6968c48cc9e0 ]
    
    When a cpu requests broadcasting, before starting the tick broadcast
    hrtimer, bc_set_next() checks if the timer callback (bc_handler) is active
    using hrtimer_try_to_cancel(). But hrtimer_try_to_cancel() does not provide
    the required synchronization when the callback is active on other core.
    
    The callback could have already executed tick_handle_oneshot_broadcast()
    and could have also returned. But still there is a small time window where
    the hrtimer_try_to_cancel() returns -1. In that case bc_set_next() returns
    without doing anything, but the next_event of the tick broadcast clock
    device is already set to a timeout value.
    
    In the race condition diagram below, CPU #1 is running the timer callback
    and CPU #2 is entering idle state and so calls bc_set_next().
    
    In the worst case, the next_event will contain an expiry time, but the
    hrtimer will not be started which happens when the racing callback returns
    HRTIMER_NORESTART. The hrtimer might never recover if all further requests
    from the CPUs to subscribe to tick broadcast have timeout greater than the
    next_event of tick broadcast clock device. This leads to cascading of
    failures and finally noticed as rcu stall warnings
    
    Here is a depiction of the race condition
    
    CPU #1 (Running timer callback)                   CPU #2 (Enter idle
                                                      and subscribe to
                                                      tick broadcast)
    ---------------------                             ---------------------
    
    __run_hrtimer()                                   tick_broadcast_enter()
    
      bc_handler()                                      __tick_broadcast_oneshot_control()
    
        tick_handle_oneshot_broadcast()
    
          raw_spin_lock(&tick_broadcast_lock);
    
          dev->next_event = KTIME_MAX;                  //wait for tick_broadcast_lock
          //next_event for tick broadcast clock
          set to KTIME_MAX since no other cores
          subscribed to tick broadcasting
    
          raw_spin_unlock(&tick_broadcast_lock);
    
        if (dev->next_event == KTIME_MAX)
          return HRTIMER_NORESTART
        // callback function exits without
           restarting the hrtimer                      //tick_broadcast_lock acquired
                                                       raw_spin_lock(&tick_broadcast_lock);
    
                                                       tick_broadcast_set_event()
    
                                                         clockevents_program_event()
    
                                                           dev->next_event = expires;
    
                                                           bc_set_next()
    
                                                             hrtimer_try_to_cancel()
                                                             //returns -1 since the timer
                                                             callback is active. Exits without
                                                             restarting the timer
      cpu_base->running = NULL;
    
    The comment that hrtimer cannot be armed from within the callback is
    wrong. It is fine to start the hrtimer from within the callback. Also it is
    safe to start the hrtimer from the enter/exit idle code while the broadcast
    handler is active. The enter/exit idle code and the broadcast handler are
    synchronized using tick_broadcast_lock. So there is no need for the
    existing try to cancel logic. All this can be removed which will eliminate
    the race condition as well.
    
    Fixes: 5d1638acb9f6 ("tick: Introduce hrtimer based broadcast")
    Originally-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Balasubramani Vivekanandan <balasubramani_vivekanandan@mentor.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190926135101.12102-2-balasubramani_vivekanandan@mentor.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 429fb2a93645706e5fa0f69a9399fad1e8cc24c7
Author: Steven Rostedt (VMware) <rostedt@goodmis.org>
Date:   Wed Aug 28 15:05:28 2019 -0400

    tools lib traceevent: Do not free tep->cmdlines in add_new_comm() on failure
    
    [ Upstream commit e0d2615856b2046c2e8d5bfd6933f37f69703b0b ]
    
    If the re-allocation of tep->cmdlines succeeds, then the previous
    allocation of tep->cmdlines will be freed. If we later fail in
    add_new_comm(), we must not free cmdlines, and also should assign
    tep->cmdlines to the new allocation. Otherwise when freeing tep, the
    tep->cmdlines will be pointing to garbage.
    
    Fixes: a6d2a61ac653a ("tools lib traceevent: Remove some die() calls")
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: linux-trace-devel@vger.kernel.org
    Cc: stable@vger.kernel.org
    Link: http://lkml.kernel.org/r/20190828191819.970121417@goodmis.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 07a971f35f90e4b5823a7c2e7a83df85328f4ad3
Author: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Date:   Wed May 15 13:15:52 2019 +0530

    powerpc/pseries: Fix cpu_hotplug_lock acquisition in resize_hpt()
    
    [ Upstream commit c784be435d5dae28d3b03db31753dd7a18733f0c ]
    
    The calls to arch_add_memory()/arch_remove_memory() are always made
    with the read-side cpu_hotplug_lock acquired via memory_hotplug_begin().
    On pSeries, arch_add_memory()/arch_remove_memory() eventually call
    resize_hpt() which in turn calls stop_machine() which acquires the
    read-side cpu_hotplug_lock again, thereby resulting in the recursive
    acquisition of this lock.
    
    In the absence of CONFIG_PROVE_LOCKING, we hadn't observed a system
    lockup during a memory hotplug operation because cpus_read_lock() is a
    per-cpu rwsem read, which, in the fast-path (in the absence of the
    writer, which in our case is a CPU-hotplug operation) simply
    increments the read_count on the semaphore. Thus a recursive read in
    the fast-path doesn't cause any problems.
    
    However, we can hit this problem in practice if there is a concurrent
    CPU-Hotplug operation in progress which is waiting to acquire the
    write-side of the lock. This will cause the second recursive read to
    block until the writer finishes. While the writer is blocked since the
    first read holds the lock. Thus both the reader as well as the writers
    fail to make any progress thereby blocking both CPU-Hotplug as well as
    Memory Hotplug operations.
    
    Memory-Hotplug                          CPU-Hotplug
    CPU 0                                   CPU 1
    ------                                  ------
    
    1. down_read(cpu_hotplug_lock.rw_sem)
       [memory_hotplug_begin]
                                            2. down_write(cpu_hotplug_lock.rw_sem)
                                            [cpu_up/cpu_down]
    3. down_read(cpu_hotplug_lock.rw_sem)
       [stop_machine()]
    
    Lockdep complains as follows in these code-paths.
    
     swapper/0/1 is trying to acquire lock:
     (____ptrval____) (cpu_hotplug_lock.rw_sem){++++}, at: stop_machine+0x2c/0x60
    
    but task is already holding lock:
    (____ptrval____) (cpu_hotplug_lock.rw_sem){++++}, at: mem_hotplug_begin+0x20/0x50
    
     other info that might help us debug this:
      Possible unsafe locking scenario:
    
            CPU0
            ----
       lock(cpu_hotplug_lock.rw_sem);
       lock(cpu_hotplug_lock.rw_sem);
    
      *** DEADLOCK ***
    
      May be due to missing lock nesting notation
    
     3 locks held by swapper/0/1:
      #0: (____ptrval____) (&dev->mutex){....}, at: __driver_attach+0x12c/0x1b0
      #1: (____ptrval____) (cpu_hotplug_lock.rw_sem){++++}, at: mem_hotplug_begin+0x20/0x50
      #2: (____ptrval____) (mem_hotplug_lock.rw_sem){++++}, at: percpu_down_write+0x54/0x1a0
    
    stack backtrace:
     CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.0.0-rc5-58373-gbc99402235f3-dirty #166
     Call Trace:
       dump_stack+0xe8/0x164 (unreliable)
       __lock_acquire+0x1110/0x1c70
       lock_acquire+0x240/0x290
       cpus_read_lock+0x64/0xf0
       stop_machine+0x2c/0x60
       pseries_lpar_resize_hpt+0x19c/0x2c0
       resize_hpt_for_hotplug+0x70/0xd0
       arch_add_memory+0x58/0xfc
       devm_memremap_pages+0x5e8/0x8f0
       pmem_attach_disk+0x764/0x830
       nvdimm_bus_probe+0x118/0x240
       really_probe+0x230/0x4b0
       driver_probe_device+0x16c/0x1e0
       __driver_attach+0x148/0x1b0
       bus_for_each_dev+0x90/0x130
       driver_attach+0x34/0x50
       bus_add_driver+0x1a8/0x360
       driver_register+0x108/0x170
       __nd_driver_register+0xd0/0xf0
       nd_pmem_driver_init+0x34/0x48
       do_one_initcall+0x1e0/0x45c
       kernel_init_freeable+0x540/0x64c
       kernel_init+0x2c/0x160
       ret_from_kernel_thread+0x5c/0x68
    
    Fix this issue by
      1) Requiring all the calls to pseries_lpar_resize_hpt() be made
         with cpu_hotplug_lock held.
    
      2) In pseries_lpar_resize_hpt() invoke stop_machine_cpuslocked()
         as a consequence of 1)
    
      3) To satisfy 1), in hpt_order_set(), call mmu_hash_ops.resize_hpt()
         with cpu_hotplug_lock held.
    
    Fixes: dbcf929c0062 ("powerpc/pseries: Add support for hash table resizing")
    Cc: stable@vger.kernel.org # v4.11+
    Reported-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
    Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/1557906352-29048-1-git-send-email-ego@linux.vnet.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0b584bf573ae59021069c056c22d65d5721910cb
Author: Mike Christie <mchristi@redhat.com>
Date:   Sun Aug 4 14:10:06 2019 -0500

    nbd: fix max number of supported devs
    
    [ Upstream commit e9e006f5fcf2bab59149cb38a48a4817c1b538b4 ]
    
    This fixes a bug added in 4.10 with commit:
    
    commit 9561a7ade0c205bc2ee035a2ac880478dcc1a024
    Author: Josef Bacik <jbacik@fb.com>
    Date:   Tue Nov 22 14:04:40 2016 -0500
    
        nbd: add multi-connection support
    
    that limited the number of devices to 256. Before the patch we could
    create 1000s of devices, but the patch switched us from using our
    own thread to using a work queue which has a default limit of 256
    active works.
    
    The problem is that our recv_work function sits in a loop until
    disconnection but only handles IO for one connection. The work is
    started when the connection is started/restarted, but if we end up
    creating 257 or more connections, the queue_work call just queues
    connection257+'s recv_work and that waits for connection 1 - 256's
    recv_work to be disconnected and that work instance completing.
    
    Instead of reverting back to kthreads, this has us allocate a
    workqueue_struct per device, so we can block in the work.
    
    Cc: stable@vger.kernel.org
    Reviewed-by: Josef Bacik <josef@toxicpanda.com>
    Signed-off-by: Mike Christie <mchristi@redhat.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dd36e726ede475418c77ccaaffdd097caab4b4d1
Author: Dan Melnic <dmm@fb.com>
Date:   Mon Sep 18 13:08:51 2017 -0700

    block/ndb: add WQ_UNBOUND to the knbd-recv workqueue
    
    [ Upstream commit 2189c97cdbed630d5971ab22f05dc998774e354e ]
    
    Add WQ_UNBOUND to the knbd-recv workqueue so we're not bound
    to a single CPU that is selected at device creation time.
    
    Signed-off-by: Dan Melnic <dmm@fb.com>
    Reviewed-by: Josef Bacik <jbacik@fb.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 498ade7db232c10d3cbb2d63296d8ca3acec83cc
Author: Xiubo Li <xiubli@redhat.com>
Date:   Wed May 29 15:16:05 2019 -0500

    nbd: fix crash when the blksize is zero
    
    [ Upstream commit 553768d1169a48c0cd87c4eb4ab57534ee663415 ]
    
    This will allow the blksize to be set zero and then use 1024 as
    default.
    
    Reviewed-by: Josef Bacik <josef@toxicpanda.com>
    Signed-off-by: Xiubo Li <xiubli@redhat.com>
    [fix to use goto out instead of return in genl_connect]
    Signed-off-by: Mike Christie <mchristi@redhat.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3f57d4b477491227e1270544c2d41d660e4ec893
Author: Cédric Le Goater <clg@kaod.org>
Date:   Tue Aug 6 19:25:38 2019 +0200

    KVM: PPC: Book3S HV: XIVE: Free escalation interrupts before disabling the VP
    
    [ Upstream commit 237aed48c642328ff0ab19b63423634340224a06 ]
    
    When a vCPU is brought done, the XIVE VP (Virtual Processor) is first
    disabled and then the event notification queues are freed. When freeing
    the queues, we check for possible escalation interrupts and free them
    also.
    
    But when a XIVE VP is disabled, the underlying XIVE ENDs also are
    disabled in OPAL. When an END (Event Notification Descriptor) is
    disabled, its ESB pages (ESn and ESe) are disabled and loads return all
    1s. Which means that any access on the ESB page of the escalation
    interrupt will return invalid values.
    
    When an interrupt is freed, the shutdown handler computes a 'saved_p'
    field from the value returned by a load in xive_do_source_set_mask().
    This value is incorrect for escalation interrupts for the reason
    described above.
    
    This has no impact on Linux/KVM today because we don't make use of it
    but we will introduce in future changes a xive_get_irqchip_state()
    handler. This handler will use the 'saved_p' field to return the state
    of an interrupt and 'saved_p' being incorrect, softlockup will occur.
    
    Fix the vCPU cleanup sequence by first freeing the escalation interrupts
    if any, then disable the XIVE VP and last free the queues.
    
    Fixes: 90c73795afa2 ("KVM: PPC: Book3S HV: Add a new KVM device for the XIVE native exploitation mode")
    Fixes: 5af50993850a ("KVM: PPC: Book3S HV: Native usage of the XIVE interrupt controller")
    Cc: stable@vger.kernel.org # v4.12+
    Signed-off-by: Cédric Le Goater <clg@kaod.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20190806172538.5087-1-clg@kaod.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2046beea7627daf02d4ef3128f2f7188ef18f6c2
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date:   Thu Sep 26 14:36:48 2019 -0300

    perf unwind: Fix libunwind build failure on i386 systems
    
    [ Upstream commit 26acf400d2dcc72c7e713e1f55db47ad92010cc2 ]
    
    Naresh Kamboju reported, that on the i386 build pr_err()
    doesn't get defined properly due to header ordering:
    
      perf-in.o: In function `libunwind__x86_reg_id':
      tools/perf/util/libunwind/../../arch/x86/util/unwind-libunwind.c:109:
      undefined reference to `pr_err'
    
    Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: David Ahern <dsahern@gmail.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fd9c4df98547f7f778f72d80927ba09f09c9e1e7
Author: Valdis Kletnieks <valdis.kletnieks@vt.edu>
Date:   Wed Sep 25 16:45:59 2019 -0700

    kernel/elfcore.c: include proper prototypes
    
    [ Upstream commit 0f74914071ab7e7b78731ed62bf350e3a344e0a5 ]
    
    When building with W=1, gcc properly complains that there's no prototypes:
    
      CC      kernel/elfcore.o
    kernel/elfcore.c:7:17: warning: no previous prototype for 'elf_core_extra_phdrs' [-Wmissing-prototypes]
        7 | Elf_Half __weak elf_core_extra_phdrs(void)
          |                 ^~~~~~~~~~~~~~~~~~~~
    kernel/elfcore.c:12:12: warning: no previous prototype for 'elf_core_write_extra_phdrs' [-Wmissing-prototypes]
       12 | int __weak elf_core_write_extra_phdrs(struct coredump_params *cprm, loff_t offset)
          |            ^~~~~~~~~~~~~~~~~~~~~~~~~~
    kernel/elfcore.c:17:12: warning: no previous prototype for 'elf_core_write_extra_data' [-Wmissing-prototypes]
       17 | int __weak elf_core_write_extra_data(struct coredump_params *cprm)
          |            ^~~~~~~~~~~~~~~~~~~~~~~~~
    kernel/elfcore.c:22:15: warning: no previous prototype for 'elf_core_extra_data_size' [-Wmissing-prototypes]
       22 | size_t __weak elf_core_extra_data_size(void)
          |               ^~~~~~~~~~~~~~~~~~~~~~~~
    
    Provide the include file so gcc is happy, and we don't have potential code drift
    
    Link: http://lkml.kernel.org/r/29875.1565224705@turing-police
    Signed-off-by: Valdis Kletnieks <valdis.kletnieks@vt.edu>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 29edeea5cb65664034f8bfc388c29be725eedda9
Author: Thomas Richter <tmricht@linux.ibm.com>
Date:   Mon Sep 9 13:41:16 2019 +0200

    perf build: Add detection of java-11-openjdk-devel package
    
    [ Upstream commit 815c1560bf8fd522b8d93a1d727868b910c1cc24 ]
    
    With Java 11 there is no seperate JRE anymore.
    
    Details:
    
      https://coderanch.com/t/701603/java/JRE-JDK
    
    Therefore the detection of the JRE needs to be adapted.
    
    This change works for s390 and x86.  I have not tested other platforms.
    
    Committer testing:
    
    Continues to work with the OpenJDK 8:
    
      $ rm -f ~acme/lib64/libperf-jvmti.so
      $ rpm -qa | grep jdk-devel
      java-1.8.0-openjdk-devel-1.8.0.222.b10-0.fc30.x86_64
      $ git log --oneline -1
      a51937170f33 (HEAD -> perf/core) perf build: Add detection of java-11-openjdk-devel package
      $ rm -rf /tmp/build/perf ; mkdir -p /tmp/build/perf ; make -C tools/perf O=/tmp/build/perf install > /dev/null 2>1
      $ ls -la ~acme/lib64/libperf-jvmti.so
      -rwxr-xr-x. 1 acme acme 230744 Sep 24 16:46 /home/acme/lib64/libperf-jvmti.so
      $
    
    Suggested-by: Andreas Krebbel <krebbel@linux.ibm.com>
    Signed-off-by: Thomas Richter <tmricht@linux.ibm.com>
    Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
    Cc: Hendrik Brueckner <brueckner@linux.ibm.com>
    Cc: Vasily Gorbik <gor@linux.ibm.com>
    Link: http://lore.kernel.org/lkml/20190909114116.50469-4-tmricht@linux.ibm.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5d49886483c73838e7aba438f10ce8a7b1123eb7
Author: KeMeng Shi <shikemeng@huawei.com>
Date:   Mon Sep 16 06:53:28 2019 +0000

    sched/core: Fix migration to invalid CPU in __set_cpus_allowed_ptr()
    
    [ Upstream commit 714e501e16cd473538b609b3e351b2cc9f7f09ed ]
    
    An oops can be triggered in the scheduler when running qemu on arm64:
    
     Unable to handle kernel paging request at virtual address ffff000008effe40
     Internal error: Oops: 96000007 [#1] SMP
     Process migration/0 (pid: 12, stack limit = 0x00000000084e3736)
     pstate: 20000085 (nzCv daIf -PAN -UAO)
     pc : __ll_sc___cmpxchg_case_acq_4+0x4/0x20
     lr : move_queued_task.isra.21+0x124/0x298
     ...
     Call trace:
      __ll_sc___cmpxchg_case_acq_4+0x4/0x20
      __migrate_task+0xc8/0xe0
      migration_cpu_stop+0x170/0x180
      cpu_stopper_thread+0xec/0x178
      smpboot_thread_fn+0x1ac/0x1e8
      kthread+0x134/0x138
      ret_from_fork+0x10/0x18
    
    __set_cpus_allowed_ptr() will choose an active dest_cpu in affinity mask to
    migrage the process if process is not currently running on any one of the
    CPUs specified in affinity mask. __set_cpus_allowed_ptr() will choose an
    invalid dest_cpu (dest_cpu >= nr_cpu_ids, 1024 in my virtual machine) if
    CPUS in an affinity mask are deactived by cpu_down after cpumask_intersects
    check. cpumask_test_cpu() of dest_cpu afterwards is overflown and may pass if
    corresponding bit is coincidentally set. As a consequence, kernel will
    access an invalid rq address associate with the invalid CPU in
    migration_cpu_stop->__migrate_task->move_queued_task and the Oops occurs.
    
    The reproduce the crash:
    
      1) A process repeatedly binds itself to cpu0 and cpu1 in turn by calling
      sched_setaffinity.
    
      2) A shell script repeatedly does "echo 0 > /sys/devices/system/cpu/cpu1/online"
      and "echo 1 > /sys/devices/system/cpu/cpu1/online" in turn.
    
      3) Oops appears if the invalid CPU is set in memory after tested cpumask.
    
    Signed-off-by: KeMeng Shi <shikemeng@huawei.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Valentin Schneider <valentin.schneider@arm.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Link: https://lkml.kernel.org/r/1568616808-16808-1-git-send-email-shikemeng@huawei.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1c8c25209dd17a7c31e6efe4d8f603f1adccc310
Author: zhengbin <zhengbin13@huawei.com>
Date:   Wed Aug 14 15:59:09 2019 +0800

    fuse: fix memleak in cuse_channel_open
    
    [ Upstream commit 9ad09b1976c562061636ff1e01bfc3a57aebe56b ]
    
    If cuse_send_init fails, need to fuse_conn_put cc->fc.
    
    cuse_channel_open->fuse_conn_init->refcount_set(&fc->count, 1)
                     ->fuse_dev_alloc->fuse_conn_get
                     ->fuse_dev_free->fuse_conn_put
    
    Fixes: cc080e9e9be1 ("fuse: introduce per-instance fuse_dev structure")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: zhengbin <zhengbin13@huawei.com>
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 414755a4bf32adef628cc1f5d569f05c968de138
Author: Ido Schimmel <idosch@mellanox.com>
Date:   Wed Jul 10 13:14:52 2019 +0300

    thermal: Fix use-after-free when unregistering thermal zone device
    
    [ Upstream commit 1851799e1d2978f68eea5d9dff322e121dcf59c1 ]
    
    thermal_zone_device_unregister() cancels the delayed work that polls the
    thermal zone, but it does not wait for it to finish. This is racy with
    respect to the freeing of the thermal zone device, which can result in a
    use-after-free [1].
    
    Fix this by waiting for the delayed work to finish before freeing the
    thermal zone device. Note that thermal_zone_device_set_polling() is
    never invoked from an atomic context, so it is safe to call
    cancel_delayed_work_sync() that can block.
    
    [1]
    [  +0.002221] ==================================================================
    [  +0.000064] BUG: KASAN: use-after-free in __mutex_lock+0x1076/0x11c0
    [  +0.000016] Read of size 8 at addr ffff8881e48e0450 by task kworker/1:0/17
    
    [  +0.000023] CPU: 1 PID: 17 Comm: kworker/1:0 Not tainted 5.2.0-rc6-custom-02495-g8e73ca3be4af #1701
    [  +0.000010] Hardware name: Mellanox Technologies Ltd. MSN2100-CB2FO/SA001017, BIOS 5.6.5 06/07/2016
    [  +0.000016] Workqueue: events_freezable_power_ thermal_zone_device_check
    [  +0.000012] Call Trace:
    [  +0.000021]  dump_stack+0xa9/0x10e
    [  +0.000020]  print_address_description.cold.2+0x9/0x25e
    [  +0.000018]  __kasan_report.cold.3+0x78/0x9d
    [  +0.000016]  kasan_report+0xe/0x20
    [  +0.000016]  __mutex_lock+0x1076/0x11c0
    [  +0.000014]  step_wise_throttle+0x72/0x150
    [  +0.000018]  handle_thermal_trip+0x167/0x760
    [  +0.000019]  thermal_zone_device_update+0x19e/0x5f0
    [  +0.000019]  process_one_work+0x969/0x16f0
    [  +0.000017]  worker_thread+0x91/0xc40
    [  +0.000014]  kthread+0x33d/0x400
    [  +0.000015]  ret_from_fork+0x3a/0x50
    
    [  +0.000020] Allocated by task 1:
    [  +0.000015]  save_stack+0x19/0x80
    [  +0.000015]  __kasan_kmalloc.constprop.4+0xc1/0xd0
    [  +0.000014]  kmem_cache_alloc_trace+0x152/0x320
    [  +0.000015]  thermal_zone_device_register+0x1b4/0x13a0
    [  +0.000015]  mlxsw_thermal_init+0xc92/0x23d0
    [  +0.000014]  __mlxsw_core_bus_device_register+0x659/0x11b0
    [  +0.000013]  mlxsw_core_bus_device_register+0x3d/0x90
    [  +0.000013]  mlxsw_pci_probe+0x355/0x4b0
    [  +0.000014]  local_pci_probe+0xc3/0x150
    [  +0.000013]  pci_device_probe+0x280/0x410
    [  +0.000013]  really_probe+0x26a/0xbb0
    [  +0.000013]  driver_probe_device+0x208/0x2e0
    [  +0.000013]  device_driver_attach+0xfe/0x140
    [  +0.000013]  __driver_attach+0x110/0x310
    [  +0.000013]  bus_for_each_dev+0x14b/0x1d0
    [  +0.000013]  driver_register+0x1c0/0x400
    [  +0.000015]  mlxsw_sp_module_init+0x5d/0xd3
    [  +0.000014]  do_one_initcall+0x239/0x4dd
    [  +0.000013]  kernel_init_freeable+0x42b/0x4e8
    [  +0.000012]  kernel_init+0x11/0x18b
    [  +0.000013]  ret_from_fork+0x3a/0x50
    
    [  +0.000015] Freed by task 581:
    [  +0.000013]  save_stack+0x19/0x80
    [  +0.000014]  __kasan_slab_free+0x125/0x170
    [  +0.000013]  kfree+0xf3/0x310
    [  +0.000013]  thermal_release+0xc7/0xf0
    [  +0.000014]  device_release+0x77/0x200
    [  +0.000014]  kobject_put+0x1a8/0x4c0
    [  +0.000014]  device_unregister+0x38/0xc0
    [  +0.000014]  thermal_zone_device_unregister+0x54e/0x6a0
    [  +0.000014]  mlxsw_thermal_fini+0x184/0x35a
    [  +0.000014]  mlxsw_core_bus_device_unregister+0x10a/0x640
    [  +0.000013]  mlxsw_devlink_core_bus_device_reload+0x92/0x210
    [  +0.000015]  devlink_nl_cmd_reload+0x113/0x1f0
    [  +0.000014]  genl_family_rcv_msg+0x700/0xee0
    [  +0.000013]  genl_rcv_msg+0xca/0x170
    [  +0.000013]  netlink_rcv_skb+0x137/0x3a0
    [  +0.000012]  genl_rcv+0x29/0x40
    [  +0.000013]  netlink_unicast+0x49b/0x660
    [  +0.000013]  netlink_sendmsg+0x755/0xc90
    [  +0.000013]  __sys_sendto+0x3de/0x430
    [  +0.000013]  __x64_sys_sendto+0xe2/0x1b0
    [  +0.000013]  do_syscall_64+0xa4/0x4d0
    [  +0.000013]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
    
    [  +0.000017] The buggy address belongs to the object at ffff8881e48e0008
                   which belongs to the cache kmalloc-2k of size 2048
    [  +0.000012] The buggy address is located 1096 bytes inside of
                   2048-byte region [ffff8881e48e0008, ffff8881e48e0808)
    [  +0.000007] The buggy address belongs to the page:
    [  +0.000012] page:ffffea0007923800 refcount:1 mapcount:0 mapping:ffff88823680d0c0 index:0x0 compound_mapcount: 0
    [  +0.000020] flags: 0x200000000010200(slab|head)
    [  +0.000019] raw: 0200000000010200 ffffea0007682008 ffffea00076ab808 ffff88823680d0c0
    [  +0.000016] raw: 0000000000000000 00000000000d000d 00000001ffffffff 0000000000000000
    [  +0.000007] page dumped because: kasan: bad access detected
    
    [  +0.000012] Memory state around the buggy address:
    [  +0.000012]  ffff8881e48e0300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    [  +0.000012]  ffff8881e48e0380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    [  +0.000012] >ffff8881e48e0400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    [  +0.000008]                                                  ^
    [  +0.000012]  ffff8881e48e0480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    [  +0.000012]  ffff8881e48e0500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    [  +0.000007] ==================================================================
    
    Fixes: b1569e99c795 ("ACPI: move thermal trip handling to generic thermal layer")
    Reported-by: Jiri Pirko <jiri@mellanox.com>
    Signed-off-by: Ido Schimmel <idosch@mellanox.com>
    Acked-by: Jiri Pirko <jiri@mellanox.com>
    Signed-off-by: Zhang Rui <rui.zhang@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2289b3ab663d2baa2509d7f078472068d1d3704f
Author: Fabrice Gasnier <fabrice.gasnier@st.com>
Date:   Wed Sep 18 16:54:21 2019 +0200

    pwm: stm32-lp: Add check in case requested period cannot be achieved
    
    [ Upstream commit c91e3234c6035baf5a79763cb4fcd5d23ce75c2b ]
    
    LPTimer can use a 32KHz clock for counting. It depends on clock tree
    configuration. In such a case, PWM output frequency range is limited.
    Although unlikely, nothing prevents user from requesting a PWM frequency
    above counting clock (32KHz for instance):
    - This causes (prd - 1) = 0xffff to be written in ARR register later in
    the apply() routine.
    This results in badly configured PWM period (and also duty_cycle).
    Add a check to report an error is such a case.
    
    Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
    Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fecdf72f6774c0c9e7c62845dfc7c9a7ea6b4816
Author: Trond Myklebust <trondmy@gmail.com>
Date:   Fri Sep 20 07:23:40 2019 -0400

    pNFS: Ensure we do clear the return-on-close layout stateid on fatal errors
    
    [ Upstream commit 9c47b18cf722184f32148784189fca945a7d0561 ]
    
    IF the server rejected our layout return with a state error such as
    NFS4ERR_BAD_STATEID, or even a stale inode error, then we do want
    to clear out all the remaining layout segments and mark that stateid
    as invalid.
    
    Fixes: 1c5bd76d17cca ("pNFS: Enable layoutreturn operation for...")
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cc376abf178b7ddfb5f620a8a72d9fe048828203
Author: Trek <trek00@inbox.ru>
Date:   Sat Aug 31 21:25:36 2019 +0200

    drm/amdgpu: Check for valid number of registers to read
    
    [ Upstream commit 73d8e6c7b841d9bf298c8928f228fb433676635c ]
    
    Do not try to allocate any amount of memory requested by the user.
    Instead limit it to 128 registers. Actually the longest series of
    consecutive allowed registers are 48, mmGB_TILE_MODE0-31 and
    mmGB_MACROTILE_MODE0-15 (0x2644-0x2673).
    
    Bug: https://bugs.freedesktop.org/show_bug.cgi?id=111273
    Signed-off-by: Trek <trek00@inbox.ru>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7059ce31266f364e3091b6a71179d7ac68cdb851
Author: Florian Westphal <fw@strlen.de>
Date:   Thu Sep 19 16:56:44 2019 +0200

    netfilter: nf_tables: allow lookups in dynamic sets
    
    [ Upstream commit acab713177377d9e0889c46bac7ff0cfb9a90c4d ]
    
    This un-breaks lookups in sets that have the 'dynamic' flag set.
    Given this active example configuration:
    
    table filter {
      set set1 {
        type ipv4_addr
        size 64
        flags dynamic,timeout
        timeout 1m
      }
    
      chain input {
         type filter hook input priority 0; policy accept;
      }
    }
    
    ... this works:
    nft add rule ip filter input add @set1 { ip saddr }
    
    -> whenever rule is triggered, the source ip address is inserted
    into the set (if it did not exist).
    
    This won't work:
    nft add rule ip filter input ip saddr @set1 counter
    Error: Could not process rule: Operation not supported
    
    In other words, we can add entries to the set, but then can't make
    matching decision based on that set.
    
    That is just wrong -- all set backends support lookups (else they would
    not be very useful).
    The failure comes from an explicit rejection in nft_lookup.c.
    
    Looking at the history, it seems like NFT_SET_EVAL used to mean
    'set contains expressions' (aka. "is a meter"), for instance something like
    
     nft add rule ip filter input meter example { ip saddr limit rate 10/second }
     or
     nft add rule ip filter input meter example { ip saddr counter }
    
    The actual meaning of NFT_SET_EVAL however, is
    'set can be updated from the packet path'.
    
    'meters' and packet-path insertions into sets, such as
    'add @set { ip saddr }' use exactly the same kernel code (nft_dynset.c)
    and thus require a set backend that provides the ->update() function.
    
    The only set that provides this also is the only one that has the
    NFT_SET_EVAL feature flag.
    
    Removing the wrong check makes the above example work.
    While at it, also fix the flag check during set instantiation to
    allow supported combinations only.
    
    Fixes: 8aeff920dcc9b3f ("netfilter: nf_tables: add stateful object reference to set elements")
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 484bb2776320ef97d9f6835c1a3e3dd35cf3b095
Author: Ryan Chen <ryan_chen@aspeedtech.com>
Date:   Mon Aug 19 14:47:38 2019 +0930

    watchdog: aspeed: Add support for AST2600
    
    [ Upstream commit b3528b4874480818e38e4da019d655413c233e6a ]
    
    The ast2600 can be supported by the same code as the ast2500.
    
    Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
    Signed-off-by: Joel Stanley <joel@jms.id.au>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Link: https://lore.kernel.org/r/20190819051738.17370-3-joel@jms.id.au
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 160f160e89386836427ce49bfe12c82bcdfa4fdf
Author: Erqi Chen <chenerqi@gmail.com>
Date:   Wed Aug 28 21:22:45 2019 +0800

    ceph: reconnect connection if session hang in opening state
    
    [ Upstream commit 71a228bc8d65900179e37ac309e678f8c523f133 ]
    
    If client mds session is evicted in CEPH_MDS_SESSION_OPENING state,
    mds won't send session msg to client, and delayed_work skip
    CEPH_MDS_SESSION_OPENING state session, the session hang forever.
    
    Allow ceph_con_keepalive to reconnect a session in OPENING to avoid
    session hang. Also, ensure that we skip sessions in RESTARTING and
    REJECTED states since those states can't be resurrected by issuing
    a keepalive.
    
    Link: https://tracker.ceph.com/issues/41551
    Signed-off-by: Erqi Chen chenerqi@gmail.com
    Reviewed-by: "Yan, Zheng" <zyan@redhat.com>
    Signed-off-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dff953adf050bf9856de8e9f741a0055256a0794
Author: Luis Henriques <lhenriques@suse.com>
Date:   Tue Jul 23 16:50:20 2019 +0100

    ceph: fix directories inode i_blkbits initialization
    
    [ Upstream commit 750670341a24cb714e624e0fd7da30900ad93752 ]
    
    When filling an inode with info from the MDS, i_blkbits is being
    initialized using fl_stripe_unit, which contains the stripe unit in
    bytes.  Unfortunately, this doesn't make sense for directories as they
    have fl_stripe_unit set to '0'.  This means that i_blkbits will be set
    to 0xff, causing an UBSAN undefined behaviour in i_blocksize():
    
      UBSAN: Undefined behaviour in ./include/linux/fs.h:731:12
      shift exponent 255 is too large for 32-bit type 'int'
    
    Fix this by initializing i_blkbits to CEPH_BLOCK_SHIFT if fl_stripe_unit
    is zero.
    
    Signed-off-by: Luis Henriques <lhenriques@suse.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6c5207b5c4e42a2cbcbdfdbd0397a9a6883f8af2
Author: Igor Druzhinin <igor.druzhinin@citrix.com>
Date:   Thu Sep 12 19:31:51 2019 +0100

    xen/pci: reserve MCFG areas earlier
    
    [ Upstream commit a4098bc6eed5e31e0391bcc068e61804c98138df ]
    
    If MCFG area is not reserved in E820, Xen by default will defer its usage
    until Dom0 registers it explicitly after ACPI parser recognizes it as
    a reserved resource in DSDT. Having it reserved in E820 is not
    mandatory according to "PCI Firmware Specification, rev 3.2" (par. 4.1.2)
    and firmware is free to keep a hole in E820 in that place. Xen doesn't know
    what exactly is inside this hole since it lacks full ACPI view of the
    platform therefore it's potentially harmful to access MCFG region
    without additional checks as some machines are known to provide
    inconsistent information on the size of the region.
    
    Now xen_mcfg_late() runs after acpi_init() which is too late as some basic
    PCI enumeration starts exactly there as well. Trying to register a device
    prior to MCFG reservation causes multiple problems with PCIe extended
    capability initializations in Xen (e.g. SR-IOV VF BAR sizing). There are
    no convenient hooks for us to subscribe to so register MCFG areas earlier
    upon the first invocation of xen_add_device(). It should be safe to do once
    since all the boot time buses must have their MCFG areas in MCFG table
    already and we don't support PCI bus hot-plug.
    
    Signed-off-by: Igor Druzhinin <igor.druzhinin@citrix.com>
    Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 338aec3e9d33e4947bd4f6c29a5ee9259dc21ec7
Author: Chengguang Xu <cgxu519@zoho.com.cn>
Date:   Tue Aug 20 18:03:25 2019 +0800

    9p: avoid attaching writeback_fid on mmap with type PRIVATE
    
    [ Upstream commit c87a37ebd40b889178664c2c09cc187334146292 ]
    
    Currently on mmap cache policy, we always attach writeback_fid
    whether mmap type is SHARED or PRIVATE. However, in the use case
    of kata-container which combines 9p(Guest OS) with overlayfs(Host OS),
    this behavior will trigger overlayfs' copy-up when excute command
    inside container.
    
    Link: http://lkml.kernel.org/r/20190820100325.10313-1-cgxu519@zoho.com.cn
    Signed-off-by: Chengguang Xu <cgxu519@zoho.com.cn>
    Signed-off-by: Dominique Martinet <dominique.martinet@cea.fr>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 576a47e933cfd267953d54f99a647fb22fd014e8
Author: Jia-Ju Bai <baijiaju1990@gmail.com>
Date:   Fri Jul 26 15:48:53 2019 +0800

    fs: nfs: Fix possible null-pointer dereferences in encode_attrs()
    
    [ Upstream commit e2751463eaa6f9fec8fea80abbdc62dbc487b3c5 ]
    
    In encode_attrs(), there is an if statement on line 1145 to check
    whether label is NULL:
        if (label && (attrmask[2] & FATTR4_WORD2_SECURITY_LABEL))
    
    When label is NULL, it is used on lines 1178-1181:
        *p++ = cpu_to_be32(label->lfs);
        *p++ = cpu_to_be32(label->pi);
        *p++ = cpu_to_be32(label->len);
        p = xdr_encode_opaque_fixed(p, label->label, label->len);
    
    To fix these bugs, label is checked before being used.
    
    These bugs are found by a static analysis tool STCheck written by us.
    
    Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
    Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 27551dbe091615e6bb6ad17ea7117ef1beb8aa81
Author: Sascha Hauer <s.hauer@pengutronix.de>
Date:   Tue Jul 2 10:00:40 2019 +0200

    ima: always return negative code for error
    
    [ Upstream commit f5e1040196dbfe14c77ce3dfe3b7b08d2d961e88 ]
    
    integrity_kernel_read() returns the number of bytes read. If this is
    a short read then this positive value is returned from
    ima_calc_file_hash_atfm(). Currently this is only indirectly called from
    ima_calc_file_hash() and this function only tests for the return value
    being zero or nonzero and also doesn't forward the return value.
    Nevertheless there's no point in returning a positive value as an error,
    so translate a short read into -EINVAL.
    
    Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
    Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 77ed4fcf1d1a550713aa716007e715bf405f0112
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Mon Sep 23 13:51:16 2019 +0200

    cfg80211: initialize on-stack chandefs
    
    commit f43e5210c739fe76a4b0ed851559d6902f20ceb1 upstream.
    
    In a few places we don't properly initialize on-stack chandefs,
    resulting in EDMG data to be non-zero, which broke things.
    
    Additionally, in a few places we rely on the driver to init the
    data completely, but perhaps we shouldn't as non-EDMG drivers
    may not initialize the EDMG data, also initialize it there.
    
    Cc: stable@vger.kernel.org
    Fixes: 2a38075cd0be ("nl80211: Add support for EDMG channels")
    Reported-by: Dmitry Osipenko <digetx@gmail.com>
    Tested-by: Dmitry Osipenko <digetx@gmail.com>
    Link: https://lore.kernel.org/r/1569239475-I2dcce394ecf873376c386a78f31c2ec8b538fa25@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 481376cc2ccb32113a2492ed1f8de32b5c777b00
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Sep 19 14:12:34 2019 +0200

    ieee802154: atusb: fix use-after-free at disconnect
    
    commit 7fd25e6fc035f4b04b75bca6d7e8daa069603a76 upstream.
    
    The disconnect callback was accessing the hardware-descriptor private
    data after having having freed it.
    
    Fixes: 7490b008d123 ("ieee802154: add support for atusb transceiver")
    Cc: stable <stable@vger.kernel.org>     # 4.2
    Cc: Alexander Aring <alex.aring@gmail.com>
    Reported-by: syzbot+f4509a9138a1472e7e80@syzkaller.appspotmail.com
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit baba981bfea8e8e80a5d42c0b1233e029360746a
Author: Juergen Gross <jgross@suse.com>
Date:   Tue Oct 1 17:03:55 2019 +0200

    xen/xenbus: fix self-deadlock after killing user process
    
    commit a8fabb38525c51a094607768bac3ba46b3f4a9d5 upstream.
    
    In case a user process using xenbus has open transactions and is killed
    e.g. via ctrl-C the following cleanup of the allocated resources might
    result in a deadlock due to trying to end a transaction in the xenbus
    worker thread:
    
    [ 2551.474706] INFO: task xenbus:37 blocked for more than 120 seconds.
    [ 2551.492215]       Tainted: P           OE     5.0.0-29-generic #5
    [ 2551.510263] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
    [ 2551.528585] xenbus          D    0    37      2 0x80000080
    [ 2551.528590] Call Trace:
    [ 2551.528603]  __schedule+0x2c0/0x870
    [ 2551.528606]  ? _cond_resched+0x19/0x40
    [ 2551.528632]  schedule+0x2c/0x70
    [ 2551.528637]  xs_talkv+0x1ec/0x2b0
    [ 2551.528642]  ? wait_woken+0x80/0x80
    [ 2551.528645]  xs_single+0x53/0x80
    [ 2551.528648]  xenbus_transaction_end+0x3b/0x70
    [ 2551.528651]  xenbus_file_free+0x5a/0x160
    [ 2551.528654]  xenbus_dev_queue_reply+0xc4/0x220
    [ 2551.528657]  xenbus_thread+0x7de/0x880
    [ 2551.528660]  ? wait_woken+0x80/0x80
    [ 2551.528665]  kthread+0x121/0x140
    [ 2551.528667]  ? xb_read+0x1d0/0x1d0
    [ 2551.528670]  ? kthread_park+0x90/0x90
    [ 2551.528673]  ret_from_fork+0x35/0x40
    
    Fix this by doing the cleanup via a workqueue instead.
    
    Reported-by: James Dingwall <james@dingwall.me.uk>
    Fixes: fd8aa9095a95c ("xen: optimize xenbus driver for multiple concurrent xenstore accesses")
    Cc: <stable@vger.kernel.org> # 4.11
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 859cc323167050bcda865415c1716ec9518947f0
Author: Wanpeng Li <wanpengli@tencent.com>
Date:   Mon Sep 9 09:40:28 2019 +0800

    Revert "locking/pvqspinlock: Don't wait if vCPU is preempted"
    
    commit 89340d0935c9296c7b8222b6eab30e67cb57ab82 upstream.
    
    This patch reverts commit 75437bb304b20 (locking/pvqspinlock: Don't
    wait if vCPU is preempted).  A large performance regression was caused
    by this commit.  on over-subscription scenarios.
    
    The test was run on a Xeon Skylake box, 2 sockets, 40 cores, 80 threads,
    with three VMs of 80 vCPUs each.  The score of ebizzy -M is reduced from
    13000-14000 records/s to 1700-1800 records/s:
    
              Host                Guest                score
    
    vanilla w/o kvm optimizations     upstream    1700-1800 records/s
    vanilla w/o kvm optimizations     revert      13000-14000 records/s
    vanilla w/ kvm optimizations      upstream    4500-5000 records/s
    vanilla w/ kvm optimizations      revert      14000-15500 records/s
    
    Exit from aggressive wait-early mechanism can result in premature yield
    and extra scheduling latency.
    
    Actually, only 6% of wait_early events are caused by vcpu_is_preempted()
    being true.  However, when one vCPU voluntarily releases its vCPU, all
    the subsequently waiters in the queue will do the same and the cascading
    effect leads to bad performance.
    
    kvm optimizations:
    [1] commit d73eb57b80b (KVM: Boost vCPUs that are delivering interrupts)
    [2] commit 266e85a5ec9 (KVM: X86: Boost queue head vCPU to mitigate lock waiter preemption)
    
    Tested-by: loobinliu@tencent.com
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Waiman Long <longman@redhat.com>
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Cc: Radim Krčmář <rkrcmar@redhat.com>
    Cc: loobinliu@tencent.com
    Cc: stable@vger.kernel.org
    Fixes: 75437bb304b20 (locking/pvqspinlock: Don't wait if vCPU is preempted)
    Signed-off-by: Wanpeng Li <wanpengli@tencent.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6475db6c42a408c5c0a52dbdb8494310c48ed2d3
Author: Russell King <rmk+kernel@armlinux.org.uk>
Date:   Sun Sep 22 11:26:58 2019 +0100

    mmc: sdhci-of-esdhc: set DMA snooping based on DMA coherence
    
    commit 121bd08b029e03404c451bb237729cdff76eafed upstream.
    
    We must not unconditionally set the DMA snoop bit; if the DMA API is
    assuming that the device is not DMA coherent, and the device snoops the
    CPU caches, the device can see stale cache lines brought in by
    speculative prefetch.
    
    This leads to the device seeing stale data, potentially resulting in
    corrupted data transfers.  Commonly, this results in a descriptor fetch
    error such as:
    
    mmc0: ADMA error
    mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
    mmc0: sdhci: Sys addr:  0x00000000 | Version:  0x00002202
    mmc0: sdhci: Blk size:  0x00000008 | Blk cnt:  0x00000001
    mmc0: sdhci: Argument:  0x00000000 | Trn mode: 0x00000013
    mmc0: sdhci: Present:   0x01f50008 | Host ctl: 0x00000038
    mmc0: sdhci: Power:     0x00000003 | Blk gap:  0x00000000
    mmc0: sdhci: Wake-up:   0x00000000 | Clock:    0x000040d8
    mmc0: sdhci: Timeout:   0x00000003 | Int stat: 0x00000001
    mmc0: sdhci: Int enab:  0x037f108f | Sig enab: 0x037f108b
    mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00002202
    mmc0: sdhci: Caps:      0x35fa0000 | Caps_1:   0x0000af00
    mmc0: sdhci: Cmd:       0x0000333a | Max curr: 0x00000000
    mmc0: sdhci: Resp[0]:   0x00000920 | Resp[1]:  0x001d8a33
    mmc0: sdhci: Resp[2]:   0x325b5900 | Resp[3]:  0x3f400e00
    mmc0: sdhci: Host ctl2: 0x00000000
    mmc0: sdhci: ADMA Err:  0x00000009 | ADMA Ptr: 0x000000236d43820c
    mmc0: sdhci: ============================================
    mmc0: error -5 whilst initialising SD card
    
    but can lead to other errors, and potentially direct the SDHCI
    controller to read/write data to other memory locations (e.g. if a valid
    descriptor is visible to the device in a stale cache line.)
    
    Fix this by ensuring that the DMA snoop bit corresponds with the
    behaviour of the DMA API.  Since the driver currently only supports DT,
    use of_dma_is_coherent().  Note that device_get_dma_attr() can not be
    used as that risks re-introducing this bug if/when the driver is
    converted to ACPI.
    
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
    Acked-by: Adrian Hunter <adrian.hunter@intel.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7e7df7f5cbc254481375a5fdf0db21458e99a962
Author: Russell King <rmk+kernel@armlinux.org.uk>
Date:   Sun Sep 22 11:26:53 2019 +0100

    mmc: sdhci: improve ADMA error reporting
    
    commit d1c536e3177390da43d99f20143b810c35433d1f upstream.
    
    ADMA errors are potentially data corrupting events; although we print
    the register state, we do not usefully print the ADMA descriptors.
    Worse than that, we print them by referencing their virtual address
    which is meaningless when the register state gives us the DMA address
    of the failing descriptor.
    
    Print the ADMA descriptors giving their DMA addresses rather than their
    virtual addresses, and print them using SDHCI_DUMP() rather than DBG().
    
    We also do not show the correct value of the interrupt status register;
    the register dump shows the current value, after we have cleared the
    pending interrupts we are going to service.  What is more useful is to
    print the interrupts that _were_ pending at the time the ADMA error was
    encountered.  Fix that too.
    
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
    Acked-by: Adrian Hunter <adrian.hunter@intel.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2ed8cd8998cd93ac5088b6253f3986ad89aaf36f
Author: Tomi Valkeinen <tomi.valkeinen@ti.com>
Date:   Wed Oct 2 15:25:42 2019 +0300

    drm/omap: fix max fclk divider for omap36xx
    
    commit e2c4ed148cf3ec8669a1d90dc66966028e5fad70 upstream.
    
    The OMAP36xx and AM/DM37x TRMs say that the maximum divider for DSS fclk
    (in CM_CLKSEL_DSS) is 32. Experimentation shows that this is not
    correct, and using divider of 32 breaks DSS with a flood or underflows
    and sync losts. Dividers up to 31 seem to work fine.
    
    There is another patch to the DT files to limit the divider correctly,
    but as the DSS driver also needs to know the maximum divider to be able
    to iteratively find good rates, we also need to do the fix in the DSS
    driver.
    
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
    Cc: Adam Ford <aford173@gmail.com>
    Cc: stable@vger.kernel.org
    Link: https://patchwork.freedesktop.org/patch/msgid/20191002122542.8449-1-tomi.valkeinen@ti.com
    Tested-by: Adam Ford <aford173@gmail.com>
    Reviewed-by: Jyri Sarha <jsarha@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2890b718f4a8bab2b4e4ef773cecab2b99ddd5d6
Author: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Date:   Mon Aug 12 15:13:56 2019 +0200

    watchdog: imx2_wdt: fix min() calculation in imx2_wdt_set_timeout
    
    commit 144783a80cd2cbc45c6ce17db649140b65f203dd upstream.
    
    Converting from ms to s requires dividing by 1000, not multiplying. So
    this is currently taking the smaller of new_timeout and 1.28e8,
    i.e. effectively new_timeout.
    
    The driver knows what it set max_hw_heartbeat_ms to, so use that
    value instead of doing a division at run-time.
    
    FWIW, this can easily be tested by booting into a busybox shell and
    doing "watchdog -t 5 -T 130 /dev/watchdog" - without this patch, the
    watchdog fires after 130&127 == 2 seconds.
    
    Fixes: b07e228eee69 "watchdog: imx2_wdt: Fix set_timeout for big timeout values"
    Cc: stable@vger.kernel.org # 5.2 plus anything the above got backported to
    Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Link: https://lore.kernel.org/r/20190812131356.23039-1-linux@rasmusvillemoes.dk
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8f25db0a2e89f529beccdd7c13dc70d6857e5dbe
Author: Li RongQing <lirongqing@baidu.com>
Date:   Thu Sep 19 20:04:47 2019 +0800

    timer: Read jiffies once when forwarding base clk
    
    commit e430d802d6a3aaf61bd3ed03d9404888a29b9bf9 upstream.
    
    The timer delayed for more than 3 seconds warning was triggered during
    testing.
    
      Workqueue: events_unbound sched_tick_remote
      RIP: 0010:sched_tick_remote+0xee/0x100
      ...
      Call Trace:
       process_one_work+0x18c/0x3a0
       worker_thread+0x30/0x380
       kthread+0x113/0x130
       ret_from_fork+0x22/0x40
    
    The reason is that the code in collect_expired_timers() uses jiffies
    unprotected:
    
        if (next_event > jiffies)
            base->clk = jiffies;
    
    As the compiler is allowed to reload the value base->clk can advance
    between the check and the store and in the worst case advance farther than
    next event. That causes the timer expiry to be delayed until the wheel
    pointer wraps around.
    
    Convert the code to use READ_ONCE()
    
    Fixes: 236968383cf5 ("timers: Optimize collect_expired_timers() for NOHZ")
    Signed-off-by: Li RongQing <lirongqing@baidu.com>
    Signed-off-by: Liang ZhiCheng <liangzhicheng@baidu.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/1568894687-14499-1-git-send-email-lirongqing@baidu.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a93e0bcdbda6ddcbbb8a103ab743f0f51451bcf4
Author: Kees Cook <keescook@chromium.org>
Date:   Tue Sep 17 11:00:25 2019 -0700

    usercopy: Avoid HIGHMEM pfn warning
    
    commit 314eed30ede02fa925990f535652254b5bad6b65 upstream.
    
    When running on a system with >512MB RAM with a 32-bit kernel built with:
    
            CONFIG_DEBUG_VIRTUAL=y
            CONFIG_HIGHMEM=y
            CONFIG_HARDENED_USERCOPY=y
    
    all execve()s will fail due to argv copying into kmap()ed pages, and on
    usercopy checking the calls ultimately of virt_to_page() will be looking
    for "bad" kmap (highmem) pointers due to CONFIG_DEBUG_VIRTUAL=y:
    
     ------------[ cut here ]------------
     kernel BUG at ../arch/x86/mm/physaddr.c:83!
     invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
     CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.3.0-rc8 #6
     Hardware name: Dell Inc. Inspiron 1318/0C236D, BIOS A04 01/15/2009
     EIP: __phys_addr+0xaf/0x100
     ...
     Call Trace:
      __check_object_size+0xaf/0x3c0
      ? __might_sleep+0x80/0xa0
      copy_strings+0x1c2/0x370
      copy_strings_kernel+0x2b/0x40
      __do_execve_file+0x4ca/0x810
      ? kmem_cache_alloc+0x1c7/0x370
      do_execve+0x1b/0x20
      ...
    
    The check is from arch/x86/mm/physaddr.c:
    
            VIRTUAL_BUG_ON((phys_addr >> PAGE_SHIFT) > max_low_pfn);
    
    Due to the kmap() in fs/exec.c:
    
                    kaddr = kmap(kmapped_page);
            ...
            if (copy_from_user(kaddr+offset, str, bytes_to_copy)) ...
    
    Now we can fetch the correct page to avoid the pfn check. In both cases,
    hardened usercopy will need to walk the page-span checker (if enabled)
    to do sanity checking.
    
    Reported-by: Randy Dunlap <rdunlap@infradead.org>
    Tested-by: Randy Dunlap <rdunlap@infradead.org>
    Fixes: f5509cc18daa ("mm: Hardened usercopy")
    Cc: Matthew Wilcox <willy@infradead.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org>
    Link: https://lore.kernel.org/r/201909171056.7F2FFD17@keescook
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e5f55c5097d2b6dffa8f20b7901eccbaa4470811
Author: Horia Geantă <horia.geanta@nxp.com>
Date:   Tue Jul 30 08:48:33 2019 +0300

    crypto: caam - fix concurrency issue in givencrypt descriptor
    
    commit 48f89d2a2920166c35b1c0b69917dbb0390ebec7 upstream.
    
    IV transfer from ofifo to class2 (set up at [29][30]) is not guaranteed
    to be scheduled before the data transfer from ofifo to external memory
    (set up at [38]:
    
    [29] 10FA0004           ld: ind-nfifo (len=4) imm
    [30] 81F00010               <nfifo_entry: ofifo->class2 type=msg len=16>
    [31] 14820004           ld: ccb2-datasz len=4 offs=0 imm
    [32] 00000010               data:0x00000010
    [33] 8210010D    operation: cls1-op aes cbc init-final enc
    [34] A8080B04         math: (seqin + math0)->vseqout len=4
    [35] 28000010    seqfifold: skip len=16
    [36] A8080A04         math: (seqin + math0)->vseqin len=4
    [37] 2F1E0000    seqfifold: both msg1->2-last2-last1 len=vseqinsz
    [38] 69300000   seqfifostr: msg len=vseqoutsz
    [39] 5C20000C      seqstr: ccb2 ctx len=12 offs=0
    
    If ofifo -> external memory transfer happens first, DECO will hang
    (issuing a Watchdog Timeout error, if WDOG is enabled) waiting for
    data availability in ofifo for the ofifo -> c2 ififo transfer.
    
    Make sure IV transfer happens first by waiting for all CAAM internal
    transfers to end before starting payload transfer.
    
    New descriptor with jump command inserted at [37]:
    
    [..]
    [36] A8080A04         math: (seqin + math0)->vseqin len=4
    [37] A1000401         jump: jsl1 all-match[!nfifopend] offset=[01] local->[38]
    [38] 2F1E0000    seqfifold: both msg1->2-last2-last1 len=vseqinsz
    [39] 69300000   seqfifostr: msg len=vseqoutsz
    [40] 5C20000C      seqstr: ccb2 ctx len=12 offs=0
    
    [Note: the issue is present in the descriptor from the very beginning
    (cf. Fixes tag). However I've marked it v4.19+ since it's the oldest
    maintained kernel that the patch applies clean against.]
    
    Cc: <stable@vger.kernel.org> # v4.19+
    Fixes: 1acebad3d8db8 ("crypto: caam - faster aead implementation")
    Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 72463f8295afca1933b027049dec96166f246791
Author: Wei Yongjun <weiyongjun1@huawei.com>
Date:   Wed Sep 4 14:18:09 2019 +0000

    crypto: cavium/zip - Add missing single_release()
    
    commit c552ffb5c93d9d65aaf34f5f001c4e7e8484ced1 upstream.
    
    When using single_open() for opening, single_release() should be
    used instead of seq_release(), otherwise there is a memory leak.
    
    Fixes: 09ae5d37e093 ("crypto: zip - Add Compression/Decompression statistics")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 61a2c2c94422b4d1a07405d1df9408fa3af2b4c6
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Fri Sep 6 13:13:06 2019 +1000

    crypto: skcipher - Unmap pages after an external error
    
    commit 0ba3c026e685573bd3534c17e27da7c505ac99c4 upstream.
    
    skcipher_walk_done may be called with an error by internal or
    external callers.  For those internal callers we shouldn't unmap
    pages but for external callers we must unmap any pages that are
    in use.
    
    This patch distinguishes between the two cases by checking whether
    walk->nbytes is zero or not.  For internal callers, we now set
    walk->nbytes to zero prior to the call.  For external callers,
    walk->nbytes has always been non-zero (as zero is used to indicate
    the termination of a walk).
    
    Reported-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Fixes: 5cde0af2a982 ("[CRYPTO] cipher: Added block cipher type")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 79fa159824e9dcdfe39f6a2a4b20265b00a942c9
Author: Alexander Sverdlin <alexander.sverdlin@nokia.com>
Date:   Tue Jul 23 07:24:01 2019 +0000

    crypto: qat - Silence smp_processor_id() warning
    
    commit 1b82feb6c5e1996513d0fb0bbb475417088b4954 upstream.
    
    It seems that smp_processor_id() is only used for a best-effort
    load-balancing, refer to qat_crypto_get_instance_node(). It's not feasible
    to disable preemption for the duration of the crypto requests. Therefore,
    just silence the warning. This commit is similar to e7a9b05ca4
    ("crypto: cavium - Fix smp_processor_id() warnings").
    
    Silences the following splat:
    BUG: using smp_processor_id() in preemptible [00000000] code: cryptomgr_test/2904
    caller is qat_alg_ablkcipher_setkey+0x300/0x4a0 [intel_qat]
    CPU: 1 PID: 2904 Comm: cryptomgr_test Tainted: P           O    4.14.69 #1
    ...
    Call Trace:
     dump_stack+0x5f/0x86
     check_preemption_disabled+0xd3/0xe0
     qat_alg_ablkcipher_setkey+0x300/0x4a0 [intel_qat]
     skcipher_setkey_ablkcipher+0x2b/0x40
     __test_skcipher+0x1f3/0xb20
     ? cpumask_next_and+0x26/0x40
     ? find_busiest_group+0x10e/0x9d0
     ? preempt_count_add+0x49/0xa0
     ? try_module_get+0x61/0xf0
     ? crypto_mod_get+0x15/0x30
     ? __kmalloc+0x1df/0x1f0
     ? __crypto_alloc_tfm+0x116/0x180
     ? crypto_skcipher_init_tfm+0xa6/0x180
     ? crypto_create_tfm+0x4b/0xf0
     test_skcipher+0x21/0xa0
     alg_test_skcipher+0x3f/0xa0
     alg_test.part.6+0x126/0x2a0
     ? finish_task_switch+0x21b/0x260
     ? __schedule+0x1e9/0x800
     ? __wake_up_common+0x8d/0x140
     cryptomgr_test+0x40/0x50
     kthread+0xff/0x130
     ? cryptomgr_notify+0x540/0x540
     ? kthread_create_on_node+0x70/0x70
     ret_from_fork+0x24/0x50
    
    Fixes: ed8ccaef52 ("crypto: qat - Add support for SRIOV")
    Cc: stable@vger.kernel.org
    Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nokia.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3ea7e47f94ccd112122cc8af5da9ebc20be7ed1a
Author: Steven Rostedt (VMware) <rostedt@goodmis.org>
Date:   Mon Aug 5 13:01:50 2019 -0400

    tools lib traceevent: Fix "robust" test of do_generate_dynamic_list_file
    
    commit 82a2f88458d70704be843961e10b5cef9a6e95d3 upstream.
    
    The tools/lib/traceevent/Makefile had a test added to it to detect a failure
    of the "nm" when making the dynamic list file (whatever that is). The
    problem is that the test sorts the values "U W w" and some versions of sort
    will place "w" ahead of "W" (even though it has a higher ASCII value, and
    break the test.
    
    Add 'tr "w" "W"' to merge the two and not worry about the ordering.
    
    Reported-by: Tzvetomir Stoyanov <tstoyanov@vmware.com>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: David Carrillo-Cisneros <davidcc@google.com>
    Cc: He Kuang <hekuang@huawei.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Michal rarek <mmarek@suse.com>
    Cc: Paul Turner <pjt@google.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Stephane Eranian <eranian@google.com>
    Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Cc: Wang Nan <wangnan0@huawei.com>
    Cc: stable@vger.kernel.org
    Fixes: 6467753d61399 ("tools lib traceevent: Robustify do_generate_dynamic_list_file")
    Link: http://lkml.kernel.org/r/20190805130150.25acfeb1@gandalf.local.home
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 30724d3436ddb57d378289b6a23b6fe2a89bd24e
Author: Marc Kleine-Budde <mkl@pengutronix.de>
Date:   Tue Aug 13 16:01:02 2019 +0200

    can: mcp251x: mcp251x_hw_reset(): allow more time after a reset
    
    commit d84ea2123f8d27144e3f4d58cd88c9c6ddc799de upstream.
    
    Some boards take longer than 5ms to power up after a reset, so allow
    some retries attempts before giving up.
    
    Fixes: ff06d611a31c ("can: mcp251x: Improve mcp251x_hw_reset()")
    Cc: linux-stable <stable@vger.kernel.org>
    Tested-by: Sean Nyekjaer <sean@geanix.com>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b79a816ba23a1ff7d240eb8ad76eb1cc593e3cf7
Author: Andrew Donnellan <ajd@linux.ibm.com>
Date:   Fri May 3 17:52:53 2019 +1000

    powerpc/powernv: Restrict OPAL symbol map to only be readable by root
    
    commit e7de4f7b64c23e503a8c42af98d56f2a7462bd6d upstream.
    
    Currently the OPAL symbol map is globally readable, which seems bad as
    it contains physical addresses.
    
    Restrict it to root.
    
    Fixes: c8742f85125d ("powerpc/powernv: Expose OPAL firmware symbol map")
    Cc: stable@vger.kernel.org # v3.19+
    Suggested-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20190503075253.22798-1-ajd@linux.ibm.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7fda3e7f0a5066667a0c362c6c990bc074ed373a
Author: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
Date:   Fri Jul 19 10:05:30 2019 +0000

    ASoC: Define a set of DAPM pre/post-up events
    
    commit cfc8f568aada98f9608a0a62511ca18d647613e2 upstream.
    
    Prepare to use SND_SOC_DAPM_PRE_POST_PMU definition to
    reduce coming code size and make it more readable.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
    Reviewed-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
    Reviewed-by: Igor Opaniuk <igor.opaniuk@toradex.com>
    Reviewed-by: Fabio Estevam <festevam@gmail.com>
    Link: https://lore.kernel.org/r/20190719100524.23300-2-oleksandr.suvorov@toradex.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 938284992abe090fa170e9947b703ccd6f57c864
Author: Dmitry Osipenko <digetx@gmail.com>
Date:   Thu May 2 02:38:00 2019 +0300

    PM / devfreq: tegra: Fix kHz to Hz conversion
    
    commit 62bacb06b9f08965c4ef10e17875450490c948c0 upstream.
    
    The kHz to Hz is incorrectly converted in a few places in the code,
    this results in a wrong frequency being calculated because devfreq core
    uses OPP frequencies that are given in Hz to clamp the rate, while
    tegra-devfreq gives to the core value in kHz and then it also expects to
    receive value in kHz from the core. In a result memory freq is always set
    to a value which is close to ULONG_MAX because of the bug. Hence the EMC
    frequency is always capped to the maximum and the driver doesn't do
    anything useful. This patch was tested on Tegra30 and Tegra124 SoC's, EMC
    frequency scaling works properly now.
    
    Cc: <stable@vger.kernel.org> # 4.14+
    Tested-by: Steev Klimaszewski <steev@kali.org>
    Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
    Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
    Acked-by: Thierry Reding <treding@nvidia.com>
    Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5ff375e9dcb5a9ec75f460aaa61fd605a731dda9
Author: Jack Wang <jinpu.wang@cloud.ionos.com>
Date:   Mon Oct 7 14:36:53 2019 +0200

    KVM: nVMX: handle page fault in vmread fix
    
    During backport f7eea636c3d5 ("KVM: nVMX: handle page fault in vmread"),
    there was a mistake the exception reference should be passed to function
    kvm_write_guest_virt_system, instead of NULL, other wise, we will get
    NULL pointer deref, eg
    
    kvm-unit-test triggered a NULL pointer deref below:
    [  948.518437] kvm [24114]: vcpu0, guest rIP: 0x407ef9 kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x3, nop
    [  949.106464] BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
    [  949.106707] PGD 0 P4D 0
    [  949.106872] Oops: 0002 [#1] SMP
    [  949.107038] CPU: 2 PID: 24126 Comm: qemu-2.7 Not tainted 4.19.77-pserver #4.19.77-1+feature+daily+update+20191005.1625+a4168bb~deb9
    [  949.107283] Hardware name: Dell Inc. Precision Tower 3620/09WH54, BIOS 2.7.3 01/31/2018
    [  949.107549] RIP: 0010:kvm_write_guest_virt_system+0x12/0x40 [kvm]
    [  949.107719] Code: c0 5d 41 5c 41 5d 41 5e 83 f8 03 41 0f 94 c0 41 c1 e0 02 e9 b0 ed ff ff 0f 1f 44 00 00 48 89 f0 c6 87 59 56 00 00 01 48 89 d6 <49> c7 00 00 00 00 00 89 ca 49 c7 40 08 00 00 00 00 49 c7 40 10 00
    [  949.108044] RSP: 0018:ffffb31b0a953cb0 EFLAGS: 00010202
    [  949.108216] RAX: 000000000046b4d8 RBX: ffff9e9f415b0000 RCX: 0000000000000008
    [  949.108389] RDX: ffffb31b0a953cc0 RSI: ffffb31b0a953cc0 RDI: ffff9e9f415b0000
    [  949.108562] RBP: 00000000d2e14928 R08: 0000000000000000 R09: 0000000000000000
    [  949.108733] R10: 0000000000000000 R11: 0000000000000000 R12: ffffffffffffffc8
    [  949.108907] R13: 0000000000000002 R14: ffff9e9f4f26f2e8 R15: 0000000000000000
    [  949.109079] FS:  00007eff8694c700(0000) GS:ffff9e9f51a80000(0000) knlGS:0000000031415928
    [  949.109318] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  949.109495] CR2: 0000000000000000 CR3: 00000003be53b002 CR4: 00000000003626e0
    [  949.109671] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [  949.109845] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [  949.110017] Call Trace:
    [  949.110186]  handle_vmread+0x22b/0x2f0 [kvm_intel]
    [  949.110356]  ? vmexit_fill_RSB+0xc/0x30 [kvm_intel]
    [  949.110549]  kvm_arch_vcpu_ioctl_run+0xa98/0x1b30 [kvm]
    [  949.110725]  ? kvm_vcpu_ioctl+0x388/0x5d0 [kvm]
    [  949.110901]  kvm_vcpu_ioctl+0x388/0x5d0 [kvm]
    [  949.111072]  do_vfs_ioctl+0xa2/0x620
    
    Signed-off-by: Jack Wang <jinpu.wang@cloud.ionos.com>
    Acked-by: Paolo Bonzini <pbonzini@redhat.com>

commit d4feec4004b868892e064d7ae9dd80f58d309915
Author: Paul Mackerras <paulus@ozlabs.org>
Date:   Tue Aug 27 11:35:40 2019 +1000

    KVM: PPC: Book3S HV: Don't lose pending doorbell request on migration on P9
    
    commit ff42df49e75f053a8a6b4c2533100cdcc23afe69 upstream.
    
    On POWER9, when userspace reads the value of the DPDES register on a
    vCPU, it is possible for 0 to be returned although there is a doorbell
    interrupt pending for the vCPU.  This can lead to a doorbell interrupt
    being lost across migration.  If the guest kernel uses doorbell
    interrupts for IPIs, then it could malfunction because of the lost
    interrupt.
    
    This happens because a newly-generated doorbell interrupt is signalled
    by setting vcpu->arch.doorbell_request to 1; the DPDES value in
    vcpu->arch.vcore->dpdes is not updated, because it can only be updated
    when holding the vcpu mutex, in order to avoid races.
    
    To fix this, we OR in vcpu->arch.doorbell_request when reading the
    DPDES value.
    
    Cc: stable@vger.kernel.org # v4.13+
    Fixes: 579006944e0d ("KVM: PPC: Book3S HV: Virtualize doorbell facility on POWER9")
    Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
    Tested-by: Alexey Kardashevskiy <aik@ozlabs.ru>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1ea91b6a0aadb4494daba67c5957ecdcbbc44794
Author: Vasily Gorbik <gor@linux.ibm.com>
Date:   Thu Sep 19 15:55:17 2019 +0200

    s390/cio: exclude subchannels with no parent from pseudo check
    
    commit ab5758848039de9a4b249d46e4ab591197eebaf2 upstream.
    
    ccw console is created early in start_kernel and used before css is
    initialized or ccw console subchannel is registered. Until then console
    subchannel does not have a parent. For that reason assume subchannels
    with no parent are not pseudo subchannels. This fixes the following
    kasan finding:
    
    BUG: KASAN: global-out-of-bounds in sch_is_pseudo_sch+0x8e/0x98
    Read of size 8 at addr 00000000000005e8 by task swapper/0/0
    
    CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.3.0-rc8-07370-g6ac43dd12538 #2
    Hardware name: IBM 2964 NC9 702 (z/VM 6.4.0)
    Call Trace:
    ([<000000000012cd76>] show_stack+0x14e/0x1e0)
     [<0000000001f7fb44>] dump_stack+0x1a4/0x1f8
     [<00000000007d7afc>] print_address_description+0x64/0x3c8
     [<00000000007d75f6>] __kasan_report+0x14e/0x180
     [<00000000018a2986>] sch_is_pseudo_sch+0x8e/0x98
     [<000000000189b950>] cio_enable_subchannel+0x1d0/0x510
     [<00000000018cac7c>] ccw_device_recognition+0x12c/0x188
     [<0000000002ceb1a8>] ccw_device_enable_console+0x138/0x340
     [<0000000002cf1cbe>] con3215_init+0x25e/0x300
     [<0000000002c8770a>] console_init+0x68a/0x9b8
     [<0000000002c6a3d6>] start_kernel+0x4fe/0x728
     [<0000000000100070>] startup_continue+0x70/0xd0
    
    Cc: stable@vger.kernel.org
    Reviewed-by: Sebastian Ott <sebott@linux.ibm.com>
    Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b24b3eb6f20e2ddbb0a13efbd3e93e99890ec98c
Author: Vasily Gorbik <gor@linux.ibm.com>
Date:   Tue Sep 17 20:04:04 2019 +0200

    s390/cio: avoid calling strlen on null pointer
    
    commit ea298e6ee8b34b3ed4366be7eb799d0650ebe555 upstream.
    
    Fix the following kasan finding:
    BUG: KASAN: global-out-of-bounds in ccwgroup_create_dev+0x850/0x1140
    Read of size 1 at addr 0000000000000000 by task systemd-udevd.r/561
    
    CPU: 30 PID: 561 Comm: systemd-udevd.r Tainted: G    B
    Hardware name: IBM 3906 M04 704 (LPAR)
    Call Trace:
    ([<0000000231b3db7e>] show_stack+0x14e/0x1a8)
     [<0000000233826410>] dump_stack+0x1d0/0x218
     [<000000023216fac4>] print_address_description+0x64/0x380
     [<000000023216f5a8>] __kasan_report+0x138/0x168
     [<00000002331b8378>] ccwgroup_create_dev+0x850/0x1140
     [<00000002332b618a>] group_store+0x3a/0x50
     [<00000002323ac706>] kernfs_fop_write+0x246/0x3b8
     [<00000002321d409a>] vfs_write+0x132/0x450
     [<00000002321d47da>] ksys_write+0x122/0x208
     [<0000000233877102>] system_call+0x2a6/0x2c8
    
    Triggered by:
    openat(AT_FDCWD, "/sys/bus/ccwgroup/drivers/qeth/group",
                    O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 16
    write(16, "0.0.bd00,0.0.bd01,0.0.bd02", 26) = 26
    
    The problem is that __get_next_id in ccwgroup_create_dev might set "buf"
    buffer pointer to NULL and explicit check for that is required.
    
    Cc: stable@vger.kernel.org
    Reviewed-by: Sebastian Ott <sebott@linux.ibm.com>
    Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2f85516a0a65eb53d66cc1f759e0a8945f1326e0
Author: Vasily Gorbik <gor@linux.ibm.com>
Date:   Tue Sep 17 22:59:03 2019 +0200

    s390/topology: avoid firing events before kobjs are created
    
    commit f3122a79a1b0a113d3aea748e0ec26f2cb2889de upstream.
    
    arch_update_cpu_topology is first called from:
    kernel_init_freeable->sched_init_smp->sched_init_domains
    
    even before cpus has been registered in:
    kernel_init_freeable->do_one_initcall->s390_smp_init
    
    Do not trigger kobject_uevent change events until cpu devices are
    actually created. Fixes the following kasan findings:
    
    BUG: KASAN: global-out-of-bounds in kobject_uevent_env+0xb40/0xee0
    Read of size 8 at addr 0000000000000020 by task swapper/0/1
    
    BUG: KASAN: global-out-of-bounds in kobject_uevent_env+0xb36/0xee0
    Read of size 8 at addr 0000000000000018 by task swapper/0/1
    
    CPU: 0 PID: 1 Comm: swapper/0 Tainted: G    B
    Hardware name: IBM 3906 M04 704 (LPAR)
    Call Trace:
    ([<0000000143c6db7e>] show_stack+0x14e/0x1a8)
     [<0000000145956498>] dump_stack+0x1d0/0x218
     [<000000014429fb4c>] print_address_description+0x64/0x380
     [<000000014429f630>] __kasan_report+0x138/0x168
     [<0000000145960b96>] kobject_uevent_env+0xb36/0xee0
     [<0000000143c7c47c>] arch_update_cpu_topology+0x104/0x108
     [<0000000143df9e22>] sched_init_domains+0x62/0xe8
     [<000000014644c94a>] sched_init_smp+0x3a/0xc0
     [<0000000146433a20>] kernel_init_freeable+0x558/0x958
     [<000000014599002a>] kernel_init+0x22/0x160
     [<00000001459a71d4>] ret_from_fork+0x28/0x30
     [<00000001459a71dc>] kernel_thread_starter+0x0/0x10
    
    Cc: stable@vger.kernel.org
    Reviewed-by: Heiko Carstens <heiko.carstens@de.ibm.com>
    Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 799a1d34d03030a32902b637eec80de17c1e2270
Author: Thomas Huth <thuth@redhat.com>
Date:   Thu Aug 29 14:25:17 2019 +0200

    KVM: s390: Test for bad access register and size at the start of S390_MEM_OP
    
    commit a13b03bbb4575b350b46090af4dfd30e735aaed1 upstream.
    
    If the KVM_S390_MEM_OP ioctl is called with an access register >= 16,
    then there is certainly a bug in the calling userspace application.
    We check for wrong access registers, but only if the vCPU was already
    in the access register mode before (i.e. the SIE block has recorded
    it). The check is also buried somewhere deep in the calling chain (in
    the function ar_translation()), so this is somewhat hard to find.
    
    It's better to always report an error to the userspace in case this
    field is set wrong, and it's safer in the KVM code if we block wrong
    values here early instead of relying on a check somewhere deep down
    the calling chain, so let's add another check to kvm_s390_guest_mem_op()
    directly.
    
    We also should check that the "size" is non-zero here (thanks to Janosch
    Frank for the hint!). If we do not check the size, we could call vmalloc()
    with this 0 value, and this will cause a kernel warning.
    
    Signed-off-by: Thomas Huth <thuth@redhat.com>
    Link: https://lkml.kernel.org/r/20190829122517.31042-1-thuth@redhat.com
    Reviewed-by: Cornelia Huck <cohuck@redhat.com>
    Reviewed-by: Janosch Frank <frankja@linux.ibm.com>
    Reviewed-by: David Hildenbrand <david@redhat.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 219faf28d9c054a9ba0da4983253b08a0650be82
Author: Vasily Gorbik <gor@linux.ibm.com>
Date:   Tue Aug 13 20:11:08 2019 +0200

    s390/process: avoid potential reading of freed stack
    
    commit 8769f610fe6d473e5e8e221709c3ac402037da6c upstream.
    
    With THREAD_INFO_IN_TASK (which is selected on s390) task's stack usage
    is refcounted and should always be protected by get/put when touching
    other task's stack to avoid race conditions with task's destruction code.
    
    Fixes: d5c352cdd022 ("s390: move thread_info into task_struct")
    Cc: stable@vger.kernel.org # v4.10+
    Acked-by: Ilya Leoshkevich <iii@linux.ibm.com>
    Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>