public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Gabriel C <nix.or.die@gmail.com>
Cc: Christian Brauner <christian@brauner.io>,
	Marcus Meissner <christian.brauner@canonical.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Greg KH <gregkh@linuxfoundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: FYI: Userland breakage caused by udev bind commit
Date: Mon, 24 Dec 2018 01:17:44 -0800	[thread overview]
Message-ID: <20181224091744.GA122208@dtor-ws> (raw)
In-Reply-To: <CAEJqkgjSX8PW-NXa8CoMzx=2P5LOiDz0MCHoZ03zE7wZ=n2dKg@mail.gmail.com>

On Mon, Dec 24, 2018 at 08:31:27AM +0100, Gabriel C wrote:
> Am So., 23. Dez. 2018 um 19:09 Uhr schrieb Dmitry Torokhov
> <dmitry.torokhov@gmail.com>:
> 
> [ also added Linus to CC on that one too ]
> >
> > On Sun, Dec 23, 2018 at 06:17:04PM +0100, Christian Brauner wrote:
> > > On Sun, Dec 23, 2018 at 05:49:54PM +0100, Marcus Meissner wrote:
> > > > Hi,
> > > >
> > > > I am the maintainer of libmtp and libgphoto2
> > > >
> > > > Some months ago I was made aware of this bug:
> > > >     https://bugs.kde.org/show_bug.cgi?id=387454
> > > >
> > > > This was fallout identified to come from this kernel commit:
> > > >
> > > >     commit 1455cf8dbfd06aa7651dcfccbadb7a093944ca65
> > > >     Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> > > >     Date:   Wed Jul 19 17:24:30 2017 -0700
> > >
> > > Fwiw, the addition of {un}bind events has caused issues for
> > > systemd-udevd as well and is tracked here:
> > > https://github.com/systemd/systemd/issues/7587
> > > I haven't been aware of this until yesterday and it seems that so far
> > > this hasn't been brought up on lkml until you did now.
> >
> > The fallout was caused by premature enabling of the new events in
> > systemd/udev by yours truly (even though the commit has Lennart's name
> > on it due to how it was merged):
> >
> > https://github.com/systemd/systemd/commit/9a39e1ce314d1a6f8a754f6dab040019239666a9
> >
> > "Add handling for bind/unbind actions (#6720)
> >
> > Newer kernels will emit uevents with "bind" and "unbind" actions. These
> > uevents will be issued when driver is bound to or unbound from a device.
> > "Bind" events are helpful when device requires a firmware to operate
> > properly, and driver is unable to create a child device before firmware
> > is properly loaded.
> >
> > For some reason systemd validates actions and drops the ones it does not
> > know, instead of passing them on through as old udev did, so we need to
> > explicitly teach it about them."
> >
> > Similarly it is now papered over in systemd/udev until we make it
> > properly handle new events:
> >
> > https://github.com/systemd/systemd/commit/56c886dc7ed5b2bb0882ba85136f4070545bfc1b
> >
> > "sd-device: ignore bind/unbind events for now
> >
> > Until systemd/udev are ready for the new events and do not flush entire
> > device state on each new event received, we should ignore them."
> >
> 
> And how about peoples still uses systemd < 235 and newer kernels ?

Should work exactly as it was with older kernels as it ignores
bind/unbind attributes.

> 
> > > >
> > > > If distributions would be using libmtp and libgphoto2 udev rules
> > > > that just triggered on "add" events, and not the new "bind" events,
> > > > the missing "attribute tagging" of the "bind" events would confused the
> > > > KDE Solid device detection and make the devices no longer detected.
> > > >
> > > > This did not affect distributions that rely on the newer "hwdb"
> > > > device detection method.
> > > >
> > > > I have released fixed libmtp and libgphoto2 versions in November, so
> > > > this is under control, but wanted to bring this up as a "kernel caused
> > > > userland breakage".
> >
> > Given that we explicitly enabled these new events in systemd/udev code
> > this is actually "userspace caused userspace breakage" case.
> 
> I really do not agree with you here .. Is kernel -> userspace breakage
> and while userspace is trying to workaround even much more breaks.
>

Not sure I follow your logic. We enabled handling new events in
systemd/udev. This thing broke systemd/udev. We now disabled this new
thing in systemd/udev.

Thanks.

-- 
Dmitry

  parent reply	other threads:[~2018-12-24  9:17 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-23 16:49 FYI: Userland breakage caused by udev bind commit Marcus Meissner
2018-12-23 17:17 ` Christian Brauner
2018-12-23 18:06   ` Dmitry Torokhov
2018-12-24  7:31     ` Gabriel C
2018-12-24  9:17       ` Greg KH
2018-12-24 10:15         ` Gabriel C
2018-12-24 10:54           ` Greg KH
2018-12-24 11:32             ` Gabriel C
2018-12-24 17:34             ` Dmitry Torokhov
2018-12-24 18:06               ` Linus Torvalds
2018-12-24 18:13                 ` Christian Brauner
2018-12-24 18:28                   ` Linus Torvalds
2018-12-24 18:42                     ` Christian Brauner
2018-12-24  9:17       ` Dmitry Torokhov [this message]
2018-12-24 10:30         ` Gabriel C
2018-12-24  9:12 ` Greg KH
2018-12-24  9:22   ` Dmitry Torokhov
2018-12-24  9:34     ` Greg KH

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=20181224091744.GA122208@dtor-ws \
    --to=dmitry.torokhov@gmail.com \
    --cc=christian.brauner@canonical.com \
    --cc=christian@brauner.io \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nix.or.die@gmail.com \
    --cc=torvalds@linux-foundation.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