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
| ||
|
Message-ID: <1831224a48dfbf54fb45fa56fce826d1d312700f.camel@redhat.com> Date: Mon, 06 Nov 2023 08:21:52 +0100 From: Paolo Abeni <pabeni@...hat.com> To: Eric Dumazet <edumazet@...gle.com>, Mat Martineau <martineau@...nel.org> Cc: Matthieu Baerts <matttbe@...nel.org>, "David S. Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org, mptcp@...ts.linux.dev Subject: Re: [PATCH net-next 9/9] mptcp: refactor sndbuf auto-tuning Hi, On Thu, 2023-11-02 at 18:19 +0100, Eric Dumazet wrote: > On Mon, Oct 23, 2023 at 10:45 PM Mat Martineau <martineau@...nel.org> wrote: > > > > From: Paolo Abeni <pabeni@...hat.com> > > > > The MPTCP protocol account for the data enqueued on all the subflows > > to the main socket send buffer, while the send buffer auto-tuning > > algorithm set the main socket send buffer size as the max size among > > the subflows. > > > > That causes bad performances when at least one subflow is sndbuf > > limited, e.g. due to very high latency, as the MPTCP scheduler can't > > even fill such buffer. > > > > Change the send-buffer auto-tuning algorithm to compute the main socket > > send buffer size as the sum of all the subflows buffer size. > > > > Reviewed-by: Mat Martineau <martineau@...nel.org> > > Signed-off-by: Paolo Abeni <pabeni@...hat.com> > > Signed-off-by: Mat Martineau <martineau@...nel.org > > ... > > > diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c > > index df208666fd19..2b43577f952e 100644 > > --- a/net/mptcp/subflow.c > > +++ b/net/mptcp/subflow.c > > @@ -421,6 +421,7 @@ static bool subflow_use_different_dport(struct mptcp_sock *msk, const struct soc > > > > void __mptcp_set_connected(struct sock *sk) > > { > > + __mptcp_propagate_sndbuf(sk, mptcp_sk(sk)->first); > > ->first can be NULL here, according to syzbot. I'm sorry for the latency on my side, I had a different kind of crash to handle here. Do you have a syzkaller report available? Or the call trace landing here? Thanks! Paolo
Powered by blists - more mailing lists