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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2A67CC05027 for ; Wed, 8 Feb 2023 16:07:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230445AbjBHQHF (ORCPT ); Wed, 8 Feb 2023 11:07:05 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52636 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229539AbjBHQHD (ORCPT ); Wed, 8 Feb 2023 11:07:03 -0500 Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:3::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8CB7B460BB; Wed, 8 Feb 2023 08:07:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=I+8/zUoQiK+vQy80qJDNf+yWTBzPHdJgShoFpq1p2MA=; b=SoJIEnEY/Cemy5seqHZ9JFmTMd a06i0nD26pTQDw/xDS5VYYD4VB5/YEA534bCu0v3imj+4+yu8Q98hf06hGLZ7rBCDv3N45I6TFWiN arYFsB7TZ6IlE+CpG++ifMttPiyqx2wZilomoPoGFWjliol1lVl0nf8l+qk9KmQu4wH85R2MStxLx IDR7+yQ2uBY0S81kINNTtEN9vnxJuyk+iYJCrsOAZA4uWQtEDsC+sSc4eFLTxLlM9Fc0hFmicAz1z /ezAS+1NDGAcCEhnKsigJh7cPV3oxqu6cvVga0wHNAslyuI9o4u8aOPDvaYs4DnGEC2ZEsxViLCBI vnDNxmsA==; Received: from mcgrof by bombadil.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1pPmyI-00GChE-QD; Wed, 08 Feb 2023 16:06:58 +0000 Date: Wed, 8 Feb 2023 08:06:58 -0800 From: Luis Chamberlain To: Thomas Gleixner Cc: Song Liu , linux-modules@vger.kernel.org, linux-kernel@vger.kernel.org, hch@lst.de, kernel-team@meta.com, Peter Zijlstra , Guenter Roeck , Christophe Leroy Subject: Re: [PATCH v10] module: replace module_layout with module_memory Message-ID: References: <20230207002802.2514802-1-song@kernel.org> <87357gv9ha.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87357gv9ha.ffs@tglx> Sender: Luis Chamberlain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 08, 2023 at 09:37:21AM +0100, Thomas Gleixner wrote: > On Mon, Feb 06 2023 at 16:28, Song Liu wrote: > > module_layout manages different types of memory (text, data, rodata, etc.) > > in one allocation, which is problematic for some reasons: > > > > 1. It is hard to enable CONFIG_STRICT_MODULE_RWX. > > 2. It is hard to use huge pages in modules (and not break strict rwx). > > 3. Many archs uses module_layout for arch-specific data, but it is not > > obvious how these data are used (are they RO, RX, or RW?) > > > > Improve the scenario by replacing 2 (or 3) module_layout per module with > > up to 7 module_memory per module: > > > > MOD_TEXT, > > MOD_DATA, > > MOD_RODATA, > > MOD_RO_AFTER_INIT, > > MOD_INIT_TEXT, > > MOD_INIT_DATA, > > MOD_INIT_RODATA, > > > > and allocating them separately. This adds slightly more entries to > > mod_tree (from up to 3 entries per module, to up to 7 entries per > > module). However, this at most adds a small constant overhead to > > __module_address(), which is expected to be fast. > > > > Various archs use module_layout for different data. These data are put > > into different module_memory based on their location in module_layout. > > IOW, data that used to go with text is allocated with MOD_MEM_TYPE_TEXT; > > data that used to go with data is allocated with MOD_MEM_TYPE_DATA, etc. > > > > module_memory simplifies quite some of the module code. For example, > > ARCH_WANTS_MODULES_DATA_IN_VMALLOC is a lot cleaner, as it just uses a > > different allocator for the data. kernel/module/strict_rwx.c is also > > much cleaner with module_memory. > > > > Signed-off-by: Song Liu > > Cc: Luis Chamberlain > > Cc: Thomas Gleixner > > Cc: Peter Zijlstra > > Cc: Guenter Roeck > > Cc: Christophe Leroy > > With the comment update folded in: > > Reviewed-by: Thomas Gleixner Thanks! I've merged this onto modules-next for winder testing. It is too late for v6.2 as we're on rc7 but this just means we'll get testing on linux-next for a good while for v6.3. If other folks do complete review please send your Reviewed-by annotation so I can ammend the commit log as we go. Luis