Peter Zijlstra wrote:
> On Mon, Oct 23, 2017 at 09:37:03PM +0200, Florian Westphal wrote:
>
> > > OK, so then why not do something like so?
> > > @@ -260,10 +259,18 @@ void rtnl_unregister_all(int protocol)
> > > RCU_INIT_POINTER(rtnl_msg_handlers[protocol], NULL);
> > > rtnl_unlock();
> > >
On Mon, Oct 23, 2017 at 09:37:03PM +0200, Florian Westphal wrote:
> > OK, so then why not do something like so?
> > @@ -260,10 +259,18 @@ void rtnl_unregister_all(int protocol)
> > RCU_INIT_POINTER(rtnl_msg_handlers[protocol], NULL);
> > rtnl_unlock();
> >
> > + /*
> > +* XXX expla
Peter Zijlstra wrote:
> On Mon, Oct 23, 2017 at 06:37:44PM +0200, Florian Westphal wrote:
>
> > Is refcount_t only supposed to be used with dec_and_test patterns?
>
> Yes, for reference counting objects.
Hmm, I still feel its appropriate, but anyway:
> > > This rtnetlink_rcv_msg() is called fr
On Mon, Oct 23, 2017 at 06:37:44PM +0200, Florian Westphal wrote:
> Is refcount_t only supposed to be used with dec_and_test patterns?
Yes, for reference counting objects.
> > This rtnetlink_rcv_msg() is called from softirq-context, right? Also,
> > all that stuff happens with rcu_read_lock() he
Peter Zijlstra wrote:
> On Mon, Oct 23, 2017 at 05:32:00PM +0200, Florian Westphal wrote:
>
> > > 1) it not in fact a refcount, so using refcount_t is silly
> >
> > Your suggestion is...?
>
> Normal atomic_t
Why? refcount_t gives debug options to catch leaks/underflows,
atomic_t does not.
I
On Mon, Oct 23, 2017 at 05:32:00PM +0200, Florian Westphal wrote:
> > 1) it not in fact a refcount, so using refcount_t is silly
>
> Your suggestion is...?
Normal atomic_t
> > 2) there is a distinct lack of memory barriers, so we can easily
> > observe the decrement while the msg_handler
Peter Zijlstra wrote:
> 019a316992ee ("rtnetlink: add reference counting to prevent module unload
> while dump is in progress")
>
> And that commit is _completely_ broken.
>
> 1) it not in fact a refcount, so using refcount_t is silly
Your suggestion is...?
> 2) there is a distinct lack o
