Re: MPTCP upstreaming, week of 26-Sept-2022

[Paolo Abeni <pabeni@redhat.com>]

On Tue, 2022-09-27 at 10:07 +0200, Matthieu Baerts wrote:
> Hi Mat, Paolo,
> 
> On 27/09/2022 02:10, Mat Martineau wrote:
> > 
> > Matthieu and Paolo -
> > 
> > I upstreamed the fastopen changes for net-next today, so those are in
> > the patchwork queue for the netdev maintainers:
> > 
> > https://patchwork.kernel.org/project/netdevbpf/list/?series=680767
> 
> Thank you!
> 
> > The other patch sets we discussed upstreaming in the meeting last week
> > were:
> > 
> >     - Fixes for -net:
> > 
> >         - [6e827151a607] mptcp: factor out __mptcp_close() without
> > socket lock (Menglong Dong)
> >         - [62b5536f77f6] mptcp: fix unreleased socket in accept queue
> > (Menglong Dong):
> >             - can wait a bit more and can be sent next week
> > 
> > 
> >     - Features for net-next:
> > 
> >         - [ef4a93571133] mptcp: propagate fastclose error (Paolo Abeni)
> >         - [885cab8b5203] mptcp: use fastclose on more edge scenarios
> > (Paolo Abeni)
> >         - [13c82c8b0d9f] selftests: mptcp: update and extend fastclose
> > test-cases (Paolo Abeni):
> >             - can wait a bit, Paolo would like to have a look at the
> > modification on packetdrill side
> > 
> > 
> > I'm planning to upstream the two -net patches on Tuesday unless someone
> > objects.
> 
> Sounds good to me.
> 
> > The net-next patches are slightly more complicated:
> > 
> >  * They were updated with a squash-to patch today
> >  * Need to wait until fastopen patches are merged
> 
> We should at least wait for the fastopen patches to be applied I suppose.
> 
> >  * There is a minor conflict with the -net patches (just diff context)
> >    in "mptcp: use fastclose on more edge scenarios".
> > 
> > 
> > Regarding the conflict, I could wait until Friday for a likely
> > net/net-next sync.
> > 
> > Another option is to modify the patch slightly by moving
> > mptcp_check_readable() before __mptcp_check_send_data_fin(), it doesn't
> > make the diff any larger and avoids the -net conflict. What do you think?
> 
> We can also add a note in the commit and explain how to fix this
> conflict. I think the function is at the right place but it can also be
> moved if it eases stuff.


I think there is no rush for that patches. If the net patches will land
upstream soon, they will be likely merged by EoW. If there will be
another RC, we can rebase the net-next and send out still for 6.1,
othewise the fastclose patches can wait IMHO a few more weeks.

Cheers,

Paolo