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 D2F27C433F5 for ; Mon, 9 May 2022 19:09:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6FD918D0002; Mon, 9 May 2022 15:09:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6AC7D8D0001; Mon, 9 May 2022 15:09:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 59C5E8D0002; Mon, 9 May 2022 15:09:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 4BE138D0001 for ; Mon, 9 May 2022 15:09:31 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay13.hostedemail.com (Postfix) with ESMTP id 2E44460C0B for ; Mon, 9 May 2022 19:09:31 +0000 (UTC) X-FDA: 79447143342.26.F49374D Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf24.hostedemail.com (Postfix) with ESMTP id 0697A1800C7 for ; Mon, 9 May 2022 19:09:22 +0000 (UTC) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1652123368; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=VawBhkp/iVX6wIchfdV6yUwkO3Wiahi7D6DYX4ALtEQ=; b=oVLpbua2F51imTuUaCqhV2+tynkaE/0W46R/u/Ylc4zzKQfAnTT/f4Im++Ucg+RkNzJ/hN bEb6OMwxPx9QUDW7IRFzZRDzOsB56DTxlJgMj6RHuJHo8gvEEVPHdbctzCpWazF/ISy7W1 HHlZSqzEpUDDYolJhc/j3GV/wUFpAJCGwSpFqnC2uH1frWVxJscfbfPgWJ36FCRFx8e5zT DDIpU3jiZemHAXmIHkg0+z8xM6suFIuf3rgTfbP4WXfmcxXMMmldoM1HFAK2qXThGOQeHt 5Jv67t5NZPZaiGZLeAYLTWiFZxEbhrcarUsXRocx2XPwesDlfNDM7EpqRONy5A== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1652123368; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=VawBhkp/iVX6wIchfdV6yUwkO3Wiahi7D6DYX4ALtEQ=; b=UvZgazfQq/GqF7NhfTSquz3f+mV65lytaY+y7GU3ZJ4yfzTagDuVaUmX92GGwEBcJlNJHW zAnfw07wpj9oXcAg== To: Alexander Potapenko Cc: Alexander Viro , Andrew Morton , 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 , Vasily Gorbik , Vegard Nossum , Vlastimil Babka , kasan-dev , Linux Memory Management List , Linux-Arch , LKML Subject: Re: [PATCH v3 28/46] kmsan: entry: handle register passing from uninstrumented code In-Reply-To: References: <20220426164315.625149-1-glider@google.com> <20220426164315.625149-29-glider@google.com> <87a6c6y7mg.ffs@tglx> <87y1zjlhmj.ffs@tglx> <878rrfiqyr.ffs@tglx> <87k0ayhc43.ffs@tglx> <87h762h5c2.ffs@tglx> Date: Mon, 09 May 2022 21:09:27 +0200 Message-ID: <871qx2r09k.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=oVLpbua2; dkim=pass header.d=linutronix.de header.s=2020e header.b=UvZgazfQ; spf=pass (imf24.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de X-Rspam-User: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 0697A1800C7 X-Stat-Signature: kfzjigxndggixn4o4s1rgwukuwkmcq4a X-HE-Tag: 1652123362-814904 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, May 09 2022 at 18:50, Alexander Potapenko wrote: > Indeed, calling kmsan_unpoison_memory() in irqentry_enter() was > supposed to be enough, but we have code in kmsan_unpoison_memory() (as > well as other runtime functions) that checks for kmsan_in_runtime() > and bails out to prevent potential recursion if KMSAN code starts > calling itself. > > kmsan_in_runtime() is implemented as follows: > > ============================================== > static __always_inline bool kmsan_in_runtime(void) > { > if ((hardirq_count() >> HARDIRQ_SHIFT) > 1) > return true; > return kmsan_get_context()->kmsan_in_runtime; > } > ============================================== > (see the code here: > https://lore.kernel.org/lkml/20220426164315.625149-13-glider@google.com/#Z31mm:kmsan:kmsan.h) > > If we are running in the task context (in_task()==true), > kmsan_get_context() returns a per-task `struct *kmsan_ctx`. > If `in_task()==false` and `hardirq_count()>>HARDIRQ_SHIFT==1`, it > returns a per-CPU one. > Otherwise kmsan_in_runtime() is considered true to avoid dealing with > nested interrupts. > > So in the case when `hardirq_count()>>HARDIRQ_SHIFT` is greater than > 1, kmsan_in_runtime() becomes a no-op, which leads to false positives. But, that'd only > 1 when there is a nested interrupt, which is not the case. Interrupt handlers keep interrupts disabled. The last exception from that rule was some legacy IDE driver which is gone by now. So no, not a good explanation either. Thanks, tglx