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 46AD1C35FE4 for ; Sun, 15 Sep 2024 10:23:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 610896B007B; Sun, 15 Sep 2024 06:23:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5C1AB6B0082; Sun, 15 Sep 2024 06:23:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4AF506B0083; Sun, 15 Sep 2024 06:23:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 32B4F6B007B for ; Sun, 15 Sep 2024 06:23:54 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 9FF181415DD for ; Sun, 15 Sep 2024 10:23:53 +0000 (UTC) X-FDA: 82566586746.25.1008523 Received: from mail-ej1-f41.google.com (mail-ej1-f41.google.com [209.85.218.41]) by imf05.hostedemail.com (Postfix) with ESMTP id A0518100002 for ; Sun, 15 Sep 2024 10:23:51 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=OenxbCHO; spf=pass (imf05.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.218.41 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1726395724; 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=f75/B+YJIkfShj1QXvpWl879ackrfJNXWNNR4sT+G0w=; b=QwOq9f6bZwE42cfWKL14TYkWUfZ/7lIqahpCo59UjRCKJ2knnZkdLI+SWImFambzTSgJ1o 5vBYmXk1phMseV7b5UI7KGcW/cW1cFjv6weJ72lBmsGyEqc8Y+ZOz706Z7sbSeDT9GA/RH +qn7NmTp1DTFs5xdE5UlcWdgZOhiTzo= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1726395724; a=rsa-sha256; cv=none; b=c/VZCLUufWMjWi1yj6fOCJXun21jbAA1b/FPQheCZuR+EbuxKSycLCByGr9/tUKzZDMvjf bM1hF+MXz/tW4Dc8+3ZkD4tbIFOVWM0/tIRLICLn+LDdtDmWrErfQuoZz84NevqWnYnFov 7DguJIql4qu5KgufSKybD8q129FY0bM= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=OenxbCHO; spf=pass (imf05.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.218.41 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none Received: by mail-ej1-f41.google.com with SMTP id a640c23a62f3a-a8d2b4a5bf1so478411466b.2 for ; Sun, 15 Sep 2024 03:23:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1726395830; x=1727000630; 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=f75/B+YJIkfShj1QXvpWl879ackrfJNXWNNR4sT+G0w=; b=OenxbCHOpbEi4meQpRdDwo2kn2WEFty1lHW2PqX0ASRufWcMO0M/jFEJiWFf06wKQd bVbDTdLN7W2HoksjNUcZagxb/4oe3bCNrUF6TRxt6z9ohyxWfYRIoKMV7mikMRF6qLoL Y8MzWtfFbFX0TBM8uH9ylpvQBXvw0jsASrhas= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726395830; x=1727000630; 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=f75/B+YJIkfShj1QXvpWl879ackrfJNXWNNR4sT+G0w=; b=DqpJBjVP+SvTSDAPfo0kjbl+r01sDHejcyHVyJUVoSC34BXmCmZmEYGNWisqqCVNpe f9fkfIEA8MsP82cE5UuZfSdn8F2PAEYaH0spWrVgfvA5hwPVWLRoInrIIUphnq0HuLVH wSE0ya+zaIYtxZgt0sL3+NL+4LXfTFFX4Bda1RognefvAYu6wWiNm53D5l8WGzD7IBn2 ifE6/XufqF4SnKyMBMyxb5145xB9XRlG7o1dYFqVAZsOjPVn5bZvE6UQMf7Arv1msFhm UNS8mHXbFrOSkZ1RgtrxuxR+veFfhUcoPCHrPxh2KRyGFdjn6ukGn5mX4TL+4OKHfinm Ejxw== X-Gm-Message-State: AOJu0Yz97jWiuPy028S0TvSV1FHL5Igsk44dEiQUKUuXkRu0BPI0Jl0i Y74Ue3c2kNBrD47PKsu8KVme8JTVR6PffRrXU8XqfoGAyayryFsVc6+x58NqkA7yieYFSj2tsQ+ iy8qzbw== X-Google-Smtp-Source: AGHT+IF3oA9vXdOi32u63XOtDQxL/D4hYq8mEumGLCvOZDZItL6/yDxo0LhtDDVk0PsnSwGtOwry9A== X-Received: by 2002:a17:907:efc7:b0:a8d:439d:5c25 with SMTP id a640c23a62f3a-a90294a881amr1282812766b.4.1726395829160; Sun, 15 Sep 2024 03:23:49 -0700 (PDT) Received: from mail-ed1-f44.google.com (mail-ed1-f44.google.com. [209.85.208.44]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a9061116c28sm182027066b.95.2024.09.15.03.23.48 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 15 Sep 2024 03:23:48 -0700 (PDT) Received: by mail-ed1-f44.google.com with SMTP id 4fb4d7f45d1cf-5c42bd0386cso1578282a12.2 for ; Sun, 15 Sep 2024 03:23:48 -0700 (PDT) X-Received: by 2002:a05:6402:278b:b0:5c2:480e:7960 with SMTP id 4fb4d7f45d1cf-5c413cbc723mr11477480a12.0.1726395828069; Sun, 15 Sep 2024 03:23:48 -0700 (PDT) MIME-Version: 1.0 References: <8e3ffaf2-358f-479c-8de6-46e1b0bb0c5f@stanley.mountain> In-Reply-To: <8e3ffaf2-358f-479c-8de6-46e1b0bb0c5f@stanley.mountain> From: Linus Torvalds Date: Sun, 15 Sep 2024 12:23:31 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [bug report] mm: avoid leaving partial pfn mappings around in error case To: Dan Carpenter Cc: linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: A0518100002 X-Stat-Signature: khbzp1mmxx74fbdbfm45heey1ez4ozsm X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1726395831-921698 X-HE-Meta: U2FsdGVkX18eWw7ImBB6BMiTATcJNnIy5awYMHHUvfntqwjMlUuWqIYm8jYRRHR1Q9Rh4zse9bx8QcHU8T08vy1y8ATD5JB75zVGEJLG4AHrOJ3y4JAakUNe0FgULu2DWZ3SKiQHY7oFtwgJptdHuf0mIZPBEHIfnKw459VQGpnhBwepSbQAyZ6b61vHCb0VOjA8o9fgh2OuGqYnp4w481HPTBNhRefjgM0OlPVpX4jJsRD+CUcoos8fgj9bjIil1IShZQFZ3qR70P+zWpImCsE9Om0b2ExnWvmRFVUivqj9dt9fBtNnAZGiiiwXIH09nutgr5qMQG0mOSxC6akXbrynVoNnrXK1vL1obzVab+OMeKN73w2UqLqLyx85DTBMliBUZrdWpbh3z+x1aCR/bvlb0TKbp8ZurF4sngvS9sYRIrkqHUvXD9CqmSwTTIKumNrH6f2PGywcPqgh1nAbIkUdCVzv5UuVor2SRzf0mMRvN/hPFzvBG2qostXXJ6YIVN/xSkrmE/3AR56hAM0EbaXyeD0Wlj32e6icBQ8zj6WO0jauOwOTc494BNr2lZMB0ZGqlcTeWIFs8h3mTY9seLUqTKNiGwyskJOmzpRTaYa5x4PRsSlc7/FXMACfZkz7lRkV8I6sPgx8KzEWZQ22HKZCLzHCzjzOE74oZLEBZ49ZJ5TQdhNcfR59+2P/aQm6PLvAQaF3mFdWXfofDBPDqz0Eonja0iDLl/uEZ/evqR6gUR0PNIRbrxPMfQB7WC3aLOZtkrdvarYAbv4DiQwYniV+WnUveDlVyNtCtfUFOMCiZBArQ7k78vvWPspbwFtKWeXCVcjsMkXxs6ApuQFE+B9ZpJG59OGhw3dw0eMLXOUMtVon7U2l2gpvr0teGfjfnv+nw3a9GB1RK0+Dt16eTgmyPcPo9uaQGpbzzrnJdGurotQDyVCOvjEtrYb8hoyjeHGyO68PnNCn2K1PBD7 0XehzBcn qN+NPfnL0Qq31rzbkdtf1SZhDqeGijMWKtWssdEv+OwnXRvlvNaWbL2a4VLa7Y9pENvZWSLT3AnA37BKUZDh3gKOUiBQnUsuOslSeQNvoltIPrPrwj1I65ZsT49BU4E991n4AxIui0kbz3uzSBZ3W+OzOlfpGK7SdQHUUc4KWEVLYzZiSI0nRkNBYtoU/JqSc+hvmISwY3cr8OifaCu4NUH/alpnBXtoWgnteQR3TtZuerV6cqmkbPMErsCcEjA8tjEbWWREAGLuMUJYh8tdiRPk66SBXi1xIwTBgwXv+c28ZfXiXHAdGQSR0nkVk7NNKPhHuJqL929SV3EubLO8fasjsc9zmLGshtPC9G77KKSmiyEg3waD12XcHpcjwHXZn8tbvM/Eet1a5nH7akEzv/hoYrodiO2ZNbxAQ/nHqHm22q3WXEZ1pNDA0A1xcODDmdQC9H4YvF4MfwLWL5q3zi3S+82AO9C5upCA2m5t0eDtvDML4lNwk5otco0wgDtW617ku4DQWJ5SmQZpuFS5sfeBSoDTpQdwZ3mIKRHCKbLOCX4gJjbn46VzVGt1v+nzqPfFjKkh/SsBfRFlNsZJ0dHmNeC1ountRgxs5dHEi3IQyJelw1hYGbgu/RiZ/Npj6dyKyPF2gpTYrbUYprOvK43YkDw== 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 Sun, 15 Sept 2024 at 12:08, Dan Carpenter wrote: > > The lru_add_drain() function at the start of zap_page_range_single() takes a > mutex. Yes, that shouldn't be problematic. But: > It's the preempt_disable() in gru_fault() which is the issue. The call tree > is: > > gru_fault() <- disables preempt > -> remap_pfn_range() > -> remap_pfn_range_notrack() That code is very odd. It was invalid to call remap_pfn_range() with preemption disabled even before, because it will allocate the page tables that it fills in. But presumably *that* never happened in practice, and so nobody noticed how broken that code was before. Now smatch seems to see a new problem, but I *think* it's because smatch didn't notice the sleeping by p4d_alloc() / pud_alloc() / pmd_alloc() because those allocations are all conditional (so smatch doesn't see them as static violations). Put another way: I do not believe this is a new issue, but perhaps a "new to smatch" issue? I do get the feeling that even despite the pmd_alloc() having that conditional, smatch should have seen how it goes to __pmd_alloc() and then to pmd_alloc_one() and pagetable_alloc_noprof() -> alloc_pages_noprof(). Have you maybe disabled those warnings from before? Or is there some other reason why smatch just considers that to be ok with preemption disabled? Linus