All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH net] sctp: allow delivering notifications after receiving SHUTDOWN
@ 2016-07-30  6:09 ` Xin Long
  0 siblings, 0 replies; 6+ messages in thread
From: Xin Long @ 2016-07-30  6:09 UTC (permalink / raw)
  To: network dev, linux-sctp
  Cc: davem, Marcelo Ricardo Leitner, Vlad Yasevich, daniel

Prior to this patch, once sctp received SHUTDOWN or shutdown with RD,
sk->sk_shutdown would be set with RCV_SHUTDOWN, and all events would
be dropped in sctp_ulpq_tail_event(). It would cause:

1. some notifications couldn't be received by users. like
   SCTP_SHUTDOWN_COMP generated by sctp_sf_do_4_C().

2. sctp would also never trigger sk_data_ready when the association
   was closed, making it harder to identify the end of the association
   by calling recvmsg() and getting an EOF. It was not convenient for
   kernel users.

The check here should be stopping delivering DATA chunks after receiving
SHUTDOWN, and stopping delivering ANY chunks after sctp_close().

So this patch is to allow notifications to enqueue into receive queue
even if sk->sk_shutdown is set to RCV_SHUTDOWN in sctp_ulpq_tail_event,
but if sk->sk_shutdown == RCV_SHUTDOWN | SEND_SHUTDOWN, it drops all
events.

Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
 net/sctp/ulpqueue.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/net/sctp/ulpqueue.c b/net/sctp/ulpqueue.c
index ec166d2..877e550 100644
--- a/net/sctp/ulpqueue.c
+++ b/net/sctp/ulpqueue.c
@@ -204,7 +204,9 @@ int sctp_ulpq_tail_event(struct sctp_ulpq *ulpq, struct sctp_ulpevent *event)
 	/* If the socket is just going to throw this away, do not
 	 * even try to deliver it.
 	 */
-	if (sock_flag(sk, SOCK_DEAD) || (sk->sk_shutdown & RCV_SHUTDOWN))
+	if (sk->sk_shutdown & RCV_SHUTDOWN &&
+	    (sk->sk_shutdown & SEND_SHUTDOWN ||
+	     !sctp_ulpevent_is_notification(event)))
 		goto out_free;
 
 	if (!sctp_ulpevent_is_notification(event)) {
-- 
2.1.0

^ permalink raw reply related	[flat|nested] 6+ messages in thread

* [PATCH net] sctp: allow delivering notifications after receiving SHUTDOWN
@ 2016-07-30  6:09 ` Xin Long
  0 siblings, 0 replies; 6+ messages in thread
From: Xin Long @ 2016-07-30  6:09 UTC (permalink / raw)
  To: network dev, linux-sctp
  Cc: davem, Marcelo Ricardo Leitner, Vlad Yasevich, daniel

Prior to this patch, once sctp received SHUTDOWN or shutdown with RD,
sk->sk_shutdown would be set with RCV_SHUTDOWN, and all events would
be dropped in sctp_ulpq_tail_event(). It would cause:

1. some notifications couldn't be received by users. like
   SCTP_SHUTDOWN_COMP generated by sctp_sf_do_4_C().

2. sctp would also never trigger sk_data_ready when the association
   was closed, making it harder to identify the end of the association
   by calling recvmsg() and getting an EOF. It was not convenient for
   kernel users.

The check here should be stopping delivering DATA chunks after receiving
SHUTDOWN, and stopping delivering ANY chunks after sctp_close().

So this patch is to allow notifications to enqueue into receive queue
even if sk->sk_shutdown is set to RCV_SHUTDOWN in sctp_ulpq_tail_event,
but if sk->sk_shutdown = RCV_SHUTDOWN | SEND_SHUTDOWN, it drops all
events.

Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
 net/sctp/ulpqueue.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/net/sctp/ulpqueue.c b/net/sctp/ulpqueue.c
index ec166d2..877e550 100644
--- a/net/sctp/ulpqueue.c
+++ b/net/sctp/ulpqueue.c
@@ -204,7 +204,9 @@ int sctp_ulpq_tail_event(struct sctp_ulpq *ulpq, struct sctp_ulpevent *event)
 	/* If the socket is just going to throw this away, do not
 	 * even try to deliver it.
 	 */
-	if (sock_flag(sk, SOCK_DEAD) || (sk->sk_shutdown & RCV_SHUTDOWN))
+	if (sk->sk_shutdown & RCV_SHUTDOWN &&
+	    (sk->sk_shutdown & SEND_SHUTDOWN ||
+	     !sctp_ulpevent_is_notification(event)))
 		goto out_free;
 
 	if (!sctp_ulpevent_is_notification(event)) {
-- 
2.1.0


^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [PATCH net] sctp: allow delivering notifications after receiving SHUTDOWN
  2016-07-30  6:09 ` Xin Long
@ 2016-07-30 13:22   ` Marcelo Ricardo Leitner
  -1 siblings, 0 replies; 6+ messages in thread
From: Marcelo Ricardo Leitner @ 2016-07-30 13:22 UTC (permalink / raw)
  To: Xin Long; +Cc: network dev, linux-sctp, davem, Vlad Yasevich, daniel

On Sat, Jul 30, 2016 at 02:09:09PM +0800, Xin Long wrote:
> Prior to this patch, once sctp received SHUTDOWN or shutdown with RD,
> sk->sk_shutdown would be set with RCV_SHUTDOWN, and all events would
> be dropped in sctp_ulpq_tail_event(). It would cause:
> 
> 1. some notifications couldn't be received by users. like
>    SCTP_SHUTDOWN_COMP generated by sctp_sf_do_4_C().
> 
> 2. sctp would also never trigger sk_data_ready when the association
>    was closed, making it harder to identify the end of the association
>    by calling recvmsg() and getting an EOF. It was not convenient for
>    kernel users.
> 
> The check here should be stopping delivering DATA chunks after receiving
> SHUTDOWN, and stopping delivering ANY chunks after sctp_close().
> 
> So this patch is to allow notifications to enqueue into receive queue
> even if sk->sk_shutdown is set to RCV_SHUTDOWN in sctp_ulpq_tail_event,
> but if sk->sk_shutdown == RCV_SHUTDOWN | SEND_SHUTDOWN, it drops all
> events.
> 
> Signed-off-by: Xin Long <lucien.xin@gmail.com>

Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>

> ---
>  net/sctp/ulpqueue.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/net/sctp/ulpqueue.c b/net/sctp/ulpqueue.c
> index ec166d2..877e550 100644
> --- a/net/sctp/ulpqueue.c
> +++ b/net/sctp/ulpqueue.c
> @@ -204,7 +204,9 @@ int sctp_ulpq_tail_event(struct sctp_ulpq *ulpq, struct sctp_ulpevent *event)
>  	/* If the socket is just going to throw this away, do not
>  	 * even try to deliver it.
>  	 */
> -	if (sock_flag(sk, SOCK_DEAD) || (sk->sk_shutdown & RCV_SHUTDOWN))
> +	if (sk->sk_shutdown & RCV_SHUTDOWN &&
> +	    (sk->sk_shutdown & SEND_SHUTDOWN ||
> +	     !sctp_ulpevent_is_notification(event)))
>  		goto out_free;
>  
>  	if (!sctp_ulpevent_is_notification(event)) {
> -- 
> 2.1.0
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH net] sctp: allow delivering notifications after receiving SHUTDOWN
@ 2016-07-30 13:22   ` Marcelo Ricardo Leitner
  0 siblings, 0 replies; 6+ messages in thread
From: Marcelo Ricardo Leitner @ 2016-07-30 13:22 UTC (permalink / raw)
  To: Xin Long; +Cc: network dev, linux-sctp, davem, Vlad Yasevich, daniel

On Sat, Jul 30, 2016 at 02:09:09PM +0800, Xin Long wrote:
> Prior to this patch, once sctp received SHUTDOWN or shutdown with RD,
> sk->sk_shutdown would be set with RCV_SHUTDOWN, and all events would
> be dropped in sctp_ulpq_tail_event(). It would cause:
> 
> 1. some notifications couldn't be received by users. like
>    SCTP_SHUTDOWN_COMP generated by sctp_sf_do_4_C().
> 
> 2. sctp would also never trigger sk_data_ready when the association
>    was closed, making it harder to identify the end of the association
>    by calling recvmsg() and getting an EOF. It was not convenient for
>    kernel users.
> 
> The check here should be stopping delivering DATA chunks after receiving
> SHUTDOWN, and stopping delivering ANY chunks after sctp_close().
> 
> So this patch is to allow notifications to enqueue into receive queue
> even if sk->sk_shutdown is set to RCV_SHUTDOWN in sctp_ulpq_tail_event,
> but if sk->sk_shutdown = RCV_SHUTDOWN | SEND_SHUTDOWN, it drops all
> events.
> 
> Signed-off-by: Xin Long <lucien.xin@gmail.com>

Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>

> ---
>  net/sctp/ulpqueue.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/net/sctp/ulpqueue.c b/net/sctp/ulpqueue.c
> index ec166d2..877e550 100644
> --- a/net/sctp/ulpqueue.c
> +++ b/net/sctp/ulpqueue.c
> @@ -204,7 +204,9 @@ int sctp_ulpq_tail_event(struct sctp_ulpq *ulpq, struct sctp_ulpevent *event)
>  	/* If the socket is just going to throw this away, do not
>  	 * even try to deliver it.
>  	 */
> -	if (sock_flag(sk, SOCK_DEAD) || (sk->sk_shutdown & RCV_SHUTDOWN))
> +	if (sk->sk_shutdown & RCV_SHUTDOWN &&
> +	    (sk->sk_shutdown & SEND_SHUTDOWN ||
> +	     !sctp_ulpevent_is_notification(event)))
>  		goto out_free;
>  
>  	if (!sctp_ulpevent_is_notification(event)) {
> -- 
> 2.1.0
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH net] sctp: allow delivering notifications after receiving SHUTDOWN
  2016-07-30  6:09 ` Xin Long
@ 2016-07-31  5:07   ` David Miller
  -1 siblings, 0 replies; 6+ messages in thread
From: David Miller @ 2016-07-31  5:07 UTC (permalink / raw)
  To: lucien.xin; +Cc: netdev, linux-sctp, marcelo.leitner, vyasevich, daniel

From: Xin Long <lucien.xin@gmail.com>
Date: Sat, 30 Jul 2016 14:09:09 +0800

> Prior to this patch, once sctp received SHUTDOWN or shutdown with RD,
> sk->sk_shutdown would be set with RCV_SHUTDOWN, and all events would
> be dropped in sctp_ulpq_tail_event(). It would cause:
> 
> 1. some notifications couldn't be received by users. like
>    SCTP_SHUTDOWN_COMP generated by sctp_sf_do_4_C().
> 
> 2. sctp would also never trigger sk_data_ready when the association
>    was closed, making it harder to identify the end of the association
>    by calling recvmsg() and getting an EOF. It was not convenient for
>    kernel users.
> 
> The check here should be stopping delivering DATA chunks after receiving
> SHUTDOWN, and stopping delivering ANY chunks after sctp_close().
> 
> So this patch is to allow notifications to enqueue into receive queue
> even if sk->sk_shutdown is set to RCV_SHUTDOWN in sctp_ulpq_tail_event,
> but if sk->sk_shutdown == RCV_SHUTDOWN | SEND_SHUTDOWN, it drops all
> events.
> 
> Signed-off-by: Xin Long <lucien.xin@gmail.com>

Applied.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH net] sctp: allow delivering notifications after receiving SHUTDOWN
@ 2016-07-31  5:07   ` David Miller
  0 siblings, 0 replies; 6+ messages in thread
From: David Miller @ 2016-07-31  5:07 UTC (permalink / raw)
  To: lucien.xin; +Cc: netdev, linux-sctp, marcelo.leitner, vyasevich, daniel

From: Xin Long <lucien.xin@gmail.com>
Date: Sat, 30 Jul 2016 14:09:09 +0800

> Prior to this patch, once sctp received SHUTDOWN or shutdown with RD,
> sk->sk_shutdown would be set with RCV_SHUTDOWN, and all events would
> be dropped in sctp_ulpq_tail_event(). It would cause:
> 
> 1. some notifications couldn't be received by users. like
>    SCTP_SHUTDOWN_COMP generated by sctp_sf_do_4_C().
> 
> 2. sctp would also never trigger sk_data_ready when the association
>    was closed, making it harder to identify the end of the association
>    by calling recvmsg() and getting an EOF. It was not convenient for
>    kernel users.
> 
> The check here should be stopping delivering DATA chunks after receiving
> SHUTDOWN, and stopping delivering ANY chunks after sctp_close().
> 
> So this patch is to allow notifications to enqueue into receive queue
> even if sk->sk_shutdown is set to RCV_SHUTDOWN in sctp_ulpq_tail_event,
> but if sk->sk_shutdown = RCV_SHUTDOWN | SEND_SHUTDOWN, it drops all
> events.
> 
> Signed-off-by: Xin Long <lucien.xin@gmail.com>

Applied.

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2016-07-31  5:07 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-07-30  6:09 [PATCH net] sctp: allow delivering notifications after receiving SHUTDOWN Xin Long
2016-07-30  6:09 ` Xin Long
2016-07-30 13:22 ` Marcelo Ricardo Leitner
2016-07-30 13:22   ` Marcelo Ricardo Leitner
2016-07-31  5:07 ` David Miller
2016-07-31  5:07   ` David Miller

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.