From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: Florian Westphal <fw@strlen.de>,
Matt Zagrabelny <mzagrabe@d.umn.edu>,
netfilter <netfilter@vger.kernel.org>, bpf <bpf@vger.kernel.org>
Subject: Re: ct state module issue
Date: Wed, 26 Jul 2023 09:19:10 -0700 [thread overview]
Message-ID: <CAADnVQ+PHXbeGjm6ty6f7KbGZGinvng1SG_BdDh85T=1tvHoXQ@mail.gmail.com> (raw)
In-Reply-To: <ZMDNywzqUqjmdhOO@calendula>
On Wed, Jul 26, 2023 at 12:40 AM Pablo Neira Ayuso <pablo@netfilter.org> wrote:
>
> Hi Alexei,
>
> On Tue, Jul 25, 2023 at 12:57:13PM -0700, Alexei Starovoitov wrote:
> > On Tue, Jul 25, 2023 at 12:33 PM Florian Westphal <fw@strlen.de> wrote:
> > >
> > > Matt Zagrabelny <mzagrabe@d.umn.edu> wrote:
> > >
> > > [ CCing bpf/btf experts ]
> > >
> > > > I'm running kernel: 6.1.0-10-amd64
> > > > and
> > > > nftables v1.0.6 (Lester Gooch #5)
> > > >
> > > > I have a set of nftables rules that have served me well for Debian 11
> > > > - thanks in large part to the netfilter mailing list, so...thank you!
> > > > nftables on Debian 11 is: 0.9.8-3.1+deb11u1
> > > >
> > > > I have recently installed Debian 12 and tried my nftables rules and
> > > > have hit a snag with the connection tracking and a verdict map.
> > > > nftables on Debian 12 is: 1.0.6-2+deb12u1
> > > >
> > > > When I run the offending snippet:
> > > >
> > > > # nft -f /etc/nftables.conf.d/300-common.d/200-connection-tracking.nft
> > > > /etc/nftables.conf.d/300-common.d/200-connection-tracking.nft:4:9-16:
> > > > Error: Could not process rule: No such file or directory
> > > > ct state vmap {
> > >
> > > [..]
> > > ^^^^^^^^
> > > > When I watch the kernel logs (journalctl), I see:
> > > >
> > > > Jul 25 13:44:04 localhost kernel: BPF: [99725] STRUCT
> > > > Jul 25 13:44:04 localhost kernel: BPF: size=104 vlen=12
> > > > Jul 25 13:44:04 localhost kernel: BPF:
> > > > Jul 25 13:44:04 localhost kernel: BPF: Invalid name
> > > > Jul 25 13:44:04 localhost kernel: BPF:
> > > > Jul 25 13:44:04 localhost kernel: failed to validate module
> > > > [nf_conntrack] BTF: -22
> > > > Jul 25 13:44:04 localhost kernel: missing module BTF, cannot register kfuncs
> > >
> > > So nf_conntrack.ko fails to load because of a btf issue.
> > >
> > > My question to bpf folks is:
> > >
> > > Should we make register_nf_conntrack_bpf() return 'void'?
> > >
> > > This way normal conntrack would still work. bpf programs using
> > > conntrack kfuncs would fail, but above dmesg splat already gives
> > > a clue as to why conntrack kfuncs aren't there.
> > >
> > > No idea about the actual problem or how to debug that, but bpf
> > > people should know.
> >
> > The pr_err() was changed to pr_warn() in
> > commit 3de4d22cc9ac ("bpf, btf: Warn but return no error for NULL btf
> > from __register_btf_kfunc_id_set()").
>
> OK, no ENOENT anymore, hence no bail out.
>
> > Please upgrade the kernel and ignore the warn if you don't need bpf/btf/kfuncs.
> >
> > Three links in that commit provide more details.
>
> Jul 25 13:44:04 localhost kernel: BPF: [99725] STRUCT
> Jul 25 13:44:04 localhost kernel: BPF: size=104 vlen=12
> Jul 25 13:44:04 localhost kernel: BPF:
> Jul 25 13:44:04 localhost kernel: BPF: Invalid name
> Jul 25 13:44:04 localhost kernel: BPF:
>
> Are these debugging logs above still displayed? Maybe remove them too
> or only display them when all required things are in place and users
> opt-in to use this new infrastructure?
Kernel doesn't print them to console. These messages go to BTF verifier log
supplied by user space. It's not clear what process sends them to journalctl.
prev parent reply other threads:[~2023-07-26 16:19 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-25 19:11 ct state module issue Matt Zagrabelny
2023-07-25 19:33 ` Florian Westphal
2023-07-25 19:57 ` Alexei Starovoitov
2023-07-26 7:39 ` Pablo Neira Ayuso
2023-07-26 16:19 ` Alexei Starovoitov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAADnVQ+PHXbeGjm6ty6f7KbGZGinvng1SG_BdDh85T=1tvHoXQ@mail.gmail.com' \
--to=alexei.starovoitov@gmail.com \
--cc=bpf@vger.kernel.org \
--cc=fw@strlen.de \
--cc=mzagrabe@d.umn.edu \
--cc=netfilter@vger.kernel.org \
--cc=pablo@netfilter.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).