Re: problem with rtnetlink 'reference' count

2017-10-24 Thread Florian Westphal
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(); > > >

Re: problem with rtnetlink 'reference' count

2017-10-24 Thread Peter Zijlstra
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

Re: problem with rtnetlink 'reference' count

2017-10-23 Thread Florian Westphal
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

Re: problem with rtnetlink 'reference' count

2017-10-23 Thread Peter Zijlstra
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

Re: problem with rtnetlink 'reference' count

2017-10-23 Thread Florian Westphal
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

Re: problem with rtnetlink 'reference' count

2017-10-23 Thread Peter Zijlstra
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

Re: problem with rtnetlink 'reference' count

2017-10-23 Thread Florian Westphal
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

problem with rtnetlink 'reference' count

2017-10-23 Thread Peter Zijlstra
Hi, I just ran across commit: 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 2) there is a distinct lack of memory barriers, so we can e