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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 14DA5ECAAA1 for ; Fri, 9 Sep 2022 08:57:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4B5008D0002; Fri, 9 Sep 2022 04:57:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 463DB8D0001; Fri, 9 Sep 2022 04:57:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 37A698D0002; Fri, 9 Sep 2022 04:57:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 29E238D0001 for ; Fri, 9 Sep 2022 04:57:47 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id EBCB6C09FA for ; Fri, 9 Sep 2022 08:57:46 +0000 (UTC) X-FDA: 79891944132.08.19A1C91 Received: from mail-yw1-f182.google.com (mail-yw1-f182.google.com [209.85.128.182]) by imf10.hostedemail.com (Postfix) with ESMTP id AAF30C006C for ; Fri, 9 Sep 2022 08:57:46 +0000 (UTC) Received: by mail-yw1-f182.google.com with SMTP id 00721157ae682-3487d84e477so11509977b3.6 for ; Fri, 09 Sep 2022 01:57:46 -0700 (PDT) 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; bh=BA7v9By/PKm8Lb5EGh75hqx3B2NthlRyqEiydr+9MIw=; b=goGwbFEzBCu6ZReNVsQFXEaSFbARIBvytLuNW4v5IzfqaOxEddum2eMnFGd4n1giOm 12yr+tkvZlEG8nCUA88s5hp100Jh85VNfSeMZi+Aq6wwHb9IOv/FFX1jCussxyGiaJ5U Nxmc1qPjqj8jpEfcvVPhcAgsqpQiA8h9e32psMV1REa/fw4xpH7NmtwCwq0Y3Dt9YILC 176tLQDsChJoJCd8+GYPQmm5OjJtrlmbnNDXKD8AX6dyKzZgJPWyMxrYwLc7vOjaOYBI O9WJIH6/NkpPX9UbGKPOwAa8jlb13aKJ3GYGRyRTRCnNMOKLHvbAfbfKvl8FcfN+moBm H51Q== 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; bh=BA7v9By/PKm8Lb5EGh75hqx3B2NthlRyqEiydr+9MIw=; b=EHPDDF7L5OpH3SNTADkHM9K2WIe/0pVF+WqEjd/iUyVaDoOob+4yxDsfGFUnLZoVRZ mP8RWtdf7hbzGNlFVF/+9tvJABYKkNawzdM9JmmDGO5hqTiB3Zoz7j/ihgSy9IS0ZZaG nyGYPNzE2ZrKxQN5ZHWeRKyWPuNXridHEIuPrZCPkOlBQDseRHpZalv2JPAzAgHjZqOJ dfSUvPCxHZXXa7l/mIh431+t03GUfooIJhhuhw+i+K+aGqQ8krWxynlpWHGQy1V9wycR 63KlpNvCwj4LpY+UZ8C79VqTH2BcvMPvbUlkK3MyLx3w/BqFNcFo1j9TtmDCChRVsyaS ccog== X-Gm-Message-State: ACgBeo18WaTjrKwrcd7qVtDOY/I7oZEG5aXuwDy53NTXiAjBLgTJNItv cjA03h10iQgUzh0+EkrzuE37A9AUSSzg1R7lQhuZrw== X-Google-Smtp-Source: AA6agR6yLRVeEL7qXOrcf6i7wNdKQSe6OY+YRtuC5CLYDGWplZp6/6tDwb3XUHj4CjP4Gwj8mLOWHJSGHRh50UlvyRs= X-Received: by 2002:a0d:c7c3:0:b0:31e:9622:c4f6 with SMTP id j186-20020a0dc7c3000000b0031e9622c4f6mr10866606ywd.144.1662713865771; Fri, 09 Sep 2022 01:57:45 -0700 (PDT) MIME-Version: 1.0 References: <20220905122452.2258262-1-glider@google.com> <20220905122452.2258262-41-glider@google.com> In-Reply-To: <20220905122452.2258262-41-glider@google.com> From: Alexander Potapenko Date: Fri, 9 Sep 2022 10:57:09 +0200 Message-ID: Subject: Re: [PATCH v6 40/44] x86: kmsan: don't instrument stack walking functions To: Andrew Morton , Stephen Rothwell Cc: Alexander Viro , Alexei Starovoitov , Andrey Konovalov , Andy Lutomirski , Arnd Bergmann , Borislav Petkov , Christoph Hellwig , Christoph Lameter , David Rientjes , Dmitry Vyukov , Eric Dumazet , Greg Kroah-Hartman , Herbert Xu , Ilya Leoshkevich , Ingo Molnar , Jens Axboe , Joonsoo Kim , Kees Cook , Marco Elver , Mark Rutland , Matthew Wilcox , "Michael S. Tsirkin" , Pekka Enberg , Peter Zijlstra , Petr Mladek , Steven Rostedt , Thomas Gleixner , Vasily Gorbik , Vegard Nossum , Vlastimil Babka , kasan-dev , Linux Memory Management List , Linux-Arch , LKML Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1662713866; a=rsa-sha256; cv=none; b=k/GVysshnRM/2DC11bjkN48fZ1qkJb/653EI99OscFu8+F4iBc45GoXMgvoG8zWyTlCLZ2 x7GeYAJGRVVJRcNolu5/dN+qk7HsPPObnfpuZG/wxgXy/DiRksFHmRUqeCe2NSz2EsIg8o WIdlI9d/BtynuX0mZJBK1XDJ+NISFwU= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=goGwbFEz; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf10.hostedemail.com: domain of glider@google.com designates 209.85.128.182 as permitted sender) smtp.mailfrom=glider@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1662713866; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=BA7v9By/PKm8Lb5EGh75hqx3B2NthlRyqEiydr+9MIw=; b=siadMc5P7ZFJWqJY2j2HqaM3vkzzVPfUgJq10fEHP/TBpER2biwwTgUgv8lEmZmVguyrU6 wrrxsBOd/kiPlt+Y1My01ow6PI/byKkD2kXn6gAgBXa7NYmfYLlIGQ7UfHOSb2FnUh4oY4 cVaVr2jtinrEim0R7T7SGV2p0Tpq/iE= X-Stat-Signature: joycrnnrkap7otstpj567o581zrymu41 X-Rspamd-Queue-Id: AAF30C006C X-Rspam-User: Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=goGwbFEz; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf10.hostedemail.com: domain of glider@google.com designates 209.85.128.182 as permitted sender) smtp.mailfrom=glider@google.com X-Rspamd-Server: rspam02 X-HE-Tag: 1662713866-486215 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 Mon, Sep 5, 2022 at 2:26 PM Alexander Potapenko wrote: > > Upon function exit, KMSAN marks local variables as uninitialized. > Further function calls may result in the compiler creating the stack > frame where these local variables resided. This results in frame > pointers being marked as uninitialized data, which is normally correct, > because they are not stack-allocated. > > However stack unwinding functions are supposed to read and dereference > the frame pointers, in which case KMSAN might be reporting uses of > uninitialized values. > > To work around that, we mark update_stack_state(), unwind_next_frame() > and show_trace_log_lvl() with __no_kmsan_checks, preventing all KMSAN > reports inside those functions and making them return initialized > values. > > Signed-off-by: Alexander Potapenko Hi Andrew, Stephen, I've noticed this particular patch is missing in -mm (and, as a result, in linux-next), which results in tons of false positives at boot time. Could you please add it as well?