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]
Date:	Wed, 15 Nov 2006 09:44:33 +0100
From:	"Kay Sievers" <kay.sievers@...y.org>
To:	"Cornelia Huck" <cornelia.huck@...ibm.com>
Cc:	"Greg KH" <greg@...ah.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	"Andrew Morton" <akpm@...l.org>,
	"Martin Schwidefsky" <schwidefsky@...ibm.com>
Subject: Re: [Patch -mm 2/5] driver core: Introduce device_move(): move a device to a new parent.

On 11/15/06, Cornelia Huck <cornelia.huck@...ibm.com> wrote:
> On Tue, 14 Nov 2006 22:50:52 -0800,
> Greg KH <greg@...ah.com> wrote:
>
> > On Tue, Nov 14, 2006 at 11:32:08AM +0100, Cornelia Huck wrote:
> > > From: Cornelia Huck <cornelia.huck@...ibm.com>
> > >
> > > Provide a function device_move() to move a device to a new parent device. Add
> > > auxilliary functions kobject_move() and sysfs_move_dir().
> >
> > At first glance, this looks sane, but for the kobject_move function, we
> > are not notifying userspace that something has changed here.
> >
> > Is that ok?
> >
> > How will udev and HAL handle something like this without being told
> > about it?  When the device eventually goes away, I think they will be
> > very confused.

Yes, userspace will get confused, if we we don't get proper
notification. We require to update the udev and HAL database with the
new devpath, to find the current device context on device events, or
for "remove".

> Hm. I don't think we want to trigger udev with some remove/add events
> (especially since it is still the same device, it just has been moved
> around). A change event doesn't sound quite right either. But I guess
> we need to do something, at least to make HAL happy since it remembers
> the path in sysfs (although I seem to remember a HAL patch that got rid
> of it?)

Udev and HAL, both will need an event for the moving, with the old
DEVPATH value in the environment. We want something like a "rename" or
"move" event. Without that, weird things will happen in userspace,
because the devpath is used as the key to the device during the whole
device lifetime. The only weird exception today is the netif rename
case, which is already handled by special code in udev.

Thanks,
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ