[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090402184514.GC843@elte.hu>
Date: Thu, 2 Apr 2009 20:45:14 +0200
From: Ingo Molnar <mingo@...e.hu>
To: markus.t.metzger@...el.com
Cc: tglx@...utronix.de, hpa@...or.com, markus.t.metzger@...il.com,
roland@...hat.com, eranian@...glemail.com, oleg@...hat.com,
juan.villacis@...el.com, ak@...ux.jf.intel.com,
linux-kernel@...r.kernel.org
Subject: Re: [patch 01/18] x86, bts: fix race when bts tracer is removed
* markus.t.metzger@...el.com <markus.t.metzger@...el.com> wrote:
> +static inline void ds_take_timestamp(struct ds_context *context,
> + enum bts_qualifier qualifier,
> + struct task_struct *task)
> +{
> + struct bts_tracer *tracer = context->bts_master;
> + barrier();
why the barrier()?
> +
> + if (tracer && (tracer->flags & BTS_TIMESTAMPS)) {
> + struct bts_struct ts = {
> + .qualifier = qualifier,
> + .variant.timestamp.jiffies = jiffies_64,
> + .variant.timestamp.pid = task->pid
> + };
> + bts_write(tracer, &ts);
> + }
Why do we have .variant.timestamp.pid ? A PID is not a timestamp. It
might be .event.jiffies and .event.pid perhaps.
Also, the whole function could be cleaned up by:
1) returning early if !tracer || !(tracer->flags & BTS_TIMESTAMPS).
2) Doing a cleaner initialization - something like:
struct bts_struct ts = {
.qualifier = qualifier,
.variant.event.jiffies = jiffies_64,
.variant.event.pid = task->pid
};
Also, raw use of jiffies_64 is buggy and racy. Why does this use
jiffies to begin with - why not some finer grained time?
Ingo
--
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