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  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]
Date:   Wed, 25 Oct 2017 08:58:22 +0200
From:   Juergen Gross <>
To:     Dou Liyang <>,,
Subject: Re: [PATCH] paravirt/locks: avoid modifying static key before

On 25/10/17 06:26, Dou Liyang wrote:
> Hi Juergen,
> At 10/23/2017 09:49 PM, Juergen Gross wrote:
>> Don't try to set the static virt_spin_lock_key to a value before
>> jump_label_init() has been called, as this will result in a WARN().
>> Solve the problem by introducing a new lock_init() hook called after
>> jump_label_init() instead of doing the call inside of
>> smp_prepare_boot_cpu().
>> Signed-off-by: Juergen Gross <>
>> ---
>> Based on kernel/git/tip/tip.git locking/core
> I also found that WARN() in tip tree.
> IMO, adding a hook in start_kernel() is not elegant. It will
> affect other arches and increase the complexity of the system.
> I like your original method.
> So, I try to fix it by moving the native_pv_lock_init() from
>  native_smp_prepare_boot_cpu() to native_smp_prepare_cpus().

Hmm, this might work, but the Xen case has to be modified (same for
my more general solution), as xen_init_spinlocks() is still modifying
the static key too early. And we can't move xen_init_spinlocks() to
smp_prepare_cpus() as this would be too late for the alternatives

So let me extend your patch a little bit to cover Xen, too.

> I hope it's useful to you.

It really is, thanks.


Powered by blists - more mailing lists