Re: FYI: Userland breakage caused by udev bind commit

[Christian Brauner <christian@brauner.io>]

On Mon, Dec 24, 2018 at 10:06:54AM -0800, Linus Torvalds wrote:
> On Mon, Dec 24, 2018 at 9:34 AM Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> >
> > Well, it appears that we can no longer extend uevent interface with new
> > types of uevents, at least not until we go and fix up all
> > udev-derivatives and give some time for things to settle.
> 
> How about having the users "opt in" for new events some way?
> 
> Do all the legacy events by default, but then if some user wants a
> "bind" event (or some other new event) add a model for the uevent
> interface to actually enable it.

So one possibility is to add a socket option for lib/kobject_uevent.c
that can be set via setsockopt. We did something like this in netlink
for strict property and header checking without breaking backwards
compatibility. That might be an option:

commit cd7f7df6ca3366be4ac79e824fdaa8d482270015
Merge: 272a66173bbc 8c6e137fbc7f
Author: David S. Miller <davem@davemloft.net>
Date:   Mon Oct 8 10:39:06 2018 -0700

    Merge branch 'rtnetlink-Add-support-for-rigid-checking-of-data-in-dump-request'

    David Ahern says:

    ====================
    rtnetlink: Add support for rigid checking of data in dump request

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=cd7f7df6ca3366be4ac79e824fdaa8d482270015

or adding a new flag that can be passed when opening a
NETLINK_KOBJECT_UEVENT socket.

Christian

> 
> Not using kernel versioning (nothing should *ever* look at the kernel
> version, since that makes things like backports a huge and
> insurmountable pain), but simply using some specific control channel.
> 
> > I guess reverting is the right solution here. I wish folks would yell
> > earlier though...
> 
> So nobody is actually using the new "bind" event, I take it? It's
> about a year and a half, and it's in 4.14 which is widely used, so
> reverting it has a risk too.
> 
> Which is why I too would hope people would be much more vocal about
> "that broke my setup".
> 
> But reverting does sound like the right thing to do if nobody is using
> it. It sounds like systemd udev does not, and if eudev is actively
> broken by this then how many other cases might there be?
> 
> I assume any locally modified udev rules would still be ok with the
> revert (since presumably any udev rule modification people did was to
> just ignore the bind/unbind events that no longer would be sent).
> 
>                 Linus