From patchwork Wed Sep 11 06:45:31 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Feng Tang X-Patchwork-Id: 13799745 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 1C3E0EE0211 for ; Wed, 11 Sep 2024 06:45:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8F54A90000D; Wed, 11 Sep 2024 02:45:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8A3E16B0384; Wed, 11 Sep 2024 02:45:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 792C490000D; Wed, 11 Sep 2024 02:45:56 -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 586736B0383 for ; Wed, 11 Sep 2024 02:45:56 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 039B6161038 for ; Wed, 11 Sep 2024 06:45:55 +0000 (UTC) X-FDA: 82551522312.09.1A38792 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.12]) by imf05.hostedemail.com (Postfix) with ESMTP id E29CE10000A for ; Wed, 11 Sep 2024 06:45:53 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=WuLi9yvr; spf=pass (imf05.hostedemail.com: domain of feng.tang@intel.com designates 198.175.65.12 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=1726037050; 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=wZNuj6wBkLP0SnWxYyCLS6aj5zno8YqWIFsVBbPmmqg=; b=tkdQfAh3Q7XAUXRy3bXc9qSc5hXVRQvHfVmLhkjqYEr6AucYEr/33D3nq4FvCQniKEF2Wn 62Ao1cL5c7/iJ9hsDu7bigDVjLEbLxXNYAO+bNYLMgbCjDSX9qSB0ptgcnFJRfWVIjkuW/ QFxuNzQ8eEW1NG55jIogssCjobrzZro= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1726037050; a=rsa-sha256; cv=none; b=hxUmzcjHPuVb8K4igKkJTQgAQvPql3y61GCHVmqBRbySVnbZQ6TsYE0o6zXedmEsIwiVNQ MTu0zk7ccHmVqtwTTn6w5Wt+n3xmoyQs4iA1mmA6ZbmiH59mkQeZ8NmhVQ3GoSDuv1lp2w XIILlohquNFlytovN+YAJ6at42TrZV4= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=WuLi9yvr; spf=pass (imf05.hostedemail.com: domain of feng.tang@intel.com designates 198.175.65.12 as permitted sender) smtp.mailfrom=feng.tang@intel.com; dmarc=pass (policy=none) header.from=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1726037154; x=1757573154; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=dM2adnqSdhHnHwASvqcFoX4V3rfZ14QoQNpiYKbsRgQ=; b=WuLi9yvr32gFRzOLgX151Fjk0jHCZYCi2lwa75m6uX0rFBOPd323K6ZX WG3WQb9kDX0saZoTBZUJOC2NmJ1YsADi6y17QE/8cJcSUsq1qQ3XDqnhn OwF8qmu4cUverB2XjD5L2tAUlEmRV3SI7TbIEM7yPX40tnTe02PD3w9Aw +RVCJ9KcPg2lsDwGISteDaioWcSGWgrudXabxRgn38qJISX1mFLsCk60B 0Q19cMBy6oVXswoilJTBX1WHNzXZI965H1S/FaQqOaDR1OqYsZX2qQsX1 7z/qWQbg4DpdbRoDcYBFLu36wDBFngaLVaCNQrVeHqWWyPKl3+wH4WiDh A==; X-CSE-ConnectionGUID: jgNEGqzPSGK15Ugn3hUElQ== X-CSE-MsgGUID: WB0rTQ+3R2ORsBTyahpbiA== X-IronPort-AV: E=McAfee;i="6700,10204,11191"; a="36172980" X-IronPort-AV: E=Sophos;i="6.10,219,1719903600"; d="scan'208";a="36172980" Received: from orviesa007.jf.intel.com ([10.64.159.147]) by orvoesa104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Sep 2024 23:45:52 -0700 X-CSE-ConnectionGUID: wcILiiZ3QmaqfhSIVIcfHw== X-CSE-MsgGUID: fx8JhJANRZCRTz/LvKdSHg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.10,219,1719903600"; d="scan'208";a="67771485" Received: from feng-clx.sh.intel.com ([10.239.159.50]) by orviesa007.jf.intel.com with ESMTP; 10 Sep 2024 23:45:41 -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 , Alexander Potapenko , Andrey Ryabinin , Dmitry Vyukov , Vincenzo Frascino Cc: linux-mm@kvack.org, kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org, Feng Tang Subject: [PATCH v2 1/5] mm/kasan: Don't store metadata inside kmalloc object when slub_debug_orig_size is on Date: Wed, 11 Sep 2024 14:45:31 +0800 Message-Id: <20240911064535.557650-2-feng.tang@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240911064535.557650-1-feng.tang@intel.com> References: <20240911064535.557650-1-feng.tang@intel.com> MIME-Version: 1.0 X-Stat-Signature: qs57n6h88ctryithy6xcu3ciakr8eyps X-Rspamd-Queue-Id: E29CE10000A X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1726037153-326967 X-HE-Meta: U2FsdGVkX1/5qAvM0ZmKkShpjefwMJ5Ox3DaQfX+Uan05EzeZH5zGEwq++As7SrUzueOac3AMEOS+ifQbUlqHBg8lFodOBVold3DplGFRAg9DQLVitNZ8DCkaQ6jk1w//34iNLUVCFuudiy5lendob5qxI19GHYKjtQVnKjpS9LMQAdpGIzDTbFvZsUbRUB2JVapVOmbuepoYZWcOFxf/SWy1Or73wasisq/Fum2OtdKNrITJOzxUfe6UvdyO67E5Q4S00kGn97x1erFRuV/NBSZ0lYTBQ5yExlrtaNML44jr/9tlRfZ9FLJBcpAyXsWuTWP/0gCwoyoALIg4V3fuBYSAIVxFXXZ8Z7TV7Xq1a3qGAQSN3+B/AakVK2hjPuNs/PM7+TmuHkf5ggp48ttb7Z4wVYvrFv4lD0Mmn4rC+q2Ncnml2RucorUY27q/YpbwMeQZJtKetbGZ52FMHkDWGI1sI586itiK0JfJBdQs2AKmU+RjjjVIYt8/50lIxoPilHibf+usXbbEZiX79hjp8XWVy7yYeQvBIIVzTEi2qDZdqjHfyLrFgTI2Yx98DF5ZNKfPDE0MtXK1F1WCh63m5gGOG8WgXp744dXhgUyS3NZvFvyDZSr9R6EUxYkLaTw1kl/tRrlkxTX2D0Q4s0aRTzv/IJqpC9ujVpdCGV8Ruv5fPvpJE1sFjuvI2xeqFlkqncB5TXCYKsqamF5JedR9kL8I1zQnRgq7+20AaJTFLr9xtHWFNns+O04+yiyUMEzMyOPMemlcu1XM8sv3I4dJW5cj6NqjPVQhGoymEKnY/tpTHEGliMA7rNP5QkS9FMHR2VcuuxFNnxjZyf2QjvsZuXwQqFkCj5E9Ya9TcAfRrLDGKWMbRZOSuttJxRsmTYKONrB5GLvwdx/6u2eTjPjxtuyhAjk3YLOfIIOVKCmo4yXsQDADADzJO90yIc6eRUr6rvX2ak93PUylT2eQUv M+i0YL7O qpa0uHcGHpxQyQ6lbRKd/2oUH/2ZBBHOzvVkPEeJ/2VElQwFOW0GT/lJH9Pzq2P3bAQRzSymNnE234KCcSd1YAg8irL7Mh9/pvGXbU5FFlsa5qmByBbQgGnD5FMEoJkKIEcmJ61IhIIfPn8QqRdwlr060j7ezWyv3YqRmGnnS0Vfyl0vEw/6aXMhumAxPETgdQWCWx/pJWTnw9G5QcPDEO48HR8F0M0WBLi8kvNWSi0rkiaa3T3ijr1esc/NdJrE4RnpAfZnXW0aZao5JmAfq6WEGWpgFEAATb9H5zifiRviYt8af1APwtSC++AuAMwvSub0w 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 | 7 +++++-- mm/slab.h | 6 ++++++ mm/slub.c | 17 ----------------- 3 files changed, 11 insertions(+), 19 deletions(-) diff --git a/mm/kasan/generic.c b/mm/kasan/generic.c index 6310a180278b..8b9e348113b1 100644 --- a/mm/kasan/generic.c +++ b/mm/kasan/generic.c @@ -392,9 +392,12 @@ void kasan_cache_create(struct kmem_cache *cache, unsigned int *size, * 1. Object is SLAB_TYPESAFE_BY_RCU, which means that it can * 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. + * retain its content until the next allocation, or + * 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 f22fb760b286..f72a8849b988 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 21f71cb6cc06..87c95f170f13 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;