From: Eric Dumazet <eric.dumazet@gmail.com>
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org, hagen@jauu.net, xiaosuo@gmail.com,
wirelesser@gmail.com,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
stable@kernel.org, Pavel Emelyanov <xemul@openvz.org>
Subject: PATCH] filter: fix sk_filter rcu handling
Date: Sun, 05 Dec 2010 21:53:52 +0100 [thread overview]
Message-ID: <1291582432.2806.300.camel@edumazet-laptop> (raw)
In-Reply-To: <1291357953.2854.46.camel@edumazet-laptop>
Le vendredi 03 décembre 2010 à 07:32 +0100, Eric Dumazet a écrit :
> Le mercredi 01 décembre 2010 à 10:18 -0800, David Miller a écrit :
>
> > However, I think it's still valuable to write a few JIT compilers for
> > the existing BPF stuff. I considered working on a sparc64 JIT just to
> > see what it would look like.
> >
> > If people work on the BPF optimizer and BPF JITs in parallel, we'll have
> > both ready at the same time. win++
>
> I began work on implementing a BPF JIT for x86_64
>
> My plan is to use external helpers to load skb data/metadata, to keep
> BPF program very short and have no dependencies against struct layouts.
>
> These helpers would be the three load_word, load_half, load_byte.
>
> In case the bits are in skb head, these helpers should be fast.
>
> For practical reasons, they would be in ASM for their fast path, and C
> for the slow path. They are ASM because they are able to perform the
> shortcut (in case of error, doing the stack unwind to perform the
> "return 0;") so that we dont have to test their return from the JIT
> program.
>
>
While working on this, I found an annoying problem with current code.
This patch is a stable candidate.
Thanks
[PATCH] filter: fix sk_filter rcu handling
Pavel Emelyanov tried to fix a race between sk_filter_(de|at)tach and
sk_clone() in commit 47e958eac280c263397
Problem is we can have several clones sharing a common sk_filter, and
these clones might want to sk_filter_attach() their own filters at the
same time, and can overwrite old_filter->rcu, corrupting RCU queues.
We can not use filter->rcu without being sure no other thread could do
the same thing.
Switch code to a more conventional ref-counting technique : Do the
atomic decrement immediately and queue one rcu call back when last
reference is released.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Pavel Emelyanov <xemul@openvz.org>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: stable@kernel.org
---
include/net/sock.h | 4 +++-
net/core/filter.c | 19 ++++++-------------
2 files changed, 9 insertions(+), 14 deletions(-)
diff --git a/include/net/sock.h b/include/net/sock.h
index a6338d0..4308af7 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -1155,6 +1155,8 @@ extern void sk_common_release(struct sock *sk);
/* Initialise core socket variables */
extern void sock_init_data(struct socket *sock, struct sock *sk);
+extern void sk_filter_release_rcu(struct rcu_head *rcu);
+
/**
* sk_filter_release - release a socket filter
* @fp: filter to remove
@@ -1165,7 +1167,7 @@ extern void sock_init_data(struct socket *sock, struct sock *sk);
static inline void sk_filter_release(struct sk_filter *fp)
{
if (atomic_dec_and_test(&fp->refcnt))
- kfree(fp);
+ call_rcu_bh(&fp->rcu, sk_filter_release_rcu);
}
static inline void sk_filter_uncharge(struct sock *sk, struct sk_filter *fp)
diff --git a/net/core/filter.c b/net/core/filter.c
index c1ee800..ae21a0d 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -589,23 +589,16 @@ int sk_chk_filter(struct sock_filter *filter, int flen)
EXPORT_SYMBOL(sk_chk_filter);
/**
- * sk_filter_rcu_release - Release a socket filter by rcu_head
+ * sk_filter_release_rcu - Release a socket filter by rcu_head
* @rcu: rcu_head that contains the sk_filter to free
*/
-static void sk_filter_rcu_release(struct rcu_head *rcu)
+void sk_filter_release_rcu(struct rcu_head *rcu)
{
struct sk_filter *fp = container_of(rcu, struct sk_filter, rcu);
- sk_filter_release(fp);
-}
-
-static void sk_filter_delayed_uncharge(struct sock *sk, struct sk_filter *fp)
-{
- unsigned int size = sk_filter_len(fp);
-
- atomic_sub(size, &sk->sk_omem_alloc);
- call_rcu_bh(&fp->rcu, sk_filter_rcu_release);
+ kfree(fp);
}
+EXPORT_SYMBOL(sk_filter_release_rcu);
/**
* sk_attach_filter - attach a socket filter
@@ -649,7 +642,7 @@ int sk_attach_filter(struct sock_fprog *fprog, struct sock *sk)
rcu_assign_pointer(sk->sk_filter, fp);
if (old_fp)
- sk_filter_delayed_uncharge(sk, old_fp);
+ sk_filter_uncharge(sk, old_fp);
return 0;
}
EXPORT_SYMBOL_GPL(sk_attach_filter);
@@ -663,7 +656,7 @@ int sk_detach_filter(struct sock *sk)
sock_owned_by_user(sk));
if (filter) {
rcu_assign_pointer(sk->sk_filter, NULL);
- sk_filter_delayed_uncharge(sk, filter);
+ sk_filter_uncharge(sk, filter);
ret = 0;
}
return ret;
_______________________________________________
stable mailing list
stable@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/stable
next prev parent reply other threads:[~2010-12-05 20:53 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-30 9:22 multi bpf filter will impact performance? Rui
2010-11-30 9:34 ` Eric Dumazet
[not found] ` <AANLkTi=VpmnrXTBNV7McQm6mq9ULT7KTKbM8_hLPoL=2@mail.gmail.com>
[not found] ` <1291127670.2904.96.camel@edumazet-laptop>
2010-12-01 3:48 ` Rui
2010-12-01 4:03 ` Eric Dumazet
2010-12-01 7:45 ` [PATCH net-next-2.6] filter: add SKF_AD_RXHASH and SKF_AD_CPU Eric Dumazet
2010-12-01 8:03 ` Changli Gao
2010-12-06 21:02 ` David Miller
2010-12-03 9:40 ` multi bpf filter will impact performance? Junchang Wang
2010-12-01 7:36 ` Changli Gao
2010-12-01 7:47 ` Eric Dumazet
2010-12-01 7:59 ` Changli Gao
2010-12-01 8:09 ` Eric Dumazet
2010-12-01 8:15 ` Changli Gao
2010-12-01 8:42 ` Eric Dumazet
2010-12-01 17:22 ` Hagen Paul Pfeifer
2010-12-01 18:18 ` David Miller
2010-12-01 18:24 ` David Miller
2010-12-01 18:24 ` Eric Dumazet
2010-12-01 18:44 ` David Miller
2010-12-01 19:48 ` Eric Dumazet
2010-12-01 20:23 ` David Miller
2010-12-01 20:45 ` [PATCH net-next-2.6] filter: add a security check at install time Eric Dumazet
2010-12-02 2:30 ` Changli Gao
2010-12-02 6:46 ` Eric Dumazet
2010-12-02 8:11 ` Changli Gao
2010-12-02 8:53 ` Eric Dumazet
2010-12-02 9:00 ` Eric Dumazet
2010-12-02 9:10 ` Changli Gao
2010-12-02 9:54 ` Eric Dumazet
2010-12-02 10:10 ` Changli Gao
2010-12-02 11:15 ` Eric Dumazet
2010-12-02 11:29 ` Changli Gao
2010-12-02 13:14 ` Eric Dumazet
2010-12-02 10:59 ` Changli Gao
2010-12-06 21:07 ` David Miller
2010-12-03 6:32 ` multi bpf filter will impact performance? Eric Dumazet
2010-12-05 20:53 ` Eric Dumazet [this message]
2010-12-05 21:08 ` PATCH] filter: fix sk_filter rcu handling Andi Kleen
2010-12-05 21:28 ` Eric Dumazet
2010-12-06 17:29 ` David Miller
2010-11-30 10:01 ` multi bpf filter will impact performance? Eric Dumazet
2010-11-30 11:17 ` Eric Dumazet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1291582432.2806.300.camel@edumazet-laptop \
--to=eric.dumazet@gmail.com \
--cc=davem@davemloft.net \
--cc=hagen@jauu.net \
--cc=netdev@vger.kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=stable@kernel.org \
--cc=wirelesser@gmail.com \
--cc=xemul@openvz.org \
--cc=xiaosuo@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox