Re: [PATCH] powerpc/xmon: Fix tmpstr length check in scanhex
On Wed, Aug 14, 2024 at 12:10 PM Madhavan Srinivasan wrote: > > Reported-by: Miguel Ojeda > Signed-off-by: Madhavan Srinivasan > Link - https://lore.kernel.org/linuxppc-dev/87ilc8ym6v.fsf@mail.lhotse/ Thanks for fixing this! The "Link -" should be a tag, i.e. "Link:". And, in this case, since it was a report, I think it should be a "Closes:" instead, and thus it should be put below the "Reported-by:" and it should point to the message of the original report, i.e. https://lore.kernel.org/linuxppc-dev/CANiq72=QeTgtZL4k9=4CJP6C_Hv=rh3fsn3b9s3kfopxkyw...@mail.gmail.com/ I am not sure if a "Fixes:" tag would apply here, though. Cheers, Miguel
Re: [PATCH v2 18/18] fbdev: Document that framebuffer_alloc() returns zero'ed data
On Thu, Jul 13, 2023 at 3:03 PM Thomas Zimmermann wrote: > > Most fbdev drivers depend on framebuffer_alloc() to initialize the > allocated memory to 0. Document this guarantee. > > Suggested-by: Miguel Ojeda > Signed-off-by: Thomas Zimmermann > Cc: Helge Deller Thanks for sending this! Maybe this would be best earlier in the series, so that later patches make more sense (since they use the guarantee), but it is not a big deal. > + * aligned to sizeof(long). Both, the instance of struct fb_info and > + * the driver private data, are cleared to zero. I think both commas may be best omitted (but I am not a native speaker). Reviewed-by: Miguel Ojeda Cheers, Miguel
Re: [PATCH 09/17] auxdisplay: Remove flag FBINFO_FLAG_DEFAULT from fbdev drivers
On Tue, Jul 11, 2023 at 8:10 AM Thomas Zimmermann wrote: > > I'd like to take the patchset into drm-misc. It's part of a larger > cleanup of the fbdev modules and its interfaces. Sounds good, thanks! Cheers, Miguel
Re: [PATCH 09/17] auxdisplay: Remove flag FBINFO_FLAG_DEFAULT from fbdev drivers
On Mon, Jul 10, 2023 at 5:22 PM Thomas Zimmermann wrote: > > I'll append a patch to the series that documents this. > > Sure. Thanks! If you are planning to take it into some other tree: Acked-by: Miguel Ojeda Otherwise, I can take it into the `auxdisplay` tree. Cheers, Miguel
Re: [PATCH 09/17] auxdisplay: Remove flag FBINFO_FLAG_DEFAULT from fbdev drivers
On Mon, Jul 10, 2023 at 3:01 PM Thomas Zimmermann wrote: > > The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct > fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do > not set it. `framebuffer_alloc()` does indeed use `kzalloc()`, but the docs do not mention the zeroing. Should that guarantee be documented? > Flags should signal differences from the default values. After cleaning > up all occurences of FBINFO_FLAG_DEFAULT, the token can be removed. occurences -> occurrences can -> will maybe? Since the intention of the patch series is to remove it (them) altogether). Thanks! Cheers, Miguel
Re: [PATCH 1/1] arch:hexagon/powerpc: use KSYM_NAME_LEN in array size
On Wed, May 31, 2023 at 1:14 AM Kees Cook wrote: > > On Mon, May 29, 2023 at 04:50:45PM +0200, Miguel Ojeda wrote: > > Kees: what is the current stance on `[static N]` parameters? Something like: > > > > const char *kallsyms_lookup(unsigned long addr, > > unsigned long *symbolsize, > > unsigned long *offset, > > - char **modname, char *namebuf); > > + char **modname, char namebuf[static > > KSYM_NAME_LEN]); > > > > makes the compiler complain about cases like these (even if trivial): > > > > arch/powerpc/xmon/xmon.c:1711:10: error: array argument is too small; > > contains 128 elements, callee requires at least 512 > > [-Werror,-Warray-bounds] > > name = kallsyms_lookup(pc, &size, &offset, NULL, tmpstr); > > ^ ~~ > > ./include/linux/kallsyms.h:86:29: note: callee declares array > > parameter as static here > > char **modname, char namebuf[static KSYM_NAME_LEN]); > > ^ ~~ > > Wouldn't that be a good thing? (I.e. complain about the size mismatch?) Yeah, I would say so (i.e. I meant it as a good thing). > > But I only see 2 files in the kernel using `[static N]` (from 2020 and > > 2021). Should something else be used instead (e.g. `__counted_by`), > > even if constexpr-sized?. > > Yeah, it seems pretty uncommon. I'd say traditionally arrays aren't > based too often, rather structs containing them. > > But ultimately, yeah, everything could gain __counted_by and friends in > the future. That would be nice! Cheers, Miguel
Re: [PATCH 2/2] powerpc/xmon: use KSYM_NAME_LEN in array size
On Thu, Jun 1, 2023 at 4:02 AM Michael Ellerman wrote: > > > Side-note: in `get_function_bounds()`, I see `kallsyms_lookup()` being > > used, but the name seems discarded? Can > > `kallsyms_lookup_size_offset()` be used instead, thus avoiding the > > usage of the buffer there to begin with? > > A few lines below it uses the modname, and AFAICS there's no (easy) way > to lookup the modname without also looking up the name. Hmm... I think you are looking at the `xmon_print_symbol()` one? I was referring to the `get_function_bounds()` one, where the `modname` parameter is `NULL` (and the `name` contents are not used, only whether it was found or not). > > Side-note 2: in `scanhex()`, I see a loop `i<63` using `tmpstr` which > > then is used to do a `kallsyms_lookup_name()`, so I guess symbols > > larger than 64 couldn't be found. I have no idea about what are the > > external constraints here, but perhaps it is possible to increase the > > `line` buffer etc. to then allow for bigger symbols to be found. > > Yeah that looks wrong. I don't see any symbols that long in current > kernels, but we should fix it. > > Thanks for looking. My pleasure! Cheers, Miguel
Re: [PATCH 1/2] hexagon/traps.c: use KSYM_NAME_LEN in array size
On Mon, May 29, 2023 at 1:14 PM Maninder Singh wrote:
>
> kallsyms_lookup which in turn calls for kallsyms_lookup_buildid()
> writes on index "KSYM_NAME_LEN - 1".
>
> Thus array size should be KSYM_NAME_LEN.
>
> for hexagon it was defined as "128" directly.
> and commit '61968dbc2d5d' changed define value to 512,
> So both were missed to update with new size.
>
> Fixes: 61968dbc2d5d ("kallsyms: increase maximum kernel symbol length to 512")
>
> Co-developed-by: Onkarnath
> Signed-off-by: Onkarnath
> Signed-off-by: Maninder Singh
With the updated commit hash:
Reviewed-by: Miguel Ojeda
Cheers,
Miguel
Re: [PATCH 2/2] powerpc/xmon: use KSYM_NAME_LEN in array size
On Mon, May 29, 2023 at 1:14 PM Maninder Singh wrote: > > +static char tmpstr[KSYM_NAME_LEN]; Reviewed-by: Miguel Ojeda Side-note: in `get_function_bounds()`, I see `kallsyms_lookup()` being used, but the name seems discarded? Can `kallsyms_lookup_size_offset()` be used instead, thus avoiding the usage of the buffer there to begin with? Side-note 2: in `scanhex()`, I see a loop `i<63` using `tmpstr` which then is used to do a `kallsyms_lookup_name()`, so I guess symbols larger than 64 couldn't be found. I have no idea about what are the external constraints here, but perhaps it is possible to increase the `line` buffer etc. to then allow for bigger symbols to be found. Cheers, Miguel
Re: [PATCH 1/1] arch:hexagon/powerpc: use KSYM_NAME_LEN in array size
On Mon, May 29, 2023 at 1:08 PM Maninder Singh wrote: > > I Will add co-developed-by` tag. > because this change was identified while we were working on kallsyms some > time back. > https://lore.kernel.org/lkml/yontol4zc4cyt...@infradead.org/t/ > > this patch set is pending and we will start working on that again, so i > thought better > to send bugfix first. Sounds good to me! (Fixed Wedson's email address) > Yes, I think second buffer was not related to kallsyms, so I have not touched > that. Kees: what is the current stance on `[static N]` parameters? Something like: const char *kallsyms_lookup(unsigned long addr, unsigned long *symbolsize, unsigned long *offset, - char **modname, char *namebuf); + char **modname, char namebuf[static KSYM_NAME_LEN]); makes the compiler complain about cases like these (even if trivial): arch/powerpc/xmon/xmon.c:1711:10: error: array argument is too small; contains 128 elements, callee requires at least 512 [-Werror,-Warray-bounds] name = kallsyms_lookup(pc, &size, &offset, NULL, tmpstr); ^ ~~ ./include/linux/kallsyms.h:86:29: note: callee declares array parameter as static here char **modname, char namebuf[static KSYM_NAME_LEN]); ^ ~~ But I only see 2 files in the kernel using `[static N]` (from 2020 and 2021). Should something else be used instead (e.g. `__counted_by`), even if constexpr-sized?. Also, I went through the other callers to `kallsyms_lookup` to see other issues -- one I am not sure about is `fetch_store_symstring` in `kernel/trace/trace_probe_tmpl.h`. Steven/Masami: is that "with max length" in the function docs enough? Is it 0x? Thanks! Cheers, Miguel
Re: [PATCH 1/1] arch:hexagon/powerpc: use KSYM_NAME_LEN in array size
On Mon, May 29, 2023 at 7:44 AM Maninder Singh wrote:
>
> kallsyms_lookup which in turn calls for kallsyms_lookup_buildid()
> writes on index "KSYM_NAME_LEN - 1".
>
> Thus array size should be KSYM_NAME_LEN.
>
> for powerpc and hexagon it was defined as "128" directly.
> and commit '61968dbc2d5d' changed define value to 512,
> So both were missed to update with new size.
>
> Fixes: 61968dbc2d5d ("kallsyms: increase maximum kernel symbol length to 512")
> Signed-off-by: Onkarnath
> Signed-off-by: Maninder Singh
Thanks for this!
There is no `From:` at the top. Since I cannot locate the patch in
Lore, did you mean to put both of you as authors perhaps? In that
case, please use a `Co-developed-by` as needed.
Perhaps it is a good idea to submit each arch independently, too.
The changes themselves look fine on a quick inspection, though the
`xmon.c` one is a global buffer (and there is another equally-sized
buffer in `xmon.c` with a hard-coded `128` constant that would be nice
to clarify).
Cheers,
Miguel
Re: [PATCH 1/2] start_kernel: add no_stack_protector fn attr
On Wed, Apr 12, 2023 at 8:32 PM wrote: > > include/linux/compiler_attributes.h | 12 Acked-by: Miguel Ojeda Cheers, Miguel
Re: [PATCH] modpost: support arbitrary symbol length in modversion
On Wed, Jan 18, 2023 at 8:02 AM Masahiro Yamada wrote: > > - *.mod.c is kept human readable. On the topic of `.mod.c` readability: for approaches that may be less readable, we could improve that by adding some extra comments or rearrange things in a different way (it is a generated file, after all!). For instance, for the original approach: https://godbolt.org/z/6oh45axnc Cheers, Miguel
Re: [PATCH 12/15] auxdisplay: ht16k33: Introduce backlight_get_brightness()
On Sat, Jan 7, 2023 at 7:26 PM Sam Ravnborg via B4 Submission Endpoint wrote: > > Introduce backlight_get_brightness() to simplify logic > and avoid direct access to backlight properties. Note: Stephen sent this one too a while ago (with some more details in the commit message, which is always nice); and then he sent yesterday v2 [1] (to mention the functional change with `BL_CORE_SUSPENDED` [2]). Anyway, if it goes via drm-misc, feel free to have my: Acked-by: Miguel Ojeda Though it would be nice to have Robin test the change. Thanks! [1] https://lore.kernel.org/lkml/20230106143002.1434266-1-st...@sk2.org/ [2] https://lore.kernel.org/lkml/caniq72krhmt37h1fagygny83onyxeqjuo8zpbym0ajqowky...@mail.gmail.com/ Cheers, Miguel
Re: [PATCH v8 27/31] Kbuild: add Rust support
On Wed, Aug 17, 2022 at 5:51 PM Arnd Bergmann wrote:
>
> Thanks for the explanation. My hope was that building the kernel
Don't mention it!
> would actually be easier here than building the more complicated
> rust user space.
Yeah, the kernel is complicated for them in different ways, so I
assume they will decide which bits to tackle first... Hopefully I will
succeed in my attempts to convince them to focus a bit on the kernel
at least ;)
> I tried one more step and just removed the unsupported command
> line flags to see what would happen, but that did not get me any
> further:
Thanks!
It looks like it failed when compiling the target spec generator,
which is a Rust host program. If they were to attempt the GCC Rust
support early on, we could make things easier for them by not
compiling host programs with gccrs.
By the way, feel free to remove all the `-D` flags ("denying") when
playing with it since they are related to diagnostics (making lints
errors that can still be bypassed if needed), in case the crash is
about handling those.
Cheers,
Miguel
Re: [PATCH v8 27/31] Kbuild: add Rust support
On Wed, Aug 17, 2022 at 6:11 PM Björn Roy Baron wrote: > > There is already a prototype of such a driver. It can be found at > https://github.com/Rust-GCC/cargo-gccrs. Unlike what the name suggests it is > not cargo specific. It consists of two binaries. The first calls cargo, but > tells it to use the second binary instead of a real rustc. This second part > then translates all arguments to what gccrs expects. It is possible to > directly invoke this second binary. For now it probably won't work for > rust-for-linux though as it doesn't have all arguments that are used by > rust-for-linux implemented. I spoke with them about this a few weeks ago, but I thought it was best to leave it up to the GCC Rust folks to detail how they will proceed if they already know. > As alternative to GCC Rust there is also > github.com/rust-lang/rustc_codegen_gcc/ which uses libgccjit as backend for > the official rust compiler rather than writing a full Rust frontend for GCC > from scratch. With a bit of patching to force it to be used, I was able to > compile all Rust samples with GCC using rustc_codegen_gcc. However it gives > warnings of the following kind: > > ld.lld: warning: rust/built-in.a(core.o):(.data.rel.local) is being > placed in '.data.rel.local' > > And hangs very early in the boot process. If I enable early logging, it > prints up to "Booting the kernel." and then does nothing. This is probably > because support for setting a different relocation model is not yet > implemented. I opened > https://github.com/rust-lang/rustc_codegen_gcc/issues/205 for this. Thanks Björn for giving it a go! Arnd maintains a set of cross-GCC binaries for kernel developers, so I assumed he was mainly interested in including GCC Rust there -- I didn't mean to leave `rustc_codegen_gcc` aside! :) In fact, a few weeks ago I also spoke with Antoni (Cc'd too!) about whether he would be interested in getting it to work with Rust for Linux soon, whether and how we could help him, etc. In any case, both GCC Rust and `rustc_codegen_gcc` will be present in Kangrejos and LPC (Rust MC), so hopefully we will discuss the details face-to-face! > There may be other issues, but rustc_codegen_gcc is probably going to be the > easiest route towards a LLVM free rust-for-linux build. By the way note that > rust-bindgen which we use for generating rust bindings from C headers depends > on LLVM. See https://github.com/rust-lang/rust-bindgen/issues/1949. Yeah, `rustc_codegen_gcc` is possibly going to happen sooner than GCC Rust for the kernel. As for `bindgen`, it is indeed a pain point. There are several possibilities we have been considering (GCC backend in `bindgen`, an equivalent tool in GCC, something based on other parsers, something else entirely, "just checking the results" approaches, even convincing upstream Rust that C header support would be amazing for Rust uptake... ;-). Ideally we would get funding to have somebody working on the problem, but we will see. Cheers, Miguel
Re: [PATCH v8 27/31] Kbuild: add Rust support
Hi Arnd, On Wed, Aug 17, 2022 at 4:40 PM Arnd Bergmann wrote: > > Hi Miguel, > > I tried enabling rust support in the gcc builds I provide at > https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/arm64/12.1.0/ Thanks for giving it a go! > to make this more accessible, but it appears that the command line > options here are not portable: > > > /home/arnd/cross/x86_64/gcc-12.1.0+rust-nolibc/x86_64-linux/bin/x86_64-linux-gccrs So you mean with GCC Rust, right? (i.e. we have "GCC builds" working, via compiling the Rust side with LLVM and linking with the GCC C side, but it is not intended for production or to be supported, even if we cover it in our CI, test it boots and loads modules etc.). Indeed, `gccrs` does not support `rustc` flags yet. I am not sure if the GCC Rust team will eventually provide a driver for those like clang does for e.g. `cl` -- I would hope they do, since many projects would benefit from it, but maybe they plan to start simply by modifying Cargo to call them as they need instead. If they don't support it, we will have to map the flags on our side -- it should not be a big problem. However, see below... > I guess nobody has tried this so far. Would you think that fixing this is only > a matter for fixing the build system to pass the correct flags depending on > the > compiler, or is this broken in a more fundamental way? If you meant GCC Rust, then it is a bit too early for the compiler. As far as I now, they are working on compiling the `core` crate and supporting more stable language features. They are also researching the integration of the borrow checker, though we wouldn't need that for "only" compiling the kernel. Now, if they decided to focus on supporting Rust for Linux early on (which would be great), they would still need to work on the delta between what what they target now and what we use (which includes both stable and some unstable features), plus I assume infrastructure bits like the platform (target spec) support, the flags / `rustc` driver (though I would be happy to do as much as possible on our side to help), etc. (We privately talked about possible timelines for all that if they were to focus on Rust for Linux etc., but I let them comment or not on that... Cc'ing them! :) Cheers, Miguel
Re: [PATCH v8 00/31] Rust support
On Tue, Aug 2, 2022 at 5:09 PM Miguel Ojeda wrote: > > Yeah, patch 17, exactly (patch 11 is the `alloc` import). I have asked > Konstantin privately about them. The patches are showing up now in lore -- not sure if it was just a delay (which would be consistent with the lack of bounce) or somebody did something (thank you if so!). Cheers, Miguel
Re: [PATCH v8 00/31] Rust support
On Tue, Aug 2, 2022 at 4:01 PM Matthew Wilcox wrote: > > No objections to any of this. I love the idea of being able to write > filesystems in Rust. I just think it would go more smoothly if > linux-fsdevel were involved more closely so people at least have the > option of being able to follow design decisions, and hopefully influence > them. That goes both ways, of course; I hardly think our current > operations structures are the optimum way to implement a filesystem, > and having fresh eyes say things like "But that shouldn't be part of the > address_space_operations" can impel better abstractions. I will send the patches to fsdevel then! As for following development closely and design decisions, we have been doing it in GitHub so far pre-merge, so the easiest until the merge (for us) would be to ping you there. We can also send you copies of the `fs` related patches too if you would like that. I would highly recommend joining the monthly informal calls too. (I appreciate the kind answer, by the way!) > The obvious answer is to split out the 'fs module' into its own patch > ;-) I presume it was part of the kernel crate which would have been > either patch 17 or 11 in that series? Yeah, patch 17, exactly (patch 11 is the `alloc` import). I have asked Konstantin privately about them. In any case, I will split the patches further for v9 which should help. Meanwhile, you can also see the `fs` module here, if you are curious: https://github.com/Rust-for-Linux/linux/blob/rust-next/rust/kernel/fs.rs https://github.com/Rust-for-Linux/linux/blob/rust-next/rust/kernel/fs/param.rs Cheers, Miguel
Re: [PATCH v8 00/31] Rust support
On Tue, Aug 2, 2022 at 3:48 PM Christoph Hellwig wrote: > > handwaiving and pointing to git trees is not how Linux development > works. Please make sure all the patches go to the relevant lists > and maintainers first, and actually do have ACKs. Which hand-waving? In fact, we were requested to do it like this. As for the Cc's, if any ML wants to be Cc'd for an abstraction we create, even if no C code is modified on their side, I am more than happy to Cc them. I can even do that by default, but not everyone may want to hear about the Rust side just yet, so I have not been doing it so far. Cheers, Miguel
Re: [PATCH v8 00/31] Rust support
Hi Willy, On Tue, Aug 2, 2022 at 2:26 PM Matthew Wilcox wrote: > > None of this (afaict) has been discussed on linux-fsdevel. And I may > have missed somethiing, but I don't see the fs module in this series > of patches. Could linux-fsdevel be cc'd on the development of Rust > support for filesystems in the future? In order to provide example drivers and kernel modules, we need to have some safe abstractions for them, thus we are adding some as we need them. More importantly, the abstractions also serve as a showcase of how they may be written in the future if Rust support is merged. This does not mean these abstractions are a final design or that we plan to develop them independently of subsystem maintainers. In fact, we would prefer the opposite: in the future, when the support is merged and more people start having more experience with Rust, we hope that the respective kernel maintainers start developing and maintaining the abstractions themselves. But we have to start somewhere, and at least provide enough examples to serve as guidance and to show that it is actually possible to write abstractions that restrict the amount of unsafe code. And, of course, if you are already interested in developing them, that would be actually great and we would love your input and/or that you join us. As for the `fs` module, I see in lore 2 patches didn't make it through, but I didn't get a bounce (I do get bounces for the rust-for-linux ML, but I was told that was fine as long as LKML got them). Sorry about that... I will ask what to do. Meanwhile, you can see the patches in this branch: https://github.com/Rust-for-Linux/linux.git rust-next Cheers, Miguel
[PATCH v8 27/31] 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
Co-developed-by: Tiago Lam
Signed-off-by: Tiago Lam
Co-developed-by: Björn Roy Baron
Signed-off-by: Björn Roy Baron
Co-developed-by: Martin Rodriguez Reboredo
Signed-off-by: Martin Rodriguez Reboredo
Signed-off-by: Miguel Ojeda
---
.gitignore | 6 +
.rustfmt.toml| 12 +
Makefile | 172 +++-
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| 10 +
include/linux/compiler_types.h | 6 +-
init/Kconfig | 46 +-
lib/Kconfig.debug| 82
rust/.gitignore | 10 +
rust/Makefile| 415 +++
rust/bindgen_parameters | 21 +
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 | 232 +++
scripts/is_rust_module.sh| 16 +
scripts/kconfig/confdata.c | 75
scripts/min-tool-version.sh | 6 +
scripts/rust-is-available-bindgen-libclang.h | 2 +
scripts/rust-is-available.sh | 160 +++
33 files changed, 1408 insertions(+), 26 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 265959544978..5da004814678 100644
--- a/.gitignore
+++ b/.gitignore
@@ -37,6 +37,8 @@
*.o
*.o.*
*.patch
+*.rmeta
+*.rsi
*.s
*.so
*.so.dbg
@@ -97,6 +99,7 @@ modules.order
!.gitattributes
!.gitignore
!.mailmap
+!.rustfmt.toml
#
# Generated include files
@@ -162,3 +165,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 df92892325ae..cd1d545f316b 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)&q
[PATCH v8 00/31] Rust support
With this final cleanup, the remaining warnings (of all kinds)
are either false positives, or cannot be changed without diverging
with upstream `alloc` or would make things look worse.
## 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 will appear in the next `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
Join us in LPC 2022 (Linux Plumbers Conference) for the Rust MC
(microconference)! The schedule is available at:
https://lpc.events/event/16/sessions/150/
We will be talking about GCC Rust (the Rust frontend for GCC),
`rustc_codegen_gcc` (the GCC backend for `rustc`), Rust for Linux,
the Rust NVMe driver, the integration of Rust with the Kernel Testing
Service and Rust in the Kernel (via eBPF).
In addition, I would like to personally thank Google and ISRG
(Internet Security Research Group) for sponsoring Kangrejos,
the Rust for Linux workshop:
https://kangrejos.com
Furthermore, we would like to thank the venues we were invited to:
- Linux Foundation Live Mentorship Series
- Open Source Summit North America
- Huawei Global Software Technology Summit
## Related news
The GCC Steering Committee accepted the contribution of the Rust
frontend (GCC Rust). Its first released version (experimental,
disabled by default) should appear in GCC 13. The first round of
patches has been posted to the gcc-patches mailing list.
`rustc_codegen_gcc` (the GCC backend for `rustc`) has seen enough
progress on SIMD support to compile `stdarch`. In addition, more
prerequisite patches are making their way into GCC.
## 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:
- Nick Desaulniers, Joe Perches, Masahiro Yamada and Jarkko Sakkinen
for their reviews of some of the v7 patches.
- Daniel Latypov, Brendan Higgins and Shuah Khan for picking up
the KUnit prerequisite patch.
- As usual, Björn Roy Baron (bjorn3) and Gary Guo for all the input
on Rust compiler details, reviews and suggestions.
- Andreas Hindborg for working on the NVMe driver, as well as
adding atomic allocations for `Box` and allowing to use GFP flags
for `KernelAllocator`.
- Li Hongyu for working on a virtio abstraction.
- Boqun Feng for working on adding an alloc alignment test.
- Andreas Reindl for working on adding missing `SAFETY` comments.
- Anhad Singh for working on adding the `new_with_flags` method
to `Pages`.
- Finn Behrens for working on making it possible to compile
the kernel on macOS with Rust enabled.
- Roel Kluin for working on code refactorings.
- Wei Liu for taking the time to answer questions from newcomers
in Zulip.
- Philip Li, Yujie Liu et al. for continuing their work on adding
Rust support to the Intel 0DAY/LKP kernel test robot.
- Philip Herron and Arthur Cohen (and his supporters Open Source
Security and Embecosm) et al. for their ongoing work on GCC Rust.
- Antoni Boucher (and his supporters) et al. for their ongoing
work on `rustc_codegen_gcc`.
- Emilio Cobos Álvarez et. al. for their work on `bindgen`,
including on issues that affect the kernel.
- Mats Larsen, Marc Poulhiès et al. for their ongoing work on
improving Rust support in Compiler Explorer.
- Many folks that have reported issues, tested the project,
helped spread the word, joined discussions and contributed in
other ways!
Please see also the acknowledgements on the previous cover letters.
Boqun Feng (2):
kallsyms: use `sizeof` instead of hardcoded size
kallsyms: avoid hardcoding buffer size
Gary Guo (2):
rust: add `build_error` crate
vsprintf: add new `%pA` format specifier
Miguel Ojeda (19):
kallsyms: add static relationship between `KSYM_NAME_LEN{,_BUFFER}`
kallsyms: support "big" kernel symbols
kallsyms: increase maximum kernel symbol length to 512
rust: add C helpers
rust: add `compiler_builtins` crate
rust: import upstream `alloc` crate
rust: adapt `alloc` crate to the kernel
rust: add `macros` crate
rust: add `bindings` crate
rust: export generated symbols
scripts: checkpatch: diagnose uses of `%pA` in the C side as errors
scripts: checkp
Re: [PATCH v7 00/25] Rust support
On Sat, Jul 16, 2022 at 3:51 PM wrote: > > Ah right, sorry for the noise so. I checked the ml but didn't see a > report there. No apologies needed -- thanks to you for the report, instead! :) > Thanks Miguel, good to know! I'll just wait around for a new version. > Just been trying to get my CI etc in order for when rust support lands, > but it sounds like I should be okay as it's a known problem & not some > only-broken-on-riscv thing. Yeah, it is a simple `bindgen` issue. Thanks a lot for making the effort to prepare your CI in advance! Cheers, Miguel
Re: [PATCH v7 00/25] Rust support
Hi Conor, On Sat, Jul 16, 2022 at 2:42 PM Conor Dooley wrote: > > Maybe I am just missing something blatantly obvious here, but trying > to build rust support in -next fails for me. I am using ClangBuiltLinux > clang version 15.0.0 5b0788fef86ed7008a11f6ee19b9d86d42b6fcfa and LLD > 15.0.0. Is it just expected that building -next with rust support is > not a good idea? Please see https://github.com/Rust-for-Linux/linux/issues/795 for details about the maple tree issue. I will update the `rust-next` branch next week with the new version of the patches; but if you are interested in developing, please use the development `rust` branch instead in GitHub for the moment. Cheers, Miguel
Re: [PATCH v7 21/25] Kbuild: add Rust support
Hi Masahiro, On Sat, Jul 16, 2022 at 10:23 AM Masahiro Yamada wrote: > > Is it intentional to print the successful message to stderr? I think it makes sense to change it to `stdout`, given the message is the main point of running `rustavailable` for normal users, and those that just want the status code may ignore it. Thanks for taking a look again! Cheers, Miguel
Re: [PATCH 6/6] i2c: Make remove callback return void
n...@kernel.org>, Robert Jones , George Joseph , Vincent Knecht , Robin van der Gracht , Randy Dunlap , linux-st...@st-md-mailman.stormreply.com, Michael Tretter , Geert Uytterhoeven , Phong LE , Daniel Beer , Krzysztof Opasiak , Bjorn Andersson , Linux Crypto Mailing List , Pengutronix Kernel Team , Heungjun Kim , Hans Verkuil , David Lin , Vladimir Oltean , David Rhodes , Claudiu Beznea , Jean-Baptiste Maneyrol , Alexandre Belloni , Dan Robertson , Martyn Welch , Jiri Slaby , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , David Airlie , Jon Nettleton , Srinivas Pandruvada , Marco Felsch , Wim Van Sebroeck , Sebastian Reichel , Max Filippov , "Lad, Prabhakar" , Thierry Reding , linux-...@vger.kernel.org, Martiros Shakhzadyan , Guenter Roeck , Matthias Schwarzott , Sylwester Nawrocki , Eric Dumazet , =?UTF-8?B?TWFyZWsgQmVow7pu?= , Saranya Gopal , Lars-Peter Clausen , Corey Minyard , Evgeny Novikov , Frank Rowand , Bartosz Golaszewski , Manivannan Sadhasivam , Pierre-Louis Bossart , Minghao Chi , linux-...@vger.kernel.org, Nathan Chancellor , MyungJoo Ham , Charles Gorand , Jagan Teki , Vijendar Mukunda , Miguel Ojeda , Kyungmin Park , Tianshu Qiu , Martin Donnelly , Woojung Huh , Rudolf Marek , Charles Keepax , Linux Watchdog Mailing List , Michael Hennerich , Ido Schimmel , acpi4asus-u...@lists.sourceforge.net, Simon Trimmer , Ricard Wanderlof , Rikard Falkeborn , Alex Deucher , Jiri Valek - 2N , linux-rpi-ker...@lists.infradead.org, Biju Das , Wayne Chang , Chen-Yu Tsai , Sing-Han Chen , Linux ARM , =?UTF-8?Q?Niklas_Söderlund?= , Hans de Goede , Stephen Boyd , Maslov Dmitry , "open list:GPIO SUBSYSTEM" , Jens Frederich , Douglas Anderson , Linux Media Mailing List , "David S. Miller" , Wolfram Sang , Jarkko Sakkinen , USB list , Jacopo Mondi , Maxime Coquelin , CGEL ZTE , Colin Leroy , Platform Driver , linux-integrity , Kevin Tsai , =?UTF-8?Q?Pali_Rohár?= , Jonathan Cameron , Heiner Kallweit , Daniel Palmer , Arec Kao , Crt Mori , Jose Cazarin , Neil Armstrong , linux-...@vger.kernel.org, Tom Rix , Michael Turquette , Peter Senna Tschudin , Benjamin Mugnier , =?UTF-8?B?TnVubyBTw6E=?= , Jan-Simon Moeller , Wei Yongjun , Laurent Pinchart , Andrzej Hajda , Nikita Travkin , Jeremy Kerr , Jasmin Jessich , Sam Ravnborg , Kevin Cernekee , Alyssa Rosenzweig , linux-...@vger.ker nel.org, Daniel Thompson , Florian Fainelli , Lucas Tanure , Stefan Mavrodiev , Masahiro Yamada , Sylvain Petinot , Network Development , Kieran Bingham , Jernej Skrabec , Xin Ji , Seven Lee , Matt Ranostay , Broadcom internal kernel review list , Adrien Grassein , Yang Yingliang , chrome-platf...@lists.linux.dev, Mats Randgaard , Paolo Abeni , Alexey Dobriyan , Joel Stanley , linux-input , linuxppc-dev , Lyude Paul , Kees Cook , =?UTF-8?Q?Uwe_Kleine-König?= , Jonas Karlman , Yang Li , Tim Harvey , Jiri Kosina , Akinobu Mita , Mark Gross , Richard Fitzgerald , Mark Brown , wengjianfeng , Maxime Ripard , Sven Peter , Martin Kepplinger , openipmi-develo...@lists.sourceforge.net, Mauro Carvalho Chehab , Benson Leung , "Daniel W. S. Almeida" , Chiranjeevi Rapolu , Alessandro Zummo , linux-hw...@vger.kernel.org, Felipe Balbi , Stephan Gerhold , Support Opensource , Alexandru Ardelean , Dmitry Torokhov , Marc Hulsman , Corentin Chary , Stephen Kitt , Daniel Scally , Linux Fbdev development list , Andrey Ryabinin , Arnd Bergmann , Kirill Shilimanov , Sakari Ailus , patc...@opensource.cirrus.com, Zheng Yongjun , Alejandro Tafalla , Peter Rosin , Arnaud Ferraris , Hector Martin , Vignesh Raghavendra , Nick Dyer , Greg Kroah-Hartman , Tony Lindgren , Alexandre Torgue , Takashi Iwai , Paul Cercueil , George McCollister , Mac Chiang , Antoniu Miclaus , Alexander Potapenko , linux-stag...@lists.linux.dev, Adam Fo rd , Peter Huewe , unglinuxdri...@microchip.com, Lee Jones , MTD Maling List , Alexey Khoroshilov , Marek Vasut , Paul Kocialkowski , ALSA Development Mailing List , Vincenzo Frascino , Eric Piel , Herbert Xu , Tobias Schrammm , Richard Weinberger , Tomasz Duszynski , Janusz Krzysztofik , Russell King , linux-...@vger.kernel.org, Jason Gunthorpe , Thomas Zimmermann , Bastien Nocera , Jingoo Han , Jakub Kicinski , Vivien Didelot , Yizhuo , Shawn Tu , Leon Luo , Yan Lei , Akihiro Tsukada , Tudor Ambarus , Dmitry Rokosov , Oliver Graute , Alistair Francis , Dongliang Mu , =?UTF-8?Q?Jonathan_Neuschäfer?= , Eduardo Valentin , Rui Miguel Silva , Michael Srba , Rob Herring , linux-media...@lists.infradead.org, Fabio Estevam , Matthias Brugger , kasan-dev , "Paul J. Murphy" , Nicola Lunghi , Daniele Alessandrelli , Dmitry Vyukov , Ramesh Shanmugasundaram , Liam Girdwood , Juerg Haefliger , Oder Chiou , Shengjiu Wang , Nicolas Ferre , Robert Foss , Krzysztof Kozlowski , Daniel Vetter , =?UTF-8?Q?Alvin_Šipraga?= , Luca Ceresoli , =?U
Re: [PATCH v7 21/25] Kbuild: add Rust support
On Thu, May 26, 2022 at 12:25 AM Nick Desaulniers wrote: > > Is there a reason to not just turn clippy on always? Might be nicer to > start off with good practices by default. :^) The idea crossed my mind too [1], but sadly Clippy disables some optimizations and in general is not intended to be used for normal compilation [2]. [1] https://github.com/rust-lang/rust-clippy/issues/8035 [2] https://github.com/rust-lang/rust-clippy/pull/8037 > Are there *.rmeta directories that we _don't_ want to remove via `make > mrproper`? I'm curious why *.rmeta isn't just part of MRPROPER_FILES? Putting them in `MRPROPER_FILES` would mean only those in a given directory are removed (e.g. the root one), but the idea here is to find them anywhere in the tree, since in the future we may have library crates in different parts of the tree. However, I am not sure I understand your first question in relation with the second one -- if we put them in `MRPROPER_FILES`, that would remove less, not more. > I don't think we need to repeat dir/* here again for rust. The > existing targets listed above (outside this hunk) make sense in both > contexts. The idea here is to document the differences (e.g. `RUSTFMT`) and that we may have other targets in the future that do not apply to C (e.g. MIR dump, if that happens to be useful). But maybe I can fit that in the normal place and make it still look good... I will give it a try. > Does rustc really use .i as a conventional suffix for macro expanded > sources? (The C compiler might use the -x flag to override the guess It is not a conventional suffix at all as far as I am aware. Maybe we should use a different one to aid editors and users anyway, e.g. `.rsi`, similar to `.mi` for Objective-C `.m` files. > it would make based on the file extension; I'm curious if rustc can > ingest .i files or will it warn?) The macro expanded output is not intended to be used as a compilable input, but as a debugging aid only. I can note this there. Having said that, `rustc` accepts the "preprocessed" output in the sense that it will just treat them as normal source files (no flag needed, and e.g. both `.i` and `.rsi` work); however, it may give new diagnostics or may require extra flags to enable some compiler features. >From a quick test, I managed to compile a "preprocessed" Rust kernel module with only command-line changes. But if we really wanted to support this, we would need to ask upstream Rust to actually support it. > Are these two kconfigs used anywhere? Not for the moment, but it could still be useful when getting `.config` reports (and we could add it to `LINUX_COMPILER` etc. in the future). > How does enabling or disabling debug info work for rustc? I may have > missed it, but I was surprised to see no additional flags getting > passed to rustc based on CONFIG_DEBUG info. `-Cdebuginfo=` is the one; by default there is no debug info and that option enables it (i.e. it is not just the level but the enablement too). (Note that in userspace, when compiling a common program, you will get some debug info coming from the standard library and other dependencies). > Ah, that explains the host rust build infra. Bravo! Hard coding the > target files was my major concern last I looked at the series. I'm > very happy to see it be generated properly from .config! > > I haven't actually reviewed this yet, but it makes me significantly > more confident in the series to see this approach added. Good job > whoever wrote this. Thanks! I thought Rust would be a nice option for writing hostprogs, though of course for the moment only programs that can assume Rust is there may use it. Note that non-x86 specific options need to be handled properly still (e.g. move things between the arch Makefiles and the hostprog as needed). I would still want to see compilers come to some kind of common format for this as we discussed other times, but... :) > Does `$(READELF) -p .comment foo.o` print anything about which > compiler was used? That seems less brittle IMO. Currently, `rustc` does not add a `.comment` section; but we could ask, I sent [3]. If debug info is enabled, another way is using the `DW_AT_language` attribute, like `pahole` will be doing for a new option we need [4]. However, we would still need a way for the other case. In any case, I am not sure something like `.comment` is less or more brittle -- compilers could in theory change it (e.g. not emitting it), while adding a symbol is something we control. So different kinds of brittleness. [3] https://github.com/rust-lang/rust/pull/97550 [4] https://git.kernel.org/pub/scm/devel/pahole/pahole.git/commit/?id=8ee363790b7437283c53090a85a9fec2f0b0fbc4 Cheers, Miguel
Re: [PATCH v7 21/25] Kbuild: add Rust support
On Mon, May 23, 2022 at 8:45 PM Nick Desaulniers wrote: > > I'm super not into having the rust optimization level differ from the > C optimization level. This is just someone having too much fun > wrapping every compiler flag in a kbuild option. Either folks wan't I mean, `Makefile`s are not my favorite pastime... :) > smaller size or more optimizations. Allowing for RUST_OPT_LEVEL_S and > CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE or RUST_OPT_LEVEL_3 and > CONFIG_CC_OPTIMIZE_FOR_SIZE is just wacky nonsense that's going to > make randconfig bug reports more confusing to tease out. I think what is important is to decide whether extra levels, for C and Rust, should be kept compile-able/maintained or not (I also replied in the `-O1` for C thread [1]). Note that the Rust side can be compiled as `-O0` or `-O1` at the moment, which is something we do not have for the C side; thus having only the C == Rust option means we will not have a configuration with those anymore. For me it is less complex to not have them, and I have not heard more opinions on this, either for or against (apart from that thread suggesting `-O1` for the C side), so if nobody else chimes in, I will remove them. [1] https://lore.kernel.org/lkml/caniq72kysvvoq7eqwe0jzz3v0jttrcqodhr9ty4-sfdmdzp...@mail.gmail.com/ Cheers, Miguel
[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 ("$(orig
[PATCH v7 00/25] Rust support
working on wrapping `mm_struct`.
- Sergio González Collado for continuing his work on the GitHub CI
problem matchers.
- Wei Liu for taking the time to answer questions from newcomers
in Zulip.
- Philip Li, Yujie Liu et al. for continuing their work on adding
Rust support to the Intel 0DAY/LKP kernel test robot.
- Philip Herron and Arthur Cohen (and his supporters Open Source
Security and Embecosm) et al. for their ongoing work on GCC Rust.
- Antoni Boucher (and his supporters) et al. for their ongoing
work on `rustc_codegen_gcc`.
- Mats Larsen, Marc Poulhiès et al. for their ongoing work on
improving Rust support in Compiler Explorer.
- Many folks that have reported issues, tested the project,
helped spread the word, joined discussions and contributed in
other ways!
Please see also the acknowledgements on the previous cover letters.
Boqun Feng (1):
kallsyms: avoid hardcoding the buffer size
Gary Guo (2):
rust: add `build_error` crate
vsprintf: add new `%pA` format specifier
Miguel Ojeda (18):
kallsyms: support "big" kernel symbols
kallsyms: increase maximum kernel symbol length to 512
kunit: take `kunit_assert` as `const`
rust: add C helpers
rust: add `compiler_builtins` crate
rust: import upstream `alloc` crate
rust: adapt `alloc` crate to the kernel
rust: add `macros` crate
rust: export generated symbols
scripts: checkpatch: diagnose uses of `%pA` in the C side
scripts: checkpatch: enable language-independent checks for Rust
scripts: add `rustdoc_test_{builder,gen}.py` scripts
scripts: add `generate_rust_analyzer.py` scripts
scripts: decode_stacktrace: demangle Rust symbols
docs: add Rust documentation
Kbuild: add Rust support
samples: add Rust examples
MAINTAINERS: Rust
Wedson Almeida Filho (4):
rust: add `kernel` crate's `sync` module
rust: add `kernel` crate
[RFC] drivers: gpio: PrimeCell PL061 in Rust
[RFC] drivers: android: Binder IPC in Rust
.gitignore |5 +
.rustfmt.toml| 12 +
Documentation/core-api/printk-formats.rst| 10 +
Documentation/doc-guide/kernel-doc.rst |3 +
Documentation/index.rst |1 +
Documentation/kbuild/kbuild.rst | 17 +
Documentation/kbuild/makefiles.rst | 50 +-
Documentation/process/changes.rst| 41 +
Documentation/rust/arch-support.rst | 25 +
Documentation/rust/coding-guidelines.rst | 216 ++
Documentation/rust/general-information.rst | 79 +
Documentation/rust/index.rst | 22 +
Documentation/rust/quick-start.rst | 232 ++
MAINTAINERS | 15 +
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 +
drivers/android/Kconfig |6 +
drivers/android/Makefile |2 +
drivers/android/allocation.rs| 266 ++
drivers/android/context.rs | 80 +
drivers/android/defs.rs | 99 +
drivers/android/node.rs | 476 +++
drivers/android/process.rs | 960 +
drivers/android/range_alloc.rs | 189 +
drivers/android/rust_binder.rs | 111 +
drivers/android/thread.rs| 870 +
drivers/android/transaction.rs | 326 ++
drivers/gpio/Kconfig |8 +
drivers/gpio/Makefile|1 +
drivers/gpio/gpio_pl061_rust.rs | 370 ++
include/kunit/test.h |2 +-
include/linux/kallsyms.h |2 +-
include/linux/spinlock.h | 25 +-
include/uapi/linux/android/binder.h | 28 +-
init/Kconfig | 45 +-
kernel/kallsyms.c| 26 +-
kernel/livepatch/core.c |4 +-
lib/Kconfig.debug| 155 +
lib/kunit/test.c |4 +-
lib/vsprintf.c | 13 +
rust/.gitignore | 10 +
rust/Makefile| 398 +++
rust/alloc/README.md | 33 +
rust/alloc/alloc.rs | 438 +++
rust/alloc/borrow.rs | 498 +++
rust/alloc/boxed.rs | 20
Re: [PATCH v6 00/23] Rust support
Hi David, On Tue, May 10, 2022 at 6:45 AM David Gow wrote: > > I've just sent out a pull request to get this working under UML as > well, which would simplify running these further: > https://github.com/Rust-for-Linux/linux/pull/766 Thanks a lot! > Yeah, these are all fair points: particularly for small doctests. > > Maybe having an optional name, which more significant tests could use > to override the file:line names? That could be useful for a few of the > larger, more often referenced tests. Sounds reasonable. I can add support for that. > Ugh: it's a bit ugly either way. I suspect that file:line is still > probably better, if only because we need some way of looking up the > test in the code if it fails. I'd hate for people to be randomly > hashing bits of just to find out what test is failing. One redeeming quality is that the assertion prints the line/file number in the generated file, so it would still be possible to check where it came from: [13:13:43] # rust_kernel_doctest_str_rs_somehash: ASSERTION FAILED at rust/doctests_kernel_generated.rs:2209 [13:13:43] Expected 2 > 3 to be true, but is false [13:13:43] not ok 43 - rust_kernel_doctest_str_rs_somehash [13:13:43] [FAILED] rust_kernel_doctest_str_rs_somehash Another alternative is to keep the file:line information around without embedding it into the test name, e.g. in a TAP comment or a mapping file (which `kunit.py` could read). But, yeah, before doing hashes or things like that, I would just go for simplicity and keep things as they are unless some use case really needs doctests to be stable. > Oops: I missed that (one of the issues with testing this on a > different machine which had a rust toolchain). Looks good to me. > > Ah: I didn't realise the plan was always to have crate-specific > suites, and possibly to split things up. > > The KTAP output specification does actually support arbitrary nesting > (though KUnit itself doesn't at the moment), which would potentially > be an option if (e.g.) providing the complete module nesting made > sense. I'm not convinced that'd make things easier to read, though. That is useful to know in case we need it, thanks! Cheers, Miguel
Re: [PATCH v6 00/23] Rust support
Hi David, On Sat, May 7, 2022 at 11:29 AM David Gow wrote: > > It's great to see some KUnit support here! Thanks! > It's also possible to run these tests using the KUnit wrapper tool with: > $ ./tools/testing/kunit/kunit.py run --kconfig_add CONFIG_RUST=y > --make_options LLVM=1 --arch x86_64 'rust_kernel_doctests' > > That also nicely formats the results. Indeed! [16:55:52] rust_kernel_doctests (70 subtests) [16:55:52] [PASSED] rust_kernel_doctest_build_assert_rs_12_0 [16:55:52] [PASSED] rust_kernel_doctest_build_assert_rs_55_0 ... [16:55:52] [PASSED] rust_kernel_doctest_types_rs_445_0 [16:55:52] [PASSED] rust_kernel_doctest_types_rs_509_0 [16:55:52] == [PASSED] rust_kernel_doctests === [16:55:52] [16:55:52] Testing complete. Passed: 70, Failed: 0, Crashed: 0, Skipped: 0, Errors: 0 > That all being said, I can't say I'm thrilled with the test names > here: none of them are particularly descriptive, and they'll probably > not be static (which would make it difficult to track results / > regressions / etc between kernel versions). Neither of those are Yeah, the names are not great and would change from time to time across kernel versions. We could ask example writers to give each example a name, but that would make them fairly less convenient. For instance, sometimes they may be very small snippets interleaved with docs' prose (where giving a name may feel a bit of a burden, and people may end writing `foo_example1`, `foo_example2` etc. for each small "step" of an explanation). In other cases they may be very long, testing a wide API surface (e.g. when describing a module or type), where it is also hard to give non-generic names like `rbtree_doctest`. In those kind of cases, I think we would end up with not much better names than automatically generated ones. The other aspect is that, given they are part of the documentation, the prose or how things are explained/split may change, thus the doctests as well. For instance, one may need to split a very long `rbtree_doctest` in pieces, and then the name would need to change anyway. So I think we should avoid asking documentation writers to add a manual name, even if that means a bit ugly test names. Also this way they are consistently named. What do you think? One idea could be giving them a name based on the hash of the content and avoiding the line number, so that there is a higher chance for the name to stay the same even when the file gets modified for other reasons. > necessarily deal breakers, though it might make sense to hide them > behind a kernel option (like all other KUnit tests) so that they can > easily be excluded where they would otherwise clutter up results. (And Currently they are under `CONFIG_RUST_KERNEL_KUNIT_TEST` -- or do you mean something else? > if there's a way to properly name them, or maybe even split them into > per-file or per-module suites, that would make them a bit easier to > deal.) Additionally, there are some plans to taint the kernel[1] when Yeah, splitting them further is definitely possible. We are also likely splitting the `kernel` crate into several, which would also make the suites smaller etc. so perhaps further splits may not be needed. > Regardless, this is very neat, and I'm looking forward to taking a > closer look at it. Thanks again for taking a look and playing with it, I am glad you liked it! (even if it is just a first approximation, and only supports the `kernel` crate, etc.). Cheers, Miguel
[PATCH v6 19/23] 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
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/x86/Kconfig | 1 +
arch/x86/Makefile| 14 +
init/Kconfig | 45 ++-
lib/Kconfig.debug| 155
rust/.gitignore | 10 +
rust/Makefile| 397 +++
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
31 files changed, 1450 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 9a820c525b86..d0837a13e9d3 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 := $(clean-targets)
[PATCH v6 00/23] Rust support
u Li for working on Rust iterators as the equivalent of
`cpumask`'s `for_each_*_cpu`.
- Andreas Hindborg for adding support to `kernel::Pages` methods to
allow read/write of multiple pages.
- Sergio González Collado for working on adding `#[cold]` attributes
for error-related items and GitHub CI problem matchers.
- Sean Nash for updating the out-of-tree-module example due to a
change in the main repository.
- Michael Ellerman, Nicholas Piggin, Paul E. McKenney and Zhouyi
Zhou for debugging the `CONFIG_HIGH_RES_TIMERS=n` stall issue
in PowerPC that we triggered in our CI.
- Jonathan Corbet for writing an LWN article on the crates
discussion that took place in the Rust for Linux mailing list.
- Wei Liu for taking the time to answer questions from newcomers
in Zulip.
- Philip Li, Yujie Liu et al. for continuing their work on adding
Rust support to the Intel 0DAY/LKP kernel test robot.
- Philip Herron and Arthur Cohen (and his supporters Open Source
Security and Embecosm) et al. for their ongoing work on GCC Rust.
- Antoni Boucher (and his supporters) et al. for their ongoing
work on `rustc_codegen_gcc`.
- Mats Larsen, Marc Poulhiès et al. for their ongoing work on
improving Rust support in Compiler Explorer.
- Many folks that have reported issues, tested the project,
helped spread the word, joined discussions and contributed in
other ways!
Please see also the acknowledgements on the previous cover letters.
Boqun Feng (1):
kallsyms: avoid hardcoding the buffer size
Gary Guo (2):
rust: add `build_error` crate
vsprintf: add new `%pA` format specifier
Miguel Ojeda (16):
kallsyms: support "big" kernel symbols
kallsyms: increase maximum kernel symbol length to 512
kunit: take `kunit_assert` as `const`
rust: add C helpers
rust: add `compiler_builtins` crate
rust: import upstream `alloc` crate
rust: adapt `alloc` crate to the kernel
rust: add `macros` crate
rust: export generated symbols
scripts: add `rustdoc_test_{builder,gen}.py` scripts
scripts: add `generate_rust_analyzer.py` scripts
scripts: decode_stacktrace: demangle Rust symbols
docs: add Rust documentation
Kbuild: add Rust support
samples: add Rust examples
MAINTAINERS: Rust
Wedson Almeida Filho (4):
rust: add `kernel` crate's `sync` module
rust: add `kernel` crate
[RFC] drivers: gpio: PrimeCell PL061 in Rust
[RFC] drivers: android: Binder IPC in Rust
.gitignore |5 +
.rustfmt.toml| 12 +
Documentation/doc-guide/kernel-doc.rst |3 +
Documentation/index.rst |1 +
Documentation/kbuild/kbuild.rst | 17 +
Documentation/kbuild/makefiles.rst | 50 +-
Documentation/process/changes.rst| 41 +
Documentation/rust/arch-support.rst | 34 +
Documentation/rust/coding-guidelines.rst | 214 ++
Documentation/rust/general-information.rst | 77 +
Documentation/rust/index.rst | 20 +
Documentation/rust/logo.svg | 357 ++
Documentation/rust/quick-start.rst | 230 ++
MAINTAINERS | 15 +
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/x86/Kconfig |1 +
arch/x86/Makefile| 14 +
drivers/android/Kconfig |6 +
drivers/android/Makefile |2 +
drivers/android/allocation.rs| 266 ++
drivers/android/context.rs | 80 +
drivers/android/defs.rs | 99 +
drivers/android/node.rs | 476 +++
drivers/android/process.rs | 960 +
drivers/android/range_alloc.rs | 189 +
drivers/android/rust_binder.rs | 111 +
drivers/android/thread.rs| 870 +
drivers/android/transaction.rs | 326 ++
drivers/gpio/Kconfig |8 +
drivers/gpio/Makefile|1 +
drivers/gpio/gpio_pl061_rust.rs | 370 ++
include/kunit/test.h |2 +-
include/linux/kallsyms.h |2 +-
include/linux/spinlock.h | 25 +-
include/uapi/linux/android/binder.h | 28 +-
init/Kconfig | 45 +-
kernel/kallsyms.c| 26 +-
kernel/livepatch/core.c |4 +-
lib/Kconfig.debug
Re: rcu_sched self-detected stall on CPU
On Fri, Apr 8, 2022 at 4:42 PM Michael Ellerman wrote: > > The Rust CI has it disabled because I copied that from the x86 defconfig > they were using back when I added the Rust support. I think that was > meant to be a stripped down fast config for CI, but the result is it's Indeed, that was my intention when I created the original config. > So I'll send a patch to turn HIGH_RES_TIMERS on for the Rust CI, and we > can debug this further without blocking them. Thanks! I can also do it on your behalf, if you prefer, when I sync with -rc1. Cheers, Miguel
Re: rcu_sched self-detected stall on CPU
On Fri, Apr 8, 2022 at 9:23 AM Michael Ellerman wrote:
>
> I haven't seen it in my testing. But using Miguel's config I can
> reproduce it seemingly on every boot.
Hmm... I noticed this for some kernel builds: in some builds/commits,
it triggered the very first time, while in others I had to re-try
quite a few times. It could be a "fluke", but since it happened to you
too (and Zhouyi seemed to need 12 tries), it may be that particular
kernel builds makes the bug much more likely.
> For me it bisects to:
>
> 35de589cb879 ("powerpc/time: improve decrementer clockevent processing")
>
> Which seems plausible.
>
> Reverting that on mainline makes the bug go away.
That is great, thanks for that -- I can revert that one in our CI meanwhile.
> I'll try and work out what it is about Miguel's config that exposes
> this vs our defconfig, that might give us a clue.
Yeah, it is one based on the "debug" one you sent for Rust PPC.
Assuming you based that one on the others we had for other archs, then
I guess we are bound to find some things like this at times like with
randconfig, since I made them to be fairly minimal and "custom"... :)
Cheers,
Miguel
Re: rcu_sched self-detected stall on CPU
On Thu, Apr 7, 2022 at 5:15 PM Paul E. McKenney wrote: > > Ah. So you would instead look for boot to have completed within 10 > seconds? Either way, reliable automation might well more important than > reduction in time. No (although I guess that could be an option), I was only pointing out that when no stall is produced, the run should be much quicker than 30 seconds (at least it was in my setup), which would be the majority of the runs. Cheers, Miguel
Re: rcu_sched self-detected stall on CPU
On Thu, Apr 7, 2022 at 4:27 AM Zhouyi Zhou wrote: > > Yes, this happens within 30 seconds after kernel boot. If we take all > into account (qemu preparing, kernel loading), we can do one test > within 54 seconds. When it does not trigger, the run should be 20 seconds quicker than that (e.g. 10 seconds), since we don't wait for the stall timeout. I guess the timeout could also be reduced a fair bit to make failures quicker, but they do not contribute as much as the successes anyway. Thanks a lot for running the bisect on that server, Zhouyi! Cheers, Miguel
rcu_sched self-detected stall on CPU
Hi PPC/RCU, While merging v5.18-rc1 changes I noticed our CI PPC runs broke. I reproduced the problem in v5.18-rc1 as well as next-20220405, under both QEMU 4.2.1 and 6.1.0, with `-smp 2`; but I cannot reproduce it in v5.17 from a few tries. Sadly, the problem is not deterministic although it is not too hard to reproduce (1 out of 5?). Please see attached config and QEMU output. Cheers, Miguel qemu Description: Binary data config Description: Binary data
[PATCH v5 16/20] 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
Signed-off-by: Miguel Ojeda
---
.gitignore | 5 +
.rustfmt.toml| 12 +
Makefile | 173 -
arch/Kconfig | 6 +
arch/arm/Kconfig | 1 +
arch/arm64/Kconfig | 1 +
arch/powerpc/Kconfig | 1 +
arch/riscv/Kconfig | 1 +
arch/riscv/Makefile | 5 +
arch/x86/Kconfig | 1 +
arch/x86/Makefile| 14 +
init/Kconfig | 44 ++-
lib/Kconfig.debug| 143 +++
rust/.gitignore | 8 +
rust/Makefile| 376 +++
rust/bindgen_parameters | 13 +
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
31 files changed, 1408 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 55a30ca69350..67008a2d964c 100644
--- a/Makefile
+++ b/Makefile
@@ -120,6 +120,13 @@ 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
+
# 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 +274,7 @@ no-dot-config-targets := $(clean-targets)
[PATCH v5 00/20] Rust support
documentation and suggesting several improvements. - Petr Mladek and Rasmus Villemoes for their printing/formatting review and suggestions. - Russell King for his review of the Kconfig changes. - Andy Shevchenko, Sergey Senozhatsky, John Paul Adrian Glaubitz and David Laight for their reviews and feedback on the previous round. - bjorn3 for reviewing many PRs. - As usual, bjorn3 and Gary Guo for all the input on Rust compiler details and suggestions. - Philip Li, Yujie Liu et al. for continuing their work on adding Rust support to the Intel 0DAY/LKP kernel test robot. Also, thanks to Nathan Chancellor and Nick Desaulniers for their input. - Wei Liu for taking the time to answer questions from newcomers in Zulip. - Antoni Boucher (and his supporters) et al. for their ongoing work on `rustc_codegen_gcc`. - Philip Herrons (and his supporters Open Source Security and Embecosm) et al. for their ongoing work on GCC Rust. - Mats Larsen, Marc Poulhiès et al. for their ongoing work on improving Rust support in Compiler Explorer. - Many folks that have reported issues, tested the project, helped spread the word, joined discussions and contributed in other ways! Please see also the acknowledgements on the previous cover letters. Boqun Feng (1): kallsyms: use the correct buffer size for symbols Gary Guo (2): rust: add `build_error` crate vsprintf: add new `%pA` format specifier Miguel Ojeda (13): kallsyms: support "big" kernel symbols kallsyms: increase maximum kernel symbol length to 512 rust: add C helpers rust: add `compiler_builtins` crate rust: add `alloc` crate rust: add `macros` crate rust: export generated symbols scripts: add `generate_rust_analyzer.py` scripts: decode_stacktrace: demangle Rust symbols docs: add Rust documentation Kbuild: add Rust support samples: add Rust examples MAINTAINERS: Rust Wedson Almeida Filho (4): rust: add `kernel` crate's `sync` module rust: add `kernel` crate [RFC] drivers: gpio: PrimeCell PL061 in Rust [RFC] drivers: android: Binder IPC in Rust .gitignore |5 + .rustfmt.toml| 12 + Documentation/doc-guide/kernel-doc.rst |3 + Documentation/index.rst |1 + Documentation/kbuild/kbuild.rst | 17 + Documentation/kbuild/makefiles.rst | 50 +- Documentation/process/changes.rst| 41 + Documentation/rust/arch-support.rst | 34 + Documentation/rust/coding-guidelines.rst | 214 ++ Documentation/rust/general-information.rst | 77 + Documentation/rust/index.rst | 20 + Documentation/rust/logo.svg | 357 ++ Documentation/rust/quick-start.rst | 230 ++ MAINTAINERS | 15 + Makefile | 173 +- arch/Kconfig |6 + arch/arm/Kconfig |1 + arch/arm64/Kconfig |1 + arch/powerpc/Kconfig |1 + arch/riscv/Kconfig |1 + arch/riscv/Makefile |5 + arch/x86/Kconfig |1 + arch/x86/Makefile| 14 + drivers/android/Kconfig |6 + drivers/android/Makefile |2 + drivers/android/allocation.rs| 266 ++ drivers/android/context.rs | 80 + drivers/android/defs.rs | 99 + drivers/android/node.rs | 476 +++ drivers/android/process.rs | 960 + drivers/android/range_alloc.rs | 189 + drivers/android/rust_binder.rs | 111 + drivers/android/thread.rs| 870 + drivers/android/transaction.rs | 326 ++ drivers/gpio/Kconfig |8 + drivers/gpio/Makefile|1 + drivers/gpio/gpio_pl061_rust.rs | 370 ++ include/linux/kallsyms.h |2 +- include/linux/spinlock.h | 17 +- include/uapi/linux/android/binder.h | 28 +- init/Kconfig | 44 +- kernel/kallsyms.c| 26 +- kernel/livepatch/core.c |4 +- lib/Kconfig.debug| 143 + lib/vsprintf.c | 13 + rust/.gitignore |8 + rust/Makefile| 376 ++ rust/alloc/README.md | 32 + rust/alloc/alloc.rs | 440 +++ rust/alloc/borrow.rs | 498 +++ rust/alloc/boxed.rs | 2008 ++
[PATCH v4 16/20] 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 definition files,
the version detection script and a few other bits.
In the future, we will likely want to generate the target files
on the fly via a script.
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
Signed-off-by: Miguel Ojeda
---
.gitignore | 5 +
.rustfmt.toml| 12 +
Makefile | 154 +++-
arch/arm/rust/target.json| 27 ++
arch/arm64/rust/target.json | 34 ++
arch/powerpc/rust/target.json| 29 ++
arch/riscv/Makefile | 1 +
arch/riscv/rust/rv32ima.json | 36 ++
arch/riscv/rust/rv32imac.json| 36 ++
arch/riscv/rust/rv64ima.json | 36 ++
arch/riscv/rust/rv64imac.json| 36 ++
arch/x86/rust/target.json| 36 ++
init/Kconfig | 45 ++-
lib/Kconfig.debug| 144 +++
rust/.gitignore | 7 +
rust/Makefile| 374 +++
rust/bindgen_parameters | 13 +
scripts/Kconfig.include | 6 +-
scripts/Makefile.build | 65
scripts/Makefile.debug | 10 +
scripts/Makefile.lib | 12 +
scripts/Makefile.modfinal| 8 +-
scripts/cc-version.sh| 12 +-
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
28 files changed, 1372 insertions(+), 20 deletions(-)
create mode 100644 .rustfmt.toml
create mode 100644 arch/arm/rust/target.json
create mode 100644 arch/arm64/rust/target.json
create mode 100644 arch/powerpc/rust/target.json
create mode 100644 arch/riscv/rust/rv32ima.json
create mode 100644 arch/riscv/rust/rv32imac.json
create mode 100644 arch/riscv/rust/rv64ima.json
create mode 100644 arch/riscv/rust/rv64imac.json
create mode 100644 arch/x86/rust/target.json
create mode 100644 rust/.gitignore
create mode 100644 rust/Makefile
create mode 100644 rust/bindgen_parameters
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 ceb987e5c87b..1975d47e74e6 100644
--- a/Makefile
+++ b/Makefile
@@ -120,6 +120,13 @@ 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
+
# Use make M=dir or set the environment variable KBUILD_EX
[PATCH v4 00/20] Rust support
ting a few improvements around `is_rust_module.sh`. - Wei Liu for exporting the remaining helpers and triggering a useful discussion around it. - Miguel Cano for fixing an issue with compilers containing a full, 3-part version in the suffix part (e.g. Ubuntu Clang). - Abhik Jain for working on adding missing `// SAFETY` comments and `# Safety` sections to the code generated by the `module!` macro. - Jiapeng Chong and the Abaci Robot for reporting and fixing an unneeded header `#include`. - Finn Behrens for resuming his work on building Rust for Linux on Nix and spotting and fixing usability issues. - As usual, Gary Guo and bjorn3 for all the input on Rust compiler details and all the reviews and suggestions. - John Ericson, TennyZhuang and Xuanwo for their ongoing work on adding more fallible allocation methods (`try_*`) to the Rust standard library. - Stephan Sokolow and Mark Rousskov for their feedback on the custom documentation logo RFC. - Philip Herrons (and his supporters Open Source Security and Embecosm) et. al. for their ongoing work on GCC Rust. - Antoni Boucher (and his supporters) et. al. for their ongoing work on `rustc_codegen_gcc`. - Mats Larsen, Marc Poulhiès et. al. for their ongoing work on improving Rust support in Compiler Explorer. - Many folks that have reported issues, tested the project, helped spread the word, joined discussions and contributed in other ways! Please see also the acknowledgements on the previous cover letters. Boqun Feng (1): kallsyms: use the correct buffer size for symbols Gary Guo (2): rust: add `build_error` crate vsprintf: add new `%pA` format specifier Miguel Ojeda (13): kallsyms: support "big" kernel symbols kallsyms: increase maximum kernel symbol length to 512 rust: add C helpers rust: add `compiler_builtins` crate rust: add `alloc` crate rust: add `macros` crate rust: export generated symbols scripts: add `generate_rust_analyzer.py` scripts: decode_stacktrace: demangle Rust symbols docs: add Rust documentation Kbuild: add Rust support samples: add Rust examples MAINTAINERS: Rust Wedson Almeida Filho (4): rust: add `kernel` crate's `sync` module rust: add `kernel` crate [RFC] drivers: gpio: PrimeCell PL061 in Rust [RFC] drivers: android: Binder IPC in Rust .gitignore |5 + .rustfmt.toml| 12 + Documentation/doc-guide/kernel-doc.rst |3 + Documentation/index.rst |1 + Documentation/kbuild/kbuild.rst |4 + Documentation/process/changes.rst| 42 + Documentation/rust/arch-support.rst | 35 + Documentation/rust/coding-guidelines.rst | 153 + Documentation/rust/general-information.rst | 80 + Documentation/rust/index.rst | 21 + Documentation/rust/logo.svg | 357 ++ Documentation/rust/quick-start.rst | 231 ++ MAINTAINERS | 16 + Makefile | 154 +- arch/arm/rust/target.json| 27 + arch/arm64/rust/target.json | 34 + arch/powerpc/rust/target.json| 29 + arch/riscv/Makefile |1 + arch/riscv/rust/rv32ima.json | 36 + arch/riscv/rust/rv32imac.json| 36 + arch/riscv/rust/rv64ima.json | 36 + arch/riscv/rust/rv64imac.json| 36 + arch/x86/rust/target.json| 36 + drivers/android/Kconfig |7 + drivers/android/Makefile |2 + drivers/android/allocation.rs| 266 ++ drivers/android/context.rs | 80 + drivers/android/defs.rs | 99 + drivers/android/node.rs | 476 +++ drivers/android/process.rs | 961 + drivers/android/range_alloc.rs | 189 + drivers/android/rust_binder.rs | 111 + drivers/android/thread.rs| 871 + drivers/android/transaction.rs | 326 ++ drivers/gpio/Kconfig |8 + drivers/gpio/Makefile|1 + drivers/gpio/gpio_pl061_rust.rs | 370 ++ include/linux/kallsyms.h |2 +- include/linux/spinlock.h | 17 +- include/uapi/linux/android/binder.h | 28 +- init/Kconfig | 45 +- kernel/kallsyms.c| 26 +- kernel/livepatch/core.c |4 +- kernel/printk/printk.c |5 +- lib/Kconfig.debug| 144 + lib/rust.h | 14 + lib/vsprintf.c
Re: [PATCH v4 16/20] Kbuild: add Rust support
Hi John Paul, On Sat, Feb 12, 2022 at 7:27 PM John Paul Adrian Glaubitz wrote: > > Is there any particular reason why this list excludes MIPS*, i386, big-endian > PowerPC and SPARC targets which are already supported by the Rust programming > language? The variations we have so far were intended to showcase the Rust support in several major architectures, rather than cover everything. But as long as LLVM (& the kernel, i.e. ClangBuiltLinux) supports the target (and as long there are no compiler/toolchain issues), you should be able to try it. > Are the arch/$ARCH/rust/target.json files everything that's needed for > supporting > the other targets? Mostly -- there is also `rust/kernel/c_types.rs` and you may need to tweak `rust/compiler_builtins.rs`, but not much more. Note that for the target spec files, the short-term plan is to generate dynamically the target spec file according to what the architecture requests, instead of using these static files. Longer term, we need a Rust-stable way to setup custom targets from upstream `rustc` (though it is not clear yet how it will look, e.g. it could be via command-line flags). Cheers, Miguel
Re: [PATCH v4 16/20] Kbuild: add Rust support
On Sat, Feb 12, 2022 at 5:19 PM Russell King (Oracle) wrote: > > Right, so why made it dependent on CPU_32v6 || CPU_32v6K if ARMv7 is > supported? What about CPU_32v7? What about CPU_32v7M? > > I think it would be saner to use the CPU_V6, CPU_V6K, CPU_V7 and maybe > CPU_V7M here - even bettern to select "HAVE_RUST" from these symbols, > since I'm sure you'd start to see the issue behind my "HAVE_RUST" > suggestion as it means having four symbols just for 32-bit ARM on your > dependency line. To support arch variations properly we also have to configure the compiler via filling a target spec on the fly, but so far we only have a few static variations as an example. This is one of the missing parts of the arch support. I will let you know when we have something ready. > Interestingly, it does not list arm-unknown-linux-gnueabihf, which > is the "tuple" commonly used to build 32-bit ARM kernels. I see it there (Tier 2). > Probably because people incorrectly think it's required or some other > minor reason. As I say: In that case, we should remove them and warn about those instances, assuming the preferred style is to not have it. > so using the argument > that there are "500+ instances" and therefore should be seen as > correct is completely misguided. I did not use any such argument. > I mean, if we end up with, e.g. a filesystem coded in Rust, that > filesystem will not be available on architectures that the kernel As long as that filesystem is an optional feature (or as long as there is a C version), it should be fine. > supports until either (a) Rust gains support for that architecture For this, it would be ideal if entities behind some of the architectures could support LLVM & ClangBuiltLinux, or the GCC Rust frontend, or the GCC backend for `rustc`. For instance, Arm is supporting both LLVM and the Rust project. > or (b) someone re-codes the filesystem in C - at which point, what > is the point of having Rust in the kernel? Having a C version of some system does not mean a Rust version would not offer advantages. In fact, we are adding Rust precisely because we believe it offers some advantages over C, for both end users and maintainers. (Please see the RFC [1], previous discussions, etc.) [1] https://lore.kernel.org/lkml/20210414184604.23473-1-oj...@kernel.org/ Cheers, Miguel
Re: [PATCH v4 16/20] Kbuild: add Rust support
Hi Russell, On Sat, Feb 12, 2022 at 3:17 PM Russell King (Oracle) wrote: > > Please don't use CPU_32v6* here. > > It probably makes more sense to add a symbol "HAVE_RUST" and have the > appropriate architecture Kconfig files select HAVE_RUST. We can do it whatever way arch maintainers prefer, of course. Why would you prefer one over the other? > Does Rust support Thumb on ARMv6 and ARMv7 architectures? Yes, the main backend is LLVM. Some built-in targets and their support level are listed here, if you want to take a look: https://doc.rust-lang.org/nightly/rustc/platform-support.html There is also a GCC backend in `rustc` [1], which is making good progress and may eventually give us access to architectures supported by GCC. Furthermore, a from-scratch Rust frontend for GCC [2] is being worked on, though this effort will likely take more time to reach a point where it may be used for the kernel. [1] https://github.com/rust-lang/rust/tree/master/compiler/rustc_codegen_gcc [2] https://github.com/Rust-GCC/gccrs > Please remove every utterance of "default n" from your patch; n is the > default default which default defaults to, so you don't need to specify > default n to make the option default to n. It will default to n purely > because n is the default when no default is specified. Certainly. I am curious, though: is there a reason for most of the other 500+ instances in the kernel tree? > As Rust doesn't support all the architectures that the kernel supports, > Rust must not be used for core infrastructure. Yeah, although I am not sure I understand what you are getting at here. Cheers, Miguel
Re: ppc: hard lockup / hang in v5.17-rc1 under QEMU
Hi Nicholas, On Thu, Jan 27, 2022 at 8:47 AM Nicholas Piggin wrote: > > That sounds like my fault actually. > > https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-January/239178.html Thanks for the reference & fix! I confirm it works in our CI too. Closing the QEMU issue then. Cheers, Miguel
Re: ppc: hard lockup / hang in v5.17-rc1 under QEMU
Hi Michael, On Thu, Jan 27, 2022 at 11:54 AM Michael Ellerman wrote: > > It looks like your kernel-ppc64le-release.config does not have the > hardlockup detector enabled, so I suspect you're hitting the bug > described in that patch. On -release it was a hang; but please note that on -debug the hard lockup was actually being detected (so it was also reproducible with the detectors enabled). > That fix will hit linux-next in the next day or so and should be in rc2. I confirm the fix works for us -- thanks a lot! Cheers, Miguel
Re: ppc: hard lockup / hang in v5.17-rc1 under QEMU
On Wed, Jan 26, 2022 at 4:03 PM Cédric Le Goater wrote: > > Indeed. I could reproduce. Thanks for the quick confirmation! > Could you please send the QEMU command line and the full dmesg ? and > possibly open an issue on : > >https://gitlab.com/qemu-project/qemu/-/issues/ > > I guess it's a QEMU modeling issue. Of course -- done (details there): https://gitlab.com/qemu-project/qemu/-/issues/842 Cheers, Miguel
ppc: hard lockup / hang in v5.17-rc1 under QEMU
Hi PPC folks,
Our ppc64le CI deterministically triggers a hard lockup / hang under
QEMU since v5.17-rc1 (upgrading from v5.16).
Bisecting points to 0faf20a1ad16 ("powerpc/64s/interrupt: Don't enable
MSR[EE] in irq handlers unless perf is in use").
Cheers,
Miguel
[ 16.328310] watchdog: CPU 1 detected hard LOCKUP on other CPUs 0
[ 16.328955] watchdog: CPU 1 TB:16743325700, last SMP heartbeat
TB:8453096925 (16191ms ago)
[ 16.330786] watchdog: CPU 0 Hard LOCKUP
[ 16.331078] watchdog: CPU 0 TB:16744720354, last heartbeat
TB:8453109168 (16194ms ago)
[ 16.331295] Kernel panic - not syncing: Hard LOCKUP
[ 16.331312] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.16.0-rc2+ #28
[ 16.331729] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.16.0-rc2+ #28
[ 16.332294] NIP: c0009784 LR: c034ee60 CTR: c00096e0
[ 16.332339] REGS: c0001ff87d60 TRAP: 0100 Not tainted (5.16.0-rc2+)
[ 16.332410] MSR: 80001031 CR: 2488 XER: 2004
[ 16.334770] CFAR: c000977c IRQMASK: 3
[ 16.334770] GPR00: c034ee60 c111f590
c111f400 8002
[ 16.334770] GPR04: 0001 c113f400
c106f400 c110f400
[ 16.334770] GPR08: c03af400 2488
c111f8a0 c0011d00
[ 16.334770] GPR12: 80009033 c11d
[ 16.334770] GPR16: c110ab90 c10722f0
c1142100 0001
[ 16.334770] GPR20: 000a
00049233 c10722a8
[ 16.334770] GPR24: 0282 c1076580
c1143a00 0422
[ 16.334770] GPR28: c10b0480 c10722a8
c03b6cfa 015e
[ 16.334464] [c62675c0] [c03283e0] dump_stack_lvl+0x78/0xb8
[ 16.335274] NIP [c0009784] decrementer_common_virt+0xa4/0x210
[ 16.336451] (unreliable)
[ 16.335629] LR [c034ee60] __do_softirq+0xe0/0x2c4
[ 16.336658] [c6267600] [c009378c] panic+0x150/0x3a4
[ 16.336797] Call Trace:
[ 16.337294]
[ 16.336809] [c111f590] [c000c6d8]
interrupt_return_srr_kernel+0x8/0xec (unreliable)
[ 16.337615] [c111f8a0] [c00d2b24]
trigger_load_balance+0x94/0x480
[ 16.337863] [c111f8d0] [c034ee60] __do_softirq+0xe0/0x2c4
[ 16.338079] [c111f9c0] [c009b018] irq_exit+0xa8/0x130
[ 16.338225] [c111fa00] [c001b590] timer_interrupt+0x1b0/0x200
[ 16.338496] [c111fa60] [c00098e8]
decrementer_common_virt+0x208/0x210
[ 16.338803] --- interrupt: 900 at plpar_hcall_norets_notrace+0x18/0x2c
[ 16.339089] NIP: c0072a48 LR: c0074d04 CTR: c0074c60
[ 16.339103] REGS: c111fad0 TRAP: 0900 Not tainted (5.16.0-rc2+)
[ 16.339117] MSR: 82009033 CR: 22000888 XER:
[ 16.339354] CFAR: c0074d00 IRQMASK: 0
[ 16.339354] GPR00: 22000888
[ 16.340017]
[ 16.340120] [c6267710] [c0027650]
watchdog_smp_panic+0x420/0x4e0
[ 16.340441] [c6267800] [c002717c]
watchdog_timer_fn+0xac/0x160
[ 16.340804] c111fd70 c111f400
[ 16.340715] [c6267840] [c01202d8] __run_hrtimer+0xc8/0x190
[ 16.341234]
[ 16.341234] GPR04: 0001 c106f400
01f4
[ 16.341234] GPR08: 001908b1 02ea
006b
[ 16.341234] GPR12: c0074c60 c11d
[ 16.341234] GPR16:
[ 16.341234] GPR20:
[ 16.341234] GPR24:
[ 16.341779]
[ 16.342182] c113f400 0001 c1145928
0001
[ 16.342182] GPR28: c10717a0 c1071798
c10b0480 015e
[ 16.342160] [c6267890] [c011f300]
hrtimer_run_queues+0x150/0x1c0
[ 16.342276] NIP [c0072a48] plpar_hcall_norets_notrace+0x18/0x2c
[ 16.342783]
[ 16.342820] [c6267910] [c011cf58]
update_process_times+0x88/0x110
[ 16.343127] [c6267960] [c012dbc8]
tick_nohz_handler+0xd8/0x150
[ 16.344080] [c62679a0] [c001b570] timer_interrupt+0x190/0x200
[ 16.344439] [c6267a00] [c00098e8]
decrementer_common_virt+0x208/0x210
[ 16.342542] LR [c0074d04] pseries_lpar_idle+0xa4/0x160
[ 16.347000] --- interrupt: 900 at plpar_hcall_norets_notrace+0x18/0x2c
[ 16.347224] --- interrupt: 900
[ 16.347525] NIP: c0072a48 LR: c0074d04 CTR: c0074c60
[ 16.347637] REGS: c6267a70 TRAP: 0900 Not tainted (5.16.0-rc2+)
[ 16.347716] MSR: 80009033 CR: 2248 XER:
[ 16.347910] CFAR: c0074d00 IRQMASK: 0
[ 16.347910] GPR00: 00
Re: [PATCH 2/3] fbdev: rework backlight dependencies
On Wed, Oct 27, 2021 at 3:28 PM Arnd Bergmann wrote: > > Rather than having CONFIG_FB_BACKLIGHT select CONFIG_BACKLIGHT_CLASS_DEVICE, > make any driver that needs it have a dependency on the class device > being available, to prevent circular dependencies. Acked-by: Miguel Ojeda Cheers, Miguel
Re: [PATCH] Raise the minimum GCC version to 5.2
On Tue, May 4, 2021 at 11:22 AM Michal Suchánek wrote: > > Except it makes answering the question "Is this bug we see on this > ancient system still present in upstream?" needlessly more difficult to > answer. Can you please provide some details? If you are talking about testing a new kernel image in the ancient system "as-is", why wouldn't you build it in a newer system? If you are talking about particular problems about bisecting (kernel, compiler) pairs etc., details would also be welcome. > Sure, throwing out old compiler versions that are known to cause > problems makes sense. Updating to latest just because much less so. I definitely did not argue for "latest compiler" or "updating just because". > One of the selling point of C in general and gcc in particular is > stability. If we need the latest compiler we can as well rewrite the > kernel in Rust which has a required update cycle of a few months. Rust does not have a "required update cycle" and it does not break old code unless really required, just like C and common compilers. Concerning GCC, they patch releases for ~2.5 years, sure, but for many projects that is not nearly enough. So you still need custom support, which is anyway what most people care about. > Because some mainline kernel features rely on bleeding edge tools I end > up building mainline with current tools anyway but if you do not need > BTF or whatever other latest gimmick older toolchains should do. It would be better to hear concrete arguments about why "older toolchains should do", rather than calling things a gimmick. Cheers, Miguel
Re: [PATCH] Raise the minimum GCC version to 5.2
On Tue, May 4, 2021 at 9:57 AM Ben Dooks wrote: > > Some of us are a bit stuck as either customer refuses to upgrade > their build infrastructure or has paid for some old but safety > blessed version of gcc. These often lag years behind the recent > gcc releases :( In those scenarios, why do you need to build mainline? Aren't your customers using longterm or frozen kernels? If they are paying for certified GCC images, aren't they already paying for supported kernel images from some vendor too? I understand where you are coming from -- I have also dealt with projects/machines running ancient, unsupported software/toolchains for various reasons; but nobody expected upstream (and in particular the mainline kernel source) to support them. In the cases I experienced, those use cases require not touching anything at all, and when the time came of doing so, everything would be updated at once, re-certified/validated as needed and frozen again. Cheers, Miguel
Re: [PATCH] Raise the minimum GCC version to 5.2
On Mon, May 3, 2021 at 2:20 PM David Laight wrote: > > It would be nice to be able to build current kernels (for local > use) on the 'new' system - but gcc is already too old. I have seen such environments too... However, for the kernel in particular, you could install a newer GCC in the 'new' machine (just for the kernel builds) or do your kernel builds in a different machine -- a 'new' 'new' one :) Cheers, Miguel
Re: [PATCH] Raise the minimum GCC version to 5.2
On Sat, May 1, 2021 at 5:17 PM Masahiro Yamada wrote: > > More cleanups will be possible as follow-up patches, but this one must > be agreed and applied to the mainline first. +1 This will allow me to remove the __has_attribute hack in include/linux/compiler_attributes.h. Reviewed-by: Miguel Ojeda Cheers, Miguel
Re: [PATCH 0/4] Rust for Linux for ppc64le
On Tue, Mar 23, 2021 at 1:16 PM Michael Ellerman wrote: > > It would be nice to be in the CI. I was building natively so I haven't > tried cross compiling yet (which we'll need for CI). Indeed -- in the CI we already cross-compile arm64 (and run under QEMU both arm64 as well as x86_64), so it is easy to add new ones to the matrix. > I can send a pull request if that's easiest. No worries, I will pick the patches. But, of course, feel free to join us in GitHub! :-) Cheers, Miguel
Re: [PATCH 0/4] Rust for Linux for ppc64le
Hi Michael, On Tue, Mar 23, 2021 at 4:27 AM Michael Ellerman wrote: > > Hi all, > > Here's a first attempt at getting the kernel Rust support building on powerpc. Thanks a *lot*! It is great to have more architectures rolling. > It's powerpc64le only for now, as that's what I can easily test given the > distros I have installed. Though powerpc and powerpc64 are also Tier 2 > platforms Even if it is just 64-bit, it is very good to have it! > so in theory should work. Supporting those would require something more > complicated than just pointing rustc at arch/$(ARCH)/rust/target.json. Yeah, the arch/$(ARCH)/rust/target.json dance is a placeholder -- I need to figure out how to do that more cleanly, likely generating them on the fly. > This is based on 832575d934a2 from the Rust-for-Linux tree. Anything newer > gives > me errors about symbol name lengths. I figured I'd send this anyway, as it > seems > like those errors are probably not powerpc specific. Sure, feel free to send things even if they don't work completely. I will take a look at the symbol name lengths -- I increased that limit to 512 and added support for 2-byte lengths in the tables, but perhaps something is missing. If I manage to make it work, I can add ppc64le to our CI! :-) > Michael Ellerman (4): > rust: Export symbols in initialized data section > rust: Add powerpc64 as a 64-bit target_arch in c_types.rs > powerpc/rust: Add target.json for ppc64le > rust: Enable for ppc64le Regarding the development process: at least until the RFC we are working with the usual GitHub PR workflow (for several reasons: having a quick CI setup, getting new Rust developers on-board, having a list of "issues", cross-reference with the Rust repo, etc.). I can take patches from the list, of course, but since we are pre-RFC, do you mind if they get rebased etc. through there? Thanks again! Cheers, Miguel
Re: [PATCH 3/4] powerpc/rust: Add target.json for ppc64le
On Tue, Mar 23, 2021 at 4:27 AM Michael Ellerman wrote: > > ppc64le only for now. We'll eventually need to come up with some way to > change the target.json that's used based on more than just $(ARCH). Indeed, it is one reason I didn't tackle e.g. x86 32-bit, because I wanted to figure out how to do the whole `target.json` cleanly (i.e. likely have a script generate them on the fly), so I thought it was better to wait post-RFC. Cheers, Miguel
Re: [PATCH v2 1/3] powerpc: boot: include compiler_attributes.h
On Wed, Nov 18, 2020 at 1:08 AM Nick Desaulniers wrote: > > It was also noted in 6a9dc5fd6170 that we could -D__KERNEL__ and > -include compiler_types.h like the main kernel does, though testing that > produces a whole sea of warnings to cleanup. (Re; for Gustavo to consider since he took it now): I would add a comment noting this as a reminder -- it also helps to entice a cleanup. Cheers, Miguel
Re: [PATCH 3/3] powerpc: fix -Wimplicit-fallthrough
On Mon, Nov 16, 2020 at 5:35 AM Nick Desaulniers wrote: > > The "fallthrough" pseudo-keyword was added as a portable way to denote > intentional fallthrough. Clang will still warn on cases where there is a > fallthrough to an immediate break. Add explicit breaks for those cases. > > Link: https://github.com/ClangBuiltLinux/linux/issues/236 > Signed-off-by: Nick Desaulniers It makes things clearer having a `break` added, so I like that warning. Reviewed-by: Miguel Ojeda Cheers, Miguel
Re: [PATCH 2/3] Revert "lib: Revert use of fallthrough pseudo-keyword in lib/"
On Mon, Nov 16, 2020 at 5:35 AM Nick Desaulniers
wrote:
>
> This reverts commit 6a9dc5fd6170 ("lib: Revert use of fallthrough
> pseudo-keyword in lib/")
>
> Now that we can build arch/powerpc/boot/ free of -Wimplicit-fallthrough,
> re-enable these fixes for lib/.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/236
> Signed-off-by: Nick Desaulniers
Looks fine on visual inspection:
Reviewed-by: Miguel Ojeda
Cheers,
Miguel
Re: [PATCH 1/3] powerpc: boot: include compiler_attributes.h
On Mon, Nov 16, 2020 at 5:35 AM Nick Desaulniers wrote: > > It was also noted in 6a9dc5fd6170 that we could -D__KERNEL__ and > -include compiler_types.h like the main kernel does, though testing that > produces a whole sea of warnings to cleanup. This approach is minimally > invasive. I would add a comment noting this as a reminder -- it also helps to entice a cleanup. Acked-by: Miguel Ojeda Cheers, Miguel
Re: [PATCH 2/3] Revert "lib: Revert use of fallthrough pseudo-keyword in lib/"
On Mon, Nov 16, 2020 at 7:26 AM Gustavo A. R. Silva wrote: > > Reviewed-by: Gustavo A. R. Silva .org :-) Cheers, Miguel
Re: [PATCH] treewide: Convert macro and uses of __section(foo) to __section("foo")
On Fri, Oct 23, 2020 at 10:03 AM Joe Perches wrote: > > Thanks Miguel, but IMO it doesn't need time in next. You're welcome! It never hurts to keep things for a bit there. > Applying it just before an rc1 minimizes conflicts. There shouldn't be many conflicts after -rc1. The amount of changes is reasonable too, so no need to apply the script directly. In any case, if you prefer that Linus picks it up himself right away for this -rc1, it looks good to me (with the caveat that it isn't tested): Reviewed-by: Miguel Ojeda Cheers, Miguel
Re: [PATCH] treewide: Convert macro and uses of __section(foo) to __section("foo")
On Thu, Oct 22, 2020 at 4:36 AM Joe Perches wrote:
>
> Use a more generic form for __section that requires quotes to avoid
> complications with clang and gcc differences.
I performed visual inspection (one by one...) and the only thing I saw
is that sometimes the `__attribute__` has a whitespace afterwards and
sometimes it doesn't, same for the commas inside, e.g.:
- __used __attribute__((section(".modinfo"), unused, aligned(1))) \
+ __used __section(".modinfo") __attribute__((unused, aligned(1))) \
and:
-__attribute__ ((unused,__section__ ("__param"),aligned(sizeof(void * \
+__section("__param") __attribute__ ((unused, aligned(sizeof(void * \
I think the patch tries to follow the style of the replaced line, but
for the commas in this last case it didn't. Anyway, it is not
important.
I can pick it up in my queue along with the __alias one and keep it
for a few weeks in -next.
Cheers,
Miguel
Re: [RFC PATCH next-20200930] treewide: Convert macro and uses of __section(foo) to __section("foo")
Hi Joe, On Thu, Oct 1, 2020 at 12:56 AM Joe Perches wrote: > > So I installed the powerpc cross compiler, and > nope, that doesn't work, it makes a mess. Thanks a lot for reviving the script and sending the treewide cleanup! > So it looks like the best option is to exclude these > 2 files from conversion. Agreed. Nevertheless, is there any reason arch/powerpc/* should not be compiling cleanly with compiler.h? (CC'ing the rest of the PowerPC reviewers and ML). Cheers, Miguel
Re: [PATCH v3 10/17] memblock: reduce number of parameters in for_each_mem_range()
On Tue, Aug 18, 2020 at 5:19 PM Mike Rapoport wrote: > > .clang-format | 2 ++ For the .clang-format bit: Acked-by: Miguel Ojeda Cheers, Miguel
Re: [PATCH v2 16/17] memblock: implement for_each_reserved_mem_region() using __next_mem_region()
On Sun, Aug 2, 2020 at 6:40 PM Mike Rapoport wrote: > > .clang-format| 2 +- The .clang-format bit: Acked-by: Miguel Ojeda Cheers, Miguel
Re: [PATCH v2 17/17] memblock: use separate iterators for memory and reserved regions
On Sun, Aug 2, 2020 at 6:41 PM Mike Rapoport wrote: > > .clang-format | 3 ++- The .clang-format bit: Acked-by: Miguel Ojeda Cheers, Miguel
Re: [PATCH 10/16] powerpc: prefer __section and __printf from compiler_attributes.h
Hi Michael, On Wed, Apr 1, 2020 at 2:53 PM Michael Ellerman wrote: > > On Mon, 2019-08-12 at 21:50:43 UTC, Nick Desaulniers wrote: > > Reported-by: Sedat Dilek > > Suggested-by: Josh Poimboeuf > > Signed-off-by: Nick Desaulniers > > Applied to powerpc next, thanks. Missed this one from August, thanks Nick for this cleanup! Michael, you already picked it up, but you may have my: Acked-by: Miguel Ojeda Cheers, Miguel
Re: [PATCH RFC 4/5] rculist: Remove hlist_for_each_entry_rcu_notrace since no users
On Sat, May 25, 2019 at 1:50 AM Joel Fernandes (Google) wrote: > > The series removes all users of the API and with this patch, the API > itself. > > Signed-off-by: Joel Fernandes (Google) > --- > .clang-format | 1 - Ack for clang-format, and thanks for removing it there too! :-) Cheers, Miguel
Re: [PATCH] Documentation: fix spelling mistake, EACCESS -> EACCES
On Fri, Oct 26, 2018 at 8:53 PM Miguel Ojeda wrote: > > On Fri, Oct 26, 2018 at 8:40 PM Matthew Wilcox wrote: > > > > On Fri, Oct 26, 2018 at 08:20:12PM +0200, Miguel Ojeda wrote: > > > On Fri, Oct 26, 2018 at 7:27 PM Colin King > > > wrote: > > > > > > > > From: Colin Ian King > > > > > > > > Trivial fix to a spelling mistake of the error access name EACCESS, > > > > rename to EACCES > > > > > > ? It is not a typo, it is the name of the error (POSIX). Same thing > > > for the rest of the patches. > > > > Are you sure? From open(2): > > > >EACCES The requested access to the file is not allowed, or search > > per‐ > > mission is denied for one of the directories in the path > > prefix > > of pathname, or the file did not exist yet and write access > > to > > the parent directory is not allowed. (See also > > path_resolu‐ > > tion(7).) > > > > include/uapi/asm-generic/errno-base.h:#define EACCES 13 /* > > Permission denied */ > > I thought you were doing the reverse change. Never mind! :-) > > (Btw, the POSIX reference is > http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/errno.h.html#tag_13_09, > in case you want to include it or are curious) Sorry Matthew, thought I was answering to Colin. I should go to rest. Cheers, Miguel
Re: [PATCH] Documentation: fix spelling mistake, EACCESS -> EACCES
On Fri, Oct 26, 2018 at 8:40 PM Matthew Wilcox wrote: > > On Fri, Oct 26, 2018 at 08:20:12PM +0200, Miguel Ojeda wrote: > > On Fri, Oct 26, 2018 at 7:27 PM Colin King wrote: > > > > > > From: Colin Ian King > > > > > > Trivial fix to a spelling mistake of the error access name EACCESS, > > > rename to EACCES > > > > ? It is not a typo, it is the name of the error (POSIX). Same thing > > for the rest of the patches. > > Are you sure? From open(2): > >EACCES The requested access to the file is not allowed, or search per‐ > mission is denied for one of the directories in the path prefix > of pathname, or the file did not exist yet and write access to > the parent directory is not allowed. (See also path_resolu‐ > tion(7).) > > include/uapi/asm-generic/errno-base.h:#define EACCES 13 /* > Permission denied */ I thought you were doing the reverse change. Never mind! :-) (Btw, the POSIX reference is http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/errno.h.html#tag_13_09, in case you want to include it or are curious) Cheers, Miguel
Re: [PATCH] Documentation: fix spelling mistake, EACCESS -> EACCES
On Fri, Oct 26, 2018 at 7:27 PM Colin King wrote: > > From: Colin Ian King > > Trivial fix to a spelling mistake of the error access name EACCESS, > rename to EACCES ? It is not a typo, it is the name of the error (POSIX). Same thing for the rest of the patches. Cheers, Miguel
