Thread (30 messages) flat view 30 messages, 3 authors, 2021-01-18

Re: [PATCH v6 net-next 14/15] net: bonding: ensure .ndo_get_stats64 can sleep

From: Vladimir Oltean <olteanv@gmail.com>
Date: 2021-01-12 14:37:56

On Mon, Jan 11, 2021 at 03:38:49PM -0800, Saeed Mahameed wrote:
GFP_ATOMIC is a little bit aggressive especially when user daemons are
periodically reading stats. This can be avoided.

You can pre-allocate with GFP_KERNEL an array with an "approximate"
size.
then fill the array up with whatever slaves the the bond has at that
moment, num_of_slaves  can be less, equal or more than the array you
just allocated but we shouldn't care ..

something like:
rcu_read_lock()
nslaves = bond_get_num_slaves();
rcu_read_unlock()
sarray = kcalloc(nslaves, sizeof(struct bonding_slave_dev),
GFP_KERNEL);
rcu_read_lock();
bond_fill_slaves_array(bond, sarray); // also do: dev_hold()
rcu_read_unlock();


bond_get_slaves_array_stats(sarray);

bond_put_slaves_array(sarray);
I don't know what to say about acquiring RCU read lock twice and
traversing the list of interfaces three or four times.
On the other hand, what's the worst that can happen if the GFP_ATOMIC
memory allocation fails. It's not like there is any data loss.
User space will retry when there is less memory pressure.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help