printk/panic: Add option to allow non-panic CPUs to write to the ring buffer.

Commit 779dbc2e78d7 ("printk: Avoid non-panic CPUs writing to ringbuffer")
aimed to isolate panic-related messages. Howe

printk/panic: Add option to allow non-panic CPUs to write to the ring buffer.

Commit 779dbc2e78d7 ("printk: Avoid non-panic CPUs writing to ringbuffer")
aimed to isolate panic-related messages. However, when panic() itself
malfunctions, messages from non-panic CPUs become crucial for debugging.

While commit bcc954c6caba ("printk/panic: Allow cpu backtraces to
be written into ringbuffer during panic") enables non-panic CPU
backtraces, it may not provide sufficient diagnostic information.

Introduce the "debug_non_panic_cpus" command-line option, enabling
non-panic CPU messages to be stored in the ring buffer during a panic.
This also prevents discarding non-finalized messages from non-panic CPUs
during console flushing, providing a more comprehensive view of system
state during critical failures.

Link: https://lore.kernel.org/all/Z8cLEkqLL2IOyNIj@pathway/
Signed-off-by: Donghyeok Choe <[email protected]>
Reviewed-by: Petr Mladek <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[[email protected]: Added documentation, added module_parameter, removed printk_ prefix.]
Tested-by: Petr Mladek <[email protected]>
Signed-off-by: Petr Mladek <[email protected]>

show more ...

printk: ringbuffer: Skip non-finalized records in panic

Normally a reader will stop once reaching a non-finalized
record. However, when a panic happens, writers from other CPUs
(or an interrupted co

printk: ringbuffer: Skip non-finalized records in panic

Normally a reader will stop once reaching a non-finalized
record. However, when a panic happens, writers from other CPUs
(or an interrupted context on the panic CPU) may have been
writing a record and were unable to finalize it. The panic CPU
will reserve/commit/finalize its panic records, but these will
be located after the non-finalized records. This results in
panic() not flushing the panic messages.

Extend _prb_read_valid() to skip over non-finalized records if
on the panic CPU.

Fixes: 896fbe20b4e2 ("printk: use the lockless ringbuffer")
Signed-off-by: John Ogness <[email protected]>
Reviewed-by: Petr Mladek <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Petr Mladek <[email protected]>

show more ...

printk: Wait for all reserved records with pr_flush()

Currently pr_flush() will only wait for records that were
available to readers at the time of the call (using
prb_next_seq()). But there may be

printk: Wait for all reserved records with pr_flush()

Currently pr_flush() will only wait for records that were
available to readers at the time of the call (using
prb_next_seq()). But there may be more records (non-finalized)
that have following finalized records. pr_flush() should wait
for these to print as well. Particularly because any trailing
finalized records may be the messages that the calling context
wants to ensure are printed.

Add a new ringbuffer function prb_next_reserve_seq() to return
the sequence number following the most recently reserved record.
This guarantees that pr_flush() will wait until all current
printk() messages (completed or in progress) have been printed.

Fixes: 3b604ca81202 ("printk: add pr_flush()")
Signed-off-by: John Ogness <[email protected]>
Reviewed-by: Petr Mladek <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Petr Mladek <[email protected]>

show more ...

printk: ringbuffer: Cleanup reader terminology

With the lockless ringbuffer, it is allowed that multiple
CPUs/contexts write simultaneously into the buffer. This creates
an ambiguity as some writers

printk: ringbuffer: Cleanup reader terminology

With the lockless ringbuffer, it is allowed that multiple
CPUs/contexts write simultaneously into the buffer. This creates
an ambiguity as some writers will finalize sooner.

The documentation for the prb_read functions is not clear as it
refers to "not yet written" and "no data available". Clarify the
return values and language to be in terms of the reader: records
available for reading.

Signed-off-by: John Ogness <[email protected]>
Reviewed-by: Petr Mladek <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Petr Mladek <[email protected]>

show more ...

printk: ringbuffer: Clarify special lpos values

For empty line records, no data blocks are created. Instead,
these valid records are identified by special logical position
values (in fields of @prb_

printk: ringbuffer: Clarify special lpos values

For empty line records, no data blocks are created. Instead,
these valid records are identified by special logical position
values (in fields of @prb_desc.text_blk_lpos).

Currently the macro NO_LPOS is used for empty line records.
This name is confusing because it does not imply _why_ there is
no data block.

Rename NO_LPOS to EMPTY_LINE_LPOS so that it is clear why there
is no data block.

Also add comments explaining the use of EMPTY_LINE_LPOS as well
as clarification to the values used to represent data-less
blocks.

Signed-off-by: John Ogness <[email protected]>
Reviewed-by: Petr Mladek <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Petr Mladek <[email protected]>

show more ...

printk: ringbuffer: Do not skip non-finalized records with prb_next_seq()

Commit f244b4dc53e5 ("printk: ringbuffer: Improve
prb_next_seq() performance") introduced an optimization for
prb_next_seq()

printk: ringbuffer: Do not skip non-finalized records with prb_next_seq()

Commit f244b4dc53e5 ("printk: ringbuffer: Improve
prb_next_seq() performance") introduced an optimization for
prb_next_seq() by using best-effort to track recently finalized
records. However, the order of finalization does not
necessarily match the order of the records. The optimization
changed prb_next_seq() to return inconsistent results, possibly
yielding sequence numbers that are not available to readers
because they are preceded by non-finalized records or they are
not yet visible to the reader CPU.

Rather than simply best-effort tracking recently finalized
records, force the committing writer to read records and
increment the last "contiguous block" of finalized records. In
order to do this, the sequence number instead of ID must be
stored because ID's cannot be directly compared.

A new memory barrier pair is introduced to guarantee that a
reader can always read the records up until the sequence number
returned by prb_next_seq() (unless the records have since
been overwritten in the ringbuffer).

This restores the original functionality of prb_next_seq()
while also keeping the optimization.

For 32bit systems, only the lower 32 bits of the sequence
number are stored. When reading the value, it is expanded to
the full 64bit sequence number using the 32bit seq macros,
which fold in the value returned by prb_first_seq().

Fixes: f244b4dc53e5 ("printk: ringbuffer: Improve prb_next_seq() performance")
Signed-off-by: John Ogness <[email protected]>
Reviewed-by: Petr Mladek <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Petr Mladek <[email protected]>

show more ...

printk: Use prb_first_seq() as base for 32bit seq macros

Note: This change only applies to 32bit architectures. On 64bit
architectures the macros are NOPs.

Currently prb_next_seq() is used as

printk: Use prb_first_seq() as base for 32bit seq macros

Note: This change only applies to 32bit architectures. On 64bit
architectures the macros are NOPs.

Currently prb_next_seq() is used as the base for the 32bit seq
macros __u64seq_to_ulseq() and __ulseq_to_u64seq(). However, in
a follow-up commit, prb_next_seq() will need to make use of the
32bit seq macros.

Use prb_first_seq() as the base for the 32bit seq macros instead
because it is guaranteed to return 64bit sequence numbers without
relying on any 32bit seq macros.

Signed-off-by: John Ogness <[email protected]>
Reviewed-by: Petr Mladek <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Petr Mladek <[email protected]>

show more ...

printk: ringbuffer: Fix truncating buffer size min_t cast

If an output buffer size exceeded U16_MAX, the min_t(u16, ...) cast in
copy_data() was causing writes to truncate. This manifested as output

printk: ringbuffer: Fix truncating buffer size min_t cast

If an output buffer size exceeded U16_MAX, the min_t(u16, ...) cast in
copy_data() was causing writes to truncate. This manifested as output
bytes being skipped, seen as %NUL bytes in pstore dumps when the available
record size was larger than 65536. Fix the cast to no longer truncate
the calculation.

Cc: Petr Mladek <[email protected]>
Cc: Sergey Senozhatsky <[email protected]>
Cc: Steven Rostedt <[email protected]>
Cc: John Ogness <[email protected]>
Reported-by: Vijay Balakrishna <[email protected]>
Link: https://lore.kernel.org/lkml/[email protected]/
Fixes: b6cf8b3f3312 ("printk: add lockless ringbuffer")
Cc: [email protected]
Signed-off-by: Kees Cook <[email protected]>
Tested-by: Vijay Balakrishna <[email protected]>
Tested-by: Guilherme G. Piccoli <[email protected]> # Steam Deck
Reviewed-by: Tyler Hicks (Microsoft) <[email protected]>
Tested-by: Tyler Hicks (Microsoft) <[email protected]>
Reviewed-by: John Ogness <[email protected]>
Reviewed-by: Sergey Senozhatsky <[email protected]>
Reviewed-by: Petr Mladek <[email protected]>
Signed-off-by: Petr Mladek <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

printk: fix a typo of comment

Fix a typo of comment

Signed-off-by: Wang Honghui <[email protected]>
Reviewed-by: John Ogness <[email protected]>
Signed-off-by: Petr Mladek <pmladek@s

printk: fix a typo of comment

Fix a typo of comment

Signed-off-by: Wang Honghui <[email protected]>
Reviewed-by: John Ogness <[email protected]>
Signed-off-by: Petr Mladek <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Link: https://lore.kernel.org/r/[email protected]

show more ...

printk: ringbuffer: Improve prb_next_seq() performance

prb_next_seq() always iterates from the first known sequence number.
In the worst case, it might loop 8k times for 256kB buffer,
15k times for

printk: ringbuffer: Improve prb_next_seq() performance

prb_next_seq() always iterates from the first known sequence number.
In the worst case, it might loop 8k times for 256kB buffer,
15k times for 512kB buffer, and 64k times for 2MB buffer.

It was reported that polling and reading using syslog interface
might occupy 50% of CPU.

Speedup the search by storing @id of the last finalized descriptor.

The loop is still needed because the @id is stored and read in the best
effort way. An atomic variable is used to keep the @id consistent.
But the stores and reads are not serialized against each other.
The descriptor could get reused in the meantime. The related sequence
number will be used only when it is still valid.

An invalid value should be read _only_ when there is a flood of messages
and the ringbuffer is rapidly reused. The performance is the least
problem in this case.

Reported-by: Chunlei Wang <[email protected]>
Signed-off-by: Mukesh Ojha <[email protected]>
Reviewed-by: John Ogness <[email protected]>
Signed-off-by: Petr Mladek <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Link: https://lore.kernel.org/lkml/YXlddJxLh77DKfIO@alley/T/#m43062e8b2a17f8dbc8c6ccdb8851fb0dbaabbb14

show more ...

printk: ringbuffer: fix line counting

Counting text lines in a record simply involves counting the number
of newline characters (+1). However, it is searching the full data
block for newline charact

printk: ringbuffer: fix line counting

Counting text lines in a record simply involves counting the number
of newline characters (+1). However, it is searching the full data
block for newline characters, even though the text data can be (and
often is) a subset of that area. Since the extra area in the data
block was never initialized, the result is that extra newlines may
be seen and counted.

Restrict newline searching to the text data length.

Fixes: b6cf8b3f3312 ("printk: add lockless ringbuffer")
Signed-off-by: John Ogness <[email protected]>
Reviewed-by: Petr Mladek <[email protected]>
Acked-by: Sergey Senozhatsky <[email protected]>
Signed-off-by: Petr Mladek <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

printk: ringbuffer: Reference text_data_ring directly in callees.

A bunch of functions in the new ringbuffer code take both a
printk_ringbuffer struct and a separate prb_data_ring. This is a relic
f

printk: ringbuffer: Reference text_data_ring directly in callees.

A bunch of functions in the new ringbuffer code take both a
printk_ringbuffer struct and a separate prb_data_ring. This is a relic
from an earlier version of the code when a second data ring was present.
Since this is no longer the case remove the extra function argument
from:
- data_make_reusable()
- data_push_tail()
- data_alloc()
- data_realloc()

Signed-off-by: Nikolay Borisov <[email protected]>
Reviewed-by: John Ogness <[email protected]>
Reviewed-by: Petr Mladek <[email protected]>
Signed-off-by: Petr Mladek <[email protected]>

show more ...

printk: remove unneeded dead-store assignment

make clang-analyzer on x86_64 defconfig caught my attention with:

kernel/printk/printk_ringbuffer.c:885:3: warning:
Value stored to 'desc' is never

printk: remove unneeded dead-store assignment

make clang-analyzer on x86_64 defconfig caught my attention with:

kernel/printk/printk_ringbuffer.c:885:3: warning:
Value stored to 'desc' is never read [clang-analyzer-deadcode.DeadStores]

desc = to_desc(desc_ring, head_id);
^

Commit b6cf8b3f3312 ("printk: add lockless ringbuffer") introduced
desc_reserve() with this unneeded dead-store assignment.

As discussed with John Ogness privately, this is probably just some minor
left-over from previous iterations of the ringbuffer implementation. So,
simply remove this unneeded dead assignment to make clang-analyzer happy.

As compilers will detect this unneeded assignment and optimize this anyway,
the resulting object code is identical before and after this change.

No functional change. No change to object code.

Signed-off-by: Lukas Bulwahn <[email protected]>
Reviewed-by: Sergey Senozhatsky <[email protected]>
Reviewed-by: John Ogness <[email protected]>
Reviewed-by: Nathan Chancellor <[email protected]>
Signed-off-by: Petr Mladek <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

printk: ringbuffer: Replace zero-length array with flexible-array member

There is a regular need in the kernel to provide a way to declare having a
dynamically sized set of trailing elements in a st

printk: ringbuffer: Replace zero-length array with flexible-array member

There is a regular need in the kernel to provide a way to declare having a
dynamically sized set of trailing elements in a structure. Kernel code should
always use “flexible array members”[1] for these cases. The older style of
one-element or zero-length arrays should no longer be used[2].

[1] https://en.wikipedia.org/wiki/Flexible_array_member
[2] https://www.kernel.org/doc/html/v5.9/process/deprecated.html#zero-length-and-one-element-arrays

Signed-off-by: Gustavo A. R. Silva <[email protected]>

show more ...

printk: ringbuffer: Wrong data pointer when appending small string

data_realloc() returns wrong data pointer when the block is wrapped and
the size is not increased. It might happen when pr_cont() w

printk: ringbuffer: Wrong data pointer when appending small string

data_realloc() returns wrong data pointer when the block is wrapped and
the size is not increased. It might happen when pr_cont() wants to
add only few characters and there is already a space for them because
of alignment.

It might cause writing outsite the buffer. It has been detected by LTP
tests with KASAN enabled:

[ 221.921944] oom-kill:constraint=CONSTRAINT_MEMCG,nodemask=(null),cpuset=c,mems_allowed=0,oom_memcg=/0,task_memcg=in
[ 221.922108] ==================================================================
[ 221.922111] BUG: KASAN: global-out-of-bounds in vprintk_store+0x362/0x3d0
[ 221.922112] Write of size 2 at addr ffffffffba51dbcd by task
memcg_test_1/11282
[ 221.922113]
[ 221.922114] CPU: 1 PID: 11282 Comm: memcg_test_1 Not tainted
5.9.0-next-20201013 #1
[ 221.922116] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS
2.0b 07/27/2017
[ 221.922116] Call Trace:
[ 221.922117] dump_stack+0xa4/0xd9
[ 221.922118] print_address_description.constprop.0+0x21/0x210
[ 221.922119] ? _raw_write_lock_bh+0xe0/0xe0
[ 221.922120] ? vprintk_store+0x362/0x3d0
[ 221.922121] kasan_report.cold+0x37/0x7c
[ 221.922122] ? vprintk_store+0x362/0x3d0
[ 221.922123] check_memory_region+0x18c/0x1f0
[ 221.922124] memcpy+0x3c/0x60
[ 221.922125] vprintk_store+0x362/0x3d0
[ 221.922125] ? __ia32_sys_syslog+0x50/0x50
[ 221.922126] ? _raw_spin_lock_irqsave+0x9b/0x100
[ 221.922127] ? _raw_spin_lock_irq+0xf0/0xf0
[ 221.922128] ? __kasan_check_write+0x14/0x20
[ 221.922129] vprintk_emit+0x8d/0x1f0
[ 221.922130] vprintk_default+0x1d/0x20
[ 221.922131] vprintk_func+0x5a/0x100
[ 221.922132] printk+0xb2/0xe3
[ 221.922133] ? swsusp_write.cold+0x189/0x189
[ 221.922134] ? kernfs_vfs_xattr_set+0x60/0x60
[ 221.922134] ? _raw_write_lock_bh+0xe0/0xe0
[ 221.922135] ? trace_hardirqs_on+0x38/0x100
[ 221.922136] pr_cont_kernfs_path.cold+0x49/0x4b
[ 221.922137] mem_cgroup_print_oom_context.cold+0x74/0xc3
[ 221.922138] dump_header+0x340/0x3bf
[ 221.922139] oom_kill_process.cold+0xb/0x10
[ 221.922140] out_of_memory+0x1e9/0x860
[ 221.922141] ? oom_killer_disable+0x210/0x210
[ 221.922142] mem_cgroup_out_of_memory+0x198/0x1c0
[ 221.922143] ? mem_cgroup_count_precharge_pte_range+0x250/0x250
[ 221.922144] try_charge+0xa9b/0xc50
[ 221.922145] ? arch_stack_walk+0x9e/0xf0
[ 221.922146] ? memory_high_write+0x230/0x230
[ 221.922146] ? avc_has_extended_perms+0x830/0x830
[ 221.922147] ? stack_trace_save+0x94/0xc0
[ 221.922148] ? stack_trace_consume_entry+0x90/0x90
[ 221.922149] __memcg_kmem_charge+0x73/0x120
[ 221.922150] ? cred_has_capability+0x10f/0x200
[ 221.922151] ? mem_cgroup_can_attach+0x260/0x260
[ 221.922152] ? selinux_sb_eat_lsm_opts+0x2f0/0x2f0
[ 221.922153] ? obj_cgroup_charge+0x16b/0x220
[ 221.922154] ? kmem_cache_alloc+0x78/0x4c0
[ 221.922155] obj_cgroup_charge+0x122/0x220
[ 221.922156] ? vm_area_alloc+0x20/0x90
[ 221.922156] kmem_cache_alloc+0x78/0x4c0
[ 221.922157] vm_area_alloc+0x20/0x90
[ 221.922158] mmap_region+0x3ed/0x9a0
[ 221.922159] ? cap_mmap_addr+0x1d/0x80
[ 221.922160] do_mmap+0x3ee/0x720
[ 221.922161] vm_mmap_pgoff+0x16a/0x1c0
[ 221.922162] ? randomize_stack_top+0x90/0x90
[ 221.922163] ? copy_page_range+0x1980/0x1980
[ 221.922163] ksys_mmap_pgoff+0xab/0x350
[ 221.922164] ? find_mergeable_anon_vma+0x110/0x110
[ 221.922165] ? __audit_syscall_entry+0x1a6/0x1e0
[ 221.922166] __x64_sys_mmap+0x8d/0xb0
[ 221.922167] do_syscall_64+0x38/0x50
[ 221.922168] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 221.922169] RIP: 0033:0x7fe8f5e75103
[ 221.922172] Code: 54 41 89 d4 55 48 89 fd 53 4c 89 cb 48 85 ff 74
56 49 89 d9 45 89 f8 45 89 f2 44 89 e2 4c 89 ee 48 89 ef b8 09 00 00
00 0f 05 <48> 3d 00 f0 ff ff 77 7d 5b 5d 41 5c 41 5d 41 5e 41 5f c3 66
2e 0f
[ 221.922173] RSP: 002b:00007ffd38c90198 EFLAGS: 00000246 ORIG_RAX:
0000000000000009
[ 221.922175] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fe8f5e75103
[ 221.922176] RDX: 0000000000000003 RSI: 0000000000001000 RDI: 0000000000000000
[ 221.922178] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
[ 221.922179] R10: 0000000000002022 R11: 0000000000000246 R12: 0000000000000003
[ 221.922180] R13: 0000000000001000 R14: 0000000000002022 R15: 0000000000000000
[ 221.922181]
[ 213O[ 221.922182] The buggy address belongs to the variable:
[ 221.922183] clear_seq+0x2d/0x40
[ 221.922183]
[ 221.922184] Memory state around the buggy address:
[ 221.922185] ffffffffba51da80: 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00
[ 221.922187] ffffffffba51db00: 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00
[ 221.922188] >ffffffffba51db80: f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9
00 f9 f9 f9
[ 221.922189] ^
[ 221.922190] ffffffffba51dc00: f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9
00 f9 f9 f9
[ 221.922191] ffffffffba51dc80: f9 f9 f9 f9 01 f9 f9 f9 f9 f9 f9 f9
00 f9 f9 f9
[ 221.922193] ==================================================================
[ 221.922194] Disabling lock debugging due to kernel taint
[ 221.922196] ,task=memcg_test_1,pid=11280,uid=0
[ 221.922205] Memory cgroup out of memory: Killed process 11280

Link: https://lore.kernel.org/r/CA+G9fYt46oC7-BKryNDaaXPJ9GztvS2cs_7GjYRjanRi4+ryCQ@mail.gmail.com
Fixes: 4cfc7258f876a7feba673ac ("printk: ringbuffer: add finalization/extension support")
Reported-by: Naresh Kamboju <[email protected]>
Reviewed-by: John Ogness <[email protected]>
Acked-by: Sergey Senozhatsky <[email protected]>
Signed-off-by: Petr Mladek <[email protected]>
Link: https://lore.kernel.org/r/20201014175051.GC13775@alley

show more ...

printk: avoid and/or handle record truncation

If a reader provides a buffer that is smaller than the message text,
the @text_len field of @info will have a value larger than the buffer
size. If read

printk: avoid and/or handle record truncation

If a reader provides a buffer that is smaller than the message text,
the @text_len field of @info will have a value larger than the buffer
size. If readers blindly read @text_len bytes of data without
checking the size, they will read beyond their buffer.

Add this check to record_print_text() to properly recognize when such
truncation has occurred.

Add a maximum size argument to the ringbuffer function to extend
records so that records can not be created that are larger than the
buffer size of readers.

When extending records (LOG_CONT), do not extend records beyond
LOG_LINE_MAX since that is the maximum size available in the buffers
used by consoles and syslog.

Fixes: f5f022e53b87 ("printk: reimplement log_cont using record extension")
Reported-by: Marek Szyprowski <[email protected]>
Signed-off-by: John Ogness <[email protected]>
Reviewed-by: Petr Mladek <[email protected]>
Signed-off-by: Petr Mladek <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

printk: remove dict ring

Since there is no code that will ever store anything into the dict
ring, remove it. If any future dictionary properties are to be
added, these should be added to the struct

printk: remove dict ring

Since there is no code that will ever store anything into the dict
ring, remove it. If any future dictionary properties are to be
added, these should be added to the struct printk_info.

Signed-off-by: John Ogness <[email protected]>
Reviewed-by: Petr Mladek <[email protected]>
Signed-off-by: Petr Mladek <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

printk: move printk_info into separate array

The majority of the size of a descriptor is taken up by meta data,
which is often not of interest to the ringbuffer (for example,
when performing state c

printk: move printk_info into separate array

The majority of the size of a descriptor is taken up by meta data,
which is often not of interest to the ringbuffer (for example,
when performing state checks). Since descriptors are often
temporarily stored on the stack, keeping their size minimal will
help reduce stack pressure.

Rather than embedding the printk_info into the descriptor, create
a separate printk_info array. The index of a descriptor in the
descriptor array corresponds to the printk_info with the same
index in the printk_info array. The rules for validity of a
printk_info match the existing rules for the data blocks: the
descriptor must be in a consistent state.

Signed-off-by: John Ogness <[email protected]>
Reviewed-by: Petr Mladek <[email protected]>
Signed-off-by: Petr Mladek <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

printk: ringbuffer: add finalization/extension support

Add support for extending the newest data block. For this, introduce
a new finalization state (desc_finalized) denoting a committed
descriptor

printk: ringbuffer: add finalization/extension support

Add support for extending the newest data block. For this, introduce
a new finalization state (desc_finalized) denoting a committed
descriptor that cannot be extended.

Until a record is finalized, a writer can reopen that record to
append new data. Reopening a record means transitioning from the
desc_committed state back to the desc_reserved state.

A writer can explicitly finalize a record if there is no intention
of extending it. Also, records are automatically finalized when a
new record is reserved. This relieves writers of needing to
explicitly finalize while also making such records available to
readers sooner. (Readers can only traverse finalized records.)

Four new memory barrier pairs are introduced. Two of them are
insignificant additions (data_realloc:A/desc_read:D and
data_realloc:A/data_push_tail:B) because they are alternate path
memory barriers that exactly match the purpose, pairing, and
context of the two existing memory barrier pairs they provide an
alternate path for. The other two new memory barrier pairs are
significant additions:

desc_reopen_last:A / _prb_commit:B - When reopening a descriptor,
ensure the state transitions back to desc_reserved before
fully trusting the descriptor data.

_prb_commit:B / desc_reserve:D - When committing a descriptor,
ensure the state transitions to desc_committed before checking
the head ID to see if the descriptor needs to be finalized.

Signed-off-by: John Ogness <[email protected]>
Reviewed-by: Petr Mladek <[email protected]>
Signed-off-by: Petr Mladek <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

printk: ringbuffer: change representation of states

Rather than deriving the state by evaluating bits within the flags
area of the state variable, assign the states explicit values and
set those val

printk: ringbuffer: change representation of states

Rather than deriving the state by evaluating bits within the flags
area of the state variable, assign the states explicit values and
set those values in the flags area. Introduce macros to make it
simple to read and write state values for the state variable.

Although the functionality is preserved, the binary representation
for the states is changed.

Signed-off-by: John Ogness <[email protected]>
Reviewed-by: Petr Mladek <[email protected]>
Signed-off-by: Petr Mladek <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

printk: ringbuffer: clear initial reserved fields

prb_reserve() will set some meta data values and leave others
uninitialized (or rather, containing the values of the previous
wrap). Simplify the AP

printk: ringbuffer: clear initial reserved fields

prb_reserve() will set some meta data values and leave others
uninitialized (or rather, containing the values of the previous
wrap). Simplify the API by always clearing out all the fields.
Only the sequence number is filled in. The caller is now
responsible for filling in the rest of the meta data fields.
In particular, for correctly filling in text and dict lengths.

Signed-off-by: John Ogness <[email protected]>
Reviewed-by: Petr Mladek <[email protected]>
Signed-off-by: Petr Mladek <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

printk: ringbuffer: add BLK_DATALESS() macro

Rather than continually needing to explicitly check @begin and @next
to identify a dataless block, introduce and use a BLK_DATALESS()
macro.

Signed-off-

printk: ringbuffer: add BLK_DATALESS() macro

Rather than continually needing to explicitly check @begin and @next
to identify a dataless block, introduce and use a BLK_DATALESS()
macro.

Signed-off-by: John Ogness <[email protected]>
Reviewed-by: Petr Mladek <[email protected]>
Signed-off-by: Petr Mladek <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

printk: ringbuffer: relocate get_data()

Move the internal get_data() function as-is above prb_reserve() so
that a later change can make use of the static function.

Signed-off-by: John Ogness <john.

printk: ringbuffer: relocate get_data()

Move the internal get_data() function as-is above prb_reserve() so
that a later change can make use of the static function.

Signed-off-by: John Ogness <[email protected]>
Reviewed-by: Petr Mladek <[email protected]>
Signed-off-by: Petr Mladek <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

printk: ringbuffer: avoid memcpy() on state_var

@state_var is copied as part of the descriptor copying via
memcpy(). This is not allowed because @state_var is an atomic type,
which in some implement

printk: ringbuffer: avoid memcpy() on state_var

@state_var is copied as part of the descriptor copying via
memcpy(). This is not allowed because @state_var is an atomic type,
which in some implementations may contain a spinlock.

Avoid using memcpy() with @state_var by explicitly copying the other
fields of the descriptor. @state_var is set using atomic set
operator before returning.

Fixes: b6cf8b3f3312 ("printk: add lockless ringbuffer")
Signed-off-by: John Ogness <[email protected]>
Reviewed-by: Petr Mladek <[email protected]>
Signed-off-by: Petr Mladek <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

printk: ringbuffer: fix setting state in desc_read()

It is expected that desc_read() will always set at least the
@state_var field. However, if the descriptor is in an inconsistent
state, no fields

printk: ringbuffer: fix setting state in desc_read()

It is expected that desc_read() will always set at least the
@state_var field. However, if the descriptor is in an inconsistent
state, no fields are set.

Also, the second load of @state_var is not stored in @desc_out and
so might not match the state value that is returned.

Always set the last loaded @state_var into @desc_out, regardless of
the descriptor consistency.

Fixes: b6cf8b3f3312 ("printk: add lockless ringbuffer")
Signed-off-by: John Ogness <[email protected]>
Reviewed-by: Petr Mladek <[email protected]>
Signed-off-by: Petr Mladek <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...