All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Osipenko <digetx@gmail.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: "Michał Mirosław" <mirq-linux@rere.qmqm.pl>,
	"Thierry Reding" <thierry.reding@gmail.com>,
	"Jonathan Hunter" <jonathanh@nvidia.com>,
	"Russell King" <linux@armlinux.org.uk>,
	"Catalin Marinas" <catalin.marinas@arm.com>,
	"Will Deacon" <will@kernel.org>, "Guo Ren" <guoren@kernel.org>,
	"Geert Uytterhoeven" <geert@linux-m68k.org>,
	"Greg Ungerer" <gerg@linux-m68k.org>,
	"Joshua Thompson" <funaho@jurai.org>,
	"Thomas Bogendoerfer" <tsbogend@alpha.franken.de>,
	"Sebastian Reichel" <sre@kernel.org>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Philipp Zabel" <p.zabel@pengutronix.de>,
	"Greentime Hu" <green.hu@gmail.com>,
	"Vincent Chen" <deanbo422@gmail.com>,
	"James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
	"Helge Deller" <deller@gmx.de>,
	"Michael Ellerman" <mpe@ellerman.id.au>,
	"Benjamin Herrenschmidt" <benh@kernel.crashing.org>,
	"Paul Mackerras" <paulus@samba.org>,
	"Paul Walmsley" <paul.walmsley@sifive.com>,
	"Palmer Dabbelt" <palmer@dabbelt.com>,
	"Albert Ou" <aou@eecs.berkeley.edu>,
	"Yoshinori Sato" <ysato@users.sourceforge.jp>,
	"Rich Felker" <dalias@libc.org>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Ingo Molnar" <mingo@redhat.com>,
	"Borislav Petkov" <bp@alien8.de>,
	"Dave Hansen" <dave.hansen@linux.intel.com>,
	"the arch/x86 maintainers" <x86@kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	"Boris Ostrovsky" <boris.ostrovsky@oracle.com>,
	"Juergen Gross" <jgross@suse.com>,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	"Len Brown" <lenb@kernel.org>,
	"Santosh Shilimkar" <ssantosh@kernel.org>,
	"Krzysztof Kozlowski" <krzysztof.kozlowski@canonical.com>,
	"Liam Girdwood" <lgirdwood@gmail.com>,
	"Mark Brown" <broonie@kernel.org>, "Pavel Machek" <pavel@ucw.cz>,
	"Lee Jones" <lee.jones@linaro.org>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Guenter Roeck" <linux@roeck-us.net>,
	"Daniel Lezcano" <daniel.lezcano@linaro.org>,
	"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
	"Ulf Hansson" <ulf.hansson@linaro.org>,
	alankao@andestech.com,
	"K . C . Kuen-Chern Lin" <kclin@andestech.com>,
	"Linux ARM" <linux-arm-kernel@lists.infradead.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	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 <linuxppc-dev@lists.ozlabs.org>,
	linux-riscv@lists.infradead.org,
	"Linux-sh list" <linux-sh@vger.kernel.org>,
	xen-devel@lists.xenproject.org,
	"ACPI Devel Maling List" <linux-acpi@vger.kernel.org>,
	"Linux PM" <linux-pm@vger.kernel.org>,
	linux-tegra <linux-tegra@vger.kernel.org>
Subject: Re: [PATCH v4 05/25] reboot: Warn if restart handler has duplicated priority
Date: Fri, 10 Dec 2021 22:04:27 +0300	[thread overview]
Message-ID: <45025b2d-4be1-f694-be61-31903795cf5d@gmail.com> (raw)
In-Reply-To: <CAJZ5v0jMvdhfBqjY+V9h_Z6EH1ohuJH+KjuGiOw_Jor1Tnp7vg@mail.gmail.com>

10.12.2021 21:27, Rafael J. Wysocki пишет:
> On Mon, Nov 29, 2021 at 12:34 PM Dmitry Osipenko <digetx@gmail.com> wrote:
>>
>> 29.11.2021 03:26, Michał Mirosław пишет:
>>> On Mon, Nov 29, 2021 at 12:06:19AM +0300, Dmitry Osipenko wrote:
>>>> 28.11.2021 03:28, Michał Mirosław пишет:
>>>>> On Fri, Nov 26, 2021 at 09:00:41PM +0300, Dmitry Osipenko wrote:
>>>>>> Add sanity check which ensures that there are no two restart handlers
>>>>>> registered with the same priority. Normally it's a direct sign of a
>>>>>> problem if two handlers use the same priority.
>>>>>
>>>>> The patch doesn't ensure the property that there are no duplicated-priority
>>>>> entries on the chain.
>>>>
>>>> It's not the exact point of this patch.
>>>>
>>>>> I'd rather see a atomic_notifier_chain_register_unique() that returns
>>>>> -EBUSY or something istead of adding an entry with duplicate priority.
>>>>> That way it would need only one list traversal unless you want to
>>>>> register the duplicate anyway (then you would call the older
>>>>> atomic_notifier_chain_register() after reporting the error).
>>>>
>>>> The point of this patch is to warn developers about the problem that
>>>> needs to be fixed. We already have such troubling drivers in mainline.
>>>>
>>>> It's not critical to register different handlers with a duplicated
>>>> priorities, but such cases really need to be corrected. We shouldn't
>>>> break users' machines during transition to the new API, meanwhile
>>>> developers should take action of fixing theirs drivers.
>>>>
>>>>> (Or you could return > 0 when a duplicate is registered in
>>>>> atomic_notifier_chain_register() if the callers are prepared
>>>>> for that. I don't really like this way, though.)
>>>>
>>>> I had a similar thought at some point before and decided that I'm not in
>>>> favor of this approach. It's nicer to have a dedicated function that
>>>> verifies the uniqueness, IMO.
>>>
>>> I don't like the part that it traverses the list second time to check
>>> the uniqueness. But actually you could avoid that if
>>> notifier_chain_register() would always add equal-priority entries in
>>> reverse order:
>>>
>>>  static int notifier_chain_register(struct notifier_block **nl,
>>>               struct notifier_block *n)
>>>  {
>>>       while ((*nl) != NULL) {
>>>               if (unlikely((*nl) == n)) {
>>>                       WARN(1, "double register detected");
>>>                       return 0;
>>>               }
>>> -             if (n->priority > (*nl)->priority)
>>> +             if (n->priority >= (*nl)->priority)
>>>                       break;
>>>               nl = &((*nl)->next);
>>>       }
>>>       n->next = *nl;
>>>       rcu_assign_pointer(*nl, n);
>>>       return 0;
>>>  }
>>>
>>> Then the check for uniqueness after adding would be:
>>>
>>>  WARN(nb->next && nb->priority == nb->next->priority);
>>
>> We can't just change the registration order because invocation order of
>> the call chain depends on the registration order
> 
> It doesn't if unique priorities are required and isn't that what you want?
> 
>> and some of current
>> users may rely on that order. I'm pretty sure that changing the order
>> will have unfortunate consequences.
> 
> Well, the WARN() doesn't help much then.
> 
> Either you can make all of the users register with unique priorities,
> and then you can make the registration reject non-unique ones, or you
> cannot assume them to be unique.

There is no strong requirement for priorities to be unique, the reboot.c
code will work properly.

The potential problem is on the user's side and the warning is intended
to aid the user.

We can make it a strong requirement, but only after converting and
testing all kernel drivers. I'll consider to add patches for that.

WARNING: multiple messages have this Message-ID (diff)
From: Dmitry Osipenko <digetx@gmail.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: "Michał Mirosław" <mirq-linux@rere.qmqm.pl>,
	"Thierry Reding" <thierry.reding@gmail.com>,
	"Jonathan Hunter" <jonathanh@nvidia.com>,
	"Russell King" <linux@armlinux.org.uk>,
	"Catalin Marinas" <catalin.marinas@arm.com>,
	"Will Deacon" <will@kernel.org>, "Guo Ren" <guoren@kernel.org>,
	"Geert Uytterhoeven" <geert@linux-m68k.org>,
	"Greg Ungerer" <gerg@linux-m68k.org>,
	"Joshua Thompson" <funaho@jurai.org>,
	"Thomas Bogendoerfer" <tsbogend@alpha.franken.de>,
	"Sebastian Reichel" <sre@kernel.org>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Philipp Zabel" <p.zabel@pengutronix.de>,
	"Greentime Hu" <green.hu@gmail.com>,
	"Vincent Chen" <deanbo422@gmail.com>,
	"James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
	"Helge Deller" <deller@gmx.de>,
	"Michael Ellerman" <mpe@ellerman.id.au>,
	"Benjamin Herrenschmidt" <benh@kernel.crashing.org>,
	"Paul Mackerras" <paulus@samba.org>,
	"Paul Walmsley" <paul.walmsley@sifive.com>,
	"Palmer Dabbelt" <palmer@dabbelt.com>,
	"Albert Ou" <aou@eecs.berkeley.edu>,
	"Yoshinori Sato" <ysato@users.sourceforge.jp>,
	"Rich Felker" <dalias@libc.org>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Ingo Molnar" <mingo@redhat.com>,
	"Borislav Petkov" <bp@alien8.de>,
	"Dave Hansen" <dave.hansen@linux.intel.com>,
	"the arch/x86 maintainers" <x86@kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	"Boris Ostrovsky" <boris.ostrovsky@oracle.com>,
	"Juergen Gross" <jgross@suse.com>,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	"Len Brown" <lenb@kernel.org>,
	"Santosh Shilimkar" <ssantosh@kernel.org>,
	"Krzysztof Kozlowski" <krzysztof.kozlowski@canonical.com>,
	"Liam Girdwood" <lgirdwood@gmail.com>,
	"Mark Brown" <broonie@kernel.org>, "Pavel Machek" <pavel@ucw.cz>,
	"Lee Jones" <lee.jones@linaro.org>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Guenter Roeck" <linux@roeck-us.net>,
	"Daniel Lezcano" <daniel.lezcano@linaro.org>,
	"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
	"Ulf Hansson" <ulf.hansson@linaro.org>,
	alankao@andestech.com,
	"K . C . Kuen-Chern Lin" <kclin@andestech.com>,
	"Linux ARM" <linux-arm-kernel@lists.infradead.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	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 <linuxppc-dev@lists.ozlabs.org>,
	linux-riscv@lists.infradead.org,
	"Linux-sh list" <linux-sh@vger.kernel.org>,
	xen-devel@lists.xenproject.org,
	"ACPI Devel Maling List" <linux-acpi@vger.kernel.org>,
	"Linux PM" <linux-pm@vger.kernel.org>,
	linux-tegra <linux-tegra@vger.kernel.org>
Subject: Re: [PATCH v4 05/25] reboot: Warn if restart handler has duplicated priority
Date: Fri, 10 Dec 2021 22:04:27 +0300	[thread overview]
Message-ID: <45025b2d-4be1-f694-be61-31903795cf5d@gmail.com> (raw)
In-Reply-To: <CAJZ5v0jMvdhfBqjY+V9h_Z6EH1ohuJH+KjuGiOw_Jor1Tnp7vg@mail.gmail.com>

10.12.2021 21:27, Rafael J. Wysocki пишет:
> On Mon, Nov 29, 2021 at 12:34 PM Dmitry Osipenko <digetx@gmail.com> wrote:
>>
>> 29.11.2021 03:26, Michał Mirosław пишет:
>>> On Mon, Nov 29, 2021 at 12:06:19AM +0300, Dmitry Osipenko wrote:
>>>> 28.11.2021 03:28, Michał Mirosław пишет:
>>>>> On Fri, Nov 26, 2021 at 09:00:41PM +0300, Dmitry Osipenko wrote:
>>>>>> Add sanity check which ensures that there are no two restart handlers
>>>>>> registered with the same priority. Normally it's a direct sign of a
>>>>>> problem if two handlers use the same priority.
>>>>>
>>>>> The patch doesn't ensure the property that there are no duplicated-priority
>>>>> entries on the chain.
>>>>
>>>> It's not the exact point of this patch.
>>>>
>>>>> I'd rather see a atomic_notifier_chain_register_unique() that returns
>>>>> -EBUSY or something istead of adding an entry with duplicate priority.
>>>>> That way it would need only one list traversal unless you want to
>>>>> register the duplicate anyway (then you would call the older
>>>>> atomic_notifier_chain_register() after reporting the error).
>>>>
>>>> The point of this patch is to warn developers about the problem that
>>>> needs to be fixed. We already have such troubling drivers in mainline.
>>>>
>>>> It's not critical to register different handlers with a duplicated
>>>> priorities, but such cases really need to be corrected. We shouldn't
>>>> break users' machines during transition to the new API, meanwhile
>>>> developers should take action of fixing theirs drivers.
>>>>
>>>>> (Or you could return > 0 when a duplicate is registered in
>>>>> atomic_notifier_chain_register() if the callers are prepared
>>>>> for that. I don't really like this way, though.)
>>>>
>>>> I had a similar thought at some point before and decided that I'm not in
>>>> favor of this approach. It's nicer to have a dedicated function that
>>>> verifies the uniqueness, IMO.
>>>
>>> I don't like the part that it traverses the list second time to check
>>> the uniqueness. But actually you could avoid that if
>>> notifier_chain_register() would always add equal-priority entries in
>>> reverse order:
>>>
>>>  static int notifier_chain_register(struct notifier_block **nl,
>>>               struct notifier_block *n)
>>>  {
>>>       while ((*nl) != NULL) {
>>>               if (unlikely((*nl) == n)) {
>>>                       WARN(1, "double register detected");
>>>                       return 0;
>>>               }
>>> -             if (n->priority > (*nl)->priority)
>>> +             if (n->priority >= (*nl)->priority)
>>>                       break;
>>>               nl = &((*nl)->next);
>>>       }
>>>       n->next = *nl;
>>>       rcu_assign_pointer(*nl, n);
>>>       return 0;
>>>  }
>>>
>>> Then the check for uniqueness after adding would be:
>>>
>>>  WARN(nb->next && nb->priority == nb->next->priority);
>>
>> We can't just change the registration order because invocation order of
>> the call chain depends on the registration order
> 
> It doesn't if unique priorities are required and isn't that what you want?
> 
>> and some of current
>> users may rely on that order. I'm pretty sure that changing the order
>> will have unfortunate consequences.
> 
> Well, the WARN() doesn't help much then.
> 
> Either you can make all of the users register with unique priorities,
> and then you can make the registration reject non-unique ones, or you
> cannot assume them to be unique.

There is no strong requirement for priorities to be unique, the reboot.c
code will work properly.

The potential problem is on the user's side and the warning is intended
to aid the user.

We can make it a strong requirement, but only after converting and
testing all kernel drivers. I'll consider to add patches for that.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

WARNING: multiple messages have this Message-ID (diff)
From: Dmitry Osipenko <digetx@gmail.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: "Ulf Hansson" <ulf.hansson@linaro.org>,
	"Rich Felker" <dalias@libc.org>,
	linux-ia64@vger.kernel.org,
	"Santosh Shilimkar" <ssantosh@kernel.org>,
	"Linux-sh list" <linux-sh@vger.kernel.org>,
	"Boris Ostrovsky" <boris.ostrovsky@oracle.com>,
	"Catalin Marinas" <catalin.marinas@arm.com>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Dave Hansen" <dave.hansen@linux.intel.com>,
	"Liam Girdwood" <lgirdwood@gmail.com>,
	"James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
	"Thierry Reding" <thierry.reding@gmail.com>,
	"Paul Mackerras" <paulus@samba.org>,
	"Pavel Machek" <pavel@ucw.cz>, "H. Peter Anvin" <hpa@zytor.com>,
	linux-riscv@lists.infradead.org,
	"Vincent Chen" <deanbo422@gmail.com>,
	"Will Deacon" <will@kernel.org>,
	"Greg Ungerer" <gerg@linux-m68k.org>,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	alankao@andestech.com,
	"Yoshinori Sato" <ysato@users.sourceforge.jp>,
	"Krzysztof Kozlowski" <krzysztof.kozlowski@canonical.com>,
	"Helge Deller" <deller@gmx.de>,
	"the arch/x86 maintainers" <x86@kernel.org>,
	"Russell King" <linux@armlinux.org.uk>,
	linux-csky@vger.kernel.org,
	"Jonathan Hunter" <jonathanh@nvidia.com>,
	"ACPI Devel Maling List" <linux-acpi@vger.kernel.org>,
	"Ingo Molnar" <mingo@redhat.com>,
	"Geert Uytterhoeven" <geert@linux-m68k.org>,
	xen-devel@lists.xenproject.org, linux-mips@vger.kernel.org,
	"Guenter Roeck" <linux@roeck-us.net>,
	"Len Brown" <lenb@kernel.org>,
	"Albert Ou" <aou@eecs.berkeley.edu>,
	"Lee Jones" <lee.jones@linaro.org>,
	"Michał Mirosław" <mirq-linux@rere.qmqm.pl>,
	linux-m68k@lists.linux-m68k.org,
	"Mark Brown" <broonie@kernel.org>,
	"Borislav Petkov" <bp@alien8.de>,
	"Greentime Hu" <green.hu@gmail.com>,
	"Paul Walmsley" <paul.walmsley@sifive.com>,
	linux-tegra <linux-tegra@vger.kernel.org>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
	"Linux ARM" <linux-arm-kernel@lists.infradead.org>,
	"Juergen Gross" <jgross@suse.com>,
	"Thomas Bogendoerfer" <tsbogend@alpha.franken.de>,
	"Daniel Lezcano" <daniel.lezcano@linaro.org>,
	linux-parisc@vger.kernel.org,
	"Linux PM" <linux-pm@vger.kernel.org>,
	"Sebastian Reichel" <sre@kernel.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"K . C . Kuen-Chern Lin" <kclin@andestech.com>,
	"Palmer Dabbelt" <palmer@dabbelt.com>,
	"Philipp Zabel" <p.zabel@pengutronix.de>,
	"Guo Ren" <guoren@kernel.org>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	"Joshua Thompson" <funaho@jurai.org>
Subject: Re: [PATCH v4 05/25] reboot: Warn if restart handler has duplicated priority
Date: Fri, 10 Dec 2021 22:04:27 +0300	[thread overview]
Message-ID: <45025b2d-4be1-f694-be61-31903795cf5d@gmail.com> (raw)
In-Reply-To: <CAJZ5v0jMvdhfBqjY+V9h_Z6EH1ohuJH+KjuGiOw_Jor1Tnp7vg@mail.gmail.com>

10.12.2021 21:27, Rafael J. Wysocki пишет:
> On Mon, Nov 29, 2021 at 12:34 PM Dmitry Osipenko <digetx@gmail.com> wrote:
>>
>> 29.11.2021 03:26, Michał Mirosław пишет:
>>> On Mon, Nov 29, 2021 at 12:06:19AM +0300, Dmitry Osipenko wrote:
>>>> 28.11.2021 03:28, Michał Mirosław пишет:
>>>>> On Fri, Nov 26, 2021 at 09:00:41PM +0300, Dmitry Osipenko wrote:
>>>>>> Add sanity check which ensures that there are no two restart handlers
>>>>>> registered with the same priority. Normally it's a direct sign of a
>>>>>> problem if two handlers use the same priority.
>>>>>
>>>>> The patch doesn't ensure the property that there are no duplicated-priority
>>>>> entries on the chain.
>>>>
>>>> It's not the exact point of this patch.
>>>>
>>>>> I'd rather see a atomic_notifier_chain_register_unique() that returns
>>>>> -EBUSY or something istead of adding an entry with duplicate priority.
>>>>> That way it would need only one list traversal unless you want to
>>>>> register the duplicate anyway (then you would call the older
>>>>> atomic_notifier_chain_register() after reporting the error).
>>>>
>>>> The point of this patch is to warn developers about the problem that
>>>> needs to be fixed. We already have such troubling drivers in mainline.
>>>>
>>>> It's not critical to register different handlers with a duplicated
>>>> priorities, but such cases really need to be corrected. We shouldn't
>>>> break users' machines during transition to the new API, meanwhile
>>>> developers should take action of fixing theirs drivers.
>>>>
>>>>> (Or you could return > 0 when a duplicate is registered in
>>>>> atomic_notifier_chain_register() if the callers are prepared
>>>>> for that. I don't really like this way, though.)
>>>>
>>>> I had a similar thought at some point before and decided that I'm not in
>>>> favor of this approach. It's nicer to have a dedicated function that
>>>> verifies the uniqueness, IMO.
>>>
>>> I don't like the part that it traverses the list second time to check
>>> the uniqueness. But actually you could avoid that if
>>> notifier_chain_register() would always add equal-priority entries in
>>> reverse order:
>>>
>>>  static int notifier_chain_register(struct notifier_block **nl,
>>>               struct notifier_block *n)
>>>  {
>>>       while ((*nl) != NULL) {
>>>               if (unlikely((*nl) == n)) {
>>>                       WARN(1, "double register detected");
>>>                       return 0;
>>>               }
>>> -             if (n->priority > (*nl)->priority)
>>> +             if (n->priority >= (*nl)->priority)
>>>                       break;
>>>               nl = &((*nl)->next);
>>>       }
>>>       n->next = *nl;
>>>       rcu_assign_pointer(*nl, n);
>>>       return 0;
>>>  }
>>>
>>> Then the check for uniqueness after adding would be:
>>>
>>>  WARN(nb->next && nb->priority == nb->next->priority);
>>
>> We can't just change the registration order because invocation order of
>> the call chain depends on the registration order
> 
> It doesn't if unique priorities are required and isn't that what you want?
> 
>> and some of current
>> users may rely on that order. I'm pretty sure that changing the order
>> will have unfortunate consequences.
> 
> Well, the WARN() doesn't help much then.
> 
> Either you can make all of the users register with unique priorities,
> and then you can make the registration reject non-unique ones, or you
> cannot assume them to be unique.

There is no strong requirement for priorities to be unique, the reboot.c
code will work properly.

The potential problem is on the user's side and the warning is intended
to aid the user.

We can make it a strong requirement, but only after converting and
testing all kernel drivers. I'll consider to add patches for that.

WARNING: multiple messages have this Message-ID (diff)
From: Dmitry Osipenko <digetx@gmail.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: "Michał Mirosław" <mirq-linux@rere.qmqm.pl>,
	"Thierry Reding" <thierry.reding@gmail.com>,
	"Jonathan Hunter" <jonathanh@nvidia.com>,
	"Russell King" <linux@armlinux.org.uk>,
	"Catalin Marinas" <catalin.marinas@arm.com>,
	"Will Deacon" <will@kernel.org>, "Guo Ren" <guoren@kernel.org>,
	"Geert Uytterhoeven" <geert@linux-m68k.org>,
	"Greg Ungerer" <gerg@linux-m68k.org>,
	"Joshua Thompson" <funaho@jurai.org>,
	"Thomas Bogendoerfer" <tsbogend@alpha.franken.de>,
	"Sebastian Reichel" <sre@kernel.org>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Philipp Zabel" <p.zabel@pengutronix.de>,
	"Greentime Hu" <green.hu@gmail.com>,
	"Vincent Chen" <deanbo422@gmail.com>,
	"James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
	"Helge Deller" <deller@gmx.de>,
	"Michael Ellerman" <mpe@ellerman.id.au>,
	"Benjamin Herrenschmidt" <benh@kernel.crashing.org>,
	"Paul Mackerras" <paulus@samba.org>,
	"Paul Walmsley" <paul.walmsley@sifive.com>,
	"Palmer Dabbelt" <palmer@dabbelt.com>,
	"Albert Ou" <aou@eecs.berkeley.edu>,
	"Yoshinori Sato" <ysato@users.sourceforge.jp>,
	"Rich Felker" <dalias@libc.org>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Ingo Molnar" <mingo@redhat.com>,
	"Borislav Petkov" <bp@alien8.de>,
	"Dave Hansen" <dave.hansen@linux.intel.com>,
	"the arch/x86 maintainers" <x86@kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	"Boris Ostrovsky" <boris.ostrovsky@oracle.com>,
	"Juergen Gross" <jgross@suse.com>,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	"Len Brown" <lenb@kernel.org>,
	"Santosh Shilimkar" <ssantosh@kernel.org>,
	"Krzysztof Kozlowski" <krzysztof.kozlowski@canonical.com>,
	"Liam Girdwood" <lgirdwood@gmail.com>,
	"Mark Brown" <broonie@kernel.org>, "Pavel Machek" <pavel@ucw.cz>,
	"Lee Jones" <lee.jones@linaro.org>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Guenter Roeck" <linux@roeck-us.net>,
	"Daniel Lezcano" <daniel.lezcano@linaro.org>,
	"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
	"Ulf Hansson" <ulf.hansson@linaro.org>,
	alankao@andestech.com,
	"K . C . Kuen-Chern Lin" <kclin@andestech.com>,
	"Linux ARM" <linux-arm-kernel@lists.infradead.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	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 <linuxppc-dev@lists.ozlabs.org>,
	linux-riscv@lists.infradead.org,
	"Linux-sh list" <linux-sh@vger.kernel.org>,
	xen-devel@lists.xenproject.org,
	"ACPI Devel Maling List" <linux-acpi@vger.kernel.org>,
	"Linux PM" <linux-pm@vger.kernel.org>,
	linux-tegra <linux-tegra@vger.kernel.org>
Subject: Re: [PATCH v4 05/25] reboot: Warn if restart handler has duplicated priority
Date: Fri, 10 Dec 2021 19:04:27 +0000	[thread overview]
Message-ID: <45025b2d-4be1-f694-be61-31903795cf5d@gmail.com> (raw)
In-Reply-To: <CAJZ5v0jMvdhfBqjY+V9h_Z6EH1ohuJH+KjuGiOw_Jor1Tnp7vg@mail.gmail.com>

10.12.2021 21:27, Rafael J. Wysocki пишет:
> On Mon, Nov 29, 2021 at 12:34 PM Dmitry Osipenko <digetx@gmail.com> wrote:
>>
>> 29.11.2021 03:26, Michał Mirosław пишет:
>>> On Mon, Nov 29, 2021 at 12:06:19AM +0300, Dmitry Osipenko wrote:
>>>> 28.11.2021 03:28, Michał Mirosław пишет:
>>>>> On Fri, Nov 26, 2021 at 09:00:41PM +0300, Dmitry Osipenko wrote:
>>>>>> Add sanity check which ensures that there are no two restart handlers
>>>>>> registered with the same priority. Normally it's a direct sign of a
>>>>>> problem if two handlers use the same priority.
>>>>>
>>>>> The patch doesn't ensure the property that there are no duplicated-priority
>>>>> entries on the chain.
>>>>
>>>> It's not the exact point of this patch.
>>>>
>>>>> I'd rather see a atomic_notifier_chain_register_unique() that returns
>>>>> -EBUSY or something istead of adding an entry with duplicate priority.
>>>>> That way it would need only one list traversal unless you want to
>>>>> register the duplicate anyway (then you would call the older
>>>>> atomic_notifier_chain_register() after reporting the error).
>>>>
>>>> The point of this patch is to warn developers about the problem that
>>>> needs to be fixed. We already have such troubling drivers in mainline.
>>>>
>>>> It's not critical to register different handlers with a duplicated
>>>> priorities, but such cases really need to be corrected. We shouldn't
>>>> break users' machines during transition to the new API, meanwhile
>>>> developers should take action of fixing theirs drivers.
>>>>
>>>>> (Or you could return > 0 when a duplicate is registered in
>>>>> atomic_notifier_chain_register() if the callers are prepared
>>>>> for that. I don't really like this way, though.)
>>>>
>>>> I had a similar thought at some point before and decided that I'm not in
>>>> favor of this approach. It's nicer to have a dedicated function that
>>>> verifies the uniqueness, IMO.
>>>
>>> I don't like the part that it traverses the list second time to check
>>> the uniqueness. But actually you could avoid that if
>>> notifier_chain_register() would always add equal-priority entries in
>>> reverse order:
>>>
>>>  static int notifier_chain_register(struct notifier_block **nl,
>>>               struct notifier_block *n)
>>>  {
>>>       while ((*nl) != NULL) {
>>>               if (unlikely((*nl) = n)) {
>>>                       WARN(1, "double register detected");
>>>                       return 0;
>>>               }
>>> -             if (n->priority > (*nl)->priority)
>>> +             if (n->priority >= (*nl)->priority)
>>>                       break;
>>>               nl = &((*nl)->next);
>>>       }
>>>       n->next = *nl;
>>>       rcu_assign_pointer(*nl, n);
>>>       return 0;
>>>  }
>>>
>>> Then the check for uniqueness after adding would be:
>>>
>>>  WARN(nb->next && nb->priority = nb->next->priority);
>>
>> We can't just change the registration order because invocation order of
>> the call chain depends on the registration order
> 
> It doesn't if unique priorities are required and isn't that what you want?
> 
>> and some of current
>> users may rely on that order. I'm pretty sure that changing the order
>> will have unfortunate consequences.
> 
> Well, the WARN() doesn't help much then.
> 
> Either you can make all of the users register with unique priorities,
> and then you can make the registration reject non-unique ones, or you
> cannot assume them to be unique.

There is no strong requirement for priorities to be unique, the reboot.c
code will work properly.

The potential problem is on the user's side and the warning is intended
to aid the user.

We can make it a strong requirement, but only after converting and
testing all kernel drivers. I'll consider to add patches for that.

  reply	other threads:[~2021-12-10 19:04 UTC|newest]

Thread overview: 241+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-26 18:00 [PATCH v4 00/25] Introduce power-off+restart call chain API Dmitry Osipenko
2021-11-26 18:00 ` Dmitry Osipenko
2021-11-26 18:00 ` Dmitry Osipenko
2021-11-26 18:00 ` Dmitry Osipenko
2021-11-26 18:00 ` [PATCH v4 01/25] notifier: Remove extern annotation from function prototypes Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-26 18:00 ` [PATCH v4 02/25] notifier: Add blocking_notifier_call_chain_is_empty() Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-12-10 18:14   ` Rafael J. Wysocki
2021-12-10 18:14     ` Rafael J. Wysocki
2021-12-10 18:14     ` Rafael J. Wysocki
2021-12-10 18:14     ` Rafael J. Wysocki
2021-12-10 18:19     ` Dmitry Osipenko
2021-12-10 18:19       ` Dmitry Osipenko
2021-12-10 18:19       ` Dmitry Osipenko
2021-12-10 18:19       ` Dmitry Osipenko
2021-11-26 18:00 ` [PATCH v4 03/25] notifier: Add atomic/blocking_notifier_has_unique_priority() Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-12-10 18:19   ` Rafael J. Wysocki
2021-12-10 18:19     ` Rafael J. Wysocki
2021-12-10 18:19     ` Rafael J. Wysocki
2021-12-10 18:19     ` Rafael J. Wysocki
2021-12-10 18:52     ` Dmitry Osipenko
2021-12-10 18:52       ` Dmitry Osipenko
2021-12-10 18:52       ` Dmitry Osipenko
2021-12-10 18:52       ` Dmitry Osipenko
2021-12-10 19:05       ` Rafael J. Wysocki
2021-12-10 19:05         ` Rafael J. Wysocki
2021-12-10 19:05         ` Rafael J. Wysocki
2021-12-10 19:05         ` Rafael J. Wysocki
2021-12-10 19:33         ` Dmitry Osipenko
2021-12-10 19:33           ` Dmitry Osipenko
2021-12-10 19:33           ` Dmitry Osipenko
2021-12-10 19:33           ` Dmitry Osipenko
2021-12-10 20:16           ` Dmitry Osipenko
2021-12-10 20:16             ` Dmitry Osipenko
2021-12-10 20:16             ` Dmitry Osipenko
2021-12-10 20:16             ` Dmitry Osipenko
2021-11-26 18:00 ` [PATCH v4 04/25] reboot: Correct typo in a comment Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-12-10 18:21   ` Rafael J. Wysocki
2021-12-10 18:21     ` Rafael J. Wysocki
2021-12-10 18:21     ` Rafael J. Wysocki
2021-12-10 18:21     ` Rafael J. Wysocki
2021-11-26 18:00 ` [PATCH v4 05/25] reboot: Warn if restart handler has duplicated priority Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-28  0:28   ` Michał Mirosław
2021-11-28  0:28     ` Michał Mirosław
2021-11-28  0:28     ` Michał Mirosław
2021-11-28 21:06     ` Dmitry Osipenko
2021-11-28 21:06       ` Dmitry Osipenko
2021-11-28 21:06       ` Dmitry Osipenko
2021-11-29  0:26       ` Michał Mirosław
2021-11-29  0:26         ` Michał Mirosław
2021-11-29  0:26         ` Michał Mirosław
2021-11-29 11:34         ` Dmitry Osipenko
2021-11-29 11:34           ` Dmitry Osipenko
2021-11-29 11:34           ` Dmitry Osipenko
2021-11-29 11:34           ` Dmitry Osipenko
2021-12-10 18:27           ` Rafael J. Wysocki
2021-12-10 18:27             ` Rafael J. Wysocki
2021-12-10 18:27             ` Rafael J. Wysocki
2021-12-10 18:27             ` Rafael J. Wysocki
2021-12-10 19:04             ` Dmitry Osipenko [this message]
2021-12-10 19:04               ` Dmitry Osipenko
2021-12-10 19:04               ` Dmitry Osipenko
2021-12-10 19:04               ` Dmitry Osipenko
2021-12-10 19:14               ` Rafael J. Wysocki
2021-12-10 19:14                 ` Rafael J. Wysocki
2021-12-10 19:14                 ` Rafael J. Wysocki
2021-12-10 19:14                 ` Rafael J. Wysocki
2021-12-10 19:42                 ` Dmitry Osipenko
2021-12-10 19:42                   ` Dmitry Osipenko
2021-12-10 19:42                   ` Dmitry Osipenko
2021-12-10 19:42                   ` Dmitry Osipenko
2021-12-10 19:44                   ` Dmitry Osipenko
2021-12-10 19:44                     ` Dmitry Osipenko
2021-12-10 19:44                     ` Dmitry Osipenko
2021-12-10 19:44                     ` Dmitry Osipenko
2021-12-10 19:49                     ` Dmitry Osipenko
2021-12-10 19:49                       ` Dmitry Osipenko
2021-12-10 19:49                       ` Dmitry Osipenko
2021-12-10 19:49                       ` Dmitry Osipenko
2021-12-13  9:23                 ` Geert Uytterhoeven
2021-12-13  9:23                   ` Geert Uytterhoeven
2021-12-13  9:23                   ` Geert Uytterhoeven
2021-12-13  9:23                   ` Geert Uytterhoeven
2021-11-26 18:00 ` [PATCH v4 06/25] reboot: Warn if unregister_restart_handler() fails Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-12-10 18:32   ` Rafael J. Wysocki
2021-12-10 18:32     ` Rafael J. Wysocki
2021-12-10 18:32     ` Rafael J. Wysocki
2021-12-10 18:32     ` Rafael J. Wysocki
2021-12-10 18:54     ` Dmitry Osipenko
2021-12-10 18:54       ` Dmitry Osipenko
2021-12-10 18:54       ` Dmitry Osipenko
2021-12-10 18:54       ` Dmitry Osipenko
2021-12-10 19:08       ` Rafael J. Wysocki
2021-12-10 19:08         ` Rafael J. Wysocki
2021-12-10 19:08         ` Rafael J. Wysocki
2021-12-10 19:08         ` Rafael J. Wysocki
2021-12-10 19:38         ` Dmitry Osipenko
2021-12-10 19:38           ` Dmitry Osipenko
2021-12-10 19:38           ` Dmitry Osipenko
2021-12-10 19:38           ` Dmitry Osipenko
2021-11-26 18:00 ` [PATCH v4 07/25] reboot: Remove extern annotation from function prototypes Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-12-10 18:09   ` Rafael J. Wysocki
2021-12-10 18:09     ` Rafael J. Wysocki
2021-12-10 18:09     ` Rafael J. Wysocki
2021-12-10 18:09     ` Rafael J. Wysocki
2021-12-10 18:15     ` Dmitry Osipenko
2021-12-10 18:15       ` Dmitry Osipenko
2021-12-10 18:15       ` Dmitry Osipenko
2021-12-10 18:15       ` Dmitry Osipenko
2021-12-10 18:35       ` Rafael J. Wysocki
2021-12-10 18:35         ` Rafael J. Wysocki
2021-12-10 18:35         ` Rafael J. Wysocki
2021-12-10 18:35         ` Rafael J. Wysocki
2021-12-10 18:56         ` Dmitry Osipenko
2021-12-10 18:56           ` Dmitry Osipenko
2021-12-10 18:56           ` Dmitry Osipenko
2021-12-10 18:56           ` Dmitry Osipenko
2021-11-26 18:00 ` [PATCH v4 08/25] kernel: Add combined power-off+restart handler call chain API Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-28  0:43   ` Michał Mirosław
2021-11-28  0:43     ` Michał Mirosław
2021-11-28  0:43     ` Michał Mirosław
2021-11-28 21:04     ` Dmitry Osipenko
2021-11-28 21:04       ` Dmitry Osipenko
2021-11-28 21:04       ` Dmitry Osipenko
2021-11-28 21:17       ` Michał Mirosław
2021-11-28 21:17         ` Michał Mirosław
2021-11-28 21:17         ` Michał Mirosław
2021-11-28 21:53         ` Dmitry Osipenko
2021-11-28 21:53           ` Dmitry Osipenko
2021-11-28 21:53           ` Dmitry Osipenko
2021-11-28 21:53           ` Dmitry Osipenko
2021-11-29  0:36           ` Michał Mirosław
2021-11-29  0:36             ` Michał Mirosław
2021-11-29  0:36             ` Michał Mirosław
2021-11-29 11:52             ` Dmitry Osipenko
2021-11-29 11:52               ` Dmitry Osipenko
2021-11-29 11:52               ` Dmitry Osipenko
2021-11-29 11:52               ` Dmitry Osipenko
2021-11-26 18:00 ` [PATCH v4 09/25] ARM: Use do_kernel_power_off() Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-26 18:00 ` [PATCH v4 10/25] csky: " Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-26 18:00 ` [PATCH v4 11/25] riscv: " Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-26 18:00 ` [PATCH v4 12/25] arm64: " Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-26 18:00 ` [PATCH v4 13/25] parisc: " Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-26 18:00 ` [PATCH v4 14/25] xen/x86: " Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-26 18:00 ` [PATCH v4 15/25] powerpc: " Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-26 18:00 ` [PATCH v4 16/25] m68k: Switch to new sys-off handler API Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-26 18:00 ` [PATCH v4 17/25] sh: Use do_kernel_power_off() Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-26 18:00 ` [PATCH v4 18/25] x86: " Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-28  1:15   ` Michał Mirosław
2021-11-28  1:15     ` Michał Mirosław
2021-11-28  1:15     ` Michał Mirosław
2021-11-28 21:06     ` Dmitry Osipenko
2021-11-28 21:06       ` Dmitry Osipenko
2021-11-28 21:06       ` Dmitry Osipenko
2021-11-28 21:06       ` Dmitry Osipenko
2021-11-26 18:00 ` [PATCH v4 19/25] ia64: " Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-26 18:00 ` [PATCH v4 20/25] mips: " Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-26 18:00 ` [PATCH v4 21/25] nds32: " Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-26 18:00 ` [PATCH v4 22/25] memory: emif: Use kernel_can_power_off() Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-28  1:23   ` Michał Mirosław
2021-11-28  1:23     ` Michał Mirosław
2021-11-28  1:23     ` Michał Mirosław
2021-11-28 21:04     ` Dmitry Osipenko
2021-11-28 21:04       ` Dmitry Osipenko
2021-11-28 21:04       ` Dmitry Osipenko
2021-11-28 21:04       ` Dmitry Osipenko
2021-11-26 18:00 ` [PATCH v4 23/25] ACPI: power: Switch to sys-off handler API Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-26 18:00   ` Dmitry Osipenko
2021-11-26 18:01 ` [PATCH v4 24/25] regulator: pfuze100: Use devm_register_sys_off_handler() Dmitry Osipenko
2021-11-26 18:01   ` Dmitry Osipenko
2021-11-26 18:01   ` Dmitry Osipenko
2021-11-26 18:01   ` Dmitry Osipenko
2021-11-26 18:01 ` [PATCH v4 25/25] reboot: Remove pm_power_off_prepare() Dmitry Osipenko
2021-11-26 18:01   ` Dmitry Osipenko
2021-11-26 18:01   ` Dmitry Osipenko
2021-11-26 18:01   ` Dmitry Osipenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45025b2d-4be1-f694-be61-31903795cf5d@gmail.com \
    --to=digetx@gmail.com \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=akpm@linux-foundation.org \
    --cc=alankao@andestech.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=benh@kernel.crashing.org \
    --cc=boris.ostrovsky@oracle.com \
    --cc=bp@alien8.de \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=dalias@libc.org \
    --cc=daniel.lezcano@linaro.org \
    --cc=dave.hansen@linux.intel.com \
    --cc=deanbo422@gmail.com \
    --cc=deller@gmx.de \
    --cc=funaho@jurai.org \
    --cc=geert@linux-m68k.org \
    --cc=gerg@linux-m68k.org \
    --cc=green.hu@gmail.com \
    --cc=guoren@kernel.org \
    --cc=hpa@zytor.com \
    --cc=jgross@suse.com \
    --cc=jonathanh@nvidia.com \
    --cc=kclin@andestech.com \
    --cc=krzysztof.kozlowski@canonical.com \
    --cc=lee.jones@linaro.org \
    --cc=lenb@kernel.org \
    --cc=lgirdwood@gmail.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-csky@vger.kernel.org \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-m68k@lists.linux-m68k.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=linux@roeck-us.net \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mingo@redhat.com \
    --cc=mirq-linux@rere.qmqm.pl \
    --cc=mpe@ellerman.id.au \
    --cc=p.zabel@pengutronix.de \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=paulus@samba.org \
    --cc=pavel@ucw.cz \
    --cc=rafael@kernel.org \
    --cc=sre@kernel.org \
    --cc=ssantosh@kernel.org \
    --cc=sstabellini@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=thierry.reding@gmail.com \
    --cc=tsbogend@alpha.franken.de \
    --cc=ulf.hansson@linaro.org \
    --cc=will@kernel.org \
    --cc=x86@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    --cc=ysato@users.sourceforge.jp \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.