Re: [PATCH] parisc/ftrace: add missing CONFIG_DYNAMIC_FTRACE check
On 2/11/24 23:43, Max Kellermann wrote:
Fixes a bug revealed by -Wmissing-prototypes when
CONFIG_FUNCTION_GRAPH_TRACER is enabled but not CONFIG_DYNAMIC_FTRACE:
arch/parisc/kernel/ftrace.c:82:5: error: no previous prototype for
'ftrace_enable_ftrace_graph_caller' [-Werror=missing-prototypes]
82 | int ftrace_enable_ftrace_graph_caller(void)
| ^
arch/parisc/kernel/ftrace.c:88:5: error: no previous prototype for
'ftrace_disable_ftrace_graph_caller' [-Werror=missing-prototypes]
88 | int ftrace_disable_ftrace_graph_caller(void)
| ^~
Signed-off-by: Max Kellermann
applied to parisc git tree.
Thanks!
Helge
---
arch/parisc/kernel/ftrace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/parisc/kernel/ftrace.c b/arch/parisc/kernel/ftrace.c
index d1defb9ede70..621a4b386ae4 100644
--- a/arch/parisc/kernel/ftrace.c
+++ b/arch/parisc/kernel/ftrace.c
@@ -78,7 +78,7 @@ asmlinkage void notrace __hot
ftrace_function_trampoline(unsigned long parent,
#endif
}
-#ifdef CONFIG_FUNCTION_GRAPH_TRACER
+#if defined(CONFIG_DYNAMIC_FTRACE) && defined(CONFIG_FUNCTION_GRAPH_TRACER)
int ftrace_enable_ftrace_graph_caller(void)
{
static_key_enable(_graph_enable.key);
Re: [PATCH] parisc/kprobes: always include asm-generic/kprobes.h
On 2/12/24 00:09, Max Kellermann wrote:
The NOKPROBE_SYMBOL macro (and others) were moved to
asm-generic/kprobes.h in 2017 by commit 7d134b2ce639 ("kprobes: move
kprobe declarations to asm-generic/kprobes.h"), and this new header
was included by asm/kprobes.h unconditionally on all architectures.
When kprobe support was added to parisc in 2017 by commit
8858ac8e9e9b1 ("parisc: Implement kprobes"), that header was only
included when CONFIG_KPROBES was enabled.
This can lead to build failures when NOKPROBE_SYMBOL is used, but
CONFIG_KPROBES is disabled. This mistake however was never actually
noticed because linux/kprobes.h also includes asm-generic/kprobes.h
(though I do not understand why that is, because it also includes
asm/kprobes.h).
To prevent eventual build failures, I suggest to always include
asm-generic/kprobes.h on parisc, just like all the other architectures
do. This way, including asm/kprobes.h suffices, and nobody (outside
of arch/) ever needs to explicitly include asm-generic/kprobes.h.
Signed-off-by: Max Kellermann
applied to parisc git tree.
Thanks!
Helge
---
arch/parisc/include/asm/kprobes.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/parisc/include/asm/kprobes.h
b/arch/parisc/include/asm/kprobes.h
index 0a175ac87698..0f42f5c8e3b6 100644
--- a/arch/parisc/include/asm/kprobes.h
+++ b/arch/parisc/include/asm/kprobes.h
@@ -10,9 +10,10 @@
#ifndef _PARISC_KPROBES_H
#define _PARISC_KPROBES_H
+#include
+
#ifdef CONFIG_KPROBES
-#include
#include
#include
#include
Re: [PATCH 2/4] modules: Ensure 64-bit alignment on __ksymtab_* sections
On 1/22/24 17:10, Luis Chamberlain wrote: On Sat, Dec 30, 2023 at 08:33:24AM +0100, Helge Deller wrote: Your selftest code is based on perf. AFAICS we don't have perf on parisc/hppa, I see! so I can't test your selftest code on that architecture. I assume you tested on x86, where the CPU will transparently take care of unaligned accesses. This is probably why the results are within the noise. But on some platforms the CPU raises an exception on unaligned accesses and jumps into special exception handler assembler code inside the kernel. This is much more expensive than on x86, which is why we track on parisc in /proc/cpuinfo counters on how often this exception handler is called: IRQ: CPU0 CPU1 3: 1332 0 SuperIO ttyS0 7:1270013 0 SuperIO pata_ns87415 64: 320023012 320021431 CPU timer 65: 17080507 20624423 CPU IPI UAH: 10948640 58104 Unaligned access handler traps This "UAH" field could theoretically be used to extend your selftest. Nice! But is it really worth it? The outcome is very much architecture and CPU specific, maybe it's just within the noise as you measured. It's within the noise for x86_64, but given what you suggest for parisc where it is much more expensive, we should see a non-noise delta. Even just time on loading the module should likely result in a considerable delta than on x86_64. You may just need to play a bit with the default values at build time. I don't know if it will be a "considerable" amount of time. IMHO we should always try to natively align structures, and if we see we got it wrong in kernel code, we should fix it. This was all motivated by the first review criteria of these patches as if they were stable worthy or not. Even if we don't consider them stable material, given the test is now written and easily extended to test on parisc with just timing information and UAH I think it would be nice to have this data for a few larger default factor values so we can compare against x86_64 while we're at it. If you don't feel like doing that test that's fine too, we can just ignore that. I can do that test, but I won't have time for that in the next few weeks... I'll still apply the patches Yes, please do! Even if I don't test now, I (or others) will test at a later point. but, I figured I'd ask to collect information while the test was already written and it should now be easy to compare / contrast differences. Ok. Helge
Re: [PATCH 2/4] modules: Ensure 64-bit alignment on __ksymtab_* sections
Hi Luis, On 12/22/23 21:10, Luis Chamberlain wrote: On Fri, Dec 22, 2023 at 01:13:26PM +0100, Helge Deller wrote: On 12/22/23 06:59, Luis Chamberlain wrote: On Wed, Nov 22, 2023 at 11:18:12PM +0100, del...@kernel.org wrote: On 64-bit architectures without CONFIG_HAVE_ARCH_PREL32_RELOCATIONS (e.g. ppc64, ppc64le, parisc, s390x,...) the __KSYM_REF() macro stores 64-bit pointers into the __ksymtab* sections. Make sure that those sections will be correctly aligned at module link time, otherwise unaligned memory accesses may happen at runtime. ... ... So, honestly I don't see a real reason why it shouldn't be applied... Like I said, you Cc'd stable as a fix, I added "Cc: sta...@vger.kernel.org" on the patch itself, so *if* the patch would have been applied by you, it would later end up in stable kernel series too. But I did not CC'ed the stable mailing list directly, so my patch was never sent to that mailing list. as a maintainer it is my job to verify how critical this is and ask for more details about how you found it and evaluate the real impact. Even if it was not a stable fix I tend to ask this for patches, even if they are trivial. ... OK, can you extend the patch below with something like: perf stat --repeat 100 --pre 'modprobe -r b a b c' -- ./tools/testing/selftests/module/find_symbol.sh And test before and after? I ran a simple test as-is and the data I get is within noise, and so I think we need the --repeat 100 thing. Your selftest code is based on perf. AFAICS we don't have perf on parisc/hppa, so I can't test your selftest code on that architecture. I assume you tested on x86, where the CPU will transparently take care of unaligned accesses. This is probably why the results are within the noise. But on some platforms the CPU raises an exception on unaligned accesses and jumps into special exception handler assembler code inside the kernel. This is much more expensive than on x86, which is why we track on parisc in /proc/cpuinfo counters on how often this exception handler is called: IRQ: CPU0 CPU1 3: 1332 0 SuperIO ttyS0 7:1270013 0 SuperIO pata_ns87415 64: 320023012 320021431 CPU timer 65: 17080507 20624423 CPU IPI UAH: 10948640 58104 Unaligned access handler traps This "UAH" field could theoretically be used to extend your selftest. But is it really worth it? The outcome is very much architecture and CPU specific, maybe it's just within the noise as you measured. IMHO we should always try to natively align structures, and if we see we got it wrong in kernel code, we should fix it. My patches just fix those memory sections where we use inline assembly (instead of C) and thus missed to provide the correct alignments. Helge --- before: sudo ./tools/testing/selftests/module/find_symbol.sh Performance counter stats for '/sbin/modprobe test_kallsyms_b': 81,956,206 ns duration_time 81,883,000 ns system_time 210 page-faults 0.081956206 seconds time elapsed 0.0 seconds user 0.081883000 seconds sys Performance counter stats for '/sbin/modprobe test_kallsyms_b': 85,960,863 ns duration_time 84,679,000 ns system_time 212 page-faults 0.085960863 seconds time elapsed 0.0 seconds user 0.084679000 seconds sys Performance counter stats for '/sbin/modprobe test_kallsyms_b': 86,484,868 ns duration_time 86,541,000 ns system_time 213 page-faults 0.086484868 seconds time elapsed 0.0 seconds user 0.086541000 seconds sys --- After your modules alignement fix: sudo ./tools/testing/selftests/module/find_symbol.sh Performance counter stats for '/sbin/modprobe test_kallsyms_b': 83,579,980 ns duration_time 83,530,000 ns system_time 212 page-faults 0.083579980 seconds time elapsed 0.0 seconds user 0.08353 seconds sys Performance counter stats for '/sbin/modprobe test_kallsyms_b': 70,721,786 ns duration_time 69,289,000 ns system_time 211 page-faults 0.070721786 seconds time elapsed 0.0 seconds user 0.069289000 seconds sys Performance counter stats for '/sbin/modprobe test_kallsyms_b': 76,513,219 ns duration_time 76,381,000 ns system_time 214 page-faults 0.076513219 seconds time elapsed 0.0 seconds user 0.076381000 seconds sys After your modules alignement fix: sudo ./tools/testing/selftests/module/find_symbol.sh Perfo
Re: [PATCH 2/4] modules: Ensure 64-bit alignment on __ksymtab_* sections
Hi Luis,
On 12/22/23 06:59, Luis Chamberlain wrote:
On Wed, Nov 22, 2023 at 11:18:12PM +0100, del...@kernel.org wrote:
From: Helge Deller
On 64-bit architectures without CONFIG_HAVE_ARCH_PREL32_RELOCATIONS
(e.g. ppc64, ppc64le, parisc, s390x,...) the __KSYM_REF() macro stores
64-bit pointers into the __ksymtab* sections.
Make sure that those sections will be correctly aligned at module link time,
otherwise unaligned memory accesses may happen at runtime.
The ramifications are not explained there.
What do you mean exactly by this?
You keep sending me patches with this and we keep doing a nose dive
on this. It means I have to do more work.
Sorry about that. Since you are mentioned as maintainer for modules I
thought you are the right contact.
Furthermore, this patch is pretty small and trivial.
And I had the impression that people understand that having unaligned
structures is generally a bad idea as it usually always impacts performance
(although the performance penalty in this case isn't critical at all,
as we are not on hot paths).
So as I had suggested with your patch which I merged in
commit 87c482bdfa79 ("modules: Ensure natural alignment for
.altinstructions and __bug_table sections") please clarify the
impact of not merging this patch. Also last time you noticed the
misalignment due to a faulty exception handler, please mention how
you found this out now.
Sure.
And since this is not your first patch on the exact related subject
I'd appreciate if you can show me perf stat results differences between
having and not having this patch merged. Why? Because we talk about
a performance penalthy, but we are not saying how much, and since this
is an ongoing thing, we might as well have a tool belt with ways to
measure such performance impact to bring clarity and value to this
and future related patches.
The __kcrctab* sections store 32-bit entities, so use ALIGN(4) for those.
I've given some thought about how to test this. Sadly perf kallsysms
just opens the /proc/kallsysms file, but that's fine, we need our own
test.
I think a 3 new simple modules selftest would do it and running perf
stat on it. One module, let us call it module A which constructs its own
name space prefix for its exported symbols and has tons of silly symbols
for arbitrary data, whatever. We then have module B which refers to a
few arbitrary symbols from module A, hopefully spread out linearly, so
if module A had 10,000 symbols, we'd have module A refer to a symbol
ever 1,000 symbols. Finally we want a symbol C which has say, 50,000
symbols all of which will not be used at all by the first two modules,
but the selftest will load module C first, prior to calling modprobe B.
We'll stress test this way two calls which use find_symbol():
1) Upon load of B it will trigger simplify_symbols() to look for the
symbol it uses from the module A with tons of symbols. That's an
indirect way for us to call resolve_symbol_wait() from module A without
having to use symbol_get() which want to remove as exported as it is
just a hack which should go away. Our goal is for us to test
resolve_symbol() which will call find_symbol() and that will eventually
look for the symbol on module A with:
find_exported_symbol_in_section()
That uses bsearch() so a binary search for the symbol and we'd end up
hitting the misalignments here. Binary search will at worst be O(log(n))
and so the only way to aggreviate the search will be to add tons of
symbols to A, and have B use a few of them.
2) When you load B, userspace will at first load A as depmod will inform
userspace A goes before B. Upon B's load towards the end right before
we call module B's init routine we get complete_formation() called on
the module. That will first check for duplicate symbols with the call
to verify_exported_symbols(). That is when we'll force iteration on
module C's insane symbol list.
The selftests just runs
perf stat -e pick-your-poison-for-misalignments
tools/testing/selftests/kmod/ksymtab.sh
Where ksymtab.sh is your new script which calls:
modprobe C
modprobe B
I say pick-your-poison-for-misalignments because I am not sure what is
best here.
Thoughts?
I really appreciate your thoughts here!
But given the triviality of this patch, I personally think you are
proposing a huge academic investment in time and resources with no real benefit.
On which architecture would you suggest to test this?
What would be the effective (really new) outcome?
If the performance penalty is zero or close to zero, will that imply
that such a patch isn't useful?
Please also keep in mind that not everyone gets paid to work on the kernel,
so I have neither the time nor the various architectures to test on.
Then, as Masahiro already mentioned, the real solution is
probably to add ".balign" to the various inline assembler parts.
With this the alignment gets recorded in the sh_addralign field
in the object files, and the linker will correctly lay out the exe
Re: [PATCH 0/4] Section alignment issues?
On 12/20/23 20:40, Luis Chamberlain wrote: On Tue, Dec 19, 2023 at 01:26:49PM -0800, Luis Chamberlain wrote: On Wed, Nov 22, 2023 at 11:18:10PM +0100, del...@kernel.org wrote: From: Helge Deller My questions: - Am I wrong with my analysis? This would typically of course depend on the arch, but whether it helps is what I would like to see with real numbers rather then speculation. Howeer, I don't expect some of these are hot paths except maybe the table lookups. So could you look at some perf stat differences without / with alignment ? Other than bootup live patching would be a good test case. We have selftest for modules, the script in selftests tools/testing/selftests/kmod/kmod.sh is pretty aggressive, but the live patching tests might be better suited. - What does people see on other architectures? - Does it make sense to add a compile- and runtime-check, like the patch below, to the kernel? The chatty aspects really depend on the above results. Aren't there some archs where an unaligned access would actually crash? Why hasn't that happened? I've gone down through memory lane and we have discussed this before. It would seem this misalignment should not affect performance, and this should not be an issue unless you have a buggy exception hanlder. We actually ran into one before. Please refer to merge commit e74acdf55da6649dd30be5b621a93b71cbe7f3f9 Yes, this is the second time I stumbled over this issue. But let's continue discussing in the other mail thread... Helge
Re: [PATCH 3/4] vmlinux.lds.h: Fix alignment for __ksymtab*, __kcrctab_* and .pci_fixup sections
On 12/21/23 14:07, Masahiro Yamada wrote:
On Thu, Nov 23, 2023 at 7:18 AM wrote:
From: Helge Deller
On 64-bit architectures without CONFIG_HAVE_ARCH_PREL32_RELOCATIONS
(e.g. ppc64, ppc64le, parisc, s390x,...) the __KSYM_REF() macro stores
64-bit pointers into the __ksymtab* sections.
Make sure that the start of those sections is 64-bit aligned in the vmlinux
executable, otherwise unaligned memory accesses may happen at runtime.
Are you solving a real problem?
Not any longer.
I faced a problem on parisc when neither #1 and #3 were applied
because of a buggy unalignment exception handler. But this is
not something which I would count a "real generic problem".
1/4 already ensures the proper alignment of __ksymtab*, doesn't it?
Yes, it does.
...
So, my understanding is this patch is unneeded.
Yes, it's not required and I'm fine if we drop it.
But regarding __kcrctab:
@@ -498,6 +501,7 @@
} \
\
/* Kernel symbol table: Normal symbols */ \
+ . = ALIGN(4); \
__kcrctab : AT(ADDR(__kcrctab) - LOAD_OFFSET) { \
__start___kcrctab = .; \
KEEP(*(SORT(___kcrctab+*))) \
I think this patch would be beneficial to get proper alignment:
diff --git a/include/linux/export-internal.h b/include/linux/export-internal.h
index cd253eb51d6c..d445705ac13c 100644
--- a/include/linux/export-internal.h
+++ b/include/linux/export-internal.h
@@ -64,6 +64,7 @@
#define SYMBOL_CRC(sym, crc, sec) \
asm(".section \"___kcrctab" sec "+" #sym "\",\"a\"" "\n" \
+ ".balign 4" "\n" \
"__crc_" #sym ":" "\n" \
".long " #crc "\n" \
".previous" "\n")
Helge
Re: [PATCH 0/4] Section alignment issues?
On 12/21/23 16:42, Masahiro Yamada wrote:
On Thu, Dec 21, 2023 at 10:40 PM Masahiro Yamada wrote:
On Thu, Nov 23, 2023 at 7:18 AM wrote:
From: Helge Deller
While working on the 64-bit parisc kernel, I noticed that the __ksymtab[]
table was not correctly 64-bit aligned in many modules.
The following patches do fix some of those issues in the generic code.
But further investigation shows that multiple sections in the kernel and in
modules are possibly not correctly aligned, and thus may lead to performance
degregations at runtime (small on x86, huge on parisc, sparc and others which
need exception handlers). Sometimes wrong alignments may also be simply hidden
by the linker or kernel module loader which pulls in the sections by luck with
a correct alignment (e.g. because the previous section was aligned already).
An objdump on a x86 module shows e.g.:
./kernel/net/netfilter/nf_log_syslog.ko: file format elf64-x86-64
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 1fdf 0040 2**4
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
1 .init.text00f6 2020 2**4
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
2 .exit.text005c 2120 2**4
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
3 .rodata.str1.8 00dc 2180 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .rodata.str1.1 030a 225c 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
5 .rodata 00b0 2580 2**5
CONTENTS, ALLOC, LOAD, READONLY, DATA
6 .modinfo 019e 2630 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
7 .return_sites 0034 27ce 2**0
CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
8 .call_sites 029c 2802 2**0
CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
In this example I believe the ".return_sites" and ".call_sites" should have
an alignment of at least 32-bit (4 bytes).
On other architectures or modules other sections like ".altinstructions" or
"__ex_table" may show up wrongly instead.
In general I think it would be beneficial to search for wrong alignments at
link time, and maybe at runtime.
The patch at the end of this cover letter
- adds compile time checks to the "modpost" tool, and
- adds a runtime check to the kernel module loader at runtime.
And it will possibly show false positives too (!!!)
I do understand that some of those sections are not performce critical
and thus any alignment is OK.
The modpost patch will emit at compile time such warnings (on x86-64 kernel
build):
WARNING: modpost: vmlinux: section .initcall7.init (type 1, flags 2) has
alignment of 1, expected at least 4.
Maybe you need to add ALIGN() to the modules.lds file (or fix modpost) ?
WARNING: modpost: vmlinux: section .altinstructions (type 1, flags 2) has
alignment of 1, expected at least 2.
WARNING: modpost: vmlinux: section .initcall6.init (type 1, flags 2) has
alignment of 1, expected at least 4.
WARNING: modpost: vmlinux: section .initcallearly.init (type 1, flags 2) has
alignment of 1, expected at least 4.
WARNING: modpost: vmlinux: section .rodata.cst2 (type 1, flags 18) has
alignment of 2, expected at least 64.
WARNING: modpost: vmlinux: section .static_call_tramp_key (type 1, flags 2) has
alignment of 1, expected at least 8.
WARNING: modpost: vmlinux: section .con_initcall.init (type 1, flags 2) has
alignment of 1, expected at least 8.
WARNING: modpost: vmlinux: section __bug_table (type 1, flags 3) has alignment
of 1, expected at least 4.
...
modpost acts on vmlinux.o instead of vmlinux.
vmlinux.o is a relocatable ELF, which is not a real layout
because no linker script has been considered yet at this
point.
vmlinux is an executable ELF, produced by a linker,
with the linker script taken into consideration
to determine the final section/symbol layout.
So, checking this in modpost is meaningless.
I did not check the module checking code, but
modules are also relocatable ELF.
Sorry, I replied too early.
(Actually I replied without reading your modpost code).
Now, I understand what your checker is doing.
I did not test how many false positives are produced,
but it catches several suspicious mis-alignments.
Yes.
However, I am not convinced with this warning.
+ warn("%s: section %s (type %d, flags %lu) has
alignment of %d, expected at least %d.\n"
+"Maybe you
[PATCH 0/4] Section alignment issues?
From: Helge Deller While working on the 64-bit parisc kernel, I noticed that the __ksymtab[] table was not correctly 64-bit aligned in many modules. The following patches do fix some of those issues in the generic code. But further investigation shows that multiple sections in the kernel and in modules are possibly not correctly aligned, and thus may lead to performance degregations at runtime (small on x86, huge on parisc, sparc and others which need exception handlers). Sometimes wrong alignments may also be simply hidden by the linker or kernel module loader which pulls in the sections by luck with a correct alignment (e.g. because the previous section was aligned already). An objdump on a x86 module shows e.g.: ./kernel/net/netfilter/nf_log_syslog.ko: file format elf64-x86-64 Sections: Idx Name Size VMA LMA File off Algn 0 .text 1fdf 0040 2**4 CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE 1 .init.text00f6 2020 2**4 CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE 2 .exit.text005c 2120 2**4 CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE 3 .rodata.str1.8 00dc 2180 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .rodata.str1.1 030a 225c 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 5 .rodata 00b0 2580 2**5 CONTENTS, ALLOC, LOAD, READONLY, DATA 6 .modinfo 019e 2630 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 7 .return_sites 0034 27ce 2**0 CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA 8 .call_sites 029c 2802 2**0 CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA In this example I believe the ".return_sites" and ".call_sites" should have an alignment of at least 32-bit (4 bytes). On other architectures or modules other sections like ".altinstructions" or "__ex_table" may show up wrongly instead. In general I think it would be beneficial to search for wrong alignments at link time, and maybe at runtime. The patch at the end of this cover letter - adds compile time checks to the "modpost" tool, and - adds a runtime check to the kernel module loader at runtime. And it will possibly show false positives too (!!!) I do understand that some of those sections are not performce critical and thus any alignment is OK. The modpost patch will emit at compile time such warnings (on x86-64 kernel build): WARNING: modpost: vmlinux: section .initcall7.init (type 1, flags 2) has alignment of 1, expected at least 4. Maybe you need to add ALIGN() to the modules.lds file (or fix modpost) ? WARNING: modpost: vmlinux: section .altinstructions (type 1, flags 2) has alignment of 1, expected at least 2. WARNING: modpost: vmlinux: section .initcall6.init (type 1, flags 2) has alignment of 1, expected at least 4. WARNING: modpost: vmlinux: section .initcallearly.init (type 1, flags 2) has alignment of 1, expected at least 4. WARNING: modpost: vmlinux: section .rodata.cst2 (type 1, flags 18) has alignment of 2, expected at least 64. WARNING: modpost: vmlinux: section .static_call_tramp_key (type 1, flags 2) has alignment of 1, expected at least 8. WARNING: modpost: vmlinux: section .con_initcall.init (type 1, flags 2) has alignment of 1, expected at least 8. WARNING: modpost: vmlinux: section __bug_table (type 1, flags 3) has alignment of 1, expected at least 4. ... while the kernel module loader may show at runtime: ** WARNING **: module: efivarfs, dest=0xc02d08d2, section=.retpoline_sites possibly not correctly aligned. ** WARNING **: module: efivarfs, dest=0xc02d0bae, section=.ibt_endbr_seal possibly not correctly aligned. ** WARNING **: module: efivarfs, dest=0xc02d0be6, section=.orc_unwind possibly not correctly aligned. ** WARNING **: module: efivarfs, dest=0xc02d12a6, section=.orc_unwind_ip possibly not correctly aligned. ** WARNING **: module: efivarfs, dest=0xc02d178c, section=.note.Linux possibly not correctly aligned. ** WARNING **: module: efivarfs, dest=0xc02d17bc, section=.orc_header possibly not correctly aligned. ** WARNING **: module: xt_addrtype, dest=0xc01ef18a, size=0x0020, section=.return_sites My questions: - Am I wrong with my analysis? - What does people see on other architectures? - Does it make sense to add a compile- and runtime-check, like the patch below, to the kernel? Helge --- From: Helge Deller Subject: [
[PATCH 3/4] vmlinux.lds.h: Fix alignment for __ksymtab*, __kcrctab_* and .pci_fixup sections
From: Helge Deller
On 64-bit architectures without CONFIG_HAVE_ARCH_PREL32_RELOCATIONS
(e.g. ppc64, ppc64le, parisc, s390x,...) the __KSYM_REF() macro stores
64-bit pointers into the __ksymtab* sections.
Make sure that the start of those sections is 64-bit aligned in the vmlinux
executable, otherwise unaligned memory accesses may happen at runtime.
The __kcrctab* sections store 32-bit entities, so make those sections
32-bit aligned.
The pci fixup routines want to be 64-bit aligned on 64-bit platforms
which don't define CONFIG_HAVE_ARCH_PREL32_RELOCATIONS. An alignment
of 8 bytes is sufficient to guarantee aligned accesses at runtime.
Signed-off-by: Helge Deller
Cc: # v6.0+
---
include/asm-generic/vmlinux.lds.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/asm-generic/vmlinux.lds.h
b/include/asm-generic/vmlinux.lds.h
index bae0fe4d499b..fa4335346e7d 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -467,6 +467,7 @@
} \
\
/* PCI quirks */\
+ . = ALIGN(8); \
.pci_fixup: AT(ADDR(.pci_fixup) - LOAD_OFFSET) {\
BOUNDED_SECTION_PRE_LABEL(.pci_fixup_early, _pci_fixups_early,
__start, __end) \
BOUNDED_SECTION_PRE_LABEL(.pci_fixup_header,
_pci_fixups_header, __start, __end) \
@@ -484,6 +485,7 @@
PRINTK_INDEX\
\
/* Kernel symbol table: Normal symbols */ \
+ . = ALIGN(8); \
__ksymtab : AT(ADDR(__ksymtab) - LOAD_OFFSET) { \
__start___ksymtab = .; \
KEEP(*(SORT(___ksymtab+*))) \
@@ -491,6 +493,7 @@
} \
\
/* Kernel symbol table: GPL-only symbols */ \
+ . = ALIGN(8); \
__ksymtab_gpl : AT(ADDR(__ksymtab_gpl) - LOAD_OFFSET) { \
__start___ksymtab_gpl = .; \
KEEP(*(SORT(___ksymtab_gpl+*))) \
@@ -498,6 +501,7 @@
} \
\
/* Kernel symbol table: Normal symbols */ \
+ . = ALIGN(4); \
__kcrctab : AT(ADDR(__kcrctab) - LOAD_OFFSET) { \
__start___kcrctab = .; \
KEEP(*(SORT(___kcrctab+*))) \
@@ -505,6 +509,7 @@
} \
\
/* Kernel symbol table: GPL-only symbols */ \
+ . = ALIGN(4); \
__kcrctab_gpl : AT(ADDR(__kcrctab_gpl) - LOAD_OFFSET) { \
__start___kcrctab_gpl = .; \
KEEP(*(SORT(___kcrctab_gpl+*))) \
--
2.41.0
[PATCH 4/4] modules: Add missing entry for __ex_table
From: Helge Deller
The entry for __ex_table was missing, which may make __ex_table
become 1- or 2-byte aligned in modules.
Add the entry to ensure it gets 32-bit aligned.
Signed-off-by: Helge Deller
Cc: # v6.0+
---
scripts/module.lds.S | 1 +
1 file changed, 1 insertion(+)
diff --git a/scripts/module.lds.S b/scripts/module.lds.S
index b00415a9ff27..488f61b156b2 100644
--- a/scripts/module.lds.S
+++ b/scripts/module.lds.S
@@ -26,6 +26,7 @@ SECTIONS {
.altinstructions0 : ALIGN(8) { KEEP(*(.altinstructions)) }
__bug_table 0 : ALIGN(8) { KEEP(*(__bug_table)) }
__jump_table0 : ALIGN(8) { KEEP(*(__jump_table)) }
+ __ex_table 0 : ALIGN(4) { KEEP(*(__ex_table)) }
__patchable_function_entries : { *(__patchable_function_entries) }
--
2.41.0
[PATCH 2/4] modules: Ensure 64-bit alignment on __ksymtab_* sections
From: Helge Deller
On 64-bit architectures without CONFIG_HAVE_ARCH_PREL32_RELOCATIONS
(e.g. ppc64, ppc64le, parisc, s390x,...) the __KSYM_REF() macro stores
64-bit pointers into the __ksymtab* sections.
Make sure that those sections will be correctly aligned at module link time,
otherwise unaligned memory accesses may happen at runtime.
The __kcrctab* sections store 32-bit entities, so use ALIGN(4) for those.
Signed-off-by: Helge Deller
Cc: # v6.0+
---
scripts/module.lds.S | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/scripts/module.lds.S b/scripts/module.lds.S
index bf5bcf2836d8..b00415a9ff27 100644
--- a/scripts/module.lds.S
+++ b/scripts/module.lds.S
@@ -15,10 +15,10 @@ SECTIONS {
*(.discard.*)
}
- __ksymtab 0 : { *(SORT(___ksymtab+*)) }
- __ksymtab_gpl 0 : { *(SORT(___ksymtab_gpl+*)) }
- __kcrctab 0 : { *(SORT(___kcrctab+*)) }
- __kcrctab_gpl 0 : { *(SORT(___kcrctab_gpl+*)) }
+ __ksymtab 0 : ALIGN(8) { *(SORT(___ksymtab+*)) }
+ __ksymtab_gpl 0 : ALIGN(8) { *(SORT(___ksymtab_gpl+*)) }
+ __kcrctab 0 : ALIGN(4) { *(SORT(___kcrctab+*)) }
+ __kcrctab_gpl 0 : ALIGN(4) { *(SORT(___kcrctab_gpl+*)) }
.ctors 0 : ALIGN(8) { *(SORT(.ctors.*)) *(.ctors) }
.init_array 0 : ALIGN(8) { *(SORT(.init_array.*))
*(.init_array) }
--
2.41.0
[PATCH 1/4] linux/export: Fix alignment for 64-bit ksymtab entries
From: Helge Deller An alignment of 4 bytes is wrong for 64-bit platforms which don't define CONFIG_HAVE_ARCH_PREL32_RELOCATIONS (which then store 64-bit pointers). Fix their alignment to 8 bytes. Signed-off-by: Helge Deller --- include/linux/export-internal.h | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/include/linux/export-internal.h b/include/linux/export-internal.h index 69501e0ec239..cd253eb51d6c 100644 --- a/include/linux/export-internal.h +++ b/include/linux/export-internal.h @@ -16,10 +16,13 @@ * and eliminates the need for absolute relocations that require runtime * processing on relocatable kernels. */ +#define __KSYM_ALIGN ".balign 4" #define __KSYM_REF(sym)".long " #sym "- ." #elif defined(CONFIG_64BIT) +#define __KSYM_ALIGN ".balign 8" #define __KSYM_REF(sym)".quad " #sym #else +#define __KSYM_ALIGN ".balign 4" #define __KSYM_REF(sym)".long " #sym #endif @@ -42,7 +45,7 @@ " .asciz \"" ns "\"" "\n" \ " .previous" "\n" \ " .section \"___ksymtab" sec "+" #name "\", \"a\"""\n" \ - " .balign 4" "\n" \ + __KSYM_ALIGN"\n" \ "__ksymtab_" #name ":" "\n" \ __KSYM_REF(sym) "\n" \ __KSYM_REF(__kstrtab_ ##name) "\n" \ -- 2.41.0
Re: [PATCH 3/5] parisc: remove broken vdso_install
Hi Masahiro, On 10/9/23 14:42, Masahiro Yamada wrote: 'make ARCH=parisc vdso_install' has never worked. It attempts to descend into arch/parisc/kernel/vdso/, which does not exist. The command just fails: scripts/Makefile.build:41: arch/parisc/kernel/vdso/Makefile: No such file or directory The second line is also meaningless because parisc does not define CONFIG_COMPAT_VDSO. It appears that this code was copied from another architecture without proper adaptation. Yes. Remove the broken code. Signed-off-by: Masahiro Yamada Thanks for cleaning this up and making it consistent across the architectures. Acked-by: Helge Deller # parisc In case you do a v2 version of the patch, would you add to arch/parisc/Makefile (otherwise I can send a follow-up patch in the parisc git tree): vdso-install-y += arch/parisc/kernel/vdso32/vdso32.so vdso-install-$(CONFIG_64BIT) += arch/parisc/kernel/vdso64/vdso64.so Thanks! Helge
Re: [PATCH 15/20] kbuild: parisc: use common install script
On 4/7/21 1:23 PM, Masahiro Yamada wrote: On Wed, Apr 7, 2021 at 2:34 PM Greg Kroah-Hartman wrote: The common scripts/install.sh script will now work for parisc, all that is needed is to add the compressed image type to it. So add that file type check, and then we can remove the two different copies of the parisc install.sh script that were only different by one line and have the arch call the common install script. Cc: "James E.J. Bottomley" Cc: Helge Deller Cc: linux-par...@vger.kernel.org Signed-off-by: Greg Kroah-Hartman --- arch/parisc/Makefile| 4 +-- arch/parisc/boot/Makefile | 2 +- arch/parisc/boot/install.sh | 65 arch/parisc/install.sh | 66 - scripts/install.sh | 1 + 5 files changed, 4 insertions(+), 134 deletions(-) delete mode 100644 arch/parisc/boot/install.sh delete mode 100644 arch/parisc/install.sh diff --git a/arch/parisc/Makefile b/arch/parisc/Makefile index 7d9f71aa829a..296d8ab8e2aa 100644 --- a/arch/parisc/Makefile +++ b/arch/parisc/Makefile @@ -164,10 +164,10 @@ vmlinuz: vmlinux endif install: - $(CONFIG_SHELL) $(srctree)/arch/parisc/install.sh \ + $(CONFIG_SHELL) $(srctree)/scripts/install.sh \ $(KERNELRELEASE) vmlinux System.map "$(INSTALL_PATH)" zinstall: - $(CONFIG_SHELL) $(srctree)/arch/parisc/install.sh \ + $(CONFIG_SHELL) $(srctree)/scripts/install.sh \ $(KERNELRELEASE) vmlinuz System.map "$(INSTALL_PATH)" CLEAN_FILES+= lifimage diff --git a/arch/parisc/boot/Makefile b/arch/parisc/boot/Makefile index 61f44142cfe1..ad2611929aee 100644 --- a/arch/parisc/boot/Makefile +++ b/arch/parisc/boot/Makefile @@ -17,5 +17,5 @@ $(obj)/compressed/vmlinux: FORCE $(Q)$(MAKE) $(build)=$(obj)/compressed $@ install: $(CONFIGURE) $(obj)/bzImage - sh -x $(srctree)/$(obj)/install.sh $(KERNELRELEASE) $(obj)/bzImage \ + sh -x $(srctree)/scripts/install.sh $(KERNELRELEASE) $(obj)/bzImage \ System.map "$(INSTALL_PATH)" As far as I understood, there is no way to invoke this 'install' target in arch/parisc/boot/Makefile since everything is done by arch/parisc/Makefile. Can we remove this 'install' rule entirely? Yes, I think it can go in arch/parisc/boot/Makefile. Helge
Re: [PATCH 4/5] uapi: always define F_GETLK64/F_SETLK64/F_SETLKW64 in fcntl.h
On 4/13/21 5:46 PM, Christoph Hellwig wrote: On Tue, Apr 13, 2021 at 05:43:18PM +0200, Helge Deller wrote: On 4/12/21 10:55 AM, Christoph Hellwig wrote: The F_GETLK64/F_SETLK64/F_SETLKW64 commands are only implemented for 32-bit syscall APIs, but we also need them for compat handling on 64-bit kernels. Ok. Given that redefining them is rather error prone, as shown by parisc getting the opcodes wrong currently, just use the existing definitions for the compat handling. Can you please show me where parisc gets it currently wrong? I'm somehow blind to see it and of course I'd like to fix it in stable kernel series if that's true... Looking again I think my comment was wrong, I thought parisc would fall back to the asm-generic version with different code points for the compat case, but parisc actually already defines the constants unconditionally like this patch does for everyone else. So I'll retract that part of the comment. Ok, good. Thanks for checking! Helge
Re: [PATCH 4/5] uapi: always define F_GETLK64/F_SETLK64/F_SETLKW64 in fcntl.h
On 4/12/21 10:55 AM, Christoph Hellwig wrote:
The F_GETLK64/F_SETLK64/F_SETLKW64 commands are only implemented for
32-bit syscall APIs, but we also need them for compat handling on 64-bit
kernels.
Ok.
Given that redefining them is rather error prone, as shown by parisc
getting the opcodes wrong currently, just use the existing definitions
for the compat handling.
Can you please show me where parisc gets it currently wrong?
I'm somehow blind to see it and of course I'd like to fix it in
stable kernel series if that's true...
Other than that, thanks for this cleanup!
You may add:
Acked-by: Helge Deller
Thanks!
Helge
In theory we could try to hide them from userspace; but given that only
MIPS manages to properly do that while the asm-generic version used by
most architectures relies on a Kconfig symbol that is never set by
userspace there doesn't seem to be much of a point to even bother.
Signed-off-by: Christoph Hellwig
---
arch/arm64/include/asm/compat.h| 4
arch/mips/include/asm/compat.h | 4
arch/mips/include/uapi/asm/fcntl.h | 2 --
arch/powerpc/include/asm/compat.h | 4
arch/s390/include/asm/compat.h | 4
arch/sparc/include/asm/compat.h| 4
arch/x86/include/asm/compat.h | 4
include/uapi/asm-generic/fcntl.h | 2 --
tools/include/uapi/asm-generic/fcntl.h | 2 --
9 files changed, 30 deletions(-)
diff --git a/arch/arm64/include/asm/compat.h b/arch/arm64/include/asm/compat.h
index 23a9fb73c04ff8..a5fe4558a6ecc0 100644
--- a/arch/arm64/include/asm/compat.h
+++ b/arch/arm64/include/asm/compat.h
@@ -74,10 +74,6 @@ struct compat_flock {
compat_pid_tl_pid;
};
-#define F_GETLK64 12 /* using 'struct flock64' */
-#define F_SETLK64 13
-#define F_SETLKW64 14
-
struct compat_flock64 {
short l_type;
short l_whence;
diff --git a/arch/mips/include/asm/compat.h b/arch/mips/include/asm/compat.h
index 65975712a22dcf..a13436e91c3938 100644
--- a/arch/mips/include/asm/compat.h
+++ b/arch/mips/include/asm/compat.h
@@ -60,10 +60,6 @@ struct compat_flock {
s32 pad[4];
};
-#define F_GETLK64 33
-#define F_SETLK64 34
-#define F_SETLKW64 35
-
struct compat_flock64 {
short l_type;
short l_whence;
diff --git a/arch/mips/include/uapi/asm/fcntl.h
b/arch/mips/include/uapi/asm/fcntl.h
index 9e44ac810db94d..1769fc50d35f0e 100644
--- a/arch/mips/include/uapi/asm/fcntl.h
+++ b/arch/mips/include/uapi/asm/fcntl.h
@@ -44,11 +44,9 @@
#define F_SETOWN 24 /* for sockets. */
#define F_GETOWN 23 /* for sockets. */
-#ifndef __mips64
#define F_GETLK64 33 /* using 'struct flock64' */
#define F_SETLK64 34
#define F_SETLKW6435
-#endif
#if _MIPS_SIM != _MIPS_SIM_ABI64
#define __ARCH_FLOCK_EXTRA_SYSID long l_sysid;
diff --git a/arch/powerpc/include/asm/compat.h
b/arch/powerpc/include/asm/compat.h
index 9191fc29e6ed11..b0f2c3f7fe45a5 100644
--- a/arch/powerpc/include/asm/compat.h
+++ b/arch/powerpc/include/asm/compat.h
@@ -56,10 +56,6 @@ struct compat_flock {
compat_pid_tl_pid;
};
-#define F_GETLK64 12 /* using 'struct flock64' */
-#define F_SETLK64 13
-#define F_SETLKW64 14
-
struct compat_flock64 {
short l_type;
short l_whence;
diff --git a/arch/s390/include/asm/compat.h b/arch/s390/include/asm/compat.h
index ea5b9c34b7be5b..e0896758779da4 100644
--- a/arch/s390/include/asm/compat.h
+++ b/arch/s390/include/asm/compat.h
@@ -111,10 +111,6 @@ struct compat_flock {
compat_pid_tl_pid;
};
-#define F_GETLK64 12
-#define F_SETLK64 13
-#define F_SETLKW64 14
-
struct compat_flock64 {
short l_type;
short l_whence;
diff --git a/arch/sparc/include/asm/compat.h b/arch/sparc/include/asm/compat.h
index b85842cda99fe0..4524997424043f 100644
--- a/arch/sparc/include/asm/compat.h
+++ b/arch/sparc/include/asm/compat.h
@@ -85,10 +85,6 @@ struct compat_flock {
short __unused;
};
-#define F_GETLK64 12
-#define F_SETLK64 13
-#define F_SETLKW64 14
-
struct compat_flock64 {
short l_type;
short l_whence;
diff --git a/arch/x86/include/asm/compat.h b/arch/x86/include/asm/compat.h
index be09c7eac89f09..b1691cf148be10 100644
--- a/arch/x86/include/asm/compat.h
+++ b/arch/x86/include/asm/compat.h
@@ -59,10 +59,6 @@ struct compat_flock {
compat_pid_tl_pid;
};
-#define F_GETLK64 12 /* using 'struct flock64' */
-#define F_SETLK64 13
-#define F_SETLKW64 14
-
/*
* IA32 uses 4 byte alignment for 64 bit quantities,
* so we need to pack this structure.
diff --git a/include/uapi/asm-generic/fcntl.h b/include/uapi/asm-generic/fcntl.h
index 7e714443a8d2e3..6430a2f8023fc3 100644
--- a/include/uapi/asm-generic/fcntl.h
+++ b
Re: [PATCH v2 1/1] kernel.h: Split out panic and oops helpers
On 4/9/21 12:02 PM, Andy Shevchenko wrote: kernel.h is being used as a dump for all kinds of stuff for a long time. Here is the attempt to start cleaning it up by splitting out panic and oops helpers. There are several purposes of doing this: - dropping dependency in bug.h - dropping a loop by moving out panic_notifier.h - unload kernel.h from something which has its own domain At the same time convert users tree-wide to use new headers, although for the time being include new header back to kernel.h to avoid twisted indirected includes for existing users. Signed-off-by: Andy Shevchenko Reviewed-by: Bjorn Andersson Acked-by: Mike Rapoport Acked-by: Corey Minyard Acked-by: Christian Brauner Acked-by: Arnd Bergmann Acked-by: Kees Cook Acked-by: Wei Liu Acked-by: Rasmus Villemoes Signed-off-by: Andrew Morton Acked-by: Helge Deller # parisc Helge
Re: [GIT PULL] parisc architecture fixes for kernel v5.12-rc7
On 4/7/21 6:26 PM, Linus Torvalds wrote: On Wed, Apr 7, 2021 at 2:09 AM Helge Deller wrote: http://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git parisc-5.12-3 Not technically related to this pull (which I just did), but doing the pull did remind me that you're one of the people who don't use signed tags for pull requests. Ok. I don't require that for kernel.org accounts, and it's not really a problem, but I do encourage it. So I thought I'd just mention it in case it would be something you'd be willing to do.. Thanks for the reminder and sure, I'll sign my next tags as well. Helge
[GIT PULL] parisc architecture fixes for kernel v5.12-rc7
Hi Linus, please pull four small parisc architecture fixes for kernel 5.12-rc7 from: http://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git parisc-5.12-3 One link error fix found by the kernel test robot, one sparse warning fix, remove a duplicate declaration and some spelling fixes. Thanks, Helge Bhaskar Chowdhury (1): parisc: math-emu: Few spelling fixes in the file fpu.h Gao Xiang (1): parisc: avoid a warning on u8 cast for cmpxchg on u8 pointers Helge Deller (1): parisc: parisc-agp requires SBA IOMMU driver Wan Jiabing (1): parisc: Remove duplicate struct task_struct declaration arch/parisc/include/asm/cmpxchg.h | 2 +- arch/parisc/include/asm/processor.h | 1 - arch/parisc/math-emu/fpu.h | 32 +++- drivers/char/agp/Kconfig| 2 +- 4 files changed, 5 insertions(+), 32 deletions(-)
Re: [PATCH] parisc: avoid a warning on u8 cast for cmpxchg on u8 pointers
On 4/6/21 6:59 AM, Gao Xiang wrote:
From: Gao Xiang
commit b344d6a83d01 ("parisc: add support for cmpxchg on u8 pointers")
can generate a sparse warningi ("cast truncates bits from constant
value"), which has been reported several times [1] [2] [3].
The original code worked as expected, but anyway, let silence such
sparse warning as what others did [4].
[1] https://lore.kernel.org/r/202104061220.nrmbwcxw-...@intel.com
[2] https://lore.kernel.org/r/202012291914.t5agcn99-...@intel.com
[3] https://lore.kernel.org/r/202008210829.kvwn7xeh%25...@intel.com
[4] https://lore.kernel.org/r/20210315131512.133720-2-jacopo+rene...@jmondi.org
Cc: Liam Beguin
Cc: Helge Deller
Signed-off-by: Gao Xiang
applied to the parisc for-next git tree.
(I fixed up the typo above too)
Thanks!
Helge
---
arch/parisc/include/asm/cmpxchg.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/parisc/include/asm/cmpxchg.h
b/arch/parisc/include/asm/cmpxchg.h
index cf5ee9b0b393..84ee232278a6 100644
--- a/arch/parisc/include/asm/cmpxchg.h
+++ b/arch/parisc/include/asm/cmpxchg.h
@@ -72,7 +72,7 @@ __cmpxchg(volatile void *ptr, unsigned long old, unsigned
long new_, int size)
#endif
case 4: return __cmpxchg_u32((unsigned int *)ptr,
(unsigned int)old, (unsigned int)new_);
- case 1: return __cmpxchg_u8((u8 *)ptr, (u8)old, (u8)new_);
+ case 1: return __cmpxchg_u8((u8 *)ptr, old & 0xff, new_ & 0xff);
}
__cmpxchg_called_with_bad_pointer();
return old;
Re: ERROR: modpost: "sba_list" [drivers/char/agp/parisc-agp.ko] undefined!
* kernel test robot : > Hi Helge, > > First bad commit (maybe != root cause): > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > master > head: 0a50438c84363bd37fe18fe432888ae9a074dcab > commit: 00e35f2b0e8acb88d4e1aa96ff0490e3bfe46580 parisc: Enable -mlong-calls > gcc option by default when !CONFIG_MODULES > date: 10 weeks ago > config: parisc-randconfig-r035-20210406 (attached as .config) > compiler: hppa64-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://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=00e35f2b0e8acb88d4e1aa96ff0490e3bfe46580 > git remote add linus > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > git fetch --no-tags linus master > git checkout 00e35f2b0e8acb88d4e1aa96ff0490e3bfe46580 > # save the attached .config to linux build tree > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross > ARCH=parisc > > If you fix the issue, kindly add following tag as appropriate > Reported-by: kernel test robot > > All errors (new ones prefixed by >>, old ones prefixed by <<): > > >> ERROR: modpost: "sba_list" [drivers/char/agp/parisc-agp.ko] undefined! The following patch should fix it. I'll apply it to the parisc for-next git tree. Thanks! Helge - From: Helge Deller Date: Tue, 6 Apr 2021 11:32:52 +0200 Subject: [PATCH] parisc: parisc-agp requires SBA IOMMU driver Add a dependency to the SBA IOMMU driver to avoid: ERROR: modpost: "sba_list" [drivers/char/agp/parisc-agp.ko] undefined! Reported-by: kernel test robot Signed-off-by: Helge Deller diff --git a/drivers/char/agp/Kconfig b/drivers/char/agp/Kconfig index a086dd34f932..4f501e4842ab 100644 --- a/drivers/char/agp/Kconfig +++ b/drivers/char/agp/Kconfig @@ -125,7 +125,7 @@ config AGP_HP_ZX1 config AGP_PARISC tristate "HP Quicksilver AGP support" - depends on AGP && PARISC && 64BIT + depends on AGP && PARISC && 64BIT && IOMMU_SBA help This option gives you AGP GART support for the HP Quicksilver AGP bus adapter on HP PA-RISC machines (Ok, just on the C8000
Re: [PATCH] arch: parisc: Remove duplicate struct task_struct declaration
On 3/31/21 3:28 AM, Wan Jiabing wrote: struct task_struct is declared twice. One has been declared at 154th line. Remove the duplicate. Signed-off-by: Wan Jiabing Thanks, applied to parisc tree. Helge --- arch/parisc/include/asm/processor.h | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/parisc/include/asm/processor.h b/arch/parisc/include/asm/processor.h index 11ece0d07374..b5fbcd2c1780 100644 --- a/arch/parisc/include/asm/processor.h +++ b/arch/parisc/include/asm/processor.h @@ -272,7 +272,6 @@ on downward growing arches, it looks like this: regs->gr[23] = 0;\ } while(0) -struct task_struct; struct mm_struct; /* Free all resources held by a thread. */
Re: [PATCH 1/2] parisc: syscalls: switch to generic syscalltbl.sh
On 3/1/21 3:58 PM, Masahiro Yamada wrote:
Many architectures duplicate similar shell scripts.
This commit converts parisc to use scripts/syscalltbl.sh. This also
unifies syscall_table_64.h and syscall_table_c32.h.
Signed-off-by: Masahiro Yamada
For both patches:
Acked-by: Helge Deller
Masahiro, will you push it upstream, or should I take it through the parisc
tree?
Helge
---
arch/parisc/include/asm/Kbuild| 1 -
arch/parisc/kernel/syscall.S | 16 +-
arch/parisc/kernel/syscalls/Makefile | 19
arch/parisc/kernel/syscalls/syscalltbl.sh | 36 ---
4 files changed, 12 insertions(+), 60 deletions(-)
delete mode 100644 arch/parisc/kernel/syscalls/syscalltbl.sh
diff --git a/arch/parisc/include/asm/Kbuild b/arch/parisc/include/asm/Kbuild
index 4406475a2304..e6e7f74c8ac9 100644
--- a/arch/parisc/include/asm/Kbuild
+++ b/arch/parisc/include/asm/Kbuild
@@ -1,7 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
generated-y += syscall_table_32.h
generated-y += syscall_table_64.h
-generated-y += syscall_table_c32.h
generic-y += kvm_para.h
generic-y += mcs_spinlock.h
generic-y += user.h
diff --git a/arch/parisc/kernel/syscall.S b/arch/parisc/kernel/syscall.S
index 322503780db6..3f24a0af1e04 100644
--- a/arch/parisc/kernel/syscall.S
+++ b/arch/parisc/kernel/syscall.S
@@ -919,24 +919,24 @@ ENTRY(lws_table)
END(lws_table)
/* End of lws table */
+#ifdef CONFIG_64BIT
+#define __SYSCALL_WITH_COMPAT(nr, native, compat) __SYSCALL(nr, compat)
+#else
+#define __SYSCALL_WITH_COMPAT(nr, native, compat) __SYSCALL(nr, native)
+#endif
#define __SYSCALL(nr, entry) ASM_ULONG_INSN entry
.align 8
ENTRY(sys_call_table)
.export sys_call_table,data
-#ifdef CONFIG_64BIT
-#include/* Compat syscalls */
-#else
-#include /* 32-bit native syscalls */
-#endif
+#include /* 32-bit syscalls */
END(sys_call_table)
#ifdef CONFIG_64BIT
.align 8
ENTRY(sys_call_table64)
-#include /* 64-bit native syscalls */
+#include /* 64-bit syscalls */
END(sys_call_table64)
#endif
-#undef __SYSCALL
/*
All light-weight-syscall atomic operations
@@ -961,5 +961,3 @@ END(lws_lock_start)
.previous
.end
-
-
diff --git a/arch/parisc/kernel/syscalls/Makefile
b/arch/parisc/kernel/syscalls/Makefile
index 283f64407b07..11424f1c8d9e 100644
--- a/arch/parisc/kernel/syscalls/Makefile
+++ b/arch/parisc/kernel/syscalls/Makefile
@@ -7,7 +7,7 @@ _dummy := $(shell [ -d '$(uapi)' ] || mkdir -p '$(uapi)')
\
syscall := $(src)/syscall.tbl
syshdr := $(srctree)/$(src)/syscallhdr.sh
-systbl := $(srctree)/$(src)/syscalltbl.sh
+systbl := $(srctree)/scripts/syscalltbl.sh
quiet_cmd_syshdr = SYSHDR $@
cmd_syshdr = $(CONFIG_SHELL) '$(syshdr)' '$<' '$@' \
@@ -16,10 +16,7 @@ quiet_cmd_syshdr = SYSHDR $@
'$(syshdr_offset_$(basetarget))'
quiet_cmd_systbl = SYSTBL $@
- cmd_systbl = $(CONFIG_SHELL) '$(systbl)' '$<' '$@'\
- '$(systbl_abis_$(basetarget))' \
- '$(systbl_abi_$(basetarget))'\
- '$(systbl_offset_$(basetarget))'
+ cmd_systbl = $(CONFIG_SHELL) $(systbl) --abis $(abis) $< $@
syshdr_abis_unistd_32 := common,32
$(uapi)/unistd_32.h: $(syscall) $(syshdr) FORCE
@@ -29,23 +26,17 @@ syshdr_abis_unistd_64 := common,64
$(uapi)/unistd_64.h: $(syscall) $(syshdr) FORCE
$(call if_changed,syshdr)
-systbl_abis_syscall_table_32 := common,32
+$(kapi)/syscall_table_32.h: abis := common,32
$(kapi)/syscall_table_32.h: $(syscall) $(systbl) FORCE
$(call if_changed,systbl)
-systbl_abis_syscall_table_64 := common,64
+$(kapi)/syscall_table_64.h: abis := common,64
$(kapi)/syscall_table_64.h: $(syscall) $(systbl) FORCE
$(call if_changed,systbl)
-systbl_abis_syscall_table_c32 := common,32
-systbl_abi_syscall_table_c32 := c32
-$(kapi)/syscall_table_c32.h: $(syscall) $(systbl) FORCE
- $(call if_changed,systbl)
-
uapisyshdr-y += unistd_32.h unistd_64.h
kapisyshdr-y += syscall_table_32.h \
- syscall_table_64.h \
- syscall_table_c32.h
+ syscall_table_64.h
uapisyshdr-y := $(addprefix $(uapi)/, $(uapisyshdr-y))
kapisyshdr-y := $(addprefix $(kapi)/, $(kapisyshdr-y))
diff --git a/arch/parisc/kernel/syscalls/syscalltbl.sh
b/arch/parisc/kernel/syscalls/syscalltbl.sh
deleted file mode 100644
index f7393a7b18aa..
--- a/arch/parisc/kernel/syscalls/syscalltbl.sh
+++ /dev/null
@@ -1,36 +0,0 @@
-#!/bin/sh
-# SPDX-License-Identifier: GPL-2.0
-
-in="$1"
-out="$2"
-my_abis=`echo "($3)" | tr ',' '|'`
-my_abi="$4"
-offset="$5"
-
-emit() {
- t_nxt="$1"
- t_nr="$2"
- t_entry="$3"
-
- while
[GIT PULL] parisc architecture fixes for kernel v5.12-rc333
Hi Linus, please pull two small parisc architecture fixes for kernel 5.12-rc3 from: http://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git parisc-5.12-2 Fix a linking failure reported by the kernel test robot and remove a duplicate include. Thanks, Helge Helge Deller (1): parisc: Enable -mlong-calls gcc option with CONFIG_COMPILE_TEST Zhang Yunkai (1): arch/parisc/kernel: remove duplicate include in ptrace arch/parisc/Kconfig | 7 +-- arch/parisc/kernel/ptrace.c | 2 -- 2 files changed, 5 insertions(+), 4 deletions(-)
Re: [PATCH] arch/parisc/kernel: remove duplicate include in ptrace
On 3/4/21 3:24 AM, menglong8.d...@gmail.com wrote:
From: Zhang Yunkai
'linux/compat.h' included in 'arch/parisc/kernel/ptrace.c' is duplicated.
It is also included in the 24th line.
Signed-off-by: Zhang Yunkai
Thanks,
applied to the parisc-next tree.
Helge
---
arch/parisc/kernel/ptrace.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/parisc/kernel/ptrace.c b/arch/parisc/kernel/ptrace.c
index 2127974982df..918faa95740c 100644
--- a/arch/parisc/kernel/ptrace.c
+++ b/arch/parisc/kernel/ptrace.c
@@ -567,7 +567,6 @@ static const struct user_regset_view
user_parisc_native_view = {
};
#ifdef CONFIG_64BIT
-#include
static int gpr32_get(struct task_struct *target,
const struct user_regset *regset,
Re: hppa64-linux-ld: kernel/sched/core.o(.init.text+0x90): cannot reach printk
* Helge Deller : > On 3/2/21 7:07 PM, Nick Desaulniers wrote: > > + Arnd > > > > On Tue, Mar 2, 2021 at 10:03 AM Helge Deller wrote: > > > > > > On 3/2/21 6:29 PM, Nick Desaulniers wrote: > > > > + pa-risc folks > > > > > > Thanks for looking into this, Nick! > > > > > > > On Tue, Mar 2, 2021 at 2:59 AM kernel test robot wrote: > > > > > > > > > > tree: > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > > > > > master > > > > > head: 7a7fd0de4a9804299793e564a555a49c1fc924cb > > > > > commit: eff8728fe69880d3f7983bec3fb6cea4c306261f vmlinux.lds.h: Add > > > > > PGO and AutoFDO input sections > > > > > > > > This commit added sections explicitly to the kernel's linker script. > > > > > > Yes, but even when reverting this patch it does not prevent > > > the linking problems. > > > > > > > > > > > date: 6 months ago > > > > > config: parisc-randconfig-s031-20210228 (attached as .config) > > > > > > > > ^ randconfig (always find something curious) > > > > > > Yes :-) > > > > > > > > > > > compiler: hppa64-linux-gcc (GCC) 9.3.0 > > > > > reproduce: > > > > > wget > > > > > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross > > > > > -O ~/bin/make.cross > > > > > chmod +x ~/bin/make.cross > > > > > # apt-get install sparse > > > > > # sparse version: v0.6.3-241-geaceeafa-dirty > > > > > # > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=eff8728fe69880d3f7983bec3fb6cea4c306261f > > > > > git remote add linus > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > > > > > git fetch --no-tags linus master > > > > > git checkout eff8728fe69880d3f7983bec3fb6cea4c306261f > > > > > # save the attached .config to linux build tree > > > > > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 > > > > > make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=parisc > > > > > > > > > > If you fix the issue, kindly add following tag as appropriate > > > > > Reported-by: kernel test robot > > > > > > > > > > All errors (new ones prefixed by >>): > > > > > > > > > > hppa64-linux-ld: init/main.o(.init.text+0x294): cannot reach > > > > > printk > > > > > init/main.o: in function `do_early_param': > > > > > (.init.text+0x294): relocation truncated to fit: > > > > > R_PARISC_PCREL22F against symbol `printk' defined in .text.unlikely > > > > > section in kernel/printk/printk.o > > > > > > > > ^ so we can't encode a jump to printk from do_early_param. > > > > > > Right. > > > > > > > If the linker is warning that printk is in the .text.unlikely > > > > section, I'm curious why printk is marked cold? > > > > > > printk is always marked cold, see include/linux/printk.h: > > > asmlinkage __printf(1, 2) __cold > > > int printk(const char *fmt, ...); > > > > > > > Likely the randconfig produces a large TEXT_MAIN; > > > > > > Yes. > > > > > > > I'm guessing that .init.text is on one side of TEXT_MAIN, and > > > > .text.unlikely is on the other. Though there are many different > > > > instances below. > > > Yes. But even the large TEXT_MAIN by itself can become a problem. > > > > > > > I'm more familiar with ARM; it's common for the linker to insert > > > > trampolines/thunks to bridge jumps too large to encode in a given > > > > instruction. I don't know if BFD has arch agnostic machinery for > > > > that, but might be seeing if there's anything reuseable there. > > > > > > Dave mentioned in another mail, that long branch stub support is > > > still missing in the 64-bit parisc linker. > > > > > > My question still remains: > > > Is there any possibility to detect that we build/configure a > > > 0-day kernel? If so, auto-enabling CONFIG_MLONGCALLS kernel option > > > would solve i
Re: hppa64-linux-ld: kernel/sched/core.o(.init.text+0x90): cannot reach printk
On 3/2/21 7:07 PM, Nick Desaulniers wrote: + Arnd On Tue, Mar 2, 2021 at 10:03 AM Helge Deller wrote: On 3/2/21 6:29 PM, Nick Desaulniers wrote: + pa-risc folks Thanks for looking into this, Nick! On Tue, Mar 2, 2021 at 2:59 AM kernel test robot wrote: tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 7a7fd0de4a9804299793e564a555a49c1fc924cb commit: eff8728fe69880d3f7983bec3fb6cea4c306261f vmlinux.lds.h: Add PGO and AutoFDO input sections This commit added sections explicitly to the kernel's linker script. Yes, but even when reverting this patch it does not prevent the linking problems. date: 6 months ago config: parisc-randconfig-s031-20210228 (attached as .config) ^ randconfig (always find something curious) Yes :-) compiler: hppa64-linux-gcc (GCC) 9.3.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # apt-get install sparse # sparse version: v0.6.3-241-geaceeafa-dirty # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=eff8728fe69880d3f7983bec3fb6cea4c306261f git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout eff8728fe69880d3f7983bec3fb6cea4c306261f # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=parisc If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): hppa64-linux-ld: init/main.o(.init.text+0x294): cannot reach printk init/main.o: in function `do_early_param': (.init.text+0x294): relocation truncated to fit: R_PARISC_PCREL22F against symbol `printk' defined in .text.unlikely section in kernel/printk/printk.o ^ so we can't encode a jump to printk from do_early_param. Right. If the linker is warning that printk is in the .text.unlikely section, I'm curious why printk is marked cold? printk is always marked cold, see include/linux/printk.h: asmlinkage __printf(1, 2) __cold int printk(const char *fmt, ...); Likely the randconfig produces a large TEXT_MAIN; Yes. I'm guessing that .init.text is on one side of TEXT_MAIN, and .text.unlikely is on the other. Though there are many different instances below. Yes. But even the large TEXT_MAIN by itself can become a problem. I'm more familiar with ARM; it's common for the linker to insert trampolines/thunks to bridge jumps too large to encode in a given instruction. I don't know if BFD has arch agnostic machinery for that, but might be seeing if there's anything reuseable there. Dave mentioned in another mail, that long branch stub support is still missing in the 64-bit parisc linker. My question still remains: Is there any possibility to detect that we build/configure a 0-day kernel? If so, auto-enabling CONFIG_MLONGCALLS kernel option would solve it (temporarily). Arnd, is this kind of case what CONFIG_COMPILE_TEST is usually used for? Yes, I think that's the right knob! CONFIG_COMPILE_TEST is enabled on all parisc configs for which 0-day reported issues. I've wired it up in Kconfig and it now works around the issue. Helge The better long-term solution is to add long branch stub support to the linker. Agreed. Helge The commit in question (eff8728fe69880d3f7983bec3fb6cea4c306261f) doesn't reorder existing sections, but does add .text.hot.* before TEXT_MAIN. Existing sections could have been placed as "orphan sections." hppa64-linux-ld: init/main.o(.init.text+0x56c): cannot reach printk init/main.o: in function `unknown_bootoption': (.init.text+0x56c): relocation truncated to fit: R_PARISC_PCREL22F against symbol `printk' defined in .text.unlikely section in kernel/printk/printk.o hppa64-linux-ld: init/main.o(.init.text+0xa68): cannot reach printk init/main.o: in function `xbc_make_cmdline': (.init.text+0xa68): relocation truncated to fit: R_PARISC_PCREL22F against symbol `printk' defined in .text.unlikely section in kernel/printk/printk.o hppa64-linux-ld: init/main.o(.init.text+0xaac): cannot reach printk (.init.text+0xaac): relocation truncated to fit: R_PARISC_PCREL22F against symbol `printk' defined in .text.unlikely section in kernel/printk/printk.o hppa64-linux-ld: init/main.o(.init.text+0xb68): cannot reach printk init/main.o: in function `initcall_blacklist': (.init.text+0xb68): relocation truncated to fit: R_PARISC_PCREL22F against symbol `printk' defined in .text.unlikely section in kernel/printk/printk.o hppa64-linux-ld: init/main.o(.init.text+0xbf8): cannot reach panic (.init.text+0xbf8): relocation truncated to fit: R_PARISC_PCREL22F agains
Re: hppa64-linux-ld: kernel/sched/core.o(.init.text+0x90): cannot reach printk
On 3/2/21 6:29 PM, Nick Desaulniers wrote: + pa-risc folks Thanks for looking into this, Nick! On Tue, Mar 2, 2021 at 2:59 AM kernel test robot wrote: tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 7a7fd0de4a9804299793e564a555a49c1fc924cb commit: eff8728fe69880d3f7983bec3fb6cea4c306261f vmlinux.lds.h: Add PGO and AutoFDO input sections This commit added sections explicitly to the kernel's linker script. Yes, but even when reverting this patch it does not prevent the linking problems. date: 6 months ago config: parisc-randconfig-s031-20210228 (attached as .config) ^ randconfig (always find something curious) Yes :-) compiler: hppa64-linux-gcc (GCC) 9.3.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # apt-get install sparse # sparse version: v0.6.3-241-geaceeafa-dirty # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=eff8728fe69880d3f7983bec3fb6cea4c306261f git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout eff8728fe69880d3f7983bec3fb6cea4c306261f # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=parisc If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): hppa64-linux-ld: init/main.o(.init.text+0x294): cannot reach printk init/main.o: in function `do_early_param': (.init.text+0x294): relocation truncated to fit: R_PARISC_PCREL22F against symbol `printk' defined in .text.unlikely section in kernel/printk/printk.o ^ so we can't encode a jump to printk from do_early_param. Right. If the linker is warning that printk is in the .text.unlikely section, I'm curious why printk is marked cold? printk is always marked cold, see include/linux/printk.h: asmlinkage __printf(1, 2) __cold int printk(const char *fmt, ...); Likely the randconfig produces a large TEXT_MAIN; Yes. I'm guessing that .init.text is on one side of TEXT_MAIN, and .text.unlikely is on the other. Though there are many different instances below. Yes. But even the large TEXT_MAIN by itself can become a problem. I'm more familiar with ARM; it's common for the linker to insert trampolines/thunks to bridge jumps too large to encode in a given instruction. I don't know if BFD has arch agnostic machinery for that, but might be seeing if there's anything reuseable there. Dave mentioned in another mail, that long branch stub support is still missing in the 64-bit parisc linker. My question still remains: Is there any possibility to detect that we build/configure a 0-day kernel? If so, auto-enabling CONFIG_MLONGCALLS kernel option would solve it (temporarily). The better long-term solution is to add long branch stub support to the linker. Helge The commit in question (eff8728fe69880d3f7983bec3fb6cea4c306261f) doesn't reorder existing sections, but does add .text.hot.* before TEXT_MAIN. Existing sections could have been placed as "orphan sections." hppa64-linux-ld: init/main.o(.init.text+0x56c): cannot reach printk init/main.o: in function `unknown_bootoption': (.init.text+0x56c): relocation truncated to fit: R_PARISC_PCREL22F against symbol `printk' defined in .text.unlikely section in kernel/printk/printk.o hppa64-linux-ld: init/main.o(.init.text+0xa68): cannot reach printk init/main.o: in function `xbc_make_cmdline': (.init.text+0xa68): relocation truncated to fit: R_PARISC_PCREL22F against symbol `printk' defined in .text.unlikely section in kernel/printk/printk.o hppa64-linux-ld: init/main.o(.init.text+0xaac): cannot reach printk (.init.text+0xaac): relocation truncated to fit: R_PARISC_PCREL22F against symbol `printk' defined in .text.unlikely section in kernel/printk/printk.o hppa64-linux-ld: init/main.o(.init.text+0xb68): cannot reach printk init/main.o: in function `initcall_blacklist': (.init.text+0xb68): relocation truncated to fit: R_PARISC_PCREL22F against symbol `printk' defined in .text.unlikely section in kernel/printk/printk.o hppa64-linux-ld: init/main.o(.init.text+0xbf8): cannot reach panic (.init.text+0xbf8): relocation truncated to fit: R_PARISC_PCREL22F against symbol `panic' defined in .text.unlikely section in kernel/panic.o hppa64-linux-ld: init/main.o(.init.text+0xda0): cannot reach rest_init init/main.o: in function `arch_call_rest_init': (.init.text+0xda0): relocation truncated to fit: R_PARISC_PCREL22F against symbol `rest_init' defined in .ref.text section in init/main.o hppa64-linux-ld: init/main.o(.init.text+0xef4): cannot reach printk init/main.o: in
Re: hppa64-linux-ld: kernel/rcu/refscale.o(.init.text+0x228): cannot reach schedule_timeout_uninterruptible
On 2/28/21 11:33 PM, Paul E. McKenney wrote: On Sun, Feb 28, 2021 at 09:51:35PM +0100, Helge Deller wrote: Adding parisc-parisc mailing list... On 2/28/21 6:05 AM, Paul E. McKenney wrote: On Sun, Feb 28, 2021 at 12:08:08PM +0800, kernel test robot wrote: Hi Paul, First bad commit (maybe != root cause): tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 5695e51619745d4fe3ec2506a2f0cd982c5e27a4 commit: 1fbeb3a8c4de29433a8d230ee600b13d369b6c0f refperf: Rename refperf.c to refscale.c and change internal names date: 8 months ago config: parisc-randconfig-s031-20210228 (attached as .config) compiler: hppa64-linux-gcc (GCC) 9.3.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # apt-get install sparse # sparse version: v0.6.3-241-geaceeafa-dirty # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1fbeb3a8c4de29433a8d230ee600b13d369b6c0f git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 1fbeb3a8c4de29433a8d230ee600b13d369b6c0f # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=parisc If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): I must confess that I have no idea what I can do about these errors. Did the kernel maybe grow larger than can be handled by the PA-RISC toolchain? No, I assume it's because the function calls from the .init section are located too far away from the other code. Reason is probably because huge pages are selected and thus I tried to pack the init section so that it can get discarded after bootup. I'll look into it now... I think the only way to fix this in a clean way is to enable CONFIG_MLONGCALLS, which lets gcc use -mlong-calls compiler option and thus creates far calls. The problem is, that those calls are far more less performant, which one usually don't want to use in production kernels. In addition, typical Linux distribution kernels have most drivers built as modules and as such don't need this option. One way I can think of to work around that issue is, that if Kconfig detects that we build a test robot kernel, simply to enable this option. That way the test robot still builds everything. Is there a way to detect at compile/build time if the kernel is configured/built by the test robot? Is there maybe some config option or environment variable set which could be used? Maybe someone has another/better idea as well? Helge hppa64-linux-ld: init/main.o(.init.text+0xdd8): cannot reach rest_init init/main.o: in function `arch_call_rest_init': (.init.text+0xdd8): relocation truncated to fit: R_PARISC_PCREL22F against symbol `rest_init' defined in .ref.text section in init/main.o hppa64-linux-ld: init/main.o(.init.text+0x13d8): cannot reach build_all_zonelists init/main.o: in function `start_kernel': (.init.text+0x13d8): relocation truncated to fit: R_PARISC_PCREL22F against symbol `build_all_zonelists' defined in .ref.text section in mm/page_alloc.o hppa64-linux-ld: init/main.o(.init.text+0x176c): cannot reach profile_init (.init.text+0x176c): relocation truncated to fit: R_PARISC_PCREL22F against symbol `profile_init' defined in .ref.text section in kernel/profile.o hppa64-linux-ld: init/main.o(.init.text+0x1ac0): cannot reach wait_for_completion init/main.o: in function `kernel_init_freeable': (.init.text+0x1ac0): relocation truncated to fit: R_PARISC_PCREL22F against symbol `wait_for_completion' defined in .sched.text section in kernel/sched/completion.o hppa64-linux-ld: init/main.o(.ref.text+0x1c): cannot reach rcu_scheduler_starting init/main.o: in function `rest_init': (.ref.text+0x1c): relocation truncated to fit: R_PARISC_PCREL22F against symbol `rcu_scheduler_starting' defined in .init.text section in kernel/rcu/srcutiny.o hppa64-linux-ld: init/main.o(.ref.text+0x17c): cannot reach unknown init/main.o: in function `kernel_init': (.ref.text+0x17c): relocation truncated to fit: R_PARISC_PCREL22F against `kernel_init_freeable' hppa64-linux-ld: arch/parisc/mm/init.o(.ref.text+0x78): cannot reach unknown arch/parisc/mm/init.o: in function `free_initmem': (.ref.text+0x78): relocation truncated to fit: R_PARISC_PCREL22F against `map_pages' hppa64-linux-ld: arch/parisc/mm/init.o(.ref.text+0xa0): cannot reach unknown (.ref.text+0xa0): relocation truncated to fit: R_PARISC_PCREL22F against `map_pages' hppa64-linux-ld: arch/parisc/mm/init.o(.ref.text+0xc4): cannot reach unknown (.ref.tex
Re: [PATCH v2] binfmt_misc: Fix possible deadlock in bm_register_write
On 2/28/21 11:44 PM, Lior Ribak wrote:
There is a deadlock in bm_register_write:
First, in the beggining of the function, a lock is taken on the
binfmt_misc root inode with inode_lock(d_inode(root))
Then, if the user used the MISC_FMT_OPEN_FILE flag, the function will
call open_exec on the user-provided interpreter.
open_exec will call a path lookup, and if the path lookup process
includes the root of binfmt_misc, it will try to take a shared lock
on its inode again, but it is already locked, and the code will
get stuck in a deadlock
To reproduce the bug:
$ echo ":i:E::ii::/proc/sys/fs/binfmt_misc/bla:F" >
/proc/sys/fs/binfmt_misc/register
Yes, it's easily reproduceable with this command.
backtrace of where the lock occurs (#5):
0 schedule () at ./arch/x86/include/asm/current.h:15
1 0x81b51237 in rwsem_down_read_slowpath (sem=0x888003b202e0,
count=, state=state@entry=2) at kernel/locking/rwsem.c:992
2 0x81b5150a in __down_read_common (state=2, sem=) at
kernel/locking/rwsem.c:1213
3 __down_read (sem=) at kernel/locking/rwsem.c:1222
4 down_read (sem=) at kernel/locking/rwsem.c:1355
5 0x811ee22a in inode_lock_shared (inode=) at
./include/linux/fs.h:783
6 open_last_lookups (op=0xc922fe34, file=0x888004098600,
nd=0xc922fd10) at fs/namei.c:3177
7 path_openat (nd=nd@entry=0xc922fd10, op=op@entry=0xc922fe34,
flags=flags@entry=65) at fs/namei.c:3366
8 0x811efe1c in do_filp_open (dfd=,
pathname=pathname@entry=0x8880031b9000, op=op@entry=0xc922fe34) at
fs/namei.c:3396
9 0x811e493f in do_open_execat (fd=fd@entry=-100,
name=name@entry=0x8880031b9000, flags=, flags@entry=0) at
fs/exec.c:913
10 0x811e4a92 in open_exec (name=) at fs/exec.c:948
11 0x8124aa84 in bm_register_write (file=, buffer=, count=19, ppos=) at fs/binfmt_misc.c:682
12 0x811decd2 in vfs_write (file=file@entry=0x888004098500,
buf=buf@entry=0xa758d0 ":i:E::ii::i:CF\n", count=count@entry=19,
pos=pos@entry=0xc922ff10) at fs/read_write.c:603
13 0x811defda in ksys_write (fd=, buf=0xa758d0
":i:E::ii::i:CF\n", count=19) at fs/read_write.c:658
14 0x81b49813 in do_syscall_64 (nr=,
regs=0xc922ff58) at arch/x86/entry/common.c:46
15 0x81c0007c in entry_SYSCALL_64 () at arch/x86/entry/entry_64.S:120
To solve the issue, the open_exec call is moved to before the write
lock is taken by bm_register_write
Signed-off-by: Lior Ribak
Acked-by: Helge Deller
Thanks!
Helge
---
v2: Added "kfree(e)" above "return PTR_ERR(f)"
fs/binfmt_misc.c | 29 ++---
1 file changed, 14 insertions(+), 15 deletions(-)
diff --git a/fs/binfmt_misc.c b/fs/binfmt_misc.c
index c457334de43f..e1eae7ea823a 100644
--- a/fs/binfmt_misc.c
+++ b/fs/binfmt_misc.c
@@ -649,12 +649,24 @@ static ssize_t bm_register_write(struct file *file, const
char __user *buffer,
struct super_block *sb = file_inode(file)->i_sb;
struct dentry *root = sb->s_root, *dentry;
int err = 0;
+ struct file *f = NULL;
e = create_entry(buffer, count);
if (IS_ERR(e))
return PTR_ERR(e);
+ if (e->flags & MISC_FMT_OPEN_FILE) {
+ f = open_exec(e->interpreter);
+ if (IS_ERR(f)) {
+ pr_notice("register: failed to install interpreter file
%s\n",
+e->interpreter);
+ kfree(e);
+ return PTR_ERR(f);
+ }
+ e->interp_file = f;
+ }
+
inode_lock(d_inode(root));
dentry = lookup_one_len(e->name, root, strlen(e->name));
err = PTR_ERR(dentry);
@@ -678,21 +690,6 @@ static ssize_t bm_register_write(struct file *file, const
char __user *buffer,
goto out2;
}
- if (e->flags & MISC_FMT_OPEN_FILE) {
- struct file *f;
-
- f = open_exec(e->interpreter);
- if (IS_ERR(f)) {
- err = PTR_ERR(f);
- pr_notice("register: failed to install interpreter file
%s\n", e->interpreter);
- simple_release_fs(_mnt, _count);
- iput(inode);
- inode = NULL;
- goto out2;
- }
- e->interp_file = f;
- }
-
e->dentry = dget(dentry);
inode->i_private = e;
inode->i_fop = _entry_operations;
@@ -709,6 +706,8 @@ static ssize_t bm_register_write(struct file *file, const
char __user *buffer,
inode_unlock(d_inode(root));
if (err) {
+ if (f)
+ filp_close(f, NULL);
kfree(e);
return err;
}
Re: hppa64-linux-ld: kernel/rcu/refscale.o(.init.text+0x228): cannot reach schedule_timeout_uninterruptible
Adding parisc-parisc mailing list... On 2/28/21 6:05 AM, Paul E. McKenney wrote: On Sun, Feb 28, 2021 at 12:08:08PM +0800, kernel test robot wrote: Hi Paul, First bad commit (maybe != root cause): tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 5695e51619745d4fe3ec2506a2f0cd982c5e27a4 commit: 1fbeb3a8c4de29433a8d230ee600b13d369b6c0f refperf: Rename refperf.c to refscale.c and change internal names date: 8 months ago config: parisc-randconfig-s031-20210228 (attached as .config) compiler: hppa64-linux-gcc (GCC) 9.3.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # apt-get install sparse # sparse version: v0.6.3-241-geaceeafa-dirty # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1fbeb3a8c4de29433a8d230ee600b13d369b6c0f git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 1fbeb3a8c4de29433a8d230ee600b13d369b6c0f # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=parisc If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): I must confess that I have no idea what I can do about these errors. Did the kernel maybe grow larger than can be handled by the PA-RISC toolchain? No, I assume it's because the function calls from the .init section are located too far away from the other code. Reason is probably because huge pages are selected and thus I tried to pack the init section so that it can get discarded after bootup. I'll look into it now... Helge Thanx, Paul hppa64-linux-ld: init/main.o(.init.text+0xdd8): cannot reach rest_init init/main.o: in function `arch_call_rest_init': (.init.text+0xdd8): relocation truncated to fit: R_PARISC_PCREL22F against symbol `rest_init' defined in .ref.text section in init/main.o hppa64-linux-ld: init/main.o(.init.text+0x13d8): cannot reach build_all_zonelists init/main.o: in function `start_kernel': (.init.text+0x13d8): relocation truncated to fit: R_PARISC_PCREL22F against symbol `build_all_zonelists' defined in .ref.text section in mm/page_alloc.o hppa64-linux-ld: init/main.o(.init.text+0x176c): cannot reach profile_init (.init.text+0x176c): relocation truncated to fit: R_PARISC_PCREL22F against symbol `profile_init' defined in .ref.text section in kernel/profile.o hppa64-linux-ld: init/main.o(.init.text+0x1ac0): cannot reach wait_for_completion init/main.o: in function `kernel_init_freeable': (.init.text+0x1ac0): relocation truncated to fit: R_PARISC_PCREL22F against symbol `wait_for_completion' defined in .sched.text section in kernel/sched/completion.o hppa64-linux-ld: init/main.o(.ref.text+0x1c): cannot reach rcu_scheduler_starting init/main.o: in function `rest_init': (.ref.text+0x1c): relocation truncated to fit: R_PARISC_PCREL22F against symbol `rcu_scheduler_starting' defined in .init.text section in kernel/rcu/srcutiny.o hppa64-linux-ld: init/main.o(.ref.text+0x17c): cannot reach unknown init/main.o: in function `kernel_init': (.ref.text+0x17c): relocation truncated to fit: R_PARISC_PCREL22F against `kernel_init_freeable' hppa64-linux-ld: arch/parisc/mm/init.o(.ref.text+0x78): cannot reach unknown arch/parisc/mm/init.o: in function `free_initmem': (.ref.text+0x78): relocation truncated to fit: R_PARISC_PCREL22F against `map_pages' hppa64-linux-ld: arch/parisc/mm/init.o(.ref.text+0xa0): cannot reach unknown (.ref.text+0xa0): relocation truncated to fit: R_PARISC_PCREL22F against `map_pages' hppa64-linux-ld: arch/parisc/mm/init.o(.ref.text+0xc4): cannot reach unknown (.ref.text+0xc4): relocation truncated to fit: R_PARISC_PCREL22F against `map_pages' hppa64-linux-ld: kernel/printk/printk.o(.init.text+0x768): cannot reach _raw_spin_lock kernel/printk/printk.o: in function `setup_log_buf': (.init.text+0x768): relocation truncated to fit: R_PARISC_PCREL22F against symbol `_raw_spin_lock' defined in .spinlock.text section in kernel/locking/spinlock.o hppa64-linux-ld: kernel/printk/printk.o(.init.text+0x7c4): cannot reach _raw_spin_unlock (.init.text+0x7c4): additional relocation overflows omitted from the output hppa64-linux-ld: kernel/cgroup/cgroup.o(.init.text+0x228): cannot reach mutex_lock hppa64-linux-ld: kernel/cgroup/cgroup.o(.init.text+0x440): cannot reach mutex_unlock hppa64-linux-ld: kernel/cgroup/cgroup.o(.init.text+0x7a0): cannot reach mutex_lock hppa64-linux-ld: kernel/cgroup/cgroup.o(.init.text+0x878): cannot reach
Re: [PATCH printk-rework 08/14] printk: add syslog_lock
On 2/23/21 3:23 PM, Petr Mladek wrote:
On Tue 2021-02-23 13:22:22, Helge Deller wrote:
On 2/22/21 5:28 PM, Petr Mladek wrote:
On Sun 2021-02-21 22:39:42, Helge Deller wrote:
On 2/19/21 5:33 PM, John Ogness wrote:
Added CC: linux-par...@vger.kernel.org
On 2021-02-19, John Ogness wrote:
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 20c21a25143d..401df370832b 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
+/* Return a consistent copy of @syslog_seq. */
+static u64 read_syslog_seq_irq(void)
+{
+ u64 seq;
+
+ raw_spin_lock_irq(_lock);
+ seq = syslog_seq;
+ raw_spin_unlock_irq(_lock);
Is there any particular reason to disable interrupts here?
I found a possible call chain in interrupt context. From arch/parisc
there is the interrupt handler:
Yes, handle_interruption() is the irq handler, running with irqs off.
HPMC is the crash handler - it's called when the kernel will stop
anyway. pdc_console is a very basic firmware console which prints
the last messages before the machine halts on fatal errors.
So, this code it's not the typical use case
Thanks for information.
Is this code supposed to work only during early boot or anytime,
please?
No.
It's only called when the kernel completely crashes, when all
spinlocks should get busted and so on.
It's the emergency way to get some info out at least.
OK.
Note that it is not safe because register_console() takes
console_lock() which is a sleeping lock.
As I said, in that stage the plan is to bust all spinlocks.
Just to be sure. Note that that register_console() does not bust
console_lock in panic.
Ok.
bust_spinlocks() just increments oops_in_progress counter. It has
effect only when the caller checks this variable and use trylock
when it is set. For example, see serial8250_console_write():
void serial8250_console_write(struct uart_8250_port *up, const char *s,
unsigned int count)
{
int locked = 1;
if (oops_in_progress)
locked = spin_trylock_irqsave(>lock, flags);
else
spin_lock_irqsave(>lock, flags);
...
if (locked)
spin_unlock_irqrestore(>lock, flags);
}
register_console() does not check oops_in_progress at the moment
and might get blocked on console_sem.
We could add the checks for oops_in_progress into register_console().
But I am not sure if it is worth it.
It's not worth it just because of parisc.
I haven't seen any such crash in years, so the current implementation
is probably untested and outdated.
It seems that you used this code for ages. The risk of the deadlock
is small. It likely works most of the time. The upcoming printk rework
should allow a cleaner solution.
Yes, it would be great if you can include such a "hard-panic/crash-dump-case"
in the rework.
Helge
Re: [PATCH printk-rework 08/14] printk: add syslog_lock
On 2/22/21 5:28 PM, Petr Mladek wrote:
On Sun 2021-02-21 22:39:42, Helge Deller wrote:
On 2/19/21 5:33 PM, John Ogness wrote:
Added CC: linux-par...@vger.kernel.org
On 2021-02-19, John Ogness wrote:
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 20c21a25143d..401df370832b 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
+/* Return a consistent copy of @syslog_seq. */
+static u64 read_syslog_seq_irq(void)
+{
+ u64 seq;
+
+ raw_spin_lock_irq(_lock);
+ seq = syslog_seq;
+ raw_spin_unlock_irq(_lock);
Is there any particular reason to disable interrupts here?
It would make sense only when the lock could be taken in IRQ
context. Then we would need to always disable interrupts when
the lock is taken. And if it is taken in IRQ context, we would
need to safe flags.
All other instances of locking @syslog_lock are done with interrupts
disabled. And we have:
register_console()
logbuf_lock_irqsave()
raw_spin_lock(_lock)
I suppose I need to go through all the console drivers to see if any
register in interrupt context. If not, that logbuf_lock_irqsave()
should be replaced with logbuf_lock_irq(). And then locking
@syslog_lock will not need to disable interrupts.
I found a possible call chain in interrupt context. From arch/parisc
there is the interrupt handler:
handle_interruption(code=1) /* High-priority machine check (HPMC) */
pdc_console_restart()
pdc_console_init_force()
register_console()
All other register_console() calls in the kernel are either during init
(within __init sections and probe functions) or are clearly not in
interrupt context (using mutex, kzalloc, spin_lock_irq, etc).
I am not familiar with parisc, but I am assuming handle_interruption()
is always called with interrupts disabled (unless the HPMC interrupt is
somehow an exception).
Yes, handle_interruption() is the irq handler, running with irqs off.
HPMC is the crash handler - it's called when the kernel will stop
anyway. pdc_console is a very basic firmware console which prints
the last messages before the machine halts on fatal errors.
So, this code it's not the typical use case
Thanks for information.
Is this code supposed to work only during early boot or anytime,
please?
No.
It's only called when the kernel completely crashes, when all
spinlocks should get busted and so on.
It's the emergency way to get some info out at least.
Note that it is not safe because register_console() takes
console_lock() which is a sleeping lock.
As I said, in that stage the plan is to bust all spinlocks.
That said, we are going to rework the console handling a lot. We are
trying to remove as many locks from the printk path as possible.
That's good!
I guess that the list of consoles will be synchronized using
rcu at the end. But it is still a long way to go.
I'd say, that you simply should ignore this specific case here.
I'm happy to change anything there, so if you get rid of printk locks
it will benefit here too.
Helge
Re: [PATCH printk-rework 08/14] printk: add syslog_lock
On 2/19/21 5:33 PM, John Ogness wrote:
Added CC: linux-par...@vger.kernel.org
On 2021-02-19, John Ogness wrote:
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 20c21a25143d..401df370832b 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
+/* Return a consistent copy of @syslog_seq. */
+static u64 read_syslog_seq_irq(void)
+{
+ u64 seq;
+
+ raw_spin_lock_irq(_lock);
+ seq = syslog_seq;
+ raw_spin_unlock_irq(_lock);
Is there any particular reason to disable interrupts here?
It would make sense only when the lock could be taken in IRQ
context. Then we would need to always disable interrupts when
the lock is taken. And if it is taken in IRQ context, we would
need to safe flags.
All other instances of locking @syslog_lock are done with interrupts
disabled. And we have:
register_console()
logbuf_lock_irqsave()
raw_spin_lock(_lock)
I suppose I need to go through all the console drivers to see if any
register in interrupt context. If not, that logbuf_lock_irqsave()
should be replaced with logbuf_lock_irq(). And then locking
@syslog_lock will not need to disable interrupts.
I found a possible call chain in interrupt context. From arch/parisc
there is the interrupt handler:
handle_interruption(code=1) /* High-priority machine check (HPMC) */
pdc_console_restart()
pdc_console_init_force()
register_console()
All other register_console() calls in the kernel are either during init
(within __init sections and probe functions) or are clearly not in
interrupt context (using mutex, kzalloc, spin_lock_irq, etc).
I am not familiar with parisc, but I am assuming handle_interruption()
is always called with interrupts disabled (unless the HPMC interrupt is
somehow an exception).
Yes, handle_interruption() is the irq handler, running with irqs off.
HPMC is the crash handler - it's called when the kernel will stop
anyway. pdc_console is a very basic firmware console which prints
the last messages before the machine halts on fatal errors.
So, this code it's not the typical use case
Helge
[GIT PULL] parisc architecture updates for kernel v5.12-rc1
Hi Linus, please pull the parisc architecture updates for kernel 5.12-rc1 from: http://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git parisc-5.12-1 Updates include: * Optimize parisc page table locks by using the existing page_table_lock * Export argv0-preserve flag in binfmt_misc for usage in qemu-user * Fix interrupt table (IVT) checksum so firmware will call crash handler (HPMC) * Increase IRQ stack to 64kb on 64-bit kernel * Switch to common devmem_is_allowed() implementation * Minor fix to get_whan() Thanks, Helge Helge Deller (3): parisc: Drop out of get_whan() if task is running again parisc: Use the generic devmem_is_allowed() parisc: Optimize per-pagetable spinlocks John David Anglin (1): parisc: Bump 64-bit IRQ stack size to 64 KB Laurent Vivier (1): binfmt_misc: pass binfmt_misc flags to the interpreter Sven Schnelle (1): parisc: Fix IVT checksum calculation wrt HPMC Tiezhu Yang (1): parisc: Replace test_ti_thread_flag() with test_tsk_thread_flag() arch/parisc/Kconfig | 11 arch/parisc/include/asm/compat.h | 2 +- arch/parisc/include/asm/io.h | 2 + arch/parisc/include/asm/mmu_context.h | 7 ++ arch/parisc/include/asm/page.h| 2 +- arch/parisc/include/asm/pgalloc.h | 76 ++ arch/parisc/include/asm/pgtable.h | 89 ++ arch/parisc/kernel/asm-offsets.c | 1 - arch/parisc/kernel/entry.S| 116 +++--- arch/parisc/kernel/hpmc.S | 10 --- arch/parisc/kernel/irq.c | 4 ++ arch/parisc/kernel/process.c | 2 + arch/parisc/kernel/traps.c| 9 +-- arch/parisc/mm/hugetlbpage.c | 13 arch/parisc/mm/init.c | 10 +-- fs/binfmt_elf.c | 5 +- fs/binfmt_elf_fdpic.c | 5 +- fs/binfmt_misc.c | 4 +- include/linux/binfmts.h | 4 ++ include/uapi/linux/binfmts.h | 4 ++ 20 files changed, 141 insertions(+), 235 deletions(-)
Re: [PATCH v3] binfmt_misc: pass binfmt_misc flags to the interpreter
On 6/5/20 6:20 PM, Laurent Vivier wrote: Le 28/01/2020 à 14:25, Laurent Vivier a écrit : It can be useful to the interpreter to know which flags are in use. For instance, knowing if the preserve-argv[0] is in use would allow to skip the pathname argument. This patch uses an unused auxiliary vector, AT_FLAGS, to add a flag to inform interpreter if the preserve-argv[0] is enabled. Signed-off-by: Laurent Vivier Acked-by: Helge Deller If nobody objects, I'd like to take this patch through the parisc arch git tree. It fixes a real-world problem with qemu-user which fails to preserve the argv[0] argument when the callee of an exec is a qemu-user target. This problem leads to build errors on multiple Debian buildd servers which are using qemu-user as emulation for the target machines. For details see Debian bug: http://bugs.debian.org/970460 Helge --- Notes: This can be tested with QEMU from my branch: https://github.com/vivier/qemu/commits/binfmt-argv0 With something like: # cp /qemu-ppc /chroot/powerpc/jessie # qemu-binfmt-conf.sh --qemu-path / --systemd ppc --credential yes \ --persistent no --preserve-argv0 yes # systemctl restart systemd-binfmt.service # cat /proc/sys/fs/binfmt_misc/qemu-ppc enabled interpreter //qemu-ppc flags: POC offset 0 magic 7f454c46010201020014 mask ff00fffe # chroot /chroot/powerpc/jessie sh -c 'echo $0' sh # qemu-binfmt-conf.sh --qemu-path / --systemd ppc --credential yes \ --persistent no --preserve-argv0 no # systemctl restart systemd-binfmt.service # cat /proc/sys/fs/binfmt_misc/qemu-ppc enabled interpreter //qemu-ppc flags: OC offset 0 magic 7f454c46010201020014 mask ff00fffe # chroot /chroot/powerpc/jessie sh -c 'echo $0' /bin/sh v3: mix my patch with one from YunQiang Su and my comments on it introduce a new flag in the uabi for the AT_FLAGS v2: only pass special flags (remove Magic and Enabled flags) fs/binfmt_elf.c | 5 - fs/binfmt_elf_fdpic.c| 5 - fs/binfmt_misc.c | 4 +++- include/linux/binfmts.h | 4 include/uapi/linux/binfmts.h | 4 5 files changed, 19 insertions(+), 3 deletions(-) diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c index ecd8d2698515..ff918042ceed 100644 --- a/fs/binfmt_elf.c +++ b/fs/binfmt_elf.c @@ -176,6 +176,7 @@ create_elf_tables(struct linux_binprm *bprm, struct elfhdr *exec, unsigned char k_rand_bytes[16]; int items; elf_addr_t *elf_info; + elf_addr_t flags = 0; int ei_index = 0; const struct cred *cred = current_cred(); struct vm_area_struct *vma; @@ -250,7 +251,9 @@ create_elf_tables(struct linux_binprm *bprm, struct elfhdr *exec, NEW_AUX_ENT(AT_PHENT, sizeof(struct elf_phdr)); NEW_AUX_ENT(AT_PHNUM, exec->e_phnum); NEW_AUX_ENT(AT_BASE, interp_load_addr); - NEW_AUX_ENT(AT_FLAGS, 0); + if (bprm->interp_flags & BINPRM_FLAGS_PRESERVE_ARGV0) + flags |= AT_FLAGS_PRESERVE_ARGV0; + NEW_AUX_ENT(AT_FLAGS, flags); NEW_AUX_ENT(AT_ENTRY, exec->e_entry); NEW_AUX_ENT(AT_UID, from_kuid_munged(cred->user_ns, cred->uid)); NEW_AUX_ENT(AT_EUID, from_kuid_munged(cred->user_ns, cred->euid)); diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c index 240f3543..abb90d82aa58 100644 --- a/fs/binfmt_elf_fdpic.c +++ b/fs/binfmt_elf_fdpic.c @@ -507,6 +507,7 @@ static int create_elf_fdpic_tables(struct linux_binprm *bprm, char __user *u_platform, *u_base_platform, *p; int loop; int nr; /* reset for each csp adjustment */ + unsigned long flags = 0; #ifdef CONFIG_MMU /* In some cases (e.g. Hyper-Threading), we want to avoid L1 evictions @@ -647,7 +648,9 @@ static int create_elf_fdpic_tables(struct linux_binprm *bprm, NEW_AUX_ENT(AT_PHENT, sizeof(struct elf_phdr)); NEW_AUX_ENT(AT_PHNUM, exec_params->hdr.e_phnum); NEW_AUX_ENT(AT_BASE,interp_params->elfhdr_addr); - NEW_AUX_ENT(AT_FLAGS, 0); + if (bprm->interp_flags & BINPRM_FLAGS_PRESERVE_ARGV0) + flags |= AT_FLAGS_PRESERVE_ARGV0; + NEW_AUX_ENT(AT_FLAGS, flags); NEW_AUX_ENT(AT_ENTRY, exec_params->entry_addr); NEW_AUX_ENT(AT_UID, (elf_addr_t) from_kuid_munged(cred->user_ns, cred->uid)); NEW_AUX_ENT(AT_EUID,(elf_addr_t) from_kuid_munged(cred->user_ns, cred->euid)); diff --git a/fs/binfmt_misc.c b/fs/binfmt_misc.c index cdb45829354d..b9acdd26a654 100644 --- a/fs/binfmt_misc.c +++ b/fs/binfmt_misc.c @@ -154,7 +154,9 @@ static int load_mi
Re: [PATCH] parisc: Replace test_ti_thread_flag() with test_tsk_thread_flag()
On 2/3/21 6:27 AM, Tiezhu Yang wrote:
> Use test_tsk_thread_flag() directly instead of test_ti_thread_flag() to
> improve readability when the argument type is struct task_struct, it is
> similar with commit 5afc78551bf5 ("arm64: Use test_tsk_thread_flag() for
> checking TIF_SINGLESTEP").
>
> Signed-off-by: Tiezhu Yang
Thanks!
Applied to the parisc git tree.
Helge
> ---
> arch/parisc/include/asm/compat.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/parisc/include/asm/compat.h
> b/arch/parisc/include/asm/compat.h
> index 8f33085..1a609d3 100644
> --- a/arch/parisc/include/asm/compat.h
> +++ b/arch/parisc/include/asm/compat.h
> @@ -179,7 +179,7 @@ static __inline__ void __user
> *arch_compat_alloc_user_space(long len)
>
> static inline int __is_compat_task(struct task_struct *t)
> {
> - return test_ti_thread_flag(task_thread_info(t), TIF_32BIT);
> + return test_tsk_thread_flag(t, TIF_32BIT);
> }
>
> static inline int is_compat_task(void)
>
[GIT PULL] parisc architecture updates for kernel v5.11-rc6
Hi Linus, please pull two fixes for the parisc architecture for kernel 5.11-rc6 from: http://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git parisc-5.11-2 Two small fixes: * Fix linking error with 64-bit kernel when modules are disabled, reported by kernel test robot. * Remove leftover reference to power_tasklet, by Davidlohr Bueso Thanks, Helge Davidlohr Bueso (1): parisc: Remove leftover reference to the power_tasklet Helge Deller (1): parisc: Enable -mlong-calls gcc option by default when !CONFIG_MODULES arch/parisc/Kconfig | 5 ++--- arch/parisc/include/asm/irq.h | 3 --- arch/parisc/kernel/entry.S| 13 ++--- 3 files changed, 12 insertions(+), 9 deletions(-)
Re: hppa64-linux-ld: mm/hugetlb.o(.text+0x50dc): cannot reach printk
On 1/25/21 7:34 PM, John David Anglin wrote: > For calls, this issue can be avoided with -mlong-calls option. Without this, > 64-bit calls are limited to > a 22-bit pc-relative offset (8 MB). This does make branches somewhat less > efficient. At the moment, > the 64-bit linker does not support adding branch extending stubs. > > Thunks are currently limited to a 17-bit pc-relative offset. When using huge pages, I've tried to set up a lds layout in which all init functions are in one page which can be deleted afterwards. I assume that's why they can't be reached. I'll look into the issue if I can reproduce it. Will keep you updated. Helge > Regards, > Dave > > On 2021-01-25 12:54 p.m., Nick Desaulniers wrote: >> I suspect that adding some more sections here makes the distance >> between other sections too large to encode? IIRC, arm (32b) linker >> can emit "range extending thunks" to help jump large distances. Not >> sure what to make of this report; I wouldn't have expected this GCC >> randconfig to generate code in any of the sections that were added to >> the linkerscript in >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=eff8728fe69880d3f7983bec3fb6cea4c306261f. >> >> On Sat, Jan 16, 2021 at 6:37 AM kernel test robot wrote: >>> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git >>> master >>> head: 1d94330a437a573cfdf848f6743b1ed169242c8a >>> commit: eff8728fe69880d3f7983bec3fb6cea4c306261f vmlinux.lds.h: Add PGO and >>> AutoFDO input sections >>> date: 5 months ago >>> config: parisc-randconfig-r032-20210116 (attached as .config) >>> compiler: hppa64-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://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=eff8728fe69880d3f7983bec3fb6cea4c306261f >>> git remote add linus >>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git >>> git fetch --no-tags linus master >>> git checkout eff8728fe69880d3f7983bec3fb6cea4c306261f >>> # save the attached .config to linux build tree >>> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross >>> ARCH=parisc >>> >>> If you fix the issue, kindly add following tag as appropriate >>> Reported-by: kernel test robot >>> >>> All errors (new ones prefixed by >>): >>> >>>hppa64-linux-ld: mm/page_alloc.o(.ref.text+0x110): cannot reach unknown >>>hppa64-linux-ld: mm/memblock.o(.text+0x27c): cannot reach __warn_printk >>>hppa64-linux-ld: mm/memblock.o(.meminit.text+0xc4): cannot reach printk >>>hppa64-linux-ld: mm/memblock.o(.meminit.text+0x140): cannot reach printk >>>hppa64-linux-ld: mm/memblock.o(.meminit.text+0x1e0): cannot reach memmove >>>hppa64-linux-ld: mm/memblock.o(.meminit.text+0x314): cannot reach memmove >>>hppa64-linux-ld: mm/memblock.o(.meminit.text+0x428): cannot reach memmove >>>hppa64-linux-ld: mm/memblock.o(.meminit.text+0x5d4): cannot reach >>> __warn_printk >>>hppa64-linux-ld: mm/memblock.o(.meminit.text+0xb20): cannot reach printk >>>hppa64-linux-ld: mm/memblock.o(.meminit.text+0xce8): cannot reach printk >>>hppa64-linux-ld: mm/memblock.o(.meminit.text+0xd30): cannot reach printk >>>hppa64-linux-ld: mm/memblock.o(.meminit.text+0xd4c): cannot reach memcpy >>>hppa64-linux-ld: mm/memblock.o(.meminit.text+0x1130): cannot reach printk >>>hppa64-linux-ld: mm/memblock.o(.meminit.text+0x11e0): cannot reach printk >>>hppa64-linux-ld: mm/memblock.o(.meminit.text+0x16d8): cannot reach printk >>>hppa64-linux-ld: mm/memblock.o(.meminit.text+0x1788): cannot reach printk >>>hppa64-linux-ld: mm/memblock.o(.meminit.text+0x1e04): cannot reach printk >>>hppa64-linux-ld: mm/memblock.o(.meminit.text+0x1e2c): cannot reach printk >>>hppa64-linux-ld: mm/memblock.o(.init.text+0x24): cannot reach strstr >>>hppa64-linux-ld: mm/memblock.o(.init.text+0x100): cannot reach >>> __warn_printk >>>hppa64-linux-ld: mm/memblock.o(.init.text+0x118): cannot reach dump_stack >>>hppa64-linux-ld: mm/memblock.o(.init.text+0x220): cannot reach printk >>>hppa64-linux-ld: mm/memblock.o(.init.text+0x48c): cannot reach printk >>>hppa64-linux-ld: mm/memblock.o(.init.text+0x55c): cannot reach printk >>>hppa64-linux-ld: mm/memblock.o(.init.text+0x62c): cannot reach printk >>>hppa64-linux-ld: mm/memblock.o(.init.text+0x720): cannot reach printk >>>hppa64-linux-ld: mm/hugetlb.o(.text+0x4cc): cannot reach _raw_spin_lock >>>hppa64-linux-ld: mm/hugetlb.o(.text+0x580): cannot reach _raw_spin_unlock >>>hppa64-linux-ld: mm/hugetlb.o(.text+0x690): cannot reach _raw_spin_unlock >>>hppa64-linux-ld: mm/hugetlb.o(.text+0x768): cannot reach _raw_spin_unlock >>>hppa64-linux-ld: mm/hugetlb.o(.text+0x7c8):
Re: hppa64-linux-ld: mm/hugetlb.o(.text+0x50dc): cannot reach printk
On 1/25/21 10:08 PM, John David Anglin wrote: > I would suggest the following for this hunk: > > + ldil L%intr_restore, %r2 > + BL preempt_schedule_irq > + ldo R%intr_restore(%r2), %r2 > > ldil L%intr_restore, %r1 > b,l preempt_schedule_irq,%r2 > ldo R%intr_restore(%r1), %r2 > > On PA 2.0 hardware that gives a 22-bit call. "BL" is already using "b,l", see #define in arch/parisc/include/asm/assembly.h The 22-bit weren't sufficient, that's why I changed it too. Helge
Re: hppa64-linux-ld: mm/hugetlb.o(.text+0x50dc): cannot reach printk
On 1/25/21 10:17 PM, John David Anglin wrote: > On 2021-01-25 4:13 p.m., Helge Deller wrote: >> On 1/25/21 10:08 PM, John David Anglin wrote: >>> I would suggest the following for this hunk: >>> >>> + ldil L%intr_restore, %r2 >>> + BL preempt_schedule_irq >>> + ldo R%intr_restore(%r2), %r2 >>> >>> ldil L%intr_restore, %r1 >>> b,l preempt_schedule_irq,%r2 >>> ldo R%intr_restore(%r1), %r2 >>> >>> On PA 2.0 hardware that gives a 22-bit call. >> "BL" is already using "b,l", see #define in >> arch/parisc/include/asm/assembly.h >> >> The 22-bit weren't sufficient, that's why I changed it too. > Okay but "b,l" only provides a 22-bit branch with %r2 as link register. Argh. Yes. Didn't know. We have BL,%r25 in the same file. > You also need to use %r1 in the ldil and ldo instructions. Ok, will fix. Helge
Re: hppa64-linux-ld: mm/hugetlb.o(.text+0x50dc): cannot reach printk
On 1/25/21 9:58 PM, Nick Desaulniers wrote: > On Mon, Jan 25, 2021 at 12:47 PM Helge Deller wrote: >> >>>>> On Sat, Jan 16, 2021 at 6:37 AM kernel test robot wrote: >>>>>> tree: >>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master >>>>>> head: 1d94330a437a573cfdf848f6743b1ed169242c8a >>>>>> commit: eff8728fe69880d3f7983bec3fb6cea4c306261f vmlinux.lds.h: Add PGO >>>>>> and AutoFDO input sections >>>>>> date: 5 months ago >>>>>> config: parisc-randconfig-r032-20210116 (attached as .config) >>>>>> compiler: hppa64-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://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=eff8728fe69880d3f7983bec3fb6cea4c306261f >>>>>> git remote add linus >>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git >>>>>> git fetch --no-tags linus master >>>>>> git checkout eff8728fe69880d3f7983bec3fb6cea4c306261f >>>>>> # save the attached .config to linux build tree >>>>>> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross >>>>>> ARCH=parisc >>>>>> >>>>>> If you fix the issue, kindly add following tag as appropriate >>>>>> Reported-by: kernel test robot >>>>>> >>>>>> All errors (new ones prefixed by >>): >>>>>> >>>>>>hppa64-linux-ld: mm/page_alloc.o(.ref.text+0x110): cannot reach >>>>>> unknown >>>>>>hppa64-linux-ld: mm/memblock.o(.text+0x27c): cannot reach >>>>>> __warn_printk >>>>>>hppa64-linux-ld: mm/memblock.o(.meminit.text+0xc4): cannot reach >>>>>> printk >> >> >> The problem with this .config is, that both CONFIG_MODULES and >> CONFIG_MLONGCALLS are set to "n". >> The Kconfig autodetection needs fixing to enable CONFIG_MLONGCALLS in >> this case. >> >> >> This patch fixes it for me: >> >> [PATCH] Require -mlong-calls gcc option for !CONFIG_MODULES >> >> When building a kernel without module support, the CONFIG_MLONGCALL >> option needs to be enabled. This patch fixes the autodetection in the >> Kconfig script and uses a far call to preempt_schedule_irq() in >> intr_do_preempt(). >> >> Signed-off-by: Helge Deller >> Reported-by: kernel test robot >> >> --- >> >> diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig >> index 78b17621ee4a..278462186ac4 100644 >> --- a/arch/parisc/Kconfig >> +++ b/arch/parisc/Kconfig >> @@ -202,9 +202,8 @@ config PREFETCH >> depends on PA8X00 || PA7200 >> >> config MLONGCALLS >> - bool "Enable the -mlong-calls compiler option for big kernels" >> - default y if !MODULES || UBSAN || FTRACE >> - default n >> + def_bool y if !MODULES || UBSAN || FTRACE >> + bool "Enable the -mlong-calls compiler option for big kernels" if >> MODULES && !UBSAN && !FTRACE > > ^ this looks like the same constraints specified twice? Am I > understanding that correctly? (I don't understand why this isn't > specified _once_). The logic is: - if (!MODULES || UBSAN || FTRACE) then don't ask and always set to Y, - otherwise show menu entry but leave default as N. If this can be done in one line I'm happy to correct it. Helge
Re: hppa64-linux-ld: mm/hugetlb.o(.text+0x50dc): cannot reach printk
On 1/25/21 9:47 PM, Helge Deller wrote: >>>> On Sat, Jan 16, 2021 at 6:37 AM kernel test robot wrote: >>>>> tree: >>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master >>>>> head: 1d94330a437a573cfdf848f6743b1ed169242c8a >>>>> commit: eff8728fe69880d3f7983bec3fb6cea4c306261f vmlinux.lds.h: Add PGO >>>>> and AutoFDO input sections >>>>> date: 5 months ago >>>>> config: parisc-randconfig-r032-20210116 (attached as .config) >>>>> compiler: hppa64-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://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=eff8728fe69880d3f7983bec3fb6cea4c306261f >>>>> git remote add linus >>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git >>>>> git fetch --no-tags linus master >>>>> git checkout eff8728fe69880d3f7983bec3fb6cea4c306261f >>>>> # save the attached .config to linux build tree >>>>> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross >>>>> ARCH=parisc >>>>> >>>>> If you fix the issue, kindly add following tag as appropriate >>>>> Reported-by: kernel test robot >>>>> >>>>> All errors (new ones prefixed by >>): >>>>> >>>>>hppa64-linux-ld: mm/page_alloc.o(.ref.text+0x110): cannot reach unknown >>>>>hppa64-linux-ld: mm/memblock.o(.text+0x27c): cannot reach __warn_printk >>>>>hppa64-linux-ld: mm/memblock.o(.meminit.text+0xc4): cannot reach printk > > > The problem with this .config is, that both CONFIG_MODULES and > CONFIG_MLONGCALLS are set to "n". > The Kconfig autodetection needs fixing to enable CONFIG_MLONGCALLS in > this case. > > > This patch fixes it for me: > > [PATCH] Require -mlong-calls gcc option for !CONFIG_MODULES > > When building a kernel without module support, the CONFIG_MLONGCALL > option needs to be enabled. This patch fixes the autodetection in the > Kconfig script and uses a far call to preempt_schedule_irq() in > intr_do_preempt(). > > Signed-off-by: Helge Deller > Reported-by: kernel test robot There's a small bug in the code below: BL preempt_schedule_irq needs to be BL preempt_schedule_irq, %r0 I'll do some more testing and will push the final version through the parisc tree. Helge > --- > > diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig > index 78b17621ee4a..278462186ac4 100644 > --- a/arch/parisc/Kconfig > +++ b/arch/parisc/Kconfig > @@ -202,9 +202,8 @@ config PREFETCH > depends on PA8X00 || PA7200 > > config MLONGCALLS > - bool "Enable the -mlong-calls compiler option for big kernels" > - default y if !MODULES || UBSAN || FTRACE > - default n > + def_bool y if !MODULES || UBSAN || FTRACE > + bool "Enable the -mlong-calls compiler option for big kernels" if > MODULES && !UBSAN && !FTRACE > depends on PA8X00 > help > If you configure the kernel to include many drivers built-in instead > diff --git a/arch/parisc/kernel/entry.S b/arch/parisc/kernel/entry.S > index beba9816cc6c..6320f6a8397c 100644 > --- a/arch/parisc/kernel/entry.S > +++ b/arch/parisc/kernel/entry.S > @@ -997,10 +997,19 @@ intr_do_preempt: > bb,<,n %r20, 31 - PSW_SM_I, intr_restore > nop > > - BL preempt_schedule_irq, %r2 > - nop > + /* ssm PSW_SM_I done later in intr_restore */ > +#ifdef CONFIG_MLONGCALLS > + ldilL%intr_restore, %r2 > + load32 preempt_schedule_irq, %r1 > + bv %r0(%r1) > + ldo R%intr_restore(%r2), %r2 > +#else > + ldilL%intr_restore, %r2 > + BL preempt_schedule_irq > + ldo R%intr_restore(%r2), %r2 > +#endif > + > > - b,n intr_restore/* ssm PSW_SM_I done by intr_restore */ > #endif /* CONFIG_PREEMPTION */ > > /* > >
Re: hppa64-linux-ld: mm/hugetlb.o(.text+0x50dc): cannot reach printk
> >> On Sat, Jan 16, 2021 at 6:37 AM kernel test robot wrote: > >>> tree: > >>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master > >>> head: 1d94330a437a573cfdf848f6743b1ed169242c8a > >>> commit: eff8728fe69880d3f7983bec3fb6cea4c306261f vmlinux.lds.h: Add PGO > >>> and AutoFDO input sections > >>> date: 5 months ago > >>> config: parisc-randconfig-r032-20210116 (attached as .config) > >>> compiler: hppa64-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://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=eff8728fe69880d3f7983bec3fb6cea4c306261f > >>> git remote add linus > >>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > >>> git fetch --no-tags linus master > >>> git checkout eff8728fe69880d3f7983bec3fb6cea4c306261f > >>> # save the attached .config to linux build tree > >>> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross > >>> ARCH=parisc > >>> > >>> If you fix the issue, kindly add following tag as appropriate > >>> Reported-by: kernel test robot > >>> > >>> All errors (new ones prefixed by >>): > >>> > >>>hppa64-linux-ld: mm/page_alloc.o(.ref.text+0x110): cannot reach unknown > >>>hppa64-linux-ld: mm/memblock.o(.text+0x27c): cannot reach __warn_printk > >>>hppa64-linux-ld: mm/memblock.o(.meminit.text+0xc4): cannot reach printk The problem with this .config is, that both CONFIG_MODULES and CONFIG_MLONGCALLS are set to "n". The Kconfig autodetection needs fixing to enable CONFIG_MLONGCALLS in this case. This patch fixes it for me: [PATCH] Require -mlong-calls gcc option for !CONFIG_MODULES When building a kernel without module support, the CONFIG_MLONGCALL option needs to be enabled. This patch fixes the autodetection in the Kconfig script and uses a far call to preempt_schedule_irq() in intr_do_preempt(). Signed-off-by: Helge Deller Reported-by: kernel test robot --- diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig index 78b17621ee4a..278462186ac4 100644 --- a/arch/parisc/Kconfig +++ b/arch/parisc/Kconfig @@ -202,9 +202,8 @@ config PREFETCH depends on PA8X00 || PA7200 config MLONGCALLS - bool "Enable the -mlong-calls compiler option for big kernels" - default y if !MODULES || UBSAN || FTRACE - default n + def_bool y if !MODULES || UBSAN || FTRACE + bool "Enable the -mlong-calls compiler option for big kernels" if MODULES && !UBSAN && !FTRACE depends on PA8X00 help If you configure the kernel to include many drivers built-in instead diff --git a/arch/parisc/kernel/entry.S b/arch/parisc/kernel/entry.S index beba9816cc6c..6320f6a8397c 100644 --- a/arch/parisc/kernel/entry.S +++ b/arch/parisc/kernel/entry.S @@ -997,10 +997,19 @@ intr_do_preempt: bb,<,n %r20, 31 - PSW_SM_I, intr_restore nop - BL preempt_schedule_irq, %r2 - nop + /* ssm PSW_SM_I done later in intr_restore */ +#ifdef CONFIG_MLONGCALLS + ldilL%intr_restore, %r2 + load32 preempt_schedule_irq, %r1 + bv %r0(%r1) + ldo R%intr_restore(%r2), %r2 +#else + ldilL%intr_restore, %r2 + BL preempt_schedule_irq + ldo R%intr_restore(%r2), %r2 +#endif + - b,n intr_restore/* ssm PSW_SM_I done by intr_restore */ #endif /* CONFIG_PREEMPTION */ /*
Re: [PATCH] crypto: xor - avoid division by zero crash
On 1/24/21 3:30 PM, Ard Biesheuvel wrote:
> On Sun, 24 Jan 2021 at 15:28, Helge Deller wrote:
>>
>> On some of my parisc machines, this patch c055e3eae0f1 ("crypto: xor -
>> use ktime for template benchmarking") triggers a dividy-by-zero
>> exception because "min" becomes zero, which then leads to a kernel
>> crash.
>>
>> It's not clear yet, why I see the issue only on some machines. At least
>> on those the measured time to run the xor speed tests becomes zero
>> nanoseconds. Maybe it's because gcc-10 optimizes the speed test out, or
>> because of some other changes in the time keeping routines.
>>
>> In either case, the kernel should not crash.
>>
>> This patch adds a workaround by reporting such cases with a kernel
>> warning and continues as if the xor tests would have run in 1 ns.
>>
>> Signed-off-by: Helge Deller
>> Cc: sta...@vger.kernel.org # 5.10+
>>
>> ---
>>
>> diff --git a/crypto/xor.c b/crypto/xor.c
>> index eacbf4f93990..3639341bac7e 100644
>> --- a/crypto/xor.c
>> +++ b/crypto/xor.c
>> @@ -100,6 +100,8 @@ do_xor_speed(struct xor_block_template *tmpl, void *b1,
>> void *b2)
>> mb();
>> }
>> diff = ktime_sub(ktime_get(), start);
>> + if (WARN_ON(diff == 0))
>> + diff = 1;
>> if (diff < min)
>> min = diff;
>> }
>
> This should already be fixed in mainline - please check whether that
> fix works for you.
Yes, it's basically the same fix and a good step.
It fixes the kernel crash at least, but it's still strange that
the timing calculation will be wrong.
Helge
[PATCH] crypto: xor - avoid division by zero crash
On some of my parisc machines, this patch c055e3eae0f1 ("crypto: xor -
use ktime for template benchmarking") triggers a dividy-by-zero
exception because "min" becomes zero, which then leads to a kernel
crash.
It's not clear yet, why I see the issue only on some machines. At least
on those the measured time to run the xor speed tests becomes zero
nanoseconds. Maybe it's because gcc-10 optimizes the speed test out, or
because of some other changes in the time keeping routines.
In either case, the kernel should not crash.
This patch adds a workaround by reporting such cases with a kernel
warning and continues as if the xor tests would have run in 1 ns.
Signed-off-by: Helge Deller
Cc: sta...@vger.kernel.org # 5.10+
---
diff --git a/crypto/xor.c b/crypto/xor.c
index eacbf4f93990..3639341bac7e 100644
--- a/crypto/xor.c
+++ b/crypto/xor.c
@@ -100,6 +100,8 @@ do_xor_speed(struct xor_block_template *tmpl, void *b1,
void *b2)
mb();
}
diff = ktime_sub(ktime_get(), start);
+ if (WARN_ON(diff == 0))
+ diff = 1;
if (diff < min)
min = diff;
}
Re: [proc/wchan] 30a3a19273: leaking-addresses.proc.wchan./proc/bus/input/devices:B:KEY=1000000000007ff980000000007fffebeffdfffeffffffffffffffffffffe
On 1/3/21 3:27 PM, kernel test robot wrote:
>
> Greeting,
>
> FYI, we noticed the following commit (built with gcc-9):
>
> commit: 30a3a192730a997bc4afff5765254175b6fb64f3 ("[PATCH] proc/wchan: Use
> printk format instead of lookup_symbol_name()")
> url:
> https://github.com/0day-ci/linux/commits/Helge-Deller/proc-wchan-Use-printk-format-instead-of-lookup_symbol_name/20201218-010048
> base: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git
> 09162bc32c880a791c6c0668ce0745cf7958f576
>
> in testcase: leaking-addresses
> version: leaking-addresses-x86_64-4f19048-1_2020
> with following parameters:
>
> ucode: 0xde
>
>
>
> on test machine: 4 threads Intel(R) Core(TM) i7-7567U CPU @ 3.50GHz with 32G
> memory
>
> caused below changes (please refer to attached dmesg/kmsg for entire
> log/backtrace):
I don't see anything wrong with the wchan patch
(30a3a192730a997bc4afff5765254175b6fb64f3),
or that it could have leaked anything.
Maybe the kernel test robot picked up the wchan patch by mistake ?
Helge
>
> If you fix the issue, kindly add following tag
> Reported-by: kernel test robot
>
> 2021-01-01 01:52:25 ./leaking_addresses.pl --output-raw result/scan.out
> 2021-01-01 01:52:49 ./leaking_addresses.pl --input-raw result/scan.out
> --squash-by-filename
>
> Total number of results from scan (incl dmesg): 156538
>
> dmesg output:
> [0.058490] mapped IOAPIC to ff5fb000 (fec0)
>
> Results squashed by filename (excl dmesg). Displaying [
> ],
> [1 _error_injection_whitelist] 0xc0a254b0
> [25 __bug_table] 0xc01e0070
> [46 .orc_unwind_ip] 0xc009f3a0
> [6 __tracepoints_strings] 0xc027d7d0
> [50 .strtab] 0xc00b9b88
> [1 .rodata.cst16.mask2] 0xc00a70e0
> [1 key] 10007 ff9807ff febeffdfffef fffe
> [50 .note.Linux] 0xc009f024
> [41 .data] 0xc00a1000
> [6 .static_call.text] 0xc0274b44
> [1 _ftrace_eval_map] 0xc0a20148
> [10 .data.once] 0xc04475b4
> [7 .static_call_sites] 0xc0a22088
> [6 __tracepoints_ptrs] 0xc027d7bc
> [7 .fixup] 0xc00852ea
> [49 __mcount_loc] 0xc009f03c
> [19 __param] 0xc009f378
> [38 .rodata.str1.8] 0xc009f170
> [1 ___srcu_struct_ptrs] 0xc0355000
> [14 .altinstr_replacement] 0xc04349ca
> [154936 kallsyms] 8100 T startup_64
> [50 .gnu.linkonce.this_module] 0xc00a1140
> [24 __ksymtab_strings] 0xc00e2048
> [31 .bss] 0xc00a1500
> [42 .rodata.str1.1] 0xc009f09c
> [9 .init.rodata] 0xc00b8000
> [11 __ex_table] 0xc00bd128
> [14 .parainstructions] 0xc03b5d88
> [6 __tracepoints] 0xc02818c0
> [1 .rodata.cst16.mask1] 0xc00a70d0
> [18 __dyndbg] 0xc00a10c8
> [5 .altinstr_aux] 0xc0143a49
> [22 .smp_locks] 0xc009f094
> [2 .rodata.cst16.bswap_mask] 0xc005e070
> [40 .init.text] 0xc00b7000
> [4 .init.data] 0xc00e7000
> [10 .data..read_mostly] 0xc00a1100
> [14 .altinstructions] 0xc0446846
> [6 __bpf_raw_tp_map] 0xc0281720
> [50 .note.gnu.build-id] 0xc009f000
> [6 _ftrace_events] 0xc0281780
> [140 printk_formats] 0x82341767 : "CPU_ON"
> [25 __jump_table] 0xc00a
> [37 .exit.text] 0xc009ec70
> [50 .text] 0xc009e000
> [35 .text.unlikely] 0xc009ebaf
> [18 __ksymtab] 0xc00e203c
> [46 .orc_unwind] 0xc009f544
> [1 .data..cacheline_aligned] 0xc081d8c0
> [2 .noinstr.text] 0xc04b8d00
> [1 uevent] KEY=10007 ff9807ff febeffdfffef
> fffe
> [50 modules] netconsole 20480 0 - Live 0xc00cb000
> [337 blacklist] 0x81c00880-0x81c008a0 asm_exc_overflow
> [1 .rodata.cst32.byteshift_table] 0xc00a7100
> [2 wchan] 0xc93c/proc/bus/input/devices: B: KEY=10007
> ff9807ff febeffdfffef fffe
> [6 .ref.data] 0xc02817a0
> [14 __ksymtab_gpl] 0xc03b503c
> [42 .rodata] 0xc009f2c0
> [50 .symtab] 0xc00b9000
>
>
>
> To reproduce:
>
> git clone https://github.com/intel/lkp-tests.git
> cd lkp-tests
> bin/lkp install job.yaml # job file is attached in this email
> bin/lkp run job.yaml
>
>
>
> Thanks,
> Oliver Sang
>
[PATCH] mm: fix extend calculation for move_page_tables()
On parisc the kernel fails to start the init process because in
shift_arg_pages() in fs/exec.c, move_page_tables() is called to e.g.
move pages from start addr 0xffeff000 to the new start addr 0xf9ccb000
with a length of 0x1000 bytes, but move_page_tables() instead returns
that it apparently moved 0x57000 bytes. Since the number of bytes is
different than the number of bytes which should have been moved,
shift_arg_pages() aborts with -ENOMEM.
Debugging shows that commit c49dd34018026 ("mm: speedup mremap on
1GB or larger regions") is the culprit.
In this commit, the extent calculation was tried to be optimized, but
got it wrong for this case.
The patch below reverts to the previous way to calculate the extent and
thus fixes the boot problem.
Fixes: c49dd34018026 ("mm: speedup mremap on 1GB or larger regions")
Signed-off-by: Helge Deller
Cc: Kalesh Singh
Cc: "Kirill A. Shutemov"
Cc: Andrew Morton
---
diff --git a/mm/mremap.c b/mm/mremap.c
index c5590afe7165..f554320281cc 100644
--- a/mm/mremap.c
+++ b/mm/mremap.c
@@ -358,7 +358,9 @@ static unsigned long get_extent(enum pgt_entry entry,
unsigned long old_addr,
next = (old_addr + size) & mask;
/* even if next overflowed, extent below will be ok */
- extent = (next > old_end) ? old_end - old_addr : next - old_addr;
+ extent = next - old_addr;
+ if (extent > old_end - old_addr)
+ extent = old_end - old_addr;
next = (new_addr + size) & mask;
if (extent > next - new_addr)
extent = next - new_addr;
Re: [PATCH] proc/wchan: Use printk format instead of lookup_symbol_name()
On 12/23/20 3:18 AM, Andrew Morton wrote:
> On Thu, 17 Dec 2020 17:54:13 +0100 Helge Deller wrote:
>
>> To resolve the symbol fuction name for wchan, use the printk format
>> specifier %ps instead of manually looking up the symbol function name
>> via lookup_symbol_name().
>>
>> Signed-off-by: Helge Deller
>>
>
> Please don't forget the "^---$" to separate the changelog from the
> diff.
Ok.
>
>> #include
>> @@ -386,19 +385,17 @@ static int proc_pid_wchan(struct seq_file *m, struct
>> pid_namespace *ns,
>>struct pid *pid, struct task_struct *task)
>> {
>> unsigned long wchan;
>> -char symname[KSYM_NAME_LEN];
>>
>> -if (!ptrace_may_access(task, PTRACE_MODE_READ_FSCREDS))
>> -goto print0;
>> +if (ptrace_may_access(task, PTRACE_MODE_READ_FSCREDS))
>> +wchan = get_wchan(task);
>> +else
>> +wchan = 0;
>>
>> -wchan = get_wchan(task);
>> -if (wchan && !lookup_symbol_name(wchan, symname)) {
>> -seq_puts(m, symname);
>> -return 0;
>> -}
>> +if (wchan)
>> +seq_printf(m, "%ps", (void *) wchan);
>> +else
>> +seq_putc(m, '0');
>>
>> -print0:
>> -seq_putc(m, '0');
>> return 0;
>> }
>
> We can simplify this further?
>
> static int proc_pid_wchan(struct seq_file *m, struct pid_namespace *ns,
> struct pid *pid, struct task_struct *task)
> {
> if (ptrace_may_access(task, PTRACE_MODE_READ_FSCREDS))
> seq_printf(m, "%ps", (void *)get_wchan(task));
> else
> seq_putc(m, '0');
>
> return 0;
> }
>
>
> ---
> a/fs/proc/base.c~proc-wchan-use-printk-format-instead-of-lookup_symbol_name-fix
> +++ a/fs/proc/base.c
> @@ -384,15 +384,8 @@ static const struct file_operations proc
> static int proc_pid_wchan(struct seq_file *m, struct pid_namespace *ns,
> struct pid *pid, struct task_struct *task)
> {
> - unsigned long wchan;
> -
> if (ptrace_may_access(task, PTRACE_MODE_READ_FSCREDS))
> - wchan = get_wchan(task);
> - else
> - wchan = 0;
> -
> - if (wchan)
> - seq_printf(m, "%ps", (void *) wchan);
> + seq_printf(m, "%ps", (void *)get_wchan(task));
> else
> seq_putc(m, '0');
get_wchan() does return NULL sometimes, in which case with
your change now "0x0" instead of "0" gets printed.
If that's acceptable, then your patch is Ok.
Helge
Re: [PATCH] checkpatch: add new warning when lookup_symbol_name() is used
On 12/17/20 7:15 PM, Joe Perches wrote:
> On Thu, 2020-12-17 at 18:42 +0100, Helge Deller wrote:
>> On 12/17/20 6:27 PM, Joe Perches wrote:
>>> On Thu, 2020-12-17 at 18:11 +0100, Helge Deller wrote:
>>>> In most cases people use lookup_symbol_name() to resolve a kernel symbol
>>>> and then print it via printk().
>>>>
>>>> In such cases using the %ps, %pS, %pSR or %pB printk formats are easier
>>>> to use and thus should be preferred.
>>> []
>>>> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
>>> []
>>>> @@ -4317,6 +4317,12 @@ sub process {
>>>> "LINUX_VERSION_CODE should be avoided, code should
>>>> be for the version to which it is merged\n" . $herecurr);
>>>> }
>>>>
>>>> +# avoid lookup_symbol_name()
>>>> + if ($line =~ /\blookup_symbol_name\b/) {
>>>> + WARN("PREFER_PRINTK_FORMAT",
>>>> + "If possible prefer %ps or %pS printk format
>>>> string to print symbol name instead of using lookup_symbol_name()\n" .
>>>> $herecurr);
>>>> + }
>>>> +
>>>> # check for uses of printk_ratelimit
>>>> if ($line =~ /\bprintk_ratelimit\s*\(/) {
>>>> WARN("PRINTK_RATELIMITED",
>>>
>>> Huh? nak.
>>>
>>> lookup_symbol_name is used in the kernel a grand total of 3 times.
>>
>> Yes, there were much more in the past which got fixed by patches I submitted.
>
> Hi Helge.
>
> Much more may be a bit of an overstatement.
>
> I found 3 instances of lookup_symbol_name removals in 2 patches.
>
> commit 36dbca148bf8e3b8658982aa2256bdc7ef040256
> - lookup_symbol_name((ulong)pm_power_off, symname);
> - lookup_symbol_name((ulong)pm_power_off, symname);
> commit da88f9b3113620dcd30fc203236aa53d5430ee98
> - if (lookup_symbol_name((unsigned long)sym, symname) < 0)
>
> There's a tension between adding tests and newbies that consider
> checkpatch warnings as dicta that must be followed so there would
> be patches submitted eventually against the existing correct uses.
>
> So thanks, but given the very few existing all correct uses of
> this function and the low probability of new uses I'd prefer not
> to apply this.
Ok.
Thanks!
Helge
Re: [PATCH] checkpatch: add new warning when lookup_symbol_name() is used
On 12/17/20 6:27 PM, Joe Perches wrote:
> On Thu, 2020-12-17 at 18:11 +0100, Helge Deller wrote:
>> In most cases people use lookup_symbol_name() to resolve a kernel symbol
>> and then print it via printk().
>>
>> In such cases using the %ps, %pS, %pSR or %pB printk formats are easier
>> to use and thus should be preferred.
> []
>> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> []
>> @@ -4317,6 +4317,12 @@ sub process {
>> "LINUX_VERSION_CODE should be avoided, code should
>> be for the version to which it is merged\n" . $herecurr);
>> }
>>
>> +# avoid lookup_symbol_name()
>> +if ($line =~ /\blookup_symbol_name\b/) {
>> +WARN("PREFER_PRINTK_FORMAT",
>> + "If possible prefer %ps or %pS printk format
>> string to print symbol name instead of using lookup_symbol_name()\n" .
>> $herecurr);
>> +}
>> +
>> # check for uses of printk_ratelimit
>> if ($line =~ /\bprintk_ratelimit\s*\(/) {
>> WARN("PRINTK_RATELIMITED",
>
> Huh? nak.
>
> lookup_symbol_name is used in the kernel a grand total of 3 times.
Yes, there were much more in the past which got fixed by patches I submitted.
> 2 uses are kprobe, the other is fs/proc
Right. For fs/proc see:
https://lore.kernel.org/lkml/20201217165413.ga1...@ls3530.fritz.box/
> None of the existing uses is equivalent to %ps
Yes, those are the remaining legimate users.
> Why should this be applied?
... to prevent people to add new code with possibly unjustified use?
Helge
[PATCH] checkpatch: add new warning when lookup_symbol_name() is used
In most cases people use lookup_symbol_name() to resolve a kernel symbol
and then print it via printk().
In such cases using the %ps, %pS, %pSR or %pB printk formats are easier
to use and thus should be preferred.
Signed-off-by: Helge Deller
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index fab38b493cef..0d5515a3d875 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -4317,6 +4317,12 @@ sub process {
"LINUX_VERSION_CODE should be avoided, code should
be for the version to which it is merged\n" . $herecurr);
}
+# avoid lookup_symbol_name()
+ if ($line =~ /\blookup_symbol_name\b/) {
+ WARN("PREFER_PRINTK_FORMAT",
+"If possible prefer %ps or %pS printk format
string to print symbol name instead of using lookup_symbol_name()\n" .
$herecurr);
+ }
+
# check for uses of printk_ratelimit
if ($line =~ /\bprintk_ratelimit\s*\(/) {
WARN("PRINTK_RATELIMITED",
[PATCH] proc/wchan: Use printk format instead of lookup_symbol_name()
To resolve the symbol fuction name for wchan, use the printk format
specifier %ps instead of manually looking up the symbol function name
via lookup_symbol_name().
Signed-off-by: Helge Deller
diff --git a/fs/proc/base.c b/fs/proc/base.c
index b362523a9829..c4593e1cafa4 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -67,7 +67,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -386,19 +385,17 @@ static int proc_pid_wchan(struct seq_file *m, struct
pid_namespace *ns,
struct pid *pid, struct task_struct *task)
{
unsigned long wchan;
- char symname[KSYM_NAME_LEN];
- if (!ptrace_may_access(task, PTRACE_MODE_READ_FSCREDS))
- goto print0;
+ if (ptrace_may_access(task, PTRACE_MODE_READ_FSCREDS))
+ wchan = get_wchan(task);
+ else
+ wchan = 0;
- wchan = get_wchan(task);
- if (wchan && !lookup_symbol_name(wchan, symname)) {
- seq_puts(m, symname);
- return 0;
- }
+ if (wchan)
+ seq_printf(m, "%ps", (void *) wchan);
+ else
+ seq_putc(m, '0');
-print0:
- seq_putc(m, '0');
return 0;
}
#endif /* CONFIG_KALLSYMS */
[GIT PULL] parisc architecture updates for kernel v5.11-rc1
Hello Linus, please pull the updates for the parisc architecture for kernel 5.11-rc1 from: http://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git parisc-5.11-1 This patchset includes: A change to increase the default maximum stack size on parisc to 100 MB and the ability to further increase the stack hard limit size at runtime with ulimit for newly started processes. The other patches fix compile warnings, utilizes the Kbuild logic and cleanups the parisc arch code. Thanks, Helge The following changes since commit f8394f232b1eab649ce2df5c5f15b0e528c92091: Linux 5.10-rc3 (2020-11-08 16:10:16 -0800) are available in the Git repository at: http://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git parisc-5.11-1 for you to fetch changes up to 39b1e779b6e2d4ca7967b49b26f1e4358f20c90c: parisc: pci-dma: fix warning unused-function (2020-12-15 05:41:11 +0100) Anders Roxell (1): parisc: pci-dma: fix warning unused-function Geert Uytterhoeven (1): parisc/uapi: Use Kbuild logic to provide Helge Deller (3): parisc: Drop loops_per_jiffy from per_cpu struct parisc: Use _TIF_USER_WORK_MASK in entry.S parisc: Make user stack size configurable arch/parisc/include/asm/processor.h | 8 ++-- arch/parisc/include/uapi/asm/types.h | 7 --- arch/parisc/kernel/entry.S | 4 ++-- arch/parisc/kernel/pci-dma.c | 2 +- arch/parisc/kernel/processor.c | 5 ++--- arch/parisc/kernel/sys_parisc.c | 23 +-- fs/exec.c| 4 ++-- mm/Kconfig | 12 +--- 8 files changed, 35 insertions(+), 30 deletions(-) delete mode 100644 arch/parisc/include/uapi/asm/types.h
Re: linux-next: manual merge of the parisc-hd tree with the asm-generic tree
On 12/14/20 8:48 PM, Stephen Rothwell wrote:
> Hi all,
>
> On Mon, 2 Nov 2020 12:38:41 +1100 Stephen Rothwell
> wrote:
>>
>> Today's linux-next merge of the parisc-hd tree got a conflict in:
>>
>> arch/parisc/kernel/time.c
>>
>> between commit:
>>
>> 686092e7daaa ("parisc: use legacy_timer_tick")
>>
>> from the asm-generic tree and commit:
>>
>> 3b7ab4a74a2d ("parisc: Switch to clockevent based timers")
>>
>> from the parisc-hd tree.
>>
>> I fixed it up (I effectively reverted the former commit) and can carry the
>> fix as necessary. This is now fixed as far as linux-next is concerned,
>> but any non trivial conflicts should be mentioned to your upstream
>> maintainer when your tree is submitted for merging. You may also want
>> to consider cooperating with the maintainer of the conflicting tree to
>> minimise any particularly complex conflicts.
>
> This is just a reminder that this conflict still exists.
I dropped the patch from the parisc-hd tree for now -
it needs more work and will not be part of the next merge window.
Thanks,
Helge
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] arch: fix 'unexpected IRQ trap at vector' warnings
On 12/8/20 3:11 AM, Michael Ellerman wrote:
> "Enrico Weigelt, metux IT consult" writes:
>> All archs, except Alpha, print out the irq number in hex, but the message
>> looks like it was a decimal number, which is quite confusing. Fixing this
>> by adding "0x" prefix.
>
> Arguably decimal would be better, /proc/interrupts and /proc/irq/ both
> use decimal.
I agree.
> The whole message is very dated IMO, these days the number it prints is
> (possibly) virtualised via IRQ domains, ie. it's not necessarily a
> "vector" if that even makes sense on all arches). Arguably "trap" is the
> wrong term on some arches too.
>
> So it would be better reworded entirely IMO, and also switched to
> decimal to match other sources of information on interrupts.
>
> Perhaps:
> "Unexpected Linux IRQ %d."
Yes.
and while cleaning it up, introducing a default weak implementation of
ack_bad_irq()
which adds and increases irq_err_count for all platforms would be a nice
cleanup.
Helge
> If anyone else is having deja vu like me, yes this has come up before:
>
> https://lore.kernel.org/lkml/20150712220211.7166.42035.st...@bhelgaas-glaptop2.roam.corp.google.com/
>
> cheers
>
>
>
>> diff --git a/arch/arm/include/asm/hw_irq.h b/arch/arm/include/asm/hw_irq.h
>> index cecc13214ef1..2749f19271d9 100644
>> --- a/arch/arm/include/asm/hw_irq.h
>> +++ b/arch/arm/include/asm/hw_irq.h
>> @@ -9,7 +9,7 @@ static inline void ack_bad_irq(int irq)
>> {
>> extern unsigned long irq_err_count;
>> irq_err_count++;
>> -pr_crit("unexpected IRQ trap at vector %02x\n", irq);
>> +pr_crit("unexpected IRQ trap at vector 0x%02x\n", irq);
>> }
>>
>> #define ARCH_IRQ_INIT_FLAGS (IRQ_NOREQUEST | IRQ_NOPROBE)
>> diff --git a/arch/parisc/include/asm/hardirq.h
>> b/arch/parisc/include/asm/hardirq.h
>> index 7f7039516e53..c3348af88d3f 100644
>> --- a/arch/parisc/include/asm/hardirq.h
>> +++ b/arch/parisc/include/asm/hardirq.h
>> @@ -35,6 +35,6 @@ DECLARE_PER_CPU_SHARED_ALIGNED(irq_cpustat_t, irq_stat);
>> #define __IRQ_STAT(cpu, member) (irq_stat[cpu].member)
>> #define inc_irq_stat(member)this_cpu_inc(irq_stat.member)
>> #define __inc_irq_stat(member) __this_cpu_inc(irq_stat.member)
>> -#define ack_bad_irq(irq) WARN(1, "unexpected IRQ trap at vector %02x\n",
>> irq)
>> +#define ack_bad_irq(irq) WARN(1, "unexpected IRQ trap at vector 0x%02x\n",
>> irq)
>>
>> #endif /* _PARISC_HARDIRQ_H */
>> diff --git a/arch/powerpc/include/asm/hardirq.h
>> b/arch/powerpc/include/asm/hardirq.h
>> index f133b5930ae1..ec8cf3cf6e49 100644
>> --- a/arch/powerpc/include/asm/hardirq.h
>> +++ b/arch/powerpc/include/asm/hardirq.h
>> @@ -29,7 +29,7 @@ DECLARE_PER_CPU_SHARED_ALIGNED(irq_cpustat_t, irq_stat);
>>
>> static inline void ack_bad_irq(unsigned int irq)
>> {
>> -printk(KERN_CRIT "unexpected IRQ trap at vector %02x\n", irq);
>> +printk(KERN_CRIT "unexpected IRQ trap at vector 0x%02x\n", irq);
>> }
>>
>> extern u64 arch_irq_stat_cpu(unsigned int cpu);
>> diff --git a/arch/s390/include/asm/hardirq.h
>> b/arch/s390/include/asm/hardirq.h
>> index dfbc3c6c0674..aaaec5cdd4fe 100644
>> --- a/arch/s390/include/asm/hardirq.h
>> +++ b/arch/s390/include/asm/hardirq.h
>> @@ -23,7 +23,7 @@
>>
>> static inline void ack_bad_irq(unsigned int irq)
>> {
>> -printk(KERN_CRIT "unexpected IRQ trap at vector %02x\n", irq);
>> +printk(KERN_CRIT "unexpected IRQ trap at vector 0x%02x\n", irq);
>> }
>>
>> #endif /* __ASM_HARDIRQ_H */
>> diff --git a/arch/um/include/asm/hardirq.h b/arch/um/include/asm/hardirq.h
>> index b426796d26fd..2a2e6eae034b 100644
>> --- a/arch/um/include/asm/hardirq.h
>> +++ b/arch/um/include/asm/hardirq.h
>> @@ -15,7 +15,7 @@ typedef struct {
>> #ifndef ack_bad_irq
>> static inline void ack_bad_irq(unsigned int irq)
>> {
>> -printk(KERN_CRIT "unexpected IRQ trap at vector %02x\n", irq);
>> +printk(KERN_CRIT "unexpected IRQ trap at vector 0x%02x\n", irq);
>> }
>> #endif
>>
>> diff --git a/arch/x86/kernel/irq.c b/arch/x86/kernel/irq.c
>> index c5dd50369e2f..957c716f2df7 100644
>> --- a/arch/x86/kernel/irq.c
>> +++ b/arch/x86/kernel/irq.c
>> @@ -37,7 +37,7 @@ atomic_t irq_err_count;
>> void ack_bad_irq(unsigned int irq)
>> {
>> if (printk_ratelimit())
>> -pr_err("unexpected IRQ trap at vector %02x\n", irq);
>> +pr_err("unexpected IRQ trap at vector 0x%02x\n", irq);
>>
>> /*
>> * Currently unexpected vectors happen only on SMP and APIC.
>> --
>> 2.11.0
Re: [PATCH] parisc: signal: remove _SA_SIGGFAULT
On 11/26/20 2:06 PM, Anders Roxell wrote:
> When building tinyconfig on parisc the following error shows up:
>
> /tmp/kernel/signal.c: In function 'do_sigaction':
> /tmp/arch/parisc/include/asm/signal.h:24:30: error: '_SA_SIGGFAULT'
> undeclared (first use in this function); did you mean 'SIL_FAULT'?
> #define __ARCH_UAPI_SA_FLAGS _SA_SIGGFAULT
> ^
>
> The changes in the two individual patches listed in 'Fixes' below are
> OK. Remove the _SA_SIGGFAULT define since PH-UX isn't going to be
> supported according to commit 41f5a81c07cd ("parisc: Drop HP-UX specific
> fcntl and signal flags").
>
> Fixes: 23acdc76f179 ("signal: clear non-uapi flag bits when passing/returning
> sa_flags")
> Fixes: 41f5a81c07cd ("parisc: Drop HP-UX specific fcntl and signal flags")
> Signed-off-by: Anders Roxell
> ---
> arch/parisc/include/asm/signal.h | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/arch/parisc/include/asm/signal.h
> b/arch/parisc/include/asm/signal.h
> index 30dd1e43ef88..715c96ba2ec8 100644
> --- a/arch/parisc/include/asm/signal.h
> +++ b/arch/parisc/include/asm/signal.h
> @@ -21,8 +21,6 @@ typedef struct {
> unsigned long sig[_NSIG_WORDS];
> } sigset_t;
>
> -#define __ARCH_UAPI_SA_FLAGS _SA_SIGGFAULT
> -
Which kernel are you testing?
I don't see this line in current git head...?!?
Helge
> #include
>
> #endif /* !__ASSEMBLY */
>
[tip: timers/core] timer_list: Use printk format instead of open-coded symbol lookup
The following commit has been merged into the timers/core branch of tip:
Commit-ID: da88f9b3113620dcd30fc203236aa53d5430ee98
Gitweb:
https://git.kernel.org/tip/da88f9b3113620dcd30fc203236aa53d5430ee98
Author:Helge Deller
AuthorDate:Wed, 04 Nov 2020 17:34:01 +01:00
Committer: Thomas Gleixner
CommitterDate: Sun, 15 Nov 2020 20:47:14 +01:00
timer_list: Use printk format instead of open-coded symbol lookup
Use the "%ps" printk format string to resolve symbol names.
This works on all platforms, including ia64, ppc64 and parisc64 on which
one needs to dereference pointers to function descriptors instead of
function pointers.
Signed-off-by: Helge Deller
Signed-off-by: Thomas Gleixner
Link: https://lore.kernel.org/r/20201104163401.ga3...@ls3530.fritz.box
---
kernel/time/timer_list.c | 66 +++
1 file changed, 19 insertions(+), 47 deletions(-)
diff --git a/kernel/time/timer_list.c b/kernel/time/timer_list.c
index acb326f..6939140 100644
--- a/kernel/time/timer_list.c
+++ b/kernel/time/timer_list.c
@@ -42,24 +42,11 @@ static void SEQ_printf(struct seq_file *m, const char *fmt,
...)
va_end(args);
}
-static void print_name_offset(struct seq_file *m, void *sym)
-{
- char symname[KSYM_NAME_LEN];
-
- if (lookup_symbol_name((unsigned long)sym, symname) < 0)
- SEQ_printf(m, "<%pK>", sym);
- else
- SEQ_printf(m, "%s", symname);
-}
-
static void
print_timer(struct seq_file *m, struct hrtimer *taddr, struct hrtimer *timer,
int idx, u64 now)
{
- SEQ_printf(m, " #%d: ", idx);
- print_name_offset(m, taddr);
- SEQ_printf(m, ", ");
- print_name_offset(m, timer->function);
+ SEQ_printf(m, " #%d: <%pK>, %ps", idx, taddr, timer->function);
SEQ_printf(m, ", S:%02x", timer->state);
SEQ_printf(m, "\n");
SEQ_printf(m, " # expires at %Lu-%Lu nsecs [in %Ld to %Ld nsecs]\n",
@@ -116,9 +103,7 @@ print_base(struct seq_file *m, struct hrtimer_clock_base
*base, u64 now)
SEQ_printf(m, " .resolution: %u nsecs\n", hrtimer_resolution);
- SEQ_printf(m, " .get_time: ");
- print_name_offset(m, base->get_time);
- SEQ_printf(m, "\n");
+ SEQ_printf(m, " .get_time: %ps\n", base->get_time);
#ifdef CONFIG_HIGH_RES_TIMERS
SEQ_printf(m, " .offset: %Lu nsecs\n",
(unsigned long long) ktime_to_ns(base->offset));
@@ -218,42 +203,29 @@ print_tickdevice(struct seq_file *m, struct tick_device
*td, int cpu)
SEQ_printf(m, " next_event: %Ld nsecs\n",
(unsigned long long) ktime_to_ns(dev->next_event));
- SEQ_printf(m, " set_next_event: ");
- print_name_offset(m, dev->set_next_event);
- SEQ_printf(m, "\n");
+ SEQ_printf(m, " set_next_event: %ps\n", dev->set_next_event);
- if (dev->set_state_shutdown) {
- SEQ_printf(m, " shutdown: ");
- print_name_offset(m, dev->set_state_shutdown);
- SEQ_printf(m, "\n");
- }
+ if (dev->set_state_shutdown)
+ SEQ_printf(m, " shutdown: %ps\n",
+ dev->set_state_shutdown);
- if (dev->set_state_periodic) {
- SEQ_printf(m, " periodic: ");
- print_name_offset(m, dev->set_state_periodic);
- SEQ_printf(m, "\n");
- }
+ if (dev->set_state_periodic)
+ SEQ_printf(m, " periodic: %ps\n",
+ dev->set_state_periodic);
- if (dev->set_state_oneshot) {
- SEQ_printf(m, " oneshot: ");
- print_name_offset(m, dev->set_state_oneshot);
- SEQ_printf(m, "\n");
- }
+ if (dev->set_state_oneshot)
+ SEQ_printf(m, " oneshot:%ps\n",
+ dev->set_state_oneshot);
- if (dev->set_state_oneshot_stopped) {
- SEQ_printf(m, " oneshot stopped: ");
- print_name_offset(m, dev->set_state_oneshot_stopped);
- SEQ_printf(m, "\n");
- }
+ if (dev->set_state_oneshot_stopped)
+ SEQ_printf(m, " oneshot stopped: %ps\n",
+ dev->set_state_oneshot_stopped);
- if (dev->tick_resume) {
- SEQ_printf(m, " resume: ");
- print_name_offset(m, dev->tick_resume);
- SEQ_printf(m, "\n");
- }
+ if (dev->tick_resume)
+ SEQ_printf(m, " resume: %ps\n",
+ dev->tick_resume);
- SEQ_printf(m, " event_handler: ");
- print_name_offset(m, dev->event_handler);
+ SEQ_printf(m, " event_handler: %ps\n", dev->event_handler);
SEQ_printf(m, "\n");
SEQ_printf(m, " retries:%lu\n", dev->retries);
SEQ_printf(m, "\n");
Re: [PATCH] parisc/uapi: Use Kbuild logic to provide
On 11/10/20 5:51 PM, Geert Uytterhoeven wrote: > Uapi just includes > > Signed-off-by: Geert Uytterhoeven Thanks, applied to the parisc for-next tree. Helge > --- > This is a resend of a very old patch from 2013, which is still valid. > > arch/parisc/include/uapi/asm/types.h | 7 --- > 1 file changed, 7 deletions(-) > delete mode 100644 arch/parisc/include/uapi/asm/types.h > > diff --git a/arch/parisc/include/uapi/asm/types.h > b/arch/parisc/include/uapi/asm/types.h > deleted file mode 100644 > index 28c7d7453b10f9b1.. > --- a/arch/parisc/include/uapi/asm/types.h > +++ /dev/null > @@ -1,7 +0,0 @@ > -/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */ > -#ifndef _PARISC_TYPES_H > -#define _PARISC_TYPES_H > - > -#include > - > -#endif >
[PATCH] power: reset: Use printk format symbol resolver
Instead of looking up a symbol name by hand, use the %ps printk format
specifier.
Signed-off-by: Helge Deller
diff --git a/drivers/power/reset/qnap-poweroff.c
b/drivers/power/reset/qnap-poweroff.c
index 52b7dc61d870..0ddf7f25f7b8 100644
--- a/drivers/power/reset/qnap-poweroff.c
+++ b/drivers/power/reset/qnap-poweroff.c
@@ -14,7 +14,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -75,7 +74,6 @@ static int qnap_power_off_probe(struct platform_device *pdev)
struct device_node *np = pdev->dev.of_node;
struct resource *res;
struct clk *clk;
- char symname[KSYM_NAME_LEN];
const struct of_device_id *match =
of_match_node(qnap_power_off_of_match_table, np);
@@ -104,10 +102,8 @@ static int qnap_power_off_probe(struct platform_device
*pdev)
/* Check that nothing else has already setup a handler */
if (pm_power_off) {
- lookup_symbol_name((ulong)pm_power_off, symname);
- dev_err(>dev,
- "pm_power_off already claimed %p %s",
- pm_power_off, symname);
+ dev_err(>dev, "pm_power_off already claimed for %ps",
+ pm_power_off);
return -EBUSY;
}
pm_power_off = qnap_power_off;
diff --git a/drivers/power/reset/syscon-poweroff.c
b/drivers/power/reset/syscon-poweroff.c
index 4d6923b102b6..ed58bdf41e27 100644
--- a/drivers/power/reset/syscon-poweroff.c
+++ b/drivers/power/reset/syscon-poweroff.c
@@ -6,7 +6,6 @@
* Author: Moritz Fischer
*/
-#include
#include
#include
#include
@@ -34,7 +33,6 @@ static void syscon_poweroff(void)
static int syscon_poweroff_probe(struct platform_device *pdev)
{
- char symname[KSYM_NAME_LEN];
int mask_err, value_err;
map = syscon_regmap_lookup_by_phandle(pdev->dev.of_node, "regmap");
@@ -65,10 +63,8 @@ static int syscon_poweroff_probe(struct platform_device
*pdev)
}
if (pm_power_off) {
- lookup_symbol_name((ulong)pm_power_off, symname);
- dev_err(>dev,
- "pm_power_off already claimed %p %s",
- pm_power_off, symname);
+ dev_err(>dev, "pm_power_off already claimed for %ps",
+ pm_power_off);
return -EBUSY;
}
Re: [PATCH seccomp 2/8] parisc: Enable seccomp architecture tracking
On 11/3/20 2:42 PM, YiFei Zhu wrote: > From: YiFei Zhu > > To enable seccomp constant action bitmaps, we need to have a static > mapping to the audit architecture and system call table size. Add these > for parisc. > > Signed-off-by: YiFei Zhu I did compile- and boot-tested it, works on 32- and 64-bit parisc kernel. I don't know how to test it actually, but anyway: Acked-by: Helge Deller Thanks! Helge > --- > arch/parisc/include/asm/Kbuild| 1 - > arch/parisc/include/asm/seccomp.h | 22 ++ > 2 files changed, 22 insertions(+), 1 deletion(-) > create mode 100644 arch/parisc/include/asm/seccomp.h > > diff --git a/arch/parisc/include/asm/Kbuild b/arch/parisc/include/asm/Kbuild > index e3ee5c0bfe80..f16c4db80116 100644 > --- a/arch/parisc/include/asm/Kbuild > +++ b/arch/parisc/include/asm/Kbuild > @@ -5,5 +5,4 @@ generated-y += syscall_table_c32.h > generic-y += kvm_para.h > generic-y += local64.h > generic-y += mcs_spinlock.h > -generic-y += seccomp.h > generic-y += user.h > diff --git a/arch/parisc/include/asm/seccomp.h > b/arch/parisc/include/asm/seccomp.h > new file mode 100644 > index ..b058b2220322 > --- /dev/null > +++ b/arch/parisc/include/asm/seccomp.h > @@ -0,0 +1,22 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +#ifndef _ASM_SECCOMP_H > +#define _ASM_SECCOMP_H > + > +#include > + > +#ifdef CONFIG_64BIT > +# define SECCOMP_ARCH_NATIVE AUDIT_ARCH_PARISC64 > +# define SECCOMP_ARCH_NATIVE_NR NR_syscalls > +# define SECCOMP_ARCH_NATIVE_NAME"parisc64" > +# ifdef CONFIG_COMPAT > +# define SECCOMP_ARCH_COMPATAUDIT_ARCH_PARISC > +# define SECCOMP_ARCH_COMPAT_NR NR_syscalls > +# define SECCOMP_ARCH_COMPAT_NAME "parisc" > +# endif > +#else /* !CONFIG_64BIT */ > +# define SECCOMP_ARCH_NATIVE AUDIT_ARCH_PARISC > +# define SECCOMP_ARCH_NATIVE_NR NR_syscalls > +# define SECCOMP_ARCH_NATIVE_NAME"parisc" > +#endif > + > +#endif /* _ASM_SECCOMP_H */ >
[PATCH] timer_list: Use printk format instead of open-coded symbol lookup
Use the "%ps" printk format string to resolve symbol names.
This works on all platforms, including ia64, ppc64 and parisc64 on which
one needs to dereference pointers to function descriptors instead of
function pointers.
Signed-off-by: Helge Deller
diff --git a/kernel/time/timer_list.c b/kernel/time/timer_list.c
index acb326f5f50a..6939140ab7c5 100644
--- a/kernel/time/timer_list.c
+++ b/kernel/time/timer_list.c
@@ -42,24 +42,11 @@ static void SEQ_printf(struct seq_file *m, const char *fmt,
...)
va_end(args);
}
-static void print_name_offset(struct seq_file *m, void *sym)
-{
- char symname[KSYM_NAME_LEN];
-
- if (lookup_symbol_name((unsigned long)sym, symname) < 0)
- SEQ_printf(m, "<%pK>", sym);
- else
- SEQ_printf(m, "%s", symname);
-}
-
static void
print_timer(struct seq_file *m, struct hrtimer *taddr, struct hrtimer *timer,
int idx, u64 now)
{
- SEQ_printf(m, " #%d: ", idx);
- print_name_offset(m, taddr);
- SEQ_printf(m, ", ");
- print_name_offset(m, timer->function);
+ SEQ_printf(m, " #%d: <%pK>, %ps", idx, taddr, timer->function);
SEQ_printf(m, ", S:%02x", timer->state);
SEQ_printf(m, "\n");
SEQ_printf(m, " # expires at %Lu-%Lu nsecs [in %Ld to %Ld nsecs]\n",
@@ -116,9 +103,7 @@ print_base(struct seq_file *m, struct hrtimer_clock_base
*base, u64 now)
SEQ_printf(m, " .resolution: %u nsecs\n", hrtimer_resolution);
- SEQ_printf(m, " .get_time: ");
- print_name_offset(m, base->get_time);
- SEQ_printf(m, "\n");
+ SEQ_printf(m, " .get_time: %ps\n", base->get_time);
#ifdef CONFIG_HIGH_RES_TIMERS
SEQ_printf(m, " .offset: %Lu nsecs\n",
(unsigned long long) ktime_to_ns(base->offset));
@@ -218,42 +203,29 @@ print_tickdevice(struct seq_file *m, struct tick_device
*td, int cpu)
SEQ_printf(m, " next_event: %Ld nsecs\n",
(unsigned long long) ktime_to_ns(dev->next_event));
- SEQ_printf(m, " set_next_event: ");
- print_name_offset(m, dev->set_next_event);
- SEQ_printf(m, "\n");
+ SEQ_printf(m, " set_next_event: %ps\n", dev->set_next_event);
- if (dev->set_state_shutdown) {
- SEQ_printf(m, " shutdown: ");
- print_name_offset(m, dev->set_state_shutdown);
- SEQ_printf(m, "\n");
- }
+ if (dev->set_state_shutdown)
+ SEQ_printf(m, " shutdown: %ps\n",
+ dev->set_state_shutdown);
- if (dev->set_state_periodic) {
- SEQ_printf(m, " periodic: ");
- print_name_offset(m, dev->set_state_periodic);
- SEQ_printf(m, "\n");
- }
+ if (dev->set_state_periodic)
+ SEQ_printf(m, " periodic: %ps\n",
+ dev->set_state_periodic);
- if (dev->set_state_oneshot) {
- SEQ_printf(m, " oneshot: ");
- print_name_offset(m, dev->set_state_oneshot);
- SEQ_printf(m, "\n");
- }
+ if (dev->set_state_oneshot)
+ SEQ_printf(m, " oneshot:%ps\n",
+ dev->set_state_oneshot);
- if (dev->set_state_oneshot_stopped) {
- SEQ_printf(m, " oneshot stopped: ");
- print_name_offset(m, dev->set_state_oneshot_stopped);
- SEQ_printf(m, "\n");
- }
+ if (dev->set_state_oneshot_stopped)
+ SEQ_printf(m, " oneshot stopped: %ps\n",
+ dev->set_state_oneshot_stopped);
- if (dev->tick_resume) {
- SEQ_printf(m, " resume: ");
- print_name_offset(m, dev->tick_resume);
- SEQ_printf(m, "\n");
- }
+ if (dev->tick_resume)
+ SEQ_printf(m, " resume: %ps\n",
+ dev->tick_resume);
- SEQ_printf(m, " event_handler: ");
- print_name_offset(m, dev->event_handler);
+ SEQ_printf(m, " event_handler: %ps\n", dev->event_handler);
SEQ_printf(m, "\n");
SEQ_printf(m, " retries:%lu\n", dev->retries);
SEQ_printf(m, "\n");
Re: [PATCH v2 07/15] parisc: use legacy_timer_tick
On 10/30/20 8:33 PM, Arnd Bergmann wrote:
> On Fri, Oct 30, 2020 at 6:13 PM Helge Deller wrote:
>>
>> On 10/30/20 4:17 PM, Arnd Bergmann wrote:
>>> From: Arnd Bergmann
>>>
>>> parisc has selected CONFIG_GENERIC_CLOCKEVENTS since commit 43b1f6abd590
>>> ("parisc: Switch to generic sched_clock implementation"), but does not
>>> appear to actually be using it, and instead calls the low-level
>>> timekeeping functions directly.
>>
>> Arnd, thank you for this patch!
>> It reminded me that I really missed to fully implement the clockevents on
>> parisc!
>>
>> Your other patch ("RFC: m68k: mac: convert to generic clockevent")
>> was a big help too, as it showed how it might work on parisc as well.
>>
>> Here is now a current version of the clockevents-enabling-patch for parisc:
>> https://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git/commit/?h=for-next=3b7ab4a74a2d1972dbeb33285d85f1500b2ff96a
>
> Ah, nice!
>
>>> Remove the GENERIC_CLOCKEVENTS select again, and instead convert to
>>> the newly added legacy_timer_tick() helper.
>>
>> My patch still needs more testing, but if it turns to work
>> out right, would you mind to drop your patch for parisc?
>
> I think it would be easier if you could base your patch on top of
> my series, as they would otherwise inevitably conflict. I could either
> add it to my tree, or you could merge my branch into your tree.
Couldn't you drop your patch and include mine in your tree instead?
That way nothing conflicts, and they get merged together?
Helge
Re: [PATCH v2 07/15] parisc: use legacy_timer_tick
On 10/30/20 4:17 PM, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> parisc has selected CONFIG_GENERIC_CLOCKEVENTS since commit 43b1f6abd590
> ("parisc: Switch to generic sched_clock implementation"), but does not
> appear to actually be using it, and instead calls the low-level
> timekeeping functions directly.
Arnd, thank you for this patch!
It reminded me that I really missed to fully implement the clockevents on
parisc!
Your other patch ("RFC: m68k: mac: convert to generic clockevent")
was a big help too, as it showed how it might work on parisc as well.
Here is now a current version of the clockevents-enabling-patch for parisc:
https://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git/commit/?h=for-next=3b7ab4a74a2d1972dbeb33285d85f1500b2ff96a
> Remove the GENERIC_CLOCKEVENTS select again, and instead convert to
> the newly added legacy_timer_tick() helper.
My patch still needs more testing, but if it turns to work
out right, would you mind to drop your patch for parisc?
Helge
> Reviewed-by: Linus Walleij
> Signed-off-by: Arnd Bergmann
> ---
> Documentation/features/time/clockevents/arch-support.txt | 2 +-
> arch/parisc/Kconfig | 2 +-
> arch/parisc/kernel/time.c| 9 +++--
> 3 files changed, 5 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/features/time/clockevents/arch-support.txt
> b/Documentation/features/time/clockevents/arch-support.txt
> index 8287b6aa522e..61a5c9d68c15 100644
> --- a/Documentation/features/time/clockevents/arch-support.txt
> +++ b/Documentation/features/time/clockevents/arch-support.txt
> @@ -21,7 +21,7 @@
> | nds32: | ok |
> | nios2: | ok |
> |openrisc: | ok |
> -| parisc: | ok |
> +| parisc: | TODO |
> | powerpc: | ok |
> | riscv: | ok |
> |s390: | ok |
> diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
> index b234e8154cbd..78b17621ee4a 100644
> --- a/arch/parisc/Kconfig
> +++ b/arch/parisc/Kconfig
> @@ -52,7 +52,7 @@ config PARISC
> select HAVE_REGS_AND_STACK_ACCESS_API
> select GENERIC_SCHED_CLOCK
> select HAVE_UNSTABLE_SCHED_CLOCK if SMP
> - select GENERIC_CLOCKEVENTS
> + select LEGACY_TIMER_TICK
> select CPU_NO_EFFICIENT_FFS
> select NEED_DMA_MAP_STATE
> select NEED_SG_DMA_LENGTH
> diff --git a/arch/parisc/kernel/time.c b/arch/parisc/kernel/time.c
> index 13d94f0f94a0..08e4d480abe1 100644
> --- a/arch/parisc/kernel/time.c
> +++ b/arch/parisc/kernel/time.c
> @@ -70,8 +70,6 @@ irqreturn_t __irq_entry timer_interrupt(int irq, void
> *dev_id)
> /* gcc can optimize for "read-only" case with a local clocktick */
> unsigned long cpt = clocktick;
>
> - profile_tick(CPU_PROFILING);
> -
> /* Initialize next_tick to the old expected tick time. */
> next_tick = cpuinfo->it_value;
>
> @@ -86,10 +84,9 @@ irqreturn_t __irq_entry timer_interrupt(int irq, void
> *dev_id)
> cpuinfo->it_value = next_tick;
>
> /* Go do system house keeping. */
> - if (cpu == 0)
> - xtime_update(ticks_elapsed);
> -
> - update_process_times(user_mode(get_irq_regs()));
> + if (cpu != 0)
> + ticks_elapsed = 0;
> + legacy_timer_tick(ticks_elapsed);
>
> /* Skip clockticks on purpose if we know we would miss those.
>* The new CR16 must be "later" than current CR16 otherwise
>
Re: [PATCH] USB: serial: ftdi_sio: Fix serial port stall after resume
On 10/27/20 10:00 AM, Johan Hovold wrote:
> On Thu, Oct 08, 2020 at 08:16:02PM +0200, Helge Deller wrote:
>> On 10/8/20 5:21 PM, Johan Hovold wrote:
>>> On Tue, Sep 29, 2020 at 09:33:27PM +0200, Helge Deller wrote:
>>>> With a 4-port serial USB HUB with FT232BM chips the serial ports stop
>>>> working after a software suspend/resume cycle.
>>>> Rewriting the latency timer during the resume phase fixes it.
>
>>>> +static int ftdi_reset_resume(struct usb_serial *serial)
>>>> +{
>>>> + struct usb_serial_port *port = serial->port[0];
>>>> +
>>>> + if (tty_port_initialized(>port))
>>>> + write_latency_timer(port);
>>>
>>> Why are you only doing this for open ports?
>>
>> I more or less copied it from another driver
>>
>>>> +
>>>> + return usb_serial_generic_resume(serial);
>>>> +}
>>>
>>> And if the device has been reset there may need to reconfigured the
>>> termios settings for open ports.
>>>
>>> Could you expand a bit on what the problem is here?
>>
>> My testcase is pretty simple:
>> 1. I use e.g. "minicom -D /dev/ttyUSB2". Serial connection works.
>> 2. I exit minicom.
>> 3. I suspend the workstation: "systemctl suspend"
>> 4. I wake up the machine and wait a few seconds.
>> 5. I start "minicom -D /dev/ttyUSB2" again. No transfers on the serial port.
>>
>> With my patch the minicom serial communications does work.
>> Another way to wake up the connection is to rmmod the driver and
>> insmod it again.
>
> Weird indeed. If you exit minicom before suspend and no other process is
> keeping the port open, then that write_latency_timer() above would never
> be executed.
>
> Could you enable some debugging and provide a dmesg log from a test
> cycle (open/close minicom, suspend/resume, open minicom)?
>
> echo file usb-serial.c +p > /sys/kernel/debug/dynamic_debug/control
I enabled the debugging and tried a few times, but somehow I can not
reproduce the issue any longer.
So, please drop my patch for now.
Thanks!
Helge
[GIT PULL] parisc architecture updates for kernel v5.10-rc1
Hi Linus, please pull a few last fixes and updates for the parisc architecture for kernel 5.10-rc1 from: git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git parisc-5.10-2 This patchset includes: * During this merge window O_NONBLOCK was changed to become 00020, but we missed that the syscalls timerfd_create(), signalfd4(), eventfd2(), pipe2(), inotify_init1() and userfaultfd() do a strict bit-wise check of the flags parameter. To provide backward compatibility with existing userspace we introduce parisc specific wrappers for those syscalls which filter out the old O_NONBLOCK value and replaces it with the new one. * Prevent HIL bus driver to get stuck when keyboard or mouse isn't attached * Improve error return codes when setting rtc time * Minor documentation fix in pata_ns87415.c Thanks, Helge The following changes since commit f9893351acaecf0a414baf9942b48d5bb5c688c6: Merge tag 'kconfig-v5.10' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild (2020-10-22 13:20:39 -0700) are available in the Git repository at: http://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git parisc-5.10-2 for you to fetch changes up to 2e34ae02a9b49d1f459d811ae77d72d300584a69: ata: pata_ns87415.c: Document support on parisc with superio chip (2020-10-23 20:23:47 +0200) Helge Deller (4): parisc: Improve error return codes when setting rtc time hil/parisc: Disable HIL driver when it gets stuck parisc: Add wrapper syscalls to fix O_NONBLOCK flag usage ata: pata_ns87415.c: Document support on parisc with superio chip arch/parisc/kernel/sys_parisc.c | 73 - arch/parisc/kernel/syscalls/syscall.tbl | 12 +++--- arch/parisc/kernel/time.c | 11 - drivers/ata/pata_ns87415.c | 3 +- drivers/input/serio/hil_mlc.c | 21 -- drivers/input/serio/hp_sdc_mlc.c| 8 ++-- include/linux/hil_mlc.h | 2 +- 7 files changed, 111 insertions(+), 19 deletions(-)
[PATCH] scsi: mptfusion: Fix null pointer dereferences in mptscsih_remove()
The mptscsih_remove() function triggers a kernel oops if the
Scsi_Host pointer (ioc->sh) is NULL, as can be seen in this syslog:
ioc0: LSI53C1030 B2: Capabilities={Initiator,Target}
Begin: Waiting for root file system ...
scsi host2: error handler thread failed to spawn, error = -4
mptspi: ioc0: WARNING - Unable to register controller with SCSI subsystem
Backtrace:
[<1045b7cc>] mptspi_probe+0x248/0x3d0 [mptspi]
[<40946470>] pci_device_probe+0x1ac/0x2d8
[<40add668>] really_probe+0x1bc/0x988
[<40ade704>] driver_probe_device+0x160/0x218
[<40adee24>] device_driver_attach+0x160/0x188
[<40adef90>] __driver_attach+0x144/0x320
[<40ad7c78>] bus_for_each_dev+0xd4/0x158
[<40adc138>] driver_attach+0x4c/0x80
[<40adb3ec>] bus_add_driver+0x3e0/0x498
[<40ae0130>] driver_register+0xf4/0x298
[<409450c4>] __pci_register_driver+0x78/0xa8
[<0007d248>] mptspi_init+0x18c/0x1c4 [mptspi]
This patch adds the necessary NULL-pointer checks.
Successfully tested on a HP C8000 parisc workstation with buggy SCSI drives.
Signed-off-by: Helge Deller
Cc:
diff --git a/drivers/message/fusion/mptscsih.c
b/drivers/message/fusion/mptscsih.c
index 8543f0324d5a..0d1b2b0eb843 100644
--- a/drivers/message/fusion/mptscsih.c
+++ b/drivers/message/fusion/mptscsih.c
@@ -1176,8 +1176,10 @@ mptscsih_remove(struct pci_dev *pdev)
MPT_SCSI_HOST *hd;
int sz1;
- if((hd = shost_priv(host)) == NULL)
- return;
+ if (host == NULL)
+ hd = NULL;
+ else
+ hd = shost_priv(host);
mptscsih_shutdown(pdev);
@@ -1193,14 +1195,15 @@ mptscsih_remove(struct pci_dev *pdev)
"Free'd ScsiLookup (%d) memory\n",
ioc->name, sz1));
- kfree(hd->info_kbuf);
+ if (hd)
+ kfree(hd->info_kbuf);
/* NULL the Scsi_Host pointer
*/
ioc->sh = NULL;
- scsi_host_put(host);
-
+ if (host)
+ scsi_host_put(host);
mpt_detach(pdev);
}
nfsroot: Default mount option should ask for built-in NFS version
Change the nfsroot default mount option to ask for NFSv2 only *if* the kernel was built with NFSv2 support. If not, default to NFSv3 or as last choice to NFSv4, depending on actual kernel config. Signed-off-by: Helge Deller diff --git a/fs/nfs/nfsroot.c b/fs/nfs/nfsroot.c index 8d3278805602..fa148308822c 100644 --- a/fs/nfs/nfsroot.c +++ b/fs/nfs/nfsroot.c @@ -88,7 +88,13 @@ #define NFS_ROOT "/tftpboot/%s" /* Default NFSROOT mount options. */ +#if defined(CONFIG_NFS_V2) #define NFS_DEF_OPTIONS"vers=2,tcp,rsize=4096,wsize=4096" +#elif defined(CONFIG_NFS_V3) +#define NFS_DEF_OPTIONS"vers=3,tcp,rsize=4096,wsize=4096" +#else +#define NFS_DEF_OPTIONS"vers=4,tcp,rsize=4096,wsize=4096" +#endif /* Parameters passed from the kernel command line */ static char nfs_root_parms[NFS_MAXPATHLEN + 1] __initdata = "";
[GIT PULL] parisc architecture updates for kernel v5.10-rc1
Hi Linus, please pull the fixes and updates for the parisc architecture for kernel 5.10-rc1 from: git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git parisc-5.10-1 This patchset includes: * Added fw_cfg support for parisc on qemu * Added font support in sti text console driver for byte- and word-mode ROMs * Switch to more fine grained lws locks and improve spinlock handling * Add ioread64_hi_lo() and iowrite64_hi_lo() to avoid 0-day linking errors * Mark pointers volatile in __xchg8(), __xchg32() and __xchg64() to help compiler * Header file cleanups, mostly removal of unused HP-UX compat defines * Drop one bit from our O_NONBLOCK define to become now 00020 * Add MAP_UNINITIALIZED define to avoid userspace compile errors * Drop CONFIG_IDE from defconfigs * Speed up synchronize_caches() on UP machines * Rewrite tlb flush threshold calculation * Comment fixes and cleanups Thanks, Helge The following changes since commit 3e4fb4346c781068610d03c12b16c0cfb0fd24a3: Merge tag 'spdx-5.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/spdx (2020-10-14 16:19:42 -0700) are available in the Git repository at: http://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git parisc-5.10-1 for you to fetch changes up to 7ff3f14ddc355bfbc94c766f43b90606b1f79e83: parisc/sticon: Add user font support (2020-10-15 08:12:59 +0200) Christoph Hellwig (1): parisc: disable CONFIG_IDE in defconfigs Helge Deller (11): fw_cfg: Add support for parisc architecture parisc: Add qemu fw_cfg interface parisc: Avoid external interrupts when IPI finishes parisc: Drop HP-UX specific fcntl and signal flags parisc: Define O_NONBLOCK to become 00020 parisc: Drop useless comments in uapi/asm/signal.h parisc: Add ioread64_hi_lo() and iowrite64_hi_lo() parisc: Install vmlinuz instead of zImage file parisc: Add MAP_UNINITIALIZED define parisc/sticon: Always register sticon console driver parisc/sticon: Add user font support John David Anglin (6): parisc: Add alternative patching to synchronize_caches define parisc: Fix comments and enable interrupts later parisc: Mark pointers volatile in __xchg8(), __xchg32() and __xchg64() parisc: Switch to more fine grained lws locks parisc: Rewrite tlb flush threshold calculation parisc: Improve spinlock handling arch/parisc/Kconfig | 1 + arch/parisc/configs/generic-32bit_defconfig | 6 +- arch/parisc/configs/generic-64bit_defconfig | 6 +- arch/parisc/include/asm/barrier.h | 6 +- arch/parisc/include/asm/cmpxchg.h | 14 +- arch/parisc/include/asm/futex.h | 4 +- arch/parisc/include/asm/socket.h| 4 +- arch/parisc/include/asm/spinlock.h | 23 ++- arch/parisc/include/uapi/asm/fcntl.h| 7 +- arch/parisc/include/uapi/asm/mman.h | 1 + arch/parisc/include/uapi/asm/signal.h | 5 +- arch/parisc/install.sh | 2 +- arch/parisc/kernel/cache.c | 18 +- arch/parisc/kernel/entry.S | 14 +- arch/parisc/kernel/inventory.c | 30 +++ arch/parisc/kernel/smp.c| 9 +- arch/parisc/kernel/syscall.S| 10 +- arch/parisc/lib/bitops.c| 6 +- arch/parisc/lib/iomap.c | 18 ++ drivers/firmware/Kconfig| 2 +- drivers/firmware/qemu_fw_cfg.c | 3 + drivers/video/console/Kconfig | 1 + drivers/video/console/sticon.c | 297 drivers/video/console/sticore.c | 284 +- drivers/video/fbdev/sticore.h | 27 ++- tools/arch/parisc/include/uapi/asm/mman.h | 1 - 26 files changed, 453 insertions(+), 346 deletions(-)
Re: [PATCH] USB: serial: ftdi_sio: Fix serial port stall after resume
On 10/8/20 5:21 PM, Johan Hovold wrote:
> On Tue, Sep 29, 2020 at 09:33:27PM +0200, Helge Deller wrote:
>> With a 4-port serial USB HUB with FT232BM chips the serial ports stop
>> working after a software suspend/resume cycle.
>> Rewriting the latency timer during the resume phase fixes it.
>
> Hmm. This sounds weird. Why would the latency timer make such a
> difference?
Actually, I don't know.
My assumption is, that by setting the latency timer, the USB
transmissions somehow starts again. Maybe the integrated HUB is involved as
well?
I'm no expert on this driver, the only thing I did is to compare
what is being configured when the device is detected and initialized
and when what happens when it's waked up.
Setting the latency timer seemed to me to be the only difference,
and it actually worked then.
But I agree, it seems weird. If you have other ideas, I'm happy
to test.
>> Cc: sta...@vger.kernel.org
>> Signed-off-by: Helge Deller
>>
>> diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
>> index 9823bb424abd..8ee6cf6215c1 100644
>> --- a/drivers/usb/serial/ftdi_sio.c
>> +++ b/drivers/usb/serial/ftdi_sio.c
>> @@ -1092,6 +1092,7 @@ static u32 ftdi_232bm_baud_base_to_divisor(int baud,
>> int base);
>> static u32 ftdi_232bm_baud_to_divisor(int baud);
>> static u32 ftdi_2232h_baud_base_to_divisor(int baud, int base);
>> static u32 ftdi_2232h_baud_to_divisor(int baud);
>> +static int ftdi_reset_resume(struct usb_serial *serial);
>>
>> static struct usb_serial_driver ftdi_sio_device = {
>> .driver = {
>> @@ -1122,6 +1123,7 @@ static struct usb_serial_driver ftdi_sio_device = {
>> .set_termios = ftdi_set_termios,
>> .break_ctl =ftdi_break_ctl,
>> .tx_empty = ftdi_tx_empty,
>> +.reset_resume = ftdi_reset_resume,
>> };
>>
>> static struct usb_serial_driver * const serial_drivers[] = {
>> @@ -2379,6 +2381,16 @@ static int ftdi_stmclite_probe(struct usb_serial
>> *serial)
>> return 0;
>> }
>>
>> +static int ftdi_reset_resume(struct usb_serial *serial)
>> +{
>> +struct usb_serial_port *port = serial->port[0];
>> +
>> +if (tty_port_initialized(>port))
>> +write_latency_timer(port);
>
> Why are you only doing this for open ports?
I more or less copied it from another driver
>> +
>> +return usb_serial_generic_resume(serial);
>> +}
>
> And if the device has been reset there may need to reconfigured the
> termios settings for open ports.
>
> Could you expand a bit on what the problem is here?
My testcase is pretty simple:
1. I use e.g. "minicom -D /dev/ttyUSB2". Serial connection works.
2. I exit minicom.
3. I suspend the workstation: "systemctl suspend"
4. I wake up the machine and wait a few seconds.
5. I start "minicom -D /dev/ttyUSB2" again. No transfers on the serial port.
With my patch the minicom serial communications does work.
Another way to wake up the connection is to rmmod the driver and insmod it
again.
Helge
[PATCH] USB: serial: ftdi_sio: Fix serial port stall after resume
With a 4-port serial USB HUB with FT232BM chips the serial ports stop
working after a software suspend/resume cycle.
Rewriting the latency timer during the resume phase fixes it.
Cc: sta...@vger.kernel.org
Signed-off-by: Helge Deller
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 9823bb424abd..8ee6cf6215c1 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -1092,6 +1092,7 @@ static u32 ftdi_232bm_baud_base_to_divisor(int baud, int
base);
static u32 ftdi_232bm_baud_to_divisor(int baud);
static u32 ftdi_2232h_baud_base_to_divisor(int baud, int base);
static u32 ftdi_2232h_baud_to_divisor(int baud);
+static int ftdi_reset_resume(struct usb_serial *serial);
static struct usb_serial_driver ftdi_sio_device = {
.driver = {
@@ -1122,6 +1123,7 @@ static struct usb_serial_driver ftdi_sio_device = {
.set_termios = ftdi_set_termios,
.break_ctl =ftdi_break_ctl,
.tx_empty = ftdi_tx_empty,
+ .reset_resume = ftdi_reset_resume,
};
static struct usb_serial_driver * const serial_drivers[] = {
@@ -2379,6 +2381,16 @@ static int ftdi_stmclite_probe(struct usb_serial *serial)
return 0;
}
+static int ftdi_reset_resume(struct usb_serial *serial)
+{
+ struct usb_serial_port *port = serial->port[0];
+
+ if (tty_port_initialized(>port))
+ write_latency_timer(port);
+
+ return usb_serial_generic_resume(serial);
+}
+
static int ftdi_sio_port_remove(struct usb_serial_port *port)
{
struct ftdi_private *priv = usb_get_serial_port_data(port);
Re: [PATCH 07/28] 53c700: improve non-coherent DMA handling
Hi Willy, On 01.09.20 18:53, Matthew Wilcox wrote: > On Tue, Sep 01, 2020 at 06:41:12PM +0200, Helge Deller wrote: >>> I still have a zoo of machines running for such testing, including a >>> 715/64 and two 730. >>> I'm going to test this git tree on the 715/64: > > The 715/64 is a 7100LC machine though. I think you need to boot on > the 730 to test the non-coherent path. Just tested the 730, and it works as well. Helge
Re: [PATCH 07/28] 53c700: improve non-coherent DMA handling
On 01.09.20 18:21, Helge Deller wrote: > On 01.09.20 17:22, James Bottomley wrote: >> On Tue, 2020-09-01 at 16:05 +0100, Matthew Wilcox wrote: >>> On Tue, Sep 01, 2020 at 07:52:40AM -0700, James Bottomley wrote: >>>> I think this looks mostly OK, except for one misnamed parameter >>>> below. Unfortunately, the last non-coherent parisc was the 700 >>>> series and I no longer own a box, so I can't test that part of it >>>> (I can fire up the C360 to test it on a coherent arch). >>> >>> I have a 715/50 that probably hasn't been powered on in 15 years if >>> you need something that old to test on (I believe the 725/100 uses >>> the 7100LC and so is coherent). I'll need to set up a cross-compiler >>> ... >> >> I'm not going to say no to actual testing, but it's going to be a world >> of pain getting something so old going. I do have a box of older >> systems I keep for architectural testing that I need to rummage around >> in ... I just have a vague memory that my 715 actually caught fire a >> decade ago and had to be disposed of. > > I still have a zoo of machines running for such testing, including a > 715/64 and two 730. > I'm going to test this git tree on the 715/64: > git://git.infradead.org/users/hch/misc.git dma_alloc_pages This tree boots nicely (up to a command prompt with i82596 nic working): 53c700: Version 2.8 By james.bottom...@hansenpartnership.com scsi0: 53c710 rev 2 scsi host0: LASI SCSI 53c700 scsi 0:0:6:0: Direct-Access QUANTUM FIREBALL_TM3200S 300X PQ: 0 ANSI: 2 scsi target0:0:6: Beginning Domain Validation scsi 0:0:6:0: tag#56 Enabling Tag Command Queuing scsi target0:0:6: asynchronous scsi target0:0:6: FAST-10 SCSI 10.0 MB/s ST (100 ns, offset 8) scsi target0:0:6: Domain Validation skipping write tests scsi target0:0:6: Ending Domain Validation scsi 0:0:6:1: tag#63 Disabling Tag Command Queuing st: Version 20160209, fixed bufsize 32768, s/g segs 256 sd 0:0:6:0: Power-on or device reset occurred sd 0:0:6:0: Attached scsi generic sg0 type 0 LASI 82596 driver - Revision: 1.30 Found i82596 at 0xf0107000, IRQ 17 eth0: 82596 at 0xf0107000, 08:00:09:c2:9e:60 IRQ 17. sd 0:0:6:0: [sda] 6281856 512-byte logical blocks: (3.22 GB/3.00 GiB) sd 0:0:6:0: [sda] Write Protect is off Christoph, you may add a Tested-by: Helge Deller # parisc to the series. Helge
Re: [PATCH 07/28] 53c700: improve non-coherent DMA handling
On 01.09.20 17:22, James Bottomley wrote: > On Tue, 2020-09-01 at 16:05 +0100, Matthew Wilcox wrote: >> On Tue, Sep 01, 2020 at 07:52:40AM -0700, James Bottomley wrote: >>> I think this looks mostly OK, except for one misnamed parameter >>> below. Unfortunately, the last non-coherent parisc was the 700 >>> series and I no longer own a box, so I can't test that part of it >>> (I can fire up the C360 to test it on a coherent arch). >> >> I have a 715/50 that probably hasn't been powered on in 15 years if >> you need something that old to test on (I believe the 725/100 uses >> the 7100LC and so is coherent). I'll need to set up a cross-compiler >> ... > > I'm not going to say no to actual testing, but it's going to be a world > of pain getting something so old going. I do have a box of older > systems I keep for architectural testing that I need to rummage around > in ... I just have a vague memory that my 715 actually caught fire a > decade ago and had to be disposed of. I still have a zoo of machines running for such testing, including a 715/64 and two 730. I'm going to test this git tree on the 715/64: git://git.infradead.org/users/hch/misc.git dma_alloc_pages Helge
Re: a saner API for allocating DMA addressable pages
Hi Christoph, On 19.08.20 08:55, Christoph Hellwig wrote: > this series replaced the DMA_ATTR_NON_CONSISTENT flag to dma_alloc_attrs > with a separate new dma_alloc_pages API, which is available on all > platforms. In addition to cleaning up the convoluted code path, this > ensures that other drivers that have asked for better support for > non-coherent DMA to pages with incurring bounce buffering over can finally > be properly supported. > > A git tree is available here: > > git://git.infradead.org/users/hch/misc.git dma_alloc_pages I've tested this tree on my parisc machine which uses the 53c700 and lasi_82596 drivers. Everything worked as expected, so you may add: Tested-by: Helge Deller # parisc Thanks! Helge > > Gitweb: > > > http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/dma_alloc_pages > > > Diffstat: > Documentation/core-api/dma-api.rst | 92 ++ > Documentation/core-api/dma-attributes.rst|8 > Documentation/userspace-api/media/v4l/buffer.rst | 17 - > Documentation/userspace-api/media/v4l/vidioc-reqbufs.rst |1 > arch/alpha/kernel/pci_iommu.c|2 > arch/arm/include/asm/dma-direct.h|4 > arch/arm/mm/dma-mapping-nommu.c |2 > arch/arm/mm/dma-mapping.c|4 > arch/ia64/Kconfig|3 > arch/ia64/hp/common/sba_iommu.c |2 > arch/ia64/kernel/dma-mapping.c | 14 > arch/ia64/mm/init.c |3 > arch/mips/Kconfig|1 > arch/mips/bmips/dma.c|4 > arch/mips/cavium-octeon/dma-octeon.c |4 > arch/mips/include/asm/dma-direct.h |4 > arch/mips/include/asm/jazzdma.h |2 > arch/mips/jazz/jazzdma.c | 102 +-- > arch/mips/loongson2ef/fuloong-2e/dma.c |4 > arch/mips/loongson2ef/lemote-2f/dma.c|4 > arch/mips/loongson64/dma.c |4 > arch/mips/mm/dma-noncoherent.c | 48 +-- > arch/mips/pci/pci-ar2315.c |4 > arch/mips/pci/pci-xtalk-bridge.c |4 > arch/mips/sgi-ip32/ip32-dma.c|4 > arch/parisc/Kconfig |1 > arch/parisc/kernel/pci-dma.c |6 > arch/powerpc/include/asm/dma-direct.h|4 > arch/powerpc/kernel/dma-iommu.c |2 > arch/powerpc/platforms/ps3/system-bus.c |4 > arch/powerpc/platforms/pseries/vio.c |2 > arch/s390/pci/pci_dma.c |2 > arch/x86/kernel/amd_gart_64.c|8 > drivers/gpu/drm/exynos/exynos_drm_gem.c |2 > drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c |3 > drivers/iommu/dma-iommu.c|2 > drivers/iommu/intel/iommu.c |6 > drivers/media/common/videobuf2/videobuf2-core.c | 36 -- > drivers/media/common/videobuf2/videobuf2-dma-contig.c| 19 - > drivers/media/common/videobuf2/videobuf2-dma-sg.c|3 > drivers/media/common/videobuf2/videobuf2-v4l2.c | 12 > drivers/net/ethernet/amd/au1000_eth.c| 15 - > drivers/net/ethernet/i825xx/lasi_82596.c | 36 +- > drivers/net/ethernet/i825xx/lib82596.c | 148 +- > drivers/net/ethernet/i825xx/sni_82596.c | 23 - > drivers/net/ethernet/seeq/sgiseeq.c | 24 - > drivers/nvme/host/pci.c | 79 ++--- > drivers/parisc/ccio-dma.c|2 > drivers/parisc/sba_iommu.c |2 > drivers/scsi/53c700.c| 120 > drivers/scsi/53c700.h|9 > drivers/scsi/sgiwd93.c | 14 > drivers/xen/swiotlb-xen.c|2 > include/linux/dma-direct.h | 55 ++- > include/linux/dma-mapping.h | 32 +- > include/linux/dma-noncoherent.h | 21 - > include/linux/dmapool.h | 23
Re: [PATCH v2 15/23] parisc: use asm-generic/mmu_context.h for no-op implementations
On 26.08.20 16:52, Nicholas Piggin wrote:
> Cc: "James E.J. Bottomley"
> Cc: Helge Deller
> Cc: linux-par...@vger.kernel.org
> Signed-off-by: Nicholas Piggin
Acked-by: Helge Deller
> ---
> arch/parisc/include/asm/mmu_context.h | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/arch/parisc/include/asm/mmu_context.h
> b/arch/parisc/include/asm/mmu_context.h
> index cb5f2f730421..46f8c22c5977 100644
> --- a/arch/parisc/include/asm/mmu_context.h
> +++ b/arch/parisc/include/asm/mmu_context.h
> @@ -7,16 +7,13 @@
> #include
> #include
>
> -static inline void enter_lazy_tlb(struct mm_struct *mm, struct task_struct
> *tsk)
> -{
> -}
> -
> /* on PA-RISC, we actually have enough contexts to justify an allocator
> * for them. prumpf */
>
> extern unsigned long alloc_sid(void);
> extern void free_sid(unsigned long);
>
> +#define init_new_context init_new_context
> static inline int
> init_new_context(struct task_struct *tsk, struct mm_struct *mm)
> {
> @@ -26,6 +23,7 @@ init_new_context(struct task_struct *tsk, struct mm_struct
> *mm)
> return 0;
> }
>
> +#define destroy_context destroy_context
> static inline void
> destroy_context(struct mm_struct *mm)
> {
> @@ -71,8 +69,7 @@ static inline void switch_mm(struct mm_struct *prev,
> }
> #define switch_mm_irqs_off switch_mm_irqs_off
>
> -#define deactivate_mm(tsk,mm)do { } while (0)
> -
> +#define activate_mm activate_mm
> static inline void activate_mm(struct mm_struct *prev, struct mm_struct
> *next)
> {
> /*
> @@ -90,4 +87,7 @@ static inline void activate_mm(struct mm_struct *prev,
> struct mm_struct *next)
>
> switch_mm(prev,next,current);
> }
> +
> +#include
> +
> #endif
>
Re: [PATCH] parisc: fix PMD pages allocation by restoring pmd_alloc_one()
On 16.08.20 19:52, Linus Torvalds wrote: > On Sun, Aug 16, 2020 at 10:43 AM Mike Rapoport wrote: >> >> I presume this is going via parisc tree, do you mind fixing up >> while applying? > > I'll take it directly to not miss rc1, and I'll fix up the typo too. Thanks! Helge
[GIT PULL] parisc architecture updates for kernel v5.9
Hi Linus, please pull another set of patches for the parisc architecture for kernel 5.9-rc1 from: git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git parisc-5.9-2 This patchset includes: - Oscar Carter contributed a patch which fixes parisc's usage of dereference_function_descriptor() and thus will allow using the -Wcast-function-type compiler option in the top-level Makefile - Sven Schnelle fixed a bug in the SBA code to prevent crashes during kexec - John David Anglin provided implementations for __smp_store_release() and __smp_load_acquire barriers() which avoids using the sync assembler instruction and thus speeds up barrier paths - Some whitespace cleanups in parisc's atomic.h header file Thanks, Helge Helge Deller (2): sections.h: dereference_function_descriptor() returns void pointer parisc: Whitespace cleanups in atomic.h John David Anglin (1): parisc: Implement __smp_store_release and __smp_load_acquire barriers Oscar Carter (1): parisc/kernel/ftrace: Remove function callback casts Sven Schnelle (1): parisc: mask out enable and reserved bits from sba imask arch/parisc/include/asm/atomic.h | 8 ++--- arch/parisc/include/asm/barrier.h | 61 +++ arch/parisc/kernel/ftrace.c | 3 +- drivers/parisc/sba_iommu.c| 2 +- include/asm-generic/sections.h| 4 +-- 5 files changed, 70 insertions(+), 8 deletions(-)
[PATCH] sections.h: dereference_function_descriptor() returns void pointer
The function dereference_function_descriptor() takes on hppa64, ppc64 and ia64 a pointer to a function descriptor and returns a (void) pointer to the dereferenced function. To make cross-arch coding easier, on all other architectures the dereference_function_descriptor() macro should return a void pointer too. Signed-off-by: Helge Deller diff --git a/include/asm-generic/sections.h b/include/asm-generic/sections.h index 66397ed10acb..d16302d3eb59 100644 --- a/include/asm-generic/sections.h +++ b/include/asm-generic/sections.h @@ -60,8 +60,8 @@ extern __visible const void __nosave_begin, __nosave_end; /* Function descriptor handling (if any). Override in asm/sections.h */ #ifndef dereference_function_descriptor -#define dereference_function_descriptor(p) (p) -#define dereference_kernel_function_descriptor(p) (p) +#define dereference_function_descriptor(p) ((void *)(p)) +#define dereference_kernel_function_descriptor(p) ((void *)(p)) #endif /* random extra sections (if any). Override
[GIT PULL] parisc architecture updates for kernel v5.9
Hi Linus, please pull the parisc architecture updates for kernel 5.9-rc1 from: git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git parisc-5.9-1 The majority of the patches are reverts of previous commits regarding the parisc-specific low level spinlocking code and barrier handling, with which we tried to fix CPU stalls on our build servers. In the end John David Anglin found the culprit: We missed a define for atomic64_set_release(). This seems to have fixed our issues, so now it's good to remove the unnecessary code again. Other than that it's trivial stuff: Spelling fixes, constifications and such. Thanks, Helge Alexander A. Klimov (1): parisc: Replace HTTP links with HTTPS ones Helge Deller (6): parisc: Convert to BIT_MASK() and BIT_WORD() parisc: Report bad pages as HardwareCorrupted Revert "parisc: Improve interrupt handling in arch_spin_lock_flags()" Revert "parisc: Drop LDCW barrier in CAS code when running UP" Revert "parisc: Use ldcw instruction for SMP spinlock release barrier" Revert "parisc: Revert "Release spinlocks using ordered store"" John David Anglin (1): parisc: Do not use an ordered store in pa_tlb_lock() Randy Dunlap (1): parisc: elf.h: delete a duplicated word Rolf Eike Beer (1): parisc: make the log level string for register dumps const arch/parisc/Kconfig| 2 +- arch/parisc/include/asm/bitops.h | 41 +++- arch/parisc/include/asm/elf.h | 2 +- arch/parisc/include/asm/spinlock.h | 33 -- arch/parisc/kernel/entry.S | 48 -- arch/parisc/kernel/pdt.c | 3 +++ arch/parisc/kernel/syscall.S | 24 --- arch/parisc/kernel/traps.c | 6 ++--- arch/parisc/mm/init.c | 12 +- 9 files changed, 66 insertions(+), 105 deletions(-)
[GIT PULL] parisc architecture fixes for kernel v5.8
Hi Linus, please pull two late parisc architecture fixes for kernel 5.8 from: git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git parisc-5.8-2 Two fixes: - Add the cmpxchg() function for pointers to u8 values. This fixes a kernel linking error when building the tusb1210 driver (from Liam Beguin). - Add a define for atomic64_set_release() to fix CPU soft lockups which happen because of missing unlocks while processing bit operations (from John David Anglin). Thanks, Helge John David Anglin (1): parisc: Add atomic64_set_release() define to avoid CPU soft lockups Liam Beguin (1): parisc: add support for cmpxchg on u8 pointers arch/parisc/include/asm/atomic.h | 2 ++ arch/parisc/include/asm/cmpxchg.h | 2 ++ arch/parisc/lib/bitops.c | 12 3 files changed, 16 insertions(+)
Re: [PATCH] parisc/kernel/ftrace: Remove function callback casts
On 27.06.20 15:43, Oscar Carter wrote: > In an effort to enable -Wcast-function-type in the top-level Makefile to > support Control Flow Integrity builds, remove all the function callback > casts. > > To do this remove the cast to a function pointer type in the comparison > statement and add to the right and left operand a cast to unsigned long > type. This can be done since the comparison is against function address > (these operands are not function calls). On some architectures (namely ia64, ppc64 and parisc64) function pointers actually refer to function descriptors, which in turn point to the real function address. The compiler usually takes care of such comparism. That said, casting to "unsigned long" might break this... > Signed-off-by: Oscar Carter > --- > arch/parisc/kernel/ftrace.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/parisc/kernel/ftrace.c b/arch/parisc/kernel/ftrace.c > index 1df0f67ed667..86b49a5fc049 100644 > --- a/arch/parisc/kernel/ftrace.c > +++ b/arch/parisc/kernel/ftrace.c > @@ -64,7 +64,7 @@ void notrace __hot ftrace_function_trampoline(unsigned long > parent, > function_trace_op, regs); > > #ifdef CONFIG_FUNCTION_GRAPH_TRACER > - if (ftrace_graph_return != (trace_func_graph_ret_t) ftrace_stub || > + if ((unsigned long)ftrace_graph_return != (unsigned long)ftrace_stub || Untested, but maybe better use: dereference_function_descriptor(ftrace_graph_return) != dereference_function_descriptor(ftrace_stub) ? Helge
Re: rename probe_kernel_* and probe_user_*
On 18.06.20 21:48, Linus Torvalds wrote: > [ Explicitly added architecture lists and developers to the cc to make > this more visible ] > > On Wed, Jun 17, 2020 at 12:38 AM Christoph Hellwig wrote: >> >> Andrew and I decided to drop the patches implementing your suggested >> rename of the probe_kernel_* and probe_user_* helpers from -mm as there >> were way to many conflicts. After -rc1 might be a good time for this as >> all the conflicts are resolved now. > > So I've merged this renaming now, together with my changes to make > 'get_kernel_nofault()' look and act a lot more like 'get_user()'. > > It just felt wrong (and potentially dangerous) to me to have a > 'get_kernel_nofault()' naming that implied semantics that we're all > familiar with from 'get_user()', but acting very differently. > > But part of the fixups I made for the type checking are for > architectures where I didn't even compile-test the end result. I > looked at every case individually, and the patch looks sane, but I > could have screwed something up. > > Basically, 'get_kernel_nofault()' doesn't do the same automagic type > munging from the pointer to the target that 'get_user()' does, but at > least now it checks that the types are superficially compatible. > There should be build failures if they aren't, but I hopefully fixed > everything up properly for all architectures. > > This email is partly to ask people to double-check, but partly just as > a heads-up so that _if_ I screwed something up, you'll have the > background and it won't take you by surprise. Linus. thanks for the heads-up! With your change it compiles cleanly on 32- and 64-bit parisc. Helge
Re: [PATCH 26/38] vt: use newly defined CUR_* macros
On 15.06.20 09:48, Jiri Slaby wrote:
> We defined macros for all the magic constants in the previous patch. So
> let us use the macro in the code now.
>
> No functional change intended.
>
> Signed-off-by: Jiri Slaby
> Cc: Thomas Winischhofer
> Cc: Bartlomiej Zolnierkiewicz
> Cc: "James E.J. Bottomley"
> Cc: Helge Deller
> Cc: linux-...@vger.kernel.org
> Cc: dri-de...@lists.freedesktop.org
> Cc: linux-fb...@vger.kernel.org
> Cc: linux-par...@vger.kernel.org
Acked-by: Helge Deller
Thanks!
Helge
> ---
> drivers/tty/vt/vt.c | 22 +-
> drivers/usb/misc/sisusbvga/sisusb_con.c | 2 +-
> drivers/video/console/mdacon.c | 2 +-
> drivers/video/console/sticon.c | 2 +-
> drivers/video/console/vgacon.c | 2 +-
> drivers/video/fbdev/core/bitblit.c | 2 +-
> drivers/video/fbdev/core/fbcon.c| 2 +-
> drivers/video/fbdev/core/fbcon_ccw.c| 2 +-
> drivers/video/fbdev/core/fbcon_cw.c | 2 +-
> drivers/video/fbdev/core/fbcon_ud.c | 2 +-
> drivers/video/fbdev/core/tileblit.c | 2 +-
> 11 files changed, 23 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
> index af1ef717f416..2b9fc628f05b 100644
> --- a/drivers/tty/vt/vt.c
> +++ b/drivers/tty/vt/vt.c
> @@ -866,17 +866,18 @@ static void add_softcursor(struct vc_data *vc)
> int i = scr_readw((u16 *) vc->vc_pos);
> u32 type = vc->vc_cursor_type;
>
> - if (!(type & 0x10))
> + if (!(type & CUR_SW))
> return;
> if (softcursor_original != -1)
> return;
> softcursor_original = i;
> - i |= (type >> 8) & 0xff00;
> - i ^= type & 0xff00;
> - if ((type & 0x20) && (softcursor_original & 0x7000) == (i & 0x7000))
> - i ^= 0x7000;
> - if ((type & 0x40) && (i & 0x700) == ((i & 0x7000) >> 4))
> - i ^= 0x0700;
> + i |= CUR_SET(type);
> + i ^= CUR_CHANGE(type);
> + if ((type & CUR_ALWAYS_BG) &&
> + (softcursor_original & CUR_BG) == (i & CUR_BG))
> + i ^= CUR_BG;
> + if ((type & CUR_INVERT_FG_BG) && (i & CUR_FG) == ((i & CUR_BG) >> 4))
> + i ^= CUR_FG;
> scr_writew(i, (u16 *)vc->vc_pos);
> if (con_should_update(vc))
> vc->vc_sw->con_putc(vc, i, vc->state.y, vc->state.x);
> @@ -910,7 +911,7 @@ static void set_cursor(struct vc_data *vc)
> if (vc_is_sel(vc))
> clear_selection();
> add_softcursor(vc);
> - if ((vc->vc_cursor_type & 0x0f) != 1)
> + if (CUR_SIZE(vc->vc_cursor_type) != CUR_NONE)
> vc->vc_sw->con_cursor(vc, CM_DRAW);
> } else
> hide_cursor(vc);
> @@ -2322,7 +2323,10 @@ static void do_con_trol(struct tty_struct *tty, struct
> vc_data *vc, int c)
> case 'c':
> if (vc->vc_priv == EPdec) {
> if (vc->vc_par[0])
> - vc->vc_cursor_type = vc->vc_par[0] |
> (vc->vc_par[1] << 8) | (vc->vc_par[2] << 16);
> + vc->vc_cursor_type =
> + CUR_MAKE(vc->vc_par[0],
> + vc->vc_par[1],
> + vc->vc_par[2]);
> else
> vc->vc_cursor_type = cur_default;
> return;
> diff --git a/drivers/usb/misc/sisusbvga/sisusb_con.c
> b/drivers/usb/misc/sisusbvga/sisusb_con.c
> index 80657c49310a..1058eaba3084 100644
> --- a/drivers/usb/misc/sisusbvga/sisusb_con.c
> +++ b/drivers/usb/misc/sisusbvga/sisusb_con.c
> @@ -727,7 +727,7 @@ sisusbcon_cursor(struct vc_data *c, int mode)
>
> baseline = c->vc_font.height - (c->vc_font.height < 10 ? 1 : 2);
>
> - switch (c->vc_cursor_type & 0x0f) {
> + switch (CUR_SIZE(c->vc_cursor_type)) {
> case CUR_BLOCK: from = 1;
> to = c->vc_font.height;
> break;
> diff --git a/drivers/video/console/mdacon.c b/drivers/video/console/mdacon.c
> index 00cb6245fbef..ef29b321967f 100644
> --- a/drivers/video/console/mdacon.c
> +++ b/drivers/video/console/mdacon.c
> @@ -492,7 +492,7 @@ static void mdacon_cursor(struct vc_data *c, int mode)
>
&
Re: [PATCH] parisc: suppress error messages for 'make clean'
On 13.06.20 21:36, Rolf Eike Beer wrote: > Helge Deller wrote: >> On 10.05.20 03:19, Masahiro Yamada wrote: >>> Hi Helge, >>> >>> On Sun, May 10, 2020 at 2:39 AM Helge Deller wrote: > >>> I will drop this patch from my kbuild tree, >>> then you will apply what you think is best >>> to your tree. >>> >>> What do you think? >> >> Sure, I'll take it through the parisc tree. > > Is this already in 5.7.2? No, because it went into 5.8 kernel and not backwards into 5.7.x: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0d341e0ddb1a3444716420ad9151949c02adbe4e Helge > I get these: > > pioneer /usr/src/linux-5.7.1-gentoo # make distclean > gcc: error: missing argument to '-Wframe-larger-than=' > gcc: error: missing argument to '-Wframe-larger-than=' > CLEAN arch/parisc/kernel > gcc: error: missing argument to '-Wframe-larger-than=' > gcc: error: missing argument to '-Wframe-larger-than=' signature.asc Description: OpenPGP digital signature
[GIT PULL] parisc architecture updates for kernel v5.8-rc1
Hi Linus, please pull the parisc architecture updates for kernel 5.8-rc1 from: git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git parisc-5.8-1 Enable the sysctl file interface for panic_on_stackoverflow for parisc, a warning fix and a bunch of documentation updates since the parisc website is now at https://parisc.wiki.kernel.org Thanks, Helge Arnd Bergmann (1): parisc: use -fno-strict-aliasing for decompressor Helge Deller (6): parisc: suppress error messages for 'make clean' parisc: Kconfig: Update references to parisc website parisc: firmware: Update references to parisc website parisc: hardware: Update references to parisc website parisc: module: Update references to parisc website parisc: MAINTAINERS: Update references to parisc website Xiaoming Ni (1): parisc: add sysctl file interface panic_on_stackoverflow MAINTAINERS | 2 +- arch/parisc/Kconfig | 2 +- arch/parisc/Makefile | 4 ++-- arch/parisc/boot/compressed/Makefile | 1 + arch/parisc/kernel/firmware.c| 3 ++- arch/parisc/kernel/hardware.c| 3 ++- arch/parisc/kernel/module.c | 4 ++-- kernel/sysctl.c | 20 +++- 8 files changed, 22 insertions(+), 17 deletions(-)
[PATCH v2] fs/signalfd.c: Fix inconsistent return codes for signalfd4
The kernel signalfd4() syscall returns different error codes when called
either in compat or native mode. This behaviour makes correct emulation in qemu
and testing programs like LTP more complicated.
Fix the code to always return -in both modes- EFAULT for unaccessible user
memory, and EINVAL when called with an invalid signal mask.
Signed-off-by: Helge Deller
---
Changelog v2:
- Rephrased commit message.
diff --git a/fs/signalfd.c b/fs/signalfd.c
index 44b6845b071c..5b78719be445 100644
--- a/fs/signalfd.c
+++ b/fs/signalfd.c
@@ -314,9 +314,10 @@ SYSCALL_DEFINE4(signalfd4, int, ufd, sigset_t __user *,
user_mask,
{
sigset_t mask;
- if (sizemask != sizeof(sigset_t) ||
- copy_from_user(, user_mask, sizeof(mask)))
+ if (sizemask != sizeof(sigset_t))
return -EINVAL;
+ if (copy_from_user(, user_mask, sizeof(mask)))
+ return -EFAULT;
return do_signalfd4(ufd, , flags);
}
@@ -325,9 +326,10 @@ SYSCALL_DEFINE3(signalfd, int, ufd, sigset_t __user *,
user_mask,
{
sigset_t mask;
- if (sizemask != sizeof(sigset_t) ||
- copy_from_user(, user_mask, sizeof(mask)))
+ if (sizemask != sizeof(sigset_t))
return -EINVAL;
+ if (copy_from_user(, user_mask, sizeof(mask)))
+ return -EFAULT;
return do_signalfd4(ufd, , 0);
}
[GIT PULL] parisc architecture fix for kernel v5.7
Hi Linus, please pull a kernel panic fix for the parisc architecture for kernel 5.7 from: git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git parisc-5.7-2 Fix a kernel panic at boot time for some HP-PARISC machines. Thanks, Helge Helge Deller (1): parisc: Fix kernel panic in mem_init() arch/parisc/mm/init.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Re: [PATCH] parisc: suppress error messages for 'make clean'
On 10.05.20 03:19, Masahiro Yamada wrote: > Hi Helge, > > On Sun, May 10, 2020 at 2:39 AM Helge Deller wrote: >> >> * Masahiro Yamada : >>> Hi Helge, >>> >>> On Sat, May 9, 2020 at 6:46 AM Helge Deller wrote: >>>> >>>> * Masahiro Yamada : >>>>> On Sat, Apr 25, 2020 at 2:47 PM Masahiro Yamada >>>>> wrote: >>>>>> >>>>>> 'make ARCH=parisc clean' emits a tons of error messages as follows: >>>>>> >>>>>> $ make ARCH=parisc clean >>>>>> gcc: error: unrecognized command line option '-mno-space-regs' >>>>>> gcc: error: unrecognized command line option '-mfast-indirect-calls'; >>>>>> did you mean '-mforce-indirect-call'? >>>>>> gcc: error: unrecognized command line option '-mdisable-fpregs' >>>>>> gcc: error: missing argument to '-Wframe-larger-than=' >>>>>> gcc: error: unrecognized command line option '-mno-space-regs' >>>>>> gcc: error: unrecognized command line option '-mfast-indirect-calls'; >>>>>> did you mean '-mforce-indirect-call'? >>>>>> gcc: error: unrecognized command line option '-mdisable-fpregs' >>>>>> gcc: error: missing argument to '-Wframe-larger-than=' >>>>>> ... >>>>>> >>>>>> You can supporess them except '-Wframe-larger-than' by setting correct >>>>>> CROSS_COMPILE=, but we should not require any compiler for cleaning. >>>>>> >>>>>> This $(shell ...) is evaluated so many times because LIBGCC is exported. >>>>>> Use the ':=' operator to evaluate it just once, and sink the stderr. >>>>>> >>>>> >>>>> Applied to linux-kbuild. >>>> >>>> That patch breaks then building the boot loader/compressor: >>>> ... >>>> hppa-linux-gnu-ld-X -e startup --as-needed -T >>>> arch/parisc/boot/compressed/vmlinux.lds arch/parisc/boot/compressed/head.o >>>> arch/parisc/boot/compressed/real2.o arch/parisc/boot/compressed/firmware.o >>>> arch/parisc/boot/compressed/misc.o arch/parisc/boot/compressed/piggy.o -o >>>> arch/parisc/boot/compressed/vmlinux >>>> hppa-linux-gnu-ld: arch/parisc/boot/compressed/misc.o: in function >>>> `dec_vli': >>>> (.text+0x104): undefined reference to `__ashldi3' >>>> hppa-linux-gnu-ld: arch/parisc/boot/compressed/misc.o: in function >>>> `lzma_len': >>>> (.text+0x2b0): undefined reference to `$$mulI' >>>> hppa-linux-gnu-ld: (.text+0x344): undefined reference to `$$mulI' >>>> hppa-linux-gnu-ld: (.text+0x3f8): undefined reference to `$$mulI' >>>> >>>> >>>> The patch below works, but I wonder if it's possible to avoid >>>> to examine LIBGCC twice? >>>> >>>> Helge >>> >>> >>> Sorry for the breakage. >>> >>> How about moving LIBGCC below ? >> >> Good idea. >> The patch below does work for me. >> We do not need $KBUILD_CFLAGS to get the libgcc.a filename, > > > I not not sure about this change. > Generally speaking, the path to libgcc.a is affected > by compiler flags, especially, bit size flags, > endian flags, etc. > > For example, my distro gcc is biarch for i386/x86_64. > > $ gcc -print-libgcc-file-name > /usr/lib/gcc/x86_64-linux-gnu/9/libgcc.a > $ gcc -m64 -print-libgcc-file-name > /usr/lib/gcc/x86_64-linux-gnu/9/libgcc.a > $ gcc -m32 -print-libgcc-file-name > /usr/lib/gcc/x86_64-linux-gnu/9/32/libgcc.a > > One real example in Linux is arch/arc/Makefile. > ARC supports both big endian and little endian. > > If you drop cflags-y from line 59 > of arch/arc/Makefile, vmlinux fails to link > due to endian mismatch. > > > I am not familiar with parisc. > Also, as it turned out, > this change is not so trivial. > > I think the best approach is to leave this up to you > since you are the parisc maintainer. Yes, I knew about the possible biarch options. On parisc that's not relevant yet. > I will drop this patch from my kbuild tree, > then you will apply what you think is best > to your tree. > > What do you think? Sure, I'll take it through the parisc tree. Thanks! Helge >> so we do not need to pipe the output to /dev/null either. >> Can you try if that works, and if yes, can you apply it? >> >> Helge >> >> >> diff --git a/arch/parisc/Makefile b/arch/parisc/Makefile >> index 628cd8bb7ad8..fadbbd010337 100644 >> --- a/arch/parisc/Makefile >> +++ b/arch/parisc/Makefile >> @@ -21,8 +21,6 @@ KBUILD_IMAGE := vmlinuz >> >> NM = sh $(srctree)/arch/parisc/nm >> CHECKFLAGS += -D__hppa__=1 >> -LIBGCC = $(shell $(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name) >> -export LIBGCC >> >> ifdef CONFIG_64BIT >> UTS_MACHINE:= parisc64 >> @@ -110,6 +108,8 @@ cflags-$(CONFIG_PA8X00) += -march=2.0 >> -mschedule=8000 >> head-y := arch/parisc/kernel/head.o >> >> KBUILD_CFLAGS += $(cflags-y) >> +LIBGCC := $(shell $(CC) -print-libgcc-file-name) >> +export LIBGCC >> >> kernel-y := mm/ kernel/ math-emu/ >> > >
Re: [PATCH] parisc: suppress error messages for 'make clean'
* Masahiro Yamada : > Hi Helge, > > On Sat, May 9, 2020 at 6:46 AM Helge Deller wrote: > > > > * Masahiro Yamada : > > > On Sat, Apr 25, 2020 at 2:47 PM Masahiro Yamada > > > wrote: > > > > > > > > 'make ARCH=parisc clean' emits a tons of error messages as follows: > > > > > > > > $ make ARCH=parisc clean > > > > gcc: error: unrecognized command line option '-mno-space-regs' > > > > gcc: error: unrecognized command line option '-mfast-indirect-calls'; > > > > did you mean '-mforce-indirect-call'? > > > > gcc: error: unrecognized command line option '-mdisable-fpregs' > > > > gcc: error: missing argument to '-Wframe-larger-than=' > > > > gcc: error: unrecognized command line option '-mno-space-regs' > > > > gcc: error: unrecognized command line option '-mfast-indirect-calls'; > > > > did you mean '-mforce-indirect-call'? > > > > gcc: error: unrecognized command line option '-mdisable-fpregs' > > > > gcc: error: missing argument to '-Wframe-larger-than=' > > > > ... > > > > > > > > You can supporess them except '-Wframe-larger-than' by setting correct > > > > CROSS_COMPILE=, but we should not require any compiler for cleaning. > > > > > > > > This $(shell ...) is evaluated so many times because LIBGCC is exported. > > > > Use the ':=' operator to evaluate it just once, and sink the stderr. > > > > > > > > > > Applied to linux-kbuild. > > > > That patch breaks then building the boot loader/compressor: > > ... > > hppa-linux-gnu-ld-X -e startup --as-needed -T > > arch/parisc/boot/compressed/vmlinux.lds arch/parisc/boot/compressed/head.o > > arch/parisc/boot/compressed/real2.o arch/parisc/boot/compressed/firmware.o > > arch/parisc/boot/compressed/misc.o arch/parisc/boot/compressed/piggy.o -o > > arch/parisc/boot/compressed/vmlinux > > hppa-linux-gnu-ld: arch/parisc/boot/compressed/misc.o: in function > > `dec_vli': > > (.text+0x104): undefined reference to `__ashldi3' > > hppa-linux-gnu-ld: arch/parisc/boot/compressed/misc.o: in function > > `lzma_len': > > (.text+0x2b0): undefined reference to `$$mulI' > > hppa-linux-gnu-ld: (.text+0x344): undefined reference to `$$mulI' > > hppa-linux-gnu-ld: (.text+0x3f8): undefined reference to `$$mulI' > > > > > > The patch below works, but I wonder if it's possible to avoid > > to examine LIBGCC twice? > > > > Helge > > > Sorry for the breakage. > > How about moving LIBGCC below ? Good idea. The patch below does work for me. We do not need $KBUILD_CFLAGS to get the libgcc.a filename, so we do not need to pipe the output to /dev/null either. Can you try if that works, and if yes, can you apply it? Helge diff --git a/arch/parisc/Makefile b/arch/parisc/Makefile index 628cd8bb7ad8..fadbbd010337 100644 --- a/arch/parisc/Makefile +++ b/arch/parisc/Makefile @@ -21,8 +21,6 @@ KBUILD_IMAGE := vmlinuz NM = sh $(srctree)/arch/parisc/nm CHECKFLAGS += -D__hppa__=1 -LIBGCC = $(shell $(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name) -export LIBGCC ifdef CONFIG_64BIT UTS_MACHINE:= parisc64 @@ -110,6 +108,8 @@ cflags-$(CONFIG_PA8X00) += -march=2.0 -mschedule=8000 head-y := arch/parisc/kernel/head.o KBUILD_CFLAGS += $(cflags-y) +LIBGCC := $(shell $(CC) -print-libgcc-file-name) +export LIBGCC kernel-y := mm/ kernel/ math-emu/
Re: [PATCH] parisc: suppress error messages for 'make clean'
* Masahiro Yamada : > On Sat, Apr 25, 2020 at 2:47 PM Masahiro Yamada wrote: > > > > 'make ARCH=parisc clean' emits a tons of error messages as follows: > > > > $ make ARCH=parisc clean > > gcc: error: unrecognized command line option '-mno-space-regs' > > gcc: error: unrecognized command line option '-mfast-indirect-calls'; did > > you mean '-mforce-indirect-call'? > > gcc: error: unrecognized command line option '-mdisable-fpregs' > > gcc: error: missing argument to '-Wframe-larger-than=' > > gcc: error: unrecognized command line option '-mno-space-regs' > > gcc: error: unrecognized command line option '-mfast-indirect-calls'; did > > you mean '-mforce-indirect-call'? > > gcc: error: unrecognized command line option '-mdisable-fpregs' > > gcc: error: missing argument to '-Wframe-larger-than=' > > ... > > > > You can supporess them except '-Wframe-larger-than' by setting correct > > CROSS_COMPILE=, but we should not require any compiler for cleaning. > > > > This $(shell ...) is evaluated so many times because LIBGCC is exported. > > Use the ':=' operator to evaluate it just once, and sink the stderr. > > > > Applied to linux-kbuild. That patch breaks then building the boot loader/compressor: ... hppa-linux-gnu-ld-X -e startup --as-needed -T arch/parisc/boot/compressed/vmlinux.lds arch/parisc/boot/compressed/head.o arch/parisc/boot/compressed/real2.o arch/parisc/boot/compressed/firmware.o arch/parisc/boot/compressed/misc.o arch/parisc/boot/compressed/piggy.o -o arch/parisc/boot/compressed/vmlinux hppa-linux-gnu-ld: arch/parisc/boot/compressed/misc.o: in function `dec_vli': (.text+0x104): undefined reference to `__ashldi3' hppa-linux-gnu-ld: arch/parisc/boot/compressed/misc.o: in function `lzma_len': (.text+0x2b0): undefined reference to `$$mulI' hppa-linux-gnu-ld: (.text+0x344): undefined reference to `$$mulI' hppa-linux-gnu-ld: (.text+0x3f8): undefined reference to `$$mulI' The patch below works, but I wonder if it's possible to avoid to examine LIBGCC twice? Helge diff --git a/arch/parisc/Makefile b/arch/parisc/Makefile index 628cd8bb7ad8..aeea20abbf01 100644 --- a/arch/parisc/Makefile +++ b/arch/parisc/Makefile @@ -21,8 +21,7 @@ KBUILD_IMAGE := vmlinuz NM = sh $(srctree)/arch/parisc/nm CHECKFLAGS += -D__hppa__=1 -LIBGCC = $(shell $(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name) -export LIBGCC +LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name) ifdef CONFIG_64BIT UTS_MACHINE:= parisc64 diff --git a/arch/parisc/boot/compressed/Makefile b/arch/parisc/boot/compressed/Makefile index 1e5879c6a752..b008cf1b5c1e 100644 --- a/arch/parisc/boot/compressed/Makefile +++ b/arch/parisc/boot/compressed/Makefile @@ -22,6 +22,8 @@ ifndef CONFIG_64BIT KBUILD_CFLAGS += -mfast-indirect-calls endif +LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name) + OBJECTS += $(obj)/head.o $(obj)/real2.o $(obj)/firmware.o $(obj)/misc.o $(obj)/piggy.o LDFLAGS_vmlinux := -X -e startup --as-needed -T
Re: [PATCH] parisc: use -fno-strict-aliasing for decompressor
On 08.05.20 11:35, Arnd Bergmann wrote: > An experimental patch series of mine reworks how warnings are processed > in Kbuild. A side effect is a new warning about a harmless aliasing > rule violation in an inline function: > > In file included from > include/linux/rhashtable-types.h:15:0, > from include/linux/ipc.h:7, > from include/uapi/linux/sem.h:5, > from include/linux/sem.h:5, > from include/linux/sched.h:15, > from include/linux/uaccess.h:6, > from arch/parisc/boot/compressed/misc.c:7: > include/linux/workqueue.h: In function 'work_static': > include/linux/workqueue.h:212:2: warning: dereferencing > type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] > return *work_data_bits(work) & WORK_STRUCT_STATIC; > > Make the decompressor use -fno-strict-aliasing like the rest of > the kernel for consistency, and to ensure this warning never makes > it into a release. > > Reported-by: kbuild test robot > Signed-off-by: Arnd Bergmann Acked-by: Helge Deller Arnd, will you take it through your trees when you push your experimental patches, or do you want me to take it through the parisc tree? Helge > --- > arch/parisc/boot/compressed/Makefile | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/parisc/boot/compressed/Makefile > b/arch/parisc/boot/compressed/Makefile > index 1e5879c6a752..dff453687530 100644 > --- a/arch/parisc/boot/compressed/Makefile > +++ b/arch/parisc/boot/compressed/Makefile > @@ -16,6 +16,7 @@ targets += real2.S firmware.c > > KBUILD_CFLAGS := -D__KERNEL__ -O2 -DBOOTLOADER > KBUILD_CFLAGS += -DDISABLE_BRANCH_PROFILING > +KBUILD_CFLAGS += -fno-strict-aliasing > KBUILD_CFLAGS += $(cflags-y) -fno-delete-null-pointer-checks > -fno-builtin-printf > KBUILD_CFLAGS += -fno-PIE -mno-space-regs -mdisable-fpregs -Os > ifndef CONFIG_64BIT >
Re: [PATCH] parisc: add sysctl file interface panic_on_stackoverflow
On 11.04.20 15:06, Xiaoming Ni wrote:
> The variable sysctl_panic_on_stackoverflow is used in
> arch/parisc/kernel/irq.c and arch/x86/kernel/irq_32.c, but the sysctl file
> interface panic_on_stackoverflow only exists on x86.
>
> Add sysctl file interface panic_on_stackoverflow for parisc
>
> Signed-off-by: Xiaoming Ni
Acked-by: Helge Deller
Helge
> ---
> kernel/sysctl.c | 20 +++-
> 1 file changed, 11 insertions(+), 9 deletions(-)
>
> diff --git a/kernel/sysctl.c b/kernel/sysctl.c
> index 8a176d8..b9ff323 100644
> --- a/kernel/sysctl.c
> +++ b/kernel/sysctl.c
> @@ -994,30 +994,32 @@ static int sysrq_sysctl_handler(struct ctl_table
> *table, int write,
> .proc_handler = proc_dointvec,
> },
> #endif
> -#if defined(CONFIG_X86)
> +
> +#if (defined(CONFIG_X86_32) || defined(CONFIG_PARISC)) && \
> + defined(CONFIG_DEBUG_STACKOVERFLOW)
> {
> - .procname = "panic_on_unrecovered_nmi",
> - .data = _on_unrecovered_nmi,
> + .procname = "panic_on_stackoverflow",
> + .data = _panic_on_stackoverflow,
> .maxlen = sizeof(int),
> .mode = 0644,
> .proc_handler = proc_dointvec,
> },
> +#endif
> +#if defined(CONFIG_X86)
> {
> - .procname = "panic_on_io_nmi",
> - .data = _on_io_nmi,
> + .procname = "panic_on_unrecovered_nmi",
> + .data = _on_unrecovered_nmi,
> .maxlen = sizeof(int),
> .mode = 0644,
> .proc_handler = proc_dointvec,
> },
> -#ifdef CONFIG_DEBUG_STACKOVERFLOW
> {
> - .procname = "panic_on_stackoverflow",
> - .data = _panic_on_stackoverflow,
> + .procname = "panic_on_io_nmi",
> + .data = _on_io_nmi,
> .maxlen = sizeof(int),
> .mode = 0644,
> .proc_handler = proc_dointvec,
> },
> -#endif
> {
> .procname = "bootloader_type",
> .data = _type,
>
Re: [PATCH] Input: hp_sdc_rtc - remove dead chardev code
On 23.10.19 17:22, Alexandre Belloni wrote:
On 23/10/2019 16:25:02+0200, Arnd Bergmann wrote:
The driver contains half of the implementation of /dev/rtc, but this
was never completed, and it is now incompatible with the drivers/rtc
framework.
Remove the chardev completely. If anyone wants to add the functionality
later, that shoudl be done through rtc_register_device().
The remaining portions of the driver basically implement a single
procfs file that may or may not be used anywhere. Not sure why this
is in drivers/input/ though.
Signed-off-by: Arnd Bergmann
Acked-by: Alexandre Belloni
A year ago I did actually converted this driver to the RTC framework.
But after some testing on my physical box (a 715/64 PA-RISC machine
with HIL connector) I realized that the SDC in that machine doesn't
provide a functional RTC, and even more important, on that box we don't
need this RTC because the system provides a built-in RTC on-mainboard instead.
So, I never pushed my changes upstream, which can still be found here:
https://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git/commit/?h=hp_sdc_rtc_conversion=0d4250dbcfa2bb8b326ce7721e19e10a66f1eb92
So, I don't think any PA-RISC machine needs this driver, and as such
I'm happy to give my:
Acked-by: Helge Deller
I even think the whole driver can go away...
Helge
PS: Maybe some really old 68000-based HP machines needed that, but
I don't know if any recent Linux kernel runs on those old boxes any
longer...
---
drivers/input/misc/hp_sdc_rtc.c | 342
1 file changed, 342 deletions(-)
diff --git a/drivers/input/misc/hp_sdc_rtc.c b/drivers/input/misc/hp_sdc_rtc.c
index abca895a6156..199bc17ddb1d 100644
--- a/drivers/input/misc/hp_sdc_rtc.c
+++ b/drivers/input/misc/hp_sdc_rtc.c
@@ -53,28 +53,10 @@ MODULE_LICENSE("Dual BSD/GPL");
#define RTC_VERSION "1.10d"
-static DEFINE_MUTEX(hp_sdc_rtc_mutex);
static unsigned long epoch = 2000;
static struct semaphore i8042tregs;
-static hp_sdc_irqhook hp_sdc_rtc_isr;
-
-static struct fasync_struct *hp_sdc_rtc_async_queue;
-
-static DECLARE_WAIT_QUEUE_HEAD(hp_sdc_rtc_wait);
-
-static ssize_t hp_sdc_rtc_read(struct file *file, char __user *buf,
- size_t count, loff_t *ppos);
-
-static long hp_sdc_rtc_unlocked_ioctl(struct file *file,
- unsigned int cmd, unsigned long arg);
-
-static unsigned int hp_sdc_rtc_poll(struct file *file, poll_table *wait);
-
-static int hp_sdc_rtc_open(struct inode *inode, struct file *file);
-static int hp_sdc_rtc_fasync (int fd, struct file *filp, int on);
-
static void hp_sdc_rtc_isr (int irq, void *dev_id,
uint8_t status, uint8_t data)
{
@@ -283,151 +265,6 @@ static inline int hp_sdc_rtc_read_ct(struct timespec64
*res) {
return 0;
}
-
-#if 0 /* not used yet */
-/* Set the i8042 real-time clock */
-static int hp_sdc_rtc_set_rt (struct timeval *setto)
-{
- uint32_t tenms;
- unsigned int days;
- hp_sdc_transaction t;
- uint8_t tseq[11] = {
- HP_SDC_ACT_PRECMD | HP_SDC_ACT_DATAOUT,
- HP_SDC_CMD_SET_RTMS, 3, 0, 0, 0,
- HP_SDC_ACT_PRECMD | HP_SDC_ACT_DATAOUT,
- HP_SDC_CMD_SET_RTD, 2, 0, 0
- };
-
- t.endidx = 10;
-
- if (0x < setto->tv_sec / 86400) return -1;
- days = setto->tv_sec / 86400;
- if (0x < setto->tv_usec / 100 / 86400) return -1;
- days += ((setto->tv_sec % 86400) + setto->tv_usec / 100) / 86400;
- if (days > 0x) return -1;
-
- if (0xff < setto->tv_sec) return -1;
- tenms = setto->tv_sec * 100;
- if (0xff < setto->tv_usec / 1) return -1;
- tenms += setto->tv_usec / 1;
- if (tenms > 0xff) return -1;
-
- tseq[3] = (uint8_t)(tenms & 0xff);
- tseq[4] = (uint8_t)((tenms >> 8) & 0xff);
- tseq[5] = (uint8_t)((tenms >> 16) & 0xff);
-
- tseq[9] = (uint8_t)(days & 0xff);
- tseq[10] = (uint8_t)((days >> 8) & 0xff);
-
- t.seq = tseq;
-
- if (hp_sdc_enqueue_transaction()) return -1;
- return 0;
-}
-
-/* Set the i8042 fast handshake timer */
-static int hp_sdc_rtc_set_fhs (struct timeval *setto)
-{
- uint32_t tenms;
- hp_sdc_transaction t;
- uint8_t tseq[5] = {
- HP_SDC_ACT_PRECMD | HP_SDC_ACT_DATAOUT,
- HP_SDC_CMD_SET_FHS, 2, 0, 0
- };
-
- t.endidx = 4;
-
- if (0x < setto->tv_sec) return -1;
- tenms = setto->tv_sec * 100;
- if (0x < setto->tv_usec / 1) return -1;
- tenms += setto->tv_usec / 1;
- if (tenms > 0x) return -1;
-
- tseq[3] = (uint8_t)(tenms & 0xff);
- tseq[4] = (uint8_t)((tenms >> 8) & 0xff);
-
- t.seq = tseq;
-
- if (hp
[GIT PULL] parisc architecture fixes for kernel v5.4-rc4
Hi Linus, please pull some fixes for the parisc architecture for kernel 5.4-rc4 from: git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git parisc-5.4-2 Changes: * Fix a parisc-specific fallout of Christoph's dma_set_mask_and_coherent() patches (Sven) * Fix a vmap memory leak in ioremap()/ioremap() (Helge) * Some minor cleanups and documentation updates (Nick, Helge) Thanks, Helge Helge Deller (3): MAINTAINERS: Add hp_sdc drivers to parisc arch parisc: sysctl.c: Use CONFIG_PARISC instead of __hppa_ define parisc: Fix vmap memory leak in ioremap()/iounmap() Nick Desaulniers (1): parisc: prefer __section from compiler_attributes.h Sven Schnelle (1): parisc: Remove 32-bit DMA enforcement from sba_iommu MAINTAINERS | 3 +++ arch/parisc/include/asm/cache.h | 2 +- arch/parisc/include/asm/ldcw.h | 2 +- arch/parisc/mm/ioremap.c| 12 +++- drivers/parisc/sba_iommu.c | 8 kernel/sysctl.c | 4 ++-- 6 files changed, 14 insertions(+), 17 deletions(-)
Re: [RFC][PATCH] sysctl: Remove the sysctl system call
On 02.10.19 00:53, Eric W. Biederman wrote: Kees Cook writes: As there appear to be no users of the sysctl system call, remove the code>... I copied everyone who had put this into a defconfig and I will wait a little more to see if anyone screams. I think it is a safe guess that several of the affected configurations are dead (or at least unmaintained) as I received 17 bounces when copying everyone. arch/parisc/configs/c8000_defconfig |1 - arch/parisc/configs/generic-32bit_defconfig |1 - I'm not aware that we require the sysctl syscall somewhere on parisc, so I think it's safe to remove the code. Helge
[GIT PULL] parisc architecture updates for kernel v5.4
Hi Linus, please pull the parisc architecture updates for kernel 5.4 from: git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git parisc-5.4-1 Major changes: * Make the powerpc implementation to read elf files available as a public kexec interface so it can be re-used on other architectures (Sven) * Implement kexec on parisc (Sven) * Add kprobes on ftrace on parisc (Sven) * Fix kernel crash with HSC-PCI cards based on card-mode Dino * Add assembly implementations for memset, strlen, strcpy, strncpy and strcat * Some cleanups, documentation updates, warning fixes, ... Thanks, Helge Helge Deller (8): parisc: Add assembly implementations for memset, strlen, strcpy, strncpy and strcat parisc: Add ALTERNATIVE_CODE() and ALT_COND_RUN_ON_QEMU parisc: speed up flush_tlb_all_local with qemu parisc: Avoid warning when loading hppb driver parisc: Convert eisa_enumerator to use pr_cont() parisc: Drop comments which are already in pci.h parisc: Save some bytes in dino driver parisc: Disable HP HSC-PCI Cards to prevent kernel crash Jeroen Roovers (1): parisc: Have git ignore generated real2.S and firmware.c Jisheng Zhang (1): kprobes/parisc: remove arch_kprobe_on_func_entry() Sven Schnelle (15): parisc/ftrace: Add ARCH_SUPPORTS_FTRACE_OPS support parisc/ftrace: Add KPROBES_ON_FTRACE parisc: Update feature list parisc: trigger die notifier chain in parisc_terminate() kexec: add KEXEC_ELF kexec_elf: change order of elf_*_to_cpu() functions kexec_elf: remove parsing of section headers kexec_elf: remove PURGATORY_STACK_SIZE kexec_elf: remove Elf_Rel macro kexec_elf: remove unused variable in kexec_elf_load() kexec_elf: support 32 bit ELF files parisc: add __pdc_cpu_rendezvous() parisc: add kexec syscall support parisc: wire up kexec_file_load syscall parisc: add support for kexec_file_load() syscall .../features/core/jump-labels/arch-support.txt | 2 +- .../debug/kprobes-on-ftrace/arch-support.txt | 2 +- arch/Kconfig | 3 + arch/parisc/Kconfig| 25 + arch/parisc/boot/compressed/.gitignore | 2 + arch/parisc/include/asm/alternative.h | 11 +- arch/parisc/include/asm/fixmap.h | 1 + arch/parisc/include/asm/ftrace.h | 1 + arch/parisc/include/asm/kexec.h| 37 ++ arch/parisc/include/asm/pdc.h | 1 + arch/parisc/include/asm/string.h | 15 + arch/parisc/kernel/Makefile| 2 + arch/parisc/kernel/alternative.c | 23 +- arch/parisc/kernel/entry.S | 99 arch/parisc/kernel/firmware.c | 13 + arch/parisc/kernel/ftrace.c| 64 ++- arch/parisc/kernel/kexec.c | 112 + arch/parisc/kernel/kexec_file.c| 86 arch/parisc/kernel/kprobes.c | 4 - arch/parisc/kernel/pacache.S | 9 + arch/parisc/kernel/parisc_ksyms.c | 4 + arch/parisc/kernel/pci.c | 11 - arch/parisc/kernel/relocate_kernel.S | 149 ++ arch/parisc/kernel/smp.c | 1 + arch/parisc/kernel/syscalls/syscall.tbl| 3 +- arch/parisc/kernel/traps.c | 2 + arch/parisc/lib/Makefile | 4 +- arch/parisc/lib/memset.c | 91 arch/parisc/lib/string.S | 136 + arch/powerpc/Kconfig | 1 + arch/powerpc/kernel/kexec_elf_64.c | 545 + drivers/parisc/dino.c | 30 +- drivers/parisc/eisa_enumerator.c | 10 +- drivers/parisc/hppb.c | 11 +- include/linux/kexec.h | 23 + include/uapi/linux/kexec.h | 1 + kernel/Makefile| 1 + kernel/kexec_elf.c | 430 38 files changed, 1289 insertions(+), 676 deletions(-) create mode 100644 arch/parisc/include/asm/kexec.h create mode 100644 arch/parisc/kernel/kexec.c create mode 100644 arch/parisc/kernel/kexec_file.c create mode 100644 arch/parisc/kernel/relocate_kernel.S delete mode 100644 arch/parisc/lib/memset.c create mode 100644 arch/parisc/lib/string.S create mode 100644 kernel/kexec_elf.c
Re: [PATCH RESEND 0/8] Fix mmap base in bottom-up mmap
On 26.08.19 09:34, Alexandre Ghiti wrote: On 6/20/19 7:03 AM, Alexandre Ghiti wrote: This series fixes the fallback of the top-down mmap: in case of failure, a bottom-up scheme can be tried as a last resort between the top-down mmap base and the stack, hoping for a large unused stack limit. Lots of architectures and even mm code start this fallback at TASK_UNMAPPED_BASE, which is useless since the top-down scheme already failed on the whole address space: instead, simply use mmap_base. Along the way, it allows to get rid of of mmap_legacy_base and mmap_compat_legacy_base from mm_struct. Note that arm and mips already implement this behaviour. Alexandre Ghiti (8): s390: Start fallback of top-down mmap at mm->mmap_base sh: Start fallback of top-down mmap at mm->mmap_base sparc: Start fallback of top-down mmap at mm->mmap_base x86, hugetlbpage: Start fallback of top-down mmap at mm->mmap_base mm: Start fallback top-down mmap at mm->mmap_base parisc: Use mmap_base, not mmap_legacy_base, as low_limit for bottom-up mmap x86: Use mmap_*base, not mmap_*legacy_base, as low_limit for bottom-up mmap mm: Remove mmap_legacy_base and mmap_compat_legacy_code fields from mm_struct arch/parisc/kernel/sys_parisc.c | 8 +++- arch/s390/mm/mmap.c | 2 +- arch/sh/mm/mmap.c | 2 +- arch/sparc/kernel/sys_sparc_64.c | 2 +- arch/sparc/mm/hugetlbpage.c | 2 +- arch/x86/include/asm/elf.h | 2 +- arch/x86/kernel/sys_x86_64.c | 4 ++-- arch/x86/mm/hugetlbpage.c | 7 --- arch/x86/mm/mmap.c | 20 +--- include/linux/mm_types.h | 2 -- mm/debug.c | 4 ++-- mm/mmap.c | 2 +- 12 files changed, 26 insertions(+), 31 deletions(-) Any thoughts about that series ? As said before, this is just a preparatory patchset in order to merge x86 mmap top down code with the generic version. I just tested your patch series successfully on the parisc architeture. You may add: Tested-by: Helge Deller # parisc Thanks! Helge
Re: [PATCH] parisc: fix compilation errrors
On 15.08.19 23:02, Guenter Roeck wrote:
On Thu, Aug 15, 2019 at 04:53:05PM -0400, Qian Cai wrote:
The commit 0cfaee2af3a0 ("include/asm-generic/5level-fixup.h: fix
variable 'p4d' set but not used") converted a few functions from macros
to static inline, which causes parisc to complain,
In file included from ./include/asm-generic/4level-fixup.h:38:0,
from ./arch/parisc/include/asm/pgtable.h:5,
from ./arch/parisc/include/asm/io.h:6,
from ./include/linux/io.h:13,
from sound/core/memory.c:9:
./include/asm-generic/5level-fixup.h:14:18: error: unknown type name
'pgd_t'; did you mean 'pid_t'?
#define p4d_tpgd_t
^
./include/asm-generic/5level-fixup.h:24:28: note: in expansion of macro
'p4d_t'
static inline int p4d_none(p4d_t p4d)
^
It is because "4level-fixup.h" is included before "asm/page.h" where
"pgd_t" is defined.
Fixes: 0cfaee2af3a0 ("include/asm-generic/5level-fixup.h: fix variable 'p4d' set but
not used")
Reported-by: Guenter Roeck
Signed-off-by: Qian Cai
Tested-by: Guenter Roeck
Acked-by: Helge Deller
Helge
