Kernel: Adjustments to unsafe code - #2600
Merged
Merged
Conversation
Contributor
Author
labbott
reviewed
Jul 17, 2026
hawkw
reviewed
Jul 17, 2026
aapoalas
reviewed
Jul 17, 2026
aapoalas
left a comment
Contributor
There was a problem hiding this comment.
Please excuse my unrequested comments; the topic called out to me.
hawkw
reviewed
Jul 17, 2026
This was referenced Jul 20, 2026
jamesmunns
added a commit
that referenced
this pull request
Aug 6, 2026
also add a contrasting comment vs static-cell Similar to #2600.
Contributor
Author
labbott
approved these changes
Aug 14, 2026
labbott
left a comment
Collaborator
There was a problem hiding this comment.
thought I already approved it whoops
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.

The following is a number of tweaks to the kernel code that in my opinion, make some of the unsafe code a bit more direct to follow. In particular, these changes:
switch_toas a single method onTask, rather than one version insyscalls.rs, and a handful of semantically-equal copy/pastesascasts as is reasonable, e.g.x as *const _ as *mut _, replacing them with discrete steps that note the implicit casts (references to pointer), and explicit casts, usingptr::cast()unsafeusage a bit instartupwhen initializing each task slot&mut Taskinstead of&Task, as these are used for settingCURRENT_TASK_PTR, which semantically allows us to write-through to that address (often in assembly) when returning to the kernel, and that feels a little sketch to me doing from a pointer with shared provenanceMaybeUninit<[Task; N]>to[MaybeUninit<Task>; N], as this makes startup a little less awkwardIn my opinion, none of these are strictly necessary for soundness, so if we don't want to touch it, I could definitely understand that!
I think 1, 2, and 3 are pretty clear readability/clarity wins.
I think 4 is maybe a little nitpicky, and is a bit more semantically correct, but also unlikely to cause miscompilations in practice.
I think 5 is maybe a mixed bag (we can still make the changes for 3 without 5), and I need to check it isn't going to make
humilityupset as the types have changed (even though the before/after are guaranteed to have the same layout and semantics).Happy to revert any chunks, or rework these into separate commits if that makes reviewing easier.
This is extracted from #2592, and most of these were noticed while I was hacking around on that.