linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] cls_cgroup: read classid atomically in classifier
@ 2009-05-21 18:31 Paul Menage
  2009-05-21 19:44 ` Jiri Pirko
  0 siblings, 1 reply; 10+ messages in thread
From: Paul Menage @ 2009-05-21 18:31 UTC (permalink / raw)
  To: lizf, akpm, davem, tgraf; +Cc: linux-kernel, netdev

cls_cgroup: read classid atomically in classifier

Avoid reading the unsynchronized value cs->classid multiple times,
since it could change concurrently from non-zero to zero; this would
result in the classifier returning a positive result with a bogus
(zero) classid.

Signed-off-by: Paul Menage <menage@google.com>
Reviewed-by: Li Zefan <lizf@cn.fujitsu.com>

---

Resending to cc netdev@vger.kernel.org as requested by DaveM

 net/sched/cls_cgroup.c |   22 +++++++++++-----------
 1 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/net/sched/cls_cgroup.c b/net/sched/cls_cgroup.c
index 1ab4542..4ece6e0 100644
--- a/net/sched/cls_cgroup.c
+++ b/net/sched/cls_cgroup.c
@@ -98,8 +98,7 @@ static int cls_cgroup_classify(struct sk_buff *skb, struct tcf_proto *tp,
 			       struct tcf_result *res)
 {
 	struct cls_cgroup_head *head = tp->root;
-	struct cgroup_cls_state *cs;
-	int ret = 0;
+        u32 classid;
 
 	/*
 	 * Due to the nature of the classifier it is required to ignore all
@@ -115,17 +114,18 @@ static int cls_cgroup_classify(struct sk_buff *skb, struct tcf_proto *tp,
 		return -1;
 
 	rcu_read_lock();
-	cs = task_cls_state(current);
-	if (cs->classid && tcf_em_tree_match(skb, &head->ematches, NULL)) {
-		res->classid = cs->classid;
-		res->class = 0;
-		ret = tcf_exts_exec(skb, &head->exts, res);
-	} else
-		ret = -1;
-
+	classid = task_cls_state(current)->classid;
 	rcu_read_unlock();
 
-	return ret;
+	if (!classid)
+		return -1;
+
+	if (!tcf_em_tree_match(skb, &head->ematches, NULL))
+		return -1;
+
+	res->classid = classid;
+	res->class = 0;
+	return tcf_exts_exec(skb, &head->exts, res);
 }
 
 static unsigned long cls_cgroup_get(struct tcf_proto *tp, u32 handle)


^ permalink raw reply related	[flat|nested] 10+ messages in thread

* Re: [PATCH] cls_cgroup: read classid atomically in classifier
  2009-05-21 18:31 [PATCH] cls_cgroup: read classid atomically in classifier Paul Menage
@ 2009-05-21 19:44 ` Jiri Pirko
  2009-05-21 22:22   ` David Miller
  0 siblings, 1 reply; 10+ messages in thread
From: Jiri Pirko @ 2009-05-21 19:44 UTC (permalink / raw)
  To: Paul Menage; +Cc: lizf, akpm, davem, tgraf, linux-kernel, netdev

Thu, May 21, 2009 at 08:31:26PM CEST, menage@google.com wrote:
>cls_cgroup: read classid atomically in classifier
>
>Avoid reading the unsynchronized value cs->classid multiple times,
>since it could change concurrently from non-zero to zero; this would
>result in the classifier returning a positive result with a bogus
>(zero) classid.
>
>Signed-off-by: Paul Menage <menage@google.com>
>Reviewed-by: Li Zefan <lizf@cn.fujitsu.com>
>
>---
>
>Resending to cc netdev@vger.kernel.org as requested by DaveM
>
> net/sched/cls_cgroup.c |   22 +++++++++++-----------
> 1 files changed, 11 insertions(+), 11 deletions(-)
>
>diff --git a/net/sched/cls_cgroup.c b/net/sched/cls_cgroup.c
>index 1ab4542..4ece6e0 100644
>--- a/net/sched/cls_cgroup.c
>+++ b/net/sched/cls_cgroup.c
>@@ -98,8 +98,7 @@ static int cls_cgroup_classify(struct sk_buff *skb, struct tcf_proto *tp,
> 			       struct tcf_result *res)
> {
> 	struct cls_cgroup_head *head = tp->root;
>-	struct cgroup_cls_state *cs;
>-	int ret = 0;
>+        u32 classid;
  ^^^^^^^^ How about using TAB instead?
> 
> 	/*
> 	 * Due to the nature of the classifier it is required to ignore all
>@@ -115,17 +114,18 @@ static int cls_cgroup_classify(struct sk_buff *skb, struct tcf_proto *tp,
> 		return -1;
> 
> 	rcu_read_lock();
>-	cs = task_cls_state(current);
>-	if (cs->classid && tcf_em_tree_match(skb, &head->ematches, NULL)) {
>-		res->classid = cs->classid;
>-		res->class = 0;
>-		ret = tcf_exts_exec(skb, &head->exts, res);
>-	} else
>-		ret = -1;
>-
>+	classid = task_cls_state(current)->classid;
> 	rcu_read_unlock();
> 
>-	return ret;
>+	if (!classid)
>+		return -1;
>+
>+	if (!tcf_em_tree_match(skb, &head->ematches, NULL))
>+		return -1;
>+
>+	res->classid = classid;
>+	res->class = 0;
>+	return tcf_exts_exec(skb, &head->exts, res);
> }
> 
> static unsigned long cls_cgroup_get(struct tcf_proto *tp, u32 handle)
>
>--
>To unsubscribe from this list: send the line "unsubscribe netdev" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] cls_cgroup: read classid atomically in classifier
  2009-05-21 19:44 ` Jiri Pirko
@ 2009-05-21 22:22   ` David Miller
  0 siblings, 0 replies; 10+ messages in thread
From: David Miller @ 2009-05-21 22:22 UTC (permalink / raw)
  To: jpirko; +Cc: menage, lizf, akpm, tgraf, linux-kernel, netdev

From: Jiri Pirko <jpirko@redhat.com>
Date: Thu, 21 May 2009 21:44:48 +0200

> Thu, May 21, 2009 at 08:31:26PM CEST, menage@google.com wrote:
>>cls_cgroup: read classid atomically in classifier
>>
>>Avoid reading the unsynchronized value cs->classid multiple times,
>>since it could change concurrently from non-zero to zero; this would
>>result in the classifier returning a positive result with a bogus
>>(zero) classid.
>>
>>Signed-off-by: Paul Menage <menage@google.com>
>>Reviewed-by: Li Zefan <lizf@cn.fujitsu.com>
>>
>>---
>>
>>Resending to cc netdev@vger.kernel.org as requested by DaveM
>>
>> net/sched/cls_cgroup.c |   22 +++++++++++-----------
>> 1 files changed, 11 insertions(+), 11 deletions(-)
>>
>>diff --git a/net/sched/cls_cgroup.c b/net/sched/cls_cgroup.c
>>index 1ab4542..4ece6e0 100644
>>--- a/net/sched/cls_cgroup.c
>>+++ b/net/sched/cls_cgroup.c
>>@@ -98,8 +98,7 @@ static int cls_cgroup_classify(struct sk_buff *skb, struct tcf_proto *tp,
>> 			       struct tcf_result *res)
>> {
>> 	struct cls_cgroup_head *head = tp->root;
>>-	struct cgroup_cls_state *cs;
>>-	int ret = 0;
>>+        u32 classid;
>   ^^^^^^^^ How about using TAB instead?

Agreed, please use proper formatting.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] cls_cgroup: read classid atomically in classifier
  2009-05-26 19:59 Paul Menage
  2009-05-26 21:04 ` Andrew Morton
@ 2009-05-27  3:47 ` David Miller
  1 sibling, 0 replies; 10+ messages in thread
From: David Miller @ 2009-05-27  3:47 UTC (permalink / raw)
  To: menage; +Cc: lizf, akpm, tgraf, linux-kernel, netdev

From: Paul Menage <menage@google.com>
Date: Tue, 26 May 2009 12:59:11 -0700

> cls_cgroup: read classid atomically in classifier
> 
> Avoid reading the unsynchronized value cs->classid multiple times,
> since it could change concurrently from non-zero to zero; this would
> result in the classifier returning a positive result with a bogus
> (zero) classid.
> 
> Signed-off-by: Paul Menage <menage@google.com>
> Reviewed-by: Li Zefan <lizf@cn.fujitsu.com>

Patch applied, thanks!

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] cls_cgroup: read classid atomically in classifier
  2009-05-26 21:04 ` Andrew Morton
@ 2009-05-26 21:39   ` Paul Menage
  0 siblings, 0 replies; 10+ messages in thread
From: Paul Menage @ 2009-05-26 21:39 UTC (permalink / raw)
  To: Andrew Morton; +Cc: lizf, davem, tgraf, linux-kernel, netdev

On Tue, May 26, 2009 at 2:04 PM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Tue, 26 May 2009 12:59:11 -0700
> Paul Menage <menage@google.com> wrote:
>
>> Avoid reading the unsynchronized value cs->classid multiple times,
>> since it could change concurrently from non-zero to zero; this would
>> result in the classifier returning a positive result with a bogus
>> (zero) classid.
>
> When this race occurs, what are the user-visible consequences?

My guess is very little - rather than returning -1 to indicate that
there's no classid associated with the flow, we're returning a
positive response that the classid is 0. I don't know the network
scheduling code well enough to predict what effect that would have,
but I'd guess it results in the subsequent classid->queue lookup
failing and the packet being shunted down some default queue (unless
the user happens to have set up a queue with id 0). But the race looks
to be against the intent of the code, which is to return -1 if the
classid is 0, or fill in the res struct if it's non-zero.

>
> People who need to decide to which kernels a patch should be applied
> like to know such things.
>

I don't think this is a -stable candidate.

Paul

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] cls_cgroup: read classid atomically in classifier
  2009-05-26 19:59 Paul Menage
@ 2009-05-26 21:04 ` Andrew Morton
  2009-05-26 21:39   ` Paul Menage
  2009-05-27  3:47 ` David Miller
  1 sibling, 1 reply; 10+ messages in thread
From: Andrew Morton @ 2009-05-26 21:04 UTC (permalink / raw)
  To: Paul Menage; +Cc: lizf, davem, tgraf, linux-kernel, netdev

On Tue, 26 May 2009 12:59:11 -0700
Paul Menage <menage@google.com> wrote:

> Avoid reading the unsynchronized value cs->classid multiple times,
> since it could change concurrently from non-zero to zero; this would
> result in the classifier returning a positive result with a bogus
> (zero) classid.

When this race occurs, what are the user-visible consequences?

People who need to decide to which kernels a patch should be applied
like to know such things.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [PATCH] cls_cgroup: read classid atomically in classifier
@ 2009-05-26 19:59 Paul Menage
  2009-05-26 21:04 ` Andrew Morton
  2009-05-27  3:47 ` David Miller
  0 siblings, 2 replies; 10+ messages in thread
From: Paul Menage @ 2009-05-26 19:59 UTC (permalink / raw)
  To: lizf, akpm, davem, tgraf; +Cc: linux-kernel, netdev

cls_cgroup: read classid atomically in classifier

Avoid reading the unsynchronized value cs->classid multiple times,
since it could change concurrently from non-zero to zero; this would
result in the classifier returning a positive result with a bogus
(zero) classid.

Signed-off-by: Paul Menage <menage@google.com>
Reviewed-by: Li Zefan <lizf@cn.fujitsu.com>

---

Fixes a whitespace issue from the previous version of the patch

 net/sched/cls_cgroup.c |   22 +++++++++++-----------
 1 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/net/sched/cls_cgroup.c b/net/sched/cls_cgroup.c
index 1ab4542..0f815cc 100644
--- a/net/sched/cls_cgroup.c
+++ b/net/sched/cls_cgroup.c
@@ -98,8 +98,7 @@ static int cls_cgroup_classify(struct sk_buff *skb, struct tcf_proto *tp,
 			       struct tcf_result *res)
 {
 	struct cls_cgroup_head *head = tp->root;
-	struct cgroup_cls_state *cs;
-	int ret = 0;
+	u32 classid;
 
 	/*
 	 * Due to the nature of the classifier it is required to ignore all
@@ -115,17 +114,18 @@ static int cls_cgroup_classify(struct sk_buff *skb, struct tcf_proto *tp,
 		return -1;
 
 	rcu_read_lock();
-	cs = task_cls_state(current);
-	if (cs->classid && tcf_em_tree_match(skb, &head->ematches, NULL)) {
-		res->classid = cs->classid;
-		res->class = 0;
-		ret = tcf_exts_exec(skb, &head->exts, res);
-	} else
-		ret = -1;
-
+	classid = task_cls_state(current)->classid;
 	rcu_read_unlock();
 
-	return ret;
+	if (!classid)
+		return -1;
+
+	if (!tcf_em_tree_match(skb, &head->ematches, NULL))
+		return -1;
+
+	res->classid = classid;
+	res->class = 0;
+	return tcf_exts_exec(skb, &head->exts, res);
 }
 
 static unsigned long cls_cgroup_get(struct tcf_proto *tp, u32 handle)


^ permalink raw reply related	[flat|nested] 10+ messages in thread

* Re: [PATCH] cls_cgroup: read classid atomically in classifier
  2009-05-21  0:49 ` Li Zefan
@ 2009-05-21  3:40   ` David Miller
  0 siblings, 0 replies; 10+ messages in thread
From: David Miller @ 2009-05-21  3:40 UTC (permalink / raw)
  To: lizf; +Cc: menage, akpm, tgraf, linux-kernel, linux-net

From: Li Zefan <lizf@cn.fujitsu.com>
Date: Thu, 21 May 2009 08:49:10 +0800

> (better CC netdev)

linux-net != netdev :-)

Also the original should be sent there so that the patch is
properly tracked at:

	http://patchwork.ozlabs.org/project/netdev/list/

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] cls_cgroup: read classid atomically in classifier
  2009-05-20 17:34 Paul Menage
@ 2009-05-21  0:49 ` Li Zefan
  2009-05-21  3:40   ` David Miller
  0 siblings, 1 reply; 10+ messages in thread
From: Li Zefan @ 2009-05-21  0:49 UTC (permalink / raw)
  To: Paul Menage; +Cc: akpm, davem, tgraf, linux-kernel, linux-net

(better CC netdev)

Paul Menage wrote:
> cls_cgroup: read classid atomically in classifier
> 
> Avoid reading the unsynchronized value cs->classid multiple times,
> since it could change concurrently from non-zero to zero; this would
> result in the classifier returning a positive result with a bogus
> (zero) classid.
> 

This patch looks nice. It also narrows rcu read section.

Reviewed-by: Li Zefan <lizf@cn.fujitsu.com>

> Signed-off-by: Paul Menage <menage@google.com>
> 
> ---
> 
>  net/sched/cls_cgroup.c |   22 +++++++++++-----------
>  1 files changed, 11 insertions(+), 11 deletions(-)
> 
> diff --git a/net/sched/cls_cgroup.c b/net/sched/cls_cgroup.c
> index 1ab4542..4ece6e0 100644
> --- a/net/sched/cls_cgroup.c
> +++ b/net/sched/cls_cgroup.c
> @@ -98,8 +98,7 @@ static int cls_cgroup_classify(struct sk_buff *skb, struct tcf_proto *tp,
>  			       struct tcf_result *res)
>  {
>  	struct cls_cgroup_head *head = tp->root;
> -	struct cgroup_cls_state *cs;
> -	int ret = 0;
> +        u32 classid;
>  
>  	/*
>  	 * Due to the nature of the classifier it is required to ignore all
> @@ -115,17 +114,18 @@ static int cls_cgroup_classify(struct sk_buff *skb, struct tcf_proto *tp,
>  		return -1;
>  
>  	rcu_read_lock();
> -	cs = task_cls_state(current);
> -	if (cs->classid && tcf_em_tree_match(skb, &head->ematches, NULL)) {
> -		res->classid = cs->classid;
> -		res->class = 0;
> -		ret = tcf_exts_exec(skb, &head->exts, res);
> -	} else
> -		ret = -1;
> -
> +	classid = task_cls_state(current)->classid;
>  	rcu_read_unlock();
>  
> -	return ret;
> +	if (!classid)
> +		return -1;
> +
> +	if (!tcf_em_tree_match(skb, &head->ematches, NULL))
> +		return -1;
> +
> +	res->classid = classid;
> +	res->class = 0;
> +	return tcf_exts_exec(skb, &head->exts, res);
>  }
>  
>  static unsigned long cls_cgroup_get(struct tcf_proto *tp, u32 handle)
> 
> 
> 

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [PATCH] cls_cgroup: read classid atomically in classifier
@ 2009-05-20 17:34 Paul Menage
  2009-05-21  0:49 ` Li Zefan
  0 siblings, 1 reply; 10+ messages in thread
From: Paul Menage @ 2009-05-20 17:34 UTC (permalink / raw)
  To: lizf, akpm, davem, tgraf; +Cc: linux-kernel

cls_cgroup: read classid atomically in classifier

Avoid reading the unsynchronized value cs->classid multiple times,
since it could change concurrently from non-zero to zero; this would
result in the classifier returning a positive result with a bogus
(zero) classid.

Signed-off-by: Paul Menage <menage@google.com>

---

 net/sched/cls_cgroup.c |   22 +++++++++++-----------
 1 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/net/sched/cls_cgroup.c b/net/sched/cls_cgroup.c
index 1ab4542..4ece6e0 100644
--- a/net/sched/cls_cgroup.c
+++ b/net/sched/cls_cgroup.c
@@ -98,8 +98,7 @@ static int cls_cgroup_classify(struct sk_buff *skb, struct tcf_proto *tp,
 			       struct tcf_result *res)
 {
 	struct cls_cgroup_head *head = tp->root;
-	struct cgroup_cls_state *cs;
-	int ret = 0;
+        u32 classid;
 
 	/*
 	 * Due to the nature of the classifier it is required to ignore all
@@ -115,17 +114,18 @@ static int cls_cgroup_classify(struct sk_buff *skb, struct tcf_proto *tp,
 		return -1;
 
 	rcu_read_lock();
-	cs = task_cls_state(current);
-	if (cs->classid && tcf_em_tree_match(skb, &head->ematches, NULL)) {
-		res->classid = cs->classid;
-		res->class = 0;
-		ret = tcf_exts_exec(skb, &head->exts, res);
-	} else
-		ret = -1;
-
+	classid = task_cls_state(current)->classid;
 	rcu_read_unlock();
 
-	return ret;
+	if (!classid)
+		return -1;
+
+	if (!tcf_em_tree_match(skb, &head->ematches, NULL))
+		return -1;
+
+	res->classid = classid;
+	res->class = 0;
+	return tcf_exts_exec(skb, &head->exts, res);
 }
 
 static unsigned long cls_cgroup_get(struct tcf_proto *tp, u32 handle)


^ permalink raw reply related	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2009-05-27  3:47 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-05-21 18:31 [PATCH] cls_cgroup: read classid atomically in classifier Paul Menage
2009-05-21 19:44 ` Jiri Pirko
2009-05-21 22:22   ` David Miller
  -- strict thread matches above, loose matches on Subject: below --
2009-05-26 19:59 Paul Menage
2009-05-26 21:04 ` Andrew Morton
2009-05-26 21:39   ` Paul Menage
2009-05-27  3:47 ` David Miller
2009-05-20 17:34 Paul Menage
2009-05-21  0:49 ` Li Zefan
2009-05-21  3:40   ` David Miller

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).