Prevent .eh_frame from being emitted for -C panic=abort by nbdd0121 · Pull Request #112403 · rust-lang/rust (original) (raw)

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Conversation17 Commits1 Checks0 Files changed

Conversation

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters

[ Show hidden characters]({{ revealButtonHref }})

nbdd0121

Since CheckAlignment pass is after the AbortUnwindingCalls pass, the UnwindAction::Terminate inserted in it has no chance to be converted to UnwindAction::Unreachable anymore, causing us to emit landing pads that are not necessary. Although these landing pads can themselves be eliminated by LLVM, .eh_frame sections are still generated. This causes trouble for Rust-for-Linux project recently.

This PR changes it to generate UnwindAction::Terminate when we opt for -Cpanic=unwind, and UnwindAction::Unreachable for -Cpanic=abort.

@ojeda

@nbdd0121

@rustbot

r? @petrochenkov

(rustbot has picked a reviewer for you, use r? to override)

@rustbot rustbot added S-waiting-on-review

Status: Awaiting review from the assignee but also interested parties.

T-compiler

Relevant to the compiler team, which will review and decide on the PR/issue.

labels

Jun 7, 2023

@rustbot

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

@ojeda ojeda mentioned this pull request

Jun 7, 2023

56 tasks

@ojeda

Thanks @nbdd0121 for taking such a quick look at it.

Mark-Simulacrum

@@ -236,7 +237,11 @@ fn insert_alignment_check<'tcx>(
required: Operand::Copy(alignment),
found: Operand::Copy(addr),
}),
unwind: UnwindAction::Terminate,
unwind: if tcx.sess.panic_strategy() == PanicStrategy::Unwind {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This feels like something we're going to regress on with the next similar check in MIR -- can we introduce another run of AbortUnwindingCalls or otherwise make this more general?

(I'm not super familiar with mir opts so not sure if that pass is very expensive).

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Currently this pass is the only pass that can add a new call, and given that this pass is only enabled with debug assertions, re-running AbortUnwindingCalls feels a bit unnecessary?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we run AbortUnwindingCalls after it (or rather, run the alignment checks before it)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

alternatively, MIR validation could check that no normal unwind actions are present on panic=abort

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

UnwindAction::Terminate may be present in -Cpanic=abort when C-unwind is used so we couldn't just do it in validation.

Lifting the CheckAlignment pass might make sense.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

terminate existing with panic=unwind could happen, but other unwind actions with panic=abort shouldn't, right? that could be validated

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's entirely orthogonal to this PR though.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just checked we couldn't lift CheckAlignment, because alignment checks are not doable for CTFE, so it must stay as an optimization pass. We also couldn't delay AbortUnwindingCalls, because it needs to be run before generator lowering.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I understood @saethlin correctly, this could be Unreachable always?

Either way there should be a comment explaining why this is unreachable. "Because we use the non-unwinding panic machinery" seems like a good answer to me; it is explicitly intended to not unwind so I have no issue with this non-local dependency.

EDIT: Ah, #112599 already did this. :)

@petrochenkov

@ojeda ojeda mentioned this pull request

Jun 9, 2023

@Noratrieb

I've looked at this a little more and I think I finally understood it. TerminatorKind::Assert codegens to a function call on failure, which may unwind with panic=unwind. We don't want pointer dereferences to ever unwind because that may be very confusing, so this pass forcefully sets it to abort if the function unwinds. But if we're panic=abort, it can never unwind, so having the abort is unnecessary (and rust for linux relies on no unnecessary landing pads being generated).
While I agree with Mark that it's not the nicest thing that this needs to do a check here, We may want to add an AbortUnwindingCalls (which, while not implied by the name, also UnreachablesNonUnwindingCalls, what we'd want here) at the end of the MIR pipeline, but I think for now this check here is fine.
cc @saethlin as you've added this and may plan on adding more passes like it
@bors r+

@bors

📌 Commit d9531a0 has been approved by Nilstrieb

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors

Status: Waiting on bors to run and complete tests. Bors will change the label on completion.

and removed S-waiting-on-review

Status: Awaiting review from the assignee but also interested parties.

labels

Jun 14, 2023

@saethlin

Panics due to UB checks should never unwind. This is a very strongly desirable property, because a lot of unsafe code has sections where unwinding would cause UB, so if we insert an unwinding panic as a UB detection we could have made things worse.

This should be documented clearly in the code, the fact that it wasn't here is an oversight.

Additionally, the fact that the panic function that is called in the standard library ever unwinds at all is also an oversight. We have a way to launch non-unwinding panics, I just failed to use it in this pass initially. I have a PR to use it here: #112599

I was considering submitting a PR similar to this one after #112599 landed to turn this into UnwindAction::Unreachable. The only reason I didn't do that immediately is that it's not clear to me if we're comfortable with that kind of nonlocal dependency. If for whatever reason that function in the standard library gets accidentally changed to an unwind, changing this to UnwindAction::Unreachable would make these panics UB.

@saethlin

Also my second UB-checking pass is here: #104862

bors added a commit to rust-lang-ci/rust that referenced this pull request

Jun 15, 2023

@bors

…llaumeGomez

Rollup of 8 pull requests

Successful merges:

r? @ghost @rustbot modify labels: rollup

bors added a commit to rust-lang-ci/rust that referenced this pull request

Aug 20, 2023

@bors

Add MIR validation for unwind out from nounwind functions + fixes to make validation pass

@Nilstrieb This is the MIR validation you asked in rust-lang#112403 (comment).

Two passes need to be fixed to get the validation to pass:

I believe this PR should also fix Rust-for-Linux/linux#1016, cc @ojeda

r? @Nilstrieb

github-actions bot pushed a commit to rust-lang/miri that referenced this pull request

Aug 21, 2023

@bors

Add MIR validation for unwind out from nounwind functions + fixes to make validation pass

@Nilstrieb This is the MIR validation you asked in rust-lang/rust#112403 (comment).

Two passes need to be fixed to get the validation to pass:

I believe this PR should also fix Rust-for-Linux/linux#1016, cc @ojeda

r? @Nilstrieb

ojeda added a commit to ojeda/linux that referenced this pull request

Aug 23, 2023

@ojeda

This is the second upgrade to the Rust toolchain, from 1.71.1 to 1.72.0 (i.e. the latest) [1].

See the upgrade policy [2] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2").

Unstable features

No unstable features (that we use) were stabilized.

Therefore, the only unstable feature allowed to be used outside the kernel crate is still new_uninit, though other code to be upstreamed may increase the list.

Please see [3] for details.

Other improvements

Previously, the compiler could incorrectly generate a .eh_frame section under -Cpanic=abort. We were hitting this bug in our old rust branch [4]. Gary fixed the issue in Rust 1.72.0 [5].

Required changes

For the upgrade, the following changes are required:

alloc upgrade and reviewing

The vast majority of changes are due to our alloc fork being upgraded at once.

There are two kinds of changes to be aware of: the ones coming from upstream, which we should follow as closely as possible, and the updates needed in our added fallible APIs to keep them matching the newer infallible APIs coming from upstream.

Instead of taking a look at the diff of this patch, an alternative approach is reviewing a diff of the changes between upstream alloc and the kernel's. This allows to easily inspect the kernel additions only, especially to check if the fallible methods we already have still match the infallible ones in the new version coming from upstream.

Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions.

To apply these approaches, one may follow steps similar to the following to generate a pair of patches that show the differences between upstream Rust and the kernel (for the subset of alloc we use) before and after applying this patch:

# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc

# Apply this patch.
git -C linux am rust-upgrade.patch

# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/alloc

Now one may check the new.patch to take a look at the additions (first approach) or at the difference between those two patches (second approach). For the latter, a side-by-side tool is recommended.

Link: https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1720-2023-08-24 [1] Link: https://rust-for-linux.com/rust-version-policy [2] Link: Rust-for-Linux#2 [3] Closes: Rust-for-Linux#1012 [4] Link: rust-lang/rust#112403 [5] Signed-off-by: Miguel Ojeda ojeda@kernel.org

intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request

Aug 23, 2023

@ojeda @intel-lab-lkp

This is the second upgrade to the Rust toolchain, from 1.71.1 to 1.72.0 (i.e. the latest) [1].

See the upgrade policy [2] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2").

Unstable features

No unstable features (that we use) were stabilized.

Therefore, the only unstable feature allowed to be used outside the kernel crate is still new_uninit, though other code to be upstreamed may increase the list.

Please see [3] for details.

Other improvements

Previously, the compiler could incorrectly generate a .eh_frame section under -Cpanic=abort. We were hitting this bug in our old rust branch [4]. Gary fixed the issue in Rust 1.72.0 [5].

Required changes

For the upgrade, the following changes are required:

alloc upgrade and reviewing

The vast majority of changes are due to our alloc fork being upgraded at once.

There are two kinds of changes to be aware of: the ones coming from upstream, which we should follow as closely as possible, and the updates needed in our added fallible APIs to keep them matching the newer infallible APIs coming from upstream.

Instead of taking a look at the diff of this patch, an alternative approach is reviewing a diff of the changes between upstream alloc and the kernel's. This allows to easily inspect the kernel additions only, especially to check if the fallible methods we already have still match the infallible ones in the new version coming from upstream.

Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions.

To apply these approaches, one may follow steps similar to the following to generate a pair of patches that show the differences between upstream Rust and the kernel (for the subset of alloc we use) before and after applying this patch:

# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc

# Apply this patch.
git -C linux am rust-upgrade.patch

# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/alloc

Now one may check the new.patch to take a look at the additions (first approach) or at the difference between those two patches (second approach). For the latter, a side-by-side tool is recommended.

Link: https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1720-2023-08-24 [1] Link: https://rust-for-linux.com/rust-version-policy [2] Link: Rust-for-Linux#2 [3] Closes: Rust-for-Linux#1012 [4] Link: rust-lang/rust#112403 [5] Signed-off-by: Miguel Ojeda ojeda@kernel.org

1715173329 added a commit to 1715173329/packages-official that referenced this pull request

Aug 26, 2023

@1715173329

1715173329 added a commit to 1715173329/packages-official that referenced this pull request

Aug 26, 2023

@1715173329

fbq pushed a commit to Rust-for-Linux/linux that referenced this pull request

Aug 28, 2023

@ojeda @fbq

This is the second upgrade to the Rust toolchain, from 1.71.1 to 1.72.0 (i.e. the latest) [1].

See the upgrade policy [2] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2").

Unstable features

No unstable features (that we use) were stabilized.

Therefore, the only unstable feature allowed to be used outside the kernel crate is still new_uninit, though other code to be upstreamed may increase the list.

Please see [3] for details.

Other improvements

Previously, the compiler could incorrectly generate a .eh_frame section under -Cpanic=abort. We were hitting this bug in our old rust branch [4]. Gary fixed the issue in Rust 1.72.0 [5].

Required changes

For the upgrade, the following changes are required:

alloc upgrade and reviewing

The vast majority of changes are due to our alloc fork being upgraded at once.

There are two kinds of changes to be aware of: the ones coming from upstream, which we should follow as closely as possible, and the updates needed in our added fallible APIs to keep them matching the newer infallible APIs coming from upstream.

Instead of taking a look at the diff of this patch, an alternative approach is reviewing a diff of the changes between upstream alloc and the kernel's. This allows to easily inspect the kernel additions only, especially to check if the fallible methods we already have still match the infallible ones in the new version coming from upstream.

Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions.

To apply these approaches, one may follow steps similar to the following to generate a pair of patches that show the differences between upstream Rust and the kernel (for the subset of alloc we use) before and after applying this patch:

# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc

# Apply this patch.
git -C linux am rust-upgrade.patch

# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/alloc

Now one may check the new.patch to take a look at the additions (first approach) or at the difference between those two patches (second approach). For the latter, a side-by-side tool is recommended.

Link: https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1720-2023-08-24 [1] Link: https://rust-for-linux.com/rust-version-policy [2] Link: #2 [3] Closes: #1012 [4] Link: rust-lang/rust#112403 [5] Signed-off-by: Miguel Ojeda ojeda@kernel.org Link: https://lore.kernel.org/r/20230823160244.188033-3-ojeda@kernel.org

fbq pushed a commit to Rust-for-Linux/linux that referenced this pull request

Sep 15, 2023

@ojeda @fbq

This is the second upgrade to the Rust toolchain, from 1.71.1 to 1.72.0 (i.e. the latest) [1].

See the upgrade policy [2] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2").

Unstable features

No unstable features (that we use) were stabilized.

Therefore, the only unstable feature allowed to be used outside the kernel crate is still new_uninit, though other code to be upstreamed may increase the list.

Please see [3] for details.

Other improvements

Previously, the compiler could incorrectly generate a .eh_frame section under -Cpanic=abort. We were hitting this bug in our old rust branch [4]. Gary fixed the issue in Rust 1.72.0 [5].

Required changes

For the upgrade, the following changes are required:

alloc upgrade and reviewing

The vast majority of changes are due to our alloc fork being upgraded at once.

There are two kinds of changes to be aware of: the ones coming from upstream, which we should follow as closely as possible, and the updates needed in our added fallible APIs to keep them matching the newer infallible APIs coming from upstream.

Instead of taking a look at the diff of this patch, an alternative approach is reviewing a diff of the changes between upstream alloc and the kernel's. This allows to easily inspect the kernel additions only, especially to check if the fallible methods we already have still match the infallible ones in the new version coming from upstream.

Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions.

To apply these approaches, one may follow steps similar to the following to generate a pair of patches that show the differences between upstream Rust and the kernel (for the subset of alloc we use) before and after applying this patch:

# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc

# Apply this patch.
git -C linux am rust-upgrade.patch

# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/alloc

Now one may check the new.patch to take a look at the additions (first approach) or at the difference between those two patches (second approach). For the latter, a side-by-side tool is recommended.

Link: https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1720-2023-08-24 [1] Link: https://rust-for-linux.com/rust-version-policy [2] Link: #2 [3] Closes: #1012 [4] Link: rust-lang/rust#112403 [5] Signed-off-by: Miguel Ojeda ojeda@kernel.org Link: https://lore.kernel.org/r/20230823160244.188033-3-ojeda@kernel.org

jefferyto pushed a commit to jefferyto/openwrt-packages that referenced this pull request

Sep 21, 2023

@1715173329 @jefferyto

BKPepe pushed a commit to openwrt/packages that referenced this pull request

Sep 21, 2023

@1715173329 @BKPepe

wip-sync pushed a commit to NetBSD/pkgsrc-wip that referenced this pull request

Sep 24, 2023

@he32

fbq pushed a commit to Rust-for-Linux/linux that referenced this pull request

Sep 25, 2023

@ojeda @fbq

This is the second upgrade to the Rust toolchain, from 1.71.1 to 1.72.0 (i.e. the latest) [1].

See the upgrade policy [2] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2").

Unstable features

No unstable features (that we use) were stabilized.

Therefore, the only unstable feature allowed to be used outside the kernel crate is still new_uninit, though other code to be upstreamed may increase the list.

Please see [3] for details.

Other improvements

Previously, the compiler could incorrectly generate a .eh_frame section under -Cpanic=abort. We were hitting this bug in our old rust branch [4]. Gary fixed the issue in Rust 1.72.0 [5].

Required changes

For the upgrade, the following changes are required:

alloc upgrade and reviewing

The vast majority of changes are due to our alloc fork being upgraded at once.

There are two kinds of changes to be aware of: the ones coming from upstream, which we should follow as closely as possible, and the updates needed in our added fallible APIs to keep them matching the newer infallible APIs coming from upstream.

Instead of taking a look at the diff of this patch, an alternative approach is reviewing a diff of the changes between upstream alloc and the kernel's. This allows to easily inspect the kernel additions only, especially to check if the fallible methods we already have still match the infallible ones in the new version coming from upstream.

Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions.

To apply these approaches, one may follow steps similar to the following to generate a pair of patches that show the differences between upstream Rust and the kernel (for the subset of alloc we use) before and after applying this patch:

# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc

# Apply this patch.
git -C linux am rust-upgrade.patch

# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/alloc

Now one may check the new.patch to take a look at the additions (first approach) or at the difference between those two patches (second approach). For the latter, a side-by-side tool is recommended.

Link: https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1720-2023-08-24 [1] Link: https://rust-for-linux.com/rust-version-policy [2] Link: #2 [3] Closes: #1012 [4] Link: rust-lang/rust#112403 [5] Signed-off-by: Miguel Ojeda ojeda@kernel.org Link: https://lore.kernel.org/r/20230823160244.188033-3-ojeda@kernel.org

fbq pushed a commit to Rust-for-Linux/linux that referenced this pull request

Sep 25, 2023

@ojeda @fbq

This is the second upgrade to the Rust toolchain, from 1.71.1 to 1.72.0 (i.e. the latest) [1].

See the upgrade policy [2] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2").

Unstable features

No unstable features (that we use) were stabilized.

Therefore, the only unstable feature allowed to be used outside the kernel crate is still new_uninit, though other code to be upstreamed may increase the list.

Please see [3] for details.

Other improvements

Previously, the compiler could incorrectly generate a .eh_frame section under -Cpanic=abort. We were hitting this bug in our old rust branch [4]. Gary fixed the issue in Rust 1.72.0 [5].

Required changes

For the upgrade, the following changes are required:

alloc upgrade and reviewing

The vast majority of changes are due to our alloc fork being upgraded at once.

There are two kinds of changes to be aware of: the ones coming from upstream, which we should follow as closely as possible, and the updates needed in our added fallible APIs to keep them matching the newer infallible APIs coming from upstream.

Instead of taking a look at the diff of this patch, an alternative approach is reviewing a diff of the changes between upstream alloc and the kernel's. This allows to easily inspect the kernel additions only, especially to check if the fallible methods we already have still match the infallible ones in the new version coming from upstream.

Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions.

To apply these approaches, one may follow steps similar to the following to generate a pair of patches that show the differences between upstream Rust and the kernel (for the subset of alloc we use) before and after applying this patch:

# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc

# Apply this patch.
git -C linux am rust-upgrade.patch

# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/alloc

Now one may check the new.patch to take a look at the additions (first approach) or at the difference between those two patches (second approach). For the latter, a side-by-side tool is recommended.

Link: https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1720-2023-08-24 [1] Link: https://rust-for-linux.com/rust-version-policy [2] Link: #2 [3] Closes: #1012 [4] Link: rust-lang/rust#112403 [5] Signed-off-by: Miguel Ojeda ojeda@kernel.org Link: https://lore.kernel.org/r/20230823160244.188033-3-ojeda@kernel.org

fbq pushed a commit to fbq/linux that referenced this pull request

Oct 1, 2023

@ojeda @fbq

This is the second upgrade to the Rust toolchain, from 1.71.1 to 1.72.0 (i.e. the latest) [1].

See the upgrade policy [2] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2").

Unstable features

No unstable features (that we use) were stabilized.

Therefore, the only unstable feature allowed to be used outside the kernel crate is still new_uninit, though other code to be upstreamed may increase the list.

Please see [3] for details.

Other improvements

Previously, the compiler could incorrectly generate a .eh_frame section under -Cpanic=abort. We were hitting this bug in our old rust branch [4]. Gary fixed the issue in Rust 1.72.0 [5].

Required changes

For the upgrade, the following changes are required:

alloc upgrade and reviewing

The vast majority of changes are due to our alloc fork being upgraded at once.

There are two kinds of changes to be aware of: the ones coming from upstream, which we should follow as closely as possible, and the updates needed in our added fallible APIs to keep them matching the newer infallible APIs coming from upstream.

Instead of taking a look at the diff of this patch, an alternative approach is reviewing a diff of the changes between upstream alloc and the kernel's. This allows to easily inspect the kernel additions only, especially to check if the fallible methods we already have still match the infallible ones in the new version coming from upstream.

Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions.

To apply these approaches, one may follow steps similar to the following to generate a pair of patches that show the differences between upstream Rust and the kernel (for the subset of alloc we use) before and after applying this patch:

# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc

# Apply this patch.
git -C linux am rust-upgrade.patch

# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/alloc

Now one may check the new.patch to take a look at the additions (first approach) or at the difference between those two patches (second approach). For the latter, a side-by-side tool is recommended.

Link: https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1720-2023-08-24 [1] Link: https://rust-for-linux.com/rust-version-policy [2] Link: Rust-for-Linux/linux#2 [3] Closes: Rust-for-Linux/linux#1012 [4] Link: rust-lang/rust#112403 [5] Signed-off-by: Miguel Ojeda ojeda@kernel.org Link: https://lore.kernel.org/r/20230823160244.188033-3-ojeda@kernel.org

ojeda added a commit to Rust-for-Linux/linux that referenced this pull request

Oct 5, 2023

@ojeda

This is the second upgrade to the Rust toolchain, from 1.71.1 to 1.72.1 (i.e. the latest) [1].

See the upgrade policy [2] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2").

Unstable features

No unstable features (that we use) were stabilized.

Therefore, the only unstable feature allowed to be used outside the kernel crate is still new_uninit, though other code to be upstreamed may increase the list.

Please see [3] for details.

Other improvements

Previously, the compiler could incorrectly generate a .eh_frame section under -Cpanic=abort. We were hitting this bug when debug assertions were enabled (CONFIG_RUST_DEBUG_ASSERTIONS=y) [4]:

  LD      .tmp_vmlinux.kallsyms1
ld.lld: error: <internal>:(.eh_frame) is being placed in '.eh_frame'

Gary fixed the issue in Rust 1.72.0 [5].

Required changes

For the upgrade, the following changes are required:

alloc upgrade and reviewing

The vast majority of changes are due to our alloc fork being upgraded at once.

There are two kinds of changes to be aware of: the ones coming from upstream, which we should follow as closely as possible, and the updates needed in our added fallible APIs to keep them matching the newer infallible APIs coming from upstream.

Instead of taking a look at the diff of this patch, an alternative approach is reviewing a diff of the changes between upstream alloc and the kernel's. This allows to easily inspect the kernel additions only, especially to check if the fallible methods we already have still match the infallible ones in the new version coming from upstream.

Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions.

To apply these approaches, one may follow steps similar to the following to generate a pair of patches that show the differences between upstream Rust and the kernel (for the subset of alloc we use) before and after applying this patch:

# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc

# Apply this patch.
git -C linux am rust-upgrade.patch

# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/alloc

Now one may check the new.patch to take a look at the additions (first approach) or at the difference between those two patches (second approach). For the latter, a side-by-side tool is recommended.

Link: https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1721-2023-09-19 [1] Link: https://rust-for-linux.com/rust-version-policy [2] Link: #2 [3] Closes: #1012 [4] Link: rust-lang/rust#112403 [5] Reviewed-by: Martin Rodriguez Reboredo yakoyoku@gmail.com Reviewed-by: Gary Guo gary@garyguo.net Reviewed-by: Alice Ryhl aliceryhl@google.com Reviewed-by: Björn Roy Baron bjorn3_gh@protonmail.com Link: https://lore.kernel.org/r/20230823160244.188033-3-ojeda@kernel.org [ Used 1.72.1 instead of .0 (no changes in alloc) and reworded to mention that we hit the .eh_frame bug under debug assertions. ] Signed-off-by: Miguel Ojeda ojeda@kernel.org

ojeda added a commit to Rust-for-Linux/linux that referenced this pull request

Oct 5, 2023

@ojeda

This is the third upgrade to the Rust toolchain, from 1.71.1 to 1.72.1 (i.e. the latest) [1].

See the upgrade policy [2] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2").

Unstable features

No unstable features (that we use) were stabilized.

Therefore, the only unstable feature allowed to be used outside the kernel crate is still new_uninit, though other code to be upstreamed may increase the list.

Please see [3] for details.

Other improvements

Previously, the compiler could incorrectly generate a .eh_frame section under -Cpanic=abort. We were hitting this bug when debug assertions were enabled (CONFIG_RUST_DEBUG_ASSERTIONS=y) [4]:

  LD      .tmp_vmlinux.kallsyms1
ld.lld: error: <internal>:(.eh_frame) is being placed in '.eh_frame'

Gary fixed the issue in Rust 1.72.0 [5].

Required changes

For the upgrade, the following changes are required:

alloc upgrade and reviewing

The vast majority of changes are due to our alloc fork being upgraded at once.

There are two kinds of changes to be aware of: the ones coming from upstream, which we should follow as closely as possible, and the updates needed in our added fallible APIs to keep them matching the newer infallible APIs coming from upstream.

Instead of taking a look at the diff of this patch, an alternative approach is reviewing a diff of the changes between upstream alloc and the kernel's. This allows to easily inspect the kernel additions only, especially to check if the fallible methods we already have still match the infallible ones in the new version coming from upstream.

Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions.

To apply these approaches, one may follow steps similar to the following to generate a pair of patches that show the differences between upstream Rust and the kernel (for the subset of alloc we use) before and after applying this patch:

# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc

# Apply this patch.
git -C linux am rust-upgrade.patch

# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/alloc

Now one may check the new.patch to take a look at the additions (first approach) or at the difference between those two patches (second approach). For the latter, a side-by-side tool is recommended.

Link: https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1721-2023-09-19 [1] Link: https://rust-for-linux.com/rust-version-policy [2] Link: #2 [3] Closes: #1012 [4] Link: rust-lang/rust#112403 [5] Reviewed-by: Martin Rodriguez Reboredo yakoyoku@gmail.com Reviewed-by: Gary Guo gary@garyguo.net Reviewed-by: Alice Ryhl aliceryhl@google.com Reviewed-by: Björn Roy Baron bjorn3_gh@protonmail.com Link: https://lore.kernel.org/r/20230823160244.188033-3-ojeda@kernel.org [ Used 1.72.1 instead of .0 (no changes in alloc) and reworded to mention that we hit the .eh_frame bug under debug assertions. ] Signed-off-by: Miguel Ojeda ojeda@kernel.org

lu-zero pushed a commit to domo-iot/packages that referenced this pull request

Oct 23, 2023

@1715173329 @lu-zero

hmtheboy154 pushed a commit to hmtheboy154/Darkmatter-kernel that referenced this pull request

Feb 2, 2024

@ojeda

This is the third upgrade to the Rust toolchain, from 1.71.1 to 1.72.1 (i.e. the latest) [1].

See the upgrade policy [2] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2").

No unstable features (that we use) were stabilized.

Therefore, the only unstable feature allowed to be used outside the kernel crate is still new_uninit, though other code to be upstreamed may increase the list.

Please see [3] for details.

Previously, the compiler could incorrectly generate a .eh_frame section under -Cpanic=abort. We were hitting this bug when debug assertions were enabled (CONFIG_RUST_DEBUG_ASSERTIONS=y) [4]:

  LD      .tmp_vmlinux.kallsyms1
ld.lld: error: <internal>:(.eh_frame) is being placed in '.eh_frame'

Gary fixed the issue in Rust 1.72.0 [5].

For the upgrade, the following changes are required:

The vast majority of changes are due to our alloc fork being upgraded at once.

There are two kinds of changes to be aware of: the ones coming from upstream, which we should follow as closely as possible, and the updates needed in our added fallible APIs to keep them matching the newer infallible APIs coming from upstream.

Instead of taking a look at the diff of this patch, an alternative approach is reviewing a diff of the changes between upstream alloc and the kernel's. This allows to easily inspect the kernel additions only, especially to check if the fallible methods we already have still match the infallible ones in the new version coming from upstream.

Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions.

To apply these approaches, one may follow steps similar to the following to generate a pair of patches that show the differences between upstream Rust and the kernel (for the subset of alloc we use) before and after applying this patch:

# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc

# Apply this patch.
git -C linux am rust-upgrade.patch

# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/alloc

Now one may check the new.patch to take a look at the additions (first approach) or at the difference between those two patches (second approach). For the latter, a side-by-side tool is recommended.

Link: https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1721-2023-09-19 [1] Link: https://rust-for-linux.com/rust-version-policy [2] Link: Rust-for-Linux/linux#2 [3] Closes: Rust-for-Linux/linux#1012 [4] Link: rust-lang/rust#112403 [5] Reviewed-by: Martin Rodriguez Reboredo yakoyoku@gmail.com Reviewed-by: Gary Guo gary@garyguo.net Reviewed-by: Alice Ryhl aliceryhl@google.com Reviewed-by: Björn Roy Baron bjorn3_gh@protonmail.com Link: https://lore.kernel.org/r/20230823160244.188033-3-ojeda@kernel.org [ Used 1.72.1 instead of .0 (no changes in alloc) and reworded to mention that we hit the .eh_frame bug under debug assertions. ] Change-Id: Ie17c06d483a356708fdf62fa954a2dde1932526d Signed-off-by: Miguel Ojeda ojeda@kernel.org Signed-off-by: Matthew Maurer mmaurer@google.com (cherry picked from commit ae6df65)

johnny-mnemonic pushed a commit to linux-ia64/linux-stable-rc that referenced this pull request

Feb 10, 2024

@ojeda

commit ae6df65 upstream.

This is the third upgrade to the Rust toolchain, from 1.71.1 to 1.72.1 (i.e. the latest) [1].

See the upgrade policy [2] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2").

Unstable features

No unstable features (that we use) were stabilized.

Therefore, the only unstable feature allowed to be used outside the kernel crate is still new_uninit, though other code to be upstreamed may increase the list.

Please see [3] for details.

Other improvements

Previously, the compiler could incorrectly generate a .eh_frame section under -Cpanic=abort. We were hitting this bug when debug assertions were enabled (CONFIG_RUST_DEBUG_ASSERTIONS=y) [4]:

  LD      .tmp_vmlinux.kallsyms1
ld.lld: error: <internal>:(.eh_frame) is being placed in '.eh_frame'

Gary fixed the issue in Rust 1.72.0 [5].

Required changes

For the upgrade, the following changes are required:

alloc upgrade and reviewing

The vast majority of changes are due to our alloc fork being upgraded at once.

There are two kinds of changes to be aware of: the ones coming from upstream, which we should follow as closely as possible, and the updates needed in our added fallible APIs to keep them matching the newer infallible APIs coming from upstream.

Instead of taking a look at the diff of this patch, an alternative approach is reviewing a diff of the changes between upstream alloc and the kernel's. This allows to easily inspect the kernel additions only, especially to check if the fallible methods we already have still match the infallible ones in the new version coming from upstream.

Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions.

To apply these approaches, one may follow steps similar to the following to generate a pair of patches that show the differences between upstream Rust and the kernel (for the subset of alloc we use) before and after applying this patch:

# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc

# Apply this patch.
git -C linux am rust-upgrade.patch

# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/alloc

Now one may check the new.patch to take a look at the additions (first approach) or at the difference between those two patches (second approach). For the latter, a side-by-side tool is recommended.

Link: https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1721-2023-09-19 [1] Link: https://rust-for-linux.com/rust-version-policy [2] Link: Rust-for-Linux/linux#2 [3] Closes: Rust-for-Linux/linux#1012 [4] Link: rust-lang/rust#112403 [5] Reviewed-by: Martin Rodriguez Reboredo yakoyoku@gmail.com Reviewed-by: Gary Guo gary@garyguo.net Reviewed-by: Alice Ryhl aliceryhl@google.com Reviewed-by: Björn Roy Baron bjorn3_gh@protonmail.com Link: https://lore.kernel.org/r/20230823160244.188033-3-ojeda@kernel.org [ Used 1.72.1 instead of .0 (no changes in alloc) and reworded to mention that we hit the .eh_frame bug under debug assertions. ] Signed-off-by: Miguel Ojeda ojeda@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org

johnny-mnemonic pushed a commit to linux-ia64/linux-stable-rc that referenced this pull request

Feb 11, 2024

@ojeda

commit ae6df65 upstream.

This is the third upgrade to the Rust toolchain, from 1.71.1 to 1.72.1 (i.e. the latest) [1].

See the upgrade policy [2] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2").

Unstable features

No unstable features (that we use) were stabilized.

Therefore, the only unstable feature allowed to be used outside the kernel crate is still new_uninit, though other code to be upstreamed may increase the list.

Please see [3] for details.

Other improvements

Previously, the compiler could incorrectly generate a .eh_frame section under -Cpanic=abort. We were hitting this bug when debug assertions were enabled (CONFIG_RUST_DEBUG_ASSERTIONS=y) [4]:

  LD      .tmp_vmlinux.kallsyms1
ld.lld: error: <internal>:(.eh_frame) is being placed in '.eh_frame'

Gary fixed the issue in Rust 1.72.0 [5].

Required changes

For the upgrade, the following changes are required:

alloc upgrade and reviewing

The vast majority of changes are due to our alloc fork being upgraded at once.

There are two kinds of changes to be aware of: the ones coming from upstream, which we should follow as closely as possible, and the updates needed in our added fallible APIs to keep them matching the newer infallible APIs coming from upstream.

Instead of taking a look at the diff of this patch, an alternative approach is reviewing a diff of the changes between upstream alloc and the kernel's. This allows to easily inspect the kernel additions only, especially to check if the fallible methods we already have still match the infallible ones in the new version coming from upstream.

Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions.

To apply these approaches, one may follow steps similar to the following to generate a pair of patches that show the differences between upstream Rust and the kernel (for the subset of alloc we use) before and after applying this patch:

# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc

# Apply this patch.
git -C linux am rust-upgrade.patch

# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/alloc

Now one may check the new.patch to take a look at the additions (first approach) or at the difference between those two patches (second approach). For the latter, a side-by-side tool is recommended.

Link: https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1721-2023-09-19 [1] Link: https://rust-for-linux.com/rust-version-policy [2] Link: Rust-for-Linux/linux#2 [3] Closes: Rust-for-Linux/linux#1012 [4] Link: rust-lang/rust#112403 [5] Reviewed-by: Martin Rodriguez Reboredo yakoyoku@gmail.com Reviewed-by: Gary Guo gary@garyguo.net Reviewed-by: Alice Ryhl aliceryhl@google.com Reviewed-by: Björn Roy Baron bjorn3_gh@protonmail.com Link: https://lore.kernel.org/r/20230823160244.188033-3-ojeda@kernel.org [ Used 1.72.1 instead of .0 (no changes in alloc) and reworded to mention that we hit the .eh_frame bug under debug assertions. ] Signed-off-by: Miguel Ojeda ojeda@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org

johnny-mnemonic pushed a commit to linux-ia64/linux-stable-rc that referenced this pull request

Feb 12, 2024

@ojeda

commit ae6df65 upstream.

This is the third upgrade to the Rust toolchain, from 1.71.1 to 1.72.1 (i.e. the latest) [1].

See the upgrade policy [2] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2").

Unstable features

No unstable features (that we use) were stabilized.

Therefore, the only unstable feature allowed to be used outside the kernel crate is still new_uninit, though other code to be upstreamed may increase the list.

Please see [3] for details.

Other improvements

Previously, the compiler could incorrectly generate a .eh_frame section under -Cpanic=abort. We were hitting this bug when debug assertions were enabled (CONFIG_RUST_DEBUG_ASSERTIONS=y) [4]:

  LD      .tmp_vmlinux.kallsyms1
ld.lld: error: <internal>:(.eh_frame) is being placed in '.eh_frame'

Gary fixed the issue in Rust 1.72.0 [5].

Required changes

For the upgrade, the following changes are required:

alloc upgrade and reviewing

The vast majority of changes are due to our alloc fork being upgraded at once.

There are two kinds of changes to be aware of: the ones coming from upstream, which we should follow as closely as possible, and the updates needed in our added fallible APIs to keep them matching the newer infallible APIs coming from upstream.

Instead of taking a look at the diff of this patch, an alternative approach is reviewing a diff of the changes between upstream alloc and the kernel's. This allows to easily inspect the kernel additions only, especially to check if the fallible methods we already have still match the infallible ones in the new version coming from upstream.

Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions.

To apply these approaches, one may follow steps similar to the following to generate a pair of patches that show the differences between upstream Rust and the kernel (for the subset of alloc we use) before and after applying this patch:

# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc

# Apply this patch.
git -C linux am rust-upgrade.patch

# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/alloc

Now one may check the new.patch to take a look at the additions (first approach) or at the difference between those two patches (second approach). For the latter, a side-by-side tool is recommended.

Link: https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1721-2023-09-19 [1] Link: https://rust-for-linux.com/rust-version-policy [2] Link: Rust-for-Linux/linux#2 [3] Closes: Rust-for-Linux/linux#1012 [4] Link: rust-lang/rust#112403 [5] Reviewed-by: Martin Rodriguez Reboredo yakoyoku@gmail.com Reviewed-by: Gary Guo gary@garyguo.net Reviewed-by: Alice Ryhl aliceryhl@google.com Reviewed-by: Björn Roy Baron bjorn3_gh@protonmail.com Link: https://lore.kernel.org/r/20230823160244.188033-3-ojeda@kernel.org [ Used 1.72.1 instead of .0 (no changes in alloc) and reworded to mention that we hit the .eh_frame bug under debug assertions. ] Signed-off-by: Miguel Ojeda ojeda@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org

johnny-mnemonic pushed a commit to linux-ia64/linux-stable-rc that referenced this pull request

Feb 13, 2024

@ojeda

commit ae6df65 upstream.

This is the third upgrade to the Rust toolchain, from 1.71.1 to 1.72.1 (i.e. the latest) [1].

See the upgrade policy [2] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2").

Unstable features

No unstable features (that we use) were stabilized.

Therefore, the only unstable feature allowed to be used outside the kernel crate is still new_uninit, though other code to be upstreamed may increase the list.

Please see [3] for details.

Other improvements

Previously, the compiler could incorrectly generate a .eh_frame section under -Cpanic=abort. We were hitting this bug when debug assertions were enabled (CONFIG_RUST_DEBUG_ASSERTIONS=y) [4]:

  LD      .tmp_vmlinux.kallsyms1
ld.lld: error: <internal>:(.eh_frame) is being placed in '.eh_frame'

Gary fixed the issue in Rust 1.72.0 [5].

Required changes

For the upgrade, the following changes are required:

alloc upgrade and reviewing

The vast majority of changes are due to our alloc fork being upgraded at once.

There are two kinds of changes to be aware of: the ones coming from upstream, which we should follow as closely as possible, and the updates needed in our added fallible APIs to keep them matching the newer infallible APIs coming from upstream.

Instead of taking a look at the diff of this patch, an alternative approach is reviewing a diff of the changes between upstream alloc and the kernel's. This allows to easily inspect the kernel additions only, especially to check if the fallible methods we already have still match the infallible ones in the new version coming from upstream.

Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions.

To apply these approaches, one may follow steps similar to the following to generate a pair of patches that show the differences between upstream Rust and the kernel (for the subset of alloc we use) before and after applying this patch:

# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc

# Apply this patch.
git -C linux am rust-upgrade.patch

# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/alloc

Now one may check the new.patch to take a look at the additions (first approach) or at the difference between those two patches (second approach). For the latter, a side-by-side tool is recommended.

Link: https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1721-2023-09-19 [1] Link: https://rust-for-linux.com/rust-version-policy [2] Link: Rust-for-Linux/linux#2 [3] Closes: Rust-for-Linux/linux#1012 [4] Link: rust-lang/rust#112403 [5] Reviewed-by: Martin Rodriguez Reboredo yakoyoku@gmail.com Reviewed-by: Gary Guo gary@garyguo.net Reviewed-by: Alice Ryhl aliceryhl@google.com Reviewed-by: Björn Roy Baron bjorn3_gh@protonmail.com Link: https://lore.kernel.org/r/20230823160244.188033-3-ojeda@kernel.org [ Used 1.72.1 instead of .0 (no changes in alloc) and reworded to mention that we hit the .eh_frame bug under debug assertions. ] Signed-off-by: Miguel Ojeda ojeda@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org

johnny-mnemonic pushed a commit to linux-ia64/linux-stable-rc that referenced this pull request

Feb 13, 2024

@ojeda @gregkh

commit ae6df65 upstream.

This is the third upgrade to the Rust toolchain, from 1.71.1 to 1.72.1 (i.e. the latest) [1].

See the upgrade policy [2] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2").

Unstable features

No unstable features (that we use) were stabilized.

Therefore, the only unstable feature allowed to be used outside the kernel crate is still new_uninit, though other code to be upstreamed may increase the list.

Please see [3] for details.

Other improvements

Previously, the compiler could incorrectly generate a .eh_frame section under -Cpanic=abort. We were hitting this bug when debug assertions were enabled (CONFIG_RUST_DEBUG_ASSERTIONS=y) [4]:

  LD      .tmp_vmlinux.kallsyms1
ld.lld: error: <internal>:(.eh_frame) is being placed in '.eh_frame'

Gary fixed the issue in Rust 1.72.0 [5].

Required changes

For the upgrade, the following changes are required:

alloc upgrade and reviewing

The vast majority of changes are due to our alloc fork being upgraded at once.

There are two kinds of changes to be aware of: the ones coming from upstream, which we should follow as closely as possible, and the updates needed in our added fallible APIs to keep them matching the newer infallible APIs coming from upstream.

Instead of taking a look at the diff of this patch, an alternative approach is reviewing a diff of the changes between upstream alloc and the kernel's. This allows to easily inspect the kernel additions only, especially to check if the fallible methods we already have still match the infallible ones in the new version coming from upstream.

Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions.

To apply these approaches, one may follow steps similar to the following to generate a pair of patches that show the differences between upstream Rust and the kernel (for the subset of alloc we use) before and after applying this patch:

# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc

# Apply this patch.
git -C linux am rust-upgrade.patch

# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/alloc

Now one may check the new.patch to take a look at the additions (first approach) or at the difference between those two patches (second approach). For the latter, a side-by-side tool is recommended.

Link: https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1721-2023-09-19 [1] Link: https://rust-for-linux.com/rust-version-policy [2] Link: Rust-for-Linux/linux#2 [3] Closes: Rust-for-Linux/linux#1012 [4] Link: rust-lang/rust#112403 [5] Reviewed-by: Martin Rodriguez Reboredo yakoyoku@gmail.com Reviewed-by: Gary Guo gary@garyguo.net Reviewed-by: Alice Ryhl aliceryhl@google.com Reviewed-by: Björn Roy Baron bjorn3_gh@protonmail.com Link: https://lore.kernel.org/r/20230823160244.188033-3-ojeda@kernel.org [ Used 1.72.1 instead of .0 (no changes in alloc) and reworded to mention that we hit the .eh_frame bug under debug assertions. ] Signed-off-by: Miguel Ojeda ojeda@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org

johnny-mnemonic pushed a commit to linux-ia64/linux-stable-rc that referenced this pull request

Feb 14, 2024

@ojeda @gregkh

commit ae6df65 upstream.

This is the third upgrade to the Rust toolchain, from 1.71.1 to 1.72.1 (i.e. the latest) [1].

See the upgrade policy [2] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2").

Unstable features

No unstable features (that we use) were stabilized.

Therefore, the only unstable feature allowed to be used outside the kernel crate is still new_uninit, though other code to be upstreamed may increase the list.

Please see [3] for details.

Other improvements

Previously, the compiler could incorrectly generate a .eh_frame section under -Cpanic=abort. We were hitting this bug when debug assertions were enabled (CONFIG_RUST_DEBUG_ASSERTIONS=y) [4]:

  LD      .tmp_vmlinux.kallsyms1
ld.lld: error: <internal>:(.eh_frame) is being placed in '.eh_frame'

Gary fixed the issue in Rust 1.72.0 [5].

Required changes

For the upgrade, the following changes are required:

alloc upgrade and reviewing

The vast majority of changes are due to our alloc fork being upgraded at once.

There are two kinds of changes to be aware of: the ones coming from upstream, which we should follow as closely as possible, and the updates needed in our added fallible APIs to keep them matching the newer infallible APIs coming from upstream.

Instead of taking a look at the diff of this patch, an alternative approach is reviewing a diff of the changes between upstream alloc and the kernel's. This allows to easily inspect the kernel additions only, especially to check if the fallible methods we already have still match the infallible ones in the new version coming from upstream.

Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions.

To apply these approaches, one may follow steps similar to the following to generate a pair of patches that show the differences between upstream Rust and the kernel (for the subset of alloc we use) before and after applying this patch:

# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc

# Apply this patch.
git -C linux am rust-upgrade.patch

# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/alloc

Now one may check the new.patch to take a look at the additions (first approach) or at the difference between those two patches (second approach). For the latter, a side-by-side tool is recommended.

Link: https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1721-2023-09-19 [1] Link: https://rust-for-linux.com/rust-version-policy [2] Link: Rust-for-Linux/linux#2 [3] Closes: Rust-for-Linux/linux#1012 [4] Link: rust-lang/rust#112403 [5] Reviewed-by: Martin Rodriguez Reboredo yakoyoku@gmail.com Reviewed-by: Gary Guo gary@garyguo.net Reviewed-by: Alice Ryhl aliceryhl@google.com Reviewed-by: Björn Roy Baron bjorn3_gh@protonmail.com Link: https://lore.kernel.org/r/20230823160244.188033-3-ojeda@kernel.org [ Used 1.72.1 instead of .0 (no changes in alloc) and reworded to mention that we hit the .eh_frame bug under debug assertions. ] Signed-off-by: Miguel Ojeda ojeda@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org

johnny-mnemonic pushed a commit to linux-ia64/linux-stable-rc that referenced this pull request

Feb 14, 2024

@ojeda

commit ae6df65 upstream.

This is the third upgrade to the Rust toolchain, from 1.71.1 to 1.72.1 (i.e. the latest) [1].

See the upgrade policy [2] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2").

Unstable features

No unstable features (that we use) were stabilized.

Therefore, the only unstable feature allowed to be used outside the kernel crate is still new_uninit, though other code to be upstreamed may increase the list.

Please see [3] for details.

Other improvements

Previously, the compiler could incorrectly generate a .eh_frame section under -Cpanic=abort. We were hitting this bug when debug assertions were enabled (CONFIG_RUST_DEBUG_ASSERTIONS=y) [4]:

  LD      .tmp_vmlinux.kallsyms1
ld.lld: error: <internal>:(.eh_frame) is being placed in '.eh_frame'

Gary fixed the issue in Rust 1.72.0 [5].

Required changes

For the upgrade, the following changes are required:

alloc upgrade and reviewing

The vast majority of changes are due to our alloc fork being upgraded at once.

There are two kinds of changes to be aware of: the ones coming from upstream, which we should follow as closely as possible, and the updates needed in our added fallible APIs to keep them matching the newer infallible APIs coming from upstream.

Instead of taking a look at the diff of this patch, an alternative approach is reviewing a diff of the changes between upstream alloc and the kernel's. This allows to easily inspect the kernel additions only, especially to check if the fallible methods we already have still match the infallible ones in the new version coming from upstream.

Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions.

To apply these approaches, one may follow steps similar to the following to generate a pair of patches that show the differences between upstream Rust and the kernel (for the subset of alloc we use) before and after applying this patch:

# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc

# Apply this patch.
git -C linux am rust-upgrade.patch

# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/alloc

Now one may check the new.patch to take a look at the additions (first approach) or at the difference between those two patches (second approach). For the latter, a side-by-side tool is recommended.

Link: https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1721-2023-09-19 [1] Link: https://rust-for-linux.com/rust-version-policy [2] Link: Rust-for-Linux/linux#2 [3] Closes: Rust-for-Linux/linux#1012 [4] Link: rust-lang/rust#112403 [5] Reviewed-by: Martin Rodriguez Reboredo yakoyoku@gmail.com Reviewed-by: Gary Guo gary@garyguo.net Reviewed-by: Alice Ryhl aliceryhl@google.com Reviewed-by: Björn Roy Baron bjorn3_gh@protonmail.com Link: https://lore.kernel.org/r/20230823160244.188033-3-ojeda@kernel.org [ Used 1.72.1 instead of .0 (no changes in alloc) and reworded to mention that we hit the .eh_frame bug under debug assertions. ] Signed-off-by: Miguel Ojeda ojeda@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org

johnny-mnemonic pushed a commit to linux-ia64/linux-stable-rc that referenced this pull request

Feb 15, 2024

@ojeda

commit ae6df65 upstream.

This is the third upgrade to the Rust toolchain, from 1.71.1 to 1.72.1 (i.e. the latest) [1].

See the upgrade policy [2] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2").

Unstable features

No unstable features (that we use) were stabilized.

Therefore, the only unstable feature allowed to be used outside the kernel crate is still new_uninit, though other code to be upstreamed may increase the list.

Please see [3] for details.

Other improvements

Previously, the compiler could incorrectly generate a .eh_frame section under -Cpanic=abort. We were hitting this bug when debug assertions were enabled (CONFIG_RUST_DEBUG_ASSERTIONS=y) [4]:

  LD      .tmp_vmlinux.kallsyms1
ld.lld: error: <internal>:(.eh_frame) is being placed in '.eh_frame'

Gary fixed the issue in Rust 1.72.0 [5].

Required changes

For the upgrade, the following changes are required:

alloc upgrade and reviewing

The vast majority of changes are due to our alloc fork being upgraded at once.

There are two kinds of changes to be aware of: the ones coming from upstream, which we should follow as closely as possible, and the updates needed in our added fallible APIs to keep them matching the newer infallible APIs coming from upstream.

Instead of taking a look at the diff of this patch, an alternative approach is reviewing a diff of the changes between upstream alloc and the kernel's. This allows to easily inspect the kernel additions only, especially to check if the fallible methods we already have still match the infallible ones in the new version coming from upstream.

Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions.

To apply these approaches, one may follow steps similar to the following to generate a pair of patches that show the differences between upstream Rust and the kernel (for the subset of alloc we use) before and after applying this patch:

# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc

# Apply this patch.
git -C linux am rust-upgrade.patch

# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/alloc

Now one may check the new.patch to take a look at the additions (first approach) or at the difference between those two patches (second approach). For the latter, a side-by-side tool is recommended.

Link: https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1721-2023-09-19 [1] Link: https://rust-for-linux.com/rust-version-policy [2] Link: Rust-for-Linux/linux#2 [3] Closes: Rust-for-Linux/linux#1012 [4] Link: rust-lang/rust#112403 [5] Reviewed-by: Martin Rodriguez Reboredo yakoyoku@gmail.com Reviewed-by: Gary Guo gary@garyguo.net Reviewed-by: Alice Ryhl aliceryhl@google.com Reviewed-by: Björn Roy Baron bjorn3_gh@protonmail.com Link: https://lore.kernel.org/r/20230823160244.188033-3-ojeda@kernel.org [ Used 1.72.1 instead of .0 (no changes in alloc) and reworded to mention that we hit the .eh_frame bug under debug assertions. ] Signed-off-by: Miguel Ojeda ojeda@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org

johnny-mnemonic pushed a commit to linux-ia64/linux-stable-rc that referenced this pull request

Feb 15, 2024

@ojeda @gregkh

commit ae6df65 upstream.

This is the third upgrade to the Rust toolchain, from 1.71.1 to 1.72.1 (i.e. the latest) [1].

See the upgrade policy [2] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2").

Unstable features

No unstable features (that we use) were stabilized.

Therefore, the only unstable feature allowed to be used outside the kernel crate is still new_uninit, though other code to be upstreamed may increase the list.

Please see [3] for details.

Other improvements

Previously, the compiler could incorrectly generate a .eh_frame section under -Cpanic=abort. We were hitting this bug when debug assertions were enabled (CONFIG_RUST_DEBUG_ASSERTIONS=y) [4]:

  LD      .tmp_vmlinux.kallsyms1
ld.lld: error: <internal>:(.eh_frame) is being placed in '.eh_frame'

Gary fixed the issue in Rust 1.72.0 [5].

Required changes

For the upgrade, the following changes are required:

alloc upgrade and reviewing

The vast majority of changes are due to our alloc fork being upgraded at once.

There are two kinds of changes to be aware of: the ones coming from upstream, which we should follow as closely as possible, and the updates needed in our added fallible APIs to keep them matching the newer infallible APIs coming from upstream.

Instead of taking a look at the diff of this patch, an alternative approach is reviewing a diff of the changes between upstream alloc and the kernel's. This allows to easily inspect the kernel additions only, especially to check if the fallible methods we already have still match the infallible ones in the new version coming from upstream.

Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions.

To apply these approaches, one may follow steps similar to the following to generate a pair of patches that show the differences between upstream Rust and the kernel (for the subset of alloc we use) before and after applying this patch:

# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc

# Apply this patch.
git -C linux am rust-upgrade.patch

# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/alloc

Now one may check the new.patch to take a look at the additions (first approach) or at the difference between those two patches (second approach). For the latter, a side-by-side tool is recommended.

Link: https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1721-2023-09-19 [1] Link: https://rust-for-linux.com/rust-version-policy [2] Link: Rust-for-Linux/linux#2 [3] Closes: Rust-for-Linux/linux#1012 [4] Link: rust-lang/rust#112403 [5] Reviewed-by: Martin Rodriguez Reboredo yakoyoku@gmail.com Reviewed-by: Gary Guo gary@garyguo.net Reviewed-by: Alice Ryhl aliceryhl@google.com Reviewed-by: Björn Roy Baron bjorn3_gh@protonmail.com Link: https://lore.kernel.org/r/20230823160244.188033-3-ojeda@kernel.org [ Used 1.72.1 instead of .0 (no changes in alloc) and reworded to mention that we hit the .eh_frame bug under debug assertions. ] Signed-off-by: Miguel Ojeda ojeda@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org

Whissi pushed a commit to Whissi/linux-stable that referenced this pull request

Feb 16, 2024

@ojeda @gregkh

commit ae6df65 upstream.

This is the third upgrade to the Rust toolchain, from 1.71.1 to 1.72.1 (i.e. the latest) [1].

See the upgrade policy [2] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2").

Unstable features

No unstable features (that we use) were stabilized.

Therefore, the only unstable feature allowed to be used outside the kernel crate is still new_uninit, though other code to be upstreamed may increase the list.

Please see [3] for details.

Other improvements

Previously, the compiler could incorrectly generate a .eh_frame section under -Cpanic=abort. We were hitting this bug when debug assertions were enabled (CONFIG_RUST_DEBUG_ASSERTIONS=y) [4]:

  LD      .tmp_vmlinux.kallsyms1
ld.lld: error: <internal>:(.eh_frame) is being placed in '.eh_frame'

Gary fixed the issue in Rust 1.72.0 [5].

Required changes

For the upgrade, the following changes are required:

alloc upgrade and reviewing

The vast majority of changes are due to our alloc fork being upgraded at once.

There are two kinds of changes to be aware of: the ones coming from upstream, which we should follow as closely as possible, and the updates needed in our added fallible APIs to keep them matching the newer infallible APIs coming from upstream.

Instead of taking a look at the diff of this patch, an alternative approach is reviewing a diff of the changes between upstream alloc and the kernel's. This allows to easily inspect the kernel additions only, especially to check if the fallible methods we already have still match the infallible ones in the new version coming from upstream.

Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions.

To apply these approaches, one may follow steps similar to the following to generate a pair of patches that show the differences between upstream Rust and the kernel (for the subset of alloc we use) before and after applying this patch:

# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc

# Apply this patch.
git -C linux am rust-upgrade.patch

# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/alloc

Now one may check the new.patch to take a look at the additions (first approach) or at the difference between those two patches (second approach). For the latter, a side-by-side tool is recommended.

Link: https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1721-2023-09-19 [1] Link: https://rust-for-linux.com/rust-version-policy [2] Link: Rust-for-Linux/linux#2 [3] Closes: Rust-for-Linux/linux#1012 [4] Link: rust-lang/rust#112403 [5] Reviewed-by: Martin Rodriguez Reboredo yakoyoku@gmail.com Reviewed-by: Gary Guo gary@garyguo.net Reviewed-by: Alice Ryhl aliceryhl@google.com Reviewed-by: Björn Roy Baron bjorn3_gh@protonmail.com Link: https://lore.kernel.org/r/20230823160244.188033-3-ojeda@kernel.org [ Used 1.72.1 instead of .0 (no changes in alloc) and reworded to mention that we hit the .eh_frame bug under debug assertions. ] Signed-off-by: Miguel Ojeda ojeda@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org

This was referenced

Jul 22, 2024

Labels

S-waiting-on-bors

Status: Waiting on bors to run and complete tests. Bors will change the label on completion.

T-compiler

Relevant to the compiler team, which will review and decide on the PR/issue.