2020-05-08 14:52:40 +00:00
|
|
|
From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
|
2020-04-23 20:47:21 +00:00
|
|
|
From: Jiri Benc <jbenc@redhat.com>
|
|
|
|
|
Date: Wed, 19 Feb 2020 11:52:20 +0100
|
|
|
|
|
Subject: [PATCH] redhat: rh_kabi add a comment with warning about
|
|
|
|
|
RH_KABI_EXCLUDE usage
|
|
|
|
|
|
|
|
|
|
RH-Acked-by: Prarit Bhargava <prarit@redhat.com>
|
|
|
|
|
RH-Acked-by: Don Zickus <dzickus@redhat.com>
|
|
|
|
|
|
|
|
|
|
Upstream status: RHEL only
|
|
|
|
|
|
|
|
|
|
We've seen attempts of incorrect RH_KABI_EXCLUDE usage. The macro is
|
|
|
|
|
dangerous and any structure marked by it becomes fragile. It completely
|
|
|
|
|
mutes the kABI checker and a future attempt to whitelist anything using
|
|
|
|
|
a structure annotated by RH_KABI_EXCLUDE will generate easily broken, error
|
|
|
|
|
prone code. Also, it bypasses module loading checks for the structure and
|
|
|
|
|
can lead to kernel crashes triggered by 3rd party modules unless carefully
|
|
|
|
|
prevented by RH_KABI_FORCE_CHANGE.
|
|
|
|
|
|
|
|
|
|
As such, it should not be used routinely. The only valid usage is a code
|
|
|
|
|
heavily in flux upstream that is going to be refactored and turned upside
|
|
|
|
|
down, which is indirectly whitelisted and which we expect to need
|
|
|
|
|
backported.
|
|
|
|
|
|
|
|
|
|
Any usage of this macro requires deep understanding of how kABI works.
|
|
|
|
|
|
|
|
|
|
Add a big fat warning to stop the misuse.
|
|
|
|
|
|
|
|
|
|
Upstream Status: RHEL only
|
|
|
|
|
Signed-off-by: Jiri Benc <jbenc@redhat.com>
|
|
|
|
|
---
|
|
|
|
|
include/linux/rh_kabi.h | 11 ++++++++++-
|
|
|
|
|
1 file changed, 10 insertions(+), 1 deletion(-)
|
|
|
|
|
|
|
|
|
|
diff --git a/include/linux/rh_kabi.h b/include/linux/rh_kabi.h
|
|
|
|
|
index 4debb7aaad48..b90601e8a657 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-2017 Jiri Benc
|
|
|
|
|
+ * Copyright (c) 2015-2018 Jiri Benc
|
|
|
|
|
* Copyright (c) 2015 Sabrina Dubroca, Hannes Frederic Sowa
|
|
|
|
|
* Copyright (c) 2016-2018 Prarit Bhargava
|
|
|
|
|
* Copyright (c) 2017 Paolo Abeni, Larry Woodman
|
|
|
|
|
@@ -93,7 +93,16 @@
|
|
|
|
|
* corrupt memory. Instead, by changing the symbol checksum, such modules
|
|
|
|
|
* won't be loaded by the kernel. This macro should only be used as a
|
|
|
|
|
* last resort when all other KABI workarounds have failed.
|
|
|
|
|
+ *
|
|
|
|
|
* RH_KABI_EXCLUDE
|
|
|
|
|
+ * !!! WARNING: DANGEROUS, DO NOT USE unless you are aware of all the !!!
|
|
|
|
|
+ * !!! implications. This should be used ONLY EXCEPTIONALLY and only !!!
|
|
|
|
|
+ * !!! under specific circumstances. Very likely, this macro does not !!!
|
|
|
|
|
+ * !!! do what you expect it to do. Note that any usage of this macro !!!
|
|
|
|
|
+ * !!! MUST be paired with a RH_KABI_FORCE_CHANGE annotation of !!!
|
|
|
|
|
+ * !!! a suitable symbol (or an equivalent safeguard) and the commit !!!
|
|
|
|
|
+ * !!! log MUST explain why the chosen solution is appropriate. !!!
|
|
|
|
|
+ *
|
|
|
|
|
* Exclude the element from checksum generation. Any such element is
|
|
|
|
|
* considered not to be part of the kABI whitelist and may be changed at
|
|
|
|
|
* will. Note however that it's the responsibility of the developer
|
|
|
|
|
--
|
2020-06-29 18:02:20 +00:00
|
|
|
2.25.4
|
2020-04-23 20:47:21 +00:00
|
|
|
|
