lkml.org 
[lkml]   [2001]   [May]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [CHECKER] large stack variables (>=1K) in 2.4.4 and 2.4.4-ac8
On Thu, 24 May 2001 14:10:00 -0700 (PDT), Dawson Engler wrote:

>[BUG]
>/u2/engler/mc/oses/linux/2.4.4-ac8/arch/i386/kernel/nmi.c:47:check_nmi_watchdog: ERROR:VAR:47:47: suspicious var 'tmp' = 1024 bytes:47 [nbytes=1024]
>#define P6_EVENT_CPU_CLOCKS_NOT_HALTED 0x79
>#define P6_NMI_EVENT P6_EVENT_CPU_CLOCKS_NOT_HALTED
>
>int __init check_nmi_watchdog (void)
>{
>
>Error --->
> irq_cpustat_t tmp[NR_CPUS];

Nice work, but I think this is a false positive.

check_nmi_watchdog() is __init and we know exactly when it's called.
The interesting cases (SMP kernel, since for UP NR_CPUS==1) are:

start_kernel -> smp_init -> smp_boot_cpus -> APIC_init_uniprocessor
-> check_nmi_watchdog

and

start_kernel -> smp_init -> smp_boot_cpus -> setup_IO_APIC ->
check_timer -> check_nmi_watchdog

In neither case is the stack large enough that the 1KB blob in
check_nmi_watchdog should pose a problem, I think. (Don't we have
something like 8KB-sizeof(struct task_struct) stack to play with?)

IMHO the checker tool should take call paths into consideration
when trying to detect stack overflow problems. Does it do that?
(I.e. is it polyvariant or monovariant?)

I could write a patch to make 'tmp' __initdata instead, which would
silence the checker tool, but I don't really want to do that unless
someone can convince me that there is a real problem here.

/Mikael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:53    [W:0.034 / U:5.492 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site