netdev - Re: [RFC net-next 1/1] : sctp: denoise deprecation log on SCTP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <559E60FD.5040708@iogearbox.net>
Date:	Thu, 09 Jul 2015 13:54:37 +0200
From:	Daniel Borkmann <daniel@...earbox.net>
To:	Jamal Hadi Salim <jhs@...atatu.com>
CC:	Neil Horman <nhorman@...driver.com>,
	Vlad Yasevich <vyasevic@...hat.com>,
	David Miller <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	mleitner@...hat.com, tuexen@...muenster.de
Subject: Re: [RFC net-next 1/1] : sctp: denoise deprecation log on SCTP_EVENTS

On 07/09/2015 12:38 PM, Jamal Hadi Salim wrote:
...
> 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 ...

> 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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html