On Wed, 21 Oct 2015 18:17:56 +0200 Lennart Poettering <lennart@xxxxxxxxxxxxxx> wrote: > On Wed, 21.10.15 08:41, Stephen Hemminger (stephen@xxxxxxxxxxxxxxxxxx) wrote: > > > Do you have any recommendations on how to deal with VMware borkage > > of the ACPI firmware index? > > Hmm, shouldn't the kernel filter such crappy data out already? I mean, > if we work around crappy firmware, why should that happen in userspace? So > far that was always a kernel job... > > Any specific reason you assume that 0xffff is a good cutoff point? > > > https://communities.vmware.com/message/2378360 > > > > My proposal is to just add special case: > > > > diff --git a/src/udev/udev-builtin-net_id.c b/src/udev/udev-builtin-net_id.c > > index 6e7e127..b8c6f47 100644 > > --- a/src/udev/udev-builtin-net_id.c > > +++ b/src/udev/udev-builtin-net_id.c > > @@ -133,7 +133,7 @@ static int dev_pci_onboard(struct udev_device *dev, struct netnames *names) { > > size_t l; > > char *s; > > const char *attr; > > - int idx; > > + unsigned long idx; > > > > /* ACPI _DSM -- device specific method for naming a PCI or PCI Express device */ > > attr = udev_device_get_sysattr_value(names->pcidev, "acpi_index"); > > @@ -143,8 +143,9 @@ static int dev_pci_onboard(struct udev_device *dev, struct netnames *names) { > > if (!attr) > > return -ENOENT; > > > > + /* vmware returns bogus values */ > > idx = strtoul(attr, NULL, 0); > > - if (idx <= 0) > > + if (idx == 0 || idx > 0xffff) > > return -EINVAL; > > > > /* kernel provided port index for multiple ports on a single PCI function */ > > Sorry for the long latency, for some reason this ended up in Spam. The kernel could filter but I suspect the ACPI developers would consider it a valid value. I made up 0xffff as a mask assuming 64K slots is more than any normal ACPI would return. VMware has other issues, there concept of PCI addresses is equally borked (unique) http://goo.gl/uhGEj8 Copying the ACPI kernel list on this. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html