Hi, On Mon, Sep 11, 2023 at 04:28:34PM +0200, Salvatore Bonaccorso wrote: > Control: found -1 5.10.191-1 > > On Mon, Sep 11, 2023 at 04:17:46PM +0200, Salvatore Bonaccorso wrote: > > Control: tags -1 + confirmed upstream > > > > Hi, > > > > On Mon, Sep 11, 2023 at 04:08:07PM +0200, Salvatore Bonaccorso wrote: > > > Control: tags -1 - moreinfo unreproducible > > > > > > Hi Timo, > > > > > > On Mon, Sep 11, 2023 at 03:15:18AM +0200, Timo Sigurdsson wrote: > > > > Hi, > > > > > > > > Salvatore Bonaccorso schrieb am 10.09.2023 12:21 (GMT +02:00): > > > > > > > > > Would it be possible to provide a minimal set of rules triggering the > > > > > issue? Can you reproduce the issue with the official build? > > > > > > > > So, I did some more testing on a different machine running the official > > > > build. My findings so far are: > > > > 1) Yes, I can reproduce the issue with the official build. > > > > 2) The issue depends on the ruleset. The minimal ruleset I have on that > > > > machine, doesn't trigger the issue, but when I copy over the ruleset > > > > from the machine I first observed this on, then I can reproduce it. > > > > > > > > I'm attaching a somewhat stripped down version of my original, rather > > > > complex ruleset. It's by no means a "minimal" reproducer, cause I > > > > haven't had the time yet to further reduce it in order to see what > > > > actually triggers it. But you should be able to observe that this > > > > ruleset loads just fine on linux 6.1.38-4, but doesn't anymore on > > > > 6.1.52-1. > > > > > > Thanks for providing it, this helps debugging the issue. > > > > > > > I also started looking into what commit could have introduced this. My > > > > first guess "netfilter: nft_dynset: disallow object maps" > > > > (23185c6aed1f) is wrong. Even with this one reverted, the issue occurs. > > > > I'll try another build with "netfilter: nf_tables: disallow rule > > > > addition to bound chain via NFTA_RULE_CHAIN_ID" (0ebc1064e487) reverted > > > > tomorrow evening... > > > > > > Thanks, as soon we have the introducing commit we can go to the next > > > step and check upstream. I cannot trigger the problem with 6.4.13-1 or > > > 6.5.2. > > > > The issue seems to be present already in 6.1.49-rc1, which I had still > > from local pareparations for the rebases. So the bisection needs to go > > to the upstream versions between 6.1.38 and 6.1.49 at least. > > Additionally the behaviour change is as well in 5.10.191-1 (and > 5.10.193 upstream), whereeas not triggering in 5.10.179. > > So to be on the safe side making the following statement: either this > is a real regression affecting several stable series or there is an > intentional upstream change uncovering an issue in ruleset. As the > behaviour is not in 6.5.2 for now considering it the first case.
Bisected the issue: $ git bisect log git bisect start # status: waiting for both good and bad commits # good: [61fd484b2cf6bc8022e8e5ea6f693a9991740ac2] Linux 6.1.38 git bisect good 61fd484b2cf6bc8022e8e5ea6f693a9991740ac2 # status: waiting for bad commit, 1 good commit known # bad: [1321ab403b38366a4cfb283145bb2c005becb1e5] Linux 6.1.45 git bisect bad 1321ab403b38366a4cfb283145bb2c005becb1e5 # good: [95d49f79e94d4fa8105c880a266789609f3e791a] ext4: only update i_reserved_data_blocks on successful block allocation git bisect good 95d49f79e94d4fa8105c880a266789609f3e791a # good: [f8b61a2c29fc70f64daad698cf09c1f79a0e39f9] drm/amd/display: Set minimum requirement for using PSR-SU on Rembrandt git bisect good f8b61a2c29fc70f64daad698cf09c1f79a0e39f9 # bad: [bd2decac7345134ea0bd3f4b978478ef53367cd8] mptcp: ensure subflow is unhashed before cleaning the backlog git bisect bad bd2decac7345134ea0bd3f4b978478ef53367cd8 # bad: [fe3409cd013cfd10d3e6787b49f33a5dda39cffd] RDMA/irdma: Fix op_type reporting in CQEs git bisect bad fe3409cd013cfd10d3e6787b49f33a5dda39cffd # good: [85c38ac62c1372cc1ab05426315aad61025d33ef] atheros: fix return value check in atl1_tso() git bisect good 85c38ac62c1372cc1ab05426315aad61025d33ef # bad: [539cf23cb48835c69cc3d22edff28b92bd82bb18] tipc: stop tipc crypto on failure in tipc_node_create git bisect bad 539cf23cb48835c69cc3d22edff28b92bd82bb18 # good: [1ecdbf2467ae4bc4df00c5cfab427cb1aaa5e3e1] x86/traps: Fix load_unaligned_zeropad() handling for shared TDX memory git bisect good 1ecdbf2467ae4bc4df00c5cfab427cb1aaa5e3e1 # bad: [7218974aba07ff60c646d5a512b02b871402b03e] mm: suppress mm fault logging if fatal signal already pending git bisect bad 7218974aba07ff60c646d5a512b02b871402b03e # good: [89a4d1a89751a0fbd520e64091873e19cc0979e8] netfilter: nft_set_rbtree: fix overlap expiration walk git bisect good 89a4d1a89751a0fbd520e64091873e19cc0979e8 # bad: [268cb07ef3ee17b5454a7c4b23376802c5b00c79] netfilter: nf_tables: disallow rule addition to bound chain via NFTA_RULE_CHAIN_ID git bisect bad 268cb07ef3ee17b5454a7c4b23376802c5b00c79 # good: [4237462a073e24f71c700f3e5929f07b6ee1bcaa] netfilter: nf_tables: skip immediate deactivate in _PREPARE_ERROR git bisect good 4237462a073e24f71c700f3e5929f07b6ee1bcaa # first bad commit: [268cb07ef3ee17b5454a7c4b23376802c5b00c79] netfilter: nf_tables: disallow rule addition to bound chain via NFTA_RULE_CHAIN_ID $ git bisect visualize commit 268cb07ef3ee17b5454a7c4b23376802c5b00c79 Author: Pablo Neira Ayuso <pa...@netfilter.org> Date: Sun Jul 23 16:41:48 2023 +0200 netfilter: nf_tables: disallow rule addition to bound chain via NFTA_RULE_CHAIN_ID [ Upstream commit 0ebc1064e4874d5987722a2ddbc18f94aa53b211 ] Bail out with EOPNOTSUPP when adding rule to bound chain via NFTA_RULE_CHAIN_ID. The following warning splat is shown when adding a rule to a deleted bound chain: WARNING: CPU: 2 PID: 13692 at net/netfilter/nf_tables_api.c:2013 nf_tables_chain_destroy+0x1f7/0x210 [nf_tables] CPU: 2 PID: 13692 Comm: chain-bound-rul Not tainted 6.1.39 #1 RIP: 0010:nf_tables_chain_destroy+0x1f7/0x210 [nf_tables] Fixes: d0e2c7de92c7 ("netfilter: nf_tables: add NFT_CHAIN_BINDING") Reported-by: Kevin Rich <kevinrich1...@gmail.com> Signed-off-by: Pablo Neira Ayuso <pa...@netfilter.org> Signed-off-by: Florian Westphal <f...@strlen.de> Signed-off-by: Sasha Levin <sas...@kernel.org> Regards, Salvatore