From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: qemu-devel@nongnu.org, Jason Wang <jasowang@redhat.com>,
Andrew Melnychenko <andrew@daynix.com>,
Yuri Benditovich <yuri.benditovich@daynix.com>
Subject: Re: ebpf functions can fail without setting an error
Date: Mon, 17 Nov 2025 15:06:12 +0000 [thread overview]
Message-ID: <aRs55PV-R4m8KDCu@redhat.com> (raw)
In-Reply-To: <871plwpxpu.fsf@pond.sub.org>
On Mon, Nov 17, 2025 at 02:58:37PM +0100, Markus Armbruster wrote:
> Markus Armbruster <armbru@redhat.com> writes:
>
> > Daniel P. Berrangé <berrange@redhat.com> writes:
> >
> >> On Thu, Aug 07, 2025 at 03:14:56PM +0200, Markus Armbruster wrote:
> >>> Three functions in ebpf_rss.h take an Error ** argument and return bool.
> >>> Good.
> >>>
> >>> They can all fail without setting an error. Not good.
> >>>
> >>> The failures without error are:
> >>>
> >>> * All three stubs in ebpf_rss-stub.c always. Oversight?
> >>
> >> Opps, yes, we really should have added error_setg() calls for diagnosis
> >> if someone tries to use eBPF when QEMU build has it disabled.
>
> Easy enough, but...
>
> > Some stubs exist only to mollify the linker. They are not meant to be
> > called. They should abort(), optionally with lipstick.
> >
> > Other stubs are called and should fail nicely.
> >
> > Can you tell me offhand which kind these are?
>
> If calling these stubs is possible, I'd like to know how I can get them
> called, so I can test the errors I add.
>
> If calling is not possible, I'd rather add abort()s.
>
> I tried to figure out whether calling is possible, but it ended in
> confusion. Can you help?
* ebpf_rss_set_all
Is called from virtio_net_attach_ebpf_rss
The call is unreachable if ebpf_rss_is_loaded returns false
Stub for ebpf_rss_is_loaded always returns false
=> ebpf_rss_set_all stub is unreachable
* ebpf_rss_load_fds, ebpf_rss_load
Is called from virtio_net_load_ebpf_fds, which is called from
virtio_net_load_ebpf
The call to virtio_net_load_ebpf_fds is unreachable if
virtio_net_attach_ebpf_to_backend fails
virtio_net_attach_ebpf_to_backend fails if set_steering_ebpf
fails
set_steering_ebpf fails if ioctl(fd, TUNSETSTEERINGEBPF...)
fails on Linux; all non-Linux impls of ebpf_rss_load_fds
return -1
It is theoretically p9ossible to build QEMU without EBPF
while both glibc & the kernel support TUNSETSTEERINGEBPF ioctl
=> ebpf_rss_load_fds, ebpf_rss_load are reachable in stubs
> >>> * Non-stub ebpf_rss_load() when ebpf_rss_is_loaded(). Are these
> >>> reachable?
> >>
> >> This scenario should never happen, and we should add a call like
> >>
> >> error_setg(errp, "eBPF program is already loaded");
> >>
> >> to report it correctly.
> >
> > Is it a programming error when it happens?
>
> This question is still open as well.
I'd consider it a programming error. I don't think we have a code
path that could trigger it currently.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2025-11-17 15:07 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-07 13:14 ebpf functions can fail without setting an error Markus Armbruster
2025-08-19 10:48 ` Daniel P. Berrangé
2025-08-25 12:19 ` Markus Armbruster
2025-08-25 13:27 ` Philippe Mathieu-Daudé
2025-08-27 8:13 ` Markus Armbruster
2025-09-17 8:24 ` Akihiko Odaki
2025-11-17 13:58 ` Markus Armbruster
2025-11-17 15:06 ` Daniel P. Berrangé [this message]
2025-11-18 12:13 ` Markus Armbruster
2025-11-18 12:23 ` Daniel P. Berrangé
2025-11-18 12:25 ` Daniel P. Berrangé
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=aRs55PV-R4m8KDCu@redhat.com \
--to=berrange@redhat.com \
--cc=andrew@daynix.com \
--cc=armbru@redhat.com \
--cc=jasowang@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=yuri.benditovich@daynix.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).