All of lore.kernel.org
 help / color / mirror / Atom feed
From: KP Singh <kpsingh@chromium.org>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>,
	linux-security-module@vger.kernel.org,
	open list <linux-kernel@vger.kernel.org>,
	bpf <bpf@vger.kernel.org>, Andrii Nakryiko <andriin@fb.com>,
	Alexei Starovoitov <ast@kernel.org>, Paul Turner <pjt@google.com>,
	Jann Horn <jannh@google.com>,
	Florent Revest <revest@chromium.org>,
	Brendan Jackman <jackmanb@chromium.org>
Subject: Re: [PATCH bpf-next v3 1/7] bpf: Refactor trampoline update code
Date: Wed, 4 Mar 2020 20:08:55 +0100	[thread overview]
Message-ID: <20200304190855.GA31073@chromium.org> (raw)
In-Reply-To: <CAEf4Bza4y_H+Avry=OdQ=j6Ey-niTYLafKUwicVeutmQ3X5g=g@mail.gmail.com>

On 04-Mär 10:47, Andrii Nakryiko wrote:
> On Wed, Mar 4, 2020 at 10:44 AM KP Singh <kpsingh@chromium.org> wrote:
> >
> > On 04-Mär 19:37, Daniel Borkmann wrote:
> > > On 3/4/20 4:47 PM, KP Singh wrote:
> > > > From: KP Singh <kpsingh@google.com>
> > > >
> > > > As we need to introduce a third type of attachment for trampolines, the
> > > > flattened signature of arch_prepare_bpf_trampoline gets even more
> > > > complicated.
> > > >
> > > > Refactor the prog and count argument to arch_prepare_bpf_trampoline to
> > > > use bpf_tramp_progs to simplify the addition and accounting for new
> > > > attachment types.
> > > >
> > > > Signed-off-by: KP Singh <kpsingh@google.com>
> > > > Acked-by: Andrii Nakryiko <andriin@fb.com>
> > >
> > > [...]
> > > > diff --git a/kernel/bpf/bpf_struct_ops.c b/kernel/bpf/bpf_struct_ops.c
> > > > index c498f0fffb40..9f7e0328a644 100644
> > > > --- a/kernel/bpf/bpf_struct_ops.c
> > > > +++ b/kernel/bpf/bpf_struct_ops.c
> > > > @@ -320,6 +320,7 @@ static int bpf_struct_ops_map_update_elem(struct bpf_map *map, void *key,
> > > >     struct bpf_struct_ops_value *uvalue, *kvalue;
> > > >     const struct btf_member *member;
> > > >     const struct btf_type *t = st_ops->type;
> > > > +   struct bpf_tramp_progs *tprogs = NULL;
> > > >     void *udata, *kdata;
> > > >     int prog_fd, err = 0;
> > > >     void *image;
> > > > @@ -425,10 +426,18 @@ static int bpf_struct_ops_map_update_elem(struct bpf_map *map, void *key,
> > > >                     goto reset_unlock;
> > > >             }
> > > > +           tprogs = kcalloc(BPF_TRAMP_MAX, sizeof(*tprogs), GFP_KERNEL);
> > > > +           if (!tprogs) {
> > > > +                   err = -ENOMEM;
> > > > +                   goto reset_unlock;
> > > > +           }
> > > > +
> > >
> > > Looking over the code again, I'm quite certain that here's a memleak
> > > since the kcalloc() is done in the for_each_member() loop in the ops
> > > update but then going out of scope and in the exit path we only kfree
> > > the last tprogs.
> >
> > You're right, nice catch. Fixing it.
> 
> There is probably no need to do many allocations as well, just one
> outside of the loop and reuse?

Yeah moved it out of the loop and before we grab the mutex, returning
an -ENOMEM directly.

Thanks for noticing this. Sending v4 now.

- KP

> 
> >
> > - KP
> >
> > >
> > > > +           tprogs[BPF_TRAMP_FENTRY].progs[0] = prog;
> > > > +           tprogs[BPF_TRAMP_FENTRY].nr_progs = 1;
> > > >             err = arch_prepare_bpf_trampoline(image,
> > > >                                               st_map->image + PAGE_SIZE,
> > > >                                               &st_ops->func_models[i], 0,
> > > > -                                             &prog, 1, NULL, 0, NULL);
> > > > +                                             tprogs, NULL);
> > > >             if (err < 0)
> > > >                     goto reset_unlock;
> > > > @@ -469,6 +478,7 @@ static int bpf_struct_ops_map_update_elem(struct bpf_map *map, void *key,
> > > >     memset(uvalue, 0, map->value_size);
> > > >     memset(kvalue, 0, map->value_size);
> > > >   unlock:
> > > > +   kfree(tprogs);
> > > >     mutex_unlock(&st_map->lock);
> > > >     return err;
> > > >   }

  reply	other threads:[~2020-03-04 19:09 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-04 15:47 [PATCH bpf-next v3 0/7] Introduce BPF_MODIFY_RET tracing progs KP Singh
2020-03-04 15:47 ` [PATCH bpf-next v3 1/7] bpf: Refactor trampoline update code KP Singh
2020-03-04 18:37   ` Daniel Borkmann
2020-03-04 18:44     ` KP Singh
2020-03-04 18:47       ` Andrii Nakryiko
2020-03-04 19:08         ` KP Singh [this message]
2020-03-04 15:47 ` [PATCH bpf-next v3 2/7] bpf: JIT helpers for fmod_ret progs KP Singh
2020-03-04 15:47 ` [PATCH bpf-next v3 3/7] bpf: Introduce BPF_MODIFY_RETURN KP Singh
2020-03-04 15:47 ` [PATCH bpf-next v3 4/7] bpf: Attachment verification for BPF_MODIFY_RETURN KP Singh
2020-03-04 16:43   ` Casey Schaufler
2020-03-04 15:47 ` [PATCH bpf-next v3 5/7] tools/libbpf: Add support " KP Singh
2020-03-04 15:47 ` [PATCH bpf-next v3 6/7] bpf: Add test ops for BPF_PROG_TYPE_TRACING KP Singh
2020-03-04 15:47 ` [PATCH bpf-next v3 7/7] bpf: Add selftests for BPF_MODIFY_RETURN 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=20200304190855.GA31073@chromium.org \
    --to=kpsingh@chromium.org \
    --cc=andrii.nakryiko@gmail.com \
    --cc=andriin@fb.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=jackmanb@chromium.org \
    --cc=jannh@google.com \
    --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.