Re: [PATCH V9 20/20] riscv: compat: Add COMPAT Kbuild skeletal support
On Tue, Mar 22, 2022 at 10:40:03PM +0800, guo...@kernel.org wrote: > From: Guo Ren > > Adds initial skeletal COMPAT Kbuild (Running 32bit U-mode on > 64bit S-mode) support. > - Setup kconfig & dummy functions for compiling. > - Implement compat_start_thread by the way. > > Signed-off-by: Guo Ren > Signed-off-by: Guo Ren > Reviewed-by: Arnd Bergmann > Tested-by: Heiko Stuebner > Cc: Palmer Dabbelt With this patch in linux-next, all my riscv64 emulations crash. [ 11.600082] Run /sbin/init as init process [ 11.628561] init[1]: unhandled signal 11 code 0x1 at 0x in libc.so[ff8ad39000+a4000] [ 11.629398] CPU: 0 PID: 1 Comm: init Not tainted 5.18.0-rc7-next-20220520 #1 [ 11.629462] Hardware name: riscv-virtio,qemu (DT) [ 11.629546] epc : 00ff8ada1100 ra : 00ff8ada13c8 sp : 00ffc58199f0 [ 11.629586] gp : 00ff8ad39000 tp : 00ff8ade0998 t0 : [ 11.629598] t1 : 00ffc5819fd0 t2 : s0 : 00ff8ade0cc0 [ 11.629610] s1 : 00ff8ade0cc0 a0 : a1 : 00ffc5819a00 [ 11.629622] a2 : 0001 a3 : 001e a4 : 00ffc5819b00 [ 11.629634] a5 : 00ffc5819b00 a6 : a7 : [ 11.629645] s2 : 00ff8ade0ac8 s3 : 00ff8ade0ec8 s4 : 00ff8ade0728 [ 11.629656] s5 : 00ff8ade0a90 s6 : s7 : 00ffc5819e40 [ 11.629667] s8 : 00ff8ade0ca0 s9 : 00ff8addba50 s10: [ 11.629678] s11: t3 : 0002 t4 : 0001 [ 11.629688] t5 : 0002 t6 : [ 11.629699] status: 4020 badaddr: cause: 000d [ 11.633421] Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b [ 11.633664] CPU: 0 PID: 1 Comm: init Not tainted 5.18.0-rc7-next-20220520 #1 [ 11.633784] Hardware name: riscv-virtio,qemu (DT) [ 11.633881] Call Trace: [ 11.633960] [] dump_backtrace+0x1c/0x24 [ 11.634162] [] show_stack+0x2c/0x38 [ 11.634274] [] dump_stack_lvl+0x60/0x8e [ 11.634386] [] dump_stack+0x14/0x1c [ 11.634491] [] panic+0x116/0x2e2 [ 11.634596] [] do_exit+0x7ce/0x7d4 [ 11.634707] [] do_group_exit+0x24/0x7c [ 11.634817] [] get_signal+0x7ee/0x830 [ 11.634924] [] do_notify_resume+0x6c/0x41c [ 11.635037] [] ret_from_exception+0x0/0x10 Guenter --- # bad: [18ecd30af1a8402c162cca1bd58771c0e5be7815] Add linux-next specific files for 20220520 # good: [42226c989789d8da4af1de0c31070c96726d990c] Linux 5.18-rc7 git bisect start 'HEAD' 'v5.18-rc7' # bad: [f9b63740b666dd9887eb0282d21b5f65bb0cadd0] Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git git bisect bad f9b63740b666dd9887eb0282d21b5f65bb0cadd0 # bad: [7db97132097c5973ff77466d0ee681650af653de] Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/cel/linux git bisect bad 7db97132097c5973ff77466d0ee681650af653de # good: [2b7d17d4b7c1ff40f58b0d32be40fc0bb6c582fb] soc: document merges git bisect good 2b7d17d4b7c1ff40f58b0d32be40fc0bb6c582fb # good: [69c9668f853fdd409bb8abbb37d615785510b29a] Merge branch 'clk-next' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git git bisect good 69c9668f853fdd409bb8abbb37d615785510b29a # bad: [1577f290aa0d4c5b29c03c46ef52e4952a21bfbb] Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git git bisect bad 1577f290aa0d4c5b29c03c46ef52e4952a21bfbb # good: [34f0971f8ca73d7e5502b4cf299788a9402120f7] powerpc/powernv/flash: Check OPAL flash calls exist before using git bisect good 34f0971f8ca73d7e5502b4cf299788a9402120f7 # good: [0349d7dfc70a26b3facd8ca97de34980d4b60954] Merge branch 'mips-next' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git git bisect good 0349d7dfc70a26b3facd8ca97de34980d4b60954 # bad: [20bfb54d3b121699674c17a854c5ebc7a8f97d81] Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git git bisect bad 20bfb54d3b121699674c17a854c5ebc7a8f97d81 # bad: [9be8459298eadb39b9fe9974b890239e9c123107] riscv: compat: Add COMPAT Kbuild skeletal support git bisect bad 9be8459298eadb39b9fe9974b890239e9c123107 # good: [01abdfeac81b5f56062d0a78f2cdc805db937a75] riscv: compat: Support TASK_SIZE for compat mode git bisect good 01abdfeac81b5f56062d0a78f2cdc805db937a75 # good: [f4b395e6f1a588ed6c9a30474e58cf6b27b65783] riscv: compat: Add hw capability check for elf git bisect good f4b395e6f1a588ed6c9a30474e58cf6b27b65783 # good: [3092eb45637573c5e435fbf5eaf9516316e5f9c6] riscv: compat: vdso: Add setup additional pages implementation git bisect good 3092eb45637573c5e435fbf5eaf9516316e5f9c6 # good: [4608c159594fb40a5101357d4f614fdde9ce1fdb] riscv: compat: ptrace: Add compat_arch_ptrace implement git bisect good 4608c159594fb40a5101357d4f614fdde9ce1fdb # first bad commit: [9be8459298eadb39b9fe9974b890239e9c123107] riscv: compat: Add COMPAT
Re: [RFC PATCH 3/3] objtool/mcount: Add powerpc specific functions
Peter Zijlstra wrote: On Sat, May 21, 2022 at 09:38:35AM +, Christophe Leroy wrote: I gave it a try this morning, I selected HAVE_OBJTOOL and HAVE_OBJTOOL_MCOUNT from arch/powerpc/Kconfig Seems like there are still some x86 arch specific stuff in common common code and I get the following errors. I'm assuming there's a metric ton of x86 specific stuff in there. That'll take a while to clean out. Mostly Josh's rewrite was centered around splitting out the runtime options, but objtool is still always build with all options included, even the ones you're not using for your arch, which is what's triggering the problems you see here, I suppose... Also, is it normal to get those functions built allthough I have not selected HAVE_STACK_VALIDATION ? CC /home/chleroy/linux-powerpc/tools/objtool/check.o check.c: In function 'has_valid_stack_frame': check.c:2369:30: error: 'CFI_BP' undeclared (first use in this function); did you mean 'CFI_SP'? 2369 | if (cfi->cfa.base == CFI_BP && | ^~ | CFI_SP check.c:2369:30: note: each undeclared identifier is reported only once for each function it appears in check.c:2371:44: error: 'CFI_RA' undeclared (first use in this function); did you mean 'CFI_R3'? 2371 | check_reg_frame_pos(>regs[CFI_RA], -cfi->cfa.offset + 8)) |^~ |CFI_R3 check.c: In function 'update_cfi_state': check.c:2499:70: error: 'CFI_BP' undeclared (first use in this function); did you mean 'CFI_SP'? 2499 | if (op->src.reg == CFI_SP && op->dest.reg == CFI_BP && | ^~ | CFI_SP make[3]: *** [/home/chleroy/linux-powerpc/tools/build/Makefile.build:97: /home/chleroy/linux-powerpc/tools/objtool/check.o] Error 1 make[2]: *** [Makefile:54: /home/chleroy/linux-powerpc/tools/objtool/objtool-in.o] Error 2 make[1]: *** [Makefile:69: objtool] Error 2 make: *** [Makefile:1337: tools/objtool] Error 2 What would be the best approach to fix that ? Define CFI_BP to your frame register (r2, afaict) I suppose. If you're only using OBJTOOL_MCOUNT this code will never run, so all you have to ensure is that it compiles, not that it makes sense (-: Sathvika has been looking into this. The very long and complicated way would be to propagate the various CONFIG_HAVE_* build time things to the objtool build and librally sprinkle a lot of #ifdef around. I think there were just a couple of unrelated checks/warnings that were causing problems on powerpc. So, we likely won't need too many #ifdefs, at least for mcount purposes. Sathvika, Can you post what you have? - Naveen
Re: [PATCH] powerpc: check previous kernel's ima-kexec-buffer against memory bounds
Vaibhav Jain writes:
> Rob Herring writes:
>> On Thu, May 19, 2022 at 01:35:47AM +0530, Vaibhav Jain wrote:
>>> Presently ima_get_kexec_buffer() doesn't check if the previous kernel's
>>> ima-kexec-buffer lies outside the addressable memory range. This can result
>>> in a kernel panic if the new kernel is booted with 'mem=X' arg and the
>>> ima-kexec-buffer was allocated beyond that range by the previous kernel.
>>> The panic is usually of the form below:
>>>
>>> $ sudo kexec --initrd initrd vmlinux --append='mem=16G'
>>>
>>>
>>> BUG: Unable to handle kernel data access on read at 0xc000c01fff7f
>>> Faulting instruction address: 0xc0837974
>>> Oops: Kernel access of bad area, sig: 11 [#1]
>>>
>>> NIP [c0837974] ima_restore_measurement_list+0x94/0x6c0
>>> LR [c083b55c] ima_load_kexec_buffer+0xac/0x160
>>> Call Trace:
>>> [c371fa80] [c083b55c] ima_load_kexec_buffer+0xac/0x160
>>> [c371fb00] [c20512c4] ima_init+0x80/0x108
>>> [c371fb70] [c20514dc] init_ima+0x4c/0x120
>>> [c371fbf0] [c0012240] do_one_initcall+0x60/0x2c0
>>> [c371fcc0] [c2004ad0] kernel_init_freeable+0x344/0x3ec
>>> [c371fda0] [c00128a4] kernel_init+0x34/0x1b0
>>> [c371fe10] [c000ce64] ret_from_kernel_thread+0x5c/0x64
>>> Instruction dump:
>>> f92100b8 f92100c0 90e10090 910100a0 4182050c 282a0017 3bc0 40810330
>>> 7c0802a6 fb610198 7c9b2378 f80101d0 2c090001 40820614 e9240010
>>> ---[ end trace ]---
>>>
>>> Fix this issue by checking returned address/size of previous kernel's
>>> ima-kexec-buffer against memblock's memory bounds.
>>>
>>> Fixes: fee3ff99bc67("powerpc: Move arch independent ima kexec functions to
>>> drivers/of/kexec.c")
...
>>
>> But more importantly, how did this commit introduce the problem? It just
>> moved the code and didn't have any such check.
> Yes, the code didnt have the necessary check to see if the address for
> previous kernel IMA buffer is beyond the currently addressable memory. I
> have described the problem in patch description.
Rob's point is that commit fee3ff99bc67 only moved existing code, the
bug already existed.
The function was introduced in:
467d27824920 ("powerpc: ima: get the kexec buffer passed by the previous
kernel")
So that's where the Fixes tag should point.
cheers
[PATCH v7 21/25] Kbuild: add Rust support
Having all the new files in place, we now enable Rust support
in the build system, including `Kconfig` entries related to Rust,
the Rust configuration printer, the target specification
generation script, the version detection script and a few
other bits.
Co-developed-by: Alex Gaynor
Signed-off-by: Alex Gaynor
Co-developed-by: Finn Behrens
Signed-off-by: Finn Behrens
Co-developed-by: Adam Bratschi-Kaye
Signed-off-by: Adam Bratschi-Kaye
Co-developed-by: Wedson Almeida Filho
Signed-off-by: Wedson Almeida Filho
Co-developed-by: Michael Ellerman
Signed-off-by: Michael Ellerman
Co-developed-by: Sven Van Asbroeck
Signed-off-by: Sven Van Asbroeck
Co-developed-by: Gary Guo
Signed-off-by: Gary Guo
Co-developed-by: Boris-Chengbiao Zhou
Signed-off-by: Boris-Chengbiao Zhou
Co-developed-by: Boqun Feng
Signed-off-by: Boqun Feng
Co-developed-by: Douglas Su
Signed-off-by: Douglas Su
Co-developed-by: Dariusz Sosnowski
Signed-off-by: Dariusz Sosnowski
Co-developed-by: Antonio Terceiro
Signed-off-by: Antonio Terceiro
Co-developed-by: Daniel Xu
Signed-off-by: Daniel Xu
Co-developed-by: Miguel Cano
Signed-off-by: Miguel Cano
Co-developed-by: David Gow
Signed-off-by: David Gow
Signed-off-by: Miguel Ojeda
---
.gitignore | 5 +
.rustfmt.toml| 12 +
Makefile | 175 +++-
arch/Kconfig | 6 +
arch/arm/Kconfig | 1 +
arch/arm64/Kconfig | 1 +
arch/powerpc/Kconfig | 1 +
arch/riscv/Kconfig | 1 +
arch/riscv/Makefile | 5 +
arch/um/Kconfig | 1 +
arch/x86/Kconfig | 1 +
arch/x86/Makefile| 14 +
init/Kconfig | 45 ++-
lib/Kconfig.debug| 155
rust/.gitignore | 10 +
rust/Makefile| 398 +++
rust/bindgen_parameters | 17 +
scripts/.gitignore | 1 +
scripts/Kconfig.include | 6 +-
scripts/Makefile | 3 +
scripts/Makefile.build | 60 +++
scripts/Makefile.debug | 10 +
scripts/Makefile.host| 34 +-
scripts/Makefile.lib | 12 +
scripts/Makefile.modfinal| 8 +-
scripts/cc-version.sh| 12 +-
scripts/generate_rust_target.rs | 227 +++
scripts/is_rust_module.sh| 13 +
scripts/kconfig/confdata.c | 75
scripts/min-tool-version.sh | 6 +
scripts/rust-is-available-bindgen-libclang.h | 2 +
scripts/rust-is-available.sh | 158
32 files changed, 1452 insertions(+), 23 deletions(-)
create mode 100644 .rustfmt.toml
create mode 100644 rust/.gitignore
create mode 100644 rust/Makefile
create mode 100644 rust/bindgen_parameters
create mode 100644 scripts/generate_rust_target.rs
create mode 100755 scripts/is_rust_module.sh
create mode 100644 scripts/rust-is-available-bindgen-libclang.h
create mode 100755 scripts/rust-is-available.sh
diff --git a/.gitignore b/.gitignore
index 7afd412dadd2..48c68948f476 100644
--- a/.gitignore
+++ b/.gitignore
@@ -37,6 +37,7 @@
*.o
*.o.*
*.patch
+*.rmeta
*.s
*.so
*.so.dbg
@@ -96,6 +97,7 @@ modules.order
!.gitattributes
!.gitignore
!.mailmap
+!.rustfmt.toml
#
# Generated include files
@@ -161,3 +163,6 @@ x509.genkey
# Documentation toolchain
sphinx_*/
+
+# Rust analyzer configuration
+/rust-project.json
diff --git a/.rustfmt.toml b/.rustfmt.toml
new file mode 100644
index ..3de5cc497465
--- /dev/null
+++ b/.rustfmt.toml
@@ -0,0 +1,12 @@
+edition = "2021"
+newline_style = "Unix"
+
+# Unstable options that help catching some mistakes in formatting and that we
may want to enable
+# when they become stable.
+#
+# They are kept here since they are useful to run from time to time.
+#format_code_in_doc_comments = true
+#reorder_impl_items = true
+#comment_width = 100
+#wrap_comments = true
+#normalize_comments = true
diff --git a/Makefile b/Makefile
index 7d5b0bfe7960..ce17ec71f89b 100644
--- a/Makefile
+++ b/Makefile
@@ -120,6 +120,15 @@ endif
export KBUILD_CHECKSRC
+# Enable "clippy" (a linter) as part of the Rust compilation.
+#
+# Use 'make CLIPPY=1' to enable it.
+ifeq ("$(origin CLIPPY)", "command line")
+ KBUILD_CLIPPY := $(CLIPPY)
+endif
+
+export KBUILD_CLIPPY
+
# Use make M=dir or set the environment variable KBUILD_EXTMOD to specify the
# directory of external module to build. Setting M= takes precedence.
ifeq ("$(origin M)", "command line")
@@ -267,7 +276,7 @@ no-dot-config-targets :=
[PATCH v7 00/25] Rust support
Rust support
This is the patch series (v7) to add support for Rust as a second
language to the Linux kernel.
If you are interested in following this effort, please join us in
the mailing list at:
rust-for-li...@vger.kernel.org
and take a look at the project itself at:
https://github.com/Rust-for-Linux
As usual, special thanks go to ISRG (Internet Security Research
Group) and Google for their financial support on this endeavor.
Cheers,
Miguel
--
# Rust support
This cover letter explains the major changes and updates done since
the previous ones. For those, please see:
RFC: https://lore.kernel.org/lkml/20210414184604.23473-1-oj...@kernel.org/
v1: https://lore.kernel.org/lkml/20210704202756.29107-1-oj...@kernel.org/
v2: https://lore.kernel.org/lkml/20211206140313.5653-1-oj...@kernel.org/
v3: https://lore.kernel.org/lkml/20220117053349.6804-1-oj...@kernel.org/
v4: https://lore.kernel.org/lkml/20220212130410.6901-1-oj...@kernel.org/
v5: https://lore.kernel.org/lkml/20220317181032.15436-1-oj...@kernel.org/
v6: https://lore.kernel.org/lkml/20220507052451.12890-1-oj...@kernel.org/
This is a small round to address the comments made in v6 plus a few
related changes:
- Added `%pA` to `Documentation/core-api/printk-formats.rst`.
- Added `checkpatch.pl` patch to search for `%pA` in C code.
- Added `checkpatch.pl` patch to enable language-independent checks.
- Added UML (x86_64) support, for KUnit (thanks David Gow!).
- Added inline licensing information ("Apache-2.0 OR MIT") in
the commit message of the `alloc` patch, as well as in
`rust/alloc/README.md` in the following patch.
- Added SPDX license identifiers to `Documentation/rust/`.
- Reformatted `Documentation/rust/arch-support.rst` list table
into simple table.
- Removed logo from documentation patch; used Linux GIF one for
the Rust generated docs in its place (to be replaced with
the SVG one once available).
- Used `"GPL"` instead of `"GPL v2"` for the `license` field of the
`module!` macro.
- Moved `module_misc_device!` macro in `samples/rust/rust_random.rs`
to the top of the file in `samples/rust/` for consistency.
- Sorted `#include` lists in `rust/kernel/bindings_helper.h`
and `rust/helpers.c`.
- Fixed some English typos.
- Made the patches more `checkpatch.pl`-clean overall.
- Picked up Reviewed-by and Acked-by tags.
## Patch series status
The Rust support is still to be considered experimental. However,
support is good enough that kernel developers can start working on the
Rust abstractions for subsystems and write drivers and other modules.
The current series has just arrived in `linux-next`, as usual.
Similarly, the preview docs for this series can be seen at:
https://rust-for-linux.github.io/docs/kernel/
As usual, please see the following link for the live list of unstable
Rust features we are using:
https://github.com/Rust-for-Linux/linux/issues/2
## Conferences, meetings and liaisons
We would like to remind everyone about the Rust MC (microconference)
of LPC 2022 (Linux Plumbers Conference):
https://lpc.events/event/16/contributions/1159/
The Rust MC intends to cover talks and discussions on both Rust for
Linux as well as other non-kernel Rust topics. The Call for Proposals
is open!
## Acknowledgements
The signatures in the main commits correspond to the people that
wrote code that has ended up in them at the present time. For details
on contributions to code and discussions, please see our repository:
https://github.com/Rust-for-Linux/linux
However, we would like to give credit to everyone that has contributed
in one way or another to the Rust for Linux project. Since the
previous cover letter:
- Kees Cook for his reviews of some of the v6 patches.
- David Gow and Brendan Higgins for their reviews of the KUnit
prerequisite patch and their feedback.
- Jonathan Corbet and Akira Yokosawa for their review of the
documentation patch and feedback on documentation rules.
- Gary Guo for working on improvements to the Rust compiler that
could make our `static_assert!` macro applicable in more cases.
- bjorn3 for working on making `rustc_parse_format` compile on
a stable Rust compiler so that it may be used by lightweight
formatting systems (for instance, by the kernel).
- As usual, bjorn3 and Gary Guo for all the input on Rust compiler
details, reviews and suggestions.
- Esteban Blanc, Arthur Cohen and Martin Schmidt for rebasing their
SPI abstraction work.
- Maciej Falkowski for continuing his work on the Samsung Exynos
TRNG driver and the required abstractions around it, such as
adding `delay`, `ktime` and `iopoll` abstractions, new methods
to `platform::Device` and run-time power management abstractions.
- Yuheng Su for working on cleaning up the `Module::init` interface.
- Peng Hao for working on wrapping `mm_struct`.
-
Re: [PATCH] cxl: fix typo in comment
On 21/5/22 21:11, Julia Lawall wrote: Spelling mistake (triple letters) in comment. Detected with the help of Coccinelle. Signed-off-by: Julia Lawall Acked-by: Andrew Donnellan -- Andrew Donnellan OzLabs, ADL Canberra a...@linux.ibm.com IBM Australia Limited
Re: [PATCH] powerpc: check previous kernel's ima-kexec-buffer against memory bounds
Rob Herring writes:
> On Thu, May 19, 2022 at 01:35:47AM +0530, Vaibhav Jain wrote:
>> Presently ima_get_kexec_buffer() doesn't check if the previous kernel's
>> ima-kexec-buffer lies outside the addressable memory range. This can result
>> in a kernel panic if the new kernel is booted with 'mem=X' arg and the
>> ima-kexec-buffer was allocated beyond that range by the previous kernel.
>> The panic is usually of the form below:
>>
>> $ sudo kexec --initrd initrd vmlinux --append='mem=16G'
>>
>>
>> BUG: Unable to handle kernel data access on read at 0xc000c01fff7f
>> Faulting instruction address: 0xc0837974
>> Oops: Kernel access of bad area, sig: 11 [#1]
>>
>> NIP [c0837974] ima_restore_measurement_list+0x94/0x6c0
>> LR [c083b55c] ima_load_kexec_buffer+0xac/0x160
>> Call Trace:
>> [c371fa80] [c083b55c] ima_load_kexec_buffer+0xac/0x160
>> [c371fb00] [c20512c4] ima_init+0x80/0x108
>> [c371fb70] [c20514dc] init_ima+0x4c/0x120
>> [c371fbf0] [c0012240] do_one_initcall+0x60/0x2c0
>> [c371fcc0] [c2004ad0] kernel_init_freeable+0x344/0x3ec
>> [c371fda0] [c00128a4] kernel_init+0x34/0x1b0
>> [c371fe10] [c000ce64] ret_from_kernel_thread+0x5c/0x64
>> Instruction dump:
>> f92100b8 f92100c0 90e10090 910100a0 4182050c 282a0017 3bc0 40810330
>> 7c0802a6 fb610198 7c9b2378 f80101d0 2c090001 40820614 e9240010
>> ---[ end trace ]---
>>
>> Fix this issue by checking returned address/size of previous kernel's
>> ima-kexec-buffer against memblock's memory bounds.
>>
>> Fixes: fee3ff99bc67("powerpc: Move arch independent ima kexec functions to
>> drivers/of/kexec.c")
>
> Your mailer (and/or you) corrupted this. There should be a space between
> the commit hash and subject, and it should not be wrapped.
I probably messed it up. Will resend a fixed patch.
>
> It should also not have a blank line here.
Sure. Will get this fixed
>
> But more importantly, how did this commit introduce the problem? It just
> moved the code and didn't have any such check.
Yes, the code didnt have the necessary check to see if the address for
previous kernel IMA buffer is beyond the currently addressable memory. I
have described the problem in patch description.
--
Cheers
~ Vaibhav
[powerpc:next] BUILD SUCCESS a5d28039ecb288f4788ae98c8291e092961e8742
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next branch HEAD: a5d28039ecb288f4788ae98c8291e092961e8742 powerpc/powernv/pci: Drop VF MPS fixup elapsed time: 720m configs tested: 175 configs skipped: 49 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm allmodconfig arm allyesconfig arm64allyesconfig arm64 defconfig i386 randconfig-c001 arm imxrt_defconfig mips loongson1b_defconfig arm imx_v6_v7_defconfig parisc alldefconfig arm stm32_defconfig sparc sparc64_defconfig sh ecovec24_defconfig sh allmodconfig arm assabet_defconfig xtensageneric_kc705_defconfig armhisi_defconfig arcvdk_hs38_defconfig shshmin_defconfig parisc defconfig mips fuloong2e_defconfig mips maltasmvp_defconfig powerpc cm5200_defconfig powerpcsam440ep_defconfig armshmobile_defconfig um alldefconfig um defconfig mips bigsur_defconfig mips bmips_be_defconfig arcnsimosci_defconfig shtitan_defconfig armrealview_defconfig xtensa alldefconfig sh polaris_defconfig powerpc wii_defconfig mipsbcm47xx_defconfig powerpc taishan_defconfig powerpc64 defconfig arm omap2plus_defconfig mips decstation_r4k_defconfig s390 zfcpdump_defconfig csky alldefconfig um i386_defconfig sparc defconfig armqcom_defconfig powerpc sequoia_defconfig armlart_defconfig um x86_64_defconfig mipsar7_defconfig m68kdefconfig m68kstmark2_defconfig m68k amcore_defconfig m68k apollo_defconfig armtrizeps4_defconfig armcerfcube_defconfig mips db1xxx_defconfig armxcep_defconfig powerpc tqm8548_defconfig powerpc eiger_defconfig sh rts7751r2dplus_defconfig arm jornada720_defconfig arc axs103_defconfig powerpc motionpro_defconfig arm sama5_defconfig arc tb10x_defconfig h8300 edosk2674_defconfig nios2alldefconfig arm h5000_defconfig m68k multi_defconfig arc axs101_defconfig sh j2_defconfig ia64generic_defconfig powerpc mpc85xx_cds_defconfig sh microdev_defconfig mips decstation_defconfig m68k allyesconfig arm sunxi_defconfig armzeus_defconfig mips jazz_defconfig xtensa audio_kc705_defconfig arm s3c6400_defconfig shedosk7760_defconfig arm randconfig-c002-20220522 x86_64randconfig-c001 ia64defconfig ia64 allmodconfig ia64 allyesconfig m68k allmodconfig alpha defconfig cskydefconfig alphaallyesconfig nios2allyesconfig arc defconfig h8300allyesconfig xtensa allyesconfig s390 allmodconfig s390defconfig s390 allyesconfig parisc64defconfig parisc allyesconfig i386 debian-10.3
Re: [PATCH 2/2] drm/tiny: Add ofdrm for Open Firmware framebuffers
Hi Javier
Am 20.05.22 um 08:19 schrieb Javier Martinez Canillas:
Hello Thomas,
On 5/18/22 20:30, Thomas Zimmermann wrote:
+config DRM_OFDRM
+ tristate "Open Firmware display driver"
+ depends on DRM && MMU && PPC
Shouldn't depend on OF? I mean, is a DRM driver for Open Firmware after all :)
I know that the old drivers/video/fbdev/offb.c doesn't, but I think that is a
but and should `depends on OF || COMPILE_TEST`
I have to look for possible pitfalls, but that seems to makes sense.
+
+/*
+ * Helpers for display nodes
+ */
+
+static int display_get_validated_int(struct drm_device *dev, const char *name,
uint32_t value)
+{
+ if (value > INT_MAX) {
+ drm_err(dev, "invalid framebuffer %s of %u\n", name, value);
+ return -EINVAL;
+ }
+ return (int)value;
+}
+
+static int display_get_validated_int0(struct drm_device *dev, const char
*name, uint32_t value)
+{
+ if (!value) {
+ drm_err(dev, "invalid framebuffer %s of %u\n", name, value);
+ return -EINVAL;
+ }
+ return display_get_validated_int(dev, name, value);
+}
+
These two helpers are the same that we already have in simpledrm.c, maybe could
include a preparatory patch that moves to drivers/gpu/drm/drm_format_helper.c
and make them public for drivers to use ? Or maybe even as static inline in
include/drm/drm_format_helper.h ?
To me it seems that these helpers are so small that they really don't
need to be shared. If anything, we could add them directly to the OF
module. Something like of_property_read_u32_range() that takes additions
min/max values.
+static const struct drm_format_info *display_get_validated_format(struct
drm_device *dev,
+ u32 depth)
+{
+ const struct drm_format_info *info;
+ u32 format;
+
+ switch (depth) {
+ case 8:
+ format = drm_mode_legacy_fb_format(8, 8);
+ break;
+ case 15:
I think is customary now to add /* fall through */ here to silence GCC warns ?
There should be no warnings if multiple case statements are directly
next to each other.
+}
+
+static int display_read_u32_of(struct drm_device *dev, struct device_node
*of_node,
+ const char *name, u32 *value)
+{
+ int ret = of_property_read_u32(of_node, name, value);
+
+ if (ret)
+ drm_err(dev, "cannot parse framebuffer %s: error %d\n", name,
ret);
+ return ret;
+}
+
[snip]
+static u64 display_get_address_of(struct drm_device *dev, struct device_node
*of_node)
+{
+ u32 address;
+ int ret;
+
+ /*
+* Not all devices provide an address property, it's not
+* a bug if this fails. The driver will try to find the
+* framebuffer base address from the device's memory regions.
+*/
+ ret = of_property_read_u32(of_node, "address", );
+ if (ret)
+ return OF_BAD_ADDR;
+
+ return address;
+}
+
All these helpers seems to be quite generic and something that other OF
drivers could benefit from. Maybe add them to drivers/gpu/drm/drm_of.c ?
No point in exporting them AFAICT. They look like the code in simpledrm,
but they are specific to this single driver. In this context 'OF' is not
OF in general, but the specific generic display of PPC's OF device tree.
No other DRM driver should use this.
+#if defined(CONFIG_PCI)
+static struct pci_dev *display_get_pci_dev_of(struct drm_device *dev, struct
device_node *of_node)
+{
+ const __be32 *vendor_p, *device_p;
+ u32 vendor, device;
+ struct pci_dev *pcidev;
+
+ vendor_p = of_get_property(of_node, "vendor-id", NULL);
+ if (!vendor_p)
+ return ERR_PTR(-ENODEV);
+ vendor = be32_to_cpup(vendor_p);
+
+ device_p = of_get_property(of_node, "device-id", NULL);
+ if (!device_p)
+ return ERR_PTR(-ENODEV);
+ device = be32_to_cpup(device_p);
+
+ pcidev = pci_get_device(vendor, device, NULL);
+ if (!pcidev)
+ return ERR_PTR(-ENODEV);
+
+ return pcidev;
+}
+#else
+static struct pci_dev *display_get_pci_dev_of(struct drm_device *dev, struct
device_node *of_node)
+{
+ return ERR_PTR(-ENODEV);
+}
+#endif
+
Unsure about this one, I don't see other display driver using a "vendor-id"
or "device-id" when looking at Documentation/devicetree/bindings/, so guess
this one would have to remain in the driver and not in a helper library.
But since you have #ifdefery here, maybe would be cleaner to have that stub
defined as static inline in include/drm/drm_of.h ?
+static struct ofdrm_device *ofdrm_device_of_dev(struct drm_device *dev)
+{
+ return container_of(dev, struct ofdrm_device, dev);
+}
+
+/*
+ * OF display settings
+ */
+
This seems like another candidate to move to the include/drm/drm_of.h header.
+static struct
[PATCH] powerpc/perf: Optimize clearing the pending PMI and remove WARN_ON for PMI check in power_pmu_disable
commit 2c9ac51b850d ("powerpc/perf: Fix PMU callbacks to clear
pending PMI before resetting an overflown PMC") added a new
function "pmi_irq_pending" in hw_irq.h. This function is to check
if there is a PMI marked as pending in Paca (PACA_IRQ_PMI).This is
used in power_pmu_disable in a WARN_ON. The intention here is to
provide a warning if there is PMI pending, but no counter is found
overflown.
During some of the perf runs, below warning is hit:
WARNING: CPU: 36 PID: 0 at arch/powerpc/perf/core-book3s.c:1332
power_pmu_disable+0x25c/0x2c0
Modules linked in:
-
NIP [c0141c3c] power_pmu_disable+0x25c/0x2c0
LR [c0141c8c] power_pmu_disable+0x2ac/0x2c0
Call Trace:
[c00baffcfb90] [c0141c8c] power_pmu_disable+0x2ac/0x2c0
(unreliable)
[c00baffcfc10] [c03e2f8c] perf_pmu_disable+0x4c/0x60
[c00baffcfc30] [c03e3344] group_sched_out.part.124+0x44/0x100
[c00baffcfc80] [c03e353c] __perf_event_disable+0x13c/0x240
[c00baffcfcd0] [c03dd334] event_function+0xc4/0x140
[c00baffcfd20] [c03d855c] remote_function+0x7c/0xa0
[c00baffcfd50] [c026c394] flush_smp_call_function_queue+0xd4/0x300
[c00baffcfde0] [c0065b24] smp_ipi_demux_relaxed+0xa4/0x100
[c00baffcfe20] [c00cb2b0] xive_muxed_ipi_action+0x20/0x40
[c00baffcfe40] [c0207c3c] __handle_irq_event_percpu+0x8c/0x250
[c00baffcfee0] [c0207e2c] handle_irq_event_percpu+0x2c/0xa0
[c00baffcff10] [c0210a04] handle_percpu_irq+0x84/0xc0
[c00baffcff40] [c0205f14] generic_handle_irq+0x54/0x80
[c00baffcff60] [c0015740] __do_irq+0x90/0x1d0
[c00baffcff90] [c0016990] __do_IRQ+0xc0/0x140
[c009732f3940] [c00bafceaca8] 0xc00bafceaca8
[c009732f39d0] [c0016b78] do_IRQ+0x168/0x1c0
[c009732f3a00] [c00090c8]
hardware_interrupt_common_virt+0x218/0x220
This means that there is no PMC overflown among the active events
in the PMU, but there is a PMU pending in Paca. The function
"any_pmc_overflown" checks the PMCs on active events in
cpuhw->n_events. Code snippet:
<<>>
if (any_pmc_overflown(cpuhw))
clear_pmi_irq_pending();
else
WARN_ON(pmi_irq_pending());
<<>>
Here the PMC overflown is not from active event. Example: When we do
perf record, default cycles and instructions will be running on PMC6
and PMC5 respectively. It could happen that overflowed event is currently
not active and pending PMI is for the inactive event. Debug logs from
trace_printk:
<<>>
any_pmc_overflown: idx is 5: pmc value is 0xd9a
power_pmu_disable: PMC1: 0x0, PMC2: 0x0, PMC3: 0x0, PMC4: 0x0, PMC5: 0xd9a,
PMC6: 0x80002011
<<>>
Here active PMC (from idx) is PMC5 , but overflown PMC is PMC6(0x80002011).
When we handle PMI interrupt for such cases, if the PMC overflown is
from inactive event, it will be ignored. Reference commit:
commit bc09c219b2e6 ("powerpc/perf: Fix finding overflowed PMC in interrupt")
Patch addresses two changes:
1) Fix 1 : Removal of warning ( WARN_ON(pmi_irq_pending()); )
We were printing warning if no PMC is found overflown among active PMU
events, but PMI pending in PACA. But this could happen in cases where
PMC overflown is not in active PMC. An inactive event could have caused
the overflow. Hence the warning is not needed. To know pending PMI is
from an inactive event, we need to loop through all PMC's which will
cause more SPR reads via mfspr and increase in context switch. Also in
existing function: perf_event_interrupt, already we ignore PMI's
overflown when it is from an inactive PMC.
2) Fix 2: optimization in clearing pending PMI.
Currently we check for any active PMC overflown before clearing PMI
pending in Paca. This is causing additional SPR read also. From point 1,
we know that if PMI pending in Paca from inactive cases, that is going
to be ignored during replay. Hence if there is pending PMI in Paca, just
clear it irrespective of PMC overflown or not.
In summary, remove the any_pmc_overflown check entirely in
power_pmu_disable. ie If there is a pending PMI in Paca, clear it, since
we are in pmu_disable. There could be cases where PMI is pending because
of inactive PMC ( which later when replayed also will get ignored ), so
WARN_ON could give false warning. Hence removing it.
Fixes: 2c9ac51b850d ("powerpc/perf: Fix PMU callbacks to clear pending PMI
before resetting an overflown PMC")
Signed-off-by: Athira Rajeev
---
arch/powerpc/perf/core-book3s.c | 35 ++---
1 file changed, 15 insertions(+), 20 deletions(-)
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index b5b42cf0a703..3adc08254875 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -1349,27 +1349,22 @@ static void power_pmu_disable(struct pmu *pmu)
* a PMI happens during interrupt replay and perf counter
Re: [PATCH 1/5] kallsyms: pass buffer size in sprint_* APIs
On Fri, May 20, 2022 at 03:52:01PM -0400, Waiman Long wrote: > On 5/20/22 04:36, Maninder Singh wrote: ... > > - sprint_symbol(sym, addr); > > + sprint_symbol(sym, KSYM_SYMBOL_LEN, addr); > > Instead of hardcoding KSYM_SYMBOL_LEN everywhere, will it better to hide it > like this: > > extern int __sprint_symbol(char *buffer, size_t size, unsigned long > address); > #define sprint_symbol(buf, addr) __sprint_symbol(buf, > sizeof(buf), addr) > > Or you can use sizeof(buf) directly instead of KSYM_SYMBOL_LEN. This assumes that buf is defined as char [], which might be not always the case. If you are going with the macro, than ARRAY_SIZE() seems appropriate to perform a check against the above mentioned constraint. -- With Best Regards, Andy Shevchenko
Re: [PATCH 0/5] kallsyms: make kallsym APIs more safe with scnprintf
On Fri, May 20, 2022 at 02:06:56PM +0530, Maninder Singh wrote: > kallsyms functionality depends on KSYM_NAME_LEN directly. > but if user passed array length lesser than it, sprintf > can cause issues of buffer overflow attack. > > So changing *sprint* and *lookup* APIs in this patch set > to have buffer size as an argument and replacing sprintf with > scnprintf. This is still a pretty horrible API. Passing something like a struct seq_buf seems like the much better API here. Also with the amount of arguments and by reference passing it might be worth to pass them as a structure while you're at it.
