Documentation: Replace del_timer/del_timer_sync()

one of its functions results in a segmentation fault. The module-unload

functions must therefore cancel any delayed calls to loadable-module

functions, for example, any outstanding mod_timer() must be dealt

with via del_timer_sync() or similar.

with via timer_delete_sync() or similar.

Unfortunately, there is no way to cancel an RCU callback; once you

invoke call_rcu(), the callback function is eventually going to be

    static void __exit test_exit(void)

    {

            del_timer_sync(&test_timer);

            timer_delete_sync(&test_timer);

    }

    module_init(test_init);

            while (list) {

                    struct foo *next = list->next;

                    del_timer(&list->timer);

                    timer_delete(&list->timer);

                    kfree(list);

                    list = next;

            }

the element (which has already been freed!).

This can be avoided by checking the result of

del_timer(): if it returns 1, the timer has been deleted.

timer_delete(): if it returns 1, the timer has been deleted.

If 0, it means (in this case) that it is currently running, so we can

do::

                    while (list) {

                            struct foo *next = list->next;

                            if (!del_timer(&list->timer)) {

                            if (!timer_delete(&list->timer)) {

                                    /* Give timer a chance to delete this */

                                    spin_unlock_bh(&list_lock);

                                    goto retry;

Another common problem is deleting timers which restart themselves (by

calling add_timer() at the end of their timer function).

Because this is a fairly common case which is prone to races, you should

use del_timer_sync() (``include/linux/timer.h``) to

handle this case.

use timer_delete_sync() (``include/linux/timer.h``) to handle this case.

Locking Speed

=============

-  kfree()

-  add_timer() and del_timer()

-  add_timer() and timer_delete()

Mutex API reference

===================

was not really a win, due to the different data structures. Also, the

hrtimer functions now have clearer behavior and clearer names - such as

hrtimer_try_to_cancel() and hrtimer_cancel() [which are roughly

equivalent to del_timer() and del_timer_sync()] - so there's no direct

equivalent to timer_delete() and timer_delete_sync()] - so there's no direct

1:1 mapping between them on the algorithmic level, and thus no real

potential for code sharing either.

            while (list) {

                    struct foo *next = list->next;

                    del_timer(&list->timer);

                    timer_delete(&list->timer);

                    kfree(list);

                    list = next;

            }

di eliminare il suo oggetto (che però è già stato eliminato).

Questo può essere evitato controllando il valore di ritorno di

del_timer(): se ritorna 1, il temporizzatore è stato già

timer_delete(): se ritorna 1, il temporizzatore è stato già

rimosso. Se 0, significa (in questo caso) che il temporizzatore è in

esecuzione, quindi possiamo fare come segue::

                    while (list) {

                            struct foo *next = list->next;

                            if (!del_timer(&list->timer)) {

                            if (!timer_delete(&list->timer)) {

                                    /* Give timer a chance to delete this */

                                    spin_unlock_bh(&list_lock);

                                    goto retry;

Un altro problema è l'eliminazione dei temporizzatori che si riavviano

da soli (chiamando add_timer() alla fine della loro esecuzione).

Dato che questo è un problema abbastanza comune con una propensione

alle corse critiche, dovreste usare del_timer_sync()

alle corse critiche, dovreste usare timer_delete_sync()

(``include/linux/timer.h``) per gestire questo caso.

Velocità della sincronizzazione

-  kfree()

-  add_timer() e del_timer()

-  add_timer() e timer_delete()

Riferimento per l'API dei Mutex

===============================