From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jakub Kicinski Subject: Re: [PATCH bpf-next 2/3] libbpf: cleanup after partial failure in bpf_object__pin Date: Wed, 7 Nov 2018 15:38:25 -0800 Message-ID: <20181107153825.5d3d5d15@cakuba.netronome.com> References: <20181107224356.73080-1-sdf@google.com> <20181107224356.73080-3-sdf@google.com> <20181107145648.66f47037@cakuba.netronome.com> <20181107230021.4yr2h6fpzhvarfcj@mini-arch> <20181107150605.59a8ac1c@cakuba.netronome.com> <20181107232516.qiy24ccbq3hh4ail@mini-arch> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Stanislav Fomichev , netdev@vger.kernel.org, linux-kselftest@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net, shuah@kernel.org, quentin.monnet@netronome.com, guro@fb.com, jiong.wang@netronome.com, bhole_prashant_q7@lab.ntt.co.jp, john.fastabend@gmail.com, jbenc@redhat.com, treeze.taeung@gmail.com, yhs@fb.com, osk@fb.com, sandipan@linux.vnet.ibm.com To: Stanislav Fomichev Return-path: Received: from mail-pg1-f195.google.com ([209.85.215.195]:43271 "EHLO mail-pg1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727591AbeKHJLL (ORCPT ); Thu, 8 Nov 2018 04:11:11 -0500 Received: by mail-pg1-f195.google.com with SMTP id n10-v6so7979672pgv.10 for ; Wed, 07 Nov 2018 15:38:29 -0800 (PST) In-Reply-To: <20181107232516.qiy24ccbq3hh4ail@mini-arch> Sender: netdev-owner@vger.kernel.org List-ID: On Wed, 7 Nov 2018 15:25:16 -0800, Stanislav Fomichev wrote: > On 11/07, Jakub Kicinski wrote: > > On Wed, 7 Nov 2018 15:00:21 -0800, Stanislav Fomichev wrote: > > > > > +err_unpin_programs: > > > > > + bpf_object__for_each_program(prog, obj) { > > > > > + char buf[PATH_MAX]; > > > > > + int len; > > > > > + > > > > > + len = snprintf(buf, PATH_MAX, "%s/%s", path, > > > > > + prog->section_name); > > > > > + if (len < 0) > > > > > + continue; > > > > > + else if (len >= PATH_MAX) > > > > > + continue; > > > > > + > > > > > + unlink(buf); > > > > > > > > I think that's no bueno, if pin failed because the file already exists > > > > you'll now remove that already existing file. > > > > > > How about we check beforehand and bail early if we are going to > > > overwrite something? > > > > Possible, although the most common way to handle situation like this in > > the kernel is to "continue the iteration in reverse" over the list. > > I.e. walk the list back. I think the objects are on a double linked > > list. You may need to add the appropriate foreach macro and helper.. > > That sounds more complicated than just ensuring that the top directory > for the pins doesn't exist and then rm -rf it on failure. Why would we require that the directory does not exist? We can check if it exists and then either create or just pin all in an existing one. I don't think it should be that much effort to write a reverse for loop - it could actually be less LoC than that rm_rf function :) > I'm thinking about copy-pasting rm_rf from perf > (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/perf/util/util.c#n119). > Thoughts? > > Btw, current patch won't work because of those /0 added by bpf_program__pin.