summaryrefslogtreecommitdiffhomepage
path: root/test/syscalls/linux/ppoll.cc
diff options
context:
space:
mode:
authorAyush Ranjan <ayushranjan@google.com>2020-11-18 23:08:04 -0800
committergVisor bot <gvisor-bot@google.com>2020-11-18 23:10:30 -0800
commit74bc6e56ccd999998805e142622314f86dce770c (patch)
tree6196b931de72143cbd00ad3b0b776d2d5cbc9080 /test/syscalls/linux/ppoll.cc
parente5650d124032e38a26e4b8058778e1c5b5aacbf0 (diff)
[vfs] kernfs: Do not panic if destroyed dentry is cached.
If a kernfs user does not cache dentries, then cacheLocked will destroy the dentry. The current DecRef implementation will be racy in this case as the following can happen: - Goroutine 1 calls DecRef and decreases ref count from 1 to 0. - Goroutine 2 acquires d.fs.mu for reading and calls IncRef and increasing the ref count from 0 to 1. - Goroutine 2 releases d.fs.mu and calls DecRef again decreasing ref count from 1 to 0. - Goroutine 1 now acquires d.fs.mu and calls cacheLocked which destroys the dentry. - Goroutine 2 now acquires d.fs.mu and calls cacheLocked to find that the dentry is already destroyed! Earlier we would panic in this case, we could instead just return instead of adding complexity to handle this race. This is similar to what the gofer client does. We do not want to lock d.fs.mu in the case that the filesystem caches dentries (common case as procfs and sysfs do this) to prevent congestion due to lock contention. PiperOrigin-RevId: 343229496
Diffstat (limited to 'test/syscalls/linux/ppoll.cc')
0 files changed, 0 insertions, 0 deletions