Received: by 2002:a05:6a10:2785:0:0:0:0 with SMTP id ia5csp2512943pxb; Mon, 11 Jan 2021 11:32:48 -0800 (PST) X-Google-Smtp-Source: ABdhPJyDu5BQdZKczeSgC5nAjFs9dOBaHg9zSoPFsyeg6OFWUkAkbVT/ZTr836WzIseo5EZfp0Ka X-Received: by 2002:a17:906:6a8a:: with SMTP id p10mr648359ejr.169.1610393567780; Mon, 11 Jan 2021 11:32:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610393567; cv=none; d=google.com; s=arc-20160816; b=Z842yiiodo7k7gqNp1fGkkUlw3eL/tRz0EfubHXwAA4AP1Yb7uwpnq4F8mkGWxKYkh WT4xeWpMl94/Qw716F8mLjkw7jUxJtftm0RTGlY7Bxc+tERCOhtA1RRJ88n7BJ1w4GjD uNGfuXXf0g39O3UInMRt+BFti/f5KJA9FrcVWDnmN0AJtYOeTTNPbJPE0wxVnG6htMsA 046xwWLXEhXQQ8kq9E3tdpuZg4ZDX3VCkz3hgJ4VIYaSO4wPnxnCJnnVCuO50nxsv2Rj tWfysaX6ZjIdL++zSWCcdrIa0QsFwIZCz707qqeMMoAaVb1x02n37lGURLbe9qZN/bvc QKmA== 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=qo2fQAXd+OsMiLPHSUfSpNVkpbDbRR3kE8tJYakNl9E=; b=S0y4Vi0/C957n42Av0+FBquUJaAUMZy73/9C7QDY7LpHl+yxseiECdB0mxEgtxfrFN PyeyIr6XPALKkd3gIP5jpuO04hx0BV2kRx6PgAJQW17e/X6n9uzpOWiN4bG0xQC6F1VJ xTEJe3kcO7eR3z2xO8YZigjILNItFjDSCpmcxrPFvEaDmgpoLKQPOz5m9KYbtYDKSwoo O5yHr6NzNhQMd2tvCFsP8vxHO6qhw3Mqvqn9FMDgtmqOi34xeobhJ/B/RxNoMmiFyeYI 812r/2pPw5up0gepMQACWvGV4O2EGV38VewY3HMeymrUCZlSt43vxOM059K0yZC8Lfra vYGg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=ax0g20+i; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id x20si268586edv.330.2021.01.11.11.32.23; Mon, 11 Jan 2021 11:32:47 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=ax0g20+i; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S2403886AbhAKTbU (ORCPT + 99 others); Mon, 11 Jan 2021 14:31:20 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46258 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732738AbhAKTbU (ORCPT ); Mon, 11 Jan 2021 14:31:20 -0500 Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 39FA6C061794 for ; Mon, 11 Jan 2021 11:30:40 -0800 (PST) Received: by mail-pg1-x529.google.com with SMTP id c132so325892pga.3 for ; Mon, 11 Jan 2021 11:30:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qo2fQAXd+OsMiLPHSUfSpNVkpbDbRR3kE8tJYakNl9E=; b=ax0g20+io9+hknWBPpMxAQv86e3BV9BnGMFgIqXJ9pFv1sGGayp8i3795ZIxSkMX8w sbhmLQZbNam8/SGqG8EAQzIj2k55phmPp6LF3oUCv0Ys+SZvKDJPdZpq7/YAVAXY8s62 c+LidHl99KI5JXqsljDZrcrpJPEMVXH4vAL6MtI56FSRor4vCDSD3vv0bg3IWq5cVANZ GLDHUEO3zwD0hgxSKUdlCf1dsNIbmaiekqEHoyzlSXmDfWpvhMESBCOXOTlLrxsfjlJv Y8Y43ATIACr24S3GqGb6p3pg5RaYkhN0eHtAvg/DD7XAGQCRN6gUP267twpShI2WGMvP QX6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qo2fQAXd+OsMiLPHSUfSpNVkpbDbRR3kE8tJYakNl9E=; b=g5fWgT2pso2pq2ZNhmyW5AnqOYSk1+JxM2eWJWP4Nfltn1MEg3uf1GKwcJHfRqPJ4B b1LLiGf6wzSOwAqiXwMINOm4g/2LxY7k49rJGSHFHVe709iHlKFEYTGk9FtgKtKokEYB JUve20x64+7B2aT1AzWcIaZay0a7JpGHWbIIq4Ul9lv8LfOMMYmM897TdNbJvnscgpxQ R1/qd+4VPH8ITqFX3gpPVwqcbIyjjlAIB0Jw+0DrutLKmWK51QjDZ2aoatNVxHxr0H2l fi5W/LzkYd5zYiwzQqkWUHnwwiYyalTdmMuWteOVbakLroYnvjZP32c2fZv4HOksJyca WtCA== X-Gm-Message-State: AOAM531dfayVl9Fcp0kkkqFpWn9zswO7FAkgCD7PRVoM7JtX263hxjNn iLflsMPc/0Ka++TnL5AsP/FNp6a+9Hc1Ii/u/Yvuuw== X-Received: by 2002:a62:e309:0:b029:1ae:5b4a:3199 with SMTP id g9-20020a62e3090000b02901ae5b4a3199mr927134pfh.24.1610393439604; Mon, 11 Jan 2021 11:30:39 -0800 (PST) MIME-Version: 1.0 References: <20210108040940.1138-1-walter-zh.wu@mediatek.com> <20210111185902.GA2112090@ubuntu-m3-large-x86> <20210111191154.GA2941328@ubuntu-m3-large-x86> In-Reply-To: <20210111191154.GA2941328@ubuntu-m3-large-x86> From: Andrey Konovalov Date: Mon, 11 Jan 2021 20:30:28 +0100 Message-ID: Subject: Re: [PATCH v3] kasan: remove redundant config option To: Nathan Chancellor Cc: Walter Wu , Andrey Ryabinin , Alexander Potapenko , Dmitry Vyukov , Andrew Morton , kasan-dev , Linux Memory Management List , LKML , Linux ARM , wsd_upstream , "moderated list:ARM/Mediatek SoC..." Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 11, 2021 at 8:11 PM Nathan Chancellor wrote: > > On Mon, Jan 11, 2021 at 08:03:29PM +0100, Andrey Konovalov wrote: > > On Mon, Jan 11, 2021 at 7:59 PM Nathan Chancellor > > wrote: > > > > > > > > -config KASAN_STACK_ENABLE > > > > > +config KASAN_STACK > > > > > bool "Enable stack instrumentation (unsafe)" if CC_IS_CLANG && !COMPILE_TEST > > > > > > > > Does this syntax mean that KASAN_STACK is only present for > > > > CC_IS_CLANG? Or that it can only be disabled for CC_IS_CLANG? > > > > > > It means that the option can only be disabled for clang. > > > > OK, got it. > > > > > > Anyway, I think it's better to 1. allow to control KASAN_STACK > > > > regardless of the compiler (as it was possible before), and 2. avoid > > > > > > It has never been possible to control KASAN_STACK for GCC because of the > > > bool ... if ... syntax. This patch does not change that logic. Making it > > > possible to control KASAN_STACK with GCC seems fine but that is going to > > > be a new change that would probably be suited for a new patch on top of > > > this one. > > > > The if syntax was never applied to KASAN_STACK, only to > > KASAN_STACK_ENABLE, so it should have been possible (although I've > > never specifically tried it). > > CONFIG_KASAN_STACK was not a user selectable symbol so it was always 1 > for GCC. Ah, indeed. Thanks for the clarification!