Thread (28 messages) flat view 28 messages, 5 authors, 2021-01-08

Re: [PATCH v3 net-next 10/12] net: bonding: ensure .ndo_get_stats64 can sleep

From: Saeed Mahameed <saeed@kernel.org>
Date: 2021-01-08 04:00:36

On Thu, 2021-01-07 at 13:58 +0100, Eric Dumazet wrote:
On Thu, Jan 7, 2021 at 12:33 PM Vladimir Oltean [off-list ref]
wrote:
quoted
On Thu, Jan 07, 2021 at 12:18:28PM +0100, Eric Dumazet wrote:
quoted
What a mess really.
Thanks, that's at least _some_ feedback :)
Yeah, I was on PTO for the last two weeks.
quoted
quoted
You chose to keep the assumption that ndo_get_stats() would not
fail,
since we were providing the needed storage from callers.

If ndo_get_stats() are now allowed to sleep, and presumably
allocate
memory, we need to make sure
we report potential errors back to the user.

I think your patch series is mostly good, but I would prefer not
hiding errors and always report them to user space.
And no, netdev_err() is not appropriate, we do not want tools to
look
at syslog to guess something went wrong.
Well, there are only 22 dev_get_stats callers in the kernel, so I
assume
that after the conversion to return void, I can do another
conversion to
return int, and then I can convert the ndo_get_stats64 method to
return
int too. I will keep the plain ndo_get_stats still void (no reason
not
to).
quoted
Last point about drivers having to go to slow path, talking to
firmware : Make sure that malicious/innocent users
reading /proc/net/dev from many threads in parallel wont brick
these devices.

Maybe they implicitly _relied_ on the fact that firmware was
gently
read every second and results were cached from a work queue or
something.
How? I don't understand how I can make sure of that.
Your patches do not attempt to change these drivers, but I guess your
cover letter might send to driver maintainers incentive to get rid of
their
logic, that is all.

We might simply warn maintainers and ask them to test their future
changes
with tests using 1000 concurrent theads reading /proc/net/dev
quoted
There is an effort initiated by Jakub to standardize the ethtool
statistics. My objection was that you can't expect that to happen
unless
dev_get_stats is sleepable just like ethtool -S is. So I think the
same
reasoning should apply to ethtool -S too, really.
I think we all agree on the principles, once we make sure to not
add more pressure on RTNL. It seems you addressed our feedback, all
is fine.
Eric, about two years ago you were totally against sleeping in
ndo_get_stats, what happened ? :) 
https://lore.kernel.org/netdev/4cc44e85-cb5e-502c-30f3-c6ea564fe9ac@gmail.com/ (local)

My approach to solve this was much simpler and didn't require  a new
mutex nor RTNL lock, all i did is to reduce the rcu critical section to
not include the call to the driver by simply holding the netdev via
dev_hold()


Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help