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: <CABPqkBR=R_xnM1j8J_+vXHniqfBzJQRr8oUZz05YVzhbSW777w@mail.gmail.com>
Date:	Wed, 13 Feb 2013 21:00:46 +0100
From:	Stephane Eranian <eranian@...gle.com>
To:	Pawel Moll <pawel.moll@....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, 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.
>
> Something along these lines? (completely untested and of course missing
> all the #defines __NR_perf_control xxx)
>
> 8<-----------------
> diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
> index 4f63c05..be7409b 100644
> --- a/include/uapi/linux/perf_event.h
> +++ b/include/uapi/linux/perf_event.h
> @@ -322,6 +322,11 @@ enum perf_event_ioc_flags {
>  };
>
>  /*
> + * Command codes for ioctl-like sys_perf_control interface:
> + */
> +#define PERF_CONTROL_GET_TIME          _IOR('$', 0, __u64)
> +
> +/*
>   * Structure of the page that can be mapped via mmap
>   */
>  struct perf_event_mmap_page {
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 301079d..750404d 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -6678,6 +6678,29 @@ err_fd:
>  }
>
>  /**
> + * 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;
> +       }
> +}
> +
> +/**
>   * perf_event_create_kernel_counter
>   *
>   * @attr: attributes of the counter to create
> 8<-----------------
>
> Cheers!

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.

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