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 71A7CEB64D9 for ; Sat, 17 Jun 2023 06:52:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CAC496B0072; Sat, 17 Jun 2023 02:52:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C5C948E0001; Sat, 17 Jun 2023 02:52:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B4B666B0078; Sat, 17 Jun 2023 02:52:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id A67E16B0072 for ; Sat, 17 Jun 2023 02:52:01 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 6E8E740ED4 for ; Sat, 17 Jun 2023 06:52:01 +0000 (UTC) X-FDA: 80911320042.10.DFB20AE Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf04.hostedemail.com (Postfix) with ESMTP id 7DEA240010 for ; Sat, 17 Jun 2023 06:51:59 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=P0RFez1E; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf04.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1686984719; 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=+65ERh8jj3gncl+7DyUSv2jW+4MNE+AeiGydtC3HyGI=; b=LJcH4In4SvZUKMcGML/YArtAQkkLt3SL3BSXEioppe6rN1YRJP7YasUa0V46nIRxuu76q/ k81L46UhH7I4nYAyiK5SyLKS2sa+O/tUOxDTQ81GhCoi3qQYm+Jt2wXRewLb9jWkGLAJYv vl6asXHj7JQgbBIxlmsODRVcH4//8z4= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=P0RFez1E; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf04.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1686984719; a=rsa-sha256; cv=none; b=lYxcqVysSVwd7SdXK1oqkDIJnO98pK7FG2QTqWgeCyBiNqWhhnWcsFiWO9ZXKWAq6WiLN/ qSI1pcFnr9Hu+13tsSnID9foOuiAngBg5MgLUmTgcjjGyQvulmp3VuRCI45tp+xnqgD2Nq YbOK3Hm9/RVFsObKKMwt4NdXGbzWEOM= 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 69FCC60B07; Sat, 17 Jun 2023 06:51:58 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4F5A2C433C0; Sat, 17 Jun 2023 06:51:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1686984717; bh=/qKKDaoSMPytALuHQ04GytBWLf/bqmvRcK74ppFE2a8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=P0RFez1EfGYRPTyev/ddBuUzPfaI7NYAV3qwPAYDnlRPd3VlORPb9LLwAJNsB7HOD XaTNoL/vc3WgcVwGzmW11kDKJAUwiH+6/aq1FZDc7+GKKGRDNnH6fEazV3xviU4Xdu C+/q5uFaTCGSUOqz7wG3tCyqcwsxuFowQGM9EqAXvug3eByaI82gwGU/LAA7W+0x7N lIyzQgQ47UaYju+tMMa6eYibyB5m2xJlH6icNOvjTXhyI/Ih1KbRLoHwZvr/gyzXyu vOgqeIZZrqb6yw/imXyF8xZATseZuyfjlfKJVafWUrfVejHNNcMI379QODomewks5q shTjXZO35vEXQ== Date: Sat, 17 Jun 2023 09:51:11 +0300 From: Mike Rapoport To: Song Liu 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 Subject: Re: [PATCH v2 06/12] mm/execmem: introduce execmem_data_alloc() Message-ID: <20230617065111.GR52412@kernel.org> References: <20230616085038.4121892-1-rppt@kernel.org> <20230616085038.4121892-7-rppt@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: 7DEA240010 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: gx7d8wtj3a5kkb717kwemed1zb71wtex X-HE-Tag: 1686984719-804665 X-HE-Meta: U2FsdGVkX192TcDGqT3h5h8Wvlt9Nu3mDEfDEuKlXOI/HOQPXp6eaTGw9+1duhVzK4eOqWYCZDx4QZ6MVdy+Ik5TIEoa4c0wK3JspmTYI/s/8unrFrrOyWvgReLcrvmnxzl6Spv0Ptr8FJqerKRnEkdvy0uyRMq5Leqpe1Yln91+HjdBetSWi1NRRwUffqCLiu4v5Qn+c0BqpNMWfuLKPdnpMF47bOLVAFBUqG8U/7u2Tvx1ANm+Q6SBfCuwc6MdTUF6cYbettdcxCU1Anw9z7efA75wa7XDVin07Kf5S+xN+7Jr21Be63ieCIiPj41qMSpl6hyZfa6FvVpn50hzJl72sl47EFzg3oSUCAJKRUtFg8Ax1QZV3rW+GB5IjAfbBedxz05d/BCJhiMtSWdDajt+tU1RgG1eq2UPPy4sv4QaKn1lCj6LJL8jkoFgnzQtn5ht6B5HSdmwSxsU+3N784Ym7Y9HnJjA8pOl3Sjme0fXMpG4wRhfKO4/5nhFYRtHirfeh+XT1hvUv9mmHPWrpNV/8vpziRlhuurtcZaKPcwq9kk7sENMD9UAOYhj5bcuxxtyN+b5GP8kY4mMpP9ycL5tF7XZx/L1kS6mfszleIcm3z6TWOjoF1J/rLPrigTrQuYFftgOR3keQjtyWnpkoHs/lQT6smkzmDF6rmQ6odhvX7mnvxg8D1rsEn9OsOKsPoo4TFlqeJPfi+QpnwEP5WyLDQRmLUNqdaPwRiQFDQK+fAhempE2bSdZjb9v+EPyQm12Q3V+ERhdn7sL+9UOf+5HAM+ffaj8yv/IRD9bdjpBMQ++8FEwIXHM53yhoih7WFuD2hlgiN/Kum5yUR6KQ7vR8kpjHstyQnpa/H1bjU3j+trqHP73hV2EOcirWYqcdmVa0QsHjPRZao8LMyUTsuAbuuLrJApL0p0noV1Y8fIgRtEWc8+RR4oD8Wpy14F+MUXxouNC+DBM2Quqiv9 +A98pVL4 LYQQrtSS0tpkzacIM2WfHVUnzEKc2J3/lN/1APiBg4lUKBiUhd9xVUsVeJ8C/bQC6b8da2GFXdt2KKGY/3EewHB8/uFsyVku9ylka+sk1k5Npw05edXZ8+n9usdN9xBRldqt90hhNanWdb7z6xXXRvW4OHWiP/bJJX9U8zI2sr1RnTu9X7nUHDrVLAq71iiaFoKnQLMFDLClwOmo8WEV7rpUdOBemmBxhffl1NRZU6Nbj9tsAmd41arSKCoo2nsVfTNMZf4frtSWNrWUPUZmCzJJ8Ii9/+fRY8bIQuNvlNaE/4dyTFNXwVl6UGQHSk1sfZTVpVM//OwJczlUoNrKvGYHRayR7O57L7AW/642SIMamkRzZyaXMs3TqamSDMVCYbF/NOx9JvASwhQZ+bgiw0dYW6zC1bLDIF3hWPDsw074MJlMwuTDmDCdYtwNZCvfYvCg7k9lNgrJp0jOAMvNeyvjcyQ== 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 01:01:08PM -0700, Song Liu wrote: > On Fri, Jun 16, 2023 at 1:51 AM Mike Rapoport wrote: > > > > 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 = execmem_params.modules.data.start; > > + unsigned long end = execmem_params.modules.data.end; > > + pgprot_t pgprot = execmem_params.modules.data.pgprot; > > + unsigned int align = execmem_params.modules.data.alignment; > > + unsigned long fallback_start = execmem_params.modules.data.fallback_start; > > + unsigned long fallback_end = execmem_params.modules.data.fallback_end; > > + bool kasan = execmem_params.modules.flags & EXECMEM_KASAN_SHADOW; > > + > > + 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_params *p) > > return true; > > } > > > > +static void execmem_init_missing(struct execmem_params *p) > > Shall we call this execmem_default_init_data? This also fills in jit.text (next patch), so _data doesn't work here :) And it's not really a default, the defaults are set explicitly for arches that don't have execmem_arch_params. > > +{ > > + struct execmem_modules_range *m = &p->modules; > > + > > + if (!pgprot_val(execmem_params.modules.data.pgprot)) > > + execmem_params.modules.data.pgprot = 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 = PAGE_KERNEL; > execmem_params.modules.data.alignment = m->text.alignment; > execmem_params.modules.data.start = m->text.start; > execmem_params.modules.data.end = m->text.end; > execmem_params.modules.data.fallback_start = m->text.fallback_start; > execmem_params.modules.data.fallback_end = m->text.fallback_end; > } Yes, we can have a single check here. > Thanks, > Song > > [...] -- Sincerely yours, Mike.