On 06.01.2016 22:01, Jesse Gross wrote:
On Wed, Jan 6, 2016 at 12:25 PM, Hannes Frederic Sowa
<han...@stressinduktion.org> wrote:
The refreshes from each module are completely synchronous and don't get
interleaved, so as long as the driver is correctly handling the locking
internally rtnl lock shouldn't be needed. But as I don't know too much about
driver developing I can revisit this.
As a advantage I see that the driver developers don't need to worry about
the rtnl lock at all when adding new events. Is this realistic?
I don't think that there is much savings to be had by avoiding RTNL
since the majority of interactions that the driver has with the stack
involve holding it anyways.
In order to do this safely without RTNL we need to have a lock in each
driver. I don't think that this is safely handled in all cases today
and is likely to get worse in the future. I also noticed that Geneve
actually doesn't hold any special lock while calling into drivers from
geneve_get_rx_port() so it is de-facto relying on RTNL. All other
operations in the Geneve driver are protected by RTNL currently, so we
would need to introduce a new lock to handle this as well. In effect,
it seems like people are implicitly assuming that these operations are
covered by RTNL since most similar things are.
Okay, on top of the v1 version I will check all drivers and add
necessary rtnl_locks. Hopefully it works out and I don't have to defer
calls into working queues in the drivers first.
Thanks,
Hannes
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
