[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: 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-hch@lst.de/
> https://lore.kernel.org/stable/YMxnXQzcP0g1F9Iw@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 <abe@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

Attachment: signature.asc
Description: PGP signature


Reply to: