From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8B57CC3ABBC for ; Tue, 6 May 2025 04:26:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 244566B000A; Tue, 6 May 2025 00:26:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1CFD96B0082; Tue, 6 May 2025 00:26:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 048CC6B0085; Tue, 6 May 2025 00:26:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id D76F26B000A for ; Tue, 6 May 2025 00:26:05 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id A7448CBCAF for ; Tue, 6 May 2025 04:26:06 +0000 (UTC) X-FDA: 83411195532.19.BD686F5 Received: from mail-pf1-f177.google.com (mail-pf1-f177.google.com [209.85.210.177]) by imf04.hostedemail.com (Postfix) with ESMTP id AC6BA40003 for ; Tue, 6 May 2025 04:26:04 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=O4SX72xR; spf=pass (imf04.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.210.177 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1746505564; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=lpTvVcHQ5NB5y7+VuyI90vpjgAMkQ7kpY0hgN5edgAQ=; b=X5oMmNqDR1rL/ZxsgW7zuFvp5wQj1VjzpQ2cvalAM2oCgpaAmhlG+sO2SaaoyAJgY8a/YT XNvalmWxmwmrktroUz0oMiWBftQfXl4K1sFtgM3jgqauK6Lwjku+vftD9BZbj934Dh8jQf W1tDYaVjMoGzHEzdE11ZsyXxFy93WA0= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=O4SX72xR; spf=pass (imf04.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.210.177 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1746505564; a=rsa-sha256; cv=none; b=mkU9YVomuPPBg8Z/PLUjaPtE86QcCi6O2ofhd8jHJH2pgbgEma91g43mue8EkC93ERqeqn rQ+qPJX7JS18oT7jrr50yUCF0t+Z62379GxlpaH/8EyryZ3fDo18QMVhvd+QbhmOOTEDLu 2GlcXubVm2nIndSWi1euCjLNHx0ZiaQ= Received: by mail-pf1-f177.google.com with SMTP id d2e1a72fcca58-736c1138ae5so5245071b3a.3 for ; Mon, 05 May 2025 21:26:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1746505563; x=1747110363; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=lpTvVcHQ5NB5y7+VuyI90vpjgAMkQ7kpY0hgN5edgAQ=; b=O4SX72xRoy2VNwSnz7eKN2AW8pVGfMeF8ZwaC1qTmaeS96mjRkTHTNyCTtJEPPTLMz 46U54P6rDg7uZxmNnD+csQ8wJBS0eHUu0xEbsz38FmeD51az746e25/Ovep7YKEui1SD POblPVPeOSC2bBW/AWjupUKA/paZMtu8sIzwM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746505563; x=1747110363; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=lpTvVcHQ5NB5y7+VuyI90vpjgAMkQ7kpY0hgN5edgAQ=; b=JtPIPvJJ9pMMwPTpC0LNVl0zyf3zWLpXnhok/erd4MEZYu0GLz3ErKWS5PxgqF0L6y EijHfMSYGuv0rPC74wFl62/qwpj8hsIU6tOG26a0bz0sVUm0JSBO8pan1iHH7989XCvZ 2kBcqqxGvEa5udBwx7/tKvbXDS5G4GN6aN05aju69+FxaNhncNqDGuYUN2nbRuBxJ0MG 0sSFTi2kXaXRjkdBp79kp8XGwP3d9I2Y65wswHneC+q7jl7z/lEy1Bp6krcBB7He+BhZ m6cLPf/riL5z6p3sk4xQQcRo6A+HzBZDYvTJ+3k0wDVy2rzUMaJtUN9vhXXeEKly77pi kV9w== X-Forwarded-Encrypted: i=1; AJvYcCXAWXTY1BqEdtYWKArSYI0f7W53tChJnUwoeThPgv/Gf3GTQZF/3QS6QOhXHSvVp654Ja6mMQUZ8g==@kvack.org X-Gm-Message-State: AOJu0YxYb0lkGFq0oQ4UL+aRILa6yUJhKGnRlZVpmGc8OCVUJ7AV7vm9 MOKixL6O/CrAAfvuU5jXfL5SJDD9zrx/p2KZDtCo/A6q7gH8r58MrQfLPLy+gA== X-Gm-Gg: ASbGncuMyQR2LDa/FDXDyJqqDNnZgqxKHoos2jl8/iDovFYDshVg8Ckte1S+IAetCYY Z1courBxYMM4PqbULwUVaJBJsyFikxMS9fVDUWD3mHkcPCzCxaWS3PuK9vcwapDFZ4q3VJVIuM2 uWgRDjt9Z0yg4XYb4n4uSVhdkenBD38arx93qoqd0uHYogNzFDddgtMdMl6aP/+MPWqt0c8uvLq VkOIQhhG+N58xG6OQN6HXkuGRrzeE1rOn55jSPZ+Daz4iCOGj4PQdkDaS8FgUuCOoCpT3HjrvMz 0UvbeMGGJFGXdDzhDKIFF46hq+NgCRzvitlUBI9JCNimWcxZSTiLEg== X-Google-Smtp-Source: AGHT+IH2lUDpOcji/4HaHFx3QdH6baMYj7NqZym6Fql1fkgTO/Dhci0Df2ouxUuviW5c8PoLDQ9qGQ== X-Received: by 2002:a05:6a00:8d82:b0:736:34a2:8a18 with SMTP id d2e1a72fcca58-74091acd3f4mr2575582b3a.24.1746505563516; Mon, 05 May 2025 21:26:03 -0700 (PDT) Received: from google.com ([2401:fa00:8f:203:761:97e0:917d:ad1e]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-74059020de2sm8063478b3a.103.2025.05.05.21.26.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 05 May 2025 21:26:03 -0700 (PDT) Date: Tue, 6 May 2025 13:25:58 +0900 From: Sergey Senozhatsky To: Andrew Morton Cc: Minchan Kim , Yosry Ahmed , Vitaly Wool , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Igor Belousov , stable@vger.kernel.org, Sergey Senozhatsky Subject: Re: [PATCH] zsmalloc: don't underflow size calculation in zs_obj_write() Message-ID: References: <20250504110650.2783619-1-senozhatsky@chromium.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250504110650.2783619-1-senozhatsky@chromium.org> X-Stat-Signature: 7mi1prj4tm9g67jsq6d8rfoyfte6hzqq X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: AC6BA40003 X-Rspam-User: X-HE-Tag: 1746505564-132930 X-HE-Meta: U2FsdGVkX1/hg4FDQ2kk7SfBwbwLvj1EedCAaXF5KAmkbMU3/DaJrrG7pP0OpMxqB7sOdpdiZStTrZNhxl292zJzkKcb5J/zj7dm5QrKuM6LcWh9fNHc9Ww3CWEFXRS7SXB85xoKCe29vMcF4fcae2SspyZ8YzsmfRfNQ4/TPu8R7n8PZSeCNobif+5BEE3ynQc/yQR9EVkZS5iXpT7LS6Wic2eLAp8Xav7sCUJ3vgtc4aOLIugvU74IfnSm69Bwkqj1bGWGYpTQK5CfqlKt2zjsa4tubLjSZsJhyTA5BZ7FHi27F/s+eCkcRUrBwR9qQwT1coh2dEnC89fsUQo5/q/3U+J7vZfOVSfry4nXBOaAM0MavVMp/jmw4umub175C8CP2yQHuh7vzIjRCXWYx9+B+q/JsUyTd7UvibA+Wtud7dnVlfFWTzl/jfs/I8BlUsuIMGAAMtDRPX+HG4ACj2g4+8uv2RufV4m335TmEeOKWd1q2DBUiFtoKkhhe1koV61el/etg6vJYXU/ft7+RYHWh7er7bhzZXZKucMyZILVjvS2WcV+suB5uwknm3HBbAimorAvHCxcnclgiRkQDY/i/ac/FojkEutI/75ya7/nySXau9UgByJDrPttQDRzjVU5daWwgNsW6TcTV/vgtGa6htjofK0MejwvbQyjbqbLCt1J7EjI5MDzi2I0aUfwPAT8oQGCnYhH8ag8Y1Ws1ZL/U1fjTps7Mhxv0MT09dup90GWcr1zcpIhVpKx8LwxmG97/BcY9PD2qyBiJ49s4yasK2vuYHaJ6fZrbTnkFMyH8fgBhFyj5zXiYKjdmthuXVavIunYxJeYWSZovK2VnrS+0FiytrWB3kBHRWueW2RMaoxDebGO52D9LlnSWyo4sgvbI2JIeI56ukoFmTfS9XhA5mhxHdAgDQk9fDs+RN6/mcFIQ1ioUxrGmet6tqDrvGk5yEyAr5fikOnZgWw mqPcAB9V J2KbOXpo5LX5CTjRHYjNoQL9j5ghzGgpU3hSxdgnqbmJyxAYya//IFvYxjlNkRMzzFFFmxdQ88w6GCYEmDxAPrd+oHJqPZ8yRCrAWze1fRfkuzck32tM6GJljJT5wLb9i7Rwbz/0MsIT0g5X6E+u1/FAz1/oxS9DChrtIQyUXt/qAAnE/JrQtM45+Sacb55otmbOqpOBp9iPnDA9iKqHMUC/EWD39Jd1wJmgOMflVwJl5KtUYxbOubY/KgIggvty69m6llclJCvxqbZup+VEDKeH+HZgO8pDXxovRHDOJ2SHcUkDp0KtxaM5xlTi4OWTntiZ6TQ/vJmGuGYH2x0J/CzFZXnHJPX4jt9ztPJdwRle7RyRlTrTIy2XUu7Wq4p5DrQtsiDxi954Qb6vFP/XNDy1wiQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: 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")