summaryrefslogtreecommitdiff
path: root/mm/madvise.c
diff options
context:
space:
mode:
authorjohn stultz <johnstul@us.ibm.com>2009-05-01 13:10:25 -0700
committerGreg Kroah-Hartman <gregkh@suse.de>2009-05-08 14:54:36 -0700
commit2ee201a9d57df7a12e228c6a9b06a15014231b72 (patch)
tree9c838f6bcfaafb1e0f932a9d7a8ba42e18921dc8 /mm/madvise.c
parent070bb0f3b6df167554f0ecdeb17a5bcdb1cd7b83 (diff)
downloadlwn-2ee201a9d57df7a12e228c6a9b06a15014231b72.tar.gz
lwn-2ee201a9d57df7a12e228c6a9b06a15014231b72.zip
clockevents: prevent endless loop in tick_handle_periodic()
commit 74a03b69d1b5ce00a568e142ca97e76b7f5239c6 upstream. tick_handle_periodic() can lock up hard when a one shot clock event device is used in combination with jiffies clocksource. Avoid an endless loop issue by requiring that a highres valid clocksource be installed before we call tick_periodic() in a loop when using ONESHOT mode. The result is we will only increment jiffies once per interrupt until a continuous hardware clocksource is available. Without this, we can run into a endless loop, where each cycle through the loop, jiffies is updated which increments time by tick_period or more (due to clock steering), which can cause the event programming to think the next event was before the newly incremented time and fail causing tick_periodic() to be called again and the whole process loops forever. [ Impact: prevent hard lock up ] Signed-off-by: John Stultz <johnstul@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Diffstat (limited to 'mm/madvise.c')
0 files changed, 0 insertions, 0 deletions