On Sat, Feb 09, 2019 at 03:12:17PM -0800, David Miller wrote: > From: Marcelo Ricardo Leitner <marcelo.leitner@xxxxxxxxx> > Date: Wed, 6 Feb 2019 18:37:54 -0200 > > > On Wed, Feb 06, 2019 at 12:14:30PM -0800, Julien Gomes wrote: > >> Make sctp_setsockopt_events() able to accept sctp_event_subscribe > >> structures longer than the current definitions. > >> > >> This should prevent unjustified setsockopt() failures due to struct > >> sctp_event_subscribe extensions (as in 4.11 and 4.12) when using > >> binaries that should be compatible, but were built with later kernel > >> uapi headers. > > > > Not sure if we support backwards compatibility like this? > > What a complete mess we have here. > > Use new socket option numbers next time, do not change the size and/or > layout of existing socket options. What about reusing the same socket option, but defining a new struct? Say, MYSOCKOPT supports struct mysockopt, struct mysockopt2, struct mysockopt3... That way we have a clear definition of the user's intent. > > This whole thread, if you read it, is basically "if we compatability > this way, that breaks, and if we do compatability this other way oh > shit this other thing doesn't work." > > I think we really need to specifically check for the difference sizes > that existed one by one, clear out the part not given by the user, and > backport this as far back as possible in a way that in the older kernels > we see if the user is actually trying to use the new features and if so > error out. I'm afraid clearing out may not be enough, though seems it's the best we can do so far. If the struct is allocated but not fully initialized via a memset, but by setting its fields one by one, the remaining new fields will be left uninitinialized. > > Which, btw, is terrible behavior. Newly compiled apps should work on > older kernels if they don't try to use the new features, and if they One use case here is: a given distro is using kernel X and app Foo is built against it. Then upgrades to X+1, Foo is patched to fix an issue and is rebuilt against X+1. The user upgrades Foo package but for whatever reason, doesn't upgrade kernel or reboot the system. Here, Foo doesn't work anymore until the new kernel is also running. > can the ones that want to try to use the new features should be able > to fall back when that feature isn't available in a non-ambiguous > and precisely defined way. > > The fact that the use of the new feature is hidden in the new > structure elements is really rotten. > > This patch, at best, needs some work and definitely a longer and more > detailed commit message.
