Jiri Slaby (SUSE)
> Cc: Bjorn Andersson
> Cc: Mathieu Poirier
> Cc: linux-remotep...@vger.kernel.org
> ---
> drivers/remoteproc/pru_rproc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/remoteproc/pru_rproc.c b/drivers/remoteproc/pru_rpr
On Fri, Mar 14, 2025 at 05:17:19PM +0200, Daniel Baluta wrote:
> Add documentation for 'run_stall' imx_dsp_rproc struct member.
> This also fixes the following warning:
>
> warning: Function parameter or struct member 'run_stall'
> not described in 'imx_dsp_rproc'
>
> Fixes: 0184b4fdbad1 ("imx_ds
from IMX DSP
> remoteproc driver because there is no Device Tree users.
>
> Changes since v4:
> https://lore.kernel.org/lkml/20250305100037.373782-3-daniel.bal...@nxp.com/T/
> - picked-up R-b tags from Frank Li and Peng Fan
> - reworded commit message of patch 8/8 as p
centrate
on _why_ we are moving from the current design to using the reset controller
API.
This can go in the 6.15 merge window if you send me a V5 fast enough.
Thanks,
Mathieu
>
> [1]
> https://patchwork.kernel.org/project/imx/patch/20250212085222.107102-6-daniel.bal...@nxp.com/
>
>
Thanks for the re-spin. I will wait for Shawn and Sascha to review their
respective bits before picking up this set.
Mathieu
On Tue, Mar 11, 2025 at 10:58:03AM +0200, Daniel Baluta wrote:
> This patch series adds support to control the Run/Stall DSP bits found on
> i.MX8MP via the
do above means the resource table in the FW
image needs to be mofidied. As such, you could take advantage of the vendor
specific resource table entry already supported by the remoteproc framework [3].
>From there you provide a resource handler specific to the iMX DSP driv
ported-by: kernel test robot
> Closes:
> https://lore.kernel.org/oe-kbuild-all/202502161648.wzwrfv7i-...@intel.com/
> Cc: Andrew Davis
> Signed-off-by: Peng Fan
> ---
> drivers/remoteproc/omap_remoteproc.c | 1 +
> 1 file changed, 1 insertion(+)
>
Applied - thanks,
Mathieu
>
rsion
of it renamed to something more meaningful) from
__rseq_handle_notify_resume() ? By combining time_before() checks from
the scheduler tick and at return to userspace after preemption, AFAIU
we'd be handling the periodic workload correctly, and therefore this
test for mm_cid compaction could check for m
ead should see 0 as mm_cid, if that
doesn't happen, the compaction mechanism didn't work and the test fails.
The test never fails if only 1 core is available, in which case, we
cannot test anything as the only available mm_cid is 0.
To: Mathieu Desnoyers
Reviewed-by: Mathieu Desnoye
On 2025-01-15 12:57, Shuah Khan wrote:
On 1/14/25 17:45, Mathieu Desnoyers wrote:
On 2025-01-14 19:14, Shuah Khan wrote:
On 1/14/25 07:51, Mathieu Desnoyers wrote:
When porting librseq commit:
commit c7b45750fa85 ("Adapt to glibc __rseq_size feature detection")
from librseq to
drivers/remoteproc/keystone_remoteproc.c | 17 +++---
> drivers/remoteproc/omap_remoteproc.c | 7 ++---
> drivers/remoteproc/st_remoteproc.c | 54
> +---
> 3 files changed, 28 insertions(+), 50 deletions(-)
I have applied this set.
Thanks,
Mathieu
>
On 2025-01-14 19:14, Shuah Khan wrote:
On 1/14/25 07:51, Mathieu Desnoyers wrote:
When porting librseq commit:
commit c7b45750fa85 ("Adapt to glibc __rseq_size feature detection")
from librseq to the kernel selftests, the following line was missed
at the end of rseq_init():
on")
Fixes: 73a4f5a704a2 ("selftests/rseq: Fix mm_cid test failure")
Signed-off-by: Mathieu Desnoyers
Cc: Raghavendra Rao Ananta
Cc: Shuah Khan
Cc: Peter Zijlstra
Cc: Boqun Feng
Cc: "Paul E. McKenney"
Cc: Carlos O'Donell
Cc: Florian Weimer
Cc: Michael Jeanson
On 2025-01-14 09:07, Mathieu Desnoyers wrote:
On 2025-01-13 18:06, Shuah Khan wrote:
On 12/10/24 15:44, Raghavendra Rao Ananta wrote:
Currently the rseq constructor, rseq_init(), assumes that glibc always
has the support for rseq symbols (__rseq_size for instance). However,
glibc supports rseq
atch. I need to review it carefully
to make sure it does not break anything else moving forward.
Please wait before merging.
Thanks,
Mathieu
thanks,
-- Shuah
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
quot; constraint.
I have compile tested this only for riscv. However, the same fixes I
use in the OpenRISC rseq selftests and everything passes with no issues.
Signed-off-by: Stafford Horne
Reviewed-by: Mathieu Desnoyers
---
tools/testing/selftests/rseq/rseq-riscv-bits.h | 6 +++---
tool
Linux: Linux buildroot 6.13.0-rc2-5-g1fa73dd6c2d3-dirty #213 SMP
Sat Dec 28 22:18:39 GMT 2024 openrisc GNU/Linux
Glibc: 2024-12-13 e4e49583d9 Stafford Horne or1k: Update
libm-test-ulps
Signed-off-by: Stafford Horne
Thanks!
Reviewed-by: Mathieu Desnoyers
---
tools
erved memory
> remoteproc: k3-r5: Use devm_kcalloc() helper
> remoteproc: k3-r5: Use devm_ioremap_wc() helper
> remoteproc: k3-r5: Use devm_rproc_add() helper
> remoteproc: k3-r5: Add devm action to release tsp
>
> drivers/remoteproc/ti_k3_r5_remoteproc.c | 88 ++--
> 1 file changed, 35 insertions(+), 53 deletions(-
I have applied this set.
Thanks,
Mathieu
>
> --
> 2.34.1
>
i_k3_r5_remoteproc.c | 86 ++--
> 1 file changed, 34 insertions(+), 52 deletions(-)
>
Please note that I am looking for an R-B and T-B tag from two
different people (for now one of each will suffice) before looking at
patches.
Thanks,
Mathieu
> --
> 2.34.1
>
Tinghan Shen
> Signed-off-by: Chen-Yu Tsai
> ---
> Changes since v1:
> - Fix commit subject: populate devices *for* SCP cores
> ---
> drivers/remoteproc/mtk_scp.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
I have applied this patch.
Thanks,
Mathie
pthread_setaffinity_np(tinfo[j], sizeof(test_affinity),
+ &test_affinity);
It would be better that each thread set their own affinity when
they start rather than having the main thread set each created thread
affinity while the
best effort.
If best effort, then this corner-case is not worthy of a "Fix" tag.
Otherwise, we should identify which commit it fixes and introduce a
"Fix" tag.
Thanks,
Mathieu
Signed-off-by: Gabriele Monaco
---
include/linux/mm_types.h | 11 +
include/linux/s
On 2024-12-13 04:54, Gabriele Monaco wrote:
From: Mathieu Desnoyers
When a process reduces its number of threads or clears bits in its CPU
affinity mask, the mm_cid allocation should eventually converge towards
smaller values.
I target v6.13 for this patch. As it fixes a commit which was
nates but before its
mm is freed.
Can you fold it in patch 1/4 ?
Thanks,
Mathieu
Signed-off-by: Gabriele Monaco
---
include/linux/mm_types.h | 7 ---
kernel/sched/core.c | 19 +++
2 files changed, 3 insertions(+), 23 deletions(-)
diff --git a/include/linux/mm_ty
On Fri, 6 Dec 2024 at 10:05, Mathieu Poirier wrote:
>
> On Thu, 5 Dec 2024 at 11:22, Arnaud POULIQUEN
> wrote:
> >
> > Hello Mathieu,
> >
> > Thanks for the review!
> > I just need to clarify a point below before preparing the next revision.
> >
On Thu, 5 Dec 2024 at 11:22, Arnaud POULIQUEN
wrote:
>
> Hello Mathieu,
>
> Thanks for the review!
> I just need to clarify a point below before preparing the next revision.
>
> On 12/3/24 18:22, Mathieu Poirier wrote:
> > On Thu, Nov 28, 2024 at 09:42:10AM +0
> @@ -1379,6 +1386,7 @@ static void scp_remove(struct platform_device *pdev)
> rproc_del(scp->rproc);
> scp_free(scp);
> }
> + of_platform_depopulate(&pdev->dev);
This looks like a sensible addition to me but I'll give Angelo some time to
chime in.
Regards,
Mathieu
> mutex_destroy(&scp_cluster->cluster_lock);
> }
>
> --
> 2.47.0.338.g60cca15819-goog
>
F segments into memory.
> Rename this to a more explicit name: load_segments().
This is introducing more code churn than is worth it. Please enhance the usage
comment for ->load() as part of the previous patch and drop this one.
I am done reviewing this set.
Thanks,
Mathieu
>
> Su
On Thu, Nov 28, 2024 at 09:42:12AM +0100, Arnaud Pouliquen wrote:
> The two methods to load the firmware to memory should be exclusive.
>
> - make load_segments optional returning 0 if not set in
> rproc_load_segments(),
> - ensure that load_segments() and load_fw() are not both set,
> - do not
On Thu, Nov 28, 2024 at 09:42:10AM +0100, Arnaud Pouliquen wrote:
> This patch updates the rproc_ops structures to include two new optional
> operations.
>
> - The load_fw() op is responsible for loading the remote processor
> non-ELF firmware image before starting the boot sequence. This ops will
panic at least the returned number of milliseconds
> * @coredump: collect firmware dump after the subsystem is shutdown
> + * @load_fw: optional function to load non-ELF firmware image to memory,
> where the remote
Round this down to 80 characters please. Here having a
Good morning,
On Thu, Nov 28, 2024 at 09:42:09AM +0100, Arnaud Pouliquen wrote:
> 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
= &curr->rcu;
Why is it OK to re-use the task struct rcu field ? Where else is it
used, and is there a risk of being inserted twice ?
Thanks,
Mathieu
unsigned long now = jiffies;
if (!curr->mm || (curr->flags & (PF_EXITING | PF_KTHREAD)) ||
- work->
3 +2503,6 @@ struct rproc *rproc_alloc(struct device *dev, const
> char *name,
> if (rproc_alloc_ops(rproc, ops))
> goto put_device;
>
> - /* Assign a unique device index and name */
> - rproc->index = ida_alloc(&rproc_dev_index, GFP_KERNEL);
&g
On Wed, 20 Nov 2024 at 09:39, Arnaud POULIQUEN
wrote:
>
>
>
> On 11/20/24 17:04, Mathieu Poirier wrote:
> > On Tue, 19 Nov 2024 at 13:38, Mathieu Poirier
> > wrote:
> >>
> >> On Tue, 19 Nov 2024 at 11:14, Arnaud POULIQUEN
> >> wrote:
>
On Tue, 19 Nov 2024 at 13:38, Mathieu Poirier
wrote:
>
> On Tue, 19 Nov 2024 at 11:14, Arnaud POULIQUEN
> wrote:
> >
> > Hello Mathieu,
> >
> > On 11/18/24 18:52, Mathieu Poirier wrote:
> > > On Mon, Nov 04, 2024 at 02:35:12PM +0100, Arnaud Poul
On Tue, 19 Nov 2024 at 11:14, Arnaud POULIQUEN
wrote:
>
> Hello Mathieu,
>
> On 11/18/24 18:52, Mathieu Poirier wrote:
> > On Mon, Nov 04, 2024 at 02:35:12PM +0100, Arnaud Pouliquen wrote:
> >> This patch updates the rproc_ops struct to include an optional
> >>
if rproc_start() fails.
4) Take rproc_tee_load_fw() out of rproc_tee_parse_fw(). It will now be called
in rproc_load_fw().
5) As stated above function rproc_release_fw() now calls rproc_tee_release_fw().
The former is already called in rproc_shutdown() so we are good in that front.
With the above the
t; struct firmware *fw)
> unprepare_subdevices:
> rproc_unprepare_subdevices(rproc);
> reset_table_ptr:
> + if (rproc->ops->release_fw)
> + rproc->ops->release_fw(rproc);
I always thought that looked hackish and brittle. I am trying to find a
On Mon, Nov 04, 2024 at 02:35:10PM +0100, Arnaud Pouliquen wrote:
> 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 by the
I have applied all 3 patches in this set.
Thanks,
Mathieu
On Mon, Oct 21, 2024 at 03:45:55PM -0500, Andrew Davis wrote:
> While it should be safe to use normal memset() on these memories as they
> are mapped as Normal Non-Cached, using the memset_io() provides stronger
> guarantees
On Fri, Oct 25, 2024 at 01:40:45PM +0530, Mukesh Ojha wrote:
> On Mon, Oct 21, 2024 at 09:12:47AM -0600, Mathieu Poirier wrote:
> > Hi Mukesh,
> >
> > On Wed, Oct 16, 2024 at 10:25:46AM +0530, Mukesh Ojha wrote:
> > > Multiple call to glink_subdev_stop() for
Good day,
On Wed, Oct 23, 2024 at 12:21:11PM -0400, Laurentiu Mihalcea wrote:
> From: Laurentiu Mihalcea
>
> Add new compatible for imx95's CM7 with SOF.
>
> Signed-off-by: Laurentiu Mihalcea
> ---
> .../bindings/remoteproc/fsl,imx-rproc.yaml| 58 +--
> 1 file changed, 53
very, with exactly this kind of
use case in mind. I think it is the only way to move forward with this
feature, though it is a big job that requires a lot of community interactions.
Regards,
Mathieu
> +
> + ret = idr_alloc(&rproc->notifyids, rvring, start, end, GFP_KERNEL);
>
c_itf);
> +
If I read Bjorn's comment properly, this should probably be:
rproc_tee_unregister(rproc);
with the if() inside the function.
> return ret;
> }
>
> @@ -933,6 +987,9 @@ static void stm32_rproc_remove(struct platform_device
> *pdev)
> dev_pm_clear_wake_irq(dev);
> device_init_wakeup(dev, false);
> }
> + if (rproc->tee_rproc_itf)
> + tee_rproc_unregister(rproc->tee_rproc_itf);
> +
Same here.
I am done reviewing this set.
Thanks,
Mathieu
> }
>
> static int stm32_rproc_suspend(struct device *dev)
> --
> 2.25.1
>
On Wed, Oct 09, 2024 at 10:01:05AM +0200, Arnaud Pouliquen wrote:
> This patch updates the rproc_ops struct to include an optional
> release_fw function.
>
> The release_fw ops is responsible for releasing the remote processor
> firmware image. The ops is called in the following cases:
>
> - An
On Wed, Oct 09, 2024 at 10:01:03AM +0200, Arnaud Pouliquen wrote:
> 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 by the
ot;, ret);
> return ret;
> }
> @@ -1839,7 +1840,7 @@ int rproc_trigger_recovery(struct rproc *rproc)
> return ret;
>
> /* State could have changed before we got the mutex */
> - if (rproc->state != RPROC_CRASHED)
> +
/20241007132441.2732215-1-a...@kernel.org/
>
> Andrew Davis (2):
> remoteproc: k3-dsp: Add compile testing support
> remoteproc: k3-r5: Add compile testing support
>
I have applied this set.
Thanks,
Mathieu
> drivers/remoteproc/Kconfig | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> --
> 2.39.2
>
On Wed, Oct 16, 2024 at 10:37:35AM -0500, Andrew Davis wrote:
> On 10/16/24 10:26 AM, Mathieu Poirier wrote:
> > On Mon, Oct 14, 2024 at 09:56:11AM -0500, Andrew Davis wrote:
> > > On 10/7/24 8:23 AM, Arnd Bergmann wrote:
> > > > From: Arnd Bergmann
> > >
On Mon, Oct 14, 2024 at 09:56:11AM -0500, Andrew Davis wrote:
> On 10/7/24 8:23 AM, Arnd Bergmann wrote:
> > From: Arnd Bergmann
> >
> > The k3-m4 remoteproc driver was merged with incorrect dependencies.
> > Despite multiple people trying to fix this, the version 6.12-rc2
> > remains broken and
On Tue, Oct 15, 2024 at 06:58:33PM +0200, Richard Weinberger wrote:
> Mathieu,
>
> Am Dienstag, 15. Oktober 2024, 18:48:08 CEST schrieb Mathieu Poirier:
> > Good morning Richard,
> >
> > On Fri, Oct 11, 2024 at 02:39:22PM +0200, Richard Weinberger wrote:
> > >
Simplify with dev_err_probe()
> remoteproc: ti_k3_r5: Simplify with dev_err_probe()
> remoteproc: ti_k3_r5: Simplify with scoped for each OF child loop
I have applied patches 1 to 4. I will let Bjorn do the QC ones.
Thanks,
Mathieu
> remoteproc: qcom_q6
ake the kernel aware of their non-standard extension but
> briefly ignore the description field.
In my opinion the real fix here is to get TI to use the standard message
announcement structure. The ->desc field doesn't seem to be that useful since
it gets discarted.
Thanks,
Mathieu
|| (COMPILE_TEST && TI_SCI_PROTOCOL=n)
> + depends on OMAP2PLUS_MBOX
I have tested this patch with CONFIG_TI_SCI_PROTOCOL=m on Arm and allmodconfig
on
x86-64 - both compilation work.
I can apply this patch as is or you can send me another one with the
modifications you did for
d field support")
Signed-off-by: Mathieu Desnoyers
Cc: Peter Zijlstra
CC: Boqun Feng
CC: "Paul E. McKenney"
Cc: Shuah Khan
CC: Carlos O'Donell
CC: Florian Weimer
CC: linux-kselft...@vger.kernel.org
CC: sta...@vger.kernel.org
---
tools/testing/selftests/rseq/rseq.c | 110
On 2024-10-08 15:50, Mathieu Desnoyers wrote:
[...]
+/* Retire the protected hazard pointer from @slot. */
+static inline
+void hazptr_retire(struct hazptr_slot *slot, void *addr)
+{
+ WARN_ON_ONCE(slot->addr != addr);
+ smp_store_release(&slot->addr, NULL);
+}
Actually,
>From hereon and starting with this version, I will not review patchets that
don't pass the compilation bots.
Mathieu
On Tue, Oct 08, 2024 at 07:07:40PM +0800, kernel test robot wrote:
> Hi Arnaud,
>
> kernel test robot noticed the following build warnings:
>
> [aut
On Mon, Oct 07, 2024 at 01:23:57PM +, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The k3-m4 remoteproc driver was merged with incorrect dependencies.
> Despite multiple people trying to fix this, the version 6.12-rc2
> remains broken and causes a build failure with CONFIG_TI_SCI_PROTOCOL=m
kernel.org/lkml/j3scdl5iymjlxavomgc6u5ndg3svhab6ga23dr36o4f5mt333w@7xslvq6b6hmv/
Link: https://lpc.events/event/18/contributions/1731/
Signed-off-by: Mathieu Desnoyers
Cc: Nicholas Piggin
Cc: Michael Ellerman
Cc: Greg Kroah-Hartman
Cc: Sebastian Andrzej Siewior
Cc: "Paul E. McKenney"
: 96
Socket(s):2
Stepping: 1
Frequency boost: enabled
CPU(s) scaling MHz: 100%
CPU max MHz: 3709.
CPU min MHz: 400.
BogoMIPS: 4799.75
Memory: 768 GB ram.
Signed-off-by: Mathieu Desnoyers
Cc: Nicholas
which depend on @a before loading @a.
The same logic applies with @a and @b swapped.
Suggested-by: Linus Torvalds
Suggested-by: Boqun Feng
Signed-off-by: Mathieu Desnoyers
Reviewed-by: Boqun Feng
Reviewed-by: Joel Fernandes (Google)
Tested-by: Joel Fernandes (Google)
Acked-by: "P
96 +21%
192 +28%
384+4%
768-0.6%
This series applies on top of v6.11.1.
Signed-off-by: Mathieu Desnoyers
Cc: Linus Torvalds
Cc: Andrew Morton
Cc: Peter Zijlstra
Cc: Nicholas Piggin
Cc: Michael Ellerman
Cc: Greg Kroah-Hartma
Refer to ptr_eq() in the rcu_dereference() documentation.
ptr_eq() is a mechanism that preserves address dependencies when
comparing pointers, and should be favored when comparing a pointer
obtained from rcu_dereference() against another pointer.
Signed-off-by: Mathieu Desnoyers
Acked-by: Alan
On 2024-10-07 21:06, Paul E. McKenney wrote:
On Mon, Oct 07, 2024 at 11:18:14AM -0700, Paul E. McKenney wrote:
On Mon, Oct 07, 2024 at 10:50:46AM -0400, Mathieu Desnoyers wrote:
On 2024-10-07 12:40, Peter Zijlstra wrote:
On Sat, Oct 05, 2024 at 02:50:17PM -0400, Mathieu Desnoyers wrote:
On
On 2024-10-07 15:47, Boqun Feng wrote:
On Thu, Oct 03, 2024 at 09:30:53AM -0400, Mathieu Desnoyers wrote:
[...]
+ /*
+* Use RCU dereference without lockdep checks, because
+* lockdep is not aware of HP guarantees.
+*/
+ addr2 = rcu_access_pointer(*addr_p
On 2024-10-07 12:40, Peter Zijlstra wrote:
On Sat, Oct 05, 2024 at 02:50:17PM -0400, Mathieu Desnoyers wrote:
On 2024-10-05 18:04, Peter Zijlstra wrote:
+/*
+ * hp_allocate: Allocate a hazard pointer.
+ *
+ * Allocate a hazard pointer slot for @addr. The object existence should
+ * be
On 2024-10-07 12:42, Peter Zijlstra wrote:
On Sat, Oct 05, 2024 at 02:56:26PM -0400, Mathieu Desnoyers wrote:
On 2024-10-05 18:07, Peter Zijlstra wrote:
On Sat, Oct 05, 2024 at 06:04:44PM +0200, Peter Zijlstra wrote:
On Fri, Oct 04, 2024 at 02:27:33PM -0400, Mathieu Desnoyers wrote:
+void
On 2024-10-07 15:18, David Laight wrote:
From: Jonas Oberhauser
Sent: 07 October 2024 12:55
Am 10/3/2024 um 3:23 PM schrieb Mathieu Desnoyers:
What _does_ work however are the following two approaches:
1) Perform the equality check on the original variables, creating
new versions (with
On 2024-10-05 18:07, Peter Zijlstra wrote:
On Sat, Oct 05, 2024 at 06:04:44PM +0200, Peter Zijlstra wrote:
On Fri, Oct 04, 2024 at 02:27:33PM -0400, Mathieu Desnoyers wrote:
+void hp_scan(struct hp_slot __percpu *percpu_slots, void *addr,
+void (*retire_cb)(int cpu, struct
On 2024-10-05 18:04, Peter Zijlstra wrote:
On Fri, Oct 04, 2024 at 02:27:33PM -0400, Mathieu Desnoyers wrote:
include/linux/hp.h | 158 +
kernel/Makefile| 2 +-
kernel/hp.c| 46 +
3 files changed, 205 insertions(+), 1
On 2024-10-04 23:25, Joel Fernandes wrote:
On Fri, Oct 4, 2024 at 2:29 PM Mathieu Desnoyers
wrote:
This API provides existence guarantees of objects through Hazard
Pointers (HP). This minimalist implementation is specific to use
with preemption disabled, but can be extended further as needed
On 2024-10-05 13:19, Frederic Weisbecker wrote:
Le Fri, Oct 04, 2024 at 02:27:33PM -0400, Mathieu Desnoyers a écrit :
+void hp_scan(struct hp_slot __percpu *percpu_slots, void *addr,
+void (*retire_cb)(int cpu, struct hp_slot *slot, void *addr))
+{
+ int cpu
Refer to ptr_eq() in the rcu_dereference() documentation.
ptr_eq() is a mechanism that preserves address dependencies when
comparing pointers, and should be favored when comparing a pointer
obtained from rcu_dereference() against another pointer.
Signed-off-by: Mathieu Desnoyers
Acked-by: Alan
: 96
Socket(s):2
Stepping: 1
Frequency boost: enabled
CPU(s) scaling MHz: 100%
CPU max MHz: 3709.
CPU min MHz: 400.
BogoMIPS: 4799.75
Memory: 768 GB ram.
Signed-off-by: Mathieu Desnoyers
Cc: Nicholas
l.org/lkml/j3scdl5iymjlxavomgc6u5ndg3svhab6ga23dr36o4f5mt333w@7xslvq6b6hmv/
Link: https://lpc.events/event/18/contributions/1731/
Signed-off-by: Mathieu Desnoyers
Cc: Nicholas Piggin
Cc: Michael Ellerman
Cc: Greg Kroah-Hartman
Cc: Sebastian Andrzej Siewior
Cc: "Paul E. McKenney"
Cc: Will Deacon
which depend on @a before loading @a.
The same logic applies with @a and @b swapped.
Suggested-by: Linus Torvalds
Suggested-by: Boqun Feng
Signed-off-by: Mathieu Desnoyers
Reviewed-by: Boqun Feng
Reviewed-by: Joel Fernandes (Google)
Tested-by: Joel Fernandes (Google)
Acked-by: "P
0.6%
This series applies on top of v6.11.1.
Signed-off-by: Mathieu Desnoyers
Cc: Linus Torvalds
Cc: Andrew Morton
Cc: Peter Zijlstra
Cc: Nicholas Piggin
Cc: Michael Ellerman
Cc: Greg Kroah-Hartman
Cc: Sebastian Andrzej Siewior
Cc: "Paul E. McKenney"
Cc: Will Deacon
Cc: Alan Stern
then the compiler can't possibly reverse the asm blocks.
Indeed.
Thanks,
Mathieu
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
Registration No: 1397386 (Wales)
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
On 2024-10-03 02:08, Joel Fernandes wrote:
On Tue, Oct 01, 2024 at 09:02:02PM -0400, Mathieu Desnoyers wrote:
Compiler CSE and SSA GVN optimizations can cause the address dependency
of addresses returned by rcu_dereference to be lost when comparing those
pointers with either constants or
On Tue, 1 Oct 2024 at 07:35, Jason Gunthorpe wrote:
>
> On Mon, Sep 30, 2024 at 10:40:30AM -0600, Mathieu Poirier wrote:
> > On Mon, Aug 12, 2024 at 03:28:11PM +0800, Lu Baolu wrote:
> > > An iommu domain is allocated in rproc_enable_iommu() and is attached to
> > >
On 2024-10-03 02:24, Boqun Feng wrote:
On Tue, Oct 01, 2024 at 09:02:04PM -0400, Mathieu Desnoyers wrote:
[...]
+/*
+ * hp_allocate: Allocate a hazard pointer.
+ *
+ * Allocate a hazard pointer slot for @addr. The object existence should
+ * be guaranteed by the caller.
+ *
+ * Returns a
of the variables which were compared
with another pointer. (as suggested by Boqun)
2) Perform the equality check on the versions resulting of hiding
both variables, making sure those versions of the variables are
not dereferenced afterwards. (as suggested by Linus)
Thanks,
Mathieu
On 2024-10-02 17:58, Jens Axboe wrote:
On 10/2/24 9:53 AM, Mathieu Desnoyers wrote:
On 2024-10-02 17:36, Mathieu Desnoyers wrote:
On 2024-10-02 17:33, Matthew Wilcox wrote:
On Wed, Oct 02, 2024 at 11:26:27AM -0400, Mathieu Desnoyers wrote:
On 2024-10-02 16:09, Paul E. McKenney wrote:
On Tue
On 2024-10-02 17:33, Matthew Wilcox wrote:
On Wed, Oct 02, 2024 at 11:26:27AM -0400, Mathieu Desnoyers wrote:
On 2024-10-02 16:09, Paul E. McKenney wrote:
On Tue, Oct 01, 2024 at 09:02:01PM -0400, Mathieu Desnoyers wrote:
Hazard pointers appear to be a good fit for replacing refcount based
>vq = NULL;
> > +#ifndef CONFIG_VIRTIO_HARDEN_NOTIFICATION
> > + rproc_virtio_synchronize_cbs(vdev);
> > +#endif
> > vring_del_virtqueue(vq);
> > }
> > }
> > @@ -334,6 +345,7 @@ static const struct virtio_config_ops
>
On 2024-10-02 16:09, Paul E. McKenney wrote:
On Tue, Oct 01, 2024 at 09:02:01PM -0400, Mathieu Desnoyers wrote:
Hazard pointers appear to be a good fit for replacing refcount based lazy
active mm tracking.
Highlight:
will-it-scale context_switch1_threads
nr threads (-t) speedup
24
Refer to ptr_eq() in the rcu_dereference() documentation.
ptr_eq() is a mechanism that preserves address dependencies when
comparing pointers, and should be favored when comparing a pointer
obtained from rcu_dereference() against another pointer.
Signed-off-by: Mathieu Desnoyers
Acked-by: Alan
31/
Signed-off-by: Mathieu Desnoyers
Cc: Nicholas Piggin
Cc: Michael Ellerman
Cc: Greg Kroah-Hartman
Cc: Sebastian Andrzej Siewior
Cc: "Paul E. McKenney"
Cc: Will Deacon
Cc: Peter Zijlstra
Cc: Boqun Feng
Cc: Alan Stern
Cc: John Stultz
Cc: Neeraj Upadhyay
Cc: Linus Torvalds
C
o see what the build bots have to say about this.
This series applies on top of v6.11.1.
Signed-off-by: Mathieu Desnoyers
Cc: Nicholas Piggin
Cc: Michael Ellerman
Cc: Greg Kroah-Hartman
Cc: Sebastian Andrzej Siewior
Cc: "Paul E. McKenney"
Cc: Will Deacon
Cc: Boqun Feng
Cc: Alan
: 400.
BogoMIPS: 4799.75
Memory: 768 GB ram.
Signed-off-by: Mathieu Desnoyers
Cc: Nicholas Piggin
Cc: Michael Ellerman
Cc: Greg Kroah-Hartman
Cc: Sebastian Andrzej Siewior
Cc: "Paul E. McKenney"
Cc: Will Deacon
Cc: Peter Zijlstra
Cc: Boqun Feng
Cc: Alan Stern
Cc: J
which depend on @a before loading @a.
The same logic applies with @a and @b swapped.
Suggested-by: Linus Torvalds
Suggested-by: Boqun Feng
Signed-off-by: Mathieu Desnoyers
Reviewed-by: Boqun Feng
Acked-by: "Paul E. McKenney"
Acked-by: Alan Stern
Cc: Greg Kroah-Hartman
Cc: Sebasti
roc.c | 6 ++
> drivers/remoteproc/ti_k3_r5_remoteproc.c | 3 +--
> 3 files changed, 5 insertions(+), 10 deletions(-)
>
Applied.
Thanks,
Mathieu
> diff --git a/drivers/remoteproc/ti_k3_dsp_remoteproc.c
> b/drivers/remoteproc/ti_k3_dsp_remoteproc.c
> index 8be
ewed-by: Jason Gunthorpe
> Link:
> https://lore.kernel.org/r/2024061008.88197-13-baolu...@linux.intel.com
> ---
> drivers/remoteproc/remoteproc_core.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
I have applied this patch.
Thanks,
Mathieu
> diff --gi
On 2024-09-29 17:51, Paul E. McKenney wrote:
On Sun, Sep 29, 2024 at 07:16:08AM -0400, Mathieu Desnoyers wrote:
Refer to ptr_eq() in the rcu_dereference() documentation.
ptr_eq() is a mechanism that preserves address dependencies when
comparing pointers, and should be favored when comparing a
Refer to ptr_eq() in the rcu_dereference() documentation.
ptr_eq() is a mechanism that preserves address dependencies when
comparing pointers, and should be favored when comparing a pointer
obtained from rcu_dereference() against another pointer.
Signed-off-by: Mathieu Desnoyers
Cc: Greg Kroah
which depend on @a before loading @a.
The same logic applies with @a and @b swapped.
Suggested-by: Linus Torvalds
Suggested-by: Boqun Feng
Signed-off-by: Mathieu Desnoyers
Reviewed-by: Boqun Feng
Acked-by: "Paul E. McKenney"
Cc: Greg Kroah-Hartman
Cc: Sebastian Andrzej Siewior
C
Introduce ptr_eq() to compare two addresses while preserving the address
dependencies for later use of the address. It should be used when
comparing an address returned by rcu_dereference().
Thanks,
Mathieu
Cc: Greg Kroah-Hartman
Cc: Sebastian Andrzej Siewior
Cc: "Paul E. McKenney"
On 2024-09-29 01:24, Gary Guo wrote:
Cc: Nikita Popov
Cc: l...@lists.linux.dev
On Sat, 28 Sep 2024 09:51:27 -0400
Mathieu Desnoyers wrote:
Compiler CSE and SSA GVN optimizations can cause the address dependency
of addresses returned by rcu_dereference to be lost when comparing those
On 2024-09-28 17:49, Alan Stern wrote:
On Sat, Sep 28, 2024 at 11:32:18AM -0400, Mathieu Desnoyers wrote:
On 2024-09-28 16:49, Alan Stern wrote:
On Sat, Sep 28, 2024 at 09:51:27AM -0400, Mathieu Desnoyers wrote:
equality, which does not preserve address dependencies and allows the
following
1 - 100 of 3150 matches
Mail list logo
