Re: [PATCH v9 15/24] mm: Introduce __vm_normal_page()
From: Jerome Glisse <hidden>
Date: 2018-04-04 21:59:26
Also in:
linux-mm, lkml
On Wed, Apr 04, 2018 at 06:26:44PM +0200, Laurent Dufour wrote:
On 03/04/2018 21:39, Jerome Glisse wrote:quoted
On Tue, Mar 13, 2018 at 06:59:45PM +0100, Laurent Dufour wrote:quoted
When dealing with the speculative fault path we should use the VMA's field cached value stored in the vm_fault structure. Currently vm_normal_page() is using the pointer to the VMA to fetch the vm_flags value. This patch provides a new __vm_normal_page() which is receiving the vm_flags flags value as parameter. Note: The speculative path is turned on for architecture providing support for special PTE flag. So only the first block of vm_normal_page is used during the speculative path.Might be a good idea to explicitly have SPECULATIVE Kconfig option depends on ARCH_PTE_SPECIAL and a comment for !HAVE_PTE_SPECIAL in the function explaining that speculative page fault should never reach that point.Unfortunately there is no ARCH_PTE_SPECIAL in the config file, it is defined in the per architecture header files. So I can't do anything in the Kconfig file
Maybe adding a new Kconfig symbol for ARCH_PTE_SPECIAL very much like others ARCH_HAS_
quoted hunk ↗ jump to hunk
However, I can check that at build time, and doing such a check in __vm_normal_page sounds to be a good place, like that:@@ -869,6 +870,14 @@ struct page *__vm_normal_page(struct vm_area_struct *vma,unsigned long addr, /* !HAVE_PTE_SPECIAL case follows: */ +#ifdef CONFIG_SPECULATIVE_PAGE_FAULT + /* This part should never get called when the speculative page fault + * handler is turned on. This is mainly because we can't rely on + * vm_start. + */ +#error CONFIG_SPECULATIVE_PAGE_FAULT requires HAVE_PTE_SPECIAL +#endif + if (unlikely(vma_flags & (VM_PFNMAP|VM_MIXEDMAP))) { if (vma_flags & VM_MIXEDMAP) { if (!pfn_valid(pfn))
I am not a fan of #if/#else/#endif in code. But that's a taste thing. I honnestly think that adding a Kconfig for special pte is the cleanest solution. Cheers, Jérôme