summaryrefslogtreecommitdiff
path: root/arch/arm/vfp/vfp.h
diff options
context:
space:
mode:
authorJohn David Anglin <dave.anglin@bell.net>2013-05-07 00:07:25 +0000
committerHelge Deller <deller@gmx.de>2013-05-07 20:33:03 +0200
commitc207a76bf155cb5cf24cf849c08f6555e9180594 (patch)
treef9f05b4d721dd215e28318337617beada3c238dd /arch/arm/vfp/vfp.h
parentf21dda025ab00da197ac30b6c6690c380d838683 (diff)
downloadlinux-3.10-c207a76bf155cb5cf24cf849c08f6555e9180594.tar.gz
linux-3.10-c207a76bf155cb5cf24cf849c08f6555e9180594.tar.bz2
linux-3.10-c207a76bf155cb5cf24cf849c08f6555e9180594.zip
parisc: only re-enable interrupts if we need to schedule or deliver signals when returning to userspace
Helge and I have found that we have a kernel stack overflow problem which causes a variety of random failures. Currently, we re-enable interrupts when returning from an external interrupt incase we need to schedule or delivery signals. As a result, a potentially unlimited number of interrupts can occur while we are running on the kernel stack. It is very limited in space (currently, 16k). This change defers enabling interrupts until we have actually decided to schedule or delivery signals. This only occurs when we about to return to userspace. This limits the number of interrupts on the kernel stack to one. In other cases, interrupts remain disabled until the final return from interrupt (rfi). Signed-off-by: John David Anglin <dave.anglin@bell.net> Signed-off-by: Helge Deller <deller@gmx.de>
Diffstat (limited to 'arch/arm/vfp/vfp.h')
0 files changed, 0 insertions, 0 deletions