From: Michael Ellerman <mpe@ellerman.id.au>
To: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Jessica Yu <jeyu@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
"kgdb-bugreport@lists.sourceforge.net"
<kgdb-bugreport@lists.sourceforge.net>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Luis Chamberlain <mcgrof@kernel.org>,
Paul Mackerras <paulus@samba.org>
Subject: Re: [PATCH v2 5/5] powerpc: Select ARCH_WANTS_MODULES_DATA_IN_VMALLOC on book3s/32 and 8xx
Date: Mon, 07 Feb 2022 12:19:06 +1100 [thread overview]
Message-ID: <877da7mq2d.fsf@mpe.ellerman.id.au> (raw)
In-Reply-To: <9cab4adb-bd4b-48d5-d63c-33a0f25c97e4@csgroup.eu>
Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> Le 03/02/2022 à 06:39, Michael Ellerman a écrit :
>> Luis Chamberlain <mcgrof@kernel.org> 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 <christophe.leroy@csgroup.eu>
>>>> Cc: Michael Ellerman <mpe@ellerman.id.au>
>>>> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>>>> Cc: Paul Mackerras <paulus@samba.org>
>>>
>>> Cc list first and then the SOB.
>>
>> Just delete the Cc: list, it's meaningless.
>>
>
> Was an easy way to copy you automatically with 'git send-email', but
> 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
WARNING: multiple messages have this Message-ID (diff)
From: Michael Ellerman <mpe@ellerman.id.au>
To: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: "linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
"kgdb-bugreport@lists.sourceforge.net"
<kgdb-bugreport@lists.sourceforge.net>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
Luis Chamberlain <mcgrof@kernel.org>,
Paul Mackerras <paulus@samba.org>, Jessica Yu <jeyu@kernel.org>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH v2 5/5] powerpc: Select ARCH_WANTS_MODULES_DATA_IN_VMALLOC on book3s/32 and 8xx
Date: Mon, 07 Feb 2022 12:19:06 +1100 [thread overview]
Message-ID: <877da7mq2d.fsf@mpe.ellerman.id.au> (raw)
In-Reply-To: <9cab4adb-bd4b-48d5-d63c-33a0f25c97e4@csgroup.eu>
Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> Le 03/02/2022 à 06:39, Michael Ellerman a écrit :
>> Luis Chamberlain <mcgrof@kernel.org> 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 <christophe.leroy@csgroup.eu>
>>>> Cc: Michael Ellerman <mpe@ellerman.id.au>
>>>> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>>>> Cc: Paul Mackerras <paulus@samba.org>
>>>
>>> Cc list first and then the SOB.
>>
>> Just delete the Cc: list, it's meaningless.
>>
>
> Was an easy way to copy you automatically with 'git send-email', but
> 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
next prev parent reply other threads:[~2022-02-07 1:27 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-27 11:27 [PATCH v2 0/5] Allocate module text and data separately Christophe Leroy
2022-01-27 11:27 ` Christophe Leroy
2022-01-27 11:27 ` [PATCH v2 1/5] modules: Always have struct mod_tree_root Christophe Leroy
2022-01-27 11:27 ` Christophe Leroy
2022-01-27 11:28 ` [PATCH v2 2/5] modules: Prepare for handling several RB trees Christophe Leroy
2022-01-27 11:28 ` Christophe Leroy
2022-01-27 11:28 ` [PATCH v2 3/5] modules: Introduce data_layout Christophe Leroy
2022-01-27 11:28 ` Christophe Leroy
2022-01-27 11:28 ` [PATCH v2 4/5] modules: Add CONFIG_ARCH_WANTS_MODULES_DATA_IN_VMALLOC Christophe Leroy
2022-01-27 11:28 ` Christophe Leroy
2022-01-28 14:09 ` Daniel Thompson
2022-01-28 14:09 ` Daniel Thompson
2022-01-27 11:28 ` [PATCH v2 5/5] powerpc: Select ARCH_WANTS_MODULES_DATA_IN_VMALLOC on book3s/32 and 8xx Christophe Leroy
2022-01-27 11:28 ` Christophe Leroy
2022-02-02 23:36 ` Luis Chamberlain
2022-02-02 23:36 ` Luis Chamberlain
2022-02-03 5:39 ` Michael Ellerman
2022-02-03 5:39 ` Michael Ellerman
2022-02-03 7:07 ` Christophe Leroy
2022-02-03 7:07 ` Christophe Leroy
2022-02-07 1:19 ` Michael Ellerman [this message]
2022-02-07 1:19 ` Michael Ellerman
2022-02-09 15:42 ` [PATCH v2 0/5] Allocate module text and data separately Miroslav Benes
2022-02-09 15:42 ` Miroslav Benes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=877da7mq2d.fsf@mpe.ellerman.id.au \
--to=mpe@ellerman.id.au \
--cc=benh@kernel.crashing.org \
--cc=christophe.leroy@csgroup.eu \
--cc=jeyu@kernel.org \
--cc=kgdb-bugreport@lists.sourceforge.net \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mcgrof@kernel.org \
--cc=paulus@samba.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.