From: Hangbin Liu <hangbin.liu@linux.dev>
To: Matthieu Baerts <matttbe@kernel.org>
Cc: MPTCP Linux <mptcp@lists.linux.dev>
Subject: Re: [PATCH mptcp-next 2/2] selftests: mptcp: convert iptables to nftables for mptcp_join.sh
Date: Mon, 7 Sep 2026 09:02:10 +0800 [thread overview]
Message-ID: <ap4NEvXYLC1U8hqO@fedora> (raw)
In-Reply-To: <aa5678f7-7089-4049-9120-6604372667ac@kernel.org>
Hi Matthieu,
On Fri, Sep 04, 2026 at 06:40:02PM +0200, Matthieu Baerts wrote:
> >
> > Yes, if not in purpose, I feel flush the whole table is dangerous.
> > Some rules may still in using in later testing.
>
> Indeed. But in our case, each subtest uses a dedicated netns. Plus only
> some tests add Netfilter rules. At the end, it is clearer to delete a
> specific rule, but I think that makes sense only if the nft_handle var
> is set locally, and used a few lines below.
>
> If a global nft_handle var is used, that doesn't seem clear, and I think
> it would be clearer/easier to:
>
> - either delete a specific rule (but I don't think that's supported)
>
> - get the handle from the test and use it to delete the rule
>
> - or flush the table.
>
> So up to you, but probably best to avoid using nft_handle as global var.
Thanks, endpoint_tests is the only test that could delete iptables rules.
I use the nft_handle mainly because the iptables also delete rules with
specific match (iptables -D OUTPUT -s .. -p tcp -j REJECT) other than flush
the table directly.
endpoint_tests
- reset_with_tcp_filter
- iptables -D
- iptables -I
- iptables -D
- reset_with_events
- iptables -I
- iptables -D
- reset_with_tcp_filter
- iptables -D
While from the logic it should be safe to flush the tables. I can avoid the
nft_handle in v4 (after v3 review). Just one question, why we use
iptables -I here? Is there any intend? If not I will use "add" instead of
"insert" in nft rules.
> > However, I cannot perform a reset on the b4 branch, and git rebase also failed.
> > These steps have blocked me a little. I have to manually recreate the b4 branch,
> > or perhaps avoid using b4 when working on mptcp changes.
>
> You need to use `|git rebase --onto` instead, e.g.
>
> git fetch origin # adapt here and below if needed
For export branch, I think git fetch is not enough? I have to reset
to latest net/net-next merge commit and pull on that.
> git rebase --onto origin/export "$(b4 prep --show-info base-commit)"
Yes, it works! New git usage learned :)
>
> Can you check if it works for you, please? (so I can update the wiki
> page if needed)
>
> The alternative is to use `for-review`, with a continuous history, see:
>
> https://github.com/multipath-tcp/mptcp_net-next/wiki/Git-Branches
I will try this tree next time
Thanks
Hangbin
next prev parent reply other threads:[~2026-09-07 1:02 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-02 6:52 [PATCH mptcp-next 0/2] selftests: mptcp: convert iptables to nftables Hangbin Liu
2026-09-02 6:52 ` [PATCH mptcp-next 1/2] selftests: mptcp: convert iptables to nftables for mptcp_sockopt.sh Hangbin Liu
2026-09-02 7:02 ` sashiko-bot
2026-09-02 7:47 ` Hangbin Liu
2026-09-02 9:17 ` Matthieu Baerts
2026-09-03 2:15 ` Hangbin Liu
2026-09-02 6:52 ` [PATCH mptcp-next 2/2] selftests: mptcp: convert iptables to nftables for mptcp_join.sh Hangbin Liu
2026-09-02 10:00 ` Matthieu Baerts
2026-09-03 2:02 ` Hangbin Liu
2026-09-03 6:35 ` Hangbin Liu
2026-09-03 6:54 ` Florian Westphal
2026-09-03 7:35 ` Hangbin Liu
2026-09-03 9:28 ` Matthieu Baerts
2026-09-04 8:01 ` Hangbin Liu
2026-09-04 16:40 ` Matthieu Baerts
2026-09-07 1:02 ` Hangbin Liu [this message]
2026-09-07 5:50 ` Matthieu Baerts
2026-09-07 6:59 ` Hangbin Liu
2026-09-07 7:55 ` Matthieu Baerts
2026-09-02 7:23 ` [PATCH mptcp-next 0/2] selftests: mptcp: convert iptables to nftables MPTCP CI
2026-09-02 8:14 ` MPTCP CI
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=ap4NEvXYLC1U8hqO@fedora \
--to=hangbin.liu@linux.dev \
--cc=matttbe@kernel.org \
--cc=mptcp@lists.linux.dev \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.