[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20070318.171337.112622504.davem@davemloft.net>
Date: Sun, 18 Mar 2007 17:13:37 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: mst@....mellanox.co.il
Cc: ebiederman@...i.com, kuznet@....inr.ac.ru, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, general@...ts.openfabrics.org
Subject: Re: [ofa-general] Re: dst_ifdown breaks infiniband?
From: "Michael S. Tsirkin" <mst@....mellanox.co.il>
Date: Mon, 19 Mar 2007 00:42:34 +0200
> > Quoting Michael S. Tsirkin <mst@....mellanox.co.il>:
> > Subject: Re: [ofa-general] Re: dst_ifdown breaks infiniband?
> >
> > > Quoting Eric W. Biederman <ebiederman@...i.com>:
> > > Subject: Re: [ofa-general] Re: dst_ifdown breaks infiniband?
> > >
> > > "Michael S. Tsirkin" <mst@....mellanox.co.il> writes:
> > >
> > > >> > Why is neighbour->dev changed here?
> > > >>
> > > >> It holds reference to device and prevents its destruction.
> > > >> If dst is held somewhere, we cannot destroy the device and deadlock
> > > >> while unregister.
> > > >
> > > > BTW, can this ever happen for the loopback device itself?
> > > > Is it ever unregistered?
> > >
> > > Well I don't think the loopback device is currently but as soon
> > > as we get network namespace support we will have multiple loopback
> > > devices and they will get unregistered when we remove the network
> > > namespace.
> >
> > Hmm. Then the code moving dst->dev to point to the loopback
> > device will have to be fixed too. I'll post a patch a bit later.
>
> Does this look sane (untested)?
>
> Signed-off-by: Michael S. Tsirkin <mst@....mellanox.co.il>
You can't point it at NULL, we don't point it at loopback
just for fun.
There can be asynchronous paths elsewhere in the networking still
referencing the neigh or dst and they will (correctly) feel free to
derefence whatever device is hanging there. So transitioning
to NULL is invalid.
You guys will need to come up with a better solution for this silly
situation with network namespaces. Loopback is always available to
point dead routes and neighbour entries at, and this assumption is
massively rooted in the networking.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists