Re: genksyms vs. opaque struct *

Nicolas Schier
2025-11-26T20:49:17Z

[-- Attachment #1: Type: text/plain, Size: 2471 bytes --]

On Thu, Nov 13, 2025 at 09:40:11PM +0100, Philipp Hahn wrote:
> Hello,
>
> while building a Linux kernel module I stumbled over an issue with
> 'genksyms': Basically my modules uses an "opaque struct" and only gets
> a pointer to such an object. The header file declaring that struct did
> *not* #include all needed header files recursively, so some types
> remained unresolved.
> For compiling the module this was not an issue as the compiler only
> needs to allocate space for an pointer to that nested struct and does
> not need more details.
> Another module exists which uses that symbol and recorded the
> calculated CRC.
>
> Then I changed my module and added some more #includes, which resulted
> into `genksyms` getting *more* details on the next run while the
> implementation actually did not change.
>
> I only found out root cause of my problem after digging into the
> genksyms-machinery myself, where I found the option `--warnings`,
> which actually prints out such a warning in my case:
> > /home/pmhahn/prog/my-modver/my-modver.c:8: expand undefined struct bar
>
> In my example below it makes a difference if `-DDETAIL` is given or not:
> > cpp -E -D__GENKSYMS__ …my-modver.c -DDETAIL | scripts/genksyms/genksyms -r /dev/null -w
> > #SYMVER my_function 0x0cdb4509
> > cpp -E -D__GENKSYMS__ …my-modver.c | scripts/genksyms/genksyms -r /dev/null -w
> > #SYMVER my_function 0x87675506
>
> I wonder, why that option is not enabled by default or if there is
> another solution to prevent such breaking changed by including
> more/less #includes? Are there any good/recommended practices?

FTR: Philipp and I had a face-to-face conversation about the topic.
Some results for possible thread readers:

* Running genksyms with --warnings breaks the kernel build; and the
warning is output really often.

* The described situation is easily reproducible with the given
example, but it is not relevant: Symbols for exported functions are
hashed for their _source_ c module appearance; all users simply
record the found hash to allow the loader to verify the recorded
hash with the one provided by the function export.

* The actual problem that has been described is probably related to
some purely out-of-tree kmod organisation issues.

Nicolas

PS: Module symvers topic is probably better handled via
linux-modules@vger.kernel.org and linux-kbuild@vger.kernel.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]