bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Martynas Pumputis <m@lambda.lt>
To: John Fastabend <john.fastabend@gmail.com>, bpf@vger.kernel.org
Cc: ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org
Subject: Re: [PATCH bpf 1/2] libbpf: fix removal of inner map in bpf_object__create_map
Date: Thu, 15 Jul 2021 12:06:53 +0200	[thread overview]
Message-ID: <f3aff467-7dbb-5aed-d3f8-32af62bcc53f@lambda.lt> (raw)
In-Reply-To: <60ef818f81c18_5a0c120898@john-XPS-13-9370.notmuch>



On 7/15/21 2:30 AM, John Fastabend wrote:
> Martynas Pumputis wrote:
>> If creating an outer map of a BTF-defined map-in-map fails (via
>> bpf_object__create_map()), then the previously created its inner map
>> won't be destroyed.
>>
>> Fix this by ensuring that the destroy routines are not bypassed in the
>> case of a failure.
>>
>> Fixes: 646f02ffdd49c ("libbpf: Add BTF-defined map-in-map support")
>> Reported-by: Andrii Nakryiko <andrii@kernel.org>
>> Signed-off-by: Martynas Pumputis <m@lambda.lt>
>> ---
>>   tools/lib/bpf/libbpf.c | 5 +++--
>>   1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
>> index 6f5e2757bb3c..1a840e81ea0a 100644
>> --- a/tools/lib/bpf/libbpf.c
>> +++ b/tools/lib/bpf/libbpf.c
>> @@ -4479,6 +4479,7 @@ static int bpf_object__create_map(struct bpf_object *obj, struct bpf_map *map, b
>>   {
>>   	struct bpf_create_map_attr create_attr;
>>   	struct bpf_map_def *def = &map->def;
>> +	int ret = 0;
>>   
>>   	memset(&create_attr, 0, sizeof(create_attr));
>>   
>> @@ -4561,7 +4562,7 @@ static int bpf_object__create_map(struct bpf_object *obj, struct bpf_map *map, b
>>   	}
>>   
>>   	if (map->fd < 0)
>> -		return -errno;
>> +		ret = -errno;
>>   
> 
> I'm trying to track this down, not being overly familiar with this bit of
> code.
> 
> We entered bpf_object__create_map with map->inner_map potentially set and
> then here we are going to zfree(&map->inner_map). I'm trying to track
> down if this is problematic, I guess not? But seems like we could
> also free a map here that we didn't create from this call in the above
> logic.
> 

Keep in mind that we free the inner map anyway if the creation of the 
outer map was successful. Also, we don't try to recreate the map if any 
of the steps has failed. So I think it should not be problematic.


>>   	if (bpf_map_type__is_map_in_map(def->type) && map->inner_map) {
> 
>          if (bpf_map_type__is_map_in_map(def->type) && map->inner_map) {
>                  if (obj->gen_loader)
>                          map->inner_map->fd = -1;
>                  bpf_map__destroy(map->inner_map);
>                  zfree(&map->inner_map);
>          }
> 
> 
> Also not sure here, sorry didn't have time to follow too thoroughly
> will check again later. But, the 'map->inner_map->fd = -1' is going to
> cause bpf_map__destroy to bypass the close(fd) as I understand it.
> So are we leaking an fd if the inner_map->fd is coming from above
> create? Or maybe never happens because obj->gen_loader is NULL?

I think in the case of obj->gen_loader, we don't need to close the FD of 
any map, as the creation of maps will happen at a later stage in the 
kernel: 
https://lore.kernel.org/bpf/20210514003623.28033-15-alexei.starovoitov@gmail.com/.

> 
> Thanks!
> 
> 
>>   		if (obj->gen_loader)
>> @@ -4570,7 +4571,7 @@ static int bpf_object__create_map(struct bpf_object *obj, struct bpf_map *map, b
>>   		zfree(&map->inner_map);
>>   	}
>>   
>> -	return 0;
>> +	return ret;
>>   }
>>   
>>   static int init_map_slots(struct bpf_object *obj, struct bpf_map *map)
>> -- 
>> 2.32.0
>>
> 
> 

  reply	other threads:[~2021-07-15 10:04 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-14 16:54 [PATCH bpf 0/2] libbpf: fix inner map removal in bpf_object__create_map Martynas Pumputis
2021-07-14 16:54 ` [PATCH bpf 1/2] libbpf: fix removal of inner map " Martynas Pumputis
2021-07-15  0:30   ` John Fastabend
2021-07-15 10:06     ` Martynas Pumputis [this message]
2021-07-15 19:59       ` John Fastabend
2021-07-16  3:06         ` John Fastabend
2021-07-16  3:09   ` John Fastabend
2021-07-16  5:27   ` Andrii Nakryiko
2021-07-16 15:24     ` Martynas Pumputis
2021-07-14 16:54 ` [PATCH bpf 2/2] selftests/bpf: check inner map deletion Martynas Pumputis
2021-07-16  3:11   ` John Fastabend
2021-07-16  5:35   ` Andrii Nakryiko
2021-07-16 15:09     ` Martynas Pumputis
2021-07-16 18:24       ` Andrii Nakryiko
2021-07-19 17:38 [PATCH v2 bpf 0/2] libbpf: fix inner map removal in bpf_object__create_map Martynas Pumputis
2021-07-19 17:38 ` [PATCH bpf 1/2] libbpf: fix removal of inner map " Martynas Pumputis
2021-07-19 22:58   ` Andrii Nakryiko

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=f3aff467-7dbb-5aed-d3f8-32af62bcc53f@lambda.lt \
    --to=m@lambda.lt \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=john.fastabend@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;
as well as URLs for NNTP newsgroup(s).