On Tue, 2019-07-23 at 14:33 -0700, David Miller wrote:

From: Shannon Nelson <redacted>
Date: Mon, 22 Jul 2019 14:40:15 -0700

quoted

+	if (in_interrupt()) {
+		work = kzalloc(sizeof(*work), GFP_ATOMIC);
+		if (!work) {
+			netdev_err(lif->netdev, "%s OOM\n", __func__);
+			return -ENOMEM;
+		}
+		work->type = add ? DW_TYPE_RX_ADDR_ADD :
DW_TYPE_RX_ADDR_DEL;
+		memcpy(work->addr, addr, ETH_ALEN);
+		netdev_dbg(lif->netdev, "deferred: rx_filter %s %pM\n",
+			   add ? "add" : "del", addr);
+		ionic_lif_deferred_enqueue(&lif->deferred, work);
+	} else {
+		netdev_dbg(lif->netdev, "rx_filter %s %pM\n",
+			   add ? "add" : "del", addr);
+		if (add)
+			return ionic_lif_addr_add(lif, addr);
+		else
+			return ionic_lif_addr_del(lif, addr);
+	}

I don't know about this.

Generally interface address changes are expected to be synchronous.

Well, drivers can't sleep on set_rx_mode ndo, dev_set_rx_mode is
holding netif_addr_lock_bh.

Some drivers need to wait for firmware/device completion to program the
new address and they have to do this asynchronously to avoid atomic
context. I assume this driver is having the same issue due to
"ionic_adminq_post_wait()" ..