[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <18964.38744.198924.182451@cargo.ozlabs.ibm.com>
Date: Thu, 21 May 2009 09:50:48 +1000
From: Paul Mackerras <paulus@...ba.org>
To: Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc: Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
Corey Ashford <cjashfor@...ux.vnet.ibm.com>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [RFC PATCH] perf_counter: dynamically allocate tasks'
perf_counter_context struct
Peter Zijlstra writes:
> This seems to be the only site where we use ->perf_counter_mutex,
> couldn't we simply write this as:
>
> if (cmpxchg(&task->perf_counter_ctx, NULL, ctx) != NULL)
> kfree(ctx);
>
> and get rid of the mutex?
Yes, that should work, with an smp_wmb() before the cmpxchg.
> If, in find_get_context() we exclude PF_EXITING tasks under ctx->mutex,
> and ensure we take ctx->mutex in perf_counter_exit_task() we should be
> good.
It's the fact that we also call perf_counter_exit_task when doing an
exec of a setuid program that concerns me. In that case the task
isn't exiting and its pid is still accessible, so it is quite possible
that some other task could be attaching counters to us. Certainly
root could; I don't know whether we change uid before doing the
dumpable check or not, so it's possible a non-privileged process would
be refused.
Paul.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists