From: Stephen Hemminger <stephen@networkplumber.org>
To: Lennart Poettering <lennart@poettering.net>
Cc: Tom Gundersen <teg@jklm.no>, Kay Sievers <kay@vrfy.org>,
linux-acpi@vger.kernel.org
Subject: Re: Bogus names on vmware
Date: Thu, 19 Nov 2015 17:10:41 -0800 [thread overview]
Message-ID: <20151119171041.13468158@xeon-e3> (raw)
In-Reply-To: <20151021161755.GA15833@gardel-login>
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.
parent reply other threads:[~2015-11-20 1:10 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <20151021161755.GA15833@gardel-login>]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151119171041.13468158@xeon-e3 \
--to=stephen@networkplumber.org \
--cc=kay@vrfy.org \
--cc=lennart@poettering.net \
--cc=linux-acpi@vger.kernel.org \
--cc=teg@jklm.no \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox