From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 87E3CCA9ECB for ; Thu, 31 Oct 2019 17:43:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5FCB2208E3 for ; Thu, 31 Oct 2019 17:43:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="SpUWcPHz" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728837AbfJaRnt (ORCPT ); Thu, 31 Oct 2019 13:43:49 -0400 Received: from mail-qk1-f194.google.com ([209.85.222.194]:41810 "EHLO mail-qk1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728561AbfJaRns (ORCPT ); Thu, 31 Oct 2019 13:43:48 -0400 Received: by mail-qk1-f194.google.com with SMTP id m125so7865971qkd.8; Thu, 31 Oct 2019 10:43:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=u8oevFSkFa644ahK7KMD169VA8J9aujIwgv9sqolFwY=; b=SpUWcPHzQBnSzNDN2NMkT5dCbazUFcOZzisSQhIFX/HyML/hCtqgQgxgItDCRlkliw HQvcaRN18hvsLMFodlxXrw/b7qYKYQJf5WZz72aWocAabuSB9FCqdxouTC4IcwdsJIu1 UCncNX4Qq80yu3BQwwaG+/6YuDPLiEs13eBnQG1DQBTeAt52ibYbCLnrmUkC5c/S2Anq NVNg3qZqWP5nq95RKnq760b/F0SZu+i9CqzNiQTT9d6V4ZfX0ZfZsQFx9UwSb+K7SILM MJFJ4YAiIFjw0uIQ63TvV9nrlM/sdvq3WKpXzOY0x/FJSMeLecgjYTYuI8ZAZEI0X/q9 TDvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=u8oevFSkFa644ahK7KMD169VA8J9aujIwgv9sqolFwY=; b=jhQL17GFczbgl4i3QyAhO6HEsOfrVvqmf8VzpvQoxvtE0cDgcZzJ1omMNMMIOYu5G/ O5thE/Z6Rn5P0XlOktJtpEBmjA7eDG5NGsiVibBspAEWd4yDufzrEAVE2VdTDIp/LiEm fqZw9Qp+OvpX+5MeAuyKSEP9UkR52AhxD56G6y3kwAaAQTtlh7OrLXPcbbrEBAkXfs7M 6aLlKzTj7/XetS9iaYIS3ZOds8SUj4+ZfyQ65MPwTRUPlBodd1YrD0ebmpuUo+Z9EafD 7GVXXilligC0bxzwQt30O5Mn8k8DMBm78ojUp2+9hzrYOI+NIRos/acFeUCylmTIswir eA6A== X-Gm-Message-State: APjAAAVRTclsyAmxL6jJ6DxvzPDVXG+SwAYX3rPQoCjco16bQVY1BqIl r3A68jXokSgELNrkwpiE8iMaF7/A1ilimBRwfJI= X-Google-Smtp-Source: APXvYqxNynYFdnrO16j//tOAgyfq0Hxp0Uia96Yq1TZDzXAYtnQO5tyM1xkkpHikOJQqcT3uoL4X2qumTTOp2k8965U= X-Received: by 2002:a37:4c13:: with SMTP id z19mr1617922qka.449.1572543827485; Thu, 31 Oct 2019 10:43:47 -0700 (PDT) MIME-Version: 1.0 References: <157237796219.169521.2129132883251452764.stgit@toke.dk> <157237796448.169521.1399805620810530569.stgit@toke.dk> <8736f8om96.fsf@toke.dk> In-Reply-To: <8736f8om96.fsf@toke.dk> From: Andrii Nakryiko Date: Thu, 31 Oct 2019 10:43:36 -0700 Message-ID: Subject: Re: [PATCH bpf-next v4 2/5] libbpf: Store map pin path and status in struct bpf_map To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: Daniel Borkmann , Alexei Starovoitov , Martin KaFai Lau , Song Liu , Yonghong Song , Jesper Dangaard Brouer , David Miller , Networking , bpf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Thu, Oct 31, 2019 at 10:31 AM Toke H=C3=B8iland-J=C3=B8rgensen wrote: > > Andrii Nakryiko writes: > > > [...] > > > >> > >> return err; > >> @@ -4131,17 +4205,24 @@ int bpf_object__unpin_maps(struct bpf_object *= obj, const char *path) > >> return -ENOENT; > >> > >> bpf_object__for_each_map(map, obj) { > >> + char *pin_path =3D NULL; > >> char buf[PATH_MAX]; > > > > you can call buf as pin_path and get rid of extra pointer? > > The idea here is to end up with bpf_map__unpin(map, NULL) if path is > unset. GCC complains if I reassign a static array pointer, so don't > think I can actually get rid of this? oh, right, it's nullable pointer, then you do need buf and pin_path, never mind. I keep forgetting this NULL semantics for pin/unpin :) > > -Toke