Skip to content
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 and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Kernel: Make the shutdown procedure infallible #20786

Conversation

supercomputer7
Copy link
Member

@supercomputer7 supercomputer7 marked this pull request as draft August 26, 2023 11:33
@github-actions github-actions bot added 👀 pr-needs-review PR needs review from a maintainer or community member and removed 👀 pr-needs-review PR needs review from a maintainer or community member labels Aug 26, 2023
@supercomputer7 supercomputer7 marked this pull request as ready for review August 26, 2023 13:26
@github-actions github-actions bot added the 👀 pr-needs-review PR needs review from a maintainer or community member label Aug 26, 2023
@stale
Copy link

stale bot commented Sep 24, 2023

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions!

@stale stale bot added the stale label Sep 24, 2023
This new template will be used for variables that are expected to be
written only once during the whole kernel lifetime, but to be read
multiple times without inducing heavy locking penalties.
This is done by making the power state switch code to rely on a process
that is always alive, initially started during boot.
Other functions are infallible as well - such as the procedure to kill
all user processes, so now they're marked as such.
We do this by simplifying the unmounting code during the shutdown
procedure to a great extent, so only the actual last call on unmount for
each Mount could fail, but still will not stop the procedure from moving
forward with the rest of the shutdown sequence.
@stale
Copy link

stale bot commented Oct 15, 2023

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions!

@stale stale bot added the stale label Oct 15, 2023
@stale
Copy link

stale bot commented Oct 22, 2023

This pull request has been closed because it has not had recent activity. Feel free to re-open if you wish to still contribute these changes. Thank you for your contributions!

@stale stale bot closed this Oct 22, 2023
@github-actions github-actions bot removed the 👀 pr-needs-review PR needs review from a maintainer or community member label Oct 22, 2023
@stale stale bot removed the stale label Oct 22, 2023
@github-actions github-actions bot added the 👀 pr-needs-review PR needs review from a maintainer or community member label Oct 22, 2023

static constexpr StringView power_management_task_name = "Power Management Task"sv;
Thread* g_power_management_task_thread;
WritableOnce<PowerStateCommand> g_power_management_task_command { PowerStateCommand::None };
Copy link
Member

Choose a reason for hiding this comment

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

Is this truly Writeable once? I could foresee us wanting to do suspend/resume as well in the future.

Copy link
Member Author

Choose a reason for hiding this comment

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

Sure, but for now we don't support these things, so maybe a FIXME is sufficient for now?

Copy link
Member Author

Choose a reason for hiding this comment

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

I have something in place to fix this in a better way :)

Comment on lines +351 to +352
// NOTE: This is balanced by a `new` statement that is happening in various places before inserting the Mount object to the list.
delete &mount;
Copy link
Member

Choose a reason for hiding this comment

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

"new that is happening in various places" :/ . This code is a bit smelly. Deleting a reference is not very idiomatic.

Can we centralize where the allocation and deletion happens so that we don't have funky lifetimes?

return stack;
}

ErrorOr<void> VirtualFileSystem::unmount_all(Badge<PowerManagementTask>)
Copy link
Member

Choose a reason for hiding this comment

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

So... why is it ok to continue on with shutdown after the first filesystem fails to unmount? This code as written will not try to unmount every FS at least once. it always bails on the first error.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Huh, I missed that. Definitely should try unmounting everything, since we’ve had bugs in the past with non-unmountable file systems.

Copy link

stale bot commented Nov 26, 2023

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions!

@stale stale bot added the stale label Nov 26, 2023
Copy link

stale bot commented Jan 6, 2024

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions!

@stale stale bot added the stale label Jan 6, 2024
Copy link

stale bot commented Feb 9, 2024

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions!

@stale stale bot added the stale label Feb 9, 2024
@supercomputer7 supercomputer7 added ⛔️ pr-is-blocked PR is blocked by something outside of the author's control, protected from stalebot and removed stale labels Feb 9, 2024
@supercomputer7
Copy link
Member Author

PR is blocked now on #22968.
That PR will make it so much nicer to deal with the shutdown procedure in my opinion, so that we should wait until I get that done first.

@supercomputer7 supercomputer7 marked this pull request as draft February 9, 2024 16:24
@github-actions github-actions bot removed 👀 pr-needs-review PR needs review from a maintainer or community member ⛔️ pr-is-blocked PR is blocked by something outside of the author's control, protected from stalebot labels Feb 9, 2024
@supercomputer7 supercomputer7 added the ⛔️ pr-is-blocked PR is blocked by something outside of the author's control, protected from stalebot label Feb 9, 2024
Copy link

stale bot commented Mar 3, 2024

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions!

@stale stale bot added the stale label Mar 3, 2024
Copy link

stale bot commented Mar 31, 2024

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions!

@stale stale bot added the stale label Mar 31, 2024
@supercomputer7
Copy link
Member Author

I am not sure this is necessary when we actually merge #22968, so until I figure out what to do next, let's close this :)

@github-actions github-actions bot removed the ⛔️ pr-is-blocked PR is blocked by something outside of the author's control, protected from stalebot label Apr 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants