From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 49E0A33F8B7 for ; Wed, 26 Nov 2025 20:49:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764190158; cv=none; b=skcImmVN0YENS9l53iOlmrMVWgGOZuObs20WNenFsHCUKwcmrVI/I8o3J/sHOe+E6Lq/6SuShBdNnNrLm7B1hyGVqBuWzIXhyDR63golkMkmAURUac++sMsOBsFQhU5WrVR8eDNUj0aWSoB4uFRivilIkyAUOcAQqZb5wKqsIqU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764190158; c=relaxed/simple; bh=iCChH+8ajZ6DcVrQ4DarMlAus9A9TfX7Hp2DBPppDNs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Pg59hy23+BTlhJdBfWJYGFt+XN/E9DTddCxA4Cwy7agM1WdzhEN8iheUnxjeSKqZXnVvgHXxGYK2lZT9PX0OJJTrPGThAxJ2d+7qT99HUxxZkgY2VMUkdCJelqOq/j/5Xxiyuxsh+TtNNLy/nQg44bM54dohHrrqsVpywmVhGag= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=sM4Kqii5; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="sM4Kqii5" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 43DE7C4CEF7; Wed, 26 Nov 2025 20:49:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1764190157; bh=iCChH+8ajZ6DcVrQ4DarMlAus9A9TfX7Hp2DBPppDNs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=sM4Kqii57vK4ZP9m/CJkpjkAJKXndzGMAL8m9HnyzTpUXN0IVKaaBtc5U1FYBjyyC 0838GlGrg/AVmQtyfeebTfImsxlp4RPONtQ5KkLvODQgJOnPLen8hsBZoxkq+c1vby MYgP0IVPp78RJeQxapHgnYV46ZXipkfzOe4KLkOpZNw8EQVz9+TG10QEyJd4KIl9It uFZH1wZcQ6dnfwpzxyTKsHYkm33csyxUnNBQBiR5Q24d0QyLFWPL1n1Pa6K7/Kc7Jg 2h427079vfsz6eTeIgUi2fDvrB7GQ6qJ/rp42Y2f053dVn+n9lOVhBufddkVu2mA3M lTbW3k2e7TskA== Date: Wed, 26 Nov 2025 16:22:07 +0100 From: Nicolas Schier To: Philipp Hahn Cc: Masahiro Yamada , linux-kernel@vger.kernel.org Subject: Re: genksyms vs. opaque struct * Message-ID: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="hkrpR37cjLCucVF3" Content-Disposition: inline In-Reply-To: --hkrpR37cjLCucVF3 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 13, 2025 at 09:40:11PM +0100, Philipp Hahn wrote: > Hello, >=20 > 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. >=20 > 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. >=20 > 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 >=20 > In my example below it makes a difference if `-DDETAIL` is given or not: > > cpp -E -D__GENKSYMS__ =E2=80=A6my-modver.c -DDETAIL | scripts/genksyms/= genksyms -r /dev/null -w > > #SYMVER my_function 0x0cdb4509 > > cpp -E -D__GENKSYMS__ =E2=80=A6my-modver.c | scripts/genksyms/genksyms= -r /dev/null -w > > #SYMVER my_function 0x87675506 >=20 > 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 --hkrpR37cjLCucVF3 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEh0E3p4c3JKeBvsLGB1IKcBYmEmkFAmknGxsACgkQB1IKcBYm Emkfmg//YaRpnXQMeHtaWx+2BABgqKUlm9p87xsxxgFn92D1cGMPsYXnTWJ2c0nQ QprV6577JVOephEYNTs7kZEZ9UEt5T1VUrzEDOkN7H8jRXumRbBCwGpUW699NK+i EOth8+mID9icMNhtYABJj781gogFugc+sadJMc2heWKRDMB2shh+iju2ldm8lWTl TAeq1EHMaFC9L5LY3RLV0AV+fXLwR5Ye4s3wsPCDZCGFNq9LgOlGOqjEgvAXkgAj 1Hw+BiZDEZ5EZ1T9/t+WRDJeODtRNof3mldgCvQrmJny46I9Eg89Yeeeft6+pgiu iRDDmMDIiQL15yRMuYEN5SUQ9bVX22EszdyPSqvHNo3SMQ87YxqPBEv/NJryipm0 Cy8eKb3OZ2UcQCaZQWqSO0v6z+by+R00DAA2NfywSz373MpD1AS5dQfQYSlWrTu5 uY6E4ueHqnCBZOVPdR0P17yquirjiZcocLdEZ0fbv+806qpQeNgEZupVryQrVQLz FhSDCZGLKoGZuIN4CL0IJ8DU3l2AGlM4Ic9+Do6QJzxm8jXxf62bHEVIoSoLldww OxAjPjBVNKa74oFuMmc88dx4MPxFjCYZUcxJ5Xl28iYChCYYgEE1pwkrZ7Oim8+V fnMa8KlAgHoZNixHI1WPQTuSKbMVBIKYxBSaJuggmDcFzit1UiU= =Iwoj -----END PGP SIGNATURE----- --hkrpR37cjLCucVF3--