On 16.12.2020 17:49, Mike Galbraith wrote:
> On Wed, 2020-12-16 at 15:31 +0100, Mike Galbraith wrote:
>> On Wed, 2020-12-16 at 17:23 +0300, Kirill Tkhai wrote:
>>>
>>> Does this regression only cause that one error message "check_release: 
>>> Can't get the kernel version"
>>> is printed instead of another: "The kernel version is not supported."?
>>
>> The thing does indeed mutter about the kernel version, with or without
>> 9a56493f6942 reverted, but it work despite the muttering with
>> 9a56493f6942 reverted.
> 
> makedumpfile 1.6.7 source only claims to work up to linux-5.4.8, but
> actually does work all the way up until 9a56493f6942.
> 
> If the answer here is that v1,6,7 has reached EOL, that's fine, I'll
> just carry a revert until I can cobble together an updated package.

I think, since there is no a makedumpfile version working, this is a regression,
and it should be workarounded it in kernel.

We may consider a patch like the below till updated makedumpfile is not 
published:

diff --git a/include/linux/utsname.h b/include/linux/utsname.h
index 2b1737c9b244..d6bcad448f52 100644
--- a/include/linux/utsname.h
+++ b/include/linux/utsname.h
@@ -8,6 +8,7 @@
 #include <linux/ns_common.h>
 #include <linux/err.h>
 #include <uapi/linux/utsname.h>
+#include <linux/kref.h>
 
 enum uts_proc {
        UTS_PROC_OSTYPE,
@@ -21,6 +22,7 @@ struct user_namespace;
 extern struct user_namespace init_user_ns;
 
 struct uts_namespace {
+       struct kref unused;
        struct new_utsname name;
        struct user_namespace *user_ns;
        struct ucounts *ucounts;

Reply via email to