linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Brendan Higgins <brendanhiggins@google.com>,
	rafael@kernel.org, linux-kernel@vger.kernel.org,
	naresh.kamboju@linaro.org, sakari.ailus@linux.intel.com,
	andy.shevchenko@gmail.com, hdegoede@redhat.com,
	rafael.j.wysocki@intel.com, linux-kselftest@vger.kernel.org,
	rostedt@goodmis.org, sergey.senozhatsky@gmail.com,
	andriy.shevchenko@linux.intel.com, shuah@kernel.org,
	anders.roxell@linaro.org, lkft-triage@lists.linaro.org,
	linux@rasmusvillemoes.dk
Subject: Re: [PATCH v1] kobject: make sure parent is not released before children
Date: Wed, 15 Apr 2020 11:46:53 +0300	[thread overview]
Message-ID: <20200415084653.GM2828150@kuha.fi.intel.com> (raw)
In-Reply-To: <20200415061154.GA2496263@kroah.com>

Hi Greg,

On Wed, Apr 15, 2020 at 08:11:54AM +0200, Greg KH wrote:
> > diff --git a/lib/kobject.c b/lib/kobject.c
> > index 83198cb37d8d..5921e2470b46 100644
> > --- a/lib/kobject.c
> > +++ b/lib/kobject.c
> > @@ -663,6 +663,7 @@ EXPORT_SYMBOL(kobject_get_unless_zero);
> >   */
> >  static void kobject_cleanup(struct kobject *kobj)
> >  {
> > +	struct kobject *parent = kobj->parent;
> >  	struct kobj_type *t = get_ktype(kobj);
> >  	const char *name = kobj->name;
> >  
> > @@ -680,6 +681,9 @@ static void kobject_cleanup(struct kobject *kobj)
> >  		kobject_uevent(kobj, KOBJ_REMOVE);
> >  	}
> >  
> > +	/* make sure the parent is not released before the (last) child */
> > +	kobject_get(parent);
> > +
> >  	/* remove from sysfs if the caller did not do it */
> >  	if (kobj->state_in_sysfs) {
> >  		pr_debug("kobject: '%s' (%p): auto cleanup kobject_del\n",
> > @@ -693,6 +697,8 @@ static void kobject_cleanup(struct kobject *kobj)
> >  		t->release(kobj);
> >  	}
> >  
> > +	kobject_put(parent);
> > +
> 
> No, please don't do this.
> 
> A child device should have always incremented the parent already if it
> was correctly registered.  We have had this patch been proposed multiple
> times over the years, and every time it was, we said no and went and
> fixed the real issue which was with the user of the interface.

The parent ref count is incremented by the child, that is not the
problem. The problem is that when that child is released, if it's the
last child of the parent, and there are no other users for the parent,
then the parent is actually released _before_ the child. And that
happens in the above function kobject_cleanup().

We can work around the problem by taking a reference to the parent
separately, but we have to do that everywhere separately (which I
guess is exactly what has been done so far). That workaroud still does
not really fix the core problem. The core problem is still that
lib/kboject.c is allowing the parent kobject to be released before the
child kobject, and that quite simply should not be allowed to happen.

I don't have a problem if you want to have a better solution for this,
but the solution really can't anymore be that we are always expected
to separately increment the parent's ref count with every type of
kobject.


thanks,

-- 
heikki

  reply	other threads:[~2020-04-15  8:47 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-14 20:42 [PATCH v1] kobject: make sure parent is not released before children Brendan Higgins
2020-04-14 22:38 ` Randy Dunlap
2020-04-15  6:11 ` Greg KH
2020-04-15  8:46   ` Heikki Krogerus [this message]
2020-04-15  9:21     ` Rafael J. Wysocki
2020-04-15 13:10       ` Heikki Krogerus
2020-04-15 13:31         ` Greg KH
2020-04-17 11:39           ` Heikki Krogerus
2020-04-17 16:08             ` Randy Dunlap
2020-04-20 22:03               ` Brendan Higgins
2020-04-15  9:21     ` Greg KH
2020-04-15 11:25       ` Heikki Krogerus
2020-04-15 12:12         ` Greg KH
2020-04-15  8:18 ` Heikki Krogerus

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=20200415084653.GM2828150@kuha.fi.intel.com \
    --to=heikki.krogerus@linux.intel.com \
    --cc=anders.roxell@linaro.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=brendanhiggins@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hdegoede@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=lkft-triage@lists.linaro.org \
    --cc=naresh.kamboju@linaro.org \
    --cc=rafael.j.wysocki@intel.com \
    --cc=rafael@kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=sakari.ailus@linux.intel.com \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=shuah@kernel.org \
    /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 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).