2022-12-23 11:53:35

by Sverdlin, Alexander

Subject: [PATCH v2] docs: kernel-hacking: discourage from calling disable_irq() in atomic

From: Alexander Sverdlin <[email protected]>

Correct the example in documentation so that disable_irq() is not being
called in atomic context.

disable_irq() calls sleeping synchronize_irq(), it's not allowed to call
them in atomic context.

Link: https://lore.kernel.org/lkml/87k02wbs2n.ffs@tglx/
Reviewed-by: Manfred Spraul <[email protected]>
Signed-off-by: Alexander Sverdlin <[email protected]>
---
Changelog:
v2: Dropped changes to manage.c because of already applied
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/kernel-irq-managec-disable_irq-might-sleep.patch

Documentation/kernel-hacking/locking.rst | 4 ++--
Documentation/translations/it_IT/kernel-hacking/locking.rst | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/Documentation/kernel-hacking/locking.rst b/Documentation/kernel-hacking/locking.rst
index 6805ae6e86e65..95fd6e0900d92 100644
--- a/Documentation/kernel-hacking/locking.rst
+++ b/Documentation/kernel-hacking/locking.rst
@@ -1274,11 +1274,11 @@ Manfred Spraul points out that you can still do this, even if the data
is very occasionally accessed in user context or softirqs/tasklets. The
irq handler doesn't use a lock, and all other accesses are done as so::

- spin_lock(&lock);
+ mutex_lock(&lock);
disable_irq(irq);
...
enable_irq(irq);
- spin_unlock(&lock);
+ mutex_unlock(&lock);

The disable_irq() prevents the irq handler from running
(and waits for it to finish if it's currently running on other CPUs).
diff --git a/Documentation/translations/it_IT/kernel-hacking/locking.rst b/Documentation/translations/it_IT/kernel-hacking/locking.rst
index 51af37f2d6210..bfbada56cf351 100644
--- a/Documentation/translations/it_IT/kernel-hacking/locking.rst
+++ b/Documentation/translations/it_IT/kernel-hacking/locking.rst
@@ -1309,11 +1309,11 @@ se i dati vengono occasionalmente utilizzati da un contesto utente o
da un'interruzione software. Il gestore d'interruzione non utilizza alcun
*lock*, e tutti gli altri accessi verranno fatti così::

- spin_lock(&lock);
+ mutex_lock(&lock);
disable_irq(irq);
...
enable_irq(irq);
- spin_unlock(&lock);
+ mutex_unlock(&lock);

La funzione disable_irq() impedisce al gestore d'interruzioni
d'essere eseguito (e aspetta che finisca nel caso fosse in esecuzione su
--
2.34.1

2023-01-11 23:28:23

by Jonathan Corbet

Subject: Re: [PATCH v2] docs: kernel-hacking: discourage from calling disable_irq() in atomic

"A. Sverdlin" <[email protected]> writes:

> From: Alexander Sverdlin <[email protected]>
>
> Correct the example in documentation so that disable_irq() is not being
> called in atomic context.
>
> disable_irq() calls sleeping synchronize_irq(), it's not allowed to call
> them in atomic context.
>
> Link: https://lore.kernel.org/lkml/87k02wbs2n.ffs@tglx/
> Reviewed-by: Manfred Spraul <[email protected]>
> Signed-off-by: Alexander Sverdlin <[email protected]>
> ---
> Changelog:
> v2: Dropped changes to manage.c because of already applied
> https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/kernel-irq-managec-disable_irq-might-sleep.patch
>
> Documentation/kernel-hacking/locking.rst | 4 ++--
> Documentation/translations/it_IT/kernel-hacking/locking.rst | 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)

Applied, thanks.

jon