Age | Commit message (Collapse) | Author |
|
|
|
PiperOrigin-RevId: 398763161
|
|
|
|
The p9 client does the same. This allows applications to read/write >= 2MB of
data. This enables the read write benchmarks to work with lisafs.
Updates #5466
PiperOrigin-RevId: 398659947
|
|
This allows to avoind unnecessary lock-ordering dependencies on task.mu.
|
|
|
|
Create the /sys/fs/cgroup directory when cgroups are available. This
creates the empty directory to serve as the mountpoint, actually
mounting cgroups is left to the launcher/userspace. This is consistent
with Linux behaviour.
Without this mountpoint, getdents(2) on /sys/fs indicates an empty
directory even if the launcher mounts cgroupfs at /sys/fs/cgroup. The
launcher can't create the mountpoint directory since sysfs doesn't
support mkdir.
PiperOrigin-RevId: 398596698
|
|
|
|
PiperOrigin-RevId: 398572735
|
|
|
|
...instead of an address.
This allows a later change to more precisely select an address
based on the NAT type (source vs. destination NAT).
PiperOrigin-RevId: 398559901
|
|
|
|
PiperOrigin-RevId: 398559780
|
|
|
|
An ICMP endpoint's write path can use the datagram-based endpoint.
Updates #6565.
Test: Datagram-based generic socket + ICMP/ping syscall tests.
PiperOrigin-RevId: 398539844
|
|
|
|
...to make it clear what arguments are needed per hook.
PiperOrigin-RevId: 398538776
|
|
|
|
This circular reference is misleading at best, and the various code and
commentary that claim `listenEP` can be nil are impossible by
definition.
Add checklocks annotations to enforce preconditions.
PiperOrigin-RevId: 398517574
|
|
|
|
Call sites for the two checkpoints aren't added yet.
PiperOrigin-RevId: 398375903
|
|
|
|
This will enable NAT to be performed on UDP packets that are sent
in response to packets sent by the stack.
This will also enable ICMP errors to be properly NAT-ed in response
to UDP packets (#5916).
Updates #5915.
PiperOrigin-RevId: 398373251
|
|
This prevents go module errors of the form
found packages tcp (accept.go) and rcv (rcv_test.go) in ...
PiperOrigin-RevId: 398370042
|
|
|
|
As per https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt
linux does not limit ICMP Echos by default.
icmp_ratemask - INTEGER
Mask made of ICMP types for which rates are being limited.
Significant bits: IHGFEDCBA9876543210
Default mask: 0000001100000011000 (6168)
Bit definitions (see include/linux/icmp.h):
0 Echo Reply
3 Destination Unreachable *
4 Source Quench *
5 Redirect
8 Echo Request
B Time Exceeded *
C Parameter Problem *
D Timestamp Request
E Timestamp Reply
F Info Request
G Info Reply
H Address Mask Request
I Address Mask Reply
* These are rate limited by default (see default mask above)
Equivalently for ICMPv6.
Lay out foundation for ICMP rate masks, exposing that configuration will be
addressed later when the need arises (#6521).
Fixes #6519
PiperOrigin-RevId: 398337963
|
|
PiperOrigin-RevId: 398336708
|
|
Signed-off-by: Andrei Vagin <avagin@google.com>
|
|
We install seccomp rules so that the SIGSYS signal is generated for
each mmap system call. Then our signal handler executes the real mmap
syscall and if a new regions is created, it maps it to the guest.
Signed-off-by: Andrei Vagin <avagin@google.com>
|
|
|
|
|
|
|
|
Turns out certain features of iptables (e.g. NAT) will not perform
any checks/work unless both the Network and Transport headers are
populated.
With this change, provide the packet directly to the outgoing
network endpoint's `writePacket` method instead of going
through `WriteHeaderIncludedPacket` which expected the headers
to not be set.
PiperOrigin-RevId: 398304004
|
|
|
|
Fixes #6495
PiperOrigin-RevId: 398121921
|
|
|
|
Before this change, when a new connection was created after receiving
an ACK that matched a SYN-cookie, it was always delivered asynchronously
to the accept queue. There was a chance that the listening endpoint
would process a SYN from another client before the delivery happened,
and the listening endpoint would not know yet that the queue was about
to be full, once the delivery happened.
Now, when an ACK matching a SYN-cookie is received, the new endpoint is
created and moved to the accept queue synchronously, while holding the
accept lock.
Fixes #6545
PiperOrigin-RevId: 398107254
|
|
|
|
A socket queue can contain sockets (others and this one). We have to avoid
taking locks of the same class where it is possible.
PiperOrigin-RevId: 398100744
|
|
|
|
Introduces RPC methods in lisafs. Makes that gofer client use lisafs RPCs
instead of p9 when lisafs is enabled.
Implements the handlers for those methods in fsgofer.
Fixes #5465
PiperOrigin-RevId: 398080310
|
|
|
|
lisafs is only supported in VFS2. Added a runsc flag which enables lisafs.
When the flag is enabled, the gofer process and the client communicate using
lisafs protocol instead of 9P.
Added a filesystem option in fsimpl/gofer which indicates if lisafs is being
used. That will be used to gate lisafs on the gofer client.
Note that this change does not make the gofer client use lisafs just yet.
Updates #5465
PiperOrigin-RevId: 397917844
|
|
|
|
Updates #6621
PiperOrigin-RevId: 397898852
|
|
|
|
PiperOrigin-RevId: 397813331
|
|
|
|
Once a packet socket is bound to a network protocol, it cannot be
unbound from that protocol; the network protocol binding may only be
updated to a different network protocol.
To comply with Linux.
PiperOrigin-RevId: 397810878
|
|
This change mainly aims to define the semantics of communication for the LISAFS
(LInux SAndbox Filesystem) protocol. This protocol aims to replace 9P and
intends to bring some performance benefits with it.
Some of the notable differences from the p9 package are:
- Now the server implementations own the handlers.
- As a result, there is no verbose interface like `p9.File` that all servers
need to implement. Different implementations can extend their File
implementations to varying degrees without imposing those extensions to other
server implementations that might not have anything to do with those features.
- If a server implementation adds a new RPC message, other implementations are
not compelled to support it.
I wrote a benchmark `BenchmarkSendRecv` in connection_test.go which competes
with p9's `BenchmarkSendRecvChannel`. Running these on an AMD Milan machine
shows that lisafs is **45%** faster.
**With 9P**
goos: linux
goarch: amd64
pkg: gvisor/pkg/p9/p9
cpu: AMD EPYC 7B13 64-Core Processor
BenchmarkSendRecvLegacy-256 82830 14053 ns/op 633 B/op 23 allocs/op
BenchmarkSendRecvChannel-256 776971 1551 ns/op 184 B/op 6 allocs/op
**With lisafs**
goos: linux
goarch: amd64
pkg: pkg/lisafs/connection_test
cpu: AMD EPYC 7B13 64-Core Processor
BenchmarkSendRecv-256 1399610 853.5 ns/op 48 B/op 2 allocs/op
Fixes #5464
PiperOrigin-RevId: 397803163
|