|Priority:||4 - Normal|
Fixed: A fix for this issue is checked into the tree and tested.
(Resolution Date: 2018-07-30T14:57:22.939Z)
2018-08-02 XCannon (Release Date: 2018-08-02)
Prior to OS-7034, updates to the ctxop list associated with a kthread were simple: The new item would update its
next pointer to the value of
t_ctx, then it would update
t_ctx so it pointed at the new value. If a preemption occurred any time before the
t_ctx update, the new item would not be called for save or restore. If it occurred after the
t_ctx update, both savectx and restorectx would act upon the new time.
With the change to a doubly-linked list for ctxops, it is no longer safe to do this without
kpreempt_disable protection. There is a short window between the
prev field of the head item is updated and when
t_ctx itself is pointed to the new item that a preemption would result in the
savectx operation being skipped for the new item but the
restorectx operation executing on it.
A simple application of
kpreempt_disable/kpreempt_enable should be all that's needed to protect that window from danger.
I only caught this as I was reviewing ctxop-related code. The problematic behavior described is not something I've seen in the wild.
I booted up bits with this change as a smoke test, but haven't done gone further than that.
illumos-joyent commit 84b3dff9b0680a7c2e5ce7f1066fedc9ef036560 (branch master, by Patrick Mooney)
OS-7096 installctx needs kpreempt_disable protection
Reviewed by: John Levon <email@example.com>
Reviewed by: Jerry Jelinek <firstname.lastname@example.org>
Reviewed by: Robert Mustacchi <email@example.com>
Approved by: Robert Mustacchi <firstname.lastname@example.org>