{
> obj = ubuf->data + tail;
> /* process obj */
> tail += obj->size;
> tail %= ubuf->size;
> }
>
> /*
> * Ensure all data reads are complete before we issue the
> *
Allow it to be used from SPU, since it should not have unwanted
side-effects.
[ Untested on this architecture. To try it out: fetch linux-next/akpm,
apply this patch, build/run a membarrier-enabled kernel, and do make
kselftest. ]
Signed-off-by: Mathieu Desnoyers
CC: Andrew Morton
CC
- On Aug 31, 2015, at 2:54 AM, Michael Ellerman m...@ellerman.id.au wrote:
> On Thu, 2015-08-27 at 13:56 -0400, Mathieu Desnoyers wrote:
>> Allow it to be used from SPU, since it should not have unwanted
>> side-effects.
>>
>> [ Untested on this architecture. To t
Allow it to be used from SPU, since it should not have unwanted
side-effects.
[ Picked-by: Michael Ellerman ]
Signed-off-by: Mathieu Desnoyers
CC: Andrew Morton
CC: linux-...@vger.kernel.org
CC: Benjamin Herrenschmidt
CC: Paul Mackerras
CC: Michael Ellerman
CC: linuxppc-dev
Signed-off-by: Mathieu Desnoyers
CC: Benjamin Herrenschmidt
CC: Paul Mackerras
CC: Michael Ellerman
CC: Boqun Feng
CC: Peter Zijlstra
CC: "Paul E. McKenney"
CC: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/include/asm/systbl.h | 1 +
arch/powerpc/include/uapi/asm/unistd.
Signed-off-by: Mathieu Desnoyers
CC: Benjamin Herrenschmidt
CC: Paul Mackerras
CC: Michael Ellerman
CC: Boqun Feng
CC: Peter Zijlstra
CC: "Paul E. McKenney"
CC: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/include/asm/systbl.h | 1 +
arch/powerpc/include/uapi/asm/unistd.
- On May 24, 2018, at 3:03 AM, Michael Ellerman m...@ellerman.id.au wrote:
> Mathieu Desnoyers writes:
>> - On May 23, 2018, at 4:14 PM, Mathieu Desnoyers
>> mathieu.desnoy...@efficios.com wrote:
> ...
>>>
>>> Hi Boqun,
>>>
>>> I t
From: Boqun Feng
Call the rseq_handle_notify_resume() function on return to userspace if
TIF_NOTIFY_RESUME thread flag is set.
Perform fixup on the pre-signal when a signal is delivered on top of a
restartable sequence critical section.
Signed-off-by: Boqun Feng
Signed-off-by: Mathieu
-bit powerpc kernel by Mathieu Desnoyers. Still needs to
be tested on 32-bit powerpc kernel. ]
Signed-off-by: Boqun Feng
Signed-off-by: Mathieu Desnoyers
CC: Benjamin Herrenschmidt
CC: Paul Mackerras
CC: Michael Ellerman
CC: Peter Zijlstra
CC: "Paul E. McKenney"
CC: li
-reservation/store-conditional atomics.
Signed-off-by: Boqun Feng
Signed-off-by: Mathieu Desnoyers
CC: Benjamin Herrenschmidt
CC: Paul Mackerras
CC: Michael Ellerman
CC: Peter Zijlstra
CC: "Paul E. McKenney"
CC: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/include/asm/systbl.h |
- On Jun 5, 2018, at 1:21 AM, Michael Ellerman m...@ellerman.id.au wrote:
> Mathieu Desnoyers writes:
>> From: Boqun Feng
>>
>> Syscalls are not allowed inside restartable sequences, so add a call to
>> rseq_syscall() at the very beginning of s
- On Jun 5, 2018, at 1:18 AM, Michael Ellerman m...@ellerman.id.au wrote:
> Mathieu Desnoyers writes:
>
>> From: Boqun Feng
>>
>> Wire up the rseq system call on powerpc.
>>
>> This provides an ABI improving the speed of a user-space getcpu
>> o
is is why we came up with this
value, but I don't have the detailed specs of that machine.
Any feedback on this matter would be appreciated.
Thanks!
Mathieu
[1] https://liburcu.org
[2] https://github.com/urcu/userspace-rcu/pull/22
[3] https://www.7-cpu.com/
--
Mathieu Desnoyers
EfficiOS
On 2024-03-26 03:19, Michael Ellerman wrote:
Mathieu Desnoyers writes:
Hi,
Hi Mathieu,
In the powerpc architecture support within the liburcu project [1]
we have a cache line size defined as 256 bytes with the following
comment:
/* Include size of POWER5+ L3 cache lines: 256 bytes
On 2024-03-25 16:34, Nathan Lynch wrote:
Mathieu Desnoyers writes:
In the powerpc architecture support within the liburcu project [1]
we have a cache line size defined as 256 bytes with the following
comment:
/* Include size of POWER5+ L3 cache lines: 256 bytes */
#define CAA_CACHE_LINE_SIZE
RCU read locks shared with nmi handlers.
Thoughts ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
lsyms.c:symbol_valid() to also include function descriptor
symbols. This would mean accepting symbols pointing into the .opd ELF
section.
IMHO the second option would be better because it does not increase the
kernel image size as much as KALLSYMS_ALL.
Thoughts ?
Thanks,
Mathieu
--
Mathieu De
On 2022-12-06 21:09, Michael Ellerman wrote:
Mathieu Desnoyers writes:
On 2022-12-05 17:50, Michael Ellerman wrote:
Michael Jeanson writes:
On 2022-12-05 15:11, Michael Jeanson wrote:
Michael Jeanson writes:
In v5.7 the powerpc syscall entry/exit logic was rewritten in C, on
spect it would be good to merge that fix into tip/master though
sched/core.
Thanks,
Mathieu
Thanks
-Sachin
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
|| (SPU_FS = y &&
> OPROFILE = y)
> + default y
> + help
> + Profiling of Cell BE SPUs requires special support enabled
> + by this option.
> +
> config KPROBES
>
--
Mathieu Desnoyers
Computer Engin
S and OPROFILE are enabled.
Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
CC: Adrian Bunk <[EMAIL PROTECTED]>
CC: Randy Dunlap <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
CC: linuxppc-dev@ozlabs.org
CC: [EMAIL PROTECTED]
---
arch/powerpc/Kconfig |4
* Arnd Bergmann ([EMAIL PROTECTED]) wrote:
> On Saturday 29 December 2007, Mathieu Desnoyers wrote:
> > This patch restores the Cell OProfile support that was killed by
> > commit 09cadedbdc01f1a4bea1f427d4fb4642eaa19da9.
> >
> > It puts it in arch/powerpc/Kconfig.
Make sure that at least cmpxchg64_local is available on all architectures to use
for unsigned long long values.
Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
Acked-by: Paul Mackerras <[EMAIL PROTECTED]>
CC: linuxppc-dev@ozlabs.org
---
include/asm-powerpc/system.h |6 ++
Make sure that at least cmpxchg64_local is available on all architectures to use
for unsigned long long values.
Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
Acked-by: Paul Mackerras <[EMAIL PROTECTED]>
CC: linuxppc-dev@ozlabs.org
---
include/asm-powerpc/sys
Hi Andrew,
I got the following errors when building 2.6.23-rc2-mm2 on both mips and
arm. Both errors are very much alike.
MIPS:
/opt/crosstool/gcc-3.4.5-glibc-2.3.6/mips-unknown-linux-gnu/lib/gcc/mips-unknown-linux-gnu/3.4.5/include
-D__KERNEL__ -Iinclude -Iinclude2 -I/home/compudj/git/linux-
* Martin Schwidefsky ([EMAIL PROTECTED]) wrote:
> On Fri, 2007-08-10 at 22:58 -0400, Mathieu Desnoyers wrote:
> > I got the following errors when building 2.6.23-rc2-mm2 on both mips and
> > arm. Both errors are very much alike.
>
> That attached patch should fix it for arm
Make sure that at least cmpxchg64_local is available on all architectures to use
for unsigned long long values.
Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]
CC: linuxppc-dev@ozlabs.org
---
include/asm-powerpc/system.h |6 ++
1 file changed, 6 inse
* Paul Mackerras ([EMAIL PROTECTED]) wrote:
> Mathieu Desnoyers writes:
>
> > Make sure that at least cmpxchg64_local is available on all architectures
> > to use
> > for unsigned long long values.
> >
> > Signed-off-by: Mathieu Desnoyers <[EMAIL PR
Subject: [RFC patch 6/9] Re: [PATCH] Stringify support commas
> This is a no-no for those archs that still use -traditional.
> > I dunno if this is a problem for you at the moment and the
> > right fix is anyway to nuke -traditional.
> >
> > Sam
Signed-off-by
* Paul Mackerras ([EMAIL PROTECTED]) wrote:
> Mathieu Desnoyers writes:
> > Subject: [RFC patch 6/9] Re: [PATCH] Stringify support commas
> > > This is a no-no for those archs that still use -traditional.
> > > > I dunno if this is a problem for you at the moment
freescale(P) 80211(P)
>> shm_freescale(P) ath_remote_regs_freescale(P) exsw
>> load_local_fpga_freescale 8021q poe_fi
>> NIP: c00bd6fc LR: c00bd6fc CTR: c00bd6c8
>> REGS: decd5cf0 TRAP: 0700 Tainted: P (2.6.27-rc2)
>> MSR: 00029000 CR: 8882 XER: 2000
>> TASK = d9f5a9a0[6897] 'sh' THREAD: decd4000
>> GPR00: decd5da0 d9f5a9a0 dd801180 decd5de8 0004
>> fff9
>> GPR08: fffa 00d5ca28 decd5d90 2ccc1686 100ad874 1fffb200
>>
>> GPR16: 007fff00 decd5ec4 0008 c02fe298 00200200 c031aa34
>> decd5de8
>> GPR24: decd5df4 1af2 dd507d00 c038 dd801180 decd5de8
>> decd5da0
>> NIP [c00bd6fc] d_lookup+0x40/0x90
>> LR [c00bd6fc] d_lookup+0x40/0x90
>> Call Trace:
>> [decd5dc0] [c00bd7d8] d_hash_and_lookup+0x8c/0xc4
>> [decd5de0] [c00ed728] proc_flush_task+0xb4/0x268
>> [decd5e40] [c0032894] release_task+0x6c/0x39c
>> [decd5e70] [c0033238] wait_consider_task+0x674/0x920
>> [decd5eb0] [c0033610] do_wait+0x12c/0x3d4
>> [decd5f20] [c0033954] sys_wait4+0x9c/0xe8
>> [decd5f40] [c0010554] ret_from_syscall+0x0/0x3c
>> Instruction dump:
>> 7c0802a6 bf61000c 3f60c038 7c3f0b78 90010024 7c7c1b78 7c9d2378 83db52a0
>> 73c1 7f83e378 7fa4eb78 4082002f <> 2f83 409e0030 801b52a0
>> ---[ end trace 00106ff4ec3b9c22 ]---
>>
>>
>>
>>
>
--
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
* Steven Rostedt ([EMAIL PROTECTED]) wrote:
> Mathieu Desnoyers wrote:
>>
>> Steve ? I just noticed this :
>>
>>
>> ftrace_modify_code(unsigned long ip, unsigned char *old_code,
>>unsigned char *new_code)
>> {
>> unsi
> [dd5b1df0] [c00b13f8] do_path_lookup+0x78/0x13c
> [dd5b1e20] [c00b20f4] user_path_at+0x64/0xac
> [dd5b1e90] [c00a9028] vfs_lstat_fd+0x34/0x74
> [dd5b1ec0] [c00a90fc] vfs_lstat+0x30/0x48
> [dd5b1ed0] [c00a9144] sys_lstat64+0x30/0x5c
> [dd5b1f40] [c0010554] ret_from_syscall+0x0/
de:
> >
> > That would work I suppose, I'll give it a try.
> >
> > > if (copy_from_user(cmd, ip, ARCH_CALL_SIZE))
> > > goto fault;
> > >
> > > if (memcmp(cmd, old, ARCH_CALL_SIZE) != 0)
> > > goto not_same
* Steven Rostedt ([EMAIL PROTECTED]) wrote:
>
> On Mon, 18 Aug 2008, Mathieu Desnoyers wrote:
>
> > * Steven Rostedt ([EMAIL PROTECTED]) wrote:
> > >
> > > On Tue, 19 Aug 2008, Benjamin Herrenschmidt wrote:
> > >
> > > >
> > &g
* Eran Liberty ([EMAIL PROTECTED]) wrote:
> Mathieu Desnoyers wrote:
>> Can you check if, at some point during the system execution (starting
>> from boot), 0xdd5b1d58 is an address where a module is loaded ? (the
>> module can be later unloaded, what I wonder is if this addre
xc00bb700 :mr r31,r1
> 0xc00bb704 :stw r0,36(r1)
> 0xc00bb708 :mr r28,r3
> 0xc00bb70c :mr r29,r4
> 0xc00bb710 : lwz r30,12960(r27)
> 0xc00bb714 :andi. r0,r30,1
> 0xc00bb718 :mr r3
* Eran Liberty ([EMAIL PROTECTED]) wrote:
> Mathieu Desnoyers wrote:
>> Can you also give us
>>
>> objdump -S --start-address=0xC00BB724 vmlinux | head 20
>>
>> ?
>>
>> Then we could compare the result with the OOPS instruction dump :
>>
>&
* Steven Rostedt ([EMAIL PROTECTED]) wrote:
>
>
> On Mon, 18 Aug 2008, Mathieu Desnoyers wrote:
>
> > * Steven Rostedt ([EMAIL PROTECTED]) wrote:
> > >
> > > On Tue, 19 Aug 2008, Benjamin Herrenschmidt wrote:
> > >
> > > >
> >
We need a marker_synchronize_unregister() before the end of exit() to make sure
every probe callers have exited the non preemptible section and thus are not
executing the probe code anymore.
Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
CC: Ingo Molnar <[EMAIL PROTECTED]>
CC:
We need a marker_synchronize_unregister() before the end of exit() to make sure
every probe callers have exited the non preemptible section and thus are not
executing the probe code anymore.
Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
CC: Ingo Molnar <[EMAIL PROTECTED]>
CC:
Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]
CC: linuxppc-dev@ozlabs.org
--
arch/powerpc/kernel/vmlinux.lds.S |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Index: linux-2.6-lttng/arch/powerpc/kernel/vmlinux
testing your code ***
>
> See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find
> out what to do about this
>
> --
> Subject: powerpc: add missing DATA_DATA
> From: Mathieu Desnoyers <[EMAIL PR
ly sparc can not include linux/pagemap.h in this file
* so leave page_cache_release and release_pages undeclared... */
#define free_page_and_swap_cache(page) \
page_cache_release(page)
#define free_pages_and_swap_cache(pages, nr) \
release_pages((pages), (nr), 0);
Signed-off-by:
.data.rel* .toc1)
+ DATA_DATA
+ *(.data.rel*)
+ *(.toc1)
*(.branch_lt)
}
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F2
de2/asm/pgtable.h:15,
from /home/compudj/git/linux-2.6-lttng/include/linux/mm.h:38,
from /home/compudj/git/linux-2.6-lttng/include/linux/rmap.h:9,
from /home/compudj/git/linux-2.6-lttng/init/main.c:49:
mm.h includes asm-sparc/pgtable.h includes linux/
nterrupt replay is an interesting case. I thought it was okay (because
> the IPI would cause a hard interrupt which does do the rfi) but that
> should at least be written.
Yes.
> The context synchronisation happens before
> the Linux IPI function is called, but for the purpose of membarr
//gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html#Machine-Constraints
it seems that "Q" means "A memory operand addressed by just a base register."
I suspect that lwz and stw don't expect some kind of immediate offset which
can be kept with "m", and
- On Jul 7, 2020, at 8:59 PM, Segher Boessenkool seg...@kernel.crashing.org
wrote:
> Hi!
>
> On Tue, Jul 07, 2020 at 03:17:10PM -0400, Mathieu Desnoyers wrote:
>> I'm trying to build librseq at:
>>
>> https://git.kernel.org/pub/scm/libs/librseq/librseq.
- On Jul 8, 2020, at 8:33 AM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> - On Jul 7, 2020, at 8:59 PM, Segher Boessenkool
> seg...@kernel.crashing.org
> wrote:
[...]
>>
>> So perhaps you have code like
>>
>> int *p;
>> int x
barrier + context synchronistaion by the time it has done" is not strictly
correct: the context synchronizing instruction does not strictly need to
happen on each core before membarrier returns. A similar line of thoughts
can be followed for memory barriers.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Jul 8, 2020, at 10:21 AM, Christophe Leroy christophe.le...@csgroup.eu
wrote:
> Le 08/07/2020 à 16:00, Mathieu Desnoyers a écrit :
>> - On Jul 8, 2020, at 8:33 AM, Mathieu Desnoyers
>> mathieu.desnoy...@efficios.com wrote:
>>
>>> - On Jul 7, 2020,
uot; (*((unsigned char *)ptep+4))
: "r" (pte) : "memory");
where I would have expected:
stw%U1%X1 %L2,%1"
Is it a bug or am I missing something ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
IT for SMP support")
Signed-off-by: Mathieu Desnoyers
Cc: Christophe Leroy
Cc: Kumar Gala
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: linuxppc-dev@lists.ozlabs.org
Cc: # v2.6.28+
---
arch/powerpc/include/asm/book3s/32/pgtable.h | 2 +-
arch/powerpc/include/asm/n
r17 as long as your code (after inlining etc.!) stays
> small, but there is Murphy's law.
r17 is in the clobber list, so it should be ok.
>
> Anyway... something in rseq_str is wrong, missing %X. This may
> have to do with the abuse of inline asm here, making a fix harder :-(
I just committed a fix which enhances the macros.
Thanks for your help!
Mathieu
>
>
> Segher
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Jul 8, 2020, at 8:10 PM, Segher Boessenkool seg...@kernel.crashing.org
wrote:
> Hi!
>
> On Wed, Jul 08, 2020 at 10:00:01AM -0400, Mathieu Desnoyers wrote:
[...]
>
>> -#define STORE_WORD "std "
>> -#define LOAD_WORD "ld "
&
- On Jul 8, 2020, at 8:18 PM, Segher Boessenkool seg...@kernel.crashing.org
wrote:
> On Wed, Jul 08, 2020 at 08:01:23PM -0400, Mathieu Desnoyers wrote:
>> > > #define RSEQ_ASM_OP_CMPEQ(var, expect, label)
>> > > \
>> > > LOAD_
- On Jul 9, 2020, at 1:37 PM, Segher Boessenkool seg...@kernel.crashing.org
wrote:
> On Thu, Jul 09, 2020 at 09:43:47AM -0400, Mathieu Desnoyers wrote:
>> > What protects r17 *after* this asm statement?
>>
>> As discussed in the other leg of the thread (with the cod
- On Jul 9, 2020, at 1:42 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> - On Jul 9, 2020, at 1:37 PM, Segher Boessenkool
> seg...@kernel.crashing.org
> wrote:
>
>> On Thu, Jul 09, 2020 at 09:43:47AM -0400, Mathieu Desnoyers wrote:
>>> >
- On Jul 9, 2020, at 4:46 PM, Segher Boessenkool seg...@kernel.crashing.org
wrote:
> On Thu, Jul 09, 2020 at 01:56:19PM -0400, Mathieu Desnoyers wrote:
>> > Just to make sure I understand your recommendation. So rather than
>> > hard coding r17 as the temporary registers
RIVATE,GLOBAL}_EXPEDITED, implicitly
> - * provided by mmdrop(),
> - * - a sync_core for SYNC_CORE.
> + * switch_mm(). Membarrier requires a full barrier after storing to
> + * rq->curr, before returning to userspace, for
> + * {PRIVATE,GLOBAL}_EXPEDITED. This is implicitly provided by mmdrop().
>*/
> - if (mm) {
> - membarrier_mm_sync_core_before_usermode(mm);
> + if (mm)
> mmdrop(mm);
> - }
> +
> if (unlikely(prev_state == TASK_DEAD)) {
> if (prev->sched_class->task_dead)
> prev->sched_class->task_dead(prev);
> @@ -6292,6 +6289,7 @@ void idle_task_exit(void)
> BUG_ON(current != this_rq()->idle);
>
> if (mm != &init_mm) {
> + /* enter_lazy_tlb is not done because we're about to go down */
> switch_mm(mm, &init_mm, current);
> finish_arch_post_lock_switch();
> }
> --
> 2.23.0
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
interrupt to kernel code does not need to be context serializing
as long as kernel serializes before returning to user-space.
However, return from interrupt to user-space needs to be context serializing.
Thanks,
Mathieu
>
> https://lists.ozlabs.org/pipermail/linuxppc-dev/2020-July/214171.html
ed more than just context sync after IPI. We need context
sync
in return path of any trap/interrupt/system call which returns to user-space,
else
we'd need to add the proper core serializing barriers in the scheduler, as we
had
to do for lazy tlb on x86.
Or am I missing something ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
_uring write request
or this other scenario:
* Frequent read / Infrequent write, communicating read completion through
variable X
load from X (waiting for X==1) -> membarrier -> submit io_uring write request
with matching
wait for io_uring read request completion -> asm volatile (::: "memory") ->
store X=1
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
all.
In the case of io_uring, submitting a request or returning from waiting
on request completion appear to provide this causality relationship.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Jul 16, 2020, at 11:46 AM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> - On Jul 16, 2020, at 12:42 AM, Nicholas Piggin npig...@gmail.com wrote:
>> I should be more complete here, especially since I was complaining
>> about unclear barrier comment :)
- On Jul 16, 2020, at 12:03 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> - On Jul 16, 2020, at 11:46 AM, Mathieu Desnoyers
> mathieu.desnoy...@efficios.com wrote:
>
>> - On Jul 16, 2020, at 12:42 AM, Nicholas Piggin npig...@gmail.com wrote:
>&
- On Jul 16, 2020, at 5:24 PM, Alan Stern st...@rowland.harvard.edu wrote:
> On Thu, Jul 16, 2020 at 02:58:41PM -0400, Mathieu Desnoyers wrote:
>> - On Jul 16, 2020, at 12:03 PM, Mathieu Desnoyers
>> mathieu.desnoy...@efficios.com wrote:
>>
>> >
rmed through
system calls from the context of user-space threads, which are called from the
right mm.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Jul 17, 2020, at 10:51 AM, Alan Stern st...@rowland.harvard.edu wrote:
> On Fri, Jul 17, 2020 at 09:39:25AM -0400, Mathieu Desnoyers wrote:
>> - On Jul 16, 2020, at 5:24 PM, Alan Stern st...@rowland.harvard.edu
>> wrote:
>>
>> > On Thu, Jul 16, 202
ory barrier on the caller thread _after_ we finished
* waiting for the last IPI. [...]
However, it does not explain why it needs to be paired with a barrier in the
scheduler, clearly for the case where the IPI is skipped. I wonder whether this
part
of the comment is factually correct:
* [...] Matches memory barriers around rq->curr modification in
scheduler.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Jul 17, 2020, at 1:44 PM, Alan Stern st...@rowland.harvard.edu wrote:
> On Fri, Jul 17, 2020 at 12:22:49PM -0400, Mathieu Desnoyers wrote:
>> - On Jul 17, 2020, at 12:11 PM, Alan Stern st...@rowland.harvard.edu
>> wrote:
>>
>> >> > I agree w
Please provide an example case with memory accesses via kthread_use_mm where
ordering matters to support your concern.
> so I really think
> it's a fragile interface with no real way for the user to know how
> kernel threads may use its mm for any particular reason, so membarrier
> should synchronize all possible kernel users as well.
I strongly doubt so, but perhaps something should be clarified in the
documentation
if you have that feeling.
Thanks,
Mathieu
>
> Thanks,
> Nick
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
have a compelling use-case to implement a different behavior which covers
kthreads, this could be added consistently across membarrier commands with a
flag (or by adding new commands).
Does this approach make sense ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
rely on this, and we just provide an additional guarantee for future kthread
implementations.
> Also, I just realized, I still have a fix for use_mm() now
> kthread_use_mm() that seems to have been lost.
I suspect we need to at least document the memory barriers in kthread_use_mm and
kthread_unuse_mm to state that they are required by membarrier if we want to
ipi kthreads as well.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Jul 21, 2020, at 11:19 AM, Peter Zijlstra pet...@infradead.org wrote:
> On Tue, Jul 21, 2020 at 11:15:13AM -0400, Mathieu Desnoyers wrote:
>> - On Jul 21, 2020, at 11:06 AM, Peter Zijlstra pet...@infradead.org
>> wrote:
>>
>> > On Tue, Jul 21, 2020
- On Aug 25, 2021, at 8:51 PM, Sean Christopherson sea...@google.com wrote:
> On Mon, Aug 23, 2021, Mathieu Desnoyers wrote:
>> [ re-send to Darren Hart ]
>>
>> - On Aug 23, 2021, at 11:18 AM, Mathieu Desnoyers
>> mathieu.desnoy...@efficios.com wrote:
>>
- On Aug 26, 2021, at 7:54 PM, Sean Christopherson sea...@google.com wrote:
> On Thu, Aug 26, 2021, Mathieu Desnoyers wrote:
>> - On Aug 25, 2021, at 8:51 PM, Sean Christopherson sea...@google.com
>> wrote:
>> >> >> + r = sched_s
- On Aug 27, 2021, at 7:23 PM, Sean Christopherson sea...@google.com wrote:
> On Fri, Aug 27, 2021, Mathieu Desnoyers wrote:
[...]
>> Does it reproduce if we randomize the delay to have it picked randomly from
>> 0us
>> to 100us (with 1us step) ? It would remove a
("x86/kvm: Use generic xfer
> to guest work function"), where TIF_NOTIFY_RESUME would be cleared by KVM
> without updating rseq, leading to a stale CPU ID and other badness.
>
> Signed-off-by: Sean Christopherson
Thanks!
Acked-by: Mathieu Desnoyers
> ---
> tools/testing
tter put in x86 lazy tlb code.
Ideally yes this complexity should sit within the x86 architecture code
if only that architecture requires it.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
re is the meat. The current code is using the (possibly incomplete)
lazy TLB state known by the scheduler to sync core, and it appears it may be
a bit more heavy that what is strictly needed.
Your change instead rely on the internal knowledge of lazy TLB within x86
switch_mm_irqs_off to achie
// the mm check for?
>> +membarrier_mm_sync_core_before_usermode(next);
>
> On the other hand the reason for this mm check that you mention contradicts
> my previous understanding as the git log says:
>
> commit 2840cf02fae627860156737e83326df354ee4ec
?
Based on the notes I have, use of `eret` on aarch64 guarantees a context
synchronizing
instruction when returning to user-space.
Thanks,
Mathieu
>
> Cc: Michael Ellerman
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: Nich
pose to user-space, e.g. flush_icache_user_range on arm32.
So between code modification and allowing other threads to jump to that code,
it should be expected that architectures without coherent i/d cache will need
to flush caches to ensure coherency *and* to issue membarrier to make sure
core serializing instructions will be issued by every thread acting on the
same mm either immediately by means of the IPI, or before they return to
user-space if they do not happen to be currently running when the membarrier
system call is invoked.
Hoping this clarifies things. I suspect we will need to clarify documentation
about what membarrier *does not* guarantee, given that you mistakenly expected
membarrier to take care of cache flushing.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
ck".
>
> So, the core executing this call is not allowed to block, but the
> other part indicates that the other CPUs _have_ executed a serialising
> instruction before this call returns... one wonders how that happens
> without blocking. Maybe the CPU spins waiting for completion instead?
Membarrier expedited sync-core issues IPIs to all CPUs running sibling
threads. AFAIR the IPI mechanism uses the "csd lock" which is basically
busy waiting. So it does not "block", it busy-waits.
For completeness of the explanation, other (non-running) threads acting
on the same mm will eventually issue the context synchronizing instruction
before returning to user-space whenever they are scheduled back.
Thanks,
Mathieu
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
4/a/Memory-Ordering/Barriers/ISB-in-more-detail
[2]
https://montcs.bloomu.edu/Information/ARMv8/ARMv8-A_Architecture_Reference_Manual_(Issue_A.a).pdf
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Dec 28, 2020, at 4:06 PM, Andy Lutomirski l...@kernel.org wrote:
> On Mon, Dec 28, 2020 at 12:32 PM Mathieu Desnoyers
> wrote:
>>
>> - On Dec 28, 2020, at 2:44 PM, Andy Lutomirski l...@kernel.org wrote:
>>
>> > On Mon, Dec 28, 2020 at 11:09
e {
...
}
I don't think mixing up preprocessor and code logic makes it more readable.
Thanks,
Mathieu
> } else if (flags == MEMBARRIER_FLAG_RSEQ) {
> if (!IS_ENABLED(CONFIG_RSEQ))
> return -EINVAL;
> --
> 2.31.1
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
tent with the icache flush and the CPU's cache type.
> +#
> +# On powerpc, a program can use MEMBARRIER_CMD_PRIVATE_EXPEDITED_SYNC_CORE
> +# similarly to arm64. It would be nice if the powerpc maintainers could
> +# add a more clear explanantion.
We should document the requirements on ARMv7 as well.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Jun 17, 2021, at 8:12 PM, Andy Lutomirski l...@kernel.org wrote:
> On 6/17/21 7:47 AM, Mathieu Desnoyers wrote:
>
>> Please change back this #ifndef / #else / #endif within function for
>>
>> if (!IS_ENABLED(CONFIG_ARCH_HAS_MEMBARRIER_SYNC_COR
le__ ("sync" : : : "memory")
So the original motivation here was to skip a "sync" instruction whenever
switching between threads which are part of the same process. But based on
recent discussions, I suspect my implementation may be inaccurately doing
so
- On Jun 18, 2021, at 3:58 PM, Andy Lutomirski l...@kernel.org wrote:
> On Fri, Jun 18, 2021, at 9:31 AM, Mathieu Desnoyers wrote:
>> - On Jun 17, 2021, at 8:12 PM, Andy Lutomirski l...@kernel.org wrote:
>>
>> > On 6/17/21 7:47 AM, Mathieu Desnoyers wrote:
>&g
e paths which consume the
NOTIFY_RESUME without calling the rseq callback, which introduces issues.
Agreed.
Acked-by: Mathieu Desnoyers
>
> Signed-off-by: Sean Christopherson
> ---
> arch/arm/kernel/signal.c | 1 -
> arch/arm64/kernel/signal.c | 1 -
> arch/csky/kernel/signa
ip fixup code. Indeed, it
is not relevant to do any fixup here, because it is nested in a ioctl system
call.
Effectively, this would preserve the SIGSEGV behavior when this ioctl is
erroneously called by user-space from a rseq critical section.
Thanks for looking into this !
Mathieu
> return clear_rseq_cs(t);
> ret = rseq_need_restart(t, rseq_cs.flags);
> if (ret <= 0)
> --
> 2.33.0.rc1.237.g0d66db33f3-goog
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
seq_abi.cpu_id reads
vs
sched_setaffinity calls within the migration thread.
Thoughts ?
Thanks,
Mathieu
> + TEST_ASSERT(rseq_cpu == cpu || cpu != sched_getcpu(),
> + "rseq CPU = %d, sched CPU = %d\n", rseq_cpu, cpu);
> + }
> +
> + pthread_join(migration_thread, NULL);
> +
> + kvm_vm_free(vm);
> +
> + sys_rseq(RSEQ_FLAG_UNREGISTER);
> +
> + return 0;
> +}
> --
> 2.33.0.rc1.237.g0d66db33f3-goog
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Aug 19, 2021, at 7:33 PM, Sean Christopherson sea...@google.com wrote:
> On Thu, Aug 19, 2021, Mathieu Desnoyers wrote:
>> - On Aug 17, 2021, at 8:12 PM, Sean Christopherson sea...@google.com
>> wrote:
>>
>> > Add a test to verify an rseq's CPU
- On Aug 19, 2021, at 7:48 PM, Sean Christopherson sea...@google.com wrote:
> On Thu, Aug 19, 2021, Mathieu Desnoyers wrote:
>> - On Aug 17, 2021, at 8:12 PM, Sean Christopherson sea...@google.com
>> wrote:
>> > @@ -250,7 +250,7 @@ static int rseq_ip_fi
earing TIF_NOTIFY_RESUME without informing rseq can lead to segfaults
> and other badness in userspace VMMs that use rseq in combination with KVM,
> e.g. due to the CPU ID being stale after task migration.
Acked-by: Mathieu Desnoyers
>
> Fixes: 72c3c0fe54a3 ("x86/kvm: Use generic xfer to
();
> + cpu = sched_getcpu();
> + rseq_cpu = READ_ONCE(__rseq.cpu_id);
> + smp_rmb();
> + } while (snapshot != atomic_read(&seq_cnt));
> +
> + TEST_ASSERT(rseq_cpu == cpu,
> + "rseq CPU = %d, sched CPU = %d\n", rseq_cpu, cpu);
> + }
> +
> + pthread_join(migration_thread, NULL);
> +
> + kvm_vm_free(vm);
> +
> + sys_rseq(RSEQ_FLAG_UNREGISTER);
> +
> + return 0;
> +}
> --
> 2.33.0.rc2.250.ged5fa647cd-goog
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
1 - 100 of 167 matches
Mail list logo
