No. If you look at the TLB handler, you will see that locking is not done for misses in
On Sat, 26 Dec 2015, Helge Deller wrote:
On 26.12.2015 13:09, Mikulas Patocka wrote:I tested the patch and it works OK for me so far.
BTW. I looked at this in arch/parisc/mm/hugetlbpage.c:set_huge_pte_atRight.
"*ptep = entry;" and it seems like a bad bug. PA-RISC doesn't have atomic
instructions to modify page table entries, so it takes spinlock in the TLB
handler and modifies the page table entry non-atomically. If you modify
the page table entry without the spinlock, you may race with TLB handler
on another CPU and your modification may be lost.
The comment says something about double locking on pa_tlb_lock, butI have a work-in-progress patch for that in one of my trees, e.g.:
pa_tlb_lock isn't held when that function is called.
http://git.kernel.org/cgit/linux/kernel/git/deller/parisc-linux.git/commit/?h=parisc-next&id=5c76b525cbdb097401f46522b27b1eb6244f34f9
It's lightly tested though.
Helge
BTW. what happens if some kernel code takes the TLB spinlock and then TLB
miss in kernel space happens? (it would attempt to lock the spinlock
recursively) Is it assumed that the TLB is big enough that this can't
happen?