diff mbox series

bpf: return EOPNOTSUPP when JIT is needed and not possible

Message ID 20211209134038.41388-1-cascardo@canonical.com (mailing list archive)
State Changes Requested
Delegated to: BPF
Headers show
Series bpf: return EOPNOTSUPP when JIT is needed and not possible | expand

Checks

Context Check Description
netdev/tree_selection success Not a local patch
bpf/vmtest-bpf-next-PR success PR summary
bpf/vmtest-bpf-next success VM_Test

Commit Message

Thadeu Lima de Souza Cascardo Dec. 9, 2021, 1:40 p.m. UTC
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 <cascardo@canonical.com>
---
 kernel/bpf/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

John Fastabend Dec. 9, 2021, 7:05 p.m. UTC | #1
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 <cascardo@canonical.com>
> ---
>  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
Ido Schimmel Dec. 9, 2021, 7:31 p.m. UTC | #2
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 <cascardo@canonical.com>
> > ---
> >  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/20191204.125135.750458923752225025.davem@davemloft.net/
Daniel Borkmann Dec. 9, 2021, 11:03 p.m. UTC | #3
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 <cascardo@canonical.com>
>>> ---
>>>   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/20191204.125135.750458923752225025.davem@davemloft.net/

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
Jakub Kicinski Dec. 10, 2021, 2:23 a.m. UTC | #4
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/20191204.125135.750458923752225025.davem@davemloft.net/  
> 
> 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..
Thadeu Lima de Souza Cascardo Dec. 10, 2021, 12:24 p.m. UTC | #5
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/20191204.125135.750458923752225025.davem@davemloft.net/  
> > 
> > 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..
diff mbox series

Patch

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 {