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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 C296BC433E4 for ; Fri, 19 Mar 2021 18:07:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A2EB261989 for ; Fri, 19 Mar 2021 18:07:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230286AbhCSSGt (ORCPT ); Fri, 19 Mar 2021 14:06:49 -0400 Received: from mga04.intel.com ([192.55.52.120]:56593 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230097AbhCSSGY (ORCPT ); Fri, 19 Mar 2021 14:06:24 -0400 IronPort-SDR: ckvKblsVR9f4OeKUSW5ZpmtlVEG5iI3k78uid9Gxz/rDlco5AHmmS1zlv6Myx61k3lwHKCiSu2 dbh5bLHxnNaA== X-IronPort-AV: E=McAfee;i="6000,8403,9928"; a="187595067" X-IronPort-AV: E=Sophos;i="5.81,262,1610438400"; d="scan'208";a="187595067" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Mar 2021 11:06:23 -0700 IronPort-SDR: /AnKk4h0Ng4+xzjWlggIp7YBDN2uKRn8cfFOGGOWQ3cP2q9+QqcPybMg/CwhcEXHPYnS/erhWA JUHfBruesqNA== X-IronPort-AV: E=Sophos;i="5.81,262,1610438400"; d="scan'208";a="450954496" Received: from smile.fi.intel.com (HELO smile) ([10.237.68.40]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Mar 2021 11:06:21 -0700 Received: from andy by smile with local (Exim 4.94) (envelope-from ) id 1lNJVq-00Dw7c-LM; Fri, 19 Mar 2021 20:06:18 +0200 Date: Fri, 19 Mar 2021 20:06:18 +0200 From: Andy Shevchenko To: "Rafael J. Wysocki" Cc: "Rafael J. Wysocki" , ACPI Devel Maling List , Linux Kernel Mailing List , "Rafael J. Wysocki" , Len Brown Subject: Re: [PATCH v1 1/1] ACPI: scan: Use unique number for instance_no Message-ID: References: <20210312160137.19463-1-andriy.shevchenko@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Mar 19, 2021 at 06:00:38PM +0100, Rafael J. Wysocki wrote: > On Fri, Mar 12, 2021 at 5:02 PM Andy Shevchenko > wrote: > > > > Current mechanism of incrementing and decrementing plain integer > > to get a next free instance_no when creating an ACPI device is fragile. > > > > In case of hot plug event or namespace removal of the device instances > > with the low numbers the plain integer counter can't cover the gaps > > and become desynchronized with real state of affairs. If during next > > hot plug event or namespace injection the new instances of > > the devices need to be instantiated, the counter may mistakenly point > > to the existing instance_no and kernel will complain: > > "sysfs: cannot create duplicate filename '/bus/acpi/devices/XXXX1234:02'" > > This is a slightly convoluted way of stating that there is a bug in > acpi_device_del(). Any suggestion how to massage the above? But in the dry end, yes, decrementing is a bug. > Yes, there is one, the instance_no decrementation is clearly incorrect. > > > Replace plain integer approach by using IDA framework. > > Also the general idea of using IDA for the instance numbering is a good one IMO. ... > > - unsigned int instance_no; > > + struct ida no; > > struct ida instance_ida; ? Will rename. ... > > + p = strrchr(dev_name(&device->dev), ':'); > > + if (!p) > > + return -ENODATA; > > + > > + error = kstrtoint(p + 1, 16, &result); > > + if (error) > > + return error; > > + > > + return result; > > I don't like the above at all. > > I would just store the instance number in struct acpi_device_pnp (say). TBH, I simply didn't know which struct to touch and left this one and I also don't like it. Lemme see if acpi_device_pnp is good enough for that. -- With Best Regards, Andy Shevchenko