All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH net] net: sctp: stop spamming klog with rfc6458, 5.3.2. deprecation warnings
@ 2015-07-22 14:31 Daniel Borkmann
  2015-07-22 14:43 ` Jamal Hadi Salim
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: Daniel Borkmann @ 2015-07-22 14:31 UTC (permalink / raw)
  To: davem
  Cc: jhs, vyasevic, nhorman, David.Laight, netdev, Daniel Borkmann,
	Michael Tuexen

Back then when we added support for SCTP_SNDINFO/SCTP_RCVINFO from
RFC6458 5.3.4/5.3.5, we decided to add a deprecation warning for the
(as per RFC deprecated) SCTP_SNDRCV via commit bbbea41d5e53 ("net:
sctp: deprecate rfc6458, 5.3.2. SCTP_SNDRCV support"), see [1].

Imho, it was not a good idea, and we should just revert that message
for a couple of reasons:

  1) It's uapi and therefore set in stone forever.

  2) To be able to run on older and newer kernels, an SCTP application
     would need to probe for both, SCTP_SNDRCV, but also SCTP_SNDINFO/
     SCTP_RCVINFO support, so that on older kernels, it can make use
     of SCTP_SNDRCV, and on newer kernels SCTP_SNDINFO/SCTP_RCVINFO.
     In my (limited) experience, a lot of SCTP appliances are migrating
     to newer kernels only ve(ee)ry slowly.

  3) Some people don't have the chance to change their applications,
     f.e. due to proprietary legacy stuff. So, they'll hit this warning
     in fast path and are stuck with older kernels.

But i.e. due to point 1) I really fail to see the benefit of a warning.
So just revert that for now, the issue was reported up Jamal.

  [1] http://thread.gmane.org/gmane.linux.network/321960/

Reported-by: Jamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Cc: Michael Tuexen <tuexen@fh-muenster.de>
---
 net/sctp/socket.c | 6 ------
 1 file changed, 6 deletions(-)

diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index 1425ec2..17bef01 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -2200,12 +2200,6 @@ static int sctp_setsockopt_events(struct sock *sk, char __user *optval,
 	if (copy_from_user(&sctp_sk(sk)->subscribe, optval, optlen))
 		return -EFAULT;
 
-	if (sctp_sk(sk)->subscribe.sctp_data_io_event)
-		pr_warn_ratelimited(DEPRECATED "%s (pid %d) "
-				    "Requested SCTP_SNDRCVINFO event.\n"
-				    "Use SCTP_RCVINFO through SCTP_RECVRCVINFO option instead.\n",
-				    current->comm, task_pid_nr(current));
-
 	/* At the time when a user app subscribes to SCTP_SENDER_DRY_EVENT,
 	 * if there is no data to be sent or retransmit, the stack will
 	 * immediately send up this notification.
-- 
1.9.3

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

* Re: [PATCH net] net: sctp: stop spamming klog with rfc6458, 5.3.2. deprecation warnings
  2015-07-22 14:31 [PATCH net] net: sctp: stop spamming klog with rfc6458, 5.3.2. deprecation warnings Daniel Borkmann
@ 2015-07-22 14:43 ` Jamal Hadi Salim
  2015-07-22 14:46 ` Michael Tuexen
  2015-07-26 23:32 ` David Miller
  2 siblings, 0 replies; 4+ messages in thread
From: Jamal Hadi Salim @ 2015-07-22 14:43 UTC (permalink / raw)
  To: Daniel Borkmann, davem
  Cc: vyasevic, nhorman, David.Laight, netdev, Michael Tuexen

On 07/22/15 10:31, Daniel Borkmann wrote:
> Back then when we added support for SCTP_SNDINFO/SCTP_RCVINFO from
> RFC6458 5.3.4/5.3.5, we decided to add a deprecation warning for the
> (as per RFC deprecated) SCTP_SNDRCV via commit bbbea41d5e53 ("net:
> sctp: deprecate rfc6458, 5.3.2. SCTP_SNDRCV support"), see [1].
>
> Imho, it was not a good idea, and we should just revert that message
> for a couple of reasons:
>
>    1) It's uapi and therefore set in stone forever.
>
>    2) To be able to run on older and newer kernels, an SCTP application
>       would need to probe for both, SCTP_SNDRCV, but also SCTP_SNDINFO/
>       SCTP_RCVINFO support, so that on older kernels, it can make use
>       of SCTP_SNDRCV, and on newer kernels SCTP_SNDINFO/SCTP_RCVINFO.
>       In my (limited) experience, a lot of SCTP appliances are migrating
>       to newer kernels only ve(ee)ry slowly.
>
>    3) Some people don't have the chance to change their applications,
>       f.e. due to proprietary legacy stuff. So, they'll hit this warning
>       in fast path and are stuck with older kernels.
>
> But i.e. due to point 1) I really fail to see the benefit of a warning.
> So just revert that for now, the issue was reported up Jamal.
>
>    [1] http://thread.gmane.org/gmane.linux.network/321960/
>
> Reported-by: Jamal Hadi Salim <jhs@mojatatu.com>
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
> Cc: Michael Tuexen <tuexen@fh-muenster.de>


Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>

cheers,
jamal

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

* Re: [PATCH net] net: sctp: stop spamming klog with rfc6458, 5.3.2. deprecation warnings
  2015-07-22 14:31 [PATCH net] net: sctp: stop spamming klog with rfc6458, 5.3.2. deprecation warnings Daniel Borkmann
  2015-07-22 14:43 ` Jamal Hadi Salim
@ 2015-07-22 14:46 ` Michael Tuexen
  2015-07-26 23:32 ` David Miller
  2 siblings, 0 replies; 4+ messages in thread
From: Michael Tuexen @ 2015-07-22 14:46 UTC (permalink / raw)
  To: Daniel Borkmann; +Cc: davem, jhs, vyasevic, nhorman, David.Laight, netdev

> On 22 Jul 2015, at 16:31, Daniel Borkmann <daniel@iogearbox.net> wrote:
> 
> Back then when we added support for SCTP_SNDINFO/SCTP_RCVINFO from
> RFC6458 5.3.4/5.3.5, we decided to add a deprecation warning for the
> (as per RFC deprecated) SCTP_SNDRCV via commit bbbea41d5e53 ("net:
> sctp: deprecate rfc6458, 5.3.2. SCTP_SNDRCV support"), see [1].
> 
> Imho, it was not a good idea, and we should just revert that message
> for a couple of reasons:
> 
>  1) It's uapi and therefore set in stone forever.
> 
>  2) To be able to run on older and newer kernels, an SCTP application
>     would need to probe for both, SCTP_SNDRCV, but also SCTP_SNDINFO/
>     SCTP_RCVINFO support, so that on older kernels, it can make use
>     of SCTP_SNDRCV, and on newer kernels SCTP_SNDINFO/SCTP_RCVINFO.
>     In my (limited) experience, a lot of SCTP appliances are migrating
>     to newer kernels only ve(ee)ry slowly.
> 
>  3) Some people don't have the chance to change their applications,
>     f.e. due to proprietary legacy stuff. So, they'll hit this warning
>     in fast path and are stuck with older kernels.
> 
> But i.e. due to point 1) I really fail to see the benefit of a warning.
> So just revert that for now, the issue was reported up Jamal.
> 
>  [1] http://thread.gmane.org/gmane.linux.network/321960/
Looks good to me.

Best regards
Michael
> 
> Reported-by: Jamal Hadi Salim <jhs@mojatatu.com>
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
> Cc: Michael Tuexen <tuexen@fh-muenster.de>
> ---
> net/sctp/socket.c | 6 ------
> 1 file changed, 6 deletions(-)
> 
> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> index 1425ec2..17bef01 100644
> --- a/net/sctp/socket.c
> +++ b/net/sctp/socket.c
> @@ -2200,12 +2200,6 @@ static int sctp_setsockopt_events(struct sock *sk, char __user *optval,
> 	if (copy_from_user(&sctp_sk(sk)->subscribe, optval, optlen))
> 		return -EFAULT;
> 
> -	if (sctp_sk(sk)->subscribe.sctp_data_io_event)
> -		pr_warn_ratelimited(DEPRECATED "%s (pid %d) "
> -				    "Requested SCTP_SNDRCVINFO event.\n"
> -				    "Use SCTP_RCVINFO through SCTP_RECVRCVINFO option instead.\n",
> -				    current->comm, task_pid_nr(current));
> -
> 	/* At the time when a user app subscribes to SCTP_SENDER_DRY_EVENT,
> 	 * if there is no data to be sent or retransmit, the stack will
> 	 * immediately send up this notification.
> -- 
> 1.9.3
> 
> 

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

* Re: [PATCH net] net: sctp: stop spamming klog with rfc6458, 5.3.2. deprecation warnings
  2015-07-22 14:31 [PATCH net] net: sctp: stop spamming klog with rfc6458, 5.3.2. deprecation warnings Daniel Borkmann
  2015-07-22 14:43 ` Jamal Hadi Salim
  2015-07-22 14:46 ` Michael Tuexen
@ 2015-07-26 23:32 ` David Miller
  2 siblings, 0 replies; 4+ messages in thread
From: David Miller @ 2015-07-26 23:32 UTC (permalink / raw)
  To: daniel; +Cc: jhs, vyasevic, nhorman, David.Laight, netdev, tuexen

From: Daniel Borkmann <daniel@iogearbox.net>
Date: Wed, 22 Jul 2015 16:31:49 +0200

> Back then when we added support for SCTP_SNDINFO/SCTP_RCVINFO from
> RFC6458 5.3.4/5.3.5, we decided to add a deprecation warning for the
> (as per RFC deprecated) SCTP_SNDRCV via commit bbbea41d5e53 ("net:
> sctp: deprecate rfc6458, 5.3.2. SCTP_SNDRCV support"), see [1].
> 
> Imho, it was not a good idea, and we should just revert that message
> for a couple of reasons:
> 
>   1) It's uapi and therefore set in stone forever.
> 
>   2) To be able to run on older and newer kernels, an SCTP application
>      would need to probe for both, SCTP_SNDRCV, but also SCTP_SNDINFO/
>      SCTP_RCVINFO support, so that on older kernels, it can make use
>      of SCTP_SNDRCV, and on newer kernels SCTP_SNDINFO/SCTP_RCVINFO.
>      In my (limited) experience, a lot of SCTP appliances are migrating
>      to newer kernels only ve(ee)ry slowly.
> 
>   3) Some people don't have the chance to change their applications,
>      f.e. due to proprietary legacy stuff. So, they'll hit this warning
>      in fast path and are stuck with older kernels.
> 
> But i.e. due to point 1) I really fail to see the benefit of a warning.
> So just revert that for now, the issue was reported up Jamal.
> 
>   [1] http://thread.gmane.org/gmane.linux.network/321960/
> 
> Reported-by: Jamal Hadi Salim <jhs@mojatatu.com>
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>

Applied, thanks Daniel.

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

end of thread, other threads:[~2015-07-26 23:33 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-07-22 14:31 [PATCH net] net: sctp: stop spamming klog with rfc6458, 5.3.2. deprecation warnings Daniel Borkmann
2015-07-22 14:43 ` Jamal Hadi Salim
2015-07-22 14:46 ` Michael Tuexen
2015-07-26 23:32 ` 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.