1. 23 12月, 2015 5 次提交
  2. 22 12月, 2015 6 次提交
  3. 17 12月, 2015 3 次提交
  4. 14 12月, 2015 3 次提交
    • T
      crypto: qat - uint8_t is not large enough for accel_id · 81b312f1
      Tadeusz Struk 提交于
      accel_id has to be large enough to hold ADF_MAX_DEVICES + 1
      (which is > 1025) so uint8_t is too small.
      Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NTadeusz Struk <tadeusz.struk@intel.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      81b312f1
    • S
      crypto: omap-des - Fix "schedule while atomic" bug · 50eca256
      Sam Protsenko 提交于
      When using DES module the next bug appears:
      
          BUG: scheduling while atomic: kworker/0:1/63/0x00000102
      
      With backtrace as follows:
      
      <<<<<<<<<<<<<<<<<<<<<<<<<<<<<< cut here >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
      
      [<c0012294>] (dump_backtrace) from [<c00124ac>] (show_stack+0x18/0x1c)
      [<c0012494>] (show_stack) from [<c0752554>] (dump_stack+0x84/0xc4)
      [<c07524d0>] (dump_stack) from [<c0750218>] (__schedule_bug+0x54/0x64)
      [<c07501c4>] (__schedule_bug) from [<c07548a4>] (__schedule+0x4ac/0x53c)
      [<c07543f8>] (__schedule) from [<c075496c>] (schedule+0x38/0x88)
      [<c0754934>] (schedule) from [<c03c3984>] (rpm_resume+0x158/0x59c)
      [<c03c382c>] (rpm_resume) from [<c03c3e1c>] (__pm_runtime_resume+0x54/0x6c)
      [<c03c3dc8>] (__pm_runtime_resume) from [<c0568ff8>] (omap_des_handle_queue+0x154/0x7bc)
      [<c0568ea4>] (omap_des_handle_queue) from [<c05696b8>] (omap_des_crypt+0x58/0xbc)
      [<c0569660>] (omap_des_crypt) from [<c0569730>] (omap_des_cbc_decrypt+0x14/0x18)
      [<c056971c>] (omap_des_cbc_decrypt) from [<c0297534>] (authenc_verify_ahash_done+0xe0/0xe8)
      [<c0297454>] (authenc_verify_ahash_done) from [<c056a330>] (omap_sham_finish_req+0x58/0xa8)
      [<c056a2d8>] (omap_sham_finish_req) from [<c056b714>] (omap_sham_done_task+0x1c0/0x1e0)
      [<c056b554>] (omap_sham_done_task) from [<c003e53c>] (tasklet_action+0x80/0x118)
      [<c003e4bc>] (tasklet_action) from [<c003e740>] (__do_softirq+0x11c/0x260)
      [<c003e624>] (__do_softirq) from [<c003eb64>] (irq_exit+0xc0/0xfc)
      [<c003eaa4>] (irq_exit) from [<c000f1c4>] (handle_IRQ+0x4c/0x98)
      [<c000f178>] (handle_IRQ) from [<c0008568>] (gic_handle_irq+0x34/0x64)
      [<c0008534>] (gic_handle_irq) from [<c0758540>] (__irq_svc+0x40/0x70)
      
      <<<<<<<<<<<<<<<<<<<<<<<<<<<<<< cut here >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
      
      Insight was seen in drivers/crypto/omap-sham.c driver.
      All credits for this patch go to Grygorii Strashko.
      Signed-off-by: NSam Protsenko <semen.protsenko@linaro.org>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      50eca256
    • Z
      crypto: qat - enable VF irq after guest exits ungracefully · 40c18a59
      Zeng Xin 提交于
      The VF bundle interrupt is not triggered any more in
      the case when guest is shut down with sample app running.
      Need to clear the flag interrupt bit when restarting to fix
      this irrecoverable state.
      Signed-off-by: NZeng Xin <xin.zeng@intel.com>
      Signed-off-by: NTadeusz Struk <tadeusz.struk@intel.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      40c18a59
  5. 11 12月, 2015 2 次提交
  6. 10 12月, 2015 2 次提交
    • A
      crypto: sahara - fix debug output for 64-bit dma_addr_t · d4b98f20
      Arnd Bergmann 提交于
      The sahara_dump_descriptors and sahara_dump_links functions attempt
      to print a dma_addr_t value with a 0x%08x format string, which
      produces a warning when dma_addr_t is 64-bit wide:
      
      drivers/crypto/sahara.c:419:120: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t {aka long long unsigned int}' [-Wformat=]
      
      This changes the code to use the %pad format string that is meant
      for dma_addr_t, which avoids the warning and gives us the correct
      output in all configurations.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      d4b98f20
    • A
      crypto: sahara - fix 64-bit dma_addr_t compilation · 75d3f811
      Arnd Bergmann 提交于
      The sahara hardware uses DMA descriptors with 32-bit addresses, but
      dma_addr_t is variable size depending on whether we want to support
      any devices that use 64-bit DMA addresses in hardware.
      This means that the definition of the DMA descriptor structure is wrong,
      and we helpfully get a compiler warning about them too:
      
      drivers/crypto/sahara.c:423:372: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'dma_addr_t {aka long long unsigned int}' [-Wformat=]
      
      This changes the definition of the sahara_hw_desc and sahara_hw_link
      structures to only contain fixed-length members, which is required
      to make the driver work on ARM LPAE mode, and avoids most of the
      gcc warnings we get.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      75d3f811
  7. 09 12月, 2015 7 次提交
  8. 04 12月, 2015 6 次提交
    • T
      crypto: n2 - Use platform_register/unregister_drivers() · a103a75a
      Thierry Reding 提交于
      These new helpers simplify implementing multi-driver modules and
      properly handle failure to register one driver by unregistering all
      previously registered drivers.
      Signed-off-by: NThierry Reding <treding@nvidia.com>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      a103a75a
    • L
      crypto: talitos - add new crypto modes · 5e75ae1b
      LEROY Christophe 提交于
      This patch adds the following algorithms to the talitos driver:
      * ecb(aes)
      * ctr(aes)
      * ecb(des)
      * cbc(des)
      * ecb(des3_ede)
      Signed-off-by: NChristophe Leroy <christophe.leroy@c-s.fr>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      5e75ae1b
    • L
      crypto: vmx - IV size failing on skcipher API · 0d3d054b
      Leonidas Da Silva Barbosa 提交于
      IV size was zero on CBC and CTR modes,
      causing a bug triggered by skcipher.
      
      Fixing this  adding a correct size.
      Signed-off-by: NLeonidas Da Silva Barbosa <leosilva@linux.vnet.ibm.com>
      Signed-off-by: NPaulo Smorigo <pfsmorigo@linux.vnet.ibm.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      0d3d054b
    • F
      crypto: caam - pass the correct buffer length · f456cd2d
      Fabio Estevam 提交于
      When buffer 0 is used we should use buflen_0 instead of buflen_1.
      
      Fix it.
      Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      f456cd2d
    • H
      crypto: rockchip - fix possible deadlock · ac7c8e6b
      Heiko Stuebner 提交于
      Lockdep warns about a possible deadlock resulting from the use of regular
      spin_locks:
      
      =================================
      [ INFO: inconsistent lock state ]
      4.4.0-rc2+ #2724 Not tainted
      ---------------------------------
      inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
      ksoftirqd/0/3 [HC0[0]:SC1[1]:HE1:SE0] takes:
      (&(&crypto_info->lock)->rlock){+.?...}, at: [<bf14a65c>] rk_crypto_tasklet_cb+0x24/0xb4 [rk_crypto]
      {SOFTIRQ-ON-W} state was registered at:
        [<c007f4ac>] lock_acquire+0x178/0x218
        [<c0759bac>] _raw_spin_lock+0x54/0x64
        [<bf14af88>] rk_handle_req+0x7c/0xbc [rk_crypto]
        [<bf14b040>] rk_des_ecb_encrypt+0x2c/0x30 [rk_crypto]
        [<bf14b05c>] rk_aes_ecb_encrypt+0x18/0x1c [rk_crypto]
        [<c028c820>] skcipher_encrypt_ablkcipher+0x64/0x68
        [<c0290770>] __test_skcipher+0x2a8/0x8dc
        [<c0292e94>] test_skcipher+0x38/0xc4
        [<c0292fb0>] alg_test_skcipher+0x90/0xb0
        [<c0292158>] alg_test+0x1e8/0x280
        [<c028f6f4>] cryptomgr_test+0x34/0x54
        [<c004bbe8>] kthread+0xf4/0x10c
        [<c0010010>] ret_from_fork+0x14/0x24
      irq event stamp: 10672
      hardirqs last  enabled at (10672): [<c002fac8>] tasklet_action+0x48/0x104
      hardirqs last disabled at (10671): [<c002faa0>] tasklet_action+0x20/0x104
      softirqs last  enabled at (10658): [<c002ef84>] __do_softirq+0x358/0x49c
      softirqs last disabled at (10669): [<c002f108>] run_ksoftirqd+0x40/0x80
      
      other info that might help us debug this:
      Possible unsafe locking scenario:
      
          CPU0
          ----
        lock(&(&crypto_info->lock)->rlock);
        <Interrupt>
          lock(&(&crypto_info->lock)->rlock);
      
       *** DEADLOCK ***
      
      Fix this by moving to irq-disabling spinlocks.
      Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      ac7c8e6b
    • J
      hwrng: core - sleep interruptible in read · 1ab87298
      Jiri Slaby 提交于
      hwrng kthread can be waiting via hwrng_fillfn for some data from a rng
      like virtio-rng:
      hwrng           D ffff880093e17798     0   382      2 0x00000000
      ...
      Call Trace:
       [<ffffffff817339c6>] wait_for_completion_killable+0x96/0x210
       [<ffffffffa00aa1b7>] virtio_read+0x57/0xf0 [virtio_rng]
       [<ffffffff814f4a35>] hwrng_fillfn+0x75/0x130
       [<ffffffff810aa243>] kthread+0xf3/0x110
      
      And when some user program tries to read the /dev node in this state,
      we get:
      rngd            D ffff880093e17798     0   762      1 0x00000004
      ...
      Call Trace:
       [<ffffffff817351ac>] mutex_lock_nested+0x15c/0x3e0
       [<ffffffff814f478e>] rng_dev_read+0x6e/0x240
       [<ffffffff81231958>] __vfs_read+0x28/0xe0
       [<ffffffff81232393>] vfs_read+0x83/0x130
      
      And this is indeed unkillable. So use mutex_lock_interruptible
      instead of mutex_lock in rng_dev_read and exit immediatelly when
      interrupted. And possibly return already read data, if any (as POSIX
      allows).
      
      v2: use ERESTARTSYS instead of EINTR
      Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      Cc: Matt Mackall <mpm@selenic.com>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Cc: <linux-crypto@vger.kernel.org>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      1ab87298
  9. 27 11月, 2015 1 次提交
  10. 24 11月, 2015 3 次提交
  11. 23 11月, 2015 2 次提交