[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20080923083345.GE23031@elte.hu>
Date: Tue, 23 Sep 2008 10:33:45 +0200
From: Ingo Molnar <mingo@...e.hu>
To: Yinghai Lu <yinghai@...nel.org>
Cc: Thomas Gleixner <tglx@...utronix.de>,
"H. Peter Anvin" <hpa@...or.com>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org
Subject: Re: x86: fix macro with bad_bios_dmi_table
* Yinghai Lu <yinghai@...nel.org> wrote:
> On Tue, Sep 23, 2008 at 1:16 AM, Ingo Molnar <mingo@...e.hu> wrote:
> >
> > * Yinghai Lu <yhlu.kernel@...il.com> wrote:
> >
> >> need one blank tail.
> >>
> >> fix the crash on ingo's test box.
> >
> > applied to tip/x86/memory-corruption-check, thanks Yinghai!
> >
> >> --- a/arch/x86/kernel/setup.c
> >> +++ b/arch/x86/kernel/setup.c
> >> @@ -760,8 +760,8 @@ static struct dmi_system_id __initdata bad_bios_dmi_table[] = {
> >> DMI_MATCH(DMI_BIOS_VENDOR, "Phoenix Technologies, LTD"),
> >> },
> >> },
> >> - {}
> >> #endif
> >> + {}
> >> };
> >
> > i've seen such DMI crashes numerous times, caused by a missing NULL at
> > the end of the table. Is there no sane way to detect or robustly avoid
> > such run-off-the-end bugs?
> >
> > how about changing dmi_check_system(table) to a macro, which does
> > something like:
> >
> > __dmi_check_system(&(table), sizeof(table))
>
> ARRAY_SIZE()
yes.
> > and rename dmi_check_system() in drivers/firmware/dmi_scan.c to
> > __dmi_check_system() and add the size parameter? That way we could
> > remove the need for NULL termination and it's even a size optimization:
> > it shrinks those tables a tiny bit.
>
> # git grep dmi_system_id | grep "\[" | wc -l
> 62
what's the problem? I think in most cases dmi_check_system() is called
with an actual static table so most of the dmi_check_system() callsites
should work just fine and need not to be touched. (as we still keep the
same API - we just redirect it to __dmi_check_system())
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists