netdev - [bug] forcedeth: hung interface under load

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070403070514.GA22940@elte.hu>
Date:	Tue, 3 Apr 2007 09:05:14 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Ayaz Abdulla <AAbdulla@...dia.com>
Cc:	akpm@...ux-foundation.org, jeff@...zik.org, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, Adrian Bunk <bunk@...sta.de>
Subject: [bug] forcedeth: hung interface under load


* Ingo Molnar <mingo@...e.hu> wrote:

> 
> > I had responded eariler to the thread asking you to try out the patch
> > found in bug 8058:
> > http://bugzilla.kernel.org/show_bug.cgi?id=8058
> > 
> > I believe that is the caush of the NULL skb dereference issue.
> 
> there's a different type of regression now: under high load i dont get 
> a crash, i get a hung interface instead. No error packets or other 
> weird interface state - just a hung interface. [...]

the interface stats do not change from that point on:

eth1      Link encap:Ethernet  HWaddr 00:13:D4:DC:41:12
          inet addr:10.0.1.12  Bcast:10.0.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:14976 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3928743 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1028544 (1004.4 KiB)  TX bytes:4126766510 (3.8 GiB)
          Interrupt:16 Base address:0xa000

and the irq count does not change either:

 16:        816    3463148   IO-APIC-fasteoi   eth1

no matter what i do to the interface. So it's completely stuck. 
No kernel messages either - apparently nv_tx_timeout() never triggered.

note, the hang occurs faster if you set max_interrupt_work to a really 
low value (such as 0). [ The hang occurs _much_ faster if you apply the 
-rt patch and enable PREEMPT_RT - but the hang occurs on mainline too. ]

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