|
Revision tags: v6.15, v6.15-rc7, v6.15-rc6, v6.15-rc5, v6.15-rc4, v6.15-rc3, v6.15-rc2, v6.15-rc1, v6.14, v6.14-rc7, v6.14-rc6, v6.14-rc5, v6.14-rc4, v6.14-rc3, v6.14-rc2, v6.14-rc1, v6.13, v6.13-rc7, v6.13-rc6, v6.13-rc5, v6.13-rc4 |
|
| #
23c22d91 |
| 20-Dec-2024 |
Paul E. McKenney <[email protected]> |
rcu-tasks: Move RCU Tasks self-tests to core_initcall()
The timer and hrtimer softirq processing has moved to dedicated threads for kernels built with CONFIG_IRQ_FORCED_THREADING=y. This results in
rcu-tasks: Move RCU Tasks self-tests to core_initcall()
The timer and hrtimer softirq processing has moved to dedicated threads for kernels built with CONFIG_IRQ_FORCED_THREADING=y. This results in timers not expiring until later in early boot, which in turn causes the RCU Tasks self-tests to hang in kernels built with CONFIG_PROVE_RCU=y, which further causes the entire kernel to hang. One fix would be to make timers work during this time, but there are no known users of RCU Tasks grace periods during that time, so no justification for the added complexity. Not yet, anyway.
This commit therefore moves the call to rcu_init_tasks_generic() from kernel_init_freeable() to a core_initcall(). This works because the timer and hrtimer kthreads are created at early_initcall() time.
Fixes: 49a17639508c3 ("softirq: Use a dedicated thread for timer wakeups on PREEMPT_RT.") Signed-off-by: Paul E. McKenney <[email protected]> Cc: Sebastian Andrzej Siewior <[email protected]> Cc: Frederic Weisbecker <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Alexei Starovoitov <[email protected]> Cc: Andrii Nakryiko <[email protected]> Cc: Steven Rostedt <[email protected]> Cc: Mathieu Desnoyers <[email protected]> Cc: Masami Hiramatsu <[email protected]> Cc: <[email protected]> Tested-by: Sebastian Andrzej Siewior <[email protected]> Reviewed-by: Sebastian Andrzej Siewior <[email protected]> Signed-off-by: Boqun Feng <[email protected]>
show more ...
|
| #
c6f23979 |
| 02-Jan-2025 |
Guo Weikang <[email protected]> |
mm/memblock: add memblock_alloc_or_panic interface
Before SLUB initialization, various subsystems used memblock_alloc to allocate memory. In most cases, when memory allocation fails, an immediate p
mm/memblock: add memblock_alloc_or_panic interface
Before SLUB initialization, various subsystems used memblock_alloc to allocate memory. In most cases, when memory allocation fails, an immediate panic is required. To simplify this behavior and reduce repetitive checks, introduce `memblock_alloc_or_panic`. This function ensures that memory allocation failures result in a panic automatically, improving code readability and consistency across subsystems that require this behavior.
[[email protected]: arch/s390: save_area_alloc default failure behavior changed to panic] Link: https://lkml.kernel.org/r/[email protected] Link: https://lore.kernel.org/lkml/[email protected]/ Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Guo Weikang <[email protected]> Acked-by: Geert Uytterhoeven <[email protected]> [m68k] Reviewed-by: Alexander Gordeev <[email protected]> [s390] Acked-by: Mike Rapoport (Microsoft) <[email protected]> Cc: Alexander Gordeev <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
show more ...
|
|
Revision tags: v6.13-rc3 |
|
| #
0f52b4db |
| 12-Dec-2024 |
Uladzislau Rezki (Sony) <[email protected]> |
rcu/kvfree: Initialize kvfree_rcu() separately
Introduce a separate initialization of kvfree_rcu() functionality. For such purpose a kfree_rcu_batch_init() is renamed to a kvfree_rcu_init() and it i
rcu/kvfree: Initialize kvfree_rcu() separately
Introduce a separate initialization of kvfree_rcu() functionality. For such purpose a kfree_rcu_batch_init() is renamed to a kvfree_rcu_init() and it is invoked from the main.c right after rcu_init() is done.
Signed-off-by: Uladzislau Rezki (Sony) <[email protected]> Acked-by: Hyeonggon Yoo <[email protected]> Tested-by: Hyeonggon Yoo <[email protected]> Signed-off-by: Vlastimil Babka <[email protected]>
show more ...
|
|
Revision tags: v6.13-rc2, v6.13-rc1, v6.12, v6.12-rc7, v6.12-rc6, v6.12-rc5, v6.12-rc4, v6.12-rc3, v6.12-rc2, v6.12-rc1, v6.11 |
|
| #
17b65575 |
| 11-Sep-2024 |
Raul E Rangel <[email protected]> |
init: Don't proxy `console=` to earlycon
Today we are proxying the `console=` command line args to the `param_setup_earlycon()` handler. This is done because the following are equivalent:
conso
init: Don't proxy `console=` to earlycon
Today we are proxying the `console=` command line args to the `param_setup_earlycon()` handler. This is done because the following are equivalent:
console=uart[8250],mmio,<addr>[,options] earlycon=uart[8250],mmio,<addr>[,options]
Both invocations enable an early `bootconsole`. `console=uartXXXX` is just an alias for `earlycon=uartXXXX`.
In addition, when `earlycon=` (empty value) or just `earlycon` (no value) is specified on the command line, we enable the earlycon `bootconsole` specified by the SPCR table or the DT.
The problem arises when `console=` (empty value) is specified on the command line. It's intention is to disable the `console`, but what happens instead is that the SPRC/DT console gets enabled.
This happens because we are proxying the `console=` (empty value) parameter to the `earlycon` handler. The `earlycon` handler then sees that the parameter value is empty, so it enables the SPCR/DT `bootconsole`.
This change makes it so that the `console` or `console=` parameters no longer enable the SPCR/DT `bootconsole`. I also cleans up the hack in `main.c` that would forward the `console` parameter to the `earlycon` handler.
Signed-off-by: Raul E Rangel <[email protected]> Reviewed-by: Petr Mladek <[email protected]> Tested-by: Petr Mladek <[email protected]> Link: https://lore.kernel.org/r/20240911123507.v2.1.Id08823b2f848237ae90ce5c5fa7e027e97c33ad3@changeid Signed-off-by: Petr Mladek <[email protected]>
show more ...
|
|
Revision tags: v6.11-rc7, v6.11-rc6, v6.11-rc5, v6.11-rc4 |
|
| #
77b644c3 |
| 16-Aug-2024 |
KP Singh <[email protected]> |
init/main.c: Initialize early LSMs after arch code, static keys and calls.
With LSMs using static calls and static keys, early_lsm_init needs to wait for setup_arch for architecture specific functio
init/main.c: Initialize early LSMs after arch code, static keys and calls.
With LSMs using static calls and static keys, early_lsm_init needs to wait for setup_arch for architecture specific functionality which includes jump tables and static calls to be initialized.
Since not all architectures call jump_table_init in setup_arch, explicitly call both jump_table_init and static_call_init before early_security_init.
This only affects "early LSMs" i.e. only lockdown when CONFIG_SECURITY_LOCKDOWN_LSM_EARLY is set.
Tested-by: Guenter Roeck <[email protected]> Signed-off-by: KP Singh <[email protected]> Signed-off-by: Paul Moore <[email protected]>
show more ...
|
|
Revision tags: v6.11-rc3, v6.11-rc2, v6.11-rc1, v6.10, v6.10-rc7, v6.10-rc6, v6.10-rc5, v6.10-rc4, v6.10-rc3, v6.10-rc2, v6.10-rc1, v6.9, v6.9-rc7, v6.9-rc6, v6.9-rc5, v6.9-rc4, v6.9-rc3, v6.9-rc2, v6.9-rc1, v6.8, v6.8-rc7, v6.8-rc6, v6.8-rc5, v6.8-rc4, v6.8-rc3, v6.8-rc2 |
|
| #
f9899c02 |
| 26-Jan-2024 |
Huang Shijie <[email protected]> |
NUMA: early use of cpu_to_node() returns 0 instead of the correct node id
During the kernel booting, the generic cpu_to_node() is called too early in arm64, powerpc and riscv when CONFIG_NUMA is ena
NUMA: early use of cpu_to_node() returns 0 instead of the correct node id
During the kernel booting, the generic cpu_to_node() is called too early in arm64, powerpc and riscv when CONFIG_NUMA is enabled.
There are at least four places in the common code where the generic cpu_to_node() is called before it is initialized: 1.) early_trace_init() in kernel/trace/trace.c 2.) sched_init() in kernel/sched/core.c 3.) init_sched_fair_class() in kernel/sched/fair.c 4.) workqueue_init_early() in kernel/workqueue.c
This will harm performance since there is an increase in off node accesses.
In order to fix the bug, the patch introduces early_numa_node_init() which is called after smp_prepare_boot_cpu() in start_kernel. early_numa_node_init will initialize the "numa_node" as soon as the early_cpu_to_node() is ready, before the cpu_to_node() is called at the first time.
Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Huang Shijie <[email protected]> Acked-by: Palmer Dabbelt <[email protected]> [RISC-V] Cc: Albert Ou <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Huacai Chen <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jakub Kicinski <[email protected]> Cc: Jiaxun Yang <[email protected]> Cc: Josh Poimboeuf <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Masami Hiramatsu <[email protected]> Cc: Michael Ellerman <[email protected]> Cc: Michael Kelley (LINUX) <[email protected]> Cc: "Mike Rapoport (IBM)" <[email protected]> Cc: Nick Desaulniers <[email protected]> Cc: Paul Walmsley <[email protected]> Cc: Rafael J. Wysocki <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Valentin Schneider <[email protected]> Cc: Vlastimil Babka <[email protected]> Cc: Will Deacon <[email protected]> Cc: Yury Norov <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
show more ...
|
| #
212f863f |
| 20-Mar-2024 |
Rasmus Villemoes <[email protected]> |
bootconfig: do not put quotes on cmdline items unless necessary
When trying to migrate to using bootconfig to embed the kernel's and PID1's command line with the kernel image itself, and so allowing
bootconfig: do not put quotes on cmdline items unless necessary
When trying to migrate to using bootconfig to embed the kernel's and PID1's command line with the kernel image itself, and so allowing changing that without modifying the bootloader, I noticed that /proc/cmdline changed from e.g.
console=ttymxc0,115200n8 cma=128M quiet -- --log-level=notice
to
console="ttymxc0,115200n8" cma="128M" quiet -- --log-level="notice"
The kernel parameters are parsed just fine, and the quotes are indeed stripped from the actual argv[] given to PID1. However, the quoting doesn't really serve any purpose and looks excessive, and might confuse some (naive) userspace tool trying to parse /proc/cmdline. So do not quote the value unless it contains whitespace.
Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Rasmus Villemoes <[email protected]> Cc: Masami Hiramatsu <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
show more ...
|
| #
ddd53363 |
| 12-Apr-2024 |
Yuntao Wang <[email protected]> |
init/main.c: Minor cleanup for the setup_command_line() function
This is just a minor cleanup to make the code look a bit cleaner.
Link: https://lore.kernel.org/all/20240412081733.35925-3-ytcoode@g
init/main.c: Minor cleanup for the setup_command_line() function
This is just a minor cleanup to make the code look a bit cleaner.
Link: https://lore.kernel.org/all/[email protected]/
Signed-off-by: Yuntao Wang <[email protected]> Signed-off-by: Masami Hiramatsu (Google) <[email protected]>
show more ...
|
| #
cd24bdb0 |
| 12-Apr-2024 |
Yuntao Wang <[email protected]> |
init/main.c: Remove redundant space from saved_command_line
There is a space at the end of extra_init_args. In the current logic, copying extra_init_args to saved_command_line will cause extra space
init/main.c: Remove redundant space from saved_command_line
There is a space at the end of extra_init_args. In the current logic, copying extra_init_args to saved_command_line will cause extra spaces in saved_command_line here or there. Remove the trailing space from extra_init_args to make the string in saved_command_line look more perfect.
Link: https://lore.kernel.org/all/[email protected]/
Signed-off-by: Yuntao Wang <[email protected]> Acked-by: Masami Hiramatsu (Google) <[email protected]> Signed-off-by: Masami Hiramatsu (Google) <[email protected]>
show more ...
|
| #
efee03a5 |
| 12-Apr-2024 |
Rasmus Villemoes <[email protected]> |
bootconfig: do not put quotes on cmdline items unless necessary
When trying to migrate to using bootconfig to embed the kernel's and PID1's command line with the kernel image itself, and so allowing
bootconfig: do not put quotes on cmdline items unless necessary
When trying to migrate to using bootconfig to embed the kernel's and PID1's command line with the kernel image itself, and so allowing changing that without modifying the bootloader, I noticed that /proc/cmdline changed from e.g.
console=ttymxc0,115200n8 cma=128M quiet -- --log-level=notice
to
console="ttymxc0,115200n8" cma="128M" quiet -- --log-level="notice"
The kernel parameters are parsed just fine, and the quotes are indeed stripped from the actual argv[] given to PID1. However, the quoting doesn't really serve any purpose and looks excessive, and might confuse some (naive) userspace tool trying to parse /proc/cmdline. So do not quote the value unless it contains whitespace.
Link: https://lore.kernel.org/all/[email protected]/
Signed-off-by: Rasmus Villemoes <[email protected]> Acked-by: Masami Hiramatsu (Google) <[email protected]> Signed-off-by: Masami Hiramatsu (Google) <[email protected]>
show more ...
|
| #
46dad3c1 |
| 12-Apr-2024 |
Yuntao Wang <[email protected]> |
init/main.c: Fix potential static_command_line memory overflow
We allocate memory of size 'xlen + strlen(boot_command_line) + 1' for static_command_line, but the strings copied into static_command_l
init/main.c: Fix potential static_command_line memory overflow
We allocate memory of size 'xlen + strlen(boot_command_line) + 1' for static_command_line, but the strings copied into static_command_line are extra_command_line and command_line, rather than extra_command_line and boot_command_line.
When strlen(command_line) > strlen(boot_command_line), static_command_line will overflow.
This patch just recovers strlen(command_line) which was miss-consolidated with strlen(boot_command_line) in the commit f5c7310ac73e ("init/main: add checks for the return value of memblock_alloc*()")
Link: https://lore.kernel.org/all/[email protected]/
Fixes: f5c7310ac73e ("init/main: add checks for the return value of memblock_alloc*()") Cc: [email protected] Signed-off-by: Yuntao Wang <[email protected]> Signed-off-by: Masami Hiramatsu (Google) <[email protected]>
show more ...
|
| #
c722cea2 |
| 09-Apr-2024 |
Masami Hiramatsu <[email protected]> |
fs/proc: Skip bootloader comment if no embedded kernel parameters
If the "bootconfig" kernel command-line argument was specified or if the kernel was built with CONFIG_BOOT_CONFIG_FORCE, but if ther
fs/proc: Skip bootloader comment if no embedded kernel parameters
If the "bootconfig" kernel command-line argument was specified or if the kernel was built with CONFIG_BOOT_CONFIG_FORCE, but if there are no embedded kernel parameter, omit the "# Parameters from bootloader:" comment from the /proc/bootconfig file. This will cause automation to fall back to the /proc/cmdline file, which will be identical to the comment in this no-embedded-kernel-parameters case.
Link: https://lore.kernel.org/all/[email protected]/
Fixes: 8b8ce6c75430 ("fs/proc: remove redundant comments from /proc/bootconfig") Signed-off-by: Masami Hiramatsu <[email protected]> Signed-off-by: Paul E. McKenney <[email protected]> Cc: [email protected] Acked-by: Masami Hiramatsu (Google) <[email protected]> Signed-off-by: Masami Hiramatsu (Google) <[email protected]>
show more ...
|
| #
91a1d97e |
| 13-Mar-2024 |
Peter Zijlstra <[email protected]> |
jump_label,module: Don't alloc static_key_mod for __ro_after_init keys
When a static_key is marked ro_after_init, its state will never change (after init), therefore jump_label_update() will never n
jump_label,module: Don't alloc static_key_mod for __ro_after_init keys
When a static_key is marked ro_after_init, its state will never change (after init), therefore jump_label_update() will never need to iterate the entries, and thus module load won't actually need to track this -- avoiding the static_key::next write.
Therefore, mark these keys such that jump_label_add_module() might recognise them and avoid the modification.
Use the special state: 'static_key_linked(key) && !static_key_mod(key)' to denote such keys.
jump_label_add_module() does not exist under CONFIG_JUMP_LABEL=n, so the newly-introduced jump_label_init_ro() can be defined as a nop for that configuration.
[ mingo: Renamed jump_label_ro() to jump_label_init_ro() ]
Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Signed-off-by: Valentin Schneider <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Acked-by: Josh Poimboeuf <[email protected]> Link: https://lore.kernel.org/r/[email protected]
show more ...
|
| #
8f8cd6c0 |
| 27-Feb-2024 |
Changbin Du <[email protected]> |
modules: wait do_free_init correctly
The synchronization here is to ensure the ordering of freeing of a module init so that it happens before W+X checking. It is worth noting it is not that the fre
modules: wait do_free_init correctly
The synchronization here is to ensure the ordering of freeing of a module init so that it happens before W+X checking. It is worth noting it is not that the freeing was not happening, it is just that our sanity checkers raced against the permission checkers which assume init memory is already gone.
Commit 1a7b7d922081 ("modules: Use vmalloc special flag") moved calling do_free_init() into a global workqueue instead of relying on it being called through call_rcu(..., do_free_init), which used to allowed us call do_free_init() asynchronously after the end of a subsequent grace period. The move to a global workqueue broke the gaurantees for code which needed to be sure the do_free_init() would complete with rcu_barrier(). To fix this callers which used to rely on rcu_barrier() must now instead use flush_work(&init_free_wq).
Without this fix, we still could encounter false positive reports in W+X checking since the rcu_barrier() here can not ensure the ordering now.
Even worse, the rcu_barrier() can introduce significant delay. Eric Chanudet reported that the rcu_barrier introduces ~0.1s delay on a PREEMPT_RT kernel.
[ 0.291444] Freeing unused kernel memory: 5568K [ 0.402442] Run /sbin/init as init process
With this fix, the above delay can be eliminated.
Link: https://lkml.kernel.org/r/[email protected] Fixes: 1a7b7d922081 ("modules: Use vmalloc special flag") Signed-off-by: Changbin Du <[email protected]> Tested-by: Eric Chanudet <[email protected]> Acked-by: Luis Chamberlain <[email protected]> Cc: Xiaoyi Su <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
show more ...
|
| #
71261072 |
| 04-Mar-2024 |
Thomas Gleixner <[email protected]> |
smp: Consolidate smp_prepare_boot_cpu()
There is no point in having seven architectures implementing the same empty stub.
Provide a weak function in the init code and remove the stubs.
This also a
smp: Consolidate smp_prepare_boot_cpu()
There is no point in having seven architectures implementing the same empty stub.
Provide a weak function in the init code and remove the stubs.
This also allows to utilize the function on UP which is required to sanitize the per CPU handling on X86 UP.
Signed-off-by: Thomas Gleixner <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Link: https://lore.kernel.org/r/[email protected]
show more ...
|
| #
cb12fd8e |
| 12-Feb-2024 |
Christian Brauner <[email protected]> |
pidfd: add pidfs
This moves pidfds from the anonymous inode infrastructure to a tiny pseudo filesystem. This has been on my todo for quite a while as it will unblock further work that we weren't abl
pidfd: add pidfs
This moves pidfds from the anonymous inode infrastructure to a tiny pseudo filesystem. This has been on my todo for quite a while as it will unblock further work that we weren't able to do simply because of the very justified limitations of anonymous inodes. Moving pidfds to a tiny pseudo filesystem allows:
* statx() on pidfds becomes useful for the first time. * pidfds can be compared simply via statx() and then comparing inode numbers. * pidfds have unique inode numbers for the system lifetime. * struct pid is now stashed in inode->i_private instead of file->private_data. This means it is now possible to introduce concepts that operate on a process once all file descriptors have been closed. A concrete example is kill-on-last-close. * file->private_data is freed up for per-file options for pidfds. * Each struct pid will refer to a different inode but the same struct pid will refer to the same inode if it's opened multiple times. In contrast to now where each struct pid refers to the same inode. Even if we were to move to anon_inode_create_getfile() which creates new inodes we'd still be associating the same struct pid with multiple different inodes.
The tiny pseudo filesystem is not visible anywhere in userspace exactly like e.g., pipefs and sockfs. There's no lookup, there's no complex inode operations, nothing. Dentries and inodes are always deleted when the last pidfd is closed.
We allocate a new inode for each struct pid and we reuse that inode for all pidfds. We use iget_locked() to find that inode again based on the inode number which isn't recycled. We allocate a new dentry for each pidfd that uses the same inode. That is similar to anonymous inodes which reuse the same inode for thousands of dentries. For pidfds we're talking way less than that. There usually won't be a lot of concurrent openers of the same struct pid. They can probably often be counted on two hands. I know that systemd does use separate pidfd for the same struct pid for various complex process tracking issues. So I think with that things actually become way simpler. Especially because we don't have to care about lookup. Dentries and inodes continue to be always deleted.
The code is entirely optional and fairly small. If it's not selected we fallback to anonymous inodes. Heavily inspired by nsfs which uses a similar stashing mechanism just for namespaces.
Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Christian Brauner <[email protected]>
show more ...
|
| #
3c2f8859 |
| 26-Feb-2024 |
Ingo Molnar <[email protected]> |
smp: Provide 'setup_max_cpus' definition on UP too
This was already defined locally by init/main.c, but let's make it generic, as arch/x86/kernel/cpu/topology.c is going to make use of it to have mo
smp: Provide 'setup_max_cpus' definition on UP too
This was already defined locally by init/main.c, but let's make it generic, as arch/x86/kernel/cpu/topology.c is going to make use of it to have more uniform code.
Reviewed-by: Thomas Gleixner <[email protected]> Cc: [email protected] Signed-off-by: Ingo Molnar <[email protected]>
show more ...
|
| #
ac4db926 |
| 24-Jan-2024 |
Geert Uytterhoeven <[email protected]> |
init: remove obsolete arch_call_rest_init() wrapper
Since commit 3570ee046c46b5dc ("s390/smp: keep the original lowcore for CPU 0"), there is no longer any architecture that needs to override arch_c
init: remove obsolete arch_call_rest_init() wrapper
Since commit 3570ee046c46b5dc ("s390/smp: keep the original lowcore for CPU 0"), there is no longer any architecture that needs to override arch_call_rest_init().
Remove the weak wrapper around rest_init(), call rest_init() directly, and make rest_init() static.
Link: https://lkml.kernel.org/r/aa10868bfb176eef4abb8bb4a710b85330792694.1706106183.git.geert@linux-m68k.org Signed-off-by: Geert Uytterhoeven <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Ilya Leoshkevich <[email protected]> Cc: Josh Poimboeuf <[email protected]> Cc: Peter Zijlstra <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
show more ...
|
| #
a5e8131a |
| 30-Jan-2024 |
Christophe Leroy <[email protected]> |
arm64, powerpc, riscv, s390, x86: ptdump: refactor CONFIG_DEBUG_WX
All architectures using the core ptdump functionality also implement CONFIG_DEBUG_WX, and they all do it more or less the same way,
arm64, powerpc, riscv, s390, x86: ptdump: refactor CONFIG_DEBUG_WX
All architectures using the core ptdump functionality also implement CONFIG_DEBUG_WX, and they all do it more or less the same way, with a function called debug_checkwx() that is called by mark_rodata_ro(), which is a substitute to ptdump_check_wx() when CONFIG_DEBUG_WX is set and a no-op otherwise.
Refactor by centrally defining debug_checkwx() in linux/ptdump.h and call debug_checkwx() immediately after calling mark_rodata_ro() instead of calling it at the end of every mark_rodata_ro().
On x86_32, mark_rodata_ro() first checks __supported_pte_mask has _PAGE_NX before calling debug_checkwx(). Now the check is inside the callee ptdump_walk_pgd_level_checkwx().
On powerpc_64, mark_rodata_ro() bails out early before calling ptdump_check_wx() when the MMU doesn't have KERNEL_RO feature. The check is now also done in ptdump_check_wx() as it is called outside mark_rodata_ro().
Link: https://lkml.kernel.org/r/a59b102d7964261d31ead0316a9f18628e4e7a8e.1706610398.git.christophe.leroy@csgroup.eu Signed-off-by: Christophe Leroy <[email protected]> Reviewed-by: Alexandre Ghiti <[email protected]> Cc: Albert Ou <[email protected]> Cc: Alexander Gordeev <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: "Aneesh Kumar K.V (IBM)" <[email protected]> Cc: Borislav Petkov (AMD) <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Christian Borntraeger <[email protected]> Cc: Dave Hansen <[email protected]> Cc: Gerald Schaefer <[email protected]> Cc: Greg KH <[email protected]> Cc: Heiko Carstens <[email protected]> Cc: "H. Peter Anvin" <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Kees Cook <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Michael Ellerman <[email protected]> Cc: "Naveen N. Rao" <[email protected]> Cc: Nicholas Piggin <[email protected]> Cc: Palmer Dabbelt <[email protected]> Cc: Paul Walmsley <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Phong Tran <[email protected]> Cc: Russell King <[email protected]> Cc: Steven Price <[email protected]> Cc: Sven Schnelle <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Vasily Gorbik <[email protected]> Cc: Will Deacon <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
show more ...
|
| #
bf52b1ac |
| 09-Feb-2024 |
Tejun Heo <[email protected]> |
async: Use a dedicated unbound workqueue with raised min_active
Async can schedule a number of interdependent work items. However, since 5797b1c18919 ("workqueue: Implement system-wide nr_active enf
async: Use a dedicated unbound workqueue with raised min_active
Async can schedule a number of interdependent work items. However, since 5797b1c18919 ("workqueue: Implement system-wide nr_active enforcement for unbound workqueues"), unbound workqueues have separate min_active which sets the number of interdependent work items that can be handled. This default value is 8 which isn't sufficient for async and can lead to stalls during resume from suspend in some cases.
Let's use a dedicated unbound workqueue with raised min_active.
Link: http://lkml.kernel.org/r/[email protected] Reported-by: Marek Szyprowski <[email protected]> Cc: Rafael J. Wysocki <[email protected]> Tested-by: Marek Szyprowski <[email protected]> Signed-off-by: Tejun Heo <[email protected]>
show more ...
|
|
Revision tags: v6.8-rc1, v6.7, v6.7-rc8, v6.7-rc7 |
|
| #
398ec3e9 |
| 21-Dec-2023 |
Christophe Leroy <[email protected]> |
init: Declare rodata_enabled and mark_rodata_ro() at all time
Declaring rodata_enabled and mark_rodata_ro() at all time helps removing related #ifdefery in C files.
Signed-off-by: Christophe Leroy
init: Declare rodata_enabled and mark_rodata_ro() at all time
Declaring rodata_enabled and mark_rodata_ro() at all time helps removing related #ifdefery in C files.
Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Luis Chamberlain <[email protected]>
show more ...
|
|
Revision tags: v6.7-rc6, v6.7-rc5, v6.7-rc4, v6.7-rc3, v6.7-rc2, v6.7-rc1, v6.6 |
|
| #
8001f493 |
| 27-Oct-2023 |
Krister Johansen <[email protected]> |
proc: sysctl: prevent aliased sysctls from getting passed to init
The code that checks for unknown boot options is unaware of the sysctl alias facility, which maps bootparams to sysctl values. If a
proc: sysctl: prevent aliased sysctls from getting passed to init
The code that checks for unknown boot options is unaware of the sysctl alias facility, which maps bootparams to sysctl values. If a user sets an old value that has a valid alias, a message about an invalid parameter will be printed during boot, and the parameter will get passed to init. Fix by checking for the existence of aliased parameters in the unknown boot parameter code. If an alias exists, don't return an error or pass the value to init.
Signed-off-by: Krister Johansen <[email protected]> Cc: [email protected] Fixes: 0a477e1ae21b ("kernel/sysctl: support handling command line aliases") Signed-off-by: Luis Chamberlain <[email protected]>
show more ...
|
|
Revision tags: v6.6-rc7, v6.6-rc6, v6.6-rc5, v6.6-rc4, v6.6-rc3, v6.6-rc2, v6.6-rc1, v6.5, v6.5-rc7, v6.5-rc6 |
|
| #
2930155b |
| 08-Aug-2023 |
Tejun Heo <[email protected]> |
workqueue: Initialize unbound CPU pods later in the boot
During boot, to initialize unbound CPU pods, wq_pod_init() was called from workqueue_init(). This is early enough for NUMA nodes to be set up
workqueue: Initialize unbound CPU pods later in the boot
During boot, to initialize unbound CPU pods, wq_pod_init() was called from workqueue_init(). This is early enough for NUMA nodes to be set up but before SMP is brought up and CPU topology information is populated.
Workqueue is in the process of improving CPU locality for unbound workqueues and will need access to topology information during pod init. This adds a new init function workqueue_init_topology() which is called after CPU topology information is available and replaces wq_pod_init().
As unbound CPU pods are now initialized after workqueues are activated, we need to revisit the workqueues to apply the pod configuration. Workqueues which are created before workqueue_init_topology() are set up so that they always use the default worker pool. After pods are set up in workqueue_init_topology(), wq_update_pod() is called on all existing workqueues to update the pool associations accordingly.
Note that wq_update_pod_attrs_buf allocation is moved to workqueue_init_early(). This isn't necessary right now but enables further generalization of pod handling in the future.
This patch changes the initialization sequence but the end result should be the same.
Signed-off-by: Tejun Heo <[email protected]>
show more ...
|
|
Revision tags: v6.5-rc5, v6.5-rc4, v6.5-rc3, v6.5-rc2, v6.5-rc1, v6.4, v6.4-rc7 |
|
| #
439e1757 |
| 13-Jun-2023 |
Thomas Gleixner <[email protected]> |
init, x86: Move mem_encrypt_init() into arch_cpu_finalize_init()
Invoke the X86ism mem_encrypt_init() from X86 arch_cpu_finalize_init() and remove the weak fallback from the core code.
No functiona
init, x86: Move mem_encrypt_init() into arch_cpu_finalize_init()
Invoke the X86ism mem_encrypt_init() from X86 arch_cpu_finalize_init() and remove the weak fallback from the core code.
No functional change.
Signed-off-by: Thomas Gleixner <[email protected]> Link: https://lore.kernel.org/r/[email protected]
show more ...
|
| #
9df9d2f0 |
| 13-Jun-2023 |
Thomas Gleixner <[email protected]> |
init: Invoke arch_cpu_finalize_init() earlier
X86 is reworking the boot process so that initializations which are not required during early boot can be moved into the late boot process and out of th
init: Invoke arch_cpu_finalize_init() earlier
X86 is reworking the boot process so that initializations which are not required during early boot can be moved into the late boot process and out of the fragile and restricted initial boot phase.
arch_cpu_finalize_init() is the obvious place to do such initializations, but arch_cpu_finalize_init() is invoked too late in start_kernel() e.g. for initializing the FPU completely. fork_init() requires that the FPU is initialized as the size of task_struct on X86 depends on the size of the required FPU register buffer.
Fortunately none of the init calls between calibrate_delay() and arch_cpu_finalize_init() is relevant for the functionality of arch_cpu_finalize_init().
Invoke it right after calibrate_delay() where everything which is relevant for arch_cpu_finalize_init() has been set up already.
No functional change intended.
Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Rick Edgecombe <[email protected]> Link: https://lore.kernel.org/r/[email protected]
show more ...
|