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 C1349EB64DB for ; Mon, 19 Jun 2023 15:24:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5B7DD8D0002; Mon, 19 Jun 2023 11:24:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5691A8D0001; Mon, 19 Jun 2023 11:24:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 42F6B8D0002; Mon, 19 Jun 2023 11:24:21 -0400 (EDT) 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 3427C8D0001 for ; Mon, 19 Jun 2023 11:24:21 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id DE69A806D6 for ; Mon, 19 Jun 2023 15:24:20 +0000 (UTC) X-FDA: 80919868680.18.212391D Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf12.hostedemail.com (Postfix) with ESMTP id 28BA640020 for ; Mon, 19 Jun 2023 15:24:18 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=kRzjt2nD; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf12.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=1687188259; 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=Ey2Ld+q1smAj2ko2DpEpecEw8SxrV0ghQXT269XkgBo=; b=Wcdjybtkr3K+236OUUrtfwXXcBeBdFUc/oqtHj9H5jj2WYsYeofY2W6aL6azJyaE2WP52m iaPIHN0sMEdYs8v47K54TQqEyWBLg3Nn+X8oyXAs8K1Lm7TRClx38Bq85Jqx8fMh85lv3l 2OL/9xVyRjnIdb6UmrtBr2GWINbEzus= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=kRzjt2nD; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf12.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=1687188259; a=rsa-sha256; cv=none; b=8cHse823U3zHum+/Vihivvw1WFFyCJ/SX9REiAmZEnvbwJxIHSukS88jPWV9jWRqwiCb35 Z14mZXLwvExCbpV8N1CAhZ8a+yXWg6QM3nVV/wfvQqS47tu9bDbi/wPNGyi+KHLVE7+0SF xCDU8QTC2GPMFBoQz45Y3JMmvRAxgZQ= 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 0183660CFB; Mon, 19 Jun 2023 15:24:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8AA4DC433C8; Mon, 19 Jun 2023 15:24:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1687188257; bh=N4a6+AKTlpfQu+hNLgDTvYGemlpqgXPewbtXySTT2Wk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=kRzjt2nDIAl4X26ojRiB8w8CJVn45eTmiPbIYkIvDYRBR/QR7IVpfAXYd9FpfNQDQ OvemWMKmfnlcr5GwcS7TCX2oTJmzf2fUUsDJHf2Oq+4RHGmHWKbk0CASnuDz6Gk1Ld 1e26ENdIJqn1qjqL2vy8CRe3zudh+ZqjAZ7btzz+Jja4UEKxYRLaqjs+hNR8TPWi48 sYyUqJtdsNHbcbOzxo9zMe/AaYlu9nZhYjfHu5NSh21mKAk+otvslcioi5dkhxeNTF EnxnECqDbcsPkYZvvYUeyjGiH7IzMmaAIOnWvmMc+HuAd2WDWUtK2BFwEfTtd03m+J SY9K1sARFWi7g== Date: Mon, 19 Jun 2023 18:23:34 +0300 From: Mike Rapoport To: Thomas Gleixner 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 , Song Liu , Steven Rostedt , Thomas Bogendoerfer , 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: <20230619152334.GC52412@kernel.org> References: <20230616085038.4121892-1-rppt@kernel.org> <20230616085038.4121892-7-rppt@kernel.org> <87jzw0qu3s.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87jzw0qu3s.ffs@tglx> X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 28BA640020 X-Stat-Signature: wido4ee7bu4oxq5y9ek8wn3mtd1t9opg X-Rspam-User: X-HE-Tag: 1687188258-840770 X-HE-Meta: U2FsdGVkX1+qt4h8IR5oyxiM75tIaqizdtZWRVcs4dqAmkT5dJ7iITDsxT8iXTXGsOAJpEewYm3ii9LVGUdWFpYv3ZNtZCQzo9xFi9U/4hLhc2oWbkdsX2sHCTz6m4518qiC5gJhQAGhNuwWnKfI9dSth++hjRXZYhz40uicsUf4VOgT3pOYMM49vIC26cAJcor5C/gzQWUPfOFs3wd7O3LOlkJdOadXJKc2FGqNXaZbXJdwkcHdHYAB4kz45S3fXOjEC2xLTxo8CKQDnh/wD9pfuECsr+hc+39Q8IR4o27ehCWYnAmSuXMRK+8+hI73PWwkRIXVXPHqL+dahQa97yhYALRuIWlyBdWOelcTt2KObLuC3g9HWG2LS2pfeB10SyA9Z7Bf+0gZcSwcfAaRZR1bdlpmHPMAX6fJrm0Vnqu3R0Nfeya6pBiDdkOuFAI+0wY1O33gYcHmKkHCPguNfRhUv4qyTl/dHt+w24eI9jtHvdSwmPYzeVOCQ+Bmu0ifOdTBkKQUzD/lYx6e6KUmwpwOVwYxSndrVEIxDfFB5HMYz5/2U5ICzAKsvc8Fvdrd0ocbaleOYmMluRgPijCT8l0rsr7CL0eCbi1Pe91kk8XzDYQMHPCy/f6ig83r5lo28nvV2lyKf12BDi4OqI0OPFPcCwH3nbFKf+f3whjVdJVsbYOnvTxR3gBS+/ebJFAjp+HNccJl/QwvQUyEUKCeC2+yTl/OsL2I/bN+L8P7q/YxoCxAVT04pFQJX8DzqiKuiejEckPthB0JPEdDH9jOddWU/5TTUgAFkTJmSyDIB5z+VH0D7neAMONUS2MsLo2PaJJfmH9ahWPy33JXQYKs6ufaPBWmdZwVWH/FDHInJpOZrPLAvTHXqMnTjsIh69/Z5lgUFnNRrcxcfRQsZyf9vOnK+qr3hUGjuvud/oxDLWYF3SdkzD1DhZWYxtBM0ScGAqjD99sEhUFIHYKDBqt 8muPmwkw MSR23asEuD2vnF/Id2BuUIs8CgdAxUkmnD/6KK/gvlhjhA47McVP4nSMfpuqDy5iGn4m1qRAb7KX+UQ0OQy5R+W3QSy2Jp0ONqEojwxm/S7sioD8PtXamwsvG8LJj0Dl2KF+6NSXdQf5c9X4Ohd1vAz+ocmzQm+YLiRR52ledms1rC0MwNVYErpG51bXZCcmHehUGTuuo0SL9sXAV9HDkzDKuyMN8P0riSKI6AhiexNPaYTITvXxlfo+YyCgi216eCjhHnwO2Q7Qwia4n+PNw3tjoc3417uTSE8C5aUx6D2tFwjOu3xDgEf9CLAThmDMGjOm72ijDowlGtzmnuc4n+ukINUmCVxMGukbIy6HMaOVy2xKphNotH6pe54UgLFQwKRf8Gf9QniqW1OMKxyv1rWSYsksbnL9tniLU 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 Mon, Jun 19, 2023 at 12:32:55AM +0200, Thomas Gleixner wrote: > Mike! > > Sorry for being late on this ... > > On Fri, Jun 16 2023 at 11:50, Mike Rapoport wrote: > > The fact that my suggestions had a 'mod_' namespace prefix does not make > any of my points moot. The prefix does not matter. What matters is what we are trying to abstract. Your suggestion is based of the memory used by modules. I'm abstracting address spaces for different types of executable and related memory. They are similar, yes, but they are not the same. The TEXT, INIT_TEXT and *_DATA do not match to what we have from arch POV. They have modules with text, rw data, ro data and ro after init data and the memory for the generated code. The memory for modules and memory for other users have different restrictions for their placement, so using a single TEXT type for them is semantically wrong. BPF and kprobes do not necessarily must be at the same address range as modules and init text does not differ from normal text. > Song did an extremly good job in abstracting things out, but you decided > to ditch his ground work instead of building on it and keeping the good > parts. That's beyond sad. Actually not. The core idea to describe address range suitable for code allocations with a structure and have arch code initialize this structure at boot and be done with it is the same. But I don't think vmalloc parameters belong there, they should be completely encapsulated in the allocator. Having fallback range named explicitly is IMO clearer than an array of address spaces. I accept your point that the structures describing ranges for different types should be unified and I've got carried away with making the wrappers to convert that structure to parameters to the core allocation function. I've chosen to define ranges as fields in the containing structure rather than enum with types and an array because I strongly feel that the callers should not care about these parameters. These parameters are defined by architecture and the callers should not need to know how each and every arch defines restrictions suitable for modules, bpf or kprobes. That's also the reason to have different names for API calls, exactly to avoid having alloc(KPROBES,...), alloc(BPF, ...), alloc(MODULES, ...) an so on. All in all, if I filter all the ranting, this boils down to having a unified structure for all the address ranges and passing this structure from the wrappers to the core alloc as is rather that translating it to separate parameters, with which I agree. > Thanks, > > tglx -- Sincerely yours, Mike.