- 16 Jan, 2023 2 commits
-
-
Anuradha Weeraman authored
Fix W=1 kernel-doc warning: kernel/printk/printk.c: - Include function parameter in console_lock_spinning_disable_and_check() Signed-off-by:
Anuradha Weeraman <anuradha@debian.org> Reviewed-by:
Petr Mladek <pmladek@suse.com> Signed-off-by:
-
John Ogness authored
Several mutexes are taken while setting up console serial ports. In particular, the tty_port->mutex and @console_mutex are taken: serial_pnp_probe serial8250_register_8250_port uart_add_one_port (locks tty_port->mutex) uart_configure_port register_console (locks @console_mutex) In order to synchronize kgdb's tty_find_polling_driver() with register_console(), commit 6193bc90 ("tty: serial: kgdboc: synchronize tty_find_polling_driver() and register_console()") takes the @console_mutex. However, this leads to the following call chain (with locking): platform_probe kgdboc_probe configure_kgdboc (locks @console_mutex) tty_find_polling_driver uart_poll_init (locks tty_port->mutex) uart_set_options This is clearly deadlock potential due to the reverse lock ordering. Since uart_set_options() requires holding @console_mutex in order to serialize early initialization of the serial-console lock, take the @console_mutex in uart_poll_init() instead of configure_kgdboc(). Since configure_kgdboc() was using @console_mutex for safe traversal of the console list, change it to use the SRCU iterator instead. Add comments to uart_set_options() kerneldoc mentioning that it requires holding @console_mutex (aka the console_list_lock). Fixes: 6193bc90 ("tty: serial: kgdboc: synchronize tty_find_polling_driver() and register_console()") Signed-off-by:John Ogness <john.ogness@linutronix.de> Reviewed-by:
Sergey Senozhatsky <senozhatsky@chromium.org> Reviewed-by:
-
- 02 Dec, 2022 38 commits
-
-
John Ogness authored
Variable and return descriptions were missing from the SRCU read lock functions. Add them. Signed-off-by:
-
John Ogness authored
When setting up the early console, the setup() callback of the regular console is used. It is called manually before registering the early console instead of providing a setup() callback for the early console. This is probably because the early setup needs a different @options during the early stage. The issue here is that the setup() callback is called without the console_list_lock held and functions such as uart_set_options() expect that. Rather than manually calling the setup() function before registering, provide an early console setup() callback that will use the different early options. This ensures that the error checking, ordering, and locking context when setting up the early console are correct. Since this early console can only be registered via the earlyprintk= parameter, the @options argument of the setup() callback will always be NULL. Rather than simply ignoring the argument, add a WARN_ON() to get our attention in case the setup() callback semantics should change in the future. Note that technically the current implementation works because it is only used in early boot. And since the early console setup is performed before registering, it cannot race with anything and thus does not need any locking. However, longterm maintenance is easier when drivers rely on the subsystem API rather than manually implementing steps that could cause breakage in the future. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by:
-
John Ogness authored
The console_list_lock provides synchronization for console list and console->flags updates. All call sites that were using the console_lock for this synchronization have either switched to use the console_list_lock or the SRCU list iterator. Remove console_lock usage for console list updates and console->flags updates. Signed-off-by:
-
John Ogness authored
kgdboc_earlycon_init() uses the console_lock to ensure that no consoles are unregistered until the kgdboc_earlycon is setup. The console_list_lock should be used instead because list synchronization responsibility will be removed from the console_lock in a later change. Signed-off-by:
Daniel Thompson <daniel.thompson@linaro.org> Reviewed-by:
-
John Ogness authored
Calling tty_find_polling_driver() can lead to uart_set_options() being called (via the poll_init() callback of tty_operations) to configure the uart. But uart_set_options() can also be called by register_console() (via the setup() callback of console). Take the console_list_lock to synchronize against register_console() and also use it for console list traversal. This also ensures the console list cannot change until the polling console has been chosen. Signed-off-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
-
John Ogness authored
configure_kgdboc() uses the console_lock for console list iteration. Use the console_list_lock instead because list synchronization responsibility will be removed from the console_lock in a later change. The SRCU iterator could have been used here, but a later change will relocate the locking of the console_list_lock to also provide synchronization against register_console(). Note, the console_lock is still needed to serialize the device() callback with other console operations. Signed-off-by:
-
John Ogness authored
Use srcu console list iteration for safe console list traversal. Note that this is a preparatory change for when console_lock no longer provides synchronization for the console list. Signed-off-by:
-
John Ogness authored
The console_lock is used in part to guarantee safe list iteration. The console_list_lock should be used because list synchronization responsibility will be removed from the console_lock in a later change. Note, the console_lock is still needed to serialize the device() callback with other console operations. Signed-off-by:
-
John Ogness authored
show_cons_active() uses the console_lock to gather information on registered consoles. It requires that no consoles are unregistered until it is finished. The console_list_lock should be used because list synchronization responsibility will be removed from the console_lock in a later change. Note, the console_lock is still needed to serialize the device() callback with other console operations. Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by:
-
John Ogness authored
With commit 9e124fe1("xen: Enable console tty by default in domU if it's not a dummy") a hack was implemented to make sure that the tty console remains the console behind the /dev/console device. The main problem with the hack is that, after getting the console pointer to the tty console, it is assumed the pointer is still valid after releasing the console_sem. This assumption is incorrect and unsafe. Make the hack safe by introducing a new function console_force_preferred_locked() and perform the full operation under the console_list_lock. Signed-off-by:
-
John Ogness authored
The CON_ENABLED flag is being misused to track whether or not the extended console should be or has been registered. Instead use a local variable to decide if the extended console should be registered and console_is_registered() to determine if it has been registered. Also add a check in cleanup_netconsole() to only unregister the extended console if it has been registered. Signed-off-by:
-
John Ogness authored
It is not reliable to check for CON_ENABLED in order to identify if a console is registered. Use console_is_registered() instead. Signed-off-by:
-
John Ogness authored
It is not reliable to check for CON_ENABLED in order to identify if a console is registered. Use console_is_registered() instead. Signed-off-by:
-
John Ogness authored
It is not reliable to check for CON_ENABLED in order to identify if a console is registered. Use console_is_registered() instead. Signed-off-by:
-
John Ogness authored
It is not reliable to check for CON_ENABLED in order to identify if a console is registered. Use console_is_registered() instead. Signed-off-by:
-
John Ogness authored
It is not reliable to check for CON_ENABLED in order to identify if a console is registered. Use console_is_registered() instead. Signed-off-by:
-
John Ogness authored
It is not reliable to check for CON_ENABLED in order to identify if a console is registered. Use console_is_registered() instead. Signed-off-by:
-
John Ogness authored
The CON_ENABLED status of a console is a runtime setting that does not involve the console driver. Drivers must not assume that if the console is disabled then proper hardware management is not needed. For the EFI earlycon case, it is about remapping/unmapping memory for the framebuffer. Use console_is_registered() instead of checking CON_ENABLED. Signed-off-by:
-
John Ogness authored
Currently CON_ENABLED is being (mis)used to identify if the console has been registered. This is not reliable because it can be set even though registration failed or it can be unset, even though the console is registered. Use console_is_registered() instead. Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Acked-by:
-
John Ogness authored
All users of uart_console_enabled() really want to know if a console is registered. It is not reliable to check for CON_ENABLED in order to identify if a console is registered. Use console_is_registered() instead. A _locked() variant is provided because uart_set_options() is always called with the console_list_lock held and must check if a console is registered in order to synchronize with kgdboc. Signed-off-by:
-
John Ogness authored
Currently it is not possible for drivers to detect if they have already successfully registered their console. Several drivers have multiple paths that lead to console registration. To avoid attempting a 2nd registration (which leads to a WARN), drivers are implementing their own solution. Introduce console_is_registered() so drivers can easily identify if their console is currently registered. A _locked() variant is also provided if the caller is already holding the console_list_lock. Signed-off-by:
-
John Ogness authored
Use srcu console list iteration for console list traversal. It is acceptable because the consoles might come and go at any time. Strict synchronizing with console registration code would not bring any advantage over srcu. Document why the console_lock is still necessary. Note that this is a preparatory change for when console_lock no longer provides synchronization for the console list. Signed-off-by:
-
John Ogness authored
With SRCU it is now safe to traverse the console list, even if the console_trylock() failed. However, overwriting console->seq when console_trylock() failed is still an issue. Switch to SRCU iteration and document remaining issue with console->seq. Signed-off-by:
-
John Ogness authored
Use srcu console list iteration for console list traversal. Document why the console_lock is still necessary. Note that this is a preparatory change for when console_lock no longer provides synchronization for the console list. Signed-off-by:
-
John Ogness authored
All users of console_is_usable() are SRCU iterators. Use the appropriate wrapper function to locklessly read the flags. Signed-off-by:
-
John Ogness authored
Use srcu console list iteration for console list traversal. Document why the console_lock is still necessary. Note that this is a preparatory change for when console_lock no longer provides synchronization for the console list. Signed-off-by:
-
John Ogness authored
Guarantee safe iteration of the console list by using SRCU. Note that in the case of a handover, the SRCU read lock is also released. This is documented in the function description and as comments in the code. It is a bit tricky, but this preserves the lockdep lock ordering for the context handing over the console_lock: console_lock() | mutex_acquire(&console_lock_dep_map) <-- console lock | console_unlock() | console_flush_all() | | srcu_read_lock(&console_srcu) <-- srcu lock | | console_emit_next_record() | | | console_lock_spinning_disable_and_check() | | | | srcu_read_unlock(&console_srcu) <-- srcu unlock | | | | mutex_release(&console_lock_dep_map) <-- console unlock Signed-off-by:
-
John Ogness authored
Guarantee safe iteration of the console list by using SRCU. Signed-off-by:
Aaron Tomlin <atomlin@atomlin.com> Reviewed-by:
-
John Ogness authored
Rather than using the console_lock to guarantee safe console list traversal, use srcu console list iteration. Signed-off-by:
-
John Ogness authored
After switching to SRCU for console list iteration, some readers will begin readings console->flags as a data race. Locklessly reading console->flags provides a consistent value because there is at most one CPU modifying console->flags and that CPU is using only read-modify-write operations. Introduce a wrapper for SRCU iterators to read console flags. Introduce a matching wrapper to write to flags of registered consoles. Writing to flags of registered consoles is synchronized by the console_list_lock. Signed-off-by:
-
John Ogness authored
Currently there exist races in register_console(), where the types of registered consoles are checked (without holding the console_lock) and then after acquiring the console_lock, it is assumed that the list has not changed. Also, some code that performs console_unregister() make similar assumptions. It might be possible to fix these races using the console_lock. But it would require a complex analysis of all console drivers to make sure that the console_lock is not taken in match() and setup() callbacks. And we really prefer to split up and reduce the responsibilities of console_lock rather than expand its complexity. Therefore, introduce a new console_list_lock to provide full synchronization for any console list changes. In addition, also use console_list_lock for synchronization of console->flags updates. All flags are either static or modified only during the console registration. There are only two exceptions. The first exception is CON_ENABLED, which is also modified by console_start()/console_stop(). Therefore, these functions must also take the console_list_lock. The second exception is when the flags are modified by the console driver init code before the console is registered. These will be ignored because they are not visible to the rest of the system via the console_drivers list. Note that one of the various responsibilities of the console_lock is also intended to provide console list and console->flags synchronization. Later changes will update call sites relying on the console_lock for these purposes. Once all call sites have been updated, the console_lock will be relieved of synchronizing console_list and console->flags updates. Suggested-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
John Ogness authored
The console_lock is held throughout the start/show/stop procedure to print out device/driver information about all registered consoles. Since the console_lock is being used for multiple reasons, explicitly document these reasons. This will be useful when the console_lock is split into fine-grained locking. Signed-off-by:
-
John Ogness authored
show_cons_active() uses the console_lock to gather information on registered consoles. Since the console_lock is being used for multiple reasons, explicitly document these reasons. This will be useful when the console_lock is split into fine-grained locking. Signed-off-by:
-
John Ogness authored
kgdboc_earlycon_init() uses the console_lock to ensure that no consoles are unregistered until the kgdboc_earlycon is setup. This is necessary because the trapping of the exit() callback assumes that the exit() callback is not called before the trap is setup. Explicitly document this non-typical console_lock usage. Signed-off-by:
-
John Ogness authored
The initial intention of the UML kmsg_dumper is to dump the kernel buffers to stdout if there is no console available to perform the regular crash output. However, if ttynull was registered as a console, no crash output was seen. Commit e23fe90d ("um: kmsg_dumper: always dump when not tty console") tried to fix this by performing the kmsg_dump unless the stdio console was behind /dev/console or enabled. But this allowed kmsg dumping to occur even if other non-stdio consoles will output the crash output. Also, a console being the driver behind /dev/console has nothing to do with a crash scenario. Restore the initial intention by dumping the kernel buffers to stdout only if a non-ttynull console is registered and enabled. Also add detailed comments so that it is clear why these rules are applied. Signed-off-by:
-
John Ogness authored
It used to be that all consoles were synchronized with respect to which message they were printing. After commit a699449b ("printk: refactor and rework printing logic"), all consoles have their own @seq for tracking which message they are on. That commit also changed how the initial sequence number was chosen. Instead of choosing the next non-printed message, it chose the sequence number of the next message that will be added to the ringbuffer. That change created a possibility that a non-boot console taking over for a boot console might skip messages if the boot console was behind and did not have a chance to catch up before being unregistered. Since it is not known which boot console is the same device, flush all consoles and, if necessary, start with the message of the enabled boot console that is the furthest behind. If no boot consoles are enabled, begin with the next message that will be added to the ringbuffer. Also, since boot consoles are meant to be used at boot time, handle them the same as CON_PRINTBUFFER to ensure that no initial messages are skipped. Signed-off-by:
-
John Ogness authored
The code to initialize @seq for a new console needs to consider more factors when choosing an initial value. Move the code into a helper function console_init_seq() "as is" so this code can be expanded without causing register_console() to become too long. A later commit will implement the additional code. Signed-off-by:
-
John Ogness authored
The @bootcon_enabled and @realcon_enabled local variables actually represent if such console types are registered. In general there has been a confusion about enabled vs. registered. Incorrectly naming such variables promotes such confusion. Rename the variables to _registered. Signed-off-by:
-
