1. 20 6月, 2016 2 次提交
  2. 13 6月, 2016 1 次提交
    • B
      crypto: qat - Remove deprecated create_workqueue · 773b1979
      Bhaktipriya Shridhar 提交于
      alloc_workqueue replaces deprecated create_workqueue().
      
      The workqueue device_reset_wq has workitem &reset_data->reset_work per
      adf_reset_dev_data. The workqueue  pf2vf_resp_wq is a workqueue for
      PF2VF responses has workitem &pf2vf_resp->pf2vf_resp_work per pf2vf_resp.
      The workqueue adf_vf_stop_wq is used to call adf_dev_stop()
      asynchronously.
      
      Dedicated workqueues have been used in all cases since the workitems
      on the workqueues are involved in operation of crypto which can be used in
      the IO path which is depended upon during memory reclaim. Hence,
      WQ_MEM_RECLAIM has been set to gurantee forward progress under memory
      pressure.
      Since there are only a fixed number of work items, explicit concurrency
      limit is unnecessary.
      Signed-off-by: NBhaktipriya Shridhar <bhaktipriya96@gmail.com>
      Acked-by: NTejun Heo <tj@kernel.org>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      773b1979
  3. 08 6月, 2016 7 次提交
  4. 07 6月, 2016 1 次提交
  5. 31 5月, 2016 5 次提交
  6. 28 5月, 2016 1 次提交
    • A
      remove lots of IS_ERR_VALUE abuses · 287980e4
      Arnd Bergmann 提交于
      Most users of IS_ERR_VALUE() in the kernel are wrong, as they
      pass an 'int' into a function that takes an 'unsigned long'
      argument. This happens to work because the type is sign-extended
      on 64-bit architectures before it gets converted into an
      unsigned type.
      
      However, anything that passes an 'unsigned short' or 'unsigned int'
      argument into IS_ERR_VALUE() is guaranteed to be broken, as are
      8-bit integers and types that are wider than 'unsigned long'.
      
      Andrzej Hajda has already fixed a lot of the worst abusers that
      were causing actual bugs, but it would be nice to prevent any
      users that are not passing 'unsigned long' arguments.
      
      This patch changes all users of IS_ERR_VALUE() that I could find
      on 32-bit ARM randconfig builds and x86 allmodconfig. For the
      moment, this doesn't change the definition of IS_ERR_VALUE()
      because there are probably still architecture specific users
      elsewhere.
      
      Almost all the warnings I got are for files that are better off
      using 'if (err)' or 'if (err < 0)'.
      The only legitimate user I could find that we get a warning for
      is the (32-bit only) freescale fman driver, so I did not remove
      the IS_ERR_VALUE() there but changed the type to 'unsigned long'.
      For 9pfs, I just worked around one user whose calling conventions
      are so obscure that I did not dare change the behavior.
      
      I was using this definition for testing:
      
       #define IS_ERR_VALUE(x) ((unsigned long*)NULL == (typeof (x)*)NULL && \
             unlikely((unsigned long long)(x) >= (unsigned long long)(typeof(x))-MAX_ERRNO))
      
      which ends up making all 16-bit or wider types work correctly with
      the most plausible interpretation of what IS_ERR_VALUE() was supposed
      to return according to its users, but also causes a compile-time
      warning for any users that do not pass an 'unsigned long' argument.
      
      I suggested this approach earlier this year, but back then we ended
      up deciding to just fix the users that are obviously broken. After
      the initial warning that caused me to get involved in the discussion
      (fs/gfs2/dir.c) showed up again in the mainline kernel, Linus
      asked me to send the whole thing again.
      
      [ Updated the 9p parts as per Al Viro  - Linus ]
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Cc: Andrzej Hajda <a.hajda@samsung.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Link: https://lkml.org/lkml/2016/1/7/363
      Link: https://lkml.org/lkml/2016/5/27/486
      Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> # For nvmem part
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      287980e4
  7. 25 5月, 2016 1 次提交
    • T
      crypto: ccp - Fix AES XTS error for request sizes above 4096 · ab6a11a7
      Tom Lendacky 提交于
      The ccp-crypto module for AES XTS support has a bug that can allow requests
      greater than 4096 bytes in size to be passed to the CCP hardware. The CCP
      hardware does not support request sizes larger than 4096, resulting in
      incorrect output. The request should actually be handled by the fallback
      mechanism instantiated by the ccp-crypto module.
      
      Add a check to insure the request size is less than or equal to the maximum
      supported size and use the fallback mechanism if it is not.
      
      Cc: <stable@vger.kernel.org> # 3.14.x-
      Signed-off-by: NTom Lendacky <thomas.lendacky@amd.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      ab6a11a7
  8. 19 5月, 2016 1 次提交
  9. 13 5月, 2016 1 次提交
  10. 10 5月, 2016 2 次提交
  11. 03 5月, 2016 9 次提交
  12. 28 4月, 2016 2 次提交
  13. 25 4月, 2016 6 次提交
    • K
      crypto: s5p-sss - Fix missed interrupts when working with 8 kB blocks · 79152e8d
      Krzysztof Kozlowski 提交于
      The tcrypt testing module on Exynos5422-based Odroid XU3/4 board failed on
      testing 8 kB size blocks:
      
      	$ sudo modprobe tcrypt sec=1 mode=500
      	testing speed of async ecb(aes) (ecb-aes-s5p) encryption
      	test 0 (128 bit key, 16 byte blocks): 21971 operations in 1 seconds (351536 bytes)
      	test 1 (128 bit key, 64 byte blocks): 21731 operations in 1 seconds (1390784 bytes)
      	test 2 (128 bit key, 256 byte blocks): 21932 operations in 1 seconds (5614592 bytes)
      	test 3 (128 bit key, 1024 byte blocks): 21685 operations in 1 seconds (22205440 bytes)
      	test 4 (128 bit key, 8192 byte blocks):
      
      This was caused by a race issue of missed BRDMA_DONE ("Block cipher
      Receiving DMA") interrupt. Device starts processing the data in DMA mode
      immediately after setting length of DMA block: receiving (FCBRDMAL) or
      transmitting (FCBTDMAL). The driver sets these lengths from interrupt
      handler through s5p_set_dma_indata() function (or xxx_setdata()).
      
      However the interrupt handler was first dealing with receive buffer
      (dma-unmap old, dma-map new, set receive block length which starts the
      operation), then with transmit buffer and finally was clearing pending
      interrupts (FCINTPEND). Because of the time window between setting
      receive buffer length and clearing pending interrupts, the operation on
      receive buffer could end already and driver would miss new interrupt.
      
      User manual for Exynos5422 confirms in example code that setting DMA
      block lengths should be the last operation.
      
      The tcrypt hang could be also observed in following blocked-task dmesg:
      
      INFO: task modprobe:258 blocked for more than 120 seconds.
            Not tainted 4.6.0-rc4-next-20160419-00005-g9eac8b7b7753-dirty #42
      "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      modprobe        D c06b09d8     0   258    256 0x00000000
      [<c06b09d8>] (__schedule) from [<c06b0f24>] (schedule+0x40/0xac)
      [<c06b0f24>] (schedule) from [<c06b49f8>] (schedule_timeout+0x124/0x178)
      [<c06b49f8>] (schedule_timeout) from [<c06b17fc>] (wait_for_common+0xb8/0x144)
      [<c06b17fc>] (wait_for_common) from [<bf0013b8>] (test_acipher_speed+0x49c/0x740 [tcrypt])
      [<bf0013b8>] (test_acipher_speed [tcrypt]) from [<bf003e8c>] (do_test+0x2240/0x30ec [tcrypt])
      [<bf003e8c>] (do_test [tcrypt]) from [<bf008048>] (tcrypt_mod_init+0x48/0xa4 [tcrypt])
      [<bf008048>] (tcrypt_mod_init [tcrypt]) from [<c010177c>] (do_one_initcall+0x3c/0x16c)
      [<c010177c>] (do_one_initcall) from [<c0191ff0>] (do_init_module+0x5c/0x1ac)
      [<c0191ff0>] (do_init_module) from [<c0185610>] (load_module+0x1a30/0x1d08)
      [<c0185610>] (load_module) from [<c0185ab0>] (SyS_finit_module+0x8c/0x98)
      [<c0185ab0>] (SyS_finit_module) from [<c01078c0>] (ret_fast_syscall+0x0/0x3c)
      
      Fixes: a49e490c ("crypto: s5p-sss - add S5PV210 advanced crypto engine support")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Tested-by: NMarek Szyprowski <m.szyprowski@samsung.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      79152e8d
    • K
      crypto: s5p-sss - Use common BIT macro · 5e00c604
      Krzysztof Kozlowski 提交于
      The BIT() macro is obvious and well known, so prefer to use it instead
      of crafted own macro.
      Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      5e00c604
    • D
      crypto: mxc-scc - fix unwinding in mxc_scc_crypto_register() · 4c048af7
      Dan Carpenter 提交于
      There are two issues here:
      
      1) We need to decrement "i" otherwise we unregister something that was
         not successfully registered.
      2) The original code did not unregister the first element in the array
         where i is zero.
      
      Fixes: d293b640 ('crypto: mxc-scc - add basic driver for the MXC SCC')
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      4c048af7
    • D
      crypto: mxc-scc - signedness bugs in mxc_scc_ablkcipher_req_init() · b908bd3d
      Dan Carpenter 提交于
      ->src_nents and ->dst_nents are unsigned so they can't be less than
      zero.  I fixed this by introducing a temporary "nents" variable.
      
      Fixes: d293b640 ('crypto: mxc-scc - add basic driver for the MXC SCC')
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      b908bd3d
    • H
      crypto: talitos - fix ahash algorithms registration · 3639ca84
      Horia Geant? 提交于
      Provide hardware state import/export functionality, as mandated by
      commit 8996eafd ("crypto: ahash - ensure statesize is non-zero")
      
      Cc: <stable@vger.kernel.org> # 4.3+
      Reported-by: NJonas Eymann <J.Eymann@gmx.net>
      Signed-off-by: NHoria Geant? <horia.geanta@nxp.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      3639ca84
    • G
      crypto: ccp - Ensure all dependencies are specified · b3c2fee5
      Gary R Hook 提交于
      A DMA_ENGINE requires DMADEVICES in Kconfig
      Signed-off-by: NGary R Hook <gary.hook@amd.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      b3c2fee5
  14. 20 4月, 2016 1 次提交