From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f175.google.com (mail-qk1-f175.google.com [209.85.222.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C69DD2882D6 for ; Fri, 24 Apr 2026 15:06:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.175 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777043193; cv=none; b=nJTE5CpMVAVv5aHHirHYkg0QMecG1/zFrn2h+p2EDCjcaYZWb3G/q46sDp8Rppnn8ZxngWSEcedRq3yGOUOtgnCM12MxzJ9aL8KsOeWf7WXUWirsUffqyzWpSQdppjXXSaEyT323sQLeFnKc+QTD3GvrSZUMKD33OPsTClxLdc8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777043193; c=relaxed/simple; bh=lPEfpzwiNnp4Us4njDeq7FVgaVJSVyeUSX/+2EeR9Qc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=SwVtB/9Qq8Ea+ybqqlPsQavIYub+LwzpB1dA04UKL2Bt08Cq8aH2fUbIFNXJPHfUXEgcfPHJFqlIfB9EN90mquH1/dtUOHyjkuhFLfBlD7IlLNYtbXcOEFTm0cgjljk3wA/mzkr/1Ha2FzDB6EAs4lr/DzNX3b/ulXyi8IDOtgc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=soleen.com; spf=pass smtp.mailfrom=soleen.com; dkim=pass (2048-bit key) header.d=soleen.com header.i=@soleen.com header.b=GOPxrBkP; arc=none smtp.client-ip=209.85.222.175 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=soleen.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=soleen.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=soleen.com header.i=@soleen.com header.b="GOPxrBkP" Received: by mail-qk1-f175.google.com with SMTP id af79cd13be357-8cbb6d5f780so714645785a.1 for ; Fri, 24 Apr 2026 08:06:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen.com; s=google; t=1777043191; x=1777647991; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=39aR5XRbrEXV24JT5m2euVHnJMBsT6ax8xLhWEkFjFY=; b=GOPxrBkPOYadJ71PWBHijiwmG4jt2QTQPo7Ldlm9LvEFlroJxbBPN5NTiTotOsTXgi Q3asdwlCzTB8cdjIwWPzSUDM4VZNSi4d0jp5iG8f1tKorNGcqs+Ujeo69f1/P85WmS9A qoriXj6lCjE58zRaO+H+1XOJ1FyzBR7u/aGIRhrIIfAmIqyyTs7vKWHAI2M6+jH4gg8u fd/tXPdx1Hrzz+hCzqibA8vr0sdBLlyiryyQONtp6gOgQ18SL6PbBD9GfPlZt1S9NUPw kiPLzzb84D3k9i6Rj0niYATkYuduDf/TC8JGIl1algwwp+CIJYLEyLn6JN9ziAzD4yWA G0Jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777043191; x=1777647991; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=39aR5XRbrEXV24JT5m2euVHnJMBsT6ax8xLhWEkFjFY=; b=DBk1Pc3i0Iyq29FidaqNjD2PB6E+z8TSf5YHMluOtvog1sUobtpKkQ+72ZY8sCwFCm VZzWh13g9gfBL7yspDLf0SF4OkX33/sZGWcVgYdvhFAsMHIaPqU72CP088vzcU12TNOk EnyPpKPq/jPTsRwTUqmrEBYSOmhFRtXw1dncIHIUWvOL4vG662f05doP1cMBN0b890zJ p8yLtoZy/Y1K0gXIXGpddyqsi+eNzO5Tzs6yEOA8m+jCQfB414JuKbwBi74RrcM4kPDu HMjtLq2m+v6gDceFpIsPmS+gRMp3yD4XQvoavGj03ssvhyJ7hez2h7/C1lbOqba+jfrO hU2Q== X-Forwarded-Encrypted: i=1; AFNElJ9XpAAjim0/4lKt4JqLTAczSljK8M91I7Ygf3ctCxePx8hep/L2PI7ezHYiLjobjKj7OgC5pStar7BMhG8=@vger.kernel.org X-Gm-Message-State: AOJu0Yyb+tzyl+WXUCBRyfA5OjC6aijhwlg/pmVYZ0bDC6D++ZixbaaS S1aMsqWmFw0s5KWUnalTtIzF8KIRt3Vq8y1SopMswJT9r/a43P5a3Zp3qG12R6mE/QQ= X-Gm-Gg: AeBDiesXUFfXl5NzHjOnIWxeGKu5HocriinL+nwC+nXbyTvbaEw4i72ya86N7BrGzFz RufQ4M9hYFdCovBMwhP+lGmWNRSY329BPm+WwUwo0M2VMqXi98FIXZFQspB9t6wt/SrQJrwmi7s LXIaYpMNMU66QXV1S3RC2HIf+BrwBEg04SFMVl/s+Z72aGxKRoq1rVS7Oc2s1jYepTCd9jNYwgW wCZt10RkO0Ve24FeE+OcYTCNgn5IfjHiJkzi/ZEmNARMT4csro5Jyqt6YjzM33KYpjZm5qeAfSV qXvatmnnI2gpBg6b4EG2xfgCCJ6y6Qfu4D7v8zMAJ16jHfym5BYsmt7sEJwr9W27WBOZqQ7BIKN JBeTA2ig6L+7dLzQIOXK2lyK556uWAInpPFi2kFYqI/Fnqmh0+v7gIFDbaqG7SPXudYRyhzERyf QiPEwf15GTEM8hPxqJHvT7I6ozkq16elT5fcD8t4W9bgW79yyM4EE/KoyOVaI0bQ== X-Received: by 2002:a05:620a:4623:b0:8cb:62c3:3690 with SMTP id af79cd13be357-8e78f443268mr4562871085a.13.1777043190723; Fri, 24 Apr 2026 08:06:30 -0700 (PDT) Received: from plex ([71.181.43.54]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8e7d9abce59sm2293120385a.46.2026.04.24.08.06.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Apr 2026 08:06:30 -0700 (PDT) Date: Fri, 24 Apr 2026 15:06:28 +0000 From: Pasha Tatashin To: Sasha Levin Cc: "David Hildenbrand (Arm)" , akpm@linux-foundation.org, corbet@lwn.net, ljs@kernel.org, Liam.Howlett@oracle.com, vbabka@kernel.org, rppt@kernel.org, surenb@google.com, mhocko@suse.com, skhan@linuxfoundation.org, jackmanb@google.com, hannes@cmpxchg.org, ziy@nvidia.com, linux-mm@kvack.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, Sasha Levin , Sanif Veeras , "Claude:claude-opus-4-7" Subject: Re: [RFC 4/7] mm: add page consistency checker implementation Message-ID: References: <20260424140056.2094777-1-sashal@kernel.org> <20260424140056.2094777-5-sashal@kernel.org> <4b961a07-b72d-4c8a-ab49-23f61ed12b53@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On 04-24 10:49, Sasha Levin wrote: > On Fri, Apr 24, 2026 at 04:25:41PM +0200, David Hildenbrand (Arm) wrote: > > > + /* > > > + * Size bitmaps to cover the full PFN range including any holes. > > > + * Holes waste a few bits but a flat bitmap keeps the indexing > > > + * trivial (pfn - min_pfn) and avoids additional data structures > > > + * that would themselves be subject to corruption. This matches > > > + * the approach used by pageblock_flags. > > > + */ > > > + pc_state.min_pfn = PHYS_PFN(memblock_start_of_DRAM()); > > > + pc_state.max_pfn = PHYS_PFN(memblock_end_of_DRAM()); > > > + spanned_pfns = pc_state.max_pfn - pc_state.min_pfn; > > > + if (!spanned_pfns || spanned_pfns > UINT_MAX) { > > > + pr_err("PFN span %lu cannot be represented by bitmap APIs, feature disabled\n", > > > + spanned_pfns); > > > + return; > > > + } > > > + > > > + pc_state.db.nbits = spanned_pfns; > > > + > > > + bitmap_bytes = BITS_TO_LONGS(pc_state.db.nbits) * sizeof(unsigned long); > > > + > > > + pr_info("Initializing: PFN range [%lu-%lu), %u bits (%zu KB per bitmap)\n", > > > + pc_state.min_pfn, pc_state.max_pfn, pc_state.db.nbits, > > > + bitmap_bytes / 1024); > > > + > > > + /* Allocate primary bitmap (zeroed by memblock_alloc) */ > > > + pc_state.db.bitmap[DUAL_BITMAP_PRIMARY] = > > > + memblock_alloc(bitmap_bytes, SMP_CACHE_BYTES); > > > + if (!pc_state.db.bitmap[DUAL_BITMAP_PRIMARY]) { > > > + pr_err("Failed to allocate primary bitmap, feature disabled\n"); > > > + return; > > > + } > > > > > > > One bitmap that covers all sparse memory available at boot. > > > > Conclusion: Just horrible. > > Depends on who's looking at the code :) > > I picked it for auditability: covering the whole range with two > memblock_alloc'd arrays means the only thing on the lookup path is the bitmap > words themselves, which is what the dual-bitmap invariant already checks. The issue is that we are going back in time to a flat memory, without NUMA or hotplug support. We need an abstraction that avoids allocating this memory in enormous contiguous chunks, as thit approach will not work on modern hardware. > > We could go with per-section bitmaps which will fix the waste but pull > mem_section[] into the trust boundary, so we'd have to start validating it too. Page-ext provides all of these capabilities, but as you described in the cover letter, it does not meet your requirements. Therefore, I believe a new abstraction layer is needed. Pasha