Thread (20 messages) read the whole thread 20 messages, 2 authors, 2d ago

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

From: Michael Chan <michael.chan@broadcom.com>
Date: 2026-07-30 06:35:26

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:
+void bnxt_clear_crypto(struct bnxt *bp)
+{
+       struct bnxt_crypto_info *crypto = bp->crypto_info;
+       struct bnxt_kid_info *kid, *tmp;
+       struct bnxt_kctx *kctx;
+       int i;
+
+       if (!crypto)
+               return;
+
+       /* No concurrent access; see the locking note above. */
+       for (i = 0; i < BNXT_MAX_CRYPTO_KEY_TYPE; i++) {
+               kctx = &crypto->kctx[i];
+               list_for_each_entry_safe(kid, tmp, &kctx->list, list) {
+                       list_del(&kid->list);
+                       kfree(kid);
+               }
Sashiko:
Is the locking assumption stated in the comment always met?
Looking at bnxt_io_error_detected() in bnxt.c, it appears to call
bnxt_clear_crypto() without clearing BNXT_STATE_OPEN or synchronizing against
asynchronous socket closures:

bnxt_io_error_detected()
  if (pci_is_enabled(pdev))
    pci_disable_device(pdev);
  bnxt_clear_crypto(bp);

Response:
Yes the locking assumption is always met.  In
bnxt_io_error_detected(), we do this under netdev_lock():

if (netif_running())
  __bnxt_close_nic()

So BNXT_STATE_OPEN is always cleared and the device is quiesced before
we call bnxt_clear_crypto().

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help