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().