02 Sep, 2005

1 commit

  • The crypto layer currently uses in_atomic() to determine whether it is
    allowed to sleep. This is incorrect since spin locks don't always cause
    in_atomic() to return true.

    Instead of that, this patch returns to an earlier idea of a per-tfm flag
    which determines whether sleeping is allowed. Unlike the earlier version,
    the default is to not allow sleeping. This ensures that no existing code
    can break.

    As usual, this flag may either be set through crypto_alloc_tfm(), or
    just before a specific crypto operation.

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

    Herbert Xu
     

15 Jul, 2005

1 commit


07 Jul, 2005

3 commits

  • This patch ensures that cit_iv is aligned according to cra_alignmask
    by allocating it as part of the tfm structure. As a side effect the
    crypto layer will also guarantee that the tfm ctx area has enough space
    to be aligned by cra_alignmask. This allows us to remove the extra
    space reservation from the Padlock driver.

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

    Herbert Xu
     
  • This patch makes a needlessly global function static.

    Signed-off-by: Adrian Bunk
    Signed-off-by: Herbert Xu
    Signed-off-by: David S. Miller

    Adrian Bunk
     
  • This patch adds hooks for cipher algorithms to implement multi-block
    ECB/CBC operations directly. This is expected to provide significant
    performance boots to the VIA Padlock.

    It could also be used for improving software implementations such as
    AES where operating on multiple blocks at a time may enable certain
    optimisations.

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

    Herbert Xu
     

24 May, 2005

1 commit

  • The netlink gfp_any() problem made me double-check the uses of in_softirq()
    in crypto/*. It seems to me that we should be checking in_atomic() instead
    of in_softirq() in crypto_yield. Otherwise people calling the crypto ops
    with spin locks held or preemption disabled will get burnt, right?

    Signed-off-by: David S. Miller

    Herbert Xu
     

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