From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f181.google.com (mail-qt1-f181.google.com [209.85.160.181]) (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 6CD5B387583 for ; Mon, 12 Jan 2026 18:27:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.181 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768242445; cv=none; b=XF9s+kp4RZT3UM3TL/XMouQox2PS5w20dJsY+4j8JbY5qgza9nO5JSabUSu71J3u16R4WvadluUfT62lV7NQKFo4hTZye1KiEn0v7JycMQHaOU19Js8n8kZH97aH9c/0IzZOvfBuagAEShcx5lgP48pGFmaEbnkKRezsQJyTDxU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768242445; c=relaxed/simple; bh=shf+2pFJKpTQXDUXGMMTyC3s2OFfrjtsyGwPASB1HGE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=e/wTLW0VArqmm+lv1iXoOvOq8CE9H32Ug/GZ+QkuRChi7tBC/x4b60zcav4SbRVFo9Q2ixIVG3YT0mmejfT8kzPoDBVabkWDWFfzfV6rH2rphGW7/ohNFK+PlwfHpFFu/90duEztjwB/b/dIqfH8i9LqSLAqEXdWyGFnif/O2YQ= 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=UR4BHGHo; arc=none smtp.client-ip=209.85.160.181 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="UR4BHGHo" Received: by mail-qt1-f181.google.com with SMTP id d75a77b69052e-4eda26a04bfso81648661cf.2 for ; Mon, 12 Jan 2026 10:27:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1768242443; x=1768847243; 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=5cR4YX7Hi9OUrcU/fLtOMjymyJE7wlwEn/EL+XWyumw=; b=UR4BHGHobLLbEf1L5CwXd3u9Ac9NF7LzZmzRN07pOBF/oQXaoClGkoVxs51ApijxcV 5jTkh700IsMFMBnF82WujaUPliQF/Q3vPWd0v2HX49eTirmEiXndwc4kdpvGOVeXxJYY fmWSpbK+RDTOzP6dvIWNiP3VlmXhDtZBmcrlZSU9+BstgwKiBzZs64Fe2wSUiG0+zDK5 jlsV8Ly6qxS59jNKVmVm/pF8/25s3ktDJ+PqXImGzVfj5VvefEx92OK9A3APV0JoZv8E n1yA6u+0pEgveV3rGM5ryj2K/vQUwySlwQyj5gAjpFyJsHzuKoggsdS4/Fc4n8NVOrIQ IWWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768242443; x=1768847243; 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=5cR4YX7Hi9OUrcU/fLtOMjymyJE7wlwEn/EL+XWyumw=; b=GHc9KpQ1o62y0xuPbp7/Yde3LKW/M1XO5cse7vz4woJ+Eb0LljeSUhjD18BvCN1N/3 gqB+yJP2p8y8UXtOp/FGOANGQXSDZIqY2qdskNL03EzWdBEnot7slvddpM2IFl3PbHv2 hbdh1Y3C8VETJYWNXFE1We26Jhxy/3hiR8BwNfHOq40vpfTSELaO7JhGioVvAKmJeT7K 0Px/KCjgS2gtV7QPVwHvWXUgdnmEsU4rdcXMxaTX3+vdBTDh8PV+pD0PfbFEQQs1c/Ib 0c+CugWdSLIzg0Y2fbXvPvqEcgHAXIcE9MvnmZlZVMCxGh8ZGrZFjDT8LBnP8UX2mLoM 1/2Q== X-Forwarded-Encrypted: i=1; AJvYcCV9B/JMle9yOCY6Gi5ssVU0tielNuEZIO1z98qZbqpmiZ7/y5dmNpP6W5SusHvH0wpRv7C2PBnDWzWSoI0=@vger.kernel.org X-Gm-Message-State: AOJu0YxBhAVav96XO0MKsoH8f5RTHVG9MtwVuIJJKIZ5NNZiDCLdM7v5 9EsqejKmKLhy0KGNvvCeirh+Kzp75V/TMO0a80G5WQGPMzLVMvTz6KW4DmzGunId7Yo= X-Gm-Gg: AY/fxX6CbgVHpaaYP3vfc4pxkghdDftbzMd7r1MgdfQVDs4EWEW5ED/WKX/5IWHCNoB DNgPL0LopBVoPv+cvhm/wu14Lcw0q0qcEJ0l+9nBBbsiOnphkU2q+N+HRcg5RwXL+Ar0FhGuwvo 3KJtQkG2uUVjkXnXSfNAKexWg5BRLNobjhrH4Nt0oWy+sdPwk09/w2er44qVulfuvVmxkDMgUqG PKcPg6cqgeqjYbjrIAGO/yR6Z9r5KfuO2cpzGBd0bAj63Mz90iI0fYganHnPMe2mm0Uur3EhQWW RsaO4aTqNiZMsIWhYrgIaWBE1MgnanQSMkp9dUxH/5Z/6tURbNqtI0BSSRo0mc1hPjcu0y3Ul6+ iJnPED017sgYT+9I4IBQR+Ak0B+nfAh2EQtsmXa8yA4KLVxSiIRqWL1RFbgNyK9vGM8+orSE4SR eLnfx/Ll9pw8Axqea8j75a+hYj7oNXNei1MeCLk2PowT5yZUZEWWSDbfXjmUPd5PQ5krE= X-Google-Smtp-Source: AGHT+IGVmZqeY1PHuUlU2eCkElvqVfhg5QPHXOe+taJKVCxnMmnVYd9cOiuxymw5goLJl6+Yj9TZrw== X-Received: by 2002:ac8:5f8d:0:b0:4ff:c680:1076 with SMTP id d75a77b69052e-4ffc6801d70mr196421351cf.7.1768242443368; Mon, 12 Jan 2026 10:27:23 -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-4ffa8e6ce5asm130263131cf.33.2026.01.12.10.27.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Jan 2026 10:27:22 -0800 (PST) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1vfMdO-00000003Sgx-1Vjy; Mon, 12 Jan 2026 14:27:22 -0400 Date: Mon, 12 Jan 2026 14:27:22 -0400 From: Jason Gunthorpe To: Mostafa Saleh Cc: 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, david@redhat.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: <20260112182722.GJ745888@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> 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: On Mon, Jan 12, 2026 at 02:58:47PM +0000, 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. > So, what is missing is the NULL check for the page_ext returned, as it > can be NULL even if pfn_valid() was true. > > But I can't see why we shouldn't use pfn_valid() at all in that path. > I don't like the approach of using the prot to check that, as the > driver can be buggy which is what the santizer is defending against. > If we find some CONFIGs conflicting with it, we can just express that > in Kconfig and disable the santaizer in that case. That's a fair point. How about adding a page_ext_from_phys() kind of function that could use pfn_valid internally and has documented semantics for what it even does for "holes" in the page map? I'd be happier to see such a well defined API than randomly adding pfn_valid() and phys_to_page() when we are trying hard to not have those things in these paths. > > That's sure looks sketchy to me.. Eg if CONFIG_WANT_PAGE_VIRTUAL is > > set and you try to feed a MMIO through through that kmap() it will > > explode. > > > > KVM can argue that it doesn't work with CONFIG_WANT_PAGE_VIRTUAL but > > iommu cannot. > > WANT_PAGE_VIRTUAL seems possible in loongarch which supports KVM. Yikes, maybe that configuration doesn't run KVM? Jason