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 607A6C54E4A for ; Fri, 8 Mar 2024 09:39:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B78996B0361; Fri, 8 Mar 2024 04:39:56 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B28586B0362; Fri, 8 Mar 2024 04:39:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9F0446B0363; Fri, 8 Mar 2024 04:39:56 -0500 (EST) 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 8D5626B0361 for ; Fri, 8 Mar 2024 04:39:56 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 16DF4121586 for ; Fri, 8 Mar 2024 09:39:56 +0000 (UTC) X-FDA: 81873375192.18.3DE2370 Received: from mail-ua1-f43.google.com (mail-ua1-f43.google.com [209.85.222.43]) by imf03.hostedemail.com (Postfix) with ESMTP id 7F8F02001B for ; Fri, 8 Mar 2024 09:39:54 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=RGBMMz8C; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf03.hostedemail.com: domain of elver@google.com designates 209.85.222.43 as permitted sender) smtp.mailfrom=elver@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709890794; 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=Mkn/lM2x4sb3JsolgYFeL1UFRJfnKJyId5+RqBqRGmc=; b=i7DsLWQiQhN5OvQW1osMI2f2TWrQsOlihGeB+erRwCMfRIzy3wmYbVPeB4ZwdUF31Ql70s AKUnvdvtCC7rEBK38wIGuHBtJzROOQhPnEuGoAzm1NeEgp5qqdRaDqPfVua7rxS2+8IIb8 S+gnzjs4x2syKH3pBFUJqz6CfOHNi/A= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=RGBMMz8C; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf03.hostedemail.com: domain of elver@google.com designates 209.85.222.43 as permitted sender) smtp.mailfrom=elver@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709890794; a=rsa-sha256; cv=none; b=d5usayUVikLNXnZkoKqa62cXdBR6+ua44CjzUMewgq6TgQTFFrLnlunnoPJ3CVms43c3+y wJM6v5fv38GTHVYTaKTPfVldGuSIQsqNrQjOb7fj9TRSSz7ZOD/Jkm+L/ScKucQeZYtbX8 UPZphFs9ek9zrVs+ma2+PBrocQaY0Fw= Received: by mail-ua1-f43.google.com with SMTP id a1e0cc1a2514c-7db36dbd474so336989241.2 for ; Fri, 08 Mar 2024 01:39:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1709890793; x=1710495593; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Mkn/lM2x4sb3JsolgYFeL1UFRJfnKJyId5+RqBqRGmc=; b=RGBMMz8CApg6JVVA5a8ryeGPUU2DbzVCYkX36GiZWK3N1jw8TG10R6SXFVrwhTIGMx zf2FrVkhBp3d9l34/WeBCIjSTf+11/XkxWb1jZYKW9y9L4G8lEJHM/tWvDVjfpF5azpL rpwgu8JqkwR94MhJ605AZ/Qd1anLRlZoxbS/I8DW+RD49xjRQ42YjY2KKfWggAG3/ein Qs2nR/MQN2ZdRoBxvE7g2yC1J5L4OpDGoSJ742ktMmy7h/nI8xhjbenOvQn8nCDNOy0N tYER1DRTLnXeYqsqUSFG/xZHR4vhtisvAIzYunMAZdPLODFeU2HTJRXKcXLQzpNDhCc2 DyhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709890793; x=1710495593; 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=Mkn/lM2x4sb3JsolgYFeL1UFRJfnKJyId5+RqBqRGmc=; b=GJlWxY32kKi6YScLv0O5vNOiEXs0MtHj+FFTkb6uWdHID/GbxzvSeCybKVZxjMAsU6 LBmbhgWKlOKnnv3IGV5BlHZfYH/QL0+pk1ATNLk3aTj+MIz02H6MbBLC12mMOr8OmKqT VLic1lxuMt5jXOST+NkvmGlAcLExgKX4aCXVj5v+oMcgWTrNDsBHxeiY55qunTvN5wA6 scnWUvj5Fa7GhZsvGARZ7I8YLEkMqqM35wTJb+94HwZ/n8NGT1Yae/dFVe/E5Ud2zF5E Bkjkw24Ju/O+xqkrCiExNgSrdhu1cBEpMObOUgvRzFLU45H0dc6x8LGMBkpngiONgJC8 WXDw== X-Forwarded-Encrypted: i=1; AJvYcCUhxK7RWpF/rVctejkEUxIFQ19NK/Dra1y6IqNiXQHeUuNdTPbuKErq3t5JUAs/lOppm19IjRfiKtEvUnsHWgvvMoM= X-Gm-Message-State: AOJu0YyoCznBGmOy8Np7rPcsCfWl6Q5VfQmvfm6K5PCoSqWeB9+vhhjJ Hl6POYB/gKEqJlE1MTSVSpNOWFXMcdHgYLQkX2nVg/s7LuWw9thuJyS+iYPRz9TFx25FDFN7qzJ WK4k0ocs7chVKhiT50ZifyZD7a9+oTfTI2UESkjJe/8R1gLWR9Pan X-Google-Smtp-Source: AGHT+IE98fk08xTbrq+mTAdTYKrnDf67OwO4kqP1lpmve9KoyN/iaSJCDm9ZXsgnS4dUvfiGh7TmfKawzn8GENgGIYc= X-Received: by 2002:a05:6122:2703:b0:4d1:34a1:c892 with SMTP id ej3-20020a056122270300b004d134a1c892mr11242267vkb.13.1709890793488; Fri, 08 Mar 2024 01:39:53 -0800 (PST) MIME-Version: 1.0 References: <20240308043448.masllzeqwht45d4j@M910t> In-Reply-To: <20240308043448.masllzeqwht45d4j@M910t> From: Marco Elver Date: Fri, 8 Mar 2024 10:39:15 +0100 Message-ID: Subject: Re: [BUG] kmsan: instrumentation recursion problems To: Changbin Du Cc: Alexander Potapenko , Andrew Morton , kasan-dev@googlegroups.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 7F8F02001B X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: noehchtjzwfaeb47amo4yteiqcyxyux3 X-HE-Tag: 1709890794-620541 X-HE-Meta: U2FsdGVkX19RnUnHGbouJ2C8qweZVNWfUC/JCFG7/tTg+ySTOiJWhglHTC2mP5IkTCxKUTj3lFcYxB5FJm8y+YgAqRqKC9wgPlQQ5jDMygzQeQLuY2E8RFdijy5XE4MC1K7MnYTNxNMMB/FvlIHbIAvyK31FEk2NZVPX563eK5t15E0rmlINTvVXNWJQIN38aL8eXCubB+j+z4OVx8cMXI38u0HqOg7gHHyU2dGpgCtjsgqMKiVkFoTMcJPd7NbLgxf1VcJ6IR/eKIZUMOKzwYTL9VSvLhBz+qiat0MR17cvXKKN9PDy/LXWPFPL0vc/FLyruG25ap1oQ6x2vIvjNYWdjwb3/5ARgLuG5GP7/K0AVfg06S0yk2g2lbG9YnPrDM+0HyO7yC02Wp/Me/sCVCOTka67pM5c027ynZecf49FFQVE38mvasNDyjcNatRsENtLGcwbdeJgdMhamAGEUGmi5sY3My8qPbQz4Tk1bVef1DglR7BTJDoP7SdYVefUijEB0SptQ8eCWgzbJfxggzoAtyLFl29DIBhz0+BWEvoJ1q1lCemy2SqTPPIJE0Anyb1Ctn5kmuh3Y2CEs2Ed3NZDkO0sbE76rQytUFgL/4pYUTbYYVjiCsKZDAvg2ZsKXV8/I77aAedjt33jcjBY8ZLJRevAzvLy2c+8ku9aXVqkyNEbkbE2gLuU5hxez1KyFtI2yYF4F20bFPtBU434mWbnCpmMAtMy5G+lbB0ZHjHmLnHmtg3NL5nksC4xvsTMzKocuvKHRwMCcgqhCobf1KPz7qsL/28YDQUGziUMlU5SFaTTmL0F8bf9VngbVN/OxhCZ7tavGCxrgBdbuzDEuGisCsTXOY2DqVC44dwlfXw2+3L3uCHsmXcUC7hAIXg/4/zSKzF/miKsq5E0fFAtY+0bIgu3MN2J9TFmkALch3qydmp9q/ZRKP4YSwOrKpLFpYBYmJxOCNE5++dnXah SBQ== 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: List-Subscribe: List-Unsubscribe: On Fri, 8 Mar 2024 at 05:36, 'Changbin Du' via kasan-dev wrote: > > Hey, folks, > I found two instrumentation recursion issues on mainline kernel. > > 1. recur on preempt count. > __msan_metadata_ptr_for_load_4() -> kmsan_virt_addr_valid() -> preempt_disable() -> __msan_metadata_ptr_for_load_4() > > 2. recur in lockdep and rcu > __msan_metadata_ptr_for_load_4() -> kmsan_virt_addr_valid() -> pfn_valid() -> rcu_read_lock_sched() -> lock_acquire() -> rcu_is_watching() -> __msan_metadata_ptr_for_load_8() > > > Here is an unofficial fix, I don't know if it will generate false reports. > > $ git show > commit 7f0120b621c1cbb667822b0f7eb89f3c25868509 (HEAD -> master) > Author: Changbin Du > Date: Fri Mar 8 20:21:48 2024 +0800 > > kmsan: fix instrumentation recursions > > Signed-off-by: Changbin Du > > diff --git a/kernel/locking/Makefile b/kernel/locking/Makefile > index 0db4093d17b8..ea925731fa40 100644 > --- a/kernel/locking/Makefile > +++ b/kernel/locking/Makefile > @@ -7,6 +7,7 @@ obj-y += mutex.o semaphore.o rwsem.o percpu-rwsem.o > > # Avoid recursion lockdep -> sanitizer -> ... -> lockdep. > KCSAN_SANITIZE_lockdep.o := n > +KMSAN_SANITIZE_lockdep.o := n This does not result in false positives? Does KMSAN_ENABLE_CHECKS_lockdep.o := n work as well? If it does, that is preferred because it makes sure there are no false positives if the lockdep code unpoisons data that is passed and used outside lockdep. lockdep has a serious impact on performance, and not sanitizing it with KMSAN is probably a reasonable performance trade-off. > ifdef CONFIG_FUNCTION_TRACER > CFLAGS_REMOVE_lockdep.o = $(CC_FLAGS_FTRACE) > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c > index b2bccfd37c38..8935cc866e2d 100644 > --- a/kernel/rcu/tree.c > +++ b/kernel/rcu/tree.c > @@ -692,7 +692,7 @@ static void rcu_disable_urgency_upon_qs(struct rcu_data *rdp) > * Make notrace because it can be called by the internal functions of > * ftrace, and making this notrace removes unnecessary recursion calls. > */ > -notrace bool rcu_is_watching(void) > +notrace __no_sanitize_memory bool rcu_is_watching(void) For all of these, does __no_kmsan_checks instead of __no_sanitize_memory work? Again, __no_kmsan_checks (function-only counterpart to KMSAN_ENABLE_CHECKS_.... := n) is preferred if it works as it avoids any potential false positives that would be introduced by not instrumenting. > { > bool ret; > > diff --git a/kernel/sched/core.c b/kernel/sched/core.c > index 9116bcc90346..33aa4df8fd82 100644 > --- a/kernel/sched/core.c > +++ b/kernel/sched/core.c > @@ -5848,7 +5848,7 @@ static inline void preempt_latency_start(int val) > } > } > > -void preempt_count_add(int val) > +void __no_sanitize_memory preempt_count_add(int val) > { > #ifdef CONFIG_DEBUG_PREEMPT > /* > @@ -5880,7 +5880,7 @@ static inline void preempt_latency_stop(int val) > trace_preempt_on(CALLER_ADDR0, get_lock_parent_ip()); > } > > -void preempt_count_sub(int val) > +void __no_sanitize_memory preempt_count_sub(int val) > { > #ifdef CONFIG_DEBUG_PREEMPT > > > -- > Cheers, > Changbin Du