Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp639417ybz; Wed, 15 Apr 2020 15:43:07 -0700 (PDT) X-Google-Smtp-Source: APiQypJYlgIUF2MG2M9k7N4+Lh1GhkCMuWdnvkEGOkvXfT7dJEUw2LrpQPQBKi/a0NFJaRP6W9SN X-Received: by 2002:aa7:cc92:: with SMTP id p18mr4289410edt.166.1586990587375; Wed, 15 Apr 2020 15:43:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1586990587; cv=none; d=google.com; s=arc-20160816; b=dYskbKlEYS7YM0YEm2nAo1yz77sPH0iFxTC+P/9Q89fk4wkjU4Uku1XSYFP4iwIwUb rGny3o6j71xX0F6B3EIOK5MbGgYD7M+puLasgFOhIdcqMCumxvX6wlqEL9r7w/WGtDsX okBvlPKTQ/n9s8ru/r3PSTzCqOoRdH3kgYh5xubgzOUOKx8aNmsJKhwMHBUV2m5sK4DL WC9M8m1i4M1pNWYJY68yeSFvgIe56aeZbRD2FfAk2n7lSzvyAiPT8NGVslo7ka4ynFcg eixu4NrHd8mOfRCBbbGWgAmEUdR9BIbtTeztt6mqzUwDb8H4zyHliziMwBsjIjKyW+Fd VPqg== 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 :ironport-sdr:ironport-sdr; bh=AEZ8tVlvilM52W+yTxvBmEz2g04n4SaN11HCO6h9SVI=; b=mWHH6Ujw0O+A0r1lnJiCe5VBycX2eiHye2vGwFAn47zmgAs0Vm+OBWmoGcKj4PhDBc XwU+ehQRLcNUxZ4GT/iVxcoL36ebTv8ptpAUw6dZfCLC1CmY/kfucwgNhNb2zXTdkSOR NkhG/dFfYOU2SJ/0t9nZHFyottlZkihOid1CPclGatzOcY8+ndjncjWEdvZngCjTyTKV X3g+LxqgEy6eisA5z6rIWfnjTlt864ORE2F1G7vCXCYJn+oll1RzeLdTxLGimafJKGpY Zmn9QjYPkIcFfMS9AuWoNhRTCo5SkvWivNc6dxSRSzo9jIVTTFlwRg7S2QZsLVr9y1SK UBXg== ARC-Authentication-Results: i=1; mx.google.com; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id oc19si5841131ejb.487.2020.04.15.15.42.43; Wed, 15 Apr 2020 15:43:07 -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; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2895020AbgDOIrJ (ORCPT + 99 others); Wed, 15 Apr 2020 04:47:09 -0400 Received: from mga14.intel.com ([192.55.52.115]:56295 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2895009AbgDOIq7 (ORCPT ); Wed, 15 Apr 2020 04:46:59 -0400 IronPort-SDR: Oe18Imx/71bJpDJYWK5nbi8LZ9xsC6/ceq+4iy7Ho2WWZIOMJucVuDEUINXeI5wmKM2jKBvjOl qVAzBGYwQmYQ== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Apr 2020 01:46:58 -0700 IronPort-SDR: 3u20hooD25XQZI2V8xRYlsnfiBRb/6zG30Vc6mYtVCu8ifitQBI+BbTf0GsayPFQNB4mvD/KZu ufb2UKMyswdg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.72,386,1580803200"; d="scan'208";a="363615514" Received: from kuha.fi.intel.com ([10.237.72.162]) by fmsmga001.fm.intel.com with SMTP; 15 Apr 2020 01:46:53 -0700 Received: by kuha.fi.intel.com (sSMTP sendmail emulation); Wed, 15 Apr 2020 11:46:53 +0300 Date: Wed, 15 Apr 2020 11:46:53 +0300 From: Heikki Krogerus To: Greg KH Cc: Brendan Higgins , 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 Message-ID: <20200415084653.GM2828150@kuha.fi.intel.com> References: <20200414204240.186377-1-brendanhiggins@google.com> <20200415061154.GA2496263@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200415061154.GA2496263@kroah.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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