Age | Commit message (Collapse) | Author |
|
PiperOrigin-RevId: 333447255
|
|
This change includes overlay, special regular gofer files, and hostfs.
Fixes #3589.
PiperOrigin-RevId: 332330860
|
|
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
|
|
/proc/[pid]/{mounts,mountinfo}.
Also move VFS.MakeSyntheticMountpoint() (which is a utility wrapper around
VFS.MkdirAllAt(), itself a utility wrapper around VFS.MkdirAt()) to not be in
the middle of the implementation of these proc files.
Fixes #3878
PiperOrigin-RevId: 330843106
|
|
- BindSocketThenOpen test was expecting the incorrect error when opening
a socket. Fixed that.
- VirtualFilesystem.BindEndpointAt should not require pop.Path.Begin.Ok()
because the filesystem implementations do not need to walk to the parent
dentry. This check also exists for MknodAt, MkdirAt, RmdirAt, SymlinkAt and
UnlinkAt but those filesystem implementations also need to walk to the parent
denty. So that check is valid. Added some syscall tests to test this.
PiperOrigin-RevId: 330625220
|
|
Updates #1487
PiperOrigin-RevId: 330580699
|
|
PiperOrigin-RevId: 330554450
|
|
PiperOrigin-RevId: 329825497
|
|
This mainly involved enabling kernfs' client filesystems to provide a
StatFS implementation.
Fixes #3411, #3515.
PiperOrigin-RevId: 329009864
|
|
This uses the refs_vfs2 template in vfs2 as well as objects common to vfs1 and
vfs2. Note that vfs1-only refcounts are not replaced, since vfs1 will be deleted
soon anyway.
The following structs now use the new tool, with leak check enabled:
devpts:rootInode
fuse:inode
kernfs:Dentry
kernfs:dir
kernfs:readonlyDir
kernfs:StaticDirectory
proc:fdDirInode
proc:fdInfoDirInode
proc:subtasksInode
proc:taskInode
proc:tasksInode
vfs:FileDescription
vfs:MountNamespace
vfs:Filesystem
sys:dir
kernel:FSContext
kernel:ProcessGroup
kernel:Session
shm:Shm
mm:aioMappable
mm:SpecialMappable
transport:queue
And the following use the template, but because they currently are not leak
checked, a TODO is left instead of enabling leak check in this patch:
kernel:FDTable
tun:tunEndpoint
Updates #1486.
PiperOrigin-RevId: 328460377
|
|
PiperOrigin-RevId: 328374775
|
|
This enables pre-release testing with 1.16. The intention is to replace these
with a nogo check before the next release.
PiperOrigin-RevId: 328193911
|
|
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
|
|
Unlike linux mount(2), OCI spec allows mounting on top of an existing
non-directory file.
PiperOrigin-RevId: 327914342
|
|
fdReader/Writer implements io.Reader/Writer so that they can be passed
to Merkle tree library.
PiperOrigin-RevId: 327901376
|
|
PiperOrigin-RevId: 327892274
|
|
This lets us create "synthetic" mountpoint directories in ReadOnly mounts
during VFS setup.
Also add context.WithMountNamespace, as some filesystems (like overlay) require
a MountNamespace on ctx to handle vfs.Filesystem Operations.
PiperOrigin-RevId: 327874971
|
|
Refactored the recursive dir creation util in runsc/boot/vfs.go to be more
flexible.
PiperOrigin-RevId: 327719100
|
|
Our "Preconditions:" blocks are very useful to determine the input invariants,
but they are bit inconsistent throughout the codebase, which makes them harder
to read (particularly cases with 5+ conditions in a single paragraph).
I've reformatted all of the cases to fit in simple rules:
1. Cases with a single condition are placed on a single line.
2. Cases with multiple conditions are placed in a bulleted list.
This format has been added to the style guide.
I've also mentioned "Postconditions:", though those are much less frequently
used, and all uses already match this style.
PiperOrigin-RevId: 327687465
|
|
PiperOrigin-RevId: 327654207
|
|
test_eintr now passes in the Python runtime tests.
Updates #3515.
PiperOrigin-RevId: 327441081
|
|
Updates #1035
PiperOrigin-RevId: 327351475
|
|
PiperOrigin-RevId: 326270643
|
|
PiperOrigin-RevId: 325490674
|
|
context is passed to DecRef() and Release() which is
needed for SO_LINGER implementation.
PiperOrigin-RevId: 324672584
|
|
Move to setstat.go and add a FileDescription wrapper method.
PiperOrigin-RevId: 324165277
|
|
Compare Linux's fs/eventpoll.c:do_epoll_ctl(). I don't know where EPOLLRDHUP
came from.
PiperOrigin-RevId: 323874419
|
|
- Check write permission on truncate(2). Unlike ftruncate(2),
truncate(2) fails if the user does not have write permissions
on the file.
- For gofers under InteropModeShared, check file type before
making a truncate request. We should fail early and avoid
making an rpc when possible. Furthermore, depending on the
remote host's failure may give us unexpected behavior--if the
host converts the truncate request to an ftruncate syscall on
an open fd, we will get EINVAL instead of EISDIR.
Updates #2923.
PiperOrigin-RevId: 322913569
|
|
Allow FUSE filesystems to be mounted using libfuse.
The appropriate flags and mount options are parsed and
understood by fusefs.
|
|
PiperOrigin-RevId: 321028238
|
|
Container restart test is disabled for VFS2 for now.
Updates #1487
PiperOrigin-RevId: 320296401
|
|
PiperOrigin-RevId: 319283715
|
|
Updates #2923.
PiperOrigin-RevId: 319153792
|
|
Also make some fixes to vfs1's F_SETOWN. The fcntl test now entirely passes
on vfs2.
Fixes #2920.
PiperOrigin-RevId: 318669529
|
|
Updates #2923.
PiperOrigin-RevId: 318648128
|
|
Updates #1479.
PiperOrigin-RevId: 318631247
|
|
Also, while we're here, make sure that gofer inotify events are generated when
files are created in remote revalidating mode.
Updates #1479.
PiperOrigin-RevId: 318536354
|
|
- Support writing on proc/[pid]/{uid,gid}map
- Return EIO for writing to static files.
Updates #2923.
PiperOrigin-RevId: 318188503
|
|
Also refactor HandleDeletion().
Updates #1479.
PiperOrigin-RevId: 317989000
|
|
Events were only skipped on parent directories after their children were
unlinked; events on the unlinked file itself need to be skipped as well.
As a result, all Watches.Notify() calls need to know whether the dentry where
the call came from was unlinked.
Updates #1479.
PiperOrigin-RevId: 317979476
|
|
Because there is no inode structure stored in the sandbox, inotify watches
must be held on the dentry. This would be an issue in the presence of hard
links, where multiple dentries would need to share the same set of watches,
but in VFS2, we do not support the internal creation of hard links on gofer
fs. As a result, we make the assumption that every dentry corresponds to a
unique inode.
Furthermore, dentries can be cached and then evicted, even if the underlying
file has not be deleted. We must prevent this from occurring if there are any
watches that would be lost. Note that if the dentry was deleted or invalidated
(d.vfsd.IsDead()), we should still destroy it along with its watches.
Additionally, when a dentry’s last watch is removed, we cache it if it also
has zero references. This way, the dentry can eventually be evicted from
memory if it is no longer needed. This is accomplished with a new dentry
method, OnZeroWatches(), which is called by Inotify.RmWatch and
Inotify.Release. Note that it must be called after all inotify locks are
released to avoid violating lock order. Stress tests are added to make sure
that inotify operations don't deadlock with gofer.OnZeroWatches.
Updates #1479.
PiperOrigin-RevId: 317958034
|
|
Updates #2923.
PiperOrigin-RevId: 317246916
|
|
Updates #2972
PiperOrigin-RevId: 317113059
|
|
- Change FileDescriptionImpl Lock/UnlockPOSIX signature to
take {start,length,whence}, so the correct offset can be
calculated in the implementations.
- Create PosixLocker interface to make it possible to share
the same locking code from different implementations.
Closes #1480
PiperOrigin-RevId: 316910286
|
|
Major differences from existing overlay filesystems:
- Linux allows lower layers in an overlay to require revalidation, but not the
upper layer. VFS1 allows the upper layer in an overlay to require
revalidation, but not the lower layer. VFS2 does not allow any layers to
require revalidation. (Now that vfs.MkdirOptions.ForSyntheticMountpoint
exists, no uses of overlay in VFS1 are believed to require upper layer
revalidation; in particular, the requirement that the upper layer support the
creation of "trusted." extended attributes for whiteouts effectively required
the upper filesystem to be tmpfs in most cases.)
- Like VFS1, but unlike Linux, VFS2 overlay does not attempt to make mutations
of the upper layer atomic using a working directory and features like
RENAME_WHITEOUT. (This may change in the future, since not having a working
directory makes error recovery for some operations, e.g. rmdir, particularly
painful.)
- Like Linux, but unlike VFS1, VFS2 represents whiteouts using character
devices with rdev == 0; the equivalent of the whiteout attribute on
directories is xattr trusted.overlay.opaque = "y"; and there is no equivalent
to the whiteout attribute on non-directories since non-directories are never
merged with lower layers.
- Device and inode numbers work as follows:
- In Linux, modulo the xino feature and a special case for when all layers
are the same filesystem:
- Directories use the overlay filesystem's device number and an
ephemeral inode number assigned by the overlay.
- Non-directories that have been copied up use the device and inode
number assigned by the upper filesystem.
- Non-directories that have not been copied up use a per-(overlay,
layer)-pair device number and the inode number assigned by the lower
filesystem.
- In VFS1, device and inode numbers always come from the lower layer unless
"whited out"; this has the adverse effect of requiring interaction with
the lower filesystem even for non-directory files that exist on the upper
layer.
- In VFS2, device and inode numbers are assigned as in Linux, except that
xino and the samefs special case are not supported.
- Like Linux, but unlike VFS1, VFS2 does not attempt to maintain memory mapping
coherence across copy-up. (This may have to change in the future, as users
may be dependent on this property.)
- Like Linux, but unlike VFS1, VFS2 uses the overlayfs mounter's credentials
when interacting with the overlay's layers, rather than the caller's.
- Like Linux, but unlike VFS1, VFS2 permits multiple lower layers in an
overlay.
- Like Linux, but unlike VFS1, VFS2's overlay filesystem is
application-mountable.
Updates #1199
PiperOrigin-RevId: 316019067
|
|
LockFD is the generic implementation that can be embedded in
FileDescriptionImpl implementations. Unique lock ID is
maintained in vfs.FileDescription and is created on demand.
Updates #1480
PiperOrigin-RevId: 315604825
|
|
This is mostly syscall plumbing, VFS2 already implements the internals of
mounts. In addition to the syscall defintions, the following mount-related
mechanisms are updated:
- Implement MS_NOATIME for VFS2, but only for tmpfs and goferfs. The other VFS2
filesystems don't implement node-level timestamps yet.
- Implement the 'mode', 'uid' and 'gid' mount options for VFS2's tmpfs.
- Plumb mount namespace ownership, which is necessary for checking appropriate
capabilities during mount(2).
Updates #1035
PiperOrigin-RevId: 315035352
|
|
Updates #179
PiperOrigin-RevId: 314563830
|
|
None of the dependencies have changed in 1.15. It may be possible to simplify
some of the wrappers in rawfile following 1.13, but that can come in a later
change.
PiperOrigin-RevId: 313863264
|
|
Limited to tmpfs. Inotify support in other filesystem implementations to
follow.
Updates #1479
PiperOrigin-RevId: 313828648
|