[OS-BUILD PATCH 3/18] kabi: macros for intentional kABI breakage

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

 



From: Čestmír Kalina <ckalina@xxxxxxxxxx>

kabi: macros for intentional kABI breakage

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2024595
Upstream Status: RHEL only

commit 69bc4518f92fcaafabc846d31e568eedd65264d9
Author: Jiri Benc <jbenc@xxxxxxxxxx>
Date: Wed, 19 Feb 2020 12:04:22 -0500

    Occasionally, we modify a struct that is included from a whitelisted
    function through a chain of other structs but the modified struct is
    internal to the kernel and 3rd party modules are not allowed to access it.

    In such cases, it is safe and preferable to modify that struct without
    paying attention to the kABI checksums.

    An example of this is bpf rebases: bpf is not considered kABI stable and
    3rd party modules may not use it without recompilation between releases.
    However, through a chain of structs, some bpf structs are part of kABI
    checksum computations. Given the high volume of changes upstream in the bpf
    code, we need to keep the added fields at the same places as in upstream to
    ensure maintainability of RHEL code.

    Another example is PHY rebases.

    Currently, the code solves it by using the RH_KABI_EXTEND macro. Although it
    is technically okay and the code will work, it is not the right macro to
    use, as the RH_KABI macro usage is expected to also serve as a documentation
    of the kABI workaround used. In particular, RH_KABI_EXTEND means the
    structure was safely extended, preserving kABI stability. Which is not the
    case here, we did break kABI (but it was okay to break it).

    Introduce new macros that convey this meaning and use them in all places
    where previously less fitting macros were used.

    RH-Signed-off-by: Jiri Benc <jbenc@xxxxxxxxxx>

Signed-off-by: Čestmír Kalina <ckalina@xxxxxxxxxx>
Signed-off-by: Prarit Bhargava <prarit@xxxxxxxxxx>

diff --git a/include/linux/rh_kabi.h b/include/linux/rh_kabi.h
index blahblah..blahblah 100644
--- a/include/linux/rh_kabi.h
+++ b/include/linux/rh_kabi.h
@@ -2,7 +2,7 @@
  * rh_kabi.h - Red Hat kABI abstraction header
  *
  * Copyright (c) 2014 Don Zickus
- * Copyright (c) 2015-2018 Jiri Benc
+ * Copyright (c) 2015-2020 Jiri Benc
  * Copyright (c) 2015 Sabrina Dubroca, Hannes Frederic Sowa
  * Copyright (c) 2016-2018 Prarit Bhargava
  * Copyright (c) 2017 Paolo Abeni, Larry Woodman
@@ -140,6 +140,30 @@
  *   of the size is not allowed and would constitute a silent kABI breakage.
  *   Beware that the RH_KABI_EXCLUDE macro does not do any size checks.
  *
+ * RH_KABI_BROKEN_INSERT
+ * RH_KABI_BROKEN_REMOVE
+ *   Insert a field to the middle of a struct / delete a field from a struct.
+ *   Note that this breaks kABI! It can be done only when it's certain that
+ *   no 3rd party driver can validly reach into the struct.  A typical
+ *   example is a struct that is:  both (a) referenced only through a long
+ *   chain of pointers from another struct that is part of a whitelisted
+ *   symbol and (b) kernel internal only, it should have never been visible
+ *   to genksyms in the first place.
+ *
+ *   Another example are structs that are explicitly exempt from kABI
+ *   guarantee but we did not have enough foresight to use RH_KABI_EXCLUDE.
+ *   In this case, the warning for RH_KABI_EXCLUDE applies.
+ *
+ *   A detailed explanation of correctness of every RH_KABI_BROKEN_* macro
+ *   use is especially important.
+ *
+ * RH_KABI_BROKEN_INSERT_BLOCK
+ * RH_KABI_BROKEN_REMOVE_BLOCK
+ *   A version of RH_KABI_BROKEN_INSERT / REMOVE that allows multiple fields
+ *   to be inserted or removed together.  All fields need to be terminated
+ *   by ';' inside(!) the macro parameter.  The macro itself must not be
+ *   terminated by ';'.
+ *
  */
 
 #undef linux
@@ -154,6 +178,10 @@
 # define RH_KABI_RENAME(_orig, _new)		_orig
 # define RH_KABI_HIDE_INCLUDE(_file)		<linux/rh_kabi.h>
 # define RH_KABI_FAKE_INCLUDE(_file)		_file
+# define RH_KABI_BROKEN_INSERT(_new)
+# define RH_KABI_BROKEN_REMOVE(_orig)		_orig;
+# define RH_KABI_BROKEN_INSERT_BLOCK(_new)
+# define RH_KABI_BROKEN_REMOVE_BLOCK(_orig)	_orig
 
 # define _RH_KABI_DEPRECATE(_type, _orig)	_type _orig
 # define _RH_KABI_DEPRECATE_FN(_type, _orig, _args...)	_type (*_orig)(_args)
@@ -172,6 +200,10 @@
 # define RH_KABI_RENAME(_orig, _new)		_new
 # define RH_KABI_HIDE_INCLUDE(_file)		_file
 # define RH_KABI_FAKE_INCLUDE(_file)		<linux/rh_kabi.h>
+# define RH_KABI_BROKEN_INSERT(_new)		_new;
+# define RH_KABI_BROKEN_REMOVE(_orig)
+# define RH_KABI_BROKEN_INSERT_BLOCK(_new)	_new
+# define RH_KABI_BROKEN_REMOVE_BLOCK(_orig)
 
 
 #if IS_BUILTIN(CONFIG_RH_KABI_SIZE_ALIGN_CHECKS)

--
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1530
_______________________________________________
kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/kernel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure




[Index of Archives]     [Fedora General Discussion]     [Older Fedora Users Archive]     [Fedora Advisory Board]     [Fedora Security]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Package Announce]     [Fedora Package Review]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Coolkey]     [Yum Users]     [Tux]     [Yosemite News]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [USB]     [Asterisk PBX]

  Powered by Linux