Age | Commit message (Collapse) | Author |
|
PiperOrigin-RevId: 342373580
|
|
Checks in Task.block() and Task.Value() are conditional on race detection being
enabled, since these functions are relatively hot. Checks in Task.SleepStart()
and Task.UninterruptibleSleepStart() are enabled unconditionally, since these
functions are not thought to lie on any critical paths, and misuse of these
functions is required for b/168241471 to manifest.
PiperOrigin-RevId: 342342175
|
|
This is actually just b/168751672 again; cl/332394146 was incorrectly reverted
by cl/341411151. Document the reference holder to reduce the likelihood that
this happens again.
Also document a few other bugs observed in the process.
PiperOrigin-RevId: 342339144
|
|
PiperOrigin-RevId: 342221309
|
|
PiperOrigin-RevId: 342214859
|
|
Store all the socket level options in a struct and call {Get/Set}SockOpt on
this struct. This will avoid implementing socket level options on all
endpoints. This CL contains implementing one socket level option for tcp and
udp endpoints.
PiperOrigin-RevId: 342203981
|
|
kernel.Task can only be used as context.Context by that Task's task goroutine.
This is violated in at least two places:
- In any case where one thread accesses the /proc/[tid] of any other thread,
passing the kernel.Task for [tid] as the context.Context is incorrect.
- Task.rebuildTraceContext() may be called by Kernel.RebuildTraceContexts()
outside the scope of any task goroutine.
Fix these (as well as a data race on Task.traceContext discovered during the
course of finding the latter).
PiperOrigin-RevId: 342174404
|
|
children names map can be used to verify whether a child is expected
during walking, so that we can detect unexpected modifications that
deleted/renamed both the target file and the corresponding merkle tree
file.
PiperOrigin-RevId: 342170715
|
|
This reduces confusion with context.Context (which is also relevant to
kernel.Tasks) and is consistent with existing function kernel.LoadTaskImage().
PiperOrigin-RevId: 342167298
|
|
PiperOrigin-RevId: 342161204
|
|
PiperOrigin-RevId: 341982672
|
|
This will help to debug:
https://syzkaller.appspot.com/bug?id=0d717bd7028dceeb4b38f09aab2841c398b41d81
PiperOrigin-RevId: 341458715
|
|
PiperOrigin-RevId: 341445910
|
|
This lets us avoid treating a value of 0 as one reference. All references
using the refsvfs2 template must call InitRefs() before the reference is
incremented/decremented, or else a panic will occur. Therefore, it should be
pretty easy to identify missing InitRef calls during testing.
Updates #1486.
PiperOrigin-RevId: 341411151
|
|
This is necessary to allow writes to files opened with O_WRONLY to go through
host FDs.
PiperOrigin-RevId: 341174509
|
|
This is consistent with what Linux does. This was causing a PHP runtime test
failure. Fixed it for VFS2.
PiperOrigin-RevId: 341155209
|
|
PiperOrigin-RevId: 341154192
|
|
We can reuse information about whether a whiteout exists on a given file path
from stepLocked when creating a file at that path. This helps save an Unlink
call to the upper filesystem if the whiteout does NOT exist (common case).
Plumbs this information from lookupLocked() -> getChildLocked() -> stepLocked().
This also helped save a Lookup in RenameAt().
Fixes #1199
PiperOrigin-RevId: 341105351
|
|
The root dentry was not created through Inode.Lookup, so we should not
release a reference even if inode.Keep() is true.
PiperOrigin-RevId: 341103220
|
|
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
|
|
PiperOrigin-RevId: 341001328
|
|
PiperOrigin-RevId: 340536306
|
|
The waits-for relationship between an epoll instance and an inotify fd should
be restored.
This fixes flaky inotify vfs2 tests.
PiperOrigin-RevId: 340531367
|
|
The default pipe size already matched linux, and is unchanged.
Furthermore `atomicIOBytes` is made a proper constant (as it is in Linux). We
were plumbing usermem.PageSize everywhere, so this is no functional change.
PiperOrigin-RevId: 340497006
|
|
PiperOrigin-RevId: 340484823
|
|
Use an sErr injection to trigger sigbus when we receive EFAULT from the
run ioctl.
After applying this patch, mmap_test_runsc_kvm will be passed on
Arm64.
Signed-off-by: Bin Lu <bin.lu@arm.com>
COPYBARA_INTEGRATE_REVIEW=https://github.com/google/gvisor/pull/4542 from lubinszARM:pr_kvm_mmap_1 f81bd42466d1d60a581e5fb34de18b78878c68c1
PiperOrigin-RevId: 340461239
|
|
PiperOrigin-RevId: 340389884
|
|
Don't return the filename, since it can already be determined by the caller.
This was causing a panic in RenameAt, which relied on the name to be nonempty
even if the error was EEXIST.
Reported-by: syzbot+e9f117d000301e42361f@syzkaller.appspotmail.com
PiperOrigin-RevId: 340381946
|
|
PiperOrigin-RevId: 340275942
|
|
Fixes: #509
Signed-off-by: Lai Jiangshan <jiangshan.ljs@antfin.com>
Signed-off-by: Lai Jiangshan <laijs@linux.alibaba.com>
|
|
PiperOrigin-RevId: 340149214
|
|
Read-only directories (e.g. under /sys, /proc) should return EPERM for rename.
PiperOrigin-RevId: 339979022
|
|
The non-errno error was causing panics before.
PiperOrigin-RevId: 339969348
|
|
kernel.copyContext{t} cannot be used outside of t's task goroutine, for three
reasons:
- t.CopyScratchBuffer() is task-goroutine-local.
- Calling t.MemoryManager() without running on t's task goroutine or locking
t.mu violates t.MemoryManager()'s preconditions.
- kernel.copyContext passes t as context.Context to MM IO methods, which is
illegal outside of t's task goroutine (cf. kernel.Task.Value()).
Fix this by splitting AsCopyContext() into CopyContext() (which takes an
explicit context.Context and is usable outside of the task goroutine) and
OwnCopyContext() (which uses t as context.Context, but is only usable by t's
task goroutine).
PiperOrigin-RevId: 339933809
|
|
PiperOrigin-RevId: 339921446
|
|
Fixes #4613.
PiperOrigin-RevId: 339746784
|
|
PiperOrigin-RevId: 339721152
|
|
current when save fpsmid register is using following
instruction:
# FMOVD Fx, 16*1(R0)
this instruction will compiled to:
# str Dx, [x0, #16]
Dx is 64bit fp register not 128bit, then upper 64bit data
will be lossed, this will cause application meet many random
crash issue. need use 128bit register Vx or Q0 to save and
restore the fpsmid context.
Signed-off-by: Min Le <lemin.lm@antgroup.com>
|
|
Updates #1486.
PiperOrigin-RevId: 339581879
|
|
Also refactor the template and CheckedObject interface to make this cleaner.
Updates #1486.
PiperOrigin-RevId: 339577120
|
|
PiperOrigin-RevId: 339540747
|
|
Updates #1199
PiperOrigin-RevId: 339528827
|
|
PiperOrigin-RevId: 339505487
|
|
PiperOrigin-RevId: 339404936
|
|
Signed-off-by: Min Le <lemin.lm@antgroup.com>
|
|
PiperOrigin-RevId: 339377254
|
|
This PR implements /proc/[pid]/mem for `pkg/sentry/fs` (refer to #2716) and `pkg/sentry/fsimpl`.
@majek
COPYBARA_INTEGRATE_REVIEW=https://github.com/google/gvisor/pull/4060 from lnsp:proc-pid-mem 2caf9021254646f441be618a9bb5528610e44d43
PiperOrigin-RevId: 339369629
|
|
In VFS1's overlayfs, files use the device and inode number of the lower layer
inode if one exists, and the upper layer inode otherwise. The former behavior
is inefficient (requiring lower layer lookups even if the file exists and is
otherwise wholly determined by the upper layer), and somewhat dangerous if the
lower layer is also observable (since both the overlay and lower layer file
will have the same device and inode numbers and thus appear to be the same
file, despite being behaviorally different). VFS2 overlayfs imitates Linux
overlayfs (in its default configuration) instead; it always uses the inode
number from the originating layer, but synthesizes a unique device number for
directories and another device number for non-directory files that have not
been copied-up.
As it turns out, the latter is insufficient (in VFS2, and possibly Linux as
well), because a given layer may include files with different device numbers.
If two distinct files on such a layer have device number X and Y respectively,
but share inode number Z, then the overlay will map both files to some private
device number X' and inode number Z, potentially confusing applications. Fix
this by assigning synthetic device numbers based on the lower layer's device
number, rather than the lower layer's vfs.Filesystem.
PiperOrigin-RevId: 339300341
|
|
Updates #3921
PiperOrigin-RevId: 339195417
|
|
PiperOrigin-RevId: 339166854
|