Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp704912ybz; Wed, 15 Apr 2020 17:07:08 -0700 (PDT) X-Google-Smtp-Source: APiQypJiugN8wSEI0GJrJCejWRTtf75DJgJzLxH7DJFVr7XJO6kfkLUtQiaFL0fqjGJTksUTINvy X-Received: by 2002:a05:6402:6d7:: with SMTP id n23mr26140209edy.21.1586995628552; Wed, 15 Apr 2020 17:07:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1586995628; cv=none; d=google.com; s=arc-20160816; b=TSytJjLGFIkeEpZCC1o6Mwd8AHLA96zY2x6b8/phwPK5iUzT2mT1uGLSGJ1SQoCv/D iiCyUNanVTli7C6gHFltBwgeac8Zqo2l93u3cuTj6IaG12E8Pj8XfyMZcxrmi423qvWM ppUBosHgKKL2R9H0Ti5rvFtw8lj+I3NGOpt9mxH4MBLQ9XVA3qGC0Y+v3JK73kcHLGHD i0vYDaUXzGI9WCiITmJg/smpZRwFMM+7lCNpuQoTI7yhHzRt3YDk2MYhTpYaqSkvC66R 0f+YCjy6lqU7CqpwI/S464eV1nKHj1mOcDAkNa+zYE+T3MX35RUOOloMmvrj6CD5c5u7 mjnA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=hLcirHOjuA95Pz4eW0Mf6aVol7B0AcTUoitoY14mgzg=; b=G22Wegu/raNKM/i9yfQaYD914Pes0W3UwNAnTfVyHKapPA3KF9OggVNSrVS24SbbP2 fqFWk7aosMYyZOr2QD3hKrMROmpb0R1bfKje7fDVX0LjIFSvb1aSoI/WECDP0xp18Iy/ igOBa26sy0Ppr3XShTbDWlQFFONTCxxvGBRWDfX8JMaPYQ/oaRVhy9T3kK795Ftchfe1 bDjxlMEO8lncARFVrNONGiGxCBmVA/lYtoWRVp4T6r+vJA4A7SosZ0oJIMOdttbM3z6C 5tv1lDnOth9kHcCKTRwJ190KRkYOr7IYq/13nYj5qgdYyVfEbZ29gmvxbT0MsFqkb5wc leaw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="HiNa/6pn"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r13si13273393edt.533.2020.04.15.17.06.45; Wed, 15 Apr 2020 17:07:08 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="HiNa/6pn"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2633262AbgDONbb (ORCPT + 99 others); Wed, 15 Apr 2020 09:31:31 -0400 Received: from mail.kernel.org ([198.145.29.99]:60850 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731696AbgDONb1 (ORCPT ); Wed, 15 Apr 2020 09:31:27 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 69F8A20767; Wed, 15 Apr 2020 13:31:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586957484; bh=wh8P4Y8m6LWxobisEMWoiN2hCWnoOBEtof1UWN68Qx4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=HiNa/6pn7ZPvPQ0P8TuZcIsps5srrh0s2MvMC9z2c0A0jH6BobpJAm/j1ySmwYyg9 K7/8bvK4uIvMinundZG3vbjGAEsTBJnSVVbf+p60+2RqTBkVJMbflqIObvXoIBnbp/ NaqA8RjagminJ4aIN4JDEOrYAWjnW12/vla8BkXw= Date: Wed, 15 Apr 2020 15:31:22 +0200 From: Greg KH To: Heikki Krogerus Cc: "Rafael J. Wysocki" , Brendan Higgins , Linux Kernel Mailing List , Naresh Kamboju , Sakari Ailus , Andy Shevchenko , Hans de Goede , Rafael Wysocki , linux-kselftest@vger.kernel.org, Steven Rostedt , Sergey Senozhatsky , Andy Shevchenko , Shuah Khan , anders.roxell@linaro.org, lkft-triage@lists.linaro.org, Rasmus Villemoes Subject: Re: [PATCH v1] kobject: make sure parent is not released before children Message-ID: <20200415133122.GB3461248@kroah.com> References: <20200414204240.186377-1-brendanhiggins@google.com> <20200415061154.GA2496263@kroah.com> <20200415084653.GM2828150@kuha.fi.intel.com> <20200415131018.GO2828150@kuha.fi.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200415131018.GO2828150@kuha.fi.intel.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 15, 2020 at 04:10:18PM +0300, Heikki Krogerus wrote: > On Wed, Apr 15, 2020 at 11:21:03AM +0200, Rafael J. Wysocki wrote: > > On Wed, Apr 15, 2020 at 10:47 AM Heikki Krogerus > > wrote: > > > > > > 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(). > > > > In fact, it happens in kobject_del() invoked by kobject_cleanup() AFAICS. > > > > So it appears incorrect to use kobject_del() as is in the latter. > > > > > 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. > > > > An alternative might be to define something like __kobject_del() doing > > everything that kobject_del() does *without* the > > kobject_put(kobj->parent). > > > > Then, kobject_del() could be defined as something like (pseudocode): > > > > kobject_del(kobj) > > { > > kobject *perent = kobj->parent; > > > > __kobject_del(kobj); > > kobject_put(parent); > > } > > > > and kobject_cleanup() could call __kobject_del() instead of > > kobject_del() and then do the last kobject_put(parent) when it is done > > with the child. > > > > Would that work? > > I think so. Greg, what do you think? Hm, maybe. Can someone test it out with the reproducer? thanks, greg k-h