RE: skbuff

[Omer Musaev <omerm@mercury.co.il>]

> -----Original Message-----
> From: Lisa & Eric Malkowski [mailto:malk@charter.net]
> Sent: Saturday, May 05, 2001 6:25 PM
> To: mohan kumar
> Cc: kernelnewbies@nl.linux.org
> Subject: Re: skbuff
> 
> 
> >my code is no big deal(copied from phrack mag vol
> >8)...it just memcpy's from the skb->data to a buffer
> >in kernel space and then sends it to the userspace
> >when some one is asking for it from there(via
> >copy_to_user).
> >
> >but any way i will look into it and mail u the code
> >after i redo it again from my house.
> 
> Ok cool...
> 
> I haven't had to use copy_to_user for anything yet, but my driver does
> support ioctl() calls on my sockets to control adding and removing the
> tunnelling devices.  In there I copy_from_user the request and act on
> it.
> 
> The function from dev_add_pack is running in bottom half 
> context...  I'm
> not sure, but copying to the user may be a no-no since it can sleep (I
> think).  If a bottom half gets hung up too long, I think bad 
> things can
> happen. 

That's right - it is forbidden to call copy_to_user from interrupt context.
 
> Perhaps what you could do is to copy the skbs (with skb_copy) to get
> your own private copy in your dev_add_pack handler, and then use
> skb_queue_head() to put them on a list (global list pointer variable).
> and free the original skb and return from dev_add_pack 
> handler (modified basic phrack article stuff).

No need to copy the sk_buff and than to free it - net_bh does it for you. 
When you are in pack_handler you have a copy of sk_buff available for
reading, 
and you should do anything with it provided that you do not perform
operations that
may sleep, and you do not modify that buffer.

> Meanwhile, from some user context entry point (character device? or
> socket?), call skb_dequeue_tail() to grab the next available 
> skb.  When none are available, block.  skb_recv_datagram() does all of 
> this for you and makes the current process sleep when necessary etc.  You 
> won't have to worry about race conditions because the skb queueing /
dequeuing
> functions are cleaver to make packets instantly appear available or not
> to something in user context grabbing stuff off the list (I 
> think...  If not, start/end_bh_atomic pairs can lock out the bottom halves

> for you in
> the contention areas).

That approach may hurt you if you use more than one reading process. In such
a case 
you will have to make your own locking and use __skb* functions ( those
without locks ). 

> This solves your problem nicely...  The bottom half handler 
> never sleeps and just produces stuff into the queue (quicker than the
copy_to_user
> stuff), and the user context code consumes when there's stuff 
> available, and sleeps when there isn't any.  This is pretty much how
datagram
> sockets work.  With a little more work, you could probably implement
> your own raw socket that gets copies of the selected ethernet 
> type with the network headers above ethernet all there.  There are already
> existing mechanisms to do all of this, but doing it yourself helps to
> learn.

Do not forget to put some limit on incoming packets, so that a net won't eat

up all your memory. Also do not forget to dealocate skb you have.

> The more I think about it, you probably don't have to copy 
> packets with
> skb_copy since you're not modifying them.  So you could use skb_clone
> and get even better performance (no overhead of copying).  My driver
> needs to modify the packets, so it copies them instead of 
> cloning them.
> 
> A clone is where an skb "description" type structure points 
> to the same
> data area as another desccription type stucture.  A copied skb is two
> completely separate description sturctures with independent 
> data areas.

As I said erlier, what the handler gets is already a clone of original skb, 
so it is not required make a second clone just to free the first one.

> Hope this all helps...  I'm certainly not an expert, but I've been
> through quite a bit of this stuff...  My stuff seems to work 
> pretty well
> too (no evidence of races, leaks, or similar nasties yet anyway!)
> 
> See ya,
> 
> -Eric
> 
-
Kernelnewbies: Help each other learn about the Linux kernel.
Archive:       http://mail.nl.linux.org/
IRC Channel:   irc.openprojects.net / #kernelnewbies
Web Page:      http://www.kernelnewbies.org/