* Dave Hansen <[email protected]> wrote:
> On 09/25/2015 11:20 PM, Ingo Molnar wrote:
> > * Dave Hansen <[email protected]> wrote:
> ...
> >> Since follow_pte() fails for all huge
> >> pages, it just falls back to pulling the protection key out of the VMA,
> >> which _does_ work for huge pages.
> >
> > That might be true for explicit hugetlb vmas, but what about transparent
> > hugepages
> > that can show up in regular vmas?
>
> All PTEs (large or small) established under a given VMA have the same
> protection key. [...]
So a 'pte' is only small. The 'large' thing is called a pmd. So follow_pte() is
not adequate. But with that removed everything should be fine as the vma
(protection) flags are size independent.
> So I think it's safe to rely on the VMA entirely. Well, as least as safe as
> the
> PTE. It's definitely a wee bit racy, which I'll elaborate on when I repost
> the
> patches.
So the race I can see is wrt. mprotect(), and we should fix that, because the
existing method of recovering the 'page fault reason', error_code, is not racy
-
so the extension of it (the protection key) should not be racy either.
By the time user-space processes the signal we might race with other threads,
but
at least the fault-address/error-reason information itself should be coherent.
This can be solved by getting the protection key while still under the
down_read()
of the vma - instead of your current solution of a second find_vma().
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
