netdev - usb interrupt storms from the ax88179 hardware

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>] [day] [month] [year] [list]

Date:	Mon, 3 Feb 2014 17:17:19 +0000
From:	David Laight <David.Laight@...LAB.COM>
To:	netdev <netdev@...r.kernel.org>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	Freddy Xin <freddy@...x.com.tw>
Subject: usb interrupt storms from the ax88179 hardware

On one system (an amd motherboard with the ASMedia xhci controller)
I'm seeing almost back to back USB (7 or 8 a second) 'interrupt'
packets from an ax88179 Ge card.
It may be that other systems behave similarly.
I'm sure this hadn't used to happen!

I don't know what the interrupt status means, the value (as LE u32)
is 0x900a1 0xe1cd6d79
The only bit the driver looks at is the 0x10000 bit in the first word.
This is the 'link up/down' flag.
The two halves of the second word are probably different fields, the
high bits appear after about a second.

Now I'd guess that the driver ought to be doing something about some
of these values. While in this mode transmits are delayed for anything
upto 100ms, at least for some time they do get sent.

However the processing of the 'link up/down' flag is clearly wrong.
The code currently does:

348         event = urb->transfer_buffer;
349         le32_to_cpus((void *)&event->intdata1);
350 
351         link = (((__force u32)event->intdata1) & AX_INT_PPLS_LINK) >> 16;
352 
353         if (netif_carrier_ok(dev->net) != link) {
354                 usbnet_link_change(dev, link, 1);
355                 netdev_info(dev->net, "ax88179 - Link status is: %d\n", link);
356         }

Which ends up doing repeated calls to usbnet_link_change() and confusing
that code a lot.

I presume there is some delay before the return value from netif_carrier_ok()
matches the set state.

I think the code should be remembering the link state locally.
It might also need to clear some other interrupt flags, only ASIX know
what they mean.

	David

--
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