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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7C179C433FE for ; Thu, 18 Nov 2021 20:30:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5E84D6128A for ; Thu, 18 Nov 2021 20:30:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230330AbhKRUc7 (ORCPT ); Thu, 18 Nov 2021 15:32:59 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42756 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229633AbhKRUc6 (ORCPT ); Thu, 18 Nov 2021 15:32:58 -0500 Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E0F00C061574 for ; Thu, 18 Nov 2021 12:29:57 -0800 (PST) Received: by mail-io1-xd2f.google.com with SMTP id 14so9730591ioe.2 for ; Thu, 18 Nov 2021 12:29:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yYt9/X+O3xwYmGyId9geOmyLFTgYSAl9UI0lqAAeF2k=; b=m5TEvsbxfBqQIb4tuD1f9/ZQ/7VmLTi9LbQFAllDlm/owT7miVsSXeVo64hP8FIeQR V5NxSG79XVDiOF7sAjpdDapSyAMaEx/jt78R+foIWa/b24yKfPQYs4Xe9IFMoefi4h/u VlTqhy3XhsWa3G1brbYr2E7mlv0o4cFLqsrhE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yYt9/X+O3xwYmGyId9geOmyLFTgYSAl9UI0lqAAeF2k=; b=mN9HXNi2q/4b0PaeigJgA8g+1HDtOoMBA77USbwtLPbKZQ71nuNQIDzklY0z/AYjs7 ZAYI1szU557iy3bFSLQ3CsJA7drXTKs++3irohaLysiYFLuMr8p0fiMrUgL7GGT6A1lg MtD47OUp/U3MO0JAND33iidujm9h1q+eeSJbOx02UJYi+iddYV0dBoy8tHArr6tHyWJw 8dhw/2w9KFnOU/8kME0VpJ9I4cmhMkgSz7WlGNsK6h1jQwpCLiT6uzzl919ntKgwue7C gugQXJgidCGsIU8O8c1uyoyEnveN2r5O0Aay9rvfd7YclOf8yP/xvsH83n9vynP5Yssr R2sQ== X-Gm-Message-State: AOAM532BcGEAz3VelyfL6i4xtFTsYCeFwKeSOBRy7sq90r5MG68UmIiA Uf39OXmZ8R6eSXWLLtQD5EFGS9mJKeBeXA5rl69Q0w== X-Google-Smtp-Source: ABdhPJzqpDhtem1HFVcS+EX78SHgn/oe6Rjax3EXhJ9Dq0IVlb5JcMUMdq2kJKmgClqwuZFcoVM4tRItcT5u/xOKfwc= X-Received: by 2002:a02:864b:: with SMTP id e69mr22200390jai.9.1637267397355; Thu, 18 Nov 2021 12:29:57 -0800 (PST) MIME-Version: 1.0 References: <20211118103335.1208372-1-revest@chromium.org> In-Reply-To: From: Florent Revest Date: Thu, 18 Nov 2021 21:29:46 +0100 Message-ID: Subject: Re: [PATCH bpf-next] libbpf: Add ability to clear per-program load flags To: Andrii Nakryiko Cc: bpf , Andrii Nakryiko , KP Singh , Brendan Jackman , open list Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 18, 2021 at 6:49 PM Andrii Nakryiko wrote: > > On Thu, Nov 18, 2021 at 2:33 AM Florent Revest wrote: > > > > We have a use-case where we construct a skeleton with a sleepable > > program and if it fails to load then we want to make it non-sleepable by > > clearing BPF_F_SLEEPABLE. > > I'd say the better way to do this is to have two programs (that share > the logic, of course) and pick one or another at runtime: > > static int whatever_logic(bool sleepable) { ... } > > SEC("fentry.s/whatever") > int BPF_PROG(whatever_sleepable, ...) > { > return whatever_logic(true); > } > > SEC("fentry/whatever") > int BPF_PROG(whatever_nonsleepable, ...) > { > return whatever_logic(false); > } > > > Then at runtime you can bpf_program__autoload(..., false) for a > variant you don't want to load. Ah cool, thanks! That's a good idea :) it will also look cleaner. > This clear_flags business seems too low-level and too limited. Next > thing we'll be adding a few more bit manipulation variants (e.g, reset > flags). Let's see how far you can get with the use of existing > features. I'd set_extra_flags() to be almost never used, btw. And they > shouldn't, if can be avoided. So I'm hesitant to keep extending > operations around prog_flags. I agree > But given we just added set_extra_flags() and it's already too > limiting, let's change set_extra flags to just set_flags() that will > override the flags with whatever user provides. Then with > bpf_program__flags() and bpf_program__set_flags() you can express > whatever you want without adding extra APIs. Care to fix that? Sure, I'll send a patch for this! :)