netdev - Re: sk_buff handling in packet handler

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

Message-ID: <4A133598.80405@accedian.com>
Date:	Tue, 19 May 2009 18:41:28 -0400
From:	Claude Robitaille <clauder@...edian.com>
To:	netdev@...r.kernel.org
Subject: Re: sk_buff handling in packet handler

Thanks Mark, very helpful

But I still  have some questions.

I see that you are using sbk_share_check, which will create a clone if 
the sk_buff is already used by someone else. In most cases the skb is 
not shared and the function simply return the same pointer without any 
modification to the original skb (in particular skb->users stays at 1). 
You  then manipulate the  sk_buff  (in particular  adding a MAC header, 
etc.) and eventually transmit the packet using dev_queue_xmit. The 
sk_buff will be ultimately kfree_skb by the NIC driver (or by you if an 
error occured somewhere before dev_queue_xmit).

My questions are:

- after you are done, net_rx_action may pass the sk_buff, modified by 
ectp_rcv, to other packet handler. How will other packet handlers know 
that, if they need to manipulate the sk_buff, they must create a clone? 
skb->users is still set to 1
- I presume that net_rx_action must also kfree the sk_buff, particularly 
if no packet handler decides to grab the packet. But it should not free 
it if it is still in the transmit queue, waiting for the HW to transmit 
it. But since nothing in the sk_buff tell net_rx_action that the packet 
is pending transmission how could this be the case? dev_queue_xmit does 
not appear to increase users (I used printk in another module to check 
this before and after calling dev_queue_xmit but it might be that my 
idle system is too fast for the printk to catch skb->users going to 2). 
In any case, I try to use sk_get (and 1 x kfree_skb) in my packet 
handler but I end up consuming all the memory in the system, presumably 
due to the fact that the sk_buff never get freed completely. What should 
be the correct way of handling this?

Claude

Mark Smith wrote:
> Hi Claude,
>
> You could have a look at my Ethernet Configuration Testing Protocol
> (ECTP) implementation. I followed what other protocols did regarding
> packet/skb handling, and also tried to make it very clear what was
> required, as I struggled a bit with similar issues that you are. The
> routine to start with is ectp_rcv().
>
> http://lwn.net/Articles/330797/
>
> Regards,
> Mark.
>
>   

-- 
Claude Robitaille
CTO
Accedian Networks
514-764-0119
clauder@...edian.com


View attachment "clauder.vcf" of type "text/x-vcard" (177 bytes)