---
- branch: netbsd-8
  date: Tue Oct 24 09:14:59 UTC 2017
  files:
  - new: 1.53.2.1
    old: '1.53'
    path: src/sys/arch/arm/vfp/vfp_init.c
    pathrev: src/sys/arch/arm/vfp/vfp_init.c@1.53.2.1
    type: modified
  - new: 1.20.6.1
    old: '1.20'
    path: src/sys/kern/subr_pcu.c
    pathrev: src/sys/kern/subr_pcu.c@1.20.6.1
    type: modified
  id: 20171024T091459Z.42bcc7b3874e703f0c187dce8d9a54d8122722b2
  log: "Pull up following revision(s) (requested by bouyer in ticket #326):\n\tsys/arch/arm/vfp/vfp_init.c:
    revision 1.54-1.55\n\tsys/kern/subr_pcu.c: revision 1.21\nPR port-arm/52603:\nThere
    is a race here, as seen on arm with FPU:\nLWP L is running but not on CPU, has
    its FPU state on CPU2 which\nhas not been released yet, so fpexc still has VFP_FPEXC_EN
    set in the PCB copy.\nLWP L is scheduled on CPU1, CPU1 calls cpu_switchto() for
    L in mi_switch().\ncpu_switchto() will set VFP_FPEXC_EN in the FPU's fpexc register
    per the\nPCB fpexc copy.\nBefore CPU1 calls pcu_switchpoint() for L, CPU2 calls\npcu_do_op(PCU_CMD_SAVE
    | PCU_CMD_RELEASE) for L because it still holds its\nFPU state and wants to load
    another lwp. This cause VFP_FPEXC_EN to\nbe cleared in the PCB copy, but not in
    CPU1's register. L's l_pcu_cpu is\nset to NULL.\nWhen CPU1 calls pcu_switchpoint()
    for L it see l_pcu_cpu is NULL, and doesn't\ncall the release callback.\nNow CPU1
    has its FPU enabled but with the wrong FPU state.\nFix by releasing the PCU even
    if l_pcu_cpu is NULL.\n--\nIn the REENABLE case, make sur the fpexc copy in the
    pcb also has\nVFP_FPEXC_EN set. Otherwise we could trap on every context switch
    even if\nthe CPU already has the VFP state.\n--\nWe KASSERT((fregs->vfp_fpexc
    & VFP_FPEXC_EN) == 0) just before, so\nenabled is always false. remove.\n"
  module: src
  subject: 'CVS commit: [netbsd-8] src/sys'
  unixtime: '1508836499'
  user: snj