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 1A166C4321E for ; Tue, 29 Nov 2022 14:16:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A51856B0072; Tue, 29 Nov 2022 09:16:58 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9DAB36B0074; Tue, 29 Nov 2022 09:16:58 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 87B2B6B0075; Tue, 29 Nov 2022 09:16:58 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 76AF66B0072 for ; Tue, 29 Nov 2022 09:16:58 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 78AE5AB24B for ; Tue, 29 Nov 2022 11:49:32 +0000 (UTC) X-FDA: 80186309784.13.0D25C17 Received: from mail-yb1-f177.google.com (mail-yb1-f177.google.com [209.85.219.177]) by imf08.hostedemail.com (Postfix) with ESMTP id 2381016000D for ; Tue, 29 Nov 2022 11:49:31 +0000 (UTC) Received: by mail-yb1-f177.google.com with SMTP id c140so17077310ybf.11 for ; Tue, 29 Nov 2022 03:49:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=KToa7R+tWe57h7Q6F1qr7Lg0Ngx6h/6bFBMqGMkri9A=; b=KWg1WWNqRJYvzYf/3YzwExxOx4ZsMdhCUFqoUpySN1QuMIIERwQ6HLgQ9kXuwvwSFA 8WXWjIiCcWG5eBC1Le1kEqGnZOEDw8rUYpit45TFyB7ZVNmP2IvH+qNoAjMSvjZFQex5 pNQh2kHhnu7VStMCG5XEfaWLSnWpX8RX1VANUlFrNJCYMJZUDyZO/VWktHOnKk12YGcX UQ0Wtkdzj+lo0YIOfm2b9glRQlAaUcN7HbwP3kTSPFesqZY4c2deBRUnOSlckaI+qyMx f+MFduF22j8WT3IcyPw+UDZHEPUSHmOZqQiPJNA5ZiGq+ejHIR89QSVLfPPGyaw7Yk9H wbsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=KToa7R+tWe57h7Q6F1qr7Lg0Ngx6h/6bFBMqGMkri9A=; b=259QGL38StpGgAwZFG7E13NbGfD+HacK8nxe04VlSHxg1Oic0rxoXBEV20Iqld0EIO W7B1euO0CiwNGMHLbyk0v1VjjCMgRZe+a3Hoc2txdX9qbm7sUPNtyJAb5aYuklNYA5bg 2ky14mGE9RuK+OCA8XMl5MgWjxE49WGsBXFCxqxek+8Soj7WHeN+PD3mL9EZZT3k37c+ vMiWk58uBjln0FgDNUL06tAuj11WAV/nPqKDJgp5UPLqGF4fkSxU50JCtLT6sGOPiy4H 7Rlh5G+zC7W2G1/XJEUSas8b4bigWR3CPA7ykpiXMLcHFymAY0sJA+Fvj7MzFkGCYsHM C69w== X-Gm-Message-State: ANoB5pmLBApXuI1XHY94T/PGV+sQ0i9LURd81YG2Gfj7pUjK6u9T4rST WAm5apOTrCCqViWAiAzO/AVso35yiAVIGvqVwPT9Gg== X-Google-Smtp-Source: AA0mqf4xYINL19aZTRyDO6h3n08BWVgOeiNMBrRMJNyWu1Pugy+10+BnYK+927KL0NuECb64gZOwp0MlnbUuucUNuCg= X-Received: by 2002:a25:e749:0:b0:6f1:9eb8:76d4 with SMTP id e70-20020a25e749000000b006f19eb876d4mr23938630ybh.143.1669722571129; Tue, 29 Nov 2022 03:49:31 -0800 (PST) MIME-Version: 1.0 References: <20221129063358.3012362-1-feng.tang@intel.com> <20221129063358.3012362-2-feng.tang@intel.com> <67e6ebce-f8cc-7d28-5e85-8a3909c2d180@suse.cz> In-Reply-To: <67e6ebce-f8cc-7d28-5e85-8a3909c2d180@suse.cz> From: Marco Elver Date: Tue, 29 Nov 2022 12:48:54 +0100 Message-ID: Subject: Re: [PATCH v2 2/2] mm/slub, kunit: Add a test case for kmalloc redzone check To: Vlastimil Babka Cc: Feng Tang , Andrew Morton , Oliver Glitta , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com>, linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669722572; a=rsa-sha256; cv=none; b=tqHVucF9gGAzWRb0QzaCDK6S3sLKY5b/rySoGPkN7bC4qYpy5f8nMaB2R5A1vt5pqMdmKN YcvFvoR+4tAMJSKdZs9inu+KFPI9Q3tTURibdIuqHbUKxhhZLhiRrXG/MMvr+W2n7FjChw 8enubDyWfcKUnp9xGE1vaXSaAclKcmY= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=KWg1WWNq; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf08.hostedemail.com: domain of elver@google.com designates 209.85.219.177 as permitted sender) smtp.mailfrom=elver@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669722572; 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=KToa7R+tWe57h7Q6F1qr7Lg0Ngx6h/6bFBMqGMkri9A=; b=M3n7hUYlVCTDNM12L64xloK3YzB1epMbmEDHGzmJ626h45Lu31XvO9AQ59jWbM1CtGOiIi rXflSHqiVmxtNPTzWZ+65ddpbrVpJnmlgefof6jHznfgyF4uJtnv+hbtFki4C4ZH3mG/at ZaI4mL1sqto4Lydoe9DyReZia0S+M98= X-Rspamd-Queue-Id: 2381016000D X-Rspam-User: Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=KWg1WWNq; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf08.hostedemail.com: domain of elver@google.com designates 209.85.219.177 as permitted sender) smtp.mailfrom=elver@google.com X-Rspamd-Server: rspam09 X-Stat-Signature: wwqtxx1hp4jd1y5m5xaj8gfug5sgym4y X-HE-Tag: 1669722571-835084 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: On Tue, 29 Nov 2022 at 12:01, Vlastimil Babka wrote: > > On 11/29/22 10:31, Marco Elver wrote: > > On Tue, 29 Nov 2022 at 07:37, Feng Tang wrote: > >> diff --git a/mm/slab.h b/mm/slab.h > >> index c71590f3a22b..b6cd98b16ba7 100644 > >> --- a/mm/slab.h > >> +++ b/mm/slab.h > >> @@ -327,7 +327,8 @@ static inline slab_flags_t kmem_cache_flags(unsigned int object_size, > >> /* Legal flag mask for kmem_cache_create(), for various configurations */ > >> #define SLAB_CORE_FLAGS (SLAB_HWCACHE_ALIGN | SLAB_CACHE_DMA | \ > >> SLAB_CACHE_DMA32 | SLAB_PANIC | \ > >> - SLAB_TYPESAFE_BY_RCU | SLAB_DEBUG_OBJECTS ) > >> + SLAB_KMALLOC | SLAB_SKIP_KFENCE | \ > >> + SLAB_TYPESAFE_BY_RCU | SLAB_DEBUG_OBJECTS) > > > > Shouldn't this hunk be in the previous patch, otherwise that patch > > alone will fail? > > Good point. > > > This will also make SLAB_SKIP_KFENCE generally available to be used > > for cache creation. This is a significant change, and before it wasn't > > possible. Perhaps add a brief note to the commit message (or have a > > separate patch). We were trying to avoid making this possible, as it > > might be abused - however, given it's required for tests like these, I > > suppose there's no way around it. > > For SLAB_SKIP_KFENCE, we could also add the flag after creation to avoid > this trouble? After all there is a sysfs file to control it at runtime > anyway (via skip_kfence_store()). > In that case patch 1 would have to wrap kmem_cache_create() and the flag > addition with a new function to avoid repeating. That function could also be > adding SLAB_NO_USER_FLAGS to kmem_cache_create(), instead of the #define > DEFAULT_FLAGS. I wouldn't overcomplicate it, all we need is a way to say "this flag should not be used directly" - and only have it available via an indirect step. Availability via sysfs is one such step. And for tests, there are 2 options: 1. we could provide a function "kmem_cache_set_test_flags(cache, gfp_flags)" and define SLAB_TEST_FLAGS (which would include SLAB_SKIP_KFENCE). This still allows to set it generally, but should make abuse less likely due to the "test" in the name of that function. 2. just set it directly, s->flags |= SLAB_SKIP_KFENCE. If you're fine with #2, that seems simplest and would be my preference. > For SLAB_KMALLOC there's probably no such way unless we abuse the internal > APIs even more and call e.g. create_boot_cache() instead of > kmem_cache_create(). But that one is __init, so probably not. If we do > instead allow the flag, I wouldn't add it to SLAB_CORE_FLAGS but rather > SLAB_CACHE_FLAGS and SLAB_FLAGS_PERMITTED. I'd probably go with the simplest solution here.