Messages in this thread | | | Date | Tue, 15 Nov 2016 08:50:07 +0100 | From | Peter Zijlstra <> | Subject | Re: [RFC][PATCH 5/7] kref: Implement kref_put_lock() |
| |
On Mon, Nov 14, 2016 at 12:35:48PM -0800, Kees Cook wrote: > On Mon, Nov 14, 2016 at 9:39 AM, Peter Zijlstra <peterz@infradead.org> wrote: > > Because home-rolling your own is _awesome_, stop doing it. Provide > > kref_put_lock(), just like kref_put_mutex() but for a spinlock. > > > > Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> > > --- > > include/linux/kref.h | 21 +++++++++++++++------ > > net/sunrpc/svcauth.c | 15 ++++++++++----- > > 2 files changed, 25 insertions(+), 11 deletions(-) > > > > --- a/include/linux/kref.h > > +++ b/include/linux/kref.h > > @@ -86,12 +86,21 @@ static inline int kref_put_mutex(struct > > struct mutex *lock) > > { > > WARN_ON(release == NULL); > > This WARN_ON makes sense, yes, though it seems like it should be deal > with differently. If it's NULL, we'll just Oops when we call release() > later... Seems like this should saturate the kref or something else > similar.
So I simply took the pattern from the existing kref_put().
But I like it more in these kref_put_{lock,mutex}() variants, because someone will need to unlock. If we simply crash/bug without unlock we'll have broken state the rest of the kernel cannot fix up.
| |