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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5DCD5C433EF for ; Mon, 9 May 2022 19:09:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240453AbiEITN1 (ORCPT ); Mon, 9 May 2022 15:13:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45696 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240446AbiEITNY (ORCPT ); Mon, 9 May 2022 15:13:24 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CFD642CCD09; Mon, 9 May 2022 12:09:29 -0700 (PDT) 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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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