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 C8BCCC4332F for ; Fri, 18 Nov 2022 18:20:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DD1068E0001; Fri, 18 Nov 2022 13:20:12 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D814C6B0072; Fri, 18 Nov 2022 13:20:12 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C70328E0001; Fri, 18 Nov 2022 13:20:12 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id B6EBC6B0071 for ; Fri, 18 Nov 2022 13:20:12 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 85BA54093E for ; Fri, 18 Nov 2022 18:20:12 +0000 (UTC) X-FDA: 80147377464.05.1E5B1E7 Received: from mail-yb1-f169.google.com (mail-yb1-f169.google.com [209.85.219.169]) by imf15.hostedemail.com (Postfix) with ESMTP id 2F36AA0009 for ; Fri, 18 Nov 2022 18:20:11 +0000 (UTC) Received: by mail-yb1-f169.google.com with SMTP id f201so6553656yba.12 for ; Fri, 18 Nov 2022 10:20:11 -0800 (PST) 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:message-id:reply-to; bh=mzosd7qcit/DhyEuPxX/KZLd3/ECFAwDjLQ9cH17uEU=; b=tja3Im+sHNbkCzYvzc5/QMgdW/Eh9+LZUeZfRUzmCboWZ5Kc8v+XQAgKuFfWoNGIcM T5UogN+WYSyyfaR20AX1lTcBpc0A2YvCYz2+eKmBo3u55rD/CdvhFwjII+htdt9KiyZj o8G3J8R6+N0aDImMDY44r4bie21MMhxTzxDczyNc4amfN6yTMpTP45/eUcgS675TgzkW eytQ2K5WqVENdQHJdyFkLhPUdFbd/HZUmNdpgNIywvc2mXlegYbslYzgjzG1ye3qZTeS iRLOH6aU7Ea/R053GzTtjTDRqItFktWSgZ7SfdPJu22OTKqIfGLg52CGMrO4U2ipkXD3 hQAw== 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:message-id :reply-to; bh=mzosd7qcit/DhyEuPxX/KZLd3/ECFAwDjLQ9cH17uEU=; b=bmoAgHALdyzQ8a79pXZO0swSDJmqy4+xNs5TYG3VwwuPfCcOAT2u8Dn/+8t7K8v/UY Uu5JGpnPTEr+oJ3pyb+zrxDaT3MQ+1SmVLM+6lEmZ6YkZJ7aWoqSIXiwD0PvtNxTJ0n9 5Lr1tSpu8QPj9y7s1/LmVf/mzIr5dj45KAUZdRMW60EmlB5HCUaUYiQomHnTlB89sZXh GFG8f0k6sKMLYhB5AGwd4wgtLQLzc8fgW2KlBjSMWKRblnW/E35YPn98ePh2GEch1qc6 ohA1sOVIXylSBKcleB3CGSczapN9kQfjAkgLAZEry0ha0Wj4QU8CKGWw4ZoM3b+quEP+ 5UjA== X-Gm-Message-State: ANoB5pl+PKZCY1zIM7NXu/eJCc44vKCVRdzpjlYW61MVRn4FXu9oP0QA 0X5RfbkQ01DsBEhLpOr0JvOWofcdhnnYQoAPoSWKdw== X-Google-Smtp-Source: AA0mqf4KgV+NlWgOQLG+Kxakm2AvlgiOEH1s2kDJ5cWonRTnrhodc89WAX4GL4t6LiA9DZd18KCquC3am6tnVQ/YEMI= X-Received: by 2002:a25:6a07:0:b0:6d4:84c5:8549 with SMTP id f7-20020a256a07000000b006d484c58549mr7428459ybc.376.1668795610233; Fri, 18 Nov 2022 10:20:10 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Alexander Potapenko Date: Fri, 18 Nov 2022 19:19:33 +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" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1668795612; a=rsa-sha256; cv=none; b=zhEBoTxpMtunOy+Po3wSN+125w6un9XfR2+OQzG+BMwy93si3HM+YsJ2uGdvubryKq6su9 c+nVdfRfeuqIViy/b1VpDs78M6KVEYPgPb6yPth3qSXSng4K3BCL//F8c6x7XP1UaDDEyt tdp7hJuGk7m5pGwprb9ka+hUSnCUwYw= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=tja3Im+s; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf15.hostedemail.com: domain of glider@google.com designates 209.85.219.169 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=1668795612; 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=mzosd7qcit/DhyEuPxX/KZLd3/ECFAwDjLQ9cH17uEU=; b=khSwdP7mR07/bYD9geiCRSxNkGb0FzT03eKItuU/A/qZd9ESw5vm3GPBXLogPTdfAuISIy EKn2qwCrDR69eQeMqErD0kSyQ2Q/u3FraxHCSw7fFguDv0HVXLEhsYGUtG1GoA3NKDPiPL EU1Rq9yaE9GGFArJrnV3Wp4iZA8Qii4= Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=tja3Im+s; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf15.hostedemail.com: domain of glider@google.com designates 209.85.219.169 as permitted sender) smtp.mailfrom=glider@google.com X-Rspam-User: X-Stat-Signature: wt9ytg63e3zqbofq3757y7pb1byxgch3 X-Rspamd-Queue-Id: 2F36AA0009 X-Rspamd-Server: rspam11 X-HE-Tag: 1668795611-196059 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 Fri, Nov 18, 2022 at 2:39 PM Alexander Potapenko wrote: > > > > As far as I can tell, removing `KMSAN_SANITIZE_lockdep.o := 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/0x180 > ... > > 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 ]--- In fact, this message is printed in both cases: with and without KMSAN instrumenting kernel/locking/lockdep.c I wonder if this is a sign of a real problem in KMSAN, or just an unavoidable consequence of instrumented code calling lockdep when taking the stackdepot lock... > > > 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 being > > 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. Sent the patch.