Feature #3283
open
131: Driver tries to stop an hrtimer which was never started
Added by Marina Makienko almost 12 years ago.
Updated over 11 years ago.
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
Related issues
1 (1 open — 0 closed)
- % 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().
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()).
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.
- Status changed from New to Open
oprofile_start() and __oprofile_hrtimer_start() were added in rule 131.
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.
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.
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?
- Status changed from Open to Resolved
- % Done changed from 10 to 100
bug fixed by commit 79db8ef not found by LDV tools due to #3325
Also available in: Atom
PDF