linux-kernel - Re: [PATCH] smp: Do not warn if smp_call_function

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <875zrhf4zh.fsf@vitty.brq.redhat.com>
Date:   Sun, 14 Apr 2019 08:58:10 +0200
From:   Vitaly Kuznetsov <vkuznets@...hat.com>
To:     Dexuan Cui <decui@...rosoft.com>
Cc:     "marcelo.cerri\@canonical.com" <marcelo.cerri@...onical.com>,
        "apw\@canonical.com" <apw@...onical.com>,
        "olaf\@aepfle.de" <olaf@...fle.de>,
        "jasowang\@redhat.com" <jasowang@...hat.com>,
        Dexuan Cui <decui@...rosoft.com>,
        "tglx\@linutronix.de" <tglx@...utronix.de>,
        "riel\@surriel.com" <riel@...riel.com>,
        "peterz\@infradead.org" <peterz@...radead.org>,
        "jpoimboe\@redhat.com" <jpoimboe@...hat.com>,
        "luto\@kernel.org" <luto@...nel.org>,
        Stephen Hemminger <sthemmin@...rosoft.com>,
        Sasha Levin <Alexander.Levin@...rosoft.com>,
        Haiyang Zhang <haiyangz@...rosoft.com>,
        KY Srinivasan <kys@...rosoft.com>,
        "linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
        Michael Kelley <mikelley@...rosoft.com>
Subject: Re: [PATCH] smp: Do not warn if smp_call_function_single() is doing a self call.

Dexuan Cui <decui@...rosoft.com> writes:

> If smp_call_function_single() is calling the function for itself, it's safe
> to run with irqs_disabled() == true.
>
> I hit the warning because I'm in the below path in the .suspend callback of
> a "syscore_ops" to support hibernation for a VM running on Hyper-V:
>
>   hv_synic_cleanup() ->
>     clockevents_unbind_device() ->
>       clockevents_unbind() ->
>         smp_call_function_single().
>

I'd suggest fixing clockevents_unbind() instead, something like
(completely untested):

diff --git a/kernel/time/clockevents.c b/kernel/time/clockevents.c
index 5e77662dd2d9..d14e881a8808 100644
--- a/kernel/time/clockevents.c
+++ b/kernel/time/clockevents.c
@@ -418,8 +418,17 @@ static void __clockevents_unbind(void *arg)
 static int clockevents_unbind(struct clock_event_device *ced, int cpu)
 {
        struct ce_unbind cu = { .ce = ced, .res = -ENODEV };
+       int this_cpu;
+
+       this_cpu = get_cpu();
+
+       if (cpu != this_cpu)
+               smp_call_function_single(cpu, __clockevents_unbind, &cu, 1);
+       else
+               __clockevents_unbind(&cu);
+
+       put_cpu();
 
-       smp_call_function_single(cpu, __clockevents_unbind, &cu, 1);
        return cu.res;
 }

> When the .suspend callback runs, only CPU0 is online and irqs_disabled() is
> true.
>
> Signed-off-by: Dexuan Cui <decui@...rosoft.com>
> ---
>  kernel/smp.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/smp.c b/kernel/smp.c
> index f4cf1b0bb3b8..4fdf6a378def 100644
> --- a/kernel/smp.c
> +++ b/kernel/smp.c
> @@ -288,7 +288,7 @@ int smp_call_function_single(int cpu, smp_call_func_t func, void *info,
>  	 * can't happen.
>  	 */
>  	WARN_ON_ONCE(cpu_online(this_cpu) && irqs_disabled()
> -		     && !oops_in_progress);
> +		     && cpu != smp_processor_id() && !oops_in_progress);

You already have 'this_cpu', no need to call smp_processor_id(). 

>  
>  	csd = &csd_stack;
>  	if (!wait) {

-- 
Vitaly