From: Thomas Gleixner <tglx@linutronix.de>
To: LKML <linux-kernel@vger.kernel.org>
Cc: Linus Torvalds <torvalds@linuxfoundation.org>,
Steven Rostedt <rostedt@goodmis.org>,
Anna-Maria Behnsen <anna-maria@linutronix.de>,
Peter Zijlstra <peterz@infradead.org>,
Stephen Boyd <sboyd@kernel.org>,
Guenter Roeck <linux@roeck-us.net>,
Andrew Morton <akpm@linux-foundation.org>,
Julia Lawall <Julia.Lawall@inria.fr>,
Arnd Bergmann <arnd@arndb.de>,
Viresh Kumar <viresh.kumar@linaro.org>,
Marc Zyngier <maz@kernel.org>,
Marcel Holtmann <marcel@holtmann.org>,
Johan Hedberg <johan.hedberg@gmail.com>,
Luiz Augusto von Dentz <luiz.dentz@gmail.com>,
linux-bluetooth@vger.kernel.org,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
netdev@vger.kernel.org
Subject: [patch V2 11/17] Documentation: Replace del_timer/del_timer_sync()
Date: Tue, 22 Nov 2022 18:45:01 +0100 (CET) [thread overview]
Message-ID: <20221122173648.737720888@linutronix.de> (raw)
In-Reply-To: 20221122171312.191765396@linutronix.de
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);
next prev parent reply other threads:[~2022-11-22 17:46 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-22 17:44 [patch V2 00/17] timers: Provide timer_shutdown[_sync]() Thomas Gleixner
2022-11-22 17:44 ` [patch V2 01/17] Documentation: Remove bogus claim about del_timer_sync() Thomas Gleixner
2022-11-22 18:37 ` timers: Provide timer_shutdown[_sync]() bluez.test.bot
2022-11-22 17:44 ` [patch V2 02/17] ARM: spear: Do not use timer namespace for timer_shutdown() function Thomas Gleixner
2022-11-22 17:44 ` [patch V2 03/17] clocksource/drivers/arm_arch_timer: " Thomas Gleixner
2022-11-22 17:44 ` [patch V2 04/17] clocksource/drivers/sp804: " Thomas Gleixner
2022-11-22 17:44 ` [patch V2 05/17] timers: Get rid of del_singleshot_timer_sync() Thomas Gleixner
2022-11-22 17:44 ` [patch V2 06/17] timers: Replace BUG_ON()s Thomas Gleixner
2022-11-22 17:44 ` [patch V2 07/17] timers: Update kernel-doc for various functions Thomas Gleixner
2022-11-23 10:23 ` Anna-Maria Behnsen
2022-11-23 17:09 ` Thomas Gleixner
2022-11-22 17:44 ` [patch V2 08/17] timers: Use del_timer_sync() even on UP Thomas Gleixner
2022-11-22 17:44 ` [patch V2 09/17] timers: Rename del_timer_sync() to timer_delete_sync() Thomas Gleixner
2022-11-22 22:23 ` David Laight
2022-11-22 22:45 ` Steven Rostedt
2022-11-23 0:08 ` Thomas Gleixner
2022-11-23 0:28 ` Steven Rostedt
2022-11-22 17:45 ` [patch V2 10/17] timers: Rename del_timer() to timer_delete() Thomas Gleixner
2022-11-22 17:45 ` Thomas Gleixner [this message]
2022-11-22 17:45 ` [patch V2 12/17] timers: Silently ignore timers with a NULL function Thomas Gleixner
2022-11-23 9:22 ` Anna-Maria Behnsen
2022-11-23 10:39 ` Anna-Maria Behnsen
2022-11-23 11:06 ` Anna-Maria Behnsen
2022-11-23 17:08 ` Thomas Gleixner
2022-11-22 17:45 ` [patch V2 13/17] timers: Split [try_to_]del_timer[_sync]() to prepare for shutdown mode Thomas Gleixner
2022-11-22 23:04 ` Jacob Keller
2022-11-23 17:05 ` Thomas Gleixner
2022-11-23 18:45 ` Jacob Keller
2022-11-23 11:23 ` Anna-Maria Behnsen
2022-11-23 11:24 ` Anna-Maria Behnsen
2022-11-22 17:45 ` [patch V2 14/17] timers: Add shutdown mechanism to the internal functions Thomas Gleixner
2022-11-22 17:45 ` [patch V2 15/17] timers: Provide timer_shutdown[_sync]() Thomas Gleixner
2022-11-23 12:02 ` Anna-Maria Behnsen
2022-11-23 17:06 ` Thomas Gleixner
2022-11-22 17:45 ` [patch V2 16/17] timers: Update the documentation to reflect on the new timer_shutdown() API Thomas Gleixner
2022-11-22 17:45 ` [patch V2 17/17] Bluetooth: hci_qca: Fix the teardown problem for real Thomas Gleixner
2022-11-22 23:09 ` [patch V2 00/17] timers: Provide timer_shutdown[_sync]() Jacob Keller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20221122173648.737720888@linutronix.de \
--to=tglx@linutronix.de \
--cc=Julia.Lawall@inria.fr \
--cc=akpm@linux-foundation.org \
--cc=anna-maria@linutronix.de \
--cc=arnd@arndb.de \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=johan.hedberg@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-bluetooth@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=luiz.dentz@gmail.com \
--cc=marcel@holtmann.org \
--cc=maz@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=sboyd@kernel.org \
--cc=torvalds@linuxfoundation.org \
--cc=viresh.kumar@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.