Re: [PATCH next-next 0/4] rtnetlink: rework handler (un)registering

2017-12-04 Thread David Miller
From: Florian Westphal Date: Mon, 4 Dec 2017 17:53:04 +0100 > The only difference is that theoretically some addrlabel rtnetlink > ops are not available if registration fails, but thats not really worse > than before as this used to panic() instead :-) > > I can send a followup

Re: [PATCH next-next 0/4] rtnetlink: rework handler (un)registering

2017-12-04 Thread Florian Westphal
David Miller wrote: > From: Florian Westphal > Date: Sat, 2 Dec 2017 21:44:04 +0100 > > > Peter Zijlstra reported (referring to commit 019a316992ee0d983, > > "rtnetlink: add reference counting to prevent module unload while dump is > > in progress"): > >

Re: [PATCH next-next 0/4] rtnetlink: rework handler (un)registering

2017-12-04 Thread David Miller
From: Florian Westphal Date: Sat, 2 Dec 2017 21:44:04 +0100 > Peter Zijlstra reported (referring to commit 019a316992ee0d983, > "rtnetlink: add reference counting to prevent module unload while dump is in > progress"): > > 1) it not in fact a refcount, so using refcount_t is

[PATCH next-next 0/4] rtnetlink: rework handler (un)registering

2017-12-02 Thread Florian Westphal
Peter Zijlstra reported (referring to commit 019a316992ee0d983, "rtnetlink: add reference counting to prevent module unload while dump is in progress"): 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 easily observe the