From: "Steven Rostedt (Google)"
The change to update the permissions of the eventfs_inode had the
misconception that using the tracefs_inode would find all the
eventfs_inodes that have been updated and reset them on remount.
The problem with this approach is that the eventfs_inodes are freed
From: "Steven Rostedt (Google)"
When the inode is being dropped from the dentry, the TRACEFS_EVENT_INODE
flag needs to be cleared to prevent a remount from calling
eventfs_remount() on the tracefs_inode private data. There's a race
between the inode is dropped (and the dentry freed) to where the
From: "Steven Rostedt (Google)"
When a remount happens, if a gid or uid is specified update the inodes to
have the same gid and uid. This will allow the simplification of the
permissions logic for the dynamically created files and directories.
Cc: sta...@vger.kernel.org
Fixes: baa23a8d4360d
From: "Steven Rostedt (Google)"
The directories require unique inode numbers but all the eventfs files
have the same inode number. Prevent the directories from having the same
inode numbers as the files as that can confuse some tooling.
Cc: sta...@vger.kernel.org
Fixes: 834bf76add3e6 ("eventfs:
The test_ownership test of the kselftests was failing again.
That's because the original fix was incorrect and a fix to
a race condition showed how the original fix was broken.
Instead of using tracefs_inodes to find the eventfs_inode that
needs to be reset on remount, use the "events"
Hello:
This patch was applied to riscv/linux.git (for-next)
by Palmer Dabbelt :
On Fri, 5 Apr 2024 14:24:53 + you wrote:
> This commit replaces riscv's support for FTRACE_WITH_REGS with support
> for FTRACE_WITH_ARGS. This is required for the ongoing effort to stop
> relying on
On Tue, May 21, 2024 at 03:08:31PM +0200, Dmitry Baryshkov wrote:
> 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
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 interrupt next triggers on the original CPU, the new affinity
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
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 synthetic event). But the
entry_attrs was freed incorrectly and since been
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 platform driver probe. Implement required
>> remoteproc framework ops to
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
---
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
: 3c999d1ae3c75991902a1a7dad0cb62c2a3008b4
patch link:
https://lore.kernel.org/r/20240521024556.419436-2-maobibo%40loongson.cn
patch subject: [PATCH v3 1/2] LoongArch: KVM: Add steal time support in kvm side
config: loongarch-randconfig-r051-20240522
(https://download.01.org/0day-ci/archive/20240522/202405221317.lctbjh1f
41 matches
Mail list logo
