Hi,
> Haven't found any, but
>
> * you do an awful lot of GFP_ATOMIC allocations and those can and
> do fail from time to time. What's worse, you ignore some of those
> failures - e.g. failing allocation in orig_hash_{add,del}_if() will be
> ignored by the caller. I haven't looked into that code enough to tell
> if it could be exploited, but I really don't like the look of it...
other GFP_* allocations can't fail ?
This whole resizing isn't escpecially beautiful and asks for some love.
> * orig_node_add_if() leaves junk in added array elements. You do
> kmalloc() followed by memcpy(), but leave the last element uninitialized.
> May be safe if you assign it soon enough, but I'd suggest checking that.
Replacing kmalloc() with kzalloc() should do, right ?
> * orig_node_del_if() looks odd - it removes element #hard_iface->if_num
> and shifts all subsequent ones down; then it renumbers interfaces to
> match that. So far, so good, and there's even a plausible comment about
> locking:
> /* renumber remaining batman interfaces _inside_ of orig_hash_lock */
> except that no such lock exists since commit d007260. What protects us
> from the obvious race in there?
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 ?
Cheers,
Marek
