From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753770AbXCSJzI (ORCPT ); Mon, 19 Mar 2007 05:55:08 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753773AbXCSJzH (ORCPT ); Mon, 19 Mar 2007 05:55:07 -0400 Received: from ug-out-1314.google.com ([66.249.92.171]:26592 "EHLO ug-out-1314.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753764AbXCSJzG (ORCPT ); Mon, 19 Mar 2007 05:55:06 -0400 Date: Mon, 19 Mar 2007 11:55:45 +0200 From: "Michael S. Tsirkin" To: "Michael S. Tsirkin" Cc: Alexey Kuznetsov , Linux Kernel Mailing List , netdev@vger.kernel.org, general@lists.openfabrics.org, Roland Dreier , David Miller Subject: Re: dst_ifdown breaks infiniband? Message-ID: <20070319095545.GF8386@mellanox.co.il> Reply-To: "Michael S. Tsirkin" References: <20070318155532.GG7958@mellanox.co.il> <20070318191238.GA20518@ms2.inr.ac.ru> <20070318195355.GB11078@mellanox.co.il> <20070318201826.GB27004@ms2.inr.ac.ru> <20070319093632.GB8386@mellanox.co.il> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070319093632.GB8386@mellanox.co.il> User-Agent: Mutt/1.5.11 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org > Quoting Michael S. Tsirkin : > Subject: Re: dst_ifdown breaks infiniband? > > > > Any simpler ideas? > > > > Well, if inifiniband destructor really needs to take that lock... no. > > Right now I do not see. > > OK, this is actually not hard to fix - for infiniband, we can just look at > neighbour->dev->type or compare neighbour->dev and > neighbour->parms->dev - if they are different, device is being unregistered, > so we do not need to do anything in the destructor. > > I'll send a patch to openfabrics, shortly. > > However, after implementing this fix, I hit what could be use after > free at module unloading. Dave, Alexey, Roland, could you take a look at > the following please? > > Works fine for me (survived a couple of hours of crazy device > loading/unloading/up/down/hotplug + link data and state activity) > and seems to fix the issue. > > --------- > > If a device driver sets neigh_destructor in neigh_params, this could > get called after the device has been unregistered and the driver module > removed. > > This is an old bug, but apparently, started to get triggered more infiniband > after recent multicast and connected mode changes. > > Fix this by delaying dev_put until the neigh_params object is removed. > > Signed-off-by: Michael S. Tsirkin The problem seems real enough but the fix seems no good - device unregister gets blocked with unregister_netdevice: waiting for ib0 to become free. Usage count = 1 It seems the parms object can survive indefinitely after device is removed. How about creating a new parms object in dst_ifdown, and pointing neighbour to this? Would that work? The advantage of this approach is that neigh->parms is already protected by RCU. -- MST