summaryrefslogtreecommitdiffhomepage
path: root/test/util/proc_util_test.cc
diff options
context:
space:
mode:
authorJamie Liu <jamieliu@google.com>2020-09-15 13:23:14 -0700
committergVisor bot <gvisor-bot@google.com>2020-09-15 13:25:58 -0700
commit0d790cbaea5cd40ceabdf8f59978efff1a0626f1 (patch)
tree14a0d03184804079a69814bebbda703376c5a24c /test/util/proc_util_test.cc
parent86b31a80777dd906b275fb4b21888e93836f8a9b (diff)
Read vfs2 epoll events atomically.
Discovered by ayushranjan@: VFS2 was employing the following algorithm for fetching ready events from an epoll instance: - Create a statically sized EpollEvent slice on the stack of size 16. - Pass that to EpollInstance.ReadEvents() to populate. - EpollInstance.ReadEvents() requeues level-triggered events that it returns back into the ready queue. - Write the results to usermem. - If the number of results were = 16 then recall EpollInstance.ReadEvents() in the hopes of getting more. But this will cause duplication of the "requeued" ready level-triggered events. So if the ready queue has >= 16 ready events, the EpollWait for loop will spin until it fills the usermem with `maxEvents` events. Fixes #3521 PiperOrigin-RevId: 331840527
Diffstat (limited to 'test/util/proc_util_test.cc')
0 files changed, 0 insertions, 0 deletions