Re: acpi_resource bug?

On Mon, Feb 14, 2011 at 10:37 AM, John Baldwin <jhb_at_freebsd.org> wrote:
> On Monday, February 14, 2011 1:30:18 pm Jung-uk Kim wrote:
>> On Monday 14 February 2011 10:29 am, Matthew Fleming wrote:
>> > On Mon, Feb 14, 2011 at 6:24 AM, John Baldwin <jhb_at_freebsd.org>
>> wrote:
>> > > On Sunday, February 13, 2011 2:46:07 pm Matthew Fleming wrote:
>> > >> I'm not very familiar with the acpi code, but we have seen an
>> > >> intermittent issue on boot:
>> > >>
>> > >> 1) should the length of the bcopy() be changed to either respect
>> > >> res->Length or the actual length of the ACPI_RESOURCE_DATA for
>> > >> the type?
>> > >
>> > > It should just use res->Length:
>> >
>> > Is there a guarantee that res->Length is <= sizeof(ACPI_RESOURCE) ?
>>
>> No.  Please try the attached patch (after your r218685).
>
> I think your patch is correct, but are you saying that ACPICA will return a
> resource with a size that doesn't match its type?
>
> ACPI_RESOURCE_DATA is a union of all the various resource types, and it does
> contain both ACPI_RESOURCE_IRQ and ACPI_RESOURCE_EXTENDED_IRQ, so it's hard
> to see how res->Length would be greater than the size of ACPI_RESOURCE.

Jung-uk Kim's patch makes acpi_resource match the other bcopy's in the
acpica directory, and in the case of what I saw it would bcopy 8+5
bytes instead of res->Length == 16.

My concern was that res->Length seemed primarily to be an offset from
the current resource to the next one, and I didn't see why that may
not include a lot of padding (including more than the target of the
bcopy was prepared for).  However, my code will also copy bytes we
don't care about any time res->Length is rounded up from the actual
struct size.

The patch looks fine to me.  I don't have direct access to the machine
that was intermittently crashing so I can't really try the new patch,
but my change resolved the issue on it.

Thanks,
matthew