Age | Commit message (Collapse) | Author |
|
|
|
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
|
|
|
|
PiperOrigin-RevId: 397813331
|
|
|
|
PiperOrigin-RevId: 397631833
|
|
|
|
...to change the network protocol a packet socket may receive packets
from.
This CL is a portion of an originally larger CL that was split with
https://github.com/google/gvisor/commit/a8ad692fd36cbaf7f5a6b9af39d601053dbee338
being the dependent CL. That CL (accidentally) included the change in
the endpoint's `afterLoad` method to take the required lock when
accessing the endpoint's netProto field. That change should have been in
this CL.
The CL that made the change mentioned in the commit message is
cl/396946187.
PiperOrigin-RevId: 397412582
|
|
|
|
In the general case, files may have offsets between MaxInt64 and MaxUint64; in
Linux pgoff is consistently represented by an unsigned long, and in gVisor the
offset types in memmap.MappableRange are uint64. However, regular file mmap is
constrained to int64 offsets (on 64-bit systems) by
mm/mmap.c:file_mmap_size_max() => MAX_LFS_FILESIZE == LLONG_MAX.
As a related fix, check for chunkStart overflow in fsutil.HostFileMapper; chunk
offsets are uint64s, but as noted above some file types may use uint64 offsets
beyond MaxInt64.
Reported-by: syzbot+71342a1585aed97ed9f7@syzkaller.appspotmail.com
PiperOrigin-RevId: 397136751
|
|
|
|
PiperOrigin-RevId: 397114051
|
|
Add global flags -profile-{block,cpu,heap,mutex} and -trace which
enable collection of the specified profile for the entire duration of a
container execution. This provides a way to definitively start profiling
before that application starts, rather than attempting to race with an
out-of-band `runsc debug`.
Note that only the main boot process is profiled.
This exposed a bug in Task.traceExecEvent: a crash when tracing and
-race are enabled. traceExecEvent is called off of the task goroutine,
but uses the Task as a context, which is a violation of the Task
contract. Switching to the AsyncContext fixes the issue.
Fixes #220
|
|
|
|
Replaced the current AddAddressWithOptions method with
AddAddressWithProperties which passes all address properties in
a single AddressProperties type. More properties that need to be
configured in the future are expected, so adding a type makes adding
them easier.
PiperOrigin-RevId: 396930729
|
|
|
|
...and EAFNOSUPPORT for unexpected address family.
To comply with Linux.
Updates #6021, #6575.
PiperOrigin-RevId: 396893590
|
|
|
|
Previously, we weren't making a copy when a sysv message queue was
receiving a message with the MSG_COPY flag. This flag indicates the
message being received should be left in the queue and a copy of the
message should be returned to userspace. Without the copy, a racing
process can modify the original message while it's being marshalled to
user memory.
Reported-by: syzbot+cb15e644698b20ff4e17@syzkaller.appspotmail.com
PiperOrigin-RevId: 396712856
|
|
|
|
PiperOrigin-RevId: 396042572
|
|
|
|
Previously, gVisor did not represent loopback devices as an ethernet
device as Linux does. To maintain Linux API compatibility for packet
sockets, a workaround was used to add an ethernet header if a link
header was not already present in the packet buffer delivered to a
packet endpoint.
However, this workaround is a bug for non-ethernet based interfaces; not
all links use an ethernet header (e.g. pure L3/TUN interfaces).
As of 3b4bb947517d0d9010120aaa1c3989fd6abf278e, gVisor represents
loopback devices as an ethernet-based device so this workaround can
now be removed.
BUG: https://fxbug.dev/81592
Updates #6530, #6531.
PiperOrigin-RevId: 395819151
|
|
|
|
PiperOrigin-RevId: 395338926
|
|
|
|
This defines common infrastructure for dynamically-configured security checks,
including an example usage in the clone(2) path.
PiperOrigin-RevId: 394797270
|
|
|
|
If we want to take two endpoint locks, we need to be sure that we always
take them in the same order.
Accept() locks the listening endpoint to work with acceptedChan and then
it calls GetLocalAddress that locks an accepted endpoint. Actually, we
can release the listening endpoint lock before calling GetLocalAddress.
Reported-by: syzbot+f52bd603f51a4ae91054@syzkaller.appspotmail.com
PiperOrigin-RevId: 394553823
|
|
|
|
...through the loopback interface, only.
This change only supports sending on packet sockets through the loopback
interface as the loopback interface is the only interface used in packet
socket syscall tests - the other link endpoints are not excercised with
the existing test infrastructure.
Support for sending on packet sockets through the other interfaces will
be added as needed.
BUG: https://fxbug.dev/81592
PiperOrigin-RevId: 394368899
|
|
|
|
...from the UDP endpoint.
Datagram-based transport endpoints (e.g. UDP, RAW IP) can share a lot
of their write path due to the datagram-based nature of these endpoints.
Extract the common facilities from UDP so they can be shared with other
transport endpoints (in a later change).
Test: UDP syscall tests.
PiperOrigin-RevId: 394347774
|
|
|
|
reflect.ValueOf takes an interface{}, so when passed a slice the compiler emits
a call to runtime.convTslice to heap-allocate a copy of the slice header.
PiperOrigin-RevId: 394310052
|
|
|
|
PiperOrigin-RevId: 394300607
|
|
|
|
PiperOrigin-RevId: 394296687
|
|
|
|
Reported-by: syzbot+1aab6800bd14829609b8@syzkaller.appspotmail.com
PiperOrigin-RevId: 394279838
|
|
|
|
PiperOrigin-RevId: 393841270
|
|
|
|
PiperOrigin-RevId: 393831108
|
|
|