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 880DCC433F5 for ; Thu, 3 Feb 2022 05:39:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DC3278D0127; Thu, 3 Feb 2022 00:39:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D729C8D0124; Thu, 3 Feb 2022 00:39:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C3A538D0127; Thu, 3 Feb 2022 00:39:10 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0216.hostedemail.com [216.40.44.216]) by kanga.kvack.org (Postfix) with ESMTP id B341F8D0124 for ; Thu, 3 Feb 2022 00:39:10 -0500 (EST) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 3DB40182888AB for ; Thu, 3 Feb 2022 05:39:10 +0000 (UTC) X-FDA: 79100365260.09.4CDC919 Received: from gandalf.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by imf29.hostedemail.com (Postfix) with ESMTP id 2EF29120002 for ; Thu, 3 Feb 2022 05:39:09 +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 4Jq6sz71xZz4xmk; Thu, 3 Feb 2022 16:39:03 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ellerman.id.au; s=201909; t=1643866745; bh=5ypoksyewD1/1A0wIikcTAQpbuRBIVCFLpLku2DM1UQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=rMj6cjmEUS8Wn69koaMHGmWtpyj6ZO2nAuoyXA+oWiHfj2yhSyVXHPcjxkz5zmpZD WdOsbHhM5IN8Sxx+y5AE3lyjCEc+r5KfaNZza81P6gEszI/6eIqJvUMkHlMNrCqRMu MD3TSoNfM8O0TEuisU+c7WgVCaJ0RpIOaxUzrqSEcepCdb37tklQLk/xwJqw3N68Zc ulZFnLmU1XaXdjsexrU4b+S2Ms2cXvBTRrkylee8pfYCCllBETW7Tbn5AerQ5uFqCQ 6bgj65lt4gPCXOpWLgub/FKbqZZkFeTJz7NSunJt46xMtkybfJYQqzJUkDijOk7idk 3YDBVgFFETn3w== From: Michael Ellerman To: Luis Chamberlain , 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 , Paul Mackerras Subject: Re: [PATCH v2 5/5] powerpc: Select ARCH_WANTS_MODULES_DATA_IN_VMALLOC on book3s/32 and 8xx In-Reply-To: References: Date: Thu, 03 Feb 2022 16:39:02 +1100 Message-ID: <87h79gmrux.fsf@mpe.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 2EF29120002 X-Stat-Signature: jfccazjpf9ckgyjp7obydy9nwt9sc69j X-Rspam-User: nil Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=ellerman.id.au header.s=201909 header.b=rMj6cjmE; spf=pass (imf29.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: 1643866749-522913 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000014, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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. Just delete the Cc: list, it's meaningless. cheers