Re: [PATCH v4 2/9] perf/core: open access for CAP_SYS_PERFMON privileged process

2020-01-11 Thread Masami Hiramatsu
On Fri, 10 Jan 2020 21:35:12 -0300 arnaldo.m...@gmail.com wrote: > ,Jann Horn ,Thomas Gleixner > ,Tvrtko Ursulin ,Lionel > Landwerlin ,linux-kernel > ,"linux-security-mod...@vger.kernel.org" > ,"seli...@vger.kernel.org" > ,"intel-...@lists.freedesktop.org" > ,"b...@vger.kernel.org" > ,"linu

Re: [PATCH] lib: vdso: mark __cvdso_clock_getres() as static

2020-01-11 Thread Thomas Gleixner
Christophe Leroy writes: > When __cvdso_clock_getres() became __cvdso_clock_getres_common() > and a new __cvdso_clock_getres() was added, static qualifier was > forgotten. > > Fixes: 502a590a170b ("lib/vdso: Move fallback invocation to the callers") > Signed-off-by: Christophe Leroy I've already

[PATCH] lib: vdso: mark __cvdso_clock_getres() as static

2020-01-11 Thread Christophe Leroy
When __cvdso_clock_getres() became __cvdso_clock_getres_common() and a new __cvdso_clock_getres() was added, static qualifier was forgotten. Fixes: 502a590a170b ("lib/vdso: Move fallback invocation to the callers") Signed-off-by: Christophe Leroy --- lib/vdso/gettimeofday.c | 1 + 1 file changed

Re: [PATCH v15 00/24] selftests, powerpc, x86: Memory Protection Keys

2020-01-11 Thread Sandipan Das
Hi Dave, On 10/01/20 11:27 pm, Dave Hansen wrote: > > Could you dump these in a git tree, please? It will make it a wee bit > easier for me to ship the resulting tree around to a couple different > systems. > I have pushed a version of this series that uses u64 for all references to the pkey r

Re: linux-next: build warning after merge of the bpf-next tree

2020-01-11 Thread Alexandre Ghiti
On 1/10/20 7:20 PM, Palmer Dabbelt wrote: On Fri, 10 Jan 2020 14:28:17 PST (-0800), alexan...@ghiti.fr wrote: Hi guys, On 10/27/19 8:02 PM, Stephen Rothwell wrote: Hi all, On Fri, 18 Oct 2019 10:56:57 +1100 Stephen Rothwell wrote: Hi all, After merging the bpf-next tree, today's linux-n

Re: linux-next: build warning after merge of the bpf-next tree

2020-01-11 Thread Alexandre Ghiti
On 1/10/20 6:18 PM, Alexei Starovoitov wrote: On Fri, Jan 10, 2020 at 2:28 PM Alexandre Ghiti wrote: Hi guys, On 10/27/19 8:02 PM, Stephen Rothwell wrote: Hi all, On Fri, 18 Oct 2019 10:56:57 +1100 Stephen Rothwell wrote: Hi all, After merging the bpf-next tree, today's linux-next buil

Re: Surprising code generated for vdso_read_begin()

2020-01-11 Thread Segher Boessenkool
On Fri, Jan 10, 2020 at 07:45:44AM +0100, Christophe Leroy wrote: > Le 09/01/2020 à 21:07, Segher Boessenkool a écrit : > >It looks like the compiler did loop peeling. What GCC version is this? > >Please try current trunk (to become GCC 10), or at least GCC 9? > > It is with GCC 5.5 > > https://

Re: [RFC PATCH v2 07/10] lib: vdso: don't use READ_ONCE() in __c_kernel_time()

2020-01-11 Thread Thomas Gleixner
Christophe Leroy writes: > > With READ_ONCE() the 64 bits are being read: > > Without the READ_ONCE() only 32 bits are read. That's the most optimal. > > Without READ_ONCE() but with a barrier() after the read, we should get > the same result but GCC (GCC 8.1) does less good: > > Assuming both pa

Re: [RFC PATCH v2 05/10] lib: vdso: inline do_hres()

2020-01-11 Thread Christophe Leroy
On 01/10/2020 09:07 PM, Thomas Gleixner wrote: Arnd Bergmann writes: On Mon, Dec 23, 2019 at 3:31 PM Christophe Leroy wrote: do_hres() is called from several places, so GCC doesn't inline it at first. do_hres() takes a struct __kernel_timespec * parameter for passing the result. In the 3

Re: [RFC PATCH v2 07/10] lib: vdso: don't use READ_ONCE() in __c_kernel_time()

2020-01-11 Thread Christophe Leroy
On 01/10/2020 09:12 PM, Thomas Gleixner wrote: Christophe Leroy writes: diff --git a/lib/vdso/gettimeofday.c b/lib/vdso/gettimeofday.c index 17b4cff6e5f0..5a17a9d2e6cd 100644 --- a/lib/vdso/gettimeofday.c +++ b/lib/vdso/gettimeofday.c @@ -144,7 +144,7 @@ __cvdso_gettimeofday(const struct vd