From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dmitry Osipenko Date: Fri, 10 Dec 2021 19:33:32 +0000 Subject: Re: [PATCH v4 03/25] notifier: Add atomic/blocking_notifier_has_unique_priority() Message-Id: List-Id: References: <20211126180101.27818-1-digetx@gmail.com> <20211126180101.27818-4-digetx@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: "Rafael J. Wysocki" Cc: Thierry Reding , Jonathan Hunter , Russell King , Catalin Marinas , Will Deacon , Guo Ren , Geert Uytterhoeven , Greg Ungerer , Joshua Thompson , Thomas Bogendoerfer , Sebastian Reichel , Linus Walleij , Philipp Zabel , Greentime Hu , Vincent Chen , "James E.J. Bottomley" , Helge Deller , Michael Ellerman , Benjamin Herrenschmidt , Paul Mackerras , Paul Walmsley , Palmer Dabbelt , Albert Ou , Yoshinori Sato , Rich Felker , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , the arch/x86 maintainers , "H. Peter Anvin" , Boris Ostrovsky , Juergen Gross , Stefano Stabellini , Len Brown , Santosh Shilimkar , Krzysztof Kozlowski , Liam Girdwood , Mark Brown , Pavel Machek , Lee Jones , Andrew Morton , Guenter Roeck , Daniel Lezcano , Andy Shevchenko , Ulf Hansson , alankao@andestech.com, "K . C . Kuen-Chern Lin" , Linux ARM , Linux Kernel Mailing List , linux-csky@vger.kernel.org, linux-ia64@vger.kernel.org, linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, linuxppc-dev , linux-riscv@lists.infradead.org, Linux-sh list , xen-devel@lists.xenproject.org, ACPI Devel Maling List , Linux PM , linux-tegra 10.12.2021 22:05, Rafael J. Wysocki пишет: > On Fri, Dec 10, 2021 at 7:52 PM Dmitry Osipenko wrote: >> >> 10.12.2021 21:19, Rafael J. Wysocki пишет: >> ... >>>> +bool atomic_notifier_has_unique_priority(struct atomic_notifier_head *nh, >>>> + struct notifier_block *n) >>>> +{ >>>> + unsigned long flags; >>>> + bool ret; >>>> + >>>> + spin_lock_irqsave(&nh->lock, flags); >>>> + ret = notifier_has_unique_priority(&nh->head, n); >>>> + spin_unlock_irqrestore(&nh->lock, flags); >>> >>> This only works if the caller can prevent new entries from being added >>> to the list at this point or if the caller knows that they cannot be >>> added for some reason, but the kerneldoc doesn't mention this >>> limitation. >> >> I'll update the comment. >> >> .. >>>> +bool blocking_notifier_has_unique_priority(struct blocking_notifier_head *nh, >>>> + struct notifier_block *n) >>>> +{ >>>> + bool ret; >>>> + >>>> + /* >>>> + * This code gets used during boot-up, when task switching is >>>> + * not yet working and interrupts must remain disabled. At such >>>> + * times we must not call down_read(). >>>> + */ >>>> + if (system_state != SYSTEM_BOOTING) >>> >>> No, please don't do this, it makes the whole thing error-prone. >> >> What should I do then? > > First of all, do you know of any users who may want to call this > during early initialization? If so, then why may they want to do > that? I'll need to carefully review all those dozens of platform restart handlers to answer this question. > Depending on the above, I would consider adding a special mechanism for them. Please notice that every blocking_notifier_*() function has this SYSTEM_BOOTING check, it's not my invention. Notifier API needs to be generic. >>>> + down_read(&nh->rwsem); >>>> + >>>> + ret = notifier_has_unique_priority(&nh->head, n); >>>> + >>>> + if (system_state != SYSTEM_BOOTING) >>>> + up_read(&nh->rwsem); >>> >>> And still what if a new entry with a non-unique priority is added to >>> the chain at this point? >> >> If entry with a non-unique priority is added after the check, then >> obviously it won't be detected. > > Why isn't this a problem?>> I don't understand the question. These >> down/up_read() are the locks that prevent the race, if that's the question. > > Not really, they only prevent the race from occurring while > notifier_has_unique_priority() is running. > > If anyone depends on this check for correctness, they need to lock the > rwsem, do the check, do the thing depending on the check while holding > the rwsem and then release the rwsem. Otherwise it is racy. > It's fine that it's a bit "racy" since in the context of this series. We always do the check after adding new entry, so it's not a problem. There are two options: 1. Use blocking_notifier_has_unique_priority() like it's done in this patchset. Remove it after all drivers are converted to the new API and add blocking_notifier_chain_register_unique(). 2. Add blocking_notifier_chain_register_unique(), but don't let it fail the registration of non-unique entries until all drivers are converted to the new API.