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 256F6C83F27 for ; Wed, 16 Jul 2025 08:40:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B47488D0002; Wed, 16 Jul 2025 04:40:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B1F068D0001; Wed, 16 Jul 2025 04:40:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A34A28D0002; Wed, 16 Jul 2025 04:40:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 8E1B38D0001 for ; Wed, 16 Jul 2025 04:40:14 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 1A1D2C02F0 for ; Wed, 16 Jul 2025 08:40:14 +0000 (UTC) X-FDA: 83669480748.15.C600C99 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf07.hostedemail.com (Postfix) with ESMTP id C59F640005 for ; Wed, 16 Jul 2025 08:40:10 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=ct2BPYgm; dmarc=pass (policy=quarantine) header.from=redhat.com; spf=pass (imf07.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752655210; a=rsa-sha256; cv=none; b=aGCtZ28DWi3c8gP0esiAlBUl2q9vyf4MNAljBSs+rkizZwnbvuH5MP5PSXLIozxaUYPcYw +R4pe0LKbvQS5PH93civanSFr1QragEUQERj/iGmu2TuA2xPBvvw6iiuWHVw4zZoiAc+kr 7Lg1i3QcCfNmce1WFuJdyX1hy4aVXPQ= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=ct2BPYgm; dmarc=pass (policy=quarantine) header.from=redhat.com; spf=pass (imf07.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1752655210; 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=OSzSTiWWx3Mgn+kOlT8G5aG3zaow2wrPSmv/FVAPdmQ=; b=X2lEMH9H2HIZBCcq+EiiYKlTjLmvQfdEN+3+VIqM2JNbrDEUUmp3ro7aTXgKXzxiLR1IBi Vw4JqcMQ3+5Mjj8xV3yhjL8MN4TUg77H9Xi02FOdasIgkXcIEvHQntATEW3ByV0I3JuGYR cEvsRp7hlAtgTluCgsguy0MB+CmbXnE= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1752655210; 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=OSzSTiWWx3Mgn+kOlT8G5aG3zaow2wrPSmv/FVAPdmQ=; b=ct2BPYgm7GhDOve4q+QVccxn8sLMuy+wgXsUOIIvv9fG1KBdRvl634skgM6oyW8VCVGtPe x519SqppU1n+CqWrFFmzQaFrw7j0r4fW5XJlgZF8mupd3UPhlSp/tGsQUiOozY2XVw6jAv b8X5UXQC3LOkDwwv/Zt9np/vjSGJ7FA= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-602--paNYAXVP0qxFCRAFns9iA-1; Wed, 16 Jul 2025 04:40:09 -0400 X-MC-Unique: -paNYAXVP0qxFCRAFns9iA-1 X-Mimecast-MFC-AGG-ID: -paNYAXVP0qxFCRAFns9iA_1752655208 Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-3a4f65a705dso4133495f8f.2 for ; Wed, 16 Jul 2025 01:40:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752655208; x=1753260008; h=content-transfer-encoding:in-reply-to:organization:content-language :from:references:cc:to:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=OSzSTiWWx3Mgn+kOlT8G5aG3zaow2wrPSmv/FVAPdmQ=; b=aqXqXJHUgtWYV+0/2wNHxRwKIegH40GYy3l3fSb1/HZYwQgVEyl/nLHqzEPlk42n8c jYhnVmZGibmv1DS2jhY7ULVdY/RWfzoX0TKS+xh+yH0g5JnOC3RiP0AbRC7/QyWIS0Qf hF3l64ebVKaKAZy0/ooMmD4Tl9iXHrwnVb0yZuTUAcz/hwRE7w6WhpeXokcxLiGiquB8 ZPfNWwymFUuIcEVNa0TfU6dStjD9CZso4+InrXcLzSqZkr6XCmG8Xc5XP979M8pyaxE7 PKs/EyVk8x1BiQJ01LoGyws8PgfJR/PizDW2lMEBQW7DmgziwofPErsIN0j3OM7seHsd gIbA== X-Gm-Message-State: AOJu0YwHlvcZAkWJWBWQd/V2mwDh2LrbU4fCmGeyl18wZV5oyiTXNe8r zzRVmOFQMnNahxwrS/0jRUH0A+eh0xtnjLvQxm0RMoT96+pF5aOzCzrlbcdOJqQqrGthEePaGQO zyoR1v7bID1sjb/6/xGiqcQyeccOpItr7yDLLuSxLjsJ29pe/dYez X-Gm-Gg: ASbGnctJ1p29m0xmvajPlMCKWtIHaNljExWLMhowM4hXrIdTQA6l/0cpWrRnaRPVlB1 7cHtMT2sKKjz7MM7RJiAtl1BS+wGUsuPocMaO7aQxFWtru+VmnNPlZZ0gH0v5M77OCrPVXo1bGv lqEx0XmKuopJLbQ3XluFCjmLD0rybMTE65Ghje0aMxNMBnbDdBFHyLJah8M+/ldFujIAggfSvGc +wlIvmjm71BQq17pvsKO5tH866G+UasuVZ4uUsAx+myrGSYYJB0sk3LjFeIgquqn54B5aUA3q/Q 7T4PYXhRmP6mMOFchqsPLymH5ln2MvyjrtEG+A0JKmMnN0ZeMtXUQr9NzEZUvIZ3zZcvNDIlDy8 rbDVN0hZ3VtsoPPrKC67r6/WURmUR/ghj4GBCUVlmuWZhdJsPZqDtKj/cBkofXYG6o+E= X-Received: by 2002:a05:6000:22c6:b0:3a3:652d:1640 with SMTP id ffacd0b85a97d-3b60e4c9551mr1177334f8f.2.1752655207765; Wed, 16 Jul 2025 01:40:07 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHrz7aA1Q5DJ0qrWg414nemqw3+E5uTkk/vafPidGzJJcoZYuxj+80SlJoZCzlNz1Q/6bN5bQ== X-Received: by 2002:a05:6000:22c6:b0:3a3:652d:1640 with SMTP id ffacd0b85a97d-3b60e4c9551mr1177269f8f.2.1752655207170; Wed, 16 Jul 2025 01:40:07 -0700 (PDT) Received: from ?IPV6:2003:d8:2f1d:ed00:1769:dd7c:7208:eb33? (p200300d82f1ded001769dd7c7208eb33.dip0.t-ipconnect.de. [2003:d8:2f1d:ed00:1769:dd7c:7208:eb33]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4562e83c9edsm13968115e9.34.2025.07.16.01.40.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 16 Jul 2025 01:40:06 -0700 (PDT) Message-ID: Date: Wed, 16 Jul 2025 10:40:04 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 6/9] mm/memory: convert print_bad_pte() to print_bad_page_map() To: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, xen-devel@lists.xenproject.org, linux-fsdevel@vger.kernel.org, nvdimm@lists.linux.dev, Andrew Morton , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Dan Williams , Matthew Wilcox , Jan Kara , Alexander Viro , Christian Brauner , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Zi Yan , Baolin Wang , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Jann Horn , Pedro Falcato , Hugh Dickins , Oscar Salvador , Lance Yang , Russell King , "linux-kernel@vger.kernel.org" References: <20250715132350.2448901-1-david@redhat.com> <20250715132350.2448901-7-david@redhat.com> From: David Hildenbrand Organization: Red Hat In-Reply-To: <20250715132350.2448901-7-david@redhat.com> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: hFBqluxpPnv-TFrAb76xcx2B8pEU3-TM_AYM4860m1E_1752655208 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: C59F640005 X-Stat-Signature: xqux7nkjnmfh397yjzendqz7frfshhzd X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1752655210-142210 X-HE-Meta: U2FsdGVkX1+wTpWoKFHpUWkHhxUHZy8yltI0VlK+LvOlA90Ee5NWp+pU/Wzcn8urux1S2jCZryQsbR9lOMdzGQ0XIgqLkyBnoIVKE+b8kQnFbV+WMmhC8KpAeiwDcybsCOMct83cTYP/l3V2SGnqK1UShF9BDQXsQk9GNe/EUWvxbSGwpI5sr9GUaqFDiJv+S59v4br5BKcLaeIWYfbybL7c3DJV9iilYdYH+1n4vYBVWKEVb9hvIu+eNLRAfqIghMvXQ/WbCC/6sK0yc8hX8IKxQPINw546yL5P5VTkm7klVTC6dE+LGRLHLLd9XmNF1cHXOCeHo7Kn3cOgKdcSoRNvVW+197wd+hmgIRgso9M14p73LlS3kKfFF7x86ObotqIVGYDQjflfexyntpe4C0WVvJHcaSP/3CAVq7l8HLh/qZiAMbH9Y2Bq8f7thA6D85vv+O7VwgdT+H4157z/fNOTlcdJjjZlUq+p87b4JLgC5be2C1fezBa8jFNJIkRcWK7xWjclNjz5f4AGr5ocyKc6w3xrU4MCKx6j7ti4eJdFTriMtxyBJ4LOyuDLQ2iG4b17xXtHg9fUI3sMCsycP2rr//75J/Qean0GCK3Rz/LPxVKW+M5OkIUuEoicS7mzKOF5YgcKQ3teHZvb2jB3q5qGpnwu6/BB1H2/D4JfbYZbB56s99TnaOlYDsbTVY7DhxkglBS0BqLChpFOfjXDs0+inIwKf1sIfOq6jhwCZeWDZa6xu1rMt8cUZNNLMqJ020OhJgFElf8Ry3T9pnw2GNJPhqTYQA7pBLaELmZcHUsnaDvcs1h+U+KbTjjGtxyZecBtqfMXFEdPPbX517R4Wc+5g6wRwf6mFvn4fl02SHaQvHp9gS3xqpTWGFEk/VmR9owH5ZzxkunyPCLDKrNDYb+RwGJSwKSrVXUQhxVFdAa9vKHkL4nNirhkPpIdBNcQREP0CuHBt+cG99Ud1kO r3nyr19Y SxyTPaDGjaKltbzcGiOl7dj2hNDQbMTGXHYq8FkdIkjuEUk/U6ZHv9vJ/g/dMM4V6LaTDGfAMTSrp/uJilFvcDfMxoyUGisz7yiOFEE4ws1l3Bv8CQ2bnLqmXvVahZ6mrd4ym680e0pW5e2wrUzjOHkguNed4Qpx/mGOdZCRH6D5X8XaWCkdrOfWX+i2+j9JiunhDalXO5QdPo9qHK4PAWAtw3PTVhX4AvU0K6ljO7/hXjaHpvpDl5uBm0wlJ4RXVlgpoybNBYCSYl2koSAPu4JEUVPzZkVbUUMt5ehzRz9U8Xj5S3oPGQNRZ6ChAXx606pyiCzbpPW06xpiMLqdS9APmDdME2H4HbPgwqB5CRsrKC+wsX/AWXG/jueAysm8D8M9gsWOqG0pk0QnPIpggjkWSZtxVv10bBs9jIvGotk/BU0njhdlWIoMAc+p5CbxoSidkbMoX2vfW96OIQMVkNb8LCYLRRTVtqau/DHengRZL4KcLDxrNEvhVs4hjXwFDdlcD4U1MIf8467vnBMGsjYqAHF/hn4lcg197 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: List-Subscribe: List-Unsubscribe: On 15.07.25 15:23, David Hildenbrand wrote: > print_bad_pte() looks like something that should actually be a WARN > or similar, but historically it apparently has proven to be useful to > detect corruption of page tables even on production systems -- report > the issue and keep the system running to make it easier to actually detect > what is going wrong (e.g., multiple such messages might shed a light). > > As we want to unify vm_normal_page_*() handling for PTE/PMD/PUD, we'll have > to take care of print_bad_pte() as well. > > Let's prepare for using print_bad_pte() also for non-PTEs by adjusting the > implementation and renaming the function -- we'll rename it to what > we actually print: bad (page) mappings. Maybe it should be called > "print_bad_table_entry()"? We'll just call it "print_bad_page_map()" > because the assumption is that we are dealing with some (previously) > present page table entry that got corrupted in weird ways. > > Whether it is a PTE or something else will usually become obvious from the > page table dump or from the dumped stack. If ever required in the future, > we could pass the entry level type similar to "enum rmap_level". For now, > let's keep it simple. > > To make the function a bit more readable, factor out the ratelimit check > into is_bad_page_map_ratelimited() and place the dumping of page > table content into __dump_bad_page_map_pgtable(). We'll now dump > information from each level in a single line, and just stop the table > walk once we hit something that is not a present page table. > > Use print_bad_page_map() in vm_normal_page_pmd() similar to how we do it > for vm_normal_page(), now that we have a function that can handle it. > > The report will now look something like (dumping pgd to pmd values): > > [ 77.943408] BUG: Bad page map in process XXX entry:80000001233f5867 > [ 77.944077] addr:00007fd84bb1c000 vm_flags:08100071 anon_vma: ... > [ 77.945186] pgd:10a89f067 p4d:10a89f067 pud:10e5a2067 pmd:105327067 > > Signed-off-by: David Hildenbrand > --- > mm/memory.c | 120 ++++++++++++++++++++++++++++++++++++++++------------ > 1 file changed, 94 insertions(+), 26 deletions(-) > > diff --git a/mm/memory.c b/mm/memory.c > index a4f62923b961c..00ee0df020503 100644 > --- a/mm/memory.c > +++ b/mm/memory.c > @@ -479,22 +479,8 @@ static inline void add_mm_rss_vec(struct mm_struct *mm, int *rss) > add_mm_counter(mm, i, rss[i]); > } > > -/* > - * This function is called to print an error when a bad pte > - * is found. For example, we might have a PFN-mapped pte in > - * a region that doesn't allow it. > - * > - * The calling function must still handle the error. > - */ > -static void print_bad_pte(struct vm_area_struct *vma, unsigned long addr, > - pte_t pte, struct page *page) > +static bool is_bad_page_map_ratelimited(void) > { > - pgd_t *pgd = pgd_offset(vma->vm_mm, addr); > - p4d_t *p4d = p4d_offset(pgd, addr); > - pud_t *pud = pud_offset(p4d, addr); > - pmd_t *pmd = pmd_offset(pud, addr); > - struct address_space *mapping; > - pgoff_t index; > static unsigned long resume; > static unsigned long nr_shown; > static unsigned long nr_unshown; > @@ -506,7 +492,7 @@ static void print_bad_pte(struct vm_area_struct *vma, unsigned long addr, > if (nr_shown == 60) { > if (time_before(jiffies, resume)) { > nr_unshown++; > - return; > + return true; > } > if (nr_unshown) { > pr_alert("BUG: Bad page map: %lu messages suppressed\n", > @@ -517,15 +503,87 @@ static void print_bad_pte(struct vm_area_struct *vma, unsigned long addr, > } > if (nr_shown++ == 0) > resume = jiffies + 60 * HZ; > + return false; > +} > + > +static void __dump_bad_page_map_pgtable(struct mm_struct *mm, unsigned long addr) > +{ > + unsigned long long pgdv, p4dv, pudv, pmdv; > + pgd_t pgd, *pgdp; > + p4d_t p4d, *p4dp; > + pud_t pud, *pudp; > + pmd_t *pmdp; > + > + /* > + * This looks like a fully lockless walk, however, the caller is > + * expected to hold the leaf page table lock in addition to other > + * rmap/mm/vma locks. So this is just a re-walk to dump page table > + * content while any concurrent modifications should be completely > + * prevented. > + */ > + pgdp = pgd_offset(mm, addr); > + pgd = pgdp_get(pgdp); > + pgdv = pgd_val(pgd); Apparently there is something weird here on arm-bcm2835_defconfig: All errors (new ones prefixed by >>): >> mm/memory.c:525:6: error: array type 'pgd_t' (aka 'unsigned int[2]') is not assignable 525 | pgd = pgdp_get(pgdp); | ~~~ ^ 1 error generated. ... apparently because we have this questionable ... arch/arm/include/asm/pgtable-2level-types.h:typedef pmdval_t pgd_t[2]; I mean, the whole concept of pgdp_get() doesn't make too much sense if it wants to return an array. I don't quite understand the "#undef STRICT_MM_TYPECHECKS #ifdef STRICT_MM_TYPECHECKS" stuff. Why do we want to make it easier on the compiler while doing something fairly weird? CCing arm maintainers: what's going on here? :) An easy fix would be to not dump the pgd value, but having a non-functional pgdp_get() really is weird. -- Cheers, David / dhildenb