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 29A75C02188 for ; Mon, 27 Jan 2025 15:02:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6B766280167; Mon, 27 Jan 2025 10:02:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 667F7280165; Mon, 27 Jan 2025 10:02:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5566E280167; Mon, 27 Jan 2025 10:02:37 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 37B05280165 for ; Mon, 27 Jan 2025 10:02:37 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id AB7F01A01E7 for ; Mon, 27 Jan 2025 15:02:36 +0000 (UTC) X-FDA: 83053548312.30.35CE09F Received: from mail-out.aladdin-rd.ru (mail-out.aladdin-rd.ru [91.199.251.16]) by imf25.hostedemail.com (Postfix) with ESMTP id D44CEA001D for ; Mon, 27 Jan 2025 15:02:32 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=aladdin.ru; spf=pass (imf25.hostedemail.com: domain of D.Dulov@aladdin.ru designates 91.199.251.16 as permitted sender) smtp.mailfrom=D.Dulov@aladdin.ru ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1737990154; 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; bh=Ee/8YNHXpscwXcAA9uYMwTM8S3Ua0YkgB6gFpSCw4Ks=; b=5HQ1cFYBBK2RdhUnAj642vCxrPiQ+J4vQDv4a47Q94AXPo8PAL0b4Vlqv+mILLqa1GH45L FphPMAfnS+67XXQINj21hIWFQb1ofU5RFLw6aUoUbflQ/TykKuNx/ToNOQ2bJDG1y1L6It HpwHNFZ7lrfvpUZUzXtUjc/3znnOCPw= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1737990154; a=rsa-sha256; cv=none; b=KeU7Ga7KLdII/wBHCesIs4j3/FaSfKGpxMC79cET0JWZQwtB1F5hRIEPD3c7/VzNBw544O l5kLebHH7Etn6Qb9V8/vs4cyFN9YaY3VX3ZxOKy5EvVlvWB4Habacu3IdU2DgpTyb8F+z5 /ruEJUPX+7Fv2WqIuds0wgGQlkEbMnE= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=aladdin.ru; spf=pass (imf25.hostedemail.com: domain of D.Dulov@aladdin.ru designates 91.199.251.16 as permitted sender) smtp.mailfrom=D.Dulov@aladdin.ru From: =?koi8-r?B?5NXMz9cg5MHOycnM?= To: Lorenzo Stoakes CC: Andrew Morton , "Liam R. Howlett" , Vlastimil Babka , Jann Horn , "Matthew Wilcox (Oracle)" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , "lvc-project@linuxtesting.org" , "stable@vger.kernel.com" Subject: RE: [PATCH] mm/vma: Fix hugetlb accounting error in copy_vma() Thread-Topic: [PATCH] mm/vma: Fix hugetlb accounting error in copy_vma() Thread-Index: AQHbcMhQSVzPYt8UC0WR3XfsBPQhEbMqgLMAgAA1bSA= Date: Mon, 27 Jan 2025 15:02:26 +0000 Message-ID: References: <20250127143201.45453-1-d.dulov@aladdin.ru> <83645f1b-cede-455c-abc0-6f105199eee9@lucifer.local> In-Reply-To: <83645f1b-cede-455c-abc0-6f105199eee9@lucifer.local> Accept-Language: ru-RU, en-US Content-Language: ru-RU X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.20.125] Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Rspamd-Queue-Id: D44CEA001D X-Stat-Signature: itur5qkw39ww3pmtfrbbfkqq8mx8mp1w X-Rspam-User: X-Rspamd-Server: rspam12 X-HE-Tag: 1737990152-482188 X-HE-Meta: U2FsdGVkX18Bv1BTmDn9cpWYYanjyfXTVTqeRHTH6gAeXZKNNkRh08uWGiyRiPs00OUvMLp5pPICZI7cTfcIqNalQa/GTj2Gb8M3oykPNB3y36pBDuE2pFM+vtQ9fRRGKHVGHOg+ei6aJqLtW+bc+eMKM3jPo3WwKOPOQZXv+WyUawQQuTwF94qZQ0yAx3tsqlJxypQCoTcJG8212T/YB07vxHz+EjII37MQwYfpH9Epft19DwrZfwl/UikgNWFKaKW1sjq/eg3j82+i7pJW7jqn802y+Prizh0fHhXmcCnzKc469QRBw+3RxbXbsXbLrWm3GDmy7F0G2TcFG1RjO6OYVRkh1kS0rIdvP7avzlufDVJAVHz4DGT/fTISyCPFVNPvpra/AyQk5bavCO5cXmnt43xhlJhZCVLCggYazBQe3VRuy9iSzT/fLHTNmhWlW90XJ1B70TE75i1iJ11g/NsNJG5e9HpPnRdEjC6L9juCPeftpeE59912SHEQsUd+cFaY6mEv2DWNsSkNhVEEQA4v57HJARQpnHq7+ziE1yHrssz6ZpDS+EFhF1E8ft54eBxCDVBW723Y9sIkgr1yX4Pv5N8hPhOZmGoZ5VbO4J8KRx4zzvXRlVpz6dpsW6Q755QiUgUBzeTNqZXZBJFUdK4mPgbuLm8hgTR/CkufDGmKoi5p3TCY4TsdxPXKWFph/QdCUMRhAjAZZmAje3HJ/IXUelyMJvuKzTfmOvNW1TJehyhZh6CFCWKzdx/4QbJnf3mtdHf4fPuSIZzeCudSnqAXxMlqN81TZfMlam4eJhYNTMIZtwl5oNwl5n6A6Ixbe4IoQ88R2azGltza/On42mT5SCXxOWOUo1H0xbTZGIc2pk7u05f57q97YITrAIuTx8cQlb2ds5B9MVlZPyvWtds8O2HghRmyasqqnTvJLxqLVGOaktfiBGaQYsJ9BZ9S/Buclh9DjRIs1hGYccg cCNjzPSV xga6OGJO/KtgEz7IZHnX4joCBV2TPg0lMoC6MGjvGQRVqh5bBxqgUnPXWZtYhn1xAec5RgKUqhCR03gzQwE2Q857hFmCX+bnUtYnFvYHpcVJZQohbM40n4ukK0RqaSCzidH1Bj4Ajo29seLtJdA0omb2pRXEeOmJ73UHiRWN/oe2OeevT+VIm+vig8A8yNAEQkVxCg9T8hdwaFBvfPyHtMnLSWt5CfzaN5DxrwHd3dqmuxbdvlooKivkEqzcJMezhGAjym09zLcqg5BJfAg8CLGJa7VKmz9LEJRuw75vEFvsyy66Bb6BrMHNOPlRS44xmyTyN2lIdQVSj/U4Z41sGMMnoqoYmJGLy+xpp+WxUPxet1dHCM9/8I3YwcKry+xX1NZp7FUTjiuh8uPJlvJVFUUJP1JlEq1+u7kv5T1pBNzj7+2wECfqB/ZjMVEo5gttTSaFEFrCpLlK+19Kkcl5VFOTua5eBXOVORMXbzgCtngHNbYWRdf7mjMkvsC3InWhDFIwYUWY21HLksPW8UxkHIwRXWmeLMmn7RaLPJPnFrdD8rT51cLV0+550VcYXgEC9XuO+gE1OQokjWirYn+MCho45TcwWDj0C6NPbM4b7ld21LNNbAwtMUZ2NuyHSaE+ZGy7Z5CMLHhqqGbaSeaHr3CkuuQ3DPjcuFDlGdK0DDu2FcUaxcQTgYJyMJ8SlXmeTkLochzQefRczrS2XpCn72iNxKN9Jx2Rm4RtRPOiScu0YacOWgmtmyIGk7hjE9knOfRmVFj5PsKyrfEc= 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: Thank you for the feedback! I'll check the suggested solution ASAP. -----Original Message----- From: Lorenzo Stoakes [mailto:lorenzo.stoakes@oracle.com]=20 Sent: Monday, January 27, 2025 5:47 PM To: =E4=D5=CC=CF=D7 =E4=C1=CE=C9=C9=CC Cc: Andrew Morton ; Liam R. Howlett ; Vlastimil Babka ; Jann Horn ; Matthew Wilcox (Oracle) ; linux-mm@kvack.org; linu= x-kernel@vger.kernel.org; lvc-project@linuxtesting.org; stable@vger.kernel.= com Subject: Re: [PATCH] mm/vma: Fix hugetlb accounting error in copy_vma() Thanks for the report. On Mon, Jan 27, 2025 at 05:32:01PM +0300, Daniil Dulov wrote: > In copy_vma() allocation of maple tree nodes may fail. Since page account= ing > takes place at the close() operation for hugetlb, it is called at the err= or > path against the new_vma to account pages of the vma that was not success= fully > copied and that shares the page_counter with the original vma. Then, when= the > process is being terminated, vm_ops->close() is called once again against= the > original vma, which results in a page_counter underflow. This seems like a bug in hugetlb. I really hate the solution here, it's hacky and assumes only these fields a= re meaningful for 'close twice' scenarios. We now use vma_close(), which assigns vma->vm_ops to vma_dummy_vm_ops, mean= ing no further close() invocations can occur. If hugetlb is _still_ choosing to internally invoke this, it seems like it should have some if (vma->vm_ops =3D=3D hugetlb_vm_ops) { ... } check first= ? That way it'll account for the closing twice issue. Can you easily repro in order to check a solution like that fixes your prob= lem? I don't see why it shouldn't > > page_counter underflow: -1024 nr_pages=3D1024 > WARNING: CPU: 1 PID: 1086 at mm/page_counter.c:55 page_counter_cancel+0xd= 6/0x130 mm/page_counter.c:55 > Modules linked in: > CPU: 1 PID: 1086 Comm: syz-executor200 Not tainted 6.1.108-syzkaller-0007= 8-g9ce77c16947b #0 > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/0= 1/2014 > Call Trace: > > page_counter_uncharge+0x2e/0x70 mm/page_counter.c:158 > hugetlb_cgroup_uncharge_counter+0xd2/0x420 mm/hugetlb_cgroup.c:430 > hugetlb_vm_op_close+0x435/0x700 mm/hugetlb.c:4886 > remove_vma+0x84/0x130 mm/mmap.c:140 > exit_mmap+0x32f/0x7a0 mm/mmap.c:3249 > __mmput+0x11e/0x430 kernel/fork.c:1199 > mmput+0x61/0x70 kernel/fork.c:1221 > exit_mm kernel/exit.c:565 [inline] > do_exit+0xa4a/0x2790 kernel/exit.c:858 > do_group_exit+0xd0/0x2a0 kernel/exit.c:1021 > __do_sys_exit_group kernel/exit.c:1032 [inline] > __se_sys_exit_group kernel/exit.c:1030 [inline] > __x64_sys_exit_group+0x3a/0x50 kernel/exit.c:1030 > do_syscall_x64 arch/x86/entry/common.c:51 [inline] > do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81 > entry_SYSCALL_64_after_hwframe+0x6e/0xd8 > > > Since there is no sense in vm accounting for a bad copy of vma, set vm_st= art > to be equal vm_end and vm_pgoff to be equal 0. Previously, a similar issu= e > has been fixed in __split_vma() in the same way [1]. > > [1]: https://lore.kernel.org/all/20220719201523.3561958-1-Liam.Howlett@or= acle.com/T/ Understood that we do this elsewhere, I think equally we should not do this there either! :) > > Found by Linux Verification Center (linuxtesting.org) with Syzkaller. > > Fixes: d4af56c5c7c6 ("mm: start tracking VMAs with maple tree") > Cc: stable@vger.kernel.com > Signed-off-by: Daniil Dulov > --- > mm/vma.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/mm/vma.c b/mm/vma.c > index bb2119e5a0d0..dbc68b7cd0ec 100644 > --- a/mm/vma.c > +++ b/mm/vma.c > @@ -1772,6 +1772,9 @@ struct vm_area_struct *copy_vma(struct vm_area_stru= ct **vmap, > return new_vma; > > out_vma_link: > + /* Avoid vm accounting in close() operation */ > + new_vma->vm_start =3D new_vma->vm_end; > + new_vma->vm_pgoff =3D 0; > vma_close(new_vma); > > if (new_vma->vm_file) > -- > 2.34.1 > >