Skip to contentSkip to conversation

netfilter: fix list_entry_rcu usage.

PATCH In review Patrick Marlier 2 participants 3 messages Mar 24, 2015 – Mar 25, 2015

Subsystems (2)
Networking netfilter
lore
Share & tools
lore

Patrick Marlier

author
#0 lore raw

PATCH 2/3 netfilter: fix list_entry_rcu usage.

Signed-off-by Patrick Marlier <[email protected]>
---
 net/netfilter/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
net/netfilter/core.c +1 -1
index fea9ef5..05bd311 100644
@@ -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);
 next_hook:
    verdict = nf_iterate(&nf_hooks[pf][hook], skb, hook, indev,
                 outdev, &elem, okfn, hook_thresh);
Signature · 1 line
2.1.0
#1 lore raw
Quoted 10 lines · Patrick Marlier
Signed-off-by Patrick Marlier <[email protected]>
---
 net/netfilter/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
net/netfilter/core.c +0 -0
index fea9ef5..05bd311 100644

net/netfilter/core.c int nf_hook_slow(u_int8_t pf, unsigned int hook, · line 178

Quoted 6 lines
net/netfilter/core.c +1 -1
@@ -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?

Thanx, Paul

Quoted 11 lines
net/netfilter/core.c +0 -0
 next_hook:
    verdict = nf_iterate(&nf_hooks[pf][hook], skb, hook, indev,

                 outdev, &elem, okfn, hook_thresh);
Signature · 7 lines
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
author
#2 lore raw
Quoted 15 lines · Paul E. McKenney
Quoted 14 lines · Patrick Marlier
Quoted 14 lines
Signed-off-by Patrick Marlier<[email protected]>
---
 net/netfilter/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
net/netfilter/core.c +0 -0
index fea9ef5..05bd311 100644
@@ -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();
Quoted 3 lines
Quoted 2 lines

net/netfilter/core.c int nf_hook_slow(u_int8_t pf, unsigned int hook, struct sk_buff *skb, · line 177

Quoted 2 lines
net/netfilter/core.c +1 -1
-   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