On 10/1/24 10:47 PM, Steven Rostedt wrote:
On Tue, 1 Oct 2024 22:27:03 +0900
ts wrote:
...
sh-140 [001] ...1.18.352601: myevent:
(vfs_write+0x4/0x560)
sh-140 [001] ...1.18.352602:
=> ksys_write
=> do_syscall_64
=> entry_SYSCALL_64_a
Hi Nathan,
Thanks for all the comments!
On 2024-10-01 23:53, Nathan Chancellor wrote:
> Hi Wentao,
>
> I took this series for a spin on next-20241001 with LLVM 19.1.0 using a
> distribution configuration tailored for a local development VM using
> QEMU. You'll notice on the
On 10/01, Andrii Nakryiko wrote:
>
> At the point where find_active_uprobe_rcu() is used we know that VMA in
> question has triggered software breakpoint, so we don't need to validate
> vma->vm_flags. Keep only vma->vm_file NULL check.
>
> Suggested-by: Oleg Nesterov
> Signed-off-by: Andrii Nakry
A extra entry is shown on stack trace(CONFIG_UNWINDER_ORC=y).
[003] . 110.171589: vfs_write <-__x64_sys_write
[003] . 110.171600:
=> X (Wrong function name)
=> vfs_write
=> ksys_write
=> do_syscall_64
=> entry_SYSCALL_64_after_hwframe
To resolve this, increment skip for __ftr
Hi Wentao,
I took this series for a spin on next-20241001 with LLVM 19.1.0 using a
distribution configuration tailored for a local development VM using
QEMU. You'll notice on the rebase for 6.12-rc1 but there is a small
conflict in kernel/Makefile due to commit 0e8b67982b48 ("mm: m
On Wed, Sep 04, 2024 at 11:32:45PM -0500, Wentao Zhang wrote:
> Set ARCH_HAS_* options to "y" in kconfig and include section description in
Is description the right word here? Maybe "include the compiler generated
sections"? Open to other suggestions.
> linker script.
>
> Signed-off-by: Wentao Z
On Wed, Sep 04, 2024 at 11:32:44PM -0500, Wentao Zhang wrote:
> Disable instrumentation for arch/x86/crypto/curve25519-x86_64.c. Otherwise
> compilation would fail with "error: inline assembly requires more registers
> than available".
>
> Similar behavior was reported with gcov as well. See c390c
Hi Wentao,
On Wed, Sep 04, 2024 at 11:32:43PM -0500, Wentao Zhang wrote:
> Add infrastructure to enable Clang's Modified Condition/Decision Coverage
> (MC/DC) [1].
>
> Clang has added MC/DC support as of its 18.1.0 release. MC/DC is a fine-
> grained coverage metric required by many automotive an
Hi Wentao,
On Wed, Sep 04, 2024 at 11:32:42PM -0500, Wentao Zhang wrote:
> Add infrastructure to support Clang's source-based code coverage [1]. This
> includes debugfs entries for serializing profiles and resetting
> counters/bitmaps. Also adds coverage flags and kconfig options.
Some superfici
On Mon, 30 Sep 2024 15:03:02 -0400
Steven Rostedt wrote:
> On Tue, 17 Sep 2024 11:08:48 +0100
> Will Deacon wrote:
>
> > > > @@ -787,6 +789,9 @@ __ftrace_return_to_handler(struct ftrace_regs
> > > > *fregs, unsigned long frame_pointe
> > > > }
> > > >
> > > > trace.rettime =
On Wed, 2 Oct 2024 08:10:37 +0900
Masami Hiramatsu (Google) wrote:
> >
> > I may add some compiler hacks to enforce this. Something like:
> >
> > struct ftrace_regs {
> > void *nothing_to_see_here;
> > };
>
> Yeah, OK. But sizeof(fregs) may be changed. (Shouldn't we do too?)
Honestly, I
On Tue, 17 Sep 2024 11:14:54 +0100
Will Deacon wrote:
> On Sun, Sep 15, 2024 at 05:22:04AM -0400, Steven Rostedt wrote:
> > On Fri, 13 Sep 2024 00:09:35 +0900
> > "Masami Hiramatsu (Google)" wrote:
> >
> > > From: Masami Hiramatsu (Google)
> > >
> > > Add ftrace_partial_regs() which converts
Given filp_cachep is marked SLAB_TYPESAFE_BY_RCU (and FMODE_BACKING
files, a special case, now goes through RCU-delated freeing), we can
safely access vma->vm_file->f_inode field locklessly under just
rcu_read_lock() protection, which enables looking up uprobe from
uprobes_tree completely locklessl
At the point where find_active_uprobe_rcu() is used we know that VMA in
question has triggered software breakpoint, so we don't need to validate
vma->vm_flags. Keep only vma->vm_file NULL check.
Suggested-by: Oleg Nesterov
Signed-off-by: Andrii Nakryiko
---
kernel/events/uprobes.c | 2 +-
1 fil
6cf41fcfe099 ("backing file: free directly") switched FMODE_BACKING
files to direct freeing as back then there were no use cases requiring
RCU protected access to such files.
Now, with speculative lockless VMA-to-uprobe lookup logic, we do need to
have a guarantee that struct file memory is not go
To increase mm->mm_lock_seq robustness, switch it from int to long, so
that it's a 64-bit counter on 64-bit systems and we can stop worrying
about it wrapping around in just ~4 billion iterations. Same goes for
VMA's matching vm_lock_seq, which is derived from mm_lock_seq.
I didn't use __u64 outri
From: Suren Baghdasaryan
Add helper functions to speculatively perform operations without
read-locking mmap_lock, expecting that mmap_lock will not be
write-locked and mm is not modified from under us.
Suggested-by: Peter Zijlstra
Signed-off-by: Suren Baghdasaryan
Signed-off-by: Andrii Nakryik
Implement speculative (lockless) resolution of VMA to inode to uprobe,
bypassing the need to take mmap_lock for reads, if possible. Patch #1 by Suren
adds mm_struct helpers that help detect whether mm_struct were changed, which
is used by uprobe logic to validate that speculative results can be tru
On Tue, Oct 01, 2024 at 05:46:06PM -0400, Steven Rostedt wrote:
> On Tue, 1 Oct 2024 14:15:43 -0700
> Josh Poimboeuf wrote:
>
> > On Tue, Oct 01, 2024 at 01:29:58PM +, Alice Ryhl wrote:
> > > Add just enough support for static key so that we can use it from
> > > tracepoints. Tracepoints rely
The old static key API based on 'struct static_key' is deprecated.
Convert tracepoints to use the new API.
Signed-off-by: Josh Poimboeuf
---
include/linux/tracepoint-defs.h | 4 ++--
include/linux/tracepoint.h | 8
kernel/tracepoint.c | 4 ++--
3 files changed, 8 insert
On Tue, 1 Oct 2024 14:15:43 -0700
Josh Poimboeuf wrote:
> On Tue, Oct 01, 2024 at 01:29:58PM +, Alice Ryhl wrote:
> > Add just enough support for static key so that we can use it from
> > tracepoints. Tracepoints rely on `static_key_false` even though it is
> > deprecated, so we add the same
On Tue, Oct 01, 2024 at 01:29:58PM +, Alice Ryhl wrote:
> Add just enough support for static key so that we can use it from
> tracepoints. Tracepoints rely on `static_key_false` even though it is
> deprecated, so we add the same functionality to Rust.
Instead of extending the old deprecated st
From: Yazen Ghannam
A new "FRU Text in MCA" feature is defined where the Field Replaceable
Unit (FRU) Text for a device is represented by a string in the new
MCA_SYND1 and MCA_SYND2 registers. This feature is supported per MCA
bank, and it is advertised by the McaFruTextInMca bit (MCA_CONFIG[9]).
Starting with Zen4, AMD's Scalable MCA systems incorporate two new
registers: MCA_SYND1 and MCA_SYND2.
These registers will include supplemental error information in addition
to the existing MCA_SYND register. The data within these registers is
considered valid if MCA_STATUS[SyndV] is set.
Usersp
From: Yazen Ghannam
ACPI Boot Error Record Table (BERT) is being used by the kernel to
report errors that occurred in a previous boot. On some modern AMD
systems, these very errors within the BERT are reported through the
x86 Common Platform Error Record (CPER) format which consists of one
or mor
From: Steven Rostedt
When printing a dynamic array in a trace event, the method is rather ugly.
It has the format of:
__print_array(__get_dynamic_array(array),
__get_dynmaic_array_len(array) / el_size, el_size)
Since dynamic arrays are known to the tracing infrastructure, create a
Currently, exporting new additional machine check error information
involves adding new fields for the same at the end of the struct mce.
This additional information can then be consumed through mcelog or
tracepoint.
However, as new MSRs are being added (and will be added in the future)
by CPU ven
This patchset adds a new wrapper for struct mce to prevent its bloating
and export vendor specific error information. Additionally, support is
also introduced for two new "syndrome" MSRs used in newer AMD Scalable
MCA (SMCA) systems. Also, a new "FRU Text in MCA" feature that uses these
new "syndro
On Tue, Oct 1, 2024 at 6:17 AM Jiri Olsa wrote:
>
> On Mon, Sep 30, 2024 at 02:36:03PM -0700, Andrii Nakryiko wrote:
> > On Sun, Sep 29, 2024 at 1:57 PM Jiri Olsa wrote:
> > >
> > > This change allows the uprobe consumer to behave as session which
> > > means that 'handler' and 'ret_handler' call
On Tue, Oct 01 2024 at 05:45, Jeff Layton wrote:
> On Mon, 2024-09-30 at 23:35 +0200, Thomas Gleixner wrote:
>> > I certainly wouldn't rule out a workqueue job calling that function,
>> > but this is something we do while dirtying an inode, and that's not
>> > typically done in interrupt context.
>
On Tue, Oct 1, 2024 at 6:17 AM Jiri Olsa wrote:
>
> On Mon, Sep 30, 2024 at 02:36:08PM -0700, Andrii Nakryiko wrote:
>
> SNIP
>
> > > struct bpf_uprobe_multi_link {
> > > @@ -3248,9 +3260,13 @@ uprobe_multi_link_handler(struct uprobe_consumer
> > > *con, struct pt_regs *regs,
> > >
On Tue, Oct 1, 2024 at 7:24 AM Oleg Nesterov wrote:
>
> Hello,
>
> On top of
>
> [PATCH 0/7] uprobes: deuglify xol_get_insn_slot/xol_free_insn_slot
> paths
> https://lore.kernel.org/all/20240929144201.ga9...@redhat.com/
>
> To me this change looks like a simplification, but perhap
On Tue, 1 Oct 2024 11:35:53 +0200
Ard Biesheuvel wrote:
> All I am asking for is a line in the documentation that says that
> clobbered trace buffers could occur at any time, regardless of whether
> CONFIG_RESET_ATTACK_MITIGATION is enabled or not. That way, we have
> something to refer to when p
On Tue, Oct 1, 2024 at 3:59 AM Jeff Layton wrote:
>
> Multigrain timestamps allow the kernel to use fine-grained timestamps
> when an inode's attributes is being actively observed via ->getattr().
> With this support, it's possible for a file to get a fine-grained
> timestamp, and another modified
On Tue, 1 Oct 2024 17:16:48 +0100
Catalin Marinas wrote:
> For the arm64 changes:
>
> Acked-by: Catalin Marinas
Thanks Catalin!
-- Steve
On Tue, Oct 01, 2024 at 01:30:01PM +, Alice Ryhl wrote:
> diff --git a/arch/arm64/include/asm/jump_label.h
> b/arch/arm64/include/asm/jump_label.h
> index a0a5bbae7229..424ed421cd97 100644
> --- a/arch/arm64/include/asm/jump_label.h
> +++ b/arch/arm64/include/asm/jump_label.h
> @@ -19,10 +19,1
Thanks Steven for the Information.
I am surprised that even probe functions are inlined which are invoked
if there is a match of entry in the pci_id_table of that module.
I will try noinline.
On Mon, 30 Sept 2024 at 20:51, Steven Rostedt wrote:
>
> On Mon, 30 Sep 2024 18:16:01 +0530
> Maverickk
Hi Hans,
On Tue, 1 Oct 2024 at 10:57, Hans de Goede wrote:
>
> Hi,
>
> On 1-Oct-24 8:17 AM, Ard Biesheuvel wrote:
> > On Thu, 26 Sept 2024 at 19:02, Steven Rostedt wrote:
> >>
> >> From: Steven Rostedt
> >>
> >> At the 2024 Linux Plumbers Conference, I was talking with Hans de Goede
> >> about
On Mon, 16 Sep 2024 20:59:05 +0200
Heiko Carstens wrote:
> On Mon, Sep 16, 2024 at 12:29:30PM -0400, Steven Rostedt wrote:
> > On Mon, 16 Sep 2024 14:16:56 +0200
> > Heiko Carstens wrote:
> >
> > > This does not pass the ftrace selftests. Please merge the patch below
> > > into this patch. With
On Tue, 1 Oct 2024 14:30:33 +0800
Tiezhu Yang wrote:
> Then, CONFIG_KPROBE_EVENTS should depend on or select CONFIG_KPROBES?
> In the current code, CONFIG_KPROBE_EVENTS depend on CONFIG_KPROBES,
> the CONFIG_KPROBE_EVENTS menu is hidden if CONFIG_KPROBES is not set.
We could just for consistency
On Tue, 1 Oct 2024 08:30:42 -0400
Steven Rostedt wrote:
> On Tue, 1 Oct 2024 14:30:33 +0800
> Tiezhu Yang wrote:
>
> > Then, CONFIG_KPROBE_EVENTS should depend on or select CONFIG_KPROBES?
> > In the current code, CONFIG_KPROBE_EVENTS depend on CONFIG_KPROBES,
> > the CONFIG_KPROBE_EVENTS menu
Gentle ping in case of forgotten.
From: Steven Rostedt
Sent: 26 September 2024 13:51
To: Yeo Reum Yun
Cc: mhira...@kernel.org; mathieu.desnoy...@efficios.com;
a.p.zijls...@chello.nl; mi...@elte.hu; Mark Rutland; james.cl...@linaro.org;
nd; linux-ker...@v
Enable multigrain timestamps, which should ensure that there is an
apparent change to the timestamp whenever it has been written after
being actively observed via getattr.
For ext4, we only need to enable the FS_MGTIME flag.
Reviewed-by: Josef Bacik
Reviewed-by: Jan Kara
Tested-by: Randy Dunlap
On Mon, 2024-09-30 at 23:35 +0200, Thomas Gleixner wrote:
> On Mon, Sep 30 2024 at 16:53, Jeff Layton wrote:
> > On Mon, 2024-09-30 at 22:19 +0200, Thomas Gleixner wrote:
> > > On Mon, Sep 30 2024 at 15:37, Jeff Layton wrote:
> > > > If however, two threads have racing syscalls that overlap in time
Hi,
On 1-Oct-24 8:17 AM, Ard Biesheuvel wrote:
> On Thu, 26 Sept 2024 at 19:02, Steven Rostedt wrote:
>>
>> From: Steven Rostedt
>>
>> At the 2024 Linux Plumbers Conference, I was talking with Hans de Goede
>> about the persistent buffer to display traces from previous boots. He
>> mentioned tha
On Tue, Oct 1, 2024 at 12:18 AM Hari Bathini wrote:
>
>
>
> On 30/09/24 6:25 pm, Alexei Starovoitov wrote:
> > On Sun, Sep 29, 2024 at 10:33 PM Hari Bathini
> > wrote:
> >>
> >>
> >>
> >> On 17/09/24 1:20 pm, Alexei Starovoitov wrote:
> >>> On Sun, Sep 15, 2024 at 10:58 PM Hari Bathini
> >>> w
On Tue, 01 Oct 2024 13:29:58 +
Alice Ryhl wrote:
> Add just enough support for static key so that we can use it from
> tracepoints. Tracepoints rely on `static_key_false` even though it is
> deprecated, so we add the same functionality to Rust.
>
> This patch only provides a generic implemen
On Tue, Oct 1, 2024 at 3:14 PM Steven Rostedt wrote:
>
>
> Hi Alice,
>
> Can you rebase this series on v6.12-rc1?
Done:
https://lore.kernel.org/rust-for-linux/20241001-tracepoint-v9-0-1ad3b7d78...@google.com/
Alice
On Tue 01-10-24 06:58:58, Jeff Layton wrote:
> When updating the ctime on an inode for a SETATTR with a multigrain
> filesystem, we usually want to take the latest time we can get for the
> ctime. The exception to this rule is when there is a nfsd write
> delegation and the server is proxying times
On 10/1/24 10:27 PM, ts wrote:
On 9/30/24 8:51 AM, Masami Hiramatsu (Google) wrote:
On Thu, 26 Sep 2024 15:13:07 +0900
Tatsuya S wrote:
A extra entry is shown on stack trace(CONFIG_UNWINDER_ORC=y).
[003] . 110.171589: vfs_write <-__x64_sys_write
[003] . 110.171600:
On Tue, 1 Oct 2024 at 14:52, Steven Rostedt wrote:
>
> On Tue, 1 Oct 2024 11:35:53 +0200
> Ard Biesheuvel wrote:
>
> > All I am asking for is a line in the documentation that says that
> > clobbered trace buffers could occur at any time, regardless of whether
> > CONFIG_RESET_ATTACK_MITIGATION is
On Tue, 2024-10-01 at 15:20 +0200, Jan Kara wrote:
> On Tue 01-10-24 06:58:56, Jeff Layton wrote:
> > The VFS has always used coarse-grained timestamps when updating the
> > ctime and mtime after a change. This has the benefit of allowing
> > filesystems to optimize away a lot metadata updates, dow
To allow the Rust implementation of static_key_false to use runtime code
patching instead of the generic implementation, pull in the relevant
inline assembly from the jump_label.h header by running the C
preprocessor on a .rs.S file. Build rules are added for .rs.S files.
Since the relevant inline
Make it possible to have Rust code call into tracepoints defined by C
code. It is still required that the tracepoint is declared in a C
header, and that this header is included in the input to bindgen.
Instead of calling __DO_TRACE directly, the exported rust_do_trace_
function calls an inline hel
Hi Alice,
Can you rebase this series on v6.12-rc1?
Thanks,
-- Steve
On Thu, 22 Aug 2024 12:04:12 +
Alice Ryhl wrote:
> An important part of a production ready Linux kernel driver is
> tracepoints. So to write production ready Linux kernel drivers in Rust,
> we must be able to call trac
This updates the Rust printing sample to invoke a tracepoint. This
ensures that we have a user in-tree from the get-go even though the
patch is being merged before its real user.
Reviewed-by: Boqun Feng
Signed-off-by: Alice Ryhl
---
MAINTAINERS| 1 +
include/trace/event
On 9/30/24 8:51 AM, Masami Hiramatsu (Google) wrote:
On Thu, 26 Sep 2024 15:13:07 +0900
Tatsuya S wrote:
A extra entry is shown on stack trace(CONFIG_UNWINDER_ORC=y).
[003] . 110.171589: vfs_write <-__x64_sys_write
[003] . 110.171600:
=> X (Wrong function nam
An important part of a production ready Linux kernel driver is
tracepoints. So to write production ready Linux kernel drivers in Rust,
we must be able to call tracepoints from Rust code. This patch series
adds support for calling tracepoints declared in C from Rust.
This series includes a patch th
On Tue, 1 Oct 2024 22:27:03 +0900
ts wrote:
> > ...
> >sh-140 [001] ...1.18.352601: myevent:
> > (vfs_write+0x4/0x560)
> >sh-140 [001] ...1.18.352602:
> > => ksys_write
> > => do_syscall_64
> > => entry_SYSCALL_64_after_hwframe
> >
New percpu counters for counting various stats around multigrain
timestamp events, and a new debugfs file for displaying them when
CONFIG_DEBUG_FS is enabled:
- number of attempted ctime updates
- number of successful i_ctime_nsec swaps
- number of fine-grained timestamp fetches
Reviewed-by: Jose
Enable multigrain timestamps, which should ensure that there is an
apparent change to the timestamp whenever it has been written after
being actively observed via getattr.
Also, anytime the mtime changes, the ctime must also change, and those
are now the only two options for xfs_trans_ichgtime. Ha
Add a high-level document that describes how multigrain timestamps work,
rationale for them, and some info about implementation and tradeoffs.
Reviewed-by: Josef Bacik
Reviewed-by: Darrick J. Wong
Reviewed-by: Randy Dunlap
Reviewed-by: Jan Kara
Tested-by: Randy Dunlap # documentation bits
Sig
Enable multigrain timestamps, which should ensure that there is an
apparent change to the timestamp whenever it has been written after
being actively observed via getattr.
tmpfs only requires the FS_MGTIME flag.
Reviewed-by: Josef Bacik
Reviewed-by: Jan Kara
Tested-by: Randy Dunlap # documenta
The setattr codepath is still using coarse-grained timestamps, even on
multigrain filesystems. To fix this, we need to fetch the timestamp for
ctime updates later, at the point where the assignment occurs in
setattr_copy.
On a multigrain inode, ignore the ia_ctime in the attrs, and always
update t
Enable multigrain timestamps, which should ensure that there is an
apparent change to the timestamp whenever it has been written after
being actively observed via getattr.
Beyond enabling the FS_MGTIME flag, this patch eliminates
update_time_for_write, which goes to great pains to avoid in-memory
The VFS has always used coarse-grained timestamps when updating the
ctime and mtime after a change. This has the benefit of allowing
filesystems to optimize away a lot metadata updates, down to around 1
per jiffy, even when a file is under heavy writes.
Unfortunately, this has always been an issue
The mgtime_floor value is a global variable for tracking the latest
fine-grained timestamp handed out. Because it's a global, track the
number of times that a new floor value is assigned.
Add a new percpu counter to the timekeeping code to track the number of
floor swap events that have occurred.
On 30/09/24 6:25 pm, Alexei Starovoitov wrote:
On Sun, Sep 29, 2024 at 10:33 PM Hari Bathini wrote:
On 17/09/24 1:20 pm, Alexei Starovoitov wrote:
On Sun, Sep 15, 2024 at 10:58 PM Hari Bathini wrote:
+
+ /*
+* Generated stack layout:
+*
+* func prev back
On Mon, Sep 30, 2024 at 02:36:35PM -0700, Andrii Nakryiko wrote:
> On Sun, Sep 29, 2024 at 1:58 PM Jiri Olsa wrote:
> >
> > Adding support to attach program in uprobe session mode
> > with bpf_program__attach_uprobe_multi function.
> >
> > Adding session bool to bpf_uprobe_multi_opts struct that a
On Mon, Sep 30, 2024 at 02:36:08PM -0700, Andrii Nakryiko wrote:
SNIP
> > struct bpf_uprobe_multi_link {
> > @@ -3248,9 +3260,13 @@ uprobe_multi_link_handler(struct uprobe_consumer
> > *con, struct pt_regs *regs,
> > __u64 *data)
> > {
> > struct bpf_uprobe *u
This is a replacement for the v6 series sitting in Christian's
vfs.mgtime branch.
The kernel test robot reported a performance regression in v6 due to the
changes to current_time(). This patchset addresses that by moving the
ctime floor handling into the timekeeper code, which allows us to avoid
m
From: Steven Rostedt
At the 2024 Linux Plumbers Conference, I was talking with Hans de Goede
about the persistent buffer to display traces from previous boots. He
mentioned that UEFI can clear memory. In my own tests I have not seen
this. He later informed me that it requires the config option:
On Mon, Sep 30, 2024 at 02:36:28PM -0700, Andrii Nakryiko wrote:
> On Sun, Sep 29, 2024 at 1:58 PM Jiri Olsa wrote:
> >
> > The uprobe and kprobe session program can return only 0 or 1,
> > instruct verifier to check for that.
> >
> > Signed-off-by: Jiri Olsa
> > ---
> > kernel/bpf/verifier.c |
When updating the ctime on an inode for a SETATTR with a multigrain
filesystem, we usually want to take the latest time we can get for the
ctime. The exception to this rule is when there is a nfsd write
delegation and the server is proxying timestamps from the client.
When nfsd gets a CB_GETATTR r
On Tue 01-10-24 06:58:56, Jeff Layton wrote:
> The VFS has always used coarse-grained timestamps when updating the
> ctime and mtime after a change. This has the benefit of allowing
> filesystems to optimize away a lot metadata updates, down to around 1
> per jiffy, even when a file is under heavy
Add some tracepoints around various multigrain timestamp events.
Reviewed-by: Josef Bacik
Reviewed-by: Darrick J. Wong
Reviewed-by: Jan Kara
Reviewed-by: Steven Rostedt (Google)
Tested-by: Randy Dunlap # documentation bits
Signed-off-by: Jeff Layton
---
fs/inode.c |
Multigrain timestamps allow the kernel to use fine-grained timestamps
when an inode's attributes is being actively observed via ->getattr().
With this support, it's possible for a file to get a fine-grained
timestamp, and another modified after it to get a coarse-grained stamp
that is earlier than
On Mon, Sep 30, 2024 at 02:36:03PM -0700, Andrii Nakryiko wrote:
> On Sun, Sep 29, 2024 at 1:57 PM Jiri Olsa wrote:
> >
> > This change allows the uprobe consumer to behave as session which
> > means that 'handler' and 'ret_handler' callbacks are connected in
> > a way that allows to:
> >
> > -
Hello,
On top of
[PATCH 0/7] uprobes: deuglify xol_get_insn_slot/xol_free_insn_slot paths
https://lore.kernel.org/all/20240929144201.ga9...@redhat.com/
To me this change looks like a simplification, but perhaps it can
also be considered as optimization.
Yes, in the contended cas
On 09/27, Liao Chang wrote:
>
> The uprobe handler allocates xol slot from xol_area and quickly release
> it in the single-step handler. The atomic operations on the xol bitmap
> and slot_count lead to expensive cache line bouncing between multiple
> CPUs.
Liao, could you please check if this seri
After the previous change xol_take_insn_slot() becomes trivial, kill it.
Signed-off-by: Oleg Nesterov
---
kernel/events/uprobes.c | 17 -
1 file changed, 4 insertions(+), 13 deletions(-)
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index 38d91e10d455..40ecab097
Add just enough support for static key so that we can use it from
tracepoints. Tracepoints rely on `static_key_false` even though it is
deprecated, so we add the same functionality to Rust.
This patch only provides a generic implementation without code patching
(matching the one used when CONFIG_J
Can I get some more acks from the arch maintainers? So far there's only one
ack from Peter Zijlstra for x86. But this touches arm, arm64, loongarch and
riscv too.
-- Steve
On Tue, 01 Oct 2024 13:30:01 +
Alice Ryhl wrote:
> To avoid duplication of inline asm between C and Rust, we need to
To avoid duplication of inline asm between C and Rust, we need to
import the inline asm from the relevant `jump_label.h` header into Rust.
To make that easier, this patch updates the header files to expose the
inline asm via a new ARCH_STATIC_BRANCH_ASM macro.
The header files are all updated to d
On Mon, 30 Sep 2024 11:32:31 -0400
Steven Rostedt wrote:
> > uprobe_register/unregister APIs are exposed to the kernel modules,
> > since systemtap had been introduced this feature.
> >
>
> OK, but since they have always been visible, I would just make
> CONFIG_UPROBES a normal option and CONF
On Tue, Oct 1, 2024 at 4:11 PM Steven Rostedt wrote:
>
> On Tue, 01 Oct 2024 13:29:58 +
> Alice Ryhl wrote:
>
> > Add just enough support for static key so that we can use it from
> > tracepoints. Tracepoints rely on `static_key_false` even though it is
> > deprecated, so we add the same func
Add the new helper, xol_get_slot_nr() which does
find_first_zero_bit() + test_and_set_bit().
xol_take_insn_slot() can wait for the "xol_get_slot_nr() < UINSNS_PER_PAGE"
event instead of "area->slot_count < UINSNS_PER_PAGE".
So we can kill area->slot_count and avoid atomic_inc() + atomic_dec(), th
87 matches
Mail list logo
