^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1) =================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 2) HOWTO interact with BPF subsystem
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 3) =================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 4)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 5) This document provides information for the BPF subsystem about various
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 6) workflows related to reporting bugs, submitting patches, and queueing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 7) patches for stable kernels.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 8)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 9) For general information about submitting patches, please refer to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10) `Documentation/process/`_. This document only describes additional specifics
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11) related to BPF.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13) .. contents::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14) :local:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15) :depth: 2
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17) Reporting bugs
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18) ==============
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20) Q: How do I report bugs for BPF kernel code?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21) --------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22) A: Since all BPF kernel development as well as bpftool and iproute2 BPF
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23) loader development happens through the bpf kernel mailing list,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24) please report any found issues around BPF to the following mailing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25) list:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27) bpf@vger.kernel.org
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29) This may also include issues related to XDP, BPF tracing, etc.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31) Given netdev has a high volume of traffic, please also add the BPF
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32) maintainers to Cc (from kernel MAINTAINERS_ file):
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 33)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 34) * Alexei Starovoitov <ast@kernel.org>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 35) * Daniel Borkmann <daniel@iogearbox.net>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 36)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 37) In case a buggy commit has already been identified, make sure to keep
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 38) the actual commit authors in Cc as well for the report. They can
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 39) typically be identified through the kernel's git tree.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 40)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 41) **Please do NOT report BPF issues to bugzilla.kernel.org since it
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 42) is a guarantee that the reported issue will be overlooked.**
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 43)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 44) Submitting patches
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 45) ==================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 46)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 47) Q: To which mailing list do I need to submit my BPF patches?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 48) ------------------------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 49) A: Please submit your BPF patches to the bpf kernel mailing list:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 50)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 51) bpf@vger.kernel.org
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 52)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 53) In case your patch has changes in various different subsystems (e.g.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 54) networking, tracing, security, etc), make sure to Cc the related kernel mailing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 55) lists and maintainers from there as well, so they are able to review
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 56) the changes and provide their Acked-by's to the patches.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 57)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 58) Q: Where can I find patches currently under discussion for BPF subsystem?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 59) -------------------------------------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 60) A: All patches that are Cc'ed to netdev are queued for review under netdev
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 61) patchwork project:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 62)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 63) https://patchwork.kernel.org/project/netdevbpf/list/
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 64)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 65) Those patches which target BPF, are assigned to a 'bpf' delegate for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 66) further processing from BPF maintainers. The current queue with
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 67) patches under review can be found at:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 68)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 69) https://patchwork.kernel.org/project/netdevbpf/list/?delegate=121173
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 70)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 71) Once the patches have been reviewed by the BPF community as a whole
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 72) and approved by the BPF maintainers, their status in patchwork will be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 73) changed to 'Accepted' and the submitter will be notified by mail. This
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 74) means that the patches look good from a BPF perspective and have been
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 75) applied to one of the two BPF kernel trees.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 76)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 77) In case feedback from the community requires a respin of the patches,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 78) their status in patchwork will be set to 'Changes Requested', and purged
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 79) from the current review queue. Likewise for cases where patches would
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 80) get rejected or are not applicable to the BPF trees (but assigned to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 81) the 'bpf' delegate).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 82)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 83) Q: How do the changes make their way into Linux?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 84) ------------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 85) A: There are two BPF kernel trees (git repositories). Once patches have
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 86) been accepted by the BPF maintainers, they will be applied to one
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 87) of the two BPF trees:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 88)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 89) * https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 90) * https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 91)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 92) The bpf tree itself is for fixes only, whereas bpf-next for features,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 93) cleanups or other kind of improvements ("next-like" content). This is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 94) analogous to net and net-next trees for networking. Both bpf and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 95) bpf-next will only have a master branch in order to simplify against
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 96) which branch patches should get rebased to.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 97)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 98) Accumulated BPF patches in the bpf tree will regularly get pulled
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 99) into the net kernel tree. Likewise, accumulated BPF patches accepted
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 100) into the bpf-next tree will make their way into net-next tree. net and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 101) net-next are both run by David S. Miller. From there, they will go
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 102) into the kernel mainline tree run by Linus Torvalds. To read up on the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103) process of net and net-next being merged into the mainline tree, see
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 104) the :ref:`netdev-FAQ`
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 105)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 106)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 107)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 108) Occasionally, to prevent merge conflicts, we might send pull requests
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 109) to other trees (e.g. tracing) with a small subset of the patches, but
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 110) net and net-next are always the main trees targeted for integration.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 111)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 112) The pull requests will contain a high-level summary of the accumulated
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 113) patches and can be searched on netdev kernel mailing list through the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 114) following subject lines (``yyyy-mm-dd`` is the date of the pull
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 115) request)::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 116)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 117) pull-request: bpf yyyy-mm-dd
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 118) pull-request: bpf-next yyyy-mm-dd
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 119)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 120) Q: How do I indicate which tree (bpf vs. bpf-next) my patch should be applied to?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 121) ---------------------------------------------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 122)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 123) A: The process is the very same as described in the :ref:`netdev-FAQ`,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 124) so please read up on it. The subject line must indicate whether the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 125) patch is a fix or rather "next-like" content in order to let the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 126) maintainers know whether it is targeted at bpf or bpf-next.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 127)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 128) For fixes eventually landing in bpf -> net tree, the subject must
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 129) look like::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 130)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 131) git format-patch --subject-prefix='PATCH bpf' start..finish
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 132)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 133) For features/improvements/etc that should eventually land in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 134) bpf-next -> net-next, the subject must look like::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 135)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 136) git format-patch --subject-prefix='PATCH bpf-next' start..finish
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 137)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 138) If unsure whether the patch or patch series should go into bpf
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 139) or net directly, or bpf-next or net-next directly, it is not a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 140) problem either if the subject line says net or net-next as target.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 141) It is eventually up to the maintainers to do the delegation of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 142) the patches.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 143)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 144) If it is clear that patches should go into bpf or bpf-next tree,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 145) please make sure to rebase the patches against those trees in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 146) order to reduce potential conflicts.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 147)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 148) In case the patch or patch series has to be reworked and sent out
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 149) again in a second or later revision, it is also required to add a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 150) version number (``v2``, ``v3``, ...) into the subject prefix::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 151)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 152) git format-patch --subject-prefix='PATCH bpf-next v2' start..finish
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 153)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 154) When changes have been requested to the patch series, always send the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 155) whole patch series again with the feedback incorporated (never send
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 156) individual diffs on top of the old series).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 157)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 158) Q: What does it mean when a patch gets applied to bpf or bpf-next tree?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 159) -----------------------------------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 160) A: It means that the patch looks good for mainline inclusion from
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 161) a BPF point of view.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 162)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 163) Be aware that this is not a final verdict that the patch will
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 164) automatically get accepted into net or net-next trees eventually:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 165)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 166) On the bpf kernel mailing list reviews can come in at any point
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 167) in time. If discussions around a patch conclude that they cannot
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 168) get included as-is, we will either apply a follow-up fix or drop
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 169) them from the trees entirely. Therefore, we also reserve to rebase
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 170) the trees when deemed necessary. After all, the purpose of the tree
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 171) is to:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 172)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 173) i) accumulate and stage BPF patches for integration into trees
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 174) like net and net-next, and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 175)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 176) ii) run extensive BPF test suite and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 177) workloads on the patches before they make their way any further.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 178)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 179) Once the BPF pull request was accepted by David S. Miller, then
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 180) the patches end up in net or net-next tree, respectively, and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 181) make their way from there further into mainline. Again, see the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 182) :ref:`netdev-FAQ` for additional information e.g. on how often they are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 183) merged to mainline.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 184)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 185) Q: How long do I need to wait for feedback on my BPF patches?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 186) -------------------------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 187) A: We try to keep the latency low. The usual time to feedback will
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 188) be around 2 or 3 business days. It may vary depending on the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 189) complexity of changes and current patch load.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 190)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 191) Q: How often do you send pull requests to major kernel trees like net or net-next?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 192) ----------------------------------------------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 193)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 194) A: Pull requests will be sent out rather often in order to not
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 195) accumulate too many patches in bpf or bpf-next.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 196)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 197) As a rule of thumb, expect pull requests for each tree regularly
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 198) at the end of the week. In some cases pull requests could additionally
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 199) come also in the middle of the week depending on the current patch
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 200) load or urgency.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 201)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 202) Q: Are patches applied to bpf-next when the merge window is open?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 203) -----------------------------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 204) A: For the time when the merge window is open, bpf-next will not be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 205) processed. This is roughly analogous to net-next patch processing,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 206) so feel free to read up on the :ref:`netdev-FAQ` about further details.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 207)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 208) During those two weeks of merge window, we might ask you to resend
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 209) your patch series once bpf-next is open again. Once Linus released
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 210) a ``v*-rc1`` after the merge window, we continue processing of bpf-next.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 211)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 212) For non-subscribers to kernel mailing lists, there is also a status
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 213) page run by David S. Miller on net-next that provides guidance:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 214)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 215) http://vger.kernel.org/~davem/net-next.html
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 216)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 217) Q: Verifier changes and test cases
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 218) ----------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 219) Q: I made a BPF verifier change, do I need to add test cases for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 220) BPF kernel selftests_?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 221)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 222) A: If the patch has changes to the behavior of the verifier, then yes,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 223) it is absolutely necessary to add test cases to the BPF kernel
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 224) selftests_ suite. If they are not present and we think they are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 225) needed, then we might ask for them before accepting any changes.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 226)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 227) In particular, test_verifier.c is tracking a high number of BPF test
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 228) cases, including a lot of corner cases that LLVM BPF back end may
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 229) generate out of the restricted C code. Thus, adding test cases is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 230) absolutely crucial to make sure future changes do not accidentally
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 231) affect prior use-cases. Thus, treat those test cases as: verifier
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 232) behavior that is not tracked in test_verifier.c could potentially
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 233) be subject to change.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 234)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 235) Q: samples/bpf preference vs selftests?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 236) ---------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 237) Q: When should I add code to `samples/bpf/`_ and when to BPF kernel
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 238) selftests_ ?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 239)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 240) A: In general, we prefer additions to BPF kernel selftests_ rather than
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 241) `samples/bpf/`_. The rationale is very simple: kernel selftests are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 242) regularly run by various bots to test for kernel regressions.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 243)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 244) The more test cases we add to BPF selftests, the better the coverage
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 245) and the less likely it is that those could accidentally break. It is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 246) not that BPF kernel selftests cannot demo how a specific feature can
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 247) be used.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 248)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 249) That said, `samples/bpf/`_ may be a good place for people to get started,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 250) so it might be advisable that simple demos of features could go into
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 251) `samples/bpf/`_, but advanced functional and corner-case testing rather
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 252) into kernel selftests.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 253)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 254) If your sample looks like a test case, then go for BPF kernel selftests
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 255) instead!
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 256)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 257) Q: When should I add code to the bpftool?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 258) -----------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 259) A: The main purpose of bpftool (under tools/bpf/bpftool/) is to provide
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 260) a central user space tool for debugging and introspection of BPF programs
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 261) and maps that are active in the kernel. If UAPI changes related to BPF
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 262) enable for dumping additional information of programs or maps, then
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 263) bpftool should be extended as well to support dumping them.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 264)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 265) Q: When should I add code to iproute2's BPF loader?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 266) ---------------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 267) A: For UAPI changes related to the XDP or tc layer (e.g. ``cls_bpf``),
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 268) the convention is that those control-path related changes are added to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 269) iproute2's BPF loader as well from user space side. This is not only
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 270) useful to have UAPI changes properly designed to be usable, but also
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 271) to make those changes available to a wider user base of major
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 272) downstream distributions.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 273)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 274) Q: Do you accept patches as well for iproute2's BPF loader?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 275) -----------------------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 276) A: Patches for the iproute2's BPF loader have to be sent to:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 277)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 278) netdev@vger.kernel.org
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 279)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 280) While those patches are not processed by the BPF kernel maintainers,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 281) please keep them in Cc as well, so they can be reviewed.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 282)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 283) The official git repository for iproute2 is run by Stephen Hemminger
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 284) and can be found at:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 285)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 286) https://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git/
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 287)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 288) The patches need to have a subject prefix of '``[PATCH iproute2
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 289) master]``' or '``[PATCH iproute2 net-next]``'. '``master``' or
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 290) '``net-next``' describes the target branch where the patch should be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 291) applied to. Meaning, if kernel changes went into the net-next kernel
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 292) tree, then the related iproute2 changes need to go into the iproute2
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 293) net-next branch, otherwise they can be targeted at master branch. The
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 294) iproute2 net-next branch will get merged into the master branch after
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 295) the current iproute2 version from master has been released.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 296)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 297) Like BPF, the patches end up in patchwork under the netdev project and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 298) are delegated to 'shemminger' for further processing:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 299)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 300) http://patchwork.ozlabs.org/project/netdev/list/?delegate=389
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 301)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 302) Q: What is the minimum requirement before I submit my BPF patches?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 303) ------------------------------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 304) A: When submitting patches, always take the time and properly test your
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 305) patches *prior* to submission. Never rush them! If maintainers find
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 306) that your patches have not been properly tested, it is a good way to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 307) get them grumpy. Testing patch submissions is a hard requirement!
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 308)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 309) Note, fixes that go to bpf tree *must* have a ``Fixes:`` tag included.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 310) The same applies to fixes that target bpf-next, where the affected
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 311) commit is in net-next (or in some cases bpf-next). The ``Fixes:`` tag is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 312) crucial in order to identify follow-up commits and tremendously helps
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 313) for people having to do backporting, so it is a must have!
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 314)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 315) We also don't accept patches with an empty commit message. Take your
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 316) time and properly write up a high quality commit message, it is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 317) essential!
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 318)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 319) Think about it this way: other developers looking at your code a month
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 320) from now need to understand *why* a certain change has been done that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 321) way, and whether there have been flaws in the analysis or assumptions
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 322) that the original author did. Thus providing a proper rationale and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 323) describing the use-case for the changes is a must.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 324)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 325) Patch submissions with >1 patch must have a cover letter which includes
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 326) a high level description of the series. This high level summary will
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 327) then be placed into the merge commit by the BPF maintainers such that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 328) it is also accessible from the git log for future reference.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 329)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 330) Q: Features changing BPF JIT and/or LLVM
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 331) ----------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 332) Q: What do I need to consider when adding a new instruction or feature
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 333) that would require BPF JIT and/or LLVM integration as well?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 334)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 335) A: We try hard to keep all BPF JITs up to date such that the same user
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 336) experience can be guaranteed when running BPF programs on different
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 337) architectures without having the program punt to the less efficient
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 338) interpreter in case the in-kernel BPF JIT is enabled.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 339)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 340) If you are unable to implement or test the required JIT changes for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 341) certain architectures, please work together with the related BPF JIT
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 342) developers in order to get the feature implemented in a timely manner.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 343) Please refer to the git log (``arch/*/net/``) to locate the necessary
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 344) people for helping out.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 345)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 346) Also always make sure to add BPF test cases (e.g. test_bpf.c and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 347) test_verifier.c) for new instructions, so that they can receive
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 348) broad test coverage and help run-time testing the various BPF JITs.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 349)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 350) In case of new BPF instructions, once the changes have been accepted
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 351) into the Linux kernel, please implement support into LLVM's BPF back
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 352) end. See LLVM_ section below for further information.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 353)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 354) Stable submission
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 355) =================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 356)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 357) Q: I need a specific BPF commit in stable kernels. What should I do?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 358) --------------------------------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 359) A: In case you need a specific fix in stable kernels, first check whether
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 360) the commit has already been applied in the related ``linux-*.y`` branches:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 361)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 362) https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 363)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 364) If not the case, then drop an email to the BPF maintainers with the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 365) netdev kernel mailing list in Cc and ask for the fix to be queued up:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 366)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 367) netdev@vger.kernel.org
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 368)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 369) The process in general is the same as on netdev itself, see also the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 370) :ref:`netdev-FAQ`.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 371)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 372) Q: Do you also backport to kernels not currently maintained as stable?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 373) ----------------------------------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 374) A: No. If you need a specific BPF commit in kernels that are currently not
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 375) maintained by the stable maintainers, then you are on your own.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 376)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 377) The current stable and longterm stable kernels are all listed here:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 378)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 379) https://www.kernel.org/
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 380)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 381) Q: The BPF patch I am about to submit needs to go to stable as well
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 382) -------------------------------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 383) What should I do?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 384)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 385) A: The same rules apply as with netdev patch submissions in general, see
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 386) the :ref:`netdev-FAQ`.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 387)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 388) Never add "``Cc: stable@vger.kernel.org``" to the patch description, but
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 389) ask the BPF maintainers to queue the patches instead. This can be done
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 390) with a note, for example, under the ``---`` part of the patch which does
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 391) not go into the git log. Alternatively, this can be done as a simple
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 392) request by mail instead.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 393)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 394) Q: Queue stable patches
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 395) -----------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 396) Q: Where do I find currently queued BPF patches that will be submitted
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 397) to stable?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 398)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 399) A: Once patches that fix critical bugs got applied into the bpf tree, they
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 400) are queued up for stable submission under:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 401)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 402) http://patchwork.ozlabs.org/bundle/bpf/stable/?state=*
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 403)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 404) They will be on hold there at minimum until the related commit made its
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 405) way into the mainline kernel tree.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 406)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 407) After having been under broader exposure, the queued patches will be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 408) submitted by the BPF maintainers to the stable maintainers.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 409)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 410) Testing patches
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 411) ===============
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 412)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 413) Q: How to run BPF selftests
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 414) ---------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 415) A: After you have booted into the newly compiled kernel, navigate to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 416) the BPF selftests_ suite in order to test BPF functionality (current
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 417) working directory points to the root of the cloned git tree)::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 418)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 419) $ cd tools/testing/selftests/bpf/
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 420) $ make
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 421)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 422) To run the verifier tests::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 423)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 424) $ sudo ./test_verifier
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 425)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 426) The verifier tests print out all the current checks being
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 427) performed. The summary at the end of running all tests will dump
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 428) information of test successes and failures::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 429)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 430) Summary: 418 PASSED, 0 FAILED
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 431)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 432) In order to run through all BPF selftests, the following command is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 433) needed::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 434)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 435) $ sudo make run_tests
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 436)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 437) See the kernels selftest `Documentation/dev-tools/kselftest.rst`_
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 438) document for further documentation.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 439)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 440) To maximize the number of tests passing, the .config of the kernel
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 441) under test should match the config file fragment in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 442) tools/testing/selftests/bpf as closely as possible.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 443)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 444) Finally to ensure support for latest BPF Type Format features -
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 445) discussed in `Documentation/bpf/btf.rst`_ - pahole version 1.16
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 446) is required for kernels built with CONFIG_DEBUG_INFO_BTF=y.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 447) pahole is delivered in the dwarves package or can be built
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 448) from source at
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 449)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 450) https://github.com/acmel/dwarves
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 451)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 452) Some distros have pahole version 1.16 packaged already, e.g.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 453) Fedora, Gentoo.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 454)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 455) Q: Which BPF kernel selftests version should I run my kernel against?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 456) ---------------------------------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 457) A: If you run a kernel ``xyz``, then always run the BPF kernel selftests
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 458) from that kernel ``xyz`` as well. Do not expect that the BPF selftest
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 459) from the latest mainline tree will pass all the time.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 460)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 461) In particular, test_bpf.c and test_verifier.c have a large number of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 462) test cases and are constantly updated with new BPF test sequences, or
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 463) existing ones are adapted to verifier changes e.g. due to verifier
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 464) becoming smarter and being able to better track certain things.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 465)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 466) LLVM
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 467) ====
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 468)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 469) Q: Where do I find LLVM with BPF support?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 470) -----------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 471) A: The BPF back end for LLVM is upstream in LLVM since version 3.7.1.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 472)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 473) All major distributions these days ship LLVM with BPF back end enabled,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 474) so for the majority of use-cases it is not required to compile LLVM by
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 475) hand anymore, just install the distribution provided package.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 476)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 477) LLVM's static compiler lists the supported targets through
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 478) ``llc --version``, make sure BPF targets are listed. Example::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 479)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 480) $ llc --version
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 481) LLVM (http://llvm.org/):
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 482) LLVM version 10.0.0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 483) Optimized build.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 484) Default target: x86_64-unknown-linux-gnu
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 485) Host CPU: skylake
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 486)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 487) Registered Targets:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 488) aarch64 - AArch64 (little endian)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 489) bpf - BPF (host endian)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 490) bpfeb - BPF (big endian)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 491) bpfel - BPF (little endian)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 492) x86 - 32-bit X86: Pentium-Pro and above
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 493) x86-64 - 64-bit X86: EM64T and AMD64
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 494)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 495) For developers in order to utilize the latest features added to LLVM's
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 496) BPF back end, it is advisable to run the latest LLVM releases. Support
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 497) for new BPF kernel features such as additions to the BPF instruction
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 498) set are often developed together.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 499)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 500) All LLVM releases can be found at: http://releases.llvm.org/
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 501)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 502) Q: Got it, so how do I build LLVM manually anyway?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 503) --------------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 504) A: You need cmake and gcc-c++ as build requisites for LLVM. Once you have
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 505) that set up, proceed with building the latest LLVM and clang version
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 506) from the git repositories::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 507)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 508) $ git clone https://github.com/llvm/llvm-project.git
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 509) $ mkdir -p llvm-project/llvm/build/install
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 510) $ cd llvm-project/llvm/build
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 511) $ cmake .. -G "Ninja" -DLLVM_TARGETS_TO_BUILD="BPF;X86" \
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 512) -DLLVM_ENABLE_PROJECTS="clang" \
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 513) -DBUILD_SHARED_LIBS=OFF \
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 514) -DCMAKE_BUILD_TYPE=Release \
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 515) -DLLVM_BUILD_RUNTIME=OFF
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 516) $ ninja
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 517)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 518) The built binaries can then be found in the build/bin/ directory, where
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 519) you can point the PATH variable to.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 520)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 521) Set ``-DLLVM_TARGETS_TO_BUILD`` equal to the target you wish to build, you
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 522) will find a full list of targets within the llvm-project/llvm/lib/Target
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 523) directory.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 524)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 525) Q: Reporting LLVM BPF issues
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 526) ----------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 527) Q: Should I notify BPF kernel maintainers about issues in LLVM's BPF code
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 528) generation back end or about LLVM generated code that the verifier
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 529) refuses to accept?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 530)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 531) A: Yes, please do!
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 532)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 533) LLVM's BPF back end is a key piece of the whole BPF
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 534) infrastructure and it ties deeply into verification of programs from the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 535) kernel side. Therefore, any issues on either side need to be investigated
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 536) and fixed whenever necessary.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 537)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 538) Therefore, please make sure to bring them up at netdev kernel mailing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 539) list and Cc BPF maintainers for LLVM and kernel bits:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 540)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 541) * Yonghong Song <yhs@fb.com>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 542) * Alexei Starovoitov <ast@kernel.org>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 543) * Daniel Borkmann <daniel@iogearbox.net>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 544)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 545) LLVM also has an issue tracker where BPF related bugs can be found:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 546)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 547) https://bugs.llvm.org/buglist.cgi?quicksearch=bpf
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 548)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 549) However, it is better to reach out through mailing lists with having
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 550) maintainers in Cc.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 551)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 552) Q: New BPF instruction for kernel and LLVM
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 553) ------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 554) Q: I have added a new BPF instruction to the kernel, how can I integrate
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 555) it into LLVM?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 556)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 557) A: LLVM has a ``-mcpu`` selector for the BPF back end in order to allow
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 558) the selection of BPF instruction set extensions. By default the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 559) ``generic`` processor target is used, which is the base instruction set
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 560) (v1) of BPF.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 561)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 562) LLVM has an option to select ``-mcpu=probe`` where it will probe the host
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 563) kernel for supported BPF instruction set extensions and selects the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 564) optimal set automatically.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 565)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 566) For cross-compilation, a specific version can be select manually as well ::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 567)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 568) $ llc -march bpf -mcpu=help
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 569) Available CPUs for this target:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 570)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 571) generic - Select the generic processor.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 572) probe - Select the probe processor.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 573) v1 - Select the v1 processor.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 574) v2 - Select the v2 processor.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 575) [...]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 576)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 577) Newly added BPF instructions to the Linux kernel need to follow the same
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 578) scheme, bump the instruction set version and implement probing for the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 579) extensions such that ``-mcpu=probe`` users can benefit from the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 580) optimization transparently when upgrading their kernels.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 581)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 582) If you are unable to implement support for the newly added BPF instruction
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 583) please reach out to BPF developers for help.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 584)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 585) By the way, the BPF kernel selftests run with ``-mcpu=probe`` for better
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 586) test coverage.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 587)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 588) Q: clang flag for target bpf?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 589) -----------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 590) Q: In some cases clang flag ``-target bpf`` is used but in other cases the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 591) default clang target, which matches the underlying architecture, is used.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 592) What is the difference and when I should use which?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 593)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 594) A: Although LLVM IR generation and optimization try to stay architecture
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 595) independent, ``-target <arch>`` still has some impact on generated code:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 596)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 597) - BPF program may recursively include header file(s) with file scope
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 598) inline assembly codes. The default target can handle this well,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 599) while ``bpf`` target may fail if bpf backend assembler does not
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 600) understand these assembly codes, which is true in most cases.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 601)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 602) - When compiled without ``-g``, additional elf sections, e.g.,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 603) .eh_frame and .rela.eh_frame, may be present in the object file
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 604) with default target, but not with ``bpf`` target.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 605)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 606) - The default target may turn a C switch statement into a switch table
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 607) lookup and jump operation. Since the switch table is placed
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 608) in the global readonly section, the bpf program will fail to load.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 609) The bpf target does not support switch table optimization.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 610) The clang option ``-fno-jump-tables`` can be used to disable
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 611) switch table generation.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 612)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 613) - For clang ``-target bpf``, it is guaranteed that pointer or long /
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 614) unsigned long types will always have a width of 64 bit, no matter
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 615) whether underlying clang binary or default target (or kernel) is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 616) 32 bit. However, when native clang target is used, then it will
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 617) compile these types based on the underlying architecture's conventions,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 618) meaning in case of 32 bit architecture, pointer or long / unsigned
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 619) long types e.g. in BPF context structure will have width of 32 bit
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 620) while the BPF LLVM back end still operates in 64 bit. The native
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 621) target is mostly needed in tracing for the case of walking ``pt_regs``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 622) or other kernel structures where CPU's register width matters.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 623) Otherwise, ``clang -target bpf`` is generally recommended.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 624)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 625) You should use default target when:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 626)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 627) - Your program includes a header file, e.g., ptrace.h, which eventually
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 628) pulls in some header files containing file scope host assembly codes.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 629)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 630) - You can add ``-fno-jump-tables`` to work around the switch table issue.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 631)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 632) Otherwise, you can use ``bpf`` target. Additionally, you *must* use bpf target
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 633) when:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 634)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 635) - Your program uses data structures with pointer or long / unsigned long
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 636) types that interface with BPF helpers or context data structures. Access
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 637) into these structures is verified by the BPF verifier and may result
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 638) in verification failures if the native architecture is not aligned with
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 639) the BPF architecture, e.g. 64-bit. An example of this is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 640) BPF_PROG_TYPE_SK_MSG require ``-target bpf``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 641)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 642)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 643) .. Links
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 644) .. _Documentation/process/: https://www.kernel.org/doc/html/latest/process/
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 645) .. _MAINTAINERS: ../../MAINTAINERS
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 646) .. _netdev-FAQ: ../networking/netdev-FAQ.rst
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 647) .. _samples/bpf/: ../../samples/bpf/
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 648) .. _selftests: ../../tools/testing/selftests/bpf/
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 649) .. _Documentation/dev-tools/kselftest.rst:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 650) https://www.kernel.org/doc/html/latest/dev-tools/kselftest.html
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 651) .. _Documentation/bpf/btf.rst: btf.rst
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 652)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 653) Happy BPF hacking!
Orange Pi5 kernel
Deprecated Linux kernel 5.10.110 for OrangePi 5/5B/5+ boards
3 Commits
0 Branches
0 Tags