Messages in this thread |  | | | Date | Tue, 23 Sep 2008 10:33:45 +0200 | | From | Ingo Molnar <> | | Subject | Re: x86: fix macro with bad_bios_dmi_table |
| |
* Yinghai Lu <yinghai@kernel.org> wrote:
> On Tue, Sep 23, 2008 at 1:16 AM, Ingo Molnar <mingo@elte.hu> wrote: > > > > * Yinghai Lu <yhlu.kernel@gmail.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
|  |