19 Jun, 2019

1 commit

  • Based on 2 normalized pattern(s):

    this source code is licensed under the gnu general public license
    version 2 see the file copying for more details

    this source code is licensed under general public license version 2
    see

    extracted by the scancode license scanner the SPDX license identifier

    GPL-2.0-only

    has been chosen to replace the boilerplate/reference in 52 file(s).

    Signed-off-by: Thomas Gleixner
    Reviewed-by: Enrico Weigelt
    Reviewed-by: Allison Randal
    Reviewed-by: Alexios Zavras
    Cc: linux-spdx@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190602204653.449021192@linutronix.de
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     

25 Apr, 2019

1 commit

  • The flags field in 'struct shash_desc' never actually does anything.
    The only ostensibly supported flag is CRYPTO_TFM_REQ_MAY_SLEEP.
    However, no shash algorithm ever sleeps, making this flag a no-op.

    With this being the case, inevitably some users who can't sleep wrongly
    pass MAY_SLEEP. These would all need to be fixed if any shash algorithm
    actually started sleeping. For example, the shash_ahash_*() functions,
    which wrap a shash algorithm with the ahash API, pass through MAY_SLEEP
    from the ahash API to the shash API. However, the shash functions are
    called under kmap_atomic(), so actually they're assumed to never sleep.

    Even if it turns out that some users do need preemption points while
    hashing large buffers, we could easily provide a helper function
    crypto_shash_update_large() which divides the data into smaller chunks
    and calls crypto_shash_update() and cond_resched() for each chunk. It's
    not necessary to have a flag in 'struct shash_desc', nor is it necessary
    to make individual shash algorithms aware of this at all.

    Therefore, remove shash_desc::flags, and document that the
    crypto_shash_*() functions can be called from any context.

    Signed-off-by: Eric Biggers
    Signed-off-by: Herbert Xu

    Eric Biggers
     

14 Sep, 2018

1 commit


04 Sep, 2018

2 commits


31 May, 2015

1 commit

  • This introduces crc_t10dif_update() which enables to calculate CRC
    for a block which straddles multiple SG elements by calling multiple
    times. This also converts crc_t10dif() to use crc_t10dif_update() as
    they are almost same.

    (remove extra function call in crc_t10dif() and crc_t10dif_update -
    Tim + Herbert)

    Signed-off-by: Akinobu Mita
    Acked-by: Martin K. Petersen
    Cc: Tim Chen
    Cc: Herbert Xu
    Cc: "David S. Miller"
    Cc: linux-crypto@vger.kernel.org
    Cc: Nicholas Bellinger
    Cc: Sagi Grimberg
    Cc: "Martin K. Petersen"
    Cc: Christoph Hellwig
    Cc: "James E.J. Bottomley"
    Cc: target-devel@vger.kernel.org
    Signed-off-by: Nicholas Bellinger

    Akinobu Mita
     

12 Sep, 2013

1 commit

  • Unfortunately, even with a softdep some distros fail to include
    the necessary modules in the initrd. Therefore this patch adds
    a fallback path to restore existing behaviour where we cannot
    load the new crypto crct10dif algorithm.

    In order to do this, the underlying crct10dif has been split out
    from the crypto implementation so that it can be used on the
    fallback path.

    Signed-off-by: Herbert Xu

    Herbert Xu
     

07 Sep, 2013

1 commit


24 Jul, 2013

1 commit

  • This reverts commits
    67822649d7305caf3dd50ed46c27b99c94eff996
    39761214eefc6b070f29402aa1165f24d789b3f7
    0b95a7f85718adcbba36407ef88bba0a7379ed03
    31d939625a9a20b1badd2d4e6bf6fd39fa523405
    2d31e518a42828df7877bca23a958627d60408bc

    Unfortunately this change broke boot on some systems that used an
    initrd which does not include the newly created crct10dif modules.
    As these modules are required by sd_mod under certain configurations
    this is a serious problem.

    Signed-off-by: Herbert Xu

    Herbert Xu
     

05 Jun, 2013

1 commit


20 May, 2013

1 commit


12 Jul, 2008

1 commit