Le 09/06/2022 à 12:15, Herbert Xu a écrit :
On Sun, Jun 05, 2022 at 09:32:53AM +0200, Christophe JAILLET wrote:
When kernel.h is used in the headers it adds a lot into dependency hell,
especially when there are circular dependencies are involved.
Replace kernel.h inclusion with the list of what is really being used.
Signed-off-by: Christophe JAILLET <christophe.jaillet@xxxxxxxxxx>
---
arch/x86/crypto/camellia.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/crypto/camellia.h b/arch/x86/crypto/camellia.h
index 1dcea79e8f8e..547fb7e30928 100644
--- a/arch/x86/crypto/camellia.h
+++ b/arch/x86/crypto/camellia.h
@@ -4,7 +4,7 @@
#include <crypto/b128ops.h>
#include <linux/crypto.h>
-#include <linux/kernel.h>
+#include <linux/types.h>
#define CAMELLIA_MIN_KEY_SIZE 16
#define CAMELLIA_MAX_KEY_SIZE 32
This is not sufficient. For example, asmlinkage isn't explicitly
defined by any of these header files so it would be relying on an
implicit inclusion which is prone to breakage.
Agreed, I missed that.
Did you audit the entire file?
Yes, but I missed the asmlinkage.
In fact, I've sent a few "obvious" (but nothing is never obvious at the
end...) patches like that to see the interest.
I've spotted a few .h file with "easy to check" content.
Mostly #define, function declarations, a few u<something> datatypes.
Then, I made the #include simplification and compile tested the change.
If it worked, I consider that the patch looks fine.
In this particular case, I guess that the 'asmlinkage' should come from
another #include when "camellia.h" is used.
My goal was not to introduce some new hidden constraints related to the
order of the included .h. I just wanted to make them explicit (and
complete) and start to simplify things.
As said, nothing is never obvious, and I'll stay away from this kind of
changes :)
Thanks a lot for the review.
CJ
Cheers,
