linux-kernel - Re: [stable] [patch 00/21] 2.6.19-stable review

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: <m1mz2xg90s.fsf@ebiederm.dsl.xmission.com>
Date:	Wed, 28 Feb 2007 16:25:07 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Greg KH <greg@...ah.com>
Cc:	Zwane Mwaikambo <zwane@...radead.org>,
	"Theodore Ts'o" <tytso@....edu>,
	Justin Forbes <jmforbes@...uxtx.org>, Andi Kleen <ak@...e.de>,
	Chris Wedgwood <reviews@...cw.f00f.org>,
	linux-kernel@...r.kernel.org, Randy Dunlap <rdunlap@...otime.net>,
	Chuck Wolber <chuckw@...ntumlinux.com>,
	Chuck Ebbert <cebbert@...hat.com>,
	Dave Jones <davej@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Michael Krufky <mkrufky@...uxtv.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	stable@...nel.org, alan@...rguk.ukuu.org.uk
Subject: Re: [stable] [patch 00/21] 2.6.19-stable review

Greg KH <greg@...ah.com> writes:

> On Wed, Feb 28, 2007 at 05:28:27AM -0700, Eric W. Biederman wrote:
>> 
>> What are the rules that are supposed to govern backports to stable
>> trees these days anyway?
>
> Documentation/stable_kernel_rules.txt


Ok if that is really what we are going with, the this silly patch isn't
simple enough for a backport.  There used to other rules to the effect
the patch must be merged in mainline, and we only backport to one kernel
revision.

I think it fails the 100 lines with context test.

The meaning of obviously correct is a little bit nebulous.  But if
something is obvious multiple people can easily understand what
is going on.  I haven't gotten any feedback that has said yes I
see what you are doing on the mentioned patch.

I'm really not certain how this patch got seriously proposed then.
I guess it was the serious of the issues of peoples boxes falling
over.

I guess somewhere I got the rules for weird vendor trees confused with
our stable branches.  The relaxed stable branch rules probably did it
to me.

So the best we can do is the commit below for a backport.  It doesn't
fix the issue but it generally keeps the machines from falling over.

p.s. The copy below is whitespace damaged because I just cut and
pasted it into this email.

commit 2fb12a9bca5ad9aa6dcd2c639b4a7656a8843ef8
Author: Eric W. Biederman <ebiederm@...ssion.com>
Date:   Tue Feb 13 13:26:25 2007 +0100

    [PATCH] x86-64: survive having no irq mapping for a vector
    
    Occasionally the kernel has bugs that result in no irq being found for a
    given cpu vector.  If we acknowledge the irq the system has a good chance
    of continuing even though we dropped an irq message.  If we continue to
    simply print a message and not acknowledge the irq the system is likely to
    become non-responsive shortly there after.
    
    AK: Fixed compilation for UP kernels
    
    Signed-off-by: Eric W. Biederman <ebiederm@...ssion.com>
    Signed-off-by: Andi Kleen <ak@...e.de>
    Cc: "Luigi Genoni" <luigi.genoni@...elli.com>
    Cc: Andi Kleen <ak@...e.de>
    Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>

diff --git a/arch/x86_64/kernel/irq.c b/arch/x86_64/kernel/irq.c
index 0c06af6..3bc30d2 100644
--- a/arch/x86_64/kernel/irq.c
+++ b/arch/x86_64/kernel/irq.c
@@ -18,6 +18,7 @@
 #include <asm/uaccess.h>
 #include <asm/io_apic.h>
 #include <asm/idle.h>
+#include <asm/smp.h>
 
 atomic_t irq_err_count;
 
@@ -120,9 +121,14 @@ asmlinkage unsigned int do_IRQ(struct pt_regs *regs)
 
        if (likely(irq < NR_IRQS))
                generic_handle_irq(irq);
-       else if (printk_ratelimit())
-               printk(KERN_EMERG "%s: %d.%d No irq handler for vector\n",
-                       __func__, smp_processor_id(), vector);
+       else {
+               if (!disable_apic)
+                       ack_APIC_irq();
+
+               if (printk_ratelimit())
+                       printk(KERN_EMERG "%s: %d.%d No irq handler for vector\n",
+                               __func__, smp_processor_id(), vector);
+       }
 
        irq_exit();
 

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