From: Martin KaFai Lau <kafai@fb.com>
To: KP Singh <kpsingh@chromium.org>
Cc: <linux-kernel@vger.kernel.org>, <bpf@vger.kernel.org>,
<linux-security-module@vger.kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Paul Turner <pjt@google.com>, Jann Horn <jannh@google.com>,
Florent Revest <revest@chromium.org>
Subject: Re: [PATCH bpf-next v6 1/7] bpf: Renames to prepare for generalizing sk_storage.
Date: Thu, 23 Jul 2020 22:31:35 -0700 [thread overview]
Message-ID: <20200724053135.itp5qrqaplbyzxxw@kafai-mbp> (raw)
In-Reply-To: <20200723115032.460770-2-kpsingh@chromium.org>
On Thu, Jul 23, 2020 at 01:50:26PM +0200, KP Singh wrote:
> From: KP Singh <kpsingh@google.com>
>
> A purely mechanical change to split the renaming from the actual
> generalization.
>
> Flags/consts:
>
> SK_STORAGE_CREATE_FLAG_MASK BPF_LOCAL_STORAGE_CREATE_FLAG_MASK
> BPF_SK_STORAGE_CACHE_SIZE BPF_LOCAL_STORAGE_CACHE_SIZE
> MAX_VALUE_SIZE BPF_LOCAL_STORAGE_MAX_VALUE_SIZE
>
> Structs:
>
> bucket bpf_local_storage_map_bucket
> bpf_sk_storage_map bpf_local_storage_map
> bpf_sk_storage_data bpf_local_storage_data
> bpf_sk_storage_elem bpf_local_storage_elem
> bpf_sk_storage bpf_local_storage
> selem_linked_to_sk selem_linked_to_storage
> selem_alloc bpf_selem_alloc
>
> The "sk" member in bpf_local_storage is also updated to "owner"
> in preparation for changing the type to void * in a subsequent patch.
>
> Functions:
>
> __selem_unlink_sk bpf_selem_unlink_storage
> __selem_link_sk bpf_selem_link_storage
> selem_unlink_sk __bpf_selem_unlink_storage
> sk_storage_update bpf_local_storage_update
> __sk_storage_lookup bpf_local_storage_lookup
> bpf_sk_storage_map_free bpf_local_storage_map_free
> bpf_sk_storage_map_alloc bpf_local_storage_map_alloc
> bpf_sk_storage_map_alloc_check bpf_local_storage_map_alloc_check
> bpf_sk_storage_map_check_btf bpf_local_storage_map_check_btf
Thanks for separating this mechanical name change in a separate patch.
It is much easier to follow. This patch looks good.
A minor thought is, when I look at unlink_map() and unlink_storage(),
it keeps me looking back for the lock situation. I think
the main reason is the bpf_selem_unlink_map() is locked but
bpf_selem_unlink_storage() is unlocked now. May be:
bpf_selem_unlink_map() => bpf_selem_unlink_map_locked()
bpf_selem_link_map() => bpf_selem_link_map_locked()
__bpf_selem_unlink_storage() => bpf_selem_unlink_storage_locked()
bpf_link_storage() means unlocked
bpf_unlink_storage() means unlocked.
I think it could be one follow-up patch later instead of interrupting
multiple patches in this set for this minor thing. For now, lets
continue with this and remember default is nolock for storage.
I will continue tomorrow.
next prev parent reply other threads:[~2020-07-24 5:32 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-23 11:50 [PATCH bpf-next v6 0/7] Generalizing bpf_local_storage KP Singh
2020-07-23 11:50 ` [PATCH bpf-next v6 1/7] bpf: Renames to prepare for generalizing sk_storage KP Singh
2020-07-24 5:31 ` Martin KaFai Lau [this message]
2020-07-24 15:44 ` KP Singh
2020-07-23 11:50 ` [PATCH bpf-next v6 2/7] bpf: Generalize caching for sk_storage KP Singh
2020-07-23 11:50 ` [PATCH bpf-next v6 3/7] bpf: Generalize bpf_sk_storage KP Singh
2020-07-25 1:13 ` Martin KaFai Lau
2020-07-27 20:28 ` KP Singh
2020-07-25 1:30 ` [RFC PATCH bpf-next] bpf: POC on local_storage charge and uncharge map_ops Martin KaFai Lau
2020-07-27 20:26 ` KP Singh
2020-07-27 21:43 ` Martin KaFai Lau
2020-07-23 11:50 ` [PATCH bpf-next v6 4/7] bpf: Split bpf_local_storage to bpf_sk_storage KP Singh
2020-07-23 11:50 ` [PATCH bpf-next v6 5/7] bpf: Implement bpf_local_storage for inodes KP Singh
2020-07-23 11:50 ` [PATCH bpf-next v6 6/7] bpf: Allow local storage to be used from LSM programs KP Singh
2020-07-23 11:50 ` [PATCH bpf-next v6 7/7] bpf: Add selftests for local_storage KP Singh
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=20200724053135.itp5qrqaplbyzxxw@kafai-mbp \
--to=kafai@fb.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=jannh@google.com \
--cc=kpsingh@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=pjt@google.com \
--cc=revest@chromium.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;
as well as URLs for NNTP newsgroup(s).