On Tue, Oct 31, 2017 at 03:28:26PM +0100, Vlastimil Babka wrote:
> Hmm that could indeed work, Dmitry can you try the patch below?
> But it still seems rather fragile so I'd hope Andrea can do it more
> robust, or at least make sure that we don't reintroduce this kind of
> problem in the future (explicitly set vma to NULL with a comment?).
Reviewed-by: Andrea Arcangeli <aarcange@xxxxxxxxxx>
>
> ----8<----
> diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
> index e2baeaa053a5..9bd16fc621db 100644
> --- a/arch/x86/mm/fault.c
> +++ b/arch/x86/mm/fault.c
> @@ -1441,6 +1441,7 @@ __do_page_fault(struct pt_regs *regs, unsigned long error_code,
> * the fault. Since we never set FAULT_FLAG_RETRY_NOWAIT, if
> * we get VM_FAULT_RETRY back, the mmap_sem has been unlocked.
> */
> + pkey = vma_pkey(vma);
> fault = handle_mm_fault(vma, address, flags);
> major |= fault & VM_FAULT_MAJOR;
>
> @@ -1467,7 +1468,6 @@ __do_page_fault(struct pt_regs *regs, unsigned long error_code,
> return;
> }
>
> - pkey = vma_pkey(vma);
> up_read(&mm->mmap_sem);
> if (unlikely(fault & VM_FAULT_ERROR)) {
> mm_fault_error(regs, error_code, address, &pkey, fault);
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
