From: Harald Welte <laforge@gnumonks.org>
To: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Cc: Xin Long <lucien.xin@gmail.com>,
network dev <netdev@vger.kernel.org>,
linux-sctp@vger.kernel.org
Subject: Re: ABI breakage in sctp_event_subscribe (was [PATCH net-next 0/4] sctp: add some missing events from rfc5061)
Date: Mon, 1 Jun 2020 12:46:30 +0200 [thread overview]
Message-ID: <20200601104630.GQ182140@nataraja> (raw)
In-Reply-To: <20200501142008.GC2470@localhost.localdomain>
Dear SCTP developers,
I have to get back to this bug. It is slowly turning into a nightmare.
Not only affected it forwards/backwards compatibility of application binaries
during upgrades of a distribution, but it also affects the ability to run
containerized workloads with SCTP. It's sort-of obvious but I didn't
realize it until now.
We are observing this problem now when we operate CentOS 8 based containers
on a Debian 9 based (docker) host. Apparently the CentOS userland has a different
definition of the event structure (larger) than the Debian kernel has (smaller) -> boom.
From my point of view, this bug is making it virtually impossible to run
containerized telecom workloads. I guess most users are very
conservative and still running rather ancient kernels and/or
distributions, but as soon as they start upgrading their kernel to
anything that includes that patch to the SCTP events structure, the
nightmare starts.
To my knowledge, there is no infrastructure at all for a situation like this - neither
in the Docker universe nor in k8s.. You cannot build separate container
images depending on what the host OS/kernel is going to be.
And particularly, if you are not self-hosting your container runtimes
but running your containers on some kind of cloud infrastructure
provider, you have no control over what exact kernel version might be in
use there - and it also may change at any time at the discretion of the
cloud service provider.
On Fri, May 01, 2020 at 11:20:08AM -0300, Marcelo Ricardo Leitner wrote:
> That's what we want as well. Some breakage happened, yes, by mistake,
> and fixing that properly now, without breaking anything else, may be
> just impossible, unfortunatelly. But you can be sure that we are
> engaged on not doing it again.
I would actually seriously consider to roll that change back - not only
in the next kernel release but also in all stable kernel releases. At least
the breakage then is constrained to a limited set of kernel versions.
Alternatively, I suggest to at least apply a patch to all supported
stable kernel series (picked up hopefully distributions) that makes those
older kernels accept a larger-length sctp_event_subscribe structure from
userspace, *if* any of the additional members are 0 (memcmp the
difference between old and new).
Regards,
Harald
--
- Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
next prev parent reply other threads:[~2020-06-01 10:46 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-08 11:27 [PATCH net-next 0/4] sctp: add some missing events from rfc5061 Xin Long
2019-10-08 11:27 ` [PATCH net-next 1/4] sctp: add SCTP_ADDR_ADDED event Xin Long
2019-10-08 11:27 ` [PATCH net-next 2/4] sctp: add SCTP_ADDR_REMOVED event Xin Long
2019-10-08 11:27 ` [PATCH net-next 3/4] sctp: add SCTP_ADDR_MADE_PRIM event Xin Long
2019-10-08 11:27 ` [PATCH net-next 4/4] sctp: add SCTP_SEND_FAILED_EVENT event Xin Long
2019-10-09 18:13 ` [PATCH net-next 0/4] sctp: add some missing events from rfc5061 Neil Horman
2019-10-10 0:13 ` Jakub Kicinski
2020-04-19 10:25 ` ABI breakage in sctp_event_subscribe (was [PATCH net-next 0/4] sctp: add some missing events from rfc5061) Harald Welte
2020-05-01 13:16 ` Harald Welte
2020-05-01 14:20 ` Marcelo Ricardo Leitner
2020-06-01 10:46 ` Harald Welte [this message]
2020-06-01 12:14 ` Neil Horman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200601104630.GQ182140@nataraja \
--to=laforge@gnumonks.org \
--cc=linux-sctp@vger.kernel.org \
--cc=lucien.xin@gmail.com \
--cc=marcelo.leitner@gmail.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).