From: Kris Van Hees <kris.van.hees@oracle.com>
To: Eugene Loh <eugene.loh@oracle.com>
Cc: Kris Van Hees <kris.van.hees@oracle.com>,
dtrace@lists.linux.dev, dtrace-devel@oss.oracle.com
Subject: Re: [DTrace-devel] [PATCH 1/4] bpf: fix file descriptor leak
Date: Mon, 10 Nov 2025 16:17:55 -0500 [thread overview]
Message-ID: <aRJWg7pNBqBytP43@oracle.com> (raw)
In-Reply-To: <cee8efa1-0b4c-77bc-ebfa-dcb0684aa6e9@oracle.com>
On Mon, Nov 10, 2025 at 02:55:52PM -0500, Eugene Loh wrote:
> Reviewed-by: Eugene Loh <eugene.loh@oracle.com>
>
> But I'm curious about the "if (attach)" check. It looks a little funny that
> we first set fd= and then we check "if (attach)" to see if we are going to
> use the fd value we just set. I suppose it does not matter since we expect
> attach to be there, but normally one would first check if a value is needed
> before going to the trouble of determining the value. In a way, this small,
> pre-existing issue is outside the scope of this patch, except that the patch
> makes more obvious the one, isolated place where this temporary value is
> used.
>
> Up to you whether to clean that up.
There is a real reason for that. As you can see, fentry-based FBT probes
have their own BPF program load function (the reason a hook was added for
that in providers). That one performs the attach as part of the program
load, so it does not have an attach hook.
> On 11/10/25 10:27, Kris Van Hees via DTrace-devel wrote:
> > When a BPF program has been attached to a perf event, it is safe to
> > close its file descriptor.
> >
> > Signed-off-by: Kris Van Hees <kris.van.hees@oracle.com>
> > ---
> > libdtrace/dt_bpf.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libdtrace/dt_bpf.c b/libdtrace/dt_bpf.c
> > index 0223764a..28eb890e 100644
> > --- a/libdtrace/dt_bpf.c
> > +++ b/libdtrace/dt_bpf.c
> > @@ -1385,8 +1385,8 @@ dt_bpf_load_progs(dtrace_hdl_t *dtp, uint_t cflags)
> > if (prp->prov->impl->attach)
> > rc = prp->prov->impl->attach(dtp, prp, fd);
> > + close(fd);
> > if (rc < 0 && !(prp->flags & DT_PROBE_FLAG_OPTIONAL)) {
> > - close(fd);
> > dt_attach_error(dtp, rc,
> > prp->desc->prv, prp->desc->mod,
> > prp->desc->fun, prp->desc->prb);
next prev parent reply other threads:[~2025-11-10 21:18 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-10 15:27 [PATCH 1/4] bpf: fix file descriptor leak Kris Van Hees
2025-11-10 19:55 ` [DTrace-devel] " Eugene Loh
2025-11-10 21:17 ` Kris Van Hees [this message]
2025-11-10 21:50 ` Kris Van Hees
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=aRJWg7pNBqBytP43@oracle.com \
--to=kris.van.hees@oracle.com \
--cc=dtrace-devel@oss.oracle.com \
--cc=dtrace@lists.linux.dev \
--cc=eugene.loh@oracle.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.