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 34BCBC433FE for ; Thu, 3 Feb 2022 19:51:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 631026B0071; Thu, 3 Feb 2022 14:51:27 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5DF6E6B0072; Thu, 3 Feb 2022 14:51:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4A7886B0074; Thu, 3 Feb 2022 14:51:27 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0200.hostedemail.com [216.40.44.200]) by kanga.kvack.org (Postfix) with ESMTP id 39B906B0071 for ; Thu, 3 Feb 2022 14:51:27 -0500 (EST) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id D77DB9990B for ; Thu, 3 Feb 2022 19:51:26 +0000 (UTC) X-FDA: 79102512972.05.37FB9D3 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) by imf14.hostedemail.com (Postfix) with ESMTP id 43725100002 for ; Thu, 3 Feb 2022 19:51:26 +0000 (UTC) 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-Transfer-Encoding:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description; bh=ft7cClkc6vBpNUXHJ0m3xjhOU7udO/ZG3yRM4g1vYT4=; b=EERLXhvvt+cUvphZ6I2kMdQwAc gjUUegQLCgS6JEACSczf7sBm1sx0ciVihEcBEg6gWVwkeuOFzmzWE1IIcpdMUUXszGrQuqLXGzihh LeMchQTAwicUQZfUfwK2iMpfkQkiMsn3DWsB1QiR74LXTelFtBWOg1RxqQpd9mrtJf6TSXko8SokG LDqGoCCTv/a3N84VLojdahz+Az++nC/dlh+pCXF7cvWQr73/CSO//N38EjPDx8WMmQQ8IX57cCbyh eJKVSWYNzH5Z7YDCP3hNbckQeEzhtIKKnUKhBOPdzT69CFjUx+fIyWUbbataKpfPiqQS+5XJN4joB +evkUpRQ==; Received: from mcgrof by bombadil.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1nFi8H-002dkz-Se; Thu, 03 Feb 2022 19:51:05 +0000 Date: Thu, 3 Feb 2022 11:51:05 -0800 From: Luis Chamberlain To: Christophe Leroy , Lucas De Marchi , Lucas De Marchi , Aaron Tomlin , Michal =?iso-8859-1?Q?Such=E1nek?= Cc: Aaron Tomlin , Jessica Yu , "linux-kernel@vger.kernel.org" , "linuxppc-dev@lists.ozlabs.org" , "kgdb-bugreport@lists.sourceforge.net" , "linux-mm@kvack.org" , "linux-arch@vger.kernel.org" , Jason Wessel , Daniel Thompson , Douglas Anderson Subject: Re: [PATCH v3 4/6] modules: Add CONFIG_ARCH_WANTS_MODULES_DATA_IN_VMALLOC Message-ID: References: <228849f5-f6a4-eb45-5e1e-a9b3eccb28b3@csgroup.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <228849f5-f6a4-eb45-5e1e-a9b3eccb28b3@csgroup.eu> X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 43725100002 X-Stat-Signature: t9gx1fhipiwctec9xitqp35e5joqewxe Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b=EERLXhvv; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=none (imf14.hostedemail.com: domain of mcgrof@infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=mcgrof@infradead.org X-Rspam-User: nil X-HE-Tag: 1643917886-621107 Content-Transfer-Encoding: quoted-printable 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 Thu, Feb 03, 2022 at 07:05:13AM +0000, Christophe Leroy wrote: >=20 >=20 > Le 03/02/2022 =E0 01:01, Luis Chamberlain a =E9crit=A0: > > On Sat, Jan 29, 2022 at 05:02:09PM +0000, Christophe Leroy wrote: > >> diff --git a/kernel/module.c b/kernel/module.c > >> index 11f51e17fb9f..f3758115ebaa 100644 > >> --- a/kernel/module.c > >> +++ b/kernel/module.c > >> @@ -81,7 +81,9 @@ > >> /* If this is set, the section belongs in the init part of the mod= ule */ > >> #define INIT_OFFSET_MASK (1UL << (BITS_PER_LONG-1)) > >> =20 > >> +#ifndef CONFIG_ARCH_WANTS_MODULES_DATA_IN_VMALLOC > >> #define data_layout core_layout > >> +#endif > >> =20 > >> /* > >> * Mutex protects: > >> @@ -111,6 +113,12 @@ static struct mod_tree_root { > >> #define module_addr_min mod_tree.addr_min > >> #define module_addr_max mod_tree.addr_max > >> =20 > >> +#ifdef CONFIG_ARCH_WANTS_MODULES_DATA_IN_VMALLOC > >> +static struct mod_tree_root mod_data_tree __cacheline_aligned =3D { > >> + .addr_min =3D -1UL, > >> +}; > >> +#endif > >> + > >> #ifdef CONFIG_MODULES_TREE_LOOKUP > >> =20 > >> /* > >> @@ -186,6 +194,11 @@ static void mod_tree_insert(struct module *mod) > >> __mod_tree_insert(&mod->core_layout.mtn, &mod_tree); > >> if (mod->init_layout.size) > >> __mod_tree_insert(&mod->init_layout.mtn, &mod_tree); > >> + > >> +#ifdef CONFIG_ARCH_WANTS_MODULES_DATA_IN_VMALLOC > >> + mod->data_layout.mtn.mod =3D mod; > >> + __mod_tree_insert(&mod->data_layout.mtn, &mod_data_tree); > >> +#endif > >=20 > >=20 > > kernel/ directory has quite a few files, module.c is the second to > > largest file, and it has tons of stuff. Aaron is doing work to > > split things out to make code easier to read and so that its easier > > to review changes. See: > >=20 > > https://lkml.kernel.org/r/20220130213214.1042497-1-atomlin@redhat.com > >=20 > > I think this is a good patch example which could benefit from that wo= rk. > > So I'd much prefer to see that work go in first than this, so to see = if > > we can make the below changes more compartamentalized. > >=20 > > Curious, how much testing has been put into this series? >=20 >=20 > I tested the change up to (including) patch 4 to verify it doesn't=20 > introduce regression when not using=20 > CONFIG_ARCH_WANTS_MODULES_DATA_IN_VMALLOC, > Then I tested with patch 5. I first tried with the 'hello world' test=20 > module. After that I loaded several important modules and checked I=20 > didn't get any regression, both with and without STRICT_MODULES_RWX and= =20 > I checked the consistency in /proc/vmallocinfo > /proc/modules /sys/class/modules/* I wonder if we have a test for STRICT_MODULES_RWX. > I also tested with a hacked module_alloc() to force branch trampolines. So to verify that reducing these trampolines actually helps on an architecture? I wonder if we can generalize this somehow to let archs verify such strategies can help. I was hoping for a bit more wider testing, like actually users, etc. It does not seem like so. So we can get to that by merging this soon into modules-next and having this bleed out issues with linux-next. We are in good time to do this now. The kmod tree has tons of tests: https://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git/ Can you use that to verify there are no regressions? Aaron, Michal, if you can do the same that'd be appreciated. Luis