1. 12 10月, 2019 40 次提交
    • R
      mmc: sdhci-of-esdhc: set DMA snooping based on DMA coherence · 7ed2867c
      Russell King 提交于
      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: NRussell King <rmk+kernel@armlinux.org.uk>
      Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7ed2867c
    • R
      mmc: sdhci: improve ADMA error reporting · 4509a19d
      Russell King 提交于
      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: NRussell King <rmk+kernel@armlinux.org.uk>
      Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4509a19d
    • X
      drm/i915/gvt: update vgpu workload head pointer correctly · 873f49d6
      Xiaolin Zhang 提交于
      commit 0a3242bdb47713e09cb004a0ba4947d3edf82d8a upstream.
      
      when creating a vGPU workload, the guest context head pointer should
      be updated correctly by comparing with the exsiting workload in the
      guest worklod queue including the current running context.
      
      in some situation, there is a running context A and then received 2 new
      vGPU workload context B and A. in the new workload context A, it's head
      pointer should be updated with the running context A's tail.
      
      v2: walk through guest workload list in backward way.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NXiaolin Zhang <xiaolin.zhang@intel.com>
      Reviewed-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      873f49d6
    • L
      drm/nouveau/kms/nv50-: Don't create MSTMs for eDP connectors · 198bc704
      Lyude Paul 提交于
      commit 698c1aa9f83b618de79e9e5e19a58f70a4a6ae0f upstream.
      
      On the ThinkPad P71, we have one eDP connector exposed along with 5 DP
      connectors, resulting in a total of 11 TMDS encoders. Since the GPU on
      this system is also capable of MST, we create an additional 4 fake MST
      encoders for each DP port. Unfortunately, we also do this for the eDP
      port as well, resulting in:
      
        1 eDP port: +1 TMDS encoder
                    +4 DPMST encoders
        5 DP ports: +2 TMDS encoders
                    +4 DPMST encoders
      	      *5 ports
      	      == 35 encoders
      
      Which breaks things, since DRM has a hard coded limit of 32 encoders.
      So, fix this by not creating MSTMs for any eDP connectors. This brings
      us down to 31 encoders, although we can do better.
      
      This fixes driver probing for nouveau on the ThinkPad P71.
      Signed-off-by: NLyude Paul <lyude@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      198bc704
    • S
      drm/msm/dsi: Fix return value check for clk_get_parent · 7a85c867
      Sean Paul 提交于
      commit 5fb9b797d5ccf311ae4aba69e86080d47668b5f7 upstream.
      
      clk_get_parent returns an error pointer upon failure, not NULL. So the
      checks as they exist won't catch a failure. This patch changes the
      checks and the return values to properly handle an error pointer.
      
      Fixes: c4d8cfe5 ("drm/msm/dsi: add implementation for helper functions")
      Cc: Sibi Sankar <sibis@codeaurora.org>
      Cc: Sean Paul <seanpaul@chromium.org>
      Cc: Rob Clark <robdclark@chromium.org>
      Cc: <stable@vger.kernel.org> # v4.19+
      Signed-off-by: NSean Paul <seanpaul@chromium.org>
      Signed-off-by: NRob Clark <robdclark@chromium.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7a85c867
    • T
      drm/omap: fix max fclk divider for omap36xx · 0e45633f
      Tomi Valkeinen 提交于
      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: NTomi 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.comTested-by: NAdam Ford <aford173@gmail.com>
      Reviewed-by: NJyri Sarha <jsarha@ti.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0e45633f
    • S
      perf stat: Fix a segmentation fault when using repeat forever · 90ac4028
      Srikar Dronamraju 提交于
      commit 443f2d5ba13d65ccfd879460f77941875159d154 upstream.
      
      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: d4f63a47 ("perf stat: Introduce print_counters function")
      Signed-off-by: NSrikar Dronamraju <srikar@linux.vnet.ibm.com>
      Acked-by: NJiri Olsa <jolsa@kernel.org>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Tested-by: NRavi 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.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      90ac4028
    • R
      watchdog: imx2_wdt: fix min() calculation in imx2_wdt_set_timeout · 22f28afd
      Rasmus Villemoes 提交于
      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: NRasmus Villemoes <linux@rasmusvillemoes.dk>
      Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
      Link: https://lore.kernel.org/r/20190812131356.23039-1-linux@rasmusvillemoes.dkSigned-off-by: NGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: NWim Van Sebroeck <wim@linux-watchdog.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      22f28afd
    • S
      PCI: Restore Resizable BAR size bits correctly for 1MB BARs · e7cf8cc7
      Sumit Saxena 提交于
      commit d2182b2d4b71ff0549a07f414d921525fade707b upstream.
      
      In a Resizable BAR Control Register, bits 13:8 control the size of the BAR.
      The encoded values of these bits are as follows (see PCIe r5.0, sec
      7.8.6.3):
      
        Value    BAR size
           0     1 MB (2^20 bytes)
           1     2 MB (2^21 bytes)
           2     4 MB (2^22 bytes)
         ...
          43     8 EB (2^63 bytes)
      
      Previously we incorrectly set the BAR size bits for a 1 MB BAR to 0x1f
      instead of 0, so devices that support that size, e.g., new megaraid_sas and
      mpt3sas adapters, fail to initialize during resume from S3 sleep.
      
      Correctly calculate the BAR size bits for Resizable BAR control registers.
      
      Link: https://lore.kernel.org/r/20190725192552.24295-1-sumit.saxena@broadcom.com
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203939
      Fixes: d3252ace ("PCI: Restore resized BAR state on resume")
      Signed-off-by: NSumit Saxena <sumit.saxena@broadcom.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: NChristian König <christian.koenig@amd.com>
      Cc: stable@vger.kernel.org	# v4.19+
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e7cf8cc7
    • J
      PCI: vmd: Fix shadow offsets to reflect spec changes · 956ce989
      Jon Derrick 提交于
      commit a1a30170138c9c5157bd514ccd4d76b47060f29b upstream.
      
      The shadow offset scratchpad was moved to 0x2000-0x2010. Update the
      location to get the correct shadow offset.
      
      Fixes: 6788958e ("PCI: vmd: Assign membar addresses from shadow registers")
      Signed-off-by: NJon Derrick <jonathan.derrick@intel.com>
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Cc: stable@vger.kernel.org # v5.2+
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      956ce989
    • L
      timer: Read jiffies once when forwarding base clk · 06f25021
      Li RongQing 提交于
      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: 23696838 ("timers: Optimize collect_expired_timers() for NOHZ")
      Signed-off-by: NLi RongQing <lirongqing@baidu.com>
      Signed-off-by: NLiang ZhiCheng <liangzhicheng@baidu.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/1568894687-14499-1-git-send-email-lirongqing@baidu.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      06f25021
    • K
      usercopy: Avoid HIGHMEM pfn warning · 12c6c4a5
      Kees Cook 提交于
      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: NRandy Dunlap <rdunlap@infradead.org>
      Tested-by: NRandy Dunlap <rdunlap@infradead.org>
      Fixes: f5509cc1 ("mm: Hardened usercopy")
      Cc: Matthew Wilcox <willy@infradead.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: NKees Cook <keescook@chromium.org>
      Reviewed-by: NMatthew Wilcox (Oracle) <willy@infradead.org>
      Link: https://lore.kernel.org/r/201909171056.7F2FFD17@keescookSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      12c6c4a5
    • T
      tracing: Make sure variable reference alias has correct var_ref_idx · e010c983
      Tom Zanussi 提交于
      commit 17f8607a1658a8e70415eef67909f990d13017b5 upstream.
      
      Original changelog from Steve Rostedt (except last sentence which
      explains the problem, and the Fixes: tag):
      
      I performed a three way histogram with the following commands:
      
      echo 'irq_lat u64 lat pid_t pid' > synthetic_events
      echo 'wake_lat u64 lat u64 irqlat pid_t pid' >> synthetic_events
      echo 'hist:keys=common_pid:irqts=common_timestamp.usecs if function == 0xffffffff81200580' > events/timer/hrtimer_start/trigger
      echo 'hist:keys=common_pid:lat=common_timestamp.usecs-$irqts:onmatch(timer.hrtimer_start).irq_lat($lat,pid) if common_flags & 1' > events/sched/sched_waking/trigger
      echo 'hist:keys=pid:wakets=common_timestamp.usecs,irqlat=lat' > events/synthetic/irq_lat/trigger
      echo 'hist:keys=next_pid:lat=common_timestamp.usecs-$wakets,irqlat=$irqlat:onmatch(synthetic.irq_lat).wake_lat($lat,$irqlat,next_pid)' > events/sched/sched_switch/trigger
      echo 1 > events/synthetic/wake_lat/enable
      
      Basically I wanted to see:
      
       hrtimer_start (calling function tick_sched_timer)
      
      Note:
      
        # grep tick_sched_timer /proc/kallsyms
      ffffffff81200580 t tick_sched_timer
      
      And save the time of that, and then record sched_waking if it is called
      in interrupt context and with the same pid as the hrtimer_start, it
      will record the latency between that and the waking event.
      
      I then look at when the task that is woken is scheduled in, and record
      the latency between the wakeup and the task running.
      
      At the end, the wake_lat synthetic event will show the wakeup to
      scheduled latency, as well as the irq latency in from hritmer_start to
      the wakeup. The problem is that I found this:
      
                <idle>-0     [007] d...   190.485261: wake_lat: lat=27 irqlat=190485230 pid=698
                <idle>-0     [005] d...   190.485283: wake_lat: lat=40 irqlat=190485239 pid=10
                <idle>-0     [002] d...   190.488327: wake_lat: lat=56 irqlat=190488266 pid=335
                <idle>-0     [005] d...   190.489330: wake_lat: lat=64 irqlat=190489262 pid=10
                <idle>-0     [003] d...   190.490312: wake_lat: lat=43 irqlat=190490265 pid=77
                <idle>-0     [005] d...   190.493322: wake_lat: lat=54 irqlat=190493262 pid=10
                <idle>-0     [005] d...   190.497305: wake_lat: lat=35 irqlat=190497267 pid=10
                <idle>-0     [005] d...   190.501319: wake_lat: lat=50 irqlat=190501264 pid=10
      
      The irqlat seemed quite large! Investigating this further, if I had
      enabled the irq_lat synthetic event, I noticed this:
      
                <idle>-0     [002] d.s.   249.429308: irq_lat: lat=164968 pid=335
                <idle>-0     [002] d...   249.429369: wake_lat: lat=55 irqlat=249429308 pid=335
      
      Notice that the timestamp of the irq_lat "249.429308" is awfully
      similar to the reported irqlat variable. In fact, all instances were
      like this. It appeared that:
      
        irqlat=$irqlat
      
      Wasn't assigning the old $irqlat to the new irqlat variable, but
      instead was assigning the $irqts to it.
      
      The issue is that assigning the old $irqlat to the new irqlat variable
      creates a variable reference alias, but the alias creation code
      forgets to make sure the alias uses the same var_ref_idx to access the
      reference.
      
      Link: http://lkml.kernel.org/r/1567375321.5282.12.camel@kernel.org
      
      Cc: Linux Trace Devel <linux-trace-devel@vger.kernel.org>
      Cc: linux-rt-users <linux-rt-users@vger.kernel.org>
      Cc: stable@vger.kernel.org
      Fixes: 7e8b88a3 ("tracing: Add hist trigger support for variable reference aliases")
      Reported-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      Signed-off-by: NTom Zanussi <zanussi@kernel.org>
      Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e010c983
    • M
      power: supply: sbs-battery: only return health when battery present · 022ca58f
      Michael Nosthoff 提交于
      commit fe55e770327363304c4111423e6f7ff3c650136d upstream.
      
      when the battery is set to sbs-mode and  no gpio detection is enabled
      "health" is always returning a value even when the battery is not present.
      All other fields return "not present".
      This leads to a scenario where the driver is constantly switching between
      "present" and "not present" state. This generates a lot of constant
      traffic on the i2c.
      
      This commit changes the response of "health" to an error when the battery
      is not responding leading to a consistent "not present" state.
      
      Fixes: 76b16f4c ("power: supply: sbs-battery: don't assume MANUFACTURER_DATA formats")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NMichael Nosthoff <committed@heine.so>
      Reviewed-by: NBrian Norris <briannorris@chromium.org>
      Tested-by: NBrian Norris <briannorris@chromium.org>
      Signed-off-by: NSebastian Reichel <sebastian.reichel@collabora.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      022ca58f
    • M
      power: supply: sbs-battery: use correct flags field · 5cb6dd82
      Michael Nosthoff 提交于
      commit 99956a9e08251a1234434b492875b1eaff502a12 upstream.
      
      the type flag is stored in the chip->flags field not in the
      client->flags field. This currently leads to never using the ti
      specific health function as client->flags doesn't use that bit.
      So it's always falling back to the general one.
      
      Fixes: 76b16f4c ("power: supply: sbs-battery: don't assume MANUFACTURER_DATA formats")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NMichael Nosthoff <committed@heine.so>
      Reviewed-by: NBrian Norris <briannorris@chromium.org>
      Reviewed-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>
      Signed-off-by: NSebastian Reichel <sebastian.reichel@collabora.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5cb6dd82
    • J
      MIPS: Treat Loongson Extensions as ASEs · fb93ccde
      Jiaxun Yang 提交于
      commit d2f965549006acb865c4638f1f030ebcefdc71f6 upstream.
      
      Recently, binutils had split Loongson-3 Extensions into four ASEs:
      MMI, CAM, EXT, EXT2. This patch do the samething in kernel and expose
      them in cpuinfo so applications can probe supported ASEs at runtime.
      Signed-off-by: NJiaxun Yang <jiaxun.yang@flygoat.com>
      Cc: Huacai Chen <chenhc@lemote.com>
      Cc: Yunqiang Su <ysu@wavecomp.com>
      Cc: stable@vger.kernel.org # v4.14+
      Signed-off-by: NPaul Burton <paul.burton@mips.com>
      Cc: linux-mips@vger.kernel.org
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fb93ccde
    • G
      crypto: ccree - use the full crypt length value · a0dc60ac
      Gilad Ben-Yossef 提交于
      commit 7a4be6c113c1f721818d1e3722a9015fe393295c upstream.
      
      In case of AEAD decryption verifcation error we were using the
      wrong value to zero out the plaintext buffer leaving the end of
      the buffer with the false plaintext.
      Signed-off-by: NGilad Ben-Yossef <gilad@benyossef.com>
      Fixes: ff27e85a ("crypto: ccree - add AEAD support")
      CC: stable@vger.kernel.org # v4.17+
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a0dc60ac
    • G
      crypto: ccree - account for TEE not ready to report · f5c087a0
      Gilad Ben-Yossef 提交于
      commit 76a95bd8f9e10cade9c4c8df93b5c20ff45dc0f5 upstream.
      
      When ccree driver runs it checks the state of the Trusted Execution
      Environment CryptoCell driver before proceeding. We did not account
      for cases where the TEE side is not ready or not available at all.
      Fix it by only considering TEE error state after sync with the TEE
      side driver.
      Signed-off-by: NGilad Ben-Yossef <gilad@benyossef.com>
      Fixes: ab8ec965 ("crypto: ccree - add FIPS support")
      CC: stable@vger.kernel.org # v4.17+
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f5c087a0
    • H
      crypto: caam - fix concurrency issue in givencrypt descriptor · 561bf930
      Horia Geantă 提交于
      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: 1acebad3 ("crypto: caam - faster aead implementation")
      Signed-off-by: NHoria Geantă <horia.geanta@nxp.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      561bf930
    • W
      crypto: cavium/zip - Add missing single_release() · 3683dd70
      Wei Yongjun 提交于
      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: 09ae5d37 ("crypto: zip - Add Compression/Decompression statistics")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NWei Yongjun <weiyongjun1@huawei.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3683dd70
    • H
      crypto: skcipher - Unmap pages after an external error · cd8e0a5d
      Herbert Xu 提交于
      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: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Fixes: 5cde0af2 ("[CRYPTO] cipher: Added block cipher type")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Tested-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cd8e0a5d
    • A
      crypto: qat - Silence smp_processor_id() warning · 9349108a
      Alexander Sverdlin 提交于
      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 e7a9b05c
      ("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: ed8ccaef ("crypto: qat - Add support for SRIOV")
      Cc: stable@vger.kernel.org
      Signed-off-by: NAlexander Sverdlin <alexander.sverdlin@nokia.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9349108a
    • S
      tools lib traceevent: Fix "robust" test of do_generate_dynamic_list_file · 532920b2
      Steven Rostedt (VMware) 提交于
      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: NTzvetomir Stoyanov <tstoyanov@vmware.com>
      Signed-off-by: NSteven 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: 6467753d ("tools lib traceevent: Robustify do_generate_dynamic_list_file")
      Link: http://lkml.kernel.org/r/20190805130150.25acfeb1@gandalf.local.homeSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      532920b2
    • M
      can: mcp251x: mcp251x_hw_reset(): allow more time after a reset · 4aaea17d
      Marc Kleine-Budde 提交于
      commit d84ea2123f8d27144e3f4d58cd88c9c6ddc799de upstream.
      
      Some boards take longer than 5ms to power up after a reset, so allow
      some retries attempts before giving up.
      
      Fixes: ff06d611 ("can: mcp251x: Improve mcp251x_hw_reset()")
      Cc: linux-stable <stable@vger.kernel.org>
      Tested-by: NSean Nyekjaer <sean@geanix.com>
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4aaea17d
    • A
      powerpc/book3s64/mm: Don't do tlbie fixup for some hardware revisions · 9124eac4
      Aneesh Kumar K.V 提交于
      commit 677733e296b5c7a37c47da391fc70a43dc40bd67 upstream.
      
      The store ordering vs tlbie issue mentioned in commit
      a5d4b589 ("powerpc/mm: Fixup tlbie vs store ordering issue on
      POWER9") is fixed for Nimbus 2.3 and Cumulus 1.3 revisions. We don't
      need to apply the fixup if we are running on them
      
      We can only do this on PowerNV. On pseries guest with KVM we still
      don't support redoing the feature fixup after migration. So we should
      be enabling all the workarounds needed, because whe can possibly
      migrate between DD 2.3 and DD 2.2
      
      Fixes: a5d4b589 ("powerpc/mm: Fixup tlbie vs store ordering issue on POWER9")
      Cc: stable@vger.kernel.org # v4.16+
      Signed-off-by: NAneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      Link: https://lore.kernel.org/r/20190924035254.24612-1-aneesh.kumar@linux.ibm.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9124eac4
    • A
      powerpc/powernv/ioda: Fix race in TCE level allocation · 19c12f12
      Alexey Kardashevskiy 提交于
      commit 56090a3902c80c296e822d11acdb6a101b322c52 upstream.
      
      pnv_tce() returns a pointer to a TCE entry and originally a TCE table
      would be pre-allocated. For the default case of 2GB window the table
      needs only a single level and that is fine. However if more levels are
      requested, it is possible to get a race when 2 threads want a pointer
      to a TCE entry from the same page of TCEs.
      
      This adds cmpxchg to handle the race. Note that once TCE is non-zero,
      it cannot become zero again.
      
      Fixes: a68bd126 ("powerpc/powernv/ioda: Allocate indirect TCE levels on demand")
      CC: stable@vger.kernel.org # v4.19+
      Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      Link: https://lore.kernel.org/r/20190718051139.74787-2-aik@ozlabs.ruSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      19c12f12
    • A
      powerpc/powernv: Restrict OPAL symbol map to only be readable by root · 032ce7d7
      Andrew Donnellan 提交于
      commit e7de4f7b64c23e503a8c42af98d56f2a7462bd6d upstream.
      
      Currently the OPAL symbol map is globally readable, which seems bad as
      it contains physical addresses.
      
      Restrict it to root.
      
      Fixes: c8742f85 ("powerpc/powernv: Expose OPAL firmware symbol map")
      Cc: stable@vger.kernel.org # v3.19+
      Suggested-by: NMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: NAndrew Donnellan <ajd@linux.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      Link: https://lore.kernel.org/r/20190503075253.22798-1-ajd@linux.ibm.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      032ce7d7
    • S
      powerpc/mce: Schedule work from irq_work · ba3ca9fc
      Santosh Sivaraj 提交于
      commit b5bda6263cad9a927e1a4edb7493d542da0c1410 upstream.
      
      schedule_work() cannot be called from MCE exception context as MCE can
      interrupt even in interrupt disabled context.
      
      Fixes: 733e4a4c ("powerpc/mce: hookup memory_failure for UE errors")
      Cc: stable@vger.kernel.org # v4.15+
      Reviewed-by: NMahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
      Reviewed-by: NNicholas Piggin <npiggin@gmail.com>
      Acked-by: NBalbir Singh <bsingharora@gmail.com>
      Signed-off-by: NSantosh Sivaraj <santosh@fossix.org>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      Link: https://lore.kernel.org/r/20190820081352.8641-2-santosh@fossix.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ba3ca9fc
    • B
      powerpc/mce: Fix MCE handling for huge pages · ee6eeeb8
      Balbir Singh 提交于
      commit 99ead78afd1128bfcebe7f88f3b102fb2da09aee upstream.
      
      The current code would fail on huge pages addresses, since the shift would
      be incorrect. Use the correct page shift value returned by
      __find_linux_pte() to get the correct physical address. The code is more
      generic and can handle both regular and compound pages.
      
      Fixes: ba41e1e1 ("powerpc/mce: Hookup derror (load/store) UE errors")
      Signed-off-by: NBalbir Singh <bsingharora@gmail.com>
      [arbab@linux.ibm.com: Fixup pseries_do_memory_failure()]
      Signed-off-by: NReza Arbab <arbab@linux.ibm.com>
      Tested-by: NMahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
      Signed-off-by: NSantosh Sivaraj <santosh@fossix.org>
      Cc: stable@vger.kernel.org # v4.15+
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      Link: https://lore.kernel.org/r/20190820081352.8641-3-santosh@fossix.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ee6eeeb8
    • O
      ASoC: sgtl5000: Improve VAG power and mute control · 1284f207
      Oleksandr Suvorov 提交于
      commit b1f373a11d25fc9a5f7679c9b85799fe09b0dc4a upstream.
      
      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: 9b34e6cc ("ASoC: Add Freescale SGTL5000 codec support")
      Signed-off-by: NOleksandr Suvorov <oleksandr.suvorov@toradex.com>
      Reviewed-by: NMarcel Ziswiler <marcel.ziswiler@toradex.com>
      Reviewed-by: NFabio Estevam <festevam@gmail.com>
      Reviewed-by: NCezary Rojewski <cezary.rojewski@intel.com>
      Link: https://lore.kernel.org/r/20190719100524.23300-3-oleksandr.suvorov@toradex.comSigned-off-by: NMark Brown <broonie@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1284f207
    • O
      ASoC: Define a set of DAPM pre/post-up events · 50090b75
      Oleksandr Suvorov 提交于
      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: NOleksandr Suvorov <oleksandr.suvorov@toradex.com>
      Reviewed-by: NMarcel Ziswiler <marcel.ziswiler@toradex.com>
      Reviewed-by: NIgor Opaniuk <igor.opaniuk@toradex.com>
      Reviewed-by: NFabio Estevam <festevam@gmail.com>
      Link: https://lore.kernel.org/r/20190719100524.23300-2-oleksandr.suvorov@toradex.comSigned-off-by: NMark Brown <broonie@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      50090b75
    • D
      PM / devfreq: tegra: Fix kHz to Hz conversion · 42b888f6
      Dmitry Osipenko 提交于
      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: NSteev Klimaszewski <steev@kali.org>
      Reviewed-by: NChanwoo Choi <cw00.choi@samsung.com>
      Signed-off-by: NDmitry Osipenko <digetx@gmail.com>
      Acked-by: NThierry Reding <treding@nvidia.com>
      Signed-off-by: NMyungJoo Ham <myungjoo.ham@samsung.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      42b888f6
    • M
      nbd: fix max number of supported devs · 9f0f39c9
      Mike Christie 提交于
      commit e9e006f5fcf2bab59149cb38a48a4817c1b538b4 upstream.
      
      This fixes a bug added in 4.10 with commit:
      
      commit 9561a7ad
      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: NJosef Bacik <josef@toxicpanda.com>
      Signed-off-by: NMike Christie <mchristi@redhat.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9f0f39c9
    • J
      KVM: nVMX: handle page fault in vmread fix · eff3a54a
      Jack Wang 提交于
      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: NJack Wang <jinpu.wang@cloud.ionos.com>
      Acked-by: NPaolo Bonzini <pbonzini@redhat.com>
      eff3a54a
    • W
      KVM: X86: Fix userspace set invalid CR4 · 21874027
      Wanpeng Li 提交于
      commit 3ca94192278ca8de169d78c085396c424be123b3 upstream.
      
      Reported by syzkaller:
      
      	WARNING: CPU: 0 PID: 6544 at /home/kernel/data/kvm/arch/x86/kvm//vmx/vmx.c:4689 handle_desc+0x37/0x40 [kvm_intel]
      	CPU: 0 PID: 6544 Comm: a.out Tainted: G           OE     5.3.0-rc4+ #4
      	RIP: 0010:handle_desc+0x37/0x40 [kvm_intel]
      	Call Trace:
      	 vmx_handle_exit+0xbe/0x6b0 [kvm_intel]
      	 vcpu_enter_guest+0x4dc/0x18d0 [kvm]
      	 kvm_arch_vcpu_ioctl_run+0x407/0x660 [kvm]
      	 kvm_vcpu_ioctl+0x3ad/0x690 [kvm]
      	 do_vfs_ioctl+0xa2/0x690
      	 ksys_ioctl+0x6d/0x80
      	 __x64_sys_ioctl+0x1a/0x20
      	 do_syscall_64+0x74/0x720
      	 entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      When CR4.UMIP is set, guest should have UMIP cpuid flag. Current
      kvm set_sregs function doesn't have such check when userspace inputs
      sregs values. SECONDARY_EXEC_DESC is enabled on writes to CR4.UMIP
      in vmx_set_cr4 though guest doesn't have UMIP cpuid flag. The testcast
      triggers handle_desc warning when executing ltr instruction since
      guest architectural CR4 doesn't set UMIP. This patch fixes it by
      adding valid CR4 and CPUID combination checking in __set_sregs.
      
      syzkaller source: https://syzkaller.appspot.com/x/repro.c?x=138efb99600000
      
      Reported-by: syzbot+0f1819555fbdce992df9@syzkaller.appspotmail.com
      Cc: stable@vger.kernel.org
      Signed-off-by: NWanpeng Li <wanpengli@tencent.com>
      Reviewed-by: NSean Christopherson <sean.j.christopherson@intel.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      21874027
    • P
      KVM: PPC: Book3S HV: Don't lose pending doorbell request on migration on P9 · 30fbe0d3
      Paul Mackerras 提交于
      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: 57900694 ("KVM: PPC: Book3S HV: Virtualize doorbell facility on POWER9")
      Signed-off-by: NPaul Mackerras <paulus@ozlabs.org>
      Tested-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      30fbe0d3
    • P
      KVM: PPC: Book3S HV: Check for MMU ready on piggybacked virtual cores · 4faa7f05
      Paul Mackerras 提交于
      commit d28eafc5a64045c78136162af9d4ba42f8230080 upstream.
      
      When we are running multiple vcores on the same physical core, they
      could be from different VMs and so it is possible that one of the
      VMs could have its arch.mmu_ready flag cleared (for example by a
      concurrent HPT resize) when we go to run it on a physical core.
      We currently check the arch.mmu_ready flag for the primary vcore
      but not the flags for the other vcores that will be run alongside
      it.  This adds that check, and also a check when we select the
      secondary vcores from the preempted vcores list.
      
      Cc: stable@vger.kernel.org # v4.14+
      Fixes: 38c53af8 ("KVM: PPC: Book3S HV: Fix exclusion between HPT resizing and other HPT updates")
      Signed-off-by: NPaul Mackerras <paulus@ozlabs.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4faa7f05
    • P
      KVM: PPC: Book3S HV: Fix race in re-enabling XIVE escalation interrupts · 577a5119
      Paul Mackerras 提交于
      commit 959c5d5134786b4988b6fdd08e444aa67d1667ed upstream.
      
      Escalation interrupts are interrupts sent to the host by the XIVE
      hardware when it has an interrupt to deliver to a guest VCPU but that
      VCPU is not running anywhere in the system.  Hence we disable the
      escalation interrupt for the VCPU being run when we enter the guest
      and re-enable it when the guest does an H_CEDE hypercall indicating
      it is idle.
      
      It is possible that an escalation interrupt gets generated just as we
      are entering the guest.  In that case the escalation interrupt may be
      using a queue entry in one of the interrupt queues, and that queue
      entry may not have been processed when the guest exits with an H_CEDE.
      The existing entry code detects this situation and does not clear the
      vcpu->arch.xive_esc_on flag as an indication that there is a pending
      queue entry (if the queue entry gets processed, xive_esc_irq() will
      clear the flag).  There is a comment in the code saying that if the
      flag is still set on H_CEDE, we have to abort the cede rather than
      re-enabling the escalation interrupt, lest we end up with two
      occurrences of the escalation interrupt in the interrupt queue.
      
      However, the exit code doesn't do that; it aborts the cede in the sense
      that vcpu->arch.ceded gets cleared, but it still enables the escalation
      interrupt by setting the source's PQ bits to 00.  Instead we need to
      set the PQ bits to 10, indicating that an interrupt has been triggered.
      We also need to avoid setting vcpu->arch.xive_esc_on in this case
      (i.e. vcpu->arch.xive_esc_on seen to be set on H_CEDE) because
      xive_esc_irq() will run at some point and clear it, and if we race with
      that we may end up with an incorrect result (i.e. xive_esc_on set when
      the escalation interrupt has just been handled).
      
      It is extremely unlikely that having two queue entries would cause
      observable problems; theoretically it could cause queue overflow, but
      the CPU would have to have thousands of interrupts targetted to it for
      that to be possible.  However, this fix will also make it possible to
      determine accurately whether there is an unhandled escalation
      interrupt in the queue, which will be needed by the following patch.
      
      Fixes: 9b9b13a6 ("KVM: PPC: Book3S HV: Keep XIVE escalation interrupt masked unless ceded")
      Cc: stable@vger.kernel.org # v4.16+
      Signed-off-by: NPaul Mackerras <paulus@ozlabs.org>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      Link: https://lore.kernel.org/r/20190813100349.GD9567@blackberrySigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      577a5119
    • V
      s390/cio: exclude subchannels with no parent from pseudo check · 46cb14a5
      Vasily Gorbik 提交于
      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: NSebastian Ott <sebott@linux.ibm.com>
      Signed-off-by: NVasily Gorbik <gor@linux.ibm.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      46cb14a5
    • V
      s390/topology: avoid firing events before kobjs are created · 9aa823b3
      Vasily Gorbik 提交于
      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: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NVasily Gorbik <gor@linux.ibm.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9aa823b3