From d8b5d43a04fba8ba09d5bb3c745808964f371d80 Mon Sep 17 00:00:00 2001 From: Jesse Gross Date: Mon, 26 Apr 2010 18:08:54 -0700 Subject: datapath: Don't hold dp_mutex when setting internal devs MTU. We currently acquire dp_mutex when we are notified that the MTU of a device attached to the datapath has changed so that we can set the internal devices to the minimum MTU. However, it is not required to hold dp_mutex because we already have RTNL lock and it causes a deadlock, so don't do it. Specifically, the issue is that DP mutex is acquired twice: once in dp_device_event() before calling set_internal_devs_mtu() and then again in internal_dev_change_mtu() when it is actually being changed (since the MTU can also be set directly). Since it's not a recursive mutex, deadlock. --- datapath/vport-internal_dev.c | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-) (limited to 'datapath/vport-internal_dev.c') diff --git a/datapath/vport-internal_dev.c b/datapath/vport-internal_dev.c index 39283e05..88b6cc19 100644 --- a/datapath/vport-internal_dev.c +++ b/datapath/vport-internal_dev.c @@ -144,13 +144,7 @@ static int internal_dev_change_mtu(struct net_device *netdev, int new_mtu) return -EINVAL; if (dp_port) { - int min_mtu; - - mutex_lock(&dp_port->dp->mutex); - min_mtu = dp_min_mtu(dp_port->dp); - mutex_unlock(&dp_port->dp->mutex); - - if (new_mtu > min_mtu) + if (new_mtu > dp_min_mtu(dp_port->dp)) return -EINVAL; } -- cgit v1.2.3