This is consistent with POSIX semantics and with 9P client file.
Some VFS callers like splice really depend on such a non-nil
error being returned from FD.Read(). Otherwise, sendfile will
hang forever, spaming FD.Read() for more data.
Added a regression test. This test reproduces the issue when:
- LISAFS is enabled.
- sendfile(2) called with input file for which we don't have
cached mapping (so will need to read from gofer). Can be
simulated with shared gofer mode.
- Host FD is not available for input file to perform read. Tested
internally.
Hence this test will be more meaningful when lisafs is enabled
by default in all tests.
PiperOrigin-RevId: 458340830
- Excludes a failing java runtime test. This is a known issue being tracked
in b/228068134. Disable it to unblock submits. Should be unexcluded when the
bug is fixed.
- In upstream Linux, 6c25449e1a32 ("net: udp: fix alignment problem in
udp4_seq_show()") updated the /pro/net/udp header to add another whitespace.
But the other protocols (TCP, Raw, Ping) were not updated. gVisor produces
this header in pkg/sentry/fsimpl/proc/task_net.go for all protocols. Instead
of specially handling UDP in gVisor, just weaken the test for now.
- It seems like there is Linux sendfile bug. A nonblocking pipe blocks on
sendfile(2). Excluded the test from running natively for now.
PiperOrigin-RevId: 442042678
As part of this, change Task.interrupted() to not drain Task.interruptChan, and
do so explicitly using new function Task.unsetInterrupted() instead.
PiperOrigin-RevId: 342768365
Writes to pipes of size < PIPE_BUF are guaranteed to be atomic, so writes
larger than that will return EAGAIN if the pipe has capacity < PIPE_BUF.
Writes to eventfds will return EAGAIN if the write would cause the eventfd
value to go over the max.
In both such cases, calling Ready() on the FD will return true (because it is
possible to write), but specific kinds of writes will in fact return EAGAIN.
This CL fixes an infinite loop in splice and sendfile (VFS1 and VFS2) by
forcing skipping the readiness check for the outfile in send, splice, and tee.
PiperOrigin-RevId: 341102260
Fixes *.sh Java runtime tests, where splice()-ing from a pipe to /dev/zero
would not actually empty the pipe.
There was no guarantee that the data would actually be consumed on a splice
operation unless the output file's implementation of Write/PWrite actually
called VFSPipeFD.CopyIn. Now, whatever bytes are "written" are consumed
regardless of whether CopyIn is called or not.
Furthermore, the number of bytes in the IOSequence for reads is now capped at
the amount of data actually available. Before, splicing to /dev/zero would
always return the requested splice size without taking the actual available
data into account.
This change also refactors the case where an input file is spliced into an
output pipe so that it follows a similar pattern, which is arguably cleaner
anyway.
Updates #3576.
PiperOrigin-RevId: 328843954
The input file descriptor is always a regular file, so sendfile can't lose any
data if it will not be able to write them to the output file descriptor.
Reported-by: syzbot+22d22330a35fa1c02155@syzkaller.appspotmail.com
PiperOrigin-RevId: 272730357
This also allows the tee(2) implementation to be enabled, since dup can now be
properly supported via WriteTo.
Note that this change necessitated some minor restructoring with the
fs.FileOperations splice methods. If the *fs.File is passed through directly,
then only public API methods are accessible, which will deadlock immediately
since the locking is already done by fs.Splice. Instead, we pass through an
abstract io.Reader or io.Writer, which elide locks and use the underlying
fs.FileOperations directly.
PiperOrigin-RevId: 268805207
Based on the guidelines at
https://opensource.google.com/docs/releasing/authors/.
1. $ rg -l "Google LLC" | xargs sed -i 's/Google LLC.*/The gVisor Authors./'
2. Manual fixup of "Google Inc" references.
3. Add AUTHORS file. Authors may request to be added to this file.
4. Point netstack AUTHORS to gVisor AUTHORS. Drop CONTRIBUTORS.
Fixes#209
PiperOrigin-RevId: 245823212
Change-Id: I64530b24ad021a7d683137459cafc510f5ee1de9
gVisor bot
Fabricio Voznika
Ayush Ranjan
Jamie Liu
Adin Scannell
Andrei Vagin
Nicolas Lacasse
Dean Deng
Michael Pratt
Brian Geffon