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=-2.5 required=3.0 tests=MAILING_LIST_MULTI, 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 F095BC33CB1 for ; Thu, 16 Jan 2020 10:29:48 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id BA8D5207FF for ; Thu, 16 Jan 2020 10:29:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BA8D5207FF Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 590588E0063; Thu, 16 Jan 2020 05:29:48 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 519208E003F; Thu, 16 Jan 2020 05:29:48 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3E1798E0063; Thu, 16 Jan 2020 05:29:48 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0166.hostedemail.com [216.40.44.166]) by kanga.kvack.org (Postfix) with ESMTP id 2538F8E003F for ; Thu, 16 Jan 2020 05:29:48 -0500 (EST) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with SMTP id B9C0D180AD80F for ; Thu, 16 Jan 2020 10:29:47 +0000 (UTC) X-FDA: 76383126414.15.run92_557a95081f44a X-HE-Tag: run92_557a95081f44a X-Filterd-Recvd-Size: 5205 Received: from mail-wm1-f66.google.com (mail-wm1-f66.google.com [209.85.128.66]) by imf28.hostedemail.com (Postfix) with ESMTP for ; Thu, 16 Jan 2020 10:29:47 +0000 (UTC) Received: by mail-wm1-f66.google.com with SMTP id d139so6839325wmd.0 for ; Thu, 16 Jan 2020 02:29:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=dK/RFcCfrUs/YVCn6Rd/tNrRB7a7o6cvY1DVsir0dU0=; b=g1mHzlqGwTS+YaQ5BYf1MBJ9hVsfOZflMhWw1S1BQGwbm0PcS/prkfZgiowwQWakv5 z/rb1mksgiUSeE6/DCe6H8uhtIn5Tw6hupEfNKLOnjx8xXP4wo7V3HghP/K/IKM/SUTH jVll4VRXZEm8hL3dmmP4zD1UGhFg5hPiOtfmT+5RnRSGZO38+l7yQkaekesTiTNE2HGu xjYxfhBlvRtqP0Q1nosb8LtT63+f+qntLT1vaabPuzqQmSK7yAcKv0xDx2s1Hen4I37n aio0fbsZKq30U7h9w6wHante5gVj0T6tDIv8KCmK50uKU0hqWVvqI1DQLkU0pR67s3N6 8i6g== X-Gm-Message-State: APjAAAUc0Zczme9zSWMBq8vNiDRd9UbnQc+bcqyVvQ9sNIn6q8AFmV1+ Rg6d5KWm2V3CySoW7Sksy5M= X-Google-Smtp-Source: APXvYqzm1aW7pSp0yIJwJQ4Ot4UC9hfl7Rs4UbYhpo96+/NfPYxvFBSp6+4CWTbkPManfCqqIwTwIw== X-Received: by 2002:a05:600c:214f:: with SMTP id v15mr5425832wml.110.1579170586178; Thu, 16 Jan 2020 02:29:46 -0800 (PST) Received: from localhost (prg-ext-pat.suse.com. [213.151.95.130]) by smtp.gmail.com with ESMTPSA id x6sm3890229wmi.44.2020.01.16.02.29.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Jan 2020 02:29:45 -0800 (PST) Date: Thu, 16 Jan 2020 11:29:44 +0100 From: Michal Hocko To: Mike Kravetz Cc: Li Xinhai , "linux-mm@kvack.org" , akpm , "kirill.shutemov" Subject: Re: [PATCH v4] mm/page_vma_mapped.c: Explicitly compare pfn for normal, hugetlbfs and THP page Message-ID: <20200116102944.GQ19428@dhcp22.suse.cz> References: <1578737885-8890-1-git-send-email-lixinhai.lxh@gmail.com> <20200114092545.GF19428@dhcp22.suse.cz> <202001142147485028116@gmail.com> <20200115093148.GZ19428@dhcp22.suse.cz> <986d0f55-ae54-f3af-0d50-3e3b6621a863@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <986d0f55-ae54-f3af-0d50-3e3b6621a863@oracle.com> User-Agent: Mutt/1.12.2 (2019-09-21) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000002, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed 15-01-20 16:40:26, Mike Kravetz wrote: > On 1/15/20 1:31 AM, Michal Hocko wrote: > > On Tue 14-01-20 21:47:51, Li Xinhai wrote: > >> On 2020-01-14 at 17:25 Michal Hocko wrote: > >>> On Sat 11-01-20 10:18:05, Li Xinhai wrote: > >>>> When check_pte, pfn of normal, hugetlbfs and THP page need be compared. > >>>> The current implementation apply comparison as > >>>> - normal 4K page: page_pfn <= pfn < page_pfn + 1 > >>>> - hugetlbfs page: page_pfn <= pfn < page_pfn + HPAGE_PMD_NR > >>>> - THP page: page_pfn <= pfn < page_pfn + HPAGE_PMD_NR > >>>> in pfn_in_hpage. For hugetlbfs page, it should be > >>>> page_pfn == pfn > >>>> > >>>> Now, change pfn_in_hpage to pfn_is_match to highlight that comparison > >>>> is not only for THP and explicitly compare for these cases. > >>> > >>> Why is this important to do. I have asked and Mike had the same feeling > >>> that the patch is missing any real justification. Why do we need this > >>> change? It is great that you have dropped VM_BUG_ON btw. > >>> > >> I think it is important to make the code clear, as said, comparing hugetlbfs page > >> in range page_pfn <= pfn < page_pfn + HPAGE_PMD_NR is confusion. > > > > I am sorry but I do not really see a big confusion here. It is probably > > a matter of taste. If others consider this an improvement then I will > > not stand in the way but I consider the justification insuficient for > > merging. > > Perhaps I am confused, but the patch does update the check done for > hugetlb pages. IIUC, previously there was no distinction between THP > pages and hugetlb pages in the check. It is valid to pass in a sub- > page of a THP page, but not that of a hugetlb page. > > I do not believe it is possible for existing code to pass in a sub-page > of a hugetlb page. And, no one has ever seen this as an issue. This > is why I was questioning the need for the patch. Exactly and that is the reason I fail the see a point. > With all that said, the new code/check is better (more complete) than > the original. It may not do anything for the current code base, but > it 'could' catch potential errors in future code. Because of this, I > do consider the code an improvement. It adds a branch for something that doesn't happen and also to a code path which is quite internal to the MM AFAICS. That being said, if you believe this is an improvement then I will not stand in the way. But there are so many other places which could add checks that are not exercised... > Acked-by: Mike Kravetz -- Michal Hocko SUSE Labs