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=-6.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 858F0C433E0 for ; Fri, 31 Jul 2020 00:30:30 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 251A320829 for ; Fri, 31 Jul 2020 00:30:30 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b="VzNCGN/N" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 251A320829 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=oracle.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 75A3A6B0029; Thu, 30 Jul 2020 20:30:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 70D628D0005; Thu, 30 Jul 2020 20:30:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5D2C56B002C; Thu, 30 Jul 2020 20:30:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 447126B0029 for ; Thu, 30 Jul 2020 20:30:29 -0400 (EDT) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id D8B0E3626 for ; Fri, 31 Jul 2020 00:30:28 +0000 (UTC) X-FDA: 77096489736.23.chess78_0c1429926f7f Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin23.hostedemail.com (Postfix) with ESMTP id A822437604 for ; Fri, 31 Jul 2020 00:30:28 +0000 (UTC) X-HE-Tag: chess78_0c1429926f7f X-Filterd-Recvd-Size: 6209 Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) by imf06.hostedemail.com (Postfix) with ESMTP for ; Fri, 31 Jul 2020 00:30:27 +0000 (UTC) Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 06V0N6R2097227; Fri, 31 Jul 2020 00:30:22 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=e8NbgnfIfawl+5h9493v+Q+IJVod5c4QJ1ApMKOFxag=; b=VzNCGN/NNvaAM3aLs1F98yMpWokGwXo5GV/JemHOx/8RMlQFStmsv//PTXlFdEWZKSpf 6RUQxRqqtsj2rl5WYgbR3pQl9rlNCoGDybgyz3sPvSbhezFfsXyDuh1qxGKGOPsz0ldI qQhj5rEpVsYsNpvjuB8Px3NSTo/5U+qoSZszTo5IienuH9A95kywSaUfapvseSQjvJtl MvkZSQztf0MzUlK77Chnd0jSU/68gZ1jJaU5oll2+cdtID0TvGUvEVhYQ5FF6BC/jMw8 8oYi49O0M4tFuZWU5DHoaexmoUN8/stgDdKi29LNP9X1vH1/VvCOSoq3YGL/UGdXlCJD Zg== Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by userp2130.oracle.com with ESMTP id 32hu1jpkre-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 31 Jul 2020 00:30:22 +0000 Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 06V0IqPh079582; Fri, 31 Jul 2020 00:28:21 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserp3030.oracle.com with ESMTP id 32hu5y4qtw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 31 Jul 2020 00:28:21 +0000 Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 06V0SF79008146; Fri, 31 Jul 2020 00:28:15 GMT Received: from [192.168.2.112] (/50.38.35.18) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 30 Jul 2020 17:28:15 -0700 Subject: Re: [PATCH v2] mm/hugetlb: Fix calculation of adjust_range_if_pmd_sharing_possible To: Peter Xu Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , Andrea Arcangeli , Matthew Wilcox References: <20200730201636.74778-1-peterx@redhat.com> <4680014a-a328-b0c2-dc86-8c1eb4556f69@oracle.com> <20200730232656.GE3649@xz-x1.hitronhub.home> From: Mike Kravetz Message-ID: <5ce544da-4c94-cd42-2ab4-d4d76f3c139d@oracle.com> Date: Thu, 30 Jul 2020 17:28:13 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20200730232656.GE3649@xz-x1.hitronhub.home> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9698 signatures=668679 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 mlxscore=0 adultscore=0 spamscore=0 phishscore=0 mlxlogscore=999 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007310000 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9698 signatures=668679 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 clxscore=1011 malwarescore=0 spamscore=0 suspectscore=0 bulkscore=0 priorityscore=1501 phishscore=0 mlxlogscore=999 lowpriorityscore=0 impostorscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007310000 X-Rspamd-Queue-Id: A822437604 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam01 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 7/30/20 4:26 PM, Peter Xu wrote: > Hi, Mike, > > On Thu, Jul 30, 2020 at 02:49:18PM -0700, Mike Kravetz wrote: >> On 7/30/20 1:16 PM, Peter Xu wrote: >>> 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. >> >> Thanks Peter! >> >> That is certainly much simpler than the loop in current code. You say there >> are instances where old code 'might not work' for ranges like (1g-2m, 1g+2m). >> Not sure I understand what you mean by adjusted and expected ranges in the >> message. Both are possible 'adjusted' ranges depending on vma size. >> >> Just trying to figure out if there is an actual problem in the existing code >> that needs to be fixed in stable. I think the existing code is correct, just >> inefficient. > > Thanks for the quick review! > > I'm not sure whether that will cause a real problem, but iiuc in my previous > example of (1g-2m, 1g+2m) in the commit message, the old code will extend the > range to (0, 1g+2m). In this case, if unluckily the (1g, 2g) range is a pud > with shared pmd, then imho we face the risk of partial tlb flushing with the > old code, because it will only flush tlb for range (0, 1g+2m) but not (0, 2g). > If that's the case, maybe it worths cc stable. > > Anyway, I'd like to double confirm with you in case I missed something. You are correct. 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. Also, Fixes: 017b1660df89 ("mm: migration: fix migration of huge PMD shared pages") Reviewed-by: Mike Kravetz -- Mike Kravetz