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 14087EB64D7 for ; Fri, 16 Jun 2023 20:01:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7FB778E0002; Fri, 16 Jun 2023 16:01:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7A9708E0001; Fri, 16 Jun 2023 16:01:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 671F58E0002; Fri, 16 Jun 2023 16:01:27 -0400 (EDT) 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 55B058E0001 for ; Fri, 16 Jun 2023 16:01:27 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 140111A0D82 for ; Fri, 16 Jun 2023 20:01:27 +0000 (UTC) X-FDA: 80909680614.08.1181A16 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf06.hostedemail.com (Postfix) with ESMTP id 21566180029 for ; Fri, 16 Jun 2023 20:01:24 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="nN/7beEv"; spf=pass (imf06.hostedemail.com: domain of song@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=song@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=1686945685; 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:dkim-signature; bh=AsegpdbDq28yASVD1j6nv8C8feZL7Dz+Yc1Z2VBSTNM=; b=Q2FSZgj5c2ZdtmAycGvTVIG5KdwQbrzIdSjjWXVTl0nujf6fl4RwvSZerOdDcvpKvLEK6q TCI0nzZTOAo74yz+DAU+GNmMDZxM3UfvPIy/UoIMKQUfq+8pQzJ3YoTrKc6Wu9z+NyT3wW FkXvv2ZewipntGfoLmdMqpSniueF30w= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1686945685; a=rsa-sha256; cv=none; b=gEAxtsFJ0Vzl0YT3RVwbx3Kbe0BmOSgb13zhgLpnMK+uyHnVpRvPa+SOPaQSdW5DAg+ARb Ln3NqbyLKA9HW63WywnLCx6EEZtnwiEuCcy74EMdx67lRJIcZ8+OJaEZRomC5PZl/xLiry ocyZxxZfzl78iswc08d864ZZISZSB+A= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="nN/7beEv"; spf=pass (imf06.hostedemail.com: domain of song@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=song@kernel.org; dmarc=pass (policy=none) header.from=kernel.org Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 2471B62DE4 for ; Fri, 16 Jun 2023 20:01:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0EF11C433CC for ; Fri, 16 Jun 2023 20:01:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1686945683; bh=NNR06pawYLcrluh/DT0ZjxTIOvEpuKGIsr6P52TLsXk=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=nN/7beEvgALVGQkGDEWMU+WqmdryAGMT4sVLSi7IEGH0/JtCnmrU3kw5AqPLNEEt2 b6emvhoGN8eTdLfEDtNYs26stQbDj/4s/lj/H7doGiv19RIkQeGdhKyNqG1Qjo7N6h zQTAaJBX00GGP97q/gkRiV+5kyjXHPHnjAye9DI90OZEFDTXx9TQNSqKb0n9w0bzYW yxHLnA4zTvHmfaAjtSOfNR3JJPDo/DMYbNlXcfilvYl1IRgxPyH9NdLZUlPRpYsdUE wHxG+Bo6kDlJfk/kU/gHZcMukITMi2cUkAY5BsjH4quq3iBvEGr92lAorvbxrlQ5vA zG5Aco1x2X+Sg== Received: by mail-lf1-f42.google.com with SMTP id 2adb3069b0e04-4f766777605so1569608e87.1 for ; Fri, 16 Jun 2023 13:01:22 -0700 (PDT) X-Gm-Message-State: AC+VfDyLbvJIiz1zbMs/D4vm1R1SfayGKB9DJ+dCWzgblcEbftnumrgd mHmbRaBgTzA6iZ2dxgLPHgqzqZQncQ42i6MTuU8= X-Google-Smtp-Source: ACHHUZ5JqRMNnpRMFCyZiMjc+UWPs6A2cx1mTw/2r3SQw3woyTfRJjaUEkhnoXK7xbHKeHI/ilSSCGbka/vlr73Fo7g= X-Received: by 2002:a05:6512:60a:b0:4f8:5635:2ccf with SMTP id b10-20020a056512060a00b004f856352ccfmr2048673lfe.8.1686945680955; Fri, 16 Jun 2023 13:01:20 -0700 (PDT) MIME-Version: 1.0 References: <20230616085038.4121892-1-rppt@kernel.org> <20230616085038.4121892-7-rppt@kernel.org> In-Reply-To: <20230616085038.4121892-7-rppt@kernel.org> From: Song Liu Date: Fri, 16 Jun 2023 13:01:08 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 06/12] mm/execmem: introduce execmem_data_alloc() To: Mike Rapoport Cc: linux-kernel@vger.kernel.org, Andrew Morton , Catalin Marinas , Christophe Leroy , "David S. Miller" , Dinh Nguyen , Heiko Carstens , Helge Deller , Huacai Chen , Kent Overstreet , Luis Chamberlain , Mark Rutland , Michael Ellerman , Nadav Amit , "Naveen N. Rao" , Palmer Dabbelt , Puranjay Mohan , Rick Edgecombe , Russell King , Steven Rostedt , Thomas Bogendoerfer , Thomas Gleixner , Will Deacon , bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mips@vger.kernel.org, linux-mm@kvack.org, linux-modules@vger.kernel.org, linux-parisc@vger.kernel.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, linux-trace-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, loongarch@lists.linux.dev, netdev@vger.kernel.org, sparclinux@vger.kernel.org, x86@kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: 1k8g8rgsb4wxf6dknducirmqpyfr1jer X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 21566180029 X-Rspam-User: X-HE-Tag: 1686945684-819313 X-HE-Meta: U2FsdGVkX18Bc/XJFVeGXotjH9TPqqJOpYcg/GeUpMwps3/9KIQmf7Pa/u6Qpeq6bRgaTE5FCSwJDyb9ajqfdaw2WKrBFgFvc60Do47RRnUBPM57ICbGw+UWU9kgh3emjBHkUcP0o56XttKI8NhJTdqiXR6P1e/Ejq/G5uAPJ1h4Cz+7cSF+MWcZNyK+ezWQ3iLimU2BVIv8vQS9az2feuFyvJpS3zsagn+XZDIjTfhkjVszmFE0VOLyyxB9mXFvDz96kvL7LpRvYvBzasSSVngThpF/vBlib+nI/6Ib0iA8Da1b1acdnUzbww0mBBjaMbzSy5sF0Q0OHOPn+zkvjkQWKfh6WWHwVDqd6LcgslIn3SNrSXkzN2siDpu3omwK9suAOyIyWilbUugUCsnUQTi/4OfnymbVkSOmLWVY6/7QJYQaHPDHJTfBO1ZprgvQmF0Tst7Ep/4wiUsnsWyT1IVJ59DCrWOjtcBdkamVApR8VG4MCkvN0dkwMv4WosjBDYCSObnTUOFkb3WTmyWR6u6/PA6VY8SS4YZWH6rONRdzkoxNuv70vff6tTPscPdKcI+6vbbIgxR4k2i5vYdC3BmpWZNRUiGT/Yzg9t8A8dA/T84IizPOtP0VyaOhBDLQBU+zDiMVubLgJ4TgPmD20yYXV4Q28WSaxt0+fX1En7TafVeAccBoN/Eex9dAKsSdzco6RGBmmFumLM5HjTY5RH/Xi5k2k9DS9F1INxj/kvmFbxHhZGW2LAcGeB2zOEieu54c+AyUa7QHDLqcqpR7aYrkkK5DndZLwXgVgpoGV8x/QuA5mQGMeCztfVAbv6xkyP7CQBYinDtYkIOrw7q0JXCKjG7jE/8G4w42sMuGq5TWjLILEf9bvJPDVTmJUJ2d572t49A0/y4JcbQZ+YDjUyH220Xa3xD3Irvyi6yQBhoL9xcBDaGeF2OkxSD9I0Jt+xVgC4TeipTV8+kxEwv +uT1T/ot 3j87tUtojpryx1sjMuew6P0jLBMUT1PhVUGruo+yAPGxUWqxlk+5KNTzoBX91dCOmROPNi7ruRh1A7nTNpDbdKSOUIuz8+Q+0pTMZMvlgeLFp8ae7cdRWG6AssrspP/aBxcePOI1A66t1NYc31Et41BdjBz5m/UMG+WJMKLVnkjNbmyuBokiaD2aZFFoZbyoooKUgcl/Mf+W8rDW9I2hS+gikLUPjqYLy2ylNOQjRD6vDO0zPShWW9fFab7q1YhSPVAT7VLAubIhV7rRjjTUsvZRDzsXITgEag7o/r2CRLemfSFnCiJg4UbpcIwGpouvdwpPyWqRzd8uZRo2d4e8UW7PUtkhBsomSrrRVvO0uOJA/uS7c0LEaLaJ7BlmWwz7ratMtjkJQD33Qzh9OgvNZ80bLQCR8WD7moFiZ97TnTWI3ae8E3uigUbKOdFpfMryDOmBv7q3BY1KSJ1iPwKirCegpuJRbdhZG1odinPgdZDlJCzg= 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 Fri, Jun 16, 2023 at 1:51=E2=80=AFAM Mike Rapoport wro= te: > > From: "Mike Rapoport (IBM)" > > Data related to code allocations, such as module data section, need to > comply with architecture constraints for its placement and its > allocation right now was done using execmem_text_alloc(). > > Create a dedicated API for allocating data related to code allocations > and allow architectures to define address ranges for data allocations. > > Since currently this is only relevant for powerpc variants that use the > VMALLOC address space for module data allocations, automatically reuse > address ranges defined for text unless address range for data is > explicitly defined by an architecture. > > With separation of code and data allocations, data sections of the > modules are now mapped as PAGE_KERNEL rather than PAGE_KERNEL_EXEC which > was a default on many architectures. > > Signed-off-by: Mike Rapoport (IBM) [...] > static void free_mod_mem(struct module *mod) > diff --git a/mm/execmem.c b/mm/execmem.c > index a67acd75ffef..f7bf496ad4c3 100644 > --- a/mm/execmem.c > +++ b/mm/execmem.c > @@ -63,6 +63,20 @@ void *execmem_text_alloc(size_t size) > fallback_start, fallback_end, kasan); > } > > +void *execmem_data_alloc(size_t size) > +{ > + unsigned long start =3D execmem_params.modules.data.start; > + unsigned long end =3D execmem_params.modules.data.end; > + pgprot_t pgprot =3D execmem_params.modules.data.pgprot; > + unsigned int align =3D execmem_params.modules.data.alignment; > + unsigned long fallback_start =3D execmem_params.modules.data.fall= back_start; > + unsigned long fallback_end =3D execmem_params.modules.data.fallba= ck_end; > + bool kasan =3D execmem_params.modules.flags & EXECMEM_KASAN_SHADO= W; > + > + return execmem_alloc(size, start, end, align, pgprot, > + fallback_start, fallback_end, kasan); > +} > + > void execmem_free(void *ptr) > { > /* > @@ -101,6 +115,28 @@ static bool execmem_validate_params(struct execmem_p= arams *p) > return true; > } > > +static void execmem_init_missing(struct execmem_params *p) Shall we call this execmem_default_init_data? > +{ > + struct execmem_modules_range *m =3D &p->modules; > + > + if (!pgprot_val(execmem_params.modules.data.pgprot)) > + execmem_params.modules.data.pgprot =3D PAGE_KERNEL; Do we really need to check each of these? IOW, can we do: if (!pgprot_val(execmem_params.modules.data.pgprot)) { execmem_params.modules.data.pgprot =3D PAGE_KERNEL; execmem_params.modules.data.alignment =3D m->text.alignment; execmem_params.modules.data.start =3D m->text.start; execmem_params.modules.data.end =3D m->text.end; execmem_params.modules.data.fallback_start =3D m->text.fallback_star= t; execmem_params.modules.data.fallback_end =3D m->text.fallback_end; } Thanks, Song [...]