On Thu, Feb 2, 2017 at 6:05 PM, Joel Cunningham <joel.cunning...@me.com> wrote: > > In the case of SIOCSIFHWADDR, we get a pointer to the net_device through > __dev_get_by_name() and then pass it to dev_set_mac_address() to modify > through ndo_set_mac_address(). I didn’t see any uses of RCU APIs on the > writer side and that’s why I figured there was something going on with > rtnl_lock() that I didn’t understand or that the dev_ioctl function wasn’t > re-entrant from another CPU >
You are right, that RCU read lock could merely protect the netdevice from being unregistered concurrently, can't prevent a concurrent dev_ifsioc(). I don't know why Eric changed it to RCU read lock, it is not a hot path, using rtnl lock is fine and can guarantee a atomic read.
