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=-16.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE, SPF_PASS autolearn=ham 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 B6A22C04FF3 for ; Mon, 24 May 2021 22:20:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8757E613D6 for ; Mon, 24 May 2021 22:20:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230048AbhEXWVd (ORCPT ); Mon, 24 May 2021 18:21:33 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:59061 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229989AbhEXWVc (ORCPT ); Mon, 24 May 2021 18:21:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1621894803; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=FfD6zZEHWPiEUO4rFdOhgqC1vo03POxorC+jg1EsxHQ=; b=MHEW/7oatwSysmnd/eVTOTMHZpSdHvA4e6uKVi6JQOmG/Rh5A9x6u8ynnN6cBvoNcZSBd+ 8KykWsFcfLG4V58h1Ydj6KYx0ONvbsvpduIM4NIJczERMxQEgz6u1LS+odESphgYzh9WCg UNhgvDAnh7GELPcPC+VMbWQ9IEVclCM= Received: from mail-ed1-f69.google.com (mail-ed1-f69.google.com [209.85.208.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-588-Su-ZsV_EMCeFeudaewTHmw-1; Mon, 24 May 2021 18:19:59 -0400 X-MC-Unique: Su-ZsV_EMCeFeudaewTHmw-1 Received: by mail-ed1-f69.google.com with SMTP id w22-20020a05640234d6b029038d04376b6aso16198711edc.21 for ; Mon, 24 May 2021 15:19:59 -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=FfD6zZEHWPiEUO4rFdOhgqC1vo03POxorC+jg1EsxHQ=; b=uNRReMw0FfQNdWO0ts/PxIC5Cfm360YB3rbE5TN5xvYr3PRd7hG9JkpOnN/O2S0agB HJXQKWOM6f2CZF0Y1PL/rmtZi+hQ/DkC3ZJ1CSRU2RKhP9Kjwx1aS23ETpR/ky0Qfd05 Gd9CLmAgugCN29FQkwyE7OJjpth8+hh7qntArZc7GTCwrtkf0Yu31dfJzcAnkKhkCUlD IkRWu6xr/n8zRmZrG1qO3PpWQhWCsv7B+v7u6AbPj2RkSiyxGbczLTY7J80v6KKBXewS JP3HXDKyYOtiYZ3SaawkjHOxixd365jRXQL8BULBD2Dz0b7nxG6O1Q1O59gaKsesjDmX r6Mg== X-Gm-Message-State: AOAM533avJ0k41RQRYk1NW732L2mpby/6kawfa5+KcXnzsBt1XDy9RWt V3RM68pUYTZUjfMmdMVrHqWRfk/ytrE05RJXmAGygLeHlTJaJv7z4C73NYamXdoqeI78ijnnhsO b7p4S4wDcXECp X-Received: by 2002:a17:906:aac8:: with SMTP id kt8mr24828639ejb.402.1621894798086; Mon, 24 May 2021 15:19:58 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxpK/3GwW8AYnSjPU1AGAReRiJ/qf1K1sCGlCfqe5J2OhdsIeBbGcDIMk5AJ6UswZfAxyNjJg== X-Received: by 2002:a17:906:aac8:: with SMTP id kt8mr24828595ejb.402.1621894797409; Mon, 24 May 2021 15:19:57 -0700 (PDT) Received: from alrua-x1.borgediget.toke.dk ([2a0c:4d80:42:443::2]) by smtp.gmail.com with ESMTPSA id a22sm9204800edu.39.2021.05.24.15.19.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 May 2021 15:19:56 -0700 (PDT) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 82523180275; Tue, 25 May 2021 00:19:49 +0200 (CEST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Andrii Nakryiko Cc: John Fastabend , Stanislav Fomichev , Andrii Nakryiko , bpf , Networking , Alexei Starovoitov , Daniel Borkmann , Kernel Team Subject: Re: [PATCH bpf-next 0/5] libbpf: error reporting changes for v1.0 In-Reply-To: References: <20210521234203.1283033-1-andrii@kernel.org> <60ab496e3e211_2a2cf208d2@john-XPS-13-9370.notmuch> <87a6ojzwdi.fsf@toke.dk> <87y2c3yfxm.fsf@toke.dk> X-Clacks-Overhead: GNU Terry Pratchett Date: Tue, 25 May 2021 00:19:49 +0200 Message-ID: <87sg2bydtm.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org Andrii Nakryiko writes: > On Mon, May 24, 2021 at 2:34 PM Toke H=C3=B8iland-J=C3=B8rgensen wrote: >> >> Andrii Nakryiko writes: >> >> > On Mon, May 24, 2021 at 1:53 PM Toke H=C3=B8iland-J=C3=B8rgensen wrote: >> >> >> >> Andrii Nakryiko writes: >> >> >> >> > On Sun, May 23, 2021 at 11:36 PM John Fastabend >> >> > wrote: >> >> >> >> >> >> Andrii Nakryiko wrote: >> >> >> > Implement error reporting changes discussed in "Libbpf: the road= to v1.0" >> >> >> > ([0]) document. >> >> >> > >> >> >> > Libbpf gets a new API, libbpf_set_strict_mode() which accepts a = set of flags >> >> >> > that turn on a set of libbpf 1.0 changes, that might be potentia= lly breaking. >> >> >> > It's possible to opt-in into all current and future 1.0 features= by specifying >> >> >> > LIBBPF_STRICT_ALL flag. >> >> >> > >> >> >> > When some of the 1.0 "features" are requested, libbpf APIs might= behave >> >> >> > differently. In this patch set a first set of changes are implem= ented, all >> >> >> > related to the way libbpf returns errors. See individual patches= for details. >> >> >> > >> >> >> > Patch #1 adds a no-op libbpf_set_strict_mode() functionality to = enable >> >> >> > updating selftests. >> >> >> > >> >> >> > Patch #2 gets rid of all the bad code patterns that will break i= n libbpf 1.0 >> >> >> > (exact -1 comparison for low-level APIs, direct IS_ERR() macro u= sage to check >> >> >> > pointer-returning APIs for error, etc). These changes make selft= est work in >> >> >> > both legacy and 1.0 libbpf modes. Selftests also opt-in into 100= % libbpf 1.0 >> >> >> > mode to automatically gain all the subsequent changes, which wil= l come in >> >> >> > follow up patches. >> >> >> > >> >> >> > Patch #3 streamlines error reporting for low-level APIs wrapping= bpf() syscall. >> >> >> > >> >> >> > Patch #4 streamlines errors for all the rest APIs. >> >> >> > >> >> >> > Patch #5 ensures that BPF skeletons propagate errors properly as= well, as >> >> >> > currently on error some APIs will return NULL with no way of che= cking exact >> >> >> > error code. >> >> >> > >> >> >> > [0] https://docs.google.com/document/d/1UyjTZuPFWiPFyKk1tV5an1= 1_iaRuec6U-ZESZ54nNTY >> >> >> > >> >> >> > Andrii Nakryiko (5): >> >> >> > libbpf: add libbpf_set_strict_mode() API to turn on libbpf 1.0 >> >> >> > behaviors >> >> >> > selftests/bpf: turn on libbpf 1.0 mode and fix all IS_ERR chec= ks >> >> >> > libbpf: streamline error reporting for low-level APIs >> >> >> > libbpf: streamline error reporting for high-level APIs >> >> >> > bpftool: set errno on skeleton failures and propagate errors >> >> >> > >> >> >> >> >> >> LGTM for the series, >> >> >> >> >> >> Acked-by: John Fastabend >> >> > >> >> > Thanks, John! >> >> > >> >> > Toke, Stanislav, you cared about these aspects of libbpf 1.0 (by >> >> > commenting on the doc itself), do you mind also taking a brief look >> >> > and letting me know if this works for your use cases? Thanks! >> >> >> >> Changes LGTM: >> >> >> >> Acked-by: Toke H=C3=B8iland-J=C3=B8rgensen >> >> >> >> As a side note, the series seems to have been chopped up into individ= ual >> >> emails with no threading; was a bit weird that I had to go hunting for >> >> the individual patches in my mailbox... >> >> >> > >> > That's my bad, I messed up and sent them individually and probably >> > that's why they weren't threaded properly. >> >> Right, OK, I'll stop looking for bugs on my end, then :) >> >> BTW, one more thing that just came to mind: since that gdoc is not >> likely to be around forever, would it be useful to make the reference in >> the commit message(s) point to something more stable? IDK what that >> shoul be, really. Maybe just pasting (an abbreviated outline of?) the >> text in the document into the cover letter / merge commit could work? > > I was hoping Google won't deprecate Google Docs any time soon and I > had no intention to remove that document. But I was also thinking to > start wiki page at github.com/libbpf/libbpf with migration > instructions, so once that is up and running I can link that from > libbpf_set_strict_mode() doc comment. Right, that sounds reasonable :) > But I'd like to avoid blocking on that. Understandable; but just pasting an outline into the commit message (and keeping the link) could work in the meantime? -Toke