--Andy
> On Dec 30, 2017, at 11:15 AM, Linus Torvalds <[email protected]> > wrote: > > On Sat, Dec 30, 2017 at 11:03 AM, Dave Hansen > <[email protected]> wrote: >> 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. > > Hmm. I think you're right. > >> 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(). > > Agreed, that would certainly also be consistent. > > The current code that disables preemption only selectively seems > insane to me. Either all or nothing, not this crazy half-way thing. Agreed. The current code is bogus. I'd rather have a warning if preemptible. I'm reasonably confident that IRQs on but preempt off is okay. > > Linus
