1. 26 Jul, 2019 31 commits
  2. 21 Jul, 2019 9 commits
    • Greg Kroah-Hartman's avatar
      Linux 5.1.19 · 0d4f1b2a
      Greg Kroah-Hartman authored
      0d4f1b2a
    • Jiri Slaby's avatar
      x86/entry/32: Fix ENDPROC of common_spurious · 0e921583
      Jiri Slaby authored
      [ Upstream commit 1cbec37b ]
      
      common_spurious is currently ENDed erroneously. common_interrupt is used
      in its ENDPROC. So fix this mistake.
      
      Found by my asm macros rewrite patchset.
      
      Fixes: f8a8fe61 ("x86/irq: Seperate unused system vectors from spurious entry again")
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Link: https://lkml.kernel.org/r/20190709063402.19847-1-jslaby@suse.czSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      0e921583
    • Haren Myneni's avatar
      crypto/NX: Set receive window credits to max number of CRBs in RxFIFO · 845912c3
      Haren Myneni authored
      commit e52d484d upstream.
      
      System gets checkstop if RxFIFO overruns with more requests than the
      maximum possible number of CRBs in FIFO at the same time. The max number
      of requests per window is controlled by window credits. So find max
      CRBs from FIFO size and set it to receive window credits.
      
      Fixes: b0d6c9ba ("crypto/nx: Add P9 NX support for 842 compression engine")
      CC: stable@vger.kernel.org # v4.14+
      Signed-off-by: default avatarHaren Myneni <haren@us.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      845912c3
    • Christophe Leroy's avatar
      crypto: talitos - fix hash on SEC1. · 5b7e0364
      Christophe Leroy authored
      commit 58cdbc6d 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: default avatarChristophe Leroy <christophe.leroy@c-s.fr>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5b7e0364
    • Christophe Leroy's avatar
      crypto: talitos - move struct talitos_edesc into talitos.h · 5da29258
      Christophe Leroy authored
      commit d44769e4 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: default avatarChristophe Leroy <christophe.leroy@c-s.fr>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5da29258
    • Julian Wiedmann's avatar
      s390/qdio: don't touch the dsci in tiqdio_add_input_queues() · 9ca71f3d
      Julian Wiedmann authored
      commit ac6639cd 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: default avatarJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: default avatarVasily Gorbik <gor@linux.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9ca71f3d
    • Julian Wiedmann's avatar
      s390/qdio: (re-)initialize tiqdio list entries · 1f5dcaa9
      Julian Wiedmann authored
      commit e54e4785 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: default avatarJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: default avatarVasily Gorbik <gor@linux.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1f5dcaa9
    • Heiko Carstens's avatar
      s390: fix stfle zero padding · d6e7f5e8
      Heiko Carstens authored
      commit 4f18d869 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: default avatarVasily Gorbik <gor@linux.ibm.com>
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: default avatarVasily Gorbik <gor@linux.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d6e7f5e8
    • Arnd Bergmann's avatar
      ARC: hide unused function unw_hdr_alloc · d6d65a2f
      Arnd Bergmann authored
      commit fd5de272 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: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarVineet Gupta <vgupta@synopsys.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d6d65a2f