From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dmitry Osipenko Date: Fri, 10 Dec 2021 18:52:01 +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 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? >> + 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. I don't understand the question. These down/up_read() are the locks that prevent the race, if that's the question.