[PATCH] SCTP: Reduce log spamming for sctp setsockopt

[PATCH] SCTP: Reduce log spamming for sctp setsockopt

[Neil Horman]

During a recent discussion regarding some sctp socket options, it was noted that
we have several points at which we issue log warnings that can be flooded at an
unbounded rate by any user.  Fix this by converting all the pr_warns in the
sctp_setsockopt path to be pr_warn_ratelimited.

Note there are several debug level messages as well.  I'm leaving those alone,
as, if you turn on pr_debug, you likely want lots of verbosity.

Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: Vlad Yasevich <vyasevich@gmail.com>
CC: David Miller <davem@davemloft.net>
CC: netdev@vger.kernel.org
---
 net/sctp/socket.c | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index 42b709c..8261e69 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -2579,8 +2579,8 @@ static int sctp_setsockopt_delayed_ack(struct sock *sk,
 		if (params.sack_delay == 0 && params.sack_freq == 0)
 			return 0;
 	} else if (optlen == sizeof(struct sctp_assoc_value)) {
-		pr_warn("Use of struct sctp_assoc_value in delayed_ack socket option deprecated\n");
-		pr_warn("Use struct sctp_sack_info instead\n");
+		pr_warn_ratelimited("Use of struct sctp_assoc_value in delayed_ack socket option deprecated\n");
+		pr_warn_ratelimited("Use struct sctp_sack_info instead\n");
 		if (copy_from_user(&params, optval, optlen))
 			return -EFAULT;
 
@@ -2995,8 +2995,8 @@ static int sctp_setsockopt_maxseg(struct sock *sk, char __user *optval, unsigned
 	int val;
 
 	if (optlen == sizeof(int)) {
-		pr_warn("Use of int in maxseg socket option deprecated\n");
-		pr_warn("Use struct sctp_assoc_value instead\n");
+		pr_warn_ratelimited("Use of int in maxseg socket option deprecated\n");
+		pr_warn_ratelimited("Use struct sctp_assoc_value instead\n");
 		if (copy_from_user(&val, optval, optlen))
 			return -EFAULT;
 		params.assoc_id = 0;
@@ -3253,8 +3253,8 @@ static int sctp_setsockopt_maxburst(struct sock *sk,
 	int assoc_id = 0;
 
 	if (optlen == sizeof(int)) {
-		pr_warn("Use of int in max_burst socket option deprecated\n");
-		pr_warn("Use struct sctp_assoc_value instead\n");
+		pr_warn_ratelimited("Use of int in max_burst socket option deprecated\n");
+		pr_warn_ratelimited("Use struct sctp_assoc_value instead\n");
 		if (copy_from_user(&val, optval, optlen))
 			return -EFAULT;
 	} else if (optlen == sizeof(struct sctp_assoc_value)) {
@@ -4574,8 +4574,8 @@ static int sctp_getsockopt_delayed_ack(struct sock *sk, int len,
 		if (copy_from_user(&params, optval, len))
 			return -EFAULT;
 	} else if (len == sizeof(struct sctp_assoc_value)) {
-		pr_warn("Use of struct sctp_assoc_value in delayed_ack socket option deprecated\n");
-		pr_warn("Use struct sctp_sack_info instead\n");
+		pr_warn_ratelimited("Use of struct sctp_assoc_value in delayed_ack socket option deprecated\n");
+		pr_warn_ratelimited("Use struct sctp_sack_info instead\n");
 		if (copy_from_user(&params, optval, len))
 			return -EFAULT;
 	} else
@@ -5219,8 +5219,8 @@ static int sctp_getsockopt_maxseg(struct sock *sk, int len,
 	struct sctp_association *asoc;
 
 	if (len == sizeof(int)) {
-		pr_warn("Use of int in maxseg socket option deprecated\n");
-		pr_warn("Use struct sctp_assoc_value instead\n");
+		pr_warn_ratelimited("Use of int in maxseg socket option deprecated\n");
+		pr_warn_ratelimited("Use struct sctp_assoc_value instead\n");
 		params.assoc_id = 0;
 	} else if (len >= sizeof(struct sctp_assoc_value)) {
 		len = sizeof(struct sctp_assoc_value);
@@ -5311,8 +5311,8 @@ static int sctp_getsockopt_maxburst(struct sock *sk, int len,
 	struct sctp_association *asoc;
 
 	if (len == sizeof(int)) {
-		pr_warn("Use of int in max_burst socket option deprecated\n");
-		pr_warn("Use struct sctp_assoc_value instead\n");
+		pr_warn_ratelimited("Use of int in max_burst socket option deprecated\n");
+		pr_warn_ratelimited("Use struct sctp_assoc_value instead\n");
 		params.assoc_id = 0;
 	} else if (len >= sizeof(struct sctp_assoc_value)) {
 		len = sizeof(struct sctp_assoc_value);
-- 
1.8.3.1

Re: [PATCH] SCTP: Reduce log spamming for sctp setsockopt

[Joe Perches]

On Mon, 2013-12-16 at 09:44 -0500, Neil Horman wrote:
> During a recent discussion regarding some sctp socket options, it was noted that
> we have several points at which we issue log warnings that can be flooded at an
> unbounded rate by any user.  Fix this by converting all the pr_warns in the
> sctp_setsockopt path to be pr_warn_ratelimited.

trivial note:

> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
[]
> @@ -2579,8 +2579,8 @@ static int sctp_setsockopt_delayed_ack(struct sock *sk,
[]
> +		pr_warn_ratelimited("Use of struct sctp_assoc_value in delayed_ack socket option deprecated\n");
> +		pr_warn_ratelimited("Use struct sctp_sack_info instead\n");
[]
> @@ -2995,8 +2995,8 @@ static int sctp_setsockopt_maxseg(struct sock *sk, char __user *optval, unsigned
> +		pr_warn_ratelimited("Use of int in maxseg socket option deprecated\n");
[]
> @@ -3253,8 +3253,8 @@ static int sctp_setsockopt_maxburst(struct sock *sk,
[]
> +		pr_warn_ratelimited("Use of int in max_burst socket option deprecated\n");
> +		pr_warn_ratelimited("Use struct sctp_assoc_value instead\n");
[]
> @@ -4574,8 +4574,8 @@ static int sctp_getsockopt_delayed_ack(struct sock *sk, int len,
[]
> +		pr_warn_ratelimited("Use of struct sctp_assoc_value in delayed_ack socket option deprecated\n");
> +		pr_warn_ratelimited("Use struct sctp_sack_info instead\n");
[]
> @@ -5219,8 +5219,8 @@ static int sctp_getsockopt_maxseg(struct sock *sk, int len,
[]
> +		pr_warn_ratelimited("Use of int in maxseg socket option deprecated\n");
> +		pr_warn_ratelimited("Use struct sctp_assoc_value instead\n");
[]
> @@ -5311,8 +5311,8 @@ static int sctp_getsockopt_maxburst(struct sock *sk, int len,
[]
> +		pr_warn_ratelimited("Use of int in max_burst socket option deprecated\n");
> +		pr_warn_ratelimited("Use struct sctp_assoc_value instead\n");

Perhaps a dedicated "deprecated" warning function
to centralize these?

void _sctp_warn_deprecated(const char *func, const char *from, const char *to);
{
	etc.
}
#define sctp_warn_deprecated(from, to)		\
	_sctp_warn_deprecated(__func__, from, to)

and use

		sctp_warn_deprecated("struct sctp_assoc_value", "struct sctp_sack_info");
		sctp_warn_deprecated("int", "");
		sctp_warn_deprecated("int", "struct sctp_assoc_value");
		sctp_warn_deprecated("struct sctp_assoc_value", "struct sctp_sack_info");
		sctp_warn_deprecated("int", "struct sctp_assoc_value");
		sctp_warn_deprecated("int", "struct sctp_assoc_value");

Re: [PATCH] SCTP: Reduce log spamming for sctp setsockopt

[Daniel Borkmann]

On 12/16/2013 04:03 PM, Joe Perches wrote:
> On Mon, 2013-12-16 at 09:44 -0500, Neil Horman wrote:
>> During a recent discussion regarding some sctp socket options, it was noted that
>> we have several points at which we issue log warnings that can be flooded at an
>> unbounded rate by any user.  Fix this by converting all the pr_warns in the
>> sctp_setsockopt path to be pr_warn_ratelimited.
>
> trivial note:
[...]
>> @@ -5311,8 +5311,8 @@ static int sctp_getsockopt_maxburst(struct sock *sk, int len,
> []
>> +		pr_warn_ratelimited("Use of int in max_burst socket option deprecated\n");
>> +		pr_warn_ratelimited("Use struct sctp_assoc_value instead\n");
>
> Perhaps a dedicated "deprecated" warning function
> to centralize these?
>
> void _sctp_warn_deprecated(const char *func, const char *from, const char *to);
> {
> 	etc.
> }
> #define sctp_warn_deprecated(from, to)		\
> 	_sctp_warn_deprecated(__func__, from, to)

If so, then this should better get even more "centralized" ... as e.g.
pr_warn_deprecated() [which internally is ratelimited]. I don't see the
point why only SCTP should have this special-cased.

> and use
>
> 		sctp_warn_deprecated("struct sctp_assoc_value", "struct sctp_sack_info");
> 		sctp_warn_deprecated("int", "");
> 		sctp_warn_deprecated("int", "struct sctp_assoc_value");
> 		sctp_warn_deprecated("struct sctp_assoc_value", "struct sctp_sack_info");
> 		sctp_warn_deprecated("int", "struct sctp_assoc_value");
> 		sctp_warn_deprecated("int", "struct sctp_assoc_value");
>

Re: [PATCH] SCTP: Reduce log spamming for sctp setsockopt

[Joe Perches]

On Mon, 2013-12-16 at 16:13 +0100, Daniel Borkmann wrote:
> On 12/16/2013 04:03 PM, Joe Perches wrote:
> > On Mon, 2013-12-16 at 09:44 -0500, Neil Horman wrote:
> >> During a recent discussion regarding some sctp socket options, it was noted that
> >> we have several points at which we issue log warnings that can be flooded at an
> >> unbounded rate by any user.  Fix this by converting all the pr_warns in the
> >> sctp_setsockopt path to be pr_warn_ratelimited.
> >
> > trivial note:
> [...]
> >> @@ -5311,8 +5311,8 @@ static int sctp_getsockopt_maxburst(struct sock *sk, int len,
> > []
> >> +		pr_warn_ratelimited("Use of int in max_burst socket option deprecated\n");
> >> +		pr_warn_ratelimited("Use struct sctp_assoc_value instead\n");
> >
> > Perhaps a dedicated "deprecated" warning function
> > to centralize these?
> >
> > void _sctp_warn_deprecated(const char *func, const char *from, const char *to);
> > {
> > 	etc.
> > }
> > #define sctp_warn_deprecated(from, to)		\
> > 	_sctp_warn_deprecated(__func__, from, to)
> 
> If so, then this should better get even more "centralized" ... as e.g.
> pr_warn_deprecated() [which internally is ratelimited]. I don't see the
> point why only SCTP should have this special-cased.

Sure, if it's useful outside of sctp, but I didn't
notice any other uses like it.

Re: [PATCH] SCTP: Reduce log spamming for sctp setsockopt

[Daniel Borkmann]

On 12/16/2013 04:21 PM, Joe Perches wrote:
> On Mon, 2013-12-16 at 16:13 +0100, Daniel Borkmann wrote:
>> On 12/16/2013 04:03 PM, Joe Perches wrote:
>>> On Mon, 2013-12-16 at 09:44 -0500, Neil Horman wrote:
>>>> During a recent discussion regarding some sctp socket options, it was noted that
>>>> we have several points at which we issue log warnings that can be flooded at an
>>>> unbounded rate by any user.  Fix this by converting all the pr_warns in the
>>>> sctp_setsockopt path to be pr_warn_ratelimited.
>>>
>>> trivial note:
>> [...]
>>>> @@ -5311,8 +5311,8 @@ static int sctp_getsockopt_maxburst(struct sock *sk, int len,
>>> []
>>>> +		pr_warn_ratelimited("Use of int in max_burst socket option deprecated\n");
>>>> +		pr_warn_ratelimited("Use struct sctp_assoc_value instead\n");
>>>
>>> Perhaps a dedicated "deprecated" warning function
>>> to centralize these?
>>>
>>> void _sctp_warn_deprecated(const char *func, const char *from, const char *to);
>>> {
>>> 	etc.
>>> }
>>> #define sctp_warn_deprecated(from, to)		\
>>> 	_sctp_warn_deprecated(__func__, from, to)
>>
>> If so, then this should better get even more "centralized" ... as e.g.
>> pr_warn_deprecated() [which internally is ratelimited]. I don't see the
>> point why only SCTP should have this special-cased.
>
> Sure, if it's useful outside of sctp, but I didn't
> notice any other uses like it.

If we have a generic API for that, they might come, sure.

Re: [PATCH] SCTP: Reduce log spamming for sctp setsockopt

[Neil Horman]

On Mon, Dec 16, 2013 at 04:45:05PM +0100, Daniel Borkmann wrote:
> On 12/16/2013 04:21 PM, Joe Perches wrote:
> >On Mon, 2013-12-16 at 16:13 +0100, Daniel Borkmann wrote:
> >>On 12/16/2013 04:03 PM, Joe Perches wrote:
> >>>On Mon, 2013-12-16 at 09:44 -0500, Neil Horman wrote:
> >>>>During a recent discussion regarding some sctp socket options, it was noted that
> >>>>we have several points at which we issue log warnings that can be flooded at an
> >>>>unbounded rate by any user.  Fix this by converting all the pr_warns in the
> >>>>sctp_setsockopt path to be pr_warn_ratelimited.
> >>>
> >>>trivial note:
> >>[...]
> >>>>@@ -5311,8 +5311,8 @@ static int sctp_getsockopt_maxburst(struct sock *sk, int len,
> >>>[]
> >>>>+		pr_warn_ratelimited("Use of int in max_burst socket option deprecated\n");
> >>>>+		pr_warn_ratelimited("Use struct sctp_assoc_value instead\n");
> >>>
> >>>Perhaps a dedicated "deprecated" warning function
> >>>to centralize these?
> >>>
> >>>void _sctp_warn_deprecated(const char *func, const char *from, const char *to);
> >>>{
> >>>	etc.
> >>>}
> >>>#define sctp_warn_deprecated(from, to)		\
> >>>	_sctp_warn_deprecated(__func__, from, to)
> >>
> >>If so, then this should better get even more "centralized" ... as e.g.
> >>pr_warn_deprecated() [which internally is ratelimited]. I don't see the
> >>point why only SCTP should have this special-cased.
> >
> >Sure, if it's useful outside of sctp, but I didn't
> >notice any other uses like it.
> 
> If we have a generic API for that, they might come, sure.
I agree with Daniel.  If we're going to make this common, theres no reason to
not make it common for all uses.  Searching the kernel for uses of printk/pr_*
and the string "deprecated" shows lots of potential use sites.

Neil

> --
> 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
> 

Re: [PATCH] SCTP: Reduce log spamming for sctp setsockopt

[Joe Perches]

On Mon, 2013-12-16 at 11:04 -0500, Neil Horman wrote:
> On Mon, Dec 16, 2013 at 04:45:05PM +0100, Daniel Borkmann wrote:
> > On 12/16/2013 04:21 PM, Joe Perches wrote:
> > >On Mon, 2013-12-16 at 16:13 +0100, Daniel Borkmann wrote:
> > >>On 12/16/2013 04:03 PM, Joe Perches wrote:
> > >>>On Mon, 2013-12-16 at 09:44 -0500, Neil Horman wrote:
> > >>>>During a recent discussion regarding some sctp socket options, it was noted that
> > >>>>we have several points at which we issue log warnings that can be flooded at an
> > >>>>unbounded rate by any user.  Fix this by converting all the pr_warns in the
> > >>>>sctp_setsockopt path to be pr_warn_ratelimited.
> > >>>
> > >>>trivial note:
> > >>[...]
> > >>>>@@ -5311,8 +5311,8 @@ static int sctp_getsockopt_maxburst(struct sock *sk, int len,
> > >>>[]
> > >>>>+		pr_warn_ratelimited("Use of int in max_burst socket option deprecated\n");
> > >>>>+		pr_warn_ratelimited("Use struct sctp_assoc_value instead\n");
> > >>>
> > >>>Perhaps a dedicated "deprecated" warning function
> > >>>to centralize these?
> > >>>
> > >>>void _sctp_warn_deprecated(const char *func, const char *from, const char *to);
> > >>>{
> > >>>	etc.
> > >>>}
> > >>>#define sctp_warn_deprecated(from, to)		\
> > >>>	_sctp_warn_deprecated(__func__, from, to)
> > >>
> > >>If so, then this should better get even more "centralized" ... as e.g.
> > >>pr_warn_deprecated() [which internally is ratelimited]. I don't see the
> > >>point why only SCTP should have this special-cased.
> > >
> > >Sure, if it's useful outside of sctp, but I didn't
> > >notice any other uses like it.
> > 
> > If we have a generic API for that, they might come, sure.
> I agree with Daniel.  If we're going to make this common, theres no reason to
> not make it common for all uses.  Searching the kernel for uses of printk/pr_*
> and the string "deprecated" shows lots of potential use sites.

Does adding a couple of functions like:

void pr_warn_deprecated(const char *old, const char *new)
{
	static DEFINE_RATELIMIT_STATE(_rs,
				      DEFAULT_RATELIMIT_INTERVAL,
				      DEFAULT_RATELIMIT_BURST);

	if (!__ratelimit(&_rs))
		return;

	if (new)
		printk(KERN_WARNING "%pf: Use of \"%s\" is deprecated - use \"%s\" instead\n",
				    __builtin_return_address(1), old, new); 
	else
		printk(KERN_WARNING "%pf: Use of \"%s\" is deprecated\n",
				    __builtin_return_address(1), old); 
}

suit?  Other suggestions?

Looking at a slightly old allyesconfig vmlinux, there are a few that
fit the pattern that could use this style function.  Others have
variant/inappropriate forms.

Most are at KERN_WARNING, though a few are KERN_INFO.

$ strings vmlinux.o.old |grep -i deprecat
deprecated_sysctl_warning
4%s (%d): Attempt to access syslog with CAP_SYS_ADMIN but no CAP_SYSLOG (deprecated).
6warning: process `%s' used the deprecated sysctl system call with 
6warning: `%s' uses deprecated v2 capabilities in a way that may be insecure.
Warning: clock=pmtmr is deprecated. Use clocksource=acpi_pm.
Warning! clock= boot option is deprecated. Use clocksource=xyz
4cgroup: option changes via remount are deprecated (pid=%d comm=%s)
3AUDIT_POSSIBLE is deprecated
4%s (%d): /proc/%d/oom_adj is deprecated, please use /proc/%d/oom_score_adj instead.
Ignoring deprecated oldalloc option
Ignoring deprecated orlov option
warning: ignoring deprecated nobh option
warning: ignoring deprecated bh option
4%s (%d): Using mlock ulimits for SHM_HUGETLB is deprecated
Option iocharset is deprecated. Please use option nls=<charsetname> in the future.
delaylog is the default now, option is deprecated.
nodelaylog support has been removed, option is deprecated.
ihashsize no longer used, option is deprecated.
osyncisdsync has no effect, option is deprecated.
osyncisosync has no effect, option is deprecated.
irixsgid is now a sysctl(2) variable, option is deprecated.
4btrfs: 'subvolrootid' mount option is deprecated and has no effect
4program %s is using a deprecated SCSI ioctl, please convert it to SG_IO
4dynamic_debug:%s: ddebug_query param name is deprecated, change it to dyndbg
6sisfb: Deprecated ioctl call received - update your application!
4ACPI: Deprecated procfs I/F for AC is loaded, please retry with CONFIG_ACPI_PROCFS_POWER cleared
4ACPI: Deprecated procfs I/F for battery is loaded, please retry with CONFIG_ACPI_PROCFS_POWER cleared
4ACPI: Deprecated procfs I/F for SBS is loaded, please retry with CONFIG_ACPI_PROCFS_POWER cleared
5%s sets custom speed on %s. This is deprecated.
4mxser: '%s' uses deprecated ioctl %x (GET_MAJOR), fix your userspace
4warning: 'lp=0x%x' is deprecated, ignored
4program %s is using a deprecated SCSI ioctl, please convert it to SG_IO
43w-xxxx: SCSI_IOCTL_SEND_COMMAND deprecated, please update your 3ware tools.
master is unqueued, this is deprecated
Enabling SR-IOV VFs using the module parameter is deprecated - please use the pci sysfs interface.
Enabling SR-IOV VFs using the module parameter is deprecated - please use the pci sysfs interface.
7%s: process %d (%s) used deprecated iwpriv monitor - update software to use iwconfig mode monitor
7rtl8192c_common:%s(): deprecated!
7rtl8723ae:%s(): deprecated!
Loaded firmware %s, which is deprecated.  Please use API v%u instead.
4wlcore: WARNING chip id 0x%x (185x PG10) is deprecated
4amb: rejecting open with unspecified VPI/VCI (deprecated)
4hrz: rejecting open with unspecified VPI/VCI (deprecated)
WARNING: firmware file name %s is deprecated, please rename to %s
4WARNING! power/level is deprecated; use power/control instead
[Ueagle-atm] use deprecated cmvs version, please update your firmware
%s: attach_adapter method is deprecated
4%s: Choosing the clock frequency based on index is deprecated. Use the nominal frequency.
Sensor type %d is deprecated, please use 4 instead
Sensor type %d is deprecated, please use 4 instead
Sensor type 2 is deprecated, please use 4 instead
4ib_srp: srp_sg_tablesize is deprecated, please use cmd_sg_entries
deprecated sysfs attribute
4thinkpad_acpi: WARNING: sysfs attribute %s is deprecated and will be removed. %s
3thinkpad_acpi: Please remove the hotkey=enable module parameter, it is deprecated.  Hotkeys are always enabled.
4Loading kernel module for a network device with CAP_SYS_MODULE (deprecated).  Use CAP_NET_ADMIN and alias netdev-%s instead.
6nf_conntrack: automatic helper assignment is deprecated and it will be removed soon. Use the iptables CT target to attach helpers instead.
6xt_CT: netfilter: NOTRACK target is deprecated, use CT instead or upgrade iptables
6ipt_ULOG: ULOG is deprecated and it will be removed soon, use NFLOG instead
4ICMPv6: process `%s' is using deprecated sysctl (%s) net.ipv6.neigh.%s.%s - use net.ipv6.neigh.%s.%s_ms instead
6ebt_ulog: ebt_ulog is deprecated and it will be removed soon, use ebt_nflog instead
4%s: sockopt(PACKET_SIZE) is deprecated: fix your app
4%s: sockopt(CHANGE_L/R) is deprecated: fix your app
4sctp: Use of struct sctp_assoc_value in delayed_ack socket option deprecated
4sctp: Use of int in maxseg socket option deprecated
4sctp: Use of int in max_burst socket option deprecated
4libceph: ignoring deprecated osdtimeout option
sysfs.deprecated

Re: [PATCH] SCTP: Reduce log spamming for sctp setsockopt

[Neil Horman]

On Mon, Dec 16, 2013 at 08:50:35AM -0800, Joe Perches wrote:
> On Mon, 2013-12-16 at 11:04 -0500, Neil Horman wrote:
> > On Mon, Dec 16, 2013 at 04:45:05PM +0100, Daniel Borkmann wrote:
> > > On 12/16/2013 04:21 PM, Joe Perches wrote:
> > > >On Mon, 2013-12-16 at 16:13 +0100, Daniel Borkmann wrote:
> > > >>On 12/16/2013 04:03 PM, Joe Perches wrote:
> > > >>>On Mon, 2013-12-16 at 09:44 -0500, Neil Horman wrote:
> > > >>>>During a recent discussion regarding some sctp socket options, it was noted that
> > > >>>>we have several points at which we issue log warnings that can be flooded at an
> > > >>>>unbounded rate by any user.  Fix this by converting all the pr_warns in the
> > > >>>>sctp_setsockopt path to be pr_warn_ratelimited.
> > > >>>
> > > >>>trivial note:
> > > >>[...]
> > > >>>>@@ -5311,8 +5311,8 @@ static int sctp_getsockopt_maxburst(struct sock *sk, int len,
> > > >>>[]
> > > >>>>+		pr_warn_ratelimited("Use of int in max_burst socket option deprecated\n");
> > > >>>>+		pr_warn_ratelimited("Use struct sctp_assoc_value instead\n");
> > > >>>
> > > >>>Perhaps a dedicated "deprecated" warning function
> > > >>>to centralize these?
> > > >>>
> > > >>>void _sctp_warn_deprecated(const char *func, const char *from, const char *to);
> > > >>>{
> > > >>>	etc.
> > > >>>}
> > > >>>#define sctp_warn_deprecated(from, to)		\
> > > >>>	_sctp_warn_deprecated(__func__, from, to)
> > > >>
> > > >>If so, then this should better get even more "centralized" ... as e.g.
> > > >>pr_warn_deprecated() [which internally is ratelimited]. I don't see the
> > > >>point why only SCTP should have this special-cased.
> > > >
> > > >Sure, if it's useful outside of sctp, but I didn't
> > > >notice any other uses like it.
> > > 
> > > If we have a generic API for that, they might come, sure.
> > I agree with Daniel.  If we're going to make this common, theres no reason to
> > not make it common for all uses.  Searching the kernel for uses of printk/pr_*
> > and the string "deprecated" shows lots of potential use sites.
> 
> Does adding a couple of functions like:
> 
> void pr_warn_deprecated(const char *old, const char *new)
> {
> 	static DEFINE_RATELIMIT_STATE(_rs,
> 				      DEFAULT_RATELIMIT_INTERVAL,
> 				      DEFAULT_RATELIMIT_BURST);
> 
> 	if (!__ratelimit(&_rs))
> 		return;
> 
> 	if (new)
> 		printk(KERN_WARNING "%pf: Use of \"%s\" is deprecated - use \"%s\" instead\n",
> 				    __builtin_return_address(1), old, new); 
> 	else
> 		printk(KERN_WARNING "%pf: Use of \"%s\" is deprecated\n",
> 				    __builtin_return_address(1), old); 
> }
> 
> suit?  Other suggestions?
> 

i'm just doing this:
#define pr_warn_deprecated(fmt, ...) \
pr_warn_ratelimited("Deprecated: " fmt, ##__VA_ARGS__)

That will work for every form, giving consistency to the location of a single
word for ease of searching.  I don't really see the need to institutionalize
"use <blank> instead", since there may be no drop in replacement for something
that is deprecated.

Neil

Re: [PATCH] SCTP: Reduce log spamming for sctp setsockopt

[Joe Perches]

On Mon, 2013-12-16 at 12:02 -0500, Neil Horman wrote:
> On Mon, Dec 16, 2013 at 08:50:35AM -0800, Joe Perches wrote:
[]
> > Does adding a couple of functions like:
> > 
> > void pr_warn_deprecated(const char *old, const char *new)
> > {
> > 	static DEFINE_RATELIMIT_STATE(_rs,
> > 				      DEFAULT_RATELIMIT_INTERVAL,
> > 				      DEFAULT_RATELIMIT_BURST);
> > 
> > 	if (!__ratelimit(&_rs))
> > 		return;
> > 
> > 	if (new)
> > 		printk(KERN_WARNING "%pf: Use of \"%s\" is deprecated - use \"%s\" instead\n",
> > 				    __builtin_return_address(1), old, new); 
> > 	else
> > 		printk(KERN_WARNING "%pf: Use of \"%s\" is deprecated\n",
> > 				    __builtin_return_address(1), old); 
> > }
> > 
> > suit?  Other suggestions?
> > 
> 
> i'm just doing this:
> #define pr_warn_deprecated(fmt, ...) \
> pr_warn_ratelimited("Deprecated: " fmt, ##__VA_ARGS__)
> 
> That will work for every form, giving consistency to the location of a single
> word for ease of searching.  I don't really see the need to institutionalize
> "use <blank> instead", since there may be no drop in replacement for something
> that is deprecated.

That's what the test for non-null "new" was for
but fine, it's your code.

Do what you think appropriate.

Also, using pr_warn_once may be better.  Dunno.

cheers, Joe

Re: [PATCH] SCTP: Reduce log spamming for sctp setsockopt

[Daniel Borkmann]

On 12/16/2013 05:50 PM, Joe Perches wrote:
> On Mon, 2013-12-16 at 11:04 -0500, Neil Horman wrote:
>> On Mon, Dec 16, 2013 at 04:45:05PM +0100, Daniel Borkmann wrote:
>>> On 12/16/2013 04:21 PM, Joe Perches wrote:
>>>> On Mon, 2013-12-16 at 16:13 +0100, Daniel Borkmann wrote:
>>>>> On 12/16/2013 04:03 PM, Joe Perches wrote:
>>>>>> On Mon, 2013-12-16 at 09:44 -0500, Neil Horman wrote:
>>>>>>> During a recent discussion regarding some sctp socket options, it was noted that
>>>>>>> we have several points at which we issue log warnings that can be flooded at an
>>>>>>> unbounded rate by any user.  Fix this by converting all the pr_warns in the
>>>>>>> sctp_setsockopt path to be pr_warn_ratelimited.
>>>>>>
>>>>>> trivial note:
>>>>> [...]
>>>>>>> @@ -5311,8 +5311,8 @@ static int sctp_getsockopt_maxburst(struct sock *sk, int len,
>>>>>> []
>>>>>>> +		pr_warn_ratelimited("Use of int in max_burst socket option deprecated\n");
>>>>>>> +		pr_warn_ratelimited("Use struct sctp_assoc_value instead\n");
>>>>>>
>>>>>> Perhaps a dedicated "deprecated" warning function
>>>>>> to centralize these?
>>>>>>
>>>>>> void _sctp_warn_deprecated(const char *func, const char *from, const char *to);
>>>>>> {
>>>>>> 	etc.
>>>>>> }
>>>>>> #define sctp_warn_deprecated(from, to)		\
>>>>>> 	_sctp_warn_deprecated(__func__, from, to)
>>>>>
>>>>> If so, then this should better get even more "centralized" ... as e.g.
>>>>> pr_warn_deprecated() [which internally is ratelimited]. I don't see the
>>>>> point why only SCTP should have this special-cased.
>>>>
>>>> Sure, if it's useful outside of sctp, but I didn't
>>>> notice any other uses like it.
>>>
>>> If we have a generic API for that, they might come, sure.
>> I agree with Daniel.  If we're going to make this common, theres no reason to
>> not make it common for all uses.  Searching the kernel for uses of printk/pr_*
>> and the string "deprecated" shows lots of potential use sites.
>
> Does adding a couple of functions like:

Maybe you can also have a macro wrapper that "textyfies" old and new,
such that you don't need the "" all the time. Otherwise looks good to
me.

> void pr_warn_deprecated(const char *old, const char *new)
> {
> 	static DEFINE_RATELIMIT_STATE(_rs,
> 				      DEFAULT_RATELIMIT_INTERVAL,
> 				      DEFAULT_RATELIMIT_BURST);
>
> 	if (!__ratelimit(&_rs))
> 		return;
>
> 	if (new)
> 		printk(KERN_WARNING "%pf: Use of \"%s\" is deprecated - use \"%s\" instead\n",
> 				    __builtin_return_address(1), old, new);
> 	else
> 		printk(KERN_WARNING "%pf: Use of \"%s\" is deprecated\n",
> 				    __builtin_return_address(1), old);
> }
>
> suit?  Other suggestions?
>
> Looking at a slightly old allyesconfig vmlinux, there are a few that
> fit the pattern that could use this style function.  Others have
> variant/inappropriate forms.
>
> Most are at KERN_WARNING, though a few are KERN_INFO.
>
> $ strings vmlinux.o.old |grep -i deprecat
> deprecated_sysctl_warning
> 4%s (%d): Attempt to access syslog with CAP_SYS_ADMIN but no CAP_SYSLOG (deprecated).
> 6warning: process `%s' used the deprecated sysctl system call with
> 6warning: `%s' uses deprecated v2 capabilities in a way that may be insecure.
> Warning: clock=pmtmr is deprecated. Use clocksource=acpi_pm.
> Warning! clock= boot option is deprecated. Use clocksource=xyz
> 4cgroup: option changes via remount are deprecated (pid=%d comm=%s)
> 3AUDIT_POSSIBLE is deprecated
> 4%s (%d): /proc/%d/oom_adj is deprecated, please use /proc/%d/oom_score_adj instead.
> Ignoring deprecated oldalloc option
> Ignoring deprecated orlov option
> warning: ignoring deprecated nobh option
> warning: ignoring deprecated bh option
> 4%s (%d): Using mlock ulimits for SHM_HUGETLB is deprecated
> Option iocharset is deprecated. Please use option nls=<charsetname> in the future.
> delaylog is the default now, option is deprecated.
> nodelaylog support has been removed, option is deprecated.
> ihashsize no longer used, option is deprecated.
> osyncisdsync has no effect, option is deprecated.
> osyncisosync has no effect, option is deprecated.
> irixsgid is now a sysctl(2) variable, option is deprecated.
> 4btrfs: 'subvolrootid' mount option is deprecated and has no effect
> 4program %s is using a deprecated SCSI ioctl, please convert it to SG_IO
> 4dynamic_debug:%s: ddebug_query param name is deprecated, change it to dyndbg
> 6sisfb: Deprecated ioctl call received - update your application!
> 4ACPI: Deprecated procfs I/F for AC is loaded, please retry with CONFIG_ACPI_PROCFS_POWER cleared
> 4ACPI: Deprecated procfs I/F for battery is loaded, please retry with CONFIG_ACPI_PROCFS_POWER cleared
> 4ACPI: Deprecated procfs I/F for SBS is loaded, please retry with CONFIG_ACPI_PROCFS_POWER cleared
> 5%s sets custom speed on %s. This is deprecated.
> 4mxser: '%s' uses deprecated ioctl %x (GET_MAJOR), fix your userspace
> 4warning: 'lp=0x%x' is deprecated, ignored
> 4program %s is using a deprecated SCSI ioctl, please convert it to SG_IO
> 43w-xxxx: SCSI_IOCTL_SEND_COMMAND deprecated, please update your 3ware tools.
> master is unqueued, this is deprecated
> Enabling SR-IOV VFs using the module parameter is deprecated - please use the pci sysfs interface.
> Enabling SR-IOV VFs using the module parameter is deprecated - please use the pci sysfs interface.
> 7%s: process %d (%s) used deprecated iwpriv monitor - update software to use iwconfig mode monitor
> 7rtl8192c_common:%s(): deprecated!
> 7rtl8723ae:%s(): deprecated!
> Loaded firmware %s, which is deprecated.  Please use API v%u instead.
> 4wlcore: WARNING chip id 0x%x (185x PG10) is deprecated
> 4amb: rejecting open with unspecified VPI/VCI (deprecated)
> 4hrz: rejecting open with unspecified VPI/VCI (deprecated)
> WARNING: firmware file name %s is deprecated, please rename to %s
> 4WARNING! power/level is deprecated; use power/control instead
> [Ueagle-atm] use deprecated cmvs version, please update your firmware
> %s: attach_adapter method is deprecated
> 4%s: Choosing the clock frequency based on index is deprecated. Use the nominal frequency.
> Sensor type %d is deprecated, please use 4 instead
> Sensor type %d is deprecated, please use 4 instead
> Sensor type 2 is deprecated, please use 4 instead
> 4ib_srp: srp_sg_tablesize is deprecated, please use cmd_sg_entries
> deprecated sysfs attribute
> 4thinkpad_acpi: WARNING: sysfs attribute %s is deprecated and will be removed. %s
> 3thinkpad_acpi: Please remove the hotkey=enable module parameter, it is deprecated.  Hotkeys are always enabled.
> 4Loading kernel module for a network device with CAP_SYS_MODULE (deprecated).  Use CAP_NET_ADMIN and alias netdev-%s instead.
> 6nf_conntrack: automatic helper assignment is deprecated and it will be removed soon. Use the iptables CT target to attach helpers instead.
> 6xt_CT: netfilter: NOTRACK target is deprecated, use CT instead or upgrade iptables
> 6ipt_ULOG: ULOG is deprecated and it will be removed soon, use NFLOG instead
> 4ICMPv6: process `%s' is using deprecated sysctl (%s) net.ipv6.neigh.%s.%s - use net.ipv6.neigh.%s.%s_ms instead
> 6ebt_ulog: ebt_ulog is deprecated and it will be removed soon, use ebt_nflog instead
> 4%s: sockopt(PACKET_SIZE) is deprecated: fix your app
> 4%s: sockopt(CHANGE_L/R) is deprecated: fix your app
> 4sctp: Use of struct sctp_assoc_value in delayed_ack socket option deprecated
> 4sctp: Use of int in maxseg socket option deprecated
> 4sctp: Use of int in max_burst socket option deprecated
> 4libceph: ignoring deprecated osdtimeout option
> sysfs.deprecated
>
>

RE: [PATCH] SCTP: Reduce log spamming for sctp setsockopt

[David Laight]

> From: Neil Horman
> During a recent discussion regarding some sctp socket options, it was noted that
> we have several points at which we issue log warnings that can be flooded at an
> unbounded rate by any user.  Fix this by converting all the pr_warns in the
> sctp_setsockopt path to be pr_warn_ratelimited.
> 
> Note there are several debug level messages as well.  I'm leaving those alone,
> as, if you turn on pr_debug, you likely want lots of verbosity.
...
> -		pr_warn("Use of struct sctp_assoc_value in delayed_ack socket option deprecated\n");
> -		pr_warn("Use struct sctp_sack_info instead\n");
> +		pr_warn_ratelimited("Use of struct sctp_assoc_value in delayed_ack socket option
> deprecated\n");
> +		pr_warn_ratelimited("Use struct sctp_sack_info instead\n");

Do you need to send these as a single ratelimited message?

	David

Re: [PATCH] SCTP: Reduce log spamming for sctp setsockopt

[Neil Horman]

On Mon, Dec 16, 2013 at 03:24:48PM -0000, David Laight wrote:
> > From: Neil Horman
> > During a recent discussion regarding some sctp socket options, it was noted that
> > we have several points at which we issue log warnings that can be flooded at an
> > unbounded rate by any user.  Fix this by converting all the pr_warns in the
> > sctp_setsockopt path to be pr_warn_ratelimited.
> > 
> > Note there are several debug level messages as well.  I'm leaving those alone,
> > as, if you turn on pr_debug, you likely want lots of verbosity.
> ...
> > -		pr_warn("Use of struct sctp_assoc_value in delayed_ack socket option deprecated\n");
> > -		pr_warn("Use struct sctp_sack_info instead\n");
> > +		pr_warn_ratelimited("Use of struct sctp_assoc_value in delayed_ack socket option
> > deprecated\n");
> > +		pr_warn_ratelimited("Use struct sctp_sack_info instead\n");
> 
> Do you need to send these as a single ratelimited message?
> 
> 	David
> 
Oh, good point, I'll clean that up.  Thanks!
Neil

> 
> 
> --
> 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
> 

[PATCH v2 0/2] sctp: Consolidate and ratelimit deprecation warnings

[Neil Horman]

The SCTP protocol has several deprecation warnings in its setsockopt path that
can be triggered by unprivlidged users.  Since these are not ratelimited, we can
spam the logs quite easily here.  Since these are all deprecation warnings, and
that type of warning isn't uncommon in the rest of the kernel, lets make a
common pr_warn_deprecated macro to produce somewhat generalized ratelimited
deprecation warnings easily

Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: Vlad Yasevich <vyasevich@gmail.com>
CC: David Miller <davem@davemloft.net>
CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CC: netdev@vger.kernel.org
CC: linux-kernel@vger.kernel.org

[PATCH v2 2/2] SCTP: Reduce log spamming for sctp setsockopt

[Neil Horman]

During a recent discussion regarding some sctp socket options, it was noted that
we have several points at which we issue log warnings that can be flooded at an
unbounded rate by any user.  Fix this by converting all the pr_warns in the
sctp_setsockopt path to be pr_warn_ratelimited.

Note there are several debug level messages as well.  I'm leaving those alone,
as, if you turn on pr_debug, you likely want lots of verbosity.

Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: Vlad Yasevich <vyasevich@gmail.com>
CC: David Miller <davem@davemloft.net>
CC: netdev@vger.kernel.org

---

Change notes:

V2)
	* Based on suggestions from Daniel Borkman, and Joe Perches I'm creating
and using a new pr_warn_deprecated macro

	* Note from David Laight, The pr_warn statements come in pairs, and if
one is printed through the ratelimit filter, the other should also be printed.
Correct this by merging both calls into a single pr_warn_deprecated call.
---
 net/sctp/socket.c | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index 42b709c..77815f5 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -2579,8 +2579,8 @@ static int sctp_setsockopt_delayed_ack(struct sock *sk,
 		if (params.sack_delay == 0 && params.sack_freq == 0)
 			return 0;
 	} else if (optlen == sizeof(struct sctp_assoc_value)) {
-		pr_warn("Use of struct sctp_assoc_value in delayed_ack socket option deprecated\n");
-		pr_warn("Use struct sctp_sack_info instead\n");
+		pr_warn_deprecated("Use of struct sctp_assoc_value in delayed_ack socket option.\n"
+				   "Use struct sctp_sack_info instead\n");
 		if (copy_from_user(&params, optval, optlen))
 			return -EFAULT;
 
@@ -2995,8 +2995,8 @@ static int sctp_setsockopt_maxseg(struct sock *sk, char __user *optval, unsigned
 	int val;
 
 	if (optlen == sizeof(int)) {
-		pr_warn("Use of int in maxseg socket option deprecated\n");
-		pr_warn("Use struct sctp_assoc_value instead\n");
+		pr_warn_deprecated("Use of int in maxseg socket option.\n"
+				   "Use struct sctp_assoc_value instead\n");
 		if (copy_from_user(&val, optval, optlen))
 			return -EFAULT;
 		params.assoc_id = 0;
@@ -3253,8 +3253,8 @@ static int sctp_setsockopt_maxburst(struct sock *sk,
 	int assoc_id = 0;
 
 	if (optlen == sizeof(int)) {
-		pr_warn("Use of int in max_burst socket option deprecated\n");
-		pr_warn("Use struct sctp_assoc_value instead\n");
+		pr_warn_deprecated("Use of int in max_burst socket option deprecated.\n"
+				   "Use struct sctp_assoc_value instead\n");
 		if (copy_from_user(&val, optval, optlen))
 			return -EFAULT;
 	} else if (optlen == sizeof(struct sctp_assoc_value)) {
@@ -4574,8 +4574,8 @@ static int sctp_getsockopt_delayed_ack(struct sock *sk, int len,
 		if (copy_from_user(&params, optval, len))
 			return -EFAULT;
 	} else if (len == sizeof(struct sctp_assoc_value)) {
-		pr_warn("Use of struct sctp_assoc_value in delayed_ack socket option deprecated\n");
-		pr_warn("Use struct sctp_sack_info instead\n");
+		pr_warn_deprecated("Use of struct sctp_assoc_value in delayed_ack socket option.\n"
+				   "Use struct sctp_sack_info instead\n");
 		if (copy_from_user(&params, optval, len))
 			return -EFAULT;
 	} else
@@ -5219,8 +5219,8 @@ static int sctp_getsockopt_maxseg(struct sock *sk, int len,
 	struct sctp_association *asoc;
 
 	if (len == sizeof(int)) {
-		pr_warn("Use of int in maxseg socket option deprecated\n");
-		pr_warn("Use struct sctp_assoc_value instead\n");
+		pr_warn_deprecated("Use of int in maxseg socket option.\n"
+				   "Use struct sctp_assoc_value instead\n");
 		params.assoc_id = 0;
 	} else if (len >= sizeof(struct sctp_assoc_value)) {
 		len = sizeof(struct sctp_assoc_value);
@@ -5311,8 +5311,8 @@ static int sctp_getsockopt_maxburst(struct sock *sk, int len,
 	struct sctp_association *asoc;
 
 	if (len == sizeof(int)) {
-		pr_warn("Use of int in max_burst socket option deprecated\n");
-		pr_warn("Use struct sctp_assoc_value instead\n");
+		pr_warn_deprecated("Use of int in max_burst socket option.\n"
+				   "Use struct sctp_assoc_value instead\n");
 		params.assoc_id = 0;
 	} else if (len >= sizeof(struct sctp_assoc_value)) {
 		len = sizeof(struct sctp_assoc_value);
-- 
1.8.3.1

[PATCH v3 0/2] sctp: Consolidate and ratelimit deprecation warnings

[Neil Horman]

The SCTP protocol has several deprecation warnings in its setsockopt path that
can be triggered by unprivlidged users.  Since these are not ratelimited, we can
spam the logs quite easily here.  Since these are all deprecation warnings, and
that type of warning isn't uncommon in the rest of the kernel, lets make a
common pr_warn_deprecated macro to produce somewhat generalized ratelimited
deprecation warnings easily

Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: Vlad Yasevich <vyasevich@gmail.com>
CC: David Miller <davem@davemloft.net>
CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CC: netdev@vger.kernel.org
CC: linux-kernel@vger.kernel.org

---
Change notes

v2) Converted to use a pr_warn_deprecated macro
v3) Converted to use a DEPRECATED macro with regular pr_* macros

[PATCH v3 2/2] SCTP: Reduce log spamming for sctp setsockopt

[Neil Horman]

During a recent discussion regarding some sctp socket options, it was noted that
we have several points at which we issue log warnings that can be flooded at an
unbounded rate by any user.  Fix this by converting all the pr_warns in the
sctp_setsockopt path to be pr_warn_ratelimited.

Note there are several debug level messages as well.  I'm leaving those alone,
as, if you turn on pr_debug, you likely want lots of verbosity.

Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: Vlad Yasevich <vyasevich@gmail.com>
CC: David Miller <davem@davemloft.net>
CC: netdev@vger.kernel.org

---

Change notes:

V2)
	* Based on suggestions from Daniel Borkman, and Joe Perches I'm creating
and using a new pr_warn_deprecated macro

	* Note from David Laight, The pr_warn statements come in pairs, and if
one is printed through the ratelimit filter, the other should also be printed.
Correct this by merging both calls into a single pr_warn_deprecated call.

v3)
	* Convert to using DEPRECATED macro
---
 net/sctp/socket.c | 30 ++++++++++++++++++------------
 1 file changed, 18 insertions(+), 12 deletions(-)

diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index 42b709c..edd261e 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -2579,8 +2579,9 @@ static int sctp_setsockopt_delayed_ack(struct sock *sk,
 		if (params.sack_delay == 0 && params.sack_freq == 0)
 			return 0;
 	} else if (optlen == sizeof(struct sctp_assoc_value)) {
-		pr_warn("Use of struct sctp_assoc_value in delayed_ack socket option deprecated\n");
-		pr_warn("Use struct sctp_sack_info instead\n");
+		pr_warn_ratelimited(DEPRECATED
+				    "Use of struct sctp_assoc_value in delayed_ack socket option.\n"
+				    "Use struct sctp_sack_info instead\n");
 		if (copy_from_user(&params, optval, optlen))
 			return -EFAULT;
 
@@ -2995,8 +2996,9 @@ static int sctp_setsockopt_maxseg(struct sock *sk, char __user *optval, unsigned
 	int val;
 
 	if (optlen == sizeof(int)) {
-		pr_warn("Use of int in maxseg socket option deprecated\n");
-		pr_warn("Use struct sctp_assoc_value instead\n");
+		pr_warn_ratelimited(DEPRECATED
+				    "Use of int in maxseg socket option.\n"
+				    "Use struct sctp_assoc_value instead\n");
 		if (copy_from_user(&val, optval, optlen))
 			return -EFAULT;
 		params.assoc_id = 0;
@@ -3253,8 +3255,9 @@ static int sctp_setsockopt_maxburst(struct sock *sk,
 	int assoc_id = 0;
 
 	if (optlen == sizeof(int)) {
-		pr_warn("Use of int in max_burst socket option deprecated\n");
-		pr_warn("Use struct sctp_assoc_value instead\n");
+		pr_warn_ratelimited(DEPRECATED
+				    "Use of int in max_burst socket option deprecated.\n"
+				    "Use struct sctp_assoc_value instead\n");
 		if (copy_from_user(&val, optval, optlen))
 			return -EFAULT;
 	} else if (optlen == sizeof(struct sctp_assoc_value)) {
@@ -4574,8 +4577,9 @@ static int sctp_getsockopt_delayed_ack(struct sock *sk, int len,
 		if (copy_from_user(&params, optval, len))
 			return -EFAULT;
 	} else if (len == sizeof(struct sctp_assoc_value)) {
-		pr_warn("Use of struct sctp_assoc_value in delayed_ack socket option deprecated\n");
-		pr_warn("Use struct sctp_sack_info instead\n");
+		pr_warn_ratelimited(DEPRECATED
+				    "Use of struct sctp_assoc_value in delayed_ack socket option.\n"
+				    "Use struct sctp_sack_info instead\n");
 		if (copy_from_user(&params, optval, len))
 			return -EFAULT;
 	} else
@@ -5219,8 +5223,9 @@ static int sctp_getsockopt_maxseg(struct sock *sk, int len,
 	struct sctp_association *asoc;
 
 	if (len == sizeof(int)) {
-		pr_warn("Use of int in maxseg socket option deprecated\n");
-		pr_warn("Use struct sctp_assoc_value instead\n");
+		pr_warn_ratelimited(DEPRECATED
+				    "Use of int in maxseg socket option.\n"
+				    "Use struct sctp_assoc_value instead\n");
 		params.assoc_id = 0;
 	} else if (len >= sizeof(struct sctp_assoc_value)) {
 		len = sizeof(struct sctp_assoc_value);
@@ -5311,8 +5316,9 @@ static int sctp_getsockopt_maxburst(struct sock *sk, int len,
 	struct sctp_association *asoc;
 
 	if (len == sizeof(int)) {
-		pr_warn("Use of int in max_burst socket option deprecated\n");
-		pr_warn("Use struct sctp_assoc_value instead\n");
+		pr_warn_ratelimited(DEPRECATED
+				    "Use of int in max_burst socket option.\n"
+				    "Use struct sctp_assoc_value instead\n");
 		params.assoc_id = 0;
 	} else if (len >= sizeof(struct sctp_assoc_value)) {
 		len = sizeof(struct sctp_assoc_value);
-- 
1.8.3.1

Re: [PATCH v3 0/2] sctp: Consolidate and ratelimit deprecation warnings

[David Miller]

From: Neil Horman <nhorman@tuxdriver.com>
Date: Tue, 17 Dec 2013 11:19:57 -0500

> The SCTP protocol has several deprecation warnings in its setsockopt path that
> can be triggered by unprivlidged users.  Since these are not ratelimited, we can
> spam the logs quite easily here.  Since these are all deprecation warnings, and
> that type of warning isn't uncommon in the rest of the kernel, lets make a
> common pr_warn_deprecated macro to produce somewhat generalized ratelimited
> deprecation warnings easily
> 
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>

Neil, I really wish you would CC: netdev on all of the patches in the
series.  Otherwise only some of them end up in patchwork, and this makes
a lot more work for me if I want to actually apply this, which I do.

Please resubmit this properly, thanks.

Re: [PATCH v3 0/2] sctp: Consolidate and ratelimit deprecation warnings

[Neil Horman]

On Sun, Dec 22, 2013 at 05:56:59PM -0500, David Miller wrote:
> From: Neil Horman <nhorman@tuxdriver.com>
> Date: Tue, 17 Dec 2013 11:19:57 -0500
> 
> > The SCTP protocol has several deprecation warnings in its setsockopt path that
> > can be triggered by unprivlidged users.  Since these are not ratelimited, we can
> > spam the logs quite easily here.  Since these are all deprecation warnings, and
> > that type of warning isn't uncommon in the rest of the kernel, lets make a
> > common pr_warn_deprecated macro to produce somewhat generalized ratelimited
> > deprecation warnings easily
> > 
> > Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> 
> Neil, I really wish you would CC: netdev on all of the patches in the
> series.  Otherwise only some of them end up in patchwork, and this makes
> a lot more work for me if I want to actually apply this, which I do.
> 
> Please resubmit this properly, thanks.
> 

Will do, thanks.
Neil

[PATCH v4 0/2] sctp: Consolidate and ratelimit deprecation warnings

[Neil Horman]

The SCTP protocol has several deprecation warnings in its setsockopt path that
can be triggered by unprivlidged users.  Since these are not ratelimited, we can
spam the logs quite easily here.  Since these are all deprecation warnings, and
that type of warning isn't uncommon in the rest of the kernel, lets make a
common pr_warn_deprecated macro to produce somewhat generalized ratelimited
deprecation warnings easily

Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: Vlad Yasevich <vyasevich@gmail.com>
CC: David Miller <davem@davemloft.net>
CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CC: netdev@vger.kernel.org
CC: linux-kernel@vger.kernel.org

---
Change notes

v2) Converted to use a pr_warn_deprecated macro
v3) Converted to use a DEPRECATED macro with regular pr_* macros
v4) CC netdev on all patches as per DaveM

[PATCH v4 1/2] printk: Add a DEPRECATED macro

[Neil Horman]

sctp has several points in its setsockopt path in which it issues deprecation
warnings.  It seems like it might be handy to macrotize such a warning so other
subsystems can use it easily

Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CC: "David S. Miller" <davem@davemloft.net>
CC: linux-kernel@vger.kernel.org
CC: netdev@vger.kernel.org

---
Change Notes:

v3)
* Convert to using a string prefix rather than a specific pr_ macro
---
 include/linux/printk.h | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/include/linux/printk.h b/include/linux/printk.h
index 6949258..26fb95c 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -88,6 +88,13 @@ struct va_format {
 #define HW_ERR		"[Hardware Error]: "
 
 /*
+ * DEPRECATED
+ * Add this to a message whenever you want to warn user space about the use
+ * of a deprecated aspect of an API so they can stop using it
+ */
+#define DEPRECATED	"[Deprecated]: "
+
+/*
  * Dummy printk for disabled debugging statements to use whilst maintaining
  * gcc's format and side-effect checking.
  */
-- 
1.8.3.1

[PATCH v4 2/2] SCTP: Reduce log spamming for sctp setsockopt

[Neil Horman]

During a recent discussion regarding some sctp socket options, it was noted that
we have several points at which we issue log warnings that can be flooded at an
unbounded rate by any user.  Fix this by converting all the pr_warns in the
sctp_setsockopt path to be pr_warn_ratelimited.

Note there are several debug level messages as well.  I'm leaving those alone,
as, if you turn on pr_debug, you likely want lots of verbosity.

Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: Vlad Yasevich <vyasevich@gmail.com>
CC: David Miller <davem@davemloft.net>
CC: netdev@vger.kernel.org

---

Change notes:

V2)
	* Based on suggestions from Daniel Borkman, and Joe Perches I'm creating
and using a new pr_warn_deprecated macro

	* Note from David Laight, The pr_warn statements come in pairs, and if
one is printed through the ratelimit filter, the other should also be printed.
Correct this by merging both calls into a single pr_warn_deprecated call.

v3)
	* Convert to using DEPRECATED macro
---
 net/sctp/socket.c | 30 ++++++++++++++++++------------
 1 file changed, 18 insertions(+), 12 deletions(-)

diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index 42b709c..edd261e 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -2579,8 +2579,9 @@ static int sctp_setsockopt_delayed_ack(struct sock *sk,
 		if (params.sack_delay == 0 && params.sack_freq == 0)
 			return 0;
 	} else if (optlen == sizeof(struct sctp_assoc_value)) {
-		pr_warn("Use of struct sctp_assoc_value in delayed_ack socket option deprecated\n");
-		pr_warn("Use struct sctp_sack_info instead\n");
+		pr_warn_ratelimited(DEPRECATED
+				    "Use of struct sctp_assoc_value in delayed_ack socket option.\n"
+				    "Use struct sctp_sack_info instead\n");
 		if (copy_from_user(&params, optval, optlen))
 			return -EFAULT;
 
@@ -2995,8 +2996,9 @@ static int sctp_setsockopt_maxseg(struct sock *sk, char __user *optval, unsigned
 	int val;
 
 	if (optlen == sizeof(int)) {
-		pr_warn("Use of int in maxseg socket option deprecated\n");
-		pr_warn("Use struct sctp_assoc_value instead\n");
+		pr_warn_ratelimited(DEPRECATED
+				    "Use of int in maxseg socket option.\n"
+				    "Use struct sctp_assoc_value instead\n");
 		if (copy_from_user(&val, optval, optlen))
 			return -EFAULT;
 		params.assoc_id = 0;
@@ -3253,8 +3255,9 @@ static int sctp_setsockopt_maxburst(struct sock *sk,
 	int assoc_id = 0;
 
 	if (optlen == sizeof(int)) {
-		pr_warn("Use of int in max_burst socket option deprecated\n");
-		pr_warn("Use struct sctp_assoc_value instead\n");
+		pr_warn_ratelimited(DEPRECATED
+				    "Use of int in max_burst socket option deprecated.\n"
+				    "Use struct sctp_assoc_value instead\n");
 		if (copy_from_user(&val, optval, optlen))
 			return -EFAULT;
 	} else if (optlen == sizeof(struct sctp_assoc_value)) {
@@ -4574,8 +4577,9 @@ static int sctp_getsockopt_delayed_ack(struct sock *sk, int len,
 		if (copy_from_user(&params, optval, len))
 			return -EFAULT;
 	} else if (len == sizeof(struct sctp_assoc_value)) {
-		pr_warn("Use of struct sctp_assoc_value in delayed_ack socket option deprecated\n");
-		pr_warn("Use struct sctp_sack_info instead\n");
+		pr_warn_ratelimited(DEPRECATED
+				    "Use of struct sctp_assoc_value in delayed_ack socket option.\n"
+				    "Use struct sctp_sack_info instead\n");
 		if (copy_from_user(&params, optval, len))
 			return -EFAULT;
 	} else
@@ -5219,8 +5223,9 @@ static int sctp_getsockopt_maxseg(struct sock *sk, int len,
 	struct sctp_association *asoc;
 
 	if (len == sizeof(int)) {
-		pr_warn("Use of int in maxseg socket option deprecated\n");
-		pr_warn("Use struct sctp_assoc_value instead\n");
+		pr_warn_ratelimited(DEPRECATED
+				    "Use of int in maxseg socket option.\n"
+				    "Use struct sctp_assoc_value instead\n");
 		params.assoc_id = 0;
 	} else if (len >= sizeof(struct sctp_assoc_value)) {
 		len = sizeof(struct sctp_assoc_value);
@@ -5311,8 +5316,9 @@ static int sctp_getsockopt_maxburst(struct sock *sk, int len,
 	struct sctp_association *asoc;
 
 	if (len == sizeof(int)) {
-		pr_warn("Use of int in max_burst socket option deprecated\n");
-		pr_warn("Use struct sctp_assoc_value instead\n");
+		pr_warn_ratelimited(DEPRECATED
+				    "Use of int in max_burst socket option.\n"
+				    "Use struct sctp_assoc_value instead\n");
 		params.assoc_id = 0;
 	} else if (len >= sizeof(struct sctp_assoc_value)) {
 		len = sizeof(struct sctp_assoc_value);
-- 
1.8.3.1

Re: [PATCH v4 0/2] sctp: Consolidate and ratelimit deprecation warnings

[Ben Hutchings]

On Mon, 2013-12-23 at 08:29 -0500, Neil Horman wrote:
> The SCTP protocol has several deprecation warnings in its setsockopt path that
> can be triggered by unprivlidged users.  Since these are not ratelimited, we can
> spam the logs quite easily here.  Since these are all deprecation warnings, and
> that type of warning isn't uncommon in the rest of the kernel, lets make a
> common pr_warn_deprecated macro to produce somewhat generalized ratelimited
> deprecation warnings easily
[...]

No objection to these changes, but I think deprecation warnings should
log at least the command name and maybe also the pid of the caller.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

Re: [PATCH v4 0/2] sctp: Consolidate and ratelimit deprecation warnings

[Neil Horman]

On Mon, Dec 23, 2013 at 10:55:16PM +0000, Ben Hutchings wrote:
> On Mon, 2013-12-23 at 08:29 -0500, Neil Horman wrote:
> > The SCTP protocol has several deprecation warnings in its setsockopt path that
> > can be triggered by unprivlidged users.  Since these are not ratelimited, we can
> > spam the logs quite easily here.  Since these are all deprecation warnings, and
> > that type of warning isn't uncommon in the rest of the kernel, lets make a
> > common pr_warn_deprecated macro to produce somewhat generalized ratelimited
> > deprecation warnings easily
> [...]
> 
> No objection to these changes, but I think deprecation warnings should
> log at least the command name and maybe also the pid of the caller.
> 
I didn't change the contents of the strings in this patch, I just wanted to
avoid log spamming, but I think adding caller pid/name is a good idea.  I'll do
that in a followon patch after the holidays
Neil

> Ben.
> 
> -- 
> Ben Hutchings, Staff Engineer, Solarflare
> Not speaking for my employer; that's the marketing department's job.
> They asked us to note that Solarflare product names are trademarked.
> 
> 

Re: [PATCH v4 0/2] sctp: Consolidate and ratelimit deprecation warnings

[David Miller]

From: Neil Horman <nhorman@tuxdriver.com>
Date: Mon, 23 Dec 2013 08:29:41 -0500

> The SCTP protocol has several deprecation warnings in its setsockopt path that
> can be triggered by unprivlidged users.  Since these are not ratelimited, we can
> spam the logs quite easily here.  Since these are all deprecation warnings, and
> that type of warning isn't uncommon in the rest of the kernel, lets make a
> common pr_warn_deprecated macro to produce somewhat generalized ratelimited
> deprecation warnings easily
> 
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>

Series applied, thanks Neil.

Please consider Ben's suggestion to provide the offending command string
in the log output.

Re: [PATCH v4 0/2] sctp: Consolidate and ratelimit deprecation warnings

[Joe Perches]

On Tue, 2013-12-31 at 14:00 -0500, David Miller wrote:
> From: Neil Horman <nhorman@tuxdriver.com>
> Date: Mon, 23 Dec 2013 08:29:41 -0500
> 
> > The SCTP protocol has several deprecation warnings in its setsockopt path that
> > can be triggered by unprivlidged users.  Since these are not ratelimited, we can
> > spam the logs quite easily here.  Since these are all deprecation warnings, and
> > that type of warning isn't uncommon in the rest of the kernel, lets make a
> > common pr_warn_deprecated macro to produce somewhat generalized ratelimited
> > deprecation warnings easily
> > 
> > Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> 
> Series applied, thanks Neil.
> 
> Please consider Ben's suggestion to provide the offending command string
> in the log output.

If something like the printk extension described in this thread
http://thread.gmane.org/gmane.linux.kernel/1620126 is ever accepted,
then it should be pretty easy to add later.

Re: [PATCH v4 0/2] sctp: Consolidate and ratelimit deprecation warnings

[Neil Horman]

On Tue, Dec 31, 2013 at 02:00:00PM -0500, David Miller wrote:
> From: Neil Horman <nhorman@tuxdriver.com>
> Date: Mon, 23 Dec 2013 08:29:41 -0500
> 
> > The SCTP protocol has several deprecation warnings in its setsockopt path that
> > can be triggered by unprivlidged users.  Since these are not ratelimited, we can
> > spam the logs quite easily here.  Since these are all deprecation warnings, and
> > that type of warning isn't uncommon in the rest of the kernel, lets make a
> > common pr_warn_deprecated macro to produce somewhat generalized ratelimited
> > deprecation warnings easily
> > 
> > Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> 
> Series applied, thanks Neil.
> 
> Please consider Ben's suggestion to provide the offending command string
> in the log output.
> 
Of course, I'll take care of it this week after I dig through all the holiday
email.
Neil