Control: reassign -1 iptables-netflow-dkms Control: found -1 2.3-5 Control: notfound -1 2.5.1-2
Hi Salvatore,
Salvatore Bonaccorso wrote:
> On Mon, Jun 21, 2021 at 01:33:01PM +0200, Axel Beckert wrote:
> > 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.
[…]
> 7ef5264de773 ("modules: mark ref_module static") indeed is likely to
> cause the issue, or basically the patchset around that.
Thanks for that confirmation.
> That initially landed in 5.9-rc1,
Right, I saw that the list of tags including that change on Github. I
though wondered why 2.5.1-2 works in Sid/Bullseye but not on Buster —
but probably because the current #ifdefs just don't expect that fix
being needed for any kernel before 5.9.
> There is some background here:
>
> https://lore.kernel.org/lkml/20200730061027.29472-1-...@lst.de/
> https://lore.kernel.org/stable/ymxnxqzcp0g1f...@kroah.com/
Thanks for that! I didn't really expected license enforcing to be the
background. With that background I do understand that change much
more. :-)
> That said, upstream won't really revert those changes.
Understandable. I'm though surprised that this got backported. But I
guess the pain without it is bigger than this one precise cut.
> 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
Thanks for pointing out that this patch is already in 2.5.1-1.
I actually forgot that I had to solve this already once in the past
(probably because the solution was submitted as pull request upstream
against 2.5.1) and since 2.5.1-2 didn't work on buster either, I
didn't expect it to be more or less fixed already. But in the end it's
hopefully just replacing
#if LINUX_VERSION_CODE < KERNEL_VERSION(5,9,0)
with a bit more complex condition including further constraints.
> I had no time to check if the patch applies and what changes need to
> be done,
No need to worry. That's not your job but mine. :-)
> 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.
Ack.
Thanks again.
Regards, Axel
--
,''`. | Axel Beckert <a...@debian.org>, https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`- | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
signature.asc
Description: PGP signature
