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:	Thu, 07 Jan 2010 02:55:20 -0500
From:	Michael Breuer <mbreuer@...jas.com>
To:	Jarek Poplawski <jarkao2@...il.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 1/7/2010 2:47 AM, Jarek Poplawski wrote:
> On Thu, Jan 07, 2010 at 02:20:22AM -0500, Michael Breuer wrote:
>    
>> ...
>> Reapplied a couple of earlier patches - still can't do jumbo frames, but
>> the rx errors are gone and speed has improved. Too early to assure that
>> it's stable.
>>
>> Patches that seem to fix the rx drops (all from Stephen):
>> 1) Patch change to tx_init
>> 2) Patch to lock netif_device_detach
>> 3) Patch to sky2_tx_complete to add netif_device_present test
>> Also in the mix: Jarek's alternative 2
>>      
> BTW, the main difference between alt. 1 and 2 is error notification:
> alternative 2 doesn't hide some (most) of drops, so, dependending on
> app, there might be more and faster retransmits. (I don't know what
> apps used by you (other than dhcp) can depend so much on this.)
>
>    
Unless I misread the code, I think that in some cases e skb is actually 
freed if the cfq (among others perhaps) scheduler returns an error on 
enqueue (flow control perhaps).  Thus with alternative 1, it is possible 
that the skb is acted upon after being freed - this would be consistent 
with the DMAR errors I saw.

>> With this set and mtu=1500 all seems good - decent if not stellar
>> throughput; no logged errors; no reported packet loss. As before, will
>> leave running and see if anything falls apart.
>>      
> Good news!
>
> Jarek P.
> --
> 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/
>    

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