linux-kernel - 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]

Date:	Mon, 18 Jan 2010 16:24:52 -0500
From:	Michael Breuer <mbreuer@...jas.com>
To:	Stephen Hemminger <shemminger@...ux-foundation.org>
Cc:	Jarek Poplawski <jarkao2@...il.com>,
	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 1/18/2010 4:00 PM, Stephen Hemminger wrote:
> On Mon, 18 Jan 2010 15:56:45 -0500
> Michael Breuer<mbreuer@...jas.com>  wrote:
>
>    
>>>> 2. The dropped tx packet (DHCP) is a bit harder to recreate, but it
>>>> still happens.
>>>>
>>>>          
> You might want to use tc filter rule to set priority of DHCP packets
> higher. This would cause them to be in a separate queue and eliminate
> the problem.
>
>    
Ok - for fun, tried that - no change. Not sure I see why this might be a 
factor. The packet loss happens when TX load is low and RX high.
Also,  packets only being dropped if traversing a router vs.to  the 
router itself.  Keep in mind that pings to the router did not lose 
packets, pings through the router lost packets. The router was not under 
load (traffic is being generated from a device connected via the 1Gb 
switch, not the wifi router), and tcpdump on the router input port shows 
the pings to the router, but not the ones through the router.

One added note, when I just tried this, the test data ended while the 
packet loss was occurring. The DHCPOFFER packet loss did not clear until 
about a minute after the throughput abated. I really think something is 
getting hosed, and I'd but some weird interaction with the arp logic 
high on the list of suspects. Not sure what else would be a factor when 
looking at the extra hop on the same subnet.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/