diff options
author | Dean Deng <deandeng@google.com> | 2020-06-23 16:11:31 -0700 |
---|---|---|
committer | gVisor bot <gvisor-bot@google.com> | 2020-06-23 16:14:56 -0700 |
commit | 0c628c3152a727fff287a98897d83ee45ad990e5 (patch) | |
tree | 71a7365dbf61a641753eb102affc766257dc6805 /website/assets/images/2019-11-18-security-basics-figure1.png | |
parent | 793edf4cb4597751b7f2b7b913a5ab7fa3d50373 (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 'website/assets/images/2019-11-18-security-basics-figure1.png')
0 files changed, 0 insertions, 0 deletions