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

Bug#1051592: linux: Regression - upgrade to 6.1.52-1 breaks nftables



Hi Salvatore,

Salvatore Bonaccorso schrieb am 11.09.2023 22:20 (GMT +02:00):

> 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 <pablo@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 <kevinrich1337@gmail.com>
>     Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
>     Signed-off-by: Florian Westphal <fw@strlen.de>
>     Signed-off-by: Sasha Levin <sashal@kernel.org>

Hehe, yes, I was just about to write you the same. My test build with this one reverted lets me load the ruleset again.

Would you like to take this upstream? I was just about to file a report in netfilter's bugzilla, but since you also worked on it as well, I don't mean to interfere...

I'll try to further reduce my test ruleset to see what actually triggers this.

Thanks and regards,

Timo


Reply to: