Chia-Liang Wang and Andrew Morton
ff713698ba
lib: ratelimit: fix spelling mistake 'seperately'
...
Corrects a spelling mistake in a comment in ratelimit.c where 'seperately'
was used instead of 'separately'.
Link: https://lkml.kernel.org/r/20251119101144.3175-1-a0979625527@icloud.com
Signed-off-by: Chia-Liang Wang <a0979652527@icloud.com >
Signed-off-by: Andrew Morton <akpm@linux-foundation.org >
2025-11-20 14:03:45 -08:00
Paul E. McKenney
ba575cea29
ratelimit: Drop redundant accesses to burst
...
Now that there is the "burst <= 0" fastpath, for all later code, burst
must be strictly greater than zero. Therefore, drop the redundant checks
of this local variable.
Link: https://lore.kernel.org/all/fbe93a52-365e-47fe-93a4-44a44547d601@paulmck-laptop/
Link: https://lore.kernel.org/all/20250423115409.3425-1-spasswolf@web.de/
Signed-off-by: Paul E. McKenney <paulmck@kernel.org >
Reviewed-by: Petr Mladek <pmladek@suse.com >
Cc: Andrew Morton <akpm@linux-foundation.org >
Cc: Kuniyuki Iwashima <kuniyu@amazon.com >
Cc: Mateusz Guzik <mjguzik@gmail.com >
Cc: Steven Rostedt <rostedt@goodmis.org >
Cc: John Ogness <john.ogness@linutronix.de >
Cc: Sergey Senozhatsky <senozhatsky@chromium.org >
2025-05-08 16:13:27 -07:00
Paul E. McKenney
4b2cce999c
ratelimit: Use nolock_ret restructuring to collapse common case code
...
Now that unlock_ret releases the lock, then falls into nolock_ret, which
handles ->missed based on the value of ret, the common-case lock-held
code can be collapsed into a single "if" statement with a single-statement
"then" clause.
Yes, we could go further and just assign the "if" condition to ret,
but in the immortal words of MSDOS, "Are you sure?".
Link: https://lore.kernel.org/all/fbe93a52-365e-47fe-93a4-44a44547d601@paulmck-laptop/
Link: https://lore.kernel.org/all/20250423115409.3425-1-spasswolf@web.de/
Signed-off-by: Paul E. McKenney <paulmck@kernel.org >
Reviewed-by: Petr Mladek <pmladek@suse.com >
Cc: Andrew Morton <akpm@linux-foundation.org >
Cc: Kuniyuki Iwashima <kuniyu@amazon.com >
Cc: Mateusz Guzik <mjguzik@gmail.com >
Cc: Steven Rostedt <rostedt@goodmis.org >
Cc: John Ogness <john.ogness@linutronix.de >
Cc: Sergey Senozhatsky <senozhatsky@chromium.org >
2025-05-08 16:13:27 -07:00
Paul E. McKenney
743a1942d5
ratelimit: Use nolock_ret label to collapse lock-failure code
...
Now that we have a nolock_ret label that handles ->missed correctly
based on the value of ret, we can eliminate a local variable and collapse
several "if" statements on the lock-acquisition-failure code path.
Link: https://lore.kernel.org/all/fbe93a52-365e-47fe-93a4-44a44547d601@paulmck-laptop/
Link: https://lore.kernel.org/all/20250423115409.3425-1-spasswolf@web.de/
Signed-off-by: Paul E. McKenney <paulmck@kernel.org >
Reviewed-by: Petr Mladek <pmladek@suse.com >
Cc: Andrew Morton <akpm@linux-foundation.org >
Cc: Kuniyuki Iwashima <kuniyu@amazon.com >
Cc: Mateusz Guzik <mjguzik@gmail.com >
Cc: Steven Rostedt <rostedt@goodmis.org >
Cc: John Ogness <john.ogness@linutronix.de >
Cc: Sergey Senozhatsky <senozhatsky@chromium.org >
2025-05-08 16:13:27 -07:00
Paul E. McKenney
a69114c2a1
ratelimit: Use nolock_ret label to save a couple of lines of code
...
Create a nolock_ret label in order to start consolidating the unlocked
return paths that conditionally invoke ratelimit_state_inc_miss().
Link: https://lore.kernel.org/all/fbe93a52-365e-47fe-93a4-44a44547d601@paulmck-laptop/
Link: https://lore.kernel.org/all/20250423115409.3425-1-spasswolf@web.de/
Signed-off-by: Paul E. McKenney <paulmck@kernel.org >
Reviewed-by: Petr Mladek <pmladek@suse.com >
Cc: Andrew Morton <akpm@linux-foundation.org >
Cc: Kuniyuki Iwashima <kuniyu@amazon.com >
Cc: Mateusz Guzik <mjguzik@gmail.com >
Cc: Steven Rostedt <rostedt@goodmis.org >
Cc: John Ogness <john.ogness@linutronix.de >
Cc: Sergey Senozhatsky <senozhatsky@chromium.org >
2025-05-08 16:13:27 -07:00
Paul E. McKenney
f2d0ea0f08
ratelimit: Simplify common-case exit path
...
By making "ret" always be initialized, and moving the final call to
ratelimit_state_inc_miss() out from under the lock, we save a goto and
a couple lines of code. This also saves a couple of lines of code from
the unconditional enable/disable slowpath.
Link: https://lore.kernel.org/all/fbe93a52-365e-47fe-93a4-44a44547d601@paulmck-laptop/
Link: https://lore.kernel.org/all/20250423115409.3425-1-spasswolf@web.de/
Signed-off-by: Paul E. McKenney <paulmck@kernel.org >
Reviewed-by: Petr Mladek <pmladek@suse.com >
Cc: Andrew Morton <akpm@linux-foundation.org >
Cc: Kuniyuki Iwashima <kuniyu@amazon.com >
Cc: Mateusz Guzik <mjguzik@gmail.com >
Cc: Steven Rostedt <rostedt@goodmis.org >
Cc: John Ogness <john.ogness@linutronix.de >
Cc: Sergey Senozhatsky <senozhatsky@chromium.org >
2025-05-08 16:13:27 -07:00
Petr Mladek and Paul E. McKenney
a940d145cc
ratelimit: Warn if ->interval or ->burst are negative
...
Currently, ___ratelimit() treats a negative ->interval or ->burst as
if it was zero, but this is an accident of the current implementation.
Therefore, splat in this case, which might have the benefit of detecting
use of uninitialized ratelimit_state structures on the one hand or easing
addition of new features on the other.
Link: https://lore.kernel.org/all/fbe93a52-365e-47fe-93a4-44a44547d601@paulmck-laptop/
Link: https://lore.kernel.org/all/20250423115409.3425-1-spasswolf@web.de/
Signed-off-by: Petr Mladek <pmladek@suse.com >
Signed-off-by: Paul E. McKenney <paulmck@kernel.org >
Cc: Andrew Morton <akpm@linux-foundation.org >
Cc: Kuniyuki Iwashima <kuniyu@amazon.com >
Cc: Mateusz Guzik <mjguzik@gmail.com >
Cc: Steven Rostedt <rostedt@goodmis.org >
Cc: John Ogness <john.ogness@linutronix.de >
Cc: Sergey Senozhatsky <senozhatsky@chromium.org >
2025-05-08 16:13:27 -07:00
Paul E. McKenney
96d366048f
ratelimit: Avoid atomic decrement under lock if already rate-limited
...
Currently, if the lock is acquired, the code unconditionally does
an atomic decrement on ->rs_n_left, even if that atomic operation is
guaranteed to return a limit-rate verdict. A limit-rate verdict will
in fact be the common case when something is spewing into a rate limit.
This unconditional atomic operation incurs needless overhead and also
raises the spectre of counter wrap.
Therefore, do the atomic decrement only if there is some chance that
rates won't be limited.
Link: https://lore.kernel.org/all/fbe93a52-365e-47fe-93a4-44a44547d601@paulmck-laptop/
Link: https://lore.kernel.org/all/20250423115409.3425-1-spasswolf@web.de/
Signed-off-by: Paul E. McKenney <paulmck@kernel.org >
Reviewed-by: Petr Mladek <pmladek@suse.com >
Cc: Andrew Morton <akpm@linux-foundation.org >
Cc: Kuniyuki Iwashima <kuniyu@amazon.com >
Cc: Mateusz Guzik <mjguzik@gmail.com >
Cc: Steven Rostedt <rostedt@goodmis.org >
Cc: John Ogness <john.ogness@linutronix.de >
Cc: Sergey Senozhatsky <senozhatsky@chromium.org >
2025-05-08 16:13:27 -07:00
Paul E. McKenney
123a1d97b2
ratelimit: Avoid atomic decrement if already rate-limited
...
Currently, if the lock could not be acquired, the code unconditionally
does an atomic decrement on ->rs_n_left, even if that atomic operation
is guaranteed to return a limit-rate verdict. This incurs needless
overhead and also raises the spectre of counter wrap.
Therefore, do the atomic decrement only if there is some chance that
rates won't be limited.
Link: https://lore.kernel.org/all/fbe93a52-365e-47fe-93a4-44a44547d601@paulmck-laptop/
Link: https://lore.kernel.org/all/20250423115409.3425-1-spasswolf@web.de/
Signed-off-by: Paul E. McKenney <paulmck@kernel.org >
Reviewed-by: Petr Mladek <pmladek@suse.com >
Cc: Andrew Morton <akpm@linux-foundation.org >
Cc: Kuniyuki Iwashima <kuniyu@amazon.com >
Cc: Mateusz Guzik <mjguzik@gmail.com >
Cc: Steven Rostedt <rostedt@goodmis.org >
Cc: John Ogness <john.ogness@linutronix.de >
Cc: Sergey Senozhatsky <senozhatsky@chromium.org >
2025-05-08 16:13:27 -07:00
Paul E. McKenney
21ac6e5eda
ratelimit: Don't flush misses counter if RATELIMIT_MSG_ON_RELEASE
...
Restore the previous semantics where the misses counter is unchanged if
the RATELIMIT_MSG_ON_RELEASE flag is set.
Link: https://lore.kernel.org/all/fbe93a52-365e-47fe-93a4-44a44547d601@paulmck-laptop/
Link: https://lore.kernel.org/all/20250423115409.3425-1-spasswolf@web.de/
Signed-off-by: Paul E. McKenney <paulmck@kernel.org >
Reviewed-by: Petr Mladek <pmladek@suse.com >
Cc: Andrew Morton <akpm@linux-foundation.org >
Cc: Kuniyuki Iwashima <kuniyu@amazon.com >
Cc: Mateusz Guzik <mjguzik@gmail.com >
Cc: Steven Rostedt <rostedt@goodmis.org >
Cc: John Ogness <john.ogness@linutronix.de >
Cc: Sergey Senozhatsky <senozhatsky@chromium.org >
2025-05-08 16:13:27 -07:00
Paul E. McKenney
aa2cc356f8
ratelimit: Force re-initialization when rate-limiting re-enabled
...
Currently, if rate limiting is disabled, ___ratelimit() does an immediate
early return with no state changes. This can result in false-positive
drops when re-enabling rate limiting. Therefore, mark the ratelimit_state
structure "uninitialized" when rate limiting is disabled.
[ paulmck: Apply Petr Mladek feedback. ]
Link: https://lore.kernel.org/all/fbe93a52-365e-47fe-93a4-44a44547d601@paulmck-laptop/
Link: https://lore.kernel.org/all/20250423115409.3425-1-spasswolf@web.de/
Signed-off-by: Paul E. McKenney <paulmck@kernel.org >
Reviewed-by: Petr Mladek <pmladek@suse.com >
Cc: Andrew Morton <akpm@linux-foundation.org >
Cc: Kuniyuki Iwashima <kuniyu@amazon.com >
Cc: Mateusz Guzik <mjguzik@gmail.com >
Cc: Steven Rostedt <rostedt@goodmis.org >
Cc: John Ogness <john.ogness@linutronix.de >
Cc: Sergey Senozhatsky <senozhatsky@chromium.org >
2025-05-08 16:13:27 -07:00
Paul E. McKenney
084a990ded
ratelimit: Allow zero ->burst to disable ratelimiting
...
If ->interval is zero, then rate-limiting will be disabled.
Alternatively, if interval is greater than zero and ->burst is zero,
then rate-limiting will be applied unconditionally. The point of this
distinction is to handle current users that pass zero-initialized
ratelimit_state structures to ___ratelimit(), and in such cases the
->lock field will be uninitialized. Acquiring ->lock in this case is
clearly not a strategy to win.
Therefore, make this classification be lockless.
Note that although negative ->interval and ->burst happen to be treated
as if they were zero, this is an accident of the current implementation.
The semantics of negative values for these fields is subject to change
without notice. Especially given that Bert Karwatzki determined that
no current calls to ___ratelimit() ever have negative values for these
fields.
This commit replaces an earlier buggy versions.
Link: https://lore.kernel.org/all/fbe93a52-365e-47fe-93a4-44a44547d601@paulmck-laptop/
Link: https://lore.kernel.org/all/20250423115409.3425-1-spasswolf@web.de/
Reported-by: Bert Karwatzki <spasswolf@web.de >
Reported-by: "Aithal, Srikanth" <sraithal@amd.com >
Closes: https://lore.kernel.org/all/20250423115409.3425-1-spasswolf@web.de/
Reported-by: Mark Brown <broonie@kernel.org >
Closes: https://lore.kernel.org/all/257c3b91-e30f-48be-9788-d27a4445a416@sirena.org.uk/
Signed-off-by: Paul E. McKenney <paulmck@kernel.org >
Tested-by: "Aithal, Srikanth" <sraithal@amd.com >
Reviewed-by: Petr Mladek <pmladek@suse.com >
Cc: Andrew Morton <akpm@linux-foundation.org >
Cc: Kuniyuki Iwashima <kuniyu@amazon.com >
Cc: Mateusz Guzik <mjguzik@gmail.com >
Cc: Steven Rostedt <rostedt@goodmis.org >
Cc: John Ogness <john.ogness@linutronix.de >
Cc: Sergey Senozhatsky <senozhatsky@chromium.org >
2025-05-08 16:13:27 -07:00
Petr Mladek and Paul E. McKenney
cf8cfa8a99
ratelimit: Reduce ___ratelimit() false-positive rate limiting
...
Retain the locked design, but check rate-limiting even when the lock
could not be acquired.
Link: https://lore.kernel.org/all/Z_VRo63o2UsVoxLG@pathway.suse.cz/
Link: https://lore.kernel.org/all/fbe93a52-365e-47fe-93a4-44a44547d601@paulmck-laptop/
Link: https://lore.kernel.org/all/20250423115409.3425-1-spasswolf@web.de/
Signed-off-by: Petr Mladek <pmladek@suse.com >
Signed-off-by: Paul E. McKenney <paulmck@kernel.org >
Cc: Petr Mladek <pmladek@suse.com >
Cc: Andrew Morton <akpm@linux-foundation.org >
Cc: Kuniyuki Iwashima <kuniyu@amazon.com >
Cc: Mateusz Guzik <mjguzik@gmail.com >
Cc: Steven Rostedt <rostedt@goodmis.org >
Cc: John Ogness <john.ogness@linutronix.de >
Cc: Sergey Senozhatsky <senozhatsky@chromium.org >
2025-05-08 16:13:27 -07:00
Paul E. McKenney
e64a348dc1
ratelimit: Avoid jiffies=0 special case
...
The ___ratelimit() function special-cases the jiffies-counter value of zero
as "uninitialized". This works well on 64-bit systems, where the jiffies
counter is not going to return to zero for more than half a billion years
on systems with HZ=1000, but similar 32-bit systems take less than 50 days
to wrap the jiffies counter. And although the consequences of wrapping the
jiffies counter seem to be limited to minor confusion on the duration of
the rate-limiting interval that happens to end at time zero, it is almost
no work to avoid this confusion.
Therefore, introduce a RATELIMIT_INITIALIZED bit to the ratelimit_state
structure's ->flags field so that a ->begin value of zero is no longer
special.
Link: https://lore.kernel.org/all/fbe93a52-365e-47fe-93a4-44a44547d601@paulmck-laptop/
Link: https://lore.kernel.org/all/20250423115409.3425-1-spasswolf@web.de/
Signed-off-by: Paul E. McKenney <paulmck@kernel.org >
Reviewed-by: Petr Mladek <pmladek@suse.com >
Cc: Andrew Morton <akpm@linux-foundation.org >
Cc: Kuniyuki Iwashima <kuniyu@amazon.com >
Cc: Mateusz Guzik <mjguzik@gmail.com >
Cc: Steven Rostedt <rostedt@goodmis.org >
Cc: John Ogness <john.ogness@linutronix.de >
Cc: Sergey Senozhatsky <senozhatsky@chromium.org >
2025-05-08 16:13:26 -07:00
Paul E. McKenney
d343732ddb
ratelimit: Count misses due to lock contention
...
The ___ratelimit() function simply returns zero ("do ratelimiting")
if the trylock fails, but does not adjust the ->missed field. This
means that the resulting dropped printk()s are dropped silently, which
could seriously confuse people trying to do console-log-based debugging.
Therefore, increment the ->missed field upon trylock failure.
Link: https://lore.kernel.org/all/fbe93a52-365e-47fe-93a4-44a44547d601@paulmck-laptop/
Link: https://lore.kernel.org/all/20250423115409.3425-1-spasswolf@web.de/
Signed-off-by: Paul E. McKenney <paulmck@kernel.org >
Reviewed-by: Petr Mladek <pmladek@suse.com >
Cc: Andrew Morton <akpm@linux-foundation.org >
Cc: Kuniyuki Iwashima <kuniyu@amazon.com >
Cc: Mateusz Guzik <mjguzik@gmail.com >
Cc: Steven Rostedt <rostedt@goodmis.org >
Cc: John Ogness <john.ogness@linutronix.de >
Cc: Sergey Senozhatsky <senozhatsky@chromium.org >
2025-05-08 16:13:26 -07:00
Paul E. McKenney
78bf44de47
ratelimit: Convert the ->missed field to atomic_t
...
The ratelimit_state structure's ->missed field is sometimes incremented
locklessly, and it would be good to avoid lost counts. This is also
needed to count the number of misses due to trylock failure. Therefore,
convert the ratelimit_state structure's ->missed field to atomic_t.
Link: https://lore.kernel.org/all/fbe93a52-365e-47fe-93a4-44a44547d601@paulmck-laptop/
Link: https://lore.kernel.org/all/20250423115409.3425-1-spasswolf@web.de/
Signed-off-by: Paul E. McKenney <paulmck@kernel.org >
Reviewed-by: Petr Mladek <pmladek@suse.com >
Cc: Andrew Morton <akpm@linux-foundation.org >
Cc: Kuniyuki Iwashima <kuniyu@amazon.com >
Cc: Mateusz Guzik <mjguzik@gmail.com >
Cc: Steven Rostedt <rostedt@goodmis.org >
Cc: John Ogness <john.ogness@linutronix.de >
Cc: Sergey Senozhatsky <senozhatsky@chromium.org >
2025-05-08 16:13:26 -07:00
Paul E. McKenney
56a7b9f8b0
ratelimit: Create functions to handle ratelimit_state internals
...
A number of ratelimit use cases do open-coded access to the
ratelimit_state structure's ->missed field. This works, but is a bit
messy and makes it more annoying to make changes to this field.
Therefore, provide a ratelimit_state_inc_miss() function that increments
the ->missed field, a ratelimit_state_get_miss() function that reads
out the ->missed field, and a ratelimit_state_reset_miss() function
that reads out that field, but that also resets its value to zero.
These functions will replace client-code open-coded uses of ->missed.
In addition, a new ratelimit_state_reset_interval() function encapsulates
what was previously open-coded lock acquisition and direct field updates.
[ paulmck: Apply kernel test robot feedback. ]
Link: https://lore.kernel.org/all/fbe93a52-365e-47fe-93a4-44a44547d601@paulmck-laptop/
Link: https://lore.kernel.org/all/20250423115409.3425-1-spasswolf@web.de/
Signed-off-by: Paul E. McKenney <paulmck@kernel.org >
Reviewed-by: Petr Mladek <pmladek@suse.com >
Cc: Andrew Morton <akpm@linux-foundation.org >
Cc: Kuniyuki Iwashima <kuniyu@amazon.com >
Cc: Mateusz Guzik <mjguzik@gmail.com >
Cc: Steven Rostedt <rostedt@goodmis.org >
Cc: John Ogness <john.ogness@linutronix.de >
Cc: Sergey Senozhatsky <senozhatsky@chromium.org >
2025-05-08 16:13:26 -07:00
Kuniyuki Iwashima and David S. Miller
6bae8ceb90
ratelimit: Fix data-races in ___ratelimit().
...
While reading rs->interval and rs->burst, they can be changed
concurrently via sysctl (e.g. net_ratelimit_state). Thus, we
need to add READ_ONCE() to their readers.
Fixes: 1da177e4c3kuniyu@amazon.com >
Signed-off-by: David S. Miller <davem@davemloft.net >
2022-08-24 13:46:57 +01:00
Thomas Gleixner and Greg Kroah-Hartman
55716d2643
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 428
...
Based on 1 normalized pattern(s):
this file is released under the gplv2
extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-only
has been chosen to replace the boilerplate/reference in 68 file(s).
Signed-off-by: Thomas Gleixner <tglx@linutronix.de >
Reviewed-by: Armijn Hemel <armijn@tjaldur.nl >
Reviewed-by: Allison Randal <allison@lohutok.net >
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190531190114.292346262@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2019-06-05 17:37:16 +02:00
Sergey Senozhatsky and Linus Torvalds
656d61ce96
lib/ratelimit.c: use deferred printk() version
...
printk_ratelimit() invokes ___ratelimit() which may invoke a normal
printk() (pr_warn() in this particular case) to warn about suppressed
output. Given that printk_ratelimit() may be called from anywhere, that
pr_warn() is dangerous - it may end up deadlocking the system. Fix
___ratelimit() by using deferred printk().
Sasha reported the following lockdep error:
: Unregister pv shared memory for cpu 8
: select_fallback_rq: 3 callbacks suppressed
: process 8583 (trinity-c78) no longer affine to cpu8
:
: ======================================================
: WARNING: possible circular locking dependency detected
: 4.14.0-rc2-next-20170927+ #252 Not tainted
: ------------------------------------------------------
: migration/8/62 is trying to acquire lock:
: (&port_lock_key){-.-.}, at: serial8250_console_write()
:
: but task is already holding lock:
: (&rq->lock){-.-.}, at: sched_cpu_dying()
:
: which lock already depends on the new lock.
:
:
: the existing dependency chain (in reverse order) is:
:
: -> #3 (&rq->lock){-.-.}:
: __lock_acquire()
: lock_acquire()
: _raw_spin_lock()
: task_fork_fair()
: sched_fork()
: copy_process.part.31()
: _do_fork()
: kernel_thread()
: rest_init()
: start_kernel()
: x86_64_start_reservations()
: x86_64_start_kernel()
: verify_cpu()
:
: -> #2 (&p->pi_lock){-.-.}:
: __lock_acquire()
: lock_acquire()
: _raw_spin_lock_irqsave()
: try_to_wake_up()
: default_wake_function()
: woken_wake_function()
: __wake_up_common()
: __wake_up_common_lock()
: __wake_up()
: tty_wakeup()
: tty_port_default_wakeup()
: tty_port_tty_wakeup()
: uart_write_wakeup()
: serial8250_tx_chars()
: serial8250_handle_irq.part.25()
: serial8250_default_handle_irq()
: serial8250_interrupt()
: __handle_irq_event_percpu()
: handle_irq_event_percpu()
: handle_irq_event()
: handle_level_irq()
: handle_irq()
: do_IRQ()
: ret_from_intr()
: native_safe_halt()
: default_idle()
: arch_cpu_idle()
: default_idle_call()
: do_idle()
: cpu_startup_entry()
: rest_init()
: start_kernel()
: x86_64_start_reservations()
: x86_64_start_kernel()
: verify_cpu()
:
: -> #1 (&tty->write_wait){-.-.}:
: __lock_acquire()
: lock_acquire()
: _raw_spin_lock_irqsave()
: __wake_up_common_lock()
: __wake_up()
: tty_wakeup()
: tty_port_default_wakeup()
: tty_port_tty_wakeup()
: uart_write_wakeup()
: serial8250_tx_chars()
: serial8250_handle_irq.part.25()
: serial8250_default_handle_irq()
: serial8250_interrupt()
: __handle_irq_event_percpu()
: handle_irq_event_percpu()
: handle_irq_event()
: handle_level_irq()
: handle_irq()
: do_IRQ()
: ret_from_intr()
: native_safe_halt()
: default_idle()
: arch_cpu_idle()
: default_idle_call()
: do_idle()
: cpu_startup_entry()
: rest_init()
: start_kernel()
: x86_64_start_reservations()
: x86_64_start_kernel()
: verify_cpu()
:
: -> #0 (&port_lock_key){-.-.}:
: check_prev_add()
: __lock_acquire()
: lock_acquire()
: _raw_spin_lock_irqsave()
: serial8250_console_write()
: univ8250_console_write()
: console_unlock()
: vprintk_emit()
: vprintk_default()
: vprintk_func()
: printk()
: ___ratelimit()
: __printk_ratelimit()
: select_fallback_rq()
: sched_cpu_dying()
: cpuhp_invoke_callback()
: take_cpu_down()
: multi_cpu_stop()
: cpu_stopper_thread()
: smpboot_thread_fn()
: kthread()
: ret_from_fork()
:
: other info that might help us debug this:
:
: Chain exists of:
: &port_lock_key --> &p->pi_lock --> &rq->lock
:
: Possible unsafe locking scenario:
:
: CPU0 CPU1
: ---- ----
: lock(&rq->lock);
: lock(&p->pi_lock);
: lock(&rq->lock);
: lock(&port_lock_key);
:
: *** DEADLOCK ***
:
: 4 locks held by migration/8/62:
: #0 : (&p->pi_lock){-.-.}, at: sched_cpu_dying()
: #1 : (&rq->lock){-.-.}, at: sched_cpu_dying()
: #2 : (printk_ratelimit_state.lock){....}, at: ___ratelimit()
: #3 : (console_lock){+.+.}, at: vprintk_emit()
:
: stack backtrace:
: CPU: 8 PID: 62 Comm: migration/8 Not tainted 4.14.0-rc2-next-20170927+ #252
: Call Trace:
: dump_stack()
: print_circular_bug()
: check_prev_add()
: ? add_lock_to_list.isra.26()
: ? check_usage()
: ? kvm_clock_read()
: ? kvm_sched_clock_read()
: ? sched_clock()
: ? check_preemption_disabled()
: __lock_acquire()
: ? __lock_acquire()
: ? add_lock_to_list.isra.26()
: ? debug_check_no_locks_freed()
: ? memcpy()
: lock_acquire()
: ? serial8250_console_write()
: _raw_spin_lock_irqsave()
: ? serial8250_console_write()
: serial8250_console_write()
: ? serial8250_start_tx()
: ? lock_acquire()
: ? memcpy()
: univ8250_console_write()
: console_unlock()
: ? __down_trylock_console_sem()
: vprintk_emit()
: vprintk_default()
: vprintk_func()
: printk()
: ? show_regs_print_info()
: ? lock_acquire()
: ___ratelimit()
: __printk_ratelimit()
: select_fallback_rq()
: sched_cpu_dying()
: ? sched_cpu_starting()
: ? rcutree_dying_cpu()
: ? sched_cpu_starting()
: cpuhp_invoke_callback()
: ? cpu_disable_common()
: take_cpu_down()
: ? trace_hardirqs_off_caller()
: ? cpuhp_invoke_callback()
: multi_cpu_stop()
: ? __this_cpu_preempt_check()
: ? cpu_stop_queue_work()
: cpu_stopper_thread()
: ? cpu_stop_create()
: smpboot_thread_fn()
: ? sort_range()
: ? schedule()
: ? __kthread_parkme()
: kthread()
: ? sort_range()
: ? kthread_create_on_node()
: ret_from_fork()
: process 9121 (trinity-c78) no longer affine to cpu8
: smpboot: CPU 8 is now offline
Link: http://lkml.kernel.org/r/20170928120405.18273-1-sergey.senozhatsky@gmail.com
Fixes: 6b1d174b0csergey.senozhatsky@gmail.com >
Reported-by: Sasha Levin <levinsasha928@gmail.com >
Reviewed-by: Petr Mladek <pmladek@suse.com >
Cc: Peter Zijlstra <peterz@infradead.org >
Cc: Thomas Gleixner <tglx@linutronix.de >
Cc: Ingo Molnar <mingo@elte.hu >
Cc: Borislav Petkov <bp@suse.de >
Cc: Steven Rostedt <rostedt@goodmis.org >
Cc: <stable@vger.kernel.org >
Signed-off-by: Andrew Morton <akpm@linux-foundation.org >
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org >
2017-10-03 17:54:26 -07:00
Borislav Petkov and Linus Torvalds
6b1d174b0c
ratelimit: extend to print suppressed messages on release
...
Extend the ratelimiting facility to print the amount of suppressed lines
when it is being released.
This use case is aimed at short-termed, burst-like users for which we
want to output the suppressed lines stats only once, after it has been
disposed of. For an example, see /dev/kmsg usage in a follow-on patch.
Also, change the printk() line we issue on release to not use
"callbacks" as it is misleading: we're not suppressing callbacks but
printk() calls.
This has been separated from a previous patch by Linus.
Link: http://lkml.kernel.org/r/20160716061745.15795-2-bp@alien8.de
Signed-off-by: Borislav Petkov <bp@suse.de >
Cc: Dave Young <dyoung@redhat.com >
Cc: Franck Bui <fbui@suse.com >
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
Cc: Ingo Molnar <mingo@kernel.org >
Cc: Linus Torvalds <torvalds@linux-foundation.org >
Cc: Peter Zijlstra <peterz@infradead.org >
Cc: Steven Rostedt <rostedt@goodmis.org >
Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de >
Signed-off-by: Andrew Morton <akpm@linux-foundation.org >
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org >
2016-08-02 19:35:06 -04:00
Jaewon Kim and Linus Torvalds
c2594bc37f
ratelimit: fix bug in time interval by resetting right begin time
...
rs->begin in ratelimit is set in two cases.
1) when rs->begin was not initialized
2) when rs->interval was passed
For case #2 , current ratelimit sets the begin to 0. This incurrs
improper suppression. The begin value will be set in the next ratelimit
call by 1). Then the time interval check will be always false, and
rs->printed will not be initialized. Although enough time passed,
ratelimit may return 0 if rs->printed is not less than rs->burst. To
reset interval properly, begin should be jiffies rather than 0.
For an example code below:
static DEFINE_RATELIMIT_STATE(mylimit, 1, 1);
for (i = 1; i <= 10; i++) {
if (__ratelimit(&mylimit))
printk("ratelimit test count %d\n", i);
msleep(3000);
}
test result in the current code shows suppression even there is 3 seconds sleep.
[ 78.391148] ratelimit test count 1
[ 81.295988] ratelimit test count 2
[ 87.315981] ratelimit test count 4
[ 93.336267] ratelimit test count 6
[ 99.356031] ratelimit test count 8
[ 105.376367] ratelimit test count 10
Signed-off-by: Jaewon Kim <jaewon31.kim@samsung.com >
Signed-off-by: Andrew Morton <akpm@linux-foundation.org >
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org >
2016-01-21 17:20:51 -08:00
Paul Gortmaker
8bc3bcc93a
lib: reduce the use of module.h wherever possible
...
For files only using THIS_MODULE and/or EXPORT_SYMBOL, map
them onto including export.h -- or if the file isn't even
using those, then just delete the include. Fix up any implicit
include dependencies that were being masked by module.h along
the way.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com >
2012-03-07 15:04:04 -05:00
Thomas Gleixner and Ingo Molnar
07354eb1a7
locking, printk: Annotate logbuf_lock as raw
...
The logbuf_lock lock can be taken in atomic context and therefore
cannot be preempted on -rt - annotate it.
In mainline this change documents the low level nature of
the lock - otherwise there's no functional difference. Lockdep
and Sparse checking will work as usual.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de >
[ merged and fixed it ]
Signed-off-by: Ingo Molnar <mingo@elte.hu >
2011-09-13 11:11:54 +02:00
Yong Zhang and Linus Torvalds
57119c34e5
ratelimit: fix the return value when __ratelimit() fails to acquire the lock
...
The log of commit edaac8e316yong.zhang@windriver.com >
Cc: Ingo Molnar <mingo@elte.hu >
Cc: Christian Borntraeger <borntraeger@de.ibm.com >
Signed-off-by: Andrew Morton <akpm@linux-foundation.org >
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org >
2010-04-07 08:38:04 -07:00
Chia-Liang WangandAndrew Morton
Paul E. McKenney
Petr MladekandPaul E. McKenney
Kuniyuki IwashimaandDavid S. Miller
Thomas GleixnerandGreg Kroah-Hartman
Sergey SenozhatskyandLinus Torvalds
Borislav PetkovandLinus Torvalds
Jaewon KimandLinus Torvalds
Paul Gortmaker
Yong ZhangandLinus Torvalds