* Re: Bogus names on vmware
[not found] ` <20151021161755.GA15833@gardel-login>
@ 2015-11-20 1:10 ` Stephen Hemminger
0 siblings, 0 replies; only message in thread
From: Stephen Hemminger @ 2015-11-20 1:10 UTC (permalink / raw)
To: Lennart Poettering; +Cc: Tom Gundersen, Kay Sievers, linux-acpi
On Wed, 21 Oct 2015 18:17:56 +0200
Lennart Poettering <lennart@poettering.net> wrote:
> On Wed, 21.10.15 08:41, Stephen Hemminger (stephen@networkplumber.org) 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.
^ permalink raw reply [flat|nested] only message in thread