Le vendredi 13 janvier 2012 à 11:45 +, David Laight a écrit :
> > Trying a dynamic memory allocation, and fallback on a single
> > pre-allocated bloc of memory, shared by all cpus, protected by a
> > spinlock
> ...
> > -
> > + static u64 msg_schedule[80];
> > + static DEFINE_SPINLOCK(msg_sc
Le vendredi 13 janvier 2012 à 13:33 +0200, Alexey Dobriyan a écrit :
> On 1/13/12, Eric Dumazet wrote:
>
> > + static u64 msg_schedule[80];
> > + static DEFINE_SPINLOCK(msg_schedule_lock);
>
> No guys, no.
>
> SHA-512 only needs u64[16] running window for message scheduling.
>
> I'm sendin
> Trying a dynamic memory allocation, and fallback on a single
> pre-allocated bloc of memory, shared by all cpus, protected by a
> spinlock
...
> -
> + static u64 msg_schedule[80];
> + static DEFINE_SPINLOCK(msg_schedule_lock);
> int i;
> - u64 *W = get_cpu_var(msg_schedule);
>
On 1/13/12, Eric Dumazet wrote:
> + static u64 msg_schedule[80];
> + static DEFINE_SPINLOCK(msg_schedule_lock);
No guys, no.
SHA-512 only needs u64[16] running window for message scheduling.
I'm sending whitespace mangled patch which is only tested
with selfcryptotest passed, so you wo
On Fri, Jan 13, 2012 at 11:35:42AM +0100, Eric Dumazet wrote:
> Le vendredi 13 janvier 2012 à 18:08 +1100, Herbert Xu a écrit :
> > On Fri, Jan 13, 2012 at 02:55:14AM +0300, Alexey Dobriyan wrote:
> > >
> > > Herbert, I couldn't come up with a single scenario. :-(
> > > But the bug is easy to repro
Le vendredi 13 janvier 2012 à 11:41 +0100, Eric Dumazet a écrit :
> And a plain kmalloc() is enough, since we fully initialize the array a
> bit later.
>
> for (i = 0; i < 16; i++)
> LOAD_OP(i, W, input);
> for (i = 16; i < 80; i++) {
> BLEND_OP(i, W);
>
Le vendredi 13 janvier 2012 à 11:35 +0100, Eric Dumazet a écrit :
> I wonder ...
>
> With 4096 cpus, do we really want to reserve 5242880 bytes of memory for
> this function ?
>
> What about following patch instead ?
>
> (Trying a dynamic memory allocation, and fallback on a single
> pre-alloca
Le vendredi 13 janvier 2012 à 18:08 +1100, Herbert Xu a écrit :
> On Fri, Jan 13, 2012 at 02:55:14AM +0300, Alexey Dobriyan wrote:
> >
> > Herbert, I couldn't come up with a single scenario. :-(
> > But the bug is easy to reproduce.
>
> OK, does this patch work for you?
>
> commit 31f4e55c09c1170
> Good catch. It can be generalized to any interrupts (soft and hard)
>
> Another solution is using two blocks, one used from interrupt context.
>
> static DEFINE_PER_CPU(u64[80], msg_schedule);
> static DEFINE_PER_CPU(u64[80], msg_schedule_irq);
>
> (Like we do for SNMP mibs on !x86 arches)
