[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090428154213.GA10833@linux.vnet.ibm.com>
Date: Tue, 28 Apr 2009 08:42:13 -0700
From: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
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,
mathieu.desnoyers@...ymtl.ca, jarkao2@...il.com, paulus@...ba.org,
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}
On Tue, Apr 28, 2009 at 06:43:40AM -0700, David Miller 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 way I did this in treercu.c was to create an array of references
to the per-CPU data in question. Not necessarily recommended, but
one way of doing it. That said, one could argue that we should wait
until we have at least three users before creating a generic primitive.
And I just know that I am going to regret this deeply, but I cannot
resist posting the following URL:
http://en.wikipedia.org/wiki/Wikipedia:Avoid_Parkinson's_Bicycle_Shed_Effect
Thanx, Paul
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists