login
Login
/
Register
Search
Search this site:
Forums
News
Blogs
Features
Site
Home
»
Mailing list archives
»
linux-kernel
»
2008
»
June
»
20
Re: stack overflow on Sparc64
view
thread
Previous message: [
thread
] [
date
] [
author
]
Next message: [
thread
] [
date
] [
author
]
[view in full thread]
From: David Miller
Subject:
Re: stack overflow on Sparc64
Date: Friday, June 20, 2008 - 2:20 pm
From: Mikulas Patocka <mpatocka@redhat.com> Date: Fri, 20 Jun 2008 17:14:41 -0400 (EDT)
quoted text
> Are you sure? What about this: > ide-io.c:ide_intr > if (drive->unmask) > local_irq_enable_in_hardirq(); > > or this: > kernel/irq/handle.c:handle_IRQ_event > if (!(action->flags & IRQF_DISABLED)) > local_irq_enable_in_hardirq(); > > > --- how is number of nested interrupts here supposed to be limited? > > If these things are not limited, you get at most as many nested handlers > as there are hardware interrupts, which means crash.
It means i386 and every other platform potentially has the same exact problem. What point wrt. sparc64 are you trying to make here? :-) --
unsubscribe notice
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/
Previous message: [
thread
] [
date
] [
author
]
Next message: [
thread
] [
date
] [
author
]
Messages in current thread:
stack overflow on Sparc64
, Mikulas Patocka
, (Tue Jun 17, 5:47 pm)
Re: stack overflow on Sparc64
, David Miller
, (Tue Jun 17, 9:01 pm)
Re: stack overflow on Sparc64
, Mikulas Patocka
, (Wed Jun 18, 8:24 pm)
Re: stack overflow on Sparc64
, David Miller
, (Wed Jun 18, 8:59 pm)
Re: stack overflow on Sparc64
, Mikulas Patocka
, (Wed Jun 18, 10:17 pm)
Re: stack overflow on Sparc64
, David Miller
, (Wed Jun 18, 11:37 pm)
Re: stack overflow on Sparc64
, Mikulas Patocka
, (Thu Jun 19, 6:01 am)
Re: stack overflow on Sparc64
, Mikulas Patocka
, (Fri Jun 20, 8:47 am)
Re: stack overflow on Sparc64
, David Miller
, (Fri Jun 20, 10:26 am)
Re: stack overflow on Sparc64
, Mikulas Patocka
, (Fri Jun 20, 1:34 pm)
Re: stack overflow on Sparc64
, David Miller
, (Fri Jun 20, 1:37 pm)
Re: stack overflow on Sparc64
, Mikulas Patocka
, (Fri Jun 20, 2:14 pm)
Re: stack overflow on Sparc64
, David Miller
, (Fri Jun 20, 2:20 pm)
Re: stack overflow on Sparc64
, Mikulas Patocka
, (Fri Jun 20, 2:25 pm)
Re: stack overflow on Sparc64
, Mikulas Patocka
, (Fri Jun 20, 2:26 pm)
Re: stack overflow on Sparc64
, David Miller
, (Fri Jun 20, 2:41 pm)
Re: stack overflow on Sparc64
, David Miller
, (Fri Jun 20, 2:44 pm)
Re: stack overflow on Sparc64
, David Miller
, (Fri Jun 20, 2:47 pm)
Re: stack overflow on Sparc64
, Mikulas Patocka
, (Fri Jun 20, 3:22 pm)
Re: stack overflow on Sparc64
, David Miller
, (Fri Jun 20, 3:28 pm)
Re: stack overflow on Sparc64
, Mikulas Patocka
, (Fri Jun 20, 3:33 pm)
Re: stack overflow on Sparc64
, Mikulas Patocka
, (Fri Jun 20, 3:36 pm)
Re: stack overflow on Sparc64
, David Miller
, (Fri Jun 20, 3:47 pm)
Re: stack overflow on Sparc64
, Mikulas Patocka
, (Fri Jun 20, 5:37 pm)
Re: stack overflow on Sparc64
, David Miller
, (Fri Jun 20, 9:51 pm)
Re: stack overflow on Sparc64
, Mikulas Patocka
, (Sat Jun 21, 12:42 pm)
Re: stack overflow on Sparc64
, David Miller
, (Sun Jun 22, 12:03 am)
Re: stack overflow on Sparc64
, Mikulas Patocka
, (Sun Jun 22, 6:48 am)
Re: stack overflow on Sparc64
, David Miller
, (Mon Aug 11, 11:30 pm)
Re: stack overflow on Sparc64
, David Miller
, (Tue Aug 12, 1:22 am)
Re: stack overflow on Sparc64
, Mikulas Patocka
, (Tue Aug 12, 5:53 pm)
Re: stack overflow on Sparc64
, David Miller
, (Tue Aug 12, 5:59 pm)
console handover badness [was: stack overflow on Sparc64]
, Mikulas Patocka
, (Tue Aug 12, 6:11 pm)
Re: console handover badness
, David Miller
, (Tue Aug 12, 6:22 pm)
Re: console handover badness
, David Miller
, (Tue Aug 12, 6:40 pm)
Re: console handover badness
, David Miller
, (Wed Aug 13, 1:50 am)
Re: console handover badness
, Mikulas Patocka
, (Wed Aug 13, 5:46 am)
Re: console handover badness
, David Miller
, (Wed Aug 13, 8:25 pm)
Bootmem allocator broken [was: console handover badness]
, Mikulas Patocka
, (Thu Aug 14, 4:11 pm)
Re: Bootmem allocator broken
, David Miller
, (Thu Aug 14, 4:25 pm)
Re: Bootmem allocator broken
, Johannes Weiner
, (Thu Aug 14, 4:40 pm)
Re: Bootmem allocator broken
, Alexander Beregalov
, (Fri Aug 15, 4:09 am)
Re: Bootmem allocator broken
, David Miller
, (Fri Aug 15, 2:13 pm)
Navigation
Mailing list archives
Recent posts
Popular discussions
linux-kernel
:
Alexey Dobriyan
Re: [2.6.22.2 review 09/84] Fix rfkill IRQ flags.
Michael Moore
Re: underage models, pre teen models, lolita porn, young preteens, little lolitas
Alex Riesen
Re: [PATCH 4/7] lib: Introduce strnstr()
Thomas Gleixner
[ANNOUNCE] 2.6.31-rc6-rt2
Mathieu Desnoyers
Re: Linux 2.6.25-rc2
git
:
Blaisorblade
git-unpack-objects < pack file in repository doesn't work!
Matthieu Moy
Re: Cloning empty repositories, was Re: What is the idea for bare repositories?
Linus Torvalds
Re: Untracked working tree files
Peter Karlsson
Re: CRLF problems with Git on Win32
Johannes Schindelin
Re: [PATCH 4/4] git-rebase -i: New option to support rebase with merges
linux-netdev
:
Alan Menegotto
Re: Linux networking implementation and packet capture
Andrew Morton
Re: [PATCH] PHYLIB: IRQ event workqueue handling fixes
Timo Teräs
ip xfrm policy semantics
Jarek Poplawski
Re: [PATCH]: Fix queueing return values...
David Miller
Re: [PATCH 1/2] netdev: bfin_mac: enable bfin_mac net dev driver for BF51x
git-commits-head
:
Linux Kernel Mailing List
Blackfin: don't give CPU its own line in traps output
Linux Kernel Mailing List
No need to do lock_super() for exclusion in generic_shutdown_super()
Linux Kernel Mailing List
x86, msr: Export the register-setting MSR functions via /dev/*/msr
Linux Kernel Mailing List
MIPS: SMTC: Fix lockup in smtc_distribute_timer
Linux Kernel Mailing List
powerpc: gamecube/wii: usbgecko bootwrapper console support
openbsd-misc
:
Aaron Mason
Re: Defending OpenBSD Performance
Henning Brauer
Re: Defending OpenBSD Performance
Henning Brauer
Re: Defending OpenBSD Performance
Christiano Farina Haesbaert
Re: Defending OpenBSD Performance
Nick Holland
Re: 1 out of 3 hunks failed--saving rejects to kerberosV/src/lib/krb5/crypto.c.rej
Colocation donated by:
Syndicate