Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932831AbbERUhH (ORCPT ); Mon, 18 May 2015 16:37:07 -0400 Received: from mail.kernel.org ([198.145.29.136]:35220 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932359AbbERUhE (ORCPT ); Mon, 18 May 2015 16:37:04 -0400 Date: Mon, 18 May 2015 17:37:00 -0300 From: Arnaldo Carvalho de Melo To: Alexei Starovoitov Cc: Wang Nan , paulus@samba.org, a.p.zijlstra@chello.nl, mingo@redhat.com, namhyung@kernel.org, jolsa@kernel.org, dsahern@gmail.com, daniel@iogearbox.net, brendan.d.gregg@gmail.com, masami.hiramatsu.pt@hitachi.com, lizefan@huawei.com, linux-kernel@vger.kernel.org, pi3orama@163.com Subject: Re: [RFC PATCH v3 21/37] bpf tools: Create eBPF maps defined in an object file Message-ID: <20150518203700.GH18563@kernel.org> References: <1431860222-61636-1-git-send-email-wangnan0@huawei.com> <1431860222-61636-22-git-send-email-wangnan0@huawei.com> <555A3419.4040207@plumgrid.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <555A3419.4040207@plumgrid.com> X-Url: http://acmel.wordpress.com User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1833 Lines: 51 Em Mon, May 18, 2015 at 11:48:57AM -0700, Alexei Starovoitov escreveu: > On 5/17/15 3:56 AM, Wang Nan wrote: > >This patch creates maps based on 'map' section in object file using > >bpf_create_map(), and store the fds into an array in > >'struct bpf_object'. Since the byte order of the object may differ > >from the host, swap map definition before processing. > > > >This is the first patch in 'loading' phase. Previous patches parse ELF > >object file and create needed data structure, but doesnnt play with > >kernel. They belong to 'opening' phase. > > > >Signed-off-by: Wang Nan > ... > >+ for (j = 0; j < i; j++) { > >+ close(obj->maps_fds[j]); > >+ obj->maps_fds[j] = -1; > > this line is unnecessary, since you're freeing the whole array > at the line below: I guess this is kinda of a zfree() that he wants to achieve, i.e. if a bug creeps in that makes some code use the deleted maps_fds, he rather wants it to access a -1 fd than an some reused fd, no? > >+ } > >+ free(obj->maps_fds); > >+ obj->maps_fds = NULL; > > ... > > > void bpf_close_object(struct bpf_object *obj) > > { > > if (!obj) > > return; > > > > bpf_obj_clear_elf(obj); > >+ bpf_unload_object(obj); > > just realized that this API keeps elf file open for the whole > life time. I think that should be split up. > bpf_open_object() can do elf parsing, creation of maps and > bpf loading. > bpf_close_object() can unload programs, maps. That's fine, > but closing of elf file and freeing memory associated > with parsing sections should be a separate call. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/