From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DBC18C433E1 for ; Fri, 31 Jul 2020 20:57:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BC4D722CA1 for ; Fri, 31 Jul 2020 20:57:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1596229032; bh=vdXEGu/7qMDVaKN9D44BCySt6O+PHbNNjTVbqhCGH4c=; h=Date:From:To:Subject:In-Reply-To:List-ID:From; b=N9CAR2kDWtT6F3ucdhSpbqIukAQoNzSIBg7Dx8Qj5Mgx4w4BFzB8mFks5WyLOhEjF BPPMqVDSj94N7ZpaIihbakR8k67nT6RJuEgVRVKG13gyUte9hiIZBwzKRunGHxJ2Gm IqMA3oqFJv2vx493XTurJHXaEvw4K03Wy5fYMhZE= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727892AbgGaU5M (ORCPT ); Fri, 31 Jul 2020 16:57:12 -0400 Received: from mail.kernel.org ([198.145.29.99]:43328 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726884AbgGaU5M (ORCPT ); Fri, 31 Jul 2020 16:57:12 -0400 Received: from localhost.localdomain (c-73-231-172-41.hsd1.ca.comcast.net [73.231.172.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id EC9A1208E4; Fri, 31 Jul 2020 20:57:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1596229031; bh=vdXEGu/7qMDVaKN9D44BCySt6O+PHbNNjTVbqhCGH4c=; h=Date:From:To:Subject:In-Reply-To:From; b=xtm1XKF9cdjegSad07S+5xZLBKEiT/NU8aKvxKguh6Ip7ZZLFcErz/JiV/jQadhuV gmmjFvDIyB1DLOcM4dOOcOFI+Ta+XLbL2hVYR0WpTj0Q0/nHibo05eHXf9y1Gb/ls/ c1E1BtJKab7R2tkbP2IbJmcNpCDjPqFkRDWWJweM= Date: Fri, 31 Jul 2020 13:57:10 -0700 From: Andrew Morton To: aarcange@redhat.com, mike.kravetz@oracle.com, mm-commits@vger.kernel.org, peterx@redhat.com, stable@vger.kernel.org, willy@infradead.org Subject: + mm-hugetlb-fix-calculation-of-adjust_range_if_pmd_sharing_possible.patch added to -mm tree Message-ID: <20200731205710.iB3KouoTG%akpm@linux-foundation.org> In-Reply-To: <20200723211432.b31831a0df3bc2cbdae31b40@linux-foundation.org> User-Agent: s-nail v14.8.16 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org The patch titled Subject: mm/hugetlb: fix calculation of adjust_range_if_pmd_sharing_possible has been added to the -mm tree. Its filename is mm-hugetlb-fix-calculation-of-adjust_range_if_pmd_sharing_possible.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/mm-hugetlb-fix-calculation-of-adjust_range_if_pmd_sharing_possible.patch and later at http://ozlabs.org/~akpm/mmotm/broken-out/mm-hugetlb-fix-calculation-of-adjust_range_if_pmd_sharing_possible.patch Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Peter Xu Subject: mm/hugetlb: fix calculation of adjust_range_if_pmd_sharing_possible This is found by code observation only. Firstly, the worst case scenario should assume the whole range was covered by pmd sharing. The old algorithm might not work as expected for ranges like (1g-2m, 1g+2m), where the adjusted range should be (0, 1g+2m) but the expected range should be (0, 2g). Since at it, remove the loop since it should not be required. With that, the new code should be faster too when the invalidating range is huge. Mike said: : With range (1g-2m, 1g+2m) within a vma (0, 2g) the existing code will only : adjust to (0, 1g+2m) which is incorrect. : : We should cc stable. The original reason for adjusting the range was to : prevent data corruption (getting wrong page). Since the range is not : always adjusted correctly, the potential for corruption still exists. : : However, I am fairly confident that adjust_range_if_pmd_sharing_possible : is only gong to be called in two cases: : : 1) for a single page : 2) for range == entire vma : : In those cases, the current code should produce the correct results. : : To be safe, let's just cc stable. Link: http://lkml.kernel.org/r/20200730201636.74778-1-peterx@redhat.com Fixes: 017b1660df89 ("mm: migration: fix migration of huge PMD shared pages") Signed-off-by: Peter Xu Reviewed-by: Mike Kravetz Cc: Andrea Arcangeli Cc: Matthew Wilcox Cc: Signed-off-by: Andrew Morton --- mm/hugetlb.c | 24 ++++++++++-------------- 1 file changed, 10 insertions(+), 14 deletions(-) --- a/mm/hugetlb.c~mm-hugetlb-fix-calculation-of-adjust_range_if_pmd_sharing_possible +++ a/mm/hugetlb.c @@ -5314,25 +5314,21 @@ static bool vma_shareable(struct vm_area void adjust_range_if_pmd_sharing_possible(struct vm_area_struct *vma, unsigned long *start, unsigned long *end) { - unsigned long check_addr; + unsigned long a_start, a_end; if (!(vma->vm_flags & VM_MAYSHARE)) return; - for (check_addr = *start; check_addr < *end; check_addr += PUD_SIZE) { - unsigned long a_start = check_addr & PUD_MASK; - unsigned long a_end = a_start + PUD_SIZE; + /* Extend the range to be PUD aligned for a worst case scenario */ + a_start = ALIGN_DOWN(*start, PUD_SIZE); + a_end = ALIGN(*end, PUD_SIZE); - /* - * If sharing is possible, adjust start/end if necessary. - */ - if (range_in_vma(vma, a_start, a_end)) { - if (a_start < *start) - *start = a_start; - if (a_end > *end) - *end = a_end; - } - } + /* + * Intersect the range with the vma range, since pmd sharing won't be + * across vma after all + */ + *start = max(vma->vm_start, a_start); + *end = min(vma->vm_end, a_end); } /* _ Patches currently in -mm which might be from peterx@redhat.com are mm-hugetlb-fix-calculation-of-adjust_range_if_pmd_sharing_possible.patch mm-do-page-fault-accounting-in-handle_mm_fault.patch mm-alpha-use-general-page-fault-accounting.patch mm-arc-use-general-page-fault-accounting.patch mm-arm-use-general-page-fault-accounting.patch mm-arm64-use-general-page-fault-accounting.patch mm-csky-use-general-page-fault-accounting.patch mm-hexagon-use-general-page-fault-accounting.patch mm-ia64-use-general-page-fault-accounting.patch mm-m68k-use-general-page-fault-accounting.patch mm-microblaze-use-general-page-fault-accounting.patch mm-mips-use-general-page-fault-accounting.patch mm-nds32-use-general-page-fault-accounting.patch mm-nios2-use-general-page-fault-accounting.patch mm-openrisc-use-general-page-fault-accounting.patch mm-parisc-use-general-page-fault-accounting.patch mm-powerpc-use-general-page-fault-accounting.patch mm-riscv-use-general-page-fault-accounting.patch mm-s390-use-general-page-fault-accounting.patch mm-sh-use-general-page-fault-accounting.patch mm-sparc32-use-general-page-fault-accounting.patch mm-sparc64-use-general-page-fault-accounting.patch mm-x86-use-general-page-fault-accounting.patch mm-xtensa-use-general-page-fault-accounting.patch mm-clean-up-the-last-pieces-of-page-fault-accountings.patch mm-gup-remove-task_struct-pointer-for-all-gup-code.patch