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 A4F72C636CD for ; Tue, 7 Feb 2023 11:29:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1ADDA6B00B3; Tue, 7 Feb 2023 06:29:51 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 15F176B00B5; Tue, 7 Feb 2023 06:29:51 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 025476B00B6; Tue, 7 Feb 2023 06:29:50 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id E40CA6B00B3 for ; Tue, 7 Feb 2023 06:29:50 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id B4ECBC0B9C for ; Tue, 7 Feb 2023 11:29:50 +0000 (UTC) X-FDA: 80440276140.24.C5FF030 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf04.hostedemail.com (Postfix) with ESMTP id 0199F40008 for ; Tue, 7 Feb 2023 11:29:47 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=uRRMzvP1; spf=pass (imf04.hostedemail.com: domain of will@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=will@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=1675769388; 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=wbQaAsKp0t/sJ+M2+h5emOTrEtwDrR+tucfcERdLviI=; b=U/AHvY8LZqBX6bGOpAtOomLmDzJaNq7D4Z0XVE5t6Y2R12QBDbxeEfP6P+qJuxP7IL+NvY 6ym30Tg2NdVIrgKYndAIgFFOTi53V3iDOqGiryYyojAuFh/62ujiv3A7h+4RNO1m6c1vR0 4tLiOeIKkH8XY6vwUS8/xBLSFGmWrxY= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=uRRMzvP1; spf=pass (imf04.hostedemail.com: domain of will@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=will@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1675769388; a=rsa-sha256; cv=none; b=o4ew95r1cqqeFGUGlIw9kZtdLjW7VkMDBIp4LqYhxu5D859C0p52HEr3Wu9uonwGm80Hp/ H0Hm4TtVhxhu2W71B92DuNWXD8+6kGlOmlHiMsOFTgTBhDN0/icn0lw0hHBjrkvlPK/2PX ZnN++/2u9mVsDOxIRbzwqTQyV6VvCSQ= 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 0ADB261302; Tue, 7 Feb 2023 11:29:47 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CCB1AC433D2; Tue, 7 Feb 2023 11:29:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1675769386; bh=FMKebmT8UkF+9euLxcusDfgEaDtWb+MoAtShKQqplxA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=uRRMzvP1LqaHei6sgdqbIC2FNnrmrBBKopXsrRjigzqrmS63Khj5x5xdmLhy6U69A Uj6GfKKuk37+gGevENxVtEyBQiZIzDZS5ykNL2nwPWqd5/q62bOzSCdrnWWxfpTvVB u8t7bthW6USzVcOc5wK9wY8x6NEwkk1oYpTW8XLQuHSPML7gmLnF+DGobv9ha3g+t/ U24U1Q7WqV/UvVVNjgLm0MR53knQ0N/vtxblz1/LvAcNr78UGIXrUD+AZghJNA/WyN SNdvfm9wa8Oj3c3A2iD2KR77mXoBg5hvp9fljE3cHpZ3QZTNQvLMVd4RatsnKyhLmV qAys7FUELAzYQ== Date: Tue, 7 Feb 2023 11:29:41 +0000 From: Will Deacon To: Ard Biesheuvel Cc: Andrew Morton , Liu Shixin , Catalin Marinas , Uladzislau Rezki , Christoph Hellwig , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH RFC] arm64/vmalloc: use module region only for module_alloc() if CONFIG_RANDOMIZE_BASE is set Message-ID: <20230207112940.GA12147@willie-the-truck> References: <20221227092634.445212-1-liushixin2@huawei.com> <20230129134147.f19ca0641f1133f3e3bc185b@linux-foundation.org> <20230131150644.GA2605@willie-the-truck> <20230131150750.GB2605@willie-the-truck> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 0199F40008 X-Rspam-User: X-Stat-Signature: anrgxr7tyyiqyiof659ydqpbss3ddr49 X-HE-Tag: 1675769387-43751 X-HE-Meta: U2FsdGVkX1/jz1b+5TNhamcBGjRdaPPncy5p9wyHJJiY2K0ZUhPavPIVWCIc48f2UhMGW5bjge3sB7P125rbwLHN2fzieyfxAn5ZoniX2/COrnDAewJBT9c2K1avPXL9pM5HM+nBY8zKWMVQZc9LUPlJYJ/HhsQB5mWbTPR68lK9ikbjeeqO3wFnCRbwwbVBVu3iyhDfyfA1BHqy6OZHFLTu88+kFQMdJX9qHOSaSzlcAuruZWrUnitxA9GbbrpeS7JPRe/wj4J6Lvlx6Zu3SXMKG4zUTeaMjsAfbwLfU/R321IoDR8fsoQr4Gv4LxevOTXwl03DU4B5awmcR2cUQU+A/uwQHWAY944EX+TURZg9gTyMkQGoKTBkl8EoACAKUb5zu3VS7BZegaWrQK1xN7B2wjVZ66eJzNhTe1BcHuXKSAGHs3qt+ZM1p9teQPclahT1+mTu5HaYvuh3czUOHA3sDRC6iFYNLX32vd/m8cbmjd4VKxZvy5U2nGgs4hEAH8vW5WAnXb/WGabmjoxnOUqONlqcwX0E4dbWIBaaG5Ur9a6+glWLqvDrAuI7f5NC4ldyKmXQj2vmTD4IRZoKd4vS7JwY37Q9A87ksxR89ii2ItYm5iQayygwp7IyqGrXHHYT5/C5jaPKdiqvrXC2wRn1yRwv7WrDBLaV0BOwOoojVhUChp0cGKPn7T0ZOm9TxKOUToRH9jZwdrR/NEGpZQYDH+ASbWh2hkUP85U02yzrD8xceJKUBWcjQgnUET49bU+Udh6OzK097z7c4i/Hbvvk5+S4K7WEMvMLPvnbi9HWhobQWUpzytnCscNUA7VyBuKBhdmiXFx/f9TyPK4jG/rVA6cWz5X4suquAM/DxaZoURtCtLab/Hm9MwTbPgPgzCkST666NEE8p3KARFXE6iN4tRdOJgngLjXz0jYDEodxa/CpzkR2sXczby1nR3MnECY4fzRNonICBC81jte kkFPjEEo 2yngj4yqdBujBvtu7orlXFM1gRJmgmuLuJX8pifBEVJzSIZHU07Vn+RSQ0pYJ52YuVHEM+Vtuoltcc8TfM3AaY0FgXCtLe+rII7XLywtlxZX1jPtgWSTeAAKSNdOpfXYkNUBQ9odVeJT4sNWyhsqwLtVX4cE9/jEzqOtTo4GMdagalIu91InM7ZDcmk6zUQ5yFui6l8zwB2BHd8A7BasrXtWj9mVD/qsAi3jCq2AUA6wLwGV1RKUhnnm5iDCQ6ahYReFh63OfJApMbdvPN3MOB7q0o9xHnX02WKIm8LrnEqbH3uZdCdnh1HfKajBgUkmNnwOlxKbn/qTiLLoQF1s2X44RUn9It1r3/uWoPkvg67vpQ//VCc+L/W/ZA9yeL3aiVXGbyTQY8D66QYx0JfTfBpxTX5bzUYJCzkTdFsMiKlHeB45ynVWGKQ3doxRU80PVoqYz+pVMstNM48BOsQG7rmvQ2zM4oLg4D4sS4xbCbP3UVLuHVIU6tnQ7m/5CaVpnNr3FowyViFB95Bq6Dcki4YGSTGxe2oaAZzaldahMl/jZ4nceJTuFeOw710r1B2VAX6Nf 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 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? Cheers, Will