>From a465fcee388d62d22e390b57c81ca8411f25a1da Mon Sep 17 00:00:00 2001
From: Tejun Heo
Date: Fri, 13 Jul 2012 22:16:45 -0700
WQ_HIGHPRI was implemented by queueing highpri work items at the head
of the global worklist. Other than queueing at the head, they weren't
handled differently; unfortuna
>From 4ce62e9e30cacc26885cab133ad1de358dd79f21 Mon Sep 17 00:00:00 2001
From: Tejun Heo
Date: Fri, 13 Jul 2012 22:16:44 -0700
Introduce NR_WORKER_POOLS and for_each_worker_pool() and convert code
paths which need to manipulate all pools in a gcwq to use them.
NR_WORKER_POOLS is currently one and
Hey, Linus.
On Fri, Jul 13, 2012 at 10:00:10PM -0700, Linus Torvalds wrote:
> On Fri, Jul 13, 2012 at 9:44 PM, Tejun Heo wrote:
> >
> > nr_running is atomic_t (*nr_running)[2]. Ignoring the pointer to
> > array part, it's just returning the address of N'th element of the
> > array. ARRAY + N ==
On Fri, Jul 13, 2012 at 9:44 PM, Tejun Heo wrote:
>
> nr_running is atomic_t (*nr_running)[2]. Ignoring the pointer to
> array part, it's just returning the address of N'th element of the
> array. ARRAY + N == &ARRAY[N].
None of this matters one whit.
You did "&(x)[0]".
That's insane. It's cr
Hello, Linus.
On Fri, Jul 13, 2012 at 09:27:03PM -0700, Linus Torvalds wrote:
> Seeing code like this
>
> + return &(*nr_running)[0];
>
> just makes me go "WTF?"
I was going WTF too. This was the smallest fix and I wanted to make
it minimal because there's another stack of patches on top
Seeing code like this
+ return &(*nr_running)[0];
just makes me go "WTF?"
Why are you taking the address of something you just dereferenced (the
"& [0]" part).
And you actually do that *twice*, except the inner one is more
complicated. When you assign nr_runing, you take the address of it
>From 12f804d130d966f2a094e8037e9f163215d13f23 Mon Sep 17 00:00:00 2001
From: Tejun Heo
Date: Fri, 13 Jul 2012 20:50:50 -0700
WQ_HIGHPRI was implemented by queueing highpri work items at the head
of the global worklist. Other than queueing at the head, they weren't
handled differently; unfortuna
>From 8a0597bf9939d50039d4a6f446db51cf920daaad Mon Sep 17 00:00:00 2001
From: Tejun Heo
Date: Fri, 13 Jul 2012 20:50:50 -0700
Introduce NR_WORKER_POOLS and for_each_worker_pool() and convert code
paths which need to manipulate all pools in a gcwq to use them.
NR_WORKER_POOLS is currently one and
Hello,
On Fri, Jul 13, 2012 at 10:08:00AM +0800, Fengguang Wu wrote:
> [0.165669] Performance Events: unsupported Netburst CPU model 6 no PMU
> driver, software events only.
> [0.167001] XXX cpu=0 gcwq=88000dc0cfc0 base=88000dc11e80
> [0.167989] XXX cpu=0 nr_running=0 @ 88
commit "crypto: caam - use non-irq versions of spinlocks for job rings"
made two bad assumptions:
(a) The caam_jr_enqueue lock isn't used in softirq context.
Not true: jr_enqueue can be interrupted by an incoming net
interrupt and the received packet may be sent for encryption,
via caam_jr_enqueue
SHARE_WAIT, whilst more optimal for association-less crypto,
has the ability to start thrashing the CCB descriptor/key
caches, given high levels of traffic across multiple security
associations (and thus keys).
Switch to using the SERIAL sharing type, which prefers
the last used CCB for the SA. O
From: Shengzhou Liu
In some device trees of previous version, there were string "fsl,sec4.0".
To be backward compatible with device trees, we first check "fsl,sec-v4.0",
if it fails, then check for "fsl,sec4.0".
Signed-off-by: Shengzhou Liu
extended to include new hash and rng code, which was
commit "crypto: caam - use non-irq versions of spinlocks for job rings"
made two bad assumptions:
(a) The caam_jr_enqueue lock isn't used in softirq context.
Not true: jr_enqueue can be interrupted by an incoming net
interrupt and the received packet may be sent for encryption,
via caam_jr_enqueue
On Thu, Jul 12, 2012 at 4:46 PM, Tony Luck wrote:
> Still hasn't come back in three reboots. I have to leave now, can continue
> tomorrow.
Tired of rebooting ... seems that it is very hard to hit this with
this patch :-(
-Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-c
On Wed, Jul 11, 2012 at 02:20:56PM +0300, Jussi Kivilinna wrote:
> 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
> l
15 matches
Mail list logo
