Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Wed, 29 May 2019 19:46:54 +0200
From: Jann Horn <>
To: David Howells <>
Cc: Greg KH <>, Al Viro <>,, linux-fsdevel <>, 
	Linux API <>,,, 
	linux-security-module <>, 
	kernel list <>, Kees Cook <>, 
	Kernel Hardening <>
Subject: Re: [PATCH 1/7] General notification queue with user mmap()'able ring buffer

On Wed, May 29, 2019 at 6:07 PM David Howells <> wrote:
> Greg KH <> wrote:
> > everyone should use
> > it.  It saves us having to audit the same pattern over and over again.
> > And, even nicer, it uses a refcount now, and as you are trying to
> > reference count an object, it is exactly what this was written for.
> >
> > So yes, I do think it should be used here, unless it is deemed to not
> > fit the pattern/usage model.
> kref_put() enforces a very specific destructor signature.  I know of places
> where that doesn't work because the destructor takes more than one argument
> (granted that this is not the case here).  So why does kref_put() exist at
> all?  Why not kref_dec_and_test()?
> Why doesn't refcount_t get merged into kref, or vice versa?  Having both would
> seem redundant.
> Mind you, I've been gradually reverting atomic_t-to-refcount_t conversions
> because it seems I'm not allowed refcount_inc/dec_return() and I want to get
> at the point refcount for tracing purposes.

Yeeech, that's horrible, please don't do that.

Does this mean that refcount_read() isn't sufficient for what you want
to do with tracing (because for some reason you actually need to know
the values atomically at the time of increment/decrement)?

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.