When a CBPF program is JITed and CONFIG_BPF_JIT_ALWAYS_ON is enabled, and
the JIT fails, it would return ENOTSUPP, which is not a valid userspace
error code. Instead, EOPNOTSUPP should be returned.
Fixes: 290af86629b2 ("bpf: introduce BPF_JIT_ALWAYS_ON config")
Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]>
---
kernel/bpf/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index de3e5bc6781f..5c89bae0d6f9 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@ -1931,7 +1931,7 @@ struct bpf_prog *bpf_prog_select_runtime(struct bpf_prog *fp, int *err)
fp = bpf_int_jit_compile(fp);
bpf_prog_jit_attempt_done(fp);
if (!fp->jited && jit_needed) {
- *err = -ENOTSUPP;
+ *err = -EOPNOTSUPP;
return fp;
}
} else {
--
2.32.0
Thadeu Lima de Souza Cascardo wrote:
> When a CBPF program is JITed and CONFIG_BPF_JIT_ALWAYS_ON is enabled, and
> the JIT fails, it would return ENOTSUPP, which is not a valid userspace
> error code. Instead, EOPNOTSUPP should be returned.
>
> Fixes: 290af86629b2 ("bpf: introduce BPF_JIT_ALWAYS_ON config")
> Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]>
> ---
> kernel/bpf/core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
> index de3e5bc6781f..5c89bae0d6f9 100644
> --- a/kernel/bpf/core.c
> +++ b/kernel/bpf/core.c
> @@ -1931,7 +1931,7 @@ struct bpf_prog *bpf_prog_select_runtime(struct bpf_prog *fp, int *err)
> fp = bpf_int_jit_compile(fp);
> bpf_prog_jit_attempt_done(fp);
> if (!fp->jited && jit_needed) {
> - *err = -ENOTSUPP;
> + *err = -EOPNOTSUPP;
> return fp;
> }
> } else {
> --
> 2.32.0
>
It seems BPF subsys returns ENOTSUPP in multiple places. This fixes one
paticular case and is user facing. Not sure we want to one-off fix them
here creating user facing changes over multiple kernel versions. On the
fence with this one curious to see what others think. Haven't apps
already adapted to the current convention or they don't care?
.John
On Thu, Dec 09, 2021 at 11:05:18AM -0800, John Fastabend wrote:
> Thadeu Lima de Souza Cascardo wrote:
> > When a CBPF program is JITed and CONFIG_BPF_JIT_ALWAYS_ON is enabled, and
> > the JIT fails, it would return ENOTSUPP, which is not a valid userspace
> > error code. Instead, EOPNOTSUPP should be returned.
> >
> > Fixes: 290af86629b2 ("bpf: introduce BPF_JIT_ALWAYS_ON config")
> > Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]>
> > ---
> > kernel/bpf/core.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
> > index de3e5bc6781f..5c89bae0d6f9 100644
> > --- a/kernel/bpf/core.c
> > +++ b/kernel/bpf/core.c
> > @@ -1931,7 +1931,7 @@ struct bpf_prog *bpf_prog_select_runtime(struct bpf_prog *fp, int *err)
> > fp = bpf_int_jit_compile(fp);
> > bpf_prog_jit_attempt_done(fp);
> > if (!fp->jited && jit_needed) {
> > - *err = -ENOTSUPP;
> > + *err = -EOPNOTSUPP;
> > return fp;
> > }
> > } else {
> > --
> > 2.32.0
> >
>
> It seems BPF subsys returns ENOTSUPP in multiple places. This fixes one
> paticular case and is user facing. Not sure we want to one-off fix them
> here creating user facing changes over multiple kernel versions. On the
> fence with this one curious to see what others think. Haven't apps
> already adapted to the current convention or they don't care?
Similar issue was discussed in the past. See:
https://lore.kernel.org/netdev/[email protected]/
On 12/9/21 8:31 PM, Ido Schimmel wrote:
> On Thu, Dec 09, 2021 at 11:05:18AM -0800, John Fastabend wrote:
>> Thadeu Lima de Souza Cascardo wrote:
>>> When a CBPF program is JITed and CONFIG_BPF_JIT_ALWAYS_ON is enabled, and
>>> the JIT fails, it would return ENOTSUPP, which is not a valid userspace
>>> error code. Instead, EOPNOTSUPP should be returned.
>>>
>>> Fixes: 290af86629b2 ("bpf: introduce BPF_JIT_ALWAYS_ON config")
>>> Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]>
>>> ---
>>> kernel/bpf/core.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
>>> index de3e5bc6781f..5c89bae0d6f9 100644
>>> --- a/kernel/bpf/core.c
>>> +++ b/kernel/bpf/core.c
>>> @@ -1931,7 +1931,7 @@ struct bpf_prog *bpf_prog_select_runtime(struct bpf_prog *fp, int *err)
>>> fp = bpf_int_jit_compile(fp);
>>> bpf_prog_jit_attempt_done(fp);
>>> if (!fp->jited && jit_needed) {
>>> - *err = -ENOTSUPP;
>>> + *err = -EOPNOTSUPP;
>>> return fp;
>>> }
>>> } else {
>>
>> It seems BPF subsys returns ENOTSUPP in multiple places. This fixes one
>> paticular case and is user facing. Not sure we want to one-off fix them
>> here creating user facing changes over multiple kernel versions. On the
>> fence with this one curious to see what others think. Haven't apps
>> already adapted to the current convention or they don't care?
>
> Similar issue was discussed in the past. See:
> https://lore.kernel.org/netdev/[email protected]/
With regards to ENOTSUPP exposure, if the consensus is that we should fix all
occurences over to EOPNOTSUPP even if they've been exposed for quite some time
(Jakub?), we could give this patch a try maybe via bpf-next and see if anyone
complains.
Thadeu, I think you also need to fix up BPF selftests as test_verifier, to mention
one example (there are also bunch of others under tools/testing/selftests/), is
checking for ENOTSUPP specifically..
Thanks,
Daniel
On Fri, 10 Dec 2021 00:03:40 +0100 Daniel Borkmann wrote:
> > Similar issue was discussed in the past. See:
> > https://lore.kernel.org/netdev/[email protected]/
>
> With regards to ENOTSUPP exposure, if the consensus is that we should fix all
> occurences over to EOPNOTSUPP even if they've been exposed for quite some time
> (Jakub?),
Did you mean me? :) In case you did - I think we should avoid it
for new code but changing existing now seems risky. Alexei and Andrii
would know best but quick search of code bases at work reveals some
scripts looking for ENOTSUPP.
Thadeu, what motivated the change?
If we're getting those changes fixes based on checkpatch output maybe
there is a way to mute the checkpatch warnings when it's not run on a
diff?
> we could give this patch a try maybe via bpf-next and see if anyone complains.
>
> Thadeu, I think you also need to fix up BPF selftests as test_verifier, to mention
> one example (there are also bunch of others under tools/testing/selftests/), is
> checking for ENOTSUPP specifically..
On Thu, Dec 09, 2021 at 06:23:49PM -0800, Jakub Kicinski wrote:
> On Fri, 10 Dec 2021 00:03:40 +0100 Daniel Borkmann wrote:
> > > Similar issue was discussed in the past. See:
> > > https://lore.kernel.org/netdev/[email protected]/
> >
> > With regards to ENOTSUPP exposure, if the consensus is that we should fix all
> > occurences over to EOPNOTSUPP even if they've been exposed for quite some time
> > (Jakub?),
>
> Did you mean me? :) In case you did - I think we should avoid it
> for new code but changing existing now seems risky. Alexei and Andrii
> would know best but quick search of code bases at work reveals some
> scripts looking for ENOTSUPP.
>
> Thadeu, what motivated the change?
>
> If we're getting those changes fixes based on checkpatch output maybe
> there is a way to mute the checkpatch warnings when it's not run on a
> diff?
>
It was not checkpatch that motivated me.
I was looking into the following commits as we hit a failed test.
be08815c5d3b ("bpf: add also cbpf long jump test cases with heavy expansion")
050fad7c4534 ("bpf: fix truncated jump targets on heavy expansions")
Then, I realized that if given the right number of BPF_LDX | BPF_B | BPF_MSH
instructions, it will pass the bpf_convert_filter stage, but fail at blinding.
And if you have CONFIG_BPF_JIT_ALWAYS_ON, setting the filter will fail with
ENOTSUPP, which should not be sent to userspace.
I noticed other ENOTSUPP, but they seemed to be returned by helpers, and I was
not sure this would be relayed to userspace. So, I went for fixing the observed
case.
I will see if any of the tests I can run is broken by this change and submit it
again with the tests fixed as well.
Cascardo.
> > we could give this patch a try maybe via bpf-next and see if anyone complains.
> >
> > Thadeu, I think you also need to fix up BPF selftests as test_verifier, to mention
> > one example (there are also bunch of others under tools/testing/selftests/), is
> > checking for ENOTSUPP specifically..