1. 09 Feb, 2014 3 commits
    • Dave Jones's avatar
      crypto: ccp - Fix ccp_run_passthru_cmd dma variable assignments · 80e84c16
      Dave Jones authored
      There are some suspicious looking lines of code in the new ccp driver, including
      one that assigns a variable to itself, and another that overwrites a previous assignment.
      
      This may have been a cut-and-paste error where 'src' was forgotten to be changed to 'dst'.
      I have no hardware to test this, so this is untested.
      Signed-off-by: default avatarDave Jones <davej@fedoraproject.org>
      Acked-by: default avatarTom Lendacky <thomas.lendacky@amd.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      80e84c16
    • Nitesh Lal's avatar
      crypto: caam - Fix job ring discovery in controller driver · 0a63b09d
      Nitesh Lal authored
      The SEC Controller driver creates platform devices for it's child job ring nodes.
      Currently the driver uses for_each_compatible routine which traverses
      the whole device tree to create the job rings for the platform device.
      The patch changes this to search for the compatible property of job ring
      only in the child nodes i.e., the job rings are created as per the number
      of children associated with the crypto node.
      Signed-off-by: default avatarNitesh Lal <NiteshNarayanLal@freescale.com>
      Reviewed-by: default avatarHoria Geanta <horia.geanta@freescale.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      0a63b09d
    • Marek Vasut's avatar
      crypto: dcp - Move the AES operation type from actx to rctx · 2021abaa
      Marek Vasut authored
      Move the AES operation type and mode from async crypto context to
      crypto request context. This allows for recycling of the async crypto
      context for different kinds of operations.
      
      I found this problem when I used dm-crypt, which uses the same async
      crypto context (actx) for both encryption and decryption requests.
      Since the requests are enqueued into the processing queue, immediatelly
      storing the type of operation into async crypto context (actx) caused
      corruption of this information when encryption and decryption operations
      followed imediatelly one after the other. When the first operation was
      dequeued, the second operation was already enqueued and overwritten the
      type of operation in actx, thus causing incorrect result of the first
      operation.
      
      Fix this problem by storing the type of operation into the crypto request
      context.
      Signed-off-by: default avatarMarek Vasut <marex@denx.de>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Fabio Estevam <fabio.estevam@freescale.com>
      Cc: Shawn Guo <shawn.guo@linaro.org>
      Cc: Tom Lendacky <thomas.lendacky@amd.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      2021abaa
  2. 05 Feb, 2014 3 commits
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 · 4293242d
      Linus Torvalds authored
      Pull crypto fixes from Herbert Xu:
       "This fixes a number of concurrency issues on s390 where multiple users
        of the same crypto transform may clobber each other's results"
      
      * git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
        crypto: s390 - fix des and des3_ede ctr concurrency issue
        crypto: s390 - fix des and des3_ede cbc concurrency issue
        crypto: s390 - fix concurrency issue in aes-ctr mode
      4293242d
    • Ingo Molnar's avatar
      x86: Disable CONFIG_X86_DECODER_SELFTEST in allmod/allyesconfigs · f8f20234
      Ingo Molnar authored
      It can take some time to validate the image, make sure
      {allyes|allmod}config doesn't enable it.
      
      I'd say randconfig will cover it often enough, and the failure is also
      borderline build coverage related: you cannot really make the decoder
      test fail via source level changes, only with changes in the build
      environment, so I agree with Andi that we can disable this one too.
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Acked-by: Paul Gortmaker paul.gortmaker@windriver.com>
      Suggested-and-acked-by: Andi Kleen andi@firstfloor.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      f8f20234
    • Linus Torvalds's avatar
      execve: use 'struct filename *' for executable name passing · c4ad8f98
      Linus Torvalds authored
      This changes 'do_execve()' to get the executable name as a 'struct
      filename', and to free it when it is done.  This is what the normal
      users want, and it simplifies and streamlines their error handling.
      
      The controlled lifetime of the executable name also fixes a
      use-after-free problem with the trace_sched_process_exec tracepoint: the
      lifetime of the passed-in string for kernel users was not at all
      obvious, and the user-mode helper code used UMH_WAIT_EXEC to serialize
      the pathname allocation lifetime with the execve() having finished,
      which in turn meant that the trace point that happened after
      mm_release() of the old process VM ended up using already free'd memory.
      
      To solve the kernel string lifetime issue, this simply introduces
      "getname_kernel()" that works like the normal user-space getname()
      function, except with the source coming from kernel memory.
      
      As Oleg points out, this also means that we could drop the tcomm[] array
      from 'struct linux_binprm', since the pathname lifetime now covers
      setup_new_exec().  That would be a separate cleanup.
      Reported-by: default avatarIgor Zhbanov <i.zhbanov@samsung.com>
      Tested-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      c4ad8f98
  3. 04 Feb, 2014 3 commits
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs · 878a876b
      Linus Torvalds authored
      Pull btrfs fixes from Chris Mason:
       "Filipe is fixing compile and boot problems with our crc32c rework, and
        Josef has disabled snapshot aware defrag for now.
      
        As the number of snapshots increases, we're hitting OOM.  For the
        short term we're disabling things until a bigger fix is ready"
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs:
        Btrfs: use late_initcall instead of module_init
        Btrfs: use btrfs_crc32c everywhere instead of libcrc32c
        Btrfs: disable snapshot aware defrag for now
      878a876b
    • Linus Torvalds's avatar
      Merge tag 'nfs-for-3.14-3' of git://git.linux-nfs.org/projects/trondmy/linux-nfs · d7512f79
      Linus Torvalds authored
      Pull NFS client bugfixes from Trond Myklebust:
       "Highlights:
      
         - Fix NFSv3 acl regressions
         - Fix NFSv4 memory corruption due to slot table abuse in
           nfs4_proc_open_confirm
         - nfs4_destroy_session must call rpc_destroy_waitqueue"
      
      * tag 'nfs-for-3.14-3' of git://git.linux-nfs.org/projects/trondmy/linux-nfs:
        fs: get_acl() must be allowed to return EOPNOTSUPP
        NFSv3: Fix return value of nfs3_proc_setacls
        NFSv3: Remove unused function nfs3_proc_set_default_acl
        NFSv4.1: nfs4_destroy_session must call rpc_destroy_waitqueue
        NFSv4: Fix memory corruption in nfs4_proc_open_confirm
        nfs: fix setting of ACLs on file creation.
      d7512f79
    • Linus Torvalds's avatar
      kbuild: don't enable DEBUG_INFO when building for COMPILE_TEST · 12b13835
      Linus Torvalds authored
      It really isn't very interesting to have DEBUG_INFO when doing compile
      coverage stuff (you wouldn't want to run the result anyway, that's kind
      of the whole point of COMPILE_TEST), and it currently makes the build
      take longer and use much more disk space for "all{yes,mod}config".
      
      There's somewhat active discussion about this still, and we might end up
      with some new config option for things like this (Andi points out that
      the silly X86_DECODER_SELFTEST option also slows down the normal
      coverage tests hugely), but I'm starting the ball rolling with this
      simple one-liner.
      
      DEBUG_INFO isn't that noticeable if you have tons of memory and a good
      IO subsystem, but it hurts you a lot if you don't - for very little
      upside for the common use.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      12b13835
  4. 03 Feb, 2014 11 commits
  5. 02 Feb, 2014 12 commits
  6. 01 Feb, 2014 8 commits