[ovs-dev] [netlink v4 47/52] datapath: Adopt Generic Netlink-compatible locking.

[Jesse Gross]

On Tue, Jan 11, 2011 at 9:49 PM, Ben Pfaff <blp at nicira.com> wrote:
> The kernel Generic Netlink layer always holds a mutex (genl_lock) when it
> invokes callbacks, so that means that there is no point in having
> per-datapath mutexes or a separate vport lock.  This commit removes them.
>
> A single innermost dp_mutex is still needed to provide mutual exclusion
> with network device notifiers.
>
> Now, locks have the following hierarchy:
>
> genl_lock
>        rtnl_lock
>                dp_mutex
>
> This is undesirable, but we're stuck with it:
>
>  - Generic Netlink message receive holds genl_lock while calling into us,
>    so genl_lock is always held while executing userspace commands.  Some
>    commands need rtnl_lock, so rtnl_lock has to nest inside genl_lock.
>
>  - Network device notifiers hold the rtnl_lock when they call into us.
>    We can't take genl_lock there to get mutual exclusion versus userspace
>    command execution because that would invert the order.
>
> Therefore, dp_mutex exists as an innermost lock that can be taken in both
> these situations.  There should be no contention on it, because it is almost
> completely redundant with genl_lock, since genl_lock is taken before
> dp_mutex in every situation except when the Open vSwitch network device
> notifier is running.
>
> It might be possible to drop dp_mutex given a little bit of cleverness but
> I haven't gone to the trouble.
>
> This commit breaks support for Linux before 2.6.35 because it calls
> genl_lock(), which wasn't exported before that version.  That problem will
> be fixed once the whole userspace interface transitions to Generic
> Netlink a few commits from now.

Also, I get a sparse error from the direct access to dp->table in
odpfc_dump().  I thought that you had fixed that at some point but I'm
seeing the warning with the most recent version of your code.