linux-kernel - Re: [RFC] bind/unbind uevent

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTikC5hLpam0c-goU0KKLezgQJNBnWFJSKn8kdx0a@mail.gmail.com>
Date:	Wed, 15 Dec 2010 18:51:48 +0100
From:	Kay Sievers <kay.sievers@...y.org>
To:	Cornelia Huck <cornelia.huck@...ibm.com>
Cc:	Greg KH <gregkh@...e.de>,
	Sebastian Ott <sebott@...ux.vnet.ibm.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC] bind/unbind uevent

2010/12/15 Cornelia Huck <cornelia.huck@...ibm.com>:
> On Wed, 15 Dec 2010 08:23:16 -0800, Greg KH <gregkh@...e.de> wrote:
>> On Wed, Dec 15, 2010 at 02:21:13PM +0100, Cornelia Huck wrote:

>> How about I turn it around for you, please show me how the driver core
>> does _not_ support this today?  If you can prove that this isn't working
>> properly, then great, I'll gladly accept patches to resolve it.
>
> Looking at device_add():

...

> This will not be a problem if a device driver registers a child device
> (since it can specify the attributes there).

Which is the proper way to do it. No driver should ever mangle a
device which it does not own. It's like adding properties of a block
device directly to a usb_interface device. That just can not work
correctly for many reasons, inside and outside of the kernel.

> I think the basic problem is that the KOBJ_ADD uevent notifies
> userspace that "a device is there", while the device will only be
> really useable by userspace once a driver has bound to it.

This device represents a device on a bus, and can usually do its own
things. A driver can bind to it, but should not mangle it.

> A module
> load triggered by KOBJ_ADD is fine, but trying to actually use the
> device after KOBJ_ADD is racy. This will not matter in the usual case,
> since either the matching/probing is fast enough or userspace will wait
> for something like a block device anyway, but we've seen problems on
> s390. A KOBJ_BIND/UNBIND would make a proper distinction between
> "device is there" and "device is usable".

We don't rally want any such events. We expect a new child device
being created from the driver, instead of re-using the existing bus
device.

> (Besides, what happens on unbind/bind? Shouldn't userspace know that a
> device is now bound to a different driver?)

It does that by watching the child devices the driver creates and destroys.

We already have enough events to handle on today's boxes, we really
don't want to add new ones, which are only needed to work around such
use cases, which ideally just should be fixed.

If you can not change the current drivers to create child devices, the
driver can probably just send change events for the already existing
devices it mangles from the driver.

We don't want to encourage any such use model in general, and such
hacks should be bus/driver specific (and only for legacy reasons), and
they do not belong into the driver core.

Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/