[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [xen-unstable bisection] complete test-amd64-i386-qemuu-rhel6hvm-amd

>>> On 17.10.12 at 07:24, xen.org <ian.jackson@xxxxxxxxxxxxx> wrote:
> *** Found and reproduced problem changeset ***
>   Bug is in tree:  xen http://xenbits.xen.org/hg/staging/xen-unstable.hg 
>   Bug introduced:  4fc87c2f31a0
>   Bug not present: c1c549c4fe9e
>   changeset:   26060:4fc87c2f31a0
>   tag:         tip
>   user:        Huang Ying <ying.huang@xxxxxxxxx>
>   date:        Tue Oct 16 17:26:36 2012 +0200
>       ACPI: fix APEI related table size checking
>       On Huang Ying's machine:
>       erst_tab->header_length == sizeof(struct acpi_table_einj)
>       but Yinghai reported that on his machine,
>       erst_tab->header_length == sizeof(struct acpi_table_einj) -
>       sizeof(struct acpi_table_header)
>       To make erst table size checking code works on all systems, both
>       testing are treated as PASS.
>       Same situation applies to einj_tab->header_length, so corresponding
>       table size checking is changed in similar way too.
>       Originally-by: Yinghai Lu <yinghai@xxxxxxxxxx>
>       Signed-off-by: Huang Ying <ying.huang@xxxxxxxxx>
>       - use switch() for better readability
>       - add comment explaining why a formally invalid size it also being
>         accepted
>       - check erst_tab->header.length before even looking at
>         erst_tab->header_length
>       - prefer sizeof(*erst_tab) over sizeof(struct acpi_table_erst)
>       Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>       Acked-by: Keir Fraser <keir@xxxxxxx>
>       Committed-by: Jan Beulich <jbeulich@xxxxxxxx>

So I just now realized that a similar change was already done
by 23736:31683aa4bfb3 and then reverted by
23760:ae10d7804168. Nothing was done subsequently to
address the actual problem(s). It is quite obvious that the more
relaxed check uncovers other bugs in the ERST code, yet looking
at the Linux history of the corresponding file doesn't reveal any
fix the lack of which would explain an outright hang (rather than
a crash, as I would expect to be the result of e.g. the missing
ioremap()-s added by 0bbba38a61283a55f2061ab3e0910c572d19f462.

Most of the other changes are cosmetic or pstore related, so I
wonder whether instead of reverting again we should try pulling
in this one extra fix.

If reverting is preferred (or turns out necessary if that second
fix doesn't help), we should settle on the disposition of the whole
APEI/ERST code, as my conclusion is that it is pretty much
unmaintained since its original contribution over two years ago.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.