There is a race in the test between WritePacketToRemote and FindFDBEntry, even
though it rarely happens, we just enforce FindFDBEntry to wait for
WritePacketToRemote's completion here.
PiperOrigin-RevId: 721747159
It happens along with the other issue when the veth device buffer is full,
then the task is stuck and still have the bridge's lock (RLock) via
DeliverNetworkPacket. When the second task reads the bridge's MAC address,
it waits forever for the first task to release the rlock. Using RLock can
allow the concurrent access to the MAC address, it dones't have to be
blocked until the messages are sent.
Reported-by: syzbot+1d6d1d8f47eae4e308dc@syzkaller.appspotmail.com
PiperOrigin-RevId: 704163976
The push-* command skips rebuild and image push w/ `latest` tag when a image
tag exists remotely. Most of gVisor test images have never got a chance to be
tagged because they already exist when `DOCKER_PUSH_AS_LATEST` was introduced.
We shouldn't enable DOCKER_FORCE_PUSH in our pipelines, it is better to be a
one off tool when the `latest` tag of an image is missing from remote repos.
PiperOrigin-RevId: 696823576
GCR will be deprecated, while the prefix `gcr.io` will be
be hosted via Artifact Registry. By adding this one extra step,
all test images will be accessible via both `gcr.io` and
`pkg.dev`.
PiperOrigin-RevId: 694278137
Bridge uses bridge FDB to decide which port(s) it forwards the
received packets to.
The bridge FDB, when the bridge receives a packet, records the packet's source
MAC address and the bridge port where the packet is received. The received
packet's source MAC address will be the lookup key to the bridge FDB.
When deciding a forward port, the bridge looks for a FDB key which matches
the packet's destination MAC address, the associated port from the FDB will
forward the packet. Otherwise, the packet will flood to all available bridge
ports.
The FDB will never be garbage collected until the nic device is removed
from the bridge.
PiperOrigin-RevId: 693143851
L2 MTU includes both payload and ethernet header. gVisor has supported setting
data link layer MTU, it will be up to users to set up proper value for a
device's MTU if a larger value is expected.
By doing the change, gVisor will be consistent with runc:
```shell
# runc
root@cec4d7238802:/# ip link set dev lo mtu 1234
root@cec4d7238802:/# ip link list dev lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 1234 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
# runsc before the change.
root@7cd89278d414:/# ip link set dev lo mtu 1234
root@7cd89278d414:/# ip link list dev lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 1220
link/loopback 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
# runsc after the change.
root@e811c5851226:/# ip link set dev lo mtu 1234
root@e811c5851226:/# ip link list dev lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 1234
link/loopback 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
```
PiperOrigin-RevId: 684746090
The error code is based on the runc's behavior:
```shell
# ip link set dev br0 master br0
Error: Can not enslave a bridge to a bridge.
# echo $?
2
```
Reported-by: syzbot+9dcefbdcc9ecdeb4df96@syzkaller.appspotmail.com
PiperOrigin-RevId: 679761515
The packetdrill-test will have a new base image, and uses the main branch.
The packetdrill-v2.0 branch has been over 6 years old, and it is not
compatible with the new ubuntu releases.
PiperOrigin-RevId: 668173595
It currently expects all 3 events to happen to exit the command, the container
is killed, local port forward is compeleted, a termination signal is caught.
One can only terminate the command expecting both termination signal
(e.g. ctrl + c) and the container being killed. Instead, the ideal behavior
is that the command exits on either of previous 2 events. The local port
forward goroutine is blocked until the context's cancel function is called.
Thus, we just have the waitgroup to wait for the completion of the local
port forward task.
PiperOrigin-RevId: 668168948
The attributes are expected by Dockerd to start. In gVisor, skipping
the attributes is good enough to run the Docker workloads.
PiperOrigin-RevId: 650362257
IFLA_IFNAME is used to set an interface's name when being used
with RTM_NEWLINK and RTM_SETLINK. RTM_NEWLINK is the preferred way, it
is backwards compatible with RTM_SETLINK. For gVisor, when RTM_SETLINK is
introduced, it shall just share the implementation.
PiperOrigin-RevId: 647833657
Passing the address of the string can't be recognized by the syscall, the
syscall expects the address to the first byte of the string which is
NUL-terminated.
PiperOrigin-RevId: 617430240
The symlinks mirrors the relationship between TPU devices and its respective
IOMMU group and on the host.
Before the change, iommu_group has been treated as a normal file, which doesn't
create such symlink for the devices.
PiperOrigin-RevId: 597939650
When using KVM platform at arm64 machines, gVisor will attempts to retrieve the largest possible task size and compares the size with the expected user space size. If the user space size is larger than the task size, it will lead to mmap failures, gVisor should returns an error.
PiperOrigin-RevId: 581146644
It is not ideal to access a mount's Flags directly, gVisor will access a mount's flags via MountOptions() which locks mount's mu to avoid data race.
PiperOrigin-RevId: 576059331
Jing Chen