It is an idea of running codespell as part of our presubmit checks.
Before enabling it for new changes, let's fix what it has found.
Signed-off-by: Andrei Vagin <avagin@gmail.com>
"procid" implies "process ID", "processor (CPU?) ID", or "`runtime.p.id`". It
is none of these things. Instead, `procid.Current()` returns the caller's host
thread ID; almost every caller relies on this property. Rename the package
accordingly.
Nit: Replace "system thread identifier" with "host thread ID". "System" is
needlessly vague in a setting where many callers will also have an unrelated
application thread ID, and "identifier" is a guess at what is abbreviated by
"thread ID" - but cf. gettid(2), "NAME: gettid - get thread identification".
PiperOrigin-RevId: 507034135
Since `arch.Context64` is the only concrete implementation of
`arch.Context`, this does not functionally change anything.
While `arch.Context64` *can* mean multiple things in the codebase, since
the `arch` module uses conditional compilation to create different builds
for AMD64 vs ARM64, the `Context64` type is still singular within each
possible version this can compile to.
This avoids the overhead involved in calling interface
functions in Go:
https://github.com/teh-cmc/go-internals/blob/master/chapter2_interfaces/README.md#dynamic-dispatch
This overhead is particularly painful for functions like `SyscallSaveOrig`
which is a no-op on AMD64.
On KVM, this reduces syscall latency by 4~5%:
```
name old wall_ns/op new wall_ns/op delta
Getpid 602 ± 4% 579 ± 3% -3.94% (p=0.000 n=66+195)
GetpidOpt 604 ± 3% 573 ± 3% -5.10% (p=0.000 n=71+194)
name old cpu_ns/op new cpu_ns/op delta
Getpid 604 ± 5% 581 ± 0% -3.81% (p=0.000 n=75+130)
GetpidOpt 604 ± 2% 574 ± 3% -4.95% (p=0.000 n=71+196)
```
PiperOrigin-RevId: 461742893
Split usermem package to help remove syserror dependency in go_marshal.
New hostarch package contains code not dependent on syserror.
PiperOrigin-RevId: 365651233
The syscall package has been deprecated in favor of golang.org/x/sys.
Note that syscall is still used in the following places:
- pkg/sentry/socket/hostinet/stack.go: some netlink related functionalities
are not yet available in golang.org/x/sys.
- syscall.Stat_t is still used in some places because os.FileInfo.Sys() still
returns it and not unix.Stat_t.
Updates #214
PiperOrigin-RevId: 360701387
On ARM64, when ptrace stops on a system call, it uses the x7 register to
indicate whether the stop has been signalled from syscall entry or syscall
exit. This means that we can't get a value of this register and we can't change
it. More details are in the comment for tracehook_report_syscall in
arch/arm64/kernel/ptrace.c.
This happens only if we stop on a system call, so let's queue a signal, resume
a stub thread and catch it on a signal handling.
Fixes: #5238
PiperOrigin-RevId: 352668695
Linux use the task.thread.uw.tp_value field to store the
TLS pointer on arm64 platform, and we use a similar way
in gvisor to store it in the arch/State struct.
Signed-off-by: Haibo Xu <haibo.xu@arm.com>
Change-Id: Ie76b5c6d109bc27ccfd594008a96753806db7764
Because the abi will depend on the core types for marshalling (usermem,
context, safemem, safecopy), these need to be flattened from the sentry
directory. These packages contain no sentry-specific details.
PiperOrigin-RevId: 291811289
* Rename syncutil to sync.
* Add aliases to sync types.
* Replace existing usage of standard library sync package.
This will make it easier to swap out synchronization primitives. For example,
this will allow us to use primitives from github.com/sasha-s/go-deadlock to
check for lock ordering violations.
Updates #1472
PiperOrigin-RevId: 289033387
Right now, we need to call ptrace(PTRACE_SYSCALL) and wait() twice to execute
one system call in a stub process. With these changes, we will need to call
ptrace + wait only once.
In addition, this allows to workaround the kernel bug when a stub process
doesn't stop on syscall-exit-stop and starts executing the next system call.
Reported-by: syzbot+37143cafa8dc3b5008ee@syzkaller.appspotmail.com
PiperOrigin-RevId: 288393029
Linux PTRACE_SYSEMU support on arm64 was merged to mainline from
V5.3, and the corresponding support in go also enabled recently.
Since the "syscall" package is locked down from go 1.4, so the ptrace
PTRACE_SYSEMU definition can't be added to package "syscall" on arm64.
According to the golang community, updates required by new systems or
versions should use the corresponding package in the golang.org/x/sys
repository instead(https://golang.org/pkg/syscall/).
Signed-off-by: Haibo Xu <haibo.xu@arm.com>
Change-Id: I2f917bb2be62f990c3e158e2bb99e094ea03f751
Andrei VaginandgVisor bot
Jamie LiuandgVisor bot
Andrei Vagin
Etienne PerotandgVisor bot
Adin ScannellandgVisor bot
Ayush RanjanandgVisor bot
Zach KoopmansandgVisor bot
Rahat MahmoodandgVisor bot
Haibo Xu
Ian GudgerandgVisor bot