linux-kernel - Re: [PATCH] expand /proc/interrupts to include missing vectors, v3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <p73wswgpkvq.fsf@bingen.suse.de>
Date:	31 Jul 2007 19:02:01 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Joe Korty <joe.korty@...r.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Sven-Thorsten Dietrich <sdietrich@...ell.com>,
	"H. Peter Anvin" <hpa@...or.com>, mingo@...e.hu,
	tglx@...utronix.de, linux-rt-users@...r.kernel.org,
	linux-kernel@...r.kernel.org, jason.baietto@...r.com
Subject: Re: [PATCH] expand /proc/interrupts to include missing vectors, v3

Joe Korty <joe.korty@...r.com> writes:
> 	spurious interrupts
> 
> A threshold interrupt occurs when ECC memory correction
> is occuring at too high a frequency. 

It's configurable and the default is off. Also 
it's only on AMD hardware.

Your description is a little misleading.

> Thresholds are used
> by the ECC hardware as occasional ECC failures are part
> of normal operation,

Not really.


> ===================================================================
> --- 2.6.23-rc1-git7.orig/arch/i386/kernel/apic.c	2007-07-30 19:08:05.000000000 -0400
> +++ 2.6.23-rc1-git7/arch/i386/kernel/apic.c	2007-07-30 19:08:07.000000000 -0400
> @@ -1280,6 +1280,7 @@
>  	printk(KERN_INFO "spurious APIC interrupt on CPU#%d, "
>  	       "should never happen.\n", smp_processor_id());
>  	irq_exit();
> +	__get_cpu_var(irq_stat).irq_spur_counts++;

Wouldn't it be safer on preemptible kernels to have that inside
the irq_exit? 

>  }
>  
>  /*
> Index: 2.6.23-rc1-git7/arch/i386/kernel/cpu/mcheck/p4.c
> ===================================================================
> --- 2.6.23-rc1-git7.orig/arch/i386/kernel/cpu/mcheck/p4.c	2007-07-30 19:08:05.000000000 -0400
> +++ 2.6.23-rc1-git7/arch/i386/kernel/cpu/mcheck/p4.c	2007-07-30 19:08:07.000000000 -0400
> @@ -62,6 +62,7 @@
>  	irq_enter();
>  	vendor_thermal_interrupt(regs);
>  	irq_exit();
> +	__get_cpu_var(irq_stat).irq_thermal_counts++;
>  }
>  
>  /* P4/Xeon Thermal regulation detect and init */
> Index: 2.6.23-rc1-git7/arch/i386/kernel/irq.c
> ===================================================================
> --- 2.6.23-rc1-git7.orig/arch/i386/kernel/irq.c	2007-07-30 19:08:05.000000000 -0400
> +++ 2.6.23-rc1-git7/arch/i386/kernel/irq.c	2007-07-31 09:40:58.000000000 -0400
> @@ -284,14 +284,41 @@
>  		seq_printf(p, "NMI: ");
>  		for_each_online_cpu(j)
>  			seq_printf(p, "%10u ", nmi_count(j));
> -		seq_putc(p, '\n');
> +		seq_printf(p, "  Non-maskable interrupts\n");
>  #ifdef CONFIG_X86_LOCAL_APIC
>  		seq_printf(p, "LOC: ");
>  		for_each_online_cpu(j)
>  			seq_printf(p, "%10u ",
>  				per_cpu(irq_stat,j).apic_timer_irqs);
> -		seq_putc(p, '\n');
> +		seq_printf(p, "  Local interrupts\n");
>  #endif
> +#ifdef CONFIG_SMP
> +		seq_printf(p, "RES: ");

I think it would be better to use 5-6 char identifiers even
when it whacks the columns a bit; otherwise
nobody will know what it means. e.g. SCHED here. 

Also there you should update proc(5) and send a patch
to the manpage maintainer.

> Index: 2.6.23-rc1-git7/arch/x86_64/kernel/apic.c
> ===================================================================
> --- 2.6.23-rc1-git7.orig/arch/x86_64/kernel/apic.c	2007-07-30 19:08:05.000000000 -0400
> +++ 2.6.23-rc1-git7/arch/x86_64/kernel/apic.c	2007-07-30 19:08:07.000000000 -0400
> @@ -1118,6 +1118,7 @@
>  asmlinkage void smp_spurious_interrupt(void)
>  {
>  	unsigned int v;
> +

Don't add white space.


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