Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.kernel > #83811 > unrolled thread
| Started by | XXX XXX <tauromenion@gmail.com> |
|---|---|
| First post | 2024-09-02 23:20 +0200 |
| Last post | 2024-09-07 09:20 +0200 |
| Articles | 4 — 2 participants |
Back to article view | Back to linux.debian.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Bug#1070685: linux-image-6.1.0-21-amd64: Found Trace in the logs about br_netfilter and nf_conntrack XXX XXX <tauromenion@gmail.com> - 2024-09-02 23:20 +0200
Bug#1070685: linux-image-6.1.0-21-amd64: Found Trace in the logs about br_netfilter and nf_conntrack Salvatore Bonaccorso <carnil@debian.org> - 2024-09-06 22:10 +0200
Bug#1070685: linux-image-6.1.0-21-amd64: Found Trace in the logs about br_netfilter and nf_conntrack XXX XXX <tauromenion@gmail.com> - 2024-09-06 23:00 +0200
Bug#1070685: linux-image-6.1.0-21-amd64: Found Trace in the logs about br_netfilter and nf_conntrack Salvatore Bonaccorso <carnil@debian.org> - 2024-09-07 09:20 +0200
| From | XXX XXX <tauromenion@gmail.com> |
|---|---|
| Date | 2024-09-02 23:20 +0200 |
| Subject | Bug#1070685: linux-image-6.1.0-21-amd64: Found Trace in the logs about br_netfilter and nf_conntrack |
| Message-ID | <JimCR-9x4h-9@gated-at.bofh.it> |
Hi,
this bug seems to be fixed in linux kernel 6.1.107,
I suspect the commit that fixed it is:
commit 6dcc8ba8a6074bb79040f502dc66ad23a58a1c86
Author: Florian Westphal <fw@strlen.de>
Date: Wed Aug 7 21:28:41 2024 +0200
netfilter: nf_queue: drop packets with cloned unconfirmed conntracks
[ Upstream commit 7d8dc1c7be8d3509e8f5164dd5df64c8e34d7eeb ]
Conntrack assumes an unconfirmed entry (not yet committed to global hash
table) has a refcount of 1 and is not visible to other cores.
With multicast forwarding this assumption breaks down because such
skbs get cloned after being picked up, i.e. ct->use refcount is > 1.
Likewise, bridge netfilter will clone broad/mutlicast frames and
all frames in case they need to be flood-forwarded during learning
phase.
For ip multicast forwarding or plain bridge flood-forward this will
"work" because packets don't leave softirq and are implicitly
serialized.
With nfqueue this no longer holds true, the packets get queued
and can be reinjected in arbitrary ways.
Disable this feature, I see no other solution.
After this patch, nfqueue cannot queue packets except the last
multicast/broadcast packet.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Best regards,
Tito Ragusa
[toc] | [next] | [standalone]
| From | Salvatore Bonaccorso <carnil@debian.org> |
|---|---|
| Date | 2024-09-06 22:10 +0200 |
| Message-ID | <JjNrj-ausc-1@gated-at.bofh.it> |
| In reply to | #83811 |
Control: tags -1 + moreinfo
Hi,
On Mon, Sep 02, 2024 at 11:09:42PM +0200, XXX XXX wrote:
> Hi,
> this bug seems to be fixed in linux kernel 6.1.107,
> I suspect the commit that fixed it is:
>
> commit 6dcc8ba8a6074bb79040f502dc66ad23a58a1c86
> Author: Florian Westphal <fw@strlen.de>
> Date: Wed Aug 7 21:28:41 2024 +0200
>
> netfilter: nf_queue: drop packets with cloned unconfirmed conntracks
>
> [ Upstream commit 7d8dc1c7be8d3509e8f5164dd5df64c8e34d7eeb ]
>
> Conntrack assumes an unconfirmed entry (not yet committed to global hash
> table) has a refcount of 1 and is not visible to other cores.
>
> With multicast forwarding this assumption breaks down because such
> skbs get cloned after being picked up, i.e. ct->use refcount is > 1.
>
> Likewise, bridge netfilter will clone broad/mutlicast frames and
> all frames in case they need to be flood-forwarded during learning
> phase.
>
> For ip multicast forwarding or plain bridge flood-forward this will
> "work" because packets don't leave softirq and are implicitly
> serialized.
>
> With nfqueue this no longer holds true, the packets get queued
> and can be reinjected in arbitrary ways.
>
> Disable this feature, I see no other solution.
>
> After this patch, nfqueue cannot queue packets except the last
> multicast/broadcast packet.
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Signed-off-by: Florian Westphal <fw@strlen.de>
> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
> Signed-off-by: Sasha Levin <sashal@kernel.org>
Would you be able to confirm this? In case this is true, then this
would imply that the issue should be visible as well current testing
until <= 6.10.7-1.
Regards,
Salvatore
[toc] | [prev] | [next] | [standalone]
| From | XXX XXX <tauromenion@gmail.com> |
|---|---|
| Date | 2024-09-06 23:00 +0200 |
| Message-ID | <JjOdH-auI6-7@gated-at.bofh.it> |
| In reply to | #83862 |
On Fri, 6 Sep 2024 22:04:27 +0200
Salvatore Bonaccorso <carnil@debian.org> wrote:
> Control: tags -1 + moreinfo
>
> Hi,
>
> On Mon, Sep 02, 2024 at 11:09:42PM +0200, XXX XXX wrote:
> > Hi,
> > this bug seems to be fixed in linux kernel 6.1.107,
> > I suspect the commit that fixed it is:
> >
> > commit 6dcc8ba8a6074bb79040f502dc66ad23a58a1c86
> > Author: Florian Westphal <fw@strlen.de>
> > Date: Wed Aug 7 21:28:41 2024 +0200
> >
> > netfilter: nf_queue: drop packets with cloned unconfirmed conntracks
> >
> > [ Upstream commit 7d8dc1c7be8d3509e8f5164dd5df64c8e34d7eeb ]
> >
> > Conntrack assumes an unconfirmed entry (not yet committed to global hash
> > table) has a refcount of 1 and is not visible to other cores.
> >
> > With multicast forwarding this assumption breaks down because such
> > skbs get cloned after being picked up, i.e. ct->use refcount is > 1.
> >
> > Likewise, bridge netfilter will clone broad/mutlicast frames and
> > all frames in case they need to be flood-forwarded during learning
> > phase.
> >
> > For ip multicast forwarding or plain bridge flood-forward this will
> > "work" because packets don't leave softirq and are implicitly
> > serialized.
> >
> > With nfqueue this no longer holds true, the packets get queued
> > and can be reinjected in arbitrary ways.
> >
> > Disable this feature, I see no other solution.
> >
> > After this patch, nfqueue cannot queue packets except the last
> > multicast/broadcast packet.
> >
> > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> > Signed-off-by: Florian Westphal <fw@strlen.de>
> > Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
> > Signed-off-by: Sasha Levin <sashal@kernel.org>
>
> Would you be able to confirm this? In case this is true, then this
> would imply that the issue should be visible as well current testing
> until <= 6.10.7-1.
>
> Regards,
> Salvatore
Hi,
for sure it was visible in linux-image-6.10.6+bpo-amd64 that I tried from
stable backports after the trace popped up again after upgrading to
linux-image-6.1.0-25-amd64.
So by checking the changelog for the source file and line shown in the traces on kernel.org
I've spotted this patch that was interesting because I use suricata in nfqueue
mode and because the trace happened always at boot (during the learning phase).
So I first erroneously I tried 6.1.106 and the trace was still there
and then 6.1.107 and it was gone.
Hope this helps.
Ciao,
Tito
[toc] | [prev] | [next] | [standalone]
| From | Salvatore Bonaccorso <carnil@debian.org> |
|---|---|
| Date | 2024-09-07 09:20 +0200 |
| Message-ID | <JjXTH-aAM0-3@gated-at.bofh.it> |
| In reply to | #83863 |
Hi,
On Fri, Sep 06, 2024 at 10:47:04PM +0200, XXX XXX wrote:
> On Fri, 6 Sep 2024 22:04:27 +0200
> Salvatore Bonaccorso <carnil@debian.org> wrote:
>
> > Control: tags -1 + moreinfo
> >
> > Hi,
> >
> > On Mon, Sep 02, 2024 at 11:09:42PM +0200, XXX XXX wrote:
> > > Hi,
> > > this bug seems to be fixed in linux kernel 6.1.107,
> > > I suspect the commit that fixed it is:
> > >
> > > commit 6dcc8ba8a6074bb79040f502dc66ad23a58a1c86
> > > Author: Florian Westphal <fw@strlen.de>
> > > Date: Wed Aug 7 21:28:41 2024 +0200
> > >
> > > netfilter: nf_queue: drop packets with cloned unconfirmed conntracks
> > >
> > > [ Upstream commit 7d8dc1c7be8d3509e8f5164dd5df64c8e34d7eeb ]
> > >
> > > Conntrack assumes an unconfirmed entry (not yet committed to global hash
> > > table) has a refcount of 1 and is not visible to other cores.
> > >
> > > With multicast forwarding this assumption breaks down because such
> > > skbs get cloned after being picked up, i.e. ct->use refcount is > 1.
> > >
> > > Likewise, bridge netfilter will clone broad/mutlicast frames and
> > > all frames in case they need to be flood-forwarded during learning
> > > phase.
> > >
> > > For ip multicast forwarding or plain bridge flood-forward this will
> > > "work" because packets don't leave softirq and are implicitly
> > > serialized.
> > >
> > > With nfqueue this no longer holds true, the packets get queued
> > > and can be reinjected in arbitrary ways.
> > >
> > > Disable this feature, I see no other solution.
> > >
> > > After this patch, nfqueue cannot queue packets except the last
> > > multicast/broadcast packet.
> > >
> > > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> > > Signed-off-by: Florian Westphal <fw@strlen.de>
> > > Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
> > > Signed-off-by: Sasha Levin <sashal@kernel.org>
> >
> > Would you be able to confirm this? In case this is true, then this
> > would imply that the issue should be visible as well current testing
> > until <= 6.10.7-1.
> >
> > Regards,
> > Salvatore
>
> Hi,
>
> for sure it was visible in linux-image-6.10.6+bpo-amd64 that I tried from
> stable backports after the trace popped up again after upgrading to
> linux-image-6.1.0-25-amd64.
> So by checking the changelog for the source file and line shown in the traces on kernel.org
> I've spotted this patch that was interesting because I use suricata in nfqueue
> mode and because the trace happened always at boot (during the learning phase).
> So I first erroneously I tried 6.1.106 and the trace was still there
> and then 6.1.107 and it was gone.
> Hope this helps.
Yes thanks. One option to get a final confirmation and proper closure
tracking, would be if you can cherry-pick the commit on top of the
6.1.106-3 version and see if it resolved the issue.
You could proceed as described in
https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#id-1.6.6.4
Regards,
Salvatore
[toc] | [prev] | [standalone]
Back to top | Article view | linux.debian.kernel
csiph-web