Netdev List
 help / color / mirror / Atom feed
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

  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