1. 03 Jul, 2018 15 commits
    • Maxim Moseychuk's avatar
      usb: do not reset if a low-speed or full-speed device timed out · 3c22218e
      Maxim Moseychuk authored
      commit 6e01827e upstream.
      
      Some low-speed and full-speed devices (for example, bluetooth)
      do not have time to initialize. For them, ETIMEDOUT is a valid error.
      We need to give them another try. Otherwise, they will
      never be initialized correctly and in dmesg will be messages
      "Bluetooth: hci0 command 0x1002 tx timeout" or similars.
      
      Fixes: 264904cc ("usb: retry reset if a device times out")
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarMaxim Moseychuk <franchesko.salias.hudro.pedros@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3c22218e
    • Waldemar Rymarkiewicz's avatar
      PM / OPP: Update voltage in case freq == old_freq · 8b033765
      Waldemar Rymarkiewicz authored
      commit c5c2a97b upstream.
      
      This commit fixes a rare but possible case when the clk rate is updated
      without update of the regulator voltage.
      
      At boot up, CPUfreq checks if the system is running at the right freq. This
      is a sanity check in case a bootloader set clk rate that is outside of freq
      table present with cpufreq core. In such cases system can be unstable so
      better to change it to a freq that is preset in freq-table.
      
      The CPUfreq takes next freq that is >= policy->cur and this is our
      target_freq that needs to be set now.
      
      dev_pm_opp_set_rate(dev, target_freq) checks the target_freq and the
      old_freq (a current rate). If these are equal it returns early. If not,
      it searches for OPP (old_opp) that fits best to old_freq (not listed in
      the table) and updates old_freq (!).
      
      Here, we can end up with old_freq = old_opp.rate = target_freq, which
      is not handled in _generic_set_opp_regulator(). It's supposed to update
      voltage only when freq > old_freq  || freq > old_freq.
      
      if (freq > old_freq) {
      		ret = _set_opp_voltage(dev, reg, new_supply);
      [...]
      if (freq < old_freq) {
      		ret = _set_opp_voltage(dev, reg, new_supply);
      		if (ret)
      
      It results in, no voltage update while clk rate is updated.
      
      Example:
      freq-table = {
      	1000MHz   1.15V
      	 666MHZ   1.10V
      	 333MHz   1.05V
      }
      boot-up-freq        = 800MHz   # not listed in freq-table
      freq = target_freq  = 1GHz
      old_freq            = 800Mhz
      old_opp = _find_freq_ceil(opp_table, &old_freq);  #(old_freq is modified!)
      old_freq            = 1GHz
      
      Fixes: 6a0712f6 ("PM / OPP: Add dev_pm_opp_set_rate()")
      Cc: 4.6+ <stable@vger.kernel.org> # v4.6+
      Signed-off-by: default avatarWaldemar Rymarkiewicz <waldemar.rymarkiewicz@gmail.com>
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8b033765
    • Rafael J. Wysocki's avatar
      PM / core: Fix supplier device runtime PM usage counter imbalance · ba0be597
      Rafael J. Wysocki authored
      commit 47e5abfb upstream.
      
      If a device link is added via device_link_add() by the driver of the
      link's consumer device, the supplier's runtime PM usage counter is
      going to be dropped by the pm_runtime_put_suppliers() call in
      driver_probe_device().  However, in that case it is not incremented
      unless the supplier driver is already present and the link is not
      stateless.  That leads to a runtime PM usage counter imbalance for
      the supplier device in a few cases.
      
      To prevent that from happening, bump up the supplier runtime
      PM usage counter in device_link_add() for all links with the
      DL_FLAG_PM_RUNTIME flag set that are added at the consumer probe
      time.  Use pm_runtime_get_noresume() for that as the callers of
      device_link_add() who want the supplier to be resumed by it are
      expected to pass DL_FLAG_RPM_ACTIVE in flags to it anyway, but
      additionally resume the supplier if the link is added during
      consumer driver probe to retain the existing behavior for the
      callers depending on it.
      
      Fixes: 21d5c57b (PM / runtime: Use device links)
      Reported-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Reviewed-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Tested-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
      Cc: 4.10+ <stable@vger.kernel.org> # 4.10+
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ba0be597
    • Ulf Hansson's avatar
      PM / Domains: Fix error path during attach in genpd · b7ac0389
      Ulf Hansson authored
      commit 72038df3 upstream.
      
      In case the PM domain fails to be powered on in genpd_dev_pm_attach(), it
      returns -EPROBE_DEFER, but keeping the device attached to its PM domain.
      This leads to problems when the next attempt to attach is re-tried. More
      precisely, in that situation an -EEXIST error code is returned, because the
      device already has its PM domain pointer assigned, from the first attempt.
      
      Now, because of the sloppy error handling by the existing callers of
      dev_pm_domain_attach(), probing is allowed to continue when -EEXIST is
      returned. However, in such case there are no guarantees that the PM domain
      is powered on by genpd, which may lead to hangs when buses/drivers tried to
      access their devices.
      
      Let's fix this behaviour, simply by detaching the device when powering on
      fails in genpd_dev_pm_attach().
      
      Cc: v4.11+ <stable@vger.kernel.org> # v4.11+
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b7ac0389
    • Eric W. Biederman's avatar
      signal/xtensa: Consistenly use SIGBUS in do_unaligned_user · 8ae5d476
      Eric W. Biederman authored
      commit 7de712cc upstream.
      
      While working on changing this code to use force_sig_fault I
      discovered that do_unaliged_user is sets si_signo to SIGBUS and passes
      SIGSEGV to force_sig_info.  Which is just b0rked.
      
      The code is reporting a SIGBUS error so replace the SIGSEGV with SIGBUS.
      
      Cc: Chris Zankel <chris@zankel.net>
      Cc: Max Filippov <jcmvbkbc@gmail.com>
      Cc: linux-xtensa@linux-xtensa.org
      Cc: stable@vger.kernel.org
      Acked-by: default avatarMax Filippov <jcmvbkbc@gmail.com>
      Fixes: 5a0015d6 ("[PATCH] xtensa: Architecture support for Tensilica Xtensa Part 3")
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8ae5d476
    • Daniel Wagner's avatar
      serial: sh-sci: Use spin_{try}lock_irqsave instead of open coding version · 980899da
      Daniel Wagner authored
      commit 8afb1d2c upstream.
      
      Commit 40f70c03 ("serial: sh-sci: add locking to console write
      function to avoid SMP lockup") copied the strategy to avoid locking
      problems in conjuncture with the console from the UART8250
      driver. Instead using directly spin_{try}lock_irqsave(),
      local_irq_save() followed by spin_{try}lock() was used. While this is
      correct on mainline, for -rt it is a problem. spin_{try}lock() will
      check if it is running in a valid context. Since the local_irq_save()
      has already been executed, the context has changed and
      spin_{try}lock() will complain. The reason why spin_{try}lock()
      complains is that on -rt the spin locks are turned into mutexes and
      therefore can sleep. Sleeping with interrupts disabled is not valid.
      
      BUG: sleeping function called from invalid context at /home/wagi/work/rt/v4.4-cip-rt/kernel/locking/rtmutex.c:995
      in_atomic(): 0, irqs_disabled(): 128, pid: 778, name: irq/76-eth0
      CPU: 0 PID: 778 Comm: irq/76-eth0 Not tainted 4.4.126-test-cip22-rt14-00403-gcd03665c8318 #12
      Hardware name: Generic RZ/G1 (Flattened Device Tree)
      Backtrace:
      [<c00140a0>] (dump_backtrace) from [<c001424c>] (show_stack+0x18/0x1c)
       r7:c06b01f0 r6:60010193 r5:00000000 r4:c06b01f0
      [<c0014234>] (show_stack) from [<c01d3c94>] (dump_stack+0x78/0x94)
      [<c01d3c1c>] (dump_stack) from [<c004c134>] (___might_sleep+0x134/0x194)
       r7:60010113 r6:c06d3559 r5:00000000 r4:ffffe000
      [<c004c000>] (___might_sleep) from [<c04ded60>] (rt_spin_lock+0x20/0x74)
       r5:c06f4d60 r4:c06f4d60
      [<c04ded40>] (rt_spin_lock) from [<c02577e4>] (serial_console_write+0x100/0x118)
       r5:c06f4d60 r4:c06f4d60
      [<c02576e4>] (serial_console_write) from [<c0061060>] (call_console_drivers.constprop.15+0x10c/0x124)
       r10:c06d2894 r9:c04e18b0 r8:00000028 r7:00000000 r6:c06d3559 r5:c06d2798
       r4:c06b9914 r3:c02576e4
      [<c0060f54>] (call_console_drivers.constprop.15) from [<c0062984>] (console_unlock+0x32c/0x430)
       r10:c06d30d8 r9:00000028 r8:c06dd518 r7:00000005 r6:00000000 r5:c06d2798
       r4:c06d2798 r3:00000028
      [<c0062658>] (console_unlock) from [<c0062e1c>] (vprintk_emit+0x394/0x4f0)
       r10:c06d2798 r9:c06d30ee r8:00000006 r7:00000005 r6:c06a78fc r5:00000027
       r4:00000003
      [<c0062a88>] (vprintk_emit) from [<c0062fa0>] (vprintk+0x28/0x30)
       r10:c060bd46 r9:00001000 r8:c06b9a90 r7:c06b9a90 r6:c06b994c r5:c06b9a3c
       r4:c0062fa8
      [<c0062f78>] (vprintk) from [<c0062fb8>] (vprintk_default+0x10/0x14)
      [<c0062fa8>] (vprintk_default) from [<c009cd30>] (printk+0x78/0x84)
      [<c009ccbc>] (printk) from [<c025afdc>] (credit_entropy_bits+0x17c/0x2cc)
       r3:00000001 r2:decade60 r1:c061a5ee r0:c061a523
       r4:00000006
      [<c025ae60>] (credit_entropy_bits) from [<c025bf74>] (add_interrupt_randomness+0x160/0x178)
       r10:466e7196 r9:1f536000 r8:fffeef74 r7:00000000 r6:c06b9a60 r5:c06b9a3c
       r4:dfbcf680
      [<c025be14>] (add_interrupt_randomness) from [<c006536c>] (irq_thread+0x1e8/0x248)
       r10:c006537c r9:c06cdf21 r8:c0064fcc r7:df791c24 r6:df791c00 r5:ffffe000
       r4:df525180
      [<c0065184>] (irq_thread) from [<c003fba4>] (kthread+0x108/0x11c)
       r10:00000000 r9:00000000 r8:c0065184 r7:df791c00 r6:00000000 r5:df791d00
       r4:decac000
      [<c003fa9c>] (kthread) from [<c00101b8>] (ret_from_fork+0x14/0x3c)
       r8:00000000 r7:00000000 r6:00000000 r5:c003fa9c r4:df791d00
      
      Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: default avatarDaniel Wagner <daniel.wagner@siemens.com>
      Reviewed-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      980899da
    • Finn Thain's avatar
      m68k/mac: Fix SWIM memory resource end address · 60711b27
      Finn Thain authored
      commit 3e2816c1 upstream.
      
      The resource size is 0x2000 == end - start + 1.
      Therefore end == start + 0x2000 - 1.
      
      Cc: Laurent Vivier <lvivier@redhat.com>
      Cc: stable@vger.kernel.org # v4.14+
      Tested-by: default avatarStan Johnson <userm57@yahoo.com>
      Signed-off-by: default avatarFinn Thain <fthain@telegraphics.com.au>
      Acked-by: default avatarLaurent Vivier <lvivier@redhat.com>
      Signed-off-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      60711b27
    • Michael Schmitz's avatar
      m68k/mm: Adjust VM area to be unmapped by gap size for __iounmap() · da9ad89c
      Michael Schmitz authored
      commit 3f90f9ef upstream.
      
      If 020/030 support is enabled, get_io_area() leaves an IO_SIZE gap
      between mappings which is added to the vm_struct representing the
      mapping.  __ioremap() uses the actual requested size (after alignment),
      while __iounmap() is passed the size from the vm_struct.
      
      On 020/030, early termination descriptors are used to set up mappings of
      extent 'size', which are validated on unmapping. The unmapped gap of
      size IO_SIZE defeats the sanity check of the pmd tables, causing
      __iounmap() to loop forever on 030.
      
      On 040/060, unmapping of page table entries does not check for a valid
      mapping, so the umapping loop always completes there.
      
      Adjust size to be unmapped by the gap that had been added in the
      vm_struct prior.
      
      This fixes the hang in atari_platform_init() reported a long time ago,
      and a similar one reported by Finn recently (addressed by removing
      ioremap() use from the SWIM driver.
      
      Tested on my Falcon in 030 mode - untested but should work the same on
      040/060 (the extra page tables cleared there would never have been set
      up anyway).
      Signed-off-by: default avatarMichael Schmitz <schmitzmic@gmail.com>
      [geert: Minor commit description improvements]
      [geert: This was fixed in 2.4.23, but not in 2.5.x]
      Signed-off-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      da9ad89c
    • Siarhei Liakh's avatar
      x86: Call fixup_exception() before notify_die() in math_error() · ab693cc6
      Siarhei Liakh authored
      commit 3ae6295c upstream.
      
      fpu__drop() has an explicit fwait which under some conditions can trigger a
      fixable FPU exception while in kernel. Thus, we should attempt to fixup the
      exception first, and only call notify_die() if the fixup failed just like
      in do_general_protection(). The original call sequence incorrectly triggers
      KDB entry on debug kernels under particular FPU-intensive workloads.
      
      Andy noted, that this makes the whole conditional irq enable thing even
      more inconsistent, but fixing that it outside the scope of this.
      Signed-off-by: default avatarSiarhei Liakh <siarhei.liakh@concurrent-rt.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: default avatarAndy Lutomirski <luto@kernel.org>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: "Borislav  Petkov" <bpetkov@suse.de>
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/DM5PR11MB201156F1CAB2592B07C79A03B17D0@DM5PR11MB2011.namprd11.prod.outlook.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ab693cc6
    • Borislav Petkov's avatar
      x86/mce: Do not overwrite MCi_STATUS in mce_no_way_out() · 64d44661
      Borislav Petkov authored
      commit 1f74c8a6 upstream.
      
      mce_no_way_out() does a quick check during #MC to see whether some of
      the MCEs logged would require the kernel to panic immediately. And it
      passes a struct mce where MCi_STATUS gets written.
      
      However, after having saved a valid status value, the next iteration
      of the loop which goes over the MCA banks on the CPU, overwrites the
      valid status value because we're using struct mce as storage instead of
      a temporary variable.
      
      Which leads to MCE records with an empty status value:
      
        mce: [Hardware Error]: CPU 0: Machine Check Exception: 6 Bank 0: 0000000000000000
        mce: [Hardware Error]: RIP 10:<ffffffffbd42fbd7> {trigger_mce+0x7/0x10}
      
      In order to prevent the loss of the status register value, return
      immediately when severity is a panic one so that we can panic
      immediately with the first fatal MCE logged. This is also the intention
      of this function and not to noodle over the banks while a fatal MCE is
      already logged.
      
      Tony: read the rest of the MCA bank to populate the struct mce fully.
      Suggested-by: default avatarTony Luck <tony.luck@intel.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: <stable@vger.kernel.org>
      Link: https://lkml.kernel.org/r/20180622095428.626-8-bp@alien8.deSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      64d44661
    • Tony Luck's avatar
      x86/mce: Fix incorrect "Machine check from unknown source" message · 5b8e0868
      Tony Luck authored
      commit 40c36e27 upstream.
      
      Some injection testing resulted in the following console log:
      
        mce: [Hardware Error]: CPU 22: Machine Check Exception: f Bank 1: bd80000000100134
        mce: [Hardware Error]: RIP 10:<ffffffffc05292dd> {pmem_do_bvec+0x11d/0x330 [nd_pmem]}
        mce: [Hardware Error]: TSC c51a63035d52 ADDR 3234bc4000 MISC 88
        mce: [Hardware Error]: PROCESSOR 0:50654 TIME 1526502199 SOCKET 0 APIC 38 microcode 2000043
        mce: [Hardware Error]: Run the above through 'mcelog --ascii'
        Kernel panic - not syncing: Machine check from unknown source
      
      This confused everybody because the first line quite clearly shows
      that we found a logged error in "Bank 1", while the last line says
      "unknown source".
      
      The problem is that the Linux code doesn't do the right thing
      for a local machine check that results in a fatal error.
      
      It turns out that we know very early in the handler whether the
      machine check is fatal. The call to mce_no_way_out() has checked
      all the banks for the CPU that took the local machine check. If
      it says we must crash, we can do so right away with the right
      messages.
      
      We do scan all the banks again. This means that we might initially
      not see a problem, but during the second scan find something fatal.
      If this happens we print a slightly different message (so I can
      see if it actually every happens).
      
      [ bp: Remove unneeded severity assignment. ]
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Ashok Raj <ashok.raj@intel.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
      Cc: linux-edac <linux-edac@vger.kernel.org>
      Cc: stable@vger.kernel.org # 4.2
      Link: http://lkml.kernel.org/r/52e049a497e86fd0b71c529651def8871c804df0.1527283897.git.tony.luck@intel.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5b8e0868
    • Tony Luck's avatar
      x86/mce: Check for alternate indication of machine check recovery on Skylake · d292f33b
      Tony Luck authored
      commit 4c5717da upstream.
      
      Currently we just check the "CAPID0" register to see whether the CPU
      can recover from machine checks.
      
      But there are also some special SKUs which do not have all advanced
      RAS features, but do enable machine check recovery for use with NVDIMMs.
      
      Add a check for any of bits {8:5} in the "CAPID5" register (each
      reports some NVDIMM mode available, if any of them are set, then
      the system supports memory machine check recovery).
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
      Cc: Ashok Raj <ashok.raj@intel.com>
      Cc: stable@vger.kernel.org # 4.9
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Borislav Petkov <bp@suse.de>
      Link: https://lkml.kernel.org/r/03cbed6e99ddafb51c2eadf9a3b7c8d7a0cc204e.1527283897.git.tony.luck@intel.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d292f33b
    • Tony Luck's avatar
      x86/mce: Improve error message when kernel cannot recover · 1d1dd201
      Tony Luck authored
      commit c7d606f5 upstream.
      
      Since we added support to add recovery from some errors inside the kernel in:
      
      commit b2f9d678 ("x86/mce: Check for faults tagged in EXTABLE_CLASS_FAULT exception table entries")
      
      we have done a less than stellar job at reporting the cause of recoverable
      machine checks that occur in other parts of the kernel. The user just gets
      the unhelpful message:
      
      	mce: [Hardware Error]: Machine check: Action required: unknown MCACOD
      
      doubly unhelpful when they check the manual for the reported IA32_MSR_STATUS.MCACOD
      and see that it is listed as one of the standard recoverable values.
      
      Add an extra rule to the MCE severity table to catch this case and report it
      as:
      
      	mce: [Hardware Error]: Machine check: Data load in unrecoverable area of kernel
      
      Fixes: b2f9d678 ("x86/mce: Check for faults tagged in EXTABLE_CLASS_FAULT exception table entries")
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
      Cc: Ashok Raj <ashok.raj@intel.com>
      Cc: stable@vger.kernel.org # 4.6+
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Borislav Petkov <bp@suse.de>
      Link: https://lkml.kernel.org/r/4cc7c465150a9a48b8b9f45d0b840278e77eb9b5.1527283897.git.tony.luck@intel.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1d1dd201
    • Juergen Gross's avatar
      x86/xen: Add call of speculative_store_bypass_ht_init() to PV paths · dbb37d98
      Juergen Gross authored
      commit 74899d92 upstream.
      
      Commit:
      
        1f50ddb4 ("x86/speculation: Handle HT correctly on AMD")
      
      ... added speculative_store_bypass_ht_init() to the per-CPU initialization sequence.
      
      speculative_store_bypass_ht_init() needs to be called on each CPU for
      PV guests, too.
      Reported-by: default avatarBrian Woods <brian.woods@amd.com>
      Tested-by: default avatarBrian Woods <brian.woods@amd.com>
      Signed-off-by: default avatarJuergen Gross <jgross@suse.com>
      Cc: <stable@vger.kernel.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: boris.ostrovsky@oracle.com
      Cc: xen-devel@lists.xenproject.org
      Fixes: 1f50ddb4 ("x86/speculation: Handle HT correctly on AMD")
      Link: https://lore.kernel.org/lkml/20180621084331.21228-1-jgross@suse.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dbb37d98
    • Dan Williams's avatar
      x86/spectre_v1: Disable compiler optimizations over array_index_mask_nospec() · 3ce79716
      Dan Williams authored
      commit eab6870f upstream.
      
      Mark Rutland noticed that GCC optimization passes have the potential to elide
      necessary invocations of the array_index_mask_nospec() instruction sequence,
      so mark the asm() volatile.
      
      Mark explains:
      
      "The volatile will inhibit *some* cases where the compiler could lift the
       array_index_nospec() call out of a branch, e.g. where there are multiple
       invocations of array_index_nospec() with the same arguments:
      
              if (idx < foo) {
                      idx1 = array_idx_nospec(idx, foo)
                      do_something(idx1);
              }
      
              < some other code >
      
              if (idx < foo) {
                      idx2 = array_idx_nospec(idx, foo);
                      do_something_else(idx2);
              }
      
       ... since the compiler can determine that the two invocations yield the same
       result, and reuse the first result (likely the same register as idx was in
       originally) for the second branch, effectively re-writing the above as:
      
              if (idx < foo) {
                      idx = array_idx_nospec(idx, foo);
                      do_something(idx);
              }
      
              < some other code >
      
              if (idx < foo) {
                      do_something_else(idx);
              }
      
       ... if we don't take the first branch, then speculatively take the second, we
       lose the nospec protection.
      
       There's more info on volatile asm in the GCC docs:
      
         https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Volatile
       "
      Reported-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Acked-by: default avatarMark Rutland <mark.rutland@arm.com>
      Acked-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Acked-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Cc: <stable@vger.kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Fixes: babdde26 ("x86: Implement array_index_mask_nospec")
      Link: https://lkml.kernel.org/lkml/152838798950.14521.4893346294059739135.stgit@dwillia2-desk3.amr.corp.intel.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3ce79716
  2. 26 Jun, 2018 25 commits