On 8/14/23 10:03, Stanislav Fomichev wrote:
On 08/10, Martin Kelly wrote:
On 8/10/23 14:43, Martin Kelly wrote:
From: Marco Vedovati <marco.vedovati@xxxxxxxxxxxxxxx>
Enable the close-on-exec flag when using gzopen
This is especially important for multithreaded programs making use of
libbpf, where a fork + exec could race with libbpf library calls,
potentially resulting in a file descriptor leaked to the new process.
Signed-off-by: Marco Vedovati <marco.vedovati@xxxxxxxxxxxxxxx>
---
tools/lib/bpf/libbpf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 17883f5a44b9..b14a4376a86e 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -1978,9 +1978,9 @@ static int bpf_object__read_kconfig_file(struct bpf_object *obj, void *data)
return -ENAMETOOLONG;
/* gzopen also accepts uncompressed files. */
- file = gzopen(buf, "r");
+ file = gzopen(buf, "re");
if (!file)
- file = gzopen("/proc/config.gz", "r");
+ file = gzopen("/proc/config.gz", "re");
if (!file) {
pr_warn("failed to open system Kconfig\n");
Sorry for double-sending the patch; the first was missing the bpf-next
prefix and I wasn't sure if that would be an issue. Feel free to ignore this
patch, as the other already got a reply.
Next time pls at least reply to the first 'wrong' one :-)
Yeah, I replied to this one as you had already replied to the first, and
I didn't want to add confusion and split the conversation into two
pieces. I saw a 40 minute or so delay before the initial patch was
posted to vger, and I had thought "maybe it's because I was missing the
bpf-next prefix" and then resent... only to have the initial message
appear a few minutes later :). So, my bad, I jumped the gun.
Next time I'll make sure to add the right prefix initially and to take
into account mailing list delay.
