Re: ctl_enqueuedata ENOBUFS error
Re: ctl_enqueuedata ENOBUFS error
- Subject: Re: ctl_enqueuedata ENOBUFS error
- From: "Justin C. Walker" <email@hidden>
- Date: Tue, 12 Jul 2005 11:57:47 -0700
This is short, due to lack of time:
On Jul 12, 2005, at 11:35 , Allan Hoeltje wrote:
Look for other possibilities as well: are you always freeing the
mbufs you are using?
I am not sure I know what you mean here.
I mean: ENOBUFS usually means no space of some kind - either no
buffers or no space to put buffers in, depending. Since this is not
a common problem for existing code, it seems likely that it is due to
something you are doing, presumably incorrectly.
In my ipf_input_func (and
duplicated in my ipf_output_func) I make a copy of the complete
mbuf_t *
data via mbuf_copydata into my own _MALLOC space. I then
ctl_enqueuedata my
copy and then _FREE the copy. I do not see any other mbuf_ or ctl_
methods
that might come into play here.
The kern_ctl_reg structure used to register a kernel control has a
ctl_sendsize field that says 0 means the default size but does not
say what
that default is nor does it say what the size is: bytes,
kBytes, ...? I
want to enqueue a full IP packet so I need the ctl_sendsize to be
at least
2048 bytes.
You should be aware that the mbuf accounting rules take into account
all the space in an mbuf, whether you use it or not (e.g., if you
allocate an mbuf with cluster, put 1 byte in the cluster, and enqueue
it, you are docked for the size of the mbuf (256 bytes) + size of
cluster (2048 bytes). You may already know this but it's worth
emphasizing.
Are you sure that the queue is getting filled up?
The description of ctl_enqueuedata in sys/kern_control.h says a
return code
of ENOBUFS means the "queue is full or there are no free mbufs".
Since
there isn't an mbuf associated with the ctl_enqueuedata method I
can only
assume that some queue somewhere is full.
[snip]
<whine>
There is not enough documentation in this area. The "Network Kernel
Extensions Programming Guide" and "Kernel Programming" docs warn
about how
careful one needs to be when programming in the kernel and then
gives you
just enough information to make you dangerous. Where does a mere
mortal
learn about writing proper KEXTs?
</whine>
This is a no-whining zone. When the going gets tough, the tough get
the kernel source and look at it to figure out what *might* be going
wrong. A quick (and incomplete) check of the source tells me that
the routine in question will return ENOBUFS if the receive sockbuf of
the socket associated with the kctlref does not have sufficient free
space; or when it can't allocate an mbuf (which it will use to store
the data you pass it).
This is pretty straight-forward, and will help you understand the
environment you are developing code for. There are no courses on
kernel internals, generally, and precious little documentation. You
need to dig into the source.
Thanks for the netstat tip - I will do some more debugging and see
if I
can't narrow this thing down some more.
Hope this helps.
Regards,
Justin
--
Justin C. Walker, Curmudgeon-At-Large
Institute for General Semantics
--------
It's not whether you win or lose...
It's whether *I* win or lose.
--------
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden