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 63E8AC433F5 for ; Tue, 8 Feb 2022 18:40:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E0A006B007D; Tue, 8 Feb 2022 13:40:32 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DB8816B007E; Tue, 8 Feb 2022 13:40:32 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C804B6B0080; Tue, 8 Feb 2022 13:40:32 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0238.hostedemail.com [216.40.44.238]) by kanga.kvack.org (Postfix) with ESMTP id BA0906B007D for ; Tue, 8 Feb 2022 13:40:32 -0500 (EST) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 78F238B320 for ; Tue, 8 Feb 2022 18:40:32 +0000 (UTC) X-FDA: 79120478304.12.33A86A0 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf26.hostedemail.com (Postfix) with ESMTP id D722B140009 for ; Tue, 8 Feb 2022 18:40:31 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 8DE1D1F387; Tue, 8 Feb 2022 18:40:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1644345630; h=from:from:reply-to: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; bh=jdw+TI4CIqxgVnyNgubuTkK3R4ZTBSmLHhOkGr2VwbM=; b=G2S7x10Mrrf2/Pa/VZkTCIlv7iL0i+FD2NbkgDsTy/GD6Vznw+so0ylyvTh9qrR6r7J93J 04Ue5FWUdyaq6uRCuCrIoSwIjWj/LQNqtOZKyN/cL79m8zoUd2cQQSWFaHW3YME2Nsl1R1 /O6De15sOs6wELkTrUGF3GPKQ8cJHsc= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1644345630; h=from:from:reply-to: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; bh=jdw+TI4CIqxgVnyNgubuTkK3R4ZTBSmLHhOkGr2VwbM=; b=JP21ChhnYhMUXNASGjs5KkXOyZc8Vg8hIeeV8nPZmnJizD+KuyALDb9msBVTnWZdZTjGOt xeQkzWNQ/EVRJkBA== Received: from kunlun.suse.cz (unknown [10.100.128.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 236BDA3B84; Tue, 8 Feb 2022 18:40:30 +0000 (UTC) Date: Tue, 8 Feb 2022 19:40:29 +0100 From: Michal =?iso-8859-1?Q?Such=E1nek?= To: Luis Chamberlain Cc: Christophe Leroy , Lucas De Marchi , Lucas De Marchi , 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: <20220208184029.GB3113@kunlun.suse.cz> 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: User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspam-User: Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=G2S7x10M; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=JP21Chhn; dmarc=pass (policy=none) header.from=suse.de; spf=pass (imf26.hostedemail.com: domain of msuchanek@suse.de designates 195.135.220.29 as permitted sender) smtp.mailfrom=msuchanek@suse.de X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: D722B140009 X-Stat-Signature: w4zp78zo6um7p6jjd5q417mw9jmgf6db X-HE-Tag: 1644345631-595551 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: Hello, On Thu, Feb 03, 2022 at 11:51:05AM -0800, Luis Chamberlain wrote: > On Thu, Feb 03, 2022 at 07:05:13AM +0000, Christophe Leroy wrote: > > 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 m= odule */ > > >> #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 *mo= d) > > >> __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.c= om > > >=20 > > > I think this is a good patch example which could benefit from that = work. > > > So I'd much prefer to see that work go in first than this, so to se= e 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, >=20 > > 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 a= nd=20 > > I checked the consistency in /proc/vmallocinfo > > /proc/modules /sys/class/modules/* >=20 > I wonder if we have a test for STRICT_MODULES_RWX. >=20 > > I also tested with a hacked module_alloc() to force branch trampoline= s. >=20 > 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. >=20 > 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. >=20 > The kmod tree has tons of tests: >=20 > https://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git/ >=20 > Can you use that to verify there are no regressions? openSUSE has the testsuite packaged so it's easy to run on arbitrary kernel but only on ppc64(le) because there is no ppc there anymore. So yes, it does not regress Book3S/64 as far as kmod testsuite is conderned and building s390x non-modular kernel also still worka but that's not saying much. Thanks Michal