---
- branch: MAIN
  date: Sat Apr  2 09:53:20 UTC 2022
  files:
  - new: '1.146'
    old: '1.145'
    path: src/sys/dev/cgd.c
    pathrev: src/sys/dev/cgd.c@1.146
    type: modified
  id: 20220402T095320Z.11d65b234d2b37b2a35ca033268c46a1045ded4e
  log: |
    cgd(4): Omit technically-correct-but-broken adiantum dependency again.

    It is true that cgd_crypto.c depends on sys/crypto/adiantum now, and
    transitively on sys/crypto/aes.

    However, there's a problem with the cgd module having a formal
    (transitive) module dependency on the aes module.

    Yesterday I thought the problem with this was that fpu_kern_enter was
    artificially restricted while cold -- to detect, and noisily crash
    on, reentrance, it raises the IPL to IPL_VM, asserts that the IPL is
    not _higher_ (so it can't be re-entered by an IPL_SCHED or IPL_HIGH
    interrupt), and asserts that it's not currently in use on the current
    CPU.

    Early at boot, the IPL is at IPL_HIGH, and no interrupts are possible
    anyway, so the assertions tripped for artificial reasons, which I
    fixed in:

    https://mail-index.netbsd.org/source-changes/2022/04/01/msg137840.html

    However, I had forgotten that there's a deeper problem for the cgd
    module dependency on aes.  The ordering of events is:

    1. Initialize builtin MODULE_CLASS_DRIVER modules -- including cgd.

    2. Run configure -- including detecting CPUs, which on aarch64 is
       where the decision of which AES (and ChaCha) implementation to use
       based on supported CPU features.

    3. Initialize builtin MODULE_CLASS_MISC modules -- including aes,
       _if_ there are no driver-class modules that depend on it.

    There's a tangle of ordering dependencies here:

    - MODULE_CLASS_DRIVER modules providing _autoconf_ drivers generally
      have to be initialized _before_ configure, because you need the
      driver to be initialized before configure can attach its devices.

    - configure must run _before_ aes is initialized because the decision
      of which AES implementation to choose depends on CPU features
      detected in configure, and the prospect of dynamically changing the
      AES implementation is too painful to contemplate (it may change the
      key schedule, so it would invalidate any existing key schedules
      precomputed by callers like uvm_swap or configured cgd devices,
      which raises a host of painful concurrency issues to invalidate
      these cached key schedules on all CPUs in all subsystems using
      them).

    - cgd doesn't figure into the configure stage of autoconf, but it
      nevertheless has to be MODULE_CLASS_DRIVER because specfs autoloads
      MODULE_CLASS_DRIVER modules in case they provide _devsw_ drivers
      (i.e., /dev nodes), as cgd does.  And we don't have a mechanism for
      identifying `autoconf driver modules' separately from `devsw driver
      modules' because some modules provide both and each module can have
      only one class.

    For now, this is breaking boot on several tier I architectures so
    let's nix the cgd->adiantum->aes module dependency as a stop-gap
    measure.
  module: src
  subject: 'CVS commit: src/sys/dev'
  unixtime: '1648893200'
  user: riastradh