On Tue, 2019-07-23 at 14:33 -0700, David Miller wrote:
> From: Shannon Nelson <snel...@pensando.io>
> Date: Mon, 22 Jul 2019 14:40:15 -0700
>
> > + 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()" ..
