On 5/21/24 5:00 AM, Thomas Gleixner wrote:
> 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
>>>
On Wed, 22 May 2024 at 22:22, Jeff Johnson wrote:
>
> On 5/21/2024 2:45 AM, Dmitry Baryshkov wrote:
> > Make the driver use qcom_fw_helper to autodetect the path to the
> > calibration data file.
> >
> > Signed-off-by: Dmitry Baryshkov
> > ---
> > drivers/remoteproc/qcom_wcnss.c | 6 ++
> >
On 5/21/2024 2:45 AM, Dmitry Baryshkov wrote:
> Make the driver use qcom_fw_helper to autodetect the path to the
> calibration data file.
>
> Signed-off-by: Dmitry Baryshkov
> ---
> drivers/remoteproc/qcom_wcnss.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git
On Wed, 22 May 2024 12:45:04 -0400
Steven Rostedt wrote:
> From: "Steven Rostedt (Google)"
>
> The iput callback was added because the remount could call into the
> eventfs code and touch the ei->entry_attrs array, which could have been
> freed when an eventfs directory is freed (via a
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
> >>>
> >>> Ack, sounds good.
> >>>
> >>> Maybe also
>> +r5_core->rsc_tbl_size = rsc_data_va->rsc_tbl_size;
>> +r5_core->rsc_tbl_va = rsc_addr;
>> +
>> +return 0;
>> +}
>> +
>> +static int zynqmp_r5_attach(struct rproc *rproc)
>> +{
>> +struct zynqmp_r5_core *r5_core = rproc->priv;
&
On 22/05/2024 14:08, Bartosz Golaszewski wrote:
> From: Tengfei Fan
>
> Add GPDSP0 and GPDSP1 clients for SA8775p platform.
>
> Signed-off-by: Tengfei Fan
> Signed-off-by: Bartosz Golaszewski
> ---
Acked-by: Krzysztof Kozlowski
Best regards,
Krzysztof
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
---
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.
> - t
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
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:
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!
--
+ for (i = 0; i < r5_core->tcm_bank_count; i++) {
> + pm_domain_id = r5_core->tcm_banks[i]->pm_domain_id;
> + ret = zynqmp_pm_request_node(pm_domain_id,
> + ZYNQMP_PM_CAPABILITY_ACCESS, 0,
> +
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
>
+++ b/drivers/rpmsg/rpmsg_char.c
> @@ -52,8 +52,8 @@ static DEFINE_IDA(rpmsg_minor_ida);
> * @readq: wait object for incoming queue
> * @default_ept: set to channel default endpoint if the default endpoint
> should be re-used
> * on device open to prevent endpoint
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:
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,
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
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
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
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
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). Rather than listing all the firmware
On Tue, 21 May 2024 at 12:49, 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 .mdt files by default.
>
> I think we
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). Rather than listing all the firmware files,
including full paths, in the DT, provide a way
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 .mdt files by default.
I think we should have a mechanism to fallback to .mdt since
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 used in both the Linux and OP-TEE
> device-tree:
> - In
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 the known
> usages the first element (and sometimes the 3rd - ipc-2) are empty <>.
>
On Tue 2024-05-21 08:34:46, Miroslav Benes wrote:
> Hello,
>
> On Mon, 20 May 2024, zhang warden wrote:
>
> >
> >
> > > On May 20, 2024, at 14:46, Miroslav Benes wrote:
> > >
> > > Hi,
> > >
> > > On Mon, 20 May 2024, Wardenjohn wrote:
> > >
> > >> Livepatch module usually used to modify
Hello,
On Mon, 20 May 2024, zhang warden wrote:
>
>
> > On May 20, 2024, at 14:46, Miroslav Benes wrote:
> >
> > Hi,
> >
> > On Mon, 20 May 2024, Wardenjohn wrote:
> >
> >> Livepatch module usually used to modify kernel functions.
> >> If the patched function have bug, it may cause serious
Hi Yuanchu,
kernel test robot noticed the following build errors:
[auto build test ERROR on linus/master]
[also build test ERROR on v6.9 next-20240520]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
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
> because vdpasim_kick_vq may be
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 | 24
>
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
> ---
> drivers/vhost/vdpa.c | 3 +++
> 1 file
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 did in the first version, before you adjusted it to the sysret path).
>
>
On Mon, May 20, 2024 at 8:20 AM Jiri Olsa wrote:
>
> On Wed, May 15, 2024 at 08:32:30AM -0600, Andrii Nakryiko wrote:
> > On Wed, May 15, 2024 at 3:30 AM Peter Zijlstra wrote:
> > >
> > > On Wed, May 08, 2024 at 02:26:03PM -0700, Andrii Nakryiko wrote:
> > >
> > > > +static void
On Fri, May 17, 2024 at 1:31 PM Kris Van Hees wrote:
>
> The offset range data for builtin modules is generated using:
> - modules.builtin.modinfo: associates object files with module names
> - vmlinux.map: provides load order of sections and offset of first member
> per section
> -
On Wed, May 08, 2024 at 02:26:04PM -0700, Andrii Nakryiko wrote:
> 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,
On Wed, May 15, 2024 at 08:32:30AM -0600, Andrii Nakryiko wrote:
> On Wed, May 15, 2024 at 3:30 AM Peter Zijlstra wrote:
> >
> > On Wed, May 08, 2024 at 02:26:03PM -0700, Andrii Nakryiko wrote:
> >
> > > +static void fixup_uretprobe_trampoline_entries(struct
> > > perf_callchain_entry *entry,
>
On Sat, 18 May 2024 at 04:44, Christophe JAILLET
wrote:
>
> Le 30/04/2024 à 12:53, Beleswar Padhi a écrit :
> > PSC controller has a limitation that it can only power-up the second
> > core when the first core is in ON state. Power-state for core0 should be
> > equal to or higher than core1.
> >
On Montag, 20. Mai 2024 08:46:39 MESZ Krzysztof Kozlowski wrote:
> On 15/05/2024 17:06, Luca Weiss wrote:
> > Hi Rob,
> >
> > Any feedback on the below topic?
>
> Can be explained in description, like
> mboxes:
> description: Each entry corresponds to one remote processor
> maxItems: 5
Hi
On 5/17/2024 10:26 PM, 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 'rpmsg_eptdev'
On 5/20/2024 4:57 PM, 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: AngeloGioacchino Del Regno
---
On Mon, May 20, 2024 at 10:31:53AM -0400, Steven Rostedt wrote:
> On Mon, 20 May 2024 15:02:26 +0800
> "Ubisectech Sirius" wrote:
>
> > Hello.
> > We are Ubisectech Sirius Team, the vulnerability lab of China ValiantSec.
> > Recently, our team has discovered a issue in Linux kernel 6.7.
On Mon, 20 May 2024 15:02:26 +0800
"Ubisectech Sirius" wrote:
> Hello.
> We are Ubisectech Sirius Team, the vulnerability lab of China ValiantSec.
> Recently, our team has discovered a issue in Linux kernel 6.7. Attached to
> the email were a PoC file of the issue.
>
> Stack dump:
> UBSAN:
05,13 @@ int ring_buffer_resize(struct trace_buffer *buffer,
> unsigned long size,
>*/
> synchronize_rcu();
> for_each_buffer_cpu(buffer, cpu) {
> + unsigned long flags;
> +
> cpu_buffer = buffer->buffers[cpu];
> +
On Fri, May 17, 2024 at 1:30 PM Kris Van Hees wrote:
>
> The CONFIG_BUILTIN_MODULE_RANGES option controls whether offset range data
> is generated for kernel modules that are built into the kernel image.
>
> Signed-off-by: Kris Van Hees
> Reviewed-by: Nick Alcock
> Reviewed-by: Alan Maguire
>
OK, I will try to optimize my description after the patch is reviewed. I am
sure there are something still need to be fix for that patch.
> On May 20, 2024, at 16:00, Markus Elfring wrote:
>
> Please add a version identifier to the message subject.
>
>
> …
>> If the patched function have
On Fri, May 17, 2024 at 1:30 PM Kris Van Hees wrote:
>
> The CONFIG_BUILTIN_MODULE_RANGES option controls whether offset range data
> is generated for kernel modules that are built into the kernel image.
>
> Signed-off-by: Kris Van Hees
> Reviewed-by: Nick Alcock
> Reviewed-by: Alan Maguire
>
On Fri, May 17, 2024 at 1:32 PM Kris Van Hees wrote:
>
> When CONFIG_BUILTIN_MODULE_RANGES is enabled, the modules.builtin.ranges
> file should be installed in the module install location.
>
> Signed-off-by: Kris Van Hees
> Reviewed-by: Nick Alcock
> ---
> Changes since v2:
> - Include
Please add a version identifier to the message subject.
…
> If the patched function have bug, it may cause serious result
> such as kernel crash.
Wording suggestion:
If the patched function has a bug, it might cause serious side effects
like a kernel crash.
> This is a kobject
> On May 20, 2024, at 14:46, Miroslav Benes wrote:
>
> Hi,
>
> On Mon, 20 May 2024, 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 is a kobject attribute
On 15/05/2024 17:06, Luca Weiss wrote:
> Hi Rob,
>
> Any feedback on the below topic?
Can be explained in description, like
mboxes:
description: Each entry corresponds to one remote processor
maxItems: 5
Best regards,
Krzysztof
Hi,
On Mon, 20 May 2024, 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 is a kobject attribute of klp_func. Sysfs interface named
> "called" is introduced to
On 2024-05-18 at 00:12:46 +, Dr. David Alan Gilbert wrote:
> * li...@treblig.org (li...@treblig.org) wrote:
> > From: "Dr. David Alan Gilbert"
> >
> > It doesn't look like this was ever used.
> >
> > Build tested only.
> >
> > Signed-off-by: Dr. David Alan Gilbert
>
> Ping
Acked-by: Fei
OK, I will optimize my patch’s changelog in my next patch.
> On May 20, 2024, at 02:05, Markus Elfring wrote:
>
> I suggest to take preferred line lengths better into account
> also for such a change description.
On Wed, May 15, 2024 at 05:42:03PM +0200, Oleg Nesterov wrote:
> On 05/15, Edgecombe, Rick P wrote:
> >
> > On Wed, 2024-05-15 at 13:35 +0200, Oleg Nesterov wrote:
> > >
> > > > I'm ok with not using optimized uretprobe when shadow stack is detected
> > > > as enabled and we go with current
501 - 600 of 2410692 matches
Mail list logo
