Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1624251 > unrolled thread

[PATCH 3.18 010/145] sctp: avoid BUG_ON on sctp_wait_for_sndbuf

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH 3.18 010/145] sctp: avoid BUG_ON on sctp_wait_for_sndbuf Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-04-16 13:00 +0200
    Re: [PATCH 3.18 010/145] sctp: avoid BUG_ON on sctp_wait_for_sndbuf Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> - 2017-04-17 22:10 +0200
      Re: [PATCH 3.18 010/145] sctp: avoid BUG_ON on sctp_wait_for_sndbuf Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-04-18 07:00 +0200
        Re: [PATCH 3.18 010/145] sctp: avoid BUG_ON on sctp_wait_for_sndbuf Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-04-19 15:20 +0200

#1624251 — [PATCH 3.18 010/145] sctp: avoid BUG_ON on sctp_wait_for_sndbuf

3.18-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>


[ Upstream commit 2dcab598484185dea7ec22219c76dcdd59e3cb90 ]

Alexander Popov reported that an application may trigger a BUG_ON in
sctp_wait_for_sndbuf if the socket tx buffer is full, a thread is
waiting on it to queue more data and meanwhile another thread peels off
the association being used by the first thread.

This patch replaces the BUG_ON call with a proper error handling. It
will return -EPIPE to the original sendmsg call, similarly to what would
have been done if the association wasn't found in the first place.

Acked-by: Alexander Popov <alex.popov@linux.com>
Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Reviewed-by: Xin Long <lucien.xin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 net/sctp/socket.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -6962,7 +6962,8 @@ static int sctp_wait_for_sndbuf(struct s
 		 */
 		release_sock(sk);
 		current_timeo = schedule_timeout(current_timeo);
-		BUG_ON(sk != asoc->base.sk);
+		if (sk != asoc->base.sk)
+			goto do_error;
 		lock_sock(sk);
 
 		*timeo_p = current_timeo;

[toc] | [next] | [standalone]

#1624860

Em 16-04-2017 07:48, Greg Kroah-Hartman escreveu:
> 3.18-stable review patch.  If anyone has any objections, please let me know.
> 
> ------------------
> 
> From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> 
> 
> [ Upstream commit 2dcab598484185dea7ec22219c76dcdd59e3cb90 ]


Hi Greg. Are you also including dfcb9f4f99f1 ("sctp: deny peeloff 
operation on asocs with threads sleeping on it")
It's a follow-up fix for this one, would be good to have it too.

> 
> Alexander Popov reported that an application may trigger a BUG_ON in
> sctp_wait_for_sndbuf if the socket tx buffer is full, a thread is
> waiting on it to queue more data and meanwhile another thread peels off
> the association being used by the first thread.
> 
> This patch replaces the BUG_ON call with a proper error handling. It
> will return -EPIPE to the original sendmsg call, similarly to what would
> have been done if the association wasn't found in the first place.
> 
> Acked-by: Alexander Popov <alex.popov@linux.com>
> Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> Reviewed-by: Xin Long <lucien.xin@gmail.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
>   net/sctp/socket.c |    3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
> 
> --- a/net/sctp/socket.c
> +++ b/net/sctp/socket.c
> @@ -6962,7 +6962,8 @@ static int sctp_wait_for_sndbuf(struct s
>   		 */
>   		release_sock(sk);
>   		current_timeo = schedule_timeout(current_timeo);
> -		BUG_ON(sk != asoc->base.sk);
> +		if (sk != asoc->base.sk)
> +			goto do_error;
>   		lock_sock(sk);
>   
>   		*timeo_p = current_timeo;
> 
> 

[toc] | [prev] | [next] | [standalone]

#1625019

On Mon, Apr 17, 2017 at 05:00:50PM -0300, Marcelo Ricardo Leitner wrote:
> 
> 
> Em 16-04-2017 07:48, Greg Kroah-Hartman escreveu:
> > 3.18-stable review patch.  If anyone has any objections, please let me know.
> > 
> > ------------------
> > 
> > From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> > 
> > 
> > [ Upstream commit 2dcab598484185dea7ec22219c76dcdd59e3cb90 ]
> 
> 
> Hi Greg. Are you also including dfcb9f4f99f1 ("sctp: deny peeloff operation
> on asocs with threads sleeping on it")
> It's a follow-up fix for this one, would be good to have it too.

Interesting, I don't see that in any of the stable trees, nor in the
networking stable queue.  David, any objection to me queueing it up for
all of the stable kernels?  I think it somehow got missed.

thanks,

greg k-h

[toc] | [prev] | [next] | [standalone]

#1626105

On Tue, Apr 18, 2017 at 06:56:42AM +0200, Greg Kroah-Hartman wrote:
> On Mon, Apr 17, 2017 at 05:00:50PM -0300, Marcelo Ricardo Leitner wrote:
> > 
> > 
> > Em 16-04-2017 07:48, Greg Kroah-Hartman escreveu:
> > > 3.18-stable review patch.  If anyone has any objections, please let me know.
> > > 
> > > ------------------
> > > 
> > > From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> > > 
> > > 
> > > [ Upstream commit 2dcab598484185dea7ec22219c76dcdd59e3cb90 ]
> > 
> > 
> > Hi Greg. Are you also including dfcb9f4f99f1 ("sctp: deny peeloff operation
> > on asocs with threads sleeping on it")
> > It's a follow-up fix for this one, would be good to have it too.
> 
> Interesting, I don't see that in any of the stable trees, nor in the
> networking stable queue.  David, any objection to me queueing it up for
> all of the stable kernels?  I think it somehow got missed.

I've queued it up now in my trees, thanks.

greg k-h

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web