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