On Tue, 29 Aug 2006 09:59:57 -0700
Stephane Eranian <[email protected]> wrote:
> > > +
> > > + PFM_DBG("going wait_inactive for [%d] state=%ld flags=0x%lx",
> > > + task->pid,
> > > + task->state,
> > > + local_flags);
> > > +
> > > + spin_unlock_irqrestore(&ctx->lock, local_flags);
> > > +
> > > + wait_task_inactive(task);
> > > +
> > > + spin_lock_irqsave(&ctx->lock, new_flags);
> >
> > This sort of thing..
>
> We need to wait until the task is effectively off the CPU, i.e., with its
> machine state (incl PMU) saved. When we come back we re-run the series of tests.
> This applies only to per-thread, therefore it is not affected by smp_processor_id().
>
Generally, if a reviewer asks a question and the developer answers that
question, this is a sign that a code comment is needed. Because others are
likely to ask themselves the same question ;)
>
> ..
>
> >
> > When copying a struct from kernel to userspace we must beware of
> > compiler-inserted padding. Because that can cause the kernel to leak
> > a few bytes of uninitialised kernel memory.
>
> We are copying out exactly the same amount of data that was passed in.
>
> Are you suggesting that copy_from/copy_to may copy more data?
No, that's OK. I was pointing out the problem in situations like this:
struct foo {
u32 a;
u64 b;
};
{
struct foo f;
f.a = 0;
f.b = 0;
copy_to_user(p, &f, sizeof(f));
}
which exposes kernel memory. As you appear to be confident that the
perfmon code can't do this, all is OK.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
