On 08/04/2015 01:32 PM, Leonid Yegoshin wrote:
David,
It is interesting, I still don't understand the effect
I think the best way to think about it is to ignore vmap, and consider
the semantics of set_pte().
When a thread calls set_pte() it must ensure that no other thread will
crash using VA region covered by the PTE. That is the contract of
set_pte().
The MIPS set_pte() does something different. In addition to setting the
specified PTE, it has the side effect of clobbering another PTE (called
the buddy). There is nothing in the kernel that prevents a another
thread from using the buddy-PTE, and when that happens in the race
window, the page tables are corrupted, and the system crashes.
The fix is to not clobber the buddy-PTE.
You can go around in circles all you want trying to indirectly avoid
using the buddy-PTE from another thread, but I think it is best to make
set_pte() have easily understood semantics (and semantics that match
those of other architectures) and not clobber things in unexpected ways.
David Daney.
- if guard page
is used then two different VMAP allocations can't use two buddy PTEs.
Yes, only one of buddy PTEs in that case can be allocated and attached
to VMA but caller doesn't know about additional page and two cases are
possible. Even map_vm_area has no any info about guard page.
(assume VMA1 has low address range and VMA2 has higher address range):
a. VMA1 (after adjustment) ends at even PTE ==> caller doesn't use that
PTE and there is no collision with last pair of buddy PTEs, even if VMA2
uses odd PTE from that pair.
b. VMA1 (after adjustment) ends at odd PTE ==> again, this buddy pair
is used only VMA1. Next VMA2 start from next pair.
What is wrong here?
Is it possible that access gone bad and touches a page beyond a
requested size?
Is it possible that it is not vmap() but some different interface was used?
- Leonid.
