lkml.org 
[lkml]   [2022]   [Nov]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    From
    Subject[patch V2 11/17] Documentation: Replace del_timer/del_timer_sync()
    Date
    Adjust to the new preferred function names.

    Suggested-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    ---
    Documentation/RCU/Design/Requirements/Requirements.rst | 2 +-
    Documentation/core-api/local_ops.rst | 2 +-
    Documentation/kernel-hacking/locking.rst | 11 +++++------
    Documentation/timers/hrtimers.rst | 2 +-
    Documentation/translations/it_IT/kernel-hacking/locking.rst | 10 +++++-----
    Documentation/translations/zh_CN/core-api/local_ops.rst | 2 +-
    6 files changed, 14 insertions(+), 15 deletions(-)

    --- a/Documentation/RCU/Design/Requirements/Requirements.rst
    +++ b/Documentation/RCU/Design/Requirements/Requirements.rst
    @@ -1858,7 +1858,7 @@ unloaded. After a given module has been
    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
    --- a/Documentation/core-api/local_ops.rst
    +++ b/Documentation/core-api/local_ops.rst
    @@ -191,7 +191,7 @@ Here is a sample module which implements

    static void __exit test_exit(void)
    {
    - del_timer_sync(&test_timer);
    + timer_delete_sync(&test_timer);
    }

    module_init(test_init);
    --- a/Documentation/kernel-hacking/locking.rst
    +++ b/Documentation/kernel-hacking/locking.rst
    @@ -967,7 +967,7 @@ If you want to destroy the entire collec

    while (list) {
    struct foo *next = list->next;
    - del_timer(&list->timer);
    + timer_delete(&list->timer);
    kfree(list);
    list = next;
    }
    @@ -981,7 +981,7 @@ the lock after we spin_unlock_bh(), and
    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::

    @@ -990,7 +990,7 @@ If 0, it means (in this case) that it is

    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;
    @@ -1005,8 +1005,7 @@ If 0, it means (in this case) that it is
    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
    =============
    @@ -1334,7 +1333,7 @@ lock.

    - kfree()

    -- add_timer() and del_timer()
    +- add_timer() and timer_delete()

    Mutex API reference
    ===================
    --- a/Documentation/timers/hrtimers.rst
    +++ b/Documentation/timers/hrtimers.rst
    @@ -118,7 +118,7 @@ existing timer wheel code, as it is matu
    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.

    --- a/Documentation/translations/it_IT/kernel-hacking/locking.rst
    +++ b/Documentation/translations/it_IT/kernel-hacking/locking.rst
    @@ -990,7 +990,7 @@ Se volete eliminare l'intera collezione

    while (list) {
    struct foo *next = list->next;
    - del_timer(&list->timer);
    + timer_delete(&list->timer);
    kfree(list);
    list = next;
    }
    @@ -1003,7 +1003,7 @@ e prenderà il *lock* solo dopo spin_unl
    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::

    @@ -1012,7 +1012,7 @@ rimosso. Se 0, significa (in questo caso

    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;
    @@ -1026,7 +1026,7 @@ rimosso. Se 0, significa (in questo caso
    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
    @@ -1372,7 +1372,7 @@ contesto, o trattenendo un qualsiasi *lo

    - kfree()

    -- add_timer() e del_timer()
    +- add_timer() e timer_delete()

    Riferimento per l'API dei Mutex
    ===============================
    --- a/Documentation/translations/zh_CN/core-api/local_ops.rst
    +++ b/Documentation/translations/zh_CN/core-api/local_ops.rst
    @@ -185,7 +185,7 @@ UP之间没有不同的行为,在你�

    static void __exit test_exit(void)
    {
    - del_timer_sync(&test_timer);
    + timer_delete_sync(&test_timer);
    }

    module_init(test_init);
    \
     
     \ /
      Last update: 2022-11-22 18:47    [W:4.129 / U:1.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site