linux-kernel - Re: [PATCH v2 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <b5b98667-06aa-8330-10f7-8dba3ac0566a@google.com>
Date: Sun, 24 Dec 2023 13:44:03 -0800 (PST)
From: David Rientjes <rientjes@...gle.com>
To: Pasha Tatashin <pasha.tatashin@...een.com>
cc: 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, will@...nel.org, yu-cheng.yu@...el.com
Subject: Re: [PATCH v2 10/10] iommu: account IOMMU allocated memory

On Fri, 15 Dec 2023, Pasha Tatashin wrote:

> > > diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst
> > > index 3f85254f3cef..e004e05a7cde 100644
> > > --- a/Documentation/admin-guide/cgroup-v2.rst
> > > +++ b/Documentation/admin-guide/cgroup-v2.rst
> > > @@ -1418,7 +1418,7 @@ PAGE_SIZE multiple when read back.
> > >         sec_pagetables
> > >               Amount of memory allocated for secondary page tables,
> > >               this currently includes KVM mmu allocations on x86
> > > -             and arm64.
> > > +             and arm64 and IOMMU page tables.
> >
> > Hmm, if existing users are parsing this field and alerting when it exceeds
> > an expected value (a cloud provider, let's say), is it safe to add in a
> > whole new set of page tables?
> >
> > I understand the documentation allows for it, but I think potential impact
> > on userspace would be more interesting.
> 
> Hi David,
> 
> This is something that was discussed at LPC'23. I also was proposing a
> separate counter for iommu page tables, but it was noted that we
> specifically have sec_pagetables called this way to include all non
> regular CPU page tables, and we should therefore account for them
> together.
> 
> Please also see this discussion from the previous version of this patch series:
> https://lore.kernel.org/all/CAJD7tkb1FqTqwONrp2nphBDkEamQtPCOFm0208H3tp0Gq2OLMQ@mail.gmail.com/
> 

Gotcha, I think that makes sense.  When sec_pagetables was introduced, I 
can understand the need to account for non-primary pagetables separately 
because of the long-standing behavior.  In that sense, sec_pagetables 
becomes a dumping ground for "all other page tables" which IOMMU would 
naturally include.

So this looks good to me.

Acked-by: David Rientjes <rientjes@...gle.com>