Age | Commit message (Collapse) | Author |
|
|
|
Our implementation of vfs.CheckDeleteSticky was not consistent with Linux,
specifically not consistent with fs/linux.h:check_sticky().
One of the biggest differences was that the vfs implementation did not
allow the owner of the sticky directory to delete files inside it that belonged
to other users.
This change makes our implementation consistent with Linux.
Also adds an integration test to check for this. This bug is also present in
VFS1.
Updates #3027
PiperOrigin-RevId: 355557425
|
|
|
|
- Adds a function to enable RACK in tests.
- RACK update functions are guarded behind the flag tcpRecovery.
PiperOrigin-RevId: 355435973
|
|
|
|
|
|
This was missed in cl/351911375; pipe.VFSPipeFD.SpliceFromNonPipe already calls
Notify.
PiperOrigin-RevId: 355246655
|
|
|
|
Rename HandleNDupAcks() to HandleLossDetected() as it will enter this when
is detected after:
- reorder window expires and TLP (in case of RACK)
- dupAckCount >= 3
PiperOrigin-RevId: 355237858
|
|
|
|
Because we lack gVisor-internal cgroups, we take the CPU usage of the entire pod
and divide it proportionally according to sentry-internal usage stats.
This fixes `kubectl top pods`, which gets a pod's CPU usage by summing the usage
of its containers.
Addresses #172.
PiperOrigin-RevId: 355229833
|
|
|
|
This allows the package to serve as a general purpose ring0 support package, as
opposed to being bound to specific sentry platforms.
Updates #5039
PiperOrigin-RevId: 355220044
|
|
|
|
Reported-by: syzbot+db8d83f93b84fcb84374@syzkaller.appspotmail.com
PiperOrigin-RevId: 355213994
|
|
|
|
Netstack today will send dupACK's with no rate limit for incoming out of
window segments. This can result in ACK loops for example if a TCP socket
connects to itself (actually permitted by TCP). Where the ACK sent in
response to packets being out of order itself gets considered as an out
of window segment resulting in another ACK being generated.
PiperOrigin-RevId: 355206877
|
|
|
|
* Make split safe.
* Enable looking up next valid address.
* Support mappings with !accessType.Any(), distinct from unmap.
These changes allow for the use of pagetables in low-level OS packages, such
as ring0, and allow for the use of pagetables for more generic address space
reservation (by writing entries with no access specified).
Updates #5039
PiperOrigin-RevId: 355109016
|
|
|
|
...to remove the need for the transport layer to deduce the type of
error it received.
Rename HandleControlPacket to HandleError as HandleControlPacket only
handles errors.
tcpip.SockError now holds a tcpip.SockErrorCause interface that
different errors can implement.
PiperOrigin-RevId: 354994306
|
|
|
|
This change flips gvisor to use Neighbor unreachability detection by
default to populate the neighbor table as defined by RFC 4861 section 7.
Although RFC 4861 is targeted at IPv6, the same algorithm is used for
link resolution on IPv4 networks using ARP.
Integrators may still use the legacy link address cache by setting
stack.Options.UseLinkAddrCache to true; stack.Options.UseNeighborCache
is now unused and will be removed.
A later change will remove linkAddrCache and associated code.
Updates #4658.
PiperOrigin-RevId: 354850531
|
|
PiperOrigin-RevId: 354827491
|
|
...in IPv6 ICMP tests.
A channel link endpoint's channel is closed when the link endpoint is
closed.
When the stack tries to send packets through a NIC with a closed channel
endpoint, a panic will occur when attempting to write to a closed
channel (https://golang.org/ref/spec#Close). To make sure the stack does
not try to send packets through a NIC, we remove it.
PiperOrigin-RevId: 354822085
|
|
|
|
This stores each protocol's neighbor state separately.
This change also removes the need for each neighbor entry to keep
track of their own link address resolver now that all the entries
in a cache will use the same resolver.
PiperOrigin-RevId: 354818155
|
|
|
|
The network endpoint should not need to have logic to handle different
kinds of neighbor tables. Network endpoints can let the NIC know about
differnt neighbor discovery messages and let the NIC decide which table
to update.
This allows us to remove the LinkAddressCache interface.
PiperOrigin-RevId: 354812584
|
|
|
|
PiperOrigin-RevId: 354746864
|
|
|
|
This removes the need to provide the link address request with the NIC
the request is being performed on since the NetworkEndpoints already
have a reference to the NIC.
PiperOrigin-RevId: 354721940
|
|
|
|
This allows later decoupling of the backing network buffer implementation.
PiperOrigin-RevId: 354643297
|
|
|
|
This is dynamic state that can be re-learned when the NIC comes
back up.
Test: ipv4_test.TestIgmpV1Present
PiperOrigin-RevId: 354630921
|
|
|
|
...as per As per RFC 2236 section 3 page 3 (for IGMPv2) and
RFC 2710 section 4 page 5 (for MLDv1).
See comments in code for more details.
Test: ip_test.TestHandleQuery
PiperOrigin-RevId: 354603068
|
|
|
|
PiperOrigin-RevId: 354595623
|
|
|
|
When file is regular and metadata cache is authoritative, metadata lock
is taken. The code deadlocks trying to acquire the metadata lock
again to update time stampts.
PiperOrigin-RevId: 354584594
|
|
|
|
...per RFC 4861 s7.1.2.
Startblock:
has LGTM from sbalana
and then
add reviewer ghanan
PiperOrigin-RevId: 354539026
|
|
|
|
When a route does not need to resolve a remote link address to send a
packet, avoid having to obtain the pending packets queue's lock.
PiperOrigin-RevId: 354456280
|
|
|
|
|
|
After receiving an ACK(cumulative or selective), RACK will update the reorder
window which is used as a settling time before marking the packet as lost.
This change will add an init function to initialize the variables in RACK and
also store the reference to sender in rackControl.
The reorder window is calculated as per rfc:
https://tools.ietf.org/html/draft-ietf-tcpm-rack-08#section-7.2 Step 4.
PiperOrigin-RevId: 354453528
|