Messages in this thread | | | Date | Sat, 11 Mar 2023 17:46:07 +0000 | From | Joel Fernandes <> | Subject | Re: [PATCH rcu 14/16] rxrpc: Use call_rcu_hurry() instead of call_rcu() |
| |
On Wed, Nov 30, 2022 at 11:05:22PM +0000, David Howells wrote: > Joel Fernandes <joel@joelfernandes.org> wrote: [...] > > After your patch, you are still doing a wake up in your call_rcu() callback: > > > > - ASSERTCMP(refcount_read(&conn->ref), ==, 0); > > + if (atomic_dec_and_test(&rxnet->nr_conns)) > > + wake_up_var(&rxnet->nr_conns); > > +} > > > > Are you saying the code can now tolerate delays? What if the RCU > > callback is invoked after arbitrarily long delays making the sleeping > > process to wait? > > True. But that now only holds up the destruction of a net namespace and the > removal of the rxrpc module.
I am guessing not destructing the net namespace soon enough is not an issue. I do remember (in a different patch) that not tearing down networking things have a weird side effect to tools that require state to disappear..
> > If you agree, you can convert the call_rcu() to call_rcu_hurry() in > > your patch itself. Would you be willing to do that? If not, that's > > totally OK and I can send a patch later once yours is in (after > > further testing). > > I can add it to part 4 (see my rxrpc-ringless-5 branch) if it is necessary.
I am guessing the conversion to call_rcu_hurry() is still not necessary here, if it is then consider the conversion.
But yeah feel free to ignore this, I am just pinging here so that it did not slip through the cracks.
thanks,
- Joel
| |