linux-kernel - Re: [RFC] perf: need to expose sched_clock to correlate user samples with kernel samples

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1360838032.4045.126.camel@hornet>
Date:	Thu, 14 Feb 2013 10:33:52 +0000
From:	Pawel Moll <pawel.moll@....com>
To:	Stephane Eranian <eranian@...gle.com>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	John Stultz <john.stultz@...aro.org>,
	Peter Zijlstra <peterz@...radead.org>,
	LKML <linux-kernel@...r.kernel.org>,
	"mingo@...e.hu" <mingo@...e.hu>, Paul Mackerras <paulus@...ba.org>,
	Anton Blanchard <anton@...ba.org>,
	Will Deacon <Will.Deacon@....com>,
	"ak@...ux.intel.com" <ak@...ux.intel.com>,
	Pekka Enberg <penberg@...il.com>,
	Robert Richter <robert.richter@....com>,
	tglx <tglx@...utronix.de>
Subject: Re: [RFC] perf: need to expose sched_clock to correlate user
 samples with kernel samples

On Wed, 2013-02-13 at 20:00 +0000, Stephane Eranian wrote:
> On Wed, Feb 6, 2013 at 7:17 PM, Pawel Moll <pawel.moll@....com> wrote:
> > On Wed, 2013-02-06 at 01:19 +0000, Steven Rostedt wrote:
> >> If people are worried about adding a bunch of new perf syscalls, maybe
> >> add a sys_perf_control() system call that works like an ioctl but
> >> without a file descriptor. Something for things that don't require an
> >> event attached to it, like to retrieve a time stamp counter that perf
> >> uses, but done in a way that it could be used for other things perf
> >> related that does not require an event.
> >
> >  /**
> > + * sys_perf_control - ioctl-like interface to control system-wide
> > + *                   perf behaviour
> > + *
> > + * @cmd:       one of the PERF_CONTROL_* commands
> > + * @arg:       command-specific argument
> > + */
> > +SYSCALL_DEFINE2(perf_control, unsigned int, cmd, unsigned long, arg)
> > +{
> > +       switch (cmd) {
> > +       case PERF_CONTROL_GET_TIME:
> > +       {
> > +               u64 time = perf_clock();
> > +               if (copy_to_user((void __user *)arg, &time, sizeof(time)))
> > +                       return -EFAULT;
> > +               return 0;
> > +       }
> > +
> > +       default:
> > +               return -ENOTTY;
> > +       }
> > +}
>
> So what would be the role of this new syscall besides GET_TIME?
> What other controls without a fd could be done? We are already passing
> a lot of control thru the perf_event_open() some in the attr struct others
> as arguments.

I think Steven was thinking about an "extensible" fd-less interface.
Whether we'll need any other fd-less control in the future, I don't
know...

> The only advantage of this "disguised" ioctl() is that it does not require
> a fd. But it is worth adding a syscall just to avoid creating a fd?

Frankly speaking, I have some doubts here, but I do sys_perf_open()
anyway, so it was mainly trying to address your situation.

One way or another I'd like to get the timestamp, so how about picking
one solution and trying to make it happen? Seems that my previous
"standard ioctl()" patch would be the best compromise?

Pawel


--
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/