[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1d17349e-98ab-b582-6981-b484b0e970b6@redhat.com>
Date: Mon, 7 Oct 2019 21:36:25 +0200
From: Hans de Goede <hdegoede@...hat.com>
To: Arvind Sankar <nivedita@...m.mit.edu>,
Ingo Molnar <mingo@...nel.org>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
"H . Peter Anvin" <hpa@...or.com>,
Herbert Xu <herbert@...dor.apana.org.au>,
Ard Biesheuvel <ard.biesheuvel@...aro.org>,
linux-crypto@...r.kernel.org, x86@...nel.org,
linux-kernel@...r.kernel.org,
Stephan Mueller <smueller@...onox.de>,
linux-s390@...r.kernel.org
Subject: Re: [PATCH v2 5.4 regression fix] x86/boot: Provide memzero_explicit
Hi,
On 07-10-2019 20:42, Arvind Sankar wrote:
> On Mon, Oct 07, 2019 at 05:40:07PM +0200, Ingo Molnar wrote:
>>
>> * Arvind Sankar <nivedita@...m.mit.edu> wrote:
>>
>>> With the barrier in there, is there any reason to *not* inline the
>>> function? barrier_data() is an asm statement that tells the compiler
>>> that the asm uses the memory that was set to zero, thus preventing it
>>> from removing the memset even if nothing else uses that memory later. A
>>> more detailed comment is there in compiler-gcc.h. I can't see why it
>>> wouldn't work even if it were inlined.
>>>
>>> If the function can indeed be inlined, we could just make the common
>>> implementation a macro and avoid duplicating it? As mentioned in another
>>> mail, we otherwise will likely need another duplicate implementation for
>>> arch/s390/purgatory as well.
>>
>> I suspect macro would be justified in this case. Mind sending a v3 patch
>> to demonstrate how it would all look like?
>>
>> I'll zap v2 if the macro solution looks better.
>>
>> Thanks,
>>
>> Ingo
>
> Patch attached to turn memzero_explicit into inline function.
Hehe, I had prepared and have just tested the exact same patch
(only the commit msg was different).
I've just booted a kernel build with that patch and that works
fine (as expected).
So your patch is:
Reviewed-by: Hans de Goede <hdegoede@...hat.com>
Tested-by: Hans de Goede <hdegoede@...hat.com>
Since this is a bit of a core change though, I think it is
best if you send it to the linux-kernel list (with my tags from above
added) as is normally done for kernel patches. Then others, who may
not be following this thread, will get a chance to give feedback on it.
Regards,
Hans
Powered by blists - more mailing lists