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=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 F1066CA9ED0 for ; Fri, 1 Nov 2019 21:41:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C25EF2067D for ; Fri, 1 Nov 2019 21:41:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727025AbfKAVll convert rfc822-to-8bit (ORCPT ); Fri, 1 Nov 2019 17:41:41 -0400 Received: from mx1.redhat.com ([209.132.183.28]:60870 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725989AbfKAVlk (ORCPT ); Fri, 1 Nov 2019 17:41:40 -0400 Received: from mail-lj1-f197.google.com (mail-lj1-f197.google.com [209.85.208.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3095583F3C for ; Fri, 1 Nov 2019 21:41:40 +0000 (UTC) Received: by mail-lj1-f197.google.com with SMTP id o21so2026506ljj.23 for ; Fri, 01 Nov 2019 14:41:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version:content-transfer-encoding; bh=fjcnPmrQoA0PCrDaD/leSIuSuHVONcL18GmYVzheyO8=; b=W6cqyy5kdmp2X8GQpj+tLmw0QHD4kHbbGztB+SeAcBBP2Y2o7nhEjZ7eMGlc8jDd04 QngQ8KeEHpll7jtSE1VN8B/64Vu3hgN5F6rYYnfrE8piUgaB8EJ+9Bb/ohKtYkSgRCPX wFaikwXAR5dOTis+7DuSTM1V0bm2jCjf+pmzeGljzhG8F+8JlDiuGPmTaYtr9+I4Zo6U QLNpPGkK6A9lt3hCBmCEXbblbN/ZRqxAeQDPWijSyiTZJG5umt2nxdT8ACzgjFuzmUM6 QV0gmT59RIMqn+8rXIA7Y35ZTJPgWB6qtEokPY1jFuqo9zwJzapj9Yo1EQHroZyUct2U gYHA== X-Gm-Message-State: APjAAAXQGsx0juwtXwT7UkZDIbIhm4L/NdUvZWlKWGv1sJBX6k0RsA+/ rspiFwBvY7J9pj64BXvCQ3mFiLGUjTvh7/lrCOgozd0sSU+qi3UcF51gurmdROfUfPJD7cjPoty mZaAk+Jy1Rj7c X-Received: by 2002:a19:8196:: with SMTP id c144mr8321995lfd.129.1572644497846; Fri, 01 Nov 2019 14:41:37 -0700 (PDT) X-Google-Smtp-Source: APXvYqyNr7cebB4cE4Ajj3mY+WhWx7IhirEPQE1ymGG/2jXclx6VS4tBzt/IEOi4pxX5u6iAdx7WOA== X-Received: by 2002:a19:8196:: with SMTP id c144mr8321975lfd.129.1572644497609; Fri, 01 Nov 2019 14:41:37 -0700 (PDT) Received: from alrua-x1.borgediget.toke.dk ([2a00:7660:6da:443::2]) by smtp.gmail.com with ESMTPSA id z17sm2336835ljm.16.2019.11.01.14.41.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 Nov 2019 14:41:36 -0700 (PDT) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id A27D41818B5; Fri, 1 Nov 2019 22:41:35 +0100 (CET) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Alexei Starovoitov Cc: Jiri Olsa , =?utf-8?B?QmrDtnJuIFTDtnBlbA==?= , Magnus Karlsson , Magnus Karlsson , =?utf-8?B?QmrDtnJuIFTDtnBl?= =?utf-8?B?bA==?= , Alexei Starovoitov , Daniel Borkmann , Network Development , Jonathan Lemon , bpf , degeneloy@gmail.com, John Fastabend Subject: Re: [PATCH bpf-next v3] libbpf: fix compatibility for kernels without need_wakeup In-Reply-To: References: <87lft1ngtn.fsf@toke.dk> <87imo5ng7w.fsf@toke.dk> <87d0ednf0t.fsf@toke.dk> <20191031174208.GC2794@krava> <20191031191815.GD2794@krava> <20191101072707.GE2794@krava> <87bltvmlsr.fsf@toke.dk> X-Clacks-Overhead: GNU Terry Pratchett Date: Fri, 01 Nov 2019 22:41:35 +0100 Message-ID: <878sozmfzk.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org Alexei Starovoitov writes: > On Fri, Nov 1, 2019 at 12:36 PM Toke Høiland-Jørgensen wrote: >> >> Alexei Starovoitov writes: >> >> > On Fri, Nov 1, 2019 at 12:27 AM Jiri Olsa wrote: >> >> >> >> On Thu, Oct 31, 2019 at 01:39:12PM -0700, Alexei Starovoitov wrote: >> >> > On Thu, Oct 31, 2019 at 12:18 PM Jiri Olsa wrote: >> >> > > > >> >> > > > yes. older vmlinux and newer installed libbpf.so >> >> > > > or any version of libbpf.a that is statically linked into apps >> >> > > > is something that libbpf code has to support. >> >> > > > The server can be rebooted into older than libbpf kernel and >> >> > > > into newer than libbpf kernel. libbpf has to recognize all these >> >> > > > combinations and work appropriately. >> >> > > > That's what backward and forward compatibility is. >> >> > > > That's what makes libbpf so difficult to test, develop and code review. >> >> > > > What that particular server has in /usr/include is irrelevant. >> >> > > >> >> > > sure, anyway we can't compile following: >> >> > > >> >> > > tredaell@aldebaran ~ $ echo "#include " | gcc -x c - >> >> > > In file included from :1: >> >> > > /usr/include/bpf/xsk.h: In function ‘xsk_ring_prod__needs_wakeup’: >> >> > > /usr/include/bpf/xsk.h:82:21: error: ‘XDP_RING_NEED_WAKEUP’ undeclared (first use in this function) >> >> > > 82 | return *r->flags & XDP_RING_NEED_WAKEUP; >> >> > > ... >> >> > > >> >> > > XDP_RING_NEED_WAKEUP is defined in kernel v5.4-rc1 (77cd0d7b3f257fd0e3096b4fdcff1a7d38e99e10). >> >> > > XSK_UNALIGNED_BUF_ADDR_MASK and XSK_UNALIGNED_BUF_OFFSET_SHIFT are defined in kernel v5.4-rc1 (c05cd3645814724bdeb32a2b4d953b12bdea5f8c). >> >> > > >> >> > > with: >> >> > > kernel-headers-5.3.6-300.fc31.x86_64 >> >> > > libbpf-0.0.5-1.fc31.x86_64 >> >> > > >> >> > > if you're saying this is not supported, I guess we could be postponing >> >> > > libbpf rpm releases until we have the related fedora kernel released >> >> > >> >> > why? github/libbpf is the source of truth for building packages >> >> > and afaik it builds fine. >> >> >> >> because we will get issues like above if there's no kernel >> >> avilable that we could compile libbpf against >> > >> > what is the issue again? >> > bpf-next builds fine. github/libbpf builds fine. >> > If distro is doing something else it's distro's mistake. >> >> With that you're saying that distros should always keep their kernel >> headers and libbpf version in sync. Which is fine in itself; they can >> certainly do that. > > No. I'm not suggesting that. > distro is free to package whatever /usr/include headers. > kernel version is often != /usr/include headers I did say kernel *headers*. By which I mean the files in /usr/include. E.g., on my machine: $ pacman -Qo /usr/include/linux/if_xdp.h /usr/include/linux/if_xdp.h is owned by linux-api-headers 5.3.1-1 >> The only concern with this is that without a flow of bugfixes into the >> 'bpf' tree (and stable), users may end up with buggy versions of libbpf. >> Which is in no one's interest. So how do we avoid that? > > As I explained earlier. There is no 'bpf' tree for libbpf. It always > moves forward. Yes, you did. And I was just pointing out that this means that there will be no bug fixes in older versions. So the only way to update is to move to an entirely new version of libbpf, including updating all the headers in /usr/include. And when that is not feasible, then the only choice left is to ship a buggy libbpf... Unless you have a third option I'm missing? -Toke