del_timer and del_timer_sync

    In our product code , I meet we use del_timer without use timer_pending to fix if it is ok. because of unclear knowledge . I do some study . Now , share my study:

    del_timer isn't safe on the SMP platforms.  if the timer is running on a different CPU when del_timer() returns , del_timer will not succeed and if the timer register itself , it will run continuous unless you prevent the register.so if have code like this :
 

del_timer(timer);
kfree(timer);

he timer_handler may access invalid memory. There is another case: timer_handler adds itself, and the timer will not been deactivated sometimes. So I replace del_timer() with del_timer_sync() instead.

The usage of del_timer_sync() is much restricted:

/***
 * del_timer_sync - deactivate a timer and wait for the handler to finish.
 * @timer: the timer to be deactivated
 *
 * This function only differs from del_timer() on SMP: besides deactivating
 * the timer it also makes sure the handler has finished executing on other
 * CPUs.
 *
 * Synchronization rules: callers must prevent restarting of the timer,
 * otherwise this function is meaningless. It must not be called from
 * interrupt contexts. The caller must not hold locks which would prevent
 * completion of the timer's handler. The timer's handler must not call
 * add_timer_on(). Upon exit the timer is not queued and the handler is
 * not running on any CPU.
 *
 * The function returns whether it has deactivated a pending timer or not.
 */

It can't been used in interrupt context(both irq and softirq).

and see this:

spin_lock_t lock;

timer_handler(unsigned long arg)
{
    spin_lock_bh(&lock);
    ...
    spin_unlock_bh(&lock);
}

func()
{
    spin_lock_bh(&lock);
    del_timer_sync(timer);
    spin_unlock_bh(&lock);
}

If lock is acquired by func and timer_handler is executed on another CPU, timer_handler will waits for lock and func will waits for timer, then the two CPU are locked up.