| Age | Commit message (Collapse) | Author |
|---|
|
PiperOrigin-RevId: 338728070
|
|
Added the following fields in kernfs.InodeAttr:
- blockSize
- atime
- mtime
- ctime
Also resolved all TODOs for #1193.
Fixes #1193
PiperOrigin-RevId: 338714527
|
|
Our current reference leak checker uses finalizers to verify whether an object
has reached zero references before it is garbage collected. There are multiple
problems with this mechanism, so a rewrite is in order.
With finalizers, there is no way to guarantee that a finalizer will run before
the program exits. When an unreachable object with a finalizer is garbage
collected, its finalizer will be added to a queue and run asynchronously. The
best we can do is run garbage collection upon sandbox exit to make sure that
all finalizers are enqueued.
Furthermore, if there is a chain of finalized objects, e.g. A points to B
points to C, garbage collection needs to run multiple times before all of the
finalizers are enqueued. The first GC run will register the finalizer for A but
not free it. It takes another GC run to free A, at which point B's finalizer
can be registered. As a result, we need to run GC as many times as the length
of the longest such chain to have a somewhat reliable leak checker.
Finally, a cyclical chain of structs pointing to one another will never be
garbage collected if a finalizer is set. This is a well-known issue with Go
finalizers (https://github.com/golang/go/issues/7358). Using leak checking on
filesystem objects that produce cycles will not work and even result in memory
leaks.
The new leak checker stores reference counted objects in a global map when
leak check is enabled and removes them once they are destroyed. At sandbox
exit, any remaining objects in the map are considered as leaked. This provides
a deterministic way of detecting leaks without relying on the complexities of
finalizers and garbage collection.
This approach has several benefits over the former, including:
- Always detects leaks of objects that should be destroyed very close to
sandbox exit. The old checker very rarely detected these leaks, because it
relied on garbage collection to be run in a short window of time.
- Panics if we forgot to enable leak check on a ref-counted object (we will try
to remove it from the map when it is destroyed, but it will never have been
added).
- Can store extra logging information in the map values without adding to the
size of the ref count struct itself. With the size of just an int64, the ref
count object remains compact, meaning frequent operations like IncRef/DecRef
are more cache-efficient.
- Can aggregate leak results in a single report after the sandbox exits.
Instead of having warnings littered in the log, which were
non-deterministically triggered by garbage collection, we can print all
warning messages at once. Note that this could also be a limitation--the
sandbox must exit properly for leaks to be detected.
Some basic benchmarking indicates that this change does not significantly
affect performance when leak checking is enabled, which is understandable
since registering/unregistering is only done once for each filesystem object.
Updates #1486.
PiperOrigin-RevId: 338685972
|
|
Singleton filesystem like devpts and devtmpfs have a single filesystem shared
among all mounts, so they acquire a "self-reference" when initialized that
must be released when the entire virtual filesystem is released at sandbox
exit.
PiperOrigin-RevId: 336828852
|
|
This change aims to fix the memory leak issue reported in #3933.
Background:
VFS2 kernfs kept accumulating invalid dentries if those dentries were not
walked on. After substantial consideration of the problem by our team, we
decided to have an LRU cache solution. This change is the first part to that
solution, where we don't cache anything. The LRU cache can be added on top of
this.
What has changed:
- Introduced the concept of an inode tree in kernfs.OrderedChildren.
This is helpful is cases where the lifecycle of an inode is different from
that of a dentry.
- OrderedChildren now deals with initialized inodes instead of initialized
dentries. It now implements Lookup() where it constructs a new dentry
using the inode.
- OrderedChildren holds a ref on all its children inodes. With this change,
now an inode can "outlive" a dentry pointing to it. See comments in
kernfs.OrderedChildren.
- The kernfs dentry tree is solely maintained by kernfs only. Inode
implementations can not modify the dentry tree.
- Dentries that reach ref count 0 are removed from the dentry tree.
- revalidateChildLocked now defer-DecRefs the newly created dentry from
Inode.Lookup(), limiting its life to the current filesystem operation. If
refs are picked on the dentry during the FS op (via an FD or something),
then it will stick around and will be removed when the FD is closed. So there
is essentially _no caching_ for Look()ed up dentries.
- kernfs.DecRef does not have the precondition that fs.mu must be locked.
Fixes #3933
PiperOrigin-RevId: 336768576
|
|
Do not release dirMu between checking whether to create a child and actually
inserting it.
Also fixes a bug in fusefs which was causing it to deadlock under the new
lock ordering. We do not need to call kernfs.Dentry.InsertChild from newEntry
because it will always be called at the kernfs filesystem layer.
Updates #1193.
PiperOrigin-RevId: 334049264
|
|
The FD should hold a reference on the dentry they were opened on which in turn
holds a reference on the inode it points to.
PiperOrigin-RevId: 333589223
|
|
Update signatures for:
- All methods in inodeDirectory
- deferDecRef() and Filesystem.droppedDentries
- newSyntheticDirectory()
- `slot`s used in OrderedChildren and subsequent methods like
replaceChildLocked() and checkExistingLocked()
- stepExistingLocked(), walkParentDirLocked(), checkCreateLocked()
Updates #1193
PiperOrigin-RevId: 333558866
|
|
Updates #1663
PiperOrigin-RevId: 333539293
|
|
There were some instances where we were not enabling leak checking.
PiperOrigin-RevId: 333418571
|
|
Update signatures for:
- walkExistingLocked
- checkDeleteLocked
- Inode.Open
Updates #1193
PiperOrigin-RevId: 333163381
|
|
Updates #1193.
PiperOrigin-RevId: 332939026
|
|
PiperOrigin-RevId: 332486111
|
|
|
|
As noticed by @ayushr2, the "implements" comments are not
consistent, e.g.
// IterDirents implements kernfs.inodeDynamicLookup.
// Generate implements vfs.DynamicBytesSource.Generate.
This patch improves this by making the comments like this
consistently include the package name (when the interface
and struct are not in the same package) and method name.
Signed-off-by: Tiwei Bie <tiwei.btw@antgroup.com>
|
|
Fixes #3696
|
|
This commit implements FUSE_SETATTR command. When a system call modifies
the metadata of a regular file or a folder by chown(2), chmod(2),
truncate(2), utime(2), or utimes(2), they should be translated to
corresponding FUSE_SETATTR command and sent to the FUSE server.
Fixes #3332
|
|
Fixes #3255.
This change adds support for IterDirents. You can now use `ls` in
the FUSE sandbox.
Co-authored-by: Craig Chi <craigchi@google.com>
|
|
Fixes #3587
Co-authored-by: Craig Chi <craigchi@google.com>
|
|
Fixes #3316
|
|
Fixes #3231
Co-authored-by: Boyuan He <heboyuan@google.com>
|
|
Make setting STATX_SIZE a no-op, if it is valid for the given permissions and
file type.
Also update proc tests, which were overfitted before.
Fixes #3842.
Updates #1193.
PiperOrigin-RevId: 331861087
|
|
PiperOrigin-RevId: 330629897
|
|
Updates #1487
PiperOrigin-RevId: 330580699
|
|
PiperOrigin-RevId: 330554450
|
|
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
|
|
- Remove comment about GenericDirectoryFD not being compatible with
dynamic directories. It is currently being used to implement dynamic
directories.
- Try to handle SEEK_END better than setting the offset to
infinity. SEEK_END is poorly defined for dynamic directories
anyways, so at least try make it work correctly for the static
entries.
Updates #1193.
PiperOrigin-RevId: 327890128
|
|
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
|
|
This interface method is unneeded.
PiperOrigin-RevId: 327370325
|
|
Fixes #3243, #3521
PiperOrigin-RevId: 327308890
|
|
context is passed to DecRef() and Release() which is
needed for SO_LINGER implementation.
PiperOrigin-RevId: 324672584
|
|
- 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
|
|
Fix typos.
PiperOrigin-RevId: 322913282
|
|
To implement stat(2) in FUSE, we have to embed credentials and pid in request
header. The information should be extracted from the context passed to VFS
layer. Therefore `Stat()` signature in `kernfs.Inode` interface should include
context as first argument. Some other fs implementations need to be modified as
well, such as devpts, host, pipefs, and proc.
Fixes #3235
|
|
PiperOrigin-RevId: 321053634
|
|
PiperOrigin-RevId: 319283715
|
|
Updates #2923.
PiperOrigin-RevId: 318648128
|
|
- 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
|
|
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
|
|
Make proc/self/fd iteration work properly. Also, the comment on
kernfs.Inode.IterDirents did not accurately reflect how parameters should be
used/were used in kernfs.Inode impls other than fdDir.
Updates #2923.
PiperOrigin-RevId: 317370325
|
|
- 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
|
|
Limited to tmpfs. Inotify support in other filesystem implementations to
follow.
Updates #1479
PiperOrigin-RevId: 313828648
|
|
PiperOrigin-RevId: 313817646
|
|
Support in other filesystem impls is still needed. Unlike in Linux and vfs1, we
need to plumb inotify down to each filesystem implementation in order to keep
track of links/inode structures properly.
IN_EXCL_UNLINK still needs to be implemented, as well as a few inotify hooks
that are not present in either vfs1 or vfs2. Those will be addressed in
subsequent changes.
Updates #1479.
PiperOrigin-RevId: 313781995
|
|
Updates #1197, #1198, #1672
PiperOrigin-RevId: 310432006
|
|
Implement PrependPath() in host.filesystem to correctly format
name for host files.
Updates #1672
PiperOrigin-RevId: 309959135
|
