Messages in this thread | | | Date | Wed, 25 Mar 2015 16:11:16 +0100 | From | Patrick Marlier <> | Subject | Re: [PATCH 2/3] netfilter: fix list_entry_rcu usage. |
| |
On 03/25/2015 03:36 PM, Paul E. McKenney wrote: > On Tue, Mar 24, 2015 at 11:31:44AM +0100, Patrick Marlier wrote: >> >Signed-off-by: Patrick Marlier<patrick.marlier@gmail.com> >> >--- >> > net/netfilter/core.c | 2 +- >> > 1 file changed, 1 insertion(+), 1 deletion(-) >> > >> >diff --git a/net/netfilter/core.c b/net/netfilter/core.c >> >index fea9ef5..05bd311 100644 >> >--- a/net/netfilter/core.c >> >+++ b/net/netfilter/core.c >> >@@ -174,7 +174,7 @@ int nf_hook_slow(u_int8_t pf, unsigned int hook, >> >struct sk_buff *skb, >> > /* We may already have this, but read-locks nest anyway */ >> > rcu_read_lock(); >> > >> >- elem = list_entry_rcu(&nf_hooks[pf][hook], struct nf_hook_ops, list); >> >+ elem = list_entry_rcu(nf_hooks[pf][hook].next, struct nf_hook_ops, list); > And this departs from the list_entry() API. Is this really a good idea?
No opinion on that but AFAIK there are only 2 spots in the whole kernel source where the ".next" is not used with list_entry_rcu. -- Patrick Marlier
| |