All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heiko Carstens <hca@linux.ibm.com>
To: Mykyta Yatsenko <mykyta.yatsenko5@gmail.com>
Cc: Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Eduard Zingerman <eddyz87@gmail.com>,
	Kumar Kartikeya Dwivedi <memxor@gmail.com>,
	Mykyta Yatsenko <yatsenko@meta.com>,
	bpf@vger.kernel.org, linux-kernel@vger.kernel.org,
	Russell King <linux@armlinux.org.uk>,
	Puranjay Mohan <puranjay@kernel.org>
Subject: Re: [PATCH bpf-next] bpf: Add __bpfcall attribute to bpf_task_work_callback()
Date: Mon, 27 Jul 2026 16:13:02 +0200	[thread overview]
Message-ID: <20260727141302.11274B21-hca@linux.ibm.com> (raw)
In-Reply-To: <c1b15a2a-88d2-4f30-a827-9a96bc35b365@gmail.com>

On Mon, Jul 27, 2026 at 02:09:12PM +0100, Mykyta Yatsenko wrote:
> On 7/27/26 10:38 AM, Heiko Carstens wrote:
> > BPF kCFI support is optional for architectures which support kCFI.
> > If an architecture provides bpf kCFI support it must override the
> > default __bpfcall define (which translates to __nocfi).
> > 
> > Add the missing __bpfcall attribute to bpf_task_work_callback() which
> > calls bpf programs indirectly to avoid CFI checks for such cases.
> > 
> > Fixes: 38aa7003e369 ("bpf: task work scheduling kfuncs")
> > Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
> > ---
> >  kernel/bpf/helpers.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
> > index 88b38db47de9..9bf82c9ea1da 100644
> > --- a/kernel/bpf/helpers.c
> > +++ b/kernel/bpf/helpers.c
> > @@ -4447,7 +4447,7 @@ static void bpf_task_work_cancel(struct bpf_task_work_ctx *ctx)
> >  		bpf_task_work_ctx_put(ctx);
> >  }
> >  
> > -static void bpf_task_work_callback(struct callback_head *cb)
> > +static __bpfcall void bpf_task_work_callback(struct callback_head *cb)
> 
> Thanks for the patch, I've already sent another fix:
> https://lore.kernel.org/all/20260724-task_work_cfi-v1-1-2616691781ed@meta.com/
> Is __bpfcall still needed?

Yes, it is needed for architectures which select ARCH_SUPPORTS_CFI, and which
in addition support bpf, but do not provide CFI support for bpf programs.

As of now it looks like this is only the case for arm, at least as far as I
understand the code. It might be easier to implement bpf/cfi support for arm,
then drop the __bpfcall macro entirely, and require from future architectures
to provde bpf/cfi support whenever they select ARCH_SUPPORTS_CFI.

I'm writing the above, since due to AI feedback to this patch, there seem to
be more bpf functions which call bpf programs indirectly and which miss the
__bpfcall attribute.

      reply	other threads:[~2026-07-27 14:13 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-27  9:38 [PATCH bpf-next] bpf: Add __bpfcall attribute to bpf_task_work_callback() Heiko Carstens
2026-07-27 10:00 ` sashiko-bot
2026-07-27 13:09 ` Mykyta Yatsenko
2026-07-27 14:13   ` Heiko Carstens [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260727141302.11274B21-hca@linux.ibm.com \
    --to=hca@linux.ibm.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=memxor@gmail.com \
    --cc=mykyta.yatsenko5@gmail.com \
    --cc=puranjay@kernel.org \
    --cc=yatsenko@meta.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.