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 0F121C00140 for ; Wed, 24 Aug 2022 15:30:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8E390940009; Wed, 24 Aug 2022 11:30:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8939C940007; Wed, 24 Aug 2022 11:30:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 75A45940009; Wed, 24 Aug 2022 11:30:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 67D51940007 for ; Wed, 24 Aug 2022 11:30:56 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 34AB240D9C for ; Wed, 24 Aug 2022 15:30:56 +0000 (UTC) X-FDA: 79834874112.16.CB35854 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf09.hostedemail.com (Postfix) with ESMTP id 762D3140040 for ; Wed, 24 Aug 2022 15:30:54 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id A4E59618D6; Wed, 24 Aug 2022 15:30:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BF94DC433C1; Wed, 24 Aug 2022 15:30:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1661355053; bh=bdHWlWdZibPjvG9Ig5Z3u7zlLp/Dweo2dUzjMlR/vFw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=geWFbMj1asn2pA14t1ItPmvrZRl02ucR9eK9c7pHGlNj1EKI3zCtJFPuwX1LiT+R9 xTDPh434On1t0xJv7X1+gHWES2D2F6i3m3AzeH6zKoMhdK8gHtWBW/uWYPovjJjU8G 1sxeW6q/ABP9Yco194fvlo3PBExxSSuJaNogL2A/4Qk2ZWCX/8vybh3X14k6Y37Gky SiIPkPx7HIGXcsVxdZShNZvHmBUsG8uY53I353pLNchhaZR3Y/3EF1PsSs1Iz8C0ZO +ZiRUOO10wLn85uRxVgLxuqjB3rQDgOxyKfD6h/hVUTfd1lwe8WXzV3FVejcQ4MNMJ CmcRkw4xQ4cBQ== Date: Wed, 24 Aug 2022 16:30:47 +0100 From: Will Deacon To: Max Schulze Cc: linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com, naush@raspberrypi.com, linux-mm@kvack.org, akpm@linux-foundation.org Subject: Re: BUG: Bad page map in process/Bad Swap file entry, RPI CM4 on clone syscall Message-ID: <20220824153045.GA18443@willie-the-truck> References: <20220815142213.GA10448@willie-the-truck> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1661355054; a=rsa-sha256; cv=none; b=RvSnh3wgLF22wnkWVS8buWsRLYw4ayxg88ux2H119MaL5xx+v66toblnH7uMdDoc/oma02 wJpeSuDWk3mOTMCcSypG+CivetHBz+QNswYGVrwZAqkJ3TKjrz/uHEJPYzmo1uGeWXcB8M 5F4ZuIkLihgPNRBMVKrhydpMnTN0DuY= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=geWFbMj1; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf09.hostedemail.com: domain of will@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=will@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1661355054; 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=y16n6W74Sx/Ui1mZo4cf+0bUClxCbPUAwg0sISCyUMs=; b=3yGz5fBe5wzAoE6RDMIDFRa81j062vsFUPON7LUkY/yPYuvQoeA2DP52cHoK7SkDvxNL/O MgREF3D2kFG4fGpvCeenW+7rRVFW3rWasCn3gTW/w5MA+6F4h3EEAYIIjsgSJDPT3RxoMM v5C3IN96C0JEhTGWJCiojCj4aC/3VEU= Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=geWFbMj1; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf09.hostedemail.com: domain of will@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=will@kernel.org X-Rspamd-Queue-Id: 762D3140040 X-Rspamd-Server: rspam02 X-Stat-Signature: w5z9yjiffhgjgbp6weahtoik798bjodu X-Rspam-User: X-HE-Tag: 1661355054-644835 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, Aug 18, 2022 at 07:14:12PM +0200, Max Schulze wrote: > > On 15.08.22 16:22, Will Deacon wrote: > >>> [20:47:09] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready > >>> [20:48:46] BUG: Bad page map in process projecta  pte:1110111111111111 pmd:800000001c40003 > >>> [20:48:46] addr:0000007fa1c00000 vm_flags:00100073 anon_vma:ffffff805bf80d08 mapping:0000000000000000 index:7fa1c00 > >>> [20:48:46] file:(null) fault:0x0 mmap:0x0 read_folio:0x0 > > > > >> I hate to say it, but this all looks like memory corruption hitting the > >> page table and possibly the 'struct page' array to me :/ > > > > Perhaps a note on the occcurence: across devices, the "bad page map" > > differs at pte, but somehow is mostly consistent at pmd:800000001c40003 > > (though I have seen 800000001c02003 and 800000001c40003). Is this some > > "magic value"? Because when not, I think it would be highly unlikely to > > be the hardware. > > > > It is not only my program that has the problem, I have seen > > > > [Sun Aug 14 17:30:38 2022] BUG: Bad page map in process llvmpipe-3 pte:262d2626292a2627 pmd:800000001c01003 > > > > and > > [Sat Aug 13 11:53:43 2022] BUG: Bad page map in process Xorg:disk$1 pte:a098a09aa29ea8a4 pmd:800000001c01003 > > [Sat Aug 13 11:53:43 2022] addr:00000055a961e000 vm_flags:200100073 anon_vma:ffffff804c07d8f8 mapping:0000000000000000 index:55a961e > > [Sat Aug 13 11:53:43 2022] file:(null) fault:0x0 mmap:0x0 read_folio:0x0 > > > > > [..] > > I am able to reproduce this on 6.0.0-rc1 . > It looks like vm_normal_page does not recognize the page as being "normal" (?). > (mm/memory.c) I think the issue is much more fundamental than that; you appear to have page-table corruption (for example, "pte:262d2626292a2627" and "pte:1110111111111111" are definitely corrupted) and so anything dealing with 'struct page' derived from the physical address in the pte is going to go wonky. >From the logs here, the pmds look ok but these are the pte values I spotted: 0x1110111111111111 0x262d2626292a2627 0xa098a09aa29ea8a4 0x212725231f242323 0x2626262023222323 which don't seem to correspond to any sort of poison, but are possibly artifacts of repeated patterns with random bits cleared? Will