: sctp: denoise deprecation log on SCTP_EVENTS
Subsystems (3)
RFC 1/1 : sctp: denoise deprecation log on SCTP_EVENTS
In the newer kernels this message is extremely noisy. After a quick discussion with Daniel it seems to me it will be very hard to get existing apps that nobody is going to update to continue to work (i.e no forward compat). And newer apps that desire to play in both older kernels and new kernels will have to play some tricks to work (i.e weak backward compatibility). These are good reasons to totally get rid of this message. At minimal to neutre it. The attached change tries to do that. However, if you had multiple apps, you will only get warning for the first one.
Will send proper patch when theres some consensus.
cheers,
jamal
net/sctp/socket.c +4 -3
@@ -2207,9 +2207,10 @@ static int sctp_setsockopt_events(struct sock *sk, char __user *optval,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" , +pr_warn_once (DEPRECATED "%s (pid %d) " +"SCTP_EVENTS Option - DEPRECATED\n" +"Use SCTP_EVENT Option instead\n" +"Refer to RFC6458 section 6.2\n" , current->comm,task_pid_nr (current));/* At the time when a user app subscribes to SCTP_SENDER_DRY_EVENT,
On 07/09/2015 12:38 PM, Jamal Hadi Salim wrote:
...
Quoted 7 lines
In the newer kernels this message is extremely noisy. After a quick discussion with Daniel it seems to me it will be very hard to get existing apps that nobody is going to update to continue to work (i.e no forward compat). And newer apps that desire to play in both older kernels and new kernels will have to play some tricks to work (i.e weak backward compatibility). These are good reasons to totally get rid of this message. At minimal to neutre it.
To put some more context into this, here was the past discussion on this topic:
http://www.spinics.net/lists/linux-sctp/msg03596.html
This begs the question, which we need to clarify:
Can we *ever* get rid of the old UAPI that the RFC proposed and later on deprecated?
In the thread, there was a mentioning of 5-6 years schedule, but I honestly doubt that this would be enough, i.e. for people only upgrading their kernels, but not being able to touch their legacy SCTP apps (maybe due to proprietary appliance crap, etc).
A pr_warn_once() would only warn for the first app triggering this (and not for follow-ups), it would surely take incentives away to update their code since less annoying, but if the uapi in fact could never be removed, then why bothering spamming the klog in the first place? ;) I can understand the deprecation dilemma, but personally, I would have no problem if we just want to remove the pr_warn_ratelimited() altogether ...
Quoted 7 lines
The attached change tries to do that. However, if you had multiple apps, you will only get warning for the first one.
Will send proper patch when theres some consensus.
cheers,
jamal
Quoted 25 lines · Daniel Borkmann
On 07/09/2015 12:38 PM, Jamal Hadi Salim wrote:
...Quoted 7 lines
In the newer kernels this message is extremely noisy. After a quick discussion with Daniel it seems to me it will be very hard to get existing apps that nobody is going to update to continue to work (i.e no forward compat). And newer apps that desire to play in both older kernels and new kernels will have to play some tricks to work (i.e weak backward compatibility). These are good reasons to totally get rid of this message. At minimal to neutre it.
To put some more context into this, here was the past discussion on this topic:
http://www.spinics.net/lists/linux-sctp/msg03596.html
This begs the question, which we need to clarify:
Can we *ever* get rid of the old UAPI that the RFC proposed and later on deprecated?
In the thread, there was a mentioning of 5-6 years schedule, but I honestly doubt that this would be enough, i.e. for people only upgrading their kernels, but not being able to touch their legacy SCTP apps (maybe due to proprietary appliance crap, etc).
Quoted 12 lines
A
pr_warn_once()would only warn for the first app triggering this (and not for follow-ups), it would surely take incentives away to update their code since less annoying, but if the uapi in fact could never be removed, then why bothering spamming the klog in the first place? ;) I can understand the deprecation dilemma, but personally, I would have no problem if we just want to remove thepr_warn_ratelimited()altogether ...Quoted 4 lines
The attached change tries to do that. However, if you had multiple apps, you will only get warning for the first one.
Will send proper patch when theres some consensus.
The new message is misleading as currently we don't have SCTP_EVENT available to use. So if someone tries to actually follow that lead, it will lead to a dead and confusing end.
I'm okay with just switching it to pr_warn_once, though. It makes sense to not spam klog but to have the message there, because even if we keep it available for backwards compatibility, it might suffer from some limitations in the future and the usage of the new one is always recommended.
Marcelo
From: Jamal Hadi Salim
Quoted 11 lines
Sent: 09 July 2015 11:38
In the newer kernels this message is extremely noisy. After a quick discussion with Daniel it seems to me it will be very hard to get existing apps that nobody is going to update to continue to work (i.e no forward compat). And newer apps that desire to play in both older kernels and new kernels will have to play some tricks to work (i.e weak backward compatibility). These are good reasons to totally get rid of this message. At minimal to neutre it. The attached change tries to do that. However, if you had multiple apps, you will only get warning for the first one.
Never mind spanning the kernel log, there will be performance issues with systems that are sending significant amounts of SCTP data. I'm not sure you'll get 10000+/sec through the trace system.
I'm going to have to find which version this trace went into and make sure we tell customers not to use the relevant kernel versions.
David
Quoted 13 lines · David Laight
From: Jamal Hadi Salim
Quoted 11 lines
Sent: 09 July 2015 11:38
In the newer kernels this message is extremely noisy. After a quick discussion with Daniel it seems to me it will be very hard to get existing apps that nobody is going to update to continue to work (i.e no forward compat). And newer apps that desire to play in both older kernels and new kernels will have to play some tricks to work (i.e weak backward compatibility). These are good reasons to totally get rid of this message. At minimal to neutre it. The attached change tries to do that. However, if you had multiple apps, you will only get warning for the first one.
Quoted 3 lines
Never mind spanning the kernel log, there will be performance issues with systems that are sending significant amounts of SCTP data. I'm not sure you'll get 10000+/sec through the trace system.
What do you mean by "trace system" (there's no backtrace)?
Anyway, as previously stated, I doubt we'd get rid of the deprecated SCTP uapi from the RFC any time soon, so, imho, we should just remove these rate-limited messages altogether to stop spamming the klog ...
Quoted 5 lines
I'm going to have to find which version this trace went into and make sure we tell customers not to use the relevant kernel versions.
David
Quoted 20 lines · Daniel Borkmann
Quoted 13 lines · David Laight
From: Jamal Hadi Salim
Quoted 11 lines
Sent: 09 July 2015 11:38
In the newer kernels this message is extremely noisy. After a quick discussion with Daniel it seems to me it will be very hard to get existing apps that nobody is going to update to continue to work (i.e no forward compat). And newer apps that desire to play in both older kernels and new kernels will have to play some tricks to work (i.e weak backward compatibility). These are good reasons to totally get rid of this message. At minimal to neutre it. The attached change tries to do that. However, if you had multiple apps, you will only get warning for the first one.
Quoted 3 lines
Never mind spanning the kernel log, there will be performance issues with systems that are sending significant amounts of SCTP data. I'm not sure you'll get 10000+/sec through the trace system.
Quoted 5 lines
What do you mean by "trace system" (there's no backtrace)?
Anyway, as previously stated, I doubt we'd get rid of the deprecated SCTP uapi from the RFC any time soon, so, imho, we should just remove these rate-limited messages altogether to stop spamming the klog ...
... and we will not remove it in FreeBSD either.
Best regards
Michael
Quoted 8 lines
Quoted 6 lines
I'm going to have to find which version this trace went into and make sure we tell customers not to use the relevant kernel versions.
David
Quoted 1 line · Michael Tuexen
Quoted 1 line · Daniel Borkmann
...
Quoted 4 lines
Quoted 3 lines
Anyway, as previously stated, I doubt we'd get rid of the deprecated SCTP uapi from the RFC any time soon, so, imho, we should just remove these rate-limited messages altogether to stop spamming the klog ...
... and we will not remove it in FreeBSD either.
Right, I think same here.
Quoted 2 lines
Best regards
Michael