linux-kernel - Re: [PATCH 32/36] driver core: Introduce device

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: <20061204230511.GA9382@kroah.com>
Date:	Mon, 4 Dec 2006 15:05:11 -0800
From:	Greg KH <greg@...ah.com>
To:	Marcel Holtmann <marcel@...tmann.org>
Cc:	linux-kernel@...r.kernel.org,
	Cornelia Huck <cornelia.huck@...ibm.com>,
	Greg Kroah-Hartman <gregkh@...e.de>
Subject: Re: [PATCH 32/36] driver core: Introduce device_move(): move a device to a new parent.

On Mon, Dec 04, 2006 at 10:15:03PM +0100, Marcel Holtmann wrote:
> Hi Greg,
> 
> > > > Provide a function device_move() to move a device to a new parent device. Add
> > > > auxilliary functions kobject_move() and sysfs_move_dir().
> > > > kobject_move() generates a new uevent of type KOBJ_MOVE, containing the
> > > > previous path (DEVPATH_OLD) in addition to the usual values. For this, a new
> > > > interface kobject_uevent_env() is created that allows to add further
> > > > environmental data to the uevent at the kobject layer.
> > > 
> > > has this one been tested? I don't get it working. I always get an EINVAL
> > > when trying to move the TTY device of a Bluetooth RFCOMM link around.
> > 
> > I relied on Cornelia to test this.  I think some s390 patches depend on
> > this change, right?
> 
> my pre-condition is that the TTY device has no parent and then we move
> it to a Bluetooth ACL link as child. This however is not working or the
> TTY change to use device instead of class_device has broken something.

Hm, I don't think the class_device stuff has broken anything, but if you
think so, please let me know.

> > > And shouldn't device_move(dev, NULL) re-attach it to the virtual device
> > > tree instead of failing?
> > 
> > Yes, that would be good to have.
> 
> Cornelia, please fix this, because otherwise we can't detach a device
> from its parent. Storing the current virtual parent looks racy to me.

You can always restore the previous "virtual" parent from the
information given to you in the device itself.  That is what the code
does when it first registers the device.

And yes, I too think it should be fixed.

thanks,

greg k-h
-
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/