Bug#990123: [buster regression] iptables-netflow-dkms: No more compiles since linux-*-4.19.0-17-*: "implicit declaration of function ‘ref_module’" (Upstream kernel API regression in 4.19.191?)
Control: affects -1 + release.debian.org
Hi Axel,
On Mon, Jun 21, 2021 at 01:33:01PM +0200, Axel Beckert wrote:
> Package: iptables-netflow-dkms,linux-headers-4.19.0-17-amd64,linux-headers-4.19.0-17-i686-pae
> Severity: serious
> Version: iptables-netflow/2.3-5
> Version: iptables-netflow/2.5.1-2
> Version: linux/4.19.194-1
> Tags: buster
> Forwarded: https://github.com/aabc/ipt-netflow/issues/177
>
> Since kernel packages linux-{image,headers}-4.19.0-17-*, at least with
> -amd64 and -i686-pae, iptables-netflow-dkms no more compiles its kernel
> module upon kernel installation:
>
> In file included from /var/lib/dkms/ipt-netflow/2.3/build/ipt_NETFLOW.c:75:
> /var/lib/dkms/ipt-netflow/2.3/build/ipt_NETFLOW.c: In function ‘register_ct_events’:
> /var/lib/dkms/ipt-netflow/2.3/build/compat.h:173:21: error: implicit declaration of function ‘ref_module’; did you mean ‘use_module’? [-Werror=implicit-function-declaration]
> # define use_module ref_module
> ^~~~~~~~~~
> /var/lib/dkms/ipt-netflow/2.3/build/ipt_NETFLOW.c:5399:3: note: in expansion of macro ‘use_module’
> use_module(THIS_MODULE, netlink_m);
> ^~~~~~~~~~
>
> Reading the kernel changelog, there are a few very suspicious entries
> listed under upstream version 4.19.191:
>
> - modules: mark ref_module static
> - modules: mark find_symbol static
> - modules: mark each_symbol_section static
>
> One of the commits above (8745aa4e resp. 7ef5264d) states:
>
> ref_module isn't used anywhere outside of module.c.
>
> Which is only seems true if you ignore any third-party kernel modules
> out there.
>
> So why is the kernel API suddenly removing API-code used by third-party
> modules inmidst a stable update? This looks like a regression to me. I
> thought that stable updates only change the ABI, but not the API. (Well,
> at least upstream and in Debian. :-)
>
> I also tried the iptables-netflow-dkms 2.5.1-2 from Bullseye on Buster,
> but it fails to build the kernel module for 4.19.0-17-* when as well.
>
> 2.5.1-2 though still works fine on Sid/Bullseye, hence marked as found
> in the version in Sid, but tagged buster. In case this causes issues in
> the BTS or the release team scripts, please rather remove 2.5.1-2 from
> the "found" versions instead of removing the buster tag — unless the
> same regression gets introduced into Sid and Bullseye as well.
>
> Debian kernel maintainers: If this 3rd-party-module-breaking regression
> was really intended and won't be fixed, please reassign the bug to
> iptables-netflow-dkms only.
>
> I also reported this issue to iptables-netflow upstream at
> https://github.com/aabc/ipt-netflow/issues/177 as I think it at least
> should update the version based ifdef checks in something which looks
> like a similar issue in kernel 5.13, see
> https://github.com/aabc/ipt-netflow/commit/5aae3791922bd3df878605b15e83ea48a4bd096c
> which is part of iptables-netflow upstream's 2.6 release, not yet
> packaged due to the freeze for bullseye.
>
> I'll try and see if I can get that fix backported to the package in
> buster (and if needed, later to the one in bullseye as well) and will
> see if it actually helps in this case, too.
>
> JFTR: dkms from buster-backports (as reported below) is only installed
> as I needed it for the iptables-netflow-dkms package from bullseye. It
> happened with dkms from buster before as well.
7ef5264de773 ("modules: mark ref_module static") indeed is likely to
cause the issue, or basically the patchset around that. That initially
landed in 5.9-rc1, and recently got backported upstream to 4.19.191.
There is some background here:
https://lore.kernel.org/lkml/20200730061027.29472-1-hch@lst.de/
and
https://lore.kernel.org/stable/YMxnXQzcP0g1F9Iw@kroah.com/
That said, upstream won't really revert those changes.
So in my biased view, what would be needed for buster indeed would be
an equivalent approach in buster for iptables-netflow unbreaking this
regression similar as done in 2.5.1-1 wit the
cherry-pick-adfc6318-fix-compilation-for-5.9-workaround-ref_module-unexport.patch
patch.
I had no time to check if the patch applies and what changes need to
be done, but basically what was added there fo fix compilation with
Linux 5.9 (which introduced the above changes initially) would need as
well for the 4.19.y stable series.
Regards,
Salvatore
Reply to: