Received: by 2002:a05:6358:a55:b0:ec:fcf4:3ecf with SMTP id 21csp5365148rwb; Tue, 17 Jan 2023 12:43:32 -0800 (PST) X-Google-Smtp-Source: AMrXdXtL6Tl1iyixFkdH7gm12E0mBjt9PSInyCye7yHCazPvudvk17Ce/+ih7puLpSjgD5HJjuuf X-Received: by 2002:a17:907:8196:b0:7c1:6fd3:1efa with SMTP id iy22-20020a170907819600b007c16fd31efamr15443755ejc.28.1673988212679; Tue, 17 Jan 2023 12:43:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1673988212; cv=none; d=google.com; s=arc-20160816; b=iCIoU4V/XE8vaVm0XEheK36N1NqzQI7EM3UXtmp2DR+78hVBCRW7Z2coWNS6sJ7oRk 59z1Qq/hQFyY57/x7WHsSkuA1NC5IXGO2isbdAkrEkv0K4buYKSNz8NO8wOiKH50SoKU beB245xTqWYO+2XB6LMPycjjFTbHP7nWEDIxjYkNoceSlvxcLy1dkggFw2C4CmyefEOw 9k16QYJfAUOU84KpQjGI47175hU9t31CnU9pDIVFQx5p96+FgH6A7rBJNdyPiVH4cF63 dKhKGvi27NWiBbOFHSKnEPSih6G+zfdyHz+m0Ty2uILADXLYXmy259zAR7q0eQ9R+1e6 gEWg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=stMbbhoLIDEa3CuSU1DEA+Gk+cSZ/UCUiavdpStxCG4=; b=gpkiC15xIQQ4qWSDYABIJofPBrOVFtgkQ6CP0hco3IX3U7Gh+3ZtR/L9CkqNycfHzb 5F+Xh4Yv/AYhyWi8C0r6BVGUSfsNATGAHOH9L7fVrc9i5nUiAwgo9K3s9WQRNPafvNXa VgIzAIEDou8EVDl6VWJEYcgrtXX08EXrGwUNFqgX7ykdIFAlJw4FLwheC6zcurxUDL28 Vwt/85jjqDu275HtxPWgyB6UaJgbi/bR2YJS9lKbpMNaGF7tFl3ksTPA1GRzbf5OKcjx Y6k094P78frEg40u1akzZItlRpd2qlyiuNAPbF+qK1GY3RkC22Lc37dvIPCwM1gVfBfd jWPg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=hJ3VpHNA; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id sg18-20020a170907a41200b008650ce2977bsi20820741ejc.641.2023.01.17.12.43.20; Tue, 17 Jan 2023 12:43:32 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=hJ3VpHNA; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232741AbjAQUAe (ORCPT + 47 others); Tue, 17 Jan 2023 15:00:34 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41152 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233904AbjAQT6Q (ORCPT ); Tue, 17 Jan 2023 14:58:16 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 315CD1E2B2; Tue, 17 Jan 2023 10:51:10 -0800 (PST) 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 2047461502; Tue, 17 Jan 2023 18:51:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 84ED6C43396; Tue, 17 Jan 2023 18:51:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1673981469; bh=gd6R4XluMPB27r6LRcEsEEMwkleNjaoutuHbO7D0GHA=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=hJ3VpHNAGVQLfHfCQw6iz4bsXMbG+3VG9IOv0Yeo0GklHd7TUgHoDf3T4QV6oYO/V LeQhJBQImYjldHG8NkhTtMmSUklOh3/25QuAHnWC1Bik0aeOwUMPcUtRtLOidQFgzA y5c+4UCcdSPlihYBD1Ky9vewXXUtO5DEEpNysVeung5A0DTyOEgjFEHLm07Q8JMRWL iSPx1Rx8ZoIIAkDzKoIKU6793lAfZ0FbLkGBb7LITBdyPDnGfdmQkmRDZ62Q4X05ga 0G40nZXW8snZ+cAqQjKukHasEp7VMpTdl+bmd3zYa6+WruW5+yoZ5agffsU7Gr17sZ gBYuwNiYQ/Z6A== Received: by mail-lj1-f169.google.com with SMTP id q2so34144867ljp.6; Tue, 17 Jan 2023 10:51:09 -0800 (PST) X-Gm-Message-State: AFqh2krJRJ8bMj8C5W8jAKgnIpBkw0ohHzKQpwwFU27VsxL+qP3kWjRW 1xEj9QjaomVnbSIkkAK+fTHXfI/s9Y/vStylUlU= X-Received: by 2002:a2e:b166:0:b0:284:b05a:9e82 with SMTP id a6-20020a2eb166000000b00284b05a9e82mr303044ljm.479.1673981467417; Tue, 17 Jan 2023 10:51:07 -0800 (PST) MIME-Version: 1.0 References: <20230106220959.3398792-1-song@kernel.org> In-Reply-To: From: Song Liu Date: Tue, 17 Jan 2023 10:50:55 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH/RFC] module: replace module_layout with module_memory To: Thomas Gleixner , Luis Chamberlain , Christophe Leroy Cc: songliubraving@fb.com, Peter Zijlstra , Christoph Hellwig , linux-modules@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Thomas and Luis, Could you please share your comments on this? Specifically, is this on the right direction? And, what's your preference with Christophe's suggestions? "I dislike how it looks with enums, things like mod->mod_mem[MOD_MEM_TYPE_INIT _TEXT] are odd and don't read nicely. Could we have something nicer like mod->mod_mem_init_text ? I know it will complicate your for_each_mod_mem_type() but it would look nicer." Thanks, Song On Tue, Jan 10, 2023 at 10:31 AM Song Liu wrote: > > + Christoph > > Hi folks, > > Could you please share your comments on this work? If there isn't > major issue with it, maybe we can ship it in 6.3? (so we don't pile > too many changes in one big set). > > Thanks, > Song > > On Fri, Jan 6, 2023 at 2:10 PM 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_MEM_TYPE_TEXT, > > MOD_MEM_TYPE_DATA, > > MOD_MEM_TYPE_RODATA, > > MOD_MEM_TYPE_RO_AFTER_INIT, > > MOD_MEM_TYPE_INIT_TEXT, > > MOD_MEM_TYPE_INIT_DATA, > > MOD_MEM_TYPE_INIT_RODATA, > > > > and allocating them separately. > > > > 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. > > > > Signed-off-by: Song Liu > > Cc: Luis Chamberlain > > Cc: Thomas Gleixner > > Cc: Peter Zijlstra > > [...]