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-next>] [day] [month] [year] [list]
Message-ID: <f844342b-14fd-6ce5-55b0-5c224d0c841b@norrbonn.se>
Date:   Mon, 5 Nov 2018 11:35:57 +0100
From:   Jonas Bonn <jonas@...rbonn.se>
To:     linux-kernel@...r.kernel.org
Cc:     gregkh@...uxfoundation.org, rafael@...nel.org
Subject: KOBJ_BIND uevent

Hi,

I have a question about the ordering of uevents, specifically concerning 
complex USB devices that present multiple interfaces/functions.

Before KOBJ_BIND, a USB device would typically present itself as:

add usb_device
add usb_interface-1
add subsystem-device-1.0
add subsystem-device-1.1
add usb_interface-2
add subsystem-device-2.0

I have noted that the recently added "bind" actions, however, present in 
the reverse order.

bind subsystem-device-1.0
bind subsystem-device-1.1
bind usb-interface-1
bind subsystem-device-2.0
bind usb_interface-2
bind usb_device

This secondary ordering could be useful in the sense that the final 
"bind" action on the usb_device is an indication that the kernel has 
finished enumeration of all endpoints and has bound all drivers that it 
could to the available interfaces... i.e. no further events for this 
device are expected.

The question, then, is:  is the above ordering of "bind" events stable, 
or is it just a consequence of the current implementation and may change 
in the future?

/Jonas

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ