Project

General

Profile

Actions

Feature #12478

closed

installctx needs kpreempt_disable protection

Added by Patrick Mooney over 1 year ago. Updated over 1 year ago.

Status:
Closed
Priority:
Normal
Category:
kernel
Start date:
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:

Description

Upstreaming OS-7096 for bhyve:

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.


Related issues

Related to illumos gate - Feature #12477: ctxops should use stack ordering for save/restoreClosedPatrick Mooney

Actions
Related to illumos gate - Bug #13902: Fix for 13717 may break 8-disk raidz2ClosedDan McDonald

Actions
Related to illumos gate - Bug #13908: disable kernel FPU by default until it is stableClosedJoshua M. Clulow

Actions
Related to illumos gate - Bug #13915: installctx() blocking allocate causes problemsClosedDan McDonald

Actions
Actions #1

Updated by Dan McDonald over 1 year ago

See #12477 for testing done to confirm this as well.

Actions #2

Updated by Patrick Mooney over 1 year ago

  • Related to Feature #12477: ctxops should use stack ordering for save/restore added
Actions #3

Updated by Electric Monk over 1 year ago

  • Status changed from In Progress to Closed
  • % Done changed from 0 to 100

git commit 6e2e67256d436ef900becfa771aee283e7e55430

commit  6e2e67256d436ef900becfa771aee283e7e55430
Author: Patrick Mooney <pmooney@pfmooney.com>
Date:   2020-04-16T19:20:32.000Z

    12477 ctxops should use stack ordering for save/restore
    12478 installctx needs kpreempt_disable protection
    Reviewed by: John Levon <john.levon@joyent.com>
    Reviewed by: Robert Mustacchi <rm@joyent.com>
    Reviewed by: Jerry Jelinek <jerry.jelinek@joyent.com>
    Reviewed by: Andy Fiddaman <andy@omniosce.org>
    Approved by: Dan McDonald <danmcd@joyent.com>

Actions #4

Updated by Dan McDonald 5 months ago

  • Related to Bug #13902: Fix for 13717 may break 8-disk raidz2 added
Actions #5

Updated by Joshua M. Clulow 5 months ago

  • Related to Bug #13908: disable kernel FPU by default until it is stable added
Actions #6

Updated by Dan McDonald 5 months ago

  • Related to Bug #13915: installctx() blocking allocate causes problems added
Actions

Also available in: Atom PDF