From: sashiko-bot@kernel.org
To: "Justin Suess" <utilityemal77@gmail.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v2 2/2] selftests/bpf: Add test for map-stored struct file kptrs
Date: Thu, 23 Apr 2026 22:52:40 +0000 [thread overview]
Message-ID: <20260423225241.3EA89C2BCAF@smtp.kernel.org> (raw)
In-Reply-To: <20260423152239.4140627-3-utilityemal77@gmail.com>
Sashiko AI review found 1 potential issue(s):
- [Medium] In `copy_file`, closing an invalid file descriptor overwrites the original error code.
--
commit 975d24d408cdf10dcbd5bc80513a92bbedd7dc6f
Author: Justin Suess <utilityemal77@gmail.com>
selftests/bpf: Add test for map-stored struct file kptrs
This commit adds tests for map-stored struct file referenced kptrs. It
validates that the struct file reference remains valid when the original
file descriptor is closed, and checks that unreferenced struct file
pointers are rejected by the verifier.
> diff --git a/tools/testing/selftests/bpf/prog_tests/refcounted_kptr_file.c b/tools/testing/selftests/bpf/prog_tests/refcounted_kptr_file.c
> new file mode 100644
> index 00000000000000..1f2586a7af9365
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/prog_tests/refcounted_kptr_file.c
[ ... ]
> +static int copy_file(const char *src_path, const char *dst_path, mode_t mode)
> +{
> + char buf[4096];
> + int src_fd = -1, dst_fd = -1;
> + int err = 0;
> +
> + src_fd = open(src_path, O_RDONLY | O_CLOEXEC);
> + if (src_fd < 0)
> + return -errno;
> +
> + dst_fd = open(dst_path, O_WRONLY | O_CREAT | O_EXCL | O_CLOEXEC,
> + mode & 0777);
> + if (dst_fd < 0) {
> + err = -errno;
> + goto out;
> + }
[ ... ]
> +out:
> + err = close(src_fd) ?: err;
> + err = close(dst_fd) ?: err;
If opening the destination file fails, dst_fd is left as -1, and the code jumps
here with err set to -errno. Would calling close(-1) here fail and return -1,
causing the ?: operator to overwrite the meaningful error code in err with -1?
Should the file descriptors be guarded with a >= 0 check before calling
close() to prevent masking the true cause of the failure?
> + return err;
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260423152239.4140627-1-utilityemal77@gmail.com?part=2
prev parent reply other threads:[~2026-04-23 22:52 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-23 15:22 [PATCH bpf-next v2 0/2] Allow storing referenced struct file kptrs in BPF maps Justin Suess
2026-04-23 15:22 ` [PATCH bpf-next v2 1/2] bpf: Implement dtor for struct file BTF ID Justin Suess
2026-04-23 16:16 ` bot+bpf-ci
2026-04-23 22:32 ` sashiko-bot
2026-04-23 15:22 ` [PATCH bpf-next v2 2/2] selftests/bpf: Add test for map-stored struct file kptrs Justin Suess
2026-04-23 22:52 ` sashiko-bot [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=20260423225241.3EA89C2BCAF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=sashiko@lists.linux.dev \
--cc=utilityemal77@gmail.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