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 ADB37C64ED6 for ; Mon, 27 Feb 2023 17:17:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3626B6B0072; Mon, 27 Feb 2023 12:17:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3125A6B0073; Mon, 27 Feb 2023 12:17:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1DB2E6B0075; Mon, 27 Feb 2023 12:17:38 -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 0E9F46B0072 for ; Mon, 27 Feb 2023 12:17:38 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id C5D07A08A6 for ; Mon, 27 Feb 2023 17:17:37 +0000 (UTC) X-FDA: 80513728554.24.6594C79 Received: from wp530.webpack.hosteurope.de (wp530.webpack.hosteurope.de [80.237.130.52]) by imf21.hostedemail.com (Postfix) with ESMTP id 42C4A1C000C for ; Mon, 27 Feb 2023 17:17:33 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf21.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=1677518254; 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=FzlfjZA1x67zl+MbijG3hffpMnJMMofihlfgXBwgUOY=; b=Rz9duqCJeRMIUHXVt6acoONIqX+ViLfDcl+/A28XnzzgcUDrm/q8ZVxK5dWTuf+oiv+ctV uCGJJrdOVTQzItlmbFE30320Vrlz1FTLF/Oa+TbMxo/54PXu1oZe4rijiU1l70cul78D6M sUm1KZggF9UP2tOxA1WNmu2d1ER3L0Q= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf21.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=1677518254; a=rsa-sha256; cv=none; b=E3/IuSbUMBER7mBHWBJKdXLBm0yo8826nkWk/s7HxFXUxmP9xM9Xw9Vaj4LaGEJFXLbSIX +doTySa6ycG+hs6G8aED5TXs+1+zGA73lNKkod56i4T28eDMDH4lXlwrXEasWoQOhQUx1P rSt5REQJ37TQI1o3hIKuubkipsu1z/g= 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 1pWh7n-0005Ah-59; Mon, 27 Feb 2023 18:17:19 +0100 Message-ID: <5a05e758-3c26-875a-af3a-6d7c8ddde653@leemhuis.info> Date: Mon, 27 Feb 2023 18:17:18 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 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 , 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 , 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> <8c287b1d-476c-7b00-27f6-76c3a1a5fd46@leemhuis.info> From: "Linux regression tracking (Thorsten Leemhuis)" Reply-To: Linux regressions mailing list In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-bounce-key: webpack.hosteurope.de;regressions@leemhuis.info;1677518254;f654d572; X-HE-SMSGID: 1pWh7n-0005Ah-59 X-Rspamd-Queue-Id: 42C4A1C000C X-Stat-Signature: 799otewyxoibe9xdcjhtdbxm85zajep1 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1677518253-281929 X-HE-Meta: U2FsdGVkX1+m1iUfsgZKqAwh+nSmMRAPnioPhiwmXvs0fdvB3V8YKIlI7yJYwFCTIHzAjRx/lSMA06WY6BfU8I4i+cij4XP6v4D/aqgn8MqGD7eBbuYdIzZKtZ+nkLqflZI+CIG88DE+NxVUoxrYfUqeVX/MVz5NJ6qu4g/XP6JwiWRAM+/a/hFqpROzhT0K+d6w9SDwp425cnAPQdacnaFC7rEfzQ/uvIIzGx5gSTh6q8D7TtpLZvqOuslfCpRvONv6Ay9qZvUCi53YbdXZ6ZSj45XqwwWDXrbJRo3jSwenFjWkKxGzPeIckcFVja1C2bDAYwCuf0z5XgXFEAu5wd3AbLQos8FrRf/Gf4P0sFz7TKbpI/HESQtxNzYaOzhbpQUSWNUKLfJZdBXsqruep9473JhSyvvD+Z5a83fw94s8T1sLNvs21HKmTO4J6t5WgmlgDoyOvNEFxq2Ymg/biVjIb4QDqWP1jMrrMfHhxcVn03YVaD0eUCiCYZxSQCxWNLqKbj3yvsULxUGw3PL+536wApSyWT7oUwoxqIezkaFoDMIGTAzfwDvkT7LVm51OTNC/26PM2CyN/3im0BlzAAInJUk2GA/3hTljCJ5d9+yhV6jb+i8meTDU6lU6omolXiZJEaimHiP5SpoXIFNpz+dU8caxx9WhWFgHumUgIivCHPmuFuNDlXUkWSph1OEjK8d1vOu6f6xF6rsd0vTWM7e0d0Li6GLDbH4Zvs4sp2Fa1LVmQCefmjBLNq5OwUwn3qbZ4hZcEF072D+a2UkLcWKrn8WLt7H3Dvjba01Buz655m5aYXbHF6lKW/m5dSPc0W+ikVl1L+PDRkPrAinB2VQNKZs6cNztTlT1KDfrjdXW1sTAoVQT11JhOQncIRiLSGXIjrQiucTEEEMrnNdFSGvbd8+6nY3siV2bJ7G9iC7Wc8Yx1u0177KXF3Hry+GqklFJFP/shxIReV1h34c 13WpLy3i RwRpDLsJSeOZy6lgOEbil/YiCW2/m/yvz7hC7VGHeV//VygC3iKlloVFBb11R29hMSXso8PtrDRaY5aNeR31CMhYATFzvVQ3pJStsfyI0YJFbLd0tZGrdzP5CmQR8dAAOnC6b9P6Y2tnForVjEOv1Z/pbp0gdbal/fLXOUwJVCgOeNu154cD6ie2zApw6i6RY9erWP7dFUQ+Up3VLCkW67ov4nKnVgnJ6FziETG1xZa6wvNEH4+pL7bb9X1yaJml+HWdLsVICk7Fbq6haJeuGSixVNGi58qN52ipNx6HdFMEtS57pZxNNW6fG4MeAMcDzCo7X1BhVnIZq6P/hQFsIOKjyTtEY+YwK67FnfYdPl2VCArVEM59FUfYpos0DIpKO2nLCBKKt8rRm0DpyVeIHtiyoAgZOIYpwIfcSP0fvEo8C4LD7bBIinqUDFn3ww+3AkNcQ/4wc3cHSF1JXFuUNTsCRcZHISFi8xkJADZ4Xj6cyaA+kAoJgIwMkUZsEthYwu3gOaSNNa96sxe9dWfwb+XYbXGHX60CGh5b812hceb6AHP4nrph9xmMx1VJqlDBfAN0ZJ78gHnzIm8qtSxXr2ZH8pePEAg02rDZCxzCmh736WYoy0cCPs/RhdeNS2MR67zZhfhjKhZckHVG5yeMU2RzF05WdDjDJKSBzPNZcRHqhcrFgiVscS+O3OQ== 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 27.02.23 17:14, Ard Biesheuvel wrote: > 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. Great, many thx. >> 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? https://docs.kernel.org/process/handling-regressions.html Side note: that also mentions use of the "Link" tag. If the patch had one, I'd noticed it and wouldn't bothered anyone here. > 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. I do that sometimes, but fwiw, from what I can see it wasn't a reporter that was unresponsive: https://lore.kernel.org/linux-arm-kernel/c1ff5cae-7f56-7fdb-c832-ffbcc177535b@leemhuis.info/ But I might be missing something, sorry if I do. And there was the festive season what complicated everything. Whatever, as long as this this is fixed. /me wonders if we should ask "chenxiang (M)" to test that patch, too; but /me is not even totally sure it's the same problem >> 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) Maybe I found the wrong words, sorry. 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.