* [PATCH 1/2] powerpc/64: Make stack tracing work during very early boot
From: Michael Ellerman @ 2021-02-02 13:02 UTC (permalink / raw)
To: linuxppc-dev
If we try to stack trace very early during boot, either due to a
WARN/BUG or manual dump_stack(), we will oops in
valid_emergency_stack() when we try to dereference the paca_ptrs
array.
The fix is simple, we just return false if paca_ptrs isn't allocated
yet. The stack pointer definitely isn't part of any emergency stack
because we haven't allocated any yet.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/kernel/process.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 8520ed5ae144..e296440e9d16 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -2047,6 +2047,9 @@ static inline int valid_emergency_stack(unsigned long sp, struct task_struct *p,
unsigned long stack_page;
unsigned long cpu = task_cpu(p);
+ if (!paca_ptrs)
+ return 0;
+
stack_page = (unsigned long)paca_ptrs[cpu]->emergency_sp - THREAD_SIZE;
if (sp >= stack_page && sp <= stack_page + THREAD_SIZE - nbytes)
return 1;
--
2.25.1
^ permalink raw reply related
* [PATCH 2/2] powerpc/64s: Handle program checks in wrong endian during early boot
From: Michael Ellerman @ 2021-02-02 13:02 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20210202130207.1303975-1-mpe@ellerman.id.au>
There's a short window during boot where although the kernel is
running little endian, any exceptions will cause the CPU to switch
back to big endian. This situation persists until we call
configure_exceptions(), which calls either the hypervisor or OPAL to
configure the CPU so that exceptions will be taken in little
endian (via HID0[HILE]).
We don't intend to take exceptions during early boot, but one way we
sometimes do is via a WARN/BUG etc. Those all boil down to a trap
instruction, which will cause a program check exception.
The first instruction of the program check handler is an mtsprg, which
when executed in the wrong endian is an lhzu with a ~3GB displacement
from r3. The content of r3 is random, so that becomes a load from some
random location, and depending on the system (installed RAM etc.) can
easily lead to a checkstop, or an infinitely recursive page fault.
That prevents whatever the WARN/BUG was complaining about being
printed to the console, and the user just sees a dead system.
We can fix it by having a trampoline at the beginning of the program
check handler that detects we are in the wrong endian, and flips us
back to the correct endian.
We can't flip MSR[LE] using mtmsr (alas), so we have to use rfid. That
requires backing up SRR0/1 as well as a GPR. To do that we use
SPRG0/2/3 (SPRG1 is already used for the paca). SPRG3 is user
readable, but this trampoline is only active very early in boot, and
SPRG3 will be reinitialised in vdso_getcpu_init() before userspace
starts.
With this trampoline in place we can survive a WARN early in boot and
print a stack trace, which is eventually printed to the console once
the console is up, eg:
[83565.758545] kexec_core: Starting new kernel
[ 0.000000] ------------[ cut here ]------------
[ 0.000000] static_key_enable_cpuslocked(): static key '0xc000000000ea6160' used before call to jump_label_init()
[ 0.000000] WARNING: CPU: 0 PID: 0 at kernel/jump_label.c:166 static_key_enable_cpuslocked+0xfc/0x120
[ 0.000000] Modules linked in:
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.10.0-gcc-8.2.0-dirty #618
[ 0.000000] NIP: c0000000002fd46c LR: c0000000002fd468 CTR: c000000000170660
[ 0.000000] REGS: c000000001227940 TRAP: 0700 Not tainted (5.10.0-gcc-8.2.0-dirty)
[ 0.000000] MSR: 9000000002823003 <SF,HV,VEC,VSX,FP,ME,RI,LE> CR: 24882422 XER: 20040000
[ 0.000000] CFAR: 0000000000000730 IRQMASK: 1
[ 0.000000] GPR00: c0000000002fd468 c000000001227bd0 c000000001228300 0000000000000065
[ 0.000000] GPR04: 0000000000000001 0000000000000065 c0000000010cf970 000000000000000d
[ 0.000000] GPR08: 0000000000000000 0000000000000000 0000000000000000 c00000000122763f
[ 0.000000] GPR12: 0000000000002000 c000000000f8a980 0000000000000000 0000000000000000
[ 0.000000] GPR16: 0000000000000000 0000000000000000 c000000000f88c8e c000000000f88c9a
[ 0.000000] GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 0.000000] GPR24: 0000000000000000 c000000000dea3a8 0000000000000000 c000000000f35114
[ 0.000000] GPR28: 0000002800000000 c000000000f88c9a c000000000f88c8e c000000000ea6160
[ 0.000000] NIP [c0000000002fd46c] static_key_enable_cpuslocked+0xfc/0x120
[ 0.000000] LR [c0000000002fd468] static_key_enable_cpuslocked+0xf8/0x120
[ 0.000000] Call Trace:
[ 0.000000] [c000000001227bd0] [c0000000002fd468] static_key_enable_cpuslocked+0xf8/0x120 (unreliable)
[ 0.000000] [c000000001227c40] [c0000000002fd4c0] static_key_enable+0x30/0x50
[ 0.000000] [c000000001227c70] [c000000000f6629c] early_page_poison_param+0x58/0x9c
[ 0.000000] [c000000001227cb0] [c000000000f351b8] do_early_param+0xa4/0x10c
[ 0.000000] [c000000001227d30] [c00000000011e020] parse_args+0x270/0x5e0
[ 0.000000] [c000000001227e20] [c000000000f35864] parse_early_options+0x48/0x5c
[ 0.000000] [c000000001227e40] [c000000000f358d0] parse_early_param+0x58/0x84
[ 0.000000] [c000000001227e70] [c000000000f3a368] early_init_devtree+0xc4/0x490
[ 0.000000] [c000000001227f10] [c000000000f3bca0] early_setup+0xc8/0x1c8
[ 0.000000] [c000000001227f90] [000000000000c320] 0xc320
[ 0.000000] Instruction dump:
[ 0.000000] 4bfffddd 7c2004ac 39200001 913f0000 4bffffb8 7c651b78 3c82ffac 3c62ffc0
[ 0.000000] 38841b00 3863f310 4bdf03a5 60000000 <0fe00000> 4bffff38 60000000 60000000
[ 0.000000] random: get_random_bytes called from print_oops_end_marker+0x40/0x80 with crng_init=0
[ 0.000000] ---[ end trace 0000000000000000 ]---
[ 0.000000] dt-cpu-ftrs: setup for ISA 3000
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/kernel/exceptions-64s.S | 45 ++++++++++++++++++++++++++++
1 file changed, 45 insertions(+)
diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
index b3793f982b2b..c51c436d5845 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -1630,6 +1630,51 @@ INT_DEFINE_BEGIN(program_check)
INT_DEFINE_END(program_check)
EXC_REAL_BEGIN(program_check, 0x700, 0x100)
+
+#ifdef CONFIG_CPU_LITTLE_ENDIAN
+ /*
+ * There's a short window during boot where although the kernel is
+ * running little endian, any exceptions will cause the CPU to switch
+ * back to big endian. For example a WARN() boils down to a trap
+ * instruction, which will cause a program check, and we end up here but
+ * with the CPU in big endian mode. The first instruction of the program
+ * check handler (in GEN_INT_ENTRY below) is an mtsprg, which when
+ * executed in the wrong endian is an lhzu with a ~3GB displacement from
+ * r3. The content of r3 is random, so that is a load from some random
+ * location, and depending on the system can easily lead to a checkstop,
+ * or an infinitely recursive page fault.
+ *
+ * So to handle that case we have a trampoline here that can detect we
+ * are in the wrong endian and flip us back to the correct endian. We
+ * can't flip MSR[LE] using mtmsr, so we have to use rfid. That requires
+ * backing up SRR0/1 as well as a GPR. To do that we use SPRG0/2/3, as
+ * SPRG1 is already used for the paca. SPRG3 is user readable, but this
+ * trampoline is only active very early in boot, and SPRG3 will be
+ * reinitialised in vdso_getcpu_init() before userspace starts.
+ */
+BEGIN_FTR_SECTION
+ tdi 0,0,0x48 // Trap never, or in reverse endian: b . + 8
+ b 1f // Skip trampoline if endian is correct
+ .long 0xa643707d // mtsprg 0, r11 Backup r11
+ .long 0xa6027a7d // mfsrr0 r11
+ .long 0xa643727d // mtsprg 2, r11 Backup SRR0 in SPRG2
+ .long 0xa6027b7d // mfsrr1 r11
+ .long 0xa643737d // mtsprg 3, r11 Backup SRR1 in SPRG3
+ .long 0xa600607d // mfmsr r11
+ .long 0x01006b69 // xori r11, r11, 1 Invert MSR[LE]
+ .long 0xa6037b7d // mtsrr1 r11
+ .long 0x34076039 // li r11, 0x734
+ .long 0xa6037a7d // mtsrr0 r11
+ .long 0x2400004c // rfid
+ mfsprg r11, 3
+ mtsrr1 r11 // Restore SRR1
+ mfsprg r11, 2
+ mtsrr0 r11 // Restore SRR0
+ mfsprg r11, 0 // Restore r11
+1:
+END_FTR_SECTION(0, 1) // nop out after boot
+#endif /* CONFIG_CPU_LITTLE_ENDIAN */
+
GEN_INT_ENTRY program_check, virt=0
EXC_REAL_END(program_check, 0x700, 0x100)
EXC_VIRT_BEGIN(program_check, 0x4700, 0x100)
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v12 14/14] powerpc/64s/radix: Enable huge vmalloc mappings
From: kernel test robot @ 2021-02-02 13:48 UTC (permalink / raw)
To: Nicholas Piggin, linux-mm, Andrew Morton
Cc: linux-arch, kbuild-all, linux-kernel, Nicholas Piggin,
Christoph Hellwig, Linux Memory Management List, Jonathan Cameron,
linuxppc-dev
In-Reply-To: <20210202110515.3575274-15-npiggin@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3280 bytes --]
Hi Nicholas,
I love your patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on arm64/for-next/core v5.11-rc6]
[cannot apply to hnaz-linux-mm/master next-20210125]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Nicholas-Piggin/huge-vmalloc-mappings/20210202-190833
base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc-mpc834x_mds_defconfig (attached as .config)
compiler: powerpc-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/0day-ci/linux/commit/ba7c3aca8bdba641f1cc3cd3da5c19da2b5f721a
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Nicholas-Piggin/huge-vmalloc-mappings/20210202-190833
git checkout ba7c3aca8bdba641f1cc3cd3da5c19da2b5f721a
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=powerpc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
In file included from arch/powerpc/include/asm/book3s/pgtable.h:8,
from arch/powerpc/include/asm/pgtable.h:18,
from include/linux/pgtable.h:6,
from arch/powerpc/include/asm/kup.h:50,
from arch/powerpc/include/asm/uaccess.h:9,
from include/linux/uaccess.h:11,
from arch/powerpc/kernel/module.c:13:
arch/powerpc/kernel/module.c: In function 'module_alloc':
>> arch/powerpc/include/asm/book3s/32/pgtable.h:189:32: error: 'high_memory' undeclared (first use in this function)
189 | #define VMALLOC_START ((((long)high_memory + VMALLOC_OFFSET) & ~(VMALLOC_OFFSET-1)))
| ^~~~~~~~~~~
arch/powerpc/kernel/module.c:92:24: note: in expansion of macro 'VMALLOC_START'
92 | unsigned long start = VMALLOC_START;
| ^~~~~~~~~~~~~
arch/powerpc/include/asm/book3s/32/pgtable.h:189:32: note: each undeclared identifier is reported only once for each function it appears in
189 | #define VMALLOC_START ((((long)high_memory + VMALLOC_OFFSET) & ~(VMALLOC_OFFSET-1)))
| ^~~~~~~~~~~
arch/powerpc/kernel/module.c:92:24: note: in expansion of macro 'VMALLOC_START'
92 | unsigned long start = VMALLOC_START;
| ^~~~~~~~~~~~~
vim +/high_memory +189 arch/powerpc/include/asm/book3s/32/pgtable.h
63b2bc619565ef Christophe Leroy 2019-02-21 188
3dfcb315d81e66 Aneesh Kumar K.V 2015-12-01 @189 #define VMALLOC_START ((((long)high_memory + VMALLOC_OFFSET) & ~(VMALLOC_OFFSET-1)))
3d4247fcc938d0 Christophe Leroy 2020-01-14 190
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 15936 bytes --]
^ permalink raw reply
* Re: [PATCH 06/13] kallsyms: only build {, module_}kallsyms_on_each_symbol when required
From: Miroslav Benes @ 2021-02-02 14:03 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Petr Mladek, Jiri Kosina, Andrew Donnellan, linux-kbuild,
David Airlie, Masahiro Yamada, Josh Poimboeuf, Maarten Lankhorst,
linux-kernel, Maxime Ripard, live-patching, Michal Marek,
Joe Lawrence, dri-devel, Thomas Zimmermann, Jessica Yu,
Frederic Barrat, Daniel Vetter, linuxppc-dev
In-Reply-To: <20210202121334.1361503-7-hch@lst.de>
On Tue, 2 Feb 2021, Christoph Hellwig wrote:
> kallsyms_on_each_symbol and module_kallsyms_on_each_symbol are only used
> by the livepatching code, so don't build them if livepatching is not
> enabled.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Miroslav Benes <mbenes@suse.cz>
M
^ permalink raw reply
* Re: [PATCH 07/13] module: mark module_mutex static
From: Miroslav Benes @ 2021-02-02 14:04 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Petr Mladek, Jiri Kosina, Andrew Donnellan, linux-kbuild,
David Airlie, Masahiro Yamada, Josh Poimboeuf, Maarten Lankhorst,
linux-kernel, Maxime Ripard, live-patching, Michal Marek,
Joe Lawrence, dri-devel, Thomas Zimmermann, Jessica Yu,
Frederic Barrat, Daniel Vetter, linuxppc-dev
In-Reply-To: <20210202121334.1361503-8-hch@lst.de>
On Tue, 2 Feb 2021, Christoph Hellwig wrote:
> Except for two lockdep asserts module_mutex is only used in module.c.
> Remove the two asserts given that the functions they are in are not
> exported and just called from the module code, and mark module_mutex
> static.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Miroslav Benes <mbenes@suse.cz>
M
^ permalink raw reply
* Re: [PATCH 08/13] module: remove each_symbol_in_section
From: Miroslav Benes @ 2021-02-02 14:04 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Petr Mladek, Jiri Kosina, Andrew Donnellan, linux-kbuild,
David Airlie, Masahiro Yamada, Josh Poimboeuf, Maarten Lankhorst,
linux-kernel, Maxime Ripard, live-patching, Michal Marek,
Joe Lawrence, dri-devel, Thomas Zimmermann, Jessica Yu,
Frederic Barrat, Daniel Vetter, linuxppc-dev
In-Reply-To: <20210202121334.1361503-9-hch@lst.de>
On Tue, 2 Feb 2021, Christoph Hellwig wrote:
> each_symbol_in_section just contains a trivial loop over its arguments.
> Just open code the loop in the two callers.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Miroslav Benes <mbenes@suse.cz>
M
^ permalink raw reply
* Re: [PATCH 09/13] module: merge each_symbol_section into find_symbol
From: Miroslav Benes @ 2021-02-02 14:04 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Petr Mladek, Jiri Kosina, Andrew Donnellan, linux-kbuild,
David Airlie, Masahiro Yamada, Josh Poimboeuf, Maarten Lankhorst,
linux-kernel, Maxime Ripard, live-patching, Michal Marek,
Joe Lawrence, dri-devel, Thomas Zimmermann, Jessica Yu,
Frederic Barrat, Daniel Vetter, linuxppc-dev
In-Reply-To: <20210202121334.1361503-10-hch@lst.de>
On Tue, 2 Feb 2021, Christoph Hellwig wrote:
> each_symbol_section is only called by find_symbol, so merge the two
> functions.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Miroslav Benes <mbenes@suse.cz>
M
^ permalink raw reply
* Re: [PATCH 10/13] module: pass struct find_symbol_args to find_symbol
From: Miroslav Benes @ 2021-02-02 14:07 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Petr Mladek, Jiri Kosina, Andrew Donnellan, linux-kbuild,
David Airlie, Masahiro Yamada, Josh Poimboeuf, Maarten Lankhorst,
linux-kernel, Maxime Ripard, live-patching, Michal Marek,
Joe Lawrence, dri-devel, Thomas Zimmermann, Jessica Yu,
Frederic Barrat, Daniel Vetter, linuxppc-dev
In-Reply-To: <20210202121334.1361503-11-hch@lst.de>
> void *__symbol_get(const char *symbol)
> {
> - struct module *owner;
> - const struct kernel_symbol *sym;
> + struct find_symbol_arg fsa = {
> + .name = symbol,
> + .gplok = true,
> + .warn = true,
> + };
>
> preempt_disable();
> - sym = find_symbol(symbol, &owner, NULL, NULL, true, true);
> - if (sym && strong_try_module_get(owner))
> - sym = NULL;
> + if (!find_symbol(&fsa) || !strong_try_module_get(fsa.owner)) {
I think this should be in fact
if (!find_symbol(&fsa) || strong_try_module_get(fsa.owner)) {
to get the logic right (note the missing !). We want to return NULL if
strong_try_module_get() does not succeed for a found symbol.
> + preempt_enable();
> + return NULL;
> + }
> preempt_enable();
> -
> - return sym ? (void *)kernel_symbol_value(sym) : NULL;
> + return (void *)kernel_symbol_value(fsa.sym);
> }
> EXPORT_SYMBOL_GPL(__symbol_get);
Miroslav
^ permalink raw reply
* Re: [PATCH 11/13] module: move struct symsearch to module.c
From: Miroslav Benes @ 2021-02-02 14:10 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Petr Mladek, Jiri Kosina, Andrew Donnellan, linux-kbuild,
David Airlie, Masahiro Yamada, Josh Poimboeuf, Maarten Lankhorst,
linux-kernel, Maxime Ripard, live-patching, Michal Marek,
Joe Lawrence, dri-devel, Thomas Zimmermann, Jessica Yu,
Frederic Barrat, Daniel Vetter, linuxppc-dev
In-Reply-To: <20210202121334.1361503-12-hch@lst.de>
On Tue, 2 Feb 2021, Christoph Hellwig wrote:
> struct symsearch is only used inside of module.h, so move the definition
> out of module.h.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Miroslav Benes <mbenes@suse.cz>
M
^ permalink raw reply
* Re: [PATCH 12/13] module: remove EXPORT_SYMBOL_GPL_FUTURE
From: Miroslav Benes @ 2021-02-02 14:12 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Petr Mladek, Jiri Kosina, Andrew Donnellan, linux-kbuild,
David Airlie, Masahiro Yamada, Josh Poimboeuf, Maarten Lankhorst,
linux-kernel, Maxime Ripard, live-patching, Michal Marek,
Joe Lawrence, dri-devel, Thomas Zimmermann, Jessica Yu,
Frederic Barrat, Daniel Vetter, linuxppc-dev
In-Reply-To: <20210202121334.1361503-13-hch@lst.de>
On Tue, 2 Feb 2021, Christoph Hellwig wrote:
> As far as I can tell this has never been used at all, and certainly
> not any time recently.
Right, I've always wondered about this one.
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Miroslav Benes <mbenes@suse.cz>
M
^ permalink raw reply
* Re: [PATCH 13/13] module: remove EXPORT_UNUSED_SYMBOL*
From: Miroslav Benes @ 2021-02-02 14:21 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Petr Mladek, Jiri Kosina, Andrew Donnellan, linux-kbuild,
David Airlie, Masahiro Yamada, Josh Poimboeuf, Maarten Lankhorst,
linux-kernel, Maxime Ripard, live-patching, Michal Marek,
Joe Lawrence, dri-devel, Thomas Zimmermann, Jessica Yu,
Frederic Barrat, Daniel Vetter, linuxppc-dev
In-Reply-To: <20210202121334.1361503-14-hch@lst.de>
On Tue, 2 Feb 2021, Christoph Hellwig wrote:
> EXPORT_UNUSED_SYMBOL* is not actually used anywhere. Remove the
> unused functionality as we generally just remove unused code anyway.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Miroslav Benes <mbenes@suse.cz>
M
^ permalink raw reply
* Re: [PATCH] powerpc/64/signal: Fix regression in __kernel_sigtramp_rt64 semantics
From: Raoni Fassina Firmino @ 2021-02-02 14:30 UTC (permalink / raw)
To: Nicholas Piggin; +Cc: linuxppc-dev
In-Reply-To: <1612251472.a7pzsfoixm.astroid@bobo.none>
On Tue, Feb 02, 2021 at 05:41:35PM +1000, Nicholas Piggin wrote:
> Are you planning to update glibc to cope with this as well? Any idea
> about musl? If so, including version numbers would be good (not that
> it's really a problem to carry this patch around).
For glibc from the beginning I planned to send a patch as well and
fortunately it got in[1] in time for yesterday's 2.33 release. That
patch is meant to address kernels 5.9 and 5.10 but is also compatible
with older kernels and with this patch. So everyone should be compatible
with everyone else :-) (except unpatched kernels 5.9 and 5.10 with
unpatched glibcs prior to 2.33)
I don't know about musl, I took a look and maybe wrong here but didn't
find any backtrace() implementation and it seems that it uses its own
return code for the trampoline, but I am not sure.
Rich mentioned[2] that he didn't see how it would break musl and was
waiting for feedback from ppc users to be sure.
Thanks for the review :-)
o/
Raoni
[1] https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=5ee506ed35a2c9184bcb1fb5e79b6cceb9bb0dd1
[2] https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-January/223198.html
^ permalink raw reply
* Re: module loader dead code removal and cleanups v3
From: Jessica Yu @ 2021-02-02 14:37 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Petr Mladek, Joe Lawrence, Andrew Donnellan, linux-kbuild,
David Airlie, Masahiro Yamada, Jiri Kosina, Maarten Lankhorst,
linux-kernel, Maxime Ripard, live-patching, Michal Marek,
dri-devel, Thomas Zimmermann, Josh Poimboeuf, Frederic Barrat,
Daniel Vetter, Miroslav Benes, linuxppc-dev
In-Reply-To: <20210202121334.1361503-1-hch@lst.de>
+++ Christoph Hellwig [02/02/21 13:13 +0100]:
>Hi all,
>
>this series removes support for long term unused export types and
>cleans up various loose ends in the module loader.
>
>Changes since v2:
> - clean up klp_find_object_symbol a bit
> - remove the now unused module_assert_mutex helper
>
>Changes since v1:
> - move struct symsearch to module.c
> - rework drm to not call find_module at all
> - allow RCU-sched locking for find_module
> - keep find_module as a public API instead of module_loaded
> - update a few comments and commit logs
Thanks Christoph for cleaning up all that aged cruft, and thanks everyone
for the reviews.
I was curious about EXPORT_SYMBOL_GPL_FUTURE and EXPORT_UNUSED_SYMBOL
variants, and found that most of that stuff was introduced between
2006 - 2008. All the of the unused symbols were removed and gpl future
symbols were converted to gpl quite a long time ago, and I don't
believe these export types have been used ever since. So I
think it's safe to retire those export types now.
The patchset looks good so far. After Miroslav's comments are
addressed, I'll wait an extra day or two in case there are more
comments before queueing them onto modules-next. I can take the first
two patches as well provided the acks are there (I think patch 2 is
missing Daniel Vetter's ack from v1 of the series, but I'll add that
back in).
Thanks,
Jessica
^ permalink raw reply
* Re: [RFC PATCH 3/6] mm/mremap: Use pmd/pud_poplulate to update page table entries
From: Aneesh Kumar K.V @ 2021-02-02 14:50 UTC (permalink / raw)
To: Peter Zijlstra; +Cc: linux-mm, kaleshsingh, joel, akpm, linuxppc-dev
In-Reply-To: <YBkttA/rS/1ZHY8a@hirez.programming.kicks-ass.net>
On 2/2/21 4:17 PM, Peter Zijlstra wrote:
> On Tue, Feb 02, 2021 at 02:41:13PM +0530, Aneesh Kumar K.V wrote:
>> pmd/pud_populate is the right interface to be used to set the respective
>> page table entries. Some architectures do assume that set_pmd/pud_at
>> can only be used to set a hugepage PTE. Since we are not setting up a hugepage
>> PTE here, use the pmd/pud_populate interface.
>
> Since you did the audit, it might be nice to record which architectures
> that are. Also, how much work to fix them?
>
I didn't audit them completely primarily because I don't follow the page
table format of other archs. But I guess arm64, s390 appears to make
that assumption.
Moreover set_pmd_at was added as part of THP patch series.
BTW why should we fix those architectures ? isn't pmd_populate the right
interface for updating pmd entries other than hugepage pte ?
-aneesh
^ permalink raw reply
* Re: [RFC PATCH 1/6] selftest/mremap_test: Update the test to handle pagesize other than 4K
From: Aneesh Kumar K.V @ 2021-02-02 14:51 UTC (permalink / raw)
To: Li Xinhai, linux-mm, akpm; +Cc: peterz, linuxppc-dev, joel, kaleshsingh
In-Reply-To: <19298b0c-2db5-3755-722d-74baeb35f1ef@126.com>
On 2/2/21 6:59 PM, Li Xinhai wrote:
> what is the overall purpose of this patch set? maybe need a cover
> letter?
>
The goal of the patch series was to enable MOVE_PMD/PUD on ppc64. But
the series itself achieves that by fixing the existing code rather than
adding changes to arch/ppc64. With that we could consider the series as
a bug fix series.
-aneesh
^ permalink raw reply
* [PATCH] powerpc/pkeys: Remove unused code
From: Sandipan Das @ 2021-02-02 15:00 UTC (permalink / raw)
To: mpe; +Cc: aneesh.kumar, linuxppc-dev, linuxram
This removes arch_supports_pkeys(), arch_usable_pkeys() and
thread_pkey_regs_*() which are remnants from the following:
commit 06bb53b33804 ("powerpc: store and restore the pkey state across context switches")
commit 2cd4bd192ee9 ("powerpc/pkeys: Fix handling of pkey state across fork()")
commit cf43d3b26452 ("powerpc: Enable pkey subsystem")
arch_supports_pkeys() and arch_usable_pkeys() were unused
since their introduction while thread_pkey_regs_*() became
unused after the introduction of the following:
commit d5fa30e6993f ("powerpc/book3s64/pkeys: Reset userspace AMR correctly on exec")
commit 48a8ab4eeb82 ("powerpc/book3s64/pkeys: Don't update SPRN_AMR when in kernel mode")
Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
---
arch/powerpc/include/asm/mmu_context.h | 3 ---
arch/powerpc/include/asm/pkeys.h | 6 ------
2 files changed, 9 deletions(-)
diff --git a/arch/powerpc/include/asm/mmu_context.h b/arch/powerpc/include/asm/mmu_context.h
index d5821834dba9..652ce85f9410 100644
--- a/arch/powerpc/include/asm/mmu_context.h
+++ b/arch/powerpc/include/asm/mmu_context.h
@@ -282,9 +282,6 @@ static inline bool arch_vma_access_permitted(struct vm_area_struct *vma,
}
#define pkey_mm_init(mm)
-#define thread_pkey_regs_save(thread)
-#define thread_pkey_regs_restore(new_thread, old_thread)
-#define thread_pkey_regs_init(thread)
#define arch_dup_pkeys(oldmm, mm)
static inline u64 pte_to_hpte_pkey_bits(u64 pteflags, unsigned long flags)
diff --git a/arch/powerpc/include/asm/pkeys.h b/arch/powerpc/include/asm/pkeys.h
index a7951049e129..59a2c7dbc78f 100644
--- a/arch/powerpc/include/asm/pkeys.h
+++ b/arch/powerpc/include/asm/pkeys.h
@@ -169,10 +169,4 @@ static inline bool arch_pkeys_enabled(void)
}
extern void pkey_mm_init(struct mm_struct *mm);
-extern bool arch_supports_pkeys(int cap);
-extern unsigned int arch_usable_pkeys(void);
-extern void thread_pkey_regs_save(struct thread_struct *thread);
-extern void thread_pkey_regs_restore(struct thread_struct *new_thread,
- struct thread_struct *old_thread);
-extern void thread_pkey_regs_init(struct thread_struct *thread);
#endif /*_ASM_POWERPC_KEYS_H */
--
2.25.1
^ permalink raw reply related
* Re: module loader dead code removal and cleanups v3
From: Christoph Hellwig @ 2021-02-02 15:23 UTC (permalink / raw)
To: Jessica Yu
Cc: Petr Mladek, Joe Lawrence, Andrew Donnellan, linux-kbuild,
David Airlie, Masahiro Yamada, Jiri Kosina, Maarten Lankhorst,
linux-kernel, Maxime Ripard, live-patching, Michal Marek,
dri-devel, Thomas Zimmermann, Josh Poimboeuf, Frederic Barrat,
Daniel Vetter, Miroslav Benes, linuxppc-dev, Christoph Hellwig
In-Reply-To: <YBljkDgMFcqKcH8H@gunter>
On Tue, Feb 02, 2021 at 03:37:04PM +0100, Jessica Yu wrote:
> The patchset looks good so far. After Miroslav's comments are
> addressed, I'll wait an extra day or two in case there are more
> comments before queueing them onto modules-next. I can take the first
> two patches as well provided the acks are there (I think patch 2 is
> missing Daniel Vetter's ack from v1 of the series, but I'll add that
> back in).
I did remove the find_module entirely compared to v1, so I'd prefer
another explicit ACK for the new version.
^ permalink raw reply
* Re: [PATCH 10/13] module: pass struct find_symbol_args to find_symbol
From: Christoph Hellwig @ 2021-02-02 15:41 UTC (permalink / raw)
To: Miroslav Benes
Cc: Petr Mladek, Jiri Kosina, Andrew Donnellan, linux-kbuild,
David Airlie, Masahiro Yamada, Josh Poimboeuf, Maarten Lankhorst,
linux-kernel, Maxime Ripard, live-patching, Michal Marek,
Joe Lawrence, dri-devel, Thomas Zimmermann, Jessica Yu,
Frederic Barrat, Daniel Vetter, linuxppc-dev, Christoph Hellwig
In-Reply-To: <alpine.LSU.2.21.2102021504550.570@pobox.suse.cz>
On Tue, Feb 02, 2021 at 03:07:51PM +0100, Miroslav Benes wrote:
> > preempt_disable();
> > - sym = find_symbol(symbol, &owner, NULL, NULL, true, true);
> > - if (sym && strong_try_module_get(owner))
> > - sym = NULL;
> > + if (!find_symbol(&fsa) || !strong_try_module_get(fsa.owner)) {
>
> I think this should be in fact
>
> if (!find_symbol(&fsa) || strong_try_module_get(fsa.owner)) {
>
> to get the logic right (note the missing !). We want to return NULL if
> strong_try_module_get() does not succeed for a found symbol.
Indeed. Fixed for the next version.
^ permalink raw reply
* Re: [PATCH] ASoC: fsl_spdif: Utilize the defined parameter to clear code
From: Mark Brown @ 2021-02-02 17:29 UTC (permalink / raw)
To: perex, tiwai, timur, Tang Bin, Xiubo.Lee, nicoleotsuka, lgirdwood
Cc: alsa-devel, linuxppc-dev, linux-kernel
In-Reply-To: <20210128112714.16324-1-tangbin@cmss.chinamobile.com>
On Thu, 28 Jan 2021 19:27:14 +0800, Tang Bin wrote:
> Utilize the defined parameter 'dev' to make the code cleaner.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/1] ASoC: fsl_spdif: Utilize the defined parameter to clear code
commit: 68be8ed6a4622d4eb6cf7632bc7cb78464c83c78
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: module loader dead code removal and cleanups v3
From: Emil Velikov @ 2021-02-02 17:38 UTC (permalink / raw)
To: Jessica Yu
Cc: Petr Mladek, Joe Lawrence, Andrew Donnellan, linux-kbuild,
David Airlie, Masahiro Yamada, Jiri Kosina,
Linux-Kernel@Vger. Kernel. Org, ML dri-devel, Michal Marek,
Thomas Zimmermann, Josh Poimboeuf, Frederic Barrat, live-patching,
Miroslav Benes, linuxppc-dev, Christoph Hellwig
In-Reply-To: <YBljkDgMFcqKcH8H@gunter>
Hi Jessica,
On Tue, 2 Feb 2021 at 14:37, Jessica Yu <jeyu@kernel.org> wrote:
>
> +++ Christoph Hellwig [02/02/21 13:13 +0100]:
> >Hi all,
> >
> >this series removes support for long term unused export types and
> >cleans up various loose ends in the module loader.
> >
> >Changes since v2:
> > - clean up klp_find_object_symbol a bit
> > - remove the now unused module_assert_mutex helper
> >
> >Changes since v1:
> > - move struct symsearch to module.c
> > - rework drm to not call find_module at all
> > - allow RCU-sched locking for find_module
> > - keep find_module as a public API instead of module_loaded
> > - update a few comments and commit logs
>
> Thanks Christoph for cleaning up all that aged cruft, and thanks everyone
> for the reviews.
>
> I was curious about EXPORT_SYMBOL_GPL_FUTURE and EXPORT_UNUSED_SYMBOL
> variants, and found that most of that stuff was introduced between
> 2006 - 2008. All the of the unused symbols were removed and gpl future
> symbols were converted to gpl quite a long time ago, and I don't
> believe these export types have been used ever since. So I
> think it's safe to retire those export types now.
>
I believe you're spot on - based on reading through git log and
checking the ML archives.
Shame I didn't get to finish a similar series I had locally. Patches
11-13 match what I have here so:
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
HTH
-Emil
^ permalink raw reply
* Re: [PATCH] arch: powerpc: kernel: Fix the spelling mismach to mismatch in head.44x.S
From: Randy Dunlap @ 2021-02-02 18:10 UTC (permalink / raw)
To: Bhaskar Chowdhury, mpe, benh, paulus, akpm, rppt, linuxppc-dev,
linux-kernel
In-Reply-To: <20210202093746.5198-1-unixbhaskar@gmail.com>
On 2/2/21 1:37 AM, Bhaskar Chowdhury wrote:
>
> s/mismach/mismatch/
>
> Signed-off-by: Bhaskar Chowdhury <unixbhaskar@gmail.com>
> ---
> arch/powerpc/kernel/head_44x.S | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Acked-by: Randy Dunlap <rdunlap@infradead.org>
thanks.
--
~Randy
^ permalink raw reply
* Re: [PATCH v12 06/14] mm: HUGE_VMAP arch support cleanup
From: kernel test robot @ 2021-02-02 18:21 UTC (permalink / raw)
To: Nicholas Piggin, linux-mm, Andrew Morton
Cc: linux-arch, kbuild-all, Linux Memory Management List,
linux-kernel, Nicholas Piggin, Christoph Hellwig,
clang-built-linux, Jonathan Cameron, linuxppc-dev
In-Reply-To: <20210202110515.3575274-7-npiggin@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3335 bytes --]
Hi Nicholas,
I love your patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on arm64/for-next/core v5.11-rc6 next-20210125]
[cannot apply to hnaz-linux-mm/master]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Nicholas-Piggin/huge-vmalloc-mappings/20210202-190833
base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: x86_64-randconfig-a005-20210202 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 275c6af7d7f1ed63a03d05b4484413e447133269)
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
# https://github.com/0day-ci/linux/commit/25ffbe7d58a1f780ae44f140143eaaf6ab93061a
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Nicholas-Piggin/huge-vmalloc-mappings/20210202-190833
git checkout 25ffbe7d58a1f780ae44f140143eaaf6ab93061a
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
>> mm/debug_vm_pgtable.c:221:31: error: too few arguments to function call, single argument 'prot' was not specified
if (!arch_vmap_pmd_supported())
~~~~~~~~~~~~~~~~~~~~~~~ ^
arch/x86/include/asm/vmalloc.h:10:6: note: 'arch_vmap_pmd_supported' declared here
bool arch_vmap_pmd_supported(pgprot_t prot);
^
mm/debug_vm_pgtable.c:343:31: error: too few arguments to function call, single argument 'prot' was not specified
if (!arch_vmap_pud_supported())
~~~~~~~~~~~~~~~~~~~~~~~ ^
arch/x86/include/asm/vmalloc.h:9:6: note: 'arch_vmap_pud_supported' declared here
bool arch_vmap_pud_supported(pgprot_t prot);
^
2 errors generated.
vim +/prot +221 mm/debug_vm_pgtable.c
215
216 #ifdef CONFIG_HAVE_ARCH_HUGE_VMAP
217 static void __init pmd_huge_tests(pmd_t *pmdp, unsigned long pfn, pgprot_t prot)
218 {
219 pmd_t pmd;
220
> 221 if (!arch_vmap_pmd_supported())
222 return;
223
224 pr_debug("Validating PMD huge\n");
225 /*
226 * X86 defined pmd_set_huge() verifies that the given
227 * PMD is not a populated non-leaf entry.
228 */
229 WRITE_ONCE(*pmdp, __pmd(0));
230 WARN_ON(!pmd_set_huge(pmdp, __pfn_to_phys(pfn), prot));
231 WARN_ON(!pmd_clear_huge(pmdp));
232 pmd = READ_ONCE(*pmdp);
233 WARN_ON(!pmd_none(pmd));
234 }
235 #else /* CONFIG_HAVE_ARCH_HUGE_VMAP */
236 static void __init pmd_huge_tests(pmd_t *pmdp, unsigned long pfn, pgprot_t prot) { }
237 #endif /* CONFIG_HAVE_ARCH_HUGE_VMAP */
238
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 32639 bytes --]
^ permalink raw reply
* Re: [PATCH v4 11/23] powerpc/syscall: Rename syscall_64.c into syscall.c
From: Segher Boessenkool @ 2021-02-02 20:10 UTC (permalink / raw)
To: Nicholas Piggin
Cc: linux-kernel@vger.kernel.org, David Laight, Paul Mackerras,
msuchanek@suse.de, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1612247170.ea0f766ml4.astroid@bobo.none>
On Tue, Feb 02, 2021 at 04:38:31PM +1000, Nicholas Piggin wrote:
> > So to avoid confusion, I'll rename it. But I think "interrupt" is maybe not the right name. An
> > interrupt most of the time refers to IRQ.
>
> That depends what you mean by interrupt and IRQ.
In the PowerPC architecture, an exception is an abnormal condition, and
that can often cause an interrupt. What Christophe colloquially calls
an "IRQ" here is called an external exception c.q. external interrupt.
> But if you say irq it's more likely to mean
> a device interrupt, and "interrupt" usually refres to the asynch
> ones.
Power talks about "instruction-caused interrupts", for one aspect of the
difference here; and "precise" / "imprecise" interrupts for another.
> So it's really fine to use the proper arch-specific names for things
> in arch code. I'm trying to slowly change names from exception to
> interrupt.
Thanks :-)
> > For me system call is not an interrupt in the way it
> > doesn't unexpectedly interrupt a program flow. In powerpc manuals it is generally called exceptions,
> > no I'm more inclined to call it exception.c
>
> Actually that's backwards. Powerpc manuals (at least the one I look at)
> calls them all interrupts including system calls, and also the system
> call interrupt is actually the only one that doesn't appear to be
> associated with an exception.
Yeah. You could easily make such an exception, which is set when you
execute a system call instruction, and cleared when the interrupt is
taken, of course; but the architecture doesn't.
> And on the other hand you can deal with exceptions in some cases without
> taking an interrupt at all. For example if you had MSR[EE]=0 you could
> change the decrementer or execute msgclr or change HMER SPR etc to clear
> various exceptions without ever taking the interrupt.
A well-known example is the exception bits in the FPSCR, which do not
cause an interrupt unless the corresponding enable bits are also set.
Segher
^ permalink raw reply
* Re: [PATCH v12 10/14] mm/vmalloc: provide fallback arch huge vmap support functions
From: kernel test robot @ 2021-02-02 20:53 UTC (permalink / raw)
To: Nicholas Piggin, linux-mm, Andrew Morton
Cc: linux-arch, kbuild-all, linux-kernel, Nicholas Piggin,
Christoph Hellwig, Linux Memory Management List, Jonathan Cameron,
linuxppc-dev
In-Reply-To: <20210202110515.3575274-11-npiggin@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3313 bytes --]
Hi Nicholas,
I love your patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on arm64/for-next/core v5.11-rc6 next-20210125]
[cannot apply to hnaz-linux-mm/master]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Nicholas-Piggin/huge-vmalloc-mappings/20210202-190833
base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: arm64-allyesconfig (attached as .config)
compiler: aarch64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/0day-ci/linux/commit/abe869c9c2e3663ea8c59e730eb5ae0d7206d79b
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Nicholas-Piggin/huge-vmalloc-mappings/20210202-190833
git checkout abe869c9c2e3663ea8c59e730eb5ae0d7206d79b
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
In file included from include/linux/vmalloc.h:13,
from include/asm-generic/io.h:911,
from arch/arm64/include/asm/io.h:194,
from include/linux/io.h:13,
from include/linux/irq.h:20,
from include/asm-generic/hardirq.h:17,
from arch/arm64/include/asm/hardirq.h:17,
from include/linux/hardirq.h:10,
from include/linux/highmem.h:10,
from mm/debug_vm_pgtable.c:14:
mm/debug_vm_pgtable.c: In function 'pmd_huge_tests':
>> arch/arm64/include/asm/vmalloc.h:19:33: error: too few arguments to function 'arch_vmap_pmd_supported'
19 | #define arch_vmap_pmd_supported arch_vmap_pmd_supported
| ^~~~~~~~~~~~~~~~~~~~~~~
mm/debug_vm_pgtable.c:221:7: note: in expansion of macro 'arch_vmap_pmd_supported'
221 | if (!arch_vmap_pmd_supported())
| ^~~~~~~~~~~~~~~~~~~~~~~
arch/arm64/include/asm/vmalloc.h:19:33: note: declared here
19 | #define arch_vmap_pmd_supported arch_vmap_pmd_supported
| ^~~~~~~~~~~~~~~~~~~~~~~
arch/arm64/include/asm/vmalloc.h:20:20: note: in expansion of macro 'arch_vmap_pmd_supported'
20 | static inline bool arch_vmap_pmd_supported(pgprot_t prot)
| ^~~~~~~~~~~~~~~~~~~~~~~
vim +/arch_vmap_pmd_supported +19 arch/arm64/include/asm/vmalloc.h
18
> 19 #define arch_vmap_pmd_supported arch_vmap_pmd_supported
20 static inline bool arch_vmap_pmd_supported(pgprot_t prot)
21 {
22 /* See arch_vmap_pud_supported() */
23 return !IS_ENABLED(CONFIG_PTDUMP_DEBUGFS);
24 }
25
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 76464 bytes --]
^ permalink raw reply
* [powerpc:next-test 102/117] arch/powerpc/kernel/tau_6xx.c:103:31: error: this old-style function definition is not preceded by a prototype
From: kernel test robot @ 2021-02-02 22:33 UTC (permalink / raw)
To: Nicholas Piggin; +Cc: clang-built-linux, kbuild-all, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 2725 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test
head: a4d002e384ba1909c1c03799603f00c5909d6097
commit: f779391282ff7a95222000321b41823d86cf9aa1 [102/117] powerpc: convert interrupt handlers to use wrappers
config: powerpc-randconfig-r003-20210202 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 275c6af7d7f1ed63a03d05b4484413e447133269)
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# install powerpc cross compiling tool for clang build
# apt-get install binutils-powerpc-linux-gnu
# https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?id=f779391282ff7a95222000321b41823d86cf9aa1
git remote add powerpc https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
git fetch --no-tags powerpc next-test
git checkout f779391282ff7a95222000321b41823d86cf9aa1
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All error/warnings (new ones prefixed by >>):
>> arch/powerpc/kernel/tau_6xx.c:103:1: warning: no previous prototype for function 'DEFINE_INTERRUPT_HANDLER_ASYNC' [-Wmissing-prototypes]
DEFINE_INTERRUPT_HANDLER_ASYNC(TAUException)
^
arch/powerpc/kernel/tau_6xx.c:103:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
DEFINE_INTERRUPT_HANDLER_ASYNC(TAUException)
^
static
>> arch/powerpc/kernel/tau_6xx.c:103:31: error: this old-style function definition is not preceded by a prototype [-Werror,-Wstrict-prototypes]
DEFINE_INTERRUPT_HANDLER_ASYNC(TAUException)
^
>> arch/powerpc/kernel/tau_6xx.c:113:1: error: non-void function does not return a value [-Werror,-Wreturn-type]
}
^
1 warning and 2 errors generated.
vim +103 arch/powerpc/kernel/tau_6xx.c
96
97 #ifdef CONFIG_TAU_INT
98 /*
99 * TAU interrupts - called when we have a thermal assist unit interrupt
100 * with interrupts disabled
101 */
102
> 103 DEFINE_INTERRUPT_HANDLER_ASYNC(TAUException)
104 {
105 int cpu = smp_processor_id();
106
107 irq_enter();
108 tau[cpu].interrupts++;
109
110 TAUupdate(cpu);
111
112 irq_exit();
> 113 }
114 #endif /* CONFIG_TAU_INT */
115
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 37145 bytes --]
^ 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