31 May, 2016

1 commit


06 Feb, 2016

1 commit


21 Oct, 2015

1 commit

  • Merge the type-specific data with the payload data into one four-word chunk
    as it seems pointless to keep them separate.

    Use user_key_payload() for accessing the payloads of overloaded
    user-defined keys.

    Signed-off-by: David Howells
    cc: linux-cifs@vger.kernel.org
    cc: ecryptfs@vger.kernel.org
    cc: linux-ext4@vger.kernel.org
    cc: linux-f2fs-devel@lists.sourceforge.net
    cc: linux-nfs@vger.kernel.org
    cc: ceph-devel@vger.kernel.org
    cc: linux-ima-devel@lists.sourceforge.net

    David Howells
     

09 Mar, 2015

1 commit

  • The patch moves the information provided in
    Documentation/crypto/crypto-API-userspace.txt into a separate chapter in
    the kernel crypto API DocBook. Some corrections are applied (such as
    removing a reference to Netlink when the AF_ALG socket is referred to).

    In addition, the AEAD and RNG interface description is now added.

    Also, a brief description of the zero-copy interface with an example
    code snippet is provided.

    Signed-off-by: Stephan Mueller
    Signed-off-by: Herbert Xu

    Stephan Mueller
     

13 Nov, 2014

1 commit

  • The userspace interface of the kernel crypto API is documented with
    * a general explanation
    * a discussion of the memory in-place operation
    * the description of the message digest API
    * the description of the symmetric cipher API

    The documentation refers to libkcapi as a working example on how to use
    the kernel crypto API from user space.

    Signed-off-by: Stephan Mueller
    Signed-off-by: Herbert Xu

    Stephan Mueller
     

04 Jul, 2013

1 commit

  • There have never been any real users of MEMSET operations since they
    have been introduced in January 2007 by commit 7405f74badf4 ("dmaengine:
    refactor dmaengine around dma_async_tx_descriptor"). Therefore remove
    support for them for now, it can be always brought back when needed.

    [sebastian.hesselbarth@gmail.com: fix drivers/dma/mv_xor]
    Signed-off-by: Bartlomiej Zolnierkiewicz
    Signed-off-by: Kyungmin Park
    Signed-off-by: Sebastian Hesselbarth
    Cc: Vinod Koul
    Acked-by: Dan Williams
    Cc: Tomasz Figa
    Cc: Herbert Xu
    Cc: Olof Johansson
    Cc: Kevin Hilman
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Bartlomiej Zolnierkiewicz
     

08 Oct, 2012

1 commit


30 Aug, 2009

2 commits

  • async_raid6_2data_recov() recovers two data disk failures

    async_raid6_datap_recov() recovers a data disk and the P disk

    These routines are a port of the synchronous versions found in
    drivers/md/raid6recov.c. The primary difference is breaking out the xor
    operations into separate calls to async_xor. Two helper routines are
    introduced to perform scalar multiplication where needed.
    async_sum_product() multiplies two sources by scalar coefficients and
    then sums (xor) the result. async_mult() simply multiplies a single
    source by a scalar.

    This implemention also includes, in contrast to the original
    synchronous-only code, special case handling for the 4-disk and 5-disk
    array cases. In these situations the default N-disk algorithm will
    present 0-source or 1-source operations to dma devices. To cover for
    dma devices where the minimum source count is 2 we implement 4-disk and
    5-disk handling in the recovery code.

    [ Impact: asynchronous raid6 recovery routines for 2data and datap cases ]

    Cc: Yuri Tikhonov
    Cc: Ilya Yanok
    Cc: H. Peter Anvin
    Cc: David Woodhouse
    Reviewed-by: Andre Noll
    Acked-by: Maciej Sosnowski
    Signed-off-by: Dan Williams

    Dan Williams
     
  • [ Based on an original patch by Yuri Tikhonov ]

    This adds support for doing asynchronous GF multiplication by adding
    two additional functions to the async_tx API:

    async_gen_syndrome() does simultaneous XOR and Galois field
    multiplication of sources.

    async_syndrome_val() validates the given source buffers against known P
    and Q values.

    When a request is made to run async_pq against more than the hardware
    maximum number of supported sources we need to reuse the previous
    generated P and Q values as sources into the next operation. Care must
    be taken to remove Q from P' and P from Q'. For example to perform a 5
    source pq op with hardware that only supports 4 sources at a time the
    following approach is taken:

    p, q = PQ(src0, src1, src2, src3, COEF({01}, {02}, {04}, {08}))
    p', q' = PQ(p, q, q, src4, COEF({00}, {01}, {00}, {10}))

    p' = p + q + q + src4 = p + src4
    q' = {00}*p + {01}*q + {00}*q + {10}*src4 = q + {10}*src4

    Note: 4 is the minimum acceptable maxpq otherwise we punt to
    synchronous-software path.

    The DMA_PREP_CONTINUE flag indicates to the driver to reuse p and q as
    sources (in the above manner) and fill the remaining slots up to maxpq
    with the new sources/coefficients.

    Note1: Some devices have native support for P+Q continuation and can skip
    this extra work. Devices with this capability can advertise it with
    dma_set_maxpq. It is up to each driver how to handle the
    DMA_PREP_CONTINUE flag.

    Note2: The api supports disabling the generation of P when generating Q,
    this is ignored by the synchronous path but is implemented by some dma
    devices to save unnecessary writes. In this case the continuation
    algorithm is simplified to only reuse Q as a source.

    Cc: H. Peter Anvin
    Cc: David Woodhouse
    Signed-off-by: Yuri Tikhonov
    Signed-off-by: Ilya Yanok
    Reviewed-by: Andre Noll
    Acked-by: Maciej Sosnowski
    Signed-off-by: Dan Williams

    Dan Williams
     

04 Jun, 2009

3 commits

  • async_xor() needs space to perform dma and page address conversions. In
    most cases the code can simply reuse the struct page * array because the
    size of the native pointer matches the size of a dma/page address. In
    order to support archs where sizeof(dma_addr_t) is larger than
    sizeof(struct page *), or to preserve the input parameters, we utilize a
    memory region passed in by the caller.

    Since the code is now prepared to handle the case where it cannot
    perform address conversions on the stack, we no longer need the
    !HIGHMEM64G dependency in drivers/dma/Kconfig.

    [ Impact: don't clobber input buffers for address conversions ]

    Reviewed-by: Andre Noll
    Acked-by: Maciej Sosnowski
    Signed-off-by: Dan Williams

    Dan Williams
     
  • Prepare the api for the arrival of a new parameter, 'scribble'. This
    will allow callers to identify scratchpad memory for dma address or page
    address conversions. As this adds yet another parameter, take this
    opportunity to convert the common submission parameters (flags,
    dependency, callback, and callback argument) into an object that is
    passed by reference.

    Also, take this opportunity to fix up the kerneldoc and add notes about
    the relevant ASYNC_TX_* flags for each routine.

    [ Impact: moves api pass-by-value parameters to a pass-by-reference struct ]

    Signed-off-by: Andre Noll
    Acked-by: Maciej Sosnowski
    Signed-off-by: Dan Williams

    Dan Williams
     
  • In support of inter-channel chaining async_tx utilizes an ack flag to
    gate whether a dependent operation can be chained to another. While the
    flag is not set the chain can be considered open for appending. Setting
    the ack flag closes the chain and flags the descriptor for garbage
    collection. The ASYNC_TX_DEP_ACK flag essentially means "close the
    chain after adding this dependency". Since each operation can only have
    one child the api now implicitly sets the ack flag at dependency
    submission time. This removes an unnecessary management burden from
    clients of the api.

    [ Impact: clean up and enforce one dependency per operation ]

    Reviewed-by: Andre Noll
    Acked-by: Maciej Sosnowski
    Signed-off-by: Dan Williams

    Dan Williams
     

09 Apr, 2009

1 commit

  • 'zero_sum' does not properly describe the operation of generating parity
    and checking that it validates against an existing buffer. Change the
    name of the operation to 'val' (for 'validate'). This is in
    anticipation of the p+q case where it is a requirement to identify the
    target parity buffers separately from the source buffers, because the
    target parity buffers will not have corresponding pq coefficients.

    Reviewed-by: Andre Noll
    Acked-by: Maciej Sosnowski
    Signed-off-by: Dan Williams

    Dan Williams
     

06 Jan, 2009

1 commit

  • "Wouldn't it be better if the dmaengine layer made sure it didn't pass
    the same channel several times to a client?

    I mean, you seem concerned that the memcpy() API should be transparent
    and easy to use, but the whole registration interface is just
    ridiculously complicated..."
    - Haavard

    The dmaengine and async_tx registration/allocation interface is indeed
    needlessly complicated. This redesign has the following goals:

    1/ Simplify reference counting: dma channels are not something one would
    expect to be hotplugged, it should be an exceptional event handled by
    drivers not something clients should be mandated to handle in a
    callback. The common case channel removal event is 'rmmod ',
    which for simplicity should be disallowed if the channel is in use.
    2/ Add an interface for requesting exclusive access to a channel
    suitable to device-to-memory users.
    3/ Convert all memory-to-memory users over to a common allocator, the goal
    here is to not have competing channel allocation schemes. The only
    competition should be between device-to-memory exclusive allocations and
    the memory-to-memory usage case where channels are shared between
    multiple "clients".

    Cc: Haavard Skinnemoen
    Cc: Neil Brown
    Cc: Jeff Garzik
    Reviewed-by: Andrew Morton
    Signed-off-by: Dan Williams

    Dan Williams
     

11 Jan, 2008

1 commit

  • This patch updates the list of transforms we support and clarifies that
    the Block Ciphers interface in fact supports all ciphers including stream
    ciphers.

    It also removes the obsolete Configuration Notes section and adds the
    linux-crypto mailing list as the primary bug reporting address.

    Finally it documents the fact that setkey should only be called from
    user context.

    Signed-off-by: Herbert Xu

    Herbert Xu
     

25 Sep, 2007

1 commit


09 May, 2007

1 commit


21 Mar, 2007

1 commit

  • there is a tiny bug in Documentation/crypto/api-intro.txt.
    The file has the following example code:

    struct scatterlist sg[2];
    [...]
    if (crypto_hash_digest(&desc, &sg, 2, result))

    which does not match the declaration of crypto_hash_digest() in
    include/linux/crypto.h.

    (static inline int crypto_hash_digest(struct hash_desc *desc,
    struct scatterlist *sg, unsigned int nbytes, u8 *out)

    The code in the example passes the address of a pointer (an array actually) as
    the second argument, while the function expects the pointer itself.

    I have attached a patch to fix this.

    Signed-off-by: Herbert Xu

    Johannes Schlumberger
     

07 Feb, 2007

1 commit


21 Sep, 2006

1 commit


11 Sep, 2005

1 commit

  • The attached patch fixes the following spelling errors in Documentation/
    - double "the"
    - Several misspellings of function/functionality
    - infomation
    - memeory
    - Recieved
    - wether
    and possibly others which I forgot ;-)
    Trailing whitespaces on the same line as the typo are also deleted.

    Signed-off-by: Tobias Klauser
    Signed-off-by: Domen Puncer
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Tobias Klauser
     

02 Sep, 2005

1 commit

  • The XTEA implementation was incorrect due to a misinterpretation of
    operator precedence. Because of the wide-spread nature of this
    error, the erroneous implementation will be kept, albeit under the
    new name of XETA.

    Signed-off-by: Aaron Grothe
    Signed-off-by: Herbert Xu
    Signed-off-by: David S. Miller

    Aaron Grothe
     

17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds