From: Greg KH <greg@kroah.com>
To: Paul Menage <menage@google.com>
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] cgroups: fix probable race with put_css_set[_taskexit] and find_css_set
Date: Tue, 9 Sep 2008 23:17:17 -0700 [thread overview]
Message-ID: <20080910061717.GA6301@kroah.com> (raw)
In-Reply-To: <6599ad830809092231h90712a6mc95b81229d64d6bc@mail.gmail.com>
On Tue, Sep 09, 2008 at 10:31:24PM -0700, Paul Menage wrote:
> On Tue, Sep 9, 2008 at 10:01 PM, Greg KH <greg@kroah.com> wrote:
> >
> > What are you trying to solve here with this change? I agree, it does
> > seem a bit "chaotic" :)
>
> There's a place in cgroups that uses kref_put() to release an object;
> the release function *then* takes a write-lock and removes the object
> from a lookup table; it could race with another thread that searches
> the lookup table (while holding a read-lock) and does kref_get() on
> the same object.
Ick, yeah that's not good.
What about the way everyone else solves this, grab the lock before you
call kref_put()?
> The current fix is for the release function to recheck inside the lock
> that the object's refcount is still zero, and only actually
> unlink/free it if so. And actually I've just realised that this isn't
> actually even safe, since the thread that just acquired the object
> could kref_put() it almost immediately, which would leave two threads
> both trying to unlink/free the object.
Yeah, don't do that :)
thanks,
greg k-h
next prev parent reply other threads:[~2008-09-10 6:18 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
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 [this message]
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=20080910061717.GA6301@kroah.com \
--to=greg@kroah.com \
--cc=akpm@linux-foundation.org \
--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.