Messages in this thread | | | From | Jann Horn <> | Date | Wed, 29 May 2019 19:46:54 +0200 | 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 <dhowells@redhat.com> wrote: > Greg KH <gregkh@linuxfoundation.org> 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)?
| |