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 E0799C46467 for ; Tue, 29 Nov 2022 13:33:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 694606B0073; Tue, 29 Nov 2022 08:33:19 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 61DD26B0074; Tue, 29 Nov 2022 08:33:19 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4BF096B007B; Tue, 29 Nov 2022 08:33:19 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 3B16C6B0073 for ; Tue, 29 Nov 2022 08:33:19 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 667B0A03CD for ; Tue, 29 Nov 2022 12:56:52 +0000 (UTC) X-FDA: 80186479464.28.80A9AAC Received: from mail-yb1-f177.google.com (mail-yb1-f177.google.com [209.85.219.177]) by imf12.hostedemail.com (Postfix) with ESMTP id 22CE840010 for ; Tue, 29 Nov 2022 12:56:51 +0000 (UTC) Received: by mail-yb1-f177.google.com with SMTP id j196so17336358ybj.2 for ; Tue, 29 Nov 2022 04:56:51 -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=eQ2q70MxmrOTbyY/3idcvpot4MIQOw6xbYQRAtAnHRk=; b=k2CNqn4mmj4GxHren8t1/WpNcwnKbVDjdcpLv/RrGu2RoN9vE8ISGcNpmGrZUgp4x6 Pl3bgYcY5wHW3oNo/keuSbf9CYoAyPCy5gvbAATXwgkvlFVnte370kxzSxozhMrV70N9 54bb4mbKdDeALTNypg9O7h5clw2O+BOLf9O5Bh/evHwxwHwdgtrIpXLZejf3XCie9DLp z46XKJL3U2KAdzHAAI0ki2IjRsKDKTdEiA0ffrm/Q17I3YEwBtn4mI8K28phKEHjt9vc Tzwu2o0PyOR3EmYssrhwKDEyU/w/wO9BcrMeHUIajjRrW9JtAUx7pxuQDdqEP8gay66H gBxQ== 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=eQ2q70MxmrOTbyY/3idcvpot4MIQOw6xbYQRAtAnHRk=; b=5M/l2hFLs6Ih9CvsbAKsTLxKTFgg0mNemQRVwVhfYB+BGu9HsLZnT51RXRbnLY9zep YJYL59zJN6ZxYkq2pLa961mmOF9wdQzRAXAkgFlQAZyYmcomTSki0/DIfuIRmdiQi6ps pgZ37ND4wbOSktH5ZbWMJgroe6wQsjwwj+D9d5U/o0fai4TFsvOF2xCROiLRtCtJoUbe efuq46Ca1E+vC2JkdLvMjo/CdfIkx9yKYuTgb6tnKFiEydUQ/6jjNDH7LCeEwSUVenrM XiD+yhB5XuMmYYwac7lsQQlqTjl9AA3kVT3JnGwBK8iadjjKxQKPZYDHuO4eAFOvVYnu IOKA== X-Gm-Message-State: ANoB5pk9+xuVH2+EVY+Q8BkMe5isppIPWah0jG9rlevMG9cYrqlM552E O0gIghjzaMG5DzBpQfzSopRxgafmzBfgmvrv0gJxpA== X-Google-Smtp-Source: AA0mqf4PQ4Y68c2XrynpIIxjyPxdSRYah17bCPQEUU08Zqa1ulpRxof1sNCWke5miQDd6dOMZUbUAmVyyD43g37IsPM= X-Received: by 2002:a25:e749:0:b0:6f1:9eb8:76d4 with SMTP id e70-20020a25e749000000b006f19eb876d4mr24173229ybh.143.1669726611154; Tue, 29 Nov 2022 04:56:51 -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: From: Marco Elver Date: Tue, 29 Nov 2022 13:56:15 +0100 Message-ID: Subject: Re: [PATCH v2 2/2] mm/slub, kunit: Add a test case for kmalloc redzone check To: Feng Tang Cc: Vlastimil Babka , 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-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=k2CNqn4m; spf=pass (imf12.hostedemail.com: domain of elver@google.com designates 209.85.219.177 as permitted sender) smtp.mailfrom=elver@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669726612; a=rsa-sha256; cv=none; b=5x9HEX/O9k1yTa3nIS095uft3vKQr/DDZDNqkvG6RJJxjw/2fBVPcmwNniF0M3oLJVLKSl aQnpH+a+/njGvKHntgYoJQ/gS5wPH9RXpnxoyVj5vqNdvTeLMiT9dZfV0A4LyXqp0Aa4Nx V8/tKjydPgvRQS9iWFQ+vTwozNWkX1A= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669726612; 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=eQ2q70MxmrOTbyY/3idcvpot4MIQOw6xbYQRAtAnHRk=; b=t/mskJg0FG3164aYO+ELPnD56kXpdu1o+Vhcf+Qr7aOL1hkaZGQPF6Z9z+DRltJLBS5OHk RYzITXosvTUxjin0II48ZAhkEyU7S+GaqBnX73hqmAvnrOoa6K4K5yAkGCk9fzD+CP85OT rU84DV+2vbfQZ/v4bPyXX5BZi9bMjJ8= Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=k2CNqn4m; spf=pass (imf12.hostedemail.com: domain of elver@google.com designates 209.85.219.177 as permitted sender) smtp.mailfrom=elver@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 22CE840010 X-Stat-Signature: tzeci7nbrm6m1xxq14dwnyx7hfgnu4ui X-Rspam-User: X-HE-Tag: 1669726611-150223 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 13:53, Feng Tang wrote: > > On Tue, Nov 29, 2022 at 08:02:51PM +0800, Vlastimil Babka wrote: > > On 11/29/22 12:48, Marco Elver wrote: > > > 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: > > > > > >> 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. > > > > Yeah, that's what I meant. But slub_kunit.c could still have own internal > > cache creation function so the "|SLAB_NO_USER_FLAGS" and "s->flags |= > > SLAB_SKIP_KFENCE" is not repeated X times. > > I just quickly tried adding a new wrapper, like > > struct kmem_cache *debug_kmem_cache_create(const char *name, unsigned int size, > unsigned int align, slab_flags_t flags, > void (*ctor)(void *), slab_flags_t debug_flags); > > and found that, IIUC, both SLAB_KMALLOC and SLAB_NO_USER are creation > time flag, while SLAB_SKIP_KFENCE is an allocation runtime flag which > could be set after creation. > > So how about use the initial suggestion from Vlastimil to set the > SKIP_KFENCE flag through an internal wrapper in slub_kunit.c? > > /* Only for debug and test use, to skip kfence allocation */ > static inline void kmem_cache_skip_kfence(struct kmem_cache *s) > { > s->flags |= SLAB_SKIP_KFENCE; > } Yes, that's fine - as long as it's local to slub_kunit.c, this seems very reasonable. Thanks, -- Marco