linux-kernel - Re: [PATCH v3 10/10] iommu: account IOMMU allocated memory

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240222002152.GG13491@ziepe.ca>
Date: Wed, 21 Feb 2024 20:21:52 -0400
From: Jason Gunthorpe <jgg@...pe.ca>
To: Pasha Tatashin <pasha.tatashin@...een.com>
Cc: Will Deacon <will@...nel.org>, akpm@...ux-foundation.org,
	alim.akhtar@...sung.com, alyssa@...enzweig.io,
	asahi@...ts.linux.dev, baolu.lu@...ux.intel.com,
	bhelgaas@...gle.com, cgroups@...r.kernel.org, corbet@....net,
	david@...hat.com, dwmw2@...radead.org, hannes@...xchg.org,
	heiko@...ech.de, iommu@...ts.linux.dev, jernej.skrabec@...il.com,
	jonathanh@...dia.com, joro@...tes.org,
	krzysztof.kozlowski@...aro.org, linux-doc@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org, linux-rockchip@...ts.infradead.org,
	linux-samsung-soc@...r.kernel.org, linux-sunxi@...ts.linux.dev,
	linux-tegra@...r.kernel.org, lizefan.x@...edance.com,
	marcan@...can.st, mhiramat@...nel.org, m.szyprowski@...sung.com,
	paulmck@...nel.org, rdunlap@...radead.org, robin.murphy@....com,
	samuel@...lland.org, suravee.suthikulpanit@....com,
	sven@...npeter.dev, thierry.reding@...il.com, tj@...nel.org,
	tomas.mudrunka@...il.com, vdumpa@...dia.com, wens@...e.org,
	yu-cheng.yu@...el.com, rientjes@...gle.com
Subject: Re: [PATCH v3 10/10] iommu: account IOMMU allocated memory

On Fri, Feb 16, 2024 at 02:48:00PM -0500, Pasha Tatashin wrote:
> On Fri, Feb 16, 2024 at 12:58 PM Will Deacon <will@...nel.org> wrote:
> >
> > On Tue, Feb 13, 2024 at 10:44:53AM -0500, Pasha Tatashin wrote:
> > > > >  SecPageTables
> > > > > -              Memory consumed by secondary page tables, this currently
> > > > > -              currently includes KVM mmu allocations on x86 and arm64.
> > > > > +              Memory consumed by secondary page tables, this currently includes
> > > > > +              KVM mmu and IOMMU allocations on x86 and arm64.
> > >
> > > Hi Will,
> > >
> > > > While I can see the value in this for IOMMU mappings managed by VFIO,
> > > > doesn't this end up conflating that with the normal case of DMA domains?
> > > > For systems that e.g. rely on an IOMMU for functional host DMA, it seems
> > > > wrong to subject that to accounting constraints.
> > >
> > > The accounting constraints are only applicable when GFP_KERNEL_ACCOUNT
> > > is passed to the iommu mapping functions. We do that from the vfio,
> > > iommufd, and vhost. Without this flag, the memory useage is reported
> > > in /proc/meminfo as part of  SecPageTables field, but not constrained
> > > in cgroup.
> >
> > Thanks, Pasha, that explanation makes sense. I still find it bizarre to
> > include IOMMU allocations from the DMA API in SecPageTables though, and
> > I worry that it will confuse people who are using that metric as a way
> > to get a feeling for how much memory is being used by KVM's secondary
> > page-tables. As an extreme example, having a non-zero SecPageTables count
> > without KVM even compiled in is pretty bizarre.
> 
> I agree; I also prefer a new field in /proc/meminfo named
> 'IOMMUPageTables'. This is what I proposed at LPC, but I was asked to
> reuse the existing 'SecPageTables' field instead. The rationale was
> that 'secondary' implies not only KVM page tables, but any other
> non-regular page tables.

Right, SeanC mentioned that the purpose of SecPageTables was to
capture all non-mm page table radix allocations.

> I would appreciate the opinion of IOMMU maintainers on this: is it
> preferable to bundle the information with 'SecPageTables' or maintain
> a separate field?

I think you should keep them together. I don't think we should be
introducing new counters, in general.

Detailed memory profile should come from some kind of more dynamic and
universal scheme. Hopefully that other giant thread about profiling
will reach some conclusion.

Jason