diff options
author | Jamie Liu <jamieliu@google.com> | 2020-09-15 13:23:14 -0700 |
---|---|---|
committer | gVisor bot <gvisor-bot@google.com> | 2020-09-15 13:25:58 -0700 |
commit | 0d790cbaea5cd40ceabdf8f59978efff1a0626f1 (patch) | |
tree | 14a0d03184804079a69814bebbda703376c5a24c /test/util/proc_util_test.cc | |
parent | 86b31a80777dd906b275fb4b21888e93836f8a9b (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