t ACPI NFIT devices");
> MODULE_LICENSE("GPL v2");
> MODULE_AUTHOR("Intel Corporation");
>
> ---
> base-commit: 2df0193e62cf887f373995fb8a91068562784adc
> change-id: 20240611-nvdimm-test-mod-warn-8cf773360b37
>
> Best regards,
Not on my radar, so thanks for fixing!
Reviewed-by: Jeff Johnson
it);
+MODULE_DESCRIPTION("Test ACPI NFIT devices");
MODULE_LICENSE("GPL v2");
MODULE_AUTHOR("Intel Corporation");
---
base-commit: 2df0193e62cf887f373995fb8a91068562784adc
change-id: 20240611-nvdimm-test-mod-warn-8cf773360b37
Best regards,
--
Ira Weiny
From: "Steven Rostedt (Google)"
The addresses of a stack trace event are relative to the kallsyms. As that
can change between boots, when printing the stack trace from a buffer that
was from the last boot, it needs all the addresses to be added to the
"text_delta" that gives the delta between
From: "Steven Rostedt (Google)"
If an instance is mapped to memory on boot up, create a new file called
"last_boot_info" that will hold information that can be used to properly
parse the raw data in the ring buffer.
It will export the delta of the addresses for text and data from what it
was
From: "Steven Rostedt (Google)"
For a persistent ring buffer that is saved across boots, if function
tracing was performed in the previous boot, it only saves the address of
the functions and uses "%pS" to print their names. But the current boot,
those functions may be in different locations.
From: "Steven Rostedt (Google)"
Use the saved text_delta and data_delta of a persistent memory mapped ring
buffer that was saved from a previous boot, and use the delta in the trace
event print output so that strings and functions show up normally.
That is, for an event like trace_kmalloc()
From: "Steven Rostedt (Google)"
When a ring buffer is mapped to a specific address, save the address of a
text function and some data. This will be used to determine the delta
between the last boot and the current boot for pointers to functions as
well as to data.
Signed-off-by: Steven Rostedt
From: "Steven Rostedt (Google)"
Add an option to the trace_instance kernel command line parameter that
allows it to use the reserved memory from memmap boot parameter.
memmap=12M$0x28450 trace_instance=boot_mapped@0x28450:12M
The above will reserves 12 megs at the physical address
From: "Steven Rostedt (Google)"
Make sure all the events in each of the sub-buffers that were mapped in a
memory region are valid. This moves the code that walks the buffers for
time-stamp validation out of the CONFIG_RING_BUFFER_VALIDATE_TIME_DELTAS
ifdef block and is used to validate the
From: "Steven Rostedt (Google)"
Add a test against the ring buffer memory range to see if it has valid
data. The ring_buffer_meta structure is given a new field called
"first_buffer" which holds the address of the first sub-buffer. This is
used to both determine if the other fields are valid as
From: "Steven Rostedt (Google)"
Add a buffer_meta per-cpu file for the trace instance that is mapped to
boot memory. This shows the current meta-data and can be used by user
space tools to record off the current mappings to help reconstruct the
ring buffer after a reboot.
It does not expose any
From: "Steven Rostedt (Google)"
Allow for creating a new instance by passing in an address and size to map
the ring buffer for the instance to.
This will allow features like a pstore memory mapped region to be used for
an tracing instance ring buffer that can be retrieved from one boot to the
From: "Steven Rostedt (Google)"
Populate the ring_buffer_meta array. It holds the pointer to the
head_buffer (next to read), the commit_buffer (next to write) the size of
the sub-buffers, number of sub-buffers and an array that keeps track of
the order of the sub-buffers.
This information will
From: "Steven Rostedt (Google)"
In preparation for having the ring buffer mapped to a dedicated location,
which will have the same restrictions as user space memory mapped buffers,
allow it to use the "mapped" field of the ring_buffer_per_cpu structure
without having the user space meta page
This is a way to map a ring buffer instance across reboots.
The requirement is that you have a memory region that is not erased.
I tested this on a Debian VM running on qemu on a Debian server,
and even tested it on a baremetal box running Fedora. I was
surprised that it worked on the baremetal
From: "Steven Rostedt (Google)"
In preparation to allowing the trace ring buffer to be allocated in a
range of memory that is persistent across reboots, add
ring_buffer_alloc_range(). It takes a contiguous range of memory and will
split it up evenly for the per CPU ring buffers.
If there's not
The pvmemcontrol driver lives under drivers/virt/pvmemcontrol. We
specify maintainers for the driver.
Signed-off-by: Yuanchu Xie
---
MAINTAINERS | 7 +++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index aacccb376c28..5e661f39e07d 100644
--- a/MAINTAINERS
+++
Pvmemcontrol provides a way for the guest to control its physical memory
properties, and enables optimizations and security features. For
example, the guest can provide information to the host where parts of a
hugepage may be unbacked, or sensitive data may not be swapped out, etc.
Pvmemcontrol
On Tue, 11 Jun 2024 13:32:32 +0800 Cindy Lu wrote:
> Add new UAPI to support the mac address from vdpa tool
> Function vdpa_nl_cmd_dev_config_set_doit() will get the
> MAC address from the vdpa tool and then set it to the device.
>
> The usage is: vdpa dev set name vdpa_name mac **:**:**:**:**:**
On Tue, 11 Jun 2024 21:39:37 -0400
Steven Rostedt wrote:
> >
> > Maybe explain why sometimes __rb_inc_dec_mapped() is called to
> > increment or decrement ->mapped, and sometimes it id done directly ?
> > I can see that the function also acquires the buffer mutex, which
> > isn't needed at the
On Tue, 11 Jun 2024 16:53:43 -0700
Guenter Roeck wrote:
> >>> @@ -6403,7 +6407,8 @@ int ring_buffer_unmap(struct trace_buffer *buffer,
> >>> int cpu)
> >>> mutex_lock(>mutex);
> >>> raw_spin_lock_irqsave(_buffer->reader_lock, flags);
> >>>
> >>> - cpu_buffer->mapped = 0;
On Tue, 11 Jun 2024 06:26:53 +0900
"Masami Hiramatsu (Google)" wrote:
> From: Masami Hiramatsu (Google)
>
> This cleanup all kprobe events code is not related to the selftest
> itself, and it can fail by the reason unrelated to this test.
> If the test is successful, the generated events are
Add basic tracepoints for {alloc, evict, free}_inode, setattr and
fallocate. These can help users to debug hugetlbfs more conveniently.
Signed-off-by: Hongbo Li
---
MAINTAINERS | 1 +
include/trace/events/hugetlbfs.h | 164 +++
2 files changed,
Here we use the hugetlbfs tracepoint to track the call stack. And
the output in trace is as follows:
```
touch-5307[004] . 1402.167607: hugetlbfs_alloc_inode: dev = (0,50),
ino = 21380, dir = 16921, mode = 0100644
touch-5307[004] . 1402.167638: hugetlbfs_setattr: dev = (0,50),
Here we add some basic tracepoints for debugging hugetlbfs: {alloc, free,
evict}_inode, setattr and fallocate.
Hongbo Li (2):
hugetlbfs: support tracepoint
hugetlbfs: use tracepoints in hugetlbfs functions.
MAINTAINERS | 1 +
fs/hugetlbfs/inode.c | 21
On 6/11/24 15:53, Steven Rostedt wrote:
On Tue, 11 Jun 2024 15:43:59 -0700
Guenter Roeck wrote:
On 6/11/24 12:28, Steven Rostedt wrote:
From: "Steven Rostedt (Google)"
In preparation for having the ring buffer mapped to a dedicated location,
which will have the same restrictions as user
On Tue, 11 Jun 2024 10:25:00 -0400
Steven Rostedt wrote:
> On Tue, 11 Jun 2024 22:30:56 +0900
> "Masami Hiramatsu (Google)" wrote:
>
> > From: Masami Hiramatsu (Google)
> >
> > This cleanup all kprobe events code is not related to the selftest
> > itself, and it can fail by the reason
On 6/11/2024 5:33 AM, Sudeepgoud Patil wrote:
This commit introduces tracepoint support for smp2p,
enabling logging of communication between local and remote processors.
The tracepoints include information about the remote processor ID,
remote subsystem name, negotiation details, supported
On Tue, 11 Jun 2024 15:43:59 -0700
Guenter Roeck wrote:
> On 6/11/24 12:28, Steven Rostedt wrote:
> > From: "Steven Rostedt (Google)"
> >
> > In preparation for having the ring buffer mapped to a dedicated location,
> > which will have the same restrictions as user space memory mapped buffers,
On 6/11/24 12:28, Steven Rostedt wrote:
From: "Steven Rostedt (Google)"
In preparation for having the ring buffer mapped to a dedicated location,
which will have the same restrictions as user space memory mapped buffers,
allow it to use the "mapped" field of the ring_buffer_per_cpu structure
On Tue, 2024-06-11 at 07:57 -0500, Haitao Huang wrote:
> On Mon, 10 Jun 2024 17:39:53 -0500, Huang, Kai wrote:
>
> >
> > > --- a/arch/x86/kernel/cpu/sgx/main.c
> > > +++ b/arch/x86/kernel/cpu/sgx/main.c
> > > @@ -1045,7 +1045,7 @@ static int __init sgx_init(void)
> > >if
Commit e3e9bda38e6d ("s390/virtio_ccw: use DMA handle from DMA API")
broke configuration change notifications for virtio-ccw by putting the
DMA address of *indicatorp directly into ccw->cda disregarding the fact
that if !!(vcdev->is_thinint) then the function
virtio_ccw_register_adapter_ind() will
Replace kfree_skb_reason with sk_skb_reason_drop and pass the receiving
socket to the tracepoint.
Reported-by: kernel test robot
Closes: https://lore.kernel.org/r/202406011859.aacus8gv-...@intel.com/
Signed-off-by: Yan Zhai
---
v2->v3: fixed uninitialized sk, added missing report tags.
---
Replace kfree_skb_reason with sk_skb_reason_drop and pass the receiving
socket to the tracepoint.
Reported-by: kernel test robot
Closes: https://lore.kernel.org/r/202406011751.npvn0ssk-...@intel.com/
Signed-off-by: Yan Zhai
---
v2->v3: added missing report tags
---
net/ipv4/udp.c | 10
Replace kfree_skb_reason with sk_skb_reason_drop and pass the receiving
socket to the tracepoint.
Reported-by: kernel test robot
Closes: https://lore.kernel.org/r/202406011539.jhwbd7dx-...@intel.com/
Signed-off-by: Yan Zhai
---
v2->v3: added missing report tags
---
net/ipv4/syncookies.c | 2 +-
Replace kfree_skb_reason with sk_skb_reason_drop and pass the receiving
socket to the tracepoint.
Signed-off-by: Yan Zhai
---
net/ipv4/raw.c | 4 ++--
net/ipv6/raw.c | 8
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c
index
Replace kfree_skb_reason with sk_skb_reason_drop and pass the receiving
socket to the tracepoint.
Signed-off-by: Yan Zhai
---
net/ipv4/ping.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/ping.c b/net/ipv4/ping.c
index 823306487a82..619ddc087957 100644
---
Long used destructors kfree_skb and kfree_skb_reason do not pass
receiving socket to packet drop tracepoints trace_kfree_skb.
This makes it hard to track packet drops of a certain netns (container)
or a socket (user application).
The naming of these destructors are also not consistent with most
skb does not include enough information to find out receiving
sockets/services and netns/containers on packet drops. In theory
skb->dev tells about netns, but it can get cleared/reused, e.g. by TCP
stack for OOO packet lookup. Similarly, skb->sk often identifies a local
sender, and tells nothing
We set up our production packet drop monitoring around the kfree_skb
tracepoint. While this tracepoint is extremely valuable for diagnosing
critical problems, it also has some limitation with drops on the local
receive path: this tracepoint can only inspect the dropped skb itself,
but such skb
On Fri, May 24, 2024 at 06:14:03PM +0200, Dylan Van Assche wrote:
> Use fastrpc_remote_heap_alloc to allocate from the FastRPC device
> instead of the Compute Bank when the session ID is 0. This ensures
> that the allocation is inside the coherent DMA pool which is already
> accessible to the DSP.
On Fri, May 24, 2024 at 06:14:02PM +0200, Dylan Van Assche wrote:
> To support FastRPC Context Banks which aren't mapped via the SMMU,
> make the whole reserved memory region available to the DSP to allow
> access to coherent buffers.
>
> This is performed by assigning the memory to the DSP via a
From: "Steven Rostedt (Google)"
The addresses of a stack trace event are relative to the kallsyms. As that
can change between boots, when printing the stack trace from a buffer that
was from the last boot, it needs all the addresses to be added to the
"text_delta" that gives the delta between
From: "Steven Rostedt (Google)"
Use the saved text_delta and data_delta of a persistent memory mapped ring
buffer that was saved from a previous boot, and use the delta in the trace
event print output so that strings and functions show up normally.
That is, for an event like trace_kmalloc()
From: "Steven Rostedt (Google)"
For a persistent ring buffer that is saved across boots, if function
tracing was performed in the previous boot, it only saves the address of
the functions and uses "%pS" to print their names. But the current boot,
those functions may be in different locations.
From: "Steven Rostedt (Google)"
If an instance is mapped to memory on boot up, create a new file called
"last_boot_info" that will hold information that can be used to properly
parse the raw data in the ring buffer.
It will export the delta of the addresses for text and data from what it
was
From: "Steven Rostedt (Google)"
Add an option to the trace_instance kernel command line parameter that
allows it to use the reserved memory from memmap boot parameter.
memmap=12M$0x28450 trace_instance=boot_mapped@0x28450:12M
The above will reserves 12 megs at the physical address
From: "Steven Rostedt (Google)"
When a ring buffer is mapped to a specific address, save the address of a
text function and some data. This will be used to determine the delta
between the last boot and the current boot for pointers to functions as
well as to data.
Signed-off-by: Steven Rostedt
From: "Steven Rostedt (Google)"
Make sure all the events in each of the sub-buffers that were mapped in a
memory region are valid. This moves the code that walks the buffers for
time-stamp validation out of the CONFIG_RING_BUFFER_VALIDATE_TIME_DELTAS
ifdef block and is used to validate the
From: "Steven Rostedt (Google)"
Add a test against the ring buffer memory range to see if it has valid
data. The ring_buffer_meta structure is given a new field called
"first_buffer" which holds the address of the first sub-buffer. This is
used to both determine if the other fields are valid as
From: "Steven Rostedt (Google)"
Add a buffer_meta per-cpu file for the trace instance that is mapped to
boot memory. This shows the current meta-data and can be used by user
space tools to record off the current mappings to help reconstruct the
ring buffer after a reboot.
It does not expose any
From: "Steven Rostedt (Google)"
Populate the ring_buffer_meta array. It holds the pointer to the
head_buffer (next to read), the commit_buffer (next to write) the size of
the sub-buffers, number of sub-buffers and an array that keeps track of
the order of the sub-buffers.
This information will
From: "Steven Rostedt (Google)"
In preparation to allowing the trace ring buffer to be allocated in a
range of memory that is persistent across reboots, add
ring_buffer_alloc_range(). It takes a contiguous range of memory and will
split it up evenly for the per CPU ring buffers.
If there's not
From: "Steven Rostedt (Google)"
Allow for creating a new instance by passing in an address and size to map
the ring buffer for the instance to.
This will allow features like a pstore memory mapped region to be used for
an tracing instance ring buffer that can be retrieved from one boot to the
From: "Steven Rostedt (Google)"
In preparation for having the ring buffer mapped to a dedicated location,
which will have the same restrictions as user space memory mapped buffers,
allow it to use the "mapped" field of the ring_buffer_per_cpu structure
without having the user space meta page
This is a way to map a ring buffer instance across reboots.
The requirement is that you have a memory region that is not erased.
I tested this on a Debian VM running on qemu on a Debian server,
and even tested it on a baremetal box running Fedora. I was
surprised that it worked on the baremetal
se-commit: 83a7eefedc9b56fe7bfeff13b6c7356688ffa670
change-id: 20240611-md-drivers-vdpa-391206d17ec3
On Tue, Jun 11, 2024 at 10:53:01AM -0700, Chris Lew wrote:
>
>
> On 6/11/2024 9:06 AM, Bjorn Andersson wrote:
> > On Tue, Jun 11, 2024 at 06:03:50PM +0530, Sudeepgoud Patil wrote:
> > > Add smp2p irq devname which fetches remote name from respective
> > > smp2p dtsi node, which makes the wakeup
Hi Andrew,
On Mon, Jun 10, 2024 at 10:17:20AM -0500, Andrew Davis wrote:
> This helps prevent mistakes like freeing out of order in cleanup functions
> and forgetting to free on error paths.
>
> Signed-off-by: Andrew Davis
> ---
> drivers/remoteproc/da8xx_remoteproc.c | 29
On 6/11/2024 9:06 AM, Bjorn Andersson wrote:
On Tue, Jun 11, 2024 at 06:03:50PM +0530, Sudeepgoud Patil wrote:
Add smp2p irq devname which fetches remote name from respective
smp2p dtsi node, which makes the wakeup source distinguishable
in irq wakeup prints.
Signed-off-by: Sudeepgoud Patil
On Mon, Jun 10, 2024 at 08:36:19PM +0300, Fedor Pchelkin wrote:
> On Mon, 10. Jun 10:47, Mathieu Poirier wrote:
> > On Thu, Jun 06, 2024 at 10:52:04AM +0300, Aleksandr Mishin wrote:
> > > In imx_rproc_addr_init() "nph = of_count_phandle_with_args()" just counts
> > > number of phandles. But
On Tue, Jun 11, 2024 at 06:03:50PM +0530, Sudeepgoud Patil wrote:
> Add smp2p irq devname which fetches remote name from respective
> smp2p dtsi node, which makes the wakeup source distinguishable
> in irq wakeup prints.
>
> Signed-off-by: Sudeepgoud Patil
> ---
> drivers/soc/qcom/smp2p.c | 14
On Tue, 11 Jun 2024 13:21:49 +0200
Jiri Olsa wrote:
> hi,
> as part of the effort on speeding up the uprobes [0] coming with
> return uprobe optimization by using syscall instead of the trap
> on the uretprobe trampoline.
>
> The speed up depends on instruction type that uprobe is installed
>
Hi,
On Tue, Jun 11, 2024 at 11:30:22PM GMT, Masami Hiramatsu wrote:
> On Tue, 11 Jun 2024 13:21:58 +0200
> Jiri Olsa wrote:
>
> > Adding man page for new uretprobe syscall.
> >
> > Acked-by: Andrii Nakryiko
> > Reviewed-by: Alejandro Colomar
> > Signed-off-by: Jiri Olsa
>
> This looks good
On Tue, 11 Jun 2024 13:21:58 +0200
Jiri Olsa wrote:
> Adding man page for new uretprobe syscall.
>
> Acked-by: Andrii Nakryiko
> Reviewed-by: Alejandro Colomar
> Signed-off-by: Jiri Olsa
This looks good to me.
Reviewed-by: Masami Hiramatsu (Google)
And this needs to be picked by
On Tue, 11 Jun 2024 09:30:52 +0100
Andrii Nakryiko wrote:
>
> > I think it would be better to include those patches together in
> > linux-tree. Can you review and ack to the last patch ? ([9/9])
>
> Sure. Jiri, please add my ack for the entire series in the next revision:
>
> Acked-by: Andrii
On Tue, 11 Jun 2024 22:30:56 +0900
"Masami Hiramatsu (Google)" wrote:
> From: Masami Hiramatsu (Google)
>
> This cleanup all kprobe events code is not related to the selftest
> itself, and it can fail by the reason unrelated to this test.
> If the test is successful, the generated events are
On Tue, 11 Jun 2024 22:30:46 +0900
"Masami Hiramatsu (Google)" wrote:
> From: Masami Hiramatsu (Google)
>
> Cleanup the redundant WARN_ON_ONCE(cond) + pr_warn(msg) into
> WARN_ONCE(cond, msg). Also add some WARN_ONCE() for hitcount check.
> These WARN_ONCE() errors makes it easy to handle
On Tue, 11 Jun 2024 11:03:25 +0200
Daniel Bristot de Oliveira wrote:
> On 6/10/24 21:20, Qais Yousef wrote:
> > - if (realtime_prio(p->prio)) /* includes deadline */
> > + if (rt_or_dl_prio(p->prio))
>
> that is it... no thinking, no recall, no comment, no confusion...
How about
On Tue, 11 Jun 2024 10:42:28 +0200
Vlastimil Babka wrote:
> AFAICS that documented way is for a different situation? I assume you mean
> this part:
>
> * Specify any additional patch prerequisites for cherry picking::
>
> Cc: # 3.3.x: a1f84a3: sched: Check for idle
>
> But that would
On Tue, 11 Jun 2024 08:23:11 +0200
Greg KH wrote:
> > Depends-on: c9929f0e344a ("mm/slob: remove CONFIG_SLOB")
>
> Ick, no, use the documented way of handling this as described in the
> stable kernel rules file.
You mentioned this before, I guess you mean this:
> To send additional
From: Masami Hiramatsu (Google)
This cleanup all kprobe events code is not related to the selftest
itself, and it can fail by the reason unrelated to this test.
If the test is successful, the generated events are cleaned up.
And if not, we cannot guarantee that the kprobe events will work
From: Masami Hiramatsu (Google)
Cleanup the redundant WARN_ON_ONCE(cond) + pr_warn(msg) into
WARN_ONCE(cond, msg). Also add some WARN_ONCE() for hitcount check.
These WARN_ONCE() errors makes it easy to handle errors from ktest.
Suggested-by: Steven Rostedt
Signed-off-by: Masami Hiramatsu
From: Masami Hiramatsu (Google)
The kprobes and synth event generation test modules add events and lock
(get a reference) those event file reference in module init function,
and unlock and delete it in module exit function. This is because those
are designed for playing as modules.
If we make
Hi,
Here is v3 of a series of some fixes/cleanups for the test modules and
boot time selftest of kprobe events. The previous version is here;
https://lore.kernel.org/all/171805478534.52471.6269290579314514778.stgit@devnote2/
In this version, I updated the 2nd patch to integrate WARN_ON_ONCE()
On Mon, 10 Jun 2024 17:39:53 -0500, Huang, Kai wrote:
--- a/arch/x86/kernel/cpu/sgx/main.c
+++ b/arch/x86/kernel/cpu/sgx/main.c
@@ -1045,7 +1045,7 @@ static int __init sgx_init(void)
if (!sgx_page_cache_init())
return -ENOMEM;
-if (!sgx_page_reclaimer_init()) {
+if
On 5/24/2024 9:44 PM, Dylan Van Assche wrote:
> Use fastrpc_remote_heap_alloc to allocate from the FastRPC device
> instead of the Compute Bank when the session ID is 0. This ensures
> that the allocation is inside the coherent DMA pool which is already
> accessible to the DSP. This is
On 5/24/2024 9:44 PM, Dylan Van Assche wrote:
> To support FastRPC Context Banks which aren't mapped via the SMMU,
> make the whole reserved memory region available to the DSP to allow
> access to coherent buffers.
>
> This is performed by assigning the memory to the DSP via a hypervisor
> call
This commit introduces tracepoint support for smp2p,
enabling logging of communication between local and remote processors.
The tracepoints include information about the remote processor ID,
remote subsystem name, negotiation details, supported features,
bit change notifications, and ssr activity.
Add smp2p irq devname which fetches remote name from respective
smp2p dtsi node, which makes the wakeup source distinguishable
in irq wakeup prints.
Signed-off-by: Sudeepgoud Patil
---
drivers/soc/qcom/smp2p.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git
This commit introduces tracepoint support to smp2p module, enabling logging of
communication
events between local and remote processors. The tracepoints capture essential
details
such as remote processor ID, subsystem names, negotiation specifics, supported
features,
bit changes, and subsystem
Adding man page for new uretprobe syscall.
Acked-by: Andrii Nakryiko
Reviewed-by: Alejandro Colomar
Signed-off-by: Jiri Olsa
---
man/man2/uretprobe.2 | 56
1 file changed, 56 insertions(+)
create mode 100644 man/man2/uretprobe.2
diff --git
Adding uretprobe shadow stack test that runs all existing
uretprobe tests with shadow stack enabled if it's available.
Acked-by: Andrii Nakryiko
Reviewed-by: Masami Hiramatsu (Google)
Signed-off-by: Jiri Olsa
---
.../selftests/bpf/prog_tests/uprobe_syscall.c | 60 +++
1 file
Adding test to verify that when called from outside of the
trampoline provided by kernel, the uretprobe syscall will cause
calling process to receive SIGILL signal and the attached bpf
program is not executed.
Acked-by: Andrii Nakryiko
Reviewed-by: Masami Hiramatsu (Google)
Signed-off-by: Jiri
Adding test that creates uprobe consumer on uretprobe which changes some
of the registers. Making sure the changed registers are propagated to the
user space when the ureptobe syscall trampoline is used on x86_64.
To be able to do this, adding support to bpf_testmod to create uprobe via
new
Add uretprobe syscall test that compares register values before
and after the uretprobe is hit. It also compares the register
values seen from attached bpf program.
Acked-by: Andrii Nakryiko
Reviewed-by: Masami Hiramatsu (Google)
Signed-off-by: Jiri Olsa
---
tools/include/linux/compiler.h
Adding return uprobe test for shadow stack and making sure it's
working properly. Borrowed some of the code from bpf selftests.
Acked-by: Andrii Nakryiko
Signed-off-by: Jiri Olsa
---
.../testing/selftests/x86/test_shadow_stack.c | 145 ++
1 file changed, 145 insertions(+)
diff
Adding uretprobe syscall instead of trap to speed up return probe.
At the moment the uretprobe setup/path is:
- install entry uprobe
- when the uprobe is hit, it overwrites probed function's return address
on stack with address of the trampoline that contains breakpoint
instruction
Wiring up uretprobe system call, which comes in following changes.
We need to do the wiring before, because the uretprobe implementation
needs the syscall number.
Note at the moment uretprobe syscall is supported only for native
64-bit process.
Reviewed-by: Oleg Nesterov
Reviewed-by: Masami
Currently the application with enabled shadow stack will crash
if it sets up return uprobe. The reason is the uretprobe kernel
code changes the user space task's stack, but does not update
shadow stack accordingly.
Adding new functions to update values on shadow stack and using
them in uprobe
hi,
as part of the effort on speeding up the uprobes [0] coming with
return uprobe optimization by using syscall instead of the trap
on the uretprobe trampoline.
The speed up depends on instruction type that uprobe is installed
and depends on specific HW type, please check patch 1 for details.
On 2024/6/11 17:21, Peter Zijlstra wrote:
On Tue, Jun 11, 2024 at 09:56:51AM +0800, Zheng Yejian wrote:
On 2024/6/7 23:02, Peter Zijlstra wrote:
Oh gawd, sodding weak functions again.
I would suggest changing scipts/kallsyms.c to emit readily identifiable
symbol names for all the weak junk,
On Tue, Jun 11, 2024 at 09:56:51AM +0800, Zheng Yejian wrote:
> On 2024/6/7 23:02, Peter Zijlstra wrote:
> > Oh gawd, sodding weak functions again.
> >
> > I would suggest changing scipts/kallsyms.c to emit readily identifiable
> > symbol names for all the weak junk, eg:
> >
> >
On 11.06.24 10:42, Vlastimil Babka wrote:
> On 6/11/24 8:23 AM, Greg KH wrote:
>> On Mon, Jun 10, 2024 at 11:40:54PM +0200, Vlastimil Babka wrote:
>>> On 6/10/24 10:36 PM, Steven Rostedt wrote:
On Mon, 10 Jun 2024 08:46:42 -0700
"Paul E. McKenney" wrote:
>>> index
On 6/10/24 21:20, Qais Yousef wrote:
> - if (realtime_prio(p->prio)) /* includes deadline */
> + if (rt_or_dl_prio(p->prio))
that is it... no thinking, no recall, no comment, no confusion...
-- Daniel.
On 6/11/24 8:23 AM, Greg KH wrote:
> On Mon, Jun 10, 2024 at 11:40:54PM +0200, Vlastimil Babka wrote:
>> On 6/10/24 10:36 PM, Steven Rostedt wrote:
>> > On Mon, 10 Jun 2024 08:46:42 -0700
>> > "Paul E. McKenney" wrote:
>> >
>> >> > > index 7c29f4afc23d..338c52168e61 100644
>> >> > > ---
On Mon, Jun 10, 2024 at 10:46 PM Masami Hiramatsu wrote:
>
> On Wed, 5 Jun 2024 09:42:45 -0700
> Andrii Nakryiko wrote:
>
> > On Fri, May 31, 2024 at 10:52 AM Andrii Nakryiko
> > wrote:
> > >
> > > On Thu, May 23, 2024 at 5:11 AM Jiri Olsa wrote:
> > > >
> > > > hi,
> > > > as part of the
On Tue, Jun 11, 2024 at 07:05:21AM +0900, Masami Hiramatsu wrote:
> On Thu, 23 May 2024 14:11:42 +0200
> Jiri Olsa wrote:
>
> > Wiring up uretprobe system call, which comes in following changes.
> > We need to do the wiring before, because the uretprobe implementation
> > needs the syscall
Add a remoteproc TEE (Trusted Execution Environment) driver
that will be probed by the TEE bus. If the associated Trusted
application is supported on secure part this driver offers a client
interface to load a firmware in the secure part.
This firmware could be authenticated by the secure trusted
When a resource table is loaded by an external entity such as U-boot or
OP-TEE, we do not necessary get the device address(da) but the physical
address(pa).
This helper performs similar translation than the rproc_da_to_va()
but based on a physical address.
Signed-off-by: Arnaud Pouliquen
---
1 - 100 of 106 matches
Mail list logo
