Feature #3283
open131: Driver tries to stop an hrtimer which was never started
100%
Description
The kernel build with CONFIG_OPROFILE and CPU_HOTPLUG enabled. The oprofile is initialised using system timer in absence of hardware counters supports. Oprofile isn't started from userland.
In this setup while doing a CPU offline the kernel hangs in infinite for loop inside lock_hrtimer_base() function.
This happens because as part of oprofile_cpu_notify(, it tries to stop an hrtimer which was never started. These per-cpu hrtimers are started when the oprfile is started.
This problem also exist when the cpu is booted with maxcpus parameter set. When bringing the remaining cpus online the timers are started even if oprofile is not yet enabled.
This patch fix this issue by adding a state variable so that these hrtimer start/stop is only attempted when oprofile is started.
Commit: 79db8ef
Updated by Marina Makienko over 11 years ago
- % Done changed from 0 to 10
The function lock_hrtimer_base() is called in hrtimer_try_to_cancel(). So the function hrtimer_start() should be called before hrtimer_try_to_cancel().
Updated by Marina Makienko over 11 years ago
The function hrtimer_start:
hrtimer_start(struct hrtimer *timer, ktime_t tim, const enum hrtimer_mode mode)
{
return __hrtimer_start_range_ns(timer, tim, 0, mode, 1);
}
So I think that it would be better to call assert before function __hrtimer_start_range_ns() (not before hrtimer_start()).
Updated by Evgeny Novikov over 11 years ago
Marina Makienko wrote:
The function hrtimer_start:
hrtimer_start(struct hrtimer *timer, ktime_t tim, const enum hrtimer_mode mode) {
return __hrtimer_start_range_ns(timer, tim, 0, mode, 1);
}So I think that it would be better to call assert before function __hrtimer_start_range_ns() (not before hrtimer_start()).
IMHO, hrtimer_start is a more high-level function in comparison with __hrtimer_start_range_ns, thus it should be modeled.
Updated by Marina Makienko over 11 years ago
oprofile_start() and __oprofile_hrtimer_start() were added in rule 131.
Updated by Marina Makienko over 11 years ago
The launch was made on kernel linux-2.6.36.2 and there wasn't any unsafe verdict.
Then the model was tested on arch/x86/oprofile (because there isn't Makefile in drivers/oprofile, so this directory wasn't checked). Results: 10 safe verdicts and 1 unknown from 11 mains.
So I think that there isn't any reason to continue the development of this rule.
Updated by Marina Makienko over 11 years ago
In kernel linux-2.6.36.2 there is only 1 driver, which uses hrtimer_try_to_cancel(). If we check this driver with model 131_1a, we receive verdict "safe", because this function is inaccessible.
Updated by Evgeny Novikov over 11 years ago
It seems that commit 79db8ef was done in linux-2.6.36.2, so you need to check against linux-2.6.36.1 or less. What is the driver that was fixed in commit 79db8ef? What verdict does it have?
Updated by Marina Makienko over 11 years ago
- Status changed from Open to Resolved
- % Done changed from 10 to 100
Updated by Vadim Mutilin over 11 years ago
bug fixed by commit 79db8ef not found by LDV tools due to #3325