| Age | Commit message (Collapse) | Author |
|---|
|
|
|
We would like to track locks ordering to detect ordering violations. Detecting
violations is much simpler if mutexes must be unlocked by the same goroutine
that locked them.
Thus, as a first step to tracking lock ordering, add this lock/unlock
requirement to gVisor's sync.Mutex. This is more strict than the Go standard
library's sync.Mutex, but initial testing indicates only a single lock that is
used across goroutines. The new sync.CrossGoroutineMutex relaxes the
requirement (but will not provide lock order checking).
Due to the additional overhead, enforcement is only enabled with the
"checklocks" build tag. Build with this tag using:
bazel build --define=gotags=checklocks ...
From my spot-checking, this has no changed inlining properties when disabled.
Updates #4804
PiperOrigin-RevId: 343370200
|
|
|
|
Group addressable endpoints can simply check if it has joined the
multicast group without maintaining address endpoints. This also
helps remove the dependency on AddressableEndpoint from
GroupAddressableEndpoint.
Now that group addresses are not tracked with address endpoints, we can
avoid accidentally obtaining a route with a multicast local address.
PiperOrigin-RevId: 343336912
|
|
|
|
Migration to unified socket options left this behind.
PiperOrigin-RevId: 343305434
|
|
PiperOrigin-RevId: 343299993
|
|
|
|
If a kernfs user does not cache dentries, then cacheLocked will destroy the
dentry. The current DecRef implementation will be racy in this case as the
following can happen:
- Goroutine 1 calls DecRef and decreases ref count from 1 to 0.
- Goroutine 2 acquires d.fs.mu for reading and calls IncRef and increasing the
ref count from 0 to 1.
- Goroutine 2 releases d.fs.mu and calls DecRef again decreasing ref count from
1 to 0.
- Goroutine 1 now acquires d.fs.mu and calls cacheLocked which destroys the
dentry.
- Goroutine 2 now acquires d.fs.mu and calls cacheLocked to find that the dentry
is already destroyed!
Earlier we would panic in this case, we could instead just return instead of
adding complexity to handle this race. This is similar to what the gofer client
does.
We do not want to lock d.fs.mu in the case that the filesystem caches dentries
(common case as procfs and sysfs do this) to prevent congestion due to lock
contention.
PiperOrigin-RevId: 343229496
|
|
|
|
PiperOrigin-RevId: 343217712
|
|
|
|
PiperOrigin-RevId: 343211553
|
|
|
|
PiperOrigin-RevId: 343196927
|
|
|
|
This changes also introduces:
- `SocketOptionsHandler` interface which can be implemented by endpoints to
handle endpoint specific behavior on SetSockOpt. This is analogous to what
Linux does.
- `DefaultSocketOptionsHandler` which is a default implementation of the above.
This is embedded in all endpoints so that we don't have to uselessly
implement empty functions. Endpoints with specific behavior can override the
embedded method by manually defining its own implementation.
PiperOrigin-RevId: 343158301
|
|
|
|
PiperOrigin-RevId: 343152780
|
|
|
|
PiperOrigin-RevId: 343146856
|
|
|
|
Packets should be properly routed when sending packets to addresses
in the loopback subnet which are not explicitly assigned to the loopback
interface.
Tests:
- integration_test.TestLoopbackAcceptAllInSubnetUDP
- integration_test.TestLoopbackAcceptAllInSubnetTCP
PiperOrigin-RevId: 343135643
|
|
|
|
PiperOrigin-RevId: 343130667
|
|
|
|
PiperOrigin-RevId: 343123278
|
|
|
|
This change also makes the following fixes:
- Make SocketOptions use atomic operations instead of having to acquire/drop
locks upon each get/set option.
- Make documentation more consistent.
- Remove tcpip.SocketOptions from socketOpsCommon because it already exists
in transport.Endpoint.
- Refactors get/set socket options tests to be easily extendable.
PiperOrigin-RevId: 343103780
|
|
|
|
Redefine stack.WritePacket into stack.WritePacketToRemote which lets the NIC
decide whether to append link headers.
PiperOrigin-RevId: 343071742
|
|
This was added by mistake in cl/342868552.
PiperOrigin-RevId: 343021431
|
|
|
|
If the endpoint is in StateError but e.hardErrorLocked() returns
nil then return ErrClosedForRecieve.
This can happen if a concurrent write on the same endpoint was in progress
when the endpoint transitioned to an error state.
PiperOrigin-RevId: 343018257
|
|
|
|
PiperOrigin-RevId: 343000335
|
|
|
|
PiperOrigin-RevId: 342992936
|
|
|
|
They were returning io.ErrShortWrite, but that is not handled at higher levels
and resulted in a panic.
We can just return the short write directly from the p9 call without
ErrShortWrite.
PiperOrigin-RevId: 342960441
|
|
|
|
|
|
If we don't hold a reference, the dentry can be destroyed by another thread.
Reported-by: syzbot+f2132e50060c41f6d41f@syzkaller.appspotmail.com
PiperOrigin-RevId: 342951940
|
|
Fixes #2714
PiperOrigin-RevId: 342950412
|
|
|
|
A prefix associated with a sniffer instance can help debug situations where
more than one NIC (i.e. more than one sniffer) exists.
PiperOrigin-RevId: 342950027
|
|
Also add the lock order for verity fs, and add a lock to protect dentry
hash.
PiperOrigin-RevId: 342946537
|
|
|
|
PiperOrigin-RevId: 342943430
|
|
|
