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 D3D41C54E58 for ; Thu, 21 Mar 2024 17:19:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 322E46B009A; Thu, 21 Mar 2024 13:19:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2D3986B009C; Thu, 21 Mar 2024 13:19:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 14C766B009D; Thu, 21 Mar 2024 13:19:44 -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 033B56B009C for ; Thu, 21 Mar 2024 13:19:44 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id C4DDE1C18FA for ; Thu, 21 Mar 2024 17:19:43 +0000 (UTC) X-FDA: 81921708246.03.B7C08AD Received: from mail-yb1-f171.google.com (mail-yb1-f171.google.com [209.85.219.171]) by imf16.hostedemail.com (Postfix) with ESMTP id EC63118000A for ; Thu, 21 Mar 2024 17:19:41 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=x+TV2nab; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf16.hostedemail.com: domain of surenb@google.com designates 209.85.219.171 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711041582; 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=tqvfQSGh+Xzm8qjoxKwBWCT5Q1J0hViT+VZ+PA5jO/g=; b=RQmb/THbmtSHJK/0R68AlTSbCz6xzFIhzoZVCj6y/Ml2UH4iCjNk+2d75aCFW0l6qCm6U/ vTouENL3D6+YlCaZcY4W3JqliIWuVW8BJkTNJD0Zik/oYKwBLEjr9PM4pigPujGvhoPb0D kLSGOVc21hSjgny13AzK9yl6Na1sitU= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=x+TV2nab; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf16.hostedemail.com: domain of surenb@google.com designates 209.85.219.171 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711041582; a=rsa-sha256; cv=none; b=DGvp0KkkGHUaKwGlPt8gvR7KPYtdfzCEC8OJu7zhfMFPjzAOvgSNnwlOhKhRelgmtE0vTT A8Sg3PMW0Wfw1lm1nyRN30OmfNgbBmTGzVj4HZvyKV/1LF+RSJvwoC1D6uqzC4Oj00vxUa p4HWZvGwaj0yTRYdkqWhXbeCy82U9pE= Received: by mail-yb1-f171.google.com with SMTP id 3f1490d57ef6-dc236729a2bso1166295276.0 for ; Thu, 21 Mar 2024 10:19:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1711041581; x=1711646381; 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=tqvfQSGh+Xzm8qjoxKwBWCT5Q1J0hViT+VZ+PA5jO/g=; b=x+TV2nabbP7KQ4ockvlJT+qNd8MidK0xF8A0I2WRKtcywmOC7hdJoCKIm6XlZ154hu ZoM2NLfpNODQ49CF+WrtDQtMOLnQ06lZGLw4r9v2N/hUWI5A4iQbSPqoP8cDXNSFY2SC xZmjvik+aSJn/RwQJKPNe27Y6Ffk6hwvQ2NN6nkD2AgPTX+lLzwA2679Mx84qCPqwO4J isH91CSknMWN/7mGvuusQit0197rovYbAsHppo+Ezu0nqEA5xcN8SUJ+qc+i5aTW6DLX kBt3UBOlutEX9Ay7lXYaJB5LGVT10uEA28utsx3gduu8gD9GU2fIefOSx4g3hJP7Uu2w oWNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711041581; x=1711646381; 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=tqvfQSGh+Xzm8qjoxKwBWCT5Q1J0hViT+VZ+PA5jO/g=; b=M9SNTfAHS+6aP4MJ9Ss4BL3mF9+4D90nfTi47uHxbxto5ppMdP6/i4+qBsTWEVuCqM vYLEArlZNYrg6H0/3MX6GqqG4cKUn9Cr2Jazmr09yNvBrKnW0ck8oPsZuRuA8ejksGFn ny8BECKkQgSDAgB+a/yiz1qKxq+8U9bihcE0m79InXuQPUtwxL8vJg70nJ0WCiAWThJY QXl08PpCrWmUkHRMrMD3W4yf2q4NL0uo8wrkAVqC+/dQXwWhnK6Gj9m+tMkdtq8l8Mbz iBfv3T1EsmCtGb06b8EmIX9zyPbQI+9GRTONXszP2jjAi6Fz3TJUpBFTV5JFTDMFKtQ8 71GQ== X-Forwarded-Encrypted: i=1; AJvYcCXG9hYm0OKdE6zk7/X86zeEFTndSe8bS/IpXUZ8JAKXil69X0Q5ZNiVN+HkjuQcaQ+7NaF00zu8URJZTX2M67bwR8o= X-Gm-Message-State: AOJu0YxyaU+VGZz8IHE25Va/MTwaoEr/nFAzoqnTwoKwPvIoimzXaZh2 fWMEiOGSuj0cR9P/LkdxWjU/EOm4vuYyk6hJXr4E1tNRGie7N5ERTUv/93aw9LGIzgtNOC2bV/0 nM/HtipYr2tUYm6sJXzb/iXoesvae7xWsOzcZ X-Google-Smtp-Source: AGHT+IFQSVcpwYKqTi4u5vLJp+bH/Ul0qxjQJHN69s16T75E6/ejSMbPrhKw6oCEZl5ggVcRzfP6qAeH1y6UeIwfGAA= X-Received: by 2002:a25:dc4a:0:b0:dcd:4e54:9420 with SMTP id y71-20020a25dc4a000000b00dcd4e549420mr19795790ybe.5.1711041580565; Thu, 21 Mar 2024 10:19:40 -0700 (PDT) MIME-Version: 1.0 References: <20240321163705.3067592-1-surenb@google.com> <20240321163705.3067592-21-surenb@google.com> In-Reply-To: From: Suren Baghdasaryan Date: Thu, 21 Mar 2024 10:19:28 -0700 Message-ID: Subject: Re: [PATCH v6 20/37] mm: fix non-compound multi-order memory accounting in __free_pages To: Matthew Wilcox Cc: akpm@linux-foundation.org, kent.overstreet@linux.dev, mhocko@suse.com, vbabka@suse.cz, hannes@cmpxchg.org, roman.gushchin@linux.dev, mgorman@suse.de, dave@stgolabs.net, liam.howlett@oracle.com, penguin-kernel@i-love.sakura.ne.jp, corbet@lwn.net, void@manifault.com, peterz@infradead.org, juri.lelli@redhat.com, catalin.marinas@arm.com, will@kernel.org, arnd@arndb.de, tglx@linutronix.de, mingo@redhat.com, dave.hansen@linux.intel.com, x86@kernel.org, peterx@redhat.com, david@redhat.com, axboe@kernel.dk, mcgrof@kernel.org, masahiroy@kernel.org, nathan@kernel.org, dennis@kernel.org, jhubbard@nvidia.com, tj@kernel.org, muchun.song@linux.dev, rppt@kernel.org, paulmck@kernel.org, pasha.tatashin@soleen.com, yosryahmed@google.com, yuzhao@google.com, dhowells@redhat.com, hughd@google.com, andreyknvl@gmail.com, keescook@chromium.org, ndesaulniers@google.com, vvvvvv@google.com, gregkh@linuxfoundation.org, ebiggers@google.com, ytcoode@gmail.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, bristot@redhat.com, vschneid@redhat.com, cl@linux.com, penberg@kernel.org, iamjoonsoo.kim@lge.com, 42.hyeyoo@gmail.com, glider@google.com, elver@google.com, dvyukov@google.com, songmuchun@bytedance.com, jbaron@akamai.com, aliceryhl@google.com, rientjes@google.com, minchan@google.com, kaleshsingh@google.com, kernel-team@android.com, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, iommu@lists.linux.dev, linux-arch@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-modules@vger.kernel.org, kasan-dev@googlegroups.com, cgroups@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: EC63118000A X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: xtm16dyaiumy7iqhb4444bgo79kerem8 X-HE-Tag: 1711041581-509456 X-HE-Meta: U2FsdGVkX1+c/Hc2DUMgx/o1fC/UUzgtTDJq2LXpwpbTen/jCiiWYYYxjuDsQ98retjZkL2oPKPp3ykUouo6bXXHPE1MCe2+MDqDMxqWUkriM8yLTzttvB5ySSHqTbd1o6pDi9QCxhPCN2COc3LKASCxQV5f0b0Ki9D8tRhIsybDYgaPogs2itAyumN2fbTkgGIm2A+VBXNXZeKt3tZwHozkw+QIVJ7QnsN3IHkbvxMZwma6tRuYUES2T+RdhjtDZb/Uhc4hJ7+ngCl0lxVxBDHpOuolBynXCrFFbX+Fo5JkgTz8C/l44Nnh9e1m/e1SaVBgX6BNU5dTCfQtw+5gdSsAhzz9wJ43psbI+m/Mquii/j2ZhdH/Vn7cfgu1t/YVEuEMy2txIvEAsRbS/WiMAF88dm1qdQTtwowLy3d8WzxapngBPsHtzIoTb3yJcrTHKELlKsobJ2ysIkhuVCEkBmhcO//vpPqN/4b04YSLICd2x8Y9UkKsW+krrl9L5LkfuuHzlhXsn0mjp5d6lwVR/r/deGGgP/2T74Xr7QvFkpgQyS5XJp/iI2i5Iwc3miEBxyGYR2z181C59Dj0R9p+/gctcbRAPbyhJyC5JXr65jwVmQ2U4uIyT/+5DFNp/lYc6xbSbq1BoavShByMYWSrMmXVkZiJzrIi9uCc3FQyHaU3FVh4HOQGBjdEkViuOhlwdUXyTDlQXPSFvn2gjiHzDhe2XVcHZaAnm/sgm8nxgRtkmJ/xVpUlFWzMW8dsOQqdUfbjL96k2Qoz3Oxh0fcZavtYLEDrYQynMkM8bwCZKzvH5Yb+cFkssFR5j773vM7XMZ9Yht1SGAcBMYg7sVy5vRfMjRTPy/bcLX6G/ZVilQWKHuxTY7Wy7Mz795CQTTysGXqSeYW2Nfe7wwOe1791Tesb9N+iTfvwkKt9xDyBbGSSnfooGAc6e8rZ6dnF2Gi3jLaNfXPzIjBdOEfqany prJZ35vn pp3ACKQi3guXi+qRmO5p04bDB+ccZtsLk5mModPDsT6xbRscrOAveZhzA8OKcDm2imW6IVNAI6OeENAS7Z8LvVqWPK0dGmlU3zSKlcK9beBHNqpypecZEICHF+mwGMJ0lCI3da4BUEmqRUVrqXViWaQ/wiz58jJavO3VvhjY1tCSZ0pXnfv8O7IvnmjFkIeXalvvuUhj6daXdwRcUGuD68niqFTgoh7RDYSutp8fUuWEsqrfWeqBB2/6/NCVxBJaU11SLx8OBwqzunXFumDFZV+jO/OXnqJEZiMYtJVzZ3kEzs72fjgVAZvGrOkh5jtiUMojJ4DQfUI8uh8z2CRnTeatKbTqzuzRLeMRs2AWOQWZnjyTtAQq520kwaqMYpTafdsSsMyWU0JiZcPyisQMcCMpes1wLIFdFFNiLFMpe16rIXy3Z/P5RIZtgR1d2n4FKR8yllFBZlKGx/JVzsMD2ftDNMgf/C8a/c6luVdpGRcXXn2Y= 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, Mar 21, 2024 at 10:04=E2=80=AFAM Matthew Wilcox wrote: > > On Thu, Mar 21, 2024 at 04:48:53PM +0000, Matthew Wilcox wrote: > > On Thu, Mar 21, 2024 at 09:36:42AM -0700, Suren Baghdasaryan wrote: > > > +++ b/mm/page_alloc.c > > > @@ -4700,12 +4700,15 @@ void __free_pages(struct page *page, unsigned= int order) > > > { > > > /* get PageHead before we drop reference */ > > > int head =3D PageHead(page); > > > + struct alloc_tag *tag =3D pgalloc_tag_get(page); > > > > > > if (put_page_testzero(page)) > > > free_the_page(page, order); > > > - else if (!head) > > > + else if (!head) { > > > + pgalloc_tag_sub_pages(tag, (1 << order) - 1); > > > while (order-- > 0) > > > free_the_page(page + (1 << order), order); > > > + } > > > > Why do you need these new functions instead of just: > > > > + else if (!head) { > > + pgalloc_tag_sub(page, (1 << order) - 1); > > while (order-- > 0) > > free_the_page(page + (1 << order), order); > > + } > > Actually, I'm not sure this is safe (I don't fully understand codetags, > so it may be safe). What can happen is that the put_page() can come in > before the pgalloc_tag_sub(), and then that page can be allocated again. > Will that cause confusion? So, there are two reasons I unfortunately can't reuse pgalloc_tag_sub(): 1. We need to subtract `bytes` counter from the codetag but not the `calls` counter, otherwise the final accounting will be incorrect. This is because we effectively allocated multiple pages with one call but freeing them with separate calls here. pgalloc_tag_sub_pages() subtracts bytes but keeps calls counter the same. I mentioned this in here: https://lore.kernel.org/all/CAJuCfpEgh1OiYNE_uKG-BqW2x97sOL9+AaTX4Jct= 3=3DWHzAv+kg@mail.gmail.com/ 2. The codetag object itself is stable, it's created at build time. The exception is when we unload modules and the codetag section gets freed but during module unloading we check that all module codetags are not referenced anymore and we prevent unloading this section if any of them are still referenced (should not normally happen). That said, the reference to the codetag (in this case from the page_ext) might change from under us and we have to make sure it's valid. We ensure that here by getting the codetag itself with pgalloc_tag_get() *before* calling put_page_testzero(), which ensures its stability. >