> > On as ASUS A7V, a resp->Id ACPI_RSTYPE_IRQ (0) entry is found, it has
> > a resp->Length of 0x44 bytes. But the size of the array elements
> > (sizeof ACPI_RESOURCE) is 0x5c.
> > 
> > Doesn't the second entry start at offset 0x44 from the kmem_zalloc'ed
> > buffer, after the assignment "*srsp = *resp;" (because the actual resource
> > data doesn't use the full structure's size) ?
> 
> Yup.  I believe I'm guilty as charged.  The reason this doesn't
> blow up, and probably won't ever blow up, is that this code is
> only used to set the IRQ for a PCI IRQ link device. The _SRS
> method for a PCI IRQ link device is only going to use the first
> item in the resource byte stream (constructed from the ACPI_RESOURCE
> structures).

acpica seems to expect the ACPI_RSTYPE_END_TAG item after the
IRQ item.  IIRC, in one kmdb debug session, I zeroed out the second item's
->Id and ->Length field and I was getting an endless loop inside acpica
(acpica tried to skip to the next item, and was advancing a buffer pointer
by ->Length bytes, making no progress, and was stuck on the second item)


> > The "*srsp = *resp;" assigment might copy part of the next resource buffer
> > that follows resp, possible including the ->Id and ->Length member.
> 
> Right.  I expect the general manifestation of this failure case is
> to simply reproduce the entire resource list that was fetched using
> AcpiGetPossibleResources(), which is benign and one of the reasons
> I believe this code isn't blowing up.
> 
> Nonetheless, it's a bug and should be fixed.
> 
> > Wouldn't it be better to use something like this:
> > 
> >         srsp = kmem_zalloc(2 * sizeof (*srsp), KM_SLEEP);
> >         bcopy(resp, srsp, resp->Length);
> >         ACPI_NEXT_RESOURCE(srsp)->Id = ACPI_RSTYPE_END_TAG;
> >         ACPI_NEXT_RESOURCE(srsp)->Length = 0;
> >         break;
> 
> Yes, indeed. I'd be delighted to incorporate this contributed fix
> as a P3 bug.  Sound good?

Yes.
This message posted from opensolaris.org
_______________________________________________
opensolaris-code mailing list
[email protected]
https://opensolaris.org:444/mailman/listinfo/opensolaris-code

Reply via email to