[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090428135219.GA28513@Krystal>
Date: Tue, 28 Apr 2009 09:52:19 -0400
From: Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
To: David Miller <davem@...emloft.net>
Cc: mingo@...e.hu, dada1@...mosbay.com, torvalds@...ux-foundation.org,
shemminger@...tta.com, zbr@...emap.net, peterz@...radead.org,
jarkao2@...il.com, paulus@...ba.org, paulmck@...ux.vnet.ibm.com,
kaber@...sh.net, jeff.chua.linux@...il.com, laijs@...fujitsu.com,
jengelh@...ozas.de, r000n@...0n.net, linux-kernel@...r.kernel.org,
netfilter-devel@...r.kernel.org, netdev@...r.kernel.org,
benh@...nel.crashing.org
Subject: Re: [PATCH] netfilter: use per-CPU r**ursive lock {XV}
* David Miller (davem@...emloft.net) wrote:
> From: Ingo Molnar <mingo@...e.hu>
> Date: Tue, 28 Apr 2009 14:40:33 +0200
>
> > IMHO this locking construct should be considered for
> > linux/local_lock.h and kernel/local_lock.c. Even if the netfilter
> > code drops its use soon afterwards ;-)
>
> If you can show me have to pass a per-cpu variable (the variable,
> not a dereference of it) as an argument to an inline function,
> I'll implement this :-)
>
> It has to be dereferenced after local_bh_disable() for the
> read side acquisition.
The local_bh_disable() could be outside of the locking construct. This
would make it easier to adapt it to various users (irq disable, bh
disable, preempt disable) depending on the contexts from which they much
be protected.
And if it still does not work for some reason, using a #define is
discouraged, but could work.
Mathieu
--
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists