Re: [PATCH mptcp-next] Revert "mptcp: add data lock for sk timers"

[Mat Martineau <mathew.j.martineau@linux.intel.com>]

[-- Attachment #1: Type: text/plain, Size: 4305 bytes --]

On Tue, 10 May 2022, Matthieu Baerts wrote:

> Hi Mat,
>
> On 10/05/2022 02:11, Mat Martineau wrote:
>> On Fri, 6 May 2022, Matthieu Baerts wrote:
>>
>>> Hi Paolo, Mat,
>>>
>>> On 05/05/2022 19:12, Paolo Abeni wrote:
>>>> This reverts commit 4293248c6704b854bf816aa1967e433402bee11c.
>>>>
>>>> Additional locks are not needed, all the touched sections
>>>> are already under mptcp socket lock protection.
>>>
>>> Thank you for the patch and the review!
>>>
>>> Now in our tree (fixes for net-next) with Mat's RvB and a Fixes tag.
>>>
>>> New patches for t/upstream:
>>> - 2ff5e4eba944: Revert "mptcp: add data lock for sk timers"
>>> - Results: bc6528b2b1d7..22856348dac5 (export)
>>
>> This shows up in a different place in the export branch commit history
>> than I expected:
>>
>> * 1238ef9dd5ce (HEAD, tag: export/20220509T115202, mptcp-nn/export)
>> DO-NOT-MERGE: mptcp: enabled by default
>> * a89b2ebc4a26 DO-NOT-MERGE: mptcp: use kmalloc on kasan build
>> * 8adddf50a9e9 DO-NOT-MERGE: git markup: features other trees
>> * c0e05f5207ec selftests/bpf: add bpf_first test
>> * 90b2072ffc21 selftests/bpf: add bpf_first scheduler
>> * 2f547420d0f4 mptcp: add bpf_mptcp_sched_ops
>> * cf597ecbdb4b mptcp: add get_subflow wrappers
>> * 1b3d7a5f1f10 mptcp: add sched in mptcp_sock
>> * e31f54bd6183 mptcp: add a new sysctl scheduler
>> * 74d3c74494e6 mptcp: add struct mptcp_sched_ops
>> * 416cb433f1df selftests/bpf: verify first of struct mptcp_sock
>> * 57dcfb6f61ec selftests/bpf: verify ca_name of struct mptcp_sock
>> * 8996b41ffcd2 selftests/bpf: verify token of struct mptcp_sock
>> * f8f99d2ff6a7 selftests/bpf: test bpf_skc_to_mptcp_sock
>> * 3fb057749027 selftests/bpf: add MPTCP test base
>> * 1585ded1ef3d selftests/bpf: Enable CONFIG_IKCONFIG_PROC in config
>> * d4fc73d43d5b bpf: add bpf_skc_to_mptcp_sock_proto
>> * 581159326c14 bpf: expose is_mptcp flag to bpf_tcp_sock
>> * b20a348378e2 DO-NOT-MERGE: git markup: features net-next-next
>> * fa71bf0a2db6 selftests: mptcp: add MP_FAIL reset testcase
>> * fddb2da3de32 DO-NOT-MERGE: git markup: features net-next
>>
>> Expected to see the patch here.
>>
>> * 218186cd781d mptcp: sockopt: add TCP_DEFER_ACCEPT support
>> * 6d8839d159a7 DO-NOT-MERGE: git markup: fixes net-next
>> *   f858740fef1e TopGit-driven merge of branches:
>> |\
>> | * baa752231c4d DO-NOT-MERGE: git markup: end common net net-next
>> | * cad34cf702bc DO-NOT-MERGE: mptcp: add CI support
>> | * d7945d0bf36f DO-NOT-MERGE: git markup: fixes net
>> | * d8e908a27426 selftests: mptcp: add subflow limits test-cases
>> | * 001ce634cb09 mptcp: fix subflow accounting on close
>> | * ca2debea5aa8 net/sched: act_pedit: really ensure the skb is writable
>> | * 945110b5a812 DO-NOT-MERGE: git markup: fixes other trees
>> | * 55775678c466 x86/pm: Fix false positive kmemleak report in
>> msr_build_context()
>> | * 7a38d7853776 DO-NOT-MERGE: git markup: net
>> * | 4f43f697b6be Revert "mptcp: add data lock for sk timers"
>>
>>                  ^^^ but it's here instead
>>
>> * | f57e72f418df selftests: mptcp: fix a mp_fail test warning
>> * | 49161dcf2772 DO-NOT-MERGE: git markup: net-next
>> * |   c908565eecf2 (mptcp-nn/net-next) Merge tag
>> 'batadv-next-pullrequest-202205
>>
>>
>> Matthieu, is that what you intended?
>
> Yes, that was my initial intension: if there is an issue with a patch in
> net-next, we probably don't want to wait for a sync with -net to send
> the patch. So it is on top of net-next only. It is just in case we force
> a sync with -net evenn if net and net-next have not been recently sync yet.
>
> Do you prefer to have these patches on top of -net and net-next instead?
>

That is my preference for future mptcp-next patches, yes. But you don't 
need to re-arrange these two patches in the tree.

None of the patches staged for net-next (before or after the topgit-driven 
merge) are waiting for a sync unless there's a known conflict with a 
pending patch in export-net.

When I prepare a series to send to the netdev list I often "git rebase 
--onto net-next/master <from-sha> <to-sha>" the relevant patches, and I 
don't want a merge commit in the middle of the range. It's also helpful to 
find out if there are any surprise conflicts at that stage so I can 
consider that before sending.

--
Mat Martineau
Intel