This creates a more centralized way for nvproxy to return errors to the the
user mode driver via the NvStatus field in ioctl structs. As opposed to failing
the ioctl with mysterious EINVALs.
Also updated the following structs to NOT implement HasStatus interface:
- IoctlRegisterFD
- RMAPIVersion
- IoctlSysParams
These don't have a Status field so it is misleading for them to implement
HasStatus. Created frontendIoctlSimpleNoStatus() and
frontendIoctlInvokeNoStatus() for such structs to use.
PiperOrigin-RevId: 738959856
The following command does not report any changes in the structs we proxy:
```
make run TARGETS=//tools/nvidia_driver_differ:run_differ \
ARGS="--base 570.86.15 --next 570.124.06"
```
PiperOrigin-RevId: 738093448
Call dumpAndPanicSyscallError for the rare case where we fail to kill the the
Sentry upon detecting an unexpected stub exit. This will provide enough
information determine if a panic occur due to failed SIGKILL attempt or an
unexpected event.
PiperOrigin-RevId: 737751257
From man TIOCPKT:
"""
In packet mode, each subsequent read(2) will return a packet that either
contains a single nonzero control byte, or has a single byte containing zero
('\0') followed by data written on the slave side of the pseudoterminal."
"""
This CL implements only the data portion of packet mode, not the control bytes,
but that seems to be enough to get xfce4-terminal to work.
PiperOrigin-RevId: 737175092
Before this change, host-backed event FDs would always crash the sandbox
during exit when the sentry tried to wait on the fdnotifier for an FD that
wasn't there.
PiperOrigin-RevId: 736585573
Previously, CheckChange (corresponding to Linux's tty/tty_check_change()) was
only used the host TTY implementation, not the devpts implementation.
Furthermore, ThreadGroup.SetForegroundProcessGroup() duplicated some of the
logic in CheckChange, notably sending SIGTTOU to background tasks. This means
that, for host TTYs, we could send SIGTTOU multiple times. In some
circumstances, this leads the ioctl returning ERESTARTSYS in an infinite loop.
PiperOrigin-RevId: 735934036
This can be used by all test users. Avoids duplicated code. We can handle all
known issues in one place.
There is a Docker bug which causes restore to fail sporadically. See
https://github.com/moby/moby/issues/42900. This has been broken at least since
Docker v19.03.12 (when the issue was reported) and was fixed in v25.0.4. Added
the handling for this issue.
Also got rid of the testutil.Poll() around restore. That can hide gVisor
restore flakiness issues. That was added in 0990ef7517 ("Make
checkpoint/restore e2e test less flaky"). The original sleep has been restored.
PiperOrigin-RevId: 734303878
As of https://go.dev/cl/646095, the Go runtime calls
prctl(PR_SET_VMA, PR_SET_VMA_ANON_NAME) when mapping memory to annotate
mappings in /proc/self/maps. Since this is a system call made throughout the
application lifetime, it needs to be allowed through the system call filters.
PiperOrigin-RevId: 734182524
During checkpointing, MemoryFile.SaveTo() narrows the set of pages known by
memory accounting to be "committed" to those containing non-zero bytes, in
order to avoid saving zero pages and therefore bloating the checkpoint. In the
process of doing so, it needs to touch pages in order to determine whether they
contain non-zero bytes, and does so without holding MemoryFile.mu (in a
MemoryFile.updateUsageLocked() callback). Thus, a concurrent call to
MemoryFile.UpdateUsage() => MemoryFile.updateUsageLocked() can racily observe
that touched zero pages are committed (via mincore()) and mark them
known-committed accordingly, causing them to be unintentionally saved in the
checkpoint.
When SaveOpts.ExcludeCommittedZeroPages is set, MemoryFile.SaveTo() does not
decommit previously-known-committed zero pages, since doing so would cost time;
the motivation for decommitting zero pages is to avoid increasing (real, host)
memory usage during checkpointing, but previously-known-committed pages must
have been using memory even before being touched. However, this significantly
widens the race window described above, since any future call to
MemoryFile.UpdateUsage() will observe said pages to be committed and mark them
known-committed again, effectively negating SaveOpts.ExcludeCommittedZeroPages.
To fix this, inhibit MemoryFile.UpdateUsage() during MemoryFile.SaveTo(); in
essence, when MemoryFile.SaveTo() is in progress, it exclusively defines what
pages are known-committed.
PiperOrigin-RevId: 733876220
Lucas Manning
gVisor bot
Ayush Ranjan
Jamie Liu
Jimmy Tran
Nicolas Lacasse
Nayana Bidari
Fabricio Voznika
Michael Pratt