---
- branch: MAIN
  date: Thu May 19 20:51:46 UTC 2022
  files:
  - new: '1.118'
    old: '1.117'
    path: src/sys/opencrypto/crypto.c
    pathrev: src/sys/opencrypto/crypto.c@1.118
    type: modified
  - new: '1.113'
    old: '1.112'
    path: src/sys/opencrypto/cryptodev.c
    pathrev: src/sys/opencrypto/cryptodev.c@1.113
    type: modified
  - new: '1.43'
    old: '1.42'
    path: src/sys/opencrypto/cryptodev.h
    pathrev: src/sys/opencrypto/cryptodev.h@1.43
    type: modified
  id: 20220519T205146Z.e0cc7716f630b55d7170943d261d5cd9e12714a0
  log: |
    opencrypto: Nix CRYPTO_F_USER, CRYPTO_F_CBIMM, CRYPTO_F_CBIFSYNC.

    CRYPTO_F_USER is no longer needed.  It was introduced in 2008 by
    darran@ in crypto.c 1.30, cryptodev.c 1.45 in an attempt to avoid
    double-free between the issuing thread and asynchronous callback.
    But the `fix' didn't work.  In 2017, knakahara@ fixed it properly in
    cryptodev.c 1.87 by distinguishing `the crypto operation has
    completed' (CRYPTO_F_DONE) from `the callback is done touching the
    crp object' (CRYPTO_F_DQRETQ, now renamed to CRYPTODEV_F_RET).

    CRYPTO_F_CBIMM formerly served to invoke the callback synchronously
    from the driver's interrupt completion routine, to reduce contention
    on what was once a single cryptoret thread.  Now, there is a per-CPU
    queue and softint for much cheaper processing, so there is less
    motivation for this in the first place.  So let's remove the
    complicated logic.  This means the callbacks never run in hard
    interrupt context, which means we don't need to worry about recursion
    into crypto_dispatch in hard interrupt context.
  module: src
  subject: 'CVS commit: src/sys/opencrypto'
  unixtime: '1652993506'
  user: riastradh