mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Leon Hwang <leon.hwang@linux.dev>
To: Mykyta Yatsenko <mykyta.yatsenko5@gmail.com>, bpf@vger.kernel.org
Cc: Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Martin KaFai Lau <martin.lau@linux.dev>,
	Eduard Zingerman <eddyz87@gmail.com>,
	Kumar Kartikeya Dwivedi <memxor@gmail.com>,
	Shuah Khan <shuah@kernel.org>,
	linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
	kernel-patches-bot@fb.com
Subject: Re: [PATCH bpf-next 2/5] bpf: Fix concurrent regression in map_create()
Date: Tue, 19 May 2026 10:47:34 +0800	[thread overview]
Message-ID: <5660e657-f2a5-4866-9881-c705bff0c970@linux.dev> (raw)
In-Reply-To: <261a47f4-a92b-4a61-86ca-c1de362be105@gmail.com>

On 19/5/26 00:43, Mykyta Yatsenko wrote:
> 
> 
> On 5/18/26 3:54 PM, Leon Hwang wrote:
[...]
>>  	/* preserve original error even if log finalization is successful */
>>  	ret = bpf_log_attr_finalize(&attr_log, log);
>> -	if (ret) {
>> -		if (err >= 0)
>> -			close_fd(err);
>> +	if (ret && err < 0)
>> +		/*
>> +		 * Failed to finalize the log.
>> +		 * Should not close_fd(err) here. Since the bpf_map_new_fd()
> 
> nit: you can't close_fd(err) here, because err < 0? The comment overall appears to
> explain why we are making this change right now, rather than why this works this way.
> 

Will update the comment to

		/*
		 * Failed to finalize the log.
		 *
		 * Should not close_fd(err) here by
		 *
		 *  if (ret) {
		 *      if (err >= 0)
		 *              close_fd(err);
		 *      err = ret;
		 *  }
		 *
		 * Since the bpf_map_new_fd() has published the map fd,
		 * if a concurrent thread closes the fd, then opens new,
		 * unrelated file that receives the exact same fd
		 * number, close_fd(err) might inadvertently close the
		 * unrelated file.
		 *
		 * As a trade-off, override the err only when failed to
		 * finalize the log and failed to create map.
		 */

The comment is to explain the reason for overriding err.

> If map_crate() failed with error code and then log finalization failed, do we really
> want to override error code? It sounds like map_create error is more important.
> 

In that case, there are two error codes that should be returned to user
space. How to achieve it?

Since we should not ignore any error code of them, can we report the
error code of __map_create() failure by adding an error attr to struct
bpf_common_attr? Hmm, seems not a good idea.

Any idea?

Thanks,
Leon

>> +		 * has published the map fd, if a concurrent thread closes the
>> +		 * fd, then opens new, unrelated file that receives the exact
>> +		 * same fd number, close_fd(err) might inadvertently close the
>> +		 * unrelated file.
>> +		 * As a trade-off, override the err only when failed to finalize
>> +		 * the log and failed to create map.
>> +		 */
>>  		err = ret;
>> -	}
>>  
>>  	kfree(log);
>>  	return err;
> 


  reply	other threads:[~2026-05-19  2:47 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-18 14:54 [PATCH bpf-next 0/5] bpf: Follow-up fixes for BPF syscall common attributes Leon Hwang
2026-05-18 14:54 ` [PATCH bpf-next 1/5] bpf: Check tail zero of bpf_common_attr using offsetofend Leon Hwang
2026-05-18 16:14   ` Mykyta Yatsenko
2026-05-19  2:45     ` Leon Hwang
2026-05-18 14:54 ` [PATCH bpf-next 2/5] bpf: Fix concurrent regression in map_create() Leon Hwang
2026-05-18 15:40   ` bot+bpf-ci
2026-05-19  2:48     ` Leon Hwang
2026-05-19  3:05       ` Alexei Starovoitov
2026-05-19 10:48         ` Leon Hwang
2026-05-18 16:43   ` Mykyta Yatsenko
2026-05-19  2:47     ` Leon Hwang [this message]
2026-05-19 15:15       ` Mykyta Yatsenko
2026-05-20 14:51         ` Leon Hwang
2026-05-18 14:54 ` [PATCH bpf-next 3/5] libbpf: Add OPTS_VALID() for log_opts in bpf_map_create Leon Hwang
2026-05-18 14:54 ` [PATCH bpf-next 4/5] selftests/bpf: Use -1 as token_fd in map create failure test Leon Hwang
2026-05-18 14:54 ` [PATCH bpf-next 5/5] selftests/bpf: Add test to verify checking padding bytes for BPF syscall common attributes Leon Hwang
2026-05-19  2:00 ` [PATCH bpf-next 0/5] bpf: Follow-up fixes " patchwork-bot+netdevbpf

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=5660e657-f2a5-4866-9881-c705bff0c970@linux.dev \
    --to=leon.hwang@linux.dev \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --cc=kernel-patches-bot@fb.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=memxor@gmail.com \
    --cc=mykyta.yatsenko5@gmail.com \
    --cc=shuah@kernel.org \
    /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

all inboxes | Powered by JetHome®