In my ARM randconfig tests, I'm getting a build error for
newly added code in bpf_perf_event_read and bpf_perf_event_output
whenever CONFIG_PERF_EVENTS is disabled:
kernel/trace/bpf_trace.c: In function 'bpf_perf_event_read':
kernel/trace/bpf_trace.c:203:11: error: 'struct perf_event' has no member named 'oncpu'
if (event->oncpu != smp_processor_id() ||
^
kernel/trace/bpf_trace.c:204:11: error: 'struct perf_event' has no member named 'pmu'
event->pmu->count)
This can happen when UPROBE_EVENT is enabled but KPROBE_EVENT
is disabled. I'm not sure if that is a configuration we care
about, otherwise we could prevent this case from occuring by
adding Kconfig dependencies.
Simply hiding the broken code inside #ifdef CONFIG_PERF_EVENTS
as this patch does seems to reliably fix the error as well,
I have built thousands of randconfig kernels since I started
seeing this and added the workaround.
Signed-off-by: Arnd Bergmann <[email protected]>
Fixes: 62544ce8e01c ("bpf: fix bpf_perf_event_read() helper")
Fixes: a43eec304259 ("bpf: introduce bpf_perf_event_output() helper")
---
I suspect my patch is not the right answer, but could someone please
fix this?
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index 4228fd3682c3..82e0bc9d002a 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -186,6 +186,7 @@ const struct bpf_func_proto *bpf_get_trace_printk_proto(void)
return &bpf_trace_printk_proto;
}
+#if IS_ENABLED(CONFIG_PERF_EVENTS)
static u64 bpf_perf_event_read(u64 r1, u64 index, u64 r3, u64 r4, u64 r5)
{
struct bpf_map *map = (struct bpf_map *) (unsigned long) r1;
@@ -263,6 +264,7 @@ static const struct bpf_func_proto bpf_perf_event_output_proto = {
.arg4_type = ARG_PTR_TO_STACK,
.arg5_type = ARG_CONST_STACK_SIZE,
};
+#endif
static const struct bpf_func_proto *kprobe_prog_func_proto(enum bpf_func_id func_id)
{
@@ -289,10 +291,12 @@ static const struct bpf_func_proto *kprobe_prog_func_proto(enum bpf_func_id func
return bpf_get_trace_printk_proto();
case BPF_FUNC_get_smp_processor_id:
return &bpf_get_smp_processor_id_proto;
+#if IS_ENABLED(CONFIG_PERF_EVENTS)
case BPF_FUNC_perf_event_read:
return &bpf_perf_event_read_proto;
case BPF_FUNC_perf_event_output:
return &bpf_perf_event_output_proto;
+#endif
default:
return NULL;
}
On 11/10/2015 01:55 PM, Arnd Bergmann wrote:
> In my ARM randconfig tests, I'm getting a build error for
> newly added code in bpf_perf_event_read and bpf_perf_event_output
> whenever CONFIG_PERF_EVENTS is disabled:
>
> kernel/trace/bpf_trace.c: In function 'bpf_perf_event_read':
> kernel/trace/bpf_trace.c:203:11: error: 'struct perf_event' has no member named 'oncpu'
> if (event->oncpu != smp_processor_id() ||
> ^
> kernel/trace/bpf_trace.c:204:11: error: 'struct perf_event' has no member named 'pmu'
> event->pmu->count)
>
> This can happen when UPROBE_EVENT is enabled but KPROBE_EVENT
> is disabled. I'm not sure if that is a configuration we care
> about, otherwise we could prevent this case from occuring by
> adding Kconfig dependencies.
I think that seems better than spreading #if IS_ENABLEDs into the code.
Probably enough to add a 'depends on PERF_EVENTS' to config BPF_EVENTS,
so it's also explicitly documented.
> Simply hiding the broken code inside #ifdef CONFIG_PERF_EVENTS
> as this patch does seems to reliably fix the error as well,
> I have built thousands of randconfig kernels since I started
> seeing this and added the workaround.
>
> Signed-off-by: Arnd Bergmann <[email protected]>
> Fixes: 62544ce8e01c ("bpf: fix bpf_perf_event_read() helper")
> Fixes: a43eec304259 ("bpf: introduce bpf_perf_event_output() helper")
Thanks,
Daniel
On Tue, 10 Nov 2015 14:31:38 +0100
Daniel Borkmann <[email protected]> wrote:
> On 11/10/2015 01:55 PM, Arnd Bergmann wrote:
> > In my ARM randconfig tests, I'm getting a build error for
> > newly added code in bpf_perf_event_read and bpf_perf_event_output
> > whenever CONFIG_PERF_EVENTS is disabled:
> >
> > kernel/trace/bpf_trace.c: In function 'bpf_perf_event_read':
> > kernel/trace/bpf_trace.c:203:11: error: 'struct perf_event' has no member named 'oncpu'
> > if (event->oncpu != smp_processor_id() ||
> > ^
> > kernel/trace/bpf_trace.c:204:11: error: 'struct perf_event' has no member named 'pmu'
> > event->pmu->count)
> >
> > This can happen when UPROBE_EVENT is enabled but KPROBE_EVENT
> > is disabled. I'm not sure if that is a configuration we care
> > about, otherwise we could prevent this case from occuring by
> > adding Kconfig dependencies.
>
> I think that seems better than spreading #if IS_ENABLEDs into the code.
> Probably enough to add a 'depends on PERF_EVENTS' to config BPF_EVENTS,
> so it's also explicitly documented.
>
So just do the following then?
-- Steve
diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index 8d6363f42169..f5aecff2d243 100644
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -434,7 +434,7 @@ config UPROBE_EVENT
config BPF_EVENTS
depends on BPF_SYSCALL
- depends on KPROBE_EVENT || UPROBE_EVENT
+ depends on KPROBE_EVENT && UPROBE_EVENT
bool
default y
help
On Tue, Nov 10, 2015 at 09:25:01AM -0500, Steven Rostedt wrote:
> On Tue, 10 Nov 2015 14:31:38 +0100
> Daniel Borkmann <[email protected]> wrote:
>
> > On 11/10/2015 01:55 PM, Arnd Bergmann wrote:
> > > In my ARM randconfig tests, I'm getting a build error for
> > > newly added code in bpf_perf_event_read and bpf_perf_event_output
> > > whenever CONFIG_PERF_EVENTS is disabled:
> > >
> > > kernel/trace/bpf_trace.c: In function 'bpf_perf_event_read':
> > > kernel/trace/bpf_trace.c:203:11: error: 'struct perf_event' has no member named 'oncpu'
> > > if (event->oncpu != smp_processor_id() ||
> > > ^
> > > kernel/trace/bpf_trace.c:204:11: error: 'struct perf_event' has no member named 'pmu'
> > > event->pmu->count)
> > >
> > > This can happen when UPROBE_EVENT is enabled but KPROBE_EVENT
> > > is disabled. I'm not sure if that is a configuration we care
> > > about, otherwise we could prevent this case from occuring by
> > > adding Kconfig dependencies.
> >
> > I think that seems better than spreading #if IS_ENABLEDs into the code.
> > Probably enough to add a 'depends on PERF_EVENTS' to config BPF_EVENTS,
> > so it's also explicitly documented.
> >
>
> So just do the following then?
>
> -- Steve
>
> diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
> index 8d6363f42169..f5aecff2d243 100644
> --- a/kernel/trace/Kconfig
> +++ b/kernel/trace/Kconfig
> @@ -434,7 +434,7 @@ config UPROBE_EVENT
>
> config BPF_EVENTS
> depends on BPF_SYSCALL
> - depends on KPROBE_EVENT || UPROBE_EVENT
> + depends on KPROBE_EVENT && UPROBE_EVENT
yeah that's definitely cleaner and avoids ifdef creep in the future.
On 11/10/2015 06:14 PM, Alexei Starovoitov wrote:
> On Tue, Nov 10, 2015 at 09:25:01AM -0500, Steven Rostedt wrote:
>> On Tue, 10 Nov 2015 14:31:38 +0100
>> Daniel Borkmann <[email protected]> wrote:
>>
>>> On 11/10/2015 01:55 PM, Arnd Bergmann wrote:
>>>> In my ARM randconfig tests, I'm getting a build error for
>>>> newly added code in bpf_perf_event_read and bpf_perf_event_output
>>>> whenever CONFIG_PERF_EVENTS is disabled:
>>>>
>>>> kernel/trace/bpf_trace.c: In function 'bpf_perf_event_read':
>>>> kernel/trace/bpf_trace.c:203:11: error: 'struct perf_event' has no member named 'oncpu'
>>>> if (event->oncpu != smp_processor_id() ||
>>>> ^
>>>> kernel/trace/bpf_trace.c:204:11: error: 'struct perf_event' has no member named 'pmu'
>>>> event->pmu->count)
>>>>
>>>> This can happen when UPROBE_EVENT is enabled but KPROBE_EVENT
>>>> is disabled. I'm not sure if that is a configuration we care
>>>> about, otherwise we could prevent this case from occuring by
>>>> adding Kconfig dependencies.
>>>
>>> I think that seems better than spreading #if IS_ENABLEDs into the code.
>>> Probably enough to add a 'depends on PERF_EVENTS' to config BPF_EVENTS,
>>> so it's also explicitly documented.
>>>
>>
>> So just do the following then?
>>
>> -- Steve
>>
>> diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
>> index 8d6363f42169..f5aecff2d243 100644
>> --- a/kernel/trace/Kconfig
>> +++ b/kernel/trace/Kconfig
>> @@ -434,7 +434,7 @@ config UPROBE_EVENT
>>
>> config BPF_EVENTS
>> depends on BPF_SYSCALL
>> - depends on KPROBE_EVENT || UPROBE_EVENT
>> + depends on KPROBE_EVENT && UPROBE_EVENT
>
> yeah that's definitely cleaner and avoids ifdef creep in the future.
Agreed, that's better.