Messages in this thread |  | | Subject | Re: x86/pti: smp_processor_id() called while preemptible in resume-from-sleep | From | Dave Hansen <> | Date | Sat, 30 Dec 2017 11:03:30 -0800 |
| |
On 12/30/2017 10:40 AM, Linus Torvalds wrote: > The __native_flush_tlb() function looks _very_ broken. ... > So I'd suggest moving the preempt_disable() up to the top of that > function, regardless of whether we could then remove that seemingly > stale TLB flush in that crazy > smpboot_setup/restore_warm_reset_vector() dance...
If someone is calling __native_flush_tlb(), shouldn't they already be in a state where they can't be preempted? It's fundamentally a one-cpu thing, both the actual CPU TLB flush _and_ the per-cpu variables.
It seems like we might want to _remove_ the explicit preempt_dis/enable() from here:
preempt_disable(); native_write_cr3(__native_read_cr3()); preempt_enable();
and add some warnings to ensure it's disabled when we enter __native_flush_tlb().
|  |