linux-kernel - Re: [PATCH v2] ACPI: processor: Fix build when CONFIG_ACPI

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 6 Apr 2021 17:45:25 +0200
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     Vitaly Kuznetsov <vkuznets@...hat.com>
Cc:     "Rafael J. Wysocki" <rafael@...nel.org>,
        ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        "the arch/x86 maintainers" <x86@...nel.org>,
        Len Brown <lenb@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "H. Peter Anvin" <hpa@...or.com>, Stable <stable@...r.kernel.org>,
        kernel test robot <lkp@...el.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] ACPI: processor: Fix build when CONFIG_ACPI_PROCESSOR=m

On Tue, Apr 6, 2021 at 5:39 PM Vitaly Kuznetsov <vkuznets@...hat.com> wrote:
>
> "Rafael J. Wysocki" <rafael@...nel.org> writes:
>
> > On Tue, Apr 6, 2021 at 4:01 PM Vitaly Kuznetsov <vkuznets@...hat.com> wrote:
> >>
> >> Commit 8cdddd182bd7 ("ACPI: processor: Fix CPU0 wakeup in
> >> acpi_idle_play_dead()") tried to fix CPU0 hotplug breakage by copying
> >> wakeup_cpu0() + start_cpu0() logic from hlt_play_dead()//mwait_play_dead()
> >> into acpi_idle_play_dead(). The problem is that these functions are not
> >> exported to modules so when CONFIG_ACPI_PROCESSOR=m build fails.
> >>
> >> The issue could've been fixed by exporting both wakeup_cpu0()/start_cpu0()
> >> (the later from assembly) but it seems putting the whole pattern into a
> >> new function and exporting it instead is better.
> >>
> >> Reported-by: kernel test robot <lkp@...el.com>
> >> Fixes: 8cdddd182bd7 ("CPI: processor: Fix CPU0 wakeup in acpi_idle_play_dead()")
> >> Cc: <stable@...r.kernel.org> # 5.10+
> >> Signed-off-by: Vitaly Kuznetsov <vkuznets@...hat.com>
> >> ---
> >> Changes since v1:
> >> - Rename wakeup_cpu0() to cond_wakeup_cpu0() and fold wakeup_cpu0() in
> >>  as it has no other users [Rafael J. Wysocki]
> >> ---
> >>  arch/x86/include/asm/smp.h    |  2 +-
> >>  arch/x86/kernel/smpboot.c     | 24 ++++++++++--------------
> >>  drivers/acpi/processor_idle.c |  4 +---
> >>  3 files changed, 12 insertions(+), 18 deletions(-)
> >>
> >> diff --git a/arch/x86/include/asm/smp.h b/arch/x86/include/asm/smp.h
> >> index 57ef2094af93..630ff08532be 100644
> >> --- a/arch/x86/include/asm/smp.h
> >> +++ b/arch/x86/include/asm/smp.h
> >> @@ -132,7 +132,7 @@ void native_play_dead(void);
> >>  void play_dead_common(void);
> >>  void wbinvd_on_cpu(int cpu);
> >>  int wbinvd_on_all_cpus(void);
> >> -bool wakeup_cpu0(void);
> >> +void cond_wakeup_cpu0(void);
> >>
> >>  void native_smp_send_reschedule(int cpu);
> >>  void native_send_call_func_ipi(const struct cpumask *mask);
> >> diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
> >> index f877150a91da..147f1bba9736 100644
> >> --- a/arch/x86/kernel/smpboot.c
> >> +++ b/arch/x86/kernel/smpboot.c
> >> @@ -1659,13 +1659,15 @@ void play_dead_common(void)
> >>         local_irq_disable();
> >>  }
> >>
> >> -bool wakeup_cpu0(void)
> >> +/*
> >> + * If NMI wants to wake up CPU0, start CPU0.
> >> + */
> >
> > Hasn't checkpatch.pl complained about this?
> >
>
> No, it didn't.
>
> > A proper kerneldoc would be something like:
> >
> > /**
> >  * cond_wakeup_cpu0 - Wake up CPU0 if needed.
> >  *
> >  * If NMI wants to wake up CPU0, start CPU0.
> >  */
>
> Yea, I didn't do that partly because of my laziness but partly because
> I don't see much usage of this format in arch/x86/kernel/[smpboot.c]. I
> can certainly do v3 if it's prefered.

Yes, please.

Exported functions generally need proper kerneldoc comments.