netdev - Re: [Patch bpf-next] sock_map: include sk

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6427844176538_c503a208e4@john.notmuch>
Date:   Fri, 31 Mar 2023 18:09:21 -0700
From:   John Fastabend <john.fastabend@...il.com>
To:     Yafang Shao <laoar.shao@...il.com>,
        Cong Wang <xiyou.wangcong@...il.com>
Cc:     netdev@...r.kernel.org, bpf@...r.kernel.org,
        Cong Wang <cong.wang@...edance.com>,
        Jakub Sitnicki <jakub@...udflare.com>,
        John Fastabend <john.fastabend@...il.com>
Subject: Re: [Patch bpf-next] sock_map: include sk_psock memory overhead too

Yafang Shao wrote:
> On Mon, Mar 27, 2023 at 6:16 AM Cong Wang <xiyou.wangcong@...il.com> wrote:
> >
> > From: Cong Wang <cong.wang@...edance.com>
> >
> > When a socket is added to a sockmap, sk_psock is allocated too as its
> > sk_user_data, therefore it should be consider as an overhead of sockmap
> > memory usage.
> >
> > Before this patch:
> >
> > 1: sockmap  flags 0x0
> >         key 4B  value 4B  max_entries 2  memlock 656B
> >         pids echo-sockmap(549)
> >
> > After this patch:
> >
> > 9: sockmap  flags 0x0
> >         key 4B  value 4B  max_entries 2  memlock 1824B
> >         pids echo-sockmap(568)
> >
> > Fixes: 73d2c61919e9 ("bpf, net: sock_map memory usage")
> > Cc: Yafang Shao <laoar.shao@...il.com>
> > Cc: Jakub Sitnicki <jakub@...udflare.com>
> > Cc: John Fastabend <john.fastabend@...il.com>
> > Signed-off-by: Cong Wang <cong.wang@...edance.com>
> > ---
> >  net/core/sock_map.c | 10 +++++++++-
> >  1 file changed, 9 insertions(+), 1 deletion(-)
> >
> > diff --git a/net/core/sock_map.c b/net/core/sock_map.c
> > index 7c189c2e2fbf..22197e565ece 100644
> > --- a/net/core/sock_map.c
> > +++ b/net/core/sock_map.c
> > @@ -799,9 +799,17 @@ static void sock_map_fini_seq_private(void *priv_data)
> >
> >  static u64 sock_map_mem_usage(const struct bpf_map *map)
> >  {
> > +       struct bpf_stab *stab = container_of(map, struct bpf_stab, map);
> >         u64 usage = sizeof(struct bpf_stab);
> > +       int i;
> >
> >         usage += (u64)map->max_entries * sizeof(struct sock *);
> > +
> > +       for (i = 0; i < stab->map.max_entries; i++) {
> 
> Although it adds a for-loop, the operation below is quite light. So it
> looks good to me.

We could track a count from update to avoid the loop?

> 
> > +               if (stab->sks[i])
> 
> Nit, stab->sks[i] can be modified in the delete path in parallel, so
> there should be a READ_ONCE() here.
> 
> > +                       usage += sizeof(struct sk_psock);
> > +       }
> > +
> >         return usage;
> >  }
> >
> > @@ -1412,7 +1420,7 @@ static u64 sock_hash_mem_usage(const struct bpf_map *map)
> >         u64 usage = sizeof(*htab);
> >
> >         usage += htab->buckets_num * sizeof(struct bpf_shtab_bucket);
> > -       usage += atomic_read(&htab->count) * (u64)htab->elem_size;
> > +       usage += atomic_read(&htab->count) * ((u64)htab->elem_size + sizeof(struct sk_psock));
> >         return usage;
> >  }
> >
> > --
> > 2.34.1
> >
> 
> 
> -- 
> Regards
> Yafang