[systemd-devel] Antw: [EXT] Re: [systemd‑devel] version bump of minimal kernel version supported by systemd?

[Greg Kroah-Hartman]

On Fri, Apr 01, 2022 at 07:39:25AM -0400, Neal Gompa wrote:
> On Thu, Mar 24, 2022 at 8:15 AM Greg Kroah-Hartman
> <gregkh at linuxfoundation.org> wrote:
> >
> > On Thu, Mar 24, 2022 at 10:23:21AM +0000, Luca Boccassi wrote:
> > > On Thu, 2022-03-24 at 09:45 +0100, Greg Kroah-Hartman wrote:
> > > > On Thu, Mar 24, 2022 at 09:33:50AM +0100, Ulrich Windl wrote:
> > > > > > > > Greg KH <gregkh at linuxfoundation.org> schrieb am 24.03.2022 um 08:12 in
> > > > > Nachricht <YjwZ56FP4Qgx3cMC at kroah.com>:
> > > > > > On Wed, Mar 23, 2022 at 10:34:00PM +0000, Dave Howorth wrote:
> > > > > > > FWIW, I think Greg was a bit too outspoken calling long maintenance
> > > > > > > attempts 'crazy'; that may have intimidated some. I'm thinking of
> > > > > > > moving distro to one that provides longer term maintenance than my
> > > > > > > present one. Although CIP is a completely different ball game; I hope
> > > > > > > they succeed.
> > > > > >
> > > > > > It is not "crazy" it is "well documented".  As someone who has been
> > > > > > doing this work for 20+ years now and sees all of the stable kernel
> > > > > > patches flow by, it's obvious that a distro that does not keep up with
> > > > > > them is insecure by design.
> > > > >
> > > > > If "newer is better" I'd agree. Sometimes "newer is actually worse".
> > > > > Some new features intended to improve things sometimes actually make things worse.
> > > >
> > > > That's not the issue here.
> > > >
> > > > Do you want to run a kernel with known security problems, or one with
> > > > "unknown potential problems."  The latter is always the case, so please
> > > > don't pick the known-insecure one, that's just foolish.
> > >
> > > "security problems" are a dime a dozen, as they say. Speaking as a
> > > (thankfully former) downstream integrator, you'd have much more success
> > > if you stopped breaking backward compatibility with userspace all the
> > > damn time. Upgrading major kernel version is like rolling a dice, you
> > > never know what kind of extremely expensive and time consuming rabbit
> > > hole you'll be dragged into because the kernel plays fast and loose
> > > with its userspace interfaces, and each and every time there's a chance
> > > one might end up having to do major reworks to deal with it.
> >
> > We should never be breaking working userspace programs when upgrading
> > the kernel.  If so, please report it to the regressions mailing list.
> >
> > Of course there's always some corner cases, but for the most part, this
> > should never happen.
> >
> > > So really it shouldn't be that surprising that users are averse to
> > > following the "latest is greatest" mantra from kernel.org, given how
> > > risky and expensive it is, and how little one gains in return. Rather
> > > than changing the world, what about changing your own processes first?
> > > A great starting point would be reverting backward incompatible changes
> > > regardless of who's affected, instead of doing that only if they affect
> > > the personal computer of a handful of maintainers (mainly Linus'), and
> > > shrugging reports away with "deal with it" in other cases.
> >
> > We should never be "shrugging" away reports like this.  If you have
> > specific incidents that you wish to discuss, I will be glad to do so on
> > the regressions kernel mailing list.  Otherwise this is way off-topic
> > for systemd-devel.
> >
> 
> >From a systemd-relevant angle, this has happened before. Recently
> even: https://github.com/systemd/systemd/blob/8c70e8024ba8ff42c23f1a35b9e8fafddd5caa8d/NEWS#L2355-L2437

(for those that don't want to look this up, it's the BIND/UNBIND uevent
issue.)

> That means that from a reasonable systemd user perspective, we need to
> depend on Linux kernel 4.14 or higher to cross over that breakage.

Great!  :)

> While it is true that the syscall interface is kept reasonably stable,
> almost everything else gets monkeyed with a lot, because a lot of
> kernel developers only consider the syscall interface a program
> interface. This is a problem because a *lot* of things are only
> accessible through other means (procfs, sysfs, uevents, etc.).
> 
> Unfortunately, that means that in practice, the kernel interfaces that
> userspace *must* depend on break far more than anyone likes.

The above example is an interesting case.  A new feature was added, was
around for a while, and a few _years later_ it was found out that some
people had userspace "scripts" that broke because the feature was added.
Yet people had already started depending on this feature, and really,
the "broken" scripts had always been broken, they just worked
accidentally by virtue that userspace was assuming the type of uevent
that was happening.

So what would you do if you were in my position?  We can't break
existing userspace tools that relied on the new events, and yet
upgrading the kernel broke older tools if they were not changed.

Anyway, fixing the scripts worked for everyone, and I think systemd did
the right thing here.

And yes, low level interactions like this will always have problems at
times, because we are all human and adding new interfaces is hard and we
get things wrong at times, making assumptions where we shouldn't have.
So we muddle through and handle them as they come, like was done here.

Any other cases that have not already been handled that you can think
of?

thanks,

greg k-h