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.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 A9F35C4743C for ; Fri, 4 Jun 2021 18:05:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 87E5861406 for ; Fri, 4 Jun 2021 18:05:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229962AbhFDSG5 (ORCPT ); Fri, 4 Jun 2021 14:06:57 -0400 Received: from mail-ed1-f41.google.com ([209.85.208.41]:46635 "EHLO mail-ed1-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229778AbhFDSG5 (ORCPT ); Fri, 4 Jun 2021 14:06:57 -0400 Received: by mail-ed1-f41.google.com with SMTP id r11so12096491edt.13 for ; Fri, 04 Jun 2021 11:05:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6u9C0rQYVqsqXWtKWXaZKVuAhwcfVIDbCc3WqpmlEfI=; b=bh+P6SnyBZhy0DEY5x4DSE64ESRBzAhai4VcVhkTO6HeqqvIGGJYdqQ+fvs0wH7oHw mEbNEWYmaXRaho8uWkVTlTTUGPDgjRKgxDqMXO80dSFa1i/aaMKXHWiq6JV6ilPFNIyt 3mGpEgzuehIcqqJ8cE3kVbPnoNRSt6fh2QUEMYcGI1amHyTu3eEnyYcEwEUubEntPx7I lrb+Itjkm8OkqZuEZTBqkLnqqEhXtMEh56rJWFHcgzBKn0GKkFCjv8uyZBZuEHdx1fZS Xv5kmFpaYLig1h+PqYwH8mXlcZMoRmfnqFbOdBvooV/QZpKAcoQF5dd8WuirlRAnbynf Zzqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6u9C0rQYVqsqXWtKWXaZKVuAhwcfVIDbCc3WqpmlEfI=; b=Yby8z0ggoWJ6n4Wb7Dmbcvt30b37McTOV3+r6GdYzeoAm6qjjTxhztES+lRm/+6T36 CLVug4QswKnYuZEmEcA2h9rsObbmHK2W0Ie/Y/9/Ql6rwadZQSiptWuF5MVodCflYvCn UiPcADMtUtGIU5AoqP4mKvf6I7GzQx6ADDnGtGrjW041Kb9Mwn0fdtzM7qcr76VP/M7e JhypDdUgRvHQnAdAwjtMCtfyQ3ovUBbEMBF1zoG6lZhZ0Nb0QIzc4jigtfbuqA3R7XUY O14l1dhBE563pLLOzoh3FbFPPtffzoOX/SXkP1stPGoVGukTrFJODTLyE6gl4S4z2HLt 5C7w== X-Gm-Message-State: AOAM531kBGLBhISL6k6J2t/cFcaGoPbxx4z8lPnzMt1je8pnHLSmigCc 9Y/SuGK60KU88i6NgDnXctMlRJOC99nneE5N0t8= X-Google-Smtp-Source: ABdhPJzd2i7kOilHUilrYn48mb+/d5wsI1lPzkORiARU4thKOVGUUOGv9XEKCnHISX/VNj4NIvYizYKQu8FTbG2FX5Q= X-Received: by 2002:a05:6402:1d0f:: with SMTP id dg15mr3375544edb.137.1622829849830; Fri, 04 Jun 2021 11:04:09 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yang Shi Date: Fri, 4 Jun 2021 11:03:57 -0700 Message-ID: Subject: Re: [PATCH 1/7] mm/thp: fix __split_huge_pmd_locked() on shmem migration entry To: Hugh Dickins Cc: Andrew Morton , "Kirill A. Shutemov" , Wang Yugui , Matthew Wilcox , Naoya Horiguchi , Alistair Popple , Ralph Campbell , Zi Yan , Miaohe Lin , Minchan Kim , Jue Wang , Peter Xu , Jan Kara , Linux MM , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 3, 2021 at 7:23 PM Hugh Dickins wrote: > > On Thu, 3 Jun 2021, Yang Shi wrote: > > On Tue, Jun 1, 2021 at 2:05 PM Hugh Dickins wrote: > > > > > > Are there more places that need to be careful about pmd migration entries? > > > None hit in practice, but several of those is_huge_zero_pmd() tests were > > > done without checking pmd_present() first: I believe a pmd migration entry > > > could end up satisfying that test. Ah, the inversion of swap offset, to > > > protect against L1TF, makes that impossible on x86; but other arches need > > > the pmd_present() check, and even x86 ought not to apply pmd_page() to a > > > swap-like pmd. Fix those instances; __split_huge_pmd_locked() was not > > > wrong to be checking with pmd_trans_huge() instead, but I think it's > > > clearer to use pmd_present() in each instance. > ... > > > diff --git a/mm/huge_memory.c b/mm/huge_memory.c > > > index 63ed6b25deaa..9fb7b47da87e 100644 > > > --- a/mm/huge_memory.c > > > +++ b/mm/huge_memory.c > > > @@ -1676,7 +1676,7 @@ int zap_huge_pmd(struct mmu_gather *tlb, struct vm_area_struct *vma, > > > spin_unlock(ptl); > > > if (is_huge_zero_pmd(orig_pmd)) > > > tlb_remove_page_size(tlb, pmd_page(orig_pmd), HPAGE_PMD_SIZE); > > > - } else if (is_huge_zero_pmd(orig_pmd)) { > > > + } else if (pmd_present(orig_pmd) && is_huge_zero_pmd(orig_pmd)) { > > > > If it is a huge zero migration entry, the code would fallback to the > > "else". But IIUC the "else" case doesn't handle the huge zero page > > correctly. It may mess up the rss counter. > > A huge zero migration entry? I hope that's not something special > that I've missed. > > Do we ever migrate a huge zero page - and how do we find where it's > mapped, to insert the migration entries? But if we do, I thought it > would use the usual kind of pmd migration entry; and the first check > in is_pmd_migration_entry() is !pmd_present(pmd). I overlooked if the huge zero page is migratable or not when I was writing the comment, just focused on the if/else if/else conditions. I don't think huge zero page is migratable by a quick look since: * mempolicy and numa hinting skip huge zero pmd * other migration callsites just try to migrate LRU pages > > (I have to be rather careful to check such details, after getting > burnt once by pmd_present(): which includes the "huge" bit even when > not otherwise present, to permit races with pmdp_invalidate(). > I mentioned in private mail that I'd dropped one of my "fixes" because > it was harmless but mistaken: I had misunderstood pmd_present().) > > The point here (see commit message above) is that some unrelated pmd > migration entry could pass the is_huge_zero_pmd() test, which rushes > off to use pmd_page() without even checking pmd_present() first. And > most of its users have, one way or another, checked pmd_present() first; > but this place and a couple of others had not. Thanks for the elaboration. Wondering whether we'd better add some comments in the code? Someone may submit a fix patch by visual inspection in the future due to missing these points. > > I'm just verifying that it's really a a huge zero pmd before handling > its case; the "else" still does not need to handle the huge zero page. > > Hugh 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.7 required=3.0 tests=BAYES_00,DATE_IN_PAST_12_24, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 9F57FC47082 for ; Sat, 5 Jun 2021 07:03:06 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2EA04611C2 for ; Sat, 5 Jun 2021 07:03:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2EA04611C2 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id AA3936B0036; Sat, 5 Jun 2021 03:03:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A7A686B006C; Sat, 5 Jun 2021 03:03:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 941CA6B006E; Sat, 5 Jun 2021 03:03:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0209.hostedemail.com [216.40.44.209]) by kanga.kvack.org (Postfix) with ESMTP id 641BE6B0036 for ; Sat, 5 Jun 2021 03:03:05 -0400 (EDT) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 085F9180AD801 for ; Sat, 5 Jun 2021 07:03:05 +0000 (UTC) X-FDA: 78218778330.28.0205AE6 Received: from mail-ed1-f43.google.com (mail-ed1-f43.google.com [209.85.208.43]) by imf16.hostedemail.com (Postfix) with ESMTP id 0F5AE801917B for ; Sat, 5 Jun 2021 07:02:51 +0000 (UTC) Received: by mail-ed1-f43.google.com with SMTP id u24so13651685edy.11 for ; Sat, 05 Jun 2021 00:02:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6u9C0rQYVqsqXWtKWXaZKVuAhwcfVIDbCc3WqpmlEfI=; b=bh+P6SnyBZhy0DEY5x4DSE64ESRBzAhai4VcVhkTO6HeqqvIGGJYdqQ+fvs0wH7oHw mEbNEWYmaXRaho8uWkVTlTTUGPDgjRKgxDqMXO80dSFa1i/aaMKXHWiq6JV6ilPFNIyt 3mGpEgzuehIcqqJ8cE3kVbPnoNRSt6fh2QUEMYcGI1amHyTu3eEnyYcEwEUubEntPx7I lrb+Itjkm8OkqZuEZTBqkLnqqEhXtMEh56rJWFHcgzBKn0GKkFCjv8uyZBZuEHdx1fZS Xv5kmFpaYLig1h+PqYwH8mXlcZMoRmfnqFbOdBvooV/QZpKAcoQF5dd8WuirlRAnbynf Zzqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6u9C0rQYVqsqXWtKWXaZKVuAhwcfVIDbCc3WqpmlEfI=; b=ijcgJDl/qAUuXmKAb1BapnF9cQuC+XaRbOQa81DZqxac6ipASfOdgAttOrZa/FtoKu TSR2eiT+d49xjWLimcZvE9yEtmClBSQOygmLucxcIL2mbV4DQr5AMKw7pzHyDJIbFNu5 J7X3Zzp6QcK0YAZBK2iRuIunr1L6bnb4SzbwsHVUvlpQ5s2kksdQxGF1OWBUU37obT8X XkblU6fVWgxJQpIqWx7JG8zrhon7r5sf9KLkg+OmXDiw6Kk2rf+DqLu1BgfJ8yiLTb2b vdC7wWXlsQkjRX3WK4Dn8JC1jFRpEBDT5Z4J9hnVePSvQvz6Zi4qElsn1Mc2nQzHYAjj Htew== X-Gm-Message-State: AOAM533QyydUNz6Wgv7GOiXVtO51FTbGS92mCmk6EeXzf4h0eklpEEFk /Cha2CCPqQisMajg+EIEKN1ZoFkHWlC7CgHnROoaeOVpdcEeHg== X-Google-Smtp-Source: ABdhPJzd2i7kOilHUilrYn48mb+/d5wsI1lPzkORiARU4thKOVGUUOGv9XEKCnHISX/VNj4NIvYizYKQu8FTbG2FX5Q= X-Received: by 2002:a05:6402:1d0f:: with SMTP id dg15mr3375544edb.137.1622829849830; Fri, 04 Jun 2021 11:04:09 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yang Shi Date: Fri, 4 Jun 2021 11:03:57 -0700 Message-ID: Subject: Re: [PATCH 1/7] mm/thp: fix __split_huge_pmd_locked() on shmem migration entry To: Hugh Dickins Cc: Andrew Morton , "Kirill A. Shutemov" , Wang Yugui , Matthew Wilcox , Naoya Horiguchi , Alistair Popple , Ralph Campbell , Zi Yan , Miaohe Lin , Minchan Kim , Jue Wang , Peter Xu , Jan Kara , Linux MM , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=bh+P6Sny; spf=pass (imf16.hostedemail.com: domain of shy828301@gmail.com designates 209.85.208.43 as permitted sender) smtp.mailfrom=shy828301@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 0F5AE801917B X-Stat-Signature: 3ee1yjnxh8byu1imndhkayo4b4fskagh X-HE-Tag: 1622876571-773227 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 Thu, Jun 3, 2021 at 7:23 PM Hugh Dickins wrote: > > On Thu, 3 Jun 2021, Yang Shi wrote: > > On Tue, Jun 1, 2021 at 2:05 PM Hugh Dickins wrote: > > > > > > Are there more places that need to be careful about pmd migration entries? > > > None hit in practice, but several of those is_huge_zero_pmd() tests were > > > done without checking pmd_present() first: I believe a pmd migration entry > > > could end up satisfying that test. Ah, the inversion of swap offset, to > > > protect against L1TF, makes that impossible on x86; but other arches need > > > the pmd_present() check, and even x86 ought not to apply pmd_page() to a > > > swap-like pmd. Fix those instances; __split_huge_pmd_locked() was not > > > wrong to be checking with pmd_trans_huge() instead, but I think it's > > > clearer to use pmd_present() in each instance. > ... > > > diff --git a/mm/huge_memory.c b/mm/huge_memory.c > > > index 63ed6b25deaa..9fb7b47da87e 100644 > > > --- a/mm/huge_memory.c > > > +++ b/mm/huge_memory.c > > > @@ -1676,7 +1676,7 @@ int zap_huge_pmd(struct mmu_gather *tlb, struct vm_area_struct *vma, > > > spin_unlock(ptl); > > > if (is_huge_zero_pmd(orig_pmd)) > > > tlb_remove_page_size(tlb, pmd_page(orig_pmd), HPAGE_PMD_SIZE); > > > - } else if (is_huge_zero_pmd(orig_pmd)) { > > > + } else if (pmd_present(orig_pmd) && is_huge_zero_pmd(orig_pmd)) { > > > > If it is a huge zero migration entry, the code would fallback to the > > "else". But IIUC the "else" case doesn't handle the huge zero page > > correctly. It may mess up the rss counter. > > A huge zero migration entry? I hope that's not something special > that I've missed. > > Do we ever migrate a huge zero page - and how do we find where it's > mapped, to insert the migration entries? But if we do, I thought it > would use the usual kind of pmd migration entry; and the first check > in is_pmd_migration_entry() is !pmd_present(pmd). I overlooked if the huge zero page is migratable or not when I was writing the comment, just focused on the if/else if/else conditions. I don't think huge zero page is migratable by a quick look since: * mempolicy and numa hinting skip huge zero pmd * other migration callsites just try to migrate LRU pages > > (I have to be rather careful to check such details, after getting > burnt once by pmd_present(): which includes the "huge" bit even when > not otherwise present, to permit races with pmdp_invalidate(). > I mentioned in private mail that I'd dropped one of my "fixes" because > it was harmless but mistaken: I had misunderstood pmd_present().) > > The point here (see commit message above) is that some unrelated pmd > migration entry could pass the is_huge_zero_pmd() test, which rushes > off to use pmd_page() without even checking pmd_present() first. And > most of its users have, one way or another, checked pmd_present() first; > but this place and a couple of others had not. Thanks for the elaboration. Wondering whether we'd better add some comments in the code? Someone may submit a fix patch by visual inspection in the future due to missing these points. > > I'm just verifying that it's really a a huge zero pmd before handling > its case; the "else" still does not need to handle the huge zero page. > > Hugh