From patchwork Mon Sep 9 01:29:54 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Feng Tang X-Patchwork-Id: 13795729 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 0FAEDCD4F4C for ; Mon, 9 Sep 2024 01:30:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8EDB96B00FA; Sun, 8 Sep 2024 21:30:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 89DB06B00FC; Sun, 8 Sep 2024 21:30:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 717D06B00FD; Sun, 8 Sep 2024 21:30:10 -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 4FAE16B00FA for ; Sun, 8 Sep 2024 21:30:10 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 129301C0653 for ; Mon, 9 Sep 2024 01:30:10 +0000 (UTC) X-FDA: 82543468980.01.0666E07 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.15]) by imf30.hostedemail.com (Postfix) with ESMTP id F103180002 for ; Mon, 9 Sep 2024 01:30:07 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=T2sx01ob; 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=1725845274; 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:in-reply-to:references:references:dkim-signature; bh=praePlo9gXwYoSdDC3+quBDxNg2mp+3vLJVC4CIDpoM=; b=G+pLpNmF05VjeNPpDZSF6zxWRad9DwbhKGtFR1JDtelkjdkoNOMMmNiLvrEnCLfVQQgn1f EkHQUxq8zxoa1Rf7eHC20TUTB1gnIsyW7cFi9k/KrmHG+yS9e9tAEFdEG51ghtS/EQtAUI 0l/7oq1R/mOUmTKrMGs1SyD9sfy609c= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=T2sx01ob; 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=1725845274; a=rsa-sha256; cv=none; b=nu9bMJDC7urhOAKuGJOi4UzY/26OObCQv5E5w2xPC0WvCqWDAcZQfb+RfP6fFPc5JtbH8y Q4EvGvuRP7n7nx27+Q0qKk9fMVIsqJ7RO6OMlZTefV+8Mpw6OuJAYMIc0YWOnPvsLsIeXm bhVwVrvlCvg3d+ZiNgQ1uaG7l+HoFyE= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1725845408; x=1757381408; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=pVsgqwZadHhdmsZUe9yKROnQBO6McnXZ8J3vApLU53I=; b=T2sx01obrcg6hn4YcJPB0+HLOSHNPzDxDRbu8GUa5zptODvli9Tp8q5o VXyTupaKHHxrFOBU9zJxE9Jfdcvs2CH76SsiUF/uSvRjgpyAQ5Tr/zE6S pXR6qkmjl2xDe7i0YT7CfJieK3G5Vtbg4SU1lnh9TcLamZREHiasEYFf3 1qmRcaR88nsPAy6rYpgdpH9XbVqbV0plNBwzUJG4xqYUbosKzntNkHj8X pW/Md9qD0fu/jgm0Gtn/Izaa3wRtEG0FBp+UVUq715ml0GMpTGLR5AGjp wm7Oedb1+vN9QOPu/I2V1RpxgXZdhrtKUna0XpNqklcobfPZPUd8kdNzX g==; X-CSE-ConnectionGUID: eKCpMuQRRUCHD5bNugubDw== X-CSE-MsgGUID: p081n97KSOeuC46ZrW4/IQ== X-IronPort-AV: E=McAfee;i="6700,10204,11189"; a="28258105" X-IronPort-AV: E=Sophos;i="6.10,213,1719903600"; d="scan'208";a="28258105" 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:07 -0700 X-CSE-ConnectionGUID: UowcQFlWTN6ZxGnlayNrVA== X-CSE-MsgGUID: NSxbVtALS32RTELxfc1T0A== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.10,213,1719903600"; d="scan'208";a="66486438" Received: from feng-clx.sh.intel.com ([10.239.159.50]) by orviesa009.jf.intel.com with ESMTP; 08 Sep 2024 18:30:03 -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 1/5] mm/kasan: Don't store metadata inside kmalloc object when slub_debug_orig_size is on Date: Mon, 9 Sep 2024 09:29:54 +0800 Message-Id: <20240909012958.913438-2-feng.tang@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240909012958.913438-1-feng.tang@intel.com> References: <20240909012958.913438-1-feng.tang@intel.com> MIME-Version: 1.0 X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: F103180002 X-Stat-Signature: jmiestm69ro1es6r9g5hq5zom7mf5mh7 X-Rspam-User: X-HE-Tag: 1725845407-324354 X-HE-Meta: U2FsdGVkX1/YICZlEr2gf7CWlrmw6v3E8Lu4//vk49Su9GdQzmVUetyF2qsEcl38T5ZR20Fv0oWAO68YZYoZZDCX8oPtg2L+NC3MGv/BG74nXq0gkufjIckZ5GLZxLIlTWOQJRkwTWlxCP6cjO/co+5+vZlwuXVID+5ueoyfb8g2XBzX6K/lLHwFpvKMxbj+liSVDKGaQ9RQmeYuULH90+XRtEzUk7bFpamvP+I3+fKbhgxL9LhaPr1GvDyWlqxViHPQbVrTShDGzhD2LXyYpPG+4yXE7P9OzlatQ58oHL/j9X1d9qiZtSFhZZo2CppTFlDufUr2+Q2cI1Ea6HDS5ApL1MwqTLRhP445e/q+hIqsV3n6iaMzuAV3muziWwvXczPd0pQmWrG1K0bYibIojaCOdViFfdBV+IeSNjal7F1ymmDCInv3/HLUP759bVwMmURaJJQ5bJXKjA1C5Lqu+oeQ6XDPL/S/U1BZimqJBwla5HlECM1heJ42bhzPauSe5Jr/yuCH2VE+opUBk9nZGVhesXh4AIsLiCNFXwvVDAzUuSmHUCYLtb++jNRA7XZAudvJ+wiotdEmZ66vm1VgFJUYAPGhmyIK6YnSrg0RaaPBJw12B46LVA77HrOju6hOojWPO1azqYSZXVUBnXA02Q6g/MpqndlBlOhOnA5xm7cI0HnFbwja5u39NORueG5Uk7LejKGmcC00HWkpNj/2mI7PfiL4Rhc4Qsmf/87asImsL1PK20oZIF7JJwUYyHWJm5Cl/p2EC26ofGKpUNWmKp/pGxVWM/gVEXdR6ZDu0y9mYuOlRGUCR2InTpoyVGcL9VyyxJ12JF3qMMxACmuKEgJm1CFraxfupI/Tfhj+Jhb0gvvKTS+IA9zCZQi3JLXWSP5DuyneQAuQc8Qeb0pjAK91HwXI+4us615mxLe/mfT59fMPUKNxve6RWhLCt1fbpz8QQ4Dgaf+sA0UTULB C4A6wZlL JLby6ytQmy1PTE9KO/0qD+jRRG7jz/URpxdWJDg1HE+evHYTRO9oplc6UyBgo/Ce55qQASjo3aLrGm8z5LAoX8ju1sFFuQIzUlgK4LeWyJutO9SPp6VWnGNDCuE4WC4U294PWhFfMv7FeXd5rVTi0oudHFM6jwLg9pNrEu6WaEa4sbIWakSVmke4zK5OL0qFgKWDD2/8sTuEs2tDq73ZXl/shlerVqsiZc1ocszImkegh8IKBexyKXMu10uffSRJXHK0tVPoIA1lgQaqJ0/t3TucE8gyk98rUVhZIiozt7vDpP84= 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: For a kmalloc object, when both kasan and slub redzone sanity check are enabled, they could both manipulate its data space like storing kasan free meta data and setting up kmalloc redzone, and may affect accuracy of that object's 'orig_size'. As an accurate 'orig_size' will be needed by some function like krealloc() soon, save kasan's free meta data in slub's metadata area instead of inside object when 'orig_size' is enabled. This will make it easier to maintain/understand the code. Size wise, when these two options are both enabled, the slub meta data space is already huge, and this just slightly increase the overall size. Signed-off-by: Feng Tang Acked-by: Andrey Konovalov --- mm/kasan/generic.c | 5 ++++- mm/slab.h | 6 ++++++ mm/slub.c | 17 ----------------- 3 files changed, 10 insertions(+), 18 deletions(-) diff --git a/mm/kasan/generic.c b/mm/kasan/generic.c index 6310a180278b..cad376199d47 100644 --- a/mm/kasan/generic.c +++ b/mm/kasan/generic.c @@ -393,8 +393,11 @@ void kasan_cache_create(struct kmem_cache *cache, unsigned int *size, * be touched after it was freed, or * 2. Object has a constructor, which means it's expected to * retain its content until the next allocation. + * 3. It is from a kmalloc cache which enables the debug option + * to store original size. */ - if ((cache->flags & SLAB_TYPESAFE_BY_RCU) || cache->ctor) { + if ((cache->flags & SLAB_TYPESAFE_BY_RCU) || cache->ctor || + slub_debug_orig_size(cache)) { cache->kasan_info.free_meta_offset = *size; *size += sizeof(struct kasan_free_meta); goto free_meta_added; diff --git a/mm/slab.h b/mm/slab.h index 90f95bda4571..7a0e9b34ba2a 100644 --- a/mm/slab.h +++ b/mm/slab.h @@ -689,6 +689,12 @@ void __kmem_obj_info(struct kmem_obj_info *kpp, void *object, struct slab *slab) void __check_heap_object(const void *ptr, unsigned long n, const struct slab *slab, bool to_user); +static inline bool slub_debug_orig_size(struct kmem_cache *s) +{ + return (kmem_cache_debug_flags(s, SLAB_STORE_USER) && + (s->flags & SLAB_KMALLOC)); +} + #ifdef CONFIG_SLUB_DEBUG void skip_orig_size_check(struct kmem_cache *s, const void *object); #endif diff --git a/mm/slub.c b/mm/slub.c index 23761533329d..996a72fa6f62 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -230,12 +230,6 @@ static inline bool kmem_cache_debug(struct kmem_cache *s) return kmem_cache_debug_flags(s, SLAB_DEBUG_FLAGS); } -static inline bool slub_debug_orig_size(struct kmem_cache *s) -{ - return (kmem_cache_debug_flags(s, SLAB_STORE_USER) && - (s->flags & SLAB_KMALLOC)); -} - void *fixup_red_left(struct kmem_cache *s, void *p) { if (kmem_cache_debug_flags(s, SLAB_RED_ZONE)) @@ -760,21 +754,10 @@ static inline void set_orig_size(struct kmem_cache *s, void *object, unsigned int orig_size) { void *p = kasan_reset_tag(object); - unsigned int kasan_meta_size; if (!slub_debug_orig_size(s)) return; - /* - * KASAN can save its free meta data inside of the object at offset 0. - * If this meta data size is larger than 'orig_size', it will overlap - * the data redzone in [orig_size+1, object_size]. Thus, we adjust - * 'orig_size' to be as at least as big as KASAN's meta data. - */ - kasan_meta_size = kasan_metadata_size(s, true); - if (kasan_meta_size > orig_size) - orig_size = kasan_meta_size; - p += get_info_end(s); p += sizeof(struct track) * 2; From patchwork Mon Sep 9 01:29:55 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Feng Tang X-Patchwork-Id: 13795730 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 6622ACD4F4C for ; Mon, 9 Sep 2024 01:30:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E1CFC6B00FC; Sun, 8 Sep 2024 21:30:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DCC596B00FE; Sun, 8 Sep 2024 21:30:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C6D9F6B00FF; Sun, 8 Sep 2024 21:30:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id A7CB86B00FC for ; Sun, 8 Sep 2024 21:30:14 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 12117160BCE for ; Mon, 9 Sep 2024 01:30:14 +0000 (UTC) X-FDA: 82543469148.13.599C9B5 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.15]) by imf30.hostedemail.com (Postfix) with ESMTP id DD1388000E for ; Mon, 9 Sep 2024 01:30:11 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=jDz1jhGK; 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=1725845277; 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:in-reply-to:references:references:dkim-signature; bh=2rD/2vlH1Beqh3HFAyv0sq8bJP93CMB8SMvlgU7yd5k=; b=oV34Wt95mCGUW8KMlBjtM5RejhbWuBKmer9mwXya0I3bcTux2u5FZiODM0K8JfJzFdati9 pHR1QEhtV2yDQ8GWuP4R6cE5EfZXsf+q7XYB41XtIosLbuSbNu4w6k6y0vtx1QWM5GMtZz icJ4cphNgMTzafpRCEaclsX+BThvEFY= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=jDz1jhGK; 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=1725845277; a=rsa-sha256; cv=none; b=gRf3ZiFPwOdEum1JRxFNtXPXxc4ZRDmghafJ/xUHC9JeEjf5r4qQhO0tZEkhrqynffFnnl PaFbOwOFz1EzfZcb6FZUIOfdoiUY4CIPxdB3Cgq1mRffUMyRx4em1Pwp0HYrTEqHTZYBsF nrhx+2K8Vr/cQj61q127it3upOpVKK8= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1725845412; x=1757381412; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=XQhb14NwobzgpHBJToS+EBksbjOmwkl1vy/zAbUzlvA=; b=jDz1jhGKJRnFkH03NhfTiJFMUEeUKuQN+DywzQYCi97G1/3rDoI9F0OC fchBMfq/m+xf+Fq10auRWA0nI6TYwrfQupIkZh7NntObMpNWtadoNobBP PMLkTXus+s2cwDuSW6xicI+FqG+1/IUfcb8oGveUV33vSKDiZisVTMhhD tdIcwFVTgdnZUYVlKW/I+2P1dPX9ZVVkDpVnMQWClQLtYtm88xnZpwvCo LeBH3YRR1WUgt2lKnYx2fGNmjp7D1af8TfhoMhDCjba2/WsNdOXqg/OdN yyO8qx7Iv0MMXf/6RDkX8xKcTY8jiL7fZGXW3yT8ToOmYQBzo9e+Vj4jE A==; X-CSE-ConnectionGUID: ecBi6vlySRiiIigcj6eg0g== X-CSE-MsgGUID: ssg+OqlHTFO7z7Eg/CAfHw== X-IronPort-AV: E=McAfee;i="6700,10204,11189"; a="28258117" X-IronPort-AV: E=Sophos;i="6.10,213,1719903600"; d="scan'208";a="28258117" 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:11 -0700 X-CSE-ConnectionGUID: DjU4Ii44RO+mC+79SYUM9Q== X-CSE-MsgGUID: wZvquO98SZKlH1AaBHu3rw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.10,213,1719903600"; d="scan'208";a="66486450" Received: from feng-clx.sh.intel.com ([10.239.159.50]) by orviesa009.jf.intel.com with ESMTP; 08 Sep 2024 18:30:07 -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 2/5] mm/slub: Consider kfence case for get_orig_size() Date: Mon, 9 Sep 2024 09:29:55 +0800 Message-Id: <20240909012958.913438-3-feng.tang@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240909012958.913438-1-feng.tang@intel.com> References: <20240909012958.913438-1-feng.tang@intel.com> MIME-Version: 1.0 X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: DD1388000E X-Stat-Signature: o8u33rnosisbg84hbbh36qe6he6yihzk X-Rspam-User: X-HE-Tag: 1725845411-711213 X-HE-Meta: U2FsdGVkX1+RFmYJ0Pu7vzk9T2QeyUG+Vszzsa7Glho68Rbp1SorRu+HyoU600x5b/zMhYQiZ7M9O0QDPbNWAE1IDUwfcBAQgw4gqY3ecPcj1lU8iDr73iiq34JyVmBn4BvOYhSoAuLi+1IZ5dmqoMPTiX250N8IX3v2QPHyV0RF6ZDnVtOF8yj6sZ9rDFIyojHB1Tn0Jnxs/im0xY7a9q1vBmZjQ3CQvRjOs1KCUFW7kXyVxz1kbgyMMVWdkIH709Bt8/s8m5cijS5NYcm0HVcp5C2R9OJAv0EDkgS2R9HVjbLdWSM0jgsZpYAhqFhPupeTj53uhp38z0syYhVG/WnCSihY4A8eMEx0jcGk8zIz9BqkbmKhaLXGapbKaCWs6zkow8ev538ebzxG4qXkw7HgC8C5bzoilngN40qzS/Qfxx5UCPeR+rIOebG2gn5PPGmFX2w+IrIV6ucR6r9Y3SSDohpP0W/fJkn6p6MPH7nkymrfelK9easj6Ojzr8mPOTW1iRrWxnQZUn11P6E6Z03jk8lk1vWeCScuuNWFQiY7LJqkT7mjQ3F5R4QFAOYzx4fcnLJT2lDdGXgEdMTiKiu4fJE8xg5spafljZE7B2xwRQe2FxFpL9toLS2KTCde/bG3zeUzS3+1Tyb0zZLEczoxQy0ubRpaHl4lkz/cUMPfOPUBk1IrsnuXOwYcnrH2MxucOu4wvgexPCvsX8gyx3oP1Z3O/4jIHJsijkV4j58+ltRtqfmlhH3k0Cy/AygeaqOs982oq5MdViOUduxSA5kmJgINivS5SByh4yNaY5PMmTsmP3uY0oyWNaCfeOAy2fUCIIafW5/gUjSi+W2cr2H7cPQgjEI70Su3SD2kvdTSJLUM26V2MNm88H/0CzUn//0RnJ0j69HPNu+kiYo9B1Z+SV1/25KtZcA7LquZwvCvdgf+RqeRm7Bhm1Pah8wNr9cEyYEnM7adKRNSgb+ fFRjR2+M 25MWRDmVOZwHkzAtRKc4dYQ58VWM8hCJ5uWsQ/rdtnN67kMkGKVXIWZaG7jr7k/KN27Gdd3MCqcv/sZQI+74pkBUGGsHeJrmNaPpYk3bZmGT78lhDfFCkhHlngwvw9naUX0d520DbdRwIWCuaY18oZdv4oPyvhawHGxfIVxmLd5ETOe+U+BgHmad2FKWKneLDzH+zZNpJJqDh6g14YVQ75qNNJe/HVifx/hkMwr5AYjT36S0/gIst2vTw7Sw6vdVKFY8dCAjBKAbzcgJQ4WWnR+Uts/NpcWATJOMkcZgsuypy7VM= 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: When 'orig_size' of kmalloc object is enabled by debug option, it should either contains the actual requested size or the cache's 'object_size'. But it's not true if that object is a kfence-allocated one, and its 'orig_size' in metadata could be zero or other values. This is not a big issue for current 'orig_size' usage, as init_object() and check_object() during alloc/free process will be skipped for kfence addresses. As 'orig_size' will be used by some function block like krealloc(), handle it by returning the 'object_size' in get_orig_size() for kfence addresses. Signed-off-by: Feng Tang --- mm/slub.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/slub.c b/mm/slub.c index 996a72fa6f62..4cb3822dba08 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -768,7 +768,7 @@ static inline unsigned int get_orig_size(struct kmem_cache *s, void *object) { void *p = kasan_reset_tag(object); - if (!slub_debug_orig_size(s)) + if (!slub_debug_orig_size(s) || is_kfence_address(object)) return s->object_size; p += get_info_end(s); From patchwork Mon Sep 9 01:29:56 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Feng Tang X-Patchwork-Id: 13795731 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 4D78CCD4F4C for ; Mon, 9 Sep 2024 01:30:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D33246B00FE; Sun, 8 Sep 2024 21:30:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CE2496B0100; Sun, 8 Sep 2024 21:30:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B36666B0101; Sun, 8 Sep 2024 21:30:18 -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 92D4B6B00FE for ; Sun, 8 Sep 2024 21:30:18 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 4702612095F for ; Mon, 9 Sep 2024 01:30:18 +0000 (UTC) X-FDA: 82543469316.25.8034BB0 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.15]) by imf30.hostedemail.com (Postfix) with ESMTP id 29EE880010 for ; Mon, 9 Sep 2024 01:30:16 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=UO0zbAn1; 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=1725845282; 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:in-reply-to:references:references:dkim-signature; bh=5SIq2Al2KKMR6KlWBzxeKlCo6AeeNgLC3rgQdDAQ+Bw=; b=tnJGjbIqmoBK5/xt28nlrAfwarz8AXq/VV8TPtnXhlFxy6Qv1UUCTS82VpL/du5nEb8jSt U8dvFAMHEhFFgtGB4utEZqOz/ei3ooAij84JOWrDwEE32OGWhmZTjAbhL6AjlK4Vu98ivl 9WaGQmWfCW+FO1zcY8kzDFKRu0+R+3o= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=UO0zbAn1; 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=1725845282; a=rsa-sha256; cv=none; b=IEAnvDBVWv5bUe7d1sw8TqWsblVyJhRbqfZH1bJwxDA+GbGtdduHtFuy4GStE6xAZPzGOB VbjkynQvvs+Mf8IMTDU/NhazEJN1zqc/FJGaEq8WlfAvQbiYLe/7LHLj8L+hrIPr7vtZkS aZ+zqyc03D4UMmNMtH2MlRx70tGsZSM= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1725845416; x=1757381416; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=B8mgHFZzGD1KfDB0WGMvxSgxbcgttavsuRFve7SsS4M=; b=UO0zbAn1j7vuzTnpmStJmkvfnOxNJ9Op+nqvh7P0xugVc96RZGWWASwb z/gE5KNpIX17z6sneuDNeuA3JaBXKEQIgzo7l8xqkQUFH4b/3mVC3dNkV OdJ5tM0lu7R912jZUzxPKYiiCB+6PQjPBSpJIsFeTDt5jzctY2JuSj9x5 Sda12nZMHLEHb0srYy2neudfWm2JQgmCOLuG/XRugpIIUJ7ZvdV0Oiaqp S+wza6LXdpf+iZ/2XOKkTzcetf1LbtoowfwjCIjCkA2mYR++ZOy0RfM2k hGc5mnrWQm2iuJqGNyLznY592COpxz8ONuNCH80Wmm8bIUKD7SPp6X9EA g==; X-CSE-ConnectionGUID: JEhuRQ/gQWCrtPk239EGVA== X-CSE-MsgGUID: KKxdpOhDS4qEup2PxUWykQ== X-IronPort-AV: E=McAfee;i="6700,10204,11189"; a="28258131" X-IronPort-AV: E=Sophos;i="6.10,213,1719903600"; d="scan'208";a="28258131" 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:16 -0700 X-CSE-ConnectionGUID: cx70BTLlS3CxDDTgPHNKyA== X-CSE-MsgGUID: E/DBYOyRSA6Yo9pun0F7fg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.10,213,1719903600"; d="scan'208";a="66486467" Received: from feng-clx.sh.intel.com ([10.239.159.50]) by orviesa009.jf.intel.com with ESMTP; 08 Sep 2024 18:30:11 -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 3/5] mm/slub: Improve redzone check and zeroing for krealloc() Date: Mon, 9 Sep 2024 09:29:56 +0800 Message-Id: <20240909012958.913438-4-feng.tang@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240909012958.913438-1-feng.tang@intel.com> References: <20240909012958.913438-1-feng.tang@intel.com> MIME-Version: 1.0 X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 29EE880010 X-Stat-Signature: e8wxn7yxebds16aczjyoof4fjha4h64f X-Rspam-User: X-HE-Tag: 1725845416-635326 X-HE-Meta: U2FsdGVkX1/pnJw8ARuRbW0SC835OW371LuGL4H0dbIHViKbSyiBdIoQfZsdRGSMu2Hg1LYUuLYr5737HramXIdYnhny2oEqOH2cVw4WjKlI0oZO35lYvKq/Rg/mBE4XxX7rNMYfpG+B8BSYUWhHt8hiFnsfuneoHwveVdNLm6p4r+8uHp/mhtwDnv91GMWkhuCvc4L93QunL/dk0IU9Ddg1xso9xZ22l8fumyoD6aSIBKpn2LMMEFObmqepBQm50E2fce/7V4Ca/+BacWh0CkG4nUFyk7163szdCZaaYghquxN7R0iXC6jUNpBZ5Vuy4jjSi722B3hd1rUAdXmTw93bFIV3MDvsCDmUQpBiyUnDOftZyHoqA5V2U/ZotZnVc9dfxNaTnhTDJnmwxwPTtC5/ggC/2kDphK6m57tId6RVM3AEN5lyJpZtCDjGlOJcC2exUe0b3xnAOsScRJe61Yq+ZXwVKSDWxSyJ+I+MooOE7guZ7X3lf5cgXqixMvo6YspwGqGIzrzOIu0pA8hA1YO1tGMZ7btqZUWrmm0a49jS6YrjDyuQdLQQk1Z3BCBFb+WaEv36nFtRzhPvBbxPeXM0ZEy+Pu2z5xHmyiwoetkwlHcCd8YMTkP6DLQu7EsLzkurBw5FVlGXEcTRiF6tMIk7NBBPNDMo7xH56jUnpLjepwB4KOHZNLNpAhlHuBRhe0loo0N/DWwRM9rwDSQ3sMnqBhSPRkCivbj4qCa5QPHaMHSrRSnawliiA05ugbZccPk/8HZI0MHNTD59R0/fiQ63HYa62xeVJtiu6KcMoAYdMDO1t4EUkW//KVFspCw+O65e1qiPc1az9TN8By/8VOpm9fCHl2/8EohyopAkqnhNcYW7rqyLfFvNnExdrJrsMlGIGvq2B46CgrcxMcAd9W29wIq6gOy1K6ohG8gBCwRPRLZ4SSITCR1aP+erpPcuwljBKb7MiWCSCyLTZpo ieIu25nh ldlJISNw58fJPDAYXS/GUg9OqQ0PD/8wMwdRX5LP1Wcuc/S8Bj+yEkt+qptxAL4lds/dlwsYhu4da1mf82zOY/WWQtnyQm2qX8IQWZUwZ1ra+ol4SPwqFOo2jgxYul/HHe75dSXKAZwtHsaCrf8fMqbCJGjyVRApk2Ppx1kpYH2LDh+m+ZwzhA8+hWSkrBJGBFJpDMhTiL5rQnWXBrOdp+8mxJNpHGH+jeCdGAo6tRa+uWQc2Okr2x/+rx5Zvh0iP0M1o 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: For current krealloc(), one problem is 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. So utilize it to do more accurate data handling, as well as enforce the kmalloc-redzone sanity check. The krealloc() related code is moved from slab_common.c to slub.c for more efficient function calling. Suggested-by: Vlastimil Babka Signed-off-by: Feng Tang --- mm/slab_common.c | 84 ------------------------------------- mm/slub.c | 106 +++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 106 insertions(+), 84 deletions(-) diff --git a/mm/slab_common.c b/mm/slab_common.c index ad438ba62485..e59942fb7970 100644 --- a/mm/slab_common.c +++ b/mm/slab_common.c @@ -1297,90 +1297,6 @@ module_init(slab_proc_init); #endif /* CONFIG_SLUB_DEBUG */ -static __always_inline __realloc_size(2) void * -__do_krealloc(const void *p, size_t new_size, gfp_t flags) -{ - void *ret; - size_t ks; - - /* Check for double-free before calling ksize. */ - if (likely(!ZERO_OR_NULL_PTR(p))) { - if (!kasan_check_byte(p)) - return NULL; - ks = ksize(p); - } else - ks = 0; - - /* If the object still fits, repoison it precisely. */ - if (ks >= new_size) { - /* Zero out spare memory. */ - if (want_init_on_alloc(flags)) { - kasan_disable_current(); - memset((void *)p + new_size, 0, ks - new_size); - kasan_enable_current(); - } - - p = kasan_krealloc((void *)p, new_size, flags); - return (void *)p; - } - - ret = kmalloc_node_track_caller_noprof(new_size, flags, NUMA_NO_NODE, _RET_IP_); - if (ret && p) { - /* Disable KASAN checks as the object's redzone is accessed. */ - kasan_disable_current(); - memcpy(ret, kasan_reset_tag(p), ks); - kasan_enable_current(); - } - - return ret; -} - -/** - * krealloc - reallocate memory. The contents will remain unchanged. - * @p: object to reallocate memory for. - * @new_size: how many bytes of memory are required. - * @flags: the type of memory to allocate. - * - * If @p is %NULL, krealloc() behaves exactly like kmalloc(). If @new_size - * is 0 and @p is not a %NULL pointer, the object pointed to is freed. - * - * If __GFP_ZERO logic is requested, callers must ensure that, starting with the - * initial memory allocation, every subsequent call to this API for the same - * memory allocation is flagged with __GFP_ZERO. Otherwise, it is possible that - * __GFP_ZERO is not fully honored by this API. - * - * This is the case, since krealloc() only knows about the bucket size of an - * allocation (but not the exact size it was allocated with) and hence - * implements the following semantics for shrinking and growing buffers with - * __GFP_ZERO. - * - * new bucket - * 0 size size - * |--------|----------------| - * | keep | zero | - * - * In any case, the contents of the object pointed to are preserved up to the - * lesser of the new and old sizes. - * - * Return: pointer to the allocated memory or %NULL in case of error - */ -void *krealloc_noprof(const void *p, size_t new_size, gfp_t flags) -{ - void *ret; - - if (unlikely(!new_size)) { - kfree(p); - return ZERO_SIZE_PTR; - } - - ret = __do_krealloc(p, new_size, flags); - if (ret && kasan_reset_tag(p) != kasan_reset_tag(ret)) - kfree(p); - - return ret; -} -EXPORT_SYMBOL(krealloc_noprof); - /** * kfree_sensitive - Clear sensitive information in memory before freeing * @p: object to free memory of diff --git a/mm/slub.c b/mm/slub.c index 4cb3822dba08..d4c938dfb89e 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -4709,6 +4709,112 @@ void kfree(const void *object) } EXPORT_SYMBOL(kfree); +static __always_inline __realloc_size(2) void * +__do_krealloc(const void *p, size_t new_size, gfp_t flags) +{ + void *ret; + size_t ks; + int orig_size = 0; + struct kmem_cache *s; + + /* Check for double-free before calling ksize. */ + if (likely(!ZERO_OR_NULL_PTR(p))) { + if (!kasan_check_byte(p)) + return NULL; + + s = virt_to_cache(p); + orig_size = get_orig_size(s, (void *)p); + ks = s->object_size; + } else + ks = 0; + + /* If the object doesn't fit, allocate a bigger one */ + if (new_size > ks) + goto alloc_new; + + /* Zero out spare memory. */ + if (want_init_on_alloc(flags)) { + kasan_disable_current(); + if (orig_size < new_size) + memset((void *)p + orig_size, 0, new_size - orig_size); + else + memset((void *)p + new_size, 0, ks - new_size); + kasan_enable_current(); + } + + if (slub_debug_orig_size(s) && !is_kfence_address(p)) { + set_orig_size(s, (void *)p, new_size); + if (s->flags & SLAB_RED_ZONE && new_size < ks) + memset_no_sanitize_memory((void *)p + new_size, + SLUB_RED_ACTIVE, ks - new_size); + } + + p = kasan_krealloc((void *)p, new_size, flags); + return (void *)p; + +alloc_new: + ret = kmalloc_node_track_caller_noprof(new_size, flags, NUMA_NO_NODE, _RET_IP_); + if (ret && p) { + /* Disable KASAN checks as the object's redzone is accessed. */ + kasan_disable_current(); + if (orig_size) + memcpy(ret, kasan_reset_tag(p), orig_size); + kasan_enable_current(); + } + + return ret; +} + +/** + * krealloc - reallocate memory. The contents will remain unchanged. + * @p: object to reallocate memory for. + * @new_size: how many bytes of memory are required. + * @flags: the type of memory to allocate. + * + * If @p is %NULL, krealloc() behaves exactly like kmalloc(). If @new_size + * is 0 and @p is not a %NULL pointer, the object pointed to is freed. + * + * If __GFP_ZERO logic is requested, callers must ensure that, starting with the + * initial memory allocation, every subsequent call to this API for the same + * memory allocation is flagged with __GFP_ZERO. Otherwise, it is possible that + * __GFP_ZERO is not fully honored by this API. + * + * When slub_debug_orig_size() is off, since krealloc() only knows about the + * bucket size of an allocation (but not the exact size it was allocated with) + * and hence implements the following semantics for shrinking and growing + * buffers with __GFP_ZERO. + * + * new bucket + * 0 size size + * |--------|----------------| + * | keep | zero | + * + * Otherwize, the original allocation size 'orig_size' could be used to + * precisely clear the requested size, and the new size will also be stored as + * the new 'orig_size'. + * + * In any case, the contents of the object pointed to are preserved up to the + * lesser of the new and old sizes. + * + * Return: pointer to the allocated memory or %NULL in case of error + */ +void *krealloc_noprof(const void *p, size_t new_size, gfp_t flags) +{ + void *ret; + + if (unlikely(!new_size)) { + kfree(p); + return ZERO_SIZE_PTR; + } + + ret = __do_krealloc(p, new_size, flags); + if (ret && kasan_reset_tag(p) != kasan_reset_tag(ret)) + kfree(p); + + return ret; +} +EXPORT_SYMBOL(krealloc_noprof); + struct detached_freelist { struct slab *slab; void *tail; From patchwork Mon Sep 9 01:29:57 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Feng Tang X-Patchwork-Id: 13795732 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 598E3CD4F4C for ; Mon, 9 Sep 2024 01:30:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D819A6B0100; Sun, 8 Sep 2024 21:30:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D32736B0102; Sun, 8 Sep 2024 21:30:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BF7E76B0103; Sun, 8 Sep 2024 21:30:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id A08B36B0100 for ; Sun, 8 Sep 2024 21:30:22 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 5EC121A1D6F for ; Mon, 9 Sep 2024 01:30:22 +0000 (UTC) X-FDA: 82543469484.14.2594D33 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.15]) by imf30.hostedemail.com (Postfix) with ESMTP id 4E5B680016 for ; Mon, 9 Sep 2024 01:30:20 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=Nq8Qelke; 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=1725845286; 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:in-reply-to:references:references:dkim-signature; bh=7vVZ50kdJDNFI19gsV94XEZMSmlP1RCFkWL2RtPs6kk=; b=h0q+5K+eZJVX67G81kYUvI7e8Lv95vqe9Q4urUI+PSLP1FW7gb+Gwj3jvhilIdzf5kXiDw L4UscnU8Ap44D9wI9fHsW3UNnBKot6+qlkYKxDVrQhAa8Kzx9gwFeZET0QyjcDaeA3gTT5 hDGtxBLJnx6wCPB5Ph9V6qciy2Z4Ah0= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=Nq8Qelke; 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=1725845286; a=rsa-sha256; cv=none; b=jYvVaMMKye2/p0DK61tBf2l/yBFTwRQTE6t6rucGV3pxUETMkIsFHhIZvvLG9ErXBV3vUt +rrnxf5XMaoKCsypt2mSh8XQF/oJjeyT5JtLJibCTeycEwTigfmLHMr/lUY9uAlWBmviQ1 z6tnSI7gd82hzhZOXp/NKTnMsV1QX3g= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1725845420; x=1757381420; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=sd4pFelEU/QdXj5ouoP5PRXHKn8qGUrWc/AAyu1UHpU=; b=Nq8QelkeHuFcOZnhF3FEEfIcgM3sT9yQzoPvF78Ttfv1mUx8L2ePEpaE mogHTkDHJiDiDlvzRNgiJgmHanq44ZYHwn6LfaUlpsvjkfiLir7IOm4Yc Yd6ZT8puYmkz5ncNvv6eczcwyb2CgQb26GKhP5lWh1S3KQSEbyBnMcXul J7epsH/nv5iQrYgvFIMOuV07YOJUsHIZxYR9PN9uK8OnEVTvdQLoqvjSL R28PGRTZfJzgRwHbR0W7yLEJ/vOOArs98jwu2xMGCZ1720H6b0zp5MwLe s+zM57l/KiRDhUXnu8SvK68vuCC4m7j3MOLLsUxkM6z4eFz+sdltKIreZ w==; X-CSE-ConnectionGUID: AjhE5LMKTluqRaVCQGcx0w== X-CSE-MsgGUID: T22d4ZFqSH2RCkkmYrcAng== X-IronPort-AV: E=McAfee;i="6700,10204,11189"; a="28258148" X-IronPort-AV: E=Sophos;i="6.10,213,1719903600"; d="scan'208";a="28258148" 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:20 -0700 X-CSE-ConnectionGUID: WDU907LnRC+3vfLghWzWkw== X-CSE-MsgGUID: 4FEk/tfqQaKVE8AxVIBYaQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.10,213,1719903600"; d="scan'208";a="66486499" Received: from feng-clx.sh.intel.com ([10.239.159.50]) by orviesa009.jf.intel.com with ESMTP; 08 Sep 2024 18:30:15 -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 4/5] kunit: kfence: Make KFENCE_TEST_REQUIRES macro available for all kunit case Date: Mon, 9 Sep 2024 09:29:57 +0800 Message-Id: <20240909012958.913438-5-feng.tang@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240909012958.913438-1-feng.tang@intel.com> References: <20240909012958.913438-1-feng.tang@intel.com> MIME-Version: 1.0 X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 4E5B680016 X-Stat-Signature: ep5s6sc33qxxcjpbaeiah17kat4sy1kq X-Rspam-User: X-HE-Tag: 1725845420-748773 X-HE-Meta: U2FsdGVkX19FCBc0sOpaqEE4SVVgw/i5sbWt3xYdvfyDr8hJoaZBRj7rB0qcQ9PhygiIU+NU5Ki0pedi/ZQwPAyvVPNdJxK/ZGoHRnKxP5J4gzWxZ5jRtSywXr60jAKUepFEJCoiR96D1oLd2dMXsVGrpYtyXT8F2DDoFUI3fPxIJR3t6XmaYiWhaWTSZsUtd5JBfFmDX7EJbVF0ATsDdjQW5/AB2cx3S1aJAT3h0E2MYRG3zerH25lsrCsAzk92LajgEKhNyLxFOvJIlzdG2nVvFbr1qryLRcnvjIAUFNDzJyenZfLuPDdQSpfOEKmTfmdP+O6xC66mhnOo4FqEK824dbe0PDkTzjAQMbcYWHzv2EH3OWBqcJXlTKVMBvt+t2jEfVb18a+h2Jjw6v31l8nGd3O/nT7+TzhcZQLELREWITshk4heJfAUeGjy69LrlQS9hBerKTPVexlHOxjI2/ephDr5GYhGX3AUo/LQN4LAsCXhggZmquNJWfV8AXvDHpRKNuQITkptbr2edxFO44Uv0cHCQEb/W7fwzEyzWLrVwEL9dYIBSd2w+zxq08tFVY7hUbspS+Y32LSSFrK/eKrD4PVLmvNJllvJ0b5Oz3tAo/ruZjyNR+yE+X/6G2KId1nbPPrKAYnZyzd+S84/kQHDd5V+ZO6GMWKxzQkqzYpA+1+bMZoHQHMrDCFyB6RtadxmV2AzJOPJbRYRfDNyyfh54+ow+5hhqtbHrIkoCIb7llmXCMildHwixEKThFU+tCZP+KWTOq75L7XTXUjOiF9SfBASNyu2mLGApJH/BN07nXBkqJgDDWZ0B9tQRtdgRXRYO1LXoOr/OtCIt0pIfoGioCqYz1pYh9bxGbj8gATEF4TSb2xLWk2gwfpyhHlEN3jS/Fv0zdg4aRo7jPwOy/1bx4pEP9Ny/jnJuHSYrMfipGqUh3BxNl8RS+H+icJhRfIf/cxqR0AQNI93pDp lvMRwfzt Dw0JOuM3Sw/A+dyXVgq3Yf1V502yWIA0MTgaFk2lCUIcbMXla+A48maAH/pU4DmoUzfDfhvp8+vocAAgQQ34CUzFaCAg7iOCa+xXfZKhWqKsiL8TUCKQSVkvwvVSGaJJTeyJebAH6n5n/n3RQv0vlWZJXvuO9+wVsBlW3YJDpFBOc7QjaCU1m02EXnSy31EIQUJ7ejDXcTlqV9Pq/hOumXUMmAsbSRDqNB7xEMEfuQggNzxucDTdveJ1cIWABXpLs2r4rSDTkF/9YaVGcfIQZZBnUmq1zoQy17pjhbBp8ZFKBoOg= 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: KFENCE_TEST_REQUIRES macro is convenient for judging if a prerequisite of a test case exists. Lift it into kunit/test.h so that all kunit test cases can benefit from it. Signed-off-by: Feng Tang Reviewed-by: Alexander Potapenko Reviewed-by: Marco Elver --- include/kunit/test.h | 6 ++++++ mm/kfence/kfence_test.c | 9 ++------- 2 files changed, 8 insertions(+), 7 deletions(-) diff --git a/include/kunit/test.h b/include/kunit/test.h index 5ac237c949a0..8a8027e10b89 100644 --- a/include/kunit/test.h +++ b/include/kunit/test.h @@ -643,6 +643,12 @@ void __printf(2, 3) kunit_log_append(struct string_stream *log, const char *fmt, WRITE_ONCE(test->last_seen.line, __LINE__); \ } while (0) +#define KUNIT_TEST_REQUIRES(test, cond) do { \ + if (!(cond)) \ + kunit_skip((test), "Test requires: " #cond); \ +} while (0) + + /** * KUNIT_SUCCEED() - A no-op expectation. Only exists for code clarity. * @test: The test context object. diff --git a/mm/kfence/kfence_test.c b/mm/kfence/kfence_test.c index 00fd17285285..5dbb22c8c44f 100644 --- a/mm/kfence/kfence_test.c +++ b/mm/kfence/kfence_test.c @@ -32,11 +32,6 @@ #define arch_kfence_test_address(addr) (addr) #endif -#define KFENCE_TEST_REQUIRES(test, cond) do { \ - if (!(cond)) \ - kunit_skip((test), "Test requires: " #cond); \ -} while (0) - /* Report as observed from console. */ static struct { spinlock_t lock; @@ -561,7 +556,7 @@ static void test_init_on_free(struct kunit *test) }; int i; - KFENCE_TEST_REQUIRES(test, IS_ENABLED(CONFIG_INIT_ON_FREE_DEFAULT_ON)); + KUNIT_TEST_REQUIRES(test, IS_ENABLED(CONFIG_INIT_ON_FREE_DEFAULT_ON)); /* Assume it hasn't been disabled on command line. */ setup_test_cache(test, size, 0, NULL); @@ -609,7 +604,7 @@ static void test_gfpzero(struct kunit *test) int i; /* Skip if we think it'd take too long. */ - KFENCE_TEST_REQUIRES(test, kfence_sample_interval <= 100); + KUNIT_TEST_REQUIRES(test, kfence_sample_interval <= 100); setup_test_cache(test, size, 0, NULL); buf1 = test_alloc(test, size, GFP_KERNEL, ALLOCATE_ANY); From patchwork Mon Sep 9 01:29:58 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Feng Tang X-Patchwork-Id: 13795733 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 51217ECE577 for ; Mon, 9 Sep 2024 01:30:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D5D526B0102; Sun, 8 Sep 2024 21:30:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CE5376B0104; Sun, 8 Sep 2024 21:30:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B36B26B0105; Sun, 8 Sep 2024 21:30:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 910266B0102 for ; Sun, 8 Sep 2024 21:30:26 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 4F9C5C0942 for ; Mon, 9 Sep 2024 01:30:26 +0000 (UTC) X-FDA: 82543469652.23.43E5809 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.15]) by imf30.hostedemail.com (Postfix) with ESMTP id 3C64380016 for ; Mon, 9 Sep 2024 01:30:24 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=MLiaaWnj; 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=1725845290; 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:in-reply-to:references:references:dkim-signature; bh=TdrgPZ3kYW9y9DC7KkVYudRyE6G4mFvxFIKatTay83o=; b=gYFkvHD/YgF3/UM6jmjYTb6Hac0A7slIykkp29Sc3eInbIDQIKCZNYalm+UcASGrRPbOXX XMxj4jO8zBy0kNb+kSDKjmelcX4jM9zXAcAGFZN9QE0NYkKZwjcjFoy0g13HtWJ/qj7ucE 0O1YoyFFBvsRAHZhjaF2pu/lAnvKTzA= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=MLiaaWnj; 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=1725845290; a=rsa-sha256; cv=none; b=7XkC6JELBKf8OqqmNTzFhhK5EBu7iC+d9zba4vzmuCiuU6vQiWCop8DCmQtLHQT1sCxbgY ZEOufcAO52ZHwlnXTdKXJ1KZT3dVdsCJamocfiE3ijN7Gs3eIo1xOa24mKFJULRI2gO7iC 4wQfh0T6/tsb3+0xVak7EG+8YrlZlLU= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1725845424; x=1757381424; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=Ol5TUqWkU7uvIyG026mGuFtpsR/rEt0g9LWcDZDc0MM=; b=MLiaaWnjz/qlMjstOwedT7w+GHAVqaxijuYmEZFoZ6NTFqpRG3Ux7alx +QlOJv7lWICUPNMowS43ZEY2gYQREob2TGAUyKjmzH/K4m5yo0YFq/EXR BvvKEcTcHm53x3CNZheSzcLYEw9/5BqnDu7qtB4KXGrQB/sZCGvNRVW3b B0+KJ+jJE67GWCPOGRZ7MycyFFH55cI82Csw+HoY50t2M5qtBlc6V29JT sugZakY7Qwo+iUIJh7eXWubLHjWod8w4qPXcBhQfHhsC9w2KbUIJdDEEz yD/HhVXSIubM6f9SvShySuQ+f1Ri6e80izT0finuReRIFANcnuJ2Lbxno Q==; X-CSE-ConnectionGUID: WLA+Nq/ZRriPFICWhsKQcQ== X-CSE-MsgGUID: lvyAQlHrQIWDoT+sOKS2xA== X-IronPort-AV: E=McAfee;i="6700,10204,11189"; a="28258163" X-IronPort-AV: E=Sophos;i="6.10,213,1719903600"; d="scan'208";a="28258163" 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:24 -0700 X-CSE-ConnectionGUID: ROdRq+r4T9WF2KAQcT/Xlg== X-CSE-MsgGUID: DV/YFBNgQQa1SpiY83zezA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.10,213,1719903600"; d="scan'208";a="66486541" Received: from feng-clx.sh.intel.com ([10.239.159.50]) by orviesa009.jf.intel.com with ESMTP; 08 Sep 2024 18:30:19 -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 5/5] mm/slub, kunit: Add testcase for krealloc redzone and zeroing Date: Mon, 9 Sep 2024 09:29:58 +0800 Message-Id: <20240909012958.913438-6-feng.tang@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240909012958.913438-1-feng.tang@intel.com> References: <20240909012958.913438-1-feng.tang@intel.com> MIME-Version: 1.0 X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 3C64380016 X-Stat-Signature: j6btcsyxsjkatwozurjt6ronk5bjjynr X-Rspam-User: X-HE-Tag: 1725845424-663442 X-HE-Meta: U2FsdGVkX1//cc3oEsUpR+eKMWcgl01a7AS0ZONqdIysnmoZSZ2p58YwPm8YHR+y3p8fXuRoj9XWTF4atXSwawzKzptOwHSTY9thYkS6Xabpxr9k88hq0lGVHUrKZmxCg9nmWBp+S5XIXbNweOiCcw0wYLQwehwPMgxrp7vcTXkJarBtScy9d2ao/UO4NpFpySWjuQGO50aDV7qB05mjrRIVQqqPzjzhuQorGdOkQ70Kj3DQm72aZQ6JuqNDYMay7/3SdWWErUr4yraiCJEOoztR3sM0R53NkaIfFV8N6DEjW2JaZ9glK/4F/sMtrmyJNFREda2s4fQcMubOUCCnp3nrLYW1+ontuuANPuVuNVSgGkicazvSvPyGgFFE3A2eCZnIRAUsyJS3Sr21chrwojVOniZcLBApke7RB/YgP6IdIs+jrW99N3RBEj2A7emfteyo1TdCflmStNIGpKNKn4Jof1357XV3e+P/BRZ+VX1eiqV9HoDWgfhz7+lzP5KtcEuTCJvRvHnFF+kOglD5mk8y6J21Mmc4g7YK8FkJZNz8XYu1l27AZ3XLUJbeeXoXxFZG8arZeB/wh5BC8JwMD9MAnXsHzhhufmoA/3lHvP44qd9wBzQgEwa2llCQkptRa9wQ825BM+ZfPb3JBM/oLxO8nwoAgODak6dN03VgttDjKk9dN35fSlTWAc2oOfTMD3YLIsNdpVKxiWVxCYJuYH+RhV/7Hcbzy5qtk77VN5V1fkIK8TvOQIPvSEV0jqLqFjI0+G9T/0mjbmsKxfZ+bxLfZdXpetW3kITh/00M2JmdbEw/+eX/NWwlZxvmuUevLV1ReEUMdlfjHdsOYZ5EPlDErag9kTuvS5hByDbz++iErLV4V6Rl24oe7tKwA7s9r75D0W3uUt5SHGopQC0IyE5XgUQQ0R/UMQ92rIzj8hbb7+fVHEdqzDU9Omlsm2Dz/uoDhooAyU7JcyV6t2p ududUj/V 7cyvL6fqu/ZPjOdx24bR4vUP97f/tHQ8gJLBWW6zQAMS7R5+TasJ3kync5ErvwW3C7D0sIeui+ZL8LqjAUbr20V0+ySEJG3TEHJoljkrCzoPl26ZWNbIr2+H16ZQfR9iF5/EIX8UBSfvDYj4sUzcXru4HU2FxhyOe41PYMEwRzXF1J47SnY8ItXh5xymN+w8MKQikj4tjOQzRFJu96Hmw5g1jwt2XnDpp2+GGzyPu7Que9z17IcizoqpYilQSz3aK4Ep8SIwY5ayDXcWvuvLm47pDZw== 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 raised issue about krealloc+GFP_ZERO [1], and Vlastimil suggested to add some test case which can sanity test the kmalloc-redzone and zeroing by utilizing the kmalloc's 'orig_size' debug feature. It covers the grow and shrink case of krealloc() re-using current kmalloc object, and the case of re-allocating a new bigger object. User can add "slub_debug" kernel cmdline parameter to test it. [1]. https://lore.kernel.org/lkml/20240812223707.32049-1-dakr@kernel.org/ Suggested-by: Vlastimil Babka Signed-off-by: Feng Tang Reviewed-by: Danilo Krummrich --- lib/slub_kunit.c | 46 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 46 insertions(+) diff --git a/lib/slub_kunit.c b/lib/slub_kunit.c index 6e3a1e5a7142..03e0089149ad 100644 --- a/lib/slub_kunit.c +++ b/lib/slub_kunit.c @@ -186,6 +186,51 @@ static void test_leak_destroy(struct kunit *test) KUNIT_EXPECT_EQ(test, 1, slab_errors); } +static void test_krealloc_redzone_zeroing(struct kunit *test) +{ + char *p; + int i; + + KUNIT_TEST_REQUIRES(test, __slub_debug_enabled()); + + /* Allocate a 64B kmalloc object */ + p = kzalloc(48, GFP_KERNEL); + if (unlikely(is_kfence_address(p))) { + kfree(p); + return; + } + memset(p, 0xff, 48); + + kasan_disable_current(); + OPTIMIZER_HIDE_VAR(p); + + /* Test shrink */ + p = krealloc(p, 40, GFP_KERNEL | __GFP_ZERO); + for (i = 40; i < 64; i++) + KUNIT_EXPECT_EQ(test, p[i], SLUB_RED_ACTIVE); + + /* Test grow within the same 64B kmalloc object */ + p = krealloc(p, 56, GFP_KERNEL | __GFP_ZERO); + for (i = 40; i < 56; i++) + KUNIT_EXPECT_EQ(test, p[i], 0); + for (i = 56; i < 64; i++) + KUNIT_EXPECT_EQ(test, p[i], SLUB_RED_ACTIVE); + + /* Test grow with allocating a bigger 128B object */ + p = krealloc(p, 112, GFP_KERNEL | __GFP_ZERO); + if (unlikely(is_kfence_address(p))) + goto exit; + + for (i = 56; i < 112; i++) + KUNIT_EXPECT_EQ(test, p[i], 0); + for (i = 112; i < 128; i++) + KUNIT_EXPECT_EQ(test, p[i], SLUB_RED_ACTIVE); + +exit: + kfree(p); + kasan_enable_current(); +} + static int test_init(struct kunit *test) { slab_errors = 0; @@ -196,6 +241,7 @@ static int test_init(struct kunit *test) } static struct kunit_case test_cases[] = { + KUNIT_CASE(test_krealloc_redzone_zeroing), KUNIT_CASE(test_clobber_zone), #ifndef CONFIG_KASAN