user/sven/linux.git, branch v6.6.18

Linux 6.6.18

2024-02-23T08:25:28Z

Link: https://lore.kernel.org/r/20240220205637.572693592@linuxfoundation.org Tested-by: SeongJae Park Tested-by: Allen Pais Tested-by: Bagas Sanjaya Tested-by: Takeshi Ogasawara Tested-by: Jon Hunter Tested-by: Shuah Khan Link: https://lore.kernel.org/r/20240221125953.770767246@linuxfoundation.org Tested-by: Takeshi Ogasawara Tested-by: Allen Pais Tested-by: Jon Hunter Tested-by: Florian Fainelli Tested-by: Ron Economos Tested-by: Bagas Sanjaya Tested-by: kernelci.org bot Tested-by: Linux Kernel Functional Testing Tested-by: Harshit Mogalapalli Tested-by: Kelsey Steele Signed-off-by: Greg Kroah-Hartman

tracing: Fix a NULL vs IS_ERR() bug in event_subsystem_dir()

2024-02-23T08:25:28Z

commit 5264a2f4bb3baf712e19f1f053caaa8d7d3afa2e upstream. The eventfs_create_dir() function returns error pointers, it never returns NULL. Update the check to reflect that. Link: https://lore.kernel.org/linux-trace-kernel/ff641474-84e2-46a7-9d7a-62b251a1050c@moroto.mountain Cc: Masami Hiramatsu Fixes: 5790b1fb3d67 ("eventfs: Remove eventfs_file and just use eventfs_inode") Signed-off-by: Dan Carpenter Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman

tracing: Make system_callback() function static

2024-02-23T08:25:28Z

commit 5ddd8baa4857709b4e5d84b376d735152851955b upstream. The system_callback() function in trace_events.c is only used within that file. The "static" annotation was missed. Fixes: 5790b1fb3d672 ("eventfs: Remove eventfs_file and just use eventfs_inode") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202310051743.y9EobbUr-lkp@intel.com/ Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman

Documentation/arch/ia64/features.rst: fix kernel-feat directive

2024-02-23T08:25:28Z

My mainline commit c48a7c44a1d0 ("docs: kernel_feat.py: fix potential command injection") contains a bug which can manifests like this when building the documentation: Sphinx parallel build error: UnboundLocalError: local variable 'fname' referenced before assignment make[2]: *** [Documentation/Makefile:102: htmldocs] Error 2 However, this only appears when there exists a '.. kernel-feat::' directive that points to a non-existent file, which isn't the case in mainline. When this commit was backported to stable 6.6, it didn't change Documentation/arch/ia64/features.rst since ia64 was removed in 6.7 in commit cf8e8658100d ("arch: Remove Itanium (IA-64) architecture"). This lead to the build failure seen above -- but only in stable kernels. This patch fixes the backport and should only be applied to kernels where Documentation/arch/ia64/features.rst exists and commit c48a7c44a1d0 has also been applied. A second patch will follow to fix kernel_feat.py in mainline so that it doesn't error out when the '.. kernel-feat::' directive points to a nonexistent file. Link: https://lore.kernel.org/all/ZbkfGst991YHqJHK@fedora64.linuxtx.org/ Fixes: e961f8c6966a ("docs: kernel_feat.py: fix potential command injection") # stable 6.6.15 Reported-by: Justin Forbes Reported-by: Salvatore Bonaccorso Signed-off-by: Vegard Nossum Signed-off-by: Greg Kroah-Hartman

x86/barrier: Do not serialize MSR accesses on AMD

2024-02-23T08:25:27Z

commit 04c3024560d3a14acd18d0a51a1d0a89d29b7eb5 upstream. AMD does not have the requirement for a synchronization barrier when acccessing a certain group of MSRs. Do not incur that unnecessary penalty there. There will be a CPUID bit which explicitly states that a MFENCE is not needed. Once that bit is added to the APM, this will be extended with it. While at it, move to processor.h to avoid include hell. Untangling that file properly is a matter for another day. Some notes on the performance aspect of why this is relevant, courtesy of Kishon VijayAbraham : On a AMD Zen4 system with 96 cores, a modified ipi-bench[1] on a VM shows x2AVIC IPI rate is 3% to 4% lower than AVIC IPI rate. The ipi-bench is modified so that the IPIs are sent between two vCPUs in the same CCX. This also requires to pin the vCPU to a physical core to prevent any latencies. This simulates the use case of pinning vCPUs to the thread of a single CCX to avoid interrupt IPI latency. In order to avoid run-to-run variance (for both x2AVIC and AVIC), the below configurations are done: 1) Disable Power States in BIOS (to prevent the system from going to lower power state) 2) Run the system at fixed frequency 2500MHz (to prevent the system from increasing the frequency when the load is more) With the above configuration: *) Performance measured using ipi-bench for AVIC: Average Latency: 1124.98ns [Time to send IPI from one vCPU to another vCPU] Cumulative throughput: 42.6759M/s [Total number of IPIs sent in a second from 48 vCPUs simultaneously] *) Performance measured using ipi-bench for x2AVIC: Average Latency: 1172.42ns [Time to send IPI from one vCPU to another vCPU] Cumulative throughput: 40.9432M/s [Total number of IPIs sent in a second from 48 vCPUs simultaneously] From above, x2AVIC latency is ~4% more than AVIC. However, the expectation is x2AVIC performance to be better or equivalent to AVIC. Upon analyzing the perf captures, it is observed significant time is spent in weak_wrmsr_fence() invoked by x2apic_send_IPI(). With the fix to skip weak_wrmsr_fence() *) Performance measured using ipi-bench for x2AVIC: Average Latency: 1117.44ns [Time to send IPI from one vCPU to another vCPU] Cumulative throughput: 42.9608M/s [Total number of IPIs sent in a second from 48 vCPUs simultaneously] Comparing the performance of x2AVIC with and without the fix, it can be seen the performance improves by ~4%. Performance captured using an unmodified ipi-bench using the 'mesh-ipi' option with and without weak_wrmsr_fence() on a Zen4 system also showed significant performance improvement without weak_wrmsr_fence(). The 'mesh-ipi' option ignores CCX or CCD and just picks random vCPU. Average throughput (10 iterations) with weak_wrmsr_fence(), Cumulative throughput: 4933374 IPI/s Average throughput (10 iterations) without weak_wrmsr_fence(), Cumulative throughput: 6355156 IPI/s [1] https://github.com/bytedance/kvm-utils/tree/master/microbenchmark/ipi-bench Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/r/20230622095212.20940-1-bp@alien8.de Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Greg Kroah-Hartman

dm: limit the number of targets and parameter size area

2024-02-23T08:25:27Z

commit bd504bcfec41a503b32054da5472904b404341a4 upstream. The kvmalloc function fails with a warning if the size is larger than INT_MAX. The warning was triggered by a syscall testing robot. In order to avoid the warning, this commit limits the number of targets to 1048576 and the size of the parameter area to 1073741824. Signed-off-by: Mikulas Patocka Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman

nilfs2: fix potential bug in end_buffer_async_write

2024-02-23T08:25:27Z

commit 5bc09b397cbf1221f8a8aacb1152650c9195b02b upstream. According to a syzbot report, end_buffer_async_write(), which handles the completion of block device writes, may detect abnormal condition of the buffer async_write flag and cause a BUG_ON failure when using nilfs2. Nilfs2 itself does not use end_buffer_async_write(). But, the async_write flag is now used as a marker by commit 7f42ec394156 ("nilfs2: fix issue with race condition of competition between segments for dirty blocks") as a means of resolving double list insertion of dirty blocks in nilfs_lookup_dirty_data_buffers() and nilfs_lookup_node_buffers() and the resulting crash. This modification is safe as long as it is used for file data and b-tree node blocks where the page caches are independent. However, it was irrelevant and redundant to also introduce async_write for segment summary and super root blocks that share buffers with the backing device. This led to the possibility that the BUG_ON check in end_buffer_async_write would fail as described above, if independent writebacks of the backing device occurred in parallel. The use of async_write for segment summary buffers has already been removed in a previous change. Fix this issue by removing the manipulation of the async_write flag for the remaining super root block buffer. Link: https://lkml.kernel.org/r/20240203161645.4992-1-konishi.ryusuke@gmail.com Fixes: 7f42ec394156 ("nilfs2: fix issue with race condition of competition between segments for dirty blocks") Signed-off-by: Ryusuke Konishi Reported-by: syzbot+5c04210f7c7f897c1e7f@syzkaller.appspotmail.com Closes: https://lkml.kernel.org/r/00000000000019a97c05fd42f8c8@google.com Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman

of: property: Add in-ports/out-ports support to of_graph_get_port_parent()

2024-02-23T08:25:27Z

commit 8f1e0d791b5281f3a38620bc7c57763dc551be15 upstream. Similar to the existing "ports" node name, coresight device tree bindings have added "in-ports" and "out-ports" as standard node names for a collection of ports. Add support for these name to of_graph_get_port_parent() so that remote-endpoint parsing can find the correct parent node for these coresight ports too. Signed-off-by: Saravana Kannan Link: https://lore.kernel.org/r/20240207011803.2637531-4-saravanak@google.com Signed-off-by: Rob Herring Signed-off-by: Greg Kroah-Hartman

sched/membarrier: reduce the ability to hammer on sys_membarrier

2024-02-23T08:25:27Z

commit 944d5fe50f3f03daacfea16300e656a1691c4a23 upstream. On some systems, sys_membarrier can be very expensive, causing overall slowdowns for everything. So put a lock on the path in order to serialize the accesses to prevent the ability for this to be called at too high of a frequency and saturate the machine. Reviewed-and-tested-by: Mathieu Desnoyers Acked-by: Borislav Petkov Fixes: 22e4ebb97582 ("membarrier: Provide expedited private command") Fixes: c5f58bd58f43 ("membarrier: Provide GLOBAL_EXPEDITED command") Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

x86/efistub: Use 1:1 file:memory mapping for PE/COFF .compat section

2024-02-23T08:25:27Z

commit 1ad55cecf22f05f1c884adf63cc09d3c3e609ebf upstream. The .compat section is a dummy PE section that contains the address of the 32-bit entrypoint of the 64-bit kernel image if it is bootable from 32-bit firmware (i.e., CONFIG_EFI_MIXED=y) This section is only 8 bytes in size and is only referenced from the loader, and so it is placed at the end of the memory view of the image, to avoid the need for padding it to 4k, which is required for sections appearing in the middle of the image. Unfortunately, this violates the PE/COFF spec, and even if most EFI loaders will work correctly (including the Tianocore reference implementation), PE loaders do exist that reject such images, on the basis that both the file and memory views of the file contents should be described by the section headers in a monotonically increasing manner without leaving any gaps. So reorganize the sections to avoid this issue. This results in a slight padding overhead (< 4k) which can be avoided if desired by disabling CONFIG_EFI_MIXED (which is only needed in rare cases these days) Fixes: 3e3eabe26dc8 ("x86/boot: Increase section and file alignment to 4k/512") Reported-by: Mike Beaton Link: https://lkml.kernel.org/r/CAHzAAWQ6srV6LVNdmfbJhOwhBw5ZzxxZZ07aHt9oKkfYAdvuQQ%40mail.gmail.com Signed-off-by: Ard Biesheuvel Signed-off-by: Greg Kroah-Hartman