[libvirt] [PATCH] udev: Don't let strtoul parse USB busnum and devnum as octal

udevGetUintProperty was called with base set to 0 for busnum and devnum. With base 0 strtoul parses the number as octal if it start with a 0. But busnum and devnum are decimal and udev returns them padded with leading zeros. So strtoul parses them as octal. This works for certain decimal values like 001-007, but fails for values like 008. Change udevProcessUSBDevice to use base 10 for busnum and devnum. --- src/node_device/node_device_udev.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/node_device/node_device_udev.c b/src/node_device/node_device_udev.c index 734f3f7..0c0f29a 100644 --- a/src/node_device/node_device_udev.c +++ b/src/node_device/node_device_udev.c @@ -500,14 +500,14 @@ static int udevProcessUSBDevice(struct udev_device *device, if (udevGetUintProperty(device, "BUSNUM", &data->usb_dev.bus, - 0) == PROPERTY_ERROR) { + 10) == PROPERTY_ERROR) { goto out; } if (udevGetUintProperty(device, "DEVNUM", &data->usb_dev.device, - 0) == PROPERTY_ERROR) { + 10) == PROPERTY_ERROR) { goto out; } -- 1.6.3.3

On 02/01/2010 06:10 PM, Matthias Bolte wrote:
udevGetUintProperty was called with base set to 0 for busnum and devnum. With base 0 strtoul parses the number as octal if it start with a 0. But busnum and devnum are decimal and udev returns them padded with leading zeros. So strtoul parses them as octal. This works for certain decimal values like 001-007, but fails for values like 008.
This is a good change, but I thought it was already fixed a couple of weeks ago. You're sure they're returned decimal and not hex? ACK assuming that's the case.
Change udevProcessUSBDevice to use base 10 for busnum and devnum. --- src/node_device/node_device_udev.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/node_device/node_device_udev.c b/src/node_device/node_device_udev.c index 734f3f7..0c0f29a 100644 --- a/src/node_device/node_device_udev.c +++ b/src/node_device/node_device_udev.c @@ -500,14 +500,14 @@ static int udevProcessUSBDevice(struct udev_device *device, if (udevGetUintProperty(device, "BUSNUM", &data->usb_dev.bus, - 0) == PROPERTY_ERROR) { + 10) == PROPERTY_ERROR) { goto out; }
if (udevGetUintProperty(device, "DEVNUM", &data->usb_dev.device, - 0) == PROPERTY_ERROR) { + 10) == PROPERTY_ERROR) { goto out; }

2010/2/2 Dave Allan <dallan@redhat.com>:
On 02/01/2010 06:10 PM, Matthias Bolte wrote:
udevGetUintProperty was called with base set to 0 for busnum and devnum. With base 0 strtoul parses the number as octal if it start with a 0. But busnum and devnum are decimal and udev returns them padded with leading zeros. So strtoul parses them as octal. This works for certain decimal values like 001-007, but fails for values like 008.
This is a good change, but I thought it was already fixed a couple of weeks ago. You're sure they're returned decimal and not hex? ACK assuming that's the case.
vendor, device and ID_MODEL_ID where changed to be parsed as hex some weeks ago. I based my assumption that busnum and devnum are decimal on the lsusb manpage, because the udev driver output matches the lsusb output. The manpage says busnum and devnum are decimal and it also says that vendor is hex. I just found a libvirt bugreport [1] that confirms my assumption. Also googling for 'lsusb "bus X"' with X as decimal and hex numbers gives no result with hex numbers like 00A, but gives results for decimal numbers like 010, 011, etc. So I'm pretty sure that busnum and devnum are decimal :) Okay, I pushed this one. [1] https://bugzilla.redhat.com/show_bug.cgi?id=508645 Matthias

On 02/02/2010 03:52 AM, Matthias Bolte wrote:
2010/2/2 Dave Allan<dallan@redhat.com>:
On 02/01/2010 06:10 PM, Matthias Bolte wrote:
udevGetUintProperty was called with base set to 0 for busnum and devnum. With base 0 strtoul parses the number as octal if it start with a 0. But busnum and devnum are decimal and udev returns them padded with leading zeros. So strtoul parses them as octal. This works for certain decimal values like 001-007, but fails for values like 008.
This is a good change, but I thought it was already fixed a couple of weeks ago. You're sure they're returned decimal and not hex? ACK assuming that's the case.
vendor, device and ID_MODEL_ID where changed to be parsed as hex some weeks ago.
I based my assumption that busnum and devnum are decimal on the lsusb manpage, because the udev driver output matches the lsusb output. The manpage says busnum and devnum are decimal and it also says that vendor is hex.
I just found a libvirt bugreport [1] that confirms my assumption. Also googling for 'lsusb "bus X"' with X as decimal and hex numbers gives no result with hex numbers like 00A, but gives results for decimal numbers like 010, 011, etc. So I'm pretty sure that busnum and devnum are decimal :)
Excellent--many thanks! Dave
Okay, I pushed this one.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=508645
Matthias
participants (2)
-
Dave Allan
-
Matthias Bolte