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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6EC56C433EF for ; Mon, 24 Jan 2022 06:52:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E28FE6B0081; Mon, 24 Jan 2022 01:52:01 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DD75A6B0083; Mon, 24 Jan 2022 01:52:01 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C9F346B0085; Mon, 24 Jan 2022 01:52:01 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0035.hostedemail.com [216.40.44.35]) by kanga.kvack.org (Postfix) with ESMTP id B65B46B0081 for ; Mon, 24 Jan 2022 01:52:01 -0500 (EST) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 5D002181A346D for ; Mon, 24 Jan 2022 06:52:01 +0000 (UTC) X-FDA: 79064260842.24.626102A Received: from mail-qt1-f179.google.com (mail-qt1-f179.google.com [209.85.160.179]) by imf22.hostedemail.com (Postfix) with ESMTP id E1A91C003B for ; Mon, 24 Jan 2022 06:52:00 +0000 (UTC) Received: by mail-qt1-f179.google.com with SMTP id w6so18548215qtk.4 for ; Sun, 23 Jan 2022 22:52:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version; bh=GlZoPqVPMm8RdzMvl6/ibZbcFUKUURz2grmYcIEKsF4=; b=ZnJmo/tGKN055rn72N6Zih24GuRsdF9ySmWk98JFId85TRPI5Bo9Srp8Qxam3fQDJ6 YiXimDvmxFLI1p++IhektBbDyPa2EWiUfXtpmMofib54Sydmebg3t4cC0F/5BW+QJ0Oc tV/9k73B48lKBzA8SQgkdLXkTb996NKgNDB/8FZtZjyXDFrWBpx4huqJZEZJqAWTMl6P nlrie6WPWp18Xh/L6vXTe0v4PD8PLltO6P02OvmujPoGWFHMbaD2LOXBd6MN11/HrVJe 93qlce16WxMHl9IPGvqYYia9EbJbOaj9Duq96QoWdHpu8cCH9XqGNow2mOquYLhD4L50 +7Vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:mime-version; bh=GlZoPqVPMm8RdzMvl6/ibZbcFUKUURz2grmYcIEKsF4=; b=2yNAf7a9v8apAfjecNL1w3OSbPxMecnW8Lb/iAF6oVi0PE4H8ASFLmmbb47OIBXsr1 zrvNktgtZ3ddJ2u9jIIxy2peIKjhxxBzB9/K9MabUNGKR7OktFp6xML2A9hMIuJIb5oU kE8Rnalf8nkY6PZuyEnz7Dy7lz/rGuHUM9ktCzm5ydAMLmITh/NkLzLPPQgjwvS1mqrx Pdyde2dmZ+uJM2xeQF8LuZmNFDosTfjYKsrQjg885gogtdzJtk8tJwT+W7pok3wmjGzw C1nHfbF3LgxEH0LHIO0a42pvC6zOCAUrE4kk1ikcVN1fWcdbMYuAivT/iXXhDERJ3Gx/ 008w== X-Gm-Message-State: AOAM533xMRdgCDpuzOZa8yxAbXn8u1R9VunEizrxvYc18TEsKi4BV9EG MD5Y/17x4xPecbKBXnaHQl4sYA== X-Google-Smtp-Source: ABdhPJyvKmnM6+ruVpjumUaaLZD1vF5Eeom7w0xuDWFc3jn9+iR8DqsytCpYes98PVSOcgbIsPFcAA== X-Received: by 2002:a05:622a:3ca:: with SMTP id k10mr5412768qtx.506.1643007120064; Sun, 23 Jan 2022 22:52:00 -0800 (PST) Received: from ripple.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id f5sm4241152qkp.40.2022.01.23.22.51.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 23 Jan 2022 22:51:59 -0800 (PST) Date: Sun, 23 Jan 2022 22:51:57 -0800 (PST) From: Hugh Dickins X-X-Sender: hugh@ripple.anvils To: Peter Xu cc: Hugh Dickins , linux-kernel@vger.kernel.org, linux-mm@kvack.org, David Hildenbrand , Andrea Arcangeli , Yang Shi , Vlastimil Babka , Andrew Morton , Alistair Popple , "Kirill A . Shutemov" , Matthew Wilcox Subject: Re: [PATCH RFC v2 1/2] mm: Don't skip swap entry even if zap_details specified In-Reply-To: Message-ID: <56e33192-965d-691a-afc-f77f5856afd@google.com> References: <20211115134951.85286-1-peterx@redhat.com> <20211115134951.85286-2-peterx@redhat.com> <9937aaa-d9ab-2839-b0b7-691d85c9141@google.com> <391aa58d-ce84-9d4-d68d-d98a9c533255@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Stat-Signature: ynaiybue77z8nsam87aogcrdfrzbd1uj Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="ZnJmo/tG"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf22.hostedemail.com: domain of hughd@google.com designates 209.85.160.179 as permitted sender) smtp.mailfrom=hughd@google.com X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: E1A91C003B X-HE-Tag: 1643007120-475328 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 Fri, 21 Jan 2022, Peter Xu wrote: > > Oh, one more thing.. > > When reading the history and also your explanations above, I figured one thing > that may not be right for a long time, on zero page handling of zapping. > > If to quote your comment above, we should keep the zero page entries too if > zap_details.zap_mapping is specified. However it's not true for a long time, I > guess starting from when vm_normal_page() returns NULL for zero pfns. I also > have a very strong feeling that in the old world the "page*" is non-NULL for > zero pages here. > > So... I'm boldly thinking whether we should also need another fix upon the zero > page handling here too, probably before this whole patchset (so it'll be the > 1st patch, it should directly apply to master) because if I'm right on above it > can be seen as another separate bug fix: > > ---8<--- > diff --git a/mm/memory.c b/mm/memory.c > index f306e698a1e3..9b8348746e0b 100644 > --- a/mm/memory.c > +++ b/mm/memory.c > @@ -1320,11 +1320,18 @@ struct zap_details { > static inline bool > zap_skip_check_mapping(struct zap_details *details, struct page *page) > { > - if (!details || !page) > + /* No detail pointer or no zap_mapping pointer, zap all */ > + if (!details || !details->zap_mapping) > return false; > > - return details->zap_mapping && > - (details->zap_mapping != page_rmapping(page)); > + /* > + * For example, the zero page. If the user wants to keep the private > + * pages, zero page should also be in count. > + */ > + if (!page) > + return true; > + > + return details->zap_mapping != page_rmapping(page); > } > > static unsigned long zap_pte_range(struct mmu_gather *tlb, > ---8<--- > > page can be NULL for e.g. PFNMAP and when error occured too above. I assume we > don't need to bother with them (e.g., I don't think PFNMAP or MIXED should > specify even_cows=false at all, because there's no page cache layer), though. > Mostly it's about how we should handle zero page right. I have not understood the above. I don't know of any problem that needs fixing with the zero page: how do you suppose the zero page gets into a truncatable or hole-punchable mapping? We use it for read faults in anonymous mappings. And I told the story of how once-upon-a-time it could get inserted into any mapping by reading from /dev/zero, but that odd case was dropped years ago. And I am open to (even encouraging) a change to make use of zero page for read faults of holes in shmem: but that's potential future work, which would require some changes elsewhere (though perhaps none here: the zero page could never be used for the result of a COW). Please explain the zero page problem you hope to fix here. Hugh