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