Page MenuHomeFreeBSD

kqueue: drain kqueue taskqueue if syscall tickled it
ClosedPublic

Authored by kib on Sep 6 2021, 11:47 AM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, May 9, 10:18 PM
Unknown Object (File)
Sat, May 4, 2:27 AM
Unknown Object (File)
Thu, Apr 25, 4:27 AM
Unknown Object (File)
Mon, Apr 22, 4:55 AM
Unknown Object (File)
Mon, Apr 22, 4:55 AM
Unknown Object (File)
Mon, Apr 22, 4:42 AM
Unknown Object (File)
Fri, Apr 19, 4:24 PM
Unknown Object (File)
Tue, Apr 16, 11:18 AM
Subscribers
None

Details

Summary

Otherwise return from the syscall and next syscall, which could be kevent(2) on the kqueue that should be notified, races with the kqueue taskqueue thread, and potentially miss the wakeup. This is reliably visible when kevent(2) only peeks into events using zeroed timeout.

PR: 258310

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

kib requested review of this revision.Sep 6 2021, 11:47 AM
kib created this revision.

I can confirm this reliably fixes the test original test case (converted to ATF in D31862).
Code looks good to me, but since I'm not familiar with that part of the kernel I'd wait for @markj to review too.

This revision is now accepted and ready to land.Sep 6 2021, 3:22 PM
markj added inline comments.
sys/kern/kern_event.c
1774

Isn't taskqueue_drain_all() sufficient? Or is the idea that we may have a chain of multiple kqueues listening to each other, and we need to wait until all of them have been notified?

kib marked an inline comment as done.Sep 6 2021, 10:30 PM
kib added inline comments.
sys/kern/kern_event.c
1774

Yes, I do not think that it is formally enough to drain only tasks already scheduled on the taskqueue.

This is a rare situation anyway so I do not think there is much overhead to wait for full quiesce.

This revision was automatically updated to reflect the committed changes.
kib marked an inline comment as done.