[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080912155804.GB3610@kroah.com>
Date: Fri, 12 Sep 2008 08:58:04 -0700
From: Greg KH <greg@...ah.com>
To: Paul Menage <menage@...gle.com>
Cc: Li Zefan <lizf@...fujitsu.com>,
Lai Jiangshan <laijs@...fujitsu.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] cgroups: fix probable race with put_css_set[_taskexit]
and find_css_set
On Wed, Sep 10, 2008 at 08:03:18AM -0700, Paul Menage wrote:
> On Tue, Sep 9, 2008 at 11:29 PM, Greg KH <greg@...ah.com> wrote:
> >
> > But you can't put such logic in the release() function as you are
> > finding out, that's not going to work either.
>
> Right - that's why a kref_put_and_write_lock() function would be handy
> - it would take the lock only when necessary. It would delegate most
> of its work to the (as-yet nonexistant) atomic_dec_and_write_lock()
> function, which would be an rwlock equivalent of atomic_dec_and_lock()
>
> >
> > Maybe you need to just "open-code" an atomic counter here and not use
> > kref as it sounds like you are needing to do something very "special"
> > here.
> >
>
> It's basically the same situation as the dentry cache - ref-counted
> objects that are also referenced from a hash table protected by a
> global lock.
>
> If you're opposed to the addition of kref_put_and_write_lock() then
> yes, I'll replace kref with a custom refcount.
It just seems messy, but if you want to try it, I'll be glad to look at
the code. Oh wait, was that the patch that you sent out last time?
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists