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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 48A29C433EF for ; Thu, 11 Nov 2021 10:12:28 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E2E4861108 for ; Thu, 11 Nov 2021 10:12:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org E2E4861108 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 8388D6B0095; Thu, 11 Nov 2021 05:12:27 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7E9346B0096; Thu, 11 Nov 2021 05:12:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6AFF86B0098; Thu, 11 Nov 2021 05:12:27 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0154.hostedemail.com [216.40.44.154]) by kanga.kvack.org (Postfix) with ESMTP id 5DB166B0095 for ; Thu, 11 Nov 2021 05:12:27 -0500 (EST) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 2185418495711 for ; Thu, 11 Nov 2021 10:12:27 +0000 (UTC) X-FDA: 78796234692.26.55FEAFD Received: from mail-oi1-f172.google.com (mail-oi1-f172.google.com [209.85.167.172]) by imf30.hostedemail.com (Postfix) with ESMTP id 3BF6DE00199E for ; Thu, 11 Nov 2021 10:12:05 +0000 (UTC) Received: by mail-oi1-f172.google.com with SMTP id s139so10639831oie.13 for ; Thu, 11 Nov 2021 02:12:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=x2JqhGMyfJOncOO31VPKGQJKmpqXdotolWXJ0Sscp8s=; b=CkvxSK1EjyO2pbzkq70likXbwf1/G65ullJU9N53M5lbs4WkwpWvQGJ+xxcsj3R4uD vcqB3rJiaK92xh67IbFVu3lAHIG/znWaTUQunSIypYeP4CnnjeTNGIm+mf+o07hHuzxl uGRxyXOIOSGr3YpDTGHVku9ehCQPRKdT4tIjm0CwEBIHtMVhOjrry3RqCIKnpqVak7aE eT5E5GPsB+qwjtDL4GJrrCHtn/xG1iVwritcMgG8snngv+U9QVZApUx9jhk85/z97JqK c2iyK+Ej5z+UF/7SIqqzQxvu4fH5Ror0RgY3cEcQrowltSXdyTVkGunN2QHGRAJExYJh ldjw== 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=x2JqhGMyfJOncOO31VPKGQJKmpqXdotolWXJ0Sscp8s=; b=fGw5o/jdt+udXHxoEHywpoQsOFJNdpRHgB6q2eGGtjgatrmQ8rU3pCXm8P81rAQEnN JuLP7wHuH7h6JLyyd9iuz83MOPk0n8u6sr3dfsdxAdVbQQ2BcOJcSo1+e72lTNffqEMt 9/Jrl5U/meohSPoDwUw46cRsY/BpsfQTggHYwFYbcXhxGNePsgnuv5ek50zFdEfFlbss iOm4odl4UeNPoP9tqMZlI7avWleHaYlGfW7fTRsAUIPE0IT7z1/X9T8GWF+C3/0vxlmp V9cq5YWAf8RENrD/4t6LP0Et+58kcIpzNCWQp38iBA+SD7PjS74bUW/4R5CoCxEUGSZd cMqw== X-Gm-Message-State: AOAM530dXLdOOg7ZJQmSraAdvgiOsLkpreHb0peE4cY3LfX3BSFaPzPe Y1jEQPJwlESEk0TfEePFiUf3oYXcyZvjD0EJhUA7tQ== X-Google-Smtp-Source: ABdhPJz7epDTv5uCxOQ8Cm3nb9HVHDMTO19qLrlz3UwOWboYoIDGzDq9VXXEzngFTMgtlnhp8icDZqg8O4nzWcv7HOo= X-Received: by 2002:a05:6808:118c:: with SMTP id j12mr5116357oil.65.1636625545648; Thu, 11 Nov 2021 02:12:25 -0800 (PST) MIME-Version: 1.0 References: <20211005105905.1994700-1-elver@google.com> <20211005105905.1994700-24-elver@google.com> In-Reply-To: From: Marco Elver Date: Thu, 11 Nov 2021 11:11:00 +0100 Message-ID: Subject: Re: [PATCH -rcu/kcsan 23/23] objtool, kcsan: Remove memory barrier instrumentation from noinstr To: Peter Zijlstra Cc: "Paul E . McKenney" , Alexander Potapenko , Boqun Feng , Borislav Petkov , Dmitry Vyukov , Ingo Molnar , Josh Poimboeuf , Mark Rutland , Thomas Gleixner , Waiman Long , Will Deacon , kasan-dev@googlegroups.com, linux-arch@vger.kernel.org, linux-doc@vger.kernel.org, linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, x86@kernel.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 3BF6DE00199E X-Stat-Signature: 4rcdcsrbwz1j1ekna5h3a3a5cezqm6go Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=CkvxSK1E; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf30.hostedemail.com: domain of elver@google.com designates 209.85.167.172 as permitted sender) smtp.mailfrom=elver@google.com X-HE-Tag: 1636625525-108757 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, 5 Oct 2021 at 17:13, Marco Elver wrote: > On Tue, Oct 05, 2021 at 04:37PM +0200, Peter Zijlstra wrote: > > On Tue, Oct 05, 2021 at 12:59:05PM +0200, Marco Elver wrote: > > > Teach objtool to turn instrumentation required for memory barrier > > > modeling into nops in noinstr text. > > > > > > The __tsan_func_entry/exit calls are still emitted by compilers even > > > with the __no_sanitize_thread attribute. The memory barrier > > > instrumentation will be inserted explicitly (without compiler help), and > > > thus needs to also explicitly be removed. > > > > How is arm64 and others using kernel/entry + noinstr going to fix this? > > > > ISTR they fully rely on the compilers not emitting instrumentation, > > since they don't have objtool to fix up stray issues like this. > > So this is where I'd like to hear if the approach of: > > | #if !defined(CONFIG_ARCH_WANTS_NO_INSTR) || defined(CONFIG_STACK_VALIDATION) > | ... > | #else > | #define kcsan_noinstr noinstr > | static __always_inline bool within_noinstr(unsigned long ip) > | { > | return (unsigned long)__noinstr_text_start <= ip && > | ip < (unsigned long)__noinstr_text_end; > | } > | #endif > > and then (using the !STACK_VALIDATION definitions) > > | kcsan_noinstr void instrumentation_may_appear_in_noinstr(void) > | { > | if (within_noinstr(_RET_IP_)) > | return; > > works for the non-x86 arches that select ARCH_WANTS_NO_INSTR. > > If it doesn't I can easily just remove kcsan_noinstr/within_noinstr, and > add a "depends on !ARCH_WANTS_NO_INSTR || STACK_VALIDATION" to the > KCSAN_WEAK_MEMORY option. > > Looking at a previous discussion [1], however, I was under the > impression that this would work. > > [1] https://lkml.kernel.org/r/CANpmjNMAZiW-Er=2QDgGP+_3hg1LOvPYcbfGSPMv=aR6MVTB-g@mail.gmail.com I'll send v2 of this series after 5.16-rc1. So far I think we haven't been able to say the above doesn't work, which means I'll assume it works on non-x86 architectures with ARCH_WANTS_NO_INSTR until we get evidence of the opposite.