netdev - Re: [PATCH net-next 3/7] mptcp: update mptcp ack sequence from work queue

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.OSX.2.22.394.2002261610110.50710@tvtrimel-mobl2.amr.corp.intel.com>
Date:   Wed, 26 Feb 2020 16:10:43 -0800 (PST)
From:   Mat Martineau <mathew.j.martineau@...ux.intel.com>
To:     Florian Westphal <fw@...len.de>
cc:     netdev@...r.kernel.org
Subject: Re: [PATCH net-next 3/7] mptcp: update mptcp ack sequence from work
 queue


On Wed, 26 Feb 2020, Florian Westphal wrote:

> If userspace is not reading data, all the mptcp-level acks contain the
> ack_seq from the last time userspace read data rather than the most
> recent in-sequence value.
>
> This causes pointless retransmissions for data that is already queued.
>
> The reason for this is that all the mptcp protocol level processing
> happens at mptcp_recv time.
>
> This adds work queue to move skbs from the subflow sockets receive
> queue on the mptcp socket receive queue (which was not used so far).
>
> This allows us to announce the correct mptcp ack sequence in a timely
> fashion, even when the application does not call recv() on the mptcp socket
> for some time.
>
> We still wake userspace tasks waiting for POLLIN immediately:
> If the mptcp level receive queue is empty (because the work queue is
> still pending) it can be filled from in-sequence subflow sockets at
> recv time without a need to wait for the worker.
>
> The skb_orphan when moving skbs from subflow to mptcp level is needed,
> because the destructor (sock_rfree) relies on skb->sk (ssk!) lock
> being taken.
>
> A followup patch will add needed rmem accouting for the moved skbs.
>
> Other problem: In case application behaves as expected, and calls
> recv() as soon as mptcp socket becomes readable, the work queue will
> only waste cpu cycles.  This will also be addressed in followup patches.
>
> Signed-off-by: Florian Westphal <fw@...len.de>

Reviewed-by: Mat Martineau <mathew.j.martineau@...ux.intel.com>

--
Mat Martineau
Intel