Patch "bpf: Add __bpf_kfunc tag for marking kernel functions as kfuncs" has been added to the 6.2-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This is a note to let you know that I've just added the patch titled

    bpf: Add __bpf_kfunc tag for marking kernel functions as kfuncs

to the 6.2-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     bpf-add-__bpf_kfunc-tag-for-marking-kernel-functions.patch
and it can be found in the queue-6.2 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit 37f6226ab577b5fc03de352124e1533e5a5eb54b
Author: David Vernet <void@xxxxxxxxxxxxx>
Date:   Wed Feb 1 11:30:13 2023 -0600

    bpf: Add __bpf_kfunc tag for marking kernel functions as kfuncs
    
    [ Upstream commit 57e7c169cd6afa093d858b8edfb9bceaf2e1c93b ]
    
    kfuncs are functions defined in the kernel, which may be invoked by BPF
    programs. They may or may not also be used as regular kernel functions,
    implying that they may be static (in which case the compiler could e.g.
    inline it away, or elide one or more arguments), or it could have
    external linkage, but potentially be elided in an LTO build if a
    function is observed to never be used, and is stripped from the final
    kernel binary.
    
    This has already resulted in some issues, such as those discussed in [0]
    wherein changes in DWARF that identify when a parameter has been
    optimized out can break BTF encodings (and in general break the kfunc).
    
    [0]: https://lore.kernel.org/all/1675088985-20300-2-git-send-email-alan.maguire@xxxxxxxxxx/
    
    We therefore require some convenience macro that kfunc developers can
    use just add to their kfuncs, and which will prevent all of the above
    issues from happening. This is in contrast with what we have today,
    where some kfunc definitions have "noinline", some have "__used", and
    others are static and have neither.
    
    Note that longer term, this mechanism may be replaced by a macro that
    more closely resembles EXPORT_SYMBOL_GPL(), as described in [1]. For
    now, we're going with this shorter-term approach to fix existing issues
    in kfuncs.
    
    [1]: https://lore.kernel.org/lkml/Y9AFT4pTydKh+PD3@xxxxxxxxxxxxx/
    
    Note as well that checkpatch complains about this patch with the
    following:
    
    ERROR: Macros with complex values should be enclosed in parentheses
    +#define __bpf_kfunc __used noinline
    
    There seems to be a precedent for using this pattern in other places
    such as compiler_types.h (see e.g. __randomize_layout and noinstr), so
    it seems appropriate.
    
    Signed-off-by: David Vernet <void@xxxxxxxxxxxxx>
    Signed-off-by: Daniel Borkmann <daniel@xxxxxxxxxxxxx>
    Acked-by: Stanislav Fomichev <sdf@xxxxxxxxxx>
    Link: https://lore.kernel.org/bpf/20230201173016.342758-2-void@xxxxxxxxxxxxx
    Stable-dep-of: f6a6a5a97628 ("bpf: Fix struct_meta lookup for bpf_obj_free_fields kfunc call")
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/include/linux/btf.h b/include/linux/btf.h
index 5f628f323442a..ff62fa63dc197 100644
--- a/include/linux/btf.h
+++ b/include/linux/btf.h
@@ -72,6 +72,14 @@
 #define KF_DESTRUCTIVE  (1 << 6) /* kfunc performs destructive actions */
 #define KF_RCU          (1 << 7) /* kfunc only takes rcu pointer arguments */
 
+/*
+ * Tag marking a kernel function as a kfunc. This is meant to minimize the
+ * amount of copy-paste that kfunc authors have to include for correctness so
+ * as to avoid issues such as the compiler inlining or eliding either a static
+ * kfunc, or a global kfunc in an LTO build.
+ */
+#define __bpf_kfunc __used noinline
+
 /*
  * Return the name of the passed struct, if exists, or halt the build if for
  * example the structure gets renamed. In this way, developers have to revisit



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux