Messages in this thread Patch in this message | | | Date | Fri, 1 Feb 2019 16:23:53 +0000 | From | Mark Rutland <> | Subject | Re: [PATCH 1/3] perf: convert perf_event_context.refcount to refcount_t |
| |
On Fri, Feb 01, 2019 at 03:44:38PM +0000, Reshetova, Elena wrote: > > On Tue, Jan 29, 2019 at 01:55:32PM +0000, Reshetova, Elena wrote: > > > > On Mon, Jan 28, 2019 at 02:27:26PM +0200, Elena Reshetova wrote: > > > > > diff --git a/kernel/events/core.c b/kernel/events/core.c > > > > > index 3cd13a3..a1e87d2 100644 > > > > > --- a/kernel/events/core.c > > > > > +++ b/kernel/events/core.c > > > > > @@ -1171,7 +1171,7 @@ static void perf_event_ctx_deactivate(struct > > > > perf_event_context *ctx) > > > > > > > > > > static void get_ctx(struct perf_event_context *ctx) > > > > > { > > > > > - WARN_ON(!atomic_inc_not_zero(&ctx->refcount)); > > > > > + WARN_ON(!refcount_inc_not_zero(&ctx->refcount)); > > > > > > > > This could be refcount_inc(), remember how that already produces a WARN > > > > when we try and increment 0. > > > > > > But is this true for the x86 arch-specific implementation also? > > > > If you use recount_inc_checked(), it will always produce the WARN(), > > even when using the x86-specific refcount implementation. > > > > (this was one place I had intended to use the *_checked() forms of the > > refcount ops). > > Yes, with refcount_inc_checked() it would work, but I don't like it > that much when we have functions that behave regardless of refcount > config. It does help for code minimization & clarity like here, but I think > it complicates things even more: two different configs, then functions that > do not obey configs, etc.
Sure. The main idea of having the _checked() forms was to not lose warnings in a conversion to refcount_t, but I appreciate that people might not like the existing warnings at all.
> Anyhow, I can change this to refcount_inc_checked(), if this is what everyone > thinks is the best.
I'll defer to Peter.
Peter, would you prefer refcount_inc() or refcount_inc_checked() here?
Thanks, Mark.
| |