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 CCE5CC4725D for ; Mon, 22 Jan 2024 09:57:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5F0AE6B0082; Mon, 22 Jan 2024 04:57:14 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5A0988D0002; Mon, 22 Jan 2024 04:57:14 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 468528D0001; Mon, 22 Jan 2024 04:57:14 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 3453E6B0082 for ; Mon, 22 Jan 2024 04:57:14 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id CFCD71A06E0 for ; Mon, 22 Jan 2024 09:57:13 +0000 (UTC) X-FDA: 81706493946.13.4820A81 Received: from mail-qv1-f44.google.com (mail-qv1-f44.google.com [209.85.219.44]) by imf11.hostedemail.com (Postfix) with ESMTP id 13EA640005 for ; Mon, 22 Jan 2024 09:57:10 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=ih9CkQDb; spf=pass (imf11.hostedemail.com: domain of glider@google.com designates 209.85.219.44 as permitted sender) smtp.mailfrom=glider@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705917431; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=2rKc/goBzVwdZogi61XdfYVie6DI5305ZMhUyeoLBnU=; b=3sIsNNshjSEo+j4eeBAe+DCxiRQW+3OQwQcL+0++mL1qCC3WSlceCntaYM/RFCdbZ+zp1Z hFJOV3WntggAxzOe8cwWouVjAnlaiNBOiDXHlXGYhV6p2H7uZBf06mg3QgoAkaLt1eGY5R J2Ve2d88siHdV41Q4KmmPAFiPKEm6Zs= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=ih9CkQDb; spf=pass (imf11.hostedemail.com: domain of glider@google.com designates 209.85.219.44 as permitted sender) smtp.mailfrom=glider@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705917431; a=rsa-sha256; cv=none; b=VTfvWrfXVW2sKOFB9fvBmff6fWRWCRTO4UXm8higaUPNJ5DJXY2cK/fpAb0WonfrtiZP54 LMhluQTu6JYSqm3o2h6KEaWtwk7nRNDZiR/R5Wvg/bOQqdwbcOiLZEwk6MkfoKHgwFNIO5 RUeuhFeLttGdU39kbYF+P2DwnJptv/M= Received: by mail-qv1-f44.google.com with SMTP id 6a1803df08f44-68195c0c8d1so12057756d6.3 for ; Mon, 22 Jan 2024 01:57:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1705917430; x=1706522230; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=2rKc/goBzVwdZogi61XdfYVie6DI5305ZMhUyeoLBnU=; b=ih9CkQDbc1Hqbx1quLIn1FoVnfFHtEwHO9VU9kiWnp6OUWsTJA/3Ov60rX5J5OMUg/ eI/kZKlToI348eKhiqjdIaVkx3jlAPnbDx7gDZgw6IlDvep9YRKkXetYUG5jGM95QABL 480R0PtpUj3LbumCusgG+UX4Xt6hqSp2k3ZQfxtBV4G4mdkQEvwHk9Pxl2QojujBZZKQ z0uCf4PmIdlJnUtiqUBZ+mqLnTeRl4QttTNJ8xX1jo8gXBNPHc+j8tOBlxBTq5mAKPIR XebEh33p1F9VdrVrRjcXZVkc/oqvyEZa7R/GEuvBgEApVdfKXJ2TocpODUR82CiMFnRp /dyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705917430; x=1706522230; h=content-transfer-encoding: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=2rKc/goBzVwdZogi61XdfYVie6DI5305ZMhUyeoLBnU=; b=d0dhGS0YC4JWOqXNFF0KDpByeHBOKr9K9VD6I6na+CF+rPiV88wJVqDUhCNeeCScNC fhMlYG3Z8Itg3PbmiR/cJ5ji6hoAArMewYJsiWMFtt/1K1Czv7o9xjvsf5nH37lg0W2F qus0eE9xAU4yPuGPBJmGuvYpFJ8P+KA7Tt3Bw6ji2qmMgSch6hK6SdGNyVo+W+XQ327S WOGgQo4W9uI0pLCoGWjqxg6tiqD40GkQsFGRluxvarVhYAHceiGZ+vTH6KrGYxmKNoop xImhSHDdYkMHTvt6jSS3V6qmGh9FjSrxTDE7IgYv7r3iWFfq3bf9OFdFC8FH6992KB3X GRBg== X-Gm-Message-State: AOJu0YzeagiXsKpnWJWdGwXiv5senEjOXZJhSDidrhzF69K7NVT48n2u pvr7YnPhEbbb5Ix+rzC2Vt8xq7miSXaaaXBMeJYIrmeACtxPj9Nfd3gctn6ht7ag/12/laG4bgm ln98G09XNBVR8BvAH6OoNPQ30thD0fy3UFnls X-Google-Smtp-Source: AGHT+IGYP8VHpM3Oph8CFnz0g/mJ9jSbX248qH2b2vUQpFcyR6bh+yya24MD/KchaFwIIAbaVzmkfJYYsPmNqbQKbCY= X-Received: by 2002:a05:6214:20a2:b0:686:1e2:747e with SMTP id 2-20020a05621420a200b0068601e2747emr2720892qvd.71.1705917430029; Mon, 22 Jan 2024 01:57:10 -0800 (PST) MIME-Version: 1.0 References: <20240118110022.2538350-1-elver@google.com> In-Reply-To: <20240118110022.2538350-1-elver@google.com> From: Alexander Potapenko Date: Mon, 22 Jan 2024 10:56:31 +0100 Message-ID: Subject: Re: [PATCH] mm, kmsan: fix infinite recursion due to RCU critical section To: Marco Elver Cc: Andrew Morton , Dmitry Vyukov , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, syzbot+93a9e8a3dea8d6085e12@syzkaller.appspotmail.com, Charan Teja Kalla Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 13EA640005 X-Rspam-User: X-Stat-Signature: 9zaybbtwdi9oyy69yu974iobey7bem9p X-Rspamd-Server: rspam01 X-HE-Tag: 1705917430-541818 X-HE-Meta: U2FsdGVkX19zy2wu+r1In8ja0vSd10Fo6g2J2UY3ODfpIh/dMe+rM6iXVCD0pKSojs9rhpMQ+Gc4u+oDRz68+TRu5Q0OVJ/wdU4mOpHw5xYoHdR97hJiDZwaVDkHxeqxfT6jls2dBwbm7/Ap1/scxOjbuImSOEq2k4axwje1UwnOXbQI8+vaLviT9pJhNQGL9jDpPgSXGtHiqBI5sYz5/CbFTt5AJzgZKsVYyfLYnWIHpCX5UmoJI2TC7vqyHpMVWZaRE3FHb9CXrDDLkCY1Ply8SL2n8lCDCLM40N0XnmLwdLtzORq7GTsM7mjhMhBi20xw3+lAQ3Lwl8IyoJK6ghcjyrV6OMVj+Ph+uTwe/bjL/H40+MbGoTuczxHsebbGTd2PSOPNrwqMNhdUtQPEPpbl9bH3sd2AAUMPUwmYAbbH4dDR3R3dGrsdQlxDX7Q0dcCVfGdmXutp0O1Mn2wuIyjvG1JurrI3o9iUZq5nP7ESyePrXEozU5ixjB2g5i7y0heL3jbk8bjm0h/ya4XNbYeo0I7jUg9k85drZe5vSIALH/i5VbJ3rmLLZW6RlY4RPT0awJNezi+jtqRUTSqheb44lnk1HaoOLwf0wnWzhGo/7Mv2v3FMWXA4xkbTZ8RXdGYT9H9Dz/wNPC4Y9krgkTJv4D0K1ebPsCHqsoEhgPYTnopWpn5TjraD1TSLgSBPBlRqkOWFKWimA0lHPJSYmO2DGwrPeNQsDlVG3Z7XgMcunzN/26dNNC6RkPvx+Pl5aVZDZCRLpGDHkQTzVeBAl1V7WpTrpYOC58ePBGnlihsrzXv9FxJNGLgJxmMuP5/eKHHOEFHvdhAZitG1j4Ucxxx1aOfFBomqpGORdJPGE7FQo7xy4rwo3D/0cDW+0MwON6X9pF2LX/RzbtdLvocuyZajV90VfNL2AmK1zp/7+DYLxKf4A7ggty5owBhwnA+s+uxy+morgRvLYd1a2yK 61nnofZl N2XWsF02YwOxwMARevNzmOphk8Fl3OvSqDq5Z80J6Kjg729XXrx6R8PX7veW6awAYDDYsre9hwtxjG5RXxHYaFNVT8DDLMZLeYGD/uPXqE3QYaRY2GexlD6A3894DJnnD8FR1u7O/oqkThnFMfaI997wCJbzjpI3aSMx6fHz0UGbLnAAbO/RLv8qA+OFlCUl/xcR5hx8Qcmvyk1YR36Cpkdb6WoRa/vKd9tLqRZYwFAgWrRd1NgLQJqDcHhxIhwgByAXhlxgyBUnIZzU/lAYJL9IaCdYo8VufJ66C5/X2i6/kI0/XQYOd6B8QCDMwH3FLu3Vmk6+LWKm0VC1yI4/rewKrLIElpYqyHIAbjtPDhKwzITIfNr4u7ie01C3Tkt/7EeSXISLGGSQIobizlK0he4AbGwTXzBcK7w0+K+UITw548747VZYdTLSyxeC1QIkAyk5e6r1gZ4ZT2zmq2JlbyhQDSis4o6yystROu4maXH2ExvXjFR2IBLpQjRzooUwpMV3v1cFWBhlGrqc= 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 Thu, Jan 18, 2024 at 12:00=E2=80=AFPM Marco Elver wro= te: > > Alexander Potapenko writes in [1]: "For every memory access in the code > instrumented by KMSAN we call kmsan_get_metadata() to obtain the > metadata for the memory being accessed. For virtual memory the metadata > pointers are stored in the corresponding `struct page`, therefore we > need to call virt_to_page() to get them. > > According to the comment in arch/x86/include/asm/page.h, > virt_to_page(kaddr) returns a valid pointer iff virt_addr_valid(kaddr) > is true, so KMSAN needs to call virt_addr_valid() as well. > > To avoid recursion, kmsan_get_metadata() must not call instrumented > code, therefore ./arch/x86/include/asm/kmsan.h forks parts of > arch/x86/mm/physaddr.c to check whether a virtual address is valid or > not. > > But the introduction of rcu_read_lock() to pfn_valid() added > instrumented RCU API calls to virt_to_page_or_null(), which is called by > kmsan_get_metadata(), so there is an infinite recursion now. I do not > think it is correct to stop that recursion by doing > kmsan_enter_runtime()/kmsan_exit_runtime() in kmsan_get_metadata(): that > would prevent instrumented functions called from within the runtime from > tracking the shadow values, which might introduce false positives." > > Fix the issue by switching pfn_valid() to the _sched() variant of > rcu_read_lock/unlock(), which does not require calling into RCU. Given > the critical section in pfn_valid() is very small, this is a reasonable > trade-off (with preemptible RCU). > > KMSAN further needs to be careful to suppress calls into the scheduler, > which would be another source of recursion. This can be done by wrapping > the call to pfn_valid() into preempt_disable/enable_no_resched(). The > downside is that this sacrifices breaking scheduling guarantees; > however, a kernel compiled with KMSAN has already given up any > performance guarantees due to being heavily instrumented. > > Note, KMSAN code already disables tracing via Makefile, and since > mmzone.h is included, it is not necessary to use the notrace variant, > which is generally preferred in all other cases. > > Link: https://lkml.kernel.org/r/20240115184430.2710652-1-glider@google.co= m [1] > Reported-by: Alexander Potapenko > Reported-by: syzbot+93a9e8a3dea8d6085e12@syzkaller.appspotmail.com > Signed-off-by: Marco Elver > Cc: Charan Teja Kalla Reviewed-by: Alexander Potapenko Tested-by: Alexander Potapenko