+1 -1

Documentation/RCU/Design/Requirements/Requirements.rst

reviewed

··· 1858 1858 one of its functions results in a segmentation fault. The module-unload 1859 1859 functions must therefore cancel any delayed calls to loadable-module 1860 1860 functions, for example, any outstanding mod_timer() must be dealt 1861 1861 - with via del_timer_sync() or similar. 1861 1861 + with via timer_delete_sync() or similar. 1862 1862 1863 1863 Unfortunately, there is no way to cancel an RCU callback; once you 1864 1864 invoke call_rcu(), the callback function is eventually going to be

+1 -1

Documentation/core-api/local_ops.rst

reviewed

··· 191 191 192 192 static void __exit test_exit(void) 193 193 { 194 194 - del_timer_sync(&test_timer); 194 194 + timer_delete_sync(&test_timer); 195 195 } 196 196 197 197 module_init(test_init);

+5 -6

Documentation/kernel-hacking/locking.rst

reviewed

··· 967 967 968 968 while (list) { 969 969 struct foo *next = list->next; 970 970 - del_timer(&list->timer); 970 970 + timer_delete(&list->timer); 971 971 kfree(list); 972 972 list = next; 973 973 } ··· 981 981 the element (which has already been freed!). 982 982 983 983 This can be avoided by checking the result of 984 984 - del_timer(): if it returns 1, the timer has been deleted. 984 984 + timer_delete(): if it returns 1, the timer has been deleted. 985 985 If 0, it means (in this case) that it is currently running, so we can 986 986 do:: 987 987 ··· 990 990 991 991 while (list) { 992 992 struct foo *next = list->next; 993 993 - if (!del_timer(&list->timer)) { 993 993 + if (!timer_delete(&list->timer)) { 994 994 /* Give timer a chance to delete this */ 995 995 spin_unlock_bh(&list_lock); 996 996 goto retry; ··· 1005 1005 Another common problem is deleting timers which restart themselves (by 1006 1006 calling add_timer() at the end of their timer function). 1007 1007 Because this is a fairly common case which is prone to races, you should 1008 1008 - use del_timer_sync() (``include/linux/timer.h``) to 1009 1009 - handle this case. 1008 1008 + use timer_delete_sync() (``include/linux/timer.h``) to handle this case. 1010 1009 1011 1010 Locking Speed 1012 1011 ============= ··· 1333 1334 1334 1335 - kfree() 1335 1336 1336 1336 - - add_timer() and del_timer() 1337 1337 + - add_timer() and timer_delete() 1337 1338 1338 1339 Mutex API reference 1339 1340 ===================

+1 -1

Documentation/timers/hrtimers.rst

reviewed

··· 118 118 was not really a win, due to the different data structures. Also, the 119 119 hrtimer functions now have clearer behavior and clearer names - such as 120 120 hrtimer_try_to_cancel() and hrtimer_cancel() [which are roughly 121 121 - equivalent to del_timer() and del_timer_sync()] - so there's no direct 121 121 + equivalent to timer_delete() and timer_delete_sync()] - so there's no direct 122 122 1:1 mapping between them on the algorithmic level, and thus no real 123 123 potential for code sharing either. 124 124

+5 -5

Documentation/translations/it_IT/kernel-hacking/locking.rst

reviewed

··· 990 990 991 991 while (list) { 992 992 struct foo *next = list->next; 993 993 - del_timer(&list->timer); 993 993 + timer_delete(&list->timer); 994 994 kfree(list); 995 995 list = next; 996 996 } ··· 1003 1003 di eliminare il suo oggetto (che però è già stato eliminato). 1004 1004 1005 1005 Questo può essere evitato controllando il valore di ritorno di 1006 1006 - del_timer(): se ritorna 1, il temporizzatore è stato già 1006 1006 + timer_delete(): se ritorna 1, il temporizzatore è stato già 1007 1007 rimosso. Se 0, significa (in questo caso) che il temporizzatore è in 1008 1008 esecuzione, quindi possiamo fare come segue:: 1009 1009 ··· 1012 1012 1013 1013 while (list) { 1014 1014 struct foo *next = list->next; 1015 1015 - if (!del_timer(&list->timer)) { 1015 1015 + if (!timer_delete(&list->timer)) { 1016 1016 /* Give timer a chance to delete this */ 1017 1017 spin_unlock_bh(&list_lock); 1018 1018 goto retry; ··· 1026 1026 Un altro problema è l'eliminazione dei temporizzatori che si riavviano 1027 1027 da soli (chiamando add_timer() alla fine della loro esecuzione). 1028 1028 Dato che questo è un problema abbastanza comune con una propensione 1029 1029 - alle corse critiche, dovreste usare del_timer_sync() 1029 1029 + alle corse critiche, dovreste usare timer_delete_sync() 1030 1030 (``include/linux/timer.h``) per gestire questo caso. 1031 1031 1032 1032 Velocità della sincronizzazione ··· 1372 1372 1373 1373 - kfree() 1374 1374 1375 1375 - - add_timer() e del_timer() 1375 1375 + - add_timer() e timer_delete() 1376 1376 1377 1377 Riferimento per l'API dei Mutex 1378 1378 ===============================

+1 -1

Documentation/translations/zh_CN/core-api/local_ops.rst

reviewed

··· 185 185 186 186 static void __exit test_exit(void) 187 187 { 188 188 - del_timer_sync(&test_timer); 188 188 + timer_delete_sync(&test_timer); 189 189 } 190 190 191 191 module_init(test_init);