summaryrefslogtreecommitdiffstats
path: root/lib/libsqlite3/src
diff options
context:
space:
mode:
authorhaesbaert <haesbaert@openbsd.org>2013-06-06 13:09:37 +0000
committerhaesbaert <haesbaert@openbsd.org>2013-06-06 13:09:37 +0000
commita48ed3ddf91c491c5b0741e2d21af575c8e2051b (patch)
treeb114f43fa0e4dda72dfdb05ec30206a7996a7e89 /lib/libsqlite3/src
parentdont count rx ring overruns as input errors. with MCLGETI controlling the (diff)
downloadwireguard-openbsd-a48ed3ddf91c491c5b0741e2d21af575c8e2051b.tar.xz
wireguard-openbsd-a48ed3ddf91c491c5b0741e2d21af575c8e2051b.zip
Prevent idle thread from being stolen on startup.
There is a race condition which might trigger a case where two cpus try to run the same idle thread. The problem arises when one cpu steals the idle proc of another cpu and this other cpu ends up running the idle thread via spc->spc_idleproc, resulting in two cpus trying to cpu_switchto(idleX). On startup, idle procs are scaterred around different runqueues, the decision for scheduling is: 1 look at my runqueue. 2 if empty, look at other dudes runqueue. 3 if empty, select idle proc via spc->spc_idleproc. The problem is that cpu0's idle0 might be running on cpu1 due to step 1 or 2 and cpu0 hits step 3. So cpu0 will select idle0, while cpu1 is in fact running it already. The solution is to never place idle on a runqueue, therefore being only selectable through spc->spc_idleproc. This race can be more easily triggered on a HT cpu on virtualized environments, where the guest more often than not doesn't have the cpu for itself, so timing gets shuffled. ok tedu@ guenther@ go ahead after t2k13 deraadt@
Diffstat (limited to 'lib/libsqlite3/src')
0 files changed, 0 insertions, 0 deletions