Please, Ingo, could you give an example of where such additional locking
is actually necessary?
I ask because I went over those places when splitting the page_table_lock
for userspace in 2.6.15. Some things took init_mm.page_table_lock and
some things didn't, and I concluded that actually none of them needed it.
With the userspace pagetables, we need to guard against racing threads
and vmscan/rmap. But with the kernel pagetables, we'd already be in
serious trouble if two cpus could be modifying the same pte at the
same time - there needs to be other serialization already e.g. vmalloc
has its own locking for parcelling out areas to different uses, so down
at the page table level there should be no conflict.
Allocation of new page tables, yes, that needs locking, and does use
the page_table_lock for kernel space just as for user space.
That was all two years ago, I may have been wrong then, or a lot may
have changed since. But I've heard of a grand total of 0 problems
from not having such locking.
And on the original topic of flush TLB without preemption disabled:
again I'm not sure there's a bug there, but it's less clear. Aren't
some of those __flush_tlb_ones just unnecessary, we're simply filling
a previously empty slot? And if there's a guarantee that preemption
will itself involve a TLB flush (maybe there's no such guarantee for
these kernel entries, it's quite a different case from the userspace
one, and you'll be worrying about the global bit), if, then it'd be
okay to __flush_tlb_one without disabling preemption.
Hugh
--
