[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170525143536.GT8541@lahna.fi.intel.com>
Date: Thu, 25 May 2017 17:35:36 +0300
From: Mika Westerberg <mika.westerberg@...ux.intel.com>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Andreas Noever <andreas.noever@...il.com>,
Michael Jamet <michael.jamet@...el.com>,
Yehezkel Bernat <yehezkel.bernat@...el.com>,
Lukas Wunner <lukas@...ner.de>,
Amir Levy <amir.jer.levy@...el.com>,
Andy Lutomirski <luto@...nel.org>, Mario.Limonciello@...l.com,
Jared.Dominguez@...l.com,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 15/24] thunderbolt: Rework control channel to be more
reliable
On Thu, May 25, 2017 at 03:25:46PM +0200, Greg Kroah-Hartman wrote:
> > +/**
> > + * tb_cfg_request_put() - Decrease refcount and possibly release the request
> > + * @req: Request whose refcount is decreased
> > + *
> > + * Call this function when you are done with the request. When refcount
> > + * goes to %0 the object is released.
> > + */
> > +void tb_cfg_request_put(struct tb_cfg_request *req)
> > +{
> > + kref_put(&req->kref, tb_cfg_request_destroy);
> > +}
>
> What prevents this call from being called twice on the same object from
> different threads at the same time? You still need a lock somewhere to
> protect yourself from that, am I just missing where that lock is?
No, you are right - it is missing a lock. I will add it there in the
next version.
Thanks.
Powered by blists - more mailing lists