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=-4.0 required=3.0 tests=BAYES_00,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 ED5A0C433E2 for ; Fri, 19 Mar 2021 18:45:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BEAE261980 for ; Fri, 19 Mar 2021 18:45:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230063AbhCSSoz (ORCPT ); Fri, 19 Mar 2021 14:44:55 -0400 Received: from mail-ot1-f41.google.com ([209.85.210.41]:33282 "EHLO mail-ot1-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229912AbhCSSoW (ORCPT ); Fri, 19 Mar 2021 14:44:22 -0400 Received: by mail-ot1-f41.google.com with SMTP id o19-20020a9d22130000b02901bfa5b79e18so9470718ota.0; Fri, 19 Mar 2021 11:44:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kR8NIAoP3ynBOhOjQZ15G+E4WBburaxkSRvRk4396go=; b=lSvbIuy56uHTzIe8tNhZo4u+IM5CDcezfnhWGVzNQ+Ce4f51cFHloOvdA8uBJvfi8F 4ZiXmEcWPt0BgnwBfe94B5wVXg1kWnkXQGipA99db/d8iZDBcYgppOtuZgd1EIUl49gs RqZH/SaTHDUetq0wT3hkj1nAyRN358AYO1w7TbRsmWhEwmavMfx6/grPk4979oTj+6ri Zo6ltuAwLKTUrmopmxL6ESL4g3/RwykATJrFo0hvwKd8l5I+YZ3MzUU0FGoLHLq0GlYZ C0YXEjvjpKny1uOGlQHSk4SubGJKwYO5kS+JM9QO+elQXb5uuxlp3q49CsEAL9mx9/rQ M6JQ== X-Gm-Message-State: AOAM5309ab7dcYl0qFRRPa0Zi7lMZRZ/dEPH1+G+9MnVAXRt2GE85QNm GIV18CBmTNAdoGN4NlQsnP3F2rG3FfZIr7R2ZiMwSW1Zkv4= X-Google-Smtp-Source: ABdhPJznCwEMXGPf6ROMg55dBLUqElK+MJzvCyuPcu7vKmB0CsjaD99GxOEwHiYr6iPEzzmbhruXFZg8bemiuby/92w= X-Received: by 2002:a05:6830:20d2:: with SMTP id z18mr2156324otq.260.1616179462192; Fri, 19 Mar 2021 11:44:22 -0700 (PDT) MIME-Version: 1.0 References: <20210312160137.19463-1-andriy.shevchenko@linux.intel.com> In-Reply-To: From: "Rafael J. Wysocki" Date: Fri, 19 Mar 2021 19:44:11 +0100 Message-ID: Subject: Re: [PATCH v1 1/1] ACPI: scan: Use unique number for instance_no To: Andy Shevchenko Cc: "Rafael J. Wysocki" , "Rafael J. Wysocki" , ACPI Devel Maling List , Linux Kernel Mailing List , "Rafael J. Wysocki" , Len Brown Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org On Fri, Mar 19, 2021 at 7:06 PM Andy Shevchenko wrote: > > 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? Why don't you simply say something like "The decrementation of acpi_device_bus_id->instance_no in acpi_device_del() is incorrect, because it may cause a duplicate instance number to be allocated next time a device with the same acpi_device_bus_id is added."