linux-kernel - Re: [PATCH] zsmalloc: use actual object size to detect spans

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: <3tiwggkz53gkl3ysemobzny5ymvjzn7ssfxbevae6ptpfbdzph@riv2id277ctm>
Date: Wed, 7 Jan 2026 14:38:36 +0900
From: Sergey Senozhatsky <senozhatsky@...omium.org>
To: Yosry Ahmed <yosry.ahmed@...ux.dev>
Cc: Sergey Senozhatsky <senozhatsky@...omium.org>, 
	Andrew Morton <akpm@...ux-foundation.org>, Nhat Pham <nphamcs@...il.com>, Minchan Kim <minchan@...nel.org>, 
	Johannes Weiner <hannes@...xchg.org>, Brian Geffon <bgeffon@...gle.com>, linux-kernel@...r.kernel.org, 
	linux-mm@...ck.org
Subject: Re: [PATCH] zsmalloc: use actual object size to detect spans

On (26/01/07 05:22), Yosry Ahmed wrote:
> On Wed, Jan 07, 2026 at 12:03:37PM +0900, Sergey Senozhatsky wrote:
> > On (26/01/07 02:10), Yosry Ahmed wrote:
> > > I think the changes need to be shuffled around to avoid this, or just
> > > have a combined patch, which would be less pretty.
> > 
> > Dunno.  Do we want to completely separate HugePage handling
> > and make it a fast path?  Then it seems things begin to work.
> 
> HugePage should always be PAGE_SIZE, so never spans two pages, right?

Right

  if (unlikely(class->objs_per_zspage == 1 && class->pages_per_zspage == 1))
      SetZsHugePage(zspage);

> I like separating the logic because it's cleaner, but I want us to
> understand the problem first (see my other reply) instead of just
> papering over it.

Sure.

> > diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
> > index cb449acc8809..9b067853b6c2 100644
> > --- a/mm/zsmalloc.c
> > +++ b/mm/zsmalloc.c
> > @@ -1077,6 +1077,7 @@ void *zs_obj_read_begin(struct zs_pool *pool, unsigned long handle,
> >         unsigned long obj, off;
> >         unsigned int obj_idx;
> >         struct size_class *class;
> > +       size_t sizes[2];
> >         void *addr;
> >  
> >         /* Guarantee we can get zspage from handle safely */
> > @@ -1089,35 +1090,27 @@ void *zs_obj_read_begin(struct zs_pool *pool, unsigned long handle,
> >         zspage_read_lock(zspage);
> >         read_unlock(&pool->lock);
> >  
> > +       /* Fast path for huge size class */
> > +       if (ZsHugePage(zspage))
> > +               return kmap_local_zpdesc(zpdesc);
> 
> Can we WARN here if somehow the HugePage is spanning two pages?

I can add a WARN, but that really cannot happen.  We always allocate just
one physical page per zspage for such size classes.