linux-next: manual merge of the rust tree with Linus' tree

linux-next: manual merge of the rust tree with Linus' tree

[Stephen Rothwell]

[-- 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 --]

linux-next: manual merge of the rust tree with Linus' tree

[Stephen Rothwell]

[-- 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 --]

linux-next: manual merge of the rust tree with Linus' tree

[Stephen Rothwell]

[-- 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 --]

Re: linux-next: manual merge of the rust tree with Linus' tree

[Miguel Ojeda]

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

linux-next: manual merge of the rust tree with Linus' tree

[Stephen Rothwell]

[-- 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 --]

Re: linux-next: manual merge of the rust tree with Linus' tree

[Miguel Ojeda]

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

Re: linux-next: manual merge of the rust tree with Linus' tree

[Peter Zijlstra]

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...

Re: linux-next: manual merge of the rust tree with Linus' tree

[Miguel Ojeda]

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

Re: linux-next: manual merge of the rust tree with Linus' tree

[Peter Zijlstra]

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_ ?

Re: linux-next: manual merge of the rust tree with Linus' tree

[Miguel Ojeda]

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

linux-next: manual merge of the rust tree with Linus' tree

[Stephen Rothwell]

[-- 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 --]

linux-next: manual merge of the rust tree with Linus' tree

[broonie]

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.

Re: linux-next: manual merge of the rust tree with Linus' tree

[Miguel Ojeda]

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

Re: linux-next: manual merge of the rust tree with Linus' tree

[Stephen Rothwell]

[-- 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 --]

Re: linux-next: manual merge of the rust tree with Linus' tree

[Miguel Ojeda]

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

Re: linux-next: manual merge of the rust tree with Linus' tree

[Stephen Rothwell]

[-- 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 --]

Re: linux-next: manual merge of the rust tree with Linus' tree

[Miguel Ojeda]

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

linux-next: manual merge of the rust tree with Linus' tree

[Stephen Rothwell]

[-- 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 --]

linux-next: manual merge of the rust tree with Linus' tree

[Stephen Rothwell]

[-- 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 --]