On Sun, 13 May 2018, Alexei Starovoitov wrote:
> On Sat, May 12, 2018 at 10:30:02PM +0200, Thomas Gleixner wrote:
> > But yes, the situation is slightly different here because tools which
> > create trace event magic _HAVE_ to pull in kernel headers. At the same time
> > these tools depend on a
On Sun, 13 May 2018, Alexei Starovoitov wrote:
> On Sat, May 12, 2018 at 10:30:02PM +0200, Thomas Gleixner wrote:
> > But yes, the situation is slightly different here because tools which
> > create trace event magic _HAVE_ to pull in kernel headers. At the same time
> > these tools depend on a
On Sat, May 12, 2018 at 10:30:02PM +0200, Thomas Gleixner wrote:
> On Sat, 12 May 2018, Alexei Starovoitov wrote:
> > On Thu, May 10, 2018 at 10:58 AM, Alexei Starovoitov
> > wrote:
> > > I see no option, but to fix the kernel.
> > > Regardless whether it's called
On Sat, May 12, 2018 at 10:30:02PM +0200, Thomas Gleixner wrote:
> On Sat, 12 May 2018, Alexei Starovoitov wrote:
> > On Thu, May 10, 2018 at 10:58 AM, Alexei Starovoitov
> > wrote:
> > > I see no option, but to fix the kernel.
> > > Regardless whether it's called user space breakage or kernel
On Sat, 12 May 2018, Alexei Starovoitov wrote:
> On Thu, May 10, 2018 at 10:58 AM, Alexei Starovoitov
> wrote:
> > I see no option, but to fix the kernel.
> > Regardless whether it's called user space breakage or kernel breakage.
There is a big difference. If you
On Sat, 12 May 2018, Alexei Starovoitov wrote:
> On Thu, May 10, 2018 at 10:58 AM, Alexei Starovoitov
> wrote:
> > I see no option, but to fix the kernel.
> > Regardless whether it's called user space breakage or kernel breakage.
There is a big difference. If you are abusing a kernel internal
On Thu, May 10, 2018 at 10:58 AM, Alexei Starovoitov
wrote:
> I see no option, but to fix the kernel.
> Regardless whether it's called user space breakage or kernel breakage.
Peter,
could you please ack the patch or better yet take it into tip tree
and send to
On Thu, May 10, 2018 at 10:58 AM, Alexei Starovoitov
wrote:
> I see no option, but to fix the kernel.
> Regardless whether it's called user space breakage or kernel breakage.
Peter,
could you please ack the patch or better yet take it into tip tree
and send to Linus asap ?
rc5 is almost here
On Thu, May 10, 2018 at 10:58:35AM -0700, Alexei Starovoitov wrote:
> libbcc is a library. It's not only used by bcc scripts, but by production
> services that compile bpf programs with clang.
Let me get this straight: libbcc fails to compile because it
includes (through some long include chain)
On Thu, May 10, 2018 at 10:58:35AM -0700, Alexei Starovoitov wrote:
> libbcc is a library. It's not only used by bcc scripts, but by production
> services that compile bpf programs with clang.
Let me get this straight: libbcc fails to compile because it
includes (through some long include chain)
On Thu, May 10, 2018 at 06:20:28PM +0200, Borislav Petkov wrote:
> On Thu, May 10, 2018 at 08:52:42AM -0700, Alexei Starovoitov wrote:
> > That makes me wonder what happened with "we do not break user space" rule?
>
> As someone already pointed out on IRC, arch/x86/include/asm/cpufeature.h
> is
On Thu, May 10, 2018 at 06:20:28PM +0200, Borislav Petkov wrote:
> On Thu, May 10, 2018 at 08:52:42AM -0700, Alexei Starovoitov wrote:
> > That makes me wonder what happened with "we do not break user space" rule?
>
> As someone already pointed out on IRC, arch/x86/include/asm/cpufeature.h
> is
On Thu, May 10, 2018 at 9:28 AM Borislav Petkov wrote:
> As someone already pointed out on IRC, arch/x86/include/asm/cpufeature.h
> is solely a kernel header so nothing but kernel should include it. So
> forget the userspace breakage "argument".
For what is worth, I have the
On Thu, May 10, 2018 at 9:28 AM Borislav Petkov wrote:
> As someone already pointed out on IRC, arch/x86/include/asm/cpufeature.h
> is solely a kernel header so nothing but kernel should include it. So
> forget the userspace breakage "argument".
For what is worth, I have the same exact problem
On Thu, May 10, 2018 at 08:52:42AM -0700, Alexei Starovoitov wrote:
> That makes me wonder what happened with "we do not break user space" rule?
As someone already pointed out on IRC, arch/x86/include/asm/cpufeature.h
is solely a kernel header so nothing but kernel should include it. So
forget
On Thu, May 10, 2018 at 08:52:42AM -0700, Alexei Starovoitov wrote:
> That makes me wonder what happened with "we do not break user space" rule?
As someone already pointed out on IRC, arch/x86/include/asm/cpufeature.h
is solely a kernel header so nothing but kernel should include it. So
forget
On Thu, May 10, 2018 at 12:06:34PM +0200, Peter Zijlstra wrote:
> On Thu, May 03, 2018 at 08:31:19PM -0700, Yonghong Song wrote:
>
> > This approach is preferred since the already deployed bcc scripts, or
> > any other bpf applicaitons utilizing LLVM JIT compilation functionality,
> > will
On Thu, May 10, 2018 at 12:06:34PM +0200, Peter Zijlstra wrote:
> On Thu, May 03, 2018 at 08:31:19PM -0700, Yonghong Song wrote:
>
> > This approach is preferred since the already deployed bcc scripts, or
> > any other bpf applicaitons utilizing LLVM JIT compilation functionality,
> > will
On Thu, May 03, 2018 at 08:31:19PM -0700, Yonghong Song wrote:
> Commit d0266046ad54 ("x86: Remove FAST_FEATURE_TESTS")
> removed X86_FAST_FEATURE_TESTS and make macro static_cpu_has() always
> use __always_inline function _static_cpu_has() funciton.
> The static_cpu_has() uses gcc feature asm
On Thu, May 03, 2018 at 08:31:19PM -0700, Yonghong Song wrote:
> Commit d0266046ad54 ("x86: Remove FAST_FEATURE_TESTS")
> removed X86_FAST_FEATURE_TESTS and make macro static_cpu_has() always
> use __always_inline function _static_cpu_has() funciton.
> The static_cpu_has() uses gcc feature asm
On Thu, May 03, 2018 at 08:31:19PM -0700, Yonghong Song wrote:
> This approach is preferred since the already deployed bcc scripts, or
> any other bpf applicaitons utilizing LLVM JIT compilation functionality,
> will continue work with the new kernel without re-compilation and
> re-deployment.
On Thu, May 03, 2018 at 08:31:19PM -0700, Yonghong Song wrote:
> This approach is preferred since the already deployed bcc scripts, or
> any other bpf applicaitons utilizing LLVM JIT compilation functionality,
> will continue work with the new kernel without re-compilation and
> re-deployment.
Commit d0266046ad54 ("x86: Remove FAST_FEATURE_TESTS")
removed X86_FAST_FEATURE_TESTS and make macro static_cpu_has() always
use __always_inline function _static_cpu_has() funciton.
The static_cpu_has() uses gcc feature asm goto construct,
which is not supported by clang.
Issues
==
Commit d0266046ad54 ("x86: Remove FAST_FEATURE_TESTS")
removed X86_FAST_FEATURE_TESTS and make macro static_cpu_has() always
use __always_inline function _static_cpu_has() funciton.
The static_cpu_has() uses gcc feature asm goto construct,
which is not supported by clang.
Issues
==
24 matches
Mail list logo