del_timer_sync(), function epilog and rmmod puzzle

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi guys,
Say we have a module for kernel 2.4(.25 exactly) with themodule_init() as followed:
module_init(){.....mod_timer(&my_timer, jiffies+INTERVAL);.....}
and we have my_timer.function as followed:
void my_timer_fun(unsigned long dummy){if(condition) {schedule_task(&my_task);}
if(!stop_my_timer) {mod_timer(&my_timer, jiffies+INTERVAL);}}
When rmmod, we must do some housekeeping for my_timer and my_task, andhere comes the questions:
1. As to my_timer, is the following code enough? Does any race condition exist?
stop_my_timer = 1;del_timer_sync(&my_timer);
According to my understanding, the code is enough, and furthermore,the flag var "stop_my_timer" is unnecessary. Since after return,del_timer_sync() can ensure a) my_timer is not running on any CPU; b)my_timer is not in the timer list so it will not execute in thefuture.
But according to "Linux device driver, 2e", Chapter 6 Flow of Time,Kernel Timers, it says:
" If the timer function can restart the timer itself (a commonpattern), you should also have a "stop timer'' flag that you setbefore calling del_timer_sync. The timer function should then checkthat flag and not reschedule itself with add_timer if the flag hasbeen set."
Do I misunderstand something here? Is there any trap for del_timer_sync()?
The previous quoted text can be found online here:http://www.xml.com/ldd/chapter/book/ch06.html#t5
2. As to my_task, after my_timer has been deleted, it maybe in 3status: a) running; b) in the task queue waiting for running; c) notrunning and not in the task queue. So, how can I distinguish thesesituations? Since my_task.list will not be reinitialized afterrun_task_queue(), we can't use it to check whether my_task is in queueor not. And we can't use my_task.sync either, since it has obviousrace condition. I guess it's really a newbie's question but I just cannot resolve it by myself in the last few days.
To say the least, suppose we know my_task is in the queue or isrunning by some way, we must wait for its completion, maybe we canapply interruptiable_sleep_on() in module_exit(), andwake_up_interruptible() at the end of my_task.routine() like this:
void my_task_routine(void *dummy){..........wake_up_interruptible(...);}
Well, as we know, a function contains prolog and epilog. Afterwake_up_interruptible(), the rmmod thread executes and frees thememory of this module. At this time, memory containing epilog of themy_task_routine() was freed, it may oops when those "epilog" executelater on. Is this a trap? or do I make some mistakes?
At last, many thanks for you to read my post, and any help will be appreciated.
-- Invent and fit; have fits and reinvent!We toast the Lisp programmer who pens his thoughts within nests of parentheses.��.n��������+%����w�j)p���{.n����z�ޖw�n'���q���b�������v��m�����Y�����


[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux