Date: Mon, 14 Feb 2011 10:45:58 -0800 From: Matthew Fleming <mdf356@gmail.com> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-current@freebsd.org, Jung-uk Kim <jkim@freebsd.org> Subject: Re: acpi_resource bug? Message-ID: <AANLkTimDh_s0UTXkKqBeXDjJiub3LYqL8oR0pms5PoCP@mail.gmail.com> In-Reply-To: <201102141337.59203.jhb@freebsd.org> References: <AANLkTi=C31iGJMonj7E3DGLWhx0cSKQR=b7ZHTv9CdmA@mail.gmail.com> <AANLkTimKJnyFQgTgtLTOFvmcY4fbK5gdT6mwt9zB=%2BRY@mail.gmail.com> <201102141330.20330.jkim@FreeBSD.org> <201102141337.59203.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Feb 14, 2011 at 10:37 AM, John Baldwin <jhb@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@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 <=3D sizeof(ACPI_RESOURCE) ? >> >> No. =A0Please 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 d= oes > contain both ACPI_RESOURCE_IRQ and ACPI_RESOURCE_EXTENDED_IRQ, so it's ha= rd > 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 =3D=3D 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTimDh_s0UTXkKqBeXDjJiub3LYqL8oR0pms5PoCP>