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 C2453C3DA79 for ; Mon, 15 Jan 2024 18:44:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5AFC16B0098; Mon, 15 Jan 2024 13:44:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 55F176B0099; Mon, 15 Jan 2024 13:44:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 44DC06B009A; Mon, 15 Jan 2024 13:44:38 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 3660A6B0098 for ; Mon, 15 Jan 2024 13:44:38 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 053A040506 for ; Mon, 15 Jan 2024 18:44:38 +0000 (UTC) X-FDA: 81682421436.19.D5A0266 Received: from mail-yb1-f201.google.com (mail-yb1-f201.google.com [209.85.219.201]) by imf06.hostedemail.com (Postfix) with ESMTP id 3D504180007 for ; Mon, 15 Jan 2024 18:44:36 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=dupHhIrP; spf=pass (imf06.hostedemail.com: domain of 3E32lZQYKCNY8DA56J8GG8D6.4GEDAFMP-EECN24C.GJ8@flex--glider.bounces.google.com designates 209.85.219.201 as permitted sender) smtp.mailfrom=3E32lZQYKCNY8DA56J8GG8D6.4GEDAFMP-EECN24C.GJ8@flex--glider.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705344276; a=rsa-sha256; cv=none; b=V4CU4Fh4/C5tF8hFpQJKeNQGg4D2sxVXu4u1golwRi/wcjJAuaj9GoD0HFZ+7adN6dQAjD 77SD44ldAkEP8q/x7yP+VH4qXd5PPTpbXxAd7VhtT9ySowsEDGt93sLxPLykcH6hlaIqRp GaRzeEATmLhsF9B0yX9i7mIh+sf+7qI= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=dupHhIrP; spf=pass (imf06.hostedemail.com: domain of 3E32lZQYKCNY8DA56J8GG8D6.4GEDAFMP-EECN24C.GJ8@flex--glider.bounces.google.com designates 209.85.219.201 as permitted sender) smtp.mailfrom=3E32lZQYKCNY8DA56J8GG8D6.4GEDAFMP-EECN24C.GJ8@flex--glider.bounces.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=1705344276; 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=uCCPLj9WIEdpIVdqzT004aXc52PF8jQhxejOjNa7h3c=; b=sdup/pN5Lk4XzJL7po0BA64wYC67cuLnq5YL4mcoYrsbE3eNYsD6xu1Pp6MRsnXORDPTcb kUUzN75BLhj9c0Xh8iS6vhZLb9TLYySgubuPcvVnPDx7SqPyuO7P1yMawvnlionPYqt5le JFbNBGDlWg+cERgVnbmT6FzvU383efA= Received: by mail-yb1-f201.google.com with SMTP id 3f1490d57ef6-dc221ed88d9so18323276.3 for ; Mon, 15 Jan 2024 10:44:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1705344275; x=1705949075; darn=kvack.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=uCCPLj9WIEdpIVdqzT004aXc52PF8jQhxejOjNa7h3c=; b=dupHhIrPn/Q/RTYHNCxGCi74e5I548IjE+N3oWvqB3vlUDsKM+KeGckuA3hPtkKlyl wxojtUtCnnUTOdtwaD0u8fn6gjdc8dpvV9Mbjt2rKu7M4hy8qbEc2cI8aEtUkcHa9SQz ++ft/BOU9oJJ7qPKTExZuoyNnZJ/rMn3dx53POUheP9bkTokjThiq3legEDSxr4/QdQ3 0TLvFthLL2McopHVkxmiGP/LulLh8HENZEbDMi2EpDd8FEQQirD4lKrqAK/C3EezhRdA qwKerCS3OhEpDnCkTCjcYKATS+RkZTdswL5eXrRNPJG23IIoib9QxmSavzcBm6Wb998L kjPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705344275; x=1705949075; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=uCCPLj9WIEdpIVdqzT004aXc52PF8jQhxejOjNa7h3c=; b=KSjwzPgj5oEBK+Q4nL8WEUTjUPc9AE9cs/S2mpaTw3oDaqPcTldWFdoJNjk37Gs5gN 16fOZVXXhcqdI+yR24+sRE/1A0+zY1Ky0Sp2yBAwS3uTboMSfdwRyuwiWFXEB/nZ9CDp sN3kIGTkEINB4kZoO1FO/fE+t2usTmrO8jKyb2+sfVqthwoddd5EOdvnN6Xc9SL4KDJs PN1zG7FOzoJmXKkM6Auez3qJq6ilBf0jY4OX5DS4fgLPISAUUkbZMOU5LfZqaKo+5ou0 La+84254zIpVXXVeaq3paMjA7cI/EaCB6e9mUSCZ7hNJmRczplMiAF18sTbXZxrhGFmH t9gw== X-Gm-Message-State: AOJu0YzJoZimItoevgY/dIcfJjrZrryg+oQoUhI6jX8aYufikSqjoz7E j7JAElGLDznJGw9tqKIcFjKrPZZjiKmkU4Yggw== X-Google-Smtp-Source: AGHT+IFCJ46CqM1/C8q96wk9dmF/Gg8dE6SjoZ0eTf1WG2ltKm+jUuofZWPaIYijnmKF8B+lilmt6hSO/Lc= X-Received: from glider.muc.corp.google.com ([2a00:79e0:9c:201:c671:6fb:2d64:ae58]) (user=glider job=sendgmr) by 2002:a25:5181:0:b0:dbe:a0c2:df25 with SMTP id f123-20020a255181000000b00dbea0c2df25mr268706ybb.8.1705344275329; Mon, 15 Jan 2024 10:44:35 -0800 (PST) Date: Mon, 15 Jan 2024 19:44:30 +0100 In-Reply-To: <1697202267-23600-1-git-send-email-quic_charante@quicinc.com> Mime-Version: 1.0 References: <1697202267-23600-1-git-send-email-quic_charante@quicinc.com> X-Mailer: git-send-email 2.43.0.381.gb435a96ce8-goog Message-ID: <20240115184430.2710652-1-glider@google.com> Subject: Re: [PATCH] mm/sparsemem: fix race in accessing memory_section->usage From: Alexander Potapenko To: quic_charante@quicinc.com Cc: akpm@linux-foundation.org, aneesh.kumar@linux.ibm.com, dan.j.williams@intel.com, david@redhat.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, mgorman@techsingularity.net, osalvador@suse.de, vbabka@suse.cz, Alexander Potapenko , "Paul E. McKenney" , Marco Elver , Dmitry Vyukov , kasan-dev@googlegroups.com, Ilya Leoshkevich , Nicholas Miehlbradt Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 3D504180007 X-Stat-Signature: 6t7g1r6j94h1dig9agfh6jdx1rbqqf5y X-Rspam-User: X-HE-Tag: 1705344276-427789 X-HE-Meta: U2FsdGVkX1/BU4HhAn4aHAyWH3TLK6aEdlIuKJ40t2tiozqO66LUpP0aQr7rZgr3HKAXVBl9/nV7ujOEePavrZjiAroDHSa3pV1nmySovoF1Su6Xoelm8Ga4YgFnLN6VyPLLE+L4HQ5ZEbK7l1l32p+mymCCV67j1H/rPpBZyLNXw8papyBdwem/S6IBhmBS/lxB8teD48E4ZS3SXCYEKWK+VKQlvcwWq/oBAh51LH0f79UjE40sPb0A4m4waIuJf+bcjkhpWlJlfF9kCAXUllAPqwOClJUKFPerpCEACEQ1PtMNJzbzIf1On7aIBoM2tjreFoZY9Hen14aLwTAELc9ofrCWgtnAm3iQGIDdYI7NxLO9sKiIcdh+nqjFyAe8Y3WgCO1BKbkQt++xZctjH2K+xHvEG9wpIEGezUJ5C2VpxrFlpzFpgRI4XmeXlm4gWz6+VCAKkd4508pIEUWAqGT2qi4uLAln6UvDRTnQbzi0e+I9gZhWNAhF8M4P5EgkXTspzuvEE0TfWRkB59EnmQ9FJBdyQOk8uT1H3ROozYjY2E1QAAhP1oXZcVO9KqoqJQkslYq7k+Ff2JRIDAITwtm80QJvnZITHscTcKtM7Pz+qySyJuYCQdETLwvYhMBgRNTB1l47lCsVEpBKZ8yCqNe8tJ5ktLNXyWi67NKshE5x81CuCrVGyEBxYQHf8pdOzqp5jjJxWbIRHxBHBh/dQ4zNfSiMrul5+em9bN5fWsISvK0IPgtFF3OIIC605yRvie5+1AHkFqrWgYYg9Ui8KyaYPBEfyoIc5vfekUQ943pfxTx5blv/y9Mnx67OssJFClf2Kcwn0HNNEZnaNHhNiwpZ5mDdHKdp+9A2fnsiCzRuQnlijDW97LzkuVWZqGUYpB+3hMhu1S53D8A5dGNwSqF3GGr2NcxvA18FABBGNiQLEl0bsA2O4c/5cv8CHGFasgIevJnS/rSnIZ86w5S aPeGKk9X 8e5yw5nr7EEHLJKQHm1/DDc/N3xPNZSmKBRfDQPe4BaM4MfB7OuCApRMDgE+UJ7RQ6KPbWPmn70KVyroSg7PMpayi0009DTGWJupf3EiINhGkGVOhemvyTT85vDUoOEmsl0vWMaV3q7SOkPFbiKAYx/dOZZUB0bhDJwy2cAjOIIhLbIixpZyZs0BW8pdoL8gS+cqUF6UTcyhoICaDr9Ujj23KnswleeRzCmr3NnpLhULWI16L39glWmmZ4Tm6Cy9bZLjuZu49sM0tEHl2ZHJJuRr+O4SuhwJ0oR6oh5aKi3SEQbBiS/FepeH27GxLuPvTqDuBMQEG4s1bN6IXMf1MCe4P6ZFOkRBQMQlszMiLJfVoXBzq1t9/n4WBAFmbcwMKk7ZK1mIoJ1rHs6fU17G0Ujjf3KZhP20vvGjKIDyyTyN8Lw+kOnQJYhs6+xwV5+ad0AXo031H7HlqRulT+UPk3UpAar7IaiIfR9CJ7BQxwb5UWVRPPAKdUVi3MH0TrwRe5KWf/8QttOJSzwrHE9vP8a1V29DOM19cF915m0LdEWpIoWg+WNj42WEMxPHInSYnhdEOkLCu7C5sALT6jmLKHBlHRlKOawfkNBl1fC3T4gPXQLV79M/Xlyb0EFju7gcBhbwrD5IF9KmueD3eoEiw8PUTesJMvwKqm71osKMSjeDUV/ScF/3aL2u3nA2RdyBdZQGtFAHRuFA4yVFvjEI10hEyOOu8rPus+086LDAR/USkVzpoXYMi7Qc9tgXyeAFSdp+1XC2bK/YI9j841BJ+GhRCLbuzrO6HG5TUnE/bzghbIeI= 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: Cc: "Paul E. McKenney" Cc: Marco Elver Cc: Dmitry Vyukov Cc: kasan-dev@googlegroups.com Cc: Ilya Leoshkevich Cc: Nicholas Miehlbradt Hi folks, (adding KMSAN reviewers and IBM people who are currently porting KMSAN to other architectures, plus Paul for his opinion on refactoring RCU) this patch broke x86 KMSAN in a subtle way. 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. I am currently looking into inlining __rcu_read_lock()/__rcu_read_unlock(), into KMSAN code to prevent it from being instrumented, but that might require factoring out parts of kernel/rcu/tree_plugin.h into a non-private header. Do you think this is feasible? Another option is to cut some edges in the code calling virt_to_page(). First, my observation is that virt_addr_valid() is quite rare in the kernel code, i.e. not all cases of calling virt_to_page() are covered with it. Second, every memory access to KMSAN metadata residing in virt_to_page(kaddr)->shadow always accompanies an access to `kaddr` itself, so if there is a race on a PFN then the access to `kaddr` will probably also trigger a fault. Third, KMSAN metadata accesses are inherently non-atomic, and even if we ensure pfn_valid() is returning a consistent value for a single memory access, calling it twice may already return different results. Considering the above, how bad would it be to drop synchronization for KMSAN's version of pfn_valid() called from kmsan_virt_addr_valid()?