All of lore.kernel.org
 help / color / mirror / Atom feed
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 v8 3/7] bpf: Generalize bpf_sk_storage
Date: Wed, 19 Aug 2020 10:12:15 -0700	[thread overview]
Message-ID: <20200819171215.lcgoon3fbm4kvkpc@kafai-mbp.dhcp.thefacebook.com> (raw)
In-Reply-To: <6cb51fa0-61a5-2cf6-b44d-84d58d08c775@chromium.org>

On Wed, Aug 19, 2020 at 02:41:50PM +0200, KP Singh wrote:
> On 8/18/20 3:05 AM, Martin KaFai Lau wrote:
> > On Mon, Aug 03, 2020 at 06:46:51PM +0200, KP Singh wrote:
> >> From: KP Singh <kpsingh@google.com>
> >>
> >> Refactor the functionality in bpf_sk_storage.c so that concept of
> >> storage linked to kernel objects can be extended to other objects like
> >> inode, task_struct etc.
> >>
> >> Each new local storage will still be a separate map and provide its own
> >> set of helpers. This allows for future object specific extensions and
> >> still share a lot of the underlying implementation.
> >>
> >> This includes the changes suggested by Martin in:
> >>
> >>   https://lore.kernel.org/bpf/20200725013047.4006241-1-kafai@fb.com/
> >>
> >> which adds map_local_storage_charge, map_local_storage_uncharge,
> >> and map_owner_storage_ptr.
> > A description will still be useful in the commit message to talk
> > about the new map_ops, e.g.
> > they allow kernel object to optionally have different mem-charge strategy.
> > 
> >>
> >> Co-developed-by: Martin KaFai Lau <kafai@fb.com>
> >> Signed-off-by: KP Singh <kpsingh@google.com>
> >> ---
> >>  include/linux/bpf.h            |   9 ++
> >>  include/net/bpf_sk_storage.h   |  51 +++++++
> >>  include/uapi/linux/bpf.h       |   8 +-
> >>  net/core/bpf_sk_storage.c      | 246 +++++++++++++++++++++------------
> >>  tools/include/uapi/linux/bpf.h |   8 +-
> >>  5 files changed, 233 insertions(+), 89 deletions(-)
> >>
> 
> >> +			struct bpf_local_storage_map *smap,
> >> +			struct bpf_local_storage_elem *first_selem);
> >> +
> >> +struct bpf_local_storage_data *
> >> +bpf_local_storage_update(void *owner, struct bpf_map *map, void *value,
> > Nit.  It may be more consistent to take "struct bpf_local_storage_map *smap"
> > instead of "struct bpf_map *map" here.
> > 
> > bpf_local_storage_map_check_btf() will be the only one taking
> > "struct bpf_map *map".
> 
> That's because it is used in map operations as map_check_btf which expects
> a bpf_map *map pointer. We can wrap it in another function but is that
> worth doing?
Agree.  bpf_local_storage_map_check_btf() should stay as is.

I meant to only change the "bpf_local_storage_update()" to take
"struct bpf_local_storage_map *smap".

> > 
> >>  	 *
> >>  	 * The elem of this map can be cleaned up here
> >>  	 * or
> >> -	 * by bpf_sk_storage_free() during __sk_destruct().
> >> +	 * by bpf_local_storage_free() during the destruction of the
> >> +	 * owner object. eg. __sk_destruct.
> > This belongs to patch 1 also.
> 
> 
> In patch, 1, changed it to:
> 
> 	 * The elem of this map can be cleaned up here
> 	 * or when the storage is freed e.g.
> 	 * by bpf_sk_storage_free() during __sk_destruct().
>
+1


  reply	other threads:[~2020-08-19 17:13 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-03 16:46 [PATCH bpf-next v8 0/7] Generalizing bpf_local_storage KP Singh
2020-08-03 16:46 ` [PATCH bpf-next v8 1/7] A purely mechanical change to split the renaming from the actual generalization KP Singh
2020-08-17 23:56   ` Martin KaFai Lau
2020-08-18 14:30     ` KP Singh
2020-08-03 16:46 ` [PATCH bpf-next v8 2/7] bpf: Generalize caching for sk_storage KP Singh
2020-08-17 23:57   ` Martin KaFai Lau
2020-08-03 16:46 ` [PATCH bpf-next v8 3/7] bpf: Generalize bpf_sk_storage KP Singh
2020-08-18  1:05   ` Martin KaFai Lau
2020-08-19 12:41     ` KP Singh
2020-08-19 17:12       ` Martin KaFai Lau [this message]
2020-08-19 22:19         ` KP Singh
2020-08-03 16:46 ` [PATCH bpf-next v8 4/7] bpf: Split bpf_local_storage to bpf_sk_storage KP Singh
2020-08-03 16:46 ` [PATCH bpf-next v8 5/7] bpf: Implement bpf_local_storage for inodes KP Singh
2020-08-18  1:27   ` Martin KaFai Lau
2020-08-18 15:10     ` KP Singh
2020-08-18 15:23       ` Martin KaFai Lau
2020-08-18 15:33         ` KP Singh
2020-08-03 16:46 ` [PATCH bpf-next v8 6/7] bpf: Allow local storage to be used from LSM programs KP Singh
2020-08-18  4:16   ` Martin KaFai Lau
2020-08-19 13:01     ` KP Singh
2020-08-03 16:46 ` [PATCH bpf-next v8 7/7] bpf: Add selftests for local_storage KP Singh
2020-08-03 17:46 ` [PATCH bpf-next v8 0/7] Generalizing bpf_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=20200819171215.lcgoon3fbm4kvkpc@kafai-mbp.dhcp.thefacebook.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.