From: Li Zefan <lizf@cn.fujitsu.com>
To: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: Paul Menage <menage@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Greg Kroah-Hartman <greg@kroah.com>
Subject: Re: [PATCH] cgroups: fix probable race with put_css_set[_taskexit] and find_css_set
Date: Wed, 10 Sep 2008 10:40:34 +0800 [thread overview]
Message-ID: <48C733A2.2050709@cn.fujitsu.com> (raw)
In-Reply-To: <48C72E7C.8080302@cn.fujitsu.com>
Lai Jiangshan wrote:
> Paul Menage wrote:
>> On Mon, Aug 18, 2008 at 11:29 PM, Lai Jiangshan <laijs@cn.fujitsu.com> wrote:
>>
>> 2) Use atomic_inc_not_zero() in find_existing_css_set(), to ensure
>> that we only return a referenced css, and remove the get_css_set()
>> call from find_css_set(). (Possibly wrapping this in a new
>> kref_get_not_zero() function)
>>
>
> [CC: Greg Kroah-Hartman <greg@kroah.com>]
>
> There are indeed several ways fix this race by Using the
> atomic-functions directly. I prefer the second one, i makes all
> code clearly. And put_css_set[_taskexit] do not need to be changed.
>
> I don't think adding kref_get_not_zero() API is a good idea.
> It will bring kref APIs to a little chaos, kref_get_not_zero() is
> hard to be used, for this function needs a special lock held.
>
> But I tried:
>
> Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
> ---
> diff --git a/include/linux/kref.h b/include/linux/kref.h
> index 0cef6ba..400ffab 100644
> --- a/include/linux/kref.h
> +++ b/include/linux/kref.h
> @@ -25,6 +25,7 @@ struct kref {
> void kref_set(struct kref *kref, int num);
> void kref_init(struct kref *kref);
> void kref_get(struct kref *kref);
> +int kref_get_not_zero(struct kref *kref);
> int kref_put(struct kref *kref, void (*release) (struct kref *kref));
>
> #endif /* _KREF_H_ */
> diff --git a/kernel/cgroup.c b/kernel/cgroup.c
> index 13932ab..0bbb98d 100644
> --- a/kernel/cgroup.c
> +++ b/kernel/cgroup.c
> @@ -347,6 +347,8 @@ static struct css_set *find_existing_css_set(
> hlist_for_each_entry(cg, node, hhead, hlist) {
> if (!memcmp(template, cg->subsys, sizeof(cg->subsys))) {
> /* All subsystems matched */
> + if (!kref_get_not_zero(&cg->ref))
> + return NULL;
Better add comments to explain why we might get 0 refcount here.
> return cg;
> }
> }
> @@ -410,8 +412,6 @@ static struct css_set *find_css_set(
> * the desired set */
> read_lock(&css_set_lock);
> res = find_existing_css_set(oldcg, cgrp, template);
> - if (res)
> - get_css_set(res);
> read_unlock(&css_set_lock);
>
> if (res)
> diff --git a/lib/kref.c b/lib/kref.c
> index 9ecd6e8..b8c1ce6 100644
> --- a/lib/kref.c
> +++ b/lib/kref.c
> @@ -46,6 +46,25 @@ void kref_get(struct kref *kref)
> }
>
> /**
> + * kref_get_not_zero - increment refcount for object if current refcount
> + * is not zero.
> + * @kref: object.
> + *
> + * Beware, the object maybe be being released, so we need a special lock held
s/maybe be being/may be being/
> + * to ensure the object's refcount is remaining access.
> + *
need better wording... what do you mean by "remaining access"? to ensure the object
is remaining valid?
> + * Return 0 if this refcount is 0, otherwise return 1.
> + */
> +int kref_get_not_zero(struct kref *kref)
> +{
> + if (atomic_inc_not_zero(&kref->refcount)) {
> + smp_mb__after_atomic_inc();
> + return 1;
> + }
> + return 0;
> +}
> +
> +/**
> * kref_put - decrement refcount for object.
> * @kref: object.
> * @release: pointer to the function that will clean up the object when the
>
>
next prev parent reply other threads:[~2008-09-10 2:41 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-19 6:29 [PATCH] cgroups: fix probable race with put_css_set[_taskexit] and find_css_set Lai Jiangshan
2008-09-10 0:28 ` Paul Menage
2008-09-10 2:18 ` Lai Jiangshan
2008-09-10 2:40 ` Li Zefan [this message]
2008-09-10 3:11 ` Paul Menage
2008-09-10 5:01 ` Greg KH
2008-09-10 5:31 ` Paul Menage
2008-09-10 6:17 ` Greg KH
2008-09-10 6:25 ` Li Zefan
2008-09-10 6:29 ` Greg KH
2008-09-10 15:03 ` Paul Menage
2008-09-12 15:58 ` Greg KH
2008-09-12 19:33 ` Paul Menage
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=48C733A2.2050709@cn.fujitsu.com \
--to=lizf@cn.fujitsu.com \
--cc=akpm@linux-foundation.org \
--cc=greg@kroah.com \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=menage@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.