From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f174.google.com (mail-qt1-f174.google.com [209.85.160.174]) (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 A8A921A5B84 for ; Mon, 12 Jan 2026 19:17:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.174 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768245465; cv=none; b=HCwmviU7mZ6Qxd4yEcxehSJO5MtB5x4qgIhmVorYSgYspuEheAGnL01r5PV4hzTrRu2Lnukfx5gWCLHLNFP500bpOpOcmrvgGx8+qAKxRzvggFD0Ir5EvSfp9yu5qt+uRHlBnnDD4+8Q+hooVCnzjXVS/ulBhTOCu1LjnHOewSU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768245465; c=relaxed/simple; bh=NWDfa/sJJpX4wtHFpmlns1isF6LdcCFgQER69g8Tiec=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=GO5NfP2yElmNFmUyF5Ol7nXb3lQ7mhF2hsWhB0edulL4yAgzgIsC3V3fxTWAAFQA0yRhTF9uHAgw2VQwEJ1tRC1veck5+XYfyespvnEgH8TUon+tv6ng7/A7uq8M2WjwhiX88seaOnh5n9KxlfmT6YoKop8cqu/H2Mwh7xVT1AU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca; spf=pass smtp.mailfrom=ziepe.ca; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b=UScv0ETp; arc=none smtp.client-ip=209.85.160.174 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="UScv0ETp" Received: by mail-qt1-f174.google.com with SMTP id d75a77b69052e-4ee1a3ef624so41512161cf.0 for ; Mon, 12 Jan 2026 11:17:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1768245463; x=1768850263; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=79V8FU7VojpzuezWKGikKP+GBTJI3ooJk9r8kmAFP4Q=; b=UScv0ETpQAfaKfqQsOz7MPXyqbJyPe2KF9Q5Ozh9cddSfp47VDDoLL7u1kl2uMrMqe DocHvn3d8337G/bYOdNDZ5VDYx+Z96GoS/hcI6fMuwXZ7SUOuppLPopW67Bg0i61hvoa 1fv1t1LsyvT25265RBohrHbYniaYAwIAwG4Xmn/NMVqwgFxvaZBg9IM6AFgQlYGFdbcz UH4H0x+XYZZZe5vViqWZfq41Fiy6HxSlrv8ub4ntWjffyQ38GW8KCF9hfPUOGS6ZusSL xWsqQKRYCxnPJzDBNjDdwZ1dgdCsdBqVsqLZ6tPTVrioXCkAmryry2iYees529ukRc7o lhKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768245463; x=1768850263; h=in-reply-to:content-transfer-encoding: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=79V8FU7VojpzuezWKGikKP+GBTJI3ooJk9r8kmAFP4Q=; b=xVhCFaXbBCKcEK83OTmcfWfg1KdPJz7eCjKF3cSLGreFzoWdk53W86KSmQfmTs+9aZ kRIDLvf92fWhkgwIvkWGfovEKpQXaaXlWv3WeUGHD2ILxR31jRkPyNwnffohzdsTSwQ/ RfbqGjfxYN1ZYBzHm8hfuhB6j5rVuHuK4ta2xO+WoXlk4Lh/er+K6xaTFI/lrviC0Vq+ I2PIO/FcH8f4Otj/Hz9CoMb5SY3z0cOINI5yPxi7n4suKyvQklrj2PyVp9BheF8rs+iP Mt/Fjc3/labW9iBLPkKn/GLlKgb6ykApIVlaS/J+lWcBJc0WKQkhZlPubycWegCYx9kO 03FQ== X-Forwarded-Encrypted: i=1; AJvYcCVvd7odzn7YJX1XDbyL+QGO8GNEsspcstgZe4luljY4MsanUjEa7FuvCRYEsecqXb2t/VVse+FGgGZ1zr8=@vger.kernel.org X-Gm-Message-State: AOJu0YxMmuwviNxyePXNYNYNmI6qusR4UaOqKRlPTF/+I3WDO8rA4B07 Kx2yL2JAcDSdpq1xdp5TIxYDUXYsz4bX4XOUWBpIKWOGOar+lUnW3RpO12rdqB5exXs= X-Gm-Gg: AY/fxX5NcVuUGOiqBHqQxZyps5JDxVwK8Uywddp2IHRi4tTU5xM/TQYK+ncc+ezExl7 LU25Z3k08uFWJqitTKZNjGPlX8asmcjeElyeR10aUd15XwfIQQhjoGQsvfFM+KRYZmuoGC9qgVh y74Fh0wSy8LzU6TT/NrzS3v47FcBGgZ+cixk7Sh78ayfbmZk/ru0zJVenIQR4clamHuKTl3B87F KnPcgGd/GJRtCO04bGcBWw8fcCVSeec9vvJdL5Z4ZwWpyf6I1y4kJMRbWyWtN/MU1bHKD9u2utX 6q4qs2Q9gN2gu+pCZdvoWg2IMtfNQs5Vg8DxgYl7UHr0dp3NayJZpkJicyRaiXy4Ds8zBmz6cff kWHdJ/NdymgTEspOlqRpc5xrCk1UzakwqbsXDM/90sXJz4rlJObz24eoI77ybe5H+uvc/WAAqx3 m64i2K2ygPrgrsVJj0U5yCPx6lm+YBhKFVhb4U82RafzRSTTAA96NsD/ZAlXp8FL2+aIU= X-Google-Smtp-Source: AGHT+IG8g77fglBlqhZKMGazF9A00SKS0QmAPx/h9dmbnRAuIOD9kpUD64pci6T5eeVAY5Szu07Wsg== X-Received: by 2002:a05:622a:4d0f:b0:4ec:f403:3019 with SMTP id d75a77b69052e-4ffb48fff61mr258726701cf.21.1768245462410; Mon, 12 Jan 2026 11:17:42 -0800 (PST) Received: from ziepe.ca (hlfxns017vw-142-162-112-119.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.162.112.119]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-4ffa8d3d92esm132795641cf.5.2026.01.12.11.17.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Jan 2026 11:17:41 -0800 (PST) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1vfNQ5-00000003cmO-22Z1; Mon, 12 Jan 2026 15:17:41 -0400 Date: Mon, 12 Jan 2026 15:17:41 -0400 From: Jason Gunthorpe To: "David Hildenbrand (Red Hat)" Cc: Mostafa Saleh , linux-mm@kvack.org, iommu@lists.linux.dev, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, corbet@lwn.net, joro@8bytes.org, will@kernel.org, robin.murphy@arm.com, akpm@linux-foundation.org, vbabka@suse.cz, surenb@google.com, mhocko@suse.com, jackmanb@google.com, hannes@cmpxchg.org, ziy@nvidia.com, lorenzo.stoakes@oracle.com, Liam.Howlett@oracle.com, rppt@kernel.org, xiaqinxin@huawei.com, baolu.lu@linux.intel.com, rdunlap@infradead.org, Samiullah Khawaja Subject: Re: [PATCH v6 3/4] iommu: debug-pagealloc: Track IOMMU pages Message-ID: <20260112191741.GK745888@ziepe.ca> References: <20260109171805.901995-1-smostafa@google.com> <20260109171805.901995-4-smostafa@google.com> <20260109195111.GQ545276@ziepe.ca> <20260112133256.GB745888@ziepe.ca> <20260112135208.GD745888@ziepe.ca> <746f5adb-1d91-4ca2-8ae0-a2d171203b66@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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <746f5adb-1d91-4ca2-8ae0-a2d171203b66@kernel.org> On Mon, Jan 12, 2026 at 08:11:50PM +0100, David Hildenbrand (Red Hat) wrote: > On 1/12/26 15:58, Mostafa Saleh wrote: > > On Mon, Jan 12, 2026 at 1:52 PM Jason Gunthorpe wrote: > > > > > > On Mon, Jan 12, 2026 at 01:43:41PM +0000, Mostafa Saleh wrote: > > > > But I don’t see why not. from the documentation: > > > > /** > > > > * pfn_valid - check if there is a valid memory map entry for a PFN > > > > * @pfn: the page frame number to check > > > > * > > > > * Check if there is a valid memory map entry aka struct page for the @pfn. > > > > * Note, that availability of the memory map entry does not imply that > > > > * there is actual usable memory at that @pfn. The struct page may > > > > * represent a hole or an unusable page frame. > > > > … > > > > > > > > That means that struct page exists, which is all what we need here. > > > > > > A struct page that has never been initialize shouldn't ever be read. I > > > don't know how that relates to page_ext, but are you really sure that > > > is all you need? > > > > > > > AFAIU, if pfn_valid() returns true, it means the struct page is valid, > > and lookup_page_ext() will check that a valid page_ext exists for this > > entry. > > Not always. Offline memory blocks have a memory map but no page ext. We > allocate the page ext at memory onlining time. > > Also, I'm not sure about ZONE_DEVICE memory, very likely we never allocate a > page_ext for them? > > I'd assume both cases are not relevant for your use case, though. They are in the sense that those PFNs can get into these routines and still need to be handled in some appropriate way.. Jason