Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp6204352iob; Tue, 10 May 2022 12:46:52 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwSFykCkDw7XJWcBgPeEq3mGc5COUgHxf0DXw4BfI0Bbdt1Z7xCCqExUO7mWLLGS4b3sRv+ X-Received: by 2002:a63:43c2:0:b0:3c1:829a:5602 with SMTP id q185-20020a6343c2000000b003c1829a5602mr18401968pga.252.1652212012121; Tue, 10 May 2022 12:46:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652212012; cv=none; d=google.com; s=arc-20160816; b=K4DXfod6O5TMvIadswXZ1s/HZHcQjdnZCU6Jg1pgs8yWa6aSMLOGYQ0w/Ybm28JaX0 czYSGpvTPaoJLCfx933kp41TmCncWihtxkPjrtqInbcTuP5SqbbjFheYaAmlutWF4JFF rtpREB40bboBEO8978bk8Vj/S2MASOdcfOiAezJZ22c416xlXlbl2AuNL7mR2dMZkass 1Vtyovlz4GEK4iV8i30nBsUb3Mz8DACBjI6wFxnG8xfR0mioej0wICQNC8ZkUcOGPhjo Ui6my9CKCVdiBSLZry8II1iVcjoNWHXuIHe8ZMepTx7XGRJXbqMoHF0LCio2ZjhlrtcZ PXrA== 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=qBpP6H1QXIcItowN4taveL7xKKbFDSnKJ/RJbBSFPLc=; b=e00lU12wkd6x+IhKMFq4eBqsCHA8vyNx9ezWJQQJ65rscydrx5ib70YpsagB+ijOd/ f7ccspXRFT/Z/7RyZ6C7Jr0eVg04inVxPmo5S1DTmbCHCBN167CTgIAnvlI09MbWKx3f DT8+IKMp8Mztg/GXJVk23YC5X1tZFQUvatzZFizDt0a4yT8ZEXkJha34yyj2a7guYHhe itxTfKPJSPfc7szUsCmWz08Mn9Nb7GaOUVPN8yjd8VJt/EBBa40YGQaqVPxWGCOZC8yO i2bVWB0UNDf/likrguhCvAC9B2+pFDjUwUiE66jVXYXFPoxoX4dUmBIXMzDC/EPN9lO4 DBdA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=Lt7mUYnn; 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=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id e4-20020a170902744400b00158bfb59d03si3758459plt.382.2022.05.10.12.46.36; Tue, 10 May 2022 12:46:52 -0700 (PDT) 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=@gmail.com header.s=20210112 header.b=Lt7mUYnn; 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=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347923AbiEJRYf (ORCPT + 99 others); Tue, 10 May 2022 13:24:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41588 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237841AbiEJRY3 (ORCPT ); Tue, 10 May 2022 13:24:29 -0400 Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0CE2F268652 for ; Tue, 10 May 2022 10:20:32 -0700 (PDT) Received: by mail-il1-x130.google.com with SMTP id 3so8838125ily.2 for ; Tue, 10 May 2022 10:20:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qBpP6H1QXIcItowN4taveL7xKKbFDSnKJ/RJbBSFPLc=; b=Lt7mUYnnSclD1NWgc2asYmgfRPG7Azod9mS1i2Jh8ultjaohoNhp9mUqvPMvwKfeFX +3lH2aXb4zAOEjHUEIh/QVpMfpb9lKwD1l33mRtYpWmJOuh9xpwJWcEVBzirx6yRiesk WDtra/VPQTon4LSEOjPwOfjDj5UL5OodfpB/IY8DYaUQSBbceMfgj7BfdTiPDcbWkcll t5vePG3fWKJma1cjQnbkPeCrEoMcTseLIfxwK+ZqjFpnr0DHujza42/uicb0xoV9VzGW pTeZVOaE5ChLPaILdSZp6y/jgaoW5QXbz0KwNageXa1xo4t9su4rAvd/x9qBn+UIntVt 3dog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qBpP6H1QXIcItowN4taveL7xKKbFDSnKJ/RJbBSFPLc=; b=XcdGTK5NSZrP8BRWtIvbxicU8U7aQ8CnFkpBye5ssuBbPW8Du7LnlcF+aWY13q2y2a 6ejC20kbazbn5t4ShFSPJkRf4aSoj9GDuJBVApE9VGkgoQoR1M/YlXgv7Gws/9rbbCjS X3NEgOxwGc1+KXWjTzYxcsYXbHnT2Ih20YJIsvvDelQgacNfDrm/JpuJBfdntnMZBbr8 wUQbXdeQYPZozHVa4aFYi3g6HZCze4WcZgpXX/gNVw7pzBCAcBebQzWNMRULAPY7JgnS xX+YWFGF+PlqjCVVn1DkuG7A/QOzZc2E39luBaTZX5iYn0vWlOhmuDqzYBe/oFGWYqBb hjPw== X-Gm-Message-State: AOAM533z9cATzjlHLYepb6GFRftUb1A4IR/PjDIc8tZ8CRb4y+uWBY+m ygBLRkubTTzo9KS2//e7lwjqTCIlKO5ylYyHkYg= X-Received: by 2002:a92:3609:0:b0:2c6:3595:2a25 with SMTP id d9-20020a923609000000b002c635952a25mr9876403ila.233.1652203231521; Tue, 10 May 2022 10:20:31 -0700 (PDT) MIME-Version: 1.0 References: <5bd58ebebf066593ce0e1d265d60278b5f5a1874.1652123204.git.andreyknvl@google.com> <47afaecec29221347bee49f58c258ac1ced3b429.1652123204.git.andreyknvl@google.com> In-Reply-To: From: Andrey Konovalov Date: Tue, 10 May 2022 19:20:20 +0200 Message-ID: Subject: Re: [PATCH 3/3] kasan: clean-up kconfig options descriptions To: Marco Elver Cc: andrey.konovalov@linux.dev, Alexander Potapenko , Dmitry Vyukov , Andrey Ryabinin , kasan-dev , Andrew Morton , Linux Memory Management List , LKML , Andrey Konovalov Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE 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, May 10, 2022 at 1:57 PM Marco Elver wrote: > > > - Currently CONFIG_KASAN_GENERIC doesn't work with CONFIG_DEBUG_SLAB > > - (the resulting kernel does not boot). > > + (Incompatible with CONFIG_DEBUG_SLAB: the kernel does not boot.) > > Why aren't they made mutually exclusive via Kconfig constraints? Does it > work these days? > > Either KASAN_GENERIC and KASAN_SW_TAGS do "depends on !DEBUG_SLAB || > COMPILE_TEST", or DEBUG_SLAB does "depends on !(KASAN_GENERIC || KASAN_SW_TAGS) || COMPILE_TEST". > > I feel DEBUG_SLAB might not be used very much these days, so perhaps > DEBUG_SLAB should add the constraint, also given KASAN is the better > debugging aid. They are made exclusive: it's the KASAN option that depends on !DEBUG_SLAB. And KASAN_HW_TAGS doesn't have this note, as it doesn't work with SLAB at all at the moment. Moving the constraint to DEBUG_SLAB might make sense, but let's keep this patchset as a non-functional change. Thanks!