linux-stable.git/kernel/printk, branch master

printk: fix typos in comments

2026-06-02T13:36:06+00:00

Fix spelling/grammatical errors in printk.c and nbcon.c:
- "precation" -> "precautionary"
- "othrewise" -> "otherwise"
- "An usable" -> "A usable"
- "made a progress" -> "made progress"
- "preemtible" -> "preemptible"
- "mechasism" -> "mechanism"
- "ownerhip" -> "ownership"

Signed-off-by: Naveen Kumar Chaudhary 
Link: https://patch.msgid.link/pakfewagyzb7da3yuxnaxdaoma5w4j2c7i3xebmcld3xy4mqs5@zxsx2idpxrdq
Reviewed-by: Petr Mladek 
Signed-off-by: Petr Mladek

Merge branch 'rework/prb-fixes' into for-linus

2026-04-20T11:42:01+00:00

printk: ringbuffer: fix errors in comments

2026-03-31T15:40:23+00:00

The printk ringbuffer implementation is described in the comment as
using three ringbuffers, but the current implementation uses two (desc
and data). Update the comment so it matches the code.

Fix few more known issues in the comments.

Signed-off-by: Loïc Grégoire 
Reviewed-by: John Ogness 
Link: https://patch.msgid.link/20260328021855.53956-1-loicgre@gmail.com
[pmladek@suse.com: Fixed few more issues in the comments by John Ogness.]
Signed-off-by: John Ogness 
Reviewed-by: Petr Mladek 
Signed-off-by: Petr Mladek

printk_ringbuffer: Add sanity check for 0-size data

2026-03-27T16:12:37+00:00

get_data() has a sanity check for regular data blocks to ensure at
least space for the ID exists. But a regular block should also have
at least 1 byte of data (otherwise it would be data-less instead of
regular).

Expand the get_data() block size sanity check to additionally expect
at least 1 byte of data.

Signed-off-by: John Ogness 
Reviewed-by: Petr Mladek 
Tested-by: Petr Mladek 
Link: https://patch.msgid.link/20260326133809.8045-2-john.ogness@linutronix.de
Signed-off-by: Petr Mladek

printk_ringbuffer: Fix get_data() size sanity check

2026-03-27T16:12:37+00:00

Commit cc3bad11de6e ("printk_ringbuffer: Fix check of valid data
size when blk_lpos overflows") added sanity checking to get_data()
to avoid returning data of illegal sizes (too large or too small).
It uses the helper function data_check_size() for the check.
However, data_check_size() expects the size of the data, not the
size of the data block. get_data() is providing the size of the
data block.  This means that if the data size (text_buf_size) is
at or near the maximum legal size:

sizeof(prb_data_block) + text_buf_size == DATA_SIZE(data_ring) / 2

data_check_size() will report failure because it adds
sizeof(prb_data_block) to the provided size. The sanity check in
get_data() is counting the data block header twice. The result is
that the reader fails to read the legal record.

Since get_data() subtracts the data block header size before returning,
move the sanity check to after the subtraction.

Luckily printk() is not vulnerable to this problem because
truncate_msg() limits printk-messages to 1/4 of the ringbuffer.
Indeed, by adjusting the printk_ringbuffer KUnit test, which does not
use printk() and its truncate_msg() check, it is easy to see that the
reader fails and the WARN_ON is triggered.

Fixes: cc3bad11de6e ("printk_ringbuffer: Fix check of valid data size when blk_lpos overflows")
Signed-off-by: John Ogness 
Reviewed-by: Petr Mladek 
Tested-by: Petr Mladek 
Link: https://patch.msgid.link/20260326133809.8045-1-john.ogness@linutronix.de
Signed-off-by: Petr Mladek

printk: Fix _DESCS_COUNT type for 64-bit systems

2026-03-10T15:58:05+00:00

The _DESCS_COUNT macro currently uses 1U (32-bit unsigned) instead of
1UL (unsigned long), which breaks the intended overflow testing design
on 64-bit systems.

Problem Analysis:
----------------
The printk_ringbuffer uses a deliberate design choice to initialize
descriptor IDs near the maximum 62-bit value to trigger overflow early
in the system's lifetime. This is documented in printk_ringbuffer.h:

  "initial values are chosen that map to the correct initial array
   indexes, but will result in overflows soon."

The DESC0_ID macro calculates:
  DESC0_ID(ct_bits) = DESC_ID(-(_DESCS_COUNT(ct_bits) + 1))

On 64-bit systems with typical configuration (descbits=16):
- Current buggy behavior: DESC0_ID = 0xfffeffff
- Expected behavior:      DESC0_ID = 0x3ffffffffffeffff

The buggy version only uses 32 bits, which means:
1. The initial ID is nowhere near 2^62
2. It would take ~140 trillion wraps to trigger 62-bit overflow
3. The overflow handling code is never tested in practice

Root Cause:
----------
The issue is in this line:
  #define _DESCS_COUNT(ct_bits)    (1U << (ct_bits))

When _DESCS_COUNT(16) is calculated:
  1U << 16 = 0x10000 (32-bit value)
  -(0x10000 + 1) = -0x10001 = 0xFFFEFFFF (32-bit two's complement)

On 64-bit systems, this 32-bit value doesn't get extended to create
the intended 62-bit ID near the maximum value.

Impact:
------
While index calculations still work correctly in the short term, this
bug has several implications:

1. Violates the design intention documented in the code
2. Overflow handling code paths remain untested
3. ABA detection code doesn't get exercised under overflow conditions
4. In extreme long-term running scenarios (though unlikely), could
   potentially cause issues when ID actually reaches 2^62

Verification:
------------
Tested on ARM64 system with CONFIG_LOG_BUF_SHIFT=20 (descbits=15):
- Before fix: DESC0_ID(16) = 0xfffeffff
- After fix:  DESC0_ID(16) = 0x3fffffffffff7fff

The fix aligns _DESCS_COUNT with _DATA_SIZE, which already correctly
uses 1UL:
  #define _DATA_SIZE(sz_bits)    (1UL << (sz_bits))

Signed-off-by: feng.zhou 
Reviewed-by: Petr Mladek 
Tested-by: Petr Mladek 
Link: https://patch.msgid.link/20260202094140.9518-1-realsummitzhou@gmail.com
Signed-off-by: Petr Mladek

Convert 'alloc_obj' family to use the new default GFP_KERNEL argument

2026-02-22T01:09:51+00:00

This was done entirely with mindless brute force, using

    git grep -l '\

treewide: Replace kmalloc with kmalloc_obj for non-scalar types

2026-02-21T09:02:28+00:00

This is the result of running the Coccinelle script from
scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to
avoid scalar types (which need careful case-by-case checking), and
instead replace kmalloc-family calls that allocate struct or union
object instances:

Single allocations:	kmalloc(sizeof(TYPE), ...)
are replaced with:	kmalloc_obj(TYPE, ...)

Array allocations:	kmalloc_array(COUNT, sizeof(TYPE), ...)
are replaced with:	kmalloc_objs(TYPE, COUNT, ...)

Flex array allocations:	kmalloc(struct_size(PTR, FAM, COUNT), ...)
are replaced with:	kmalloc_flex(*PTR, FAM, COUNT, ...)

(where TYPE may also be *VAR)

The resulting allocations no longer return "void *", instead returning
"TYPE *".

Signed-off-by: Kees Cook

Merge tag 'sysctl-7.00-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/sysctl/sysctl

2026-02-18T18:45:36+00:00

Pull sysctl updates from Joel Granados:

 - Remove macros from proc handler converters

   Replace the proc converter macros with "regular" functions. Though it
   is more verbose than the macro version, it helps when debugging and
   better aligns with coding-style.rst.

 - General cleanup

   Remove superfluous ctl_table forward declarations. Const qualify the
   memory_allocation_profiling_sysctl and loadpin_sysctl_table arrays.
   Add missing kernel doc to proc_dointvec_conv.

 - Testing

   This series was run through sysctl selftests/kunit test suite in
   x86_64. And went into linux-next after rc4, giving it a good 3 weeks
   of testing

* tag 'sysctl-7.00-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/sysctl/sysctl:
  sysctl: replace SYSCTL_INT_CONV_CUSTOM macro with functions
  sysctl: Replace unidirectional INT converter macros with functions
  sysctl: Add kernel doc to proc_douintvec_conv
  sysctl: Replace UINT converter macros with functions
  sysctl: Add CONFIG_PROC_SYSCTL guards for converter macros
  sysctl: clarify proc_douintvec_minmax doc
  sysctl: Return -ENOSYS from proc_douintvec_conv when CONFIG_PROC_SYSCTL=n
  sysctl: Remove unused ctl_table forward declarations
  loadpin: Implement custom proc_handler for enforce
  alloc_tag: move memory_allocation_profiling_sysctls into .rodata
  sysctl: Add missing kernel-doc for proc_dointvec_conv

printk, vt, fbcon: Remove console_conditional_schedule()

2026-02-14T10:09:47+00:00

do_con_write(), fbcon_redraw.*() invoke console_conditional_schedule()
which is a conditional scheduling point based on printk's internal
variables console_may_schedule. It may only be used if the console lock
is acquired for instance via console_lock() or console_trylock().

Prinkt sets the internal variable to 1 (and allows to schedule)
if the console lock has been acquired via console_lock(). The trylock
does not allow it.

The console_conditional_schedule() invocation in do_con_write() is
invoked shortly before console_unlock().
The console_conditional_schedule() invocation in fbcon_redraw.*()
original from fbcon_scroll() / vt's con_scroll() which originate from a
line feed.

In console_unlock() the variable is set to 0 (forbids to schedule) and
it tries to schedule while making progress printing. This is brand new
compared to when console_conditional_schedule() was added in v2.4.9.11.

In v2.6.38-rc3, console_unlock() (started its existence) iterated over
all consoles and flushed them with disabled interrupts. A scheduling
attempt here was not possible, it relied that a long print scheduled
before console_unlock().

Since commit 8d91f8b15361d ("printk: do cond_resched() between lines
while outputting to consoles"), which appeared in v4.5-rc1,
console_unlock() attempts to schedule if it was allowed to schedule
while during console_lock(). Each record is idealy one line so after
every line feed.

This console_conditional_schedule() is also only relevant on
PREEMPT_NONE and PREEMPT_VOLUNTARY builds. In other configurations
cond_resched() becomes a nop and has no impact.

I'm bringing this all up just proof that it is not required anymore. It
becomes a problem on a PREEMPT_RT build with debug code enabled because
that might_sleep() in cond_resched() remains and triggers a warnings.
This is due to

 legacy_kthread_func-> console_flush_one_record ->  vt_console_print-> lf
   -> con_scroll -> fbcon_scroll

and vt_console_print() acquires a spinlock_t which does not allow a
voluntary schedule. There is no need to fb_scroll() to schedule since
console_flush_one_record() attempts to schedule after each line.
!PREEMPT_RT is not affected because the legacy printing thread is only
enabled on PREEMPT_RT builds.

Therefore I suggest to remove console_conditional_schedule().

Cc: Simona Vetter 
Cc: Helge Deller 
Cc: linux-fbdev@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Fixes: 5f53ca3ff83b4 ("printk: Implement legacy printer kthread for PREEMPT_RT")
Signed-off-by: Sebastian Andrzej Siewior 
Acked-by: Greg Kroah-Hartman 
Acked-by: Petr Mladek  # from printk() POV
Signed-off-by: Helge Deller