netdev - Re: [PATCH] af_packet: Don't use skb after dev_queue

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]

Message-ID: <20100118204658.GC3157@del.dom.local>
Date:	Mon, 18 Jan 2010 21:46:58 +0100
From:	Jarek Poplawski <jarkao2@...il.com>
To:	Michael Breuer <mbreuer@...jas.com>
Cc:	Stephen Hemminger <shemminger@...ux-foundation.org>,
	David Miller <davem@...emloft.net>, akpm@...ux-foundation.org,
	flyboy@...il.com, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org
Subject: Re: [PATCH] af_packet: Don't use skb after dev_queue_xmit()

On Mon, Jan 18, 2010 at 11:29:31AM -0500, Michael Breuer wrote:
> Ok - up on the two patches, no DMAR. Some early observations:
> 
> 1. There's an early on MMAP oops (see below). This happens once, at
> the completion of the transition to runlevel 5 (I've seen it
> entering runlevel 3 as well). This does not recur when runlevels are
> subsequently changed. I do not see this when running with DMAR
> enabled.

OK, you mentioned this oops (actually a warning only) happened during
previous tests too.

> 
> 2. The dropped tx packet (DHCP) is a bit harder to recreate, but it
> still happens.

Btw, I guess you improved the test because you didn't mention it here,
even after my explicit question?:
http://permalink.gmane.org/gmane.linux.network/149171

> Interestingly, I initially saw no dropped packets
> with ping - but after I went the DCHP route and eventually
> reconnected, I could then cause dropped tx packets with ping. To
> clarify:
> 
> a) start throughput
> b) ping device - no packet loss - this was true for the entire test run.
> c) start throughput again
> d) ping - no loss.
> e) drop wifi on the device & restart - first attempt worked. Repeat
> attempt yielded the dropped DHCPOFFER packets. After about 6 tries,
> the device reconnected to wifi.
> f) ping again (after the reconnection) - packet loss rate about 80%.
> g) simultaneously ping the wifi router - no loss.
> h) After a while, packets are no longer dropped during ping. If I
> manage to cause the dhcp drop again, and then ping after the device
> finally reconnects, packet loss is significant for a while (maybe 30
> sec to a minute). Then things return to normal. Note that the packet
> loss continues even if the reported throughput drops to nil.
> i) I can't cause the initial packet loss at RX rates below about
> 30,000KBPS (as reported by nethogs).  At rates over 40 I can
> reproduce this on this set of patches & config about 60% of the
> time.

I forgot to mention, but did you try to check if these lost ping
packets are "being dropped somewhere after wireshark sees them and
before hitting the wire" like DHCPOFFER? Aren't there any sky2
warnings/resets while this happens?

Jarek P.
--
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