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

[Carry #3985 Part I] code refactor for process sync #4003

Merged
merged 2 commits into from
Oct 3, 2023

Conversation

lifubang
Copy link
Member

@lifubang lifubang commented Aug 31, 2023

Although we can review #3985 commit by commit, but I think these two commits are not related to mount login. If we merge these two commits first, it will be more easier to review #3985 .

I don't change any code in these tow commits.
After this carry merged, I'll carry the commit about /proc/thread-self.

The part carries two changes:

  1. sync: rename procResume -> procHooksDone

  2. sync: split init config (stream) and synchronisation (seqpacket) pipes:
    We have different requirements for the initial configuration and initWaiter pipe (just send netlink and JSON blobs with no complicated handling needed for message coalescing) and the packet-based synchronisation pipe.
    Tests with switching everything to SOCK_SEQPACKET lead to endless issues with runc hanging on start-up because random things would try to do short reads (which SOCK_SEQPACKET will not allow and the Go stdlib explicitly treats as a streaming source), so splitting it was the only reasonable solution. Even doing somewhat dodgy tricks such as adding a Read() wrapper which actually calls ReadPacket() and makes it seem like a stream source doesn't work -- and is a bit too magical.
    One upside is that doing it this way makes the difference between the modes clearer -- INITPIPE is still used for initWaiter syncrhonisation but aside from that all other synchronisation is done by SYNCPIPE.

Copy link
Contributor

@kolyshkin kolyshkin left a comment

Choose a reason for hiding this comment

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

@lifubang thanks for carrying; it is indeed easier to review it this way.

LGTM

@kolyshkin
Copy link
Contributor

@AkihiroSuda @thaJeztah @mrunalp PTAL

@kolyshkin kolyshkin added this to the 1.2.0 milestone Sep 21, 2023
@AkihiroSuda
Copy link
Member

Needs rebase

The old name was quite confusing, and with the addition of the
procMountPlease sync message there are now multiple sync messages that
are related to "resuming" runc-init.

Signed-off-by: Aleksa Sarai <[email protected]>
We have different requirements for the initial configuration and
initWaiter pipe (just send netlink and JSON blobs with no complicated
handling needed for message coalescing) and the packet-based
synchronisation pipe.

Tests with switching everything to SOCK_SEQPACKET lead to endless issues
with runc hanging on start-up because random things would try to do
short reads (which SOCK_SEQPACKET will not allow and the Go stdlib
explicitly treats as a streaming source), so splitting it was the only
reasonable solution. Even doing somewhat dodgy tricks such as adding a
Read() wrapper which actually calls ReadPacket() and makes it seem like
a stream source doesn't work -- and is a bit too magical.

One upside is that doing it this way makes the difference between the
modes clearer -- INITPIPE is still used for initWaiter syncrhonisation
but aside from that all other synchronisation is done by SYNCPIPE.

Signed-off-by: Aleksa Sarai <[email protected]>
@lifubang
Copy link
Member Author

Needs rebase

Done, PTAL

@kolyshkin
Copy link
Contributor

@cyphar I guess we can merge it and rebase #3985, wdyt?

@kolyshkin kolyshkin merged commit f56b007 into opencontainers:main Oct 3, 2023
45 checks passed
@kolyshkin kolyshkin mentioned this pull request Oct 4, 2023
@lifubang lifubang deleted the carry3985-01-syncPipe branch October 15, 2024 05:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants