On 2023-09-14, John Ogness wrote:
> Provide and use wrapper functions for spin_[un]lock*(port->lock)
> invocations so that the console mechanics can be applied later on at a
> single place and does not require to copy the same logic all over the
> drivers.
For the full 74-patch
On 2023-09-15, Ilpo Järvinen wrote:
> Would this also be useful to enable printing to console while under
> port's lock (by postponing the output until the lock is released)?
>
> E.g., 8250_dw.c has had this commented out since the dawn on time:
> /*
> * FIXME: this deadlocks if
On 2023-09-15, "Maciej W. Rozycki" wrote:
> Maybe dz.c shouldn't be touched by this series then?
Correct. This series is only wrapping the uart port lock, which dz.c is
not using.
> Though obviously both drivers will have to be eventually adapted for
> the ultimate console rework.
Correct.
When a serial port is used for kernel console output, then all
modifications to the UART registers which are done from other contexts,
e.g. getty, termios, are interference points for the kernel console.
So far this has been ignored and the printk output is based on the
principle of hope. The
From: Thomas Gleixner
When a serial port is used for kernel console output, then all
modifications to the UART registers which are done from other contexts,
e.g. getty, termios, are interference points for the kernel console.
So far this has been ignored and the printk output is based on the
From: Thomas Gleixner
When a serial port is used for kernel console output, then all
modifications to the UART registers which are done from other contexts,
e.g. getty, termios, are interference points for the kernel console.
So far this has been ignored and the printk output is based on the
Hi Michael,
On 2023-07-19, Michael Ellerman wrote:
> I regularly test with a gcc 5.5.0 / ld 2.29 toolchain and gcc 13.1.1 /
> ld 2.39, and I haven't seen the warning. I tried a bunch of others and
> can't reproduce it.
I will send my config in a separate email (without the lists in
CC).
h it
is a bit unusual to require such a modern toolchain in order to build a
kernel without warnings.
John Ogness
la.opd
and bisects to:
8ad57add77d3 ("powerpc/build: vdso linker warning for orphan sections")
Despite the warning, my ppc64 system seems to run fine. Let me know if
you need any other information from me.
I noticed [0] this with 6.5-rc1 but didn't contact the right people.
John O
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
Reviewed-by: Petr Mladek
---
drivers/tty/hvc/hvc_console.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
the console the
head of the console list.
John Ogness
[0]
https://lore.kernel.org/lkml/20221114162932.141883-1-john.ogn...@linutronix.de
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git/log/?h=srcunmisafe.2022.11.09a
John Ogness (38):
printk: Prepare for SRCU
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
Reviewed-by: Petr Mladek
---
drivers/tty/hvc/hvc_console.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
lso
take the console_lock to guarantee safe access to console->seq.
- In console_force_preferred_locked() use hlist_del_rcu() instead of
hlist_del_init_rcu() so that there is never a window where the
console can be viewed as unregistered.
John Ogness
[0]
https://lore.kernel.or
the enabled boot consoles
- add comments and lockdep assertion to
unregister_console_locked() because it is not clear from the
name which lock is implied
- dropped patches that caused unnecessary churn in the series
John Ogness
[0]
https://lore.kernel.org/lkml/20221019145600.1282823-1-john
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
---
drivers/tty/hvc/hvc_console.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/hvc/hvc_console.c b
fore adding
to list
- unregister_console: fix ENODEV return value if the console is
not registered
- console_stop: synchronize srcu
- printk_late_init: use _safe variant of iteration
- __pr_flush: use srcu instead of relying on console_lock for
list iteration
John Ogness
[0] https://lor
Replace (console->flags & CON_ENABLED) usage with console_is_enabled().
Signed-off-by: John Ogness
---
drivers/tty/hvc/hvc_console.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
index 4802cfaa107f..6d1d7
tchdog() <-- called from preemptible
Since watchdog_timer_interrupt() is called from irq context, I expect
that interrupts need to be disabled for the update in
arch_touch_nmi_watchdog(). Perhaps a using a per-cpu local_lock_t with
local_lock_irqsave() to protect write access to @wd_timer_tb?
John Ogness
On 2022-07-14, Zhouyi Zhou wrote:
> use raw_smp_processor_id() in arch_touch_nmi_watchdog
> because when called from watchdog, the cpu is preemptible.
I would expect the correct solution is to make it a non-migration
section. Something like the below (untested) patch.
John Ogness
diff
On 2022-05-10, Steven Rostedt wrote:
>> As already mentioned in the other reply, panic() sometimes stops the
>> other CPUs using NMI, for example, see kdump_nmi_shootdown_cpus().
>>
>> Another situation is when the CPU using the lock ends in some
>> infinite loop because something went wrong.
On 2021-08-04, Daniel Thompson wrote:
> On Wed, Aug 04, 2021 at 02:12:22PM +0200, Petr Mladek wrote:
>> On Wed 2021-08-04 12:31:59, Daniel Thompson wrote:
>> > On Tue, Aug 03, 2021 at 05:36:32PM +0206, John Ogness wrote:
>> > > On 2021-08-03, Daniel Thompson wrote:
ntk cpulock) for
synchronizing console output.
John Ogness
[0] https://lore.kernel.org/lkml/87k1acz5rx....@linutronix.de/
John Ogness (10):
printk: relocate printk cpulock functions
printk: rename printk cpulock API and always disable interrupts
kgdb: delay roundup if holding printk cpulock
On 2021-08-03, Daniel Thompson wrote:
> On Tue, Aug 03, 2021 at 03:18:54PM +0206, John Ogness wrote:
>> kgdb makes use of its own cpulock (@dbg_master_lock, @kgdb_active)
>> during cpu roundup. This will conflict with the printk cpulock.
>
> When the full vi
.
A new helper function kgdb_roundup_delay() is introduced for kgdb
to determine if it is holding the printk cpulock. If so, a flag is
set so that when the printk cpulock is released, kgdb will be
re-triggered for that CPU.
Signed-off-by: John Ogness
---
arch/powerpc/include/asm/smp.h | 1 +
arch
On 2021-07-21, Petr Mladek wrote:
> On Wed 2021-07-21 14:52:15, John Ogness wrote:
>> On 2021-07-21, Petr Mladek wrote:
>> >> --- a/kernel/trace/trace.c
>> >> +++ b/kernel/trace/trace.c
>> >> @@ -9647,7 +9647,7 @@ void ftrace_dump(enum ftrace_dump_mo
e.
For ftrace, remove general printk deferring. This general deferrment
was added in commit 03fc7f9c99c1 ("printk/nmi: Prevent deadlock when
accessing the main log buffer in NMI"), but really should have only
been deferred when in NMI context. Since vprintk() now checks for
NMI context when deciding to defer, ftrace does not need any special
handling.
Signed-off-by: John Ogness
and console_owner locks is left
in place. This is because the console and console_owner locks are
needed for the actual printing.
Signed-off-by: John Ogness
---
arch/powerpc/kernel/traps.c| 1 -
arch/powerpc/kernel/watchdog.c | 5 -
include/linux/printk.h | 10 -
kernel/kexec_core.c
to cause general printk
deferred printing:
arch/arm/kernel/smp.c
arch/powerpc/kexec/crash.c
kernel/trace/trace.c
For these users, provide a new function pair
printk_deferred_enter/exit that explicitly achieves the same
objective.
Signed-off-by: John Ogness
---
arch/arm/kernel/smp.c
to specify code block where all printk calls
are to be deferred printing.
John Ogness
[0] https://lore.kernel.org/lkml/2021062448.5190-1-john.ogn...@linutronix.de
John Ogness (6):
lib/nmi_backtrace: explicitly serialize banner and regs
printk: track/limit recursion
printk: remove safe buffers
nter_irqsave(flags) is not needed here. Any nested
> printk() ends here as well.
Ah, I missed that one. Good eye!
> Against this can be done in a separate patch. Well, the commit message
> mentions that the printk_safe context is removed everywhere except
> for the code manipulating console lock. But is it just a detail.
I would prefer a v4 with these fixes:
- wrap @console_owner_lock with printk_safe usage
- remove unnecessary printk_safe usage from printk_safe.c
- update commit message to say that safe context tracking is left in
place for both the console and console_owner locks
John Ogness
All NMI contexts are handled the same as the safe context: store the
message and defer printing. There is no need to have special NMI
context tracking for this. Using in_nmi() is enough.
Signed-off-by: John Ogness
Reviewed-by: Petr Mladek
---
arch/arm/kernel/smp.c | 2 --
arch/powerpc
in place. This is
because the console lock is needed for the actual printing.
Signed-off-by: John Ogness
---
arch/powerpc/kernel/traps.c| 1 -
arch/powerpc/kernel/watchdog.c | 5 -
include/linux/printk.h | 10 -
kernel/kexec_core.c| 1 -
kernel/panic.c
possible race conditions when printk's percpu
flag is set.
- Use the printk_cpu_lock to serialize banner and regs with
the stack dump in nmi_cpu_backtrace().
John Ogness
[0] https://lore.kernel.org/lkml/20210330153512.1182-1-john.ogn...@linutronix.de
John Ogness (6):
lib/nmi_backtrace
by atomic consoles.
>
> 3. Tell complaining people how to sort the messed logs.
Or we look into the long term solution now. If caller-id's cannot not be
used as the solution (because nobody turns it on, nobody knows about it,
and/or distros do not enable it), then we should look at how to make at
least the backtraces contiguous. I have a few ideas here.
John Ogness
-trigger" and this patchset:
Of course. Without caller-id, it is a mess. But this has nothing to do
with NMI. The same problem exists for WARN_ON() on multiple CPUs
simultaneously. If the user is not using caller-id, they are
lost. Caller-id is the current solution to the interlaced logs.
For the lo
On 2021-03-30, John Ogness wrote:
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index e971c0a9ec9e..f090d6a1b39e 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -1772,16 +1759,21 @@ static struct task_struct *console_owner;
k
- close the wait-read window for SYSLOG_ACTION_READ
- adjust various comments and commit messages as requested
John Ogness
[0]
https://lore.kernel.org/lkml/20210316233326.10778-1-john.ogn...@linutronix.de
John Ogness (5):
printk: track/limit recursion
printk: remove safe buffers
printk:
in place. This is
because the console lock is needed for the actual printing.
Signed-off-by: John Ogness
---
Note: The follow-up patch removes the NMI tracking.
arch/powerpc/kernel/traps.c| 1 -
arch/powerpc/kernel/watchdog.c | 5 -
include/linux/printk.h | 10 -
kernel
All NMI contexts are handled the same as the safe context: store the
message and defer printing. There is no need to have special NMI
context tracking for this. Using in_nmi() is enough.
Signed-off-by: John Ogness
---
arch/arm/kernel/smp.c | 2 --
arch/powerpc/kexec/crash.c | 3
On 2021-03-29, John Ogness wrote:
>> Will you call console write() callback with irq enabled from the
>> kthread?
>
> No. That defeats the fundamental purpose of this entire rework
> excercise. ;-)
Sorry, I misread your question. The answer is "yes". We want t
ats the fundamental purpose of this entire rework
excercise. ;-)
> Anyway, we should at least add a comment why the interrupts are
> disabled.
I decided to move the local_irq_save/restore inside the console-spinning
functions and added a comment for v2.
John Ogness
able() and
restore them at the end of console_lock_spinning_disable_and_check(),
but then I would need to add a @flags argument to both functions. I
think it is simpler to just do the disable/enable from the caller,
console_unlock().
BTW, I could not find any sane way of disabling interrupts via a
raw_spin_lock_irqsave() of @console_owner_lock because of the how it is
used with lockdep. In particular for
console_lock_spinning_disable_and_check().
John Ogness
On 2021-03-22, Petr Mladek wrote:
> On Mon 2021-03-22 12:16:15, John Ogness wrote:
>> On 2021-03-21, Sergey Senozhatsky wrote:
>> >> @@ -369,7 +70,10 @@ __printf(1, 0) int vprintk_func(const char *fmt,
>> >> va_list args)
>> >>* Use the main
mpletely removed. But I suppose I could switch
the 1 printk_nmi_direct_enter() user to printk_nmi_enter() so that
PRINTK_NMI_DIRECT_CONTEXT_MASK can be removed now. I would do this in a
4th patch of the series.
John Ogness
implemented for this series.
This series falls in line with the printk-rework plan as
presented [0] at Linux Plumbers in Lisbon 2019.
This series is based on next-20210316.
John Ogness
[0]
https://linuxplumbersconf.org/event/4/contributions/290/attachments/276/463/lpc2019_jogness_printk.pdf
(slide 23
in place. This is
because the console lock is needed for the actual printing.
Signed-off-by: John Ogness
---
arch/powerpc/kernel/traps.c| 1 -
arch/powerpc/kernel/watchdog.c | 5 -
include/linux/printk.h | 10 -
kernel/kexec_core.c| 1 -
kernel/panic.c
kmsg_dump_rewind() and kmsg_dump_get_line() are lockless, so there is
no need for _nolock() variants. Remove these functions and switch all
callers of the _nolock() variants.
The functions without _nolock() were chosen because they are already
exported to kernel modules.
Signed-off-by: John
the kmsg_dumper
structure to use the new kmsg_dump_iter structure. For kmsg_dumpers,
this also means adding a call to kmsg_dump_rewind() to initialize
the iterator.
All this is in preparation for removal of @logbuf_lock.
Signed-off-by: John Ogness
Reviewed-by: Kees Cook # pstore
---
arch/powerpc
/powerpc/platforms/powernv/opal-kmsg.c
- drivers/hv/vmbus_drv.c
The other 2 kmsg_dump users also do not rely on @active:
(hard-code @active to always be true)
- arch/powerpc/xmon/xmon.c
- kernel/debug/kdb/kdb_main.c
Therefore, @active can be removed.
Signed-off-by: John Ogness
Reviewed
object for
container_of() usage
- for kmsg_dump_get_line()/kmsg_dump_get_buffer() restrict the
minimal allowed sequence number to the cleared sequence number
John Ogness
[0]
https://lore.kernel.org/lkml/20210225202438.28985-1-john.ogn...@linutronix.de/
John Ogness (15):
um: synchronize
0;
...
for (; i < n; i++)
...;
Also, I do not really like the special use of 0/U64_MAX to identify
special actions of the kmsg_dump_get functions.
> Note that I do not resist on it. But it might make the API easier to
> use from my POV.
Since you do not resist, I will keep the API the same for v4. But I will
add the @clear_seq check to the kmsg_dump_get functions.
John Ogness
team. But most likely we will just
re-instate the dumper parameter in the callback.
I apologize for the lack of care on my part.
John Ogness
On 2021-02-26, kernel test robot wrote:
> Hi John,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on next-20
ing the system to hang. Convert the spinlock_t to the
non-sleeping raw_spinlock_t.
Signed-off-by: John Ogness
---
arch/powerpc/platforms/powermac/low_i2c.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/platforms/powermac/low_i2c.c
b/arch/powe
structure. For kmsg_dumpers, this also means adding a
call to kmsg_dump_rewind() to initialize the iterator.
All this is in preparation for removal of @logbuf_lock.
Signed-off-by: John Ogness
---
arch/powerpc/kernel/nvram_64.c | 14 +++---
arch/powerpc/platforms/powernv/opal-kmsg.c | 3
kmsg_dumpers to use their own kmsg_dump_iter (and
initialize it with kmsg_dump_rewind() if necessary)
John Ogness
[0] https://lkml.kernel.org/r/20210218081817.28849-1-john.ogn...@linutronix.de
[1] https://lkml.kernel.org/r/YDeZAA08NKCHa4s%2F@alley
John Ogness (15):
um: synchronize kmsg_dumper
mtd
kmsg_dump_rewind() and kmsg_dump_get_line() are lockless, so there is
no need for _nolock() variants. Remove these functions and switch all
callers of the _nolock() variants.
The functions without _nolock() were chosen because they are already
exported to kernel modules.
Signed-off-by: John
/powerpc/platforms/powernv/opal-kmsg.c
- drivers/hv/vmbus_drv.c
The other 2 kmsg_dump users also do not rely on @active:
(hard-code @active to always be true)
- arch/powerpc/xmon/xmon.c
- kernel/debug/kdb/kdb_main.c
Therefore, @active can be removed.
Signed-off-by: John Ogness
---
arch
On PPC32, reserve_hugetlb_gpages() is already called in MMU_init().
Signed-off-by: John Ogness <john.ogn...@linutronix.de>
---
arch/powerpc/kernel/setup-common.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/powerpc/kernel/setup-common.c
b/arch/powerpc/kernel/setup-co
g a cyclic task. With that
simple example you have complete control over the context of your
task. This is necessary to avoid things like priority inversion and
page-faults, and gives you control over things like affinity or cgroups.
John Ogness
[0]
https://wiki.linuxfoundation.org/realtime/documentation/howto/applications/cyclic
The xmon and cascade irq handlers must not run as threads.
pmac_pic_lock is already a raw_spinlock, but the irq flag
IRQF_NO_THREAD needs to be set as well.
Signed-off-by: John Ogness <john.ogn...@linutronix.de>
---
arch/powerpc/platforms/powermac/pic.c |3 ++-
1 file changed, 2 inse
Since gpio1 is not a timer, it also should not use IRQF_TIMER.
Similar to commit ba461f094bab ("powerpc: Use IRQF_NO_SUSPEND not
IRQF_TIMER for non-timer interrupts").
Signed-off-by: John Ogness <john.ogn...@linutronix.de>
---
drivers/macintosh/via-pmu.c |5 +++--
1
This driver provides UIO access to memory of a peripheral connected
to the Freescale enhanced local bus controller (eLBC) interface
using the general purpose chip-select mode (GPCM).
Signed-off-by: John Ogness john.ogn...@linutronix.de
---
There are currently drivers that use FCM and UPM modes
62 matches
Mail list logo
