public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* x86: fix macro with bad_bios_dmi_table
@ 2008-09-23  7:35 Yinghai Lu
  2008-09-23  8:16 ` Ingo Molnar
  0 siblings, 1 reply; 4+ messages in thread
From: Yinghai Lu @ 2008-09-23  7:35 UTC (permalink / raw)
  To: Ingo Molnar, Thomas Gleixner, H. Peter Anvin, Andrew Morton
  Cc: linux-kernel, Yinghai Lu

need one blank tail.

fix the crash on ingo's test box.

Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>

diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index a9998cb..3d677b5 100644
--- 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
+	{}
 };
 
 /*

^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: x86: fix macro with bad_bios_dmi_table
  2008-09-23  7:35 x86: fix macro with bad_bios_dmi_table Yinghai Lu
@ 2008-09-23  8:16 ` Ingo Molnar
  2008-09-23  8:30   ` Yinghai Lu
  0 siblings, 1 reply; 4+ messages in thread
From: Ingo Molnar @ 2008-09-23  8:16 UTC (permalink / raw)
  To: Yinghai Lu; +Cc: Thomas Gleixner, H. Peter Anvin, Andrew Morton, linux-kernel


* 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)) 

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.

	Ingo

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: x86: fix macro with bad_bios_dmi_table
  2008-09-23  8:16 ` Ingo Molnar
@ 2008-09-23  8:30   ` Yinghai Lu
  2008-09-23  8:33     ` Ingo Molnar
  0 siblings, 1 reply; 4+ messages in thread
From: Yinghai Lu @ 2008-09-23  8:30 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: Thomas Gleixner, H. Peter Anvin, Andrew Morton, linux-kernel

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()

>
> 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

YH

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: x86: fix macro with bad_bios_dmi_table
  2008-09-23  8:30   ` Yinghai Lu
@ 2008-09-23  8:33     ` Ingo Molnar
  0 siblings, 0 replies; 4+ messages in thread
From: Ingo Molnar @ 2008-09-23  8:33 UTC (permalink / raw)
  To: Yinghai Lu; +Cc: Thomas Gleixner, H. Peter Anvin, Andrew Morton, linux-kernel


* 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

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2008-09-23  8:34 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-09-23  7:35 x86: fix macro with bad_bios_dmi_table Yinghai Lu
2008-09-23  8:16 ` Ingo Molnar
2008-09-23  8:30   ` Yinghai Lu
2008-09-23  8:33     ` Ingo Molnar

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox