netdev - Re: inconsistent lock state with usbnet/asix usb ethernet and xhci

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

Date:   Tue, 27 Feb 2018 11:37:50 +0100
From:   Oliver Neukum <oneukum@...e.com>
To:     Marek Szyprowski <m.szyprowski@...sung.com>,
        LKML <linux-kernel@...r.kernel.org>,
        'LinuxSamsung SOC' <linux-samsung-soc@...r.kernel.org>,
        Linux USB Mailing List <linux-usb@...r.kernel.org>,
        netdev@...r.kernel.org
Cc:     Dean Jenkins <Dean_Jenkins@...tor.com>
Subject: Re: inconsistent lock state with usbnet/asix usb ethernet and xhci

Am Dienstag, den 27.02.2018, 08:26 +0100 schrieb Marek Szyprowski:

Hi,

> I've noticed that USBnet/ASIX AX88772B USB driver produces deplock kernel
> warning ("inconsistent lock state") on Chromebook2 Peach-PIT board. No

Is that 32 bit?

> special activity is needed to reproduce this issue, it happens almost
> on every boot. ASIX USB ethernet is connected to XHCI USB host controller
> on that board. Is it a known issue? Frankly I have no idea where to look

No, it is not known.

> to fix it. The same adapter connected to EHCI ports on other boards based
> on the same SoC works fine without any warnings.

Odd.

> And the log with mentioned warning:
> 
> [   17.768040] ================================
> [   17.772239] WARNING: inconsistent lock state
> [   17.776511] 4.16.0-rc3-next-20180227-00007-g876c53a7493c #453 Not tainted
> [   17.783329] --------------------------------
> [   17.787580] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
> [   17.793607] swapper/0/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
> [   17.798751]  (&syncp->seq#5){?.-.}, at: [<9b22e5f0>] 
> asix_rx_fixup_internal+0x188/0x288

Looks like this triggers (in usbnet):

        u64_stats_update_begin(&stats64->syncp);
        stats64->rx_packets++;
        stats64->rx_bytes += skb->len;
        u64_stats_update_end(&stats64->syncp);

That I considered to be called under lock.
Could you comment this out for testing?

	Regards
		Oliver