On Thu, 19 Nov 2020 16:37:51 +0100 Markus Blöchl wrote: > Implementation > ============== > > I then tried to come up with a solution in net/core that would > universally disable vlan filtering in promiscuous mode.
Thanks for taking a look! > Removing the features in `netdev_fix_features` is easily done, but > updating the active set of features whenever IFF_PROMISC changes > seems hard. > > `__dev_set_promiscuity` is often called in atomic context but > `.ndo_set_features` can sleep in many drivers. Are there paths other than __dev_set_rx_mode() which would call __dev_set_promiscuity() in atomic context? The saving grace about __dev_set_rx_mode() is that it sets promisc explicitly to disable unicast filtering (dev->uc_promisc), so IMO that case (dev->promiscuity == dev->uc_promisc) does not need to disable VLAN filtering. But IDK if that's the only atomic path. > Adding a work_queue or similar to every net_device seems clumsy and > inappropriate. > > Rewriting ndo_set_features of all drivers to be atomic is not a task > you should ask from me... > > Calling `netdev_update_features` after every entrypoint that locks > the rtnl seems too error-prone and also clumsy. > > Only updating the features when promiscuity was explicitly requested > by userspace in `dev_change_flags` might leave the device in a > weird inconsistent state. > > Continue to let each driver enforce the kernels definition of > promiscuity. They know how to update the features atomically. > Then I am back at my original patch... > > I'm afraid, I might need some guidance on how to approach this.
