-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
[WIP] use go 1.22 #4262
[WIP] use go 1.22 #4262
Conversation
b19fa35
to
3b2e786
Compare
@lifubang can you please create a separate PR for "use go mod instead of go get in spec.bats"? We can merge it right now, less stuff to review later. |
|
02c487b
to
4e2e957
Compare
Needs rebase |
Signed-off-by: lifubang <lifubang@acmcoder.com> Signed-off-by: lfbzhm <lifubang@acmcoder.com>
This reverts commit ac31da6. Signed-off-by: lifubang <lifubang@acmcoder.com> Signed-off-by: lfbzhm <lifubang@acmcoder.com>
This reverts commit e377e16. Signed-off-by: lifubang <lifubang@acmcoder.com> Signed-off-by: lfbzhm <lifubang@acmcoder.com>
0705b2f
to
e139be2
Compare
e139be2
to
cb1b2dd
Compare
Every tests are passed except unit test in centos7, I have no idea about this, could someone help me to figure out the reason.
|
Since glibc 2.25, the thread-local cache of the current TID is no longer updated in the child when calling clone(2). This results in very unfortunate behaviour when Go does pthread calls using pthread_self(), which has the wrong TID stored. The "simple" solution is to forcefully overwrite this cached value. Unfortunately (and unsurprisingly), the layout of "struct pthread" is strictly private and could change without warning. Luckily, glibc (currently) uses CLONE_CHILD_CLEARTID for all forks (with the child_tid set to the cached &PTHREAD_SELF->tid), meaning that as long as runc is using glibc, when "runc init" is spawned the child process will have a pointer directly to the cached value we want to change. With CONFIG_CHECKPOINT_RESTORE=y kernels on Linux 3.5 and later, we can simply use prctl(PR_GET_TID_ADDRESS). For older kernels we need to memory scan the TLS structure (pthread_self() is a pointer to the head of the TLS structure). However, to avoid false positives we first try known-correct offsets based on the current structure layouts. If that fails, we scan the 1K block for any fields that might match. When doing the scan, we assume that the first field we find that contains the actual TID of the current process is the field we want. Obviously this is all very horrific, and if you are reading this in the future, it almost certainly has caused some horrific bug that I did not forsee. Sorry about that. As far as I can tell, there is no other workable solution that doesn't also depend on the CLONE_CHILD_CLEARTID behaviour of glibc in some way. We cannot "just" do a re-exec after clone(2) for security reasons. Sadly, this is all glibc-specific. musl doesn't even allow you to use CLONE_CHILD_CLEARTID (and they use a different address for the TID anyway). We could do the memory scan and manually overwrite the address after clone(2), but we can deal with that in the future if it turns out people use non-glibc builds and need this fix. Signed-off-by: Aleksa Sarai <cyphar@cyphar.com> (cherry picked from commit b0654c7) Signed-off-by: lifubang <lifubang@acmcoder.com> Signed-off-by: lfbzhm <lifubang@acmcoder.com>
scan in pthread Signed-off-by: lfbzhm <lifubang@acmcoder.com>
cb1b2dd
to
950ff28
Compare
Signed-off-by: lfbzhm <lifubang@acmcoder.com>
There are some bugs in centos7, let's close this one. |
An alternative to #4193.
As @cyphar has indicated that we can rewrite the tid field of struct pthread through
CLONE_CHILD_SETTID | CLONE_CHILD_CLEARTID
, but first of all, we should find out the tid field's address of the struct pthread. Unfortunatelly, struct pthread wasn't export topthread.h
in glibc, so we shouldprctl(PR_GET_TID_ADDRESS)
orpthread_t
to get or scan the tid field's address.To scan it from
pthread_t
, @cyphar wants to write out the struct pthread accordding glibc's code, because the code of this struct has no changes for about twenty years. But I think it is hard to review, and we should change runc code once struct pthread changed. I propose to use another way to find out it by scanning the memory of two threads, because: