On Wed, May 22, 2024 at 3:06 PM wrote:
>
> On 22/05/2024 15:04, Bartosz Golaszewski wrote:
> > On Wed, May 22, 2024 at 2:42 PM wrote:
> >>
> >> On 22/05/2024 14:08, Bartosz Golaszewski wrote:
> >>> From: Tengfei Fan
> >>>
> >>> Document the compatibles for the components used to boot the ADSP,
On 22/05/2024 15:04, Bartosz Golaszewski wrote:
On Wed, May 22, 2024 at 2:42 PM wrote:
On 22/05/2024 14:08, Bartosz Golaszewski wrote:
From: Tengfei Fan
Document the compatibles for the components used to boot the ADSP, CDSP0,
CDSP1, GPDSP0 and GPDSP1 on the SA8775p SoC.
Signed-off-by:
On Wed, May 22, 2024 at 2:42 PM wrote:
>
> On 22/05/2024 14:08, Bartosz Golaszewski wrote:
> > From: Tengfei Fan
> >
> > Document the compatibles for the components used to boot the ADSP, CDSP0,
> > CDSP1, GPDSP0 and GPDSP1 on the SA8775p SoC.
> >
> > Signed-off-by: Tengfei Fan
> >
On 22/05/2024 14:08, Bartosz Golaszewski wrote:
From: Tengfei Fan
Document the compatibles for the components used to boot the ADSP, CDSP0,
CDSP1, GPDSP0 and GPDSP1 on the SA8775p SoC.
Signed-off-by: Tengfei Fan
Co-developed-by: Bartosz Golaszewski
Signed-off-by: Bartosz Golaszewski
---
Hello RT-list!
I'm pleased to announce the 4.19.312-rt134 stable release.
This updates the rt-stable branch to the upstream stable v4.19.312
release. This took a bit longer because there were some more complex
merge conflict . Stable backported one of the preempt-rt preparation
patches which
From: Tengfei Fan
Add nodes for remoteprocs: ADSP, CDSP0, CDSP1, GPDSP0 and GPDSP1 for
SA8775p SoCs.
Signed-off-by: Tengfei Fan
Co-developed-by: Bartosz Golaszewski
Signed-off-by: Bartosz Golaszewski
---
arch/arm64/boot/dts/qcom/sa8775p.dtsi | 332 ++
1 file
From: Bartosz Golaszewski
Enable all remoteproc nodes on the sa8775p-ride board and point to the
appropriate firmware files.
Signed-off-by: Bartosz Golaszewski
---
arch/arm64/boot/dts/qcom/sa8775p-ride.dts | 25 +
1 file changed, 25 insertions(+)
diff --git
From: Tengfei Fan
Add support for PIL loading on ADSP, CDSP0, CDSP1, GPDSP0 and GPDSP1 on
SA8775p SoCs.
Signed-off-by: Tengfei Fan
Co-developed-by: Bartosz Golaszewski
Signed-off-by: Bartosz Golaszewski
---
drivers/remoteproc/qcom_q6v5_pas.c | 92 ++
1
From: Tengfei Fan
Add GPDSP0 and GPDSP1 clients for SA8775p platform.
Signed-off-by: Tengfei Fan
Signed-off-by: Bartosz Golaszewski
---
include/dt-bindings/mailbox/qcom-ipcc.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/dt-bindings/mailbox/qcom-ipcc.h
From: Tengfei Fan
Document the compatibles for the components used to boot the ADSP, CDSP0,
CDSP1, GPDSP0 and GPDSP1 on the SA8775p SoC.
Signed-off-by: Tengfei Fan
Co-developed-by: Bartosz Golaszewski
Signed-off-by: Bartosz Golaszewski
---
.../bindings/remoteproc/qcom,sm8550-pas.yaml
Add DT bindings, relevant DT defines, DTS nodes and driver changes
required to enable the remoteprocs on sa8775p.
Signed-off-by: Bartosz Golaszewski
---
Bartosz Golaszewski (1):
arm64: dts: qcom: sa8775p-ride: enable remoteprocs
Tengfei Fan (4):
dt-bindings: remoteproc:
On Wed, May 22, 2024 at 12:59:46PM +0200, Alejandro Colomar wrote:
> Hi Jirka,
>
> On Wed, May 22, 2024 at 09:54:58AM GMT, Jiri Olsa wrote:
> > ok, thanks
> >
> > jirka
> >
> >
> > ---
> > diff --git a/man/man2/uretprobe.2 b/man/man2/uretprobe.2
> > new file mode 100644
> > index
On Thu 2024-05-16 15:30:09, Lukas Hruska wrote:
> The test proves that klp-convert works as intended and it is possible to
> livepatch a function that use an external symbol.
>
> Signed-off-by: Lukas Hruska
> --- a/tools/testing/selftests/livepatch/functions.sh
> +++
On Wed, 22 May 2024 07:38:01 -0400, "Michael S. Tsirkin"
wrote:
> On Wed, May 22, 2024 at 06:22:45PM +0800, Xuan Zhuo wrote:
> > On Wed, 22 May 2024 06:03:01 -0400, "Michael S. Tsirkin"
> > wrote:
> > > Things to note here:
> > >
> > > - the new Marvell OCTEON DPU driver is not here: latest v4
On Wed, May 22, 2024 at 06:03:08AM -0400, Michael S. Tsirkin wrote:
> Things to note here:
Sorry Linus, author of one of the patchsets I merged wants to drop it now.
I could revert but it seems cleaner to do that, re-test and re-post.
Will drop a duplicate as long as I do it.
> - the new
On Wed, May 22, 2024 at 06:22:45PM +0800, Xuan Zhuo wrote:
> On Wed, 22 May 2024 06:03:01 -0400, "Michael S. Tsirkin"
> wrote:
> > Things to note here:
> >
> > - the new Marvell OCTEON DPU driver is not here: latest v4 keeps causing
> > build failures on mips. I deferred the pull hoping to get
On Thu 2024-05-16 15:30:07, Lukas Hruska wrote:
> From: Josh Poimboeuf
>
> Add a new livepatch sample in samples/livepatch/ to make use of symbols
> that must be post-processed to enable load-time relocation resolution.
> As the new sample is to be used as an example, it is annotated with
>
Hi Jirka,
On Wed, May 22, 2024 at 09:54:58AM GMT, Jiri Olsa wrote:
> ok, thanks
>
> jirka
>
>
> ---
> diff --git a/man/man2/uretprobe.2 b/man/man2/uretprobe.2
> new file mode 100644
> index ..5b5f340b59b6
> --- /dev/null
> +++ b/man/man2/uretprobe.2
> @@ -0,0 +1,56 @@
> +.\"
On Wed, 22 May 2024 06:03:01 -0400, "Michael S. Tsirkin"
wrote:
> Things to note here:
>
> - the new Marvell OCTEON DPU driver is not here: latest v4 keeps causing
> build failures on mips. I deferred the pull hoping to get it in
> and I might merge a new version post rc1
> (supposed to be
On Thu 2024-05-16 15:30:05, Lukas Hruska wrote:
> Livepatches need to access external symbols which can't be handled
> by the normal relocation mechanism. It is needed for two types
> of symbols:
>
> + Symbols which can be local for the original livepatched function.
> The alternative
Things to note here:
- the new Marvell OCTEON DPU driver is not here: latest v4 keeps causing
build failures on mips. I deferred the pull hoping to get it in
and I might merge a new version post rc1
(supposed to be ok for new drivers as they can't cause regressions),
but we'll see.
-
On Tue, May 21, 2024 at 01:57:33PM -0700, Alexei Starovoitov wrote:
> On Tue, May 21, 2024 at 1:49 PM Deepak Gupta wrote:
> >
> > On Tue, May 21, 2024 at 12:48:16PM +0200, Jiri Olsa wrote:
> > >hi,
> > >as part of the effort on speeding up the uprobes [0] coming with
> > >return uprobe
On Tue, May 21, 2024 at 10:54:36PM +0200, Alejandro Colomar wrote:
> Hi Jirka,
>
> On Tue, May 21, 2024 at 10:24:30PM GMT, Jiri Olsa wrote:
> > how about the change below?
>
> Much better. I still have a few comments below. :-)
>
> >
> > thanks,
> > jirka
> >
> >
> > ---
> > diff --git
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
>>>
>>> Ack, sounds good.
>>>
>>> Maybe also from you, any opinion between these two binding styles?
>>>
>>> So first using index
Hi Bibo,
kernel test robot noticed the following build errors:
[auto build test ERROR on 3c999d1ae3c75991902a1a7dad0cb62c2a3008b4]
url:
https://github.com/intel-lab-lkp/linux/commits/Bibo-Mao/LoongArch-KVM-Add-steal-time-support-in-kvm-side/20240521-104902
base:
On Tue, May 21, 2024 at 9:39 PM Steven Sistare
wrote:
>
> On 5/20/2024 10:28 PM, Jason Wang wrote:
> > On Mon, May 20, 2024 at 11:21 PM Steve Sistare
> > wrote:
> >>
> >> Flush to guarantee no workers are running when suspend returns.
> >>
> >> Fixes: f345a0143b4d ("vhost-vdpa: uAPI to suspend
On Tue, May 21, 2024 at 9:39 PM Steven Sistare
wrote:
>
> On 5/20/2024 10:30 PM, Jason Wang wrote:
> > On Mon, May 20, 2024 at 11:21 PM Steve Sistare
> > wrote:
> >>
> >> Support the suspend operation. There is little to do, except flush to
> >> guarantee no workers are running when suspend
On Tue, May 21, 2024 at 9:39 PM Steven Sistare
wrote:
>
> On 5/20/2024 10:32 PM, Jason Wang wrote:
> > On Mon, May 20, 2024 at 11:21 PM Steve Sistare
> > wrote:
> >>
> >> Flush to guarantee no workers are running when suspend returns.
> >> Add a lock to enforce ordering between clearing running,
Hi Bibo,
kernel test robot noticed the following build warnings:
[auto build test WARNING on 3c999d1ae3c75991902a1a7dad0cb62c2a3008b4]
url:
https://github.com/intel-lab-lkp/linux/commits/Bibo-Mao/LoongArch-KVM-Add-steal-time-support-in-kvm-side/20240521-104902
base:
Add a set of tests to validate that stack traces captured from or in the
presence of active uprobes and uretprobes are valid and complete.
For this we use BPF program that are installed either on entry or exit
of user function, plus deep-nested USDT. One of target funtions
(target_1) is recursive
When tracing user functions with uprobe functionality, it's common to
install the probe (e.g., a BPF program) at the first instruction of the
function. This is often going to be `push %rbp` instruction in function
preamble, which means that within that function frame pointer hasn't
been
When kernel has pending uretprobes installed, it hijacks original user
function return address on the stack with a uretprobe trampoline
address. There could be multiple such pending uretprobes (either on
different user functions or on the same recursive one) at any given
time within the same task.
This helper is needed in another file, so make it a bit more uniquely
named and expose it internally.
Signed-off-by: Andrii Nakryiko
---
include/linux/uprobes.h | 1 +
kernel/events/uprobes.c | 6 +++---
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/include/linux/uprobes.h
This patch set reports two issues with captured stack traces.
First issue, fixed in patch #2, deals with fixing up uretprobe trampoline
addresses in captured stack trace. This issue happens when there are pending
return probes, for which kernel hijacks some of the return addresses on user
stacks.
On Tue, May 21, 2024 at 1:49 PM Deepak Gupta wrote:
>
> On Tue, May 21, 2024 at 12:48:16PM +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.
>
> I
Hi Jirka,
On Tue, May 21, 2024 at 10:24:30PM GMT, Jiri Olsa wrote:
> how about the change below?
Much better. I still have a few comments below. :-)
>
> thanks,
> jirka
>
>
> ---
> diff --git a/man/man2/uretprobe.2 b/man/man2/uretprobe.2
> new file mode 100644
> index
On Tue, May 21, 2024 at 12:48:16PM +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.
I understand this provides an optimization on x86. I believe primary
On Dienstag, 21. Mai 2024 10:58:07 MESZ Krzysztof Kozlowski wrote:
> On 20/05/2024 17:11, Luca Weiss wrote:
> > Hi Krzysztof
> >
> > Ack, sounds good.
> >
> > Maybe also from you, any opinion between these two binding styles?
> >
> > So first using index of mboxes for the numbering, where for
On Tue, May 21, 2024 at 01:48:59PM +0200, Jiri Olsa wrote:
> On Tue, May 21, 2024 at 01:36:25PM +0200, Alejandro Colomar wrote:
> > Hi Jiri,
> >
> > On Tue, May 21, 2024 at 12:48:25PM GMT, Jiri Olsa wrote:
> > > Adding man page for new uretprobe syscall.
> > >
> > > Signed-off-by: Jiri Olsa
> >
On Tue, May 21, 2024 at 11:49:42AM +0200, neil.armstr...@linaro.org wrote:
> On 21/05/2024 11:45, Dmitry Baryshkov wrote:
> > We have been pushing userspace to use mbn files by default for ages.
> > As a preparation for making the firmware-name optional, make the driver
> > use .mbn instead of
The pull request you sent on Mon, 20 May 2024 20:12:20 -0700:
> https://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux.git
> tags/rproc-v6.10
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/ab7b884a34ffda718cb93c772f575e45e8241c62
Thank you!
--
The pull request you sent on Mon, 20 May 2024 19:58:46 -0700:
> https://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux.git
> tags/rpmsg-v6.10
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/e66128fa8e7e38ebd0b0c95578f8020aec6c0dee
Thank you!
--
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 platform driver probe. Implement required
> remoteproc framework ops to provide resource table address and
> connect or disconnect
On Tue, May 21, 2024 at 04:22:21PM +0200, Oleg Nesterov wrote:
> On 05/21, Jiri Olsa wrote:
> >
> > 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
>
On Fri, May 17, 2024 at 06:56:54PM +0200, Arnaud Pouliquen wrote:
> Add missing @ tags for some rpmsg_eptdev structure parameters.
>
> This fixes warning messages on build:
> drivers/rpmsg/rpmsg_char.c:75: warning: Function parameter or struct member
> 'remote_flow_restricted' not described in
On Mon, May 20, 2024 at 01:27:24PM +0200, AngeloGioacchino Del Regno wrote:
> In scp_ipi_handler(), instead of zeroing out the entire shared
> buffer, which may be as large as 600 bytes, overwrite it with the
> received data, then zero out only the remaining bytes.
>
> Signed-off-by:
Manage interrupt coming from coprocessor also when state is
ATTACHED.
Fixes: 35bdafda40cc ("remoteproc: stm32_rproc: Add mutex protection for
workqueue")
Signed-off-by: Gwenael Treuveur
Acked-by: Arnaud Pouliquen
---
drivers/remoteproc/stm32_rproc.c | 2 +-
1 file changed, 1 insertion(+), 1
On Tue, 21 May 2024 09:11:08 -0600
Shuah Khan wrote:
> Any thoughts on this patch?
Sorry, this one fell through the cracks. Daniel Bristot has been
maintaining his tools and I thought this was one of his changes.
I'll take a look at it.
-- Steve
Björn Töpel writes:
> From: Björn Töpel
>
> The RISC-V port copies the PGD table from init_mm/swapper_pg_dir to
> all userland page tables, which means that if the PGD level table is
> changed, other page tables has to be updated as well.
>
> Instead of having the PGD changes ripple out to all
On 4/3/24 19:10, Shuah Khan wrote:
Fix the following -Wformat-security compile warnings adding missing
format arguments:
latency-collector.c: In function ‘show_available’:
latency-collector.c:938:17: warning: format not a string literal and
no format arguments [-Wformat-security]
938 |
On Mon, May 20, 2024 at 10:30:17PM -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
On 05/20, Andrii Nakryiko wrote:
>
> Fixes: 1b8f85defbc8 ("uprobes: prepare uprobe args buffer lazily")
> Reported-by: Breno Leitao
> Signed-off-by: Andrii Nakryiko
> ---
> kernel/trace/trace_uprobe.c | 14 +-
> 1 file changed, 9 insertions(+), 5 deletions(-)
Reviewed-by: Oleg
On 05/21, Jiri Olsa wrote:
>
> 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
On Tue, May 21, 2024 at 03:19:37PM +0200, Alexandre Ghiti wrote:
> On Tue, May 21, 2024 at 1:49 PM Björn Töpel wrote:
> > + if (PageReserved(page)) {
> > + __ClearPageReserved(page);
>
> What's the difference between __ClearPageReserved() and
> ClearPageReserved()? Because it
Alexandre Ghiti writes:
> On Tue, May 21, 2024 at 1:49 PM Björn Töpel wrote:
>>
>> From: Björn Töpel
>>
>> For an architecture to support memory hotplugging, a couple of
>> callbacks needs to be implemented:
>>
>> arch_add_memory()
>> This callback is responsible for adding the physical
Alexandre Ghiti writes:
> On Tue, May 21, 2024 at 1:49 PM Björn Töpel wrote:
>>
>> From: Björn Töpel
>>
>> ZONE_DEVICE pages need DEVMAP PTEs support to function
>> (ARCH_HAS_PTE_DEVMAP). Claim another RSW (reserved for software) bit
>> in the PTE for DEVMAP mark, add the corresponding
On Tue, May 21, 2024 at 1:49 PM Björn Töpel wrote:
>
> From: Björn Töpel
>
> ZONE_DEVICE pages need DEVMAP PTEs support to function
> (ARCH_HAS_PTE_DEVMAP). Claim another RSW (reserved for software) bit
> in the PTE for DEVMAP mark, add the corresponding helpers, and enable
> ARCH_HAS_PTE_DEVMAP
On 5/20/2024 10:32 PM, Jason Wang wrote:
On Mon, May 20, 2024 at 11:21 PM Steve Sistare
wrote:
Flush to guarantee no workers are running when suspend returns.
Add a lock to enforce ordering between clearing running, flushing,
and posting new work in vdpasim_kick_vq. It must be a spin lock
On 5/20/2024 10:30 PM, Jason Wang wrote:
On Mon, May 20, 2024 at 11:21 PM Steve Sistare
wrote:
Support the suspend operation. There is little to do, except flush to
guarantee no workers are running when suspend returns.
Signed-off-by: Steve Sistare
---
drivers/vdpa/vdpa_user/vduse_dev.c
On 5/20/2024 10:28 PM, Jason Wang wrote:
On Mon, May 20, 2024 at 11:21 PM Steve Sistare
wrote:
Flush to guarantee no workers are running when suspend returns.
Fixes: f345a0143b4d ("vhost-vdpa: uAPI to suspend the device")
Signed-off-by: Steve Sistare
Acked-by: Eugenio Pérez
---
On Tue, May 21, 2024 at 1:49 PM Björn Töpel wrote:
>
> From: Björn Töpel
>
> Enable ARCH_ENABLE_MEMORY_HOTPLUG and ARCH_ENABLE_MEMORY_HOTREMOVE for
> RISC-V.
>
> Signed-off-by: Björn Töpel
> ---
> arch/riscv/Kconfig | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/riscv/Kconfig
On Tue, May 21, 2024 at 1:49 PM Björn Töpel wrote:
>
> From: Björn Töpel
>
> For an architecture to support memory hotplugging, a couple of
> callbacks needs to be implemented:
>
> arch_add_memory()
> This callback is responsible for adding the physical memory into the
> direct map, and
On Tue, 21 May 2024 at 13:20, Kalle Valo wrote:
>
> Dmitry Baryshkov writes:
>
> > On Tue, 21 May 2024 at 12:52, wrote:
> >>
> >> On 21/05/2024 11:45, Dmitry Baryshkov wrote:
> >> > Qualcomm platforms have different sets of the firmware files, which
> >> > differ from platform to platform (and
On Tue, May 21, 2024 at 1:48 PM Björn Töpel wrote:
>
> From: Björn Töpel
>
> Prepare for memory hotplugging support by changing from __init to
> __meminit for the page table functions that are used by the upcoming
> architecture specific callbacks.
>
> Changing the __init attribute to __meminit,
The new TEE remoteproc device is used to manage remote firmware in a
secure, trusted context. The 'st,stm32mp1-m4-tee' compatibility is
introduced to delegate the loading of the firmware to the trusted
execution context. In such cases, the firmware should be signed and
adhere to the image format
Split rproc_start()to prepare the update of the management of
the cache table on start, for the support of the firmware loading
by the TEE interface.
- create rproc_set_rsc_table_on_start() to address the management of
the cache table in a specific function, as done in
The "st,stm32mp1-m4-tee" compatible is utilized in a system configuration
where the Cortex-M4 firmware is loaded by the Trusted execution Environment
(TEE).
For instance, this compatible is used in both the Linux and OP-TEE
device-tree:
- In OP-TEE, a node is defined in the device tree with the
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
Main updates from the previous version [1]:
--
1) use proc->table_ptr as unique reference to point to the resource table
--> update remoteproc_core.c to implement management of the resource table
base on rproc->rproc->tee_interface new field:
-
To prepare for the support of TEE remoteproc, create sub-functions
that can be used in both cases, with and without remoteproc TEE support.
Signed-off-by: Arnaud Pouliquen
---
drivers/remoteproc/stm32_rproc.c | 84 +++-
1 file changed, 51 insertions(+), 33
1) on start:
- Using the TEE loader, the resource table is loaded by an external entity.
In such case the resource table address is not find from the firmware but
provided by the TEE remoteproc framework.
Use the rproc_get_loaded_rsc_table instead of rproc_find_loaded_rsc_table
- test that
Add the "st,proc-id" property allowing to identify the remote processor.
This ID is used to define an unique ID, common between Linux, U-boot and
OP-TEE to identify a coprocessor.
This ID will be used in request to OP-TEE remoteproc Trusted Application
to specify the remote processor.
Hi Björn,
On Tue, May 21, 2024 at 1:48 PM Björn Töpel wrote:
>
> From: Björn Töpel
>
> Make sure that the altmap parameter is properly passed on to
> vmemmap_populate_hugepages().
>
> Signed-off-by: Björn Töpel
> ---
> arch/riscv/mm/init.c | 2 +-
> 1 file changed, 1 insertion(+), 1
On 5/21/24 11:24, Krzysztof Kozlowski wrote:
> On 21/05/2024 10:09, Arnaud Pouliquen wrote:
>> The "st,stm32mp1-m4-tee" compatible is utilized in a system configuration
>> where the Cortex-M4 firmware is loaded by the Trusted execution Environment
>> (TEE).
>> For instance, this compatible is
On Wed, May 15 2024 at 12:51, Dongli Zhang wrote:
> On 5/13/24 3:46 PM, Thomas Gleixner wrote:
>> So yes, moving the invocation of irq_force_complete_move() before the
>> irq_needs_fixup() call makes sense, but it wants this to actually work
>> correctly:
>> @@ -1097,10 +1098,11 @@ void
From: Björn Töpel
ZONE_DEVICE pages need DEVMAP PTEs support to function
(ARCH_HAS_PTE_DEVMAP). Claim another RSW (reserved for software) bit
in the PTE for DEVMAP mark, add the corresponding helpers, and enable
ARCH_HAS_PTE_DEVMAP for riscv64.
Signed-off-by: Björn Töpel
---
From: Björn Töpel
Now that RISC-V has memory hotplugging support, virtio-mem can be used
on the platform.
Acked-by: David Hildenbrand
Signed-off-by: Björn Töpel
---
drivers/virtio/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/virtio/Kconfig
From: Björn Töpel
Enable ARCH_ENABLE_MEMORY_HOTPLUG and ARCH_ENABLE_MEMORY_HOTREMOVE for
RISC-V.
Signed-off-by: Björn Töpel
---
arch/riscv/Kconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index fe5281398543..2724dc2af29f 100644
---
From: Björn Töpel
During memory hot remove, the ptdump functionality can end up touching
stale data. Avoid any potential crashes (or worse), by holding the
memory hotplug read-lock while traversing the page table.
This change is analogous to arm64's commit bf2b59f60ee1 ("arm64/mm:
Hold memory
From: Björn Töpel
For an architecture to support memory hotplugging, a couple of
callbacks needs to be implemented:
arch_add_memory()
This callback is responsible for adding the physical memory into the
direct map, and call into the memory hotplugging generic code via
__add_pages() that
From: Björn Töpel
Add a parameter to the direct map setup function, so it can be used in
arch_add_memory() later.
Reviewed-by: Alexandre Ghiti
Reviewed-by: David Hildenbrand
Reviewed-by: Oscar Salvador
Signed-off-by: Björn Töpel
---
arch/riscv/mm/init.c | 15 ++-
1 file
On Tue, May 21, 2024 at 01:36:25PM +0200, Alejandro Colomar wrote:
> Hi Jiri,
>
> On Tue, May 21, 2024 at 12:48:25PM GMT, Jiri Olsa wrote:
> > Adding man page for new uretprobe syscall.
> >
> > Signed-off-by: Jiri Olsa
> > ---
> > man2/uretprobe.2 | 50
From: Björn Töpel
Prepare for memory hotplugging support by changing from __init to
__meminit for the page table functions that are used by the upcoming
architecture specific callbacks.
Changing the __init attribute to __meminit, avoids that the functions
are removed after init. The __meminit
From: Björn Töpel
The RISC-V port copies the PGD table from init_mm/swapper_pg_dir to
all userland page tables, which means that if the PGD level table is
changed, other page tables has to be updated as well.
Instead of having the PGD changes ripple out to all tables, the
synchronization can be
From: Björn Töpel
Make sure that the altmap parameter is properly passed on to
vmemmap_populate_hugepages().
Signed-off-by: Björn Töpel
---
arch/riscv/mm/init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
index
From: Björn Töpel
Memory Hot(Un)Plug support (and ZONE_DEVICE) for the RISC-V port
Introduction
To quote
Hi Jiri,
On Tue, May 21, 2024 at 12:48:25PM GMT, Jiri Olsa wrote:
> Adding man page for new uretprobe syscall.
>
> Signed-off-by: Jiri Olsa
> ---
> man2/uretprobe.2 | 50
> 1 file changed, 50 insertions(+)
> create mode 100644 man2/uretprobe.2
Dmitry Baryshkov writes:
> On Tue, 21 May 2024 at 12:52, wrote:
>>
>> On 21/05/2024 11:45, Dmitry Baryshkov wrote:
>> > Qualcomm platforms have different sets of the firmware files, which
>> > differ from platform to platform (and from board to board, due to the
>> > embedded signatures).
On 2024-05-15 23:05:36 [+0100], Qais Yousef wrote:
> rt_task() checks if a task has RT priority. But depends on your
> dictionary, this could mean it belongs to RT class, or is a 'realtime'
> task, which includes RT and DL classes.
>
> Since this has caused some confusion already on discussion
Adding man page for new uretprobe syscall.
Signed-off-by: Jiri Olsa
---
man2/uretprobe.2 | 50
1 file changed, 50 insertions(+)
create mode 100644 man2/uretprobe.2
diff --git a/man2/uretprobe.2 b/man2/uretprobe.2
new file mode 100644
index
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.
On Tue, May 21, 2024 at 01:31:53AM +, Edgecombe, Rick P wrote:
> On Mon, 2024-05-20 at 00:18 +0200, Jiri Olsa wrote:
> > anyway I think we can fix that in another way by using the optimized
> > trampoline,
> > but returning to the user space through iret when shadow stack is detected
> > (as I
1 - 100 of 4332381 matches
Mail list logo
