On Thu, 23 May 2024 19:14:59 -0400
Steven Rostedt wrote:
> On Tue, 7 May 2024 23:08:35 +0900
> "Masami Hiramatsu (Google)" wrote:
>
> > From: Masami Hiramatsu (Google)
> >
> > Add ftrace_regs definition for x86_64 in the ftrace header to
> > clarify what register will be accessible from
On Thu, 23 May 2024 19:10:31 -0400
Steven Rostedt wrote:
> On Tue, 7 May 2024 23:08:12 +0900
> "Masami Hiramatsu (Google)" wrote:
>
> > From: Masami Hiramatsu (Google)
> >
> > To clarify what will be expected on ftrace_regs, add a comment to the
> > architecture independent definition of
On 24/05/23 03:57PM, Miklos Szeredi wrote:
> [trimming CC list]
>
> On Thu, 23 May 2024 at 04:49, John Groves wrote:
>
> > - memmap=! will reserve a pretend pmem device at
> >
> > - memmap=$ will reserve a pretend dax device at
> >
>
> Doesn't get me a /dev/dax or /dev/pmem
>
> Complete
On Mon, 20 May 2024 22:30:17 -0700
Andrii Nakryiko wrote:
> Recent changes made uprobe_cpu_buffer preparation lazy, and moved it
> deeper into __uprobe_trace_func(). This is problematic because
> __uprobe_trace_func() is called inside rcu_read_lock()/rcu_read_unlock()
> block, which then calls
On Tue, 7 May 2024 23:08:35 +0900
"Masami Hiramatsu (Google)" wrote:
> From: Masami Hiramatsu (Google)
>
> Add ftrace_regs definition for x86_64 in the ftrace header to
> clarify what register will be accessible from ftrace_regs.
>
> Signed-off-by: Masami Hiramatsu (Google)
> ---
> Changes
On Tue, 7 May 2024 23:08:12 +0900
"Masami Hiramatsu (Google)" wrote:
> From: Masami Hiramatsu (Google)
>
> To clarify what will be expected on ftrace_regs, add a comment to the
> architecture independent definition of the ftrace_regs.
>
> Signed-off-by: Masami Hiramatsu (Google)
> Acked-by:
On Wed, May 22 2024 at 15:02, Dongli Zhang wrote:
> The absence of IRQD_MOVE_PCNTXT prevents immediate effectiveness of
> interrupt affinity reconfiguration via procfs. Instead, the change is
> deferred until the next instance of the interrupt being triggered on the
> original CPU.
>
> When the
The pull request you sent on Thu, 23 May 2024 02:00:17 -0400:
> https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/2ef32ad2241340565c35baf77fc95053c84eeeb0
Thank you!
--
Deet-doot-dot, I am a
On 5/23/24 11:39, Jürgen Groß wrote:
>>
>> Let's just keep it simple. How about the attached patch?
>
> Simple indeed. The attachment is empty.
Let's try this again.diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index 5358d43886ad..c193c9e60a1b 100644
---
On 23.05.24 18:30, Dave Hansen wrote:
On 5/16/24 06:02, Chen Yu wrote:
Performance drop is reported when running encode/decode workload and
BenchSEE cache sub-workload.
Bisect points to commit ce0a1b608bfc ("x86/paravirt: Silence unused
native_pv_lock_init() function warning"). When
Hello:
This patch was applied to riscv/linux.git (for-next)
by Palmer Dabbelt :
On Thu, 23 May 2024 13:51:34 +0200 you wrote:
> Commit c97bf629963e ("riscv: Fix text patching when IPI are used")
> converted ftrace_make_nop() to use patch_insn_write() which does not
> emit any icache flush
On 5/23/24 12:05 PM, Mathieu Poirier wrote:
> On Wed, May 22, 2024 at 09:36:26AM -0500, Tanmay Shah wrote:
>>
>>
>> On 5/21/24 12:56 PM, Mathieu Poirier wrote:
>> > Hi Tanmay,
>> >
>> > On Fri, May 10, 2024 at 05:51:25PM -0700, Tanmay Shah wrote:
>> >> It is possible that remote processor is
On Wed, May 22, 2024 at 09:36:26AM -0500, Tanmay Shah wrote:
>
>
> On 5/21/24 12:56 PM, Mathieu Poirier wrote:
> > Hi Tanmay,
> >
> > On Fri, May 10, 2024 at 05:51:25PM -0700, Tanmay Shah wrote:
> >> It is possible that remote processor is already running before
> >> linux boot or remoteproc
In the context of the SCTP SNAT/DNAT handler, these calls can only
return true.
Ref: e10d3ba4d434 ("ipvs: Fix checksumming on GSO of SCTP packets")
Signed-off-by: Ismael Luceno
CC: Pablo Neira Ayuso
CC: Michal Kubeček
CC: Simon Horman
CC: Julian Anastasov
CC: lvs-de...@vger.kernel.org
CC:
On 5/16/24 06:02, Chen Yu wrote:
> Performance drop is reported when running encode/decode workload and
> BenchSEE cache sub-workload.
> Bisect points to commit ce0a1b608bfc ("x86/paravirt: Silence unused
> native_pv_lock_init() function warning"). When CONFIG_PARAVIRT_SPINLOCKS
> is disabled the
On Wed, 15 May 2024 23:05:36 +0100
Qais Yousef wrote:
> diff --git a/include/linux/sched/deadline.h b/include/linux/sched/deadline.h
> index df3aca89d4f5..5cb88b748ad6 100644
> --- a/include/linux/sched/deadline.h
> +++ b/include/linux/sched/deadline.h
> @@ -10,8 +10,6 @@
>
> #include
>
>
On Fri, May 17, 2024 at 10:46:02PM +0800, Xuewei Niu wrote:
> include/linux/virtio_vsock.h| 2 +-
> include/net/af_vsock.h | 25 ++-
> include/uapi/linux/virtio_vsock.h | 1 +
> include/uapi/linux/vm_sockets.h | 14 ++
> net/vmw_vsock/af_vsock.c
On Sun, May 19, 2024 at 03:43:43PM +0800, Wardenjohn wrote:
> Livepatch module usually used to modify kernel functions.
> If the patched function have bug, it may cause serious result
> such as kernel crash.
>
> This commit introduce a read only interface of livepatch
> sysfs interface. If a
On Thu, May 23, 2024 at 01:51:34PM +0200, Alexandre Ghiti wrote:
> Commit c97bf629963e ("riscv: Fix text patching when IPI are used")
> converted ftrace_make_nop() to use patch_insn_write() which does not
> emit any icache flush relying entirely on __ftrace_modify_code() to do
> that.
>
> But we
[trimming CC list]
On Thu, 23 May 2024 at 04:49, John Groves wrote:
> - memmap=! will reserve a pretend pmem device at
>
> - memmap=$ will reserve a pretend dax device at
Doesn't get me a /dev/dax or /dev/pmem
Complete qemu command line:
qemu-kvm -s -serial none -parallel none -kernel
Alexandre Ghiti writes:
> Commit c97bf629963e ("riscv: Fix text patching when IPI are used")
> converted ftrace_make_nop() to use patch_insn_write() which does not
> emit any icache flush relying entirely on __ftrace_modify_code() to do
> that.
>
> But we missed that ftrace_make_nop() was called
Adding man page for new uretprobe syscall.
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 a/man/man2/uretprobe.2
Adding uretprobe shadow stack test that runs all existing
uretprobe tests with shadow stack enabled if it's available.
Signed-off-by: Jiri Olsa
---
.../selftests/bpf/prog_tests/uprobe_syscall.c | 60 +++
1 file changed, 60 insertions(+)
diff --git
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.
Signed-off-by: Jiri Olsa
---
.../testing/selftests/x86/test_shadow_stack.c | 145 ++
1 file changed, 145 insertions(+)
diff --git
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.
Commit c97bf629963e ("riscv: Fix text patching when IPI are used")
converted ftrace_make_nop() to use patch_insn_write() which does not
emit any icache flush relying entirely on __ftrace_modify_code() to do
that.
But we missed that ftrace_make_nop() was called very early directly when
converting
Hi,
thanks for this RFC!
On Fri, May 17, 2024 at 10:46:02PM GMT, Xuewei Niu wrote:
# Motivition
Vsock is a lightweight and widely used data exchange mechanism between host
and guest. Kata Containers, a secure container runtime, leverages the
capability to exchange control data between the shim
On Fri, May 17, 2024 at 10:46:07PM GMT, Xuewei Niu wrote:
The new request is called `IOCTL_VM_SOCKETS_GET_LOCAL_CIDS`. And the old
one, `IOCTL_VM_SOCKETS_GET_LOCAL_CID` is retained.
For the transport that supports multi-devices:
* `IOCTL_VM_SOCKETS_GET_LOCAL_CID` returns "-1";
What about
On Fri, May 17, 2024 at 10:46:06PM GMT, Xuewei Niu wrote:
Adds a new argument, named "src_cid", to let them know which `virtio_vsock`
to be selected.
Signed-off-by: Xuewei Niu
---
include/net/af_vsock.h | 2 +-
net/vmw_vsock/af_vsock.c | 15 +--
On Fri, May 17, 2024 at 10:46:05PM GMT, Xuewei Niu wrote:
Adds a new argument, named "cid", to let them know which `virtio_vsock` to
be selected.
Signed-off-by: Xuewei Niu
---
include/linux/virtio_vsock.h| 2 +-
net/vmw_vsock/virtio_transport.c| 5 ++---
On Fri, May 17, 2024 at 10:46:04PM GMT, Xuewei Niu wrote:
The maximum number of devices is limited by `MAX_VSOCK_NUM`.
Extends `vsock_transport` struct with 4 methods to support multi-devices:
* `get_virtio_vsock()`: It receives a CID, and returns a struct of virtio
vsock. This method is
As Alyssa suggested, we should discuss spec changes in the virtio ML.
BTW as long as this is an RFC, it's fine. Just be sure, though, to
remember to merge the change in the specification first versus the
patches in Linux.
So I recommend that you don't send a non-RFC set into Linux until you
On 16.05.24 15:02, Chen Yu wrote:
Performance drop is reported when running encode/decode workload and
BenchSEE cache sub-workload.
Bisect points to commit ce0a1b608bfc ("x86/paravirt: Silence unused
native_pv_lock_init() function warning"). When CONFIG_PARAVIRT_SPINLOCKS
is disabled the
Previously, the mapped ring-buffer layout caused misalignment between
the meta-page and sub-buffers when the sub-buffer size was not a
multiple of PAGE_SIZE. This prevented hardware with larger TLB entries
from utilizing them effectively.
Add a padding with the zero-page between the meta-page and
(CCing virtio-comment, since this proposes adding a field to a struct
that is standardized[1] in the VIRTIO spec, so changes to the Linux
implementation should presumably be coordinated with changes to the
spec.)
[1]:
On 23/05/2024 08:16, Luca Weiss wrote:
> On Donnerstag, 23. Mai 2024 08:02:13 MESZ Krzysztof Kozlowski wrote:
>> On 22/05/2024 19:34, Luca Weiss wrote:
>>> On Mittwoch, 22. Mai 2024 08:49:43 MESZ Krzysztof Kozlowski wrote:
On 21/05/2024 22:35, Luca Weiss wrote:
> On Dienstag, 21. Mai 2024
On Donnerstag, 23. Mai 2024 08:02:13 MESZ Krzysztof Kozlowski wrote:
> On 22/05/2024 19:34, Luca Weiss wrote:
> > On Mittwoch, 22. Mai 2024 08:49:43 MESZ Krzysztof Kozlowski wrote:
> >> On 21/05/2024 22:35, Luca Weiss wrote:
> >>> On Dienstag, 21. Mai 2024 10:58:07 MESZ Krzysztof Kozlowski wrote:
On 22/05/2024 19:34, Luca Weiss wrote:
> On Mittwoch, 22. Mai 2024 08:49:43 MESZ Krzysztof Kozlowski wrote:
>> On 21/05/2024 22:35, Luca Weiss wrote:
>>> On Dienstag, 21. Mai 2024 10:58:07 MESZ Krzysztof Kozlowski wrote:
On 20/05/2024 17:11, Luca Weiss wrote:
> Hi Krzysztof
>
>
Things to note here:
- dropped a couple of patches at the last moment. Did a bunch
of testing in the last day to make sure that's not causing
any fallout, it's a revert and no other changes in the same area
so I feel rather safe doing that.
- the new Marvell OCTEON DPU driver is not here:
45 matches
Mail list logo
