Message ID | 20240215-upstream-net-20240215-misc-fixes-v1-3-8c01a55d8f6a@kernel.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-67494-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:c619:b0:108:e6aa:91d0 with SMTP id hn25csp53070dyb; Thu, 15 Feb 2024 10:58:19 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCV8JGH7UowGkaUAPOniX2hrheyQErGF4YPD/gRe2WD4Je7Myr6GRp3Y7HD8J2bG2/5F/nVVlj4gDDlXKofmXDyvX7iuhA== X-Google-Smtp-Source: AGHT+IH/hFrZGFa/BpCYNbeidgz7ULeWY/8XOOmQCssojl4E7avG2g2sLJxESrEAhln+IdO7xQT9 X-Received: by 2002:a17:90a:f2c9:b0:298:d0ed:e13a with SMTP id gt9-20020a17090af2c900b00298d0ede13amr3709637pjb.15.1708023498839; Thu, 15 Feb 2024 10:58:18 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1708023498; cv=pass; d=google.com; s=arc-20160816; b=VbOO8+4KItGNV70OPvicWnlKHHwf1vxEVlOam86Z5HgRpbim+tkB22y6jlMPvY5vYf EHnRCmDiorFOyQd2WN5cNOsS5lCTDV5s+iUr5xcN3l1aDQO7jivkFkq7Pobh2Af81DL+ MV4Y8RXZhBh9kBlmI4ZmarUmrsLyE1afMEaHj0tDoMncb9dWP963OGLdt8Wmu6wLOz4s fTQuMEERvANT0qUj6SotqXUBaXw1/GgzxeBmQkKlSzr4fCAQf7r59KLqCP2Mog+ppDkj u0xRShIbnoz+q/ocrCyAX+oWJ2U08/IFSkpKALctSa1irksmval/X+S2u7I2u/jTWKTe AQ5g== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:list-unsubscribe:list-subscribe:list-id:precedence :subject:date:from:dkim-signature; bh=L6lIoGryQ0LDRyNW48v27i1rlHfcHYdFthdLA3f9QII=; fh=KHm+5J6+rvFM2Sm0w04dr96065e5NgZLO7CcIOTCxTg=; b=Y0Rg4CCX93k1gGkyuk4DQoNxw7gxAkA06+j54SL+38KuTvhCHIYjnZNAppxlz8+BJ1 lvuScSxPfDFt0/DH22N5bgRWaMo7p1wUJM/TXV629prjDMf2wrka/ghmamUj6IA8qtUp bQQgkjNRPDfSh0I89Wzhg7GJWgIGdGoXk4CO7El3D3yhZy/X/QZSTJaETk3Gg/Brl6dX ZaLh8Caoo7I1oNoQ9JNx5j1paq4+ffPo3b4WSUn5S8i2BA4kuLeUtrIICm797pDbhPoQ jP8KIhLIXseApopP8forxVxmV2kQ3Iw5Y9FtNfbOnq1CV1L8ijoWwH/YUifsCR7/gN5u DfUg==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=hqdgbkKA; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-67494-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-67494-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [2604:1380:40f1:3f00::1]) by mx.google.com with ESMTPS id pb10-20020a17090b3c0a00b00296db812c4dsi1681125pjb.116.2024.02.15.10.58.18 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 15 Feb 2024 10:58:18 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-67494-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=hqdgbkKA; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-67494-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-67494-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sy.mirrors.kernel.org (Postfix) with ESMTPS id C9BC2B23692 for <ouuuleilei@gmail.com>; Thu, 15 Feb 2024 18:27:06 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 8AD4D13AA23; Thu, 15 Feb 2024 18:25:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="hqdgbkKA" Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CB24913A86C; Thu, 15 Feb 2024 18:25:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708021547; cv=none; b=FwOhGb34KXwflr+5CBFmMw0Mfubf5+KPQ8DEW2WjPIbGOPhYvDWh1XoXnk6W/J+IZDV7j5PIFMa8xW3yWmhUseZKqObQfh1QrGnP01B65EvSuXSFVnAKA+yW7H11wWraQpfkrmyQmnyazzx/nYvI/irC5/hALUoBVGflqIbVFGk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708021547; c=relaxed/simple; bh=O9TaPCeVsjOq9jAAugHSwpNIaCX6JMv1ouUykBv8gj4=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=XrC0uxlfJV+BErA7XvBrUIUiS5RjkRrcdQNbs9Q+wvRRsHAZITMkWK6fMCasa7JZDS8SRZfDOtcaSvsCC7YFumlPKuOkNyj2oGixEJBb16C/kW6wxqHfdwanZyRSShVI3srkdR2H+46Tb7P54ChU+BFYsaiLJ5xcxtzyNzsltNg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=hqdgbkKA; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 77328C43609; Thu, 15 Feb 2024 18:25:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1708021547; bh=O9TaPCeVsjOq9jAAugHSwpNIaCX6JMv1ouUykBv8gj4=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=hqdgbkKAclztcu1xQRYG5SwRNJ7ZTkGqDGETsTIo85MclM/Y+UlJmyJFDI+lhumWL ZOxv2dd/1qSHYPuFazvJBD5EDLz0NXcwX8UmSkZP79zygVUbkxXRr51z8fcTNTn7Iv MKIXrQG/GYm6NRL4z2VHRrjjvYOboYe4RRe3oXLqFGTbukkF2ncBaPG+o48tHopYrB GmDqT0esOcC01P3siGojYFcKyedjUuXGCCOgtwyMteCXjXqCsV1tkhxRddCpESewXa Og5CX31merFzpt8biF5tqb26ZKAjNiEYWRVHneSnNQPLDgiWJDPYijgzXe3pWKroZJ gr91bOtOZE9UQ== From: "Matthieu Baerts (NGI0)" <matttbe@kernel.org> Date: Thu, 15 Feb 2024 19:25:30 +0100 Subject: [PATCH net 03/13] mptcp: fix lockless access in subflow ULP diag Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20240215-upstream-net-20240215-misc-fixes-v1-3-8c01a55d8f6a@kernel.org> References: <20240215-upstream-net-20240215-misc-fixes-v1-0-8c01a55d8f6a@kernel.org> In-Reply-To: <20240215-upstream-net-20240215-misc-fixes-v1-0-8c01a55d8f6a@kernel.org> To: mptcp@lists.linux.dev, Mat Martineau <martineau@kernel.org>, Geliang Tang <geliang@kernel.org>, "David S. Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>, Davide Caratti <dcaratti@redhat.com>, Shuah Khan <shuah@kernel.org> Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, "Matthieu Baerts (NGI0)" <matttbe@kernel.org>, stable@vger.kernel.org, Boris Pismenny <borisp@nvidia.com>, John Fastabend <john.fastabend@gmail.com> X-Mailer: b4 0.12.4 X-Developer-Signature: v=1; a=openpgp-sha256; l=3080; i=matttbe@kernel.org; h=from:subject:message-id; bh=xtj9AwzwqPCqP5Friqh0vCOkOhD544GhNiZf9ekwIjU=; b=owEBbQKS/ZANAwAIAfa3gk9CaaBzAcsmYgBlzlcc3yITjm+xGd3bhfD6bwGDlnT5JnEpdqxGj PhywDxO5umJAjMEAAEIAB0WIQToy4X3aHcFem4n93r2t4JPQmmgcwUCZc5XHAAKCRD2t4JPQmmg c56hD/4jXp5hKXebFuJVEHHOfdxqoyu+ghz9oB7ej8NcNVkhVR71JwrdGzHhiOtZ5VHdCcioCrT snpg2EkpSCaNk0rj3FWP622w2st+18qVuicEQ4KM77Dl8lxFeQRgYWWWXuHanuH7YSsYl0lKudW T4IsCOgKJybSYMTlXxR8MgOVOPeVaEXG5qYmHDxB4itbeVbJoU9Py2PEl9N5h+3KrMqlqNzTxYW DHR3ZeBjz+6J4/OrxL1xUnK6KovOqZ8IEJIb/lFRicruFZcx5P41qyylcFfp7OKYEvw1t5UaopQ FlnPJvkZZVDeNXEhNf1SEsXGUG/MIReDU3MhToj5sHrw0npRicV+H2QazESpa3jgrR2z0GtemRi dTgN8ZZ6b1BrUik+FCLDPCdcbj7RQvzUalUkIktJAyUKoOhnlJWsYhz/Mt04Xi4BhH2hOGTTdTZ vjVdh/1Rr8OorQA7zSglQosfdtuXTrzd4+cQD2SuhrYPkMJy2iepEfgCZzBZlc30MeXRAd6g+8p X2i18RDY34ZT/GmHA/rsq1FswcULdaIjcf4jy8ibt946SIMff923FweP4OjYp24dFH2IgMbJve4 GG8j+/vDfkYKf8oRPj+cEESKJFmWE5zGEAs0n90PevE0DIaHcAn11CZxEKdl1ic1062ABiwho1z YbJXY9Lv8sojGlQ== X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1790992448683837542 X-GMAIL-MSGID: 1790992448683837542 |
Series |
mptcp: misc. fixes for v6.8
|
|
Commit Message
Matthieu Baerts (NGI0)
Feb. 15, 2024, 6:25 p.m. UTC
From: Paolo Abeni <pabeni@redhat.com> Since the introduction of the subflow ULP diag interface, the dump callback accessed all the subflow data with lockless. We need either to annotate all the read and write operation accordingly, or acquire the subflow socket lock. Let's do latter, even if slower, to avoid a diffstat havoc. Fixes: 5147dfb50832 ("mptcp: allow dumping subflow context to userspace") Cc: stable@vger.kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Mat Martineau <martineau@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> --- Notes: - This patch modifies the existing ULP API. No better solutions have been found for -net, and there is some similar prior art, see commit 0df48c26d841 ("tcp: add tcpi_bytes_acked to tcp_info"). Please also note that TLS ULP Diag has likely the same issue. To: Boris Pismenny <borisp@nvidia.com> To: John Fastabend <john.fastabend@gmail.com> --- include/net/tcp.h | 2 +- net/mptcp/diag.c | 6 +++++- net/tls/tls_main.c | 2 +- 3 files changed, 7 insertions(+), 3 deletions(-)
Comments
On Thu, Feb 15, 2024 at 7:25 PM Matthieu Baerts (NGI0) <matttbe@kernel.org> wrote: > > From: Paolo Abeni <pabeni@redhat.com> > > Since the introduction of the subflow ULP diag interface, the > dump callback accessed all the subflow data with lockless. > > We need either to annotate all the read and write operation accordingly, > or acquire the subflow socket lock. Let's do latter, even if slower, to > avoid a diffstat havoc. > > Fixes: 5147dfb50832 ("mptcp: allow dumping subflow context to userspace") > Cc: stable@vger.kernel.org > Signed-off-by: Paolo Abeni <pabeni@redhat.com> > Reviewed-by: Mat Martineau <martineau@kernel.org> > Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> > --- > Notes: > - This patch modifies the existing ULP API. No better solutions have > been found for -net, and there is some similar prior art, see > commit 0df48c26d841 ("tcp: add tcpi_bytes_acked to tcp_info"). > > Please also note that TLS ULP Diag has likely the same issue. > To: Boris Pismenny <borisp@nvidia.com> > To: John Fastabend <john.fastabend@gmail.com> > --- > include/net/tcp.h | 2 +- > net/mptcp/diag.c | 6 +++++- > net/tls/tls_main.c | 2 +- > 3 files changed, 7 insertions(+), 3 deletions(-) > > diff --git a/include/net/tcp.h b/include/net/tcp.h > index dd78a1181031..f6eba9652d01 100644 > --- a/include/net/tcp.h > +++ b/include/net/tcp.h > @@ -2506,7 +2506,7 @@ struct tcp_ulp_ops { > /* cleanup ulp */ > void (*release)(struct sock *sk); > /* diagnostic */ > - int (*get_info)(const struct sock *sk, struct sk_buff *skb); > + int (*get_info)(struct sock *sk, struct sk_buff *skb); > size_t (*get_info_size)(const struct sock *sk); > /* clone ulp */ > void (*clone)(const struct request_sock *req, struct sock *newsk, > diff --git a/net/mptcp/diag.c b/net/mptcp/diag.c > index a536586742f2..e57c5f47f035 100644 > --- a/net/mptcp/diag.c > +++ b/net/mptcp/diag.c > @@ -13,17 +13,19 @@ > #include <uapi/linux/mptcp.h> > #include "protocol.h" > > -static int subflow_get_info(const struct sock *sk, struct sk_buff *skb) > +static int subflow_get_info(struct sock *sk, struct sk_buff *skb) > { > struct mptcp_subflow_context *sf; > struct nlattr *start; > u32 flags = 0; > + bool slow; > int err; > > start = nla_nest_start_noflag(skb, INET_ULP_INFO_MPTCP); > if (!start) > return -EMSGSIZE; > > + slow = lock_sock_fast(sk); > rcu_read_lock(); I am afraid lockdep is not happy with this change. Paolo, we probably need the READ_ONCE() annotations after all.
On Mon, Feb 19, 2024 at 6:21 PM Eric Dumazet <edumazet@google.com> wrote: > > On Thu, Feb 15, 2024 at 7:25 PM Matthieu Baerts (NGI0) > <matttbe@kernel.org> wrote: > > > > From: Paolo Abeni <pabeni@redhat.com> > > > > Since the introduction of the subflow ULP diag interface, the > > dump callback accessed all the subflow data with lockless. > > > > We need either to annotate all the read and write operation accordingly, > > or acquire the subflow socket lock. Let's do latter, even if slower, to > > avoid a diffstat havoc. > > > > Fixes: 5147dfb50832 ("mptcp: allow dumping subflow context to userspace") > > Cc: stable@vger.kernel.org > > Signed-off-by: Paolo Abeni <pabeni@redhat.com> > > Reviewed-by: Mat Martineau <martineau@kernel.org> > > Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> > > --- > > Notes: > > - This patch modifies the existing ULP API. No better solutions have > > been found for -net, and there is some similar prior art, see > > commit 0df48c26d841 ("tcp: add tcpi_bytes_acked to tcp_info"). > > > > Please also note that TLS ULP Diag has likely the same issue. > > To: Boris Pismenny <borisp@nvidia.com> > > To: John Fastabend <john.fastabend@gmail.com> > > --- > > include/net/tcp.h | 2 +- > > net/mptcp/diag.c | 6 +++++- > > net/tls/tls_main.c | 2 +- > > 3 files changed, 7 insertions(+), 3 deletions(-) > > > > diff --git a/include/net/tcp.h b/include/net/tcp.h > > index dd78a1181031..f6eba9652d01 100644 > > --- a/include/net/tcp.h > > +++ b/include/net/tcp.h > > @@ -2506,7 +2506,7 @@ struct tcp_ulp_ops { > > /* cleanup ulp */ > > void (*release)(struct sock *sk); > > /* diagnostic */ > > - int (*get_info)(const struct sock *sk, struct sk_buff *skb); > > + int (*get_info)(struct sock *sk, struct sk_buff *skb); > > size_t (*get_info_size)(const struct sock *sk); > > /* clone ulp */ > > void (*clone)(const struct request_sock *req, struct sock *newsk, > > diff --git a/net/mptcp/diag.c b/net/mptcp/diag.c > > index a536586742f2..e57c5f47f035 100644 > > --- a/net/mptcp/diag.c > > +++ b/net/mptcp/diag.c > > @@ -13,17 +13,19 @@ > > #include <uapi/linux/mptcp.h> > > #include "protocol.h" > > > > -static int subflow_get_info(const struct sock *sk, struct sk_buff *skb) > > +static int subflow_get_info(struct sock *sk, struct sk_buff *skb) > > { > > struct mptcp_subflow_context *sf; > > struct nlattr *start; > > u32 flags = 0; > > + bool slow; > > int err; > > > > start = nla_nest_start_noflag(skb, INET_ULP_INFO_MPTCP); > > if (!start) > > return -EMSGSIZE; > > > > + slow = lock_sock_fast(sk); > > rcu_read_lock(); > > I am afraid lockdep is not happy with this change. > > Paolo, we probably need the READ_ONCE() annotations after all. Or perhaps something like the following would be enough. diff --git a/net/mptcp/diag.c b/net/mptcp/diag.c index 6ff6f14674aa2941bc04c680bacd9f79fc65060d..7017dd60659dc7133318c1c82e3f429bea3a5d57 100644 --- a/net/mptcp/diag.c +++ b/net/mptcp/diag.c @@ -21,6 +21,9 @@ static int subflow_get_info(struct sock *sk, struct sk_buff *skb) bool slow; int err; + if (inet_sk_state_load(sk) == TCP_LISTEN) + return 0; + start = nla_nest_start_noflag(skb, INET_ULP_INFO_MPTCP); if (!start) return -EMSGSIZE;
On Mon, 2024-02-19 at 18:35 +0100, Eric Dumazet wrote: > On Mon, Feb 19, 2024 at 6:21 PM Eric Dumazet <edumazet@google.com> wrote: > > > > On Thu, Feb 15, 2024 at 7:25 PM Matthieu Baerts (NGI0) > > <matttbe@kernel.org> wrote: > > > > > > From: Paolo Abeni <pabeni@redhat.com> > > > > > > Since the introduction of the subflow ULP diag interface, the > > > dump callback accessed all the subflow data with lockless. > > > > > > We need either to annotate all the read and write operation accordingly, > > > or acquire the subflow socket lock. Let's do latter, even if slower, to > > > avoid a diffstat havoc. > > > > > > Fixes: 5147dfb50832 ("mptcp: allow dumping subflow context to userspace") > > > Cc: stable@vger.kernel.org > > > Signed-off-by: Paolo Abeni <pabeni@redhat.com> > > > Reviewed-by: Mat Martineau <martineau@kernel.org> > > > Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> > > > --- > > > Notes: > > > - This patch modifies the existing ULP API. No better solutions have > > > been found for -net, and there is some similar prior art, see > > > commit 0df48c26d841 ("tcp: add tcpi_bytes_acked to tcp_info"). > > > > > > Please also note that TLS ULP Diag has likely the same issue. > > > To: Boris Pismenny <borisp@nvidia.com> > > > To: John Fastabend <john.fastabend@gmail.com> > > > --- > > > include/net/tcp.h | 2 +- > > > net/mptcp/diag.c | 6 +++++- > > > net/tls/tls_main.c | 2 +- > > > 3 files changed, 7 insertions(+), 3 deletions(-) > > > > > > diff --git a/include/net/tcp.h b/include/net/tcp.h > > > index dd78a1181031..f6eba9652d01 100644 > > > --- a/include/net/tcp.h > > > +++ b/include/net/tcp.h > > > @@ -2506,7 +2506,7 @@ struct tcp_ulp_ops { > > > /* cleanup ulp */ > > > void (*release)(struct sock *sk); > > > /* diagnostic */ > > > - int (*get_info)(const struct sock *sk, struct sk_buff *skb); > > > + int (*get_info)(struct sock *sk, struct sk_buff *skb); > > > size_t (*get_info_size)(const struct sock *sk); > > > /* clone ulp */ > > > void (*clone)(const struct request_sock *req, struct sock *newsk, > > > diff --git a/net/mptcp/diag.c b/net/mptcp/diag.c > > > index a536586742f2..e57c5f47f035 100644 > > > --- a/net/mptcp/diag.c > > > +++ b/net/mptcp/diag.c > > > @@ -13,17 +13,19 @@ > > > #include <uapi/linux/mptcp.h> > > > #include "protocol.h" > > > > > > -static int subflow_get_info(const struct sock *sk, struct sk_buff *skb) > > > +static int subflow_get_info(struct sock *sk, struct sk_buff *skb) > > > { > > > struct mptcp_subflow_context *sf; > > > struct nlattr *start; > > > u32 flags = 0; > > > + bool slow; > > > int err; > > > > > > start = nla_nest_start_noflag(skb, INET_ULP_INFO_MPTCP); > > > if (!start) > > > return -EMSGSIZE; > > > > > > + slow = lock_sock_fast(sk); > > > rcu_read_lock(); > > > > I am afraid lockdep is not happy with this change. > > > > Paolo, we probably need the READ_ONCE() annotations after all. > > Or perhaps something like the following would be enough. > > diff --git a/net/mptcp/diag.c b/net/mptcp/diag.c > index 6ff6f14674aa2941bc04c680bacd9f79fc65060d..7017dd60659dc7133318c1c82e3f429bea3a5d57 > 100644 > --- a/net/mptcp/diag.c > +++ b/net/mptcp/diag.c > @@ -21,6 +21,9 @@ static int subflow_get_info(struct sock *sk, struct > sk_buff *skb) > bool slow; > int err; > > + if (inet_sk_state_load(sk) == TCP_LISTEN) > + return 0; > + > start = nla_nest_start_noflag(skb, INET_ULP_INFO_MPTCP); > if (!start) > return -EMSGSIZE; Thanks for the head-up. This later option looks preferable, to avoid quit a bit of noise with _ONCE annotation. Is there a syzkaller splat I could look at? if it landed on the ML, I missed it. Thanks! Paolo
On Mon, Feb 19, 2024 at 7:04 PM Paolo Abeni <pabeni@redhat.com> wrote: > > On Mon, 2024-02-19 at 18:35 +0100, Eric Dumazet wrote: > > On Mon, Feb 19, 2024 at 6:21 PM Eric Dumazet <edumazet@google.com> wrote: > > > > > > On Thu, Feb 15, 2024 at 7:25 PM Matthieu Baerts (NGI0) > > > <matttbe@kernel.org> wrote: > > > > > > > > From: Paolo Abeni <pabeni@redhat.com> > > > > > > > > Since the introduction of the subflow ULP diag interface, the > > > > dump callback accessed all the subflow data with lockless. > > > > > > > > We need either to annotate all the read and write operation accordingly, > > > > or acquire the subflow socket lock. Let's do latter, even if slower, to > > > > avoid a diffstat havoc. > > > > > > > > Fixes: 5147dfb50832 ("mptcp: allow dumping subflow context to userspace") > > > > Cc: stable@vger.kernel.org > > > > Signed-off-by: Paolo Abeni <pabeni@redhat.com> > > > > Reviewed-by: Mat Martineau <martineau@kernel.org> > > > > Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> > > > > --- > > > > Notes: > > > > - This patch modifies the existing ULP API. No better solutions have > > > > been found for -net, and there is some similar prior art, see > > > > commit 0df48c26d841 ("tcp: add tcpi_bytes_acked to tcp_info"). > > > > > > > > Please also note that TLS ULP Diag has likely the same issue. > > > > To: Boris Pismenny <borisp@nvidia.com> > > > > To: John Fastabend <john.fastabend@gmail.com> > > > > --- > > > > include/net/tcp.h | 2 +- > > > > net/mptcp/diag.c | 6 +++++- > > > > net/tls/tls_main.c | 2 +- > > > > 3 files changed, 7 insertions(+), 3 deletions(-) > > > > > > > > diff --git a/include/net/tcp.h b/include/net/tcp.h > > > > index dd78a1181031..f6eba9652d01 100644 > > > > --- a/include/net/tcp.h > > > > +++ b/include/net/tcp.h > > > > @@ -2506,7 +2506,7 @@ struct tcp_ulp_ops { > > > > /* cleanup ulp */ > > > > void (*release)(struct sock *sk); > > > > /* diagnostic */ > > > > - int (*get_info)(const struct sock *sk, struct sk_buff *skb); > > > > + int (*get_info)(struct sock *sk, struct sk_buff *skb); > > > > size_t (*get_info_size)(const struct sock *sk); > > > > /* clone ulp */ > > > > void (*clone)(const struct request_sock *req, struct sock *newsk, > > > > diff --git a/net/mptcp/diag.c b/net/mptcp/diag.c > > > > index a536586742f2..e57c5f47f035 100644 > > > > --- a/net/mptcp/diag.c > > > > +++ b/net/mptcp/diag.c > > > > @@ -13,17 +13,19 @@ > > > > #include <uapi/linux/mptcp.h> > > > > #include "protocol.h" > > > > > > > > -static int subflow_get_info(const struct sock *sk, struct sk_buff *skb) > > > > +static int subflow_get_info(struct sock *sk, struct sk_buff *skb) > > > > { > > > > struct mptcp_subflow_context *sf; > > > > struct nlattr *start; > > > > u32 flags = 0; > > > > + bool slow; > > > > int err; > > > > > > > > start = nla_nest_start_noflag(skb, INET_ULP_INFO_MPTCP); > > > > if (!start) > > > > return -EMSGSIZE; > > > > > > > > + slow = lock_sock_fast(sk); > > > > rcu_read_lock(); > > > > > > I am afraid lockdep is not happy with this change. > > > > > > Paolo, we probably need the READ_ONCE() annotations after all. > > > > Or perhaps something like the following would be enough. > > > > diff --git a/net/mptcp/diag.c b/net/mptcp/diag.c > > index 6ff6f14674aa2941bc04c680bacd9f79fc65060d..7017dd60659dc7133318c1c82e3f429bea3a5d57 > > 100644 > > --- a/net/mptcp/diag.c > > +++ b/net/mptcp/diag.c > > @@ -21,6 +21,9 @@ static int subflow_get_info(struct sock *sk, struct > > sk_buff *skb) > > bool slow; > > int err; > > > > + if (inet_sk_state_load(sk) == TCP_LISTEN) > > + return 0; > > + > > start = nla_nest_start_noflag(skb, INET_ULP_INFO_MPTCP); > > if (!start) > > return -EMSGSIZE; > > Thanks for the head-up. This later option looks preferable, to avoid > quit a bit of noise with _ONCE annotation. Is there a syzkaller splat I > could look at? if it landed on the ML, I missed it. > Not landed yet, here is the splat : ====================================================== WARNING: possible circular locking dependency detected 6.8.0-rc4-syzkaller-00212-g40b9385dd8e6 #0 Not tainted ------------------------------------------------------ syz-executor.2/24141 is trying to acquire lock: ffff888045870130 (k-sk_lock-AF_INET6){+.+.}-{0:0}, at: tcp_diag_put_ulp net/ipv4/tcp_diag.c:100 [inline] ffff888045870130 (k-sk_lock-AF_INET6){+.+.}-{0:0}, at: tcp_diag_get_aux+0x738/0x830 net/ipv4/tcp_diag.c:137 but task is already holding lock: ffffc9000135e488 (&h->lhash2[i].lock){+.+.}-{2:2}, at: spin_lock include/linux/spinlock.h:351 [inline] ffffc9000135e488 (&h->lhash2[i].lock){+.+.}-{2:2}, at: inet_diag_dump_icsk+0x39f/0x1f80 net/ipv4/inet_diag.c:1038 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&h->lhash2[i].lock){+.+.}-{2:2}: lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754 __raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline] _raw_spin_lock+0x2e/0x40 kernel/locking/spinlock.c:154 spin_lock include/linux/spinlock.h:351 [inline] __inet_hash+0x335/0xbe0 net/ipv4/inet_hashtables.c:743 inet_csk_listen_start+0x23a/0x320 net/ipv4/inet_connection_sock.c:1261 __inet_listen_sk+0x2a2/0x770 net/ipv4/af_inet.c:217 inet_listen+0xa3/0x110 net/ipv4/af_inet.c:239 rds_tcp_listen_init+0x3fd/0x5a0 net/rds/tcp_listen.c:316 rds_tcp_init_net+0x141/0x320 net/rds/tcp.c:577 ops_init+0x352/0x610 net/core/net_namespace.c:136 __register_pernet_operations net/core/net_namespace.c:1214 [inline] register_pernet_operations+0x2cb/0x660 net/core/net_namespace.c:1283 register_pernet_device+0x33/0x80 net/core/net_namespace.c:1370 rds_tcp_init+0x62/0xd0 net/rds/tcp.c:735 do_one_initcall+0x238/0x830 init/main.c:1236 do_initcall_level+0x157/0x210 init/main.c:1298 do_initcalls+0x3f/0x80 init/main.c:1314 kernel_init_freeable+0x42f/0x5d0 init/main.c:1551 kernel_init+0x1d/0x2a0 init/main.c:1441 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:242 -> #0 (k-sk_lock-AF_INET6){+.+.}-{0:0}: check_prev_add kernel/locking/lockdep.c:3134 [inline] check_prevs_add kernel/locking/lockdep.c:3253 [inline] validate_chain+0x18ca/0x58e0 kernel/locking/lockdep.c:3869 __lock_acquire+0x1345/0x1fd0 kernel/locking/lockdep.c:5137 lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754 lock_sock_fast include/net/sock.h:1723 [inline] subflow_get_info+0x166/0xd20 net/mptcp/diag.c:28 tcp_diag_put_ulp net/ipv4/tcp_diag.c:100 [inline] tcp_diag_get_aux+0x738/0x830 net/ipv4/tcp_diag.c:137 inet_sk_diag_fill+0x10ed/0x1e00 net/ipv4/inet_diag.c:345 inet_diag_dump_icsk+0x55b/0x1f80 net/ipv4/inet_diag.c:1061 __inet_diag_dump+0x211/0x3a0 net/ipv4/inet_diag.c:1263 inet_diag_dump_compat+0x1c1/0x2d0 net/ipv4/inet_diag.c:1371 netlink_dump+0x59b/0xc80 net/netlink/af_netlink.c:2264 __netlink_dump_start+0x5df/0x790 net/netlink/af_netlink.c:2370 netlink_dump_start include/linux/netlink.h:338 [inline] inet_diag_rcv_msg_compat+0x209/0x4c0 net/ipv4/inet_diag.c:1405 sock_diag_rcv_msg+0xe7/0x410 netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543 sock_diag_rcv+0x2a/0x40 net/core/sock_diag.c:280 netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367 netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584 ___sys_sendmsg net/socket.c:2638 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667 do_syscall_64+0xf9/0x240 entry_SYSCALL_64_after_hwframe+0x6f/0x77 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&h->lhash2[i].lock); lock(k-sk_lock-AF_INET6); lock(&h->lhash2[i].lock); lock(k-sk_lock-AF_INET6); *** DEADLOCK *** 5 locks held by syz-executor.2/24141: #0: ffffffff8f380bc8 (sock_diag_mutex){+.+.}-{3:3}, at: sock_diag_rcv+0x1b/0x40 net/core/sock_diag.c:279 #1: ffffffff8f380a28 (sock_diag_table_mutex){+.+.}-{3:3}, at: sock_diag_rcv_msg+0xc6/0x410 net/core/sock_diag.c:259 #2: ffff8880586f5680 (nlk_cb_mutex-SOCK_DIAG){+.+.}-{3:3}, at: netlink_dump+0xde/0xc80 net/netlink/af_netlink.c:2211 #3: ffffffff8f464568 (inet_diag_table_mutex){+.+.}-{3:3}, at: inet_diag_lock_handler net/ipv4/inet_diag.c:63 [inline] #3: ffffffff8f464568 (inet_diag_table_mutex){+.+.}-{3:3}, at: __inet_diag_dump+0x191/0x3a0 net/ipv4/inet_diag.c:1261 #4: ffffc9000135e488 (&h->lhash2[i].lock){+.+.}-{2:2}, at: spin_lock include/linux/spinlock.h:351 [inline] #4: ffffc9000135e488 (&h->lhash2[i].lock){+.+.}-{2:2}, at: inet_diag_dump_icsk+0x39f/0x1f80 net/ipv4/inet_diag.c:1038 stack backtrace: CPU: 0 PID: 24141 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-00212-g40b9385dd8e6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1e7/0x2e0 lib/dump_stack.c:106 check_noncircular+0x36a/0x4a0 kernel/locking/lockdep.c:2187 check_prev_add kernel/locking/lockdep.c:3134 [inline] check_prevs_add kernel/locking/lockdep.c:3253 [inline] validate_chain+0x18ca/0x58e0 kernel/locking/lockdep.c:3869 __lock_acquire+0x1345/0x1fd0 kernel/locking/lockdep.c:5137 lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754 lock_sock_fast include/net/sock.h:1723 [inline] subflow_get_info+0x166/0xd20 net/mptcp/diag.c:28 tcp_diag_put_ulp net/ipv4/tcp_diag.c:100 [inline] tcp_diag_get_aux+0x738/0x830 net/ipv4/tcp_diag.c:137 inet_sk_diag_fill+0x10ed/0x1e00 net/ipv4/inet_diag.c:345 inet_diag_dump_icsk+0x55b/0x1f80 net/ipv4/inet_diag.c:1061 __inet_diag_dump+0x211/0x3a0 net/ipv4/inet_diag.c:1263 inet_diag_dump_compat+0x1c1/0x2d0 net/ipv4/inet_diag.c:1371 netlink_dump+0x59b/0xc80 net/netlink/af_netlink.c:2264 __netlink_dump_start+0x5df/0x790 net/netlink/af_netlink.c:2370 netlink_dump_start include/linux/netlink.h:338 [inline] inet_diag_rcv_msg_compat+0x209/0x4c0 net/ipv4/inet_diag.c:1405 sock_diag_rcv_msg+0xe7/0x410 netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543 sock_diag_rcv+0x2a/0x40 net/core/sock_diag.c:280 netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367 netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584 ___sys_sendmsg net/socket.c:2638 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667 do_syscall_64+0xf9/0x240 entry_SYSCALL_64_after_hwframe+0x6f/0x77 RIP: 0033:0x7fbc4c07dda9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fbc4ce750c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007fbc4c1abf80 RCX: 00007fbc4c07dda9 RDX: 0000000000000000 RSI: 0000000020000000 RDI: 0000000000000004 RBP: 00007fbc4c0ca47a R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000000b R14: 00007fbc4c1abf80 R15: 00007ffcc3d92258 </TASK> BUG: sleeping function called from invalid context at net/core/sock.c:3554 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 24141, name: syz-executor.2 preempt_count: 1, expected: 0 RCU nest depth: 0, expected: 0 INFO: lockdep is turned off. Preemption disabled at: [<0000000000000000>] 0x0 CPU: 0 PID: 24141 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-00212-g40b9385dd8e6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1e7/0x2e0 lib/dump_stack.c:106 __might_resched+0x5d3/0x780 kernel/sched/core.c:10176 __lock_sock_fast+0x31/0xe0 net/core/sock.c:3554 lock_sock_fast include/net/sock.h:1725 [inline] subflow_get_info+0x172/0xd20 net/mptcp/diag.c:28 tcp_diag_put_ulp net/ipv4/tcp_diag.c:100 [inline] tcp_diag_get_aux+0x738/0x830 net/ipv4/tcp_diag.c:137 inet_sk_diag_fill+0x10ed/0x1e00 net/ipv4/inet_diag.c:345 inet_diag_dump_icsk+0x55b/0x1f80 net/ipv4/inet_diag.c:1061 __inet_diag_dump+0x211/0x3a0 net/ipv4/inet_diag.c:1263 inet_diag_dump_compat+0x1c1/0x2d0 net/ipv4/inet_diag.c:1371 netlink_dump+0x59b/0xc80 net/netlink/af_netlink.c:2264 __netlink_dump_start+0x5df/0x790 net/netlink/af_netlink.c:2370 netlink_dump_start include/linux/netlink.h:338 [inline] inet_diag_rcv_msg_compat+0x209/0x4c0 net/ipv4/inet_diag.c:1405 sock_diag_rcv_msg+0xe7/0x410 netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543 sock_diag_rcv+0x2a/0x40 net/core/sock_diag.c:280 netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367 netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584 ___sys_sendmsg net/socket.c:2638 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667 do_syscall_64+0xf9/0x240 entry_SYSCALL_64_after_hwframe+0x6f/0x77 RIP: 0033:0x7fbc4c07dda9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fbc4ce750c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007fbc4c1abf80 RCX: 00007fbc4c07dda9 RDX: 0000000000000000 RSI: 0000000020000000 RDI: 0000000000000004 RBP: 00007fbc4c0ca47a R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000000b R14: 00007fbc4c1abf80 R15: 00007ffcc3d92258
On Mon, 2024-02-19 at 19:33 +0100, Eric Dumazet wrote: > On Mon, Feb 19, 2024 at 7:04 PM Paolo Abeni <pabeni@redhat.com> wrote: > > Thanks for the head-up. This later option looks preferable, to avoid > > quit a bit of noise with _ONCE annotation. Is there a syzkaller splat I > > could look at? if it landed on the ML, I missed it. > > > > Not landed yet, here is the splat : > > ====================================================== > WARNING: possible circular locking dependency detected > 6.8.0-rc4-syzkaller-00212-g40b9385dd8e6 #0 Not tainted > ------------------------------------------------------ > syz-executor.2/24141 is trying to acquire lock: > ffff888045870130 (k-sk_lock-AF_INET6){+.+.}-{0:0}, at: > tcp_diag_put_ulp net/ipv4/tcp_diag.c:100 [inline] > ffff888045870130 (k-sk_lock-AF_INET6){+.+.}-{0:0}, at: > tcp_diag_get_aux+0x738/0x830 net/ipv4/tcp_diag.c:137 > > but task is already holding lock: > ffffc9000135e488 (&h->lhash2[i].lock){+.+.}-{2:2}, at: spin_lock > include/linux/spinlock.h:351 [inline] > ffffc9000135e488 (&h->lhash2[i].lock){+.+.}-{2:2}, at: > inet_diag_dump_icsk+0x39f/0x1f80 net/ipv4/inet_diag.c:1038 [Sorry for the latency]. Yes it looks like that checking the listener status will work. I can test and send the formal patch - with the due credits! - or do you prefer otherwise? Thanks! Paolo
On Tue, Feb 20, 2024 at 6:33 PM Paolo Abeni <pabeni@redhat.com> wrote: > > On Mon, 2024-02-19 at 19:33 +0100, Eric Dumazet wrote: > > On Mon, Feb 19, 2024 at 7:04 PM Paolo Abeni <pabeni@redhat.com> wrote: > > > Thanks for the head-up. This later option looks preferable, to avoid > > > quit a bit of noise with _ONCE annotation. Is there a syzkaller splat I > > > could look at? if it landed on the ML, I missed it. > > > > > > > Not landed yet, here is the splat : > > > > ====================================================== > > WARNING: possible circular locking dependency detected > > 6.8.0-rc4-syzkaller-00212-g40b9385dd8e6 #0 Not tainted > > ------------------------------------------------------ > > syz-executor.2/24141 is trying to acquire lock: > > ffff888045870130 (k-sk_lock-AF_INET6){+.+.}-{0:0}, at: > > tcp_diag_put_ulp net/ipv4/tcp_diag.c:100 [inline] > > ffff888045870130 (k-sk_lock-AF_INET6){+.+.}-{0:0}, at: > > tcp_diag_get_aux+0x738/0x830 net/ipv4/tcp_diag.c:137 > > > > but task is already holding lock: > > ffffc9000135e488 (&h->lhash2[i].lock){+.+.}-{2:2}, at: spin_lock > > include/linux/spinlock.h:351 [inline] > > ffffc9000135e488 (&h->lhash2[i].lock){+.+.}-{2:2}, at: > > inet_diag_dump_icsk+0x39f/0x1f80 net/ipv4/inet_diag.c:1038 > > [Sorry for the latency]. Yes it looks like that checking the listener > status will work. I can test and send the formal patch - with the due > credits! - or do you prefer otherwise? Sure, please send the formal patch, thank you.
diff --git a/include/net/tcp.h b/include/net/tcp.h index dd78a1181031..f6eba9652d01 100644 --- a/include/net/tcp.h +++ b/include/net/tcp.h @@ -2506,7 +2506,7 @@ struct tcp_ulp_ops { /* cleanup ulp */ void (*release)(struct sock *sk); /* diagnostic */ - int (*get_info)(const struct sock *sk, struct sk_buff *skb); + int (*get_info)(struct sock *sk, struct sk_buff *skb); size_t (*get_info_size)(const struct sock *sk); /* clone ulp */ void (*clone)(const struct request_sock *req, struct sock *newsk, diff --git a/net/mptcp/diag.c b/net/mptcp/diag.c index a536586742f2..e57c5f47f035 100644 --- a/net/mptcp/diag.c +++ b/net/mptcp/diag.c @@ -13,17 +13,19 @@ #include <uapi/linux/mptcp.h> #include "protocol.h" -static int subflow_get_info(const struct sock *sk, struct sk_buff *skb) +static int subflow_get_info(struct sock *sk, struct sk_buff *skb) { struct mptcp_subflow_context *sf; struct nlattr *start; u32 flags = 0; + bool slow; int err; start = nla_nest_start_noflag(skb, INET_ULP_INFO_MPTCP); if (!start) return -EMSGSIZE; + slow = lock_sock_fast(sk); rcu_read_lock(); sf = rcu_dereference(inet_csk(sk)->icsk_ulp_data); if (!sf) { @@ -69,11 +71,13 @@ static int subflow_get_info(const struct sock *sk, struct sk_buff *skb) } rcu_read_unlock(); + unlock_sock_fast(sk, slow); nla_nest_end(skb, start); return 0; nla_failure: rcu_read_unlock(); + unlock_sock_fast(sk, slow); nla_nest_cancel(skb, start); return err; } diff --git a/net/tls/tls_main.c b/net/tls/tls_main.c index 1c2c6800949d..b4674f03d71a 100644 --- a/net/tls/tls_main.c +++ b/net/tls/tls_main.c @@ -1003,7 +1003,7 @@ static u16 tls_user_config(struct tls_context *ctx, bool tx) return 0; } -static int tls_get_info(const struct sock *sk, struct sk_buff *skb) +static int tls_get_info(struct sock *sk, struct sk_buff *skb) { u16 version, cipher_type; struct tls_context *ctx;