Re: decnet versions

[Steve Whitehouse <steve@gw.chygwyn.com>]

> 
> 
>   I have not looked through the sources yet, but is this allocation for a
> communication buffer?  Are the messages somewhat fixed length?  If so, how
> feasible is a pool of buffers.  The pool is allocated early on and they are
> reused.  This way even in low memory situations there should not be a failure. 
> I say should, but even a pooling scheme can have troubles.
> 
Firstly I should point out that the patch in question is the original patch
written by Eduardo[1] from which the current code in 2.3.xx is descended.
The new code in 2.3.xx and my older 2.2.xx patches both have this problem
fixed anyway, which is one reason why I'm not too concerned about it. (Well
that assumes that I've put my finger on the problem which Zane's last
message suggests that perhaps I haven't).

The particular function dn_send_disc() can be called from both user level
and interrupt contexts. In interrupt context, you must not try and sleep
at any time, hence the use of GFP_ATOMIC in the allocation. Since you can't
sleep, you can't swap either so you _must_ take account of the possability
that the alloc_skb() call will return NULL. In fact you should do that anyway
even for user level code, usually returning ENOMEM or ENOBUFS or some such
error code. In the case of dn_send_disc() the correct action is to change
the socket state, and let a timer retransmit the skb at a later date.

In 2.3.xx (I forget about 2.2.xx) the skb structure consists of a
header, plus a data portion. The header portion is allocated from the
slab allocator, the data portion from kmalloc() which is a wrapper for
allocations from the power of two sized slab caches. Theres a paper about
how this works, and the reference is given in the top of linux/mm/slab.c.

I hope this is of some help,

Steve.

[1] And modified and currently maintained by Patrick Caulfield.
-----------------------------------------------------------------------------
To unsubscribe from this list, send a mail to majordomo@dreamtime.org
containing the line "unsubscribe linux-decnet"
-----------------------------------------------------------------------------