public inbox for dtrace@lists.linux.dev
 help / color / mirror / Atom feed
From: Eugene Loh <eugene.loh@oracle.com>
To: 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 14:55:52 -0500	[thread overview]
Message-ID: <cee8efa1-0b4c-77bc-ebfa-dcb0684aa6e9@oracle.com> (raw)
In-Reply-To: <BY5PR10MB398729B40B695D3F3B541D3DC2CEA@BY5PR10MB3987.namprd10.prod.outlook.com>

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.

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);

  reply	other threads:[~2025-11-10 19:55 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 ` Eugene Loh [this message]
2025-11-10 21:17   ` [DTrace-devel] " Kris Van Hees
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=cee8efa1-0b4c-77bc-ebfa-dcb0684aa6e9@oracle.com \
    --to=eugene.loh@oracle.com \
    --cc=dtrace-devel@oss.oracle.com \
    --cc=dtrace@lists.linux.dev \
    --cc=kris.van.hees@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox