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 X-Spam-Level: X-Spam-Status: No, score=-8.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 02A76C35240 for ; Tue, 28 Jan 2020 09:08:52 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id BA71024684 for ; Tue, 28 Jan 2020 09:08:51 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="UBM+ALw8" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BA71024684 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 5D5C76B000E; Tue, 28 Jan 2020 04:08:51 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 55D9D6B0266; Tue, 28 Jan 2020 04:08:51 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3FF4F6B0269; Tue, 28 Jan 2020 04:08:51 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0237.hostedemail.com [216.40.44.237]) by kanga.kvack.org (Postfix) with ESMTP id 22E1F6B000E for ; Tue, 28 Jan 2020 04:08:51 -0500 (EST) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id B45D48248047 for ; Tue, 28 Jan 2020 09:08:50 +0000 (UTC) X-FDA: 76426468020.01.whip74_4d29a52028514 X-HE-Tag: whip74_4d29a52028514 X-Filterd-Recvd-Size: 5365 Received: from mail-qv1-f68.google.com (mail-qv1-f68.google.com [209.85.219.68]) by imf03.hostedemail.com (Postfix) with ESMTP for ; Tue, 28 Jan 2020 09:08:50 +0000 (UTC) Received: by mail-qv1-f68.google.com with SMTP id o18so5900454qvf.1 for ; Tue, 28 Jan 2020 01:08:50 -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=V9xAyfYvshxDtwWMgT0zgZJ0j7N3J44CYOXm6ENX55s=; b=UBM+ALw8CpI4ev4pjKDHghR0t6BBgD/1R2c9dxpJJ6uPN9cRyxne6hUg5PZwNOH19H hALAbYYOUfFDKSm9eXlQN/NN9tzITc8DjLZasBqt0hIvKjly0Ib0N0yaoST95Mz7bcOH yHUd/Ry/FDID53tCKpDPzxkj2EC5C/cx2d3fJ5OCFyt/5hV84RF+AVzLtLlKjUUmLdPv PIDvbbRM4Azq4pGaUJRRihjz1nnK1UZxiMh5EIoaA2yPIjBtT0ylGPpHdc8NExuKyL76 3FToEHAO9Du/AIujx4S9AAJSMPjihk4fOihEnKx8WkOM42Nx51bgYn4zoo+7/j+a0o2i B/ig== 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=V9xAyfYvshxDtwWMgT0zgZJ0j7N3J44CYOXm6ENX55s=; b=dzXhzfU7bKFwNXqdP1sjabjzDqTtOmGm5EZ5CzdQ3qtne9Vel2tcZ3hO9WWC79Agjd 6MNeabDMLlVUYQPbDUT2m+Tk6gLDL1hoBog3G7YNwdUmkf+dwxO14My+M0apF1+oijHl pyonx7PfdcPiVU65gUOmeYD2qrUPZUc61afVnwVbwYwB8GUc17/bOLDxjNF+whjA+4DJ H3hKafyp/bOUi4dCE8v8A5YZkNacWZklRP78wVhA4AbCmBvUrCpp4k83rljmkQ/5xEe3 SOUKuO+xz9/AsaBgmyYHZK+AQfY7DCxQQqU52f4tHRIAo9/sFGzrRyFMvXqWXpsF+BQQ 1UhQ== X-Gm-Message-State: APjAAAVmm2/CD/ZVZuWBfYySXW0ozlrrffViPkelN22TRBKaUOesp3rs lbffj0ngTOBunm98T+B74sG57oy97T8bHZoE6d8v8g== X-Google-Smtp-Source: APXvYqyLGSeVtyPa6QvM+kGBBxvn+S/PP0KC3EUV34HcvopeZQfmGmHJBrOqaSvVp0ThT/bYujA9Vllz/L/0apuA1W4= X-Received: by 2002:a05:6214:1874:: with SMTP id eh20mr21684750qvb.122.1580202529263; Tue, 28 Jan 2020 01:08:49 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dmitry Vyukov Date: Tue, 28 Jan 2020 10:08:37 +0100 Message-ID: Subject: Re: mmotm 2020-01-23-21-12 uploaded (efi) To: Ard Biesheuvel Cc: Qian Cai , Randy Dunlap , Andrew Morton , Mark Brown , linux-fsdevel , Linux Kernel Mailing List , Linux-MM , Linux-Next Mailing List , Michal Hocko , mm-commits@vger.kernel.org, Stephen Rothwell , Ard Biesheuvel , linux-efi , kasan-dev Content-Type: text/plain; charset="UTF-8" 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, Jan 28, 2020 at 8:33 AM Ard Biesheuvel wrote: > > > > Should be fixed by > > > > > > > > https://lore.kernel.org/linux-efi/20200121093912.5246-1-ardb@kernel.org/ > > > > > > Cc kasan-devel@ > > > > > > If everyone has to disable KASAN for the whole subdirectories like this, I am worried about we are losing testing coverage fairly quickly. Is there a bug in compiler? > > > > My understanding is that this is invalid C code in the first place, > > no? It just happened to compile with some compilers, some options and > > probably only with high optimization level. > > No, this is not true. The whole point of favoring IS_ENABLED(...) over > #ifdef ... has always been that the code remains visible to the > compiler, regardless of whether the option is selected or not, but > that it gets optimized away entirely. The linker errors prove that > there is dead code remaining in the object files, which means we can > no longer rely on IS_ENABLED() to work as intended. I agree that exposing more code to compiler is good, I prefer to do it as well. But I don't see how this proves anything wrt this particular code being invalid C. Called functions still need to be defined. There is no notion of dead code in C. Yes, this highly depends on compiler, options, optimization level, etc. Some combinations may work, some won't. E.g. my compiler compiles it just fine (clang 10) without disabling instrumentation... what does it prove? I don't know. To clarify: I completely don't object to patching this case in gcc with -O2, it just may be hard to find anybody willing to do this work if we are talking about fixing compilation of invalid code. > > There is a known, simple fix that is used throughout the kernel - > > provide empty static inline stub, or put whole calls under ifdef. > > No, sorry, that doesn't work for me. I think it is great that we have > diagnostic features that are as powerful as KASAN, but if they require > code changes beyond enable/disable, I am not going to rely on them.