* [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).