linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Sergey Senozhatsky <senozhatsky@chromium.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Minchan Kim <minchan@kernel.org>,
	Yosry Ahmed <yosry.ahmed@linux.dev>,
	 Vitaly Wool <vitaly.wool@konsulko.se>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	 Igor Belousov <igor.b@beldev.am>,
	stable@vger.kernel.org,
	 Sergey Senozhatsky <senozhatsky@chromium.org>
Subject: Re: [PATCH] zsmalloc: don't underflow size calculation in zs_obj_write()
Date: Tue, 6 May 2025 13:25:58 +0900	[thread overview]
Message-ID: <rp5x24bqoaiopfnbjee2f3n7nrg4vh6mt2j4ewutjj42n6dmn7@exl7zdf7pvwx> (raw)
In-Reply-To: <20250504110650.2783619-1-senozhatsky@chromium.org>

On (25/05/04 20:00), Sergey Senozhatsky wrote:
> Do not mix class->size and object size during offsets/sizes
> calculation in zs_obj_write().  Size classes can merge into
> clusters, based on objects-per-zspage and pages-per-zspage
> characteristics, so some size classes can store objects
> smaller than class->size.  This becomes problematic when
> object size is much smaller than class->size - we can determine
> that object spans two physical pages, because we use a larger
> class->size for this, while the actual object is much smaller
> and fits one physical page, so there is nothing to write to
> the second page and memcpy() size calculation underflows.
> 
> We always know the exact size in bytes of the object
> that we are about to write (store), so use it instead of
> class->size.

I think it's

Fixes: 44f76413496e ("zsmalloc: introduce new object mapping API")


  parent reply	other threads:[~2025-05-06  4:26 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-04 11:00 Sergey Senozhatsky
2025-05-05  9:05 ` Igor Belousov
2025-05-06  4:25 ` Sergey Senozhatsky [this message]
2025-05-06 13:56 ` Johannes Weiner
2025-05-07  5:40   ` Sergey Senozhatsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=rp5x24bqoaiopfnbjee2f3n7nrg4vh6mt2j4ewutjj42n6dmn7@exl7zdf7pvwx \
    --to=senozhatsky@chromium.org \
    --cc=akpm@linux-foundation.org \
    --cc=igor.b@beldev.am \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=minchan@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=vitaly.wool@konsulko.se \
    --cc=yosry.ahmed@linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox