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 794C1C433F5 for ; Mon, 7 Feb 2022 01:19:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 82DA26B0072; Sun, 6 Feb 2022 20:19:18 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7DC196B0073; Sun, 6 Feb 2022 20:19:18 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6CD4D6B0074; Sun, 6 Feb 2022 20:19:18 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0244.hostedemail.com [216.40.44.244]) by kanga.kvack.org (Postfix) with ESMTP id 5D5F26B0072 for ; Sun, 6 Feb 2022 20:19:18 -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 20C6895271 for ; Mon, 7 Feb 2022 01:19:18 +0000 (UTC) X-FDA: 79114225596.05.D78F75D Received: from gandalf.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by imf28.hostedemail.com (Postfix) with ESMTP id 45738C0003 for ; Mon, 7 Feb 2022 01:19:17 +0000 (UTC) Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.ozlabs.org (Postfix) with ESMTPSA id 4JsSwK1MWyz4xcZ; Mon, 7 Feb 2022 12:19:13 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ellerman.id.au; s=201909; t=1644196753; bh=DVo9TFj10WHnIMP3upbM4NlbZB2TC5ggS49NOyVsTQo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=fVv9D5FuEvLaNhfgmXgjlmjX4g5lOMemZmfYENVGDoppdX2Jo87qwVgAkhSIW0EP0 89Lc++67+OIoMEwNxjvC50RgrjFDElHcPnLgKXuA5z1ZQiM++i/WE+BI+matwTnW2P 91Ie3ar6Hr7cTtJ21ddl+Mbkp3WJslga+XRknX57rBaj+Wt1/rbTxjyAQqrUiUMLyq 69wA8R2wfhA4KR8xTZG8HD3WRA+dYQp8A8q5D5TWDPWcWDmNGi2ZrHqlZZAor3hGwP gBZUprAx+25T1ngXxDkvVI01Gokid1upCSXRiWM4/lXk81+HjumKOlIxOkqLRh8iAA xnZSLLukqnG4w== From: Michael Ellerman To: Christophe Leroy Cc: 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" , Benjamin Herrenschmidt , Luis Chamberlain , Paul Mackerras Subject: Re: [PATCH v2 5/5] powerpc: Select ARCH_WANTS_MODULES_DATA_IN_VMALLOC on book3s/32 and 8xx In-Reply-To: <9cab4adb-bd4b-48d5-d63c-33a0f25c97e4@csgroup.eu> References: <87h79gmrux.fsf@mpe.ellerman.id.au> <9cab4adb-bd4b-48d5-d63c-33a0f25c97e4@csgroup.eu> Date: Mon, 07 Feb 2022 12:19:06 +1100 Message-ID: <877da7mq2d.fsf@mpe.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspam-User: nil X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 45738C0003 X-Stat-Signature: gicrafjezbb6htqjp9dqxixs6j5qs3xi Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=ellerman.id.au header.s=201909 header.b=fVv9D5Fu; spf=pass (imf28.hostedemail.com: domain of mpe@ellerman.id.au designates 150.107.74.76 as permitted sender) smtp.mailfrom=mpe@ellerman.id.au; dmarc=none X-HE-Tag: 1644196757-511897 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000025, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Christophe Leroy writes: > Le 03/02/2022 =C3=A0 06:39, Michael Ellerman a =C3=A9crit=C2=A0: >> Luis Chamberlain writes: >>> On Thu, Jan 27, 2022 at 11:28:12AM +0000, Christophe Leroy wrote: >>>> book3s/32 and 8xx have a separate area for allocating modules, >>>> defined by MODULES_VADDR / MODULES_END. >>>> >>>> On book3s/32, it is not possible to protect against execution >>>> on a page basis. A full 256M segment is either Exec or NoExec. >>>> The module area is in an Exec segment while vmalloc area is >>>> in a NoExec segment. >>>> >>>> In order to protect module data against execution, select >>>> ARCH_WANTS_MODULES_DATA_IN_VMALLOC. >>>> >>>> For the 8xx (and possibly other 32 bits platform in the future), >>>> there is no such constraint on Exec/NoExec protection, however >>>> there is a critical distance between kernel functions and callers >>>> that needs to remain below 32Mbytes in order to avoid costly >>>> trampolines. By allocating data outside of module area, we >>>> increase the chance for module text to remain within acceptable >>>> distance from kernel core text. >>>> >>>> So select ARCH_WANTS_MODULES_DATA_IN_VMALLOC for 8xx as well. >>>> >>>> Signed-off-by: Christophe Leroy >>>> Cc: Michael Ellerman >>>> Cc: Benjamin Herrenschmidt >>>> Cc: Paul Mackerras >>> >>> Cc list first and then the SOB. >>=20 >> Just delete the Cc: list, it's meaningless. >>=20 > > Was an easy way to copy you automatically with 'git send-email', but=20 > getting it through linuxppc-dev list is enough I guess ? It's useful for making the tooling Cc the right people, it's fine to use them for that. But there's no value in committing them to the git history, I actively strip them when applying. The fact that someone is Cc'ed on a patch tells you nothing, given the volume of mail maintainers receive. The link tag back to the original submission gives you the Cc list anyway. cheers