linux-kernel - Re: [PATCH v3 3/9] x86/mm/tlb: Open-code on_each_cpu_cond_mask() for tlb_is_not

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: <D13BA044-AC02-46A7-9C5C-48FE8B6E8F63@vmware.com>
Date:   Fri, 19 Jul 2019 23:02:47 +0000
From:   Nadav Amit <namit@...are.com>
To:     Joe Perches <joe@...ches.com>
CC:     Dave Hansen <dave.hansen@...el.com>,
        Andy Lutomirski <luto@...nel.org>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "x86@...nel.org" <x86@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        Rik van Riel <riel@...riel.com>,
        Josh Poimboeuf <jpoimboe@...hat.com>
Subject: Re: [PATCH v3 3/9] x86/mm/tlb: Open-code on_each_cpu_cond_mask() for
 tlb_is_not_lazy()

> On Jul 19, 2019, at 3:44 PM, Joe Perches <joe@...ches.com> wrote:
> 
> On Fri, 2019-07-19 at 18:41 +0000, Nadav Amit wrote:
>>> On Jul 19, 2019, at 11:36 AM, Dave Hansen <dave.hansen@...el.com> wrote:
>>> 
>>> On 7/18/19 5:58 PM, Nadav Amit wrote:
>>>> @@ -865,7 +893,7 @@ void arch_tlbbatch_flush(struct arch_tlbflush_unmap_batch *batch)
>>>> 	if (cpumask_test_cpu(cpu, &batch->cpumask)) {
>>>> 		lockdep_assert_irqs_enabled();
>>>> 		local_irq_disable();
>>>> -		flush_tlb_func_local(&full_flush_tlb_info);
>>>> +		flush_tlb_func_local((void *)&full_flush_tlb_info);
>>>> 		local_irq_enable();
>>>> 	}
>>> 
>>> This looks like superfluous churn.  Is it?
>> 
>> Unfortunately not, since full_flush_tlb_info is defined as const. Without it
>> you would get:
>> 
>> warning: passing argument 1 of ‘flush_tlb_func_local’ discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
>> 
>> And flush_tlb_func_local() should get (void *) argument since it is also
>> used by the SMP infrastructure.
> 
> huh?
> 
> commit 3db6d5a5ecaf0a778d721ccf9809248350d4bfaf
> Author: Nadav Amit <namit@...are.com>
> Date:   Thu Apr 25 16:01:43 2019 -0700
> 
> []
> 
> -static void flush_tlb_func_local(void *info, enum tlb_flush_reason reason)
> +static void flush_tlb_func_local(const void *info, enum tlb_flush_reason reason)

Hopefully I decipher the “huh?” correctly...

When we moved the flush_tlb_info off the stack, in the patch that you
reference, we created a global full_flush_tlb_info variable, which was set
as const and delivered to flush_tlb_func_local. I changed the signature of
the function to avoid casting. IIRC, setting the variable as constant
slightly improved the generated assembly, and anyhow made sense.

In this patch-set I need to change the first argument of
flush_tlb_func_local to be non-const to match the SMP function signature
which takes a single non-const void * argument. Yes, there is what seems to
be non-safe casting, but flush_tlb_func_common() casts it back into a const
variable.

I know that I also added the infrastructure to run a function locally in the
SMP infrastructure, but it made sense to have the same signature for local
function and remote ones.

Does it make more sense now?