* linux-next: manual merge of the rust tree with Linus' tree
@ 2022-07-13 10:34 Stephen Rothwell
2022-07-13 10:50 ` Miguel Ojeda
2022-07-13 11:39 ` Peter Zijlstra
0 siblings, 2 replies; 19+ messages in thread
From: Stephen Rothwell @ 2022-07-13 10:34 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Adam Bratschi-Kaye, Alex Gaynor, Antonio Terceiro, Boqun Feng,
Boris-Chengbiao Zhou, Borislav Petkov, Daniel Xu,
Dariusz Sosnowski, David Gow, Douglas Su, Finn Behrens, Gary Guo,
Linux Kernel Mailing List, Linux Next Mailing List,
Michael Ellerman, Miguel Cano, Miguel Ojeda,
Peter Zijlstra (Intel),
Sven Van Asbroeck, Wedson Almeida Filho
[-- Attachment #1: Type: text/plain, Size: 1242 bytes --]
Hi all,
Today's linux-next merge of the rust tree got a conflict in:
arch/x86/Makefile
between commit:
f43b9876e857 ("x86/retbleed: Add fine grained Kconfig knobs")
from Linus' tree and commit:
0ea4b9a1bece ("Kbuild: add Rust support")
from the rust tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/x86/Makefile
index 1f40dad30d50,5ac9b324751d..000000000000
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@@ -21,12 -21,8 +21,13 @@@ ifdef CONFIG_CC_IS_CLAN
RETPOLINE_CFLAGS := -mretpoline-external-thunk
RETPOLINE_VDSO_CFLAGS := -mretpoline
endif
+ RETPOLINE_RUSTFLAGS := -Ctarget-feature=+retpoline-external-thunk
+ifdef CONFIG_RETHUNK
+RETHUNK_CFLAGS := -mfunction-return=thunk-extern
+RETPOLINE_CFLAGS += $(RETHUNK_CFLAGS)
+endif
+
export RETPOLINE_CFLAGS
export RETPOLINE_VDSO_CFLAGS
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: linux-next: manual merge of the rust tree with Linus' tree
2022-07-13 10:34 linux-next: manual merge of the rust tree with Linus' tree Stephen Rothwell
@ 2022-07-13 10:50 ` Miguel Ojeda
2022-07-13 11:39 ` Peter Zijlstra
1 sibling, 0 replies; 19+ messages in thread
From: Miguel Ojeda @ 2022-07-13 10:50 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Adam Bratschi-Kaye, Alex Gaynor, Antonio Terceiro, Boqun Feng,
Boris-Chengbiao Zhou, Borislav Petkov, Daniel Xu,
Dariusz Sosnowski, David Gow, Douglas Su, Finn Behrens, Gary Guo,
Linux Kernel Mailing List, Linux Next Mailing List,
Michael Ellerman, Miguel Cano, Miguel Ojeda,
Peter Zijlstra (Intel),
Sven Van Asbroeck, Wedson Almeida Filho
Hi Stephen,
On Wed, Jul 13, 2022 at 12:34 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the rust tree got a conflict in:
>
> arch/x86/Makefile
Thank you, looks good to me.
Cheers,
Miguel
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: linux-next: manual merge of the rust tree with Linus' tree
2022-07-13 10:34 linux-next: manual merge of the rust tree with Linus' tree Stephen Rothwell
2022-07-13 10:50 ` Miguel Ojeda
@ 2022-07-13 11:39 ` Peter Zijlstra
2022-07-15 1:13 ` Miguel Ojeda
1 sibling, 1 reply; 19+ messages in thread
From: Peter Zijlstra @ 2022-07-13 11:39 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Miguel Ojeda, Adam Bratschi-Kaye, Alex Gaynor, Antonio Terceiro,
Boqun Feng, Boris-Chengbiao Zhou, Borislav Petkov, Daniel Xu,
Dariusz Sosnowski, David Gow, Douglas Su, Finn Behrens, Gary Guo,
Linux Kernel Mailing List, Linux Next Mailing List,
Michael Ellerman, Miguel Cano, Miguel Ojeda, Sven Van Asbroeck,
Wedson Almeida Filho
On Wed, Jul 13, 2022 at 08:34:09PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the rust tree got a conflict in:
>
> arch/x86/Makefile
>
> between commit:
>
> f43b9876e857 ("x86/retbleed: Add fine grained Kconfig knobs")
>
> from Linus' tree and commit:
>
> 0ea4b9a1bece ("Kbuild: add Rust support")
>
> from the rust tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc arch/x86/Makefile
> index 1f40dad30d50,5ac9b324751d..000000000000
> --- a/arch/x86/Makefile
> +++ b/arch/x86/Makefile
> @@@ -21,12 -21,8 +21,13 @@@ ifdef CONFIG_CC_IS_CLAN
> RETPOLINE_CFLAGS := -mretpoline-external-thunk
> RETPOLINE_VDSO_CFLAGS := -mretpoline
> endif
> + RETPOLINE_RUSTFLAGS := -Ctarget-feature=+retpoline-external-thunk
>
> +ifdef CONFIG_RETHUNK
> +RETHUNK_CFLAGS := -mfunction-return=thunk-extern
> +RETPOLINE_CFLAGS += $(RETHUNK_CFLAGS)
> +endif
Does Rust have the equivalent of -mfunction-return=thunk-extern ?
Related, how does Rust deal with all the various CC_HAS_ Kconfig stuff?
What if C has the relevant option but Rust does not; then we must not
have the feature enabled or there will be a mis-match.
Do we now have to litter everythign with RUSTC_HAS_ ?
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: linux-next: manual merge of the rust tree with Linus' tree
2022-07-13 11:39 ` Peter Zijlstra
@ 2022-07-15 1:13 ` Miguel Ojeda
2022-07-15 9:01 ` Peter Zijlstra
0 siblings, 1 reply; 19+ messages in thread
From: Miguel Ojeda @ 2022-07-15 1:13 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Stephen Rothwell, Adam Bratschi-Kaye, Alex Gaynor,
Antonio Terceiro, Boqun Feng, Boris-Chengbiao Zhou,
Borislav Petkov, Daniel Xu, Dariusz Sosnowski, David Gow,
Douglas Su, Finn Behrens, Gary Guo, Linux Kernel Mailing List,
Linux Next Mailing List, Michael Ellerman, Miguel Cano,
Miguel Ojeda, Sven Van Asbroeck, Wedson Almeida Filho,
Nick Desaulniers
On Wed, Jul 13, 2022 at 1:40 PM Peter Zijlstra <peterz@infradead.org> wrote:
>
> Does Rust have the equivalent of -mfunction-return=thunk-extern ?
While GCC has had it for a while, Nick just landed 2 days ago the
X86ReturnThunks pass in LLVM, so it will take some time to arrive in
rustc.
I have naively backported it to rustc and hacked it so that I set the
LLVM attribute for all functions, and I am getting the rets replaced
in Rust functions, e.g.
(gdb) disassemble a::f
Dump of assembler code for function _ZN1a1f17hdc6112b1b4a4fe99E:
...
0x0000000000008a1f <+31>: pop %rbp
0x0000000000008a20 <+32>: jmp 0x8ce0 <__x86_return_thunk>
A trivial userspace program that counts the times that it goes through
the return thunk also appears to work.
> Related, how does Rust deal with all the various CC_HAS_ Kconfig stuff?
> What if C has the relevant option but Rust does not; then we must not
> have the feature enabled or there will be a mis-match.
I guess that would depend on the particular option: whether it applies
to Rust at all, whether it creates an incompatibility or not, etc.
> Do we now have to litter everythign with RUSTC_HAS_ ?
Why? Only a single `rustc` version is targeted at the moment, so it is
possible to statically know what it supports.
And later on, when we can declare a minimum version or when a second
compiler is ready, sure, we may need to have options depending on what
we want to do. Why would that be a problem?
Cheers,
Miguel
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: linux-next: manual merge of the rust tree with Linus' tree
2022-07-15 1:13 ` Miguel Ojeda
@ 2022-07-15 9:01 ` Peter Zijlstra
2022-07-15 11:01 ` Miguel Ojeda
0 siblings, 1 reply; 19+ messages in thread
From: Peter Zijlstra @ 2022-07-15 9:01 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Stephen Rothwell, Adam Bratschi-Kaye, Alex Gaynor,
Antonio Terceiro, Boqun Feng, Boris-Chengbiao Zhou,
Borislav Petkov, Daniel Xu, Dariusz Sosnowski, David Gow,
Douglas Su, Finn Behrens, Gary Guo, Linux Kernel Mailing List,
Linux Next Mailing List, Michael Ellerman, Miguel Cano,
Miguel Ojeda, Sven Van Asbroeck, Wedson Almeida Filho,
Nick Desaulniers, samitolvanen, joao, keescook
On Fri, Jul 15, 2022 at 03:13:17AM +0200, Miguel Ojeda wrote:
> On Wed, Jul 13, 2022 at 1:40 PM Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > Does Rust have the equivalent of -mfunction-return=thunk-extern ?
>
> While GCC has had it for a while, Nick just landed 2 days ago the
> X86ReturnThunks pass in LLVM, so it will take some time to arrive in
> rustc.
>
> I have naively backported it to rustc and hacked it so that I set the
> LLVM attribute for all functions, and I am getting the rets replaced
> in Rust functions, e.g.
>
> (gdb) disassemble a::f
> Dump of assembler code for function _ZN1a1f17hdc6112b1b4a4fe99E:
> ...
> 0x0000000000008a1f <+31>: pop %rbp
> 0x0000000000008a20 <+32>: jmp 0x8ce0 <__x86_return_thunk>
>
> A trivial userspace program that counts the times that it goes through
> the return thunk also appears to work.
Ok; I'm supposing that'll be sorted by the time rust happens.
> > Related, how does Rust deal with all the various CC_HAS_ Kconfig stuff?
> > What if C has the relevant option but Rust does not; then we must not
> > have the feature enabled or there will be a mis-match.
>
> I guess that would depend on the particular option: whether it applies
> to Rust at all, whether it creates an incompatibility or not, etc.
There's quite a few things affecting code-gen; rustc not using the exact
same compiler arguments is going to create a head-ache.
> > Do we now have to litter everythign with RUSTC_HAS_ ?
>
> Why? Only a single `rustc` version is targeted at the moment, so it is
> possible to statically know what it supports.
But does it support everything clang does now? If not, you need to
express that in Kconfig and disable the features it doesn't carry. So
even for a single rustc version will you need RUSTC_HAS_ stuff.
What about CC_HAS_IBT? Can rust generate sane IBT code? Current next
doesn't seem to have anything there, suggesting I can't build an IBT
enabled kernel if rust is on (or rather, it'll build, but it'll also
burn at boot).
What if LLVM were to grow -mindirect-branch-cs-prefix (please!) and rust
doesn't have it? Same if LLVM finally stops generating those pesky
conditional tail-calls, will rust continue emitting them?
I'm thinking of the kCFI work, will rustc support that from day 1 or
will that only work when not building any rust.
There being a single rustc is not a single target, every compiler
version grows (and breaks) new features. And for some reason we seem to
change the actual kernel calling convetion a lot of late :/
Currently we can support a feature when one compiler version supports it
(either gcc or clang), but the moment rust becomes a mandatory part of
the kernel build (and I dread that day) we'll need to
wait/update/wrangle at least two different toolchains to implement the
feature in a consistent manner before we can use it.
I also don't see any RUST -mfentry support...
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: linux-next: manual merge of the rust tree with Linus' tree
2022-07-15 9:01 ` Peter Zijlstra
@ 2022-07-15 11:01 ` Miguel Ojeda
0 siblings, 0 replies; 19+ messages in thread
From: Miguel Ojeda @ 2022-07-15 11:01 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Stephen Rothwell, Adam Bratschi-Kaye, Alex Gaynor,
Antonio Terceiro, Boqun Feng, Boris-Chengbiao Zhou,
Borislav Petkov, Daniel Xu, Dariusz Sosnowski, David Gow,
Douglas Su, Finn Behrens, Gary Guo, Linux Kernel Mailing List,
Linux Next Mailing List, Michael Ellerman, Miguel Cano,
Miguel Ojeda, Sven Van Asbroeck, Wedson Almeida Filho,
Nick Desaulniers, Sami Tolvanen, joao, Kees Cook, Arthur Cohen,
Antoni Boucher, Josh Triplett, Philip Herron
On Fri, Jul 15, 2022 at 11:02 AM Peter Zijlstra <peterz@infradead.org> wrote:
>
> Ok; I'm supposing that'll be sorted by the time rust happens.
No, it most likely won't, and I don't see why you would assume that,
or why we would want to block Rust support on that.
> There's quite a few things affecting code-gen; rustc not using the exact
> same compiler arguments is going to create a head-ache.
Yes, a GCC-like driver in `rustc` would be nice for projects like the
kernel. The GCC Rust project will support GCC-like flags, as far as I
understand.
(Cc'ing Antoni, Arthur, Josh, Philip).
> But does it support everything clang does now? If not, you need to
> express that in Kconfig and disable the features it doesn't carry. So
> even for a single rustc version will you need RUSTC_HAS_ stuff.
You could still make everything work around the `RUST` symbol, no need
to "litter everything" (as you said) just yet. :)
> What about CC_HAS_IBT? Can rust generate sane IBT code? Current next
> doesn't seem to have anything there, suggesting I can't build an IBT
> enabled kernel if rust is on (or rather, it'll build, but it'll also
> burn at boot).
>
> What if LLVM were to grow -mindirect-branch-cs-prefix (please!) and rust
> doesn't have it? Same if LLVM finally stops generating those pesky
> conditional tail-calls, will rust continue emitting them?
>
> I'm thinking of the kCFI work, will rustc support that from day 1 or
> will that only work when not building any rust.
>
> There being a single rustc is not a single target, every compiler
> version grows (and breaks) new features. And for some reason we seem to
> change the actual kernel calling convetion a lot of late :/
>
> Currently we can support a feature when one compiler version supports it
> (either gcc or clang), but the moment rust becomes a mandatory part of
> the kernel build (and I dread that day) we'll need to
> wait/update/wrangle at least two different toolchains to implement the
> feature in a consistent manner before we can use it.
>
> I also don't see any RUST -mfentry support...
I think you are getting way too ahead.
Merging the Rust support now is meant to evaluate whether Rust _as a
language_ makes sense for the kernel, whether we can write enough % of
kernel code in the safe subset (and whether that brings enough
advantages), etc.
It is not meant to provide "day 1 support" for everything. In fact,
getting merged now is what will allow to grow support for everything
needed everywhere: not just in terms of compiler flags, faster
integration of LLVM codegen/mitigation features in `rustc`, new
frontends and backends (`rustc_codegen_gcc` and GCC Rust), etc.; but
also within the kernel, in terms of safe abstractions for kernel APIs,
kernel maintainers' experience with Rust, etc.
Cheers,
Miguel
^ permalink raw reply [flat|nested] 19+ messages in thread
* linux-next: manual merge of the rust tree with Linus' tree
@ 2022-10-04 8:05 Stephen Rothwell
0 siblings, 0 replies; 19+ messages in thread
From: Stephen Rothwell @ 2022-10-04 8:05 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Adam Bratschi-Kaye, Alex Gaynor, Boris-Chengbiao Zhou, Daniel Xu,
Finn Behrens, Gary Guo, Jonathan Corbet, Julian Merkle,
Linux Kernel Mailing List, Linux Next Mailing List,
Michael Ellerman, Miguel Ojeda, Sven Van Asbroeck,
Wedson Almeida Filho, Wei Liu, Wu XiangCheng, Yuki Okushi
[-- Attachment #1: Type: text/plain, Size: 6020 bytes --]
Hi all,
Today's linux-next merge of the rust tree got a conflict in:
Documentation/index.rst
between commit:
0c7b4366f1ab ("docs: Rewrite the front page")
from the origin tree and commit:
d07479b211b7 ("docs: add Rust documentation")
from the rust tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc Documentation/index.rst
index 85eab6e990ab,00722aa20cd7..000000000000
--- a/Documentation/index.rst
+++ b/Documentation/index.rst
@@@ -12,84 -18,134 +12,85 @@@ documents into a coherent whole. Pleas
documentation are welcome; join the linux-doc list at vger.kernel.org if
you want to help out.
-Licensing documentation
------------------------
+Working with the development community
+--------------------------------------
-The following describes the license of the Linux kernel source code
-(GPLv2), how to properly mark the license of individual files in the source
-tree, as well as links to the full license text.
-
-* :ref:`kernel_licensing`
-
-User-oriented documentation
----------------------------
-
-The following manuals are written for *users* of the kernel — those who are
-trying to get it to work optimally on a given system.
+The essential guides for interacting with the kernel's development
+community and getting your work upstream.
.. toctree::
- :maxdepth: 2
-
- admin-guide/index
- kbuild/index
-
-Firmware-related documentation
-------------------------------
-The following holds information on the kernel's expectations regarding the
-platform firmwares.
+ :maxdepth: 1
-.. toctree::
- :maxdepth: 2
+ process/development-process
+ process/submitting-patches
+ Code of conduct <process/code-of-conduct>
+ maintainer/index
+ All development-process docs <process/index>
- firmware-guide/index
- devicetree/index
-Application-developer documentation
------------------------------------
+Internal API manuals
+--------------------
-The user-space API manual gathers together documents describing aspects of
-the kernel interface as seen by application developers.
+Manuals for use by developers working to interface with the rest of the
+kernel.
.. toctree::
- :maxdepth: 2
-
- userspace-api/index
+ :maxdepth: 1
+ core-api/index
+ driver-api/index
+ subsystem-apis
+ Locking in the kernel <locking/index>
-Introduction to kernel development
-----------------------------------
+Development tools and processes
+-------------------------------
-These manuals contain overall information about how to develop the kernel.
-The kernel community is quite large, with thousands of developers
-contributing over the course of a year. As with any large community,
-knowing how things are done will make the process of getting your changes
-merged much easier.
+Various other manuals with useful information for all kernel developers.
.. toctree::
- :maxdepth: 2
+ :maxdepth: 1
- process/index
- dev-tools/index
+ process/license-rules
doc-guide/index
+ dev-tools/index
+ dev-tools/testing-overview
kernel-hacking/index
trace/index
- maintainer/index
fault-injection/index
livepatch/index
+ rust/index
-Kernel API documentation
-------------------------
+User-oriented documentation
+---------------------------
-These books get into the details of how specific kernel subsystems work
-from the point of view of a kernel developer. Much of the information here
-is taken directly from the kernel source, with supplemental material added
-as needed (or at least as we managed to add it — probably *not* all that is
-needed).
+The following manuals are written for *users* of the kernel — those who are
+trying to get it to work optimally on a given system and application
+developers seeking information on the kernel's user-space APIs.
.. toctree::
- :maxdepth: 2
+ :maxdepth: 1
- driver-api/index
- core-api/index
- locking/index
- accounting/index
- block/index
- cdrom/index
- cpu-freq/index
- fb/index
- fpga/index
- hid/index
- i2c/index
- iio/index
- isdn/index
- infiniband/index
- leds/index
- netlabel/index
- networking/index
- pcmcia/index
- power/index
- target/index
- timers/index
- spi/index
- w1/index
- watchdog/index
- virt/index
- input/index
- hwmon/index
- gpu/index
- security/index
- sound/index
- crypto/index
- filesystems/index
- mm/index
- bpf/index
- usb/index
- PCI/index
- scsi/index
- misc-devices/index
- scheduler/index
- mhi/index
- peci/index
-
-Architecture-agnostic documentation
------------------------------------
+ admin-guide/index
+ The kernel build system <kbuild/index>
+ admin-guide/reporting-issues.rst
+ User-space tools <tools/index>
+ userspace-api/index
+
+See also: the `Linux man pages <https://www.kernel.org/doc/man-pages/>`_,
+which are kept separately from the kernel's own documentation.
+
+Firmware-related documentation
+------------------------------
+The following holds information on the kernel's expectations regarding the
+platform firmwares.
.. toctree::
- :maxdepth: 2
+ :maxdepth: 1
+
+ firmware-guide/index
+ devicetree/index
- asm-annotations
Architecture-specific documentation
-----------------------------------
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread* linux-next: manual merge of the rust tree with Linus' tree
@ 2022-09-12 7:24 Stephen Rothwell
0 siblings, 0 replies; 19+ messages in thread
From: Stephen Rothwell @ 2022-09-12 7:24 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Daniel Bristot de Oliveira, Linux Kernel Mailing List,
Linux Next Mailing List, Steven Rostedt (Google)
[-- Attachment #1: Type: text/plain, Size: 1955 bytes --]
Hi all,
Today's linux-next merge of the rust tree got a conflict in:
MAINTAINERS
between commit:
fa4b9df00af4 ("MAINTAINERS: Add Runtime Verification (RV) entry")
from Linus' tree and commit:
fa4b9df00af4 ("MAINTAINERS: Add Runtime Verification (RV) entry")
from the rust tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc MAINTAINERS
index cfb38ad66cfc,263ff9abca0b..000000000000
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@@ -17806,17 -17477,24 +17806,35 @@@ L: linux-rdma@vger.kernel.or
S: Maintained
F: drivers/infiniband/ulp/rtrs/
+RUNTIME VERIFICATION (RV)
+M: Daniel Bristot de Oliveira <bristot@kernel.org>
+M: Steven Rostedt <rostedt@goodmis.org>
+L: linux-trace-devel@vger.kernel.org
+S: Maintained
+F: Documentation/trace/rv/
+F: include/linux/rv.h
+F: include/rv/
+F: kernel/trace/rv/
+F: tools/verification/
+
+ RUST
+ M: Miguel Ojeda <ojeda@kernel.org>
+ M: Alex Gaynor <alex.gaynor@gmail.com>
+ M: Wedson Almeida Filho <wedsonaf@google.com>
+ R: Boqun Feng <boqun.feng@gmail.com>
+ R: Gary Guo <gary@garyguo.net>
+ R: Björn Roy Baron <bjorn3_gh@protonmail.com>
+ L: rust-for-linux@vger.kernel.org
+ S: Supported
+ W: https://github.com/Rust-for-Linux/linux
+ B: https://github.com/Rust-for-Linux/linux/issues
+ T: git https://github.com/Rust-for-Linux/linux.git rust-next
+ F: Documentation/rust/
+ F: rust/
+ F: samples/rust/
+ F: scripts/*rust*
+ K: \b(?i:rust)\b
+
RXRPC SOCKETS (AF_RXRPC)
M: David Howells <dhowells@redhat.com>
M: Marc Dionne <marc.dionne@auristor.com>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread* linux-next: manual merge of the rust tree with Linus' tree
@ 2022-07-25 8:41 Stephen Rothwell
2022-07-25 8:52 ` Miguel Ojeda
0 siblings, 1 reply; 19+ messages in thread
From: Stephen Rothwell @ 2022-07-25 8:41 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Adam Bratschi-Kaye, Alex Gaynor, Antonio Terceiro, Boqun Feng,
Boris-Chengbiao Zhou, Daniel Xu, Dariusz Sosnowski, David Gow,
Douglas Su, Finn Behrens, Gary Guo, Josh Poimboeuf,
Linux Kernel Mailing List, Linux Next Mailing List,
Michael Ellerman, Miguel Cano, Miguel Ojeda, Peter Zijlstra,
Sven Van Asbroeck, Wedson Almeida Filho
[-- Attachment #1: Type: text/plain, Size: 1267 bytes --]
Hi all,
Today's linux-next merge of the rust tree got a conflict in:
arch/x86/Makefile
between commit:
efc72a665a61 ("lkdtm: Disable return thunks in rodata.c")
from Linus' tree and commit:
0ea4b9a1bece ("Kbuild: add Rust support")
from the rust tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/x86/Makefile
index 7854685c5f25,5ac9b324751d..000000000000
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@@ -21,13 -21,8 +21,15 @@@ ifdef CONFIG_CC_IS_CLAN
RETPOLINE_CFLAGS := -mretpoline-external-thunk
RETPOLINE_VDSO_CFLAGS := -mretpoline
endif
+
+ifdef CONFIG_RETHUNK
+RETHUNK_CFLAGS := -mfunction-return=thunk-extern
+RETPOLINE_CFLAGS += $(RETHUNK_CFLAGS)
+endif
+
+ RETPOLINE_RUSTFLAGS := -Ctarget-feature=+retpoline-external-thunk
+
+export RETHUNK_CFLAGS
export RETPOLINE_CFLAGS
export RETPOLINE_VDSO_CFLAGS
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: linux-next: manual merge of the rust tree with Linus' tree
2022-07-25 8:41 Stephen Rothwell
@ 2022-07-25 8:52 ` Miguel Ojeda
0 siblings, 0 replies; 19+ messages in thread
From: Miguel Ojeda @ 2022-07-25 8:52 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Adam Bratschi-Kaye, Alex Gaynor, Antonio Terceiro, Boqun Feng,
Boris-Chengbiao Zhou, Daniel Xu, Dariusz Sosnowski, David Gow,
Douglas Su, Finn Behrens, Gary Guo, Josh Poimboeuf,
Linux Kernel Mailing List, Linux Next Mailing List,
Michael Ellerman, Miguel Cano, Miguel Ojeda, Peter Zijlstra,
Sven Van Asbroeck, Wedson Almeida Filho
On Mon, Jul 25, 2022 at 10:41 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the rust tree got a conflict in:
>
> arch/x86/Makefile
Looks fine to me (I did it a bit differently on my side, but it does
not matter).
Thanks!
Cheers,
Miguel
^ permalink raw reply [flat|nested] 19+ messages in thread
* linux-next: manual merge of the rust tree with Linus' tree
@ 2021-12-10 18:18 broonie
0 siblings, 0 replies; 19+ messages in thread
From: broonie @ 2021-12-10 18:18 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Alex Gaynor, Boqun Feng, Gary Guo, Linux Kernel Mailing List,
Linux Next Mailing List, Miguel Ojeda, Sasha Levin,
Wedson Almeida Filho
Hi all,
Today's linux-next merge of the rust tree got a conflict in:
tools/include/linux/lockdep.h
between commit:
3a49cc22d31ec ("tools/lib/lockdep: drop leftover liblockdep headers")
from the origin tree and commit:
ab4cc3d9c564d ("kallsyms: increase maximum kernel symbol length to 512")
from the rust tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
^ permalink raw reply [flat|nested] 19+ messages in thread* linux-next: manual merge of the rust tree with Linus' tree
@ 2021-11-03 3:19 Stephen Rothwell
2021-11-03 10:30 ` Miguel Ojeda
0 siblings, 1 reply; 19+ messages in thread
From: Stephen Rothwell @ 2021-11-03 3:19 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Adam Bratschi-Kaye, Alex Gaynor, Andrii Nakryiko,
Antonio Terceiro, Boqun Feng, Boris-Chengbiao Zhou, Daniel Xu,
Dariusz Sosnowski, Douglas Su, Finn Behrens, Gary Guo, Jiri Olsa,
Jiri Olsa, Linux Kernel Mailing List, Linux Next Mailing List,
Michael Ellerman, Miguel Ojeda, Sven Van Asbroeck,
Wedson Almeida Filho
[-- Attachment #1: Type: text/plain, Size: 3072 bytes --]
Hi all,
Today's linux-next merge of the rust tree got conflicts in:
Makefile
scripts/Makefile.modfinal
between commit:
9741e07ece7c ("kbuild: Unify options for BTF generation for vmlinux and modules")
from Linus' tree and commit:
fcd48fa27403 ("Kbuild: add Rust support")
from the rust tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc Makefile
index 8581ffca7f96,c4dd2c6b55e4..000000000000
--- a/Makefile
+++ b/Makefile
@@@ -533,10 -572,10 +574,11 @@@ export KBUILD_HOSTCXXFLAGS KBUILD_HOSTL
export KBUILD_CPPFLAGS NOSTDINC_FLAGS LINUXINCLUDE OBJCOPYFLAGS KBUILD_LDFLAGS
export KBUILD_CFLAGS CFLAGS_KERNEL CFLAGS_MODULE
+ export KBUILD_RUST_TARGET KBUILD_RUSTFLAGS RUSTFLAGS_KERNEL RUSTFLAGS_MODULE
export KBUILD_AFLAGS AFLAGS_KERNEL AFLAGS_MODULE
- export KBUILD_AFLAGS_MODULE KBUILD_CFLAGS_MODULE KBUILD_LDFLAGS_MODULE
- export KBUILD_AFLAGS_KERNEL KBUILD_CFLAGS_KERNEL
+ export KBUILD_AFLAGS_MODULE KBUILD_CFLAGS_MODULE KBUILD_RUSTFLAGS_MODULE KBUILD_LDFLAGS_MODULE
+ export KBUILD_AFLAGS_KERNEL KBUILD_CFLAGS_KERNEL KBUILD_RUSTFLAGS_KERNEL
+export PAHOLE_FLAGS
# Files to ignore in find ... statements
@@@ -1089,9 -1203,12 +1167,13 @@@ export MODORDER := $(extmod_prefix)modu
export MODULES_NSDEPS := $(extmod_prefix)modules.nsdeps
ifeq ($(KBUILD_EXTMOD),)
-core-y += kernel/ certs/ mm/ fs/ ipc/ security/ crypto/ block/
+core-y += kernel/ certs/ mm/ fs/ ipc/ security/ crypto/
+core-$(CONFIG_BLOCK) += block/
+ ifdef CONFIG_RUST
+ core-y += rust/
+ endif
+
vmlinux-dirs := $(patsubst %/,%,$(filter %/, \
$(core-y) $(core-m) $(drivers-y) $(drivers-m) \
$(libs-y) $(libs-m)))
diff --cc scripts/Makefile.modfinal
index 7f39599e9fae,c0842e999a75..000000000000
--- a/scripts/Makefile.modfinal
+++ b/scripts/Makefile.modfinal
@@@ -39,11 -39,12 +39,12 @@@ quiet_cmd_ld_ko_o = LD [M] $
quiet_cmd_btf_ko = BTF [M] $@
cmd_btf_ko = \
- if [ -f vmlinux ]; then \
- LLVM_OBJCOPY="$(OBJCOPY)" $(PAHOLE) -J $(PAHOLE_FLAGS) --btf_base vmlinux $@; \
- $(RESOLVE_BTFIDS) -b vmlinux $@; \
- else \
+ if [ ! -f vmlinux ]; then \
printf "Skipping BTF generation for %s due to unavailability of vmlinux\n" $@ 1>&2; \
+ elif $(srctree)/scripts/is_rust_module.sh $@; then \
+ printf "Skipping BTF generation for %s because it's a Rust module\n" $@ 1>&2; \
+ else \
- LLVM_OBJCOPY="$(OBJCOPY)" $(PAHOLE) -J --btf_base vmlinux $@; \
++ LLVM_OBJCOPY="$(OBJCOPY)" $(PAHOLE) -J $(PAHOLE_FLAGS) --btf_base vmlinux $@; \
fi;
# Same as newer-prereqs, but allows to exclude specified extra dependencies
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: linux-next: manual merge of the rust tree with Linus' tree
2021-11-03 3:19 Stephen Rothwell
@ 2021-11-03 10:30 ` Miguel Ojeda
2021-11-03 21:01 ` Stephen Rothwell
0 siblings, 1 reply; 19+ messages in thread
From: Miguel Ojeda @ 2021-11-03 10:30 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Adam Bratschi-Kaye, Alex Gaynor, Andrii Nakryiko,
Antonio Terceiro, Boqun Feng, Boris-Chengbiao Zhou, Daniel Xu,
Dariusz Sosnowski, Douglas Su, Finn Behrens, Gary Guo, Jiri Olsa,
Jiri Olsa, Linux Kernel Mailing List, Linux Next Mailing List,
Michael Ellerman, Miguel Ojeda, Sven Van Asbroeck,
Wedson Almeida Filho
Hi Stephen,
On Wed, Nov 3, 2021 at 4:19 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> diff --cc scripts/Makefile.modfinal
> index 7f39599e9fae,c0842e999a75..000000000000
> --- a/scripts/Makefile.modfinal
> +++ b/scripts/Makefile.modfinal
> @@@ -39,11 -39,12 +39,12 @@@ quiet_cmd_ld_ko_o = LD [M] $
>
> quiet_cmd_btf_ko = BTF [M] $@
> cmd_btf_ko = \
> - if [ -f vmlinux ]; then \
> - LLVM_OBJCOPY="$(OBJCOPY)" $(PAHOLE) -J $(PAHOLE_FLAGS) --btf_base vmlinux $@; \
> - $(RESOLVE_BTFIDS) -b vmlinux $@; \
> - else \
> + if [ ! -f vmlinux ]; then \
> printf "Skipping BTF generation for %s due to unavailability of vmlinux\n" $@ 1>&2; \
> + elif $(srctree)/scripts/is_rust_module.sh $@; then \
> + printf "Skipping BTF generation for %s because it's a Rust module\n" $@ 1>&2; \
> + else \
> - LLVM_OBJCOPY="$(OBJCOPY)" $(PAHOLE) -J --btf_base vmlinux $@; \
> ++ LLVM_OBJCOPY="$(OBJCOPY)" $(PAHOLE) -J $(PAHOLE_FLAGS) --btf_base vmlinux $@; \
> fi;
It looks like the `$(RESOLVE_BTFIDS)` line is gone with this
resolution. The rest looks good.
Thanks!
Cheers,
Miguel
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: linux-next: manual merge of the rust tree with Linus' tree
2021-11-03 10:30 ` Miguel Ojeda
@ 2021-11-03 21:01 ` Stephen Rothwell
2021-11-04 12:19 ` Miguel Ojeda
0 siblings, 1 reply; 19+ messages in thread
From: Stephen Rothwell @ 2021-11-03 21:01 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Adam Bratschi-Kaye, Alex Gaynor, Andrii Nakryiko,
Antonio Terceiro, Boqun Feng, Boris-Chengbiao Zhou, Daniel Xu,
Dariusz Sosnowski, Douglas Su, Finn Behrens, Gary Guo, Jiri Olsa,
Jiri Olsa, Linux Kernel Mailing List, Linux Next Mailing List,
Michael Ellerman, Miguel Ojeda, Sven Van Asbroeck,
Wedson Almeida Filho
[-- Attachment #1: Type: text/plain, Size: 1799 bytes --]
Hi Miguel,
On Wed, 3 Nov 2021 11:30:35 +0100 Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote:
>
> On Wed, Nov 3, 2021 at 4:19 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > diff --cc scripts/Makefile.modfinal
> > index 7f39599e9fae,c0842e999a75..000000000000
> > --- a/scripts/Makefile.modfinal
> > +++ b/scripts/Makefile.modfinal
> > @@@ -39,11 -39,12 +39,12 @@@ quiet_cmd_ld_ko_o = LD [M] $
> >
> > quiet_cmd_btf_ko = BTF [M] $@
> > cmd_btf_ko = \
> > - if [ -f vmlinux ]; then \
> > - LLVM_OBJCOPY="$(OBJCOPY)" $(PAHOLE) -J $(PAHOLE_FLAGS) --btf_base vmlinux $@; \
> > - $(RESOLVE_BTFIDS) -b vmlinux $@; \
> > - else \
> > + if [ ! -f vmlinux ]; then \
> > printf "Skipping BTF generation for %s due to unavailability of vmlinux\n" $@ 1>&2; \
> > + elif $(srctree)/scripts/is_rust_module.sh $@; then \
> > + printf "Skipping BTF generation for %s because it's a Rust module\n" $@ 1>&2; \
> > + else \
> > - LLVM_OBJCOPY="$(OBJCOPY)" $(PAHOLE) -J --btf_base vmlinux $@; \
> > ++ LLVM_OBJCOPY="$(OBJCOPY)" $(PAHOLE) -J $(PAHOLE_FLAGS) --btf_base vmlinux $@; \
> > fi;
>
> It looks like the `$(RESOLVE_BTFIDS)` line is gone with this
> resolution. The rest looks good.
Oops, sorry about that. I have added it back from today.
BTW, are you intending to submit the rust tree this merge window?
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: linux-next: manual merge of the rust tree with Linus' tree
2021-11-03 21:01 ` Stephen Rothwell
@ 2021-11-04 12:19 ` Miguel Ojeda
2021-11-04 20:31 ` Stephen Rothwell
0 siblings, 1 reply; 19+ messages in thread
From: Miguel Ojeda @ 2021-11-04 12:19 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Adam Bratschi-Kaye, Alex Gaynor, Andrii Nakryiko,
Antonio Terceiro, Boqun Feng, Boris-Chengbiao Zhou, Daniel Xu,
Dariusz Sosnowski, Douglas Su, Finn Behrens, Gary Guo, Jiri Olsa,
Jiri Olsa, Linux Kernel Mailing List, Linux Next Mailing List,
Michael Ellerman, Miguel Ojeda, Sven Van Asbroeck,
Wedson Almeida Filho
On Wed, Nov 3, 2021 at 10:01 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Oops, sorry about that. I have added it back from today.
No worries! By the way, I will be rebasing soon to fix a build error
that happened due to some changes in mainline, so the conflict will
disappear.
> BTW, are you intending to submit the rust tree this merge window?
That was the idea, but a few things need to be taken care of before.
In any case, I was told to start submitting it every couple weeks or
so, so I think Linus et. al. do not mind if it aligns to a merge
window or not (though I might be wrong...).
Cheers,
Miguel
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: linux-next: manual merge of the rust tree with Linus' tree
2021-11-04 12:19 ` Miguel Ojeda
@ 2021-11-04 20:31 ` Stephen Rothwell
2021-11-05 11:00 ` Miguel Ojeda
0 siblings, 1 reply; 19+ messages in thread
From: Stephen Rothwell @ 2021-11-04 20:31 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Adam Bratschi-Kaye, Alex Gaynor, Andrii Nakryiko,
Antonio Terceiro, Boqun Feng, Boris-Chengbiao Zhou, Daniel Xu,
Dariusz Sosnowski, Douglas Su, Finn Behrens, Gary Guo, Jiri Olsa,
Jiri Olsa, Linux Kernel Mailing List, Linux Next Mailing List,
Michael Ellerman, Miguel Ojeda, Sven Van Asbroeck,
Wedson Almeida Filho
[-- Attachment #1: Type: text/plain, Size: 1197 bytes --]
Hi Miguel,
On Thu, 4 Nov 2021 13:19:22 +0100 Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote:
>
> On Wed, Nov 3, 2021 at 10:01 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Oops, sorry about that. I have added it back from today.
>
> No worries! By the way, I will be rebasing soon to fix a build error
> that happened due to some changes in mainline, so the conflict will
> disappear.
I would suggest that you don't rebase if you are intending to submit to
Linus. Instead, do a test merge with his tree and fix the issue in the
merge and test that, then explain it all the in the pull request (but
ask him to pull your tree without the merge).
> > BTW, are you intending to submit the rust tree this merge window?
>
> That was the idea, but a few things need to be taken care of before.
> In any case, I was told to start submitting it every couple weeks or
> so, so I think Linus et. al. do not mind if it aligns to a merge
> window or not (though I might be wrong...).
Much better to do it in the merge window. Linus almost never takes new
features outside a merge window (but you could always ask him).
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: linux-next: manual merge of the rust tree with Linus' tree
2021-11-04 20:31 ` Stephen Rothwell
@ 2021-11-05 11:00 ` Miguel Ojeda
0 siblings, 0 replies; 19+ messages in thread
From: Miguel Ojeda @ 2021-11-05 11:00 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Adam Bratschi-Kaye, Alex Gaynor, Andrii Nakryiko,
Antonio Terceiro, Boqun Feng, Boris-Chengbiao Zhou, Daniel Xu,
Dariusz Sosnowski, Douglas Su, Finn Behrens, Gary Guo, Jiri Olsa,
Jiri Olsa, Linux Kernel Mailing List, Linux Next Mailing List,
Michael Ellerman, Miguel Ojeda, Sven Van Asbroeck,
Wedson Almeida Filho
On Thu, Nov 4, 2021 at 9:31 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> I would suggest that you don't rebase if you are intending to submit to
> Linus. Instead, do a test merge with his tree and fix the issue in the
> merge and test that, then explain it all the in the pull request (but
> ask him to pull your tree without the merge).
Note that I am still submitting this as patches, not as a PR. After we
are in, yes, of course!
Cheers,
Miguel
^ permalink raw reply [flat|nested] 19+ messages in thread
* linux-next: manual merge of the rust tree with Linus' tree
@ 2021-07-19 6:16 Stephen Rothwell
0 siblings, 0 replies; 19+ messages in thread
From: Stephen Rothwell @ 2021-07-19 6:16 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Adam Bratschi-Kaye, Alex Gaynor, Ayaan Zaidi, Boqun Feng,
Boris-Chengbiao Zhou, Douglas Su, Finn Behrens, Fox Chen,
Gary Guo, Geoffrey Thomas, Linux Kernel Mailing List,
Linux Next Mailing List, Masahiro Yamada, Michael Ellerman,
Miguel Ojeda, Sumera Priyadarsini, Sven Van Asbroeck,
Wedson Almeida Filho, Yuki Okushi
[-- Attachment #1: Type: text/plain, Size: 2198 bytes --]
Hi all,
Today's linux-next merge of the rust tree got a conflict in:
Makefile
between commit:
d952cfaf0cff ("kbuild: do not suppress Kconfig prompts for silent build")
from Linus' tree and commit:
dc08d49444e9 ("Kbuild: add Rust support")
from the rust tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc Makefile
index 45a3215179b4,c814b209b6c9..000000000000
--- a/Makefile
+++ b/Makefile
@@@ -731,12 -763,11 +778,12 @@@ $(KCONFIG_CONFIG)
# This exploits the 'multi-target pattern rule' trick.
# The syncconfig should be executed only once to make all the targets.
# (Note: use the grouped target '&:' when we bump to GNU Make 4.3)
-quiet_cmd_syncconfig = SYNC $@
- cmd_syncconfig = $(MAKE) -f $(srctree)/Makefile syncconfig
-
+#
+# Do not use $(call cmd,...) here. That would suppress prompts from syncconfig,
+# so you cannot notice that Kconfig is waiting for the user input.
- %/config/auto.conf %/config/auto.conf.cmd %/generated/autoconf.h: $(KCONFIG_CONFIG)
+ %/config/auto.conf %/config/auto.conf.cmd %/generated/autoconf.h %/generated/rustc_cfg: $(KCONFIG_CONFIG)
- +$(call cmd,syncconfig)
+ $(Q)$(kecho) " SYNC $@"
+ $(Q)$(MAKE) -f $(srctree)/Makefile syncconfig
else # !may-sync-config
# External modules and some install targets need include/generated/autoconf.h
# and include/config/auto.conf but do not care if they are up-to-date.
@@@ -1214,9 -1327,12 +1308,12 @@@ archprepare: outputmakefile archheader
prepare0: archprepare
$(Q)$(MAKE) $(build)=scripts/mod
$(Q)$(MAKE) $(build)=.
+ ifdef CONFIG_RUST
+ $(Q)$(MAKE) $(build)=rust
+ endif
# All the preparing..
-prepare: prepare0 prepare-objtool prepare-resolve_btfids
+prepare: prepare0
PHONY += remove-stale-files
remove-stale-files:
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread* linux-next: manual merge of the rust tree with Linus' tree
@ 2021-07-12 0:37 Stephen Rothwell
0 siblings, 0 replies; 19+ messages in thread
From: Stephen Rothwell @ 2021-07-12 0:37 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Adam Bratschi-Kaye, Alex Gaynor, Andrew Morton, Bixuan Cui,
Finn Behrens, Geoffrey Thomas, Linus Torvalds,
Linux Kernel Mailing List, Linux Next Mailing List, Miguel Ojeda,
Randy Dunlap, Stephen Boyd, Wedson Almeida Filho
[-- Attachment #1: Type: text/plain, Size: 1389 bytes --]
Hi all,
Today's linux-next merge of the rust tree got a conflict in:
include/linux/kallsyms.h
between commit:
9294523e3768 ("module: add printk formats to add module build ID to stacktraces")
from Linus' tree and commit:
f2f6175186f4 ("kallsyms: increase maximum kernel symbol length to 512")
from the rust tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc include/linux/kallsyms.h
index a1d6fc82d7f0,5cdc6903abca..000000000000
--- a/include/linux/kallsyms.h
+++ b/include/linux/kallsyms.h
@@@ -15,11 -14,9 +15,11 @@@
#include <asm/sections.h>
- #define KSYM_NAME_LEN 128
+ #define KSYM_NAME_LEN 512
-#define KSYM_SYMBOL_LEN (sizeof("%s+%#lx/%#lx [%s]") + (KSYM_NAME_LEN - 1) + \
- 2*(BITS_PER_LONG*3/10) + (MODULE_NAME_LEN - 1) + 1)
+#define KSYM_SYMBOL_LEN (sizeof("%s+%#lx/%#lx [%s %s]") + \
+ (KSYM_NAME_LEN - 1) + \
+ 2*(BITS_PER_LONG*3/10) + (MODULE_NAME_LEN - 1) + \
+ (BUILD_ID_SIZE_MAX * 2) + 1)
struct cred;
struct module;
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2022-10-04 8:05 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-07-13 10:34 linux-next: manual merge of the rust tree with Linus' tree Stephen Rothwell
2022-07-13 10:50 ` Miguel Ojeda
2022-07-13 11:39 ` Peter Zijlstra
2022-07-15 1:13 ` Miguel Ojeda
2022-07-15 9:01 ` Peter Zijlstra
2022-07-15 11:01 ` Miguel Ojeda
-- strict thread matches above, loose matches on Subject: below --
2022-10-04 8:05 Stephen Rothwell
2022-09-12 7:24 Stephen Rothwell
2022-07-25 8:41 Stephen Rothwell
2022-07-25 8:52 ` Miguel Ojeda
2021-12-10 18:18 broonie
2021-11-03 3:19 Stephen Rothwell
2021-11-03 10:30 ` Miguel Ojeda
2021-11-03 21:01 ` Stephen Rothwell
2021-11-04 12:19 ` Miguel Ojeda
2021-11-04 20:31 ` Stephen Rothwell
2021-11-05 11:00 ` Miguel Ojeda
2021-07-19 6:16 Stephen Rothwell
2021-07-12 0:37 Stephen Rothwell
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.