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

[Sergey Senozhatsky <senozhatsky@chromium.org>]

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.