Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp1403138imm; Fri, 29 Jun 2018 18:07:55 -0700 (PDT) X-Google-Smtp-Source: ADUXVKLpuTlB2Tmy4ItWJgat8wBjzfc4mXnBVB8NZLTJpI88T9z6Ku3KPgYH9uEwqUxwiZCe4DLE X-Received: by 2002:a17:902:b611:: with SMTP id b17-v6mr16809944pls.284.1530320875310; Fri, 29 Jun 2018 18:07:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530320875; cv=none; d=google.com; s=arc-20160816; b=TBQQoN3Acsy1BH4b07uq7vLs4NuXJjqlmi9460XwYKesWCnSurasJWZKWL+PLmR0jZ KTj7x2ST6nyTaTXJh3JeCebtnPVkROlQevKY0f69iw/xqKIv/Jz7KM+6JVwE7B26msyP RGm+BYSuD8DJNK/zSAicep45uwgCTMml54Ar+NeKVvCTrtEPilnAstrR2Dh20rBPx+2D VWnhdFlfhXTr3o3nWSgpOBZFYqRUDpDpwfnXGwQ13XGe5wA2L+nPpzYWivm8mBRgjiH5 cvKhAETDcaeEWt5MAkFOVsOKIa6gXy5UQLmW3/YqTpRpUgHxX9EsvW5kRM2Kpq/FoGGW hWFQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:date:cc:to:from:subject:message-id :arc-authentication-results; bh=Ja9K6wmBRkQW7G+LpqcAC7neSkBhJsq+ZYfX4isYAlE=; b=IVDVP0yJYIUczhHsSXoPDzLP7vRVtsZz/fmnxgAn5uD974kb6l1UvV2lMdvfP0mm95 BAylgPdQyO/yA7lE/MPIsvWyL19UeuKRrDGt9071S8U+pbXDAfhbTRy/83Rhh4vAjTkR DI2ps499ly4MefM4uffuoHdS0jcNVzeRWmUtJkBEXVSnlorBpb5fp9wbJ+snl8t+3Pc5 iMTviusjA6tohmhlhjfP6jUIo7UWXT4O3a7L3jRbE2ZhipWFuVbLlva9om+1d5UIl1aB lv9hyCvdjll26sBI13TZySaFjgIXCSOdkoUgHMiGiB9ZGpdL+CAnHRYo3wRS6QUrNVFS JeQw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w7-v6si1032659pgf.231.2018.06.29.18.07.41; Fri, 29 Jun 2018 18:07:55 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755302AbeF3BEu (ORCPT + 99 others); Fri, 29 Jun 2018 21:04:50 -0400 Received: from gate.crashing.org ([63.228.1.57]:39493 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752549AbeF3BEq (ORCPT ); Fri, 29 Jun 2018 21:04:46 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id w5U14aeo001625; Fri, 29 Jun 2018 20:04:38 -0500 Message-ID: <61424071cc0feb487e4b8ce2c9c396df2fc56bd9.camel@kernel.crashing.org> Subject: Re: [PATCH 2/2] drivers: core: Remove glue dirs from sysfs earlier From: Benjamin Herrenschmidt To: Linus Torvalds Cc: Greg Kroah-Hartman , "Eric W. Biederman" , Joel Stanley , Linux Kernel Mailing List Date: Sat, 30 Jun 2018 11:04:36 +1000 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.3 (3.28.3-1.fc28) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2018-06-29 at 06:56 -0700, Linus Torvalds wrote: > On Thu, Jun 28, 2018 at 7:22 PM Benjamin Herrenschmidt > wrote: > > > > This fixes it by instead doing an explicit kobject_del() when > > the glue dir is empty, by keeping track of the number of > > child devices of the gluedir. > > Ugh. I was hoping that you'd just do the "only check duplicate names > if actually in use" instead. I had a look (see my other email). It's non-trivial. We can still look into it, but from what I gathered of how sysfs works, it's based on kernfs which doesn't have the kobjects nor access to the reference count, and is the holder of the names rbtree. So we'd need to find a way to convey that "in-use" information down to kernfs (I thought maybe adding an optional pointer to a kref ? but then, it's still somewhat racy ...) Additionally, we would need a few more pairs of eyes to make sure that sticking duplicates in that rbtree isn't going to break some corner case in there. It's a code base I'm not at all familiar with. So while I agree with the overall idea that a kobject whose reference has gone down to 0 should probably be ignored by sysfs, actually doing it doesn't seem simple. > This patch seems to make patch 1/2 pointless. No? Somewhat. It's stil the "right thing" to do in case a hole shows up elsewhere, and it's an easier stable backport. But yes. I wrote it before I figured out what to do with 2/2 (I was still trying to do what you wanted and just skip ref=0 in sysfs name lookups). But yes, with 2/2, there shouldn't be a kobject with a 0 ref in the list anymore... hopefully. I would very much appreciate the opinion of someone more familiar with sysfs and the device core on all this though. Cheers, Ben.