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 3ADE6C64ED8 for ; Mon, 27 Feb 2023 16:14:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9813F6B0071; Mon, 27 Feb 2023 11:14:58 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 930006B0072; Mon, 27 Feb 2023 11:14:58 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7F7BB6B0073; Mon, 27 Feb 2023 11:14:58 -0500 (EST) 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 704406B0071 for ; Mon, 27 Feb 2023 11:14:58 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 36928160A46 for ; Mon, 27 Feb 2023 16:14:58 +0000 (UTC) X-FDA: 80513570676.26.F56377E Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf23.hostedemail.com (Postfix) with ESMTP id 45B2C140020 for ; Mon, 27 Feb 2023 16:14:55 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=tMs0k8ww; spf=pass (imf23.hostedemail.com: domain of ardb@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=ardb@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1677514495; 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=sT0U971rA2cApU+BBgPE1M0j8KPQN8UHtYXgMXrKJP8=; b=Q+eNCjyR6Inb9ia2tr2Bz/I24ziXzaimSrvN9JuEC3bLSfpX7wHbxRDHh0cRccMGk1f+MF ddsupwOfJG0i4z0VD6xwC2yJoYYpv+OwUbqIcnccu+jJFkNY5s67mjf53rlHyz30aPu2SR U7ROpc6t/PzMVOA8m5fxsVBTYPaIfnI= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=tMs0k8ww; spf=pass (imf23.hostedemail.com: domain of ardb@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=ardb@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1677514495; a=rsa-sha256; cv=none; b=NcKNwg5EjkoKxWC7OScPwiWi2il8EwuWX0jmgjEgKUbxqoesanLz/TNZd7FHDrpi+HcaQ6 cKP6EHQ4virmgOIKMEmR9NEIkO0f5G8SRKUCaKy7xR4p2LumZmmZeOpUI7ndgJ5LMnACS4 PAUMYE5ex9wAbVK9bmAucNJoFjWxdTQ= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 233AE60EBD for ; Mon, 27 Feb 2023 16:14:54 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7F696C433A4 for ; Mon, 27 Feb 2023 16:14:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1677514493; bh=8y1wP8ao9lT9NxXbVgWN8G4sVkHAjiaIwmzuXKtq6QQ=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=tMs0k8wwYcWOmMjV0FwbNDFJtNkNG8pCkwSaLLbzfqEtYVOxqbHzamcVYheJWyZfw /96XSfRHd4o9quYr9SRFrVJldluyX3oI1WjgM8q96fe8eYMOXIMb02IPkhqxk+hz8O pGSzIalACnf7Q2FEkQnSr8yAXNtf52hOq+hhUyuTNYYv4D3bVnmD4/7peqPYUuzzp1 LlWs4So9kr27r31XMWVH1aj7iZsRRz965JDs4+iW4NO7Q0viw04c4XDp7p8qA4a3Kb i8SikUz0QaViqMvbENBLuk3t1UGmax6ax0tktqImtr0cZrCvDUwbp8ER7KJbFYpS+U A/kUi5dHG2CGw== Received: by mail-lj1-f172.google.com with SMTP id f16so6995763ljq.10 for ; Mon, 27 Feb 2023 08:14:53 -0800 (PST) X-Gm-Message-State: AO0yUKXp8WQQ69qAQN4DsOdfTWsn49hvJOO+e2wc69d4Dwi9sjQ+ISeT O4hvjABRoC5R6CylCa6hxVfih9eqaseR/oNdX+c= X-Google-Smtp-Source: AK7set9sp5QAYc3EmdqzyPc/Ct+of5EXMBxFQXq2LkRCmzwqZe9FAlb0wqUuyF7PhsO0BtKFHzP5F40zj0J1ewU86ts= X-Received: by 2002:a05:651c:1682:b0:295:acb3:cb71 with SMTP id bd2-20020a05651c168200b00295acb3cb71mr2293634ljb.2.1677514491437; Mon, 27 Feb 2023 08:14:51 -0800 (PST) MIME-Version: 1.0 References: <20221227092634.445212-1-liushixin2@huawei.com> <20230129134147.f19ca0641f1133f3e3bc185b@linux-foundation.org> <20230131150644.GA2605@willie-the-truck> <20230131150750.GB2605@willie-the-truck> <20230207112940.GA12147@willie-the-truck> <8c287b1d-476c-7b00-27f6-76c3a1a5fd46@leemhuis.info> In-Reply-To: <8c287b1d-476c-7b00-27f6-76c3a1a5fd46@leemhuis.info> From: Ard Biesheuvel Date: Mon, 27 Feb 2023 17:14:40 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH RFC] arm64/vmalloc: use module region only for module_alloc() if CONFIG_RANDOMIZE_BASE is set To: Linux regressions mailing list Cc: Liu Shixin , Andrew Morton , Catalin Marinas , Uladzislau Rezki , Christoph Hellwig , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Will Deacon Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: 5y41as3rxarr3aocst8b9ynyishktmhe X-Rspamd-Queue-Id: 45B2C140020 X-HE-Tag: 1677514495-346733 X-HE-Meta: U2FsdGVkX18KnI3150B1pHfpXu1h3jrGbCJ1msxF3tP4LovPrXeaVEBJ8Kus4WHKAZdpI9WoAofjKs71szjpNVdlWC9vKDQzK0Vu/pQgBpNUK+bHk0sIYDeZTKO+2eWkNU56Pvyu3GEO0+bduQa95EiwAdqmhGw3HWdbSyLeeV/+sGcCFh4T8W5kyzUMrsV+mNFS97iLQUbb33Zksz/u8maou5Lgg4pLSthaVgbrnxnyqustQ9vsq6D4ziEMMcacMQDeIJ0aG1BBIRodGyv3nXv6c9SiHbMi5bMraWJlcgAaAJvRp3/MJBUEBKnxbj1uHSTcuRTQAFK32SpP5EWuFvTUn5MHWVSYfjmM7FBay7qw3+X9+mGoEQS22SDbYZ2iiuSq+/+bA2LUcM/LZf1o51j6QFFrjaqCFPbuxJmcNm7KC4F2YhsPms6lO+3+ADzT2YGWRWK2B3XoR7oaQtuaCqPaQegAktYrVyavtO6YXleExSYh0/EYHdMuivDF5f1eZneVldYFgh1tQ3pSwHogFz+xyP8qrvxRVAWrbiF2R6BppsDwIvK9dHWQKE6emQOc8A4ieM0xjn9cpInHjrwlrwrnVbYXy3cjcNfeuzFvnkYKCbj+WVCti+Q+QYAa3BJBh84FQ5DO7U5+qUejns9Ybb3DiMRqU8lFOxLoT4a3gAP/cXVNhh6tlLylnH5JBr2Wo37cRFvxExpUa4CH+lup2sb2waQCq7VlLWXnZwwaYJg2gN7s2OMXjcQLIGF9WAmdGAtgIhJ2H1YcnFf+/KDpQWIRCEpFiomyU79VNjafqa5A6NC2wH9GZxH8N8J9f+pA2SVL7UmycCQDNUZeKeXTZUCoBJHbJhC1yeJXuKhSzN2yYqqj/tLjbTonPXR2GV1iG/792/TZwxPl7uJN3n3q3wLGx4QY/a/CZnjTjqcwnJaOHAZ8Wu+ps+U/NrIyIm3de8KK2SCl6ZUjC5Hh1bZ xyhUc9+S po27rwabYcQov+7DhOfvUxOj/bPON81dTWDt6EEsJO093mSuhBYugyDhpXJmfAWfj9pQ/5q4AMswFEgscyrib7GL82m59RdOnKKMx15XbktC2QULG8E9lH6LNBvuw7OJ4DijQtVhssJthsM4NFdpFECHDyoJNpxBMWkMJHCEpN35kPse/ENfTQ24Zx6cFuEdGfR8pbfXLaDlZ3dqGopxR1p9AGmS+stdFdKzz1snmKEb8NpZocAAQo+6iZ4jV2L26QfjdXyHRZiUW3UTnLWt1t3Yh887JCPxbblU6rmD9xTpFlgImzNfR27pQU3nCQIzeg+aaXWG7tEXMDT+Htbnk7P2EzBOxRuVsADHM5g4TC03DPFCRAjCiSI6LlqmCJkM9FZOO3x5QDybOKR6sE/UW/shBQg06eR1Dlh7LSxV1VtxckS4CfvF3ilnH2zRNShFMJBFHAZktFB9ZVuKacW7lC73LN+bjmokfmq8fNHuqHmTGNrtEgWJOohLQ+sw3N7SX0foVlHXaCio+Zt152a5jt3QxvHwOTgOSxnvwTqI+bVKMhx+Mrvl4vjxCyQapg4UEC+CWCA5cWfI2AqG5sEMObwgjEbsrZVpNvTe7Opq8/MZZ61ah8hChy0cGY5rxXl9OHI2gvRmKmyYC0ZlBcCuoa0SiLB97KAuOa+edQ4ZI8lOoBB7mZoyWG7aLJg== 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: On Mon, 27 Feb 2023 at 16:08, Linux regression tracking (Thorsten Leemhuis) wrote: > > [CCing the regression list, as it should be in the loop for regressions: > https://docs.kernel.org/admin-guide/reporting-regressions.html] > > On 07.02.23 12:29, Will Deacon wrote: > > On Tue, Jan 31, 2023 at 05:03:32PM +0100, Ard Biesheuvel wrote: > >> On Tue, 31 Jan 2023 at 16:07, Will Deacon wrote: > >>> On Tue, Jan 31, 2023 at 03:06:44PM +0000, Will Deacon wrote: > >>>> On Sun, Jan 29, 2023 at 01:41:47PM -0800, Andrew Morton wrote: > >>>>> On Sun, 29 Jan 2023 10:44:31 +0800 Liu Shixin wrote: > >>>>>> On 2022/12/27 17:26, Liu Shixin wrote: > >>>>>>> After I add a 10GB pmem device, I got the following error message when > >>>>>>> insert module: > >>>>>>> > >>>>>>> insmod: vmalloc error: size 16384, vm_struct allocation failed, > >>>>>>> mode:0xcc0(GFP_KERNEL), nodemask=(null),cpuset=/,mems_allowed=0 > >>>>>>> > >>>>>>> If CONFIG_RANDOMIZE_BASE is set, the module region can be located in the > >>>>>>> vmalloc region entirely. Although module_alloc() can fall back to a 2GB > >>>>>>> window if ARM64_MODULE_PLTS is set, the module region is still easily > >>>>>>> exhausted because the module region is located at bottom of vmalloc region > >>>>>>> and the vmalloc region is allocated from bottom to top. > >>>>>>> > >>>>>>> Skip module region if not calling from module_alloc(). > >>>>> > >>>>> I'll assume this is for the arm tree. > >>>>> > >>>>> Acked-by: Andrew Morton > >>>> > >>>> This looks like the same issue previously reported at: > >>>> > >>>> https://lore.kernel.org/all/e6a804de-a5f7-c551-ffba-e09d04e438fc@hisilicon.com/ > >>>> > >>>> where Ard had a few suggestions but, afaict, they didn't help. > >>>> > >> > >> Thanks for the cc. > >> > >> So this is a bit clunky, and I wonder whether we wouldn't be better > >> off just splitting the vmalloc region into two separate regions: one > >> for the kernel and modules, and one for everything else. That way, we > >> lose one bit of entropy in the randomized placement, but the default > >> 48-bit VA space is vast anway, and even on 39-bit VA configs (such as > >> Android), I seriously doubt that we come anywhere close to exhausting > >> the vmalloc space today. > > > > That sounds like a good idea to me. > > > > Liu Shixin -- do you think you could have a go at implementing Ard's > > suggestion instead? > > Liu Shixin, did you ever look into realizing this idea? > > Or was some progress already made and I just missed it? > This patch https://lore.kernel.org/all/20230223204101.1500373-1-ardb@kernel.org/ should fix the issue. > I'm asking, as the idea discussed afaics is not only supposed to fix the > regression you tried to address, but also one that is now three months > old and stalled since Mid-December -- which is really unfortunate, as > that's not how regressions should be handled. :-/ Is it documented anywhere how regressions should be handled? The mailing list is flooded with hard to reproduce reports from users as well as automatic fuzzers and build bots, so I don't think it is entirely unreasonable to move unresponsive reporters to the back of the queue. > But well, it afaik was > caused by a patch from Ard, so it's obviously not your job to address > it. But it seems you were working on it. > We are all working together here, so please refrain from telling people what they should or should not be working on. (I am aware that you probably did not mean it that way, but things tend to get lost in translation very easily on the mailing list) Liu, could you please check whether the linked patch addresses your issue? Thanks, Ard.