e/kdump/gdbmacros.txt as well.
So perhaps while at it, we can also add here:
F: Documentation/admin-guide/kdump/gdbmacros.txt
John Ogness
- }
> + waitpid(pid, &status, 0);
> + ASSERT_TRUE(WIFSIGNALED(status));
> + ASSERT_TRUE(WCOREDUMP(status));
Why not just put these 3 lines above the for-loop? So you would wait for
the process to end, then go into the 20-second timeout loop waiting for
STACKDUMP_FILE to show up.
John Ogness
patch is good
enough. But we should probably excercise more precision in the use of
getline() so as to set a good example.
John Ogness
Hi David,
On 2024-11-22, David Gow wrote:
> It's a little unusual for a KUnit test -- particularly since it is
> time-based and uses lots of threads. This isn't a problem, but it's
> definitely a good thing that it's marked as slow. Additionally, KUnit
> doesn't track any extra threads spawned, s
From: Thomas Weißschuh
The KUnit test validates the correct operation of the ringbuffer.
A separate dedicated ringbuffer is used so that the global printk
ringbuffer is not touched.
Co-developed-by: John Ogness
Signed-off-by: John Ogness
Signed-off-by: Thomas Weißschuh
---
For those not
t; Signed-off-by: Nam Cao
Reviewed-by: John Ogness
ULL, it is safe to
> read ESP.
>
> Fixes: 92307383082d ("coredump: Don't perform any cleanups before dumping
> core")
> Signed-off-by: Nam Cao
Reviewed-by: John Ogness
ER#2"
> lock with interrupts disabled.
That seems to be one possible solution. But maybe there is reasoning why
that should not be done. (??) Right now it is clearly a spinlock that is
being taken from both interrupt and softirq contexts and does not
disable interrupts.
I will check if there is some previous kernel release where this problem
does not exist.
John Ogness
try to
squish CPU and Task IDs into 32 bits.
What about introducing a caller_id option to always only print the CPU
ID? Or do you really need Task _and_ CPU?
John Ogness
on, it still may
be desirable to specify the loglevel in the pr_cont pieces.
> pr_info("") will also prepend 'AMD-Vi:' to the feature list, which is
> nice.
I'd rather fix dev_info callers to allow pr_cont and then fix any code
that is using this workaround.
And if the print maintainers agree it is OK to encourage
pr_cont(LOGLEVEL "...") usage, then people should really start using
that if the loglevel on those pieces is important.
John Ogness
used also 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.
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;
()
register_console()
However, register_console() calls console_lock(), which might sleep.
So it has never been allowed to call register_console() from an
atomic context and the above call chain is a bug.
Signed-off-by: John Ogness
---
Note: The removal of read_syslog_seq_irq() is technically a small
step
eturn with a value of 0, never
having read _anything_.
By holding @syslog_lock between waking up and reading, it can be
guaranteed that SYSLOG_ACTION_READ blocks until it successfully
reads a syslog record (or a real error occurs).
Signed-off-by: John Ogness
---
kernel/printk/printk.c
-context.
Signed-off-by: John Ogness
---
kernel/printk/printk.c | 83 --
1 file changed, 80 insertions(+), 3 deletions(-)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 421c35571797..e971c0a9ec9e 100644
--- a/kernel/printk/printk.c
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:
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
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
On 2021-03-30, Petr Mladek wrote:
> On Tue 2021-03-23 15:42:01, Rasmus Villemoes wrote:
>> The printk code is already hard enough to understand. Remove an
>> unnecessary indirection by renaming vprintk_func to vprintk (adding
>> the asmlinkage annotation), and removing the vprintk definition from
On 2021-03-30, Petr Mladek wrote:
> On Sun 2021-03-28 10:09:32, Bhaskar Chowdhury wrote:
>>
>> s/sempahore/semaphore/
>> s/exacly/exactly/
>> s/unregistred/unregistered/
>> s/interation/iteration/
>>
>>
>> Signed-off-by: Bhaskar Chowdhury
>
> Reviewed-by: Petr Mladek
>
> John,
>
> it conflict
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
On 2021-03-23, Petr Mladek wrote:
> On Wed 2021-03-17 00:33:26, John Ogness wrote:
>> @syslog_log was a raw_spin_lock to simplify the transition of
>
> s/syslog_log/syslog_lock/
>
> Same problem is also below.
Right.
>> removing @logbuf_lock and the safe bu
interrupts
disabled. I should have just used local_irq_save().
I could add local_irq_save() to console_lock_spinning_enable() 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 Wed 2021-03-17 00:33:24, John Ogness wrote:
>> Track printk() recursion and limit it to 3 levels per-CPU and per-context.
>
> Please, explain why it is added. I mean that it will
> allow remove printk_safe that provides recursion protecti
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
is completely 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
I considered this, but am very hesitant to change the output
format. Also, the CUT_HERE usage (combined with PRINTK_CALLER) seem to
be enough.
John Ogness
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
Track printk() recursion and limit it to 3 levels per-CPU and per-context.
Signed-off-by: John Ogness
---
kernel/printk/printk.c | 80 --
1 file changed, 77 insertions(+), 3 deletions(-)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index
@syslog_log was a raw_spin_lock to simplify the transition of
removing @logbuf_lock and the safe buffers. With that transition
complete, @syslog_log can become a spin_lock.
Signed-off-by: John Ogness
---
kernel/printk/printk.c | 30 +++---
1 file changed, 15 insertions
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
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
Since the ringbuffer is lockless, there is no need for it to be
protected by @logbuf_lock. Remove @logbuf_lock.
@console_seq, @exclusive_console_stop_seq, @console_dropped are
protected by @console_lock.
Signed-off-by: John Ogness
Reviewed-by: Petr Mladek
---
kernel/printk/internal.h| 4
/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
. This simplifies the
transition to removing @logbuf_lock. Once @logbuf_lock and the
safe buffers are removed, @syslog_lock can change to spin_lock.
Signed-off-by: John Ogness
Reviewed-by: Petr Mladek
---
kernel/printk/printk.c | 41 +
1 file changed, 37
buf_lock writer-protection of
ringbuffer")
Signed-off-by: John Ogness
Reviewed-by: Petr Mladek
---
kernel/printk/printk.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 575a34b88936..77ae2704e979 100644
--- a/kernel/p
would be introduced. The MTD
kmsg_dumper may dump directly or it may be delayed (via scheduled
work). Depending on the context, different MTD callbacks are used.
For example, mtd_write() expects to be called in a non-atomic
context and may take a mutex.
Signed-off-by: John Ogness
Reviewed-by: Petr
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
The kmsg_dumper can be called from any context and CPU, possibly
from multiple CPUs simultaneously. Since a static buffer is used
to retrieve the kernel logs, this buffer must be protected against
simultaneous dumping. Skip dumping if another context is already
dumping.
Signed-off-by: John Ogness
The logic for finding records to fit into a buffer is the same for
kmsg_dump_get_buffer() and syslog_print_all(). Introduce a helper
function find_first_fitting_seq() to handle this logic.
Signed-off-by: John Ogness
Reviewed-by: Petr Mladek
---
kernel/printk/printk.c | 87
Instead of using "LOG_LINE_MAX + PREFIX_MAX" for temporary buffer
sizes, introduce CONSOLE_LOG_MAX. This represents the maximum size
that is allowed to be printed to the console for a single record.
Signed-off-by: John Ogness
---
kernel/printk/printk.c | 20
1 fi
struct kmsg_dumper still contains some fields that were used to
iterate the old ringbuffer. They are no longer used. Remove them
and update the struct documentation.
Signed-off-by: John Ogness
Reviewed-by: Petr Mladek
---
include/linux/kmsg_dump.h | 5 +++--
1 file changed, 3 insertions(+), 2
Upon registering a console, safe buffers are activated when setting
up the sequence number to replay the log. However, these are already
protected by @console_sem and @syslog_lock. Remove the unnecessary
safe buffer usage.
Signed-off-by: John Ogness
Reviewed-by: Petr Mladek
---
kernel/printk
@user->seq is indirectly protected by @logbuf_lock. Once @logbuf_lock
is removed, @user->seq will be no longer safe from an atomicity point
of view.
In preparation for the removal of @logbuf_lock, change it to
atomic64_t to provide this safety.
Signed-off-by: John Ogness
Reviewed-by
kmsg_dump_rewind_nolock() locklessly reads @clear_seq. However,
this is not done atomically. Since @clear_seq is 64-bit, this
cannot be an atomic operation for all platforms. Therefore, use
a seqcount_latch to allow readers to always read a consistent
value.
Signed-off-by: John Ogness
Reviewed
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
move this common logic into a
separate helper function.
Signed-off-by: John Ogness
Reviewed-by: Petr Mladek
---
include/linux/kmsg_dump.h | 2 +-
kernel/printk/printk.c| 62 +--
2 files changed, 34 insertions(+), 30 deletions(-)
diff --git a/include/linux
Hi Geert,
On 2021-03-02, Geert Uytterhoeven wrote:
> On Tue, Mar 2, 2021 at 2:54 PM Geert Uytterhoeven
> wrote:
>> On Thu, Feb 25, 2021 at 9:30 PM John Ogness
>> wrote:
>>> Instead of using "LOG_LINE_MAX + PREFIX_MAX" for temporary buffer
>>> siz
:
int i = 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
t does not
cause any scheduling or preemption side-effects for mtd. The mtd dumper
sometimes dumps directly, sometimes delayed (via scheduled work), and
they use different mtd callbacks in different contexts.
mtd_write() expects to be called in a non-atomic context. The callbacks
can take a mutex.
John Ogness
much.
> Well, the disabled irq might help to serialize the two calls when
> one is in normal context and the other would happen in IRQ one.
>
> As I said, using _irqsafe variant looks better to me.
For the record, the reason I removed the _irqsave for v3 is because I
felt like it was misleading, appearing to be necessary when it is not.
I think anyone could argue both sides. But it really doesn't matter
(especially for arch/um). I will use the _irqsave variant for v4. I am
OK with that.
John Ogness
e.
It looks like you have not applied the fix yet:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=08d60e5999540110576e7c1346d486220751b7f9
John Ogness
ether it is
>safe to do more dumps in parallel. Only the callback knows
>whether it is called only during panic() when no locks
>are needed.
Agreed. I implemented this part for the v3 series.
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
n sleep,
causing 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
Since the ringbuffer is lockless, there is no need for it to be
protected by @logbuf_lock. Remove @logbuf_lock.
@console_seq, @exclusive_console_stop_seq, @console_dropped are
protected by @console_lock.
Signed-off-by: John Ogness
---
kernel/printk/internal.h| 4 +-
kernel/printk
The logic for finding records to fit into a buffer is the same for
kmsg_dump_get_buffer() and syslog_print_all(). Introduce a helper
function find_first_fitting_seq() to handle this logic.
Signed-off-by: John Ogness
Reviewed-by: Petr Mladek
---
kernel/printk/printk.c | 87
. This simplifies the
transition to removing @logbuf_lock. Once @logbuf_lock and the
safe buffers are removed, @syslog_lock can change to spin_lock.
Signed-off-by: John Ogness
---
kernel/printk/printk.c | 41 +
1 file changed, 37 insertions(+), 4 deletions
increase it to 4096. With a larger buffer size, multi-line
records that are nearly LOG_LINE_MAX in length will have a better
chance of being fully printed. (When formatting a record for the
console, each line of a multi-line record is prepended with a copy
of the prefix.)
Signed-off-by: John Ognes
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_dump_rewind_nolock() locklessly reads @clear_seq. However,
this is not done atomically. Since @clear_seq is 64-bit, this
cannot be an atomic operation for all platforms. Therefore, use
a seqcount_latch to allow readers to always read a consistent
value.
Signed-off-by: John Ogness
Reviewed
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
Upon registering a console, safe buffers are activated when setting
up the sequence number to replay the log. However, these are already
protected by @console_sem and @syslog_lock. Remove the unnecessary
safe buffer usage.
Signed-off-by: John Ogness
Reviewed-by: Petr Mladek
---
kernel/printk
move this common logic into a
separate helper function.
Signed-off-by: John Ogness
Reviewed-by: Petr Mladek
---
include/linux/kmsg_dump.h | 2 +-
kernel/printk/printk.c| 62 +--
2 files changed, 34 insertions(+), 30 deletions(-)
diff --git a/include/linux
@user->seq is indirectly protected by @logbuf_lock. Once @logbuf_lock
is removed, @user->seq will be no longer safe from an atomicity point
of view.
In preparation for the removal of @logbuf_lock, change it to
atomic64_t to provide this safety.
Signed-off-by: John Ogness
Reviewed-by
buf_lock writer-protection of
ringbuffer")
Signed-off-by: John Ogness
Reviewed-by: Petr Mladek
---
kernel/printk/printk.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 575a34b88936..77ae2704e979 100644
--- a/kernel/p
pdate 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
The kmsg_dumper can be called from any context and CPU, possibly
from multiple CPUs simultaneously. Since a static buffer is used
to retrieve the kernel logs, this buffer must be protected against
simultaneous dumping. Skip dumping if another context is already
dumping.
Signed-off-by: John Ogness
. Release the
protection in between setting the buffer and the actual writing in
order for a possible panic (immediate write) to be written during
the scheduling of a previous oops (delayed write).
Signed-off-by: John Ogness
---
drivers/mtd/mtdoops.c | 12 +++-
1 file changed, 11 insertions
struct kmsg_dumper still contains some fields that were used to
iterate the old ringbuffer. They are no longer used. Remove them
and update the struct documentation.
Signed-off-by: John Ogness
Reviewed-by: Petr Mladek
---
include/linux/kmsg_dump.h | 5 +++--
1 file changed, 3 insertions(+), 2
On 2021-02-24, John Ogness wrote:
> The @active flag is useless. It should be removed.
I would like to clarify my statement, because the @active flag _did_
protect the arch/um dumper until now. (Although it didn't actually
matter because arch/um does not have SMP or preemption suppo
the useless @active flag, I am not sure what else
you would want to change. Perhaps just fixup the comments/documentation
to clarify these interfaces and what their purpose is.
John Ogness
is taken in IRQ context, we would
>>> need to safe flags.
>
> Note that console_lock was a spinlock in 2.3.15.pre1. I see it defined
> in kernel/printk.c as:
>
> spinlock_t console_lock = SPIN_LOCK_UNLOCKED;
>
> But it is a sleeping semaphore these days. As a result,
> register_console(), as it is now, must not be called in an interrupt
> context.
OK. So I will change read_syslog_seq_irq() to not disable interrupts. As
you suggested, we can fix the rest when we remove the safe buffers.
John Ogness
Added CC: linux-par...@vger.kernel.org
On 2021-02-19, John Ogness wrote:
>>> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
>>> index 20c21a25143d..401df370832b 100644
>>> --- a/kernel/printk/printk.c
>>> +++ b/kernel/printk/printk.c
>>>
that logbuf_lock_irqsave() should be replaced
with logbuf_lock_irq(). And then locking @syslog_lock will not need to
disable interrupts.
John Ogness
[0]
https://github.com/schwabe/davej-history/commit/f91c3404ba16c88cdb33824bf0249c6263cd4465#diff-84036d1e27f4207c783a3b876aef4e45340d30f43b1319bca382f5775a9b14beL348
.
Signed-off-by: John Ogness
---
arch/powerpc/kernel/nvram_64.c | 12 ++--
arch/powerpc/platforms/powernv/opal-kmsg.c | 3 +-
arch/powerpc/xmon/xmon.c | 6 +-
arch/um/kernel/kmsg_dump.c | 5 +-
drivers/hv/vmbus_drv.c | 5
buf_lock writer-protection of
ringbuffer")
Signed-off-by: John Ogness
---
kernel/printk/printk.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index c7239d169bbe..411787b900ac 100644
--- a/kernel/printk/printk.c
+++ b/ke
by @console_lock.
Signed-off-by: John Ogness
---
kernel/printk/internal.h| 4 +-
kernel/printk/printk.c | 116
kernel/printk/printk_safe.c | 29 +++--
3 files changed, 47 insertions(+), 102 deletions(-)
diff --git a/kernel/printk/internal.h b
Upon registering a console, safe buffers are activated when setting
up the sequence number to replay the log. However, these are already
protected by @console_sem and @syslog_lock. Remove the unnecessary
safe buffer usage.
Signed-off-by: John Ogness
---
kernel/printk/printk.c | 10 +++---
1
kmsg_dump() is open coding the kmsg_dump_rewind(). Call
kmsg_dump_rewind() instead.
Signed-off-by: John Ogness
---
kernel/printk/printk.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 744b806d5457..23d525e885e7
kmsg_dump_rewind_nolock() locklessly reads @clear_seq. However,
this is not done atomically. Since @clear_seq is 64-bit, this
cannot be an atomic operation for all platforms. Therefore, use
a seqcount_latch to allow readers to always read a consistent
value.
Signed-off-by: John Ogness
Reviewed
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
@user->seq is indirectly protected by @logbuf_lock. Once @logbuf_lock
is removed, @user->seq will be no longer safe from an atomicity point
of view.
In preparation for the removal of @logbuf_lock, change it to
atomic64_t to provide this safety.
Signed-off-by: John Ogness
---
kernel/
The kmsg_dumper can be called from any context and CPU, possibly
from multiple CPUs simultaneously. Since a static buffer is used
to retrieve the kernel logs, this buffer must be protected against
simultaneous dumping.
Cc: Richard Weinberger
Signed-off-by: John Ogness
Reviewed-by: Petr Mladek
move this common logic into a
separate helper function.
Signed-off-by: John Ogness
Reviewed-by: Petr Mladek
---
include/linux/kmsg_dump.h | 2 +-
kernel/printk/printk.c| 60 +--
2 files changed, 33 insertions(+), 29 deletions(-)
diff --git a/include/linux
struct kmsg_dumper still contains some fields that were used to
iterate the old ringbuffer. They are no longer used. Remove them
and update the struct documentation.
Signed-off-by: John Ogness
---
include/linux/kmsg_dump.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a
increase it to 4096. With a larger buffer size, multi-line
records that are nearly LOG_LINE_MAX in length will have a better
chance of being fully printed. (When formatting a record for the
console, each line of a multi-line record is prepended with a copy
of the prefix.)
Signed-off-by: John Ogness
ck" only change to safe buffer usage
- fixup safe buffer usage and redundance in separate patches
(patches 13 and 14)
- update comments and commit messages as requested
John Ogness
[0] https://lkml.kernel.org/r/20210126211551.26536-1-john.ogn...@linutronix.de
John Ogness (14):
printk:
. This simplifies the
transition to removing @logbuf_lock. Once @logbuf_lock and the
safe buffers are removed, @syslog_lock can change to spin_lock.
Signed-off-by: John Ogness
---
kernel/printk/printk.c | 41 +
1 file changed, 37 insertions(+), 4 deletions
The logic for finding records to fit into a buffer is the same for
kmsg_dump_get_buffer() and syslog_print_all(). Introduce a helper
function find_first_fitting_seq() to handle this logic.
Signed-off-by: John Ogness
---
kernel/printk/printk.c | 87 --
1
compact,
It is supported to provide loglevels for CONT messages. The loglevel is
then only used if the append fails:
pr_cont(KERN_INFO "message part");
I don't know if we want to go down that path. But it is supported.
John Ogness
() usage with prb_read_valid_*()
functions, which provide a start sequence number to search from.
Fixes: 896fbe20b4e2333fb55 ("printk: use the lockless ringbuffer")
Reported-by: kernel test robot
Reported-by: J. Avila
Signed-off-by: John Ogness
---
patch against next-20210211
v2: Abort and
* message it will notice and appropriately update
>* syslog_seq and reset syslog_partial.
>*/
> logbuf_unlock_irq();
> return 0;
> }
> if (info.seq != syslog_seq) {
> /* messages are gone, move to first one */
> syslog_seq = info.seq;
> syslog_partial = 0;
> }
John Ogness
On 2021-02-08, Sergey Senozhatsky wrote:
>> Can we please also ask the kernel test robot to test this patch?
Oliver Sang from LKP was able to verify that the RCU stall problem is
not seen anymore on their side. See his response below.
Thanks Oliver!
John Ogness
On 2021-02-10, Olive
of
verification.
@Avila: Can you also verify that this patch fixes your issue [0]?
John Ogness
[0] https://lkml.kernel.org/r/20210122235238.655049-1-elav...@google.com
() usage with prb_read_valid_*()
functions, which provide a start sequence number to search from.
Fixes: 896fbe20b4e2333fb55 ("printk: use the lockless ringbuffer")
Reported-by: kernel test robot
Reported-by: J. Avila
Signed-off-by: John Ogness
---
patch against next-20210205
kernel/print
the
current situation is not pretty, I do not think it needs to be rushed
for 5.11. It is an inefficiency that occurs if the average message size
greatly exceeds 32 bytes and the ringbuffer is being blasted by new
messages and userspace is reading the ringbuffer.
John Ogness
[0] https://lkml.ker
1 - 100 of 564 matches
Mail list logo
