summaryrefslogtreecommitdiffhomepage
path: root/pkg/sentry/fsbridge/BUILD
diff options
context:
space:
mode:
authorDean Deng <deandeng@google.com>2020-06-23 16:11:31 -0700
committergVisor bot <gvisor-bot@google.com>2020-06-23 16:14:56 -0700
commit0c628c3152a727fff287a98897d83ee45ad990e5 (patch)
tree71a7365dbf61a641753eb102affc766257dc6805 /pkg/sentry/fsbridge/BUILD
parent793edf4cb4597751b7f2b7b913a5ab7fa3d50373 (diff)
Support inotify in vfs2 gofer fs.
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
Diffstat (limited to 'pkg/sentry/fsbridge/BUILD')
0 files changed, 0 insertions, 0 deletions