linux-kernel - Re: [PATCH v8 5/8] mm: zswap: Modify zswap_stored_pages to be atomic_long

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: <CAJD7tkZJkeoTBfs7aEphR_cg728cB0o9+_Uwq=w_=iCzCc1=4g@mail.gmail.com>
Date: Sat, 28 Sep 2024 01:12:04 -0700
From: Yosry Ahmed <yosryahmed@...gle.com>
To: Matthew Wilcox <willy@...radead.org>
Cc: Kanchana P Sridhar <kanchana.p.sridhar@...el.com>, linux-kernel@...r.kernel.org, 
	linux-mm@...ck.org, hannes@...xchg.org, nphamcs@...il.com, 
	chengming.zhou@...ux.dev, usamaarif642@...il.com, shakeel.butt@...ux.dev, 
	ryan.roberts@....com, ying.huang@...el.com, 21cnbao@...il.com, 
	akpm@...ux-foundation.org, nanhai.zou@...el.com, wajdi.k.feghali@...el.com, 
	vinodh.gopal@...el.com
Subject: Re: [PATCH v8 5/8] mm: zswap: Modify zswap_stored_pages to be atomic_long_t.

On Fri, Sep 27, 2024 at 9:51 PM Matthew Wilcox <willy@...radead.org> wrote:
>
> On Fri, Sep 27, 2024 at 07:57:49PM -0700, Yosry Ahmed wrote:
> > On Fri, Sep 27, 2024 at 7:16 PM Kanchana P Sridhar
> > <kanchana.p.sridhar@...el.com> wrote:
> > >
> > > For zswap_store() to support large folios, we need to be able to do
> > > a batch update of zswap_stored_pages upon successful store of all pages
> > > in the folio. For this, we need to add folio_nr_pages(), which returns
> > > a long, to zswap_stored_pages.
> >
> > Do we really need this? A lot of places in the kernel assign the
> > result of folio_nr_pages() to an int (thp_nr_pages(),
> > split_huge_pages_all(), etc). I don't think we need to worry about
> > folio_nr_pages() exceeding INT_MAX for a while.
>
> You'd be surprised.  Let's assume we add support for PUD-sized pages
> (personally I think this is too large to make sense, but some people can't
> be told).  On arm64, we can have a 64kB page size, so that's 13 bits per
> level for a total of 2^26 pages per PUD.  That feels uncomfortable close
> to 2^32 to me.
>
> Anywhere you've found that's using an int to store folio_nr_pages() is
> somewhere we should probably switch to long.

There are a lot of them: rmap.c, shmem.c, khugepaged.c, etc.

> And this, btw, is why I've
> moved from using an int to store folio_size() to using size_t.  A PMD is
> already 512MB (with a 64KB page size), and so a PUD will be 4TB.

Thanks for pointing this out. I assumed the presence of many places
using int to store folio_nr_pages() means that it's a general
assumption.

Also, if we think it's possible that a single folio size may approach
INT_MAX, then we are in bigger trouble for zswap_stored_pages, because
that's the total number of pages stored in zswap on the entire system.
That's much more likely to exceed INT_MAX than a single folio.

>
> thp_nr_pages() is not a good example.  I'll be happy when we kill it;
> we're actually almost there.

Yeah I can only see 2 callers.