1. 21 7月, 2019 40 次提交
    • C
      crypto: talitos - fix hash on SEC1. · b24c6403
      Christophe Leroy 提交于
      commit 58cdbc6d2263beb36954408522762bbe73169306 upstream.
      
      On SEC1, hash provides wrong result when performing hashing in several
      steps with input data SG list has more than one element. This was
      detected with CONFIG_CRYPTO_MANAGER_EXTRA_TESTS:
      
      [   44.185947] alg: hash: md5-talitos test failed (wrong result) on test vector 6, cfg="random: may_sleep use_finup src_divs=[<reimport>25.88%@+8063, <flush>24.19%@+9588, 28.63%@+16333, <reimport>4.60%@+6756, 16.70%@+16281] dst_divs=[71.61%@alignmask+16361, 14.36%@+7756, 14.3%@+"
      [   44.325122] alg: hash: sha1-talitos test failed (wrong result) on test vector 3, cfg="random: inplace use_final src_divs=[<flush,nosimd>16.56%@+16378, <reimport>52.0%@+16329, 21.42%@alignmask+16380, 10.2%@alignmask+16380] iv_offset=39"
      [   44.493500] alg: hash: sha224-talitos test failed (wrong result) on test vector 4, cfg="random: use_final nosimd src_divs=[<reimport>52.27%@+7401, <reimport>17.34%@+16285, <flush>17.71%@+26, 12.68%@+10644] iv_offset=43"
      [   44.673262] alg: hash: sha256-talitos test failed (wrong result) on test vector 4, cfg="random: may_sleep use_finup src_divs=[<reimport>60.6%@+12790, 17.86%@+1329, <reimport>12.64%@alignmask+16300, 8.29%@+15, 0.40%@+13506, <reimport>0.51%@+16322, <reimport>0.24%@+16339] dst_divs"
      
      This is due to two issues:
      - We have an overlap between the buffer used for copying the input
      data (SEC1 doesn't do scatter/gather) and the chained descriptor.
      - Data copy is wrong when the previous hash left less than one
      blocksize of data to hash, implying a complement of the previous
      block with a few bytes from the new request.
      
      Fix it by:
      - Moving the second descriptor after the buffer, as moving the buffer
      after the descriptor would make it more complex for other cipher
      operations (AEAD, ABLKCIPHER)
      - Skip the bytes taken from the new request to complete the previous
      one by moving the SG list forward.
      
      Fixes: 37b5e889 ("crypto: talitos - chain in buffered data for ahash on SEC1")
      Cc: stable@vger.kernel.org
      Signed-off-by: NChristophe Leroy <christophe.leroy@c-s.fr>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b24c6403
    • C
      crypto: talitos - move struct talitos_edesc into talitos.h · ff1ce8ef
      Christophe Leroy 提交于
      commit d44769e4ccb636e8238adbc151f25467a536711b upstream.
      
      Moves struct talitos_edesc into talitos.h so that it can be used
      from any place in talitos.c
      
      It will be required for next patch ("crypto: talitos - fix hash
      on SEC1")
      Signed-off-by: NChristophe Leroy <christophe.leroy@c-s.fr>
      Cc: stable@vger.kernel.org
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ff1ce8ef
    • J
      s390/qdio: don't touch the dsci in tiqdio_add_input_queues() · b578b87b
      Julian Wiedmann 提交于
      commit ac6639cd3db607d386616487902b4cc1850a7be5 upstream.
      
      Current code sets the dsci to 0x00000080. Which doesn't make any sense,
      as the indicator area is located in the _left-most_ byte.
      
      Worse: if the dsci is the _shared_ indicator, this potentially clears
      the indication of activity for a _different_ device.
      tiqdio_thinint_handler() will then have no reason to call that device's
      IRQ handler, and the device ends up stalling.
      
      Fixes: d0c9d4a8 ("[S390] qdio: set correct bit in dsci")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: NVasily Gorbik <gor@linux.ibm.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b578b87b
    • J
      s390/qdio: (re-)initialize tiqdio list entries · b1d52630
      Julian Wiedmann 提交于
      commit e54e4785cb5cb4896cf4285964aeef2125612fb2 upstream.
      
      When tiqdio_remove_input_queues() removes a queue from the tiq_list as
      part of qdio_shutdown(), it doesn't re-initialize the queue's list entry
      and the prev/next pointers go stale.
      
      If a subsequent qdio_establish() fails while sending the ESTABLISH cmd,
      it calls qdio_shutdown() again in QDIO_IRQ_STATE_ERR state and
      tiqdio_remove_input_queues() will attempt to remove the queue entry a
      second time. This dereferences the stale pointers, and bad things ensue.
      Fix this by re-initializing the list entry after removing it from the
      list.
      
      For good practice also initialize the list entry when the queue is first
      allocated, and remove the quirky checks that papered over this omission.
      Note that prior to
      commit e5218134 ("s390/qdio: fix access to uninitialized qdio_q fields"),
      these checks were bogus anyway.
      
      setup_queues_misc() clears the whole queue struct, and thus needs to
      re-init the prev/next pointers as well.
      
      Fixes: 779e6e1c ("[S390] qdio: new qdio driver.")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: NVasily Gorbik <gor@linux.ibm.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b1d52630
    • H
      s390: fix stfle zero padding · 02eb533e
      Heiko Carstens 提交于
      commit 4f18d869ffd056c7858f3d617c71345cf19be008 upstream.
      
      The stfle inline assembly returns the number of double words written
      (condition code 0) or the double words it would have written
      (condition code 3), if the memory array it got as parameter would have
      been large enough.
      
      The current stfle implementation assumes that the array is always
      large enough and clears those parts of the array that have not been
      written to with a subsequent memset call.
      
      If however the array is not large enough memset will get a negative
      length parameter, which means that memset clears memory until it gets
      an exception and the kernel crashes.
      
      To fix this simply limit the maximum length. Move also the inline
      assembly to an extra function to avoid clobbering of register 0, which
      might happen because of the added min_t invocation together with code
      instrumentation.
      
      The bug was introduced with commit 14375bc4 ("[S390] cleanup
      facility list handling") but was rather harmless, since it would only
      write to a rather large array. It became a potential problem with
      commit 3ab121ab ("[S390] kernel: Add z/VM LGR detection"). Since
      then it writes to an array with only four double words, while some
      machines already deliver three double words. As soon as machines have
      a facility bit within the fifth double a crash on IPL would happen.
      
      Fixes: 14375bc4 ("[S390] cleanup facility list handling")
      Cc: <stable@vger.kernel.org> # v2.6.37+
      Reviewed-by: NVasily Gorbik <gor@linux.ibm.com>
      Signed-off-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>
      02eb533e
    • A
      ARC: hide unused function unw_hdr_alloc · 9db91573
      Arnd Bergmann 提交于
      commit fd5de2721ea7d16e2b16c4049ac49f229551b290 upstream.
      
      As kernelci.org reports, this function is not used in
      vdk_hs38_defconfig:
      
      arch/arc/kernel/unwind.c:188:14: warning: 'unw_hdr_alloc' defined but not used [-Wunused-function]
      
      Fixes: bc79c9a7 ("ARC: dw2 unwind: Reinstante unwinding out of modules")
      Link: https://kernelci.org/build/id/5d1cae3f59b514300340c132/logs/
      Cc: stable@vger.kernel.org
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9db91573
    • T
      x86/irq: Seperate unused system vectors from spurious entry again · fc6975ee
      Thomas Gleixner 提交于
      commit f8a8fe61fec8006575699559ead88b0b833d5cad upstream
      
      Quite some time ago the interrupt entry stubs for unused vectors in the
      system vector range got removed and directly mapped to the spurious
      interrupt vector entry point.
      
      Sounds reasonable, but it's subtly broken. The spurious interrupt vector
      entry point pushes vector number 0xFF on the stack which makes the whole
      logic in __smp_spurious_interrupt() pointless.
      
      As a consequence any spurious interrupt which comes from a vector != 0xFF
      is treated as a real spurious interrupt (vector 0xFF) and not
      acknowledged. That subsequently stalls all interrupt vectors of equal and
      lower priority, which brings the system to a grinding halt.
      
      This can happen because even on 64-bit the system vector space is not
      guaranteed to be fully populated. A full compile time handling of the
      unused vectors is not possible because quite some of them are conditonally
      populated at runtime.
      
      Bring the entry stubs back, which wastes 160 bytes if all stubs are unused,
      but gains the proper handling back. There is no point to selectively spare
      some of the stubs which are known at compile time as the required code in
      the IDT management would be way larger and convoluted.
      
      Do not route the spurious entries through common_interrupt and do_IRQ() as
      the original code did. Route it to smp_spurious_interrupt() which evaluates
      the vector number and acts accordingly now that the real vector numbers are
      handed in.
      
      Fixup the pr_warn so the actual spurious vector (0xff) is clearly
      distiguished from the other vectors and also note for the vectored case
      whether it was pending in the ISR or not.
      
       "Spurious APIC interrupt (vector 0xFF) on CPU#0, should never happen."
       "Spurious interrupt vector 0xed on CPU#1. Acked."
       "Spurious interrupt vector 0xee on CPU#1. Not pending!."
      
      Fixes: 2414e021 ("x86: Avoid building unused IRQ entry stubs")
      Reported-by: NJan Kiszka <jan.kiszka@siemens.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Jan Beulich <jbeulich@suse.com>
      Link: https://lkml.kernel.org/r/20190628111440.550568228@linutronix.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      fc6975ee
    • T
      x86/irq: Handle spurious interrupt after shutdown gracefully · 9494cd39
      Thomas Gleixner 提交于
      commit b7107a67f0d125459fe41f86e8079afd1a5e0b15 upstream
      
      Since the rework of the vector management, warnings about spurious
      interrupts have been reported. Robert provided some more information and
      did an initial analysis. The following situation leads to these warnings:
      
         CPU 0                  CPU 1               IO_APIC
      
                                                    interrupt is raised
                                                    sent to CPU1
      			  Unable to handle
      			  immediately
      			  (interrupts off,
      			   deep idle delay)
         mask()
         ...
         free()
           shutdown()
           synchronize_irq()
           clear_vector()
                                do_IRQ()
                                  -> vector is clear
      
      Before the rework the vector entries of legacy interrupts were statically
      assigned and occupied precious vector space while most of them were
      unused. Due to that the above situation was handled silently because the
      vector was handled and the core handler of the assigned interrupt
      descriptor noticed that it is shut down and returned.
      
      While this has been usually observed with legacy interrupts, this situation
      is not limited to them. Any other interrupt source, e.g. MSI, can cause the
      same issue.
      
      After adding proper synchronization for level triggered interrupts, this
      can only happen for edge triggered interrupts where the IO-APIC obviously
      cannot provide information about interrupts in flight.
      
      While the spurious warning is actually harmless in this case it worries
      users and driver developers.
      
      Handle it gracefully by marking the vector entry as VECTOR_SHUTDOWN instead
      of VECTOR_UNUSED when the vector is freed up.
      
      If that above late handling happens the spurious detector will not complain
      and switch the entry to VECTOR_UNUSED. Any subsequent spurious interrupt on
      that line will trigger the spurious warning as before.
      
      Fixes: 464d1230 ("x86/vector: Switch IOAPIC to global reservation mode")
      Reported-by: NRobert Hodaszi <Robert.Hodaszi@digi.com>
      Signed-off-by: Thomas Gleixner <tglx@linutronix.de>-
      Tested-by: NRobert Hodaszi <Robert.Hodaszi@digi.com>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Link: https://lkml.kernel.org/r/20190628111440.459647741@linutronix.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      9494cd39
    • T
      x86/ioapic: Implement irq_get_irqchip_state() callback · 7897f5a4
      Thomas Gleixner 提交于
      commit dfe0cf8b51b07e56ded571e3de0a4a9382517231 upstream
      
      When an interrupt is shut down in free_irq() there might be an inflight
      interrupt pending in the IO-APIC remote IRR which is not yet serviced. That
      means the interrupt has been sent to the target CPUs local APIC, but the
      target CPU is in a state which delays the servicing.
      
      So free_irq() would proceed to free resources and to clear the vector
      because synchronize_hardirq() does not see an interrupt handler in
      progress.
      
      That can trigger a spurious interrupt warning, which is harmless and just
      confuses users, but it also can leave the remote IRR in a stale state
      because once the handler is invoked the interrupt resources might be freed
      already and therefore acknowledgement is not possible anymore.
      
      Implement the irq_get_irqchip_state() callback for the IO-APIC irq chip. The
      callback is invoked from free_irq() via __synchronize_hardirq(). Check the
      remote IRR bit of the interrupt and return 'in flight' if it is set and the
      interrupt is configured in level mode. For edge mode the remote IRR has no
      meaning.
      
      As this is only meaningful for level triggered interrupts this won't cure
      the potential spurious interrupt warning for edge triggered interrupts, but
      the edge trigger case does not result in stale hardware state. This has to
      be addressed at the vector/interrupt entry level seperately.
      
      Fixes: 464d1230 ("x86/vector: Switch IOAPIC to global reservation mode")
      Reported-by: NRobert Hodaszi <Robert.Hodaszi@digi.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Link: https://lkml.kernel.org/r/20190628111440.370295517@linutronix.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      7897f5a4
    • T
      genirq: Add optional hardware synchronization for shutdown · 6074f604
      Thomas Gleixner 提交于
      commit 62e0468650c30f0298822c580f382b16328119f6 upstream
      
      free_irq() ensures that no hardware interrupt handler is executing on a
      different CPU before actually releasing resources and deactivating the
      interrupt completely in a domain hierarchy.
      
      But that does not catch the case where the interrupt is on flight at the
      hardware level but not yet serviced by the target CPU. That creates an
      interesing race condition:
      
         CPU 0                  CPU 1               IRQ CHIP
      
                                                    interrupt is raised
                                                    sent to CPU1
      			  Unable to handle
      			  immediately
      			  (interrupts off,
      			   deep idle delay)
         mask()
         ...
         free()
           shutdown()
           synchronize_irq()
           release_resources()
                                do_IRQ()
                                  -> resources are not available
      
      That might be harmless and just trigger a spurious interrupt warning, but
      some interrupt chips might get into a wedged state.
      
      Utilize the existing irq_get_irqchip_state() callback for the
      synchronization in free_irq().
      
      synchronize_hardirq() is not using this mechanism as it might actually
      deadlock unter certain conditions, e.g. when called with interrupts
      disabled and the target CPU is the one on which the synchronization is
      invoked. synchronize_irq() uses it because that function cannot be called
      from non preemtible contexts as it might sleep.
      
      No functional change intended and according to Marc the existing GIC
      implementations where the driver supports the callback should be able
      to cope with that core change. Famous last words.
      
      Fixes: 464d1230 ("x86/vector: Switch IOAPIC to global reservation mode")
      Reported-by: NRobert Hodaszi <Robert.Hodaszi@digi.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: NMarc Zyngier <marc.zyngier@arm.com>
      Tested-by: NMarc Zyngier <marc.zyngier@arm.com>
      Link: https://lkml.kernel.org/r/20190628111440.279463375@linutronix.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      6074f604
    • T
      genirq: Fix misleading synchronize_irq() documentation · 3f10ccc2
      Thomas Gleixner 提交于
      commit 1d21f2af8571c6a6a44e7c1911780614847b0253 upstream
      
      The function might sleep, so it cannot be called from interrupt
      context. Not even with care.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Link: https://lkml.kernel.org/r/20190628111440.189241552@linutronix.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      3f10ccc2
    • T
      genirq: Delay deactivation in free_irq() · 578db1aa
      Thomas Gleixner 提交于
      commit 4001d8e8762f57d418b66e4e668601791900a1dd upstream
      
      When interrupts are shutdown, they are immediately deactivated in the
      irqdomain hierarchy. While this looks obviously correct there is a subtle
      issue:
      
      There might be an interrupt in flight when free_irq() is invoking the
      shutdown. This is properly handled at the irq descriptor / primary handler
      level, but the deactivation might completely disable resources which are
      required to acknowledge the interrupt.
      
      Split the shutdown code and deactivate the interrupt after synchronization
      in free_irq(). Fixup all other usage sites where this is not an issue to
      invoke the combined shutdown_and_deactivate() function instead.
      
      This still might be an issue if the interrupt in flight servicing is
      delayed on a remote CPU beyond the invocation of synchronize_irq(), but
      that cannot be handled at that level and needs to be handled in the
      synchronize_irq() context.
      
      Fixes: f8264e34 ("irqdomain: Introduce new interfaces to support hierarchy irqdomains")
      Reported-by: NRobert Hodaszi <Robert.Hodaszi@digi.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: NMarc Zyngier <marc.zyngier@arm.com>
      Link: https://lkml.kernel.org/r/20190628111440.098196390@linutronix.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      578db1aa
    • V
      linux/kernel.h: fix overflow for DIV_ROUND_UP_ULL · 2656ee5a
      Vinod Koul 提交于
      [ Upstream commit 8f9fab480c7a87b10bb5440b5555f370272a5d59 ]
      
      DIV_ROUND_UP_ULL adds the two arguments and then invokes
      DIV_ROUND_DOWN_ULL.  But on a 32bit system the addition of two 32 bit
      values can overflow.  DIV_ROUND_DOWN_ULL does it correctly and stashes
      the addition into a unsigned long long so cast the result to unsigned
      long long here to avoid the overflow condition.
      
      [akpm@linux-foundation.org: DIV_ROUND_UP_ULL must be an rval]
      Link: http://lkml.kernel.org/r/20190625100518.30753-1-vkoul@kernel.orgSigned-off-by: NVinod Koul <vkoul@kernel.org>
      Reviewed-by: NAndrew Morton <akpm@linux-foundation.org>
      Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      2656ee5a
    • N
      pinctrl: mediatek: Update cur_mask in mask/mask ops · 9c875e85
      Nicolas Boichat 提交于
      [ Upstream commit 9d957a959bc8c3dfe37572ac8e99affb5a885965 ]
      
      During suspend/resume, mtk_eint_mask may be called while
      wake_mask is active. For example, this happens if a wake-source
      with an active interrupt handler wakes the system:
      irq/pm.c:irq_pm_check_wakeup would disable the interrupt, so
      that it can be handled later on in the resume flow.
      
      However, this may happen before mtk_eint_do_resume is called:
      in this case, wake_mask is loaded, and cur_mask is restored
      from an older copy, re-enabling the interrupt, and causing
      an interrupt storm (especially for level interrupts).
      
      Step by step, for a line that has both wake and interrupt enabled:
       1. cur_mask[irq] = 1; wake_mask[irq] = 1; EINT_EN[irq] = 1 (interrupt
          enabled at hardware level)
       2. System suspends, resumes due to that line (at this stage EINT_EN
          == wake_mask)
       3. irq_pm_check_wakeup is called, and disables the interrupt =>
          EINT_EN[irq] = 0, but we still have cur_mask[irq] = 1
       4. mtk_eint_do_resume is called, and restores EINT_EN = cur_mask, so
          it reenables EINT_EN[irq] = 1 => interrupt storm as the driver
          is not yet ready to handle the interrupt.
      
      This patch fixes the issue in step 3, by recording all mask/unmask
      changes in cur_mask. This also avoids the need to read the current
      mask in eint_do_suspend, and we can remove mtk_eint_chip_read_mask
      function.
      
      The interrupt will be re-enabled properly later on, sometimes after
      mtk_eint_do_resume, when the driver is ready to handle it.
      
      Fixes: 58a5e1b6 ("pinctrl: mediatek: Implement wake handler and suspend resume")
      Signed-off-by: NNicolas Boichat <drinkcat@chromium.org>
      Acked-by: NSean Wang <sean.wang@kernel.org>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      9c875e85
    • E
      cpu/hotplug: Fix out-of-bounds read when setting fail state · f6e01328
      Eiichi Tsukata 提交于
      [ Upstream commit 33d4a5a7a5b4d02915d765064b2319e90a11cbde ]
      
      Setting invalid value to /sys/devices/system/cpu/cpuX/hotplug/fail
      can control `struct cpuhp_step *sp` address, results in the following
      global-out-of-bounds read.
      
      Reproducer:
      
        # echo -2 > /sys/devices/system/cpu/cpu0/hotplug/fail
      
      KASAN report:
      
        BUG: KASAN: global-out-of-bounds in write_cpuhp_fail+0x2cd/0x2e0
        Read of size 8 at addr ffffffff89734438 by task bash/1941
      
        CPU: 0 PID: 1941 Comm: bash Not tainted 5.2.0-rc6+ #31
        Call Trace:
         write_cpuhp_fail+0x2cd/0x2e0
         dev_attr_store+0x58/0x80
         sysfs_kf_write+0x13d/0x1a0
         kernfs_fop_write+0x2bc/0x460
         vfs_write+0x1e1/0x560
         ksys_write+0x126/0x250
         do_syscall_64+0xc1/0x390
         entry_SYSCALL_64_after_hwframe+0x49/0xbe
        RIP: 0033:0x7f05e4f4c970
      
        The buggy address belongs to the variable:
         cpu_hotplug_lock+0x98/0xa0
      
        Memory state around the buggy address:
         ffffffff89734300: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 00 00
         ffffffff89734380: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 00 00
        >ffffffff89734400: 00 00 00 00 fa fa fa fa 00 00 00 00 fa fa fa fa
                                                ^
         ffffffff89734480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
         ffffffff89734500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      
      Add a sanity check for the value written from user space.
      
      Fixes: 1db49484 ("smp/hotplug: Hotplug state fail injection")
      Signed-off-by: NEiichi Tsukata <devel@etsukata.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: peterz@infradead.org
      Link: https://lkml.kernel.org/r/20190627024732.31672-1-devel@etsukata.comSigned-off-by: NSasha Levin <sashal@kernel.org>
      f6e01328
    • N
      pinctrl: mediatek: Ignore interrupts that are wake only during resume · fa99487a
      Nicolas Boichat 提交于
      [ Upstream commit 35594bc7cecf3a78504b590e350570e8f4d7779e ]
      
      Before suspending, mtk-eint would set the interrupt mask to the
      one in wake_mask. However, some of these interrupts may not have a
      corresponding interrupt handler, or the interrupt may be disabled.
      
      On resume, the eint irq handler would trigger nevertheless,
      and irq/pm.c:irq_pm_check_wakeup would be called, which would
      try to call irq_disable. However, if the interrupt is not enabled
      (irqd_irq_disabled(&desc->irq_data) is true), the call does nothing,
      and the interrupt is left enabled in the eint driver.
      
      Especially for level-sensitive interrupts, this will lead to an
      interrupt storm on resume.
      
      If we detect that an interrupt is only in wake_mask, but not in
      cur_mask, we can just mask it out immediately (as mtk_eint_resume
      would do anyway at a later stage in the resume sequence, when
      restoring cur_mask).
      
      Fixes: bf22ff45 ("genirq: Avoid unnecessary low level irq function calls")
      Signed-off-by: NNicolas Boichat <drinkcat@chromium.org>
      Acked-by: NSean Wang <sean.wang@kernel.org>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      fa99487a
    • K
      HID: multitouch: Add pointstick support for ALPS Touchpad · cd2646e5
      Kai-Heng Feng 提交于
      [ Upstream commit 0a95fc733da375de0688d0f1fd3a2869a1c1d499 ]
      
      There's a new ALPS touchpad/pointstick combo device that requires
      MT_CLS_WIN_8_DUAL to make its pointsitck work as a mouse.
      
      The device can be found on HP ZBook 17 G5.
      Signed-off-by: NKai-Heng Feng <kai.heng.feng@canonical.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      cd2646e5
    • O
      HID: chicony: add another quirk for PixArt mouse · 9ea3b131
      Oleksandr Natalenko 提交于
      [ Upstream commit dcf768b0ac868630e7bdb6f2f1c9fe72788012fa ]
      
      I've spotted another Chicony PixArt mouse in the wild, which requires
      HID_QUIRK_ALWAYS_POLL quirk, otherwise it disconnects each minute.
      
      USB ID of this device is 0x04f2:0x0939.
      
      We've introduced quirks like this for other models before, so lets add
      this mouse too.
      
      Link: https://github.com/sriemer/fix-linux-mouse#usb-mouse-disconnectsreconnects-every-minute-on-linuxSigned-off-by: NOleksandr Natalenko <oleksandr@redhat.com>
      Acked-by: NSebastian Parschauer <s.parschauer@gmx.de>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      9ea3b131
    • K
      x86/boot/64: Add missing fixup_pointer() for next_early_pgt access · 94968c37
      Kirill A. Shutemov 提交于
      [ Upstream commit c1887159eb48ba40e775584cfb2a443962cf1a05 ]
      
      __startup_64() uses fixup_pointer() to access global variables in a
      position-independent fashion. Access to next_early_pgt was wrapped into the
      helper, but one instance in the 5-level paging branch was missed.
      
      GCC generates a R_X86_64_PC32 PC-relative relocation for the access which
      doesn't trigger the issue, but Clang emmits a R_X86_64_32S which leads to
      an invalid memory access and system reboot.
      
      Fixes: 187e91fe ("x86/boot/64/clang: Use fixup_pointer() to access 'next_early_pgt'")
      Signed-off-by: NKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Alexander Potapenko <glider@google.com>
      Link: https://lkml.kernel.org/r/20190620112422.29264-1-kirill.shutemov@linux.intel.comSigned-off-by: NSasha Levin <sashal@kernel.org>
      94968c37
    • K
      x86/boot/64: Fix crash if kernel image crosses page table boundary · 729d25f4
      Kirill A. Shutemov 提交于
      [ Upstream commit 81c7ed296dcd02bc0b4488246d040e03e633737a ]
      
      A kernel which boots in 5-level paging mode crashes in a small percentage
      of cases if KASLR is enabled.
      
      This issue was tracked down to the case when the kernel image unpacks in a
      way that it crosses an 1G boundary. The crash is caused by an overrun of
      the PMD page table in __startup_64() and corruption of P4D page table
      allocated next to it. This particular issue is not visible with 4-level
      paging as P4D page tables are not used.
      
      But the P4D and the PUD calculation have similar problems.
      
      The PMD index calculation is wrong due to operator precedence, which fails
      to confine the PMDs in the PMD array on wrap around.
      
      The P4D calculation for 5-level paging and the PUD calculation calculate
      the first index correctly, but then blindly increment it which causes the
      same issue when a kernel image is located across a 512G and for 5-level
      paging across a 46T boundary.
      
      This wrap around mishandling was introduced when these parts moved from
      assembly to C.
      
      Restore it to the correct behaviour.
      
      Fixes: c88d7150 ("x86/boot/64: Rewrite startup_64() in C")
      Signed-off-by: NKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: https://lkml.kernel.org/r/20190620112345.28833-1-kirill.shutemov@linux.intel.comSigned-off-by: NSasha Levin <sashal@kernel.org>
      729d25f4
    • M
      dm verity: use message limit for data block corruption message · 13684714
      Milan Broz 提交于
      [ Upstream commit 2eba4e640b2c4161e31ae20090a53ee02a518657 ]
      
      DM verity should also use DMERR_LIMIT to limit repeat data block
      corruption messages.
      Signed-off-by: NMilan Broz <gmazyland@gmail.com>
      Signed-off-by: NMike Snitzer <snitzer@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      13684714
    • J
      dm table: don't copy from a NULL pointer in realloc_argv() · 042be786
      Jerome Marchand 提交于
      [ Upstream commit a0651926553cfe7992166432e418987760882652 ]
      
      For the first call to realloc_argv() in dm_split_args(), old_argv is
      NULL and size is zero. Then memcpy is called, with the NULL old_argv
      as the source argument and a zero size argument. AFAIK, this is
      undefined behavior and generates the following warning when compiled
      with UBSAN on ppc64le:
      
      In file included from ./arch/powerpc/include/asm/paca.h:19,
                       from ./arch/powerpc/include/asm/current.h:16,
                       from ./include/linux/sched.h:12,
                       from ./include/linux/kthread.h:6,
                       from drivers/md/dm-core.h:12,
                       from drivers/md/dm-table.c:8:
      In function 'memcpy',
          inlined from 'realloc_argv' at drivers/md/dm-table.c:565:3,
          inlined from 'dm_split_args' at drivers/md/dm-table.c:588:9:
      ./include/linux/string.h:345:9: error: argument 2 null where non-null expected [-Werror=nonnull]
        return __builtin_memcpy(p, q, size);
               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
      drivers/md/dm-table.c: In function 'dm_split_args':
      ./include/linux/string.h:345:9: note: in a call to built-in function '__builtin_memcpy'
      Signed-off-by: NJerome Marchand <jmarchan@redhat.com>
      Signed-off-by: NMike Snitzer <snitzer@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      042be786
    • P
      pinctrl: mcp23s08: Fix add_data and irqchip_add_nested call order · 0fc080bc
      Phil Reid 提交于
      [ Upstream commit 6dbc6e6f58556369bf999cd7d9793586f1b0e4b4 ]
      
      Currently probing of the mcp23s08 results in an error message
      "detected irqchip that is shared with multiple gpiochips:
      please fix the driver"
      
      This is due to the following:
      
      Call to mcp23s08_irqchip_setup() with call hierarchy:
      mcp23s08_irqchip_setup()
        gpiochip_irqchip_add_nested()
          gpiochip_irqchip_add_key()
            gpiochip_set_irq_hooks()
      
      Call to devm_gpiochip_add_data() with call hierarchy:
      devm_gpiochip_add_data()
        gpiochip_add_data_with_key()
          gpiochip_add_irqchip()
            gpiochip_set_irq_hooks()
      
      The gpiochip_add_irqchip() returns immediately if there isn't a irqchip
      but we added a irqchip due to the previous mcp23s08_irqchip_setup()
      call. So it calls gpiochip_set_irq_hooks() a second time.
      
      Fix this by moving the call to devm_gpiochip_add_data before
      the call to mcp23s08_irqchip_setup
      
      Fixes: 02e389e6 ("pinctrl: mcp23s08: fix irq setup order")
      Suggested-by: NMarco Felsch <m.felsch@pengutronix.de>
      Signed-off-by: NPhil Reid <preid@electromag.com.au>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      0fc080bc
    • S
      ARM: dts: imx6ul: fix PWM[1-4] interrupts · 00640eb0
      Sébastien Szymanski 提交于
      [ Upstream commit 3cf10132ac8d536565f2c02f60a3aeb315863a52 ]
      
      According to the i.MX6UL/L RM, table 3.1 "ARM Cortex A7 domain interrupt
      summary", the interrupts for the PWM[1-4] go from 83 to 86.
      
      Fixes: b9901fe8 ("ARM: dts: imx6ul: add pwm[1-4] nodes")
      Signed-off-by: NSébastien Szymanski <sebastien.szymanski@armadeus.com>
      Reviewed-by: NFabio Estevam <festevam@gmail.com>
      Signed-off-by: NShawn Guo <shawnguo@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      00640eb0
    • S
      sis900: fix TX completion · a8cc2a2c
      Sergej Benilov 提交于
      [ Upstream commit 8ac8a01092b2added0749ef937037bf1912e13e3 ]
      
      Since commit 605ad7f1 "tcp: refine TSO autosizing",
      outbound throughput is dramatically reduced for some connections, as sis900
      is doing TX completion within idle states only.
      
      Make TX completion happen after every transmitted packet.
      
      Test:
      netperf
      
      before patch:
      > netperf -H remote -l -2000000 -- -s 1000000
      MIGRATED TCP STREAM TEST from 0.0.0.0 () port 0 AF_INET to 95.223.112.76 () port 0 AF_INET : demo
      Recv   Send    Send
      Socket Socket  Message  Elapsed
      Size   Size    Size     Time     Throughput
      bytes  bytes   bytes    secs.    10^6bits/sec
      
       87380 327680 327680    253.44      0.06
      
      after patch:
      > netperf -H remote -l -10000000 -- -s 1000000
      MIGRATED TCP STREAM TEST from 0.0.0.0 () port 0 AF_INET to 95.223.112.76 () port 0 AF_INET : demo
      Recv   Send    Send
      Socket Socket  Message  Elapsed
      Size   Size    Size     Time     Throughput
      bytes  bytes   bytes    secs.    10^6bits/sec
      
       87380 327680 327680    5.38       14.89
      
      Thx to Dave Miller and Eric Dumazet for helpful hints
      Signed-off-by: NSergej Benilov <sergej.benilov@googlemail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      a8cc2a2c
    • T
      ppp: mppe: Add softdep to arc4 · 3232bccd
      Takashi Iwai 提交于
      [ Upstream commit aad1dcc4f011ea409850e040363dff1e59aa4175 ]
      
      The arc4 crypto is mandatory at ppp_mppe probe time, so let's put a
      softdep line, so that the corresponding module gets prepared
      gracefully.  Without this, a simple inclusion to initrd via dracut
      failed due to the missing dependency, for example.
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      3232bccd
    • P
      be2net: fix link failure after ethtool offline test · 5ec7753c
      Petr Oros 提交于
      [ Upstream commit 2e5db6eb3c23e5dc8171eb8f6af7a97ef9fcf3a9 ]
      
      Certain cards in conjunction with certain switches need a little more
      time for link setup that results in ethtool link test failure after
      offline test. Patch adds a loop that waits for a link setup finish.
      
      Changes in v2:
      - added fixes header
      
      Fixes: 4276e47e ("be2net: Add link test to list of ethtool self tests.")
      Signed-off-by: NPetr Oros <poros@redhat.com>
      Reviewed-by: NIvan Vecera <ivecera@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      5ec7753c
    • C
      x86/apic: Fix integer overflow on 10 bit left shift of cpu_khz · 2a6ee369
      Colin Ian King 提交于
      [ Upstream commit ea136a112d89bade596314a1ae49f748902f4727 ]
      
      The left shift of unsigned int cpu_khz will overflow for large values of
      cpu_khz, so cast it to a long long before shifting it to avoid overvlow.
      For example, this can happen when cpu_khz is 4194305, i.e. ~4.2 GHz.
      
      Addresses-Coverity: ("Unintentional integer overflow")
      Fixes: 8c3ba8d0 ("x86, apic: ack all pending irqs when crashed/on kexec")
      Signed-off-by: NColin Ian King <colin.king@canonical.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: "H . Peter Anvin" <hpa@zytor.com>
      Cc: kernel-janitors@vger.kernel.org
      Link: https://lkml.kernel.org/r/20190619181446.13635-1-colin.king@canonical.comSigned-off-by: NSasha Levin <sashal@kernel.org>
      2a6ee369
    • D
      afs: Fix uninitialised spinlock afs_volume::cb_break_lock · fdfff855
      David Howells 提交于
      [ Upstream commit 90fa9b64523a645a97edc0bdcf2d74759957eeee ]
      
      Fix the cb_break_lock spinlock in afs_volume struct by initialising it when
      the volume record is allocated.
      
      Also rename the lock to cb_v_break_lock to distinguish it from the lock of
      the same name in the afs_server struct.
      
      Without this, the following trace may be observed when a volume-break
      callback is received:
      
        INFO: trying to register non-static key.
        the code is fine but needs lockdep annotation.
        turning off the locking correctness validator.
        CPU: 2 PID: 50 Comm: kworker/2:1 Not tainted 5.2.0-rc1-fscache+ #3045
        Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014
        Workqueue: afs SRXAFSCB_CallBack
        Call Trace:
         dump_stack+0x67/0x8e
         register_lock_class+0x23b/0x421
         ? check_usage_forwards+0x13c/0x13c
         __lock_acquire+0x89/0xf73
         lock_acquire+0x13b/0x166
         ? afs_break_callbacks+0x1b2/0x3dd
         _raw_write_lock+0x2c/0x36
         ? afs_break_callbacks+0x1b2/0x3dd
         afs_break_callbacks+0x1b2/0x3dd
         ? trace_event_raw_event_afs_server+0x61/0xac
         SRXAFSCB_CallBack+0x11f/0x16c
         process_one_work+0x2c5/0x4ee
         ? worker_thread+0x234/0x2ac
         worker_thread+0x1d8/0x2ac
         ? cancel_delayed_work_sync+0xf/0xf
         kthread+0x11f/0x127
         ? kthread_park+0x76/0x76
         ret_from_fork+0x24/0x30
      
      Fixes: 68251f0a ("afs: Fix whole-volume callback handling")
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      fdfff855
    • A
      ARM: omap2: remove incorrect __init annotation · d47f06ab
      Arnd Bergmann 提交于
      [ Upstream commit 27e23d8975270df6999f8b5b3156fc0c04927451 ]
      
      omap3xxx_prm_enable_io_wakeup() is marked __init, but its caller is not, so
      we get a warning with clang-8:
      
      WARNING: vmlinux.o(.text+0x343c8): Section mismatch in reference from the function omap3xxx_prm_late_init() to the function .init.text:omap3xxx_prm_enable_io_wakeup()
      The function omap3xxx_prm_late_init() references
      the function __init omap3xxx_prm_enable_io_wakeup().
      This is often because omap3xxx_prm_late_init lacks a __init
      annotation or the annotation of omap3xxx_prm_enable_io_wakeup is wrong.
      
      When building with gcc, omap3xxx_prm_enable_io_wakeup() is always
      inlined, so we never noticed in the past.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Reviewed-by: NNathan Chancellor <natechancellor@gmail.com>
      Acked-by: NTony Lindgren <tony@atomide.com>
      Reviewed-by: NAndrew Murray <andrew.murray@arm.com>
      Signed-off-by: NOlof Johansson <olof@lixom.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      d47f06ab
    • L
      ARM: dts: gemini Fix up DNS-313 compatible string · 5d3c4553
      Linus Walleij 提交于
      [ Upstream commit 36558020128b1a48b7bddd5792ee70e3f64b04b0 ]
      
      It's a simple typo in the DNS file, which was pretty serious.
      No scripts were working properly. Fix it up.
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      5d3c4553
    • P
      perf/core: Fix perf_sample_regs_user() mm check · afda29dc
      Peter Zijlstra 提交于
      [ Upstream commit 085ebfe937d7a7a5df1729f35a12d6d655fea68c ]
      
      perf_sample_regs_user() uses 'current->mm' to test for the presence of
      userspace, but this is insufficient, consider use_mm().
      
      A better test is: '!(current->flags & PF_KTHREAD)', exec() clears
      PF_KTHREAD after it sets the new ->mm but before it drops to userspace
      for the first time.
      
      Possibly obsoletes: bf05fc25 ("powerpc/perf: Fix oops when kthread execs user process")
      Reported-by: NRavi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
      Reported-by: NYoung Xiao <92siuyang@gmail.com>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Acked-by: NWill Deacon <will.deacon@arm.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Fixes: 4018994f ("perf: Add ability to attach user level registers dump to sample")
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      afda29dc
    • H
      efi/bgrt: Drop BGRT status field reserved bits check · 627fdcc9
      Hans de Goede 提交于
      [ Upstream commit a483fcab38b43fb34a7f12ab1daadd3907f150e2 ]
      
      Starting with ACPI 6.2 bits 1 and 2 of the BGRT status field are no longer
      reserved. These bits are now used to indicate if the image needs to be
      rotated before being displayed.
      
      The first device using these bits has now shown up (the GPD MicroPC) and
      the reserved bits check causes us to reject the valid BGRT table on this
      device.
      
      Rather then changing the reserved bits check, allowing only the 2 new bits,
      instead just completely remove it so that we do not end up with a similar
      problem when more bits are added in the future.
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      627fdcc9
    • T
      clk: ti: clkctrl: Fix returning uninitialized data · cf4deb2d
      Tony Lindgren 提交于
      [ Upstream commit 41b3588dba6ef4b7995735a97e47ff0aeea6c276 ]
      
      If we do a clk_get() for a clock that does not exists, we have
      _ti_omap4_clkctrl_xlate() return uninitialized data if no match
      is found. This can be seen in some cases with SLAB_DEBUG enabled:
      
      Unable to handle kernel paging request at virtual address 5a5a5a5a
      ...
      clk_hw_create_clk.part.33
      sysc_notifier_call
      notifier_call_chain
      blocking_notifier_call_chain
      device_add
      
      Let's fix this by setting a found flag only when we find a match.
      Reported-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Fixes: 88a17252 ("clk: ti: add support for clkctrl clocks")
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      Tested-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
      Tested-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Signed-off-by: NStephen Boyd <sboyd@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      cf4deb2d
    • H
      irqchip/gic-v3-its: Fix command queue pointer comparison bug · ff232a47
      Heyi Guo 提交于
      [ Upstream commit a050fa5476d418fc16b25abe168b3d38ba11e13c ]
      
      When we run several VMs with PCI passthrough and GICv4 enabled, not
      pinning vCPUs, we will occasionally see below warnings in dmesg:
      
      ITS queue timeout (65440 65504 480)
      ITS cmd its_build_vmovp_cmd failed
      
      The reason for the above issue is that in BUILD_SINGLE_CMD_FUNC:
      1. Post the write command.
      2. Release the lock.
      3. Start to read GITS_CREADR to get the reader pointer.
      4. Compare the reader pointer to the target pointer.
      5. If reader pointer does not reach the target, sleep 1us and continue
      to try.
      
      If we have several processors running the above concurrently, other
      CPUs will post write commands while the 1st CPU is waiting the
      completion. So we may have below issue:
      
      phase 1:
      ---rd_idx-----from_idx-----to_idx--0---------
      
      wait 1us:
      
      phase 2:
      --------------from_idx-----to_idx--0-rd_idx--
      
      That is the rd_idx may fly ahead of to_idx, and if in case to_idx is
      near the wrap point, rd_idx will wrap around. So the below condition
      will not be met even after 1s:
      
      if (from_idx < to_idx && rd_idx >= to_idx)
      
      There is another theoretical issue. For a slow and busy ITS, the
      initial rd_idx may fall behind from_idx a lot, just as below:
      
      ---rd_idx---0--from_idx-----to_idx-----------
      
      This will cause the wait function exit too early.
      
      Actually, it does not make much sense to use from_idx to judge if
      to_idx is wrapped, but we need a initial rd_idx when lock is still
      acquired, and it can be used to judge whether to_idx is wrapped and
      the current rd_idx is wrapped.
      
      We switch to a method of calculating the delta of two adjacent reads
      and accumulating it to get the sum, so that we can get the real rd_idx
      from the wrapped value even when the queue is almost full.
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Signed-off-by: NHeyi Guo <guoheyi@huawei.com>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      ff232a47
    • S
      firmware: improve LSM/IMA security behaviour · 244db544
      Sven Van Asbroeck 提交于
      commit 2472d64af2d3561954e2f05365a67692bb852f2a upstream.
      
      The firmware loader queries if LSM/IMA permits it to load firmware
      via the sysfs fallback. Unfortunately, the code does the opposite:
      it expressly permits sysfs fw loading if security_kernel_load_data(
      LOADING_FIRMWARE) returns -EACCES. This happens because a
      zero-on-success return value is cast to a bool that's true on success.
      
      Fix the return value handling so we get the correct behaviour.
      
      Fixes: 6e852651 ("firmware: add call to LSM hook before firmware sysfs fallback")
      Cc: Stable <stable@vger.kernel.org>
      Cc: Mimi Zohar <zohar@linux.vnet.ibm.com>
      Cc: Kees Cook <keescook@chromium.org>
      To: Luis Chamberlain <mcgrof@kernel.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: "Rafael J. Wysocki" <rafael@kernel.org>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NSven Van Asbroeck <TheSven73@gmail.com>
      Reviewed-by: NMimi Zohar <zohar@linux.ibm.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      244db544
    • J
      drivers: base: cacheinfo: Ensure cpu hotplug work is done before Intel RDT · 079d7f16
      James Morse 提交于
      commit 83b44fe343b5abfcb1b2261289bd0cfcfcfd60a8 upstream.
      
      The cacheinfo structures are alloced/freed by cpu online/offline
      callbacks. Originally these were only used by sysfs to expose the
      cache topology to user space. Without any in-kernel dependencies
      CPUHP_AP_ONLINE_DYN was an appropriate choice.
      
      resctrl has started using these structures to identify CPUs that
      share a cache. It updates its 'domain' structures from cpu
      online/offline callbacks. These depend on the cacheinfo structures
      (resctrl_online_cpu()->domain_add_cpu()->get_cache_id()->
       get_cpu_cacheinfo()).
      These also run as CPUHP_AP_ONLINE_DYN.
      
      Now that there is an in-kernel dependency, move the cacheinfo
      work earlier so we know its done before resctrl's CPUHP_AP_ONLINE_DYN
      work runs.
      
      Fixes: 2264d9c7 ("x86/intel_rdt: Build structures for each resource based on cache topology")
      Cc: <stable@vger.kernel.org>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: Reinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJames Morse <james.morse@arm.com>
      Link: https://lore.kernel.org/r/20190624173656.202407-1-james.morse@arm.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      079d7f16
    • M
      nilfs2: do not use unexported cpu_to_le32()/le32_to_cpu() in uapi header · 68048dce
      Masahiro Yamada 提交于
      commit c32cc30c0544f13982ee0185d55f4910319b1a79 upstream.
      
      cpu_to_le32/le32_to_cpu is defined in include/linux/byteorder/generic.h,
      which is not exported to user-space.
      
      UAPI headers must use the ones prefixed with double-underscore.
      
      Detected by compile-testing exported headers:
      
        include/linux/nilfs2_ondisk.h: In function `nilfs_checkpoint_set_snapshot':
        include/linux/nilfs2_ondisk.h:536:17: error: implicit declaration of function `cpu_to_le32' [-Werror=implicit-function-declaration]
          cp->cp_flags = cpu_to_le32(le32_to_cpu(cp->cp_flags) |  \
                         ^
        include/linux/nilfs2_ondisk.h:552:1: note: in expansion of macro `NILFS_CHECKPOINT_FNS'
         NILFS_CHECKPOINT_FNS(SNAPSHOT, snapshot)
         ^~~~~~~~~~~~~~~~~~~~
        include/linux/nilfs2_ondisk.h:536:29: error: implicit declaration of function `le32_to_cpu' [-Werror=implicit-function-declaration]
          cp->cp_flags = cpu_to_le32(le32_to_cpu(cp->cp_flags) |  \
                                     ^
        include/linux/nilfs2_ondisk.h:552:1: note: in expansion of macro `NILFS_CHECKPOINT_FNS'
         NILFS_CHECKPOINT_FNS(SNAPSHOT, snapshot)
         ^~~~~~~~~~~~~~~~~~~~
        include/linux/nilfs2_ondisk.h: In function `nilfs_segment_usage_set_clean':
        include/linux/nilfs2_ondisk.h:622:19: error: implicit declaration of function `cpu_to_le64' [-Werror=implicit-function-declaration]
          su->su_lastmod = cpu_to_le64(0);
                           ^~~~~~~~~~~
      
      Link: http://lkml.kernel.org/r/20190605053006.14332-1-yamada.masahiro@socionext.com
      Fixes: e63e88bc ("nilfs2: move ioctl interface and disk layout to uapi separately")
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: NRyusuke Konishi <konishi.ryusuke@gmail.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Greg KH <gregkh@linuxfoundation.org>
      Cc: Joe Perches <joe@perches.com>
      Cc: <stable@vger.kernel.org>	[4.9+]
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      68048dce
    • C
      Input: synaptics - enable SMBUS on T480 thinkpad trackpad · 86859ef1
      Cole Rogers 提交于
      commit abbe3acd7d72ab4633ade6bd24e8306b67e0add3 upstream.
      
      Thinkpad t480 laptops had some touchpad features disabled, resulting in the
      loss of pinch to activities in GNOME, on wayland, and other touch gestures
      being slower. This patch adds the touchpad of the t480 to the smbus_pnp_ids
      whitelist to enable the extra features. In my testing this does not break
      suspend (on fedora, with wayland, and GNOME, using the rc-6 kernel), while
      also fixing the feature on a T480.
      Signed-off-by: NCole Rogers <colerogers@disroot.org>
      Acked-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      86859ef1
    • K
      e1000e: start network tx queue only when link is up · 438a3dc6
      Konstantin Khlebnikov 提交于
      commit d17ba0f616a08f597d9348c372d89b8c0405ccf3 upstream.
      
      Driver does not want to keep packets in Tx queue when link is lost.
      But present code only reset NIC to flush them, but does not prevent
      queuing new packets. Moreover reset sequence itself could generate
      new packets via netconsole and NIC falls into endless reset loop.
      
      This patch wakes Tx queue only when NIC is ready to send packets.
      
      This is proper fix for problem addressed by commit 0f9e980bf5ee
      ("e1000e: fix cyclic resets at link up with active tx").
      Signed-off-by: NKonstantin Khlebnikov <khlebnikov@yandex-team.ru>
      Suggested-by: NAlexander Duyck <alexander.duyck@gmail.com>
      Tested-by: NJoseph Yasi <joe.yasi@gmail.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Tested-by: NOleksandr Natalenko <oleksandr@redhat.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      438a3dc6