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 }})
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
.
(rustbot has picked a reviewer for you, use r? to override)
rustbot added S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
Relevant to the compiler team, which will review and decide on the PR/issue.
labels
Some changes occurred to MIR optimizations
cc @rust-lang/wg-mir-opt
ojeda mentioned this pull request
56 tasks
Thanks @nbdd0121 for taking such a quick look at it.
@@ -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. :)
ojeda mentioned this pull request
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+
📌 Commit d9531a0 has been approved by Nilstrieb
It is now in the queue for this repository.
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
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.
Also my second UB-checking pass is here: #104862
bors added a commit to rust-lang-ci/rust that referenced this pull request
…llaumeGomez
Rollup of 8 pull requests
Successful merges:
- rust-lang#112403 (Prevent
.eh_frame
from being emitted for-C panic=abort
) - rust-lang#112517 (
suspicious_double_ref_op
: don't lint on.borrow()
) - rust-lang#112529 (Extend
unused_must_use
to cover block exprs) - rust-lang#112614 (tweak suggestion for argument-position
impl ?Sized
) - rust-lang#112654 (normalize closure output in equate_inputs_and_outputs)
- rust-lang#112660 (Migrate GUI colors test to original CSS color format)
- rust-lang#112664 (Add support for test tmpdir to fuchsia test runner)
- rust-lang#112669 (Fix comment for ptr alignment checks in codegen)
r? @ghost
@rustbot
modify labels: rollup
bors added a commit to rust-lang-ci/rust that referenced this pull request
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:
RemoveNoopLandingPads
currently unconditionally introduce a resume block (even there is none to begin with!), changed to not do that- Generator state transform introduces a
assert
which may unwind, and its drop elaboration also introduces many newUnwindAction
s, so in this case run the AbortUnwindingCalls after the transformation.
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
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:
RemoveNoopLandingPads
currently unconditionally introduce a resume block (even there is none to begin with!), changed to not do that- Generator state transform introduces a
assert
which may unwind, and its drop elaboration also introduces many newUnwindAction
s, so in this case run the AbortUnwindingCalls after the transformation.
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
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:
- A call to
Box::from_raw
inrust/kernel/sync/arc.rs
now requires an explicitdrop()
call. See previous patch for details.
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
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:
- A call to
Box::from_raw
inrust/kernel/sync/arc.rs
now requires an explicitdrop()
call. See previous patch for details.
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
1715173329 added a commit to 1715173329/packages-official that referenced this pull request
fbq pushed a commit to Rust-for-Linux/linux that referenced this pull request
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:
- A call to
Box::from_raw
inrust/kernel/sync/arc.rs
now requires an explicitdrop()
call. See previous patch for details.
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
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:
- A call to
Box::from_raw
inrust/kernel/sync/arc.rs
now requires an explicitdrop()
call. See previous patch for details.
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
BKPepe pushed a commit to openwrt/packages that referenced this pull request
wip-sync pushed a commit to NetBSD/pkgsrc-wip that referenced this pull request
fbq pushed a commit to Rust-for-Linux/linux that referenced this pull request
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:
- A call to
Box::from_raw
inrust/kernel/sync/arc.rs
now requires an explicitdrop()
call. See previous patch for details.
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
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:
- A call to
Box::from_raw
inrust/kernel/sync/arc.rs
now requires an explicitdrop()
call. See previous patch for details.
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
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:
- A call to
Box::from_raw
inrust/kernel/sync/arc.rs
now requires an explicitdrop()
call. See previous patch for details.
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
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:
- A call to
Box::from_raw
inrust/kernel/sync/arc.rs
now requires an explicitdrop()
call. See previous patch for details.
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
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:
- A call to
Box::from_raw
inrust/kernel/sync/arc.rs
now requires an explicitdrop()
call. See previous patch for details.
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
hmtheboy154 pushed a commit to hmtheboy154/Darkmatter-kernel that referenced this pull request
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:
- A call to
Box::from_raw
inrust/kernel/sync/arc.rs
now requires an explicitdrop()
call. See previous patch for details.
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
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:
- A call to
Box::from_raw
inrust/kernel/sync/arc.rs
now requires an explicitdrop()
call. See previous patch for details.
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
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:
- A call to
Box::from_raw
inrust/kernel/sync/arc.rs
now requires an explicitdrop()
call. See previous patch for details.
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
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:
- A call to
Box::from_raw
inrust/kernel/sync/arc.rs
now requires an explicitdrop()
call. See previous patch for details.
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
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:
- A call to
Box::from_raw
inrust/kernel/sync/arc.rs
now requires an explicitdrop()
call. See previous patch for details.
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
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:
- A call to
Box::from_raw
inrust/kernel/sync/arc.rs
now requires an explicitdrop()
call. See previous patch for details.
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
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:
- A call to
Box::from_raw
inrust/kernel/sync/arc.rs
now requires an explicitdrop()
call. See previous patch for details.
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
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:
- A call to
Box::from_raw
inrust/kernel/sync/arc.rs
now requires an explicitdrop()
call. See previous patch for details.
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
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:
- A call to
Box::from_raw
inrust/kernel/sync/arc.rs
now requires an explicitdrop()
call. See previous patch for details.
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
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:
- A call to
Box::from_raw
inrust/kernel/sync/arc.rs
now requires an explicitdrop()
call. See previous patch for details.
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
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:
- A call to
Box::from_raw
inrust/kernel/sync/arc.rs
now requires an explicitdrop()
call. See previous patch for details.
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
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Relevant to the compiler team, which will review and decide on the PR/issue.