Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <Y3VEL0P0M3uSCxdk@sol.localdomain> <CAG_fn=XwRo71wqyo-zvZxzE021tY52KKE0j_GmYUjpZeAZa7dA@mail.gmail.com>
 <Y3b9AAEKp2Vr3e6O@sol.localdomain>
In-Reply-To: <Y3b9AAEKp2Vr3e6O@sol.localdomain>
From:   Alexander Potapenko <glider@google.com>
Date:   Fri, 18 Nov 2022 14:39:02 +0100
Message-ID: <CAG_fn=Upw7AsM_wZq0ajPixbAKp-izC7LMxyN_5onfL=OBhRzA@mail.gmail.com>
Subject: Re: KMSAN broken with lockdep again?
To:     Eric Biggers <ebiggers@kernel.org>
Cc:     Marco Elver <elver@google.com>, Dmitry Vyukov <dvyukov@google.com>,
        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
Precedence: bulk

> > 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
...
 <TASK>
 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
 </TASK>
---[ 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