Age | Commit message (Collapse) | Author |
|
|
|
PiperOrigin-RevId: 308674219
|
|
|
|
Fixes #1477.
PiperOrigin-RevId: 308317511
|
|
|
|
These methods let users eaily break the VectorisedView abstraction, and
allowed netstack to slip into pseudo-enforcement of the "all headers are
in the first View" invariant. Removing them and replacing with PullUp(n)
breaks this reliance and will make it easier to add iptables support and
rework network buffer management.
The new View.PullUp(n) method is low cost in the common case, when when
all the headers fit in the first View.
PiperOrigin-RevId: 308163542
|
|
|
|
Sentry metrics with nanoseconds units are labeled as such, and non-cumulative
sentry metrics are supported.
PiperOrigin-RevId: 307621080
|
|
|
|
PiperOrigin-RevId: 307598974
|
|
|
|
These methods let users eaily break the VectorisedView abstraction, and
allowed netstack to slip into pseudo-enforcement of the "all headers are
in the first View" invariant. Removing them and replacing with PullUp(n)
breaks this reliance and will make it easier to add iptables support and
rework network buffer management.
The new View.PullUp(n) method is low cost in the common case, when when
all the headers fit in the first View.
|
|
|
|
This previously changed in 305699233, but this behaviour turned out to
be load bearing.
PiperOrigin-RevId: 307033802
|
|
|
|
This should fix panic at aio callback.
PiperOrigin-RevId: 305798549
|
|
|
|
PiperOrigin-RevId: 305699233
|
|
|
|
We already have network namespace for netstack.
PiperOrigin-RevId: 305341954
|
|
|
|
Updates #1476, #1478, #1484, #1485.
PiperOrigin-RevId: 304845354
|
|
|
|
|
|
This change involves several steps:
- Refactor the VFS1 unix socket implementation to share methods between VFS1
and VFS2 where possible. Re-implement the rest.
- Override the default PRead, Read, PWrite, Write, Ioctl, Release methods in
FileDescriptionDefaultImpl.
- Add functions to create and initialize a new Dentry/Inode and FileDescription
for a Unix socket file.
Updates #1476
PiperOrigin-RevId: 304689796
|
|
|
|
PiperOrigin-RevId: 304508083
|
|
|
|
Refactor the existing socket interface to share methods between VFS1 and VFS2.
The method signatures do not contain anything filesystem-related, so they don't
need to be re-defined for VFS2.
Updates #1476, #1478, #1484, #1485.
PiperOrigin-RevId: 304184545
|
|
|
|
This feature will match UID and GID of the packet creator, for locally
generated packets. This match is only valid in the OUTPUT and POSTROUTING
chains. Forwarded packets do not have any socket associated with them.
Packets from kernel threads do have a socket, but usually no owner.
|
|
|
|
PiperOrigin-RevId: 302891559
|
|
|
|
This is a precursor to be being able to build an intrusive list
of PacketBuffers for use in queuing disciplines being implemented.
Updates #2214
PiperOrigin-RevId: 302677662
|
|
|
|
Fixes #506
PiperOrigin-RevId: 302540404
|
|
|
|
PiperOrigin-RevId: 302539171
|
|
|
|
Also get rid of the readViewHasData as it's not required anymore.
Updates #231, #357
PiperOrigin-RevId: 301837227
|
|
|
|
workMu is removed and e.mu is now a mutex that supports TryLock. The packet
processing path tries to lock the mutex and if its locked it will just queue the
packet and move on. The endpoint.UnlockUser() will process any backlog of
packets before unlocking the socket.
This simplifies the locking inside tcp endpoints a lot. Further the
endpoint.LockUser() implements spinning as long as the lock is not held by
another syscall goroutine. This ensures low latency as not spinning leads to the
task thread being put to sleep if the lock is held by the packet dispatch
path. This is suboptimal as the lower layer rarely holds the lock for long so
implementing spinning here helps.
If the lock is held by another task goroutine then we just proceed to call
LockUser() and the task could be put to sleep.
The protocol goroutines themselves just call e.mu.Lock() and block if the
lock is currently not available.
Updates #231, #357
PiperOrigin-RevId: 301808349
|
|
|
|
PiperOrigin-RevId: 301197007
|
|
|
|
PiperOrigin-RevId: 300362789
|
|
|
|
|
|
|