From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_PASS,URIBL_BLOCKED,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 30257C169C4 for ; Tue, 29 Jan 2019 06:58:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id F0E352177E for ; Tue, 29 Jan 2019 06:58:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1548745120; bh=MdoLdwk1cONkLqna6cLGmZxNn6yoJVacZA50ch+wbcM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=x5d3xs45K45vPT3c7Z2jH/MyB8Rpgq0Hs4sTGeAmmRMD+Tx2SbazhvUHWYaSTbpxf d07Ot+M3cavmHzKL8GT02o1BdnG7TOk4UFavV4JRtECZMbr5lUyzCe6faNaMkYSolG C+SeIrXtOEtbQeeFGAV+wyyDxdCPFVnZ7NU5WgzA= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725764AbfA2G6j (ORCPT ); Tue, 29 Jan 2019 01:58:39 -0500 Received: from mail.kernel.org ([198.145.29.99]:41940 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725267AbfA2G6j (ORCPT ); Tue, 29 Jan 2019 01:58:39 -0500 Received: from localhost (5356596B.cm-6-7b.dynamic.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 3B13E2148E; Tue, 29 Jan 2019 06:58:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1548745118; bh=MdoLdwk1cONkLqna6cLGmZxNn6yoJVacZA50ch+wbcM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=wL6YGdUSxYfxTAgAbMiz+m2zC4YRQQ+Romys1uQqFxWNAHknlMhqKgGbgKBG5wzUK WktnEUzqZSG/zXBLGZZ9JqaqQd0wkO6Pxt/SCrVevkjt8BnBXwx0oAxKUKipNEqL9Z F6eqcC7I9o87JiP44Ut9+ynKeEVO3/9R7aZokRKU= Date: Tue, 29 Jan 2019 07:58:36 +0100 From: Greg KH To: Zubin Mithra Cc: stable@vger.kernel.org, groeck@chromium.org, benh@kernel.crashing.org, rafael@kernel.org Subject: Re: [PATCH v4.4.y] drivers: core: Remove glue dirs from sysfs earlier Message-ID: <20190129065836.GA24231@kroah.com> References: <20190128173130.22618-1-zsm@chromium.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190128173130.22618-1-zsm@chromium.org> User-Agent: Mutt/1.11.2 (2019-01-07) Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org On Mon, Jan 28, 2019 at 09:31:30AM -0800, Zubin Mithra wrote: > From: Benjamin Herrenschmidt > > commit 726e41097920a73e4c7c33385dcc0debb1281e18 upstream > > For devices with a class, we create a "glue" directory between > the parent device and the new device with the class name. > > This directory is never "explicitely" removed when empty however, > this is left to the implicit sysfs removal done by kobject_release() > when the object loses its last reference via kobject_put(). > > This is problematic because as long as it's not been removed from > sysfs, it is still present in the class kset and in sysfs directory > structure. > > The presence in the class kset exposes a use after free bug fixed > by the previous patch, but the presence in sysfs means that until > the kobject is released, which can take a while (especially with > kobject debugging), any attempt at re-creating such as binding a > new device for that class/parent pair, will result in a sysfs > duplicate file name error. > > 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. > > This is made easy by the fact that all glue dir operations are > done with a global mutex, and there's already a function > (cleanup_glue_dir) called in all the right places taking that > mutex that can be enhanced for this. It appears that this was > in fact the intent of the function, but the implementation was > wrong. > > Backport Note: kref_read() is not present in 4.4. Hence, > use atomic_read(&kref.refcount) instead of kref_read(&kref). > > Signed-off-by: Benjamin Herrenschmidt > Acked-by: Linus Torvalds > Signed-off-by: Greg Kroah-Hartman > Signed-off-by: Zubin Mithra > --- > drivers/base/core.c | 2 ++ > include/linux/kobject.h | 17 +++++++++++++++++ > 2 files changed, 19 insertions(+) Wait, why is this needed? And why only for 4.4? What about 4.9 and 4.14? Do you want to upgrade and suddenly hit the same "bug" that you fixed before? There was a reason that I did not backport this to the stable tree when it was submitted, and that was because this was an odd race to ever hit. Are you hitting this in the real world without kobject deferred release enabled? And if so, are you hitting the WARN_ON that is added here? I would like to hold off on this until some more information is provided, and at the least, if it is accepted, we add it to all of the stable trees, not just 4.4.y. So I'm going to go drop it from the 4.4.y queue for now. thanks, greg k-h