24 Nov, 2014

1 commit


01 Aug, 2012

1 commit

  • Initialization of cra_list is currently mixed, most ciphers initialize this
    field and most shashes do not. Initialization however is not needed at all
    since cra_list is initialized/overwritten in __crypto_register_alg() with
    list_add(). Therefore perform cleanup to remove all unneeded initializations
    of this field in 'crypto/'.

    Signed-off-by: Jussi Kivilinna
    Signed-off-by: Herbert Xu

    Jussi Kivilinna
     

29 Jun, 2011

1 commit


23 Mar, 2011

1 commit

  • Instead of always creating a huge (268K) deflate_workspace with the
    maximum compression parameters (windowBits=15, memLevel=8), allow the
    caller to obtain a smaller workspace by specifying smaller parameter
    values.

    For example, when capturing oops and panic reports to a medium with
    limited capacity, such as NVRAM, compression may be the only way to
    capture the whole report. In this case, a small workspace (24K works
    fine) is a win, whether you allocate the workspace when you need it (i.e.,
    during an oops or panic) or at boot time.

    I've verified that this patch works with all accepted values of windowBits
    (positive and negative), memLevel, and compression level.

    Signed-off-by: Jim Keniston
    Cc: Herbert Xu
    Cc: David Miller
    Cc: Chris Mason
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jim Keniston
     

27 Nov, 2010

1 commit


16 Feb, 2010

1 commit


21 Apr, 2008

1 commit

  • On Thu, Mar 27, 2008 at 03:40:36PM +0100, Bodo Eggert wrote:
    > Kamalesh Babulal wrote:
    >
    > > This patch cleanups the crypto code, replaces the init() and fini()
    > > with the _init/_fini
    >
    > This part ist OK.
    >
    > > or init/fini_ (if the
    > > _init/_fini exist)
    >
    > Having init_foo and foo_init won't be a good thing, will it? I'd start
    > confusing them.
    >
    > What about foo_modinit instead?

    Thanks for the suggestion, the init() is replaced with

    _mod_init ()

    and fini () is replaced with _mod_fini.

    Signed-off-by: Kamalesh Babulal
    Signed-off-by: Herbert Xu

    Kamalesh Babulal
     

26 Jun, 2006

2 commits

  • This patch adds the hooks cra_init/cra_exit which are called during a tfm's
    construction and destruction respectively. This will be used by the instances
    to allocate child tfm's.

    For now this lets us get rid of the coa_init/coa_exit functions which are
    used for exactly that purpose (unlike the dia_init function which is called
    for each transaction).

    In fact the coa_exit path is currently buggy as it may get called twice
    when an error is encountered during initialisation.

    Signed-off-by: Herbert Xu

    Herbert Xu
     
  • Up until now algorithms have been happy to get a context pointer since
    they know everything that's in the tfm already (e.g., alignment, block
    size).

    However, once we have parameterised algorithms, such information will
    be specific to each tfm. So the algorithm API needs to be changed to
    pass the tfm structure instead of the context pointer.

    This patch is basically a text substitution. The only tricky bit is
    the assembly routines that need to get the context pointer offset
    through asm-offsets.h.

    Signed-off-by: Herbert Xu

    Herbert Xu
     

21 Mar, 2006

1 commit


17 Apr, 2005

2 commits

  • In the deflate_[compress|uncompress|pcompress] functions we call the
    zlib_[in|de]flateReset function at the beginning. This is OK. But when we
    unload the deflate module we don't call zlib_[in|de]flateEnd to free all
    the zlib internal data. It looks like a bug for me. Please, consider the
    attached patch.

    Signed-off-by: Artem B. Bityuckiy
    Signed-off-by: Herbert Xu
    Cc: "David S. Miller"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Artem B. Bityuckiy
     
  • 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