Re: Should the MIB_RMSUBFLOW commit go to -net?

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

On Fri, 24 Jun 2022, Matthieu Baerts wrote:

> Hi Mat, Paolo,
>
> On 24/06/2022 10:40, Paolo Abeni wrote:
>> On Thu, 2022-06-23 at 16:19 -0700, Mat Martineau wrote:
>>> I was preparing the patches we had agreed to be ready for net-next in the
>>> meeting today:
>>>
>>>          - [f1eb3f2cb4d2] mptcp: update MIB_RMSUBFLOW in cmd_sf_destroy (Geliang Tang)
>>>          - [f3c5dde10031] selftests: mptcp: userspace pm address tests (Geliang Tang)
>>>          - [92378ff55152] selftests: mptcp: userspace pm subflow tests (Geliang Tang)
>>>          - [1908a4ccaa2c] selftests: mptcp: avoid Terminated messages in userspace_pm (Geliang Tang)
>>>          - [bac5548c7c47] selftests: mptcp: update pm_nl_ctl usage header (Geliang Tang)
>>>
>>> I think the selftest commits are definitely best for net-next. But for the
>>> first one ("mptcp: update MIB_RMSUBFLOW in cmd_sf_destroy"), should we add
>>>
>>> Fixes: 702c2f646d42 ("mptcp: netlink: allow userspace-driven subflow establishment")
>>>
>>> and include that in a patch set for -net? Seems like it would be good to
>>> improve the MIB accuracy with the userspace PM in 5.19.
>>>
>>> Link to commit in patchwork:
>>> https://patchwork.kernel.org/project/mptcp/patch/723d61d82730b996132925686b43f9c3c79bc747.1655355422.git.geliang.tang@suse.com/
>>>
>>>
>>> If that patch goes to -net, it would also require waiting until the next
>>> net/net-next sync before sending the selftest patches listed above.
>>
>> I would vote for keeping the process simple and keeping all the above
>> patches on net-next.
>>
>> If we choose otherwise, I think we should also update a bit the
>> ("mptcp: update MIB_RMSUBFLOW in cmd_sf_destroy") commit message to
>> something more tuned for -net. Alike: "The user-space patch manager
>> currently miss the required update of the subflow destruction MIB,
>> address the issue "...
>
> I think all commits fixing something should have the "Fixes" tag and
> target "-net". That's not a must of course depending on the complexity
> and what the fix implies. This should simplify stable versions
> maintenance somehow if we know all fixes are explicitly linked to a
> feature: the stable team can do the backport if they think it makes
> sense to do that. We can also avoid messages like: ah yes, in v5.19,
> don't look at this MIB counter, it is not correct but that's fixed later
> in vX.Y.
>
> But I understand the issue with the sync of -net and net-next.
> Could it help to send the conflicting patch in both -net and net-next?
> 'git merge' might understand the same modification has been done on both
> side.
>
> Or explain in the commit message/cover letter there is a conflict with
> -net and the fix is not urgent?
>

I think it will be best to send it to -net with a modified commit message 
like Paolo suggests. The net/net-next sync shouldn't be a problem since 
we're at 5.19-rc4 and the dependent selftest fixes are not super urgent 
for net-next.

This patch to pm_userspace.c also fits in with the one pending commit in 
export-net and the 5 -net patches in patchwork.

--
Mat Martineau
Intel