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
n 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
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;
()
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
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 | 50
-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:
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-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
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
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 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
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
m 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
will 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
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
.
> 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
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
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
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
will 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
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
. 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
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
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 supp
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
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
>>>
e sparc64 was regstering its console in a PROM
callback (the comments there: "Pretty sick eh?").
Today sparc64 is setting up the console in init code. I suppose I need
to go through all the console drivers to see if any register in
interrupt context. If not, that logbuf_lock_irqsave() should be
.
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
@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/
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
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
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
will 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
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):
print
. 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
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
t 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
ort 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
e
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.kernel.org/r/202
something like:
dmesg > /tmpfile
cat /tmpfile > /dev/kmsg
to avoid the endless read/feed cycle.
John Ogness
On 2021-02-02, Petr Mladek wrote:
> On Tue 2021-01-26 22:21:50, John Ogness wrote:
>> Since the ringbuffer is lockless, there is no need for it to be
>> protected by @logbuf_lock. Remove @logbuf_lock.
>>
>> This means that printk_nmi_direct and printk_safe_flush_o
mit d43ff430f434
("printk: guard the amount written per line by devkmsg_read()") show any
motivation for using printk.h.
I am fine with moving them out. The only consequences could be
out-of-tree modules breaking, but do we care about that?
John Ogness
[0] https://lkml.kernel.org/r/202101262
ng some
Kconfig settings from that subsystem. Headers exist to make information
available to external code. Kconfig (particularly for a subsystem) exist
to configure that subsystem.
But my feeling on this may be misguided. Is it generally accepted in the
kernel that any code can use Kconfig settings of any other code?
John Ogness
synchronize the
>>>> kmsg_dump call and temporary buffer usage.
>>>>
>>>> Signed-off-by: John Ogness
>>>> ---
>>>> arch/um/kernel/kmsg_dump.c | 8
>>>> 1 file changed, 8 insertions(+)
>>>>
>>>>
ock to synchronize the
>> kmsg_dump call and temporary buffer usage.
>>
>> Signed-off-by: John Ogness
>> ---
>> arch/um/kernel/kmsg_dump.c | 8
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/arch/um/kernel/kmsg_dump.c b/arch/um/kernel/kmsg_
On 2021-02-01, Petr Mladek wrote:
>> Rather than store the iterator information into the registered
>> kmsg_dump structure, create a separate iterator structure. The
>> kmsg_dump_iter structure can reside on the stack of the caller,
>> thus allowing lockless use of the kmsg_dump functions.
>>
>>
flags;
raw_spin_lock_irqsave(_lock, flags);
seq = syslog_seq;
raw_spin_unlock_irqrestore(_lock, flags);
return seq;
}
Then change the code to:
error = wait_event_interruptible(log_wait,
prb_read_valid(prb, read_syslog_seq(), NULL));
register_console() could also make use of the function. (That is why I
am suggesting the flags variant.)
John Ogness
1 - 100 of 621 matches
Mail list logo
