Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp711146rwb; Tue, 29 Nov 2022 04:31:39 -0800 (PST) X-Google-Smtp-Source: AA0mqf4XZJXcC+3GZQfMJC1eUWpvrkcpbYayPUnlAS9o6RQ5lzXOayN9IX67JgYx+Ez3AqsA0bMi X-Received: by 2002:a05:6402:2421:b0:461:524f:a8f4 with SMTP id t33-20020a056402242100b00461524fa8f4mr51089128eda.260.1669725098857; Tue, 29 Nov 2022 04:31:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669725098; cv=none; d=google.com; s=arc-20160816; b=cT3u8N3LzqD9NoQpi5xnq9oMlEcZZ0T+evVpiwin8z+gQqHdpOncU18isowuzvfF+5 tOZa59t2vmJkg1Lc+j8RAFHW2DG2J9Co4fW3Rgpd1Nkh7rnk+8padDyZopL8/QnejgyI KZ5dstgyX28hshCiZ7RAPu979F2t4OotQ38lDG12aWY93acs7beHdqee84JnOxzzQs00 8xcqRz0er2ZvEjMQJMBHzUyFM3Ev/UHtGgACWHItsHBq7Bm1unAgfSMB+kxCXkn0jurQ v2z3Mcs02lO9s7rJyNvBdBw0xzQ6lxKRfokQS+2UzgvSmYM89kZZXAtQb9lSNcW8p6i3 BLJg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=KToa7R+tWe57h7Q6F1qr7Lg0Ngx6h/6bFBMqGMkri9A=; b=0af+PuJkrdE4Dq6f5fom4t7yliXVXL54sdXDda0PKdhiTjNTspJyDYKnR/+RlLxDl4 5d101/XKu7ndwqJNj+DrTAK1vQfrbPfYY4SgGYGDYH69HkJ5dbwwIzHia9kF9pGPaK69 cr6f1pEpxeCRb9DilmLgaIZE+O6OC7ryWiR2/p8ME1yed6MVVNLSo1Lo2O1JZYq5iyP9 Yjc8suBVT+8BnJJAbL6K6u526X3mpnEaWx8udJztnUAs9M8cX7swCt/IjMtD+6sKFHki oAS7eqPsNGwInkVhkqO/F8eWXNrNqro+TRkU3x0UARiGVLAVY83YT3jwmUM2JOC7gfeR Q2VA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=KWg1WWNq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id cs13-20020a170906dc8d00b0078d4ba46622si13544044ejc.616.2022.11.29.04.31.18; Tue, 29 Nov 2022 04:31:38 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=KWg1WWNq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230508AbiK2Lte (ORCPT + 84 others); Tue, 29 Nov 2022 06:49:34 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50934 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229957AbiK2Ltc (ORCPT ); Tue, 29 Nov 2022 06:49:32 -0500 Received: from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com [IPv6:2607:f8b0:4864:20::b29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1CBD624090 for ; Tue, 29 Nov 2022 03:49:32 -0800 (PST) Received: by mail-yb1-xb29.google.com with SMTP id y83so17086639yby.12 for ; Tue, 29 Nov 2022 03:49:32 -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=PFG7F2qfP5djZgWATWVy5jzoCEQHnH7jj6FiHTIcjsXtaRjiSSDuPW/M+S84do7fH7 qTJ4q6JLeJlb5PNmjhxEADQJY75VRLi8u+ixPbZkd3in2wQq2tMTMzfvQ54K5rGZxkzJ f58FHGQ0ZrBhHM+kWG0iDzosS/TY7OssR45G6uaahO/36tlN8S7njuGbxN9FOv1SDtcD lg6Rpkdyq2ViRzRi3F5j+ZWuQJOhee6TD1irBgf4wYqtk9ajGIuHDQurD/YQkUmrFNW+ xPGoMmBOcxuZsBHTj0ZzUNdE68GFcQG0V5lnTXYE6acjOIBc0AV8+55w09XwbNw3LnD/ AC2Q== X-Gm-Message-State: ANoB5pl/aMUi1u5X9h6zO5DG/5oqdZJPmsR6S9atmTJBT9UBCRX8CLht elAeOagAXC3+sq/V0fs2PNxMlykGdLRDfyZsfq23lA== 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" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.