mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@dev.mellanox.co.il>
To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	netdev@vger.kernel.org, general@lists.openfabrics.org,
	Roland Dreier <rolandd@cisco.com>,
	Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Subject: dst_ifdown breaks infiniband?
Date: Sun, 18 Mar 2007 17:55:32 +0200	[thread overview]
Message-ID: <20070318155532.GG7958@mellanox.co.il> (raw)

Alexey, Roland,
In debugging kernel lockup that occurs with IP over InfiniBand in 2.6.21-rc4:
( https://bugs.openfabrics.org/show_bug.cgi?id=402 )

I noticed the following code in dst_ifdown:

/* Dirty hack. We did it in 2.2 (in __dst_free),
 * we have _very_ good reasons not to repeat
 * this mistake in 2.3, but we have no choice
 * now. _It_ _is_ _explicit_ _deliberate_
 * _race_ _condition_.
 *
 * Commented and originally written by Alexey.
 */
static inline void dst_ifdown(struct dst_entry *dst, struct net_device *dev,
                              int unregister)
{
        if (dst->ops->ifdown)
                dst->ops->ifdown(dst, dev, unregister);

        if (dev != dst->dev)
                return;

        if (!unregister) {
                dst->input = dst_discard_in;
                dst->output = dst_discard_out;
        } else {
                dst->dev = &loopback_dev;
                dev_hold(&loopback_dev);
                dev_put(dev);
                if (dst->neighbour && dst->neighbour->dev == dev) {
                        dst->neighbour->dev = &loopback_dev;
                        dev_put(dev);
                        dev_hold(&loopback_dev);
                }
        }
}

The line dst->neighbour->dev = &loopback_dev breaks IP over InfiniBand,
simply because neighbour->parms still points to an entry that has
been set up with dev->neigh_setup call from IPoIB neighbour device.

So when neighbour->parms->neigh_destructor is called,
we get to ipoib_neigh_destructor in drivers/infiniband/ulp/ipoib/ipoib_main.c,
and that in turn crashes since it needs an infiniband device
in neighbour dev pointer.

This is not new code, and should have triggered long time ago,
so I am not sure how come we are triggering this only now,
but somehow this did not lead to crashes in 2.6.20, but does now in 2.6.21-rc4.

Ideas on how to fix this?

Why is neighbour->dev changed here?

Can dst->neighbour be changed to point to NULL instead, and the neighbour
released?

Thanks very much,
-- 
MST

             reply	other threads:[~2007-03-18 15:54 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-18 15:55 Michael S. Tsirkin [this message]
2007-03-18 19:12 ` Alexey Kuznetsov
2007-03-18 19:46   ` Michael S. Tsirkin
2007-03-18 19:55     ` Alexey Kuznetsov
2007-03-18 20:24       ` Michael S. Tsirkin
2007-03-18 19:53   ` Michael S. Tsirkin
2007-03-18 20:18     ` Alexey Kuznetsov
2007-03-18 20:29       ` Michael S. Tsirkin
2007-03-19  9:36       ` Michael S. Tsirkin
2007-03-19  9:55         ` Michael S. Tsirkin
2007-03-19 12:05         ` Alexey Kuznetsov
2007-03-19 12:12           ` Michael S. Tsirkin
2007-03-19 12:59             ` Alexey Kuznetsov
2007-03-19 15:13               ` Michael S. Tsirkin
2007-03-19 23:20                 ` Alexey Kuznetsov
2007-03-20 16:02                   ` Michael S. Tsirkin
2007-03-20 23:34                     ` David Miller
2007-03-19 12:13           ` Michael S. Tsirkin
2007-03-18 20:25   ` Michael S. Tsirkin
2007-03-18 22:24     ` [ofa-general] " Eric W. Biederman
2007-03-18 22:36       ` Michael S. Tsirkin
2007-03-18 22:42         ` Michael S. Tsirkin
2007-03-19  0:13           ` David Miller
2007-03-19  5:19             ` Michael S. Tsirkin
2007-03-19  5:30             ` Eric W. Biederman
2007-03-19  6:13               ` David Miller
2007-03-19  9:34                 ` Alexey Kuznetsov
2007-03-19 15:10                 ` Eric W. Biederman
2007-03-19  9:24           ` Alexey Kuznetsov
2007-03-19  9:33             ` Michael S. Tsirkin
2007-03-19  9:20       ` Alexey Kuznetsov
2007-03-18 20:33   ` Michael S. Tsirkin
2007-03-18 21:06     ` Michael S. Tsirkin
2007-03-18 21:20       ` Michael S. Tsirkin
2007-03-19  5:15         ` Michael S. Tsirkin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070318155532.GG7958@mellanox.co.il \
    --to=mst@dev.mellanox.co.il \
    --cc=general@lists.openfabrics.org \
    --cc=kuznet@ms2.inr.ac.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=rolandd@cisco.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®