crypto_alloc_tfm() returns an error-valued pointer in case of failure,
which must not be translated using __crypto_shash_cast().
Currently everything works fine because __crypto_shash_cast() is a no-op
(crypto_shash.base is at offset zero).
Signed-off-by: Geert Uytterhoeven
---
crypto/shash.c |
On Tue, 17 Feb 2009, Pekka Enberg wrote:
> Hmm, kmem_cache_size() seems bit pointless to me. For
> kmem_cache_create()'d caches, actual allocated size should be more or
> less optimal with no extra space.
Cacheline alignment and word alignment etc etc can still add some space to
the object.
--
T
On Tue, Feb 17, 2009 at 6:17 PM, Christoph Lameter
wrote:
> On Sun, 15 Feb 2009, Matt Mackall wrote:
>
>> And it -is- a category error. The fact that kmalloc is implemented on
>> top of kmem_cache_alloc is an implementation detail that callers should
>> not assume. They shouldn't call kfree() on k
On Sun, 15 Feb 2009, Matt Mackall wrote:
> And it -is- a category error. The fact that kmalloc is implemented on
> top of kmem_cache_alloc is an implementation detail that callers should
> not assume. They shouldn't call kfree() on kmem_cache_alloc objects
> (even though it might just happen to wo
Hi Linus:
This push fixes LRW (used for disk encryption) on big endian.
It turns out that it just never worked over there. Based on
the fact that nobody screamed about it after the addition of
mandatory testing, it seems that it just isn't used so we don't
have to worry about existing big-endian
On Sun, 15 Feb 2009, Matt Mackall wrote:
> On Sun, 2009-02-15 at 17:00 -0800, Andrew Morton wrote:
> > On Sun, 15 Feb 2009 17:49:41 -0600 Matt Mackall wrote:
>
> > The whole concept is quite hacky and nasty, isn't it?.
>
> It is, which is part of why we were trying to kill it. The primary users
