kernel/linux.git/fs/pstore/inode.c, branch linux-7.1.y

pstore/ftrace: Factor KASLR offset in the core kernel instruction addresses

2026-04-11T06:59:41+00:00

The pstore ftrace frontend works by purely collecting the instruction address, saving it on the persistent area through the backend and when the log is read, on next boot for example, the address is then resolved by using the regular printk symbol lookup (%pS for example). Problem: if we are running a relocatable kernel with KASLR enabled, this is a recipe for failure in the symbol resolution on next boots, since the addresses are offset'ed by the KASLR address. So, naturally the way to go is factor the KASLR address out of instruction address collection, and adding the fresh offset when resolving the symbol on future boots. Problem #2: modules also have varying addresses that float based on module base address and potentially the module ordering in memory, meaning factoring KASLR offset for them is useless. So, let's hereby only take KASLR offset into account for core kernel addresses, leaving module ones as is. And we have yet a 3rd complexity: not necessarily the check range for core kernel addresses holds true on future boots, since the module base address will vary. With that, the choice was to mark the addresses as being core vs module based on its MSB. And with that... ...we have the 4th challenge here: for some "simple" architectures, the CPU number is saved bit-encoded on the instruction pointer, to allow bigger timestamps - this is set through the PSTORE_CPU_IN_IP define for such architectures. Hence, the approach here is to skip such architectures (at least in a first moment). Finished? No. On top of all previous complexities, we have one extra pain point: kaslr_offset() is inlined and fully "resolved" at boot-time, after kernel decompression, through ELF relocation mechanism. Once the offset is known, it's patched to the kernel text area, wherever it is used. The mechanism, and its users, are only built-in - incompatible with module usage. Though there are possibly some hacks (as computing the offset using some kallsym lookup), the choice here is to restrict this optimization to the (hopefully common) case of CONFIG_PSTORE=y. TL;DR: let's factor KASLR offsets on pstore/ftrace for core kernel addresses, only when PSTORE is built-in and leaving module addresses out, as well as architectures that define PSTORE_CPU_IN_IP. Signed-off-by: Guilherme G. Piccoli Link: https://patch.msgid.link/20260410205848.2607169-1-gpiccoli@igalia.com Signed-off-by: Kees Cook

pstore: fix ftrace dump, when ECC is enabled

2026-03-31T21:52:25+00:00

total_size is sum of record->size and record->ecc_notice_size (ECC: No errors detected). When ECC is not used, then there is no problem. When ECC is enabled, then ftrace dump is decoded incorrectly after restart. First this affects starting offset calculation, that breaks reading of all ftrace records. CPU:66 ts:51646260179894273 3818ffff80008002 fe00ffff800080f0 0x3818ffff80008002 <- 0xfe00ffff800080f0 CPU:66 ts:56589664458375169 3818ffff80008002 ff02ffff800080f0 0x3818ffff80008002 <- 0xff02ffff800080f0 CPU:67 ts:13194139533313 afe4ffff80008002 1ffff800080f0 0xafe4ffff80008002 <- 0x1ffff800080f0 CPU:67 ts:13194139533313 b7d0ffff80008001 100ffff80008002 0xb7d0ffff80008001 <- 0x100ffff80008002 CPU:67 ts:51646260179894273 8de0ffff80008001 202ffff80008002 0x8de0ffff80008001 <- 0x202ffff80008002 Second ECC notice message is printed like ftrace record and as a result couple of last records are completely wrong. For example, when the starting offset is fixed: CPU:0 ts:113 ffffffc00879bd04 ffffffc0080dc08c cpuidle_enter <- do_idle+0x20c/0x290 CPU:0 ts:114 ffffffc00879bd04 ffffffc0080dc08c cpuidle_enter <- do_idle+0x20c/0x290 CPU:100 ts:28259048229270629 6f4e203a4343450a 2073726f72726520 0x6f4e203a4343450a <- 0x2073726f72726520 Signed-off-by: Andrey Skvortsov Tested-by: Guilherme G. Piccoli Link: https://patch.msgid.link/20260215185156.317394-1-andrej.skvortzov@gmail.com Signed-off-by: Kees Cook

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

convert pstore

2025-11-16T06:35:03+00:00

object creation by d_alloc_name()+d_add() in pstore_mkfile(), removal - via normal VFS codepaths (with ->unlink() using simple_unlink()) or in pstore_put_backend_records() via locked_recursive_removal() Replace d_add() with d_make_persistent()+dput() - that's what really happens there. The reference that goes into record->dentry is valid only until the unlink (and explicitly cleared by pstore_unlink()). Reviewed-by: Kees Cook Signed-off-by: Al Viro

fs: rename generic_delete_inode() and generic_drop_inode()

2025-09-15T14:09:42+00:00

generic_delete_inode() is rather misleading for what the routine is doing. inode_just_drop() should be much clearer. The new naming is inconsistent with generic_drop_inode(), so rename that one as well with inode_ as the suffix. No functional changes. Signed-off-by: Mateusz Guzik Reviewed-by: Jan Kara Signed-off-by: Christian Brauner

pstore: switch to locked_recursive_removal()

2025-07-03T02:36:51+00:00

rather than playing with manual d_invalidate() Reviewed-by: Christian Brauner Signed-off-by: Al Viro

Merge tag 'pstore-v6.15-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux

2025-03-24T22:43:28+00:00

Pull tiny pstore update from Kees Cook: - pstore: Change kmsg_bytes storage size to u32 * tag 'pstore-v6.15-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: pstore: Change kmsg_bytes storage size to u32

pstore: Change kmsg_bytes storage size to u32

2025-02-10T17:02:14+00:00

The types around kmsg_bytes were inconsistent. The global was unsigned long, the argument to pstore_set_kmsg_bytes() was int, and the filesystem option was u32. Given other internal limits, there's not much sense in making a single pstore record larger than INT_MAX and it can't be negative, so use u32 everywhere. Additionally, use READ/WRITE_ONCE and a local variable in pstore_dump() to avoid kmsg_bytes changing during a dump. Link: https://lore.kernel.org/r/20250206191655.work.798-kees@kernel.org Signed-off-by: Kees Cook

pstore: convert to the new mount API

2025-02-06T10:50:43+00:00

Convert the pstore filesystem to the new mount API. Cc: Kees Cook Cc: Tony Luck Signed-off-by: Eric Sandeen Link: https://lore.kernel.org/r/20250205213931.74614-2-sandeen@redhat.com Reviewed-by: Kees Cook Signed-off-by: Christian Brauner