If a client connects to us repeatedly always using the same source port
and we instantiate a service for the incoming connection this might
clash with an old instance. Hence, include the connection number, the
same way we do it for AF_UNIX to make connections unique.
https://bugs.freedesktop.org/show_bug.cgi?id=45297
<tomegun> kay: is this a valid issue: https://bugs.archlinux.org/task/27060 ?
<kay> tomegun: udev does not really care if that fails
<tomegun> kay: the suggestion there is to treat EINVAL the same way we treat ENOTTY (i.e. as an info only)
<tomegun> if it really does not matter it might make sense to avoid bogus bug reports
<kay> tomegun: done
This device is a combination USB hub, displaylink graphics, and e2i touchscreen
Bus 001 Device 005: ID 058f:6254 Alcor Micro Corp. USB Hub
Bus 001 Device 006: ID 17e9:401a Newnham Research
Bus 001 Device 007: ID 1ac7:0001
|__ Port 1: Dev 5, If 0, Class=hub, Driver=hub/4p, 480M
|__ Port 2: Dev 6, If 0, Class=vend., Driver=udlfb, 480M
|__ Port 2: Dev 6, If 1, Class=HID, Driver=usbhid, 480M
|__ Port 3: Dev 7, If 0, Class=vend., Driver=usbtouchscreen, 12M
Many servers will be connected to KVMs or include iLO support, and this
is often presented as a set of USB input devices. Enabling autosuspend on
these allows the USB hardware to be powered down, avoiding unnecessary
wakeups and power consumption. The input devices will be self powered, so
there's no risk of losing input events as there would be for real input
devices. The same is true of USB input devices that are built into the
system.
we need to make sure that configuration data we expose via the bus ends
up in using getting an assert(). Even though configuration data is only
parsed from trusted sources we should be more careful with what we read.
The use of identifying disks by magic byte sequences outside of the
filesystem or partion table is fragile and usually creates more
problems than it solves.
Udev-acl will be part of a future ConsoleKit release. On systemd systems,
advanced ConsoleKit and udev-acl functionality are natively provided by
systemd.
If the service reaches the start limit, mark the sockets that activate
it as failed (with the result code 'service-broken').
This way the sockets won't act as tarpits for clients connecting to
them.