Re: skbuff

[Lisa & Eric Malkowski <malk@charter.net>]

>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.  One time I forgot to do an end_bh_atomic() for a corresponding
start_bh_atomic() (which locks out bottom halves when running from user
context) and my kernel would panic instantly (from a "human" perspective
:)...  Adding in the end_bh_atomic() solved this and a simple review of
the code made tracking this bug down easy.

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).

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).

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.

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.

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

p.s. -- copied this to the newbies list and any experts out there can
correct anything I've said if it's inaccurate...

mohan kumar wrote:

> hi,
> thanx for the pointers.
>
> 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.
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Auctions - buy the things you want at great prices
> http://auctions.yahoo.com/

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