| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Add reverse operation to mitigate that just enables
all CPUs.
PiperOrigin-RevId: 360511215
|
|
|
|
PiperOrigin-RevId: 360491700
|
|
|
|
Prevent the situation where callers to (*stack).GetLinkAddress provide
incorrect arguments and are unable to observe this condition.
Updates #5583.
PiperOrigin-RevId: 360481557
|
|
|
|
io.Reader.ReadFull returns the number of bytes copied and an error if fewer
bytes were read.
PiperOrigin-RevId: 360247614
|
|
|
|
There is a short race where in Write an endpoint can transition from writable
to non-writable state due to say an incoming RST during the time we release
the endpoint lock and reacquire after copying the payload. In such a case
if the write happens to be a zero sized write we end up trying to call
sendData() even though nothing was queued.
This can panic when trying to enable/disable TCP timers if the endpoint had
already transitioned to a CLOSED/ERROR state due to the incoming RST as we
cleanup timers when the protocol goroutine terminates.
Sadly the race window is small enough that my attempts at reproducing the panic
in a syscall test has not been successful.
PiperOrigin-RevId: 359887905
|
|
|
|
Changes the neighbor_entry_test.go tests to always assert UpdatedAtNanos.
This field was historically not checked due to the lack of a deterministic,
controllable clock. This is no longer true with the tcpip.Clock interface.
While the tests have been adjusted to use Clock, asserting by the
UpdatedAtNanos was neglected.
Subsequent work is needed to assert UpdatedAtNanos in the neighbor cache tests.
Updates #4663
PiperOrigin-RevId: 359868254
|
|
|
|
Converts entryTestLinkResolver and testNUDDispatcher to use the embedded
sync.Mutex pattern for fields that may be accessed concurrently from different
gorountines.
Fixes #5541
PiperOrigin-RevId: 359826169
|
|
|
|
Adds helper functions for transitioning into common states. This reduces the
boilerplate by a fair amount, decreasing the barriers to entry for new features
added to neighborEntry.
PiperOrigin-RevId: 359810465
|
|
|
|
Also increase refcount of raw.endpoint.route while in use.
Avoid allocating an array of size zero.
PiperOrigin-RevId: 359797788
|
|
|
|
Without this change, the error produced is quite useless:
--- FAIL: TestZeroWindowProbeRetransmit (11.44s)
tcp_zero_window_probe_retransmit_test.go:81: expected a probe with sequence number 824638527212: loop 5
FAIL
PiperOrigin-RevId: 359796370
|
|
|
|
Use maybeSendSegment while sending segments in RACK recovery which checks if
the receiver has space and splits the segments when the segment size is
greater than MSS.
PiperOrigin-RevId: 359641097
|
|
|
|
- open flags can be different on different OSs, by putting SetNonblocking into
the posix_server rather than the testbench, we can always get the right value
for O_NONBLOCK
- merged the tcp_queue_{send,receive}_in_syn_sent into a single file
PiperOrigin-RevId: 359620630
|
|
|
|
Prevents the following deadlock:
- Raw packet is sent via e.Write(), which read locks e.mu
- Connect() is called, blocking on write locking e.mu
- The packet is routed to loopback and back to e.HandlePacket(), which read
locks e.mu
Per the atomic.RWMutex documentation, this deadlocks:
"If a goroutine holds a RWMutex for reading and another goroutine might call
Lock, no goroutine should expect to be able to acquire a read lock until the
initial read lock is released. In particular, this prohibits recursive read
locking. This is to ensure that the lock eventually becomes available; a blocked
Lock call excludes new readers from acquiring the lock."
Also, release eps.mu earlier in deliverRawPacket.
PiperOrigin-RevId: 359600926
|
|
|
|
PiperOrigin-RevId: 359591577
|
|
|
|
This will fix debian packaging.
Updates #5510
PiperOrigin-RevId: 359563378
|
|
|
|
sync.WaitGroup.Add(positive delta) is illegal if the WaitGroup counter is zero
and WaitGroup.Wait() may be called concurrently. This is problematic for
p9.connState.pendingWg, which counts inflight requests (so transitions from
zero are normal) and is waited-upon when receiving from the underlying Unix
domain socket returns an error, e.g. during connection shutdown. (Even if the
socket has been closed, new requests can still be concurrently received via
flipcall channels.)
PiperOrigin-RevId: 359416057
|
|
|
|
Fixes #5490
PiperOrigin-RevId: 359401532
|
|
|
|
One precondition of VFS.PrepareRenameAt is that the `from` and `to` dentries
are not the same. Kernfs was not checking this, which could lead to a deadlock.
PiperOrigin-RevId: 359385974
|
|
|
|
Before this CL, VFS2's overlayfs uses a single private device number and an
autoincrementing generated inode number for directories; this is consistent
with Linux's overlayfs in the non-samefs non-xino case. However, this breaks
some applications more consistently than on Linux due to more aggressive
caching of Linux overlayfs dentries.
Switch from using mapped device numbers + the topmost layer's inode number for
just non-copied-up non-directory files, to doing so for all files. This still
allows directory dev/ino numbers to change across copy-up, but otherwise keeps
them consistent.
Fixes #5545:
```
$ docker run --runtime=runsc-vfs2-overlay --rm ubuntu:focal bash -c "mkdir -p 1/2/3/4/5/6/7/8 && rm -rf 1 && echo done"
done
```
PiperOrigin-RevId: 359350716
|
|
|
|
Previously, when DAD would detect a conflict for a temporary address,
the address would be removed but its timers would not be stopped,
resulting in a panic when the removed address's invalidation timer
fired.
While I'm here, remove the check for unicast-ness on removed address
endpoints since multicast addresses are no longer stored in the same
structure as unicast addresses as of 27ee4fe76ad586ac8751951a842b3681f93.
Test: stack_test.TestMixedSLAACAddrConflictRegen
PiperOrigin-RevId: 359344849
|
|
|
|
- Use atomic add rather than CAS in every Gate method, which is slightly
faster in most cases.
- Implement Close wakeup using gopark/goready to avoid channel allocation.
New benchmarks:
name old time/op new time/op delta
GateEnterLeave-12 16.7ns ± 1% 10.3ns ± 1% -38.44% (p=0.000 n=9+8)
GateClose-12 50.2ns ± 8% 42.4ns ± 6% -15.44% (p=0.000 n=10+10)
GateEnterLeaveAsyncClose-12 972ns ± 2% 640ns ± 7% -34.15% (p=0.000 n=9+10)
PiperOrigin-RevId: 359336344
|
|
|
|
PiperOrigin-RevId: 359334029
|
|
|
|
Syzkaller hosts contains many audit messages that runsc tries
to call the clock_nanosleep syscall.
PiperOrigin-RevId: 359331413
|
|
`runsc ps` currently return pid for a task's immediate pid namespace,
which is confusing when there're multiple pid namespaces. We should
return only pids in the root namespace.
Before:
```
1000 1 0 0 ? 02:24 250ms chrome
1000 1 0 0 ? 02:24 40ms dumb-init
1000 1 0 0 ? 02:24 240ms chrome
1000 2 1 0 ? 02:24 2.78s node
```
After:
```
UID PID PPID C TTY STIME TIME CMD
1000 1 0 0 ? 12:35 0s dumb-init
1000 2 1 7 ? 12:35 240ms node
1000 13 2 21 ? 12:35 2.33s chrome
1000 27 13 3 ? 12:35 260ms chrome
```
Signed-off-by: Daniel Dao <dqminh@cloudflare.com>
|
|
|
|
Restrict ptrace(2) according to the default configurations of the YAMA security
module (mode 1), which is a common default among various Linux distributions.
The new access checks only permit the tracer to proceed if one of the following
conditions is met:
a) The tracer is already attached to the tracee.
b) The target is a descendant of the tracer.
c) The target has explicitly given permission to the tracer through the
PR_SET_PTRACER prctl.
d) The tracer has CAP_SYS_PTRACE.
See security/yama/yama_lsm.c for more details.
Note that these checks are added to CanTrace, which is checked for
PTRACE_ATTACH as well as some other operations, e.g., checking a process'
memory layout through /proc/[pid]/mem.
Since this patch adds restrictions to ptrace, it may break compatibility for
applications run by non-root users that, for instance, rely on being able to
trace processes that are not descended from the tracer (e.g., `gdb -p`). YAMA
restrictions can be turned off by setting /proc/sys/kernel/yama/ptrace_scope
to 0, or exceptions can be made on a per-process basis with the PR_SET_PTRACER
prctl.
Reported-by: syzbot+622822d8bca08c99e8c8@syzkaller.appspotmail.com
PiperOrigin-RevId: 359237723
|
|
|
