On Thu, Oct 31, 2024 at 09:06:09PM +, Edgecombe, Rick P wrote:
> On Thu, 2024-10-31 at 19:25 +0000, Mark Brown wrote:
> > base-commit: d17cd7b7cc92d37ee8b2df8f975fc859a261f4dc
> Where can I find this base commit?
Ah, that's still my branch from when I posted what's no
-by: Mark Brown
---
arch/arm64/mm/gcs.c | 54 +-
arch/x86/include/asm/shstk.h | 11 +++--
arch/x86/kernel/process.c| 2 +-
arch/x86/kernel/shstk.c | 57 +---
include/asm-generic/cacheflush.h | 11 +
include/linux/sched
., this should be overly cautious.
Acked-by: Shuah Khan
Signed-off-by: Mark Brown
---
tools/testing/selftests/clone3/clone3.c | 143 +-
tools/testing/selftests/clone3/clone3_selftests.h | 63 ++
2 files changed, 205 insertions(+), 1 deletion(-)
diff --git a
iewed-by: Catalin Marinas
Signed-off-by: Mark Brown
---
tools/testing/selftests/clone3/clone3.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/tools/testing/selftests/clone3/clone3.c
b/tools/testing/selftests/clone3/clone3.c
index
e066b201fa64eb17c55939b7cec18ac5d10
change.
Reviewed-by: Kees Cook
Tested-by: Kees Cook
Acked-by: Shuah Khan
Reviewed-by: Catalin Marinas
Signed-off-by: Mark Brown
---
tools/testing/selftests/clone3/clone3.c | 77 -
1 file changed, 37 insertions(+), 40 deletions(-)
diff --git a/tools/testing
s.
Reviewed-by: Kees Cook
Tested-by: Kees Cook
Acked-by: Shuah Khan
Reviewed-by: Catalin Marinas
Signed-off-by: Mark Brown
---
tools/testing/selftests/clone3/clone3_selftests.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/tools/testing/selftests/clone3/clone3_selftests.h
b/tools/te
interfaces.
Reviewed-by: Rick Edgecombe
Reviewed-by: Kees Cook
Tested-by: Kees Cook
Acked-by: Shuah Khan
Signed-off-by: Mark Brown
---
tools/testing/selftests/ksft_shstk.h | 98
1 file changed, 98 insertions(+)
diff --git a/tools/testing/selftests/ksft_shstk.h
b
feature let's provide some documentation covering the common aspects.
Reviewed-by: Catalin Marinas
Reviewed-by: Kees Cook
Tested-by: Kees Cook
Acked-by: Shuah Khan
Signed-off-by: Mark Brown
---
Documentation/userspace-api/index.rst| 1 +
Documentation/userspace-api/shadow_stack.rst
error code
on failure.
Acked-by: Deepak Gupta
Signed-off-by: Mark Brown
---
arch/arm64/include/asm/gcs.h | 8
arch/arm64/kernel/process.c | 8
arch/arm64/mm/gcs.c | 8
3 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm64/include/asm/gcs.h b
..@kernel.org/T/#mc58f97f27461749ccf400ebabf6f9f937116a86b
Signed-off-by: Mark Brown
---
Changes in v12:
- Add the regular prctl() to the userspace API document since arm64
support is queued in -next.
- Link to v11:
https://lore.kernel.org/r/20241005-clone3-shadow-stack-v11-0-2a6a2bd6d...@kernel.
On Sat, Oct 05, 2024 at 11:31:27AM +0100, Mark Brown wrote:
> The kernel has recently added support for shadow stacks, currently
> x86 only using their CET feature but both arm64 and RISC-V have
> equivalent features (GCS and Zicfiss respectively), I am actively
> working on GCS[1].
ignal raise
interval when all the children are started and we start sending signals.
Signed-off-by: Mark Brown
---
tools/testing/selftests/arm64/fp/fp-stress.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/arm64/fp/fp-stress.c
b/tools/testing/self
One of the things that fp-stress does to stress the floating point
context switching is send signals to the test threads it spawns.
Currently we do this once per second but as suggested by Mark Rutland if
we increase this we can improve the chances of triggering any issues
with context switching
moved the signal generation out of the main
supervisor thread, though we should also consider that he percentage of
time that we spend interacting with the floating point state is also a
consideration.
Suggested-by: Mark Rutland
Signed-off-by: Mark Brown
---
tools/testing/selftests/arm64/fp/fp
On Tue, Oct 29, 2024 at 03:43:37PM +, Mark Rutland wrote:
> On those emulated platforms (FVP?), does this change trigger the faukure
> more often?
Yes.
> I gave this a quick test, and with this change, running fp-stress on a
> defconfig kernel running on 1 CPU triggers the
Hi Mark,
On Tue, Oct 29, 2024 at 12:10:39AM +, Mark Brown wrote:
> Currently we only deliver signals to the processes being tested about
> once a second, meaning that the signal code paths are subject to
> relatively little stress. Increase this frequency substantially to
> 25
this looks fine.
Mark.
On Tue, Oct 29, 2024 at 12:10:40AM +0000, Mark Brown wrote:
> While fp-stress is waiting for children to start it doesn't send any
> signals to them so there is no need for it to have as short an epoll()
> timeout as it does when the children are all running.
more
information is available should the tests fail.
Signed-off-by: Mark Brown
---
tools/testing/selftests/arm64/mte/mte_common_util.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/tools/testing/selftests/arm64/mte/mte_common_util.c
b/tools/testing/selftests/
ignal raise
interval when all the children are started and we start sending signals.
Signed-off-by: Mark Brown
---
tools/testing/selftests/arm64/fp/fp-stress.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/arm64/fp/fp-stress.c
b/tools/testing/self
moved the signal generation out of the main
supervisor thread, though we should also consider that he percentage of
time that we spend interacting with the floating point state is also a
consideration.
Suggested-by: Mark Rutland
Signed-off-by: Mark Brown
---
tools/testing/selftests/arm64/fp/fp
One of the things that fp-stress does to stress the floating point
context switching is send signals to the test threads it spawns.
Currently we do this once per second but as suggested by Mark Rutland if
we increase this we can improve the chances of triggering any issues
with context switching
The test for SVE_B16B16 had a cut'n'paste of a SME instruction, fix it with
a relevant SVE instruction.
Fixes: 44d10c27bd75 ("kselftest/arm64: Add 2023 DPISA hwcap test coverage")
Signed-off-by: Mark Brown
---
tools/testing/selftests/arm64/abi/hwcap.c | 4 ++--
1 file c
On Tue, Oct 29, 2024 at 01:16:32AM +0530, Naresh Kamboju wrote:
> The following kselftest arm64 and FVP failed with Linux next-20241025 on
> - Qemu-arm64
> - FVP
>
> running Linux next-20241025 kernel.
>
> First seen on next-20241025
> Good: next-20241024
> BAD: next-20241025
>
> kself
On Wed, Oct 23, 2024 at 09:38:28PM +0100, Mark Brown wrote:
> Currently we test signal delivery to the programs run by fp-stress but
> our signal handlers simply count the number of signals seen and don't do
> anything with the floating point state. The original fpsimd-test
On Mon, Oct 28, 2024 at 02:26:44PM +, Mark Rutland wrote:
> 1) We only singal the tasks once a second. Dave's original shell test
>script hammered this constantly, and it makes a substantial impact
>actually triggering a bug.
>Without these patches, I hacked the
On Fri, Oct 25, 2024 at 09:40:04AM +0800, Li Zhijian wrote:
> index 12dc3fcd3456..1407fd24a97b 100644
> --- a/tools/testing/selftests/alsa/.gitignore
> +++ b/tools/testing/selftests/alsa/.gitignore
> @@ -1,3 +1,5 @@
> mixer-test
> pcm-test
> test-pcmtest-driver
> +global-timer
> +utimer-test
>
current register state which is expected to be overwritten on return
from the handler by the saved register state. Update the comment to reflect
what the handler is actually doing.
Signed-off-by: Mark Brown
---
tools/testing/selftests/arm64/fp/fpsimd-test.S | 3 +--
tools/testing/selftests/arm64
ment them,
just trivially SMSTOP and SMSTART to reset all bits in the register to 0.
Signed-off-by: Mark Brown
---
tools/testing/selftests/arm64/fp/za-test.S | 12
tools/testing/selftests/arm64/fp/zt-test.S | 12
2 files changed, 8 insertions(+), 16 deletions(-)
dif
the signal handler, verifying that when we return the saved
register state is restored from the signal context as expected. Switch over
to triggering that to validate that we are restoring as expected.
Signed-off-by: Mark Brown
---
tools/testing/selftests/arm64/fp/fp-stress.c | 2 +-
1 file
s the
number of signals like we do for SIGUSR2, allowing fp-stress to treat all
the test programs uniformly.
Signed-off-by: Mark Brown
---
tools/testing/selftests/arm64/fp/kernel-test.c | 4
1 file changed, 4 insertions(+)
diff --git a/tools/testing/selftests/arm64/fp/kernel-test.c
b/tools/te
When building for streaming SVE the irritator for SVE skips updates of both
P15 and FFR. While FFR is skipped since it might not be present there is no
reason to skip corrupting P15 so move the ifdef appropriately.
Signed-off-by: Mark Brown
---
tools/testing/selftests/arm64/fp/sve-test.S | 2
The irritator handlers for the fp-stress test programs all use ADR to load
an address into x0 which is then not referenced. Remove these ADRs as they
just cause confusion.
Signed-off-by: Mark Brown
---
tools/testing/selftests/arm64/fp/fpsimd-test.S | 1 -
tools/testing/selftests/arm64/fp/sve
test
programs that can have them and then switch the signals generated by the
fp-stress program over to use the irritators, ensuring that we validate
that we restore the saved signal context properly.
Signed-off-by: Mark Brown
---
Mark Brown (6):
kselftest/arm64: Correct misleading comments
g for output from the child. Improve robustness and output quality
by logging to stdout instead.
Signed-off-by: Mark Brown
---
tools/testing/selftests/arm64/fp/fp-stress.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/tools/testing/selftests/arm64/fp/fp-stress
ddition of this x86 specific command line flag
conditional on building for x86.
Fixes: 9a400068a158 ("KVM: selftests: x86: Avoid using SSE/AVX instructions")
Signed-off-by: Mark Brown
---
tools/testing/selftests/kvm/Makefile | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Currently fp-stress does not report a top level test result if it runs to
completion, it always exits with a return code 0. Use the ksft_finished()
helper to ensure that the exit code for the top level program reports a
failure if any of the individual tests has failed.
Signed-off-by: Mark Brown
The GCS stress test program currently uses the PID of the threads it
creates in the test names it reports, resulting in unstable test names
between runs. Fix this by using a thread number instead.
Signed-off-by: Mark Brown
---
tools/testing/selftests/arm64/gcs/gcs-stress.c | 6 +++---
1 file
On Tue, Oct 08, 2024 at 05:35:18PM +0200, Björn Töpel wrote:
> The sched_ext selftests is missing proper cross-compilation support, a
> proper target entry, and out-of-tree build support.
Tested-by: Mark Brown
Reviewed-by: Mark Brown
There's still the thing with picking up the hos
On Mon, Oct 07, 2024 at 06:00:57PM +0200, Björn Töpel wrote:
> The sched_ext BPF programs relies on a vmlinux.h, which is generated
> using bpftool and the vmlinux with BTF information. Have you built a
> kernel with BTF support?
OK, so having beaten the kernel config into shape and using GCC rat
On Mon, Oct 07, 2024 at 06:45:32PM +0200, Björn Töpel wrote:
> Mark Brown writes:
> > I didn't actually build a kernel, if the build system needs a kernel
> > it's just silently not detected that it's missing?
> It tries to find a kernel with BTF:
>
On Mon, Oct 07, 2024 at 06:00:57PM +0200, Björn Töpel wrote:
> Mark Brown writes:
> > When building for arm64 with this applied on top of mainline or -next
> > I'm seeing:
> Thanks for taking it for a spin!
> >make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -C
On Mon, Oct 07, 2024 at 06:00:57PM +0200, Björn Töpel wrote:
> Mark Brown writes:
> > On Mon, Oct 07, 2024 at 09:31:32AM +0200, Björn Töpel wrote:
> > CLNG-BPF create_dsq.bpf.o
> > In file included from create_dsq.bpf.c:9:
> > /home/broonie/git/linux/tools/sched_ext/
On Mon, Oct 07, 2024 at 09:31:32AM +0200, Björn Töpel wrote:
> When building the kselftest suite, e.g.:
> make ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu- \
> SKIP_TARGETS="" O=/output/foo -C tools/testing/selftests install
> The expectation is that the sched_ext is included, cross-built,
On Mon, Oct 07, 2024 at 10:07:24AM +0530, Dev Jain wrote:
> On 9/16/24 09:28, Dev Jain wrote:
> > Gentle ping, adding all x86 maintainers and the x86 list, in case they
> > missed.
> Gentle ping
Given that this was posted prior to the merge window you should probably
resend it at this point.
s
On Sat, Oct 05, 2024 at 12:12:15PM +0200, Björn Töpel wrote:
> Mark Brown writes:
> > On Fri, Oct 04, 2024 at 03:34:49PM +0200, Björn Töpel wrote:
> >> Mark Brown writes:
> > It's a bit unfortunate having to pull clang into GCC build containers,
> > and needi
., this should be overly cautious.
Acked-by: Shuah Khan
Signed-off-by: Mark Brown
---
tools/testing/selftests/clone3/clone3.c | 143 +-
tools/testing/selftests/clone3/clone3_selftests.h | 63 ++
2 files changed, 205 insertions(+), 1 deletion(-)
diff --git a
d-off-by: Mark Brown
---
tools/testing/selftests/clone3/clone3.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/tools/testing/selftests/clone3/clone3.c
b/tools/testing/selftests/clone3/clone3.c
index
e066b201fa64eb17c55939b7cec18ac5d109613b..5b8b7d640e70132242fc6939450669acd0c534f9
1
change.
Reviewed-by: Kees Cook
Tested-by: Kees Cook
Acked-by: Shuah Khan
Signed-off-by: Mark Brown
---
tools/testing/selftests/clone3/clone3.c | 77 -
1 file changed, 37 insertions(+), 40 deletions(-)
diff --git a/tools/testing/selftests/clone3/clone3.c
b
s.
Reviewed-by: Kees Cook
Tested-by: Kees Cook
Acked-by: Shuah Khan
Signed-off-by: Mark Brown
---
tools/testing/selftests/clone3/clone3_selftests.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/tools/testing/selftests/clone3/clone3_selftests.h
b/tools/testing/selftests/clone3/clone3_se
-by: Mark Brown
---
arch/arm64/mm/gcs.c | 54 +-
arch/x86/include/asm/shstk.h | 11 +++--
arch/x86/kernel/process.c| 2 +-
arch/x86/kernel/shstk.c | 57 +---
include/asm-generic/cacheflush.h | 11 +
include/linux/sched
interfaces.
Reviewed-by: Rick Edgecombe
Reviewed-by: Kees Cook
Tested-by: Kees Cook
Acked-by: Shuah Khan
Signed-off-by: Mark Brown
---
tools/testing/selftests/ksft_shstk.h | 98
1 file changed, 98 insertions(+)
diff --git a/tools/testing/selftests/ksft_shstk.h
b
feature let's provide some documentation covering the common aspects.
Reviewed-by: Catalin Marinas
Reviewed-by: Kees Cook
Tested-by: Kees Cook
Acked-by: Shuah Khan
Signed-off-by: Mark Brown
---
Documentation/userspace-api/index.rst| 1 +
Documentation/userspace-api/shadow_stack.rst
error code
on failure.
Signed-off-by: Mark Brown
---
arch/arm64/include/asm/gcs.h | 8
arch/arm64/kernel/process.c | 8
arch/arm64/mm/gcs.c | 8
3 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm64/include/asm/gcs.h b/arch/arm64/include/asm/
..@kernel.org/T/#mc58f97f27461749ccf400ebabf6f9f937116a86b
Signed-off-by: Mark Brown
---
Changes in v11:
- Rebase onto arm64 for-next/gcs, which is based on v6.12-rc1, and
integrate arm64 support.
- Rework the interface to specify a shadow stack pointer rather than a
base and size like we do for th
to get the permissions in case the system is locked down to make
them inaccessible.
Signed-off-by: Mark Brown
---
tools/testing/selftests/arm64/gcs/.gitignore | 2 +
tools/testing/selftests/arm64/gcs/Makefile | 8 ++-
tools/testing/selftests/arm64/gcs/gcspushm.S | 96
On Fri, Oct 04, 2024 at 03:34:49PM +0200, Björn Töpel wrote:
> Mark Brown writes:
> > On Fri, Oct 04, 2024 at 11:53:47AM +0200, Björn Töpel wrote:
> >> This effectively is a revert of commit 7a6eb7c34a78 ("selftests: Skip
> >> BPF seftests by default"). At
On Fri, Oct 04, 2024 at 11:53:47AM +0200, Björn Töpel wrote:
> From: Björn Töpel
>
> This effectively is a revert of commit 7a6eb7c34a78 ("selftests: Skip
> BPF seftests by default"). At the time when this was added, BPF had
> "build time dependencies on cutting edge versions". Since then a
> num
On Wed, Oct 02, 2024 at 02:42:58PM +0100, Mark Brown wrote:
> On Tue, Oct 01, 2024 at 11:03:10PM +, Edgecombe, Rick P wrote:
> > I'm not so sure. The thing is a regular stack can be re-used in full - just
> > set
> > the RSP to the end and take advantage of the w
On Tue, Oct 01, 2024 at 11:03:10PM +, Edgecombe, Rick P wrote:
> On Tue, 2024-10-01 at 18:33 +0100, Mark Brown wrote:
> > My suspicion would be that if we're doing the pivot to a previously used
> > shadow stack we'd also be pivoting the regular stack along wit
On Tue, Oct 01, 2024 at 05:12:38PM +0200, Christian Brauner wrote:
> On Fri, Sep 27, 2024 at 03:21:59PM GMT, Edgecombe, Rick P wrote:
> > Did you catch that a token can be at a different offsets location on the
> > stack
> > depending on args passed to map_shadow_stack? So userspace will need
>
004a ("KVM: selftests: Allow slot modification stress test with
quirk disabled")
Reported-by: Aishwarya TCV
Signed-off-by: Mark Brown
---
This is obviously disruptive for testing of KVM changes on non-x86
architectures.
---
tools/testing/selftests/kvm/memslot_modification_stress_test.c |
ly in __rproc_virtio_del_vqs
before virtqueue is free to ensure that rproc_vq_interrupt is
aware of the virtqueue removal.
The synchronized_vqs is expected to be implemented in rproc
driver to ensure that all previous vring_interrupts are handled
before the vqs are marked as broken or removed.
Signed-off-by: Ma
On Thu, Sep 05, 2024 at 11:26:02AM +0530, Dev Jain wrote:
> On 9/4/24 22:35, Shuah Khan wrote:
> > So who does the backports whenevenr something changes? You are adding
> > work where as the automated process would just work without this
> > change. It doesn't matter if there is another test that
On Wed, Aug 21, 2024 at 04:32:46PM +0100, Mark Rutland wrote:
> On Wed, Aug 21, 2024 at 07:05:39AM +0900, Masami Hiramatsu wrote:
> > On Tue, 20 Aug 2024 08:10:42 -0700
> > Sami Tolvanen wrote:
> >
> > > On Tue, Aug 20, 2024 at 3:48 AM Mark Rutland wrote:
> >
On Wed, Aug 21, 2024 at 07:05:39AM +0900, Masami Hiramatsu wrote:
> On Tue, 20 Aug 2024 08:10:42 -0700
> Sami Tolvanen wrote:
>
> > On Tue, Aug 20, 2024 at 3:48 AM Mark Rutland wrote:
> > >
> > > On Tue, Aug 20, 2024 at 10:03:30AM +0900, Masami Hiramatsu wrote:
much larger implications for
noinstr code and similar, and means that LTO is unsound...
> I found a discussion similar to this problem, but it seems very hacky.
>
> https://groups.google.com/g/llvm-dev/c/6baI9LISmSU/m/uEeY_CRbBQAJ?pli=1
Thanks for the link!
Mark.
pcode, long addr, struct pt_regs *regs)
> +{
> + long imm7;
> + u64 buf[2];
> + long new_sp;
> +
> + imm7 = sign_extend64((opcode >> 15) & 0x7f, 6);
> + new_sp = regs->sp + (imm7 << 3);
We have accessors for these fields, please use them.
> +
> + buf[0] = regs->regs[29];
> + buf[1] = regs->regs[30];
> +
> + if (copy_to_user((void __user *)new_sp, buf, sizeof(buf))) {
> + force_sig(SIGSEGV);
> + return;
> + }
As above, this won't interact with VMSA features (e.g. MTE, POE) in the
same way as an STP in userspace, and this will not have the same
atomicity properties as an STP.
> +
> + regs->sp = new_sp;
> + instruction_pointer_set(regs, instruction_pointer(regs) + 4);
Likewise, this sould need ot use arm64_skip_faulting_instruction(),
though as above I think we should drop STP emulation entirely.
Mark.
On Fri, May 31, 2024 at 07:34:58PM +0200, Karel Balej wrote:
> Support the LDO and buck regulators of the Marvell 88PM886 PMIC.
Reviewed-by: Mark Brown
signature.asc
Description: PGP signature
On Wed, Jun 05, 2024 at 02:03:39PM -0400, Steven Rostedt wrote:
> From: "Steven Rostedt (Google)"
>
> Describe what ftrace_hash_move() does and add some more comments to some
> other functions to make it easier to understand.
>
> Signed-off-by: Steven Rostedt (Goog
es.
>
> Signed-off-by: Steven Rostedt (Google)
Acked-by: Mark Rutland
Mark.
> ---
> kernel/trace/ftrace.c | 23 ---
> 1 file changed, 20 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> index 1a2444199
.
> Remove the "filter_hash" parameter from __filter_hash_rec_update() and
> comment the function for what it really is doing.
>
> Signed-off-by: Steven Rostedt (Google)
FWIW, this looks good to me, and works in testing, so:
Reviewed-by: Mark Rutland
Tested-by: Mark Rutlan
ated one. Rename it to "__move_hash()" (using starting underscores as
> it is an internal function), and add some comments about what it does.
>
> Signed-off-by: Steven Rostedt (Google)
Acked-by: Mark Rutland
Mark.
> ---
> kernel/trace/ftrace.c | 8 ++--
> 1
e horrid hacks to manipulate the global
filters, and after this series I just need to manipulate the filters in
fgraph_ops::ops, which is *much* nicer.
I've pushed out my WIP to:
https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/log/?h=stacktrace/tests
... which is all to
mentation to what the function does.
>
> Signed-off-by: Steven Rostedt (Google)
Aside from the issue with forward declarations that need to be updated,
this looks good to me, so with that fixed:
Acked-by: Mark Rutland
Mark.
> ---
> kernel/trace/ftrace.c | 33 ++
in true to __ftrace_hash_rec_update().
>
> Also add some comments to both those functions explaining what they do.
>
> Signed-off-by: Steven Rostedt (Google)
Looks good to me.
Acked-by: Mark Rutland
Mark.
> ---
> kernel/trace/ftrace.c | 24
> 1
* @filter_hash: True if for the filter hash is udpated, false for the
> + * notrace hash
Typo: s/udpated/updated/
... though I couldn't parse this regardless; maybe:
@filter_hash: true to update the filter hash, false to update
the notrace hash
it can not
> find them. Without fungraph-proc option set, it will not be displayed and
> the test will fail.
>
> Link: https://lore.kernel.org/all/Zl9JFnzKGuUM10X2@J2N7QTR9R3/
>
> Fixes: 35b944a997e2 ("selftests/ftrace: Add function_graph tracer to
> func-filter-pid test
On Tue, Jun 04, 2024 at 12:31:24PM -0400, Steven Rostedt wrote:
> On Tue, 4 Jun 2024 15:44:40 +0100
> Mark Rutland wrote:
>
> > Hi Steve, Masami,
> >
> > On Tue, Jun 04, 2024 at 08:18:50AM -0400, Steven Rostedt wrote:
> > >
> > > Masami,
> >
g odd with the filesystem I'm using
(e.g. the wnership test failed because this lacks 'stat').
Mark.
>
> -- Steve
>
>
> On Mon, 03 Jun 2024 15:07:04 -0400
> Steven Rostedt wrote:
>
> > This is a continuation of the function graph multi user code.
>
thing needs to change within ftrace itself.
> If ftrace can only observe the function being called, maybe it
> wouldn't be wrong to just observe nothing if the static key isn't
> enabled because nobody is doing the fault injection?
Yep, that sounds right to me.
Mark.
On Sun, May 05, 2024 at 08:52:06PM +0200, Karel Balej wrote:
> Should I then drop this op and the max_uA values from all the
> regulators?
Probably, yes.
signature.asc
Description: PGP signature
On Sat, May 04, 2024 at 09:37:06PM +0200, Karel Balej wrote:
> +static const struct regulator_ops pm886_ldo_ops = {
> + .list_voltage = regulator_list_voltage_table,
> + .map_voltage = regulator_map_voltage_iterate,
> + .set_voltage_sel = regulator_set_voltage_sel_regmap,
> + .get_
tting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
nce modules can refreence other modules, that ends up
actually being halved, and modules have to fit within some 2G window that
also covers the kernel.
* I'm not sure about BPF's requirements; it seems happy doing the same as
modules.
So if we *must* use a common execmem allocator, what we'd reall want is our own
types, e.g.
EXECMEM_ANYWHERE
EXECMEM_NOPLT
EXECMEM_PREL32
... and then we use those in arch code to implement module_alloc() and friends.
Mark.
On Tue, Mar 26, 2024 at 09:15:14AM -0700, Calvin Owens wrote:
> On Wednesday 03/27 at 00:24 +0900, Masami Hiramatsu wrote:
> > On Tue, 26 Mar 2024 14:46:10 +
> > Mark Rutland wrote:
> > > Different exectuable allocations can have different requirements. For
>
On Wed, Mar 27, 2024 at 12:24:03AM +0900, Masami Hiramatsu wrote:
> On Tue, 26 Mar 2024 14:46:10 +
> Mark Rutland wrote:
> >
> > On Mon, Mar 25, 2024 at 11:56:32AM +0900, Masami Hiramatsu wrote:
> > > I think, we'd better to introduce `alloc_execmem()`,
>
s which an architecture can then
choose to implement using a common library if it wants to.
I took a look at doing that using the core ifdeffery fixups from Jarkko's v6,
and it looks pretty clean to me (and works in testing on arm64):
https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/log/?h=kprobes/without-modules
Could we please start with that approach, with kprobe-specific alloc/free code
provided by the architecture?
Thanks,
Mark.
ting
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
On Thu, Mar 21, 2024 at 08:14:44PM +0100, Karel Balej wrote:
> Mark Brown, 2024-03-21T19:00:24+00:00:
> > I would expect that if you have two separate register maps they would
> > have separate configurations that describe the corresponding physical
> > register maps, as f
On Thu, Mar 21, 2024 at 07:16:43PM +0100, Karel Balej wrote:
> Mark Brown, 2024-03-21T17:48:28+00:00:
> > > They do according to the downstream driver which is my only reference.
> > > In fact, there the driver defines the configs separately for each regmap
> >
On Thu, Mar 21, 2024 at 06:32:03PM +0100, Karel Balej wrote:
> Mark Brown, 2024-03-21T17:17:40+00:00:
> > Do they both genuinely have the same maximum register?
> They do according to the downstream driver which is my only reference.
> In fact, there the driver defines the configs
On Thu, Mar 21, 2024 at 06:08:16PM +0100, Karel Balej wrote:
> Mark Brown, 2024-03-21T16:58:44+00:00:
> > > > > > > +static const struct regmap_config pm886_i2c_regmap = {
> > > > > > > + .reg_bits = 8,
> > > > > > > + .val_b
On Thu, Mar 21, 2024 at 05:55:17PM +0100, Karel Balej wrote:
> Lee Jones, 2024-03-21T16:20:45+00:00:
> > On Thu, 21 Mar 2024, Karel Balej wrote:
> > > > > +static const struct regmap_config pm886_i2c_regmap = {
> > > > > + .reg_bits = 8,
> > > > > + .val_bits = 8,
> > > > > + .max_regi
n is split over multiple
> instructions) is a no-go. It's just a too big can of worms. So, if we
> can only patch one insn, it's CALL_OPS.
>
> A couple of options (in addition to Andy's), and all require a
> per-function landing address ala CALL_OPS) tweaking what Mark is doing
&g
e recovered by the common ftrace trampoline.
>
> Not really a review, but some more background; Another rationale (on-top
> of the improved per-call performance!) for CALL_OPS was to use it to
> build ftrace direct call support (which BPF uses a lot!). Mark, please
> correct me if I
nt lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
[adding Valentin]
On Mon, Feb 05, 2024 at 08:06:09AM -0500, Steven Rostedt wrote:
> On Mon, 5 Feb 2024 10:28:57 +
> Mark Rutland wrote:
>
> > > I try to write below:
> > > echo 'target_cpus == 11 && reason == "Function call interrupts"&#
/ipi/ipi_raise/filter
The '=' checks if the target_cpus bitmap *only* contains CPU 11. If the cpumask
contains other CPUs, the filter will skip the call.
I believe you can use '&' to check whether a cpumask contains a CPU, e.g.
'target_cpus & 11'
Thanks,
Mark.
On Thu, Jan 11, 2024 at 11:15:33AM +0900, Masami Hiramatsu wrote:
> Hi Mark,
>
> Thanks for the investigation.
Hi!
As a heads-up, I already figured out the problem and sent a fixup at:
https://lore.kernel.org/lkml/ZZwEz8HsTa2IZE3L@FVFF77S0Q05N/
... and a more refined fix at:
/sys/kernel/tracing/current_tracer
# less /sys/kernel/tracing/trace
...
-0 [007] ..s3. 172.932840: wake_up_process
<-process_timeout
-0 [007] ..s1. 172.932842: my_direct_func: waking up
kcompactd0-62
-0 [007] ..s3. 173.444836: wake_u
1 - 100 of 14840 matches
Mail list logo
