Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
From:   Ulrich Drepper <drepper@redhat.com>
Date:   Wed, 8 Sep 2021 17:05:41 +0200
Message-ID: <CAP3s5k_QNQqjMqLP68KvtchpmUGc9dnfSfmsz2OXh6opFpKW+w@mail.gmail.com>
Subject: implicit dependency in x86/page_64.h:task_size_max
To:     linux-kernel@vger.kernel.org, torvalds@linux-foundation.org,
        bp@alien8.de
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

I don't have a 5.14 kernel installed, yet, but from the looks of it
this problem still persists.

Out-of-tree modules were broken by commit
025768a966a3dde8455de46d1f121a51bacb6a77 which introduced a dependency
on a CPU feature macro in the task_size_max implementation
(X86_FEATURE_LA57) without making sure the macro is defined.  The
result is that the compiler generates an object file with an reference
to a symbol with this name.  The resulting modpost invocation catches
this.

An example for the problem exists with the blackmagic-io module. I
name it here so people can perhaps find this post.

The "solution" so far is to include <asm/cpufeatures.h> before
task_size_max is defined.

In userlevel headers we had the convention that any header should
#include all the other headers to satisfy its dependencies.  If
arch/x86/asm/page_64.h would include <asm/cpufeatures.h> first there
would be no problem with the module above but I haven't checked
whether this creates other problems.  And as I mentioned, I don't know
what the convention is.

Someone will know and perhaps we could get a patch installed with
either the missing #include added or

#ifndef X86_FEATURE_LA57
# error "you need to include <asm/cpufeatures.h> first"
#endif


Thanks.