lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <56E97BEA.4070004@kyup.com>
Date:	Wed, 16 Mar 2016 17:29:46 +0200
From:	Nikolay Borisov <kernel@...p.com>
To:	David Miller <davem@...emloft.net>
Cc:	netdev@...r.kernel.org,
	SiteGround Operations <operations@...eground.com>
Subject: ipv6 not bringing up due to qdisc_tx_is_noop failing

Hello Dave,

I've been chasing a rather strange problem and I saw you were the person
that authored most of the code involved so I'm addresing you, but will
be happy to receive assistance from any one feeling knowledgeable enough
on the issue.

Basically I have an infiniband card on which I want to run ipv6 to this
effect I load modules ib_qib (the infiniband card is qlogic QLE7342) and
then I load module ib_ipoib and I get :
IPv6: ADDRCONF(NETDEV_UP): ib0: link is not ready

even though for example ibping and all that works. This happens because
the check if (!addrconf_qdisc_ok(dev)) in addrconf_notify fails, since
the dev's txq ->qdisc points to noop_qdisc.

Now, here is what happens :

1. When the ib_ipoib module is loaded
register_netdevice->dev_init_scheduler is called which sets the device's
qdisc to noop_qdisc

2. Then via a netlink message the device is being activate, which calls
into dev_activate->attach_one_default_qdisc which attaches the newly
created default qdisc to the dev->sleeping_qdisc member

3. The addrconf_notify is invoked which fails the check since the
netdev_queue's qdisk member was never updated (just the sleeping_qdisc)
to anything different than the initial state (which is noop_qdisc).

I have stack traces which do show this sequence of events, so my
questions now are:

1. What's the difference between netdev_queue->qdisc and
netdev_queue->qdisc_sleeping. Git blaming indicates those member haves
existed even before the git history was started.

2. Shouldn't the netdev_queue->qdisc also be updated during
attach_one_default_qdisc?


Regards,
Nikolay

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ