Re: [B.A.T.M.A.N.] pull request: batman-adv 2012-04-18

[Marek Lindner <lindner_marek@yahoo.de>]

On Monday, April 23, 2012 14:43:24 Al Viro wrote:
> Other GFP_* allocations fail only when system is in a really lousy state -
> killing processes, etc.  GFP_ATOMIC can fail in much milder conditions;
> note that they can't e.g. swap a page out or write a dirty page out and
> free it, etc.  _Any_ allocation failures need to be dealt with, of course,
> but with GFP_ATOMIC ones failures are just a fact of life - it's not even
> an emergency situation.

Ok, that is what I thought.


> > Replacing kmalloc() with kzalloc() should do, right ?
> 
> *shrug*
> That would do it, all right, but since you memcpy() over all but the last
> element, I'd suggest cleaning that last element explicitly.  Hell knows -
> depends on how large your arrays are...

Don't think that is worth the hassle. The index of these arrays is the number 
of interfaces batman is running on. In 90% of all cases it will be a single 
interface. Have yet to encounter a system with more than 3 interfaces.


> > Thanks for catching this. I agree that this is not properly protected.
> > All functions accessing orig_node->bcast_own(_sum) use
> > orig_node->ogm_cnt_lock to lock each other out. Obviously we would need
> > a global lock for the interface renumbering which will be as ugly as the
> > current array resizing is. You don't happen to have a good example of a
> > resizable array at hand ?
> 
> Depends...  How large those arrays realistically get?  I would probably
> consider allocating these guys separately and hashing them by
> orig_node/hwif pair, but feasibility of that depends on how many of each
> do you expect to see and how often do their numbers change...

As I explained above: The index is not big and does not change often (when an 
interface is added or removed).
Can you explain the "hashing them by orig_node/hwif pair" part in greater 
detail ?

Thanks,
Marek