Age | Commit message (Collapse) | Author |
|
|
|
Control messages should be released on Read (which ignores the control message)
or zero-byte Send. Otherwise, open fds sent through the control messages will
be leaked.
PiperOrigin-RevId: 337110774
|
|
|
|
This fixes reference leaks related to accidentally forgetting to DecRef()
after calling one or the other.
PiperOrigin-RevId: 336918922
|
|
|
|
- sysinfo(2) does not actually require a fine-grained breakdown of memory
usage. Accordingly, instead of calling pgalloc.MemoryFile.UpdateUsage() to
update the sentry's fine-grained memory accounting snapshot, just use
pgalloc.MemoryFile.TotalUsage() (which is a single fstat(), and therefore far
cheaper).
- Use the number of threads in the root PID namespace (i.e. globally) rather
than in the task's PID namespace for consistency with Linux (which just reads
global variable nr_threads), and add a new method to kernel.PIDNamespace to
allow this to be read directly from an underlying map rather than requiring
the allocation and population of an intermediate slice.
PiperOrigin-RevId: 336353100
|
|
|
|
|
|
Reported-by: syzbot+bb82fb556d5d0a43f632@syzkaller.appspotmail.com
PiperOrigin-RevId: 336324720
|
|
|
|
cf. 2a36ab717e8f "rseq/membarrier: Add MEMBARRIER_CMD_PRIVATE_EXPEDITED_RSEQ"
PiperOrigin-RevId: 336186795
|
|
|
|
|
|
Updates #267
PiperOrigin-RevId: 335713923
|
|
|
|
PiperOrigin-RevId: 335492800
|
|
|
|
PiperOrigin-RevId: 335051794
|
|
arm64 vfs2: Add support for io_submit/fallocate/
sendfile/newfstatat/readahead/fadvise64
Signed-off-by: Howard Zhang <howard.zhang@arm.com>
|
|
This patch adds minor changes for Arm64 platform:
1, add SetRobustList/GetRobustList support for arm64 syscall module.
2, add newfstatat support for arm64 vfs2 syscall module.
3, add tls value in ProtoBuf.
Signed-off-by: Bin Lu <bin.lu@arm.com>
|
|
|
|
Use HandleIOErrorVFS2 instead of custom error handling.
PiperOrigin-RevId: 333227581
|
|
|
|
This is more consistent with Linux (see comment on MM.NewSharedAnonMappable()).
We don't do the same thing on VFS1 for reasons documented by the updated
comment.
PiperOrigin-RevId: 332514849
|
|
|
|
Linux defines this struct as:
struct sched_param {
int priority;
}
... in include/linux/sched.h.
PiperOrigin-RevId: 332473133
|
|
|
|
|
|
PiperOrigin-RevId: 331940975
|
|
|
|
Discovered by ayushranjan@:
VFS2 was employing the following algorithm for fetching ready events from an
epoll instance:
- Create a statically sized EpollEvent slice on the stack of size 16.
- Pass that to EpollInstance.ReadEvents() to populate.
- EpollInstance.ReadEvents() requeues level-triggered events that it returns
back into the ready queue.
- Write the results to usermem.
- If the number of results were = 16 then recall EpollInstance.ReadEvents() in
the hopes of getting more. But this will cause duplication of the "requeued"
ready level-triggered events.
So if the ready queue has >= 16 ready events, the EpollWait for loop will spin
until it fills the usermem with `maxEvents` events.
Fixes #3521
PiperOrigin-RevId: 331840527
|
|
|
|
PiperOrigin-RevId: 331648296
|
|
|
|
PiperOrigin-RevId: 331256608
|
|
|
|
PiperOrigin-RevId: 330554450
|
|
|
|
Fixes #3779.
PiperOrigin-RevId: 330057268
|
|
|
|
PiperOrigin-RevId: 329572337
|
|
|
|
Also, add corresponding EOF tests for splice/sendfile.
Discovered by syzkaller.
PiperOrigin-RevId: 328975990
|
|
|
|
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
|
|
|
|
|
|
|
|
We now allow hard links to be created within gofer fs (see
github.com/google/gvisor/commit/f20e63e31b56784c596897e86f03441f9d05f567).
Update the inotify documentation accordingly.
PiperOrigin-RevId: 328177485
|
|
|