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 8C6DCC4332F for ; Fri, 18 Nov 2022 13:39:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EA4248E0001; Fri, 18 Nov 2022 08:39:40 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E55096B0072; Fri, 18 Nov 2022 08:39:40 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D1B588E0001; Fri, 18 Nov 2022 08:39:40 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id C28B96B0071 for ; Fri, 18 Nov 2022 08:39:40 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 8A4C61A1335 for ; Fri, 18 Nov 2022 13:39:40 +0000 (UTC) X-FDA: 80146670520.29.FBBE8CB Received: from mail-yw1-f181.google.com (mail-yw1-f181.google.com [209.85.128.181]) by imf02.hostedemail.com (Postfix) with ESMTP id 261D38000A for ; Fri, 18 Nov 2022 13:39:39 +0000 (UTC) Received: by mail-yw1-f181.google.com with SMTP id 00721157ae682-3938dc90ab0so30532737b3.4 for ; Fri, 18 Nov 2022 05:39:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=EKwPWOIei0ORF4YEoW2azGGh2uCAPxfNzIEZVLw0jwE=; b=fetFG9vb9oDky8QdSGpLBfutVlrtudcdGypf4aJjtSuCL6JFvwgaKtvU27hb+sIGKq DzSkU5loX9JmPIYx1qfBTuk0zVWGs53vd20g78Cwcjzb4VMhe9RZT/vu3ratGXW/hxKA yD+EtuQ1QzjSt4Dxv1rQSgHUh8GHi29i91ZM250PwIa4NG6DXya5jod5zasNFV6+y5aP vfLNR6vawYQzz+G+FQ6SQcWQ7JSImaJGCLhzuiTCA2r5X7DUYShKFzs8pjS49q5OAq0z QIqbere9zeRl0OcD/nTUdbQo0BpljDw9028Ki5kzxc99XePNk5/XVLQFC7s6HLfNuXMw h8zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=EKwPWOIei0ORF4YEoW2azGGh2uCAPxfNzIEZVLw0jwE=; b=JiRM6O/F6UoYK3SwBDBHbk9w4IBX7KoABxHC21LGn7wMXtzDw/0mNGMEqme4aXQSJZ DjJ7JT/Rd9W4tuWWu7YaQXsi1Bp/GHyGRP5WDjMmNIkr/IM8ecLcXtvrmMcu363CGfq7 xL/qiEAhNShRc71uOWCnTQiImVQaYxNAeUaRRhxWGCf9VWSNuLawjmDr0EAgC27Jyabs Ee/Z5oARpLusDksVO8ba7gta2WEqawjieBCAQ41vfnUsx+s39n1vKBFNgfBOwGNp5uKf b682jL+CnhTt/6ZEx1F/bGsDsHiBahiiN7jXzyWDTUZOgfCtRkPxeFANUAkphiO7PgFa 93pw== X-Gm-Message-State: ANoB5pmqtrfDVo9HFleoG8lbQ8/WEGUokgJb7PX8UDAvLtjNdN2E2DcS WdCgd2nlzyhDz3CIDLVRQpGkMwIrXZRWSV7ujR7uLA== X-Google-Smtp-Source: AA0mqf5sNuS/4nvSYw6W6u8u7JOORRs6zds70QaxItmPsTI2PIAhzA0+xwk61rB4CFzXVW8Vii8YnADenM5oj81sVqk= X-Received: by 2002:a81:dd05:0:b0:36e:8228:a127 with SMTP id e5-20020a81dd05000000b0036e8228a127mr6571943ywn.299.1668778779156; Fri, 18 Nov 2022 05:39:39 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Alexander Potapenko Date: Fri, 18 Nov 2022 14:39:02 +0100 Message-ID: Subject: Re: KMSAN broken with lockdep again? To: Eric Biggers Cc: Marco Elver , Dmitry Vyukov , kasan-dev@googlegroups.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1668778780; a=rsa-sha256; cv=none; b=qfMIWQQbOmrYuFwQifB5YpiLRMRImCGgC7QzxX7RLu9gv6HbAxqGReWQx7SdlNFzAjoiaA 0ZG6qsLCFx17M/ER9h886QbkLyQxf4IOty83ksadm2urPGaWbbHtAvvBE7hoYUki42he90 /cOwKOZtJcG0t9CyCcjTOx068OdfWkA= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=fetFG9vb; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf02.hostedemail.com: domain of glider@google.com designates 209.85.128.181 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=1668778780; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=EKwPWOIei0ORF4YEoW2azGGh2uCAPxfNzIEZVLw0jwE=; b=bYdnXwanqtJybJaqlMZ/ip+OittxnIM5dxL1e1jZkJGgncIoKTcNUl+tI0adJ4lMvo302f RwIRznSS7VxQjLDsYk4brPm9JgPDsPzqyIL7rCfQI2guAwx2IlqkqrvU3+WnLY+nTBQOmF rn+iCpI1kBG6ptwxakwJnv8u7+5EHTg= Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=fetFG9vb; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf02.hostedemail.com: domain of glider@google.com designates 209.85.128.181 as permitted sender) smtp.mailfrom=glider@google.com X-Rspam-User: X-Stat-Signature: nk7xr5x4r17nfczok8c6uec8zpdej4wy X-Rspamd-Queue-Id: 261D38000A X-Rspamd-Server: rspam11 X-HE-Tag: 1668778779-212468 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: > > As far as I can tell, removing `KMSAN_SANITIZE_lockdep.o :=3D n` does > > not actually break anything now (although the kernel becomes quite > > slow with both lockdep and KMSAN). Let me experiment a bit and send a > > patch. Hm, no, lockdep isn't particularly happy with the nested lockdep->KMSAN->lockdep calls: ------------[ cut here ]------------ DEBUG_LOCKS_WARN_ON(lockdep_hardirqs_enabled()) WARNING: CPU: 0 PID: 0 at kernel/locking/lockdep.c:5508 check_flags+0x63/0x= 180 ... lock_acquire+0x196/0x640 kernel/locking/lockdep.c:5665 __raw_spin_lock_irqsave ./include/linux/spinlock_api_smp.h:110 _raw_spin_lock_irqsave+0xb3/0x110 kernel/locking/spinlock.c:162 __stack_depot_save+0x1b1/0x4b0 lib/stackdepot.c:479 stack_depot_save+0x13/0x20 lib/stackdepot.c:533 __msan_poison_alloca+0x100/0x1a0 mm/kmsan/instrumentation.c:263 native_save_fl ./include/linux/spinlock_api_smp.h:? arch_local_save_flags ./arch/x86/include/asm/irqflags.h:70 arch_irqs_disabled ./arch/x86/include/asm/irqflags.h:130 __raw_spin_unlock_irqrestore ./include/linux/spinlock_api_smp.h:151 _raw_spin_unlock_irqrestore+0x60/0x100 kernel/locking/spinlock.c:194 tty_register_ldisc+0xcb/0x120 drivers/tty/tty_ldisc.c:68 n_tty_init+0x1f/0x21 drivers/tty/n_tty.c:2521 console_init+0x1f/0x7ee kernel/printk/printk.c:3287 start_kernel+0x577/0xaff init/main.c:1073 x86_64_start_reservations+0x2a/0x2c arch/x86/kernel/head64.c:556 x86_64_start_kernel+0x114/0x119 arch/x86/kernel/head64.c:537 secondary_startup_64_no_verify+0xcf/0xdb arch/x86/kernel/head_64.S:358 ---[ end trace 0000000000000000 ]--- > > If this won't work out, we'll need an explicit call to > > kmsan_unpoison_memory() somewhere in lockdep_init_map_type() to > > suppress these reports. I'll go for this option. > Thanks. > > I tried just disabling CONFIG_PROVE_LOCKING, but now KMSAN warnings are b= eing > spammed from check_stack_object() in mm/usercopy.c. > > Commenting out the call to arch_within_stack_frames() makes it go away. Yeah, arch_within_stack_frames() performs stack frame walking, which confuses KMSAN. We'll need to apply __no_kmsan_checks to it, like we did for other stack unwinding functions. > - Eric T -- Alexander Potapenko Software Engineer Google Germany GmbH Erika-Mann-Stra=C3=9Fe, 33 80636 M=C3=BCnchen Gesch=C3=A4ftsf=C3=BChrer: Paul Manicle, Liana Sebastian Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg