linux-kernel - [PATCH bpf-next v2 0/1] Document kfunc lifecycle / stability expectations

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Thu,  2 Feb 2023 16:35:56 -0600
From:   David Vernet <void@...ifault.com>
To:     bpf@...r.kernel.org
Cc:     ast@...nel.org, daniel@...earbox.net, andrii@...nel.org,
        martin.lau@...ux.dev, song@...nel.org, yhs@...a.com,
        john.fastabend@...il.com, kpsingh@...nel.org, sdf@...gle.com,
        haoluo@...gle.com, jolsa@...nel.org, linux-kernel@...r.kernel.org,
        kernel-team@...a.com, toke@...hat.com, brouer@...hat.com,
        corbet@....net, linux-doc@...r.kernel.org
Subject: [PATCH bpf-next v2 0/1] Document kfunc lifecycle / stability expectations

This is the v2 of the proposal for documenting BPF kfunc lifecycle and
stability. v1 of this proposal can be found in [0]. As [0] indicates,
Toke has also provided several RFC proposals, the most recent of which
is can be found in [1].

Much of this proposal is based on Toke's prior patches on this topic,
and group discussions at BPF office hours. Anyone who participated
in either prior proposals for kfunc lifecycle / stability documentation,
or in BPF office-hour discussions, may feel free to submit
Co-developed-by tags in place of Acked-by, Reviewed-by, etc.

Changelog
---------
v1 -> v2:
- Move some of the main points of the arguments around. v1 underscored
  quite strongly that kfuncs don't have _any_ stability guarantees.
  While true, it may scare away users who misinterpret the implications
  of that to mean that things will change wildly and at any time.
  Reframe the general flow of the section to still be clear that no
  stability is guaranteed, but front-load the content that clarifies why
  this isn't necessarily something to be afraid of (Toke, Daniel, and
  others).
- Add a paragraph explaining that out-of-tree BPF programs that use
  kfuncs are relevant to discussions surrounding whether kfuncs should
  be modified or removed. While the onus is on kfunc users to explicitly
  engage with the upstream community to let them know which kfuncs
  they're using and why they're useful, the added paragraph also makes
  it clear that the BPF community will in turn participate in upstream
  discussions to ensure that such users aren't equated with out-of-tree
  module users and outright ignored. Also make it clear that our hope is
  that BPF programs will be upstreamed on a more regular basis (Toke,
  Daniel, and others).
- Remove patches that add KF_DEPRECATED flag to <linux/btf.h>. They'll
  remain in the documentation for now, and will be merged at a later
  time when it's actually a useful signal for developers (Alexei).

[0]: https://lore.kernel.org/all/20230202163056.658641-1-void@manifault.com/
[1]: https://lore.kernel.org/all/20230201174449.94650-1-toke@redhat.com/

David Vernet (1):
  bpf/docs: Document kfunc lifecycle / stability expectations

 Documentation/bpf/kfuncs.rst | 139 +++++++++++++++++++++++++++++++++--
 1 file changed, 134 insertions(+), 5 deletions(-)

-- 
2.39.0