summaryrefslogtreecommitdiffhomepage
path: root/pkg/sentry/fs/mount.go
AgeCommit message (Collapse)Author
2019-01-14Remove fs.Handle, ramfs.Entry, and all the DeprecatedFileOperations.Nicolas Lacasse
More helper structs have been added to the fsutil package to make it easier to implement fs.InodeOperations and fs.FileOperations. PiperOrigin-RevId: 229305982 Change-Id: Ib6f8d3862f4216745116857913dbfa351530223b
2018-10-19Use correct company name in copyright headerIan Gudger
PiperOrigin-RevId: 217951017 Change-Id: Ie08bf6987f98467d07457bcf35b5f1ff6e43c035
2018-08-27fs: Fix remote-revalidate cache policy.Nicolas Lacasse
When revalidating a Dirent, if the inode id is the same, then we don't need to throw away the entire Dirent. We can just update the unstable attributes in place. If the inode id has changed, then the remote file has been deleted or moved, and we have no choice but to throw away the dirent we have a look up another. In this case, we may still end up losing a mounted dirent that is a child of the revalidated dirent. However, that seems appropriate here because the entire mount point has been pulled out from underneath us. Because gVisor's overlay is at the Inode level rather than the Dirent level, we must pass the parent Inode and name along with the Inode that is being revalidated. PiperOrigin-RevId: 210431270 Change-Id: I705caef9c68900234972d5aac4ae3a78c61c7d42
2018-08-10fs: Allow overlays to revalidate files from the upper fs.Nicolas Lacasse
Previously, an overlay would panic if either the upper or lower fs required revalidation for a given Dirent. Now, we allow revalidation from the upper file, but not the lower. If a cached overlay inode does need revalidation (because the upper needs revalidation), then the entire overlay Inode will be discarded and a new overlay Inode will be built with a fresh copy of the upper file. As a side effect of this change, Revalidate must take an Inode instead of a Dirent, since an overlay needs to revalidate individual Inodes. PiperOrigin-RevId: 208293638 Change-Id: Ic8f8d1ffdc09114721745661a09522b54420c5f1
2018-08-02Update comment referenceMichael Pratt
PiperOrigin-RevId: 207180809 Change-Id: I08c264812919e81b2c56fdd4a9ef06924de8b52f
2018-08-02Automated rollback of changelist 207037226Zhaozhong Ni
PiperOrigin-RevId: 207125440 Change-Id: I6c572afb4d693ee72a0c458a988b0e96d191cd49
2018-08-01Automated rollback of changelist 207007153Michael Pratt
PiperOrigin-RevId: 207037226 Change-Id: I8b5f1a056d4f3eab17846f2e0193bb737ecb5428
2018-08-01stateify: convert all packages to use explicit mode.Zhaozhong Ni
PiperOrigin-RevId: 207007153 Change-Id: Ifedf1cc3758dc18be16647a4ece9c840c1c636c9
2018-07-19fs: Pass context to Revalidate() function.Nicolas Lacasse
The current revalidation logic is very simple and does not do much introspection of the dirent being revalidated (other than looking at the type of file). Fancier revalidation logic is coming soon, and we need to be able to look at the cached and uncached attributes of a given dirent, and we need a context to perform some of these operations. PiperOrigin-RevId: 205307351 Change-Id: If17ea1c631d8f9489c0e05a263e23d7a8a3bf159
2018-06-25MountSource.Root() should return a refernce on the dirent.Nicolas Lacasse
PiperOrigin-RevId: 202038397 Change-Id: I074d525f2e2d9bcd43b247b62f86f9129c101b78
2018-04-28Check in gVisor.Googler
PiperOrigin-RevId: 194583126 Change-Id: Ica1d8821a90f74e7e745962d71801c598c652463