From patchwork Mon Sep 9 01:29:53 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Feng Tang X-Patchwork-Id: 13795728 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 19BBFECE577 for ; Mon, 9 Sep 2024 01:30:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 51BCC6B00F9; Sun, 8 Sep 2024 21:30:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4CBBB6B00FA; Sun, 8 Sep 2024 21:30:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 393C86B00FB; Sun, 8 Sep 2024 21:30:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 15D1E6B00F9 for ; Sun, 8 Sep 2024 21:30:08 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 77FDBC0993 for ; Mon, 9 Sep 2024 01:30:07 +0000 (UTC) X-FDA: 82543468854.26.703CC2D Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.15]) by imf30.hostedemail.com (Postfix) with ESMTP id C46D780011 for ; Mon, 9 Sep 2024 01:30:04 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b="J4zH6Ck/"; spf=pass (imf30.hostedemail.com: domain of feng.tang@intel.com designates 198.175.65.15 as permitted sender) smtp.mailfrom=feng.tang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1725845271; 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-transfer-encoding:content-transfer-encoding: in-reply-to:references:dkim-signature; bh=jKEXCRS/7Hh33W61G56jRGbQA05xRUYbsN8ZemhdwTI=; b=D4mvRLsNhNCSNgLa5GYhmev4fpb7XEgEOnJBO8oOVfPhgugDJ4QyfeyNmbdeKHMbqp0kuZ wmMzl7IIZl8cS3tYxGw4/DL1sgA/PWyLTOiPi0gwzUfwPdows2wqXFRKNPLoDtJTFXy6uR g0hrNlVpBQtfaNPc6ljg62QPtMaf3e8= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b="J4zH6Ck/"; spf=pass (imf30.hostedemail.com: domain of feng.tang@intel.com designates 198.175.65.15 as permitted sender) smtp.mailfrom=feng.tang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725845271; a=rsa-sha256; cv=none; b=CgwqTqgTtN8W2vUKD9a2po3KjRPBVMdCy2J6lfSFeNAq9e6Qw0GbwhftmH69AoPtlHwLX9 yAYqkGsEPpnJzNlpwTs/k5/apFpj5EfJXo2d6antruDVImeGIQxCpHiE83d1Lw/kUwqLbC 35C7eMMX4VTqMfT5PIldfCfpmWxX6Ao= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1725845405; x=1757381405; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=kaFwsBPUt5dOciyztfnnE0RsS7JQQKck/kQLtcflZiA=; b=J4zH6Ck/Urvo4qHajrOenpixzVdBhQjNiz1/Tgx1xBSaDzwsUejIaTio VTerHGRpCSx5/hn/JGmbxPiDqoXtS/+cgb0uDF/OZDQVsI3MBznDSoMID MMKhL5v5gTmL0qJnitnEZuiMKulmNC6sroCJe/POgAc8pLSebQ9/JzaKo TOLZksucMhM3DAka50uUHQ4pHY53RUllDtUrRgLcPEc1EPskdRplh9hEx k8DnZuz8yIIsXyaZpJJhAtY2JYK4wJWTIl/gCko0QfAoovgtxhbWHGMJo 2q4yju6wQ6AJDOToQ0JduOtE7f3zwtaZJmRmLb4zVfwCBMrcPzgxTX6LN g==; X-CSE-ConnectionGUID: o/EW+jNBTx2QiJfl8k2nXQ== X-CSE-MsgGUID: 4VMhmrFJQjS45M72jr/BPA== X-IronPort-AV: E=McAfee;i="6700,10204,11189"; a="28258093" X-IronPort-AV: E=Sophos;i="6.10,213,1719903600"; d="scan'208";a="28258093" Received: from orviesa009.jf.intel.com ([10.64.159.149]) by orvoesa107.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Sep 2024 18:30:03 -0700 X-CSE-ConnectionGUID: SV4/OxYHS6GhuvQL9jNidA== X-CSE-MsgGUID: WgxXmmB/SiuN1T0gsJyu7w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.10,213,1719903600"; d="scan'208";a="66486421" Received: from feng-clx.sh.intel.com ([10.239.159.50]) by orviesa009.jf.intel.com with ESMTP; 08 Sep 2024 18:29:59 -0700 From: Feng Tang To: Vlastimil Babka , Andrew Morton , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com>, Andrey Konovalov , Marco Elver , Shuah Khan , David Gow , Danilo Krummrich Cc: linux-mm@kvack.org, kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org, Feng Tang Subject: [PATCH 0/5] mm/slub: Improve data handling of krealloc() when orig_size is enabled Date: Mon, 9 Sep 2024 09:29:53 +0800 Message-Id: <20240909012958.913438-1-feng.tang@intel.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: C46D780011 X-Stat-Signature: xxyoxqksa6kzwcpt8n76ou36wgzhunq8 X-Rspam-User: X-HE-Tag: 1725845404-413 X-HE-Meta: U2FsdGVkX18h8Q8vT9cBlkgx4cukkjxsXPBcoL6WqX6UkPdyYfnE0H75PyMhwfE1JgF2gRSyC7uio8pqY7RgoZyZ6W5wNLUkwUXkCghkh0636BRXosuDsts7PkbNnhMa9azG9svbjIUDh/CqkTZXCJ5wyOXByOtzjdfD+F+xT0aqmWzTaVze7BZJ+JKFIwnYXGWNULyc6sy0WjXzhTUsDTqlApNXLTIXZb1QhTt/iJUCIKywLi/cGi6l+gh3Lbl9sC/AlCnw2K+MN/9UF4ifxt0wlENzM81qNJc2XkgJqTZ2bbLeVVUXj6yVAGmpr1WtiuMgwEHkzttAPnHp0nsvKj3POC2WYRwuIgkiF2JdKYjJmZz+B6To/BlrRCQ9OFpmt9Hz5Gv2GvQQU+iGIwXPaeAjBEbBS0LdIHdFyUhhL3JtmsLjDTyDq3D9A6BpD/oZ1CbiSB92of/q+ROAz/UMODA+CRuDCF3qWYhBrMt6mnZSPerT6BbpJaRAhU9NHX0JLaPYx2Ah+0Sw/TfYBY2kwsaihCX6hJEbP4olxDtE4hJQseKZGZ6QwJwR/xNvaJTtcErzuVlgdwlAbimLX2jtqWE7QUBQLPTaQ+7g0l5dEKDO9yVkmIkKjJT7awH5HqwE6bTMsJtaZZHav2SOTgOJieqU2JAikxIobAvBn/foW5xH1vt41p9UjrcQnbZ3jpsAfxXVY9odsrV+rbvMQeHcpkyJPv8ROa8gYgfmDB8vQWrI+XADVnrh7pGC/RM9V2dc0EGaS4KnEtO4Vo3eaBhvk3beiGdQNBEc0YBlyxwqr/z2Ra/NrcymgAJZPROe44e7O2DjAYUCdTRGp1NZKJlXXZWHYwn10tSl1udshsyDQGTOJcLqTNqvuw+MJxa39kK6ttPspGmVQWCSepnhSaIHNwl/lJMsNZPxeIIuoEpB1Wm+7uU+0I103vy2X2xmsjLR+0IeS0QQKOjZRUmiO8C 8+LbhDfq zC3pzx73QTCJZWtadIUSp0eTXq3z0BjEONge4ML2Djs/gZBwyCtx3kon703GzhN+huYUVX5Ywz9wf0bniMnHzjkujTLxDSja2z03CHTO/WKvbBg1xDXEDXHZpVi2oISNMdOpWEt6doGiIaBBP0dzw2krBlR4U8G9eFldquv1m/wOzk3H1RWmd4mScXEOG4OrcSgxMbZmp2jdjpKHuQ/gBIeRcZHSDgTK0pc9LR1OI2uS0mtO3tgcUR82udLUejEKAWwr3IxevrG3w7AvV/kOmBKtFXR/358rOoR1hZ1eJxI/dNeLpdPZC1kZgJ70JbNSiBDFQeSO3HhhTU7yJlRXR3MJFEw== 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: Danilo Krummrich's patch [1] raised one problem about krealloc() that its caller doesn't know what's the actual request size, say the object is 64 bytes kmalloc one, but the original caller may only requested 48 bytes. And when krealloc() shrinks or grows in the same object, or allocate a new bigger object, it lacks this 'original size' information to do accurate data preserving or zeroing (when __GFP_ZERO is set). And when some slub debug option is enabled, kmalloc caches do have this 'orig_size' feature. As suggested by Vlastimil, utilize it to do more accurate data handling, as well as enforce the kmalloc-redzone sanity check. To make the 'orig_size' accurate, we adjust some kasan/slub meta data handling. Also add a slub kunit test case for krealloc(). This patchset has dependency over patches in both -mm tree and -slab trees, so it is written based on linux-next tree '20240905' version. [1]. https://lore.kernel.org/lkml/20240812223707.32049-1-dakr@kernel.org/ Thanks, Feng Feng Tang (5): mm/kasan: Don't store metadata inside kmalloc object when slub_debug_orig_size is on mm/slub: Consider kfence case for get_orig_size() mm/slub: Improve redzone check and zeroing for krealloc() kunit: kfence: Make KFENCE_TEST_REQUIRES macro available for all kunit case mm/slub, kunit: Add testcase for krealloc redzone and zeroing include/kunit/test.h | 6 ++ lib/slub_kunit.c | 46 +++++++++++++++ mm/kasan/generic.c | 5 +- mm/kfence/kfence_test.c | 9 +-- mm/slab.h | 6 ++ mm/slab_common.c | 84 --------------------------- mm/slub.c | 125 ++++++++++++++++++++++++++++++++++------ 7 files changed, 171 insertions(+), 110 deletions(-)