Commit 379af13b authored Dec 12, 2022 by Alexander Sverdlin Committed by Thomas Gleixner Jan 11, 2023

docs: locking: Discourage from calling disable_irq() in atomic



Correct the example in the 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.

Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Manfred Spraul <manfred@colorfullife.com>
Cc: linux-doc@vger.kernel.org
Link: https://lore.kernel.org/lkml/87k02wbs2n.ffs@tglx/
Link: https://lore.kernel.org/r/20221212163715.830315-1-alexander.sverdlin@siemens.com

parent 17549b0f

Documentation/kernel-hacking/locking.rst

+2 −2

Original line number	Diff line number	Diff line
		@@ -1277,11 +1277,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).

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

+2 −2

Original line number	Diff line number	Diff line
		@@ -1307,11 +1307,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