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 DDA5FC6FD18 for ; Tue, 18 Apr 2023 21:33:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5CB078E0006; Tue, 18 Apr 2023 17:33:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 57B668E0001; Tue, 18 Apr 2023 17:33:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 41BEA8E0006; Tue, 18 Apr 2023 17:33:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 3057F8E0001 for ; Tue, 18 Apr 2023 17:33:21 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id E34DC14040A for ; Tue, 18 Apr 2023 21:33:20 +0000 (UTC) X-FDA: 80695812960.03.2AE5665 Received: from mail-yw1-f170.google.com (mail-yw1-f170.google.com [209.85.128.170]) by imf22.hostedemail.com (Postfix) with ESMTP id 21DD3C000F for ; Tue, 18 Apr 2023 21:33:18 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=fBPSS93a; spf=pass (imf22.hostedemail.com: domain of vishal.moola@gmail.com designates 209.85.128.170 as permitted sender) smtp.mailfrom=vishal.moola@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1681853599; a=rsa-sha256; cv=none; b=jcbFnjt2uUqxVqLMbe8Bg03flck1PBmAwae5j/L4QpcXMbkigLtHvQqiuF98XtuIow5/Kf okANH1PuUSxgmeBEzwC/Kn0MeMJ6FFUvgbWHyfLWAowhClx0LHDfEvWYcvG6raneW+nNaq GTvrBhY+fo4RPwJj9L9RkQowQAgxk7E= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=fBPSS93a; spf=pass (imf22.hostedemail.com: domain of vishal.moola@gmail.com designates 209.85.128.170 as permitted sender) smtp.mailfrom=vishal.moola@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1681853599; h=from:from:sender: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:dkim-signature; bh=fZ+faik75720SnLDzvntxl1cmAaRHsLQ7oOmPoVPf3o=; b=DObQg1zwdHKLhrvbjrDEq4BB/JFLUNS47RBxkA/Ry7GkfRjxzqWkzzM8dTxWfMmWtFsZyS 5ndCpedcSpo9wBmtACH93T8XcohzlnofNc7mt39Enzi/N8pfQrevtxlHm7HzzOzjYZ8qhd FrtBXJCBUL8FVaQGnxoqEqf0xsNzKEY= Received: by mail-yw1-f170.google.com with SMTP id 00721157ae682-54fbb713301so233882447b3.11 for ; Tue, 18 Apr 2023 14:33:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681853598; x=1684445598; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=fZ+faik75720SnLDzvntxl1cmAaRHsLQ7oOmPoVPf3o=; b=fBPSS93aalbav0LUzUejRt2NjbHpBJmNsHVPRRbsF+jG5Nu8WjfWT+weSiXFGrkEbN Bl+EcMNC7lpcawm/MuwqggHfJmNk7zAK9haLpnJV08P367c5YohyB4lPm9ubYCuINJZG pmhBTFu6UKlSFmyU0QWGBEDpdg/7xojdmyIrq4CWcHgeoPLavovDZAMaCmQm5Tmi+PdF awAr9pJ9qRfL4qAoU/GIaaVF0Yb/A9oc1EXdyleFSucNiyAMBSWiFjcubi/Cl7MqSDQT LqfYl5LxNuy3TqKDTGZky+Cx6fyOI9+XqrTm2mW88NG+xvACaI/puCphU95FqO3MwFDd on2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681853598; x=1684445598; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=fZ+faik75720SnLDzvntxl1cmAaRHsLQ7oOmPoVPf3o=; b=CaJPchJhCwpQsjuatbihATDUSIW0Gy+tekC5bw1h8RIAkt5L4qQ/79QtAkA0uM8FFK Gcq6g1TOoK92VNS9q4m1QgfB+z2U4IWgsww654LdLlWP2WXTKbH+FLpsC8TD2Ok8SXnX TIWN7quL+YMmQs88Ybro/c2lgGZdzFFMDZubguUkHZUwisPbl9KOJ9JP5Wm7+SZv9/HF cC+/Ph/0JnRxx/LkuQG/9zHm72M3ZKK5oFzCO24/PGkqhTin8zTxZk0k6ckTTAqDhhFL W83IqSZ4UjmyU4bj9ApdMtDKEEeTyIYLfGcvHbnISn771qZX5AWLMuCgrZRjSGGBCsDR ZHgw== X-Gm-Message-State: AAQBX9euIB3qlJst+6An9MTK9I3mcXBnzfG59mU3VhU1HTtyfgA5BALf od5zklqf/33G/ibiv9hmgJkF8JiQC5EW/z8Jzek= X-Google-Smtp-Source: AKy350Zg9/w1pIq1h9Mfl98gkIvdjlXYVLE/yxlCrmuaudFEJKPjKGaCNnj1KVCOnrcLYZjlnD0Q2KC4cnvL5HhzBhY= X-Received: by 2002:a81:8443:0:b0:54f:8af3:6488 with SMTP id u64-20020a818443000000b0054f8af36488mr1215032ywf.23.1681853598073; Tue, 18 Apr 2023 14:33:18 -0700 (PDT) MIME-Version: 1.0 References: <20230417205048.15870-1-vishal.moola@gmail.com> <20230417205048.15870-2-vishal.moola@gmail.com> In-Reply-To: From: Vishal Moola Date: Tue, 18 Apr 2023 14:33:06 -0700 Message-ID: Subject: Re: [PATCH 01/33] s390: Use _pt_s390_gaddr for gmap address tracking To: David Hildenbrand Cc: Andrew Morton , Matthew Wilcox , linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-csky@vger.kernel.org, linux-hexagon@vger.kernel.org, loongarch@lists.linux.dev, linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org, linux-openrisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, linux-um@lists.infradead.org, xen-devel@lists.xenproject.org, kvm@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Queue-Id: 21DD3C000F X-Rspamd-Server: rspam01 X-Stat-Signature: beyrdj6baumhe6yjsuegwj3o143fagdn X-HE-Tag: 1681853598-484115 X-HE-Meta: U2FsdGVkX18veHjqsdqZfjeHS7jg6AirhtUpV3gYj8w0f7IsqGpeX/cM2gh7VrwbB4KrezFC1tJlJeh5AHQ2n+rb0q8cXRigV+SqKZS5LqpXEGIIWXQh9EvaD/TwWYPGyjiVekZhGZ7J9uWCiytQaTltFlvsoA7j5f9nxcTOGDBMo+WneeD/hw3J+AKoDCLkDpsOP3/4Wlt3ERmSGzGBXndPkykIsit78szUJRKikK/e3aiRimUns6zqM8QMgSxPqopxqMN41F4oWnEz6XVZAicqQjo3qgAzyEag+Ug6lSalEgikHqJSQRTTPsqqY8ab1eceqiSmYpoe4b3VymPfVgYotNfIFWrMk+SoYBLbs1wd2ysaiesA7uTJr/oM5RuUpSAFCP1igzeWymg2mEc8+5HQiICloobuBe4slNZQy7Ps9NgK9uXIjxtvSFNh6cWZ4rIfJBryL2sw5IcKTCVjmj02vvZPhfy5cUytNB2thiFGC+Lg3wH3DxKlJ3Dai4p66zMcvGhXvcUhpcV1V1+Jt0uZnEjKYMBCjHbpX24sLbfLVY4IUj3mrUI09FUvYhommXx53CRwwPj+WYivey8L+MkMSxSlsTKz20blRkXpLhApnkcbxGWfzAc2wDfYfwxt24XbIGJYVk9IasyfOvCfl7us5gEJokFV3JSlSFQfQYL29FYgRl/ZBTWME61JsAnd42brinHaDrRgyuBgr5SfgNE5AiF1LVHbOFT54AAjpPftdAk/He2uIvvjuiC7AySxrbrxK5k+kIHb28s18eYL1Hs1od43fIGA35QNwH+o/GKmbv3JetL50Gp7aOQwbZrQ3oJl+afpOrAYgmtfQINnJQ/loFD4k7J5SQel9h43DY6MEfU+5YftwoEnzdDSkl6lNAfsIwBP1bR/H9VUHYHtqM4ZErZ4ez0SqerXzFITyW0ZO1jp9dtRXRtROFlP3HM0uxc6BCWBtX9yT+y9Uqi zbNHoega CYYzsFD/7d6ICmE1piTMGKnQwtty44oFWd4D5xjp/64mUqkRqBiviEwJibWql+W46wdbMNVOncst0DotkHiVmLFo0e4t7GIlGoQA0ByD60Ki/gdIgT2OdupIJWo7P6rYxNpIJ4APVwvcCc7749VxbaQ2+p5Q5aYqmTFYAjw4rYCxLjuJKA4mpKIc2Z9YImsRBS69AmnP5cDDtXvUent+PBWWCe1sV9cbOr13oUkE0XsxLms5Xl57bwIMcUOh1v2OFgU94gEZzkFhu8kXkt3I5f6XCPyGN8+fqhHm+i1uEc2ih7tKHtWt+oJqcTjibSWQwTwlJo6lRG2apOe4YM95VZKqHcSRSVBKkt10ju/DZe1tUx7mRO9TwkQFB4ejrng5l5XEqXvlS0qTiTQHML4Fl374UgBRb1wURvp6AFxf9P4s6/AxI/ycKiFrXco3orcI6V+4d7DB37EMVUKP55cwozHWcFPCYpwcRK5cV6cInEQvKhdtuBs3ElPB7iQ== 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 Tue, Apr 18, 2023 at 8:45=E2=80=AFAM David Hildenbrand wrote: > > On 17.04.23 22:50, Vishal Moola (Oracle) wrote: > > s390 uses page->index to keep track of page tables for the guest addres= s > > space. In an attempt to consolidate the usage of page fields in s390, > > replace _pt_pad_2 with _pt_s390_gaddr to replace page->index in gmap. > > > > This will help with the splitting of struct ptdesc from struct page, as > > well as allow s390 to use _pt_frag_refcount for fragmented page table > > tracking. > > > > Since page->_pt_s390_gaddr aliases with mapping, ensure its set to NULL > > before freeing the pages as well. > > > > Signed-off-by: Vishal Moola (Oracle) > > --- > > [...] > > > diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h > > index 3fc9e680f174..2616d64c0e8c 100644 > > --- a/include/linux/mm_types.h > > +++ b/include/linux/mm_types.h > > @@ -144,7 +144,7 @@ struct page { > > struct { /* Page table pages */ > > unsigned long _pt_pad_1; /* compound_head = */ > > pgtable_t pmd_huge_pte; /* protected by page->ptl= */ > > - unsigned long _pt_pad_2; /* mapping */ > > + unsigned long _pt_s390_gaddr; /* mapping */ > > union { > > struct mm_struct *pt_mm; /* x86 pgds only= */ > > atomic_t pt_frag_refcount; /* powerpc */ > > The confusing part is, that these gmap page tables are not ordinary > process page tables that we would ordinarily place into this section > here. That's why they are also not allocated/freed using the typical > page table constructor/destructor ... I initially thought the same, so I was quite confused when I saw __gmap_segment_gaddr was using pmd_pgtable_page(). Although they are not ordinary process page tables, since we eventually want to move them out of struct page, I think shifting them to be in ptdescs, being a memory descriptor for page tables, makes the most sense. Another option is to leave pmd_pgtable_page() as is just for this case. Or we can revert commit 7e25de77bc5ea which uses the function here then figure out where these gmap pages table pages will go later.