Messages in this thread | | | From | "Reshetova, Elena" <> | Subject | RE: [PATCH 1/3] perf: convert perf_event_context.refcount to refcount_t | Date | Fri, 1 Feb 2019 15:44:38 +0000 |
| |
> 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.
Anyhow, I can change this to refcount_inc_checked(), if this is what everyone thinks is the best.
Best Regards, Elena.
| |