Re: [PATCH net-next v5 09/15] bnxt_en: Add infrastructure for crypto key context IDs

Responding to Sashiko comments:
https://sashiko.dev/#/patchset/20260710042400.3996847-1-michael.chan%40broadcom.com

On Thu, Jul 9, 2026 at 9:24 PM Michael Chan [off-list ref] wrote:

+ * The ID is matched by its hardware id only (epoch stripped), so the caller
+ * must ensure it is valid for the current epoch.
+ */
+void bnxt_free_one_kctx(struct bnxt_kctx *kctx, u32 id)
+{
+       struct bnxt_kid_info *kid;
+
+       id = BNXT_KID_HW(id);
+       rcu_read_lock();
+       list_for_each_entry_rcu(kid, &kctx->list, list) {
+               if (id >= kid->start_id && id < kid->start_id + kid->count) {
+                       set_bit(id - kid->start_id, kid->ids);

Sashiko:
Could separating the epoch validation from the free operation introduce a
time-of-check to time-of-use race?
The API design forces callers to check the epoch via bnxt_kid_valid() prior
to calling bnxt_free_one_kctx():

bnxt_kid_valid()
  epoch = BNXT_KID_EPOCH(id);
  if (epoch != kctx->epoch)
    return false;

If a firmware reset happens between the caller's epoch check and the execution
of bnxt_free_one_kctx(), bnxt_clear_crypto() can advance the epoch and
replace the old lists.
Since bnxt_free_one_kctx() unconditionally strips the epoch from the provided
ID before traversing the list, is it possible for it to inadvertently set
the free bit on a stale hardware ID that has already been reassigned to a
completely different connection in the new epoch?

Response:
No, there is no TOCTOU race.  The epoch check and bnxt_clear_crypto()
cannot run concurrently when this code is put to use in patch 12.  The
epoch check is always under the critical section ktls->pending.  In
the shutdown path, the BNXT_STATE_OPEN flag is cleared and we wait for
ktls->pending to go to zero before we call bnxt_clear_crypto().