Re: [PATCH v6 0/4] Introduce mseal()

2024-01-12 Thread Randy Dunlap
>>> >> >> Jeff, >> Building arm64 defconfig, on linux-next-20240112, I get: >> > I don't quite get how this is related to my change. > Can you please send me the steps to reproduce ? I don't usually build arm. I don't get how it's related either, but whe

[linux-next:master] BUILD REGRESSION 8d04a7e2ee3fd6aabb8096b00c64db0d735bc874

2024-01-12 Thread kernel test robot
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master branch HEAD: 8d04a7e2ee3fd6aabb8096b00c64db0d735bc874 Add linux-next specific files for 20240112 Error/Warning: (recently discovered and may have been fixed) WARNING: modpost: vmlinux: section mismatch

Re: [PATCH v6 0/4] Introduce mseal()

2024-01-12 Thread Jeff Xu
On Fri, Jan 12, 2024 at 6:20 PM Randy Dunlap wrote: > > > > On 1/11/24 15:41, jef...@chromium.org wrote: > > From: Jeff Xu > > > > This patchset proposes a new mseal() syscall for the Linux kernel. > > > > Jeff, > Building arm64 defconfig, on linux-

Re: [PATCH v6 4/4] mseal:add documentation

2024-01-12 Thread Jeff Xu
ace-api/mseal.rst | 181 ++ > > 1 file changed, 181 insertions(+) > > create mode 100644 Documentation/userspace-api/mseal.rst > > > > To prevent the following documentation build warning: > > linux-next-20240112/Documentation/userspace-api/mse

Re: [PATCH v6 0/4] Introduce mseal()

2024-01-12 Thread Randy Dunlap
On 1/11/24 15:41, jef...@chromium.org wrote: > From: Jeff Xu > > This patchset proposes a new mseal() syscall for the Linux kernel. > Jeff, Building arm64 defconfig, on linux-next-20240112, I get: CC arch/arm64/kernel/asm-offsets.s In file included from ../include/uapi/

Re: [PATCH v6 4/4] mseal:add documentation

2024-01-12 Thread Randy Dunlap
e mode 100644 Documentation/userspace-api/mseal.rst > To prevent the following documentation build warning: linux-next-20240112/Documentation/userspace-api/mseal.rst: WARNING: document isn't included in any toctree please add the following to your patch 4/4: diff -- a/Documentation/userspace-

Re: [PATCH v2 5/7] selftests/mm: hugetlb-read-hwpoison: conform test to TAP format output

2024-01-12 Thread Jiaqi Yan
On Thu, Jan 11, 2024 at 11:21 PM Muhammad Usama Anjum wrote: > > Conform the layout, informational and status messages to TAP. No > functional change is intended other than the layout of output messages. > > Signed-off-by: Muhammad Usama Anjum > --- > Tested this by reverting the patch

Re: [PATCH v2 0/6] IOMMUFD: Deliver IO page faults to user space

2024-01-12 Thread Joel Granados
On Thu, Oct 26, 2023 at 10:49:24AM +0800, Lu Baolu wrote: > Hi folks, > > This series implements the functionality of delivering IO page faults to > user space through the IOMMUFD framework for nested translation. Nested > translation is a hardware feature that supports two-stage translation >

Re: [PATCH bpf-next v2 10/15] bpf: Track spilled unbounded scalars

2024-01-12 Thread Alexei Starovoitov
On Fri, Jan 12, 2024 at 12:44 PM Maxim Mikityanskiy wrote: > > On Fri, 12 Jan 2024 at 11:10:57 -0800, Alexei Starovoitov wrote: > > On Mon, Jan 8, 2024 at 12:53 PM Maxim Mikityanskiy > > wrote: > > > > > > From: Maxim Mikityanskiy > > > > > > Support the pattern where an unbounded scalar is

Re: [PATCH bpf-next v2 10/15] bpf: Track spilled unbounded scalars

2024-01-12 Thread Maxim Mikityanskiy
On Fri, 12 Jan 2024 at 11:10:57 -0800, Alexei Starovoitov wrote: > On Mon, Jan 8, 2024 at 12:53 PM Maxim Mikityanskiy > wrote: > > > > From: Maxim Mikityanskiy > > > > Support the pattern where an unbounded scalar is spilled to the stack, > > then boundary checks are performed on the src

[PATCH 6/6] of: Add KUnit test to confirm DTB is loaded

2024-01-12 Thread Stephen Boyd
Add a KUnit test that confirms a DTB has been loaded, i.e. there is a root node, and that the of_have_populated_dt() API works properly. Cc: Rob Herring Cc: Frank Rowand Cc: David Gow Cc: Brendan Higgins Signed-off-by: Stephen Boyd --- drivers/of/.kunitconfig | 3 ++ drivers/of/Kconfig

[PATCH 5/6] of: unittest: treat missing of_root as error instead of fixing up

2024-01-12 Thread Stephen Boyd
From: Frank Rowand unflatten_device_tree() now ensures that the 'of_root' node is populated with the root of a default empty devicetree. Remove the unittest code that created 'of_root' if it was missing. Verify that 'of_root' is valid before attempting to attach the testcase-data subtree. Remove

[PATCH 4/6] of: Create of_root if no dtb provided by firmware

2024-01-12 Thread Stephen Boyd
From: Frank Rowand When enabling CONFIG_OF on a platform where 'of_root' is not populated by firmware, we end up without a root node. In order to apply overlays and create subnodes of the root node, we need one. Create this root node by unflattening an empty builtin dtb. If firmware provides a

[PATCH 3/6] of: Always unflatten in unflatten_and_copy_device_tree()

2024-01-12 Thread Stephen Boyd
We want to populate an empty DT whenever CONFIG_OF is enabled so that overlays can be applied and the DT unit tests can be run. Make unflatten_and_copy_device_tree() stop printing a warning if the 'initial_boot_params' pointer is NULL. Instead, simply copy the dtb if there is one and then

[PATCH 2/6] um: Unconditionally call unflatten_device_tree()

2024-01-12 Thread Stephen Boyd
Call this function unconditionally so that we can populate an empty DTB on platforms that don't boot with a command line provided DTB. There's no harm in calling unflatten_device_tree() unconditionally. If there isn't a valid initial_boot_params dtb then unflatten_device_tree() returns early.

[PATCH 1/6] arm64: Unconditionally call unflatten_device_tree()

2024-01-12 Thread Stephen Boyd
Call this function unconditionally so that we can populate an empty DTB on platforms that don't boot with a firmware provided or builtin DTB. There's no harm in calling unflatten_device_tree() unconditionally. If there isn't a valid initial_boot_params dtb then unflatten_device_tree() returns

[PATCH 0/6] of: populate of_root node if bootloader doesn't

2024-01-12 Thread Stephen Boyd
Arch maintainers, please ack/review patches. This is a resend of a series from Frank last year[1]. I worked in Rob's review comments to unconditionally call unflatten_device_tree() and fixup/audit calls to of_have_populated_dt() so that behavior doesn't change. I need this series so I can add DT

Re: [PATCH bpf-next v3 0/3] Annotate kfuncs in .BTF_ids section

2024-01-12 Thread Daniel Xu
On Fri, Jan 12, 2024 at 05:20:39PM +0100, Jiri Olsa wrote: > On Sat, Jan 06, 2024 at 11:24:07AM -0700, Daniel Xu wrote: > > === Description === > > > > This is a bpf-treewide change that annotates all kfuncs as such inside > > .BTF_ids. This annotation eventually allows us to automatically

Re: [PATCH bpf-next v2 10/15] bpf: Track spilled unbounded scalars

2024-01-12 Thread Alexei Starovoitov
On Mon, Jan 8, 2024 at 12:53 PM Maxim Mikityanskiy wrote: > > From: Maxim Mikityanskiy > > Support the pattern where an unbounded scalar is spilled to the stack, > then boundary checks are performed on the src register, after which the > stack frame slot is refilled into a register. > > Before

RE: [PATCH 12/12] selftests/net: Add TCP-AO key-management test

2024-01-12 Thread Nassiri, Mohammad
>-Original Message- >From: Dmitry Safonov >Sent: Thursday, December 14, 2023 9:36 PM >+ >+static void end_server(const char *tst_name, int sk, >+ struct tcp_ao_counters *begin) { >+ struct tcp_ao_counters end; >+ >+ if (test_get_tcp_ao_counters(sk, )) >+

RE: [PATCH 01/12] selftests/net: Add TCP-AO library

2024-01-12 Thread Nassiri, Mohammad
Hi Dmitry, First, thank you for submitting this very helpful set of tcp-ao selftests! >-Original Message- >From: Dmitry Safonov >Sent: Thursday, December 14, 2023 9:36 PM >To: Shuah Khan ; David Ahern ; >David S. Miller ; Eric Dumazet >; Jakub Kicinski ; Paolo Abeni > >Cc: Dmitry

RE: [PATCH v2 4/6] iommufd: Deliver fault messages to user space

2024-01-12 Thread Shameerali Kolothum Thodi
> -Original Message- > From: Lu Baolu > Sent: Thursday, October 26, 2023 3:49 AM > To: Jason Gunthorpe ; Kevin Tian ; Joerg > Roedel ; Will Deacon ; Robin Murphy > ; Jean-Philippe Brucker ; > Nicolin Chen ; Yi Liu ; Jacob Pan > > Cc: io...@lists.linux.dev;

[PATCH v6 3/3] selftests: livepatch: Test livepatching a heavily called syscall

2024-01-12 Thread Marcos Paulo de Souza
The test proves that a syscall can be livepatched. It is interesting because syscalls are called a tricky way. Also the process gets livepatched either when sleeping in the userspace or when entering or leaving the kernel space. The livepatch is a bit tricky: 1. The syscall function name is

[PATCH v6 2/3] livepatch: Move tests from lib/livepatch to selftests/livepatch

2024-01-12 Thread Marcos Paulo de Souza
The modules are being moved from lib/livepatch to tools/testing/selftests/livepatch/test_modules. This code moving will allow writing more complex tests, like for example an userspace C code that will call a livepatched kernel function. The modules are now built as out-of-tree modules, but being

[PATCH v6 1/3] kselftests: lib.mk: Add TEST_GEN_MODS_DIR variable

2024-01-12 Thread Marcos Paulo de Souza
Add TEST_GEN_MODS_DIR variable for kselftests. It can point to a directory containing kernel modules that will be used by selftest scripts. The modules are built as external modules for the running kernel. As a result they are always binary compatible and the same tests can be used for older or

[PATCH v6 0/3] livepatch: Move modules to selftests and add a new test

2024-01-12 Thread Marcos Paulo de Souza
Changes in v6: - Rebased on top of 70d201a40823 (thanks Alexander Gordeev!) - Resolved a conflict because of 43e8832fed08 being reverted - Resolved a missing static declaration for lp_sys_getpid, since -Wmissing-prototypes warning was enabled. - Retested everything, from running the livepatch

Re: [PATCH bpf-next v3 0/3] Annotate kfuncs in .BTF_ids section

2024-01-12 Thread Jiri Olsa
On Sat, Jan 06, 2024 at 11:24:07AM -0700, Daniel Xu wrote: > === Description === > > This is a bpf-treewide change that annotates all kfuncs as such inside > .BTF_ids. This annotation eventually allows us to automatically generate > kfunc prototypes from bpftool. > > We store this metadata

Re: [PATCH] selftests/livepatch: fix and refactor new dmesg message code

2024-01-12 Thread Miroslav Benes
On Wed, 20 Dec 2023, Joe Lawrence wrote: > The livepatching kselftests rely on comparing expected vs. observed > dmesg output. After each test, new dmesg entries are determined by the > 'comm' utility comparing a saved, pre-test copy of dmesg to post-test > dmesg output. > > Alexander reports

Re: [PATCH 0/3] Update LLVM Phabricator and Bugzilla links

2024-01-12 Thread Alex Deucher
On Tue, Jan 9, 2024 at 5:26 PM Nathan Chancellor wrote: > > This series updates all instances of LLVM Phabricator and Bugzilla links > to point to GitHub commits directly and LLVM's Bugzilla to GitHub issue > shortlinks respectively. > > I split up the Phabricator patch into BPF selftests and the

Re: [PATCH v3] selftests/landlock:Fix two build issues

2024-01-12 Thread Mickaël Salaün
On Fri, Jan 12, 2024 at 03:12:45PM +0800, Hu Yadi wrote: > From: "Hu.Yadi" > > Two issues comes up while building selftest/landlock on my side > (gcc 7.3/glibc-2.28/kernel-4.19) > > the first one is as to gettid > > net_test.c: In function ‘set_service’: > net_test.c:91:45: warning: implicit

[PATCH V13 7/7] Documentation: introduce amd-pstate preferrd core mode kernel command line options

2024-01-12 Thread Meng Li
amd-pstate driver support enable/disable preferred core. Default enabled on platforms supporting amd-pstate preferred core. Disable amd-pstate preferred core with "amd_prefcore=disable" added to the kernel command line. Signed-off-by: Meng Li Reviewed-by: Mario Limonciello Reviewed-by: Wyes

[PATCH V13 6/7] Documentation: amd-pstate: introduce amd-pstate preferred core

2024-01-12 Thread Meng Li
Introduce amd-pstate preferred core. check preferred core state set by the kernel parameter: $ cat /sys/devices/system/cpu/amd-pstate/prefcore Tested-by: Oleksandr Natalenko Reviewed-by: Wyes Karny Reviewed-by: Mario Limonciello Reviewed-by: Huang Rui Reviewed-by: Perry Yuan Signed-off-by:

[PATCH V13 5/7] cpufreq: amd-pstate: Update amd-pstate preferred core ranking dynamically

2024-01-12 Thread Meng Li
Preferred core rankings can be changed dynamically by the platform based on the workload and platform conditions and accounting for thermals and aging. When this occurs, cpu priority need to be set. Tested-by: Oleksandr Natalenko Reviewed-by: Mario Limonciello Reviewed-by: Wyes Karny

[PATCH V13 4/7] cpufreq: Add a notification message that the highest perf has changed

2024-01-12 Thread Meng Li
BIOS issues the notify 0x85 to OS that the highest performance changed. And it will affect the ranking of the preferred core. AMD-pstate driver will set the priority of cores based on the preferred core ranking. Tested-by: Oleksandr Natalenko Reviewed-by: Mario Limonciello Reviewed-by: Huang

[PATCH V13 3/7] cpufreq: amd-pstate: Enable amd-pstate preferred core supporting.

2024-01-12 Thread Meng Li
amd-pstate driver utilizes the functions and data structures provided by the ITMT architecture to enable the scheduler to favor scheduling on cores which can be get a higher frequency with lower voltage. We call it amd-pstate preferrred core. Here sched_set_itmt_core_prio() is called to set

[PATCH V13 2/7] ACPI: CPPC: Add get the highest performance cppc control

2024-01-12 Thread Meng Li
Add support for getting the highest performance to the generic CPPC driver. This enables downstream drivers such as amd-pstate to discover and use these values. Please refer to Chapter 8.4.6.1.1.1. Highest Performance of ACPI Specification 6.5 for details on continuous performance control of

[PATCH V13 1/7] x86: Drop CPU_SUP_INTEL from SCHED_MC_PRIO for the expansion.

2024-01-12 Thread Meng Li
amd-pstate driver also uses SCHED_MC_PRIO, so decouple the requirement of CPU_SUP_INTEL from the dependencies to allow compilation in kernels without Intel CPU support. Tested-by: Oleksandr Natalenko Reviewed-by: Mario Limonciello Reviewed-by: Huang Rui Reviewed-by: Perry Yuan Signed-off-by:

[PATCH V13 0/7] amd-pstate preferred core

2024-01-12 Thread Meng Li
Hi all: The core frequency is subjected to the process variation in semiconductors. Not all cores are able to reach the maximum frequency respecting the infrastructure limits. Consequently, AMD has redefined the concept of maximum frequency of a part. This means that a fraction of cores can reach