1. 03 Jul, 2018 16 commits
    • Geert Uytterhoeven's avatar
      lib/vsprintf: Remove atomic-unsafe support for %pCr · ec7bea37
      Geert Uytterhoeven authored
      commit 666902e42fd8344b923c02dc5b0f37948ff4f225 upstream.
      
      "%pCr" formats the current rate of a clock, and calls clk_get_rate().
      The latter obtains a mutex, hence it must not be called from atomic
      context.
      
      Remove support for this rarely-used format, as vsprintf() (and e.g.
      printk()) must be callable from any context.
      
      Any remaining out-of-tree users will start seeing the clock's name
      printed instead of its rate.
      Reported-by: default avatarJia-Ju Bai <baijiaju1990@gmail.com>
      Fixes: 900cca29 ("lib/vsprintf: add %pC{,n,r} format specifiers for clocks")
      Link: http://lkml.kernel.org/r/1527845302-12159-5-git-send-email-geert+renesas@glider.be
      To: Jia-Ju Bai <baijiaju1990@gmail.com>
      To: Jonathan Corbet <corbet@lwn.net>
      To: Michael Turquette <mturquette@baylibre.com>
      To: Stephen Boyd <sboyd@kernel.org>
      To: Zhang Rui <rui.zhang@intel.com>
      To: Eduardo Valentin <edubezval@gmail.com>
      To: Eric Anholt <eric@anholt.net>
      To: Stefan Wahren <stefan.wahren@i2se.com>
      To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
      Cc: Petr Mladek <pmladek@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: linux-doc@vger.kernel.org
      Cc: linux-clk@vger.kernel.org
      Cc: linux-pm@vger.kernel.org
      Cc: linux-serial@vger.kernel.org
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-renesas-soc@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Cc: Geert Uytterhoeven <geert+renesas@glider.be>
      Cc: stable@vger.kernel.org # 4.1+
      Signed-off-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: default avatarPetr Mladek <pmladek@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ec7bea37
    • Geert Uytterhoeven's avatar
      clk: renesas: cpg-mssr: Stop using printk format %pCr · 676b002f
      Geert Uytterhoeven authored
      commit ef4b0be62641d296cf4c0ad8f75ab83ab066ed51 upstream.
      
      Printk format "%pCr" will be removed soon, as clk_get_rate() must not be
      called in atomic context.
      
      Replace it by open-coding the operation.  This is safe here, as the code
      runs in task context.
      
      Link: http://lkml.kernel.org/r/1527845302-12159-2-git-send-email-geert+renesas@glider.be
      To: Jia-Ju Bai <baijiaju1990@gmail.com>
      To: Jonathan Corbet <corbet@lwn.net>
      To: Michael Turquette <mturquette@baylibre.com>
      To: Stephen Boyd <sboyd@kernel.org>
      To: Zhang Rui <rui.zhang@intel.com>
      To: Eduardo Valentin <edubezval@gmail.com>
      To: Eric Anholt <eric@anholt.net>
      To: Stefan Wahren <stefan.wahren@i2se.com>
      To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
      Cc: Petr Mladek <pmladek@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: linux-doc@vger.kernel.org
      Cc: linux-clk@vger.kernel.org
      Cc: linux-pm@vger.kernel.org
      Cc: linux-serial@vger.kernel.org
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-renesas-soc@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Cc: Geert Uytterhoeven <geert+renesas@glider.be>
      Cc: stable@vger.kernel.org # 4.5+
      Signed-off-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Acked-by: default avatarStephen Boyd <sboyd@kernel.org>
      Signed-off-by: default avatarPetr Mladek <pmladek@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      676b002f
    • Alexander Sverdlin's avatar
      ASoC: cirrus: i2s: Fix {TX|RX}LinCtrlData setup · a879f6c2
      Alexander Sverdlin authored
      commit 5d302ed3cc80564fb835bed5fdba1e1250ecc9e5 upstream.
      
      According to "EP93xx User’s Guide", I2STXLinCtrlData and I2SRXLinCtrlData
      registers actually have different format. The only currently used bit
      (Left_Right_Justify) has different position. Fix this and simplify the
      whole setup taking into account the fact that both registers have zero
      default value.
      
      The practical effect of the above is repaired SND_SOC_DAIFMT_RIGHT_J
      support (currently unused).
      Signed-off-by: default avatarAlexander Sverdlin <alexander.sverdlin@gmail.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a879f6c2
    • Alexander Sverdlin's avatar
      ASoC: cirrus: i2s: Fix LRCLK configuration · d6aa7326
      Alexander Sverdlin authored
      commit 2d534113be9a2aa532a1ae127a57e83558aed358 upstream.
      
      The bit responsible for LRCLK polarity is i2s_tlrs (0), not i2s_trel (2)
      (refer to "EP93xx User's Guide").
      
      Previously card drivers which specified SND_SOC_DAIFMT_NB_IF actually got
      SND_SOC_DAIFMT_NB_NF, an adaptation is necessary to retain the old
      behavior.
      Signed-off-by: default avatarAlexander Sverdlin <alexander.sverdlin@gmail.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d6aa7326
    • Srinivas Kandagatla's avatar
      ASoC: dapm: delete dapm_kcontrol_data paths list before freeing it · 1a1b2790
      Srinivas Kandagatla authored
      commit ff2faf1289c1f81b5b26b9451dd1c2006aac8db8 upstream.
      
      dapm_kcontrol_data is freed as part of dapm_kcontrol_free(), leaving the
      paths pointer dangling in the list.
      
      This leads to system crash when we try to unload and reload sound card.
      I hit this bug during ADSP crash/reboot test case on Dragon board DB410c.
      
      Without this patch, on SLAB Poisoning enabled build, kernel crashes with
      "BUG kmalloc-128 (Tainted: G        W        ): Poison overwritten"
      Signed-off-by: default avatarSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1a1b2790
    • Ingo Flaschberger's avatar
      1wire: family module autoload fails because of upper/lower case mismatch. · cf05568c
      Ingo Flaschberger authored
      commit 065c09563c872e52813a17218c52cd642be1dca6 upstream.
      
      1wire family module autoload fails because of upper/lower
        case mismatch.
      Signed-off-by: default avatarIngo Flaschberger <ingo.flaschberger@gmail.com>
      Acked-by: default avatarEvgeniy Polyakov <zbr@ioremap.net>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cf05568c
    • Maxim Moseychuk's avatar
      usb: do not reset if a low-speed or full-speed device timed out · 55365ad7
      Maxim Moseychuk authored
      commit 6e01827ed93947895680fbdad68c072a0f4e2450 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>
      55365ad7
    • Eric W. Biederman's avatar
      signal/xtensa: Consistenly use SIGBUS in do_unaligned_user · c82ccd71
      Eric W. Biederman authored
      commit 7de712ccc096b81d23cc0a941cd9b8cb3956605d 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>
      c82ccd71
    • Daniel Wagner's avatar
      serial: sh-sci: Use spin_{try}lock_irqsave instead of open coding version · d9c202b2
      Daniel Wagner authored
      commit 8afb1d2c12163f77777f84616a8e9444d0050ebe 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>
      d9c202b2
    • Michael Schmitz's avatar
      m68k/mm: Adjust VM area to be unmapped by gap size for __iounmap() · 5692dcf9
      Michael Schmitz authored
      commit 3f90f9ef2dda316d64e420d5d51ba369587ccc55 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>
      5692dcf9
    • Siarhei Liakh's avatar
      x86: Call fixup_exception() before notify_die() in math_error() · 7a68dcdc
      Siarhei Liakh authored
      commit 3ae6295ccb7cf6d344908209701badbbbb503e40 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>
      7a68dcdc
    • Borislav Petkov's avatar
      x86/mce: Do not overwrite MCi_STATUS in mce_no_way_out() · 5a48f608
      Borislav Petkov authored
      commit 1f74c8a64798e2c488f86efc97e308b85fb7d7aa 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>
      5a48f608
    • Tony Luck's avatar
      x86/mce: Fix incorrect "Machine check from unknown source" message · c267eaac
      Tony Luck authored
      commit 40c36e2741d7fe1e66d6ec55477ba5fd19c9c5d2 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>
      c267eaac
    • Tony Luck's avatar
      x86/mce: Check for alternate indication of machine check recovery on Skylake · e7905a78
      Tony Luck authored
      commit 4c5717da1d021cf368eabb3cb1adcaead56c0d1e 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>
      e7905a78
    • Tony Luck's avatar
      x86/mce: Improve error message when kernel cannot recover · b4eb80a7
      Tony Luck authored
      commit c7d606f560e4c698884697fef503e4abacdd8c25 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>
      b4eb80a7
    • Dan Williams's avatar
      x86/spectre_v1: Disable compiler optimizations over array_index_mask_nospec() · 995cddcc
      Dan Williams authored
      commit eab6870fee877258122a042bfd99ee7908c40280 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>
      995cddcc
  2. 26 Jun, 2018 24 commits