From: Kui-Feng Lee <sinquersw@gmail.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>,
Kui-Feng Lee <thinker.li@gmail.com>
Cc: bpf <bpf@vger.kernel.org>, Alexei Starovoitov <ast@kernel.org>,
Martin KaFai Lau <martin.lau@linux.dev>,
Song Liu <song@kernel.org>, Kernel Team <kernel-team@meta.com>,
Andrii Nakryiko <andrii@kernel.org>,
Kui-Feng Lee <kuifeng@meta.com>
Subject: Re: [RFC bpf-next 5/5] selftests/bpf: test __kptr_user on the value of a task storage map.
Date: Mon, 12 Aug 2024 10:15:07 -0700 [thread overview]
Message-ID: <e136e024-8949-4836-be02-fb1a1ca75f16@gmail.com> (raw)
In-Reply-To: <CAADnVQ+B1oB2Ct+n0PrWnb5zJ2SEBS1ZmREqR_sK=tQys6y3zQ@mail.gmail.com>
On 8/12/24 09:58, Alexei Starovoitov wrote:
> On Wed, Aug 7, 2024 at 4:58 PM Kui-Feng Lee <thinker.li@gmail.com> wrote:
>> +
>> + user_data_mmap = mmap(NULL, sizeof(*user_data_mmap), PROT_READ | PROT_WRITE,
>> + MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
>> + if (!ASSERT_NEQ(user_data_mmap, MAP_FAILED, "mmap"))
>> + return;
>> +
>> + memcpy(user_data_mmap, &user_data_mmap_v, sizeof(*user_data_mmap));
>> + value.udata_mmap = user_data_mmap;
>> + value.udata = &user_data;
>
> There shouldn't be a need to do mmap(). It's too much memory overhead.
> The user should be able to write:
> static __thread struct user_data udata;
> value.udata = &udata;
> bpf_map_update_elem(map_fd, my_task_fd, &value)
> and do it once.
> Later multi thread user code will just access "udata".
> No map lookups.
mmap() is not necessary here. There are two pointers here.
udata_mmap one is used to test the case crossing page boundary although
in the current RFC it fails to do it. It will be fixed later.
udata one works just like what you have described, except user_data is a
local variable.
>
> If sizeof(udata) is small enough the kernel will pin either
> one or two pages (if udata crosses page boundary).
>
> So no extra memory consumption by the user process while the kernel
> pins a page or two.
> In a good case it's one page and no extra vmap.
> I wonder whether we should enforce that one page case.
> It's not hard for users to write:
> static __thread struct user_data udata __attribute__((aligned(sizeof(udata))));
With one page restriction, the implementation would be much simpler. If
you think it is a reasonable restriction, I would enforce this rule.
next prev parent reply other threads:[~2024-08-12 17:15 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-07 23:57 [RFC bpf-next 0/5] Share user memory to BPF program through task storage map Kui-Feng Lee
2024-08-07 23:57 ` [RFC bpf-next 1/5] bpf: Parse and support "kptr_user" tag Kui-Feng Lee
2024-08-07 23:57 ` [RFC bpf-next 2/5] bpf: Handle BPF_KPTR_USER in verifier Kui-Feng Lee
2024-08-12 16:48 ` Alexei Starovoitov
2024-08-13 16:52 ` Kui-Feng Lee
2024-08-13 19:35 ` Alexei Starovoitov
2024-08-13 23:13 ` Kui-Feng Lee
2024-08-07 23:57 ` [RFC bpf-next 3/5] bpf: pin, translate, and unpin __kptr_user from syscalls Kui-Feng Lee
2024-08-08 0:05 ` Kui-Feng Lee
2024-08-08 0:39 ` Kui-Feng Lee
2024-08-12 16:00 ` Kui-Feng Lee
2024-08-12 16:45 ` Alexei Starovoitov
2024-08-12 17:24 ` Kui-Feng Lee
2024-08-12 17:36 ` Alexei Starovoitov
2024-08-12 17:51 ` Kui-Feng Lee
2024-08-07 23:57 ` [RFC bpf-next 4/5] libbpf: define __kptr_user Kui-Feng Lee
2024-08-07 23:57 ` [RFC bpf-next 5/5] selftests/bpf: test __kptr_user on the value of a task storage map Kui-Feng Lee
2024-08-12 16:58 ` Alexei Starovoitov
2024-08-12 17:15 ` Kui-Feng Lee [this message]
2024-08-12 17:31 ` Alexei Starovoitov
2024-08-12 18:10 ` Kui-Feng Lee
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=e136e024-8949-4836-be02-fb1a1ca75f16@gmail.com \
--to=sinquersw@gmail.com \
--cc=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=kernel-team@meta.com \
--cc=kuifeng@meta.com \
--cc=martin.lau@linux.dev \
--cc=song@kernel.org \
--cc=thinker.li@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