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 538E9C64ED8 for ; Mon, 27 Feb 2023 15:08:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BC9BB6B0072; Mon, 27 Feb 2023 10:08:36 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B7A326B0073; Mon, 27 Feb 2023 10:08:36 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A42186B0074; Mon, 27 Feb 2023 10:08:36 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 9654E6B0072 for ; Mon, 27 Feb 2023 10:08:36 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 3CFB01C4E92 for ; Mon, 27 Feb 2023 15:08:36 +0000 (UTC) X-FDA: 80513403432.17.F6AA047 Received: from wp530.webpack.hosteurope.de (wp530.webpack.hosteurope.de [80.237.130.52]) by imf05.hostedemail.com (Postfix) with ESMTP id 222B3100020 for ; Mon, 27 Feb 2023 15:08:32 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf05.hostedemail.com: domain of regressions@leemhuis.info designates 80.237.130.52 as permitted sender) smtp.mailfrom=regressions@leemhuis.info ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1677510513; h=from:from:sender:reply-to: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=rGLr4OElOYs0Yv4FA6tHha0+UqMUwlgSRJMXYDxk3Ig=; b=SfeY5SPY9NcSQ7WENFrzeY7HBfaP+2Rqf1gA2f2gQt5Q36KL8STGdLIZaVH/0sVx0aVJky wI0GPd0WGnrTIkkEAR7ZzYyk2gBwdSFNIbon7l2AwVtupRTIT9WY89sfL8ZyxCaSeGKM9+ gYffMaqSugYQ4o2uIYlS22LWujbZR6c= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf05.hostedemail.com: domain of regressions@leemhuis.info designates 80.237.130.52 as permitted sender) smtp.mailfrom=regressions@leemhuis.info ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1677510513; a=rsa-sha256; cv=none; b=0gTHXRTGCSP3KORg7rBgTkLiVIaHKKkvfUlD3Cva279PY8veimU3g+08rD6351/ACDTi1S h7M8Vvto9tr792hYeOUAEbFzrOH8AAv0QQyet1VGCFxakhDqfiXa8SP+MCqdGv70kIHGir VVAX1JjXjDYKbuo6t5SXgA7zcPVvIsw= Received: from [2a02:8108:8980:2478:8cde:aa2c:f324:937e]; authenticated by wp530.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1pWf6z-00066K-4O; Mon, 27 Feb 2023 16:08:21 +0100 Message-ID: <8c287b1d-476c-7b00-27f6-76c3a1a5fd46@leemhuis.info> Date: Mon, 27 Feb 2023 16:08:20 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Reply-To: Linux regressions mailing list Subject: Re: [PATCH RFC] arm64/vmalloc: use module region only for module_alloc() if CONFIG_RANDOMIZE_BASE is set Content-Language: en-US, de-DE To: Ard Biesheuvel , Liu Shixin Cc: 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 , Linux kernel regressions list 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> From: "Linux regression tracking (Thorsten Leemhuis)" In-Reply-To: <20230207112940.GA12147@willie-the-truck> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-bounce-key: webpack.hosteurope.de;regressions@leemhuis.info;1677510513;2947baff; X-HE-SMSGID: 1pWf6z-00066K-4O X-Rspamd-Queue-Id: 222B3100020 X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: 17jqkx816je3cbzwahxdyubkbysa1mr5 X-HE-Tag: 1677510512-983864 X-HE-Meta: U2FsdGVkX1/gRscLvcJBwB7SeB+AfEdmrU5fSaUAQihROMl+ujISkaR1cftLp3YnAePK8vzky2xymtc02ClQ+E6pTBKJoORbSGqxFiEV18p3H4H5Xm6jdQ2P/K9kjL7stFsFgOBMA2M01XTryTNDcWBA6Nr39IoE/63Qk4sCmjlP4c0tEZhbh/zeRUVdZyM9kfq1+0DassztJ1zg3B6CAwLd0YSssg4XiFIUf34PnqF5wTSuH5xxKd8Xhw6V8vs0yXqOtG8MmgyYFwkYCIN5J5X9ZWh6hGKV99quKnHvKdtE2m5ldv4kMZBKSG+0yrnq3WobtGj0iBB0SITipuWXRnXkfyXbcMuX+y0bpKfsZaDVA9k7bq9TMfQlLlLpqXEpHECqP274ExZNWWy3C7wt/PVfVrskzmHLerKmqpXT0+SIHuSnmoAUK+JTSKry75wCkx1KLFukICjc4JatPlikR+5FOxcR4hneySkEdOFPNR8VPnrWurx5Yd6RuwVaTOxXlmhSufoQJgm0dEdKMuMs10B1Z8nm3NM6Qcw5wOY4AkJWY5hrLASjGfVB30bayHDJwhgSIca/HjSNt91tuP2Mjr6rG8wzUp2LNDUPSTnQs27oEeUMWSssLt64d2TPSSyboJD6zVdGE0ISu7MED/Lvenh1RB3cN6C9U6b9decGrbZWj9e7s+7TWWmZpoifosQZ2xx9LZ1Sx2StumPWC4+SuR6+voos+9ZBkpe6Zf0M7RNzjjc7bEMT+rXvsk3Gx+24E99/OGxv5axBkwvm52mSbP9IPdO7gPOr0c3RHAOJd0miV6IzmYCkN5WmBw//F/Bd9zQveJ77GsabaK9QxJj2BcKcKEveVZuJDW0v6bwLwGeRV/z2SOgVL8JNaRIAfS3Q/XL29ZOd8SZPoDxvaHM7RrimpO15fC/UsjgrQFhOuwzU7zaMpZivMQvkmVKqDLZ4XyDnKb7qQRlw9Mrtgwu TA/Tcdkd drgNR7ThhYR3uFbaP8utcT+BdknQtzKphMh6lVO7OPqMliy1pkHZOs+okhuS/SUMVAQsp25AI2Vyhp3m/0YKXuko93ArME1YqxFOH+JCBYBHHwU7o4iTNCRxOaWloRbBZmIOVqcz8RcP5qqzCp04OWHyH3KUtNiTVdklSkzTb7azPz1Eh1mnwhc3wB6k4GIJnYcorZxjnuFju/DpJyAHpBm6SQmFpW3keH334NI3dTBwvjAe1jLEHgfttzM2epy4AQ6w7ZnW8WOzuDGdN9X/WPe+q2SQtXTgUzeSMW06BsbZycTsi2byngBzKhc4/pHHuiexjMxONkF7qjDuCBgg0MeDvxStwVxeTtZKrjG8/+1TGkko/VAE2RWZp4EfpZX9Lah/S3QXpqDhY3obyeGqkuD6ujAbjyc/G+VoK2oRXf8cq9qErg0h82nJ6fcByu97j0JT51GBLVJbrRX4nKoyisU6zegtsEeRQmmiQutZy3nJbkgKj6fTrfHJbh/y+74LTdjwcKPWeRLOPGOTcVQgl0F4RnrDSWZ4AvV9dSRDtGB+WbC2zOaMjRgRKhaH5J0ZC/Z9bI3QPM5U650TA3MRK+H+X6nHcEO2RlbWAxQOhFnAJjR7bY0puU9rMvZxMS6hwcAK8eBjxDY/+VhTYDGd/AHB5Y041c7QKVJx4 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: [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? 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. :-/ 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. Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) -- Everything you wanna know about Linux kernel regression tracking: https://linux-regtracking.leemhuis.info/about/#tldr If I did something stupid, please tell me, as explained on that page.