* Re: [PATCH v2 0/7] soc: fsl: guts: cleanups and serial_number support
From: Arnd Bergmann @ 2022-02-10 16:20 UTC (permalink / raw)
To: Michael Walle
Cc: Ulf Hansson, Arnd Bergmann, Linux Kernel Mailing List, Li Yang,
Dan Carpenter, Sudeep Holla, linuxppc-dev, Linux ARM
In-Reply-To: <20220209163242.430265-1-michael@walle.cc>
On Wed, Feb 9, 2022 at 5:32 PM Michael Walle <michael@walle.cc> wrote:
>
> This series converts the guts driver from a platform driver to just an
> core_initcall. The driver itself cannot (or rather should never) be
> unloaded because others depends on detecting the current SoC revision
> to apply chip errata. Other SoC drivers do it the same way. Overall I
> got rid of all the global static variables.
>
> The last patch finally adds unique id support to the guts driver. But
> because the binding [1] for the security fuse processor is still pending,
> it is marked as RFC.
>
> [1] https://lore.kernel.org/linux-devicetree/20220127163728.3650648-2-michael@walle.cc/
>
> changes since v1:
> - call kfree() in error case, thanks Dan
> - add missing of_node_put(np), thanks Dan
Looks all good to me,
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* Re: [RFC PATCH 2/3] powerpc/ftrace: Override ftrace_location_lookup() for MPROFILE_KERNEL
From: Naveen N. Rao @ 2022-02-10 16:40 UTC (permalink / raw)
To: Steven Rostedt
Cc: Daniel Borkmann, Yauheni Kaliuta, Jordan Niethe, linuxppc-dev,
bpf, Jiri Olsa, Alexei Starovoitov, Hari Bathini
In-Reply-To: <20220210095944.1fe98b74@gandalf.local.home>
Steven Rostedt wrote:
> On Thu, 10 Feb 2022 13:58:29 +0000
> "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com> wrote:
>
>> diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
>> index f9feb197b2daaf..68f20cf34b0c47 100644
>> --- a/kernel/trace/ftrace.c
>> +++ b/kernel/trace/ftrace.c
>> @@ -1510,6 +1510,7 @@ ftrace_ops_test(struct ftrace_ops *ops, unsigned long ip, void *regs)
>> }
>>
>>
>> +#ifndef ftrace_cmp_recs
>> static int ftrace_cmp_recs(const void *a, const void *b)
>> {
>> const struct dyn_ftrace *key = a;
>> @@ -1521,6 +1522,7 @@ static int ftrace_cmp_recs(const void *a, const void *b)
>> return 1;
>> return 0;
>> }
>> +#endif
>>
>
> I don't really care for this part, as it seems somewhat ugly. But this
> patch does appear to solve your issue, and I can't think of a prettier way
> to do this.
Yes, this approach looks like it will solve a few different issues for
us. We would also like to nop-out the instruction before the branch to
_mcount(), so this helps ensure that kprobes won't also overwrite that
instruction.
>
> So, I will reluctantly ack it.
Since we don't want to change struct dyn_ftrace, we will need to contain
changes within the architecture code, so I don't see a way to do this in
a generic manner.
The other option is to mark ftrace_cmp_recs() as a __weak function, but
I have a vague recollection of you suggesting #ifdef rather than a
__weak function in the past. I might be mis-remembering, so if you think
making this a __weak function is better, I can do that.
>
> If anything, please add a comment above saying that architectures may need
> to override this function, and when doing so, they will define their own
> ftrace_cmp_recs.
Sure.
- Naveen
^ permalink raw reply
* Re: [RFC PATCH 2/3] powerpc/ftrace: Override ftrace_location_lookup() for MPROFILE_KERNEL
From: Steven Rostedt @ 2022-02-10 17:01 UTC (permalink / raw)
To: Naveen N. Rao
Cc: Daniel Borkmann, Yauheni Kaliuta, Jordan Niethe, linuxppc-dev,
bpf, Jiri Olsa, Alexei Starovoitov, Hari Bathini
In-Reply-To: <1644508338.5ucomwqtts.naveen@linux.ibm.com>
On Thu, 10 Feb 2022 16:40:28 +0000
"Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com> wrote:
> The other option is to mark ftrace_cmp_recs() as a __weak function, but
> I have a vague recollection of you suggesting #ifdef rather than a
> __weak function in the past. I might be mis-remembering, so if you think
> making this a __weak function is better, I can do that.
No. If I wanted that I would have suggested it. I think this is the
prettiest of the ugly solutions out there ;-)
As I said, I can't think of a better solution, and we can go with this
until something else comes along.
-- Steve
^ permalink raw reply
* Re: [PATCH] powerpc/lib/sstep: fix 'ptesync' build error
From: Christophe Leroy @ 2022-02-10 17:40 UTC (permalink / raw)
To: Anders Roxell, mpe@ellerman.id.au
Cc: stable@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org, Arnd Bergmann
In-Reply-To: <20220210124404.34773-1-anders.roxell@linaro.org>
Le 10/02/2022 à 13:44, Anders Roxell a écrit :
> Building tinyconfig with gcc (Debian 11.2.0-16) and assembler (Debian
> 2.37.90.20220207) the following build error shows up:
>
> {standard input}: Assembler messages:
> {standard input}:2088: Error: unrecognized opcode: `ptesync'
> make[3]: *** [/builds/linux/scripts/Makefile.build:287: arch/powerpc/lib/sstep.o] Error 1
>
> Re-add the ifdef __powerpc64__ around the 'ptesync' in function
> 'emulate_update_regs()' to like it is in 'analyse_instr()'. Since it looks like
> it got dropped inadvertently by commit 3cdfcbfd32b9 ("powerpc: Change
> analyse_instr so it doesn't modify *regs").
>
> Cc: stable@vger.kernel.org # v4.14+
> Fixes: 3cdfcbfd32b9 ("powerpc: Change analyse_instr so it doesn't modify *regs")
> Suggested-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
> ---
> arch/powerpc/lib/sstep.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/powerpc/lib/sstep.c b/arch/powerpc/lib/sstep.c
> index a94b0cd0bdc5..d23772f91a36 100644
> --- a/arch/powerpc/lib/sstep.c
> +++ b/arch/powerpc/lib/sstep.c
> @@ -3264,12 +3264,14 @@ void emulate_update_regs(struct pt_regs *regs, struct instruction_op *op)
> case BARRIER_EIEIO:
> eieio();
> break;
> +#ifdef __powerpc64__
Should be CONFIG_PPC64 instead of __powerpc64__
> case BARRIER_LWSYNC:
> asm volatile("lwsync" : : : "memory");
> break;
> case BARRIER_PTESYNC:
> asm volatile("ptesync" : : : "memory");
> break;
> +#endif
> }
> break;
>
^ permalink raw reply
* [PATCH 0/3] drivers/crypto: Constify static attribute_group
From: Rikard Falkeborn @ 2022-02-10 20:28 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Michael Ellerman,
Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-crypto, Rikard Falkeborn, linux-kernel
This series constifies a couple of static attribute_group structs that
are not modified. This allows the compiler to put them in read-only
memory. The patches are independent and can be applied in any order (and
go through different trees if needed).
Rikard Falkeborn (3):
crypto: omap-aes - Constify static attribute_group
crypto: omap-sham - Constify static attribute_group
crypto/nx: Constify static attribute_group structs
drivers/crypto/nx/nx-common-pseries.c | 4 ++--
drivers/crypto/omap-aes.c | 2 +-
drivers/crypto/omap-sham.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
--
2.35.1
^ permalink raw reply
* [PATCH 1/3] crypto: omap-aes - Constify static attribute_group
From: Rikard Falkeborn @ 2022-02-10 20:28 UTC (permalink / raw)
To: Herbert Xu, David S. Miller
Cc: linux-kernel, Rikard Falkeborn, Paul Mackerras, linux-crypto,
linuxppc-dev
In-Reply-To: <20220210202805.7750-1-rikard.falkeborn@gmail.com>
The only usage of omap_aes_attr_group is to pass its address to
sysfs_{create,remove}_group(), which takes pointers to const struct
attribute_group. Make it const to allow the compiler to put it in
read-only memory.
Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
---
drivers/crypto/omap-aes.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index a196bb8b1701..581211a92628 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -1093,7 +1093,7 @@ static struct attribute *omap_aes_attrs[] = {
NULL,
};
-static struct attribute_group omap_aes_attr_group = {
+static const struct attribute_group omap_aes_attr_group = {
.attrs = omap_aes_attrs,
};
--
2.35.1
^ permalink raw reply related
* [PATCH 2/3] crypto: omap-sham - Constify static attribute_group
From: Rikard Falkeborn @ 2022-02-10 20:28 UTC (permalink / raw)
To: Herbert Xu, David S. Miller
Cc: linux-kernel, Rikard Falkeborn, Paul Mackerras, linux-crypto,
linuxppc-dev
In-Reply-To: <20220210202805.7750-1-rikard.falkeborn@gmail.com>
The only usage of omap_sham_attr_group is to pass its address to
sysfs_{create,remove}_group(), which takes pointers to const struct
attribute_group. Make it const to allow the compiler to put it in
read-only memory.
Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
---
drivers/crypto/omap-sham.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index f6bf53c00b61..4b37dc69a50c 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -2045,7 +2045,7 @@ static struct attribute *omap_sham_attrs[] = {
NULL,
};
-static struct attribute_group omap_sham_attr_group = {
+static const struct attribute_group omap_sham_attr_group = {
.attrs = omap_sham_attrs,
};
--
2.35.1
^ permalink raw reply related
* [PATCH 3/3] crypto/nx: Constify static attribute_group structs
From: Rikard Falkeborn @ 2022-02-10 20:28 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Michael Ellerman,
Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-crypto, Rikard Falkeborn, linux-kernel
In-Reply-To: <20220210202805.7750-1-rikard.falkeborn@gmail.com>
The only usage of these is to pass their address to
sysfs_{create,remove}_group(), which takes pointers to const struct
attribute_group. Make them const to allow the compiler to put them in
read-only memory.
Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
---
drivers/crypto/nx/nx-common-pseries.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/nx/nx-common-pseries.c b/drivers/crypto/nx/nx-common-pseries.c
index 4e304f6081e4..7584a34ba88c 100644
--- a/drivers/crypto/nx/nx-common-pseries.c
+++ b/drivers/crypto/nx/nx-common-pseries.c
@@ -962,7 +962,7 @@ static struct attribute *nx842_sysfs_entries[] = {
NULL,
};
-static struct attribute_group nx842_attribute_group = {
+static const struct attribute_group nx842_attribute_group = {
.name = NULL, /* put in device directory */
.attrs = nx842_sysfs_entries,
};
@@ -992,7 +992,7 @@ static struct attribute *nxcop_caps_sysfs_entries[] = {
NULL,
};
-static struct attribute_group nxcop_caps_attr_group = {
+static const struct attribute_group nxcop_caps_attr_group = {
.name = "nx_gzip_caps",
.attrs = nxcop_caps_sysfs_entries,
};
--
2.35.1
^ permalink raw reply related
* Re: [PATCH v5 0/6] KEXEC_SIG with appended signature
From: Luis Chamberlain @ 2022-02-10 23:30 UTC (permalink / raw)
To: Michael Ellerman
Cc: Nayna, Mimi Zohar, Sven Schnelle, David Howells, keyrings,
Paul Mackerras, Alexander Gordeev, Rob Herring, Herbert Xu,
Baoquan He, Christian Borntraeger, James Morris,
Lakshmi Ramasubramanian, Aaron Tomlin, Michal Suchanek,
Serge E. Hallyn, Vasily Gorbik, linux-s390, Heiko Carstens,
Dmitry Kasatkin, Hari Bathini, Daniel Axtens,
Christian Borntraeger, Philipp Rudo, Frank van der Linden, kexec,
linux-kernel, linux-security-module, linux-crypto, Jessica Yu,
linux-integrity, linuxppc-dev, David S. Miller,
Thiago Jung Bauermann, buendgen
In-Reply-To: <87pmnwlkaa.fsf@mpe.ellerman.id.au>
On Wed, Feb 09, 2022 at 03:46:05PM +1100, Michael Ellerman wrote:
> Luis Chamberlain <mcgrof@kernel.org> writes:
> > On Tue, Jan 11, 2022 at 12:37:42PM +0100, Michal Suchanek wrote:
> >> Hello,
> >>
> >> This is a refresh of the KEXEC_SIG series.
> >>
> >> This adds KEXEC_SIG support on powerpc and deduplicates the code dealing
> >> with appended signatures in the kernel.
> >>
> >> powerpc supports IMA_KEXEC but that's an exception rather than the norm.
> >> On the other hand, KEXEC_SIG is portable across platforms.
> >>
> >> For distributions to have uniform security features across platforms one
> >> option should be used on all platforms.
> >>
> >> Thanks
> >>
> >> Michal
> >>
> >> Previous revision: https://lore.kernel.org/linuxppc-dev/cover.1637862358.git.msuchanek@suse.de/
> >> Patched kernel tree: https://github.com/hramrach/kernel/tree/kexec_sig
> >>
> >> Michal Suchanek (6):
> >> s390/kexec_file: Don't opencode appended signature check.
> >> powerpc/kexec_file: Add KEXEC_SIG support.
> >> kexec_file: Don't opencode appended signature verification.
> >> module: strip the signature marker in the verification function.
> >> module: Use key_being_used_for for log messages in
> >> verify_appended_signature
> >> module: Move duplicate mod_check_sig users code to mod_parse_sig
> >
> > What tree should this go through? I'd prefer if over through modules
> > tree as it can give a chance for Aaron Tomlin to work with this for his
> > code refactoring of kernel/module*.c to kernel/module/
>
> Yeah that's fine by me, the arch changes are pretty minimal and unlikely
> to conflict much.
Ok sounds good thanks.
Luis
^ permalink raw reply
* [PATCH 38/49] arch/powerpc: replace cpumask_weight with cpumask_weight_{eq, ...} where appropriate
From: Yury Norov @ 2022-02-10 22:49 UTC (permalink / raw)
To: Yury Norov, Andy Shevchenko, Rasmus Villemoes, Andrew Morton,
Michał Mirosław, Greg Kroah-Hartman, Peter Zijlstra,
David Laight, Joe Perches, Dennis Zhou, Emil Renner Berthing,
Nicholas Piggin, Matti Vaittinen, Alexey Klimov, linux-kernel,
Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
Srikar Dronamraju, Gautham R. Shenoy, Valentin Schneider,
Parth Shah, Cédric Le Goater, Hari Bathini, Rob Herring,
Laurent Dufour, Petr Mladek, John Ogness, Sudeep Holla,
Christophe Leroy, Naveen N. Rao, Xiongwei Song, Arnd Bergmann,
linuxppc-dev
In-Reply-To: <20220210224933.379149-1-yury.norov@gmail.com>
PowerPC code uses cpumask_weight() to compare the weight of cpumask with
a given number. We can do it more efficiently with cpumask_weight_{eq, ...}
because conditional cpumask_weight may stop traversing the cpumask earlier,
as soon as condition is (or can't be) met.
Signed-off-by: Yury Norov <yury.norov@gmail.com>
---
arch/powerpc/kernel/smp.c | 2 +-
arch/powerpc/kernel/watchdog.c | 2 +-
arch/powerpc/xmon/xmon.c | 4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index b7fd6a72aa76..8bff748df402 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -1656,7 +1656,7 @@ void start_secondary(void *unused)
if (has_big_cores)
sibling_mask = cpu_smallcore_mask;
- if (cpumask_weight(mask) > cpumask_weight(sibling_mask(cpu)))
+ if (cpumask_weight_gt(mask, cpumask_weight(sibling_mask(cpu))))
shared_caches = true;
}
diff --git a/arch/powerpc/kernel/watchdog.c b/arch/powerpc/kernel/watchdog.c
index bfc27496fe7e..62937a077de7 100644
--- a/arch/powerpc/kernel/watchdog.c
+++ b/arch/powerpc/kernel/watchdog.c
@@ -483,7 +483,7 @@ static void start_watchdog(void *arg)
wd_smp_lock(&flags);
cpumask_set_cpu(cpu, &wd_cpus_enabled);
- if (cpumask_weight(&wd_cpus_enabled) == 1) {
+ if (cpumask_weight_eq(&wd_cpus_enabled, 1)) {
cpumask_set_cpu(cpu, &wd_smp_cpus_pending);
wd_smp_last_reset_tb = get_tb();
}
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index fd72753e8ad5..b423812e94e0 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -469,7 +469,7 @@ static bool wait_for_other_cpus(int ncpus)
/* We wait for 2s, which is a metric "little while" */
for (timeout = 20000; timeout != 0; --timeout) {
- if (cpumask_weight(&cpus_in_xmon) >= ncpus)
+ if (cpumask_weight_ge(&cpus_in_xmon, ncpus))
return true;
udelay(100);
barrier();
@@ -1338,7 +1338,7 @@ static int cpu_cmd(void)
case 'S':
case 't':
cpumask_copy(&xmon_batch_cpus, &cpus_in_xmon);
- if (cpumask_weight(&xmon_batch_cpus) <= 1) {
+ if (cpumask_weight_le(&xmon_batch_cpus, 1)) {
printf("There are no other cpus in xmon\n");
break;
}
--
2.32.0
^ permalink raw reply related
* [PATCH 43/49] soc/qman: replace cpumask_weight with cpumask_weight_lt
From: Yury Norov @ 2022-02-10 22:49 UTC (permalink / raw)
To: Yury Norov, Andy Shevchenko, Rasmus Villemoes, Andrew Morton,
Michał Mirosław, Greg Kroah-Hartman, Peter Zijlstra,
David Laight, Joe Perches, Dennis Zhou, Emil Renner Berthing,
Nicholas Piggin, Matti Vaittinen, Alexey Klimov, linux-kernel,
Li Yang, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20220210224933.379149-1-yury.norov@gmail.com>
qman_test_stash() calls cpumask_weight() to compare the weight of cpumask
with a given number. We can do it more efficiently with cpumask_weight_lt
because conditional cpumask_weight may stop traversing the cpumask earlier,
as soon as condition is (or can't be) met.
Signed-off-by: Yury Norov <yury.norov@gmail.com>
---
drivers/soc/fsl/qbman/qman_test_stash.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/soc/fsl/qbman/qman_test_stash.c b/drivers/soc/fsl/qbman/qman_test_stash.c
index b7e8e5ec884c..28b08568a349 100644
--- a/drivers/soc/fsl/qbman/qman_test_stash.c
+++ b/drivers/soc/fsl/qbman/qman_test_stash.c
@@ -561,7 +561,7 @@ int qman_test_stash(void)
{
int err;
- if (cpumask_weight(cpu_online_mask) < 2) {
+ if (cpumask_weight_lt(cpu_online_mask, 2)) {
pr_info("%s(): skip - only 1 CPU\n", __func__);
return 0;
}
--
2.32.0
^ permalink raw reply related
* [PATCHv2] powerpc/lib/sstep: fix 'ptesync' build error
From: Anders Roxell @ 2022-02-11 0:51 UTC (permalink / raw)
To: mpe; +Cc: Anders Roxell, Arnd Bergmann, linux-kernel, stable, linuxppc-dev
Building tinyconfig with gcc (Debian 11.2.0-16) and assembler (Debian
2.37.90.20220207) the following build error shows up:
{standard input}: Assembler messages:
{standard input}:2088: Error: unrecognized opcode: `ptesync'
make[3]: *** [/builds/linux/scripts/Makefile.build:287: arch/powerpc/lib/sstep.o] Error 1
Add the 'ifdef CONFIG_PPC64' around the 'ptesync' in function
'emulate_update_regs()' to like it is in 'analyse_instr()'. Since it looks like
it got dropped inadvertently by commit 3cdfcbfd32b9 ("powerpc: Change
analyse_instr so it doesn't modify *regs").
Cc: stable@vger.kernel.org # v4.14+
Fixes: 3cdfcbfd32b9 ("powerpc: Change analyse_instr so it doesn't modify *regs")
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
---
arch/powerpc/lib/sstep.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/lib/sstep.c b/arch/powerpc/lib/sstep.c
index a94b0cd0bdc5..bd3734d5be89 100644
--- a/arch/powerpc/lib/sstep.c
+++ b/arch/powerpc/lib/sstep.c
@@ -3264,12 +3264,14 @@ void emulate_update_regs(struct pt_regs *regs, struct instruction_op *op)
case BARRIER_EIEIO:
eieio();
break;
+#ifdef CONFIG_PPC64
case BARRIER_LWSYNC:
asm volatile("lwsync" : : : "memory");
break;
case BARRIER_PTESYNC:
asm volatile("ptesync" : : : "memory");
break;
+#endif
}
break;
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v3 01/12] powerpc: Move and rename func_descr_t
From: Kees Cook @ 2022-02-11 0:51 UTC (permalink / raw)
To: Christophe Leroy
Cc: linux-arch, linux-ia64, linux-parisc, Arnd Bergmann,
Greg Kroah-Hartman, Helge Deller, linux-kernel,
James E.J. Bottomley, linux-mm, Paul Mackerras, Andrew Morton,
linuxppc-dev
In-Reply-To: <637a9a11263afa216fdfa7fb470a54479c67c61c.1634457599.git.christophe.leroy@csgroup.eu>
On Sun, Oct 17, 2021 at 02:38:14PM +0200, Christophe Leroy wrote:
> There are three architectures with function descriptors, try to
> have common names for the address they contain in order to
> refactor some functions into generic functions later.
>
> powerpc has 'entry'
> ia64 has 'ip'
> parisc has 'addr'
>
> Vote for 'addr' and update 'func_descr_t' accordingly.
>
> Move it in asm/elf.h to have it at the same place on all
> three architectures, remove the typedef which hides its real
> type, and change it to a smoother name 'struct func_desc'.
>
> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
I like the name. :)
Reviewed-by: Kees Cook <keescook@chromium.org>
--
Kees Cook
^ permalink raw reply
* Re: [PATCH v3 04/12] powerpc: Prepare func_desc_t for refactorisation
From: Kees Cook @ 2022-02-11 0:54 UTC (permalink / raw)
To: Christophe Leroy
Cc: linux-arch, linux-ia64, linux-parisc, Arnd Bergmann,
Greg Kroah-Hartman, Helge Deller, linux-kernel,
James E.J. Bottomley, linux-mm, Paul Mackerras, Andrew Morton,
linuxppc-dev
In-Reply-To: <86c393ce0a6f603f94e6d2ceca08d535f654bb23.1634457599.git.christophe.leroy@csgroup.eu>
On Sun, Oct 17, 2021 at 02:38:17PM +0200, Christophe Leroy wrote:
> In preparation of making func_desc_t generic, change the ELFv2
> version to a struct containing 'addr' element.
>
> This allows using single helpers common to ELFv1 and ELFv2.
>
> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> ---
> arch/powerpc/kernel/module_64.c | 32 ++++++++++++++------------------
> 1 file changed, 14 insertions(+), 18 deletions(-)
>
> diff --git a/arch/powerpc/kernel/module_64.c b/arch/powerpc/kernel/module_64.c
> index a89da0ee25e2..b687ef88c4c4 100644
> --- a/arch/powerpc/kernel/module_64.c
> +++ b/arch/powerpc/kernel/module_64.c
> @@ -33,19 +33,13 @@
> #ifdef PPC64_ELF_ABI_v2
>
> /* An address is simply the address of the function. */
> -typedef unsigned long func_desc_t;
> +typedef struct {
> + unsigned long addr;
> +} func_desc_t;
>
> static func_desc_t func_desc(unsigned long addr)
> {
> - return addr;
> -}
> -static unsigned long func_addr(unsigned long addr)
> -{
> - return addr;
> -}
> -static unsigned long stub_func_addr(func_desc_t func)
> -{
> - return func;
> + return (func_desc_t){addr};
There's only 1 element in the struct, so okay, but it hurt my eyes a
little. I would have been happier with:
return (func_desc_t){ .addr = addr; };
But of course that also looks bonkers because it starts with "return".
So no matter what I do my eyes bug out. ;)
So it's fine either way. :)
Reviewed-by: Kees Cook <keescook@chromium.org>
> }
>
> /* PowerPC64 specific values for the Elf64_Sym st_other field. */
> @@ -70,14 +64,6 @@ static func_desc_t func_desc(unsigned long addr)
> {
> return *(struct func_desc *)addr;
> }
> -static unsigned long func_addr(unsigned long addr)
> -{
> - return func_desc(addr).addr;
> -}
> -static unsigned long stub_func_addr(func_desc_t func)
> -{
> - return func.addr;
> -}
> static unsigned int local_entry_offset(const Elf64_Sym *sym)
> {
> return 0;
> @@ -93,6 +79,16 @@ void *dereference_module_function_descriptor(struct module *mod, void *ptr)
> }
> #endif
>
> +static unsigned long func_addr(unsigned long addr)
> +{
> + return func_desc(addr).addr;
> +}
> +
> +static unsigned long stub_func_addr(func_desc_t func)
> +{
> + return func.addr;
> +}
> +
> #define STUB_MAGIC 0x73747562 /* stub */
>
> /* Like PPC32, we need little trampolines to do > 24-bit jumps (into
> --
> 2.31.1
>
--
Kees Cook
^ permalink raw reply
* Re: [PATCH v3 08/12] asm-generic: Refactor dereference_[kernel]_function_descriptor()
From: Kees Cook @ 2022-02-11 0:56 UTC (permalink / raw)
To: Michael Ellerman
Cc: linux-arch, linux-ia64, linux-parisc, Arnd Bergmann, Helge Deller,
linux-kernel, James E.J. Bottomley, linux-mm, Paul Mackerras,
Greg Kroah-Hartman, Andrew Morton, linuxppc-dev
In-Reply-To: <8735kr814c.fsf@mpe.ellerman.id.au>
On Thu, Feb 10, 2022 at 09:30:43PM +1100, Michael Ellerman wrote:
> Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> > diff --git a/kernel/extable.c b/kernel/extable.c
> > index b0ea5eb0c3b4..1ef13789bea9 100644
> > --- a/kernel/extable.c
> > +++ b/kernel/extable.c
> > @@ -159,12 +160,32 @@ int kernel_text_address(unsigned long addr)
> > }
> >
> > /*
> > - * On some architectures (PPC64, IA64) function pointers
> > + * On some architectures (PPC64, IA64, PARISC) function pointers
> > * are actually only tokens to some data that then holds the
> > * real function address. As a result, to find if a function
> > * pointer is part of the kernel text, we need to do some
> > * special dereferencing first.
> > */
> > +#ifdef CONFIG_HAVE_FUNCTION_DESCRIPTORS
> > +void *dereference_function_descriptor(void *ptr)
> > +{
> > + func_desc_t *desc = ptr;
> > + void *p;
> > +
> > + if (!get_kernel_nofault(p, (void *)&desc->addr))
> > + ptr = p;
> > + return ptr;
> > +}
>
> This needs an EXPORT_SYMBOL_GPL(), otherwise the build breaks after
> patch 10 with CONFIG_LKDTM=m.
Oh good catch!
(There have been a few cases of LKDTM=m being the only thing needed a
symbol, so I've pondered giving it a namespace or constructing a little
ifdef wrapper... but this seems ok to export...)
--
Kees Cook
^ permalink raw reply
* Re: [PATCH v3 11/12] lkdtm: Fix execute_[user]_location()
From: Kees Cook @ 2022-02-11 1:01 UTC (permalink / raw)
To: Christophe Leroy
Cc: linux-arch, linux-ia64, linux-parisc, Arnd Bergmann,
Greg Kroah-Hartman, Helge Deller, linux-kernel,
James E.J. Bottomley, linux-mm, Paul Mackerras, Andrew Morton,
linuxppc-dev
In-Reply-To: <d4688c2af08dda706d3b6786ae5ec5a74e6171f1.1634457599.git.christophe.leroy@csgroup.eu>
On Sun, Oct 17, 2021 at 02:38:24PM +0200, Christophe Leroy wrote:
> execute_location() and execute_user_location() intent
> to copy do_nothing() text and execute it at a new location.
> However, at the time being it doesn't copy do_nothing() function
> but do_nothing() function descriptor which still points to the
> original text. So at the end it still executes do_nothing() at
> its original location allthough using a copied function descriptor.
>
> So, fix that by really copying do_nothing() text and build a new
> function descriptor by copying do_nothing() function descriptor and
> updating the target address with the new location.
>
> Also fix the displayed addresses by dereferencing do_nothing()
> function descriptor.
>
> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
This looks good. I might rename variables in the future (e.g. to avoid
the churn from adding _text) but also, that does help keep it clear. :)
Acked-by: Kees Cook <keescook@chromium.org>
-Kees
> ---
> drivers/misc/lkdtm/perms.c | 37 ++++++++++++++++++++++++++++---------
> 1 file changed, 28 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/misc/lkdtm/perms.c b/drivers/misc/lkdtm/perms.c
> index 035fcca441f0..1cf24c4a79e9 100644
> --- a/drivers/misc/lkdtm/perms.c
> +++ b/drivers/misc/lkdtm/perms.c
> @@ -44,19 +44,34 @@ static noinline void do_overwritten(void)
> return;
> }
>
> +static void *setup_function_descriptor(func_desc_t *fdesc, void *dst)
> +{
> + if (!have_function_descriptors())
> + return dst;
> +
> + memcpy(fdesc, do_nothing, sizeof(*fdesc));
> + fdesc->addr = (unsigned long)dst;
> + barrier();
> +
> + return fdesc;
> +}
> +
> static noinline void execute_location(void *dst, bool write)
> {
> - void (*func)(void) = dst;
> + void (*func)(void);
> + func_desc_t fdesc;
> + void *do_nothing_text = dereference_function_descriptor(do_nothing);
>
> - pr_info("attempting ok execution at %px\n", do_nothing);
> + pr_info("attempting ok execution at %px\n", do_nothing_text);
> do_nothing();
>
> if (write == CODE_WRITE) {
> - memcpy(dst, do_nothing, EXEC_SIZE);
> + memcpy(dst, do_nothing_text, EXEC_SIZE);
> flush_icache_range((unsigned long)dst,
> (unsigned long)dst + EXEC_SIZE);
> }
> - pr_info("attempting bad execution at %px\n", func);
> + pr_info("attempting bad execution at %px\n", dst);
> + func = setup_function_descriptor(&fdesc, dst);
> func();
> pr_err("FAIL: func returned\n");
> }
> @@ -66,16 +81,19 @@ static void execute_user_location(void *dst)
> int copied;
>
> /* Intentionally crossing kernel/user memory boundary. */
> - void (*func)(void) = dst;
> + void (*func)(void);
> + func_desc_t fdesc;
> + void *do_nothing_text = dereference_function_descriptor(do_nothing);
>
> - pr_info("attempting ok execution at %px\n", do_nothing);
> + pr_info("attempting ok execution at %px\n", do_nothing_text);
> do_nothing();
>
> - copied = access_process_vm(current, (unsigned long)dst, do_nothing,
> + copied = access_process_vm(current, (unsigned long)dst, do_nothing_text,
> EXEC_SIZE, FOLL_WRITE);
> if (copied < EXEC_SIZE)
> return;
> - pr_info("attempting bad execution at %px\n", func);
> + pr_info("attempting bad execution at %px\n", dst);
> + func = setup_function_descriptor(&fdesc, dst);
> func();
> pr_err("FAIL: func returned\n");
> }
> @@ -153,7 +171,8 @@ void lkdtm_EXEC_VMALLOC(void)
>
> void lkdtm_EXEC_RODATA(void)
> {
> - execute_location(lkdtm_rodata_do_nothing, CODE_AS_IS);
> + execute_location(dereference_function_descriptor(lkdtm_rodata_do_nothing),
> + CODE_AS_IS);
> }
>
> void lkdtm_EXEC_USERSPACE(void)
> --
> 2.31.1
>
--
Kees Cook
^ permalink raw reply
* Re: [PATCH v3 12/12] lkdtm: Add a test for function descriptors protection
From: Kees Cook @ 2022-02-11 1:09 UTC (permalink / raw)
To: Christophe Leroy
Cc: linux-arch, linux-ia64, linux-parisc, Arnd Bergmann,
Greg Kroah-Hartman, Helge Deller, linux-kernel,
James E.J. Bottomley, linux-mm, Paul Mackerras, Andrew Morton,
linuxppc-dev
In-Reply-To: <67f9545c9ad15048bfe0104278ef9595d051dbc8.1634457599.git.christophe.leroy@csgroup.eu>
On Sun, Oct 17, 2021 at 02:38:25PM +0200, Christophe Leroy wrote:
> Add WRITE_OPD to check that you can't modify function
> descriptors.
>
> Gives the following result when function descriptors are
> not protected:
>
> lkdtm: Performing direct entry WRITE_OPD
> lkdtm: attempting bad 16 bytes write at c00000000269b358
> lkdtm: FAIL: survived bad write
> lkdtm: do_nothing was hijacked!
>
> Looks like a standard compiler barrier() is not enough to force
> GCC to use the modified function descriptor. Had to add a fake empty
> inline assembly to force GCC to reload the function descriptor.
>
> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> ---
> drivers/misc/lkdtm/core.c | 1 +
> drivers/misc/lkdtm/lkdtm.h | 1 +
> drivers/misc/lkdtm/perms.c | 22 ++++++++++++++++++++++
> 3 files changed, 24 insertions(+)
>
> diff --git a/drivers/misc/lkdtm/core.c b/drivers/misc/lkdtm/core.c
> index fe6fd34b8caf..de092aa03b5d 100644
> --- a/drivers/misc/lkdtm/core.c
> +++ b/drivers/misc/lkdtm/core.c
> @@ -148,6 +148,7 @@ static const struct crashtype crashtypes[] = {
> CRASHTYPE(WRITE_RO),
> CRASHTYPE(WRITE_RO_AFTER_INIT),
> CRASHTYPE(WRITE_KERN),
> + CRASHTYPE(WRITE_OPD),
> CRASHTYPE(REFCOUNT_INC_OVERFLOW),
> CRASHTYPE(REFCOUNT_ADD_OVERFLOW),
> CRASHTYPE(REFCOUNT_INC_NOT_ZERO_OVERFLOW),
> diff --git a/drivers/misc/lkdtm/lkdtm.h b/drivers/misc/lkdtm/lkdtm.h
> index c212a253edde..188bd0fd6575 100644
> --- a/drivers/misc/lkdtm/lkdtm.h
> +++ b/drivers/misc/lkdtm/lkdtm.h
> @@ -105,6 +105,7 @@ void __init lkdtm_perms_init(void);
> void lkdtm_WRITE_RO(void);
> void lkdtm_WRITE_RO_AFTER_INIT(void);
> void lkdtm_WRITE_KERN(void);
> +void lkdtm_WRITE_OPD(void);
> void lkdtm_EXEC_DATA(void);
> void lkdtm_EXEC_STACK(void);
> void lkdtm_EXEC_KMALLOC(void);
> diff --git a/drivers/misc/lkdtm/perms.c b/drivers/misc/lkdtm/perms.c
> index 1cf24c4a79e9..2c6aba3ff32b 100644
> --- a/drivers/misc/lkdtm/perms.c
> +++ b/drivers/misc/lkdtm/perms.c
> @@ -44,6 +44,11 @@ static noinline void do_overwritten(void)
> return;
> }
>
> +static noinline void do_almost_nothing(void)
> +{
> + pr_info("do_nothing was hijacked!\n");
> +}
> +
> static void *setup_function_descriptor(func_desc_t *fdesc, void *dst)
> {
> if (!have_function_descriptors())
> @@ -144,6 +149,23 @@ void lkdtm_WRITE_KERN(void)
> do_overwritten();
> }
>
> +void lkdtm_WRITE_OPD(void)
> +{
> + size_t size = sizeof(func_desc_t);
> + void (*func)(void) = do_nothing;
> +
> + if (!have_function_descriptors()) {
> + pr_info("XFAIL: Platform doesn't use function descriptors.\n");
> + return;
> + }
> + pr_info("attempting bad %zu bytes write at %px\n", size, do_nothing);
> + memcpy(do_nothing, do_almost_nothing, size);
> + pr_err("FAIL: survived bad write\n");
Non-function-descriptor architectures would successfully crash at the
memcpy too, right? (i.e. for them this is just repeating WRITE_KERN)
I'm pondering the utility of the XFAIL vs just letting is succeed, but I
think it more accurate to say "hey, no OPD" as you have it.
> +
> + asm("" : "=m"(func));
> + func();
> +}
> +
> void lkdtm_EXEC_DATA(void)
> {
> execute_location(data_area, CODE_WRITE);
> --
> 2.31.1
>
One tiny suggestion, since I think you need to respin for the
EXPORT_SYMBOL_GPL() anyway. Please update the selftests too:
diff --git a/tools/testing/selftests/lkdtm/tests.txt b/tools/testing/selftests/lkdtm/tests.txt
index 6b36b7f5dcf9..243c781f0780 100644
--- a/tools/testing/selftests/lkdtm/tests.txt
+++ b/tools/testing/selftests/lkdtm/tests.txt
@@ -44,6 +44,7 @@ ACCESS_NULL
WRITE_RO
WRITE_RO_AFTER_INIT
WRITE_KERN
+WRITE_OPD
REFCOUNT_INC_OVERFLOW
REFCOUNT_ADD_OVERFLOW
REFCOUNT_INC_NOT_ZERO_OVERFLOW
(Though for the future I've been considering making the selftests an
opt-out list so the "normal" stuff doesn't need to keep getting added
there.)
Thanks!
Acked-by: Kees Cook <keescook@chromium.org>
-Kees
--
Kees Cook
^ permalink raw reply related
* Re: rcutorture’s init segfaults in ppc64le VM
From: Michael Ellerman @ 2022-02-11 1:48 UTC (permalink / raw)
To: Paul Menzel, Paul E. McKenney
Cc: rcu, Zhouyi Zhou, linuxppc-dev, Willy Tarreau
In-Reply-To: <e7498a9d-7420-ff52-99e4-8194f3d177f0@molgen.mpg.de>
Paul Menzel <pmenzel@molgen.mpg.de> writes:
> Am 08.02.22 um 11:09 schrieb Michael Ellerman:
>> Paul Menzel writes:
>
> […]
>
>>> On the POWER8 server IBM S822LC running Ubuntu 21.10, building Linux
>>> 5.17-rc2+ with rcutorture tests
>>
>> I'm not sure if that's the host kernel version or the version you're
>> using of rcutorture? Can you tell us the sha1 of your host kernel and of
>> the tree you're running rcutorture from?
>
> The host system runs Linux 5.17-rc1+ started with kexec. Unfortunately,
> I am unable to find the exact sha1.
>
> $ more /proc/version
> Linux version 5.17.0-rc1+
> (pmenzel@flughafenberlinbrandenburgwillybrandt.molgen.mpg.de) (Ubuntu
> clang version 13.0.0-2, LLD 13.0.0) #1 SMP Fri Jan 28
> 17:13:04 CET 2022
OK. In general rc1 kernels can have issues, so it might be worth
rebooting the host into either v5.17-rc3 or a distro or stable kernel.
Just to rule out any issues on the host.
> The Linux tree, from where I run rcutorture from, is at commit
> dfd42facf1e4 (Linux 5.17-rc3) with four patches on top:
>
> $ git log --oneline -6
> 207cec79e752 (HEAD -> master, origin/master, origin/HEAD) Problems
> with rcutorture on ppc64le: allmodconfig(2) and other failures
> 8c82f96fbe57 ata: libata-sata: improve sata_link_debounce()
> a447541d925f ata: libata-sata: remove debounce delay by default
> afd84e1eeafc ata: libata-sata: introduce struct sata_deb_timing
> f4caf7e48b75 ata: libata-sata: Simplify sata_link_resume() interface
> dfd42facf1e4 (tag: v5.17-rc3) Linux 5.17-rc3
>
>>> $ tools/testing/selftests/rcutorture/bin/torture.sh --duration 10
>>>
>>> the built init
>>>
>>> $ file tools/testing/selftests/rcutorture/initrd/init
>>> tools/testing/selftests/rcutorture/initrd/init: ELF 64-bit LSB executable, 64-bit PowerPC or cisco 7500, version 1 (SYSV), statically linked, BuildID[sha1]=0ded0e45649184a296f30d611f7a03cc51ecb616, for GNU/Linux 3.10.0, stripped
>>
>> Mine looks pretty much identical:
>>
>> $ file tools/testing/selftests/rcutorture/initrd/init
>> tools/testing/selftests/rcutorture/initrd/init: ELF 64-bit LSB executable, 64-bit PowerPC or cisco 7500, version 1 (SYSV), statically linked, BuildID[sha1]=86078bf6e5d54ab0860d36aa9a65d52818b972c8, for GNU/Linux 3.10.0, stripped
>>
>>> segfaults in QEMU. From one of the log files
>>
>> But mine doesn't segfault, it runs fine and the test completes.
>>
>> What qemu version are you using?
>>
>> I tried 4.2.1 and 6.2.0, both worked.
>
> $ qemu-system-ppc64le --version
> QEMU emulator version 6.0.0 (Debian 1:6.0+dfsg-2expubuntu1.1)
> Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers
OK, that's one difference between our setups, but I'd be surprised if it
explains this bug, but I guess anything's possible.
>>> /dev/shm/linux/tools/testing/selftests/rcutorture/res/2022.02.01-21.52.37-torture/results-rcutorture/TREE03/console.log
>
> Sorry, that was the wrong path/test. The correct one for the excerpt
> below is:
>
>
> /dev/shm/linux/tools/testing/selftests/rcutorture/res/2022.02.01-21.52.37-torture/results-locktorture-kasan/LOCK01/console.log
>
> (For TREE03, QEMU does not start the Linux kernel at all, that means no
> output after:
>
> Booting Linux via __start() @ 0x0000000000400000 ...
OK yeah I see that too.
Removing "threadirqs" from tools/testing/selftests/rcutorture/configs/rcu/TREE03.boot
seems to fix it.
I still see some preempt related warnings, we clearly have some bugs
with preempt enabled.
> You can now download the content of
> `/dev/shm/linux/tools/testing/selftests/rcutorture/res/2022.02.01-21.52.37-torture/results-locktorture-kasan/LOCK01`
> [1, 65 MB].
>
> Can you reproduce the segmentation fault with the line below?
>
> $ qemu-system-ppc64 -enable-kvm -nographic -smp cores=1,threads=8
> -net none -enable-kvm -M pseries -nodefaults -device spapr-vscsi -serial
> stdio -m 512 -kernel
> /dev/shm/linux/tools/testing/selftests/rcutorture/res/2022.02.01-21.52.37-torture/results-locktorture-kasan/LOCK01/vmlinux
> -append "debug_boot_weak_hash panic=-1 console=ttyS0
> torture.disable_onoff_at_boot locktorture.onoff_interval=3
> locktorture.onoff_holdoff=30 locktorture.stat_interval=15
> locktorture.shutdown_secs=60 locktorture.verbose=1"
That works fine for me, boots and runs the test, then shuts down.
I assume you see the segfault on every boot, not intermittently?
So the differences between our setups are the host kernel and the qemu
version. Can you try a different host kernel easily?
The other thing would be to try a different qemu version, you might need
to build from source, but it's not that hard :)
cheers
^ permalink raw reply
* [powerpc:fixes-test] BUILD SUCCESS 9bb162fa26ed76031ed0e7dbc77ccea0bf977758
From: kernel test robot @ 2022-02-11 2:22 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git fixes-test
branch HEAD: 9bb162fa26ed76031ed0e7dbc77ccea0bf977758 powerpc/603: Fix boot failure with DEBUG_PAGEALLOC and KFENCE
elapsed time: 723m
configs tested: 174
configs skipped: 97
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
powerpc randconfig-c003-20220210
i386 randconfig-c001
xtensa virt_defconfig
powerpc64 defconfig
powerpc sequoia_defconfig
arm iop32x_defconfig
h8300 defconfig
sh se7722_defconfig
sh ecovec24_defconfig
alpha defconfig
arm lpc18xx_defconfig
powerpc ppc64_defconfig
arm mini2440_defconfig
arm multi_v4t_defconfig
openrisc simple_smp_defconfig
sh se7206_defconfig
sh hp6xx_defconfig
parisc generic-64bit_defconfig
arm cm_x300_defconfig
sh titan_defconfig
x86_64 alldefconfig
powerpc ppc40x_defconfig
sh sh7757lcr_defconfig
arm shmobile_defconfig
mips ip32_defconfig
m68k q40_defconfig
powerpc warp_defconfig
s390 defconfig
riscv nommu_k210_defconfig
powerpc mpc834x_itx_defconfig
arm ezx_defconfig
arm cerfcube_defconfig
powerpc tqm8541_defconfig
arm h3600_defconfig
powerpc eiger_defconfig
arm s3c6400_defconfig
csky alldefconfig
powerpc ep88xc_defconfig
ia64 bigsur_defconfig
sh dreamcast_defconfig
arc nsimosci_hs_defconfig
mips allmodconfig
powerpc64 alldefconfig
sh defconfig
m68k m5407c3_defconfig
sh sh7770_generic_defconfig
arm pxa_defconfig
m68k m5249evb_defconfig
csky defconfig
powerpc klondike_defconfig
arc alldefconfig
um defconfig
s390 debug_defconfig
sh r7785rp_defconfig
arm footbridge_defconfig
alpha allyesconfig
m68k hp300_defconfig
powerpc tqm8555_defconfig
xtensa defconfig
arm jornada720_defconfig
arm sunxi_defconfig
powerpc linkstation_defconfig
sh microdev_defconfig
arc vdk_hs38_smp_defconfig
arm multi_v7_defconfig
sh se7750_defconfig
m68k amiga_defconfig
alpha alldefconfig
powerpc arches_defconfig
powerpc mpc837x_rdb_defconfig
arm randconfig-c002-20220210
arm randconfig-c002-20220209
arm randconfig-c002-20220211
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
nds32 defconfig
nios2 allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
s390 allmodconfig
parisc allyesconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
i386 debian-10.3-kselftests
i386 debian-10.3
mips allyesconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
x86_64 randconfig-a006
x86_64 randconfig-a004
x86_64 randconfig-a002
i386 randconfig-a012
i386 randconfig-a014
i386 randconfig-a016
s390 randconfig-r044-20220209
arc randconfig-r043-20220208
arc randconfig-r043-20220209
riscv randconfig-r042-20220210
riscv randconfig-r042-20220209
arc randconfig-r043-20220210
s390 randconfig-r044-20220210
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
riscv rv32_defconfig
x86_64 rhel-8.3-kselftests
um x86_64_defconfig
um i386_defconfig
x86_64 allyesconfig
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-func
x86_64 kexec
clang tested configs:
riscv randconfig-c006-20220209
x86_64 randconfig-c007
powerpc randconfig-c003-20220209
i386 randconfig-c001
mips randconfig-c004-20220209
arm randconfig-c002-20220209
riscv randconfig-c006-20220210
powerpc randconfig-c003-20220210
arm randconfig-c002-20220210
mips randconfig-c004-20220210
powerpc ksi8560_defconfig
powerpc ppc44x_defconfig
mips e55_defconfig
x86_64 allyesconfig
arm ep93xx_defconfig
powerpc gamecube_defconfig
powerpc ge_imp3a_defconfig
arm multi_v5_defconfig
mips rbtx49xx_defconfig
hexagon defconfig
powerpc mpc836x_mds_defconfig
powerpc tqm5200_defconfig
powerpc ebony_defconfig
mips pic32mzda_defconfig
powerpc kilauea_defconfig
powerpc mpc5200_defconfig
powerpc akebono_defconfig
mips ath79_defconfig
arm omap1_defconfig
x86_64 randconfig-a005
x86_64 randconfig-a003
x86_64 randconfig-a001
i386 randconfig-a002
i386 randconfig-a006
i386 randconfig-a004
x86_64 randconfig-a012
x86_64 randconfig-a014
x86_64 randconfig-a016
i386 randconfig-a011
i386 randconfig-a013
i386 randconfig-a015
hexagon randconfig-r045-20220210
hexagon randconfig-r045-20220208
hexagon randconfig-r041-20220210
hexagon randconfig-r041-20220208
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [PATCH kernel 0/3] powerpc/llvm/lto: Enable CONFIG_LTO_CLANG_THIN=y
From: Alexey Kardashevskiy @ 2022-02-11 2:31 UTC (permalink / raw)
To: llvm
Cc: Nathan Lynch, Fabiano Rosas, Alexey Kardashevskiy,
Nick Desaulniers, Nicholas Piggin, Nathan Chancellor,
Joel Stanley, Naveen N. Rao, linuxppc-dev, Daniel Axtens
This is based on sha1
1b43a74f255c Michael Ellerman "Automatic merge of 'master' into merge (2022-02-01 10:41)".
Please comment. Thanks.
Alexey Kardashevskiy (3):
powerpc/64: Allow LLVM LTO builds
powerpc/llvm: Sample config for LLVM LTO
powerpc/llvm/lto: Workaround conditional branches in FTR_SECTION_ELSE
arch/powerpc/Makefile | 4 +
arch/powerpc/Kconfig | 2 +
arch/powerpc/configs/ppc64_lto_defconfig | 381 +++++++++++++++++++++++
arch/powerpc/kernel/exceptions-64s.S | 6 +-
arch/powerpc/lib/copyuser_64.S | 3 +-
arch/powerpc/lib/memcpy_64.S | 3 +-
6 files changed, 396 insertions(+), 3 deletions(-)
create mode 100644 arch/powerpc/configs/ppc64_lto_defconfig
--
2.30.2
^ permalink raw reply
* [PATCH kernel 1/3] powerpc/64: Allow LLVM LTO builds
From: Alexey Kardashevskiy @ 2022-02-11 2:31 UTC (permalink / raw)
To: llvm
Cc: Nathan Lynch, Fabiano Rosas, Alexey Kardashevskiy,
Nick Desaulniers, Nicholas Piggin, Nathan Chancellor,
Joel Stanley, Naveen N. Rao, linuxppc-dev, Daniel Axtens
In-Reply-To: <20220211023125.1790960-1-aik@ozlabs.ru>
The upstream LLVM supports now LTO on PPC, enable it.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
arch/powerpc/Kconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index b779603978e1..91c122224f83 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -153,6 +153,8 @@ config PPC
select ARCH_WANT_IRQS_OFF_ACTIVATE_MM
select ARCH_WANT_LD_ORPHAN_WARN
select ARCH_WEAK_RELEASE_ACQUIRE
+ select ARCH_SUPPORTS_LTO_CLANG if PPC64
+ select ARCH_SUPPORTS_LTO_CLANG_THIN if PPC64
select BINFMT_ELF
select BUILDTIME_TABLE_SORT
select CLONE_BACKWARDS
--
2.30.2
^ permalink raw reply related
* [PATCH kernel 2/3] powerpc/llvm: Sample config for LLVM LTO
From: Alexey Kardashevskiy @ 2022-02-11 2:31 UTC (permalink / raw)
To: llvm
Cc: Nathan Lynch, Fabiano Rosas, Alexey Kardashevskiy,
Nick Desaulniers, Nicholas Piggin, Nathan Chancellor,
Joel Stanley, Naveen N. Rao, linuxppc-dev, Daniel Axtens
In-Reply-To: <20220211023125.1790960-1-aik@ozlabs.ru>
The config is a copy of ppc64_defconfig with a few tweaks. This could be
a smaller config to merge into ppc64_defconfig but unfortunately
merger does not allow disabling already enabled options.
This is a command line to compile the kernel using the upstream llvm:
make -j64 O=/home/aik/pbuild/kernels-llvm/ \
"KCFLAGS=-Wmissing-braces -Wno-array-bounds" \
ARCH=powerpc LLVM_IAS=1 ppc64le_lto_defconfig CC=clang LLVM=1
Forces CONFIG_BTRFS_FS=y to make CONFIG_ZSTD_COMPRESS=y to fix:
ld.lld: error: linking module flags 'Code Model': IDs have conflicting values in 'lib/built-in.a(entropy_common.o at 5332)' and 'ld-temp.o'
because modules are linked with -mcmodel=large but the kernel uses -mcmodel=medium
Enables CONFIG_USERFAULTFD=y as otherwise vm_userfaultfd_ctx becomes
0 bytes long and clang sanitizer crashes as
https://bugs.llvm.org/show_bug.cgi?id=500375
Disables CONFIG_FTR_FIXUP_SELFTEST as it uses FTR_SECTION_ELSE with
conditional branches. There are other places like this and the following
patches address that.
Disables CONFIG_FTRACE_MCOUNT_USE_RECORDMCOUNT as CONFIG_HAS_LTO_CLANG
depends on it being disabled. In order to avoid disabling way too many
options (like DYNAMIC_FTRACE/FUNCTION_TRACER), this converts
FTRACE_MCOUNT_USE_RECORDMCOUNT from def_bool to bool.
Note that even with this config there is a good chance that LTO
is going to fail linking vmlinux because of the "bc" problem.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
arch/powerpc/Makefile | 4 +
arch/powerpc/configs/ppc64_lto_defconfig | 381 +++++++++++++++++++++++
2 files changed, 385 insertions(+)
create mode 100644 arch/powerpc/configs/ppc64_lto_defconfig
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 5f16ac1583c5..23f1ade8abc9 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -308,6 +308,10 @@ PHONY += ppc64le_defconfig
ppc64le_defconfig:
$(call merge_into_defconfig,ppc64_defconfig,le)
+PHONY += ppc64le_lto_defconfig
+ppc64le_lto_defconfig:
+ $(call merge_into_defconfig,ppc64_lto_defconfig,le)
+
PHONY += ppc64le_guest_defconfig
ppc64le_guest_defconfig:
$(call merge_into_defconfig,ppc64_defconfig,le guest)
diff --git a/arch/powerpc/configs/ppc64_lto_defconfig b/arch/powerpc/configs/ppc64_lto_defconfig
new file mode 100644
index 000000000000..67f82b422b7d
--- /dev/null
+++ b/arch/powerpc/configs/ppc64_lto_defconfig
@@ -0,0 +1,381 @@
+CONFIG_SYSVIPC=y
+CONFIG_POSIX_MQUEUE=y
+CONFIG_NO_HZ=y
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_TASKSTATS=y
+CONFIG_TASK_DELAY_ACCT=y
+CONFIG_IKCONFIG=y
+CONFIG_IKCONFIG_PROC=y
+CONFIG_LOG_BUF_SHIFT=18
+CONFIG_LOG_CPU_MAX_BUF_SHIFT=13
+CONFIG_NUMA_BALANCING=y
+CONFIG_CGROUPS=y
+CONFIG_MEMCG=y
+CONFIG_CGROUP_SCHED=y
+CONFIG_CGROUP_FREEZER=y
+CONFIG_CPUSETS=y
+CONFIG_CGROUP_DEVICE=y
+CONFIG_CGROUP_CPUACCT=y
+CONFIG_CGROUP_PERF=y
+CONFIG_CGROUP_BPF=y
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_BPF_SYSCALL=y
+# CONFIG_COMPAT_BRK is not set
+CONFIG_PROFILING=y
+CONFIG_PPC64=y
+CONFIG_NR_CPUS=2048
+CONFIG_PPC_SPLPAR=y
+CONFIG_DTL=y
+CONFIG_PPC_SMLPAR=y
+CONFIG_IBMEBUS=y
+CONFIG_PPC_SVM=y
+CONFIG_PPC_MAPLE=y
+CONFIG_PPC_PASEMI=y
+CONFIG_PPC_PASEMI_IOMMU=y
+CONFIG_PPC_PS3=y
+CONFIG_PS3_DISK=m
+CONFIG_PS3_ROM=m
+CONFIG_PS3_FLASH=m
+CONFIG_PS3_LPM=m
+CONFIG_PPC_IBM_CELL_BLADE=y
+CONFIG_RTAS_FLASH=m
+CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
+CONFIG_CPU_FREQ_GOV_POWERSAVE=y
+CONFIG_CPU_FREQ_GOV_USERSPACE=y
+CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y
+CONFIG_CPU_FREQ_PMAC64=y
+CONFIG_HZ_100=y
+CONFIG_PPC_TRANSACTIONAL_MEM=y
+CONFIG_KEXEC=y
+CONFIG_KEXEC_FILE=y
+CONFIG_CRASH_DUMP=y
+CONFIG_FA_DUMP=y
+CONFIG_IRQ_ALL_CPUS=y
+CONFIG_SCHED_SMT=y
+CONFIG_HOTPLUG_PCI=y
+CONFIG_HOTPLUG_PCI_RPA=m
+CONFIG_HOTPLUG_PCI_RPA_DLPAR=m
+CONFIG_PCCARD=y
+CONFIG_ELECTRA_CF=y
+CONFIG_VIRTUALIZATION=y
+CONFIG_KVM_BOOK3S_64=m
+CONFIG_KVM_BOOK3S_64_HV=m
+CONFIG_VHOST_NET=m
+CONFIG_KPROBES=y
+CONFIG_JUMP_LABEL=y
+CONFIG_MODULES=y
+CONFIG_MODULE_UNLOAD=y
+CONFIG_MODVERSIONS=y
+CONFIG_MODULE_SRCVERSION_ALL=y
+CONFIG_PARTITION_ADVANCED=y
+CONFIG_BINFMT_MISC=m
+CONFIG_MEMORY_HOTPLUG=y
+CONFIG_MEMORY_HOTREMOVE=y
+CONFIG_KSM=y
+CONFIG_TRANSPARENT_HUGEPAGE=y
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_UNIX=y
+CONFIG_XFRM_USER=m
+CONFIG_NET_KEY=m
+CONFIG_INET=y
+CONFIG_IP_MULTICAST=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_DHCP=y
+CONFIG_IP_PNP_BOOTP=y
+CONFIG_NET_IPIP=y
+CONFIG_SYN_COOKIES=y
+CONFIG_INET_AH=m
+CONFIG_INET_ESP=m
+CONFIG_INET_IPCOMP=m
+CONFIG_IPV6=y
+CONFIG_NETFILTER=y
+# CONFIG_NETFILTER_ADVANCED is not set
+CONFIG_BRIDGE=m
+CONFIG_NET_SCHED=y
+CONFIG_NET_CLS_BPF=m
+CONFIG_NET_CLS_ACT=y
+CONFIG_NET_ACT_BPF=m
+CONFIG_BPF_JIT=y
+CONFIG_DEVTMPFS=y
+CONFIG_DEVTMPFS_MOUNT=y
+CONFIG_BLK_DEV_FD=y
+CONFIG_BLK_DEV_LOOP=y
+CONFIG_BLK_DEV_NBD=m
+CONFIG_BLK_DEV_RAM=y
+CONFIG_BLK_DEV_RAM_SIZE=65536
+CONFIG_VIRTIO_BLK=m
+CONFIG_BLK_DEV_SD=y
+CONFIG_CHR_DEV_ST=m
+CONFIG_BLK_DEV_SR=y
+CONFIG_CHR_DEV_SG=y
+CONFIG_SCSI_CONSTANTS=y
+CONFIG_SCSI_FC_ATTRS=y
+CONFIG_SCSI_CXGB3_ISCSI=m
+CONFIG_SCSI_CXGB4_ISCSI=m
+CONFIG_SCSI_BNX2_ISCSI=m
+CONFIG_BE2ISCSI=m
+CONFIG_SCSI_MPT2SAS=m
+CONFIG_SCSI_IBMVSCSI=y
+CONFIG_SCSI_IBMVFC=m
+CONFIG_SCSI_SYM53C8XX_2=m
+CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=0
+CONFIG_SCSI_IPR=y
+CONFIG_SCSI_QLA_FC=m
+CONFIG_SCSI_QLA_ISCSI=m
+CONFIG_SCSI_LPFC=m
+CONFIG_SCSI_VIRTIO=m
+CONFIG_SCSI_DH=y
+CONFIG_SCSI_DH_RDAC=m
+CONFIG_SCSI_DH_ALUA=m
+CONFIG_ATA=y
+CONFIG_SATA_AHCI=y
+CONFIG_SATA_SIL24=y
+CONFIG_SATA_MV=y
+CONFIG_SATA_SVW=y
+CONFIG_PATA_AMD=y
+CONFIG_PATA_MACIO=y
+CONFIG_ATA_GENERIC=y
+CONFIG_MD=y
+CONFIG_BLK_DEV_MD=y
+CONFIG_MD_LINEAR=y
+CONFIG_MD_RAID0=y
+CONFIG_MD_RAID1=y
+CONFIG_MD_RAID10=m
+CONFIG_MD_RAID456=m
+CONFIG_MD_MULTIPATH=m
+CONFIG_MD_FAULTY=m
+CONFIG_BLK_DEV_DM=y
+CONFIG_DM_CRYPT=m
+CONFIG_DM_SNAPSHOT=m
+CONFIG_DM_MIRROR=m
+CONFIG_DM_ZERO=m
+CONFIG_DM_MULTIPATH=m
+CONFIG_DM_MULTIPATH_QL=m
+CONFIG_DM_MULTIPATH_ST=m
+CONFIG_DM_UEVENT=y
+CONFIG_ADB_PMU=y
+CONFIG_PMAC_SMU=y
+CONFIG_WINDFARM=y
+CONFIG_WINDFARM_PM81=y
+CONFIG_WINDFARM_PM91=y
+CONFIG_WINDFARM_PM112=y
+CONFIG_WINDFARM_PM121=y
+CONFIG_BONDING=m
+CONFIG_DUMMY=m
+CONFIG_NETCONSOLE=y
+CONFIG_TUN=m
+CONFIG_VIRTIO_NET=m
+CONFIG_VORTEX=m
+CONFIG_ACENIC=m
+CONFIG_ACENIC_OMIT_TIGON_I=y
+CONFIG_PCNET32=m
+CONFIG_TIGON3=y
+CONFIG_BNX2X=m
+CONFIG_CHELSIO_T1=m
+CONFIG_BE2NET=m
+CONFIG_IBMVETH=m
+CONFIG_EHEA=m
+CONFIG_IBMVNIC=m
+CONFIG_E100=y
+CONFIG_E1000=y
+CONFIG_E1000E=y
+CONFIG_IXGB=m
+CONFIG_IXGBE=m
+CONFIG_I40E=m
+CONFIG_MLX4_EN=m
+CONFIG_MYRI10GE=m
+CONFIG_S2IO=m
+CONFIG_PASEMI_MAC=y
+CONFIG_NETXEN_NIC=m
+CONFIG_SUNGEM=y
+CONFIG_GELIC_NET=m
+CONFIG_GELIC_WIRELESS=y
+CONFIG_SPIDER_NET=m
+CONFIG_BROADCOM_PHY=m
+CONFIG_MARVELL_PHY=y
+CONFIG_PPP=m
+CONFIG_PPP_BSDCOMP=m
+CONFIG_PPP_DEFLATE=m
+CONFIG_PPPOE=m
+CONFIG_PPP_ASYNC=m
+CONFIG_PPP_SYNC_TTY=m
+CONFIG_INPUT_EVDEV=m
+CONFIG_INPUT_MISC=y
+CONFIG_INPUT_PCSPKR=m
+# CONFIG_SERIO_SERPORT is not set
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_ICOM=m
+CONFIG_SERIAL_JSM=m
+CONFIG_HVC_CONSOLE=y
+CONFIG_HVC_RTAS=y
+CONFIG_HVCS=m
+CONFIG_VIRTIO_CONSOLE=m
+CONFIG_IBM_BSR=m
+CONFIG_RAW_DRIVER=y
+CONFIG_I2C_CHARDEV=y
+CONFIG_I2C_AMD8111=y
+CONFIG_I2C_PASEMI=y
+CONFIG_FB=y
+CONFIG_FIRMWARE_EDID=y
+CONFIG_FB_OF=y
+CONFIG_FB_MATROX=y
+CONFIG_FB_MATROX_MILLENIUM=y
+CONFIG_FB_MATROX_MYSTIQUE=y
+CONFIG_FB_MATROX_G=y
+CONFIG_FB_MATROX_I2C=m
+CONFIG_FB_MATROX_MAVEN=m
+CONFIG_FB_RADEON=y
+CONFIG_FB_IBM_GXT4500=y
+CONFIG_FB_PS3=m
+CONFIG_LCD_CLASS_DEVICE=y
+# CONFIG_VGA_CONSOLE is not set
+CONFIG_FRAMEBUFFER_CONSOLE=y
+CONFIG_LOGO=y
+CONFIG_SOUND=m
+CONFIG_SND=m
+CONFIG_SND_OSSEMUL=y
+CONFIG_SND_MIXER_OSS=m
+CONFIG_SND_PCM_OSS=m
+CONFIG_SND_SEQUENCER=m
+CONFIG_SND_SEQ_DUMMY=m
+CONFIG_SND_SEQUENCER_OSS=m
+CONFIG_SND_POWERMAC=m
+CONFIG_SND_AOA=m
+CONFIG_SND_AOA_FABRIC_LAYOUT=m
+CONFIG_SND_AOA_ONYX=m
+CONFIG_SND_AOA_TAS=m
+CONFIG_SND_AOA_TOONIE=m
+CONFIG_HID_GYRATION=y
+CONFIG_HID_PANTHERLORD=y
+CONFIG_HID_PETALYNX=y
+CONFIG_HID_SAMSUNG=y
+CONFIG_HID_SUNPLUS=y
+CONFIG_USB_HIDDEV=y
+CONFIG_USB=y
+CONFIG_USB_MON=m
+CONFIG_USB_EHCI_HCD=y
+# CONFIG_USB_EHCI_HCD_PPC_OF is not set
+CONFIG_USB_OHCI_HCD=y
+CONFIG_USB_STORAGE=m
+CONFIG_USB_APPLEDISPLAY=m
+CONFIG_NEW_LEDS=y
+CONFIG_LEDS_CLASS=m
+CONFIG_LEDS_POWERNV=m
+CONFIG_INFINIBAND=m
+CONFIG_INFINIBAND_USER_MAD=m
+CONFIG_INFINIBAND_USER_ACCESS=m
+CONFIG_INFINIBAND_MTHCA=m
+CONFIG_INFINIBAND_CXGB4=m
+CONFIG_MLX4_INFINIBAND=m
+CONFIG_INFINIBAND_IPOIB=m
+CONFIG_INFINIBAND_IPOIB_CM=y
+CONFIG_INFINIBAND_SRP=m
+CONFIG_INFINIBAND_ISER=m
+CONFIG_EDAC=y
+CONFIG_EDAC_PASEMI=y
+CONFIG_RTC_CLASS=y
+CONFIG_RTC_DRV_DS1307=y
+CONFIG_VIRTIO_PCI=m
+CONFIG_VIRTIO_BALLOON=m
+CONFIG_LIBNVDIMM=y
+CONFIG_RAS=y
+CONFIG_EXT2_FS=y
+CONFIG_EXT2_FS_XATTR=y
+CONFIG_EXT2_FS_POSIX_ACL=y
+CONFIG_EXT2_FS_SECURITY=y
+CONFIG_EXT4_FS=y
+CONFIG_EXT4_FS_POSIX_ACL=y
+CONFIG_EXT4_FS_SECURITY=y
+CONFIG_REISERFS_FS=m
+CONFIG_REISERFS_FS_XATTR=y
+CONFIG_REISERFS_FS_POSIX_ACL=y
+CONFIG_REISERFS_FS_SECURITY=y
+CONFIG_JFS_FS=m
+CONFIG_JFS_POSIX_ACL=y
+CONFIG_JFS_SECURITY=y
+CONFIG_XFS_FS=y
+CONFIG_XFS_POSIX_ACL=y
+CONFIG_BTRFS_FS=y
+CONFIG_BTRFS_FS_POSIX_ACL=y
+CONFIG_NILFS2_FS=m
+CONFIG_FS_DAX=y
+CONFIG_AUTOFS4_FS=m
+CONFIG_FUSE_FS=m
+CONFIG_OVERLAY_FS=m
+CONFIG_ISO9660_FS=y
+CONFIG_UDF_FS=m
+CONFIG_MSDOS_FS=y
+CONFIG_VFAT_FS=m
+CONFIG_PROC_KCORE=y
+CONFIG_TMPFS=y
+CONFIG_TMPFS_POSIX_ACL=y
+CONFIG_HUGETLBFS=y
+CONFIG_HFS_FS=m
+CONFIG_HFSPLUS_FS=m
+CONFIG_CRAMFS=m
+CONFIG_SQUASHFS=m
+CONFIG_SQUASHFS_XATTR=y
+CONFIG_SQUASHFS_LZO=y
+CONFIG_SQUASHFS_XZ=y
+CONFIG_NFS_FS=y
+CONFIG_NFS_V3_ACL=y
+CONFIG_NFS_V4=y
+CONFIG_ROOT_NFS=y
+CONFIG_NFSD=m
+CONFIG_NFSD_V3_ACL=y
+CONFIG_NFSD_V4=y
+CONFIG_CIFS=m
+CONFIG_CIFS_XATTR=y
+CONFIG_CIFS_POSIX=y
+CONFIG_NLS_DEFAULT="utf8"
+CONFIG_NLS_CODEPAGE_437=y
+CONFIG_NLS_ASCII=y
+CONFIG_NLS_ISO8859_1=y
+CONFIG_NLS_UTF8=y
+CONFIG_CRYPTO_TEST=m
+CONFIG_CRYPTO_PCBC=m
+CONFIG_CRYPTO_HMAC=y
+CONFIG_CRYPTO_CRC32C_VPMSUM=m
+CONFIG_CRYPTO_MD5_PPC=m
+CONFIG_CRYPTO_MICHAEL_MIC=m
+CONFIG_CRYPTO_SHA1_PPC=m
+CONFIG_CRYPTO_SHA256=y
+CONFIG_CRYPTO_TGR192=m
+CONFIG_CRYPTO_WP512=m
+CONFIG_CRYPTO_ANUBIS=m
+CONFIG_CRYPTO_BLOWFISH=m
+CONFIG_CRYPTO_CAST6=m
+CONFIG_CRYPTO_KHAZAD=m
+CONFIG_CRYPTO_SALSA20=m
+CONFIG_CRYPTO_SERPENT=m
+CONFIG_CRYPTO_TEA=m
+CONFIG_CRYPTO_TWOFISH=m
+CONFIG_CRYPTO_LZO=m
+CONFIG_CRYPTO_DEV_NX=y
+CONFIG_CRYPTO_DEV_NX_ENCRYPT=m
+CONFIG_CRYPTO_DEV_VMX=y
+CONFIG_PRINTK_TIME=y
+CONFIG_PRINTK_CALLER=y
+CONFIG_MAGIC_SYSRQ=y
+CONFIG_DEBUG_KERNEL=y
+CONFIG_DEBUG_STACK_USAGE=y
+CONFIG_DEBUG_STACKOVERFLOW=y
+CONFIG_SOFTLOCKUP_DETECTOR=y
+CONFIG_HARDLOCKUP_DETECTOR=y
+CONFIG_DEBUG_MUTEXES=y
+CONFIG_FUNCTION_TRACER=y
+CONFIG_FTRACE_SYSCALLS=y
+CONFIG_SCHED_TRACER=y
+CONFIG_STACK_TRACER=y
+CONFIG_BLK_DEV_IO_TRACE=y
+CONFIG_CODE_PATCHING_SELFTEST=y
+CONFIG_FTR_FIXUP_SELFTEST=n
+CONFIG_MSI_BITMAP_SELFTEST=y
+CONFIG_XMON=y
+CONFIG_BOOTX_TEXT=y
+CONFIG_LTO=y
+CONFIG_LTO_CLANG_THIN=y
+CONFIG_FTRACE_MCOUNT_USE_RECORDMCOUNT=n
+CONFIG_USERFAULTFD=y
--
2.30.2
^ permalink raw reply related
* [PATCH kernel 3/3] powerpc/llvm/lto: Workaround conditional branches in FTR_SECTION_ELSE
From: Alexey Kardashevskiy @ 2022-02-11 2:31 UTC (permalink / raw)
To: llvm
Cc: Nathan Lynch, Fabiano Rosas, Alexey Kardashevskiy,
Nick Desaulniers, Nicholas Piggin, Nathan Chancellor,
Joel Stanley, Naveen N. Rao, linuxppc-dev, Daniel Axtens
In-Reply-To: <20220211023125.1790960-1-aik@ozlabs.ru>
LTO invites ld/lld to optimize the output binary and this may affect
the FTP alternative section if alt branches use "bc" (Branch Conditional)
which only allows 16 bit offsets. This manifests in errors like:
ld.lld: error: InputSection too large for range extension thunk vmlinux.o:(__ftr_alt_97+0xF0)
This works around the problem by replacing "bc" and its alias(es) in
FTR_SECTION_ELSE with "b" which allows 26 bit offsets.
This catches the problem instructions in vmlinux.o before it LTO'ed:
$ objdump -d -M raw -j __ftr_alt_97 vmlinux.o | egrep '\S+\s*\<bc\>'
30: 00 00 82 40 bc 4,eq,30 <__ftr_alt_97+0x30>
f0: 00 00 82 40 bc 4,eq,f0 <__ftr_alt_97+0xf0>
The change in copyuser_64.S is needed even when building default
configs, the other two changes are needed if the kernel config grows.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
arch/powerpc/kernel/exceptions-64s.S | 6 +++++-
arch/powerpc/lib/copyuser_64.S | 3 ++-
arch/powerpc/lib/memcpy_64.S | 3 ++-
3 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
index 55caeee37c08..b8d9a2f5f3a5 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -476,9 +476,13 @@ DEFINE_FIXED_SYMBOL(\name\()_common_real, text)
.if IHSRR_IF_HVMODE
BEGIN_FTR_SECTION
bne masked_Hinterrupt
+ b 4f
FTR_SECTION_ELSE
- bne masked_interrupt
+ nop
+ nop
ALT_FTR_SECTION_END_IFSET(CPU_FTR_HVMODE | CPU_FTR_ARCH_206)
+ bne masked_interrupt
+4:
.elseif IHSRR
bne masked_Hinterrupt
.else
diff --git a/arch/powerpc/lib/copyuser_64.S b/arch/powerpc/lib/copyuser_64.S
index db8719a14846..d07f95eebc65 100644
--- a/arch/powerpc/lib/copyuser_64.S
+++ b/arch/powerpc/lib/copyuser_64.S
@@ -75,10 +75,11 @@ _GLOBAL(__copy_tofrom_user_base)
* set is Power6.
*/
test_feature = (SELFTEST_CASE == 1)
+ beq .Ldst_aligned
BEGIN_FTR_SECTION
nop
FTR_SECTION_ELSE
- bne .Ldst_unaligned
+ b .Ldst_unaligned
ALT_FTR_SECTION_END(CPU_FTR_UNALIGNED_LD_STD | CPU_FTR_CP_USE_DCBTZ, \
CPU_FTR_UNALIGNED_LD_STD)
.Ldst_aligned:
diff --git a/arch/powerpc/lib/memcpy_64.S b/arch/powerpc/lib/memcpy_64.S
index 016c91e958d8..286c7e2d0883 100644
--- a/arch/powerpc/lib/memcpy_64.S
+++ b/arch/powerpc/lib/memcpy_64.S
@@ -50,10 +50,11 @@ ALT_FTR_SECTION_END_IFCLR(CPU_FTR_VMX_COPY)
At the time of writing the only CPU that has this combination of bits
set is Power6. */
test_feature = (SELFTEST_CASE == 1)
+ beq .ldst_aligned
BEGIN_FTR_SECTION
nop
FTR_SECTION_ELSE
- bne .Ldst_unaligned
+ b .Ldst_unaligned
ALT_FTR_SECTION_END(CPU_FTR_UNALIGNED_LD_STD | CPU_FTR_CP_USE_DCBTZ, \
CPU_FTR_UNALIGNED_LD_STD)
.Ldst_aligned:
--
2.30.2
^ permalink raw reply related
* [powerpc:next] BUILD REGRESSION 14cc509e7b686ce5db7175d0fb084cacae046d96
From: kernel test robot @ 2022-02-11 2:30 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
branch HEAD: 14cc509e7b686ce5db7175d0fb084cacae046d96 selftests/powerpc/copyloops: Add memmove_64 test
Error/Warning reports:
https://lore.kernel.org/lkml/202202110717.hZrWu55Z-lkp@intel.com
Error/Warning in current branch:
(.text+0x18): undefined reference to `._mcount'
compat_audit.c:(.text+0x14): undefined reference to `._mcount'
core.c:(.text+0x24): undefined reference to `._mcount'
fault.c:(.text+0x5c): undefined reference to `._mcount'
i2c-pasemi-platform.c:(.init.text+0x14): undefined reference to `._mcount'
i2c-pasemi-platform.c:(.text+0xc): undefined reference to `._mcount'
i2c-pca-platform.c:(.text+0x34): undefined reference to `._mcount'
main.c:(.text+0x16c): undefined reference to `._mcount'
powerpc64-linux-ld: arch/powerpc/kernel/trace/ftrace.o:(.toc+0x0): undefined reference to `_mcount'
powerpc64-linux-ld: arch/powerpc/kernel/trace/ftrace.o:(.toc+0x10): undefined reference to `ftrace_tramp_init'
powerpc64-linux-ld: arch/powerpc/kernel/trace/ftrace.o:(.toc+0x8): undefined reference to `ftrace_tramp_text'
powerpc64-linux-ld: kernel/trace/ftrace.o:(.toc+0x0): undefined reference to `_mcount'
Error/Warning ids grouped by kconfigs:
gcc_recent_errors
`-- powerpc64-randconfig-r012-20220210
|-- (.text):undefined-reference-to-_mcount
|-- compat_audit.c:(.text):undefined-reference-to-_mcount
|-- core.c:(.text):undefined-reference-to-_mcount
|-- fault.c:(.text):undefined-reference-to-_mcount
|-- i2c-pasemi-platform.c:(.init.text):undefined-reference-to-_mcount
|-- i2c-pasemi-platform.c:(.text):undefined-reference-to-_mcount
|-- i2c-pca-platform.c:(.text):undefined-reference-to-_mcount
|-- main.c:(.text):undefined-reference-to-_mcount
|-- powerpc64-linux-ld:arch-powerpc-kernel-trace-ftrace.o:(.toc):undefined-reference-to-_mcount
|-- powerpc64-linux-ld:arch-powerpc-kernel-trace-ftrace.o:(.toc):undefined-reference-to-ftrace_tramp_init
|-- powerpc64-linux-ld:arch-powerpc-kernel-trace-ftrace.o:(.toc):undefined-reference-to-ftrace_tramp_text
`-- powerpc64-linux-ld:kernel-trace-ftrace.o:(.toc):undefined-reference-to-_mcount
elapsed time: 726m
configs tested: 177
configs skipped: 13
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
powerpc randconfig-c003-20220210
i386 randconfig-c001
xtensa virt_defconfig
powerpc64 defconfig
powerpc sequoia_defconfig
arm iop32x_defconfig
h8300 defconfig
sh se7722_defconfig
alpha defconfig
sh ecovec24_defconfig
arm lpc18xx_defconfig
powerpc ppc64_defconfig
arm mini2440_defconfig
arm multi_v4t_defconfig
openrisc simple_smp_defconfig
sh se7206_defconfig
sh hp6xx_defconfig
parisc generic-64bit_defconfig
arm cm_x300_defconfig
sh titan_defconfig
x86_64 alldefconfig
powerpc ppc40x_defconfig
sh sh7757lcr_defconfig
m68k q40_defconfig
powerpc warp_defconfig
s390 defconfig
riscv nommu_k210_defconfig
powerpc mpc834x_itx_defconfig
arm ezx_defconfig
arm cerfcube_defconfig
nios2 alldefconfig
sh urquell_defconfig
arc nsimosci_hs_smp_defconfig
m68k m5249evb_defconfig
powerpc tqm8541_defconfig
arm h3600_defconfig
powerpc eiger_defconfig
arm s3c6400_defconfig
csky alldefconfig
powerpc ep88xc_defconfig
mips allmodconfig
ia64 bigsur_defconfig
sh dreamcast_defconfig
arc nsimosci_hs_defconfig
sh defconfig
m68k m5407c3_defconfig
sh sh7770_generic_defconfig
arm pxa_defconfig
csky defconfig
powerpc klondike_defconfig
arc alldefconfig
um defconfig
s390 debug_defconfig
sh r7785rp_defconfig
arm footbridge_defconfig
alpha allyesconfig
m68k hp300_defconfig
powerpc tqm8555_defconfig
xtensa defconfig
arm jornada720_defconfig
arm sunxi_defconfig
powerpc linkstation_defconfig
sh microdev_defconfig
arc vdk_hs38_smp_defconfig
arm multi_v7_defconfig
sh se7750_defconfig
m68k amiga_defconfig
alpha alldefconfig
powerpc arches_defconfig
powerpc mpc837x_rdb_defconfig
arm randconfig-c002-20220210
arm randconfig-c002-20220209
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
nds32 defconfig
nios2 allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
s390 allmodconfig
parisc allyesconfig
i386 debian-10.3
i386 allyesconfig
i386 defconfig
i386 debian-10.3-kselftests
sparc allyesconfig
sparc defconfig
mips allyesconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
x86_64 randconfig-a006
x86_64 randconfig-a004
x86_64 randconfig-a002
i386 randconfig-a012
i386 randconfig-a014
i386 randconfig-a016
s390 randconfig-r044-20220209
arc randconfig-r043-20220208
arc randconfig-r043-20220209
riscv randconfig-r042-20220210
riscv randconfig-r042-20220209
arc randconfig-r043-20220210
s390 randconfig-r044-20220210
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allmodconfig
x86_64 rhel-8.3-kselftests
um x86_64_defconfig
um i386_defconfig
x86_64 allyesconfig
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-func
x86_64 kexec
clang tested configs:
riscv randconfig-c006-20220209
x86_64 randconfig-c007
powerpc randconfig-c003-20220209
i386 randconfig-c001
mips randconfig-c004-20220209
arm randconfig-c002-20220209
riscv randconfig-c006-20220210
powerpc randconfig-c003-20220210
arm randconfig-c002-20220210
mips randconfig-c004-20220210
powerpc ksi8560_defconfig
powerpc ppc44x_defconfig
mips e55_defconfig
x86_64 allyesconfig
arm ep93xx_defconfig
powerpc gamecube_defconfig
powerpc ge_imp3a_defconfig
arm multi_v5_defconfig
mips rbtx49xx_defconfig
hexagon defconfig
powerpc mpc836x_mds_defconfig
powerpc tqm5200_defconfig
powerpc ebony_defconfig
mips pic32mzda_defconfig
powerpc kilauea_defconfig
powerpc mpc5200_defconfig
powerpc akebono_defconfig
mips ath79_defconfig
arm omap1_defconfig
mips malta_qemu_32r6_defconfig
powerpc tqm8540_defconfig
x86_64 randconfig-a005
x86_64 randconfig-a003
x86_64 randconfig-a001
i386 randconfig-a002
i386 randconfig-a006
i386 randconfig-a004
x86_64 randconfig-a012
x86_64 randconfig-a014
x86_64 randconfig-a016
i386 randconfig-a011
i386 randconfig-a013
i386 randconfig-a015
hexagon randconfig-r045-20220210
hexagon randconfig-r045-20220209
hexagon randconfig-r041-20220210
hexagon randconfig-r041-20220209
hexagon randconfig-r045-20220208
hexagon randconfig-r041-20220208
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: [PATCH 38/49] arch/powerpc: replace cpumask_weight with cpumask_weight_{eq, ...} where appropriate
From: Michael Ellerman @ 2022-02-11 4:10 UTC (permalink / raw)
To: Yury Norov, Yury Norov, Andy Shevchenko, Rasmus Villemoes,
Andrew Morton, Michał Mirosław, Greg Kroah-Hartman,
Peter Zijlstra, David Laight, Joe Perches, Dennis Zhou,
Emil Renner Berthing, Nicholas Piggin, Matti Vaittinen,
Alexey Klimov, linux-kernel, Benjamin Herrenschmidt,
Paul Mackerras, Srikar Dronamraju, Gautham R. Shenoy,
Valentin Schneider, Parth Shah, Cédric Le Goater,
Hari Bathini, Rob Herring, Laurent Dufour, Petr Mladek,
John Ogness, Sudeep Holla, Christophe Leroy, Naveen N. Rao,
Xiongwei Song, Arnd Bergmann, linuxppc-dev
In-Reply-To: <20220210224933.379149-39-yury.norov@gmail.com>
Yury Norov <yury.norov@gmail.com> writes:
> PowerPC code uses cpumask_weight() to compare the weight of cpumask with
> a given number. We can do it more efficiently with cpumask_weight_{eq, ...}
> because conditional cpumask_weight may stop traversing the cpumask earlier,
> as soon as condition is (or can't be) met.
>
> Signed-off-by: Yury Norov <yury.norov@gmail.com>
> ---
> arch/powerpc/kernel/smp.c | 2 +-
> arch/powerpc/kernel/watchdog.c | 2 +-
> arch/powerpc/xmon/xmon.c | 4 ++--
> 3 files changed, 4 insertions(+), 4 deletions(-)
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
cheers
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox