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 D4CBFC433F5 for ; Mon, 10 Jan 2022 14:34:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 29B976B0073; Mon, 10 Jan 2022 09:34:29 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 24A956B0074; Mon, 10 Jan 2022 09:34:29 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0C4FD6B0075; Mon, 10 Jan 2022 09:34:29 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0073.hostedemail.com [216.40.44.73]) by kanga.kvack.org (Postfix) with ESMTP id F24226B0073 for ; Mon, 10 Jan 2022 09:34:28 -0500 (EST) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id AAC7E181C49B4 for ; Mon, 10 Jan 2022 14:34:28 +0000 (UTC) X-FDA: 79014623016.29.E247ECB Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf11.hostedemail.com (Postfix) with ESMTP id 89D254001F for ; Mon, 10 Jan 2022 14:34:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1641825265; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=0pdJvkaxaICLWqFTDyGX/FRGk93JW9C93pZSDi04sCM=; b=cHL6R8IppPCV1gelJOXYm/yQs1vAf0PbWA0Rbv/BkfdaajDpCi08vISYTvpCbVSGCwTiwJ yz8G2XW5RC6Y+IunVIp8oDqfze1YctuVXDuF5RHPArg8xu0L0TDjyus062khct7LF4oa4J PGTgWKAWy3xqv93WIxoyxDnHWLZrOMo= Received: from mail-ed1-f72.google.com (mail-ed1-f72.google.com [209.85.208.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-159-UbiT2RDQPa-vcRfeDz9fxA-1; Mon, 10 Jan 2022 09:34:24 -0500 X-MC-Unique: UbiT2RDQPa-vcRfeDz9fxA-1 Received: by mail-ed1-f72.google.com with SMTP id o20-20020a056402439400b003f83cf1e472so10293859edc.18 for ; Mon, 10 Jan 2022 06:34:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:cc:references:from:organization:subject :in-reply-to:content-transfer-encoding; bh=0pdJvkaxaICLWqFTDyGX/FRGk93JW9C93pZSDi04sCM=; b=dciLMN4da0IU3NeVr7i46D0cHmxJhYeKXKkwkmnzuR4cM+kHaEkEXCZAc7uevypFEq ByUZGtj0syvkL9asQbza3oOFvPeAPE9ZB8R0HuBJQTGICH4y7oSI9UoS2TsfCanVOYy8 vbYaVbMRCwZK6yWkhKqGdnf0QICm2cFHbQS/XZDcvKAIBHeeDWZnUTU+tfTatW6utEVn 2t03wdGDGgQ0NNFvsKlIzE6viTnLD9/fI0f44Sbpz731Lk84Y71E8ghKh8rimjTpIIfc svE+ewDZJablrxIhG+nXQx7rKDsTKzICtg4y8keQYeQtF6E+akL/rA8axZ+pOC+RL+hu kWNg== X-Gm-Message-State: AOAM5314ASoZ25sJXHYUrPwyHn0BYynZ4ePgRZ7yHrg0smB0mejT3/QZ zO1gFnchKVY3NJcqbX/TFZ2E+ElTxS+2u8S49iwXF0XhrXUOxn6UaI0RdKByrMuHbkGadQ0j/r7 qzkZNfiZ/VMA= X-Received: by 2002:a17:907:3e1b:: with SMTP id hp27mr29499ejc.686.1641825262864; Mon, 10 Jan 2022 06:34:22 -0800 (PST) X-Google-Smtp-Source: ABdhPJzZ2+s8QwI/3ARaTXW/ZkaHnJbTUJ8rqKsbIr6UBeAbkwrR/OK7SfljCqSgZ1QwRnS97L2OLA== X-Received: by 2002:a17:907:3e1b:: with SMTP id hp27mr29483ejc.686.1641825262606; Mon, 10 Jan 2022 06:34:22 -0800 (PST) Received: from ?IPV6:2003:cb:c701:cf00:ac25:f2e3:db05:65c3? (p200300cbc701cf00ac25f2e3db0565c3.dip0.t-ipconnect.de. [2003:cb:c701:cf00:ac25:f2e3:db05:65c3]) by smtp.gmail.com with ESMTPSA id 2sm2496382ejt.224.2022.01.10.06.34.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 10 Jan 2022 06:34:22 -0800 (PST) Message-ID: Date: Mon, 10 Jan 2022 15:34:21 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 To: sxwjean@me.com, akpm@linux-foundation.org, mhocko@suse.com, dan.j.williams@intel.com, osalvador@suse.de, naoya.horiguchi@nec.com, thunder.leizhen@huawei.com Cc: linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Xiongwei Song References: <20220110141957.259022-1-sxwjean@me.com> <20220110141957.259022-3-sxwjean@me.com> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH v2 2/2] proc: Add getting pages info of ZONE_DEVICE support In-Reply-To: <20220110141957.259022-3-sxwjean@me.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 89D254001F X-Stat-Signature: yzg8yk8rfdhx9jpp6xtstcxscw5ya1to Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=cHL6R8Ip; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf11.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=david@redhat.com X-HE-Tag: 1641825266-613864 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 10.01.22 15:19, sxwjean@me.com wrote: > From: Xiongwei Song > > When requesting pages info by /proc/kpage*, the pages in ZONE_DEVICE were > missed. > The "missed" part makes it sound like this was done by accident. On the contrary, for now we decided to not expose these pages that way, for example, because determining if the memmap was already properly initialized isn't quite easy. > The pfn_to_devmap_page() function can help to get page that belongs to > ZONE_DEVICE. What's the main motivation for this? > > Signed-off-by: Xiongwei Song > --- > fs/proc/page.c | 35 ++++++++++++++++++++++------------- > 1 file changed, 22 insertions(+), 13 deletions(-) > > diff --git a/fs/proc/page.c b/fs/proc/page.c > index 9f1077d94cde..2cdc2b315ff8 100644 > --- a/fs/proc/page.c > +++ b/fs/proc/page.c > @@ -15,6 +15,7 @@ > #include > #include > #include > +#include > #include "internal.h" > > #define KPMSIZE sizeof(u64) > @@ -46,6 +47,7 @@ static ssize_t kpagecount_read(struct file *file, char __user *buf, > { > const unsigned long max_dump_pfn = get_max_dump_pfn(); > u64 __user *out = (u64 __user *)buf; > + struct dev_pagemap *pgmap = NULL; > struct page *ppage; > unsigned long src = *ppos; > unsigned long pfn; > @@ -60,17 +62,18 @@ static ssize_t kpagecount_read(struct file *file, char __user *buf, > count = min_t(unsigned long, count, (max_dump_pfn * KPMSIZE) - src); > > while (count > 0) { > - /* > - * TODO: ZONE_DEVICE support requires to identify > - * memmaps that were actually initialized. > - */ > ppage = pfn_to_online_page(pfn); > + if (!ppage) > + ppage = pfn_to_devmap_page(pfn, &pgmap); > > if (!ppage || PageSlab(ppage) || page_has_type(ppage)) > pcount = 0; > else > pcount = page_mapcount(ppage); > > + if (pgmap) > + put_dev_pagemap(pgmap); Ehm, don't you have to reset pgmap back to NULL? Otherwise during the next iteration, you'll see pgmap != NULL again. > + > if (put_user(pcount, out)) { > ret = -EFAULT; > break; > @@ -229,10 +232,12 @@ static ssize_t kpageflags_read(struct file *file, char __user *buf, > { > const unsigned long max_dump_pfn = get_max_dump_pfn(); > u64 __user *out = (u64 __user *)buf; > + struct dev_pagemap *pgmap = NULL; > struct page *ppage; > unsigned long src = *ppos; > unsigned long pfn; > ssize_t ret = 0; > + u64 flags; > > pfn = src / KPMSIZE; > if (src & KPMMASK || count & KPMMASK) > @@ -242,13 +247,15 @@ static ssize_t kpageflags_read(struct file *file, char __user *buf, > count = min_t(unsigned long, count, (max_dump_pfn * KPMSIZE) - src); > > while (count > 0) { > - /* > - * TODO: ZONE_DEVICE support requires to identify > - * memmaps that were actually initialized. > - */ > ppage = pfn_to_online_page(pfn); > + if (!ppage) > + ppage = pfn_to_devmap_page(pfn, &pgmap); > + > + flags = stable_page_flags(ppage); > + if (pgmap) > + put_dev_pagemap(pgmap); Similar comment. > > - if (put_user(stable_page_flags(ppage), out)) { > + if (put_user(flags, out)) { > ret = -EFAULT; > break; > } > @@ -277,6 +284,7 @@ static ssize_t kpagecgroup_read(struct file *file, char __user *buf, > { > const unsigned long max_dump_pfn = get_max_dump_pfn(); > u64 __user *out = (u64 __user *)buf; > + struct dev_pagemap *pgmap = NULL; > struct page *ppage; > unsigned long src = *ppos; > unsigned long pfn; > @@ -291,17 +299,18 @@ static ssize_t kpagecgroup_read(struct file *file, char __user *buf, > count = min_t(unsigned long, count, (max_dump_pfn * KPMSIZE) - src); > > while (count > 0) { > - /* > - * TODO: ZONE_DEVICE support requires to identify > - * memmaps that were actually initialized. > - */ > ppage = pfn_to_online_page(pfn); > + if (!ppage) > + ppage = pfn_to_devmap_page(pfn, &pgmap); > > if (ppage) > ino = page_cgroup_ino(ppage); > else > ino = 0; > > + if (pgmap) > + put_dev_pagemap(pgmap); Similar comment. IIRC, we might still stumble over uninitialized devmap memmaps that essentially contain garbage -- I recall it might be the device metadata. I wonder if we at least have to check pgmap_pfn_valid(). -- Thanks, David / dhildenb