iptive
?
(a "faultable" tracepoint sounds weird though)
Thanks,
Mathieu
>
>> +rcu_read_lock_trace(); \
>> +} else {\
>> + /* keep srcu and sched-rcu usage consistent */ \
>> +preempt_disable_notrace(); \
> > + } \
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
liburcu master, stable-0.12, and
stable-2.11.
Out of curiosity, which test is hanging ? Is it a test which is part of the
liburcu
tree or some out-of-tree test ? I wonder why we did not catch it in our CI [1].
Thanks,
Mathieu
[1] https://ci.lttng.org/view/Liburcu/
>
> Signed-off-by: P
liburcu master, stable-0.12, and
stable-2.11.
Out of curiosity, which test is hanging ? Is it a test which is part of the
liburcu
tree or some out-of-tree test ? I wonder why we did not catch it in our CI [1].
Thanks,
Mathieu
[1] https://ci.lttng.org/view/Liburcu/
>
> Signed-off-by: P
leepable tracepoint), but have a
truncation behavior when called from non-sleepable context. This can actually
be done by looking at the new "TRACEPOINT_MAYSLEEP" tp flag. Passing that
tp_flags to code shared between sleepable and non-sleepable probes would allow
the callee to know whether it can take a page fault or not.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Oct 26, 2020, at 4:20 AM, Peter Zijlstra pet...@infradead.org wrote:
> On Fri, Oct 23, 2020 at 05:13:59PM -0400, Joel Fernandes wrote:
>> On Fri, Oct 23, 2020 at 03:53:52PM -0400, Michael Jeanson wrote:
>> > From: Mathieu Desnoyers
>> >
>> > Consider
- On Oct 23, 2020, at 1:37 AM, Xing Zhengjun zhengjun.x...@linux.intel.com
wrote:
> On 10/22/2020 9:19 PM, Mathieu Desnoyers wrote:
>> - On Oct 21, 2020, at 9:54 PM, Xing Zhengjun
>> zhengjun.x...@linux.intel.com
>> wrote:
>> [...]
>>> In fac
tsuite, thus limiting the entire testsuite
to a single CPU, or you expect that internally the will-it-scale context-switch1
test gets affined to a single specific CPU/core/hardware thread through use of
hwloc ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Sep 29, 2020, at 4:13 AM, Florian Weimer fwei...@redhat.com wrote:
> * Mathieu Desnoyers:
>
>>> So we have a bootstrap issue here that needs to be solved, I think.
>>
>> The one thing I'm not sure about is whether the vDSO interface is indeed
>> s
- On Oct 20, 2020, at 10:36 AM, Peter Zijlstra pet...@infradead.org wrote:
> On Tue, Oct 20, 2020 at 09:47:13AM -0400, Mathieu Desnoyers wrote:
>> +void membarrier_update_current_mm(struct mm_struct *next_mm)
>> +{
>> +struct rq *rq = this_rq();
>> +
'TRACE_EVENT'
> | TRACE_EVENT(writeback_queue_io,
> Kindly look into it and do the needful. Thanks!
> Regards,
> Syeda Shagufta Naaz
> Software Development Engineer | Mentor Embedded Linux
> Mentor , A Siemens Business
> ___
> l
.
Signed-off-by: Mathieu Desnoyers
Cc: Peter Zijlstra (Intel)
Cc: Boqun Feng
Cc: Will Deacon
Cc: Paul E. McKenney
Cc: Nicholas Piggin
Cc: Andy Lutomirski
Cc: Andrew Morton
---
Changes since v1:
- Add WARN_ON_ONCE(current->mm) in play_idle_precise (PeterZ),
- Use smp_mb__after_spinlock rat
m is NULL
r2 = load x
BUG_ON(r1 == 1 && r2 == 0)
Signed-off-by: Mathieu Desnoyers
Cc: Peter Zijlstra (Intel)
Cc: Boqun Feng
Cc: Will Deacon
Cc: Paul E. McKenney
Cc: Nicholas Piggin
Cc: Andy Lutomirski
Cc: Thomas Gleixner
Cc: Linus Torvalds
Cc: Alan
Please find the following membarrier updates series posted for inclusion
upstream.
Thanks,
Mathieu
Mathieu Desnoyers (3):
sched: fix exit_mm vs membarrier (v4)
sched: membarrier: cover kthread_use_mm (v4)
sched: membarrier: document memory ordering scenarios
include/linux/sched/mm.h
Document membarrier ordering scenarios in membarrier.c. Thanks to Alan
Stern for refreshing my memory. Now that I have those in mind, it seems
appropriate to serialize them to comments for posterity.
Signed-off-by: Mathieu Desnoyers
Cc: Peter Zijlstra (Intel)
Cc: Boqun Feng
Cc: Will Deacon
Cc
- On Oct 19, 2020, at 11:24 PM, Xing Zhengjun zhengjun.x...@linux.intel.com
wrote:
> On 10/7/2020 10:50 PM, Mathieu Desnoyers wrote:
>> - On Oct 2, 2020, at 4:33 AM, Rong Chen rong.a.c...@intel.com wrote:
>>
>>> Greeting,
>>>
>&g
1518.4141-1-mathieu.desnoy...@efficios.com/
There are a few ways we could wire things up. One might be to add the
UUID field into the extended KTLS structure (so it's always updated after it
changes on next return to user-space). For this I assume that the Linux
scheduler
within the guest VM always
1518.4141-1-mathieu.desnoy...@efficios.com/
There are a few ways we could wire things up. One might be to add the
UUID field into the extended KTLS structure (so it's always updated after it
changes on next return to user-space). For this I assume that the Linux
scheduler
within the guest VM always
1518.4141-1-mathieu.desnoy...@efficios.com/
There are a few ways we could wire things up. One might be to add the
UUID field into the extended KTLS structure (so it's always updated after it
changes on next return to user-space). For this I assume that the Linux
scheduler
within the guest VM always
/1183082664.11002.1602082242482.javamail.zim...@efficios.com/
Who is maintaining those tests and the 0day bot ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
gree there is no need to hurry. Letting those patches live through
a few -rc releases before picking them into stable is a wise course of action.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
From: Michael Jeanson
The objective of the tests is to check that ICMP errors generated while
crossing between VRFs are properly routed back to the source host.
The first ttl test sends a ping with a ttl of 1 from h1 to h2 and parses the
output of the command to check that a ttl expired error
. ]
[ Testing shows that similar issues exist with ipv6 unreachable /
fragmentation needed messages. However, investigation of this
additional failure mode is beyond this investigation's scope. ]
Link: https://tools.ietf.org/html/rfc4443
Signed-off-by: Mathieu Desnoyers
Reviewed-by: David Ahern
1a6c4ea43e ("net: icmp_route_lookup should use rt dev to determine L3
domain")
Link: https://tools.ietf.org/html/rfc792
Signed-off-by: Mathieu Desnoyers
Reviewed-by: David Ahern
Cc: David Ahern
Cc: Jakub Kicinski
Cc: David S. Miller
Cc: net...@vger.kernel.org
---
Cha
paths involved in
sending TTL expired icmp errors. As detailed in the individual commit
messages, those fixes do not address similar icmp errors related to
network namespaces and unreachable / fragmentation needed messages,
which appear to use different code paths.
Thanks,
Mathieu
Mathieu
- On Oct 12, 2020, at 9:45 AM, David Ahern dsah...@gmail.com wrote:
> On 10/12/20 5:57 AM, Mathieu Desnoyers wrote:
>> OK, do you want to pick up the RFC patch series, or should I re-send it
>> without RFC tag ?
>
> you need to re-send for Dave or Jakub to pick them
te this approach first.
Thanks,
Mathieu
>
> Best regards,
> Nils Döring
> ___
> lttng-dev mailing list
> lttng-dev@lists.lttng.org
> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
__
- On Oct 11, 2020, at 7:56 PM, David Ahern dsah...@gmail.com wrote:
> On 10/5/20 9:30 AM, David Ahern wrote:
>> On 9/25/20 1:04 PM, Mathieu Desnoyers wrote:
>>> Hi,
>>>
>>> Here is an updated series of fixes for ipv4 and ipv6 which which ensure
>>&g
- On Oct 7, 2020, at 12:08 PM, Peter Zijlstra pet...@infradead.org wrote:
> On Wed, Oct 07, 2020 at 11:39:30AM -0400, Mathieu Desnoyers wrote:
>> Moving the membarrier_switch_mm to cover kthread cases was to ensure (2),
>> but if
>> we
>> add a p->mm NULL
- On Oct 7, 2020, at 11:07 AM, Peter Zijlstra pet...@infradead.org wrote:
> On Thu, Sep 24, 2020 at 01:25:07PM -0400, Mathieu Desnoyers wrote:
>
>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>> index 2d95dc3f4644..bab6f4f2809f 100644
>> --- a/kernel/sche
- On Oct 7, 2020, at 10:29 AM, Peter Zijlstra pet...@infradead.org wrote:
> On Thu, Sep 24, 2020 at 01:25:06PM -0400, Mathieu Desnoyers wrote:
>> diff --git a/kernel/exit.c b/kernel/exit.c
>> index 733e80f334e7..0767a2dbf245 100644
>> --- a/kernel/exit.c
>> +++ b
ier: cover kthread_use_mm (v3)")
> url:
> https://github.com/0day-ci/linux/commits/Mathieu-Desnoyers/Membarrier-updates/20200925-012549
> base: https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git
> 848785df48835eefebe0c4eb5da7690690b0a8b7
>
> in testcase: will-it-scale
>
xploit" }, { dfd = -100, filename = "", flags = (
"O_RDONLY" : container = 0 ), mode = ( : container = 0 ) }
[16:58:51.229348988] (+0.06260) compudjdev syscall_exit_openat: { cpu_id =
22 }, { procname = "exploit" }, { ret = -14 }
Thanks,
Mathieu
Project
xploit" }, { dfd = -100, filename = "", flags = (
"O_RDONLY" : container = 0 ), mode = ( : container = 0 ) }
[16:58:51.229348988] (+0.06260) compudjdev syscall_exit_openat: { cpu_id =
22 }, { procname = "exploit" }, { ret = -14 }
Thanks,
Mathieu
Project
- On Sep 24, 2020, at 1:25 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> Please find the following membarrier updates series posted as RFC.
Hi Peter,
I did not get any feedback on this round of RFC. Is it because it is perfect,
or because it is abysmally wrong ? :)
If i
- On Sep 28, 2020, at 11:13 AM, Florian Weimer fwei...@redhat.com wrote:
> * Mathieu Desnoyers:
>
>> Upstreaming efforts aiming to integrate rseq support into glibc led to
>> interesting discussions, where we identified a clear need to extend the
>> size of the per
,
Packaging is a commercial service offered by EfficiOS to its customers. We
then publish the packages to all interested parties.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
___
lttng-dev mailing list
lttng-dev@lists.ltt
uot;trace_enabled()" instead of "tracepoint_enabled()"
> >(Mathieu Desnoyers reported)
> >
> > - Reworded to include comments about bloating the kernel when tracepoints
> >are used in commonly used inlined functions.
> >
> > - Added the ms
since the last round are updates to the selftests.
Thanks,
Mathieu
Mathieu Desnoyers (2):
ipv4/icmp: l3mdev: Perform icmp error route lookup on source device
routing table (v2)
ipv6/icmp: l3mdev: Perform icmp error route lookup on source device
routing table (v2)
Michael Jeanson (1
1a6c4ea43e ("net: icmp_route_lookup should use rt dev to determine L3
domain")
Link: https://tools.ietf.org/html/rfc792
Signed-off-by: Mathieu Desnoyers
Cc: David Ahern
Cc: David S. Miller
Cc: net...@vger.kernel.org
---
Changes since v1:
- Introduce icmp_get_route_lookup_dev.
. ]
[ Testing shows that similar issues exist with ipv6 unreachable /
fragmentation needed messages. However, investigation of this
additional failure mode is beyond this investigation's scope. ]
Link: https://tools.ietf.org/html/rfc4443
Signed-off-by: Mathieu Desnoyers
Cc: David Ahern
Cc
From: Michael Jeanson
The objective of the tests is to check that ICMP errors generated while
crossing between VRFs are properly routed back to the source host.
The first ttl test sends a ping with a ttl of 1 from h1 to h2 and parses the
output of the command to check that a ttl expired error
to be performed by
glibc through use of clone3 CLONE_RSEQ_KTLS.
Signed-off-by: Mathieu Desnoyers
Cc: Carlos O'Donell
Cc: "Florian Weimer
Cc: Peter Zijlstra (Intel)
Cc: "Paul E. McKenney"
Cc: Boqun Feng
---
tools/testing/selftests/rseq/rseq-x86.h | 8 ++
tools/testing/selfte
his appear as new
system calls instead ?
Signed-off-by: Mathieu Desnoyers
Cc: Carlos O'Donell
Cc: "Florian Weimer
Cc: Peter Zijlstra (Intel)
Cc: "Paul E. McKenney"
Cc: Boqun Feng
---
arch/x86/kernel/process_64.c | 1 +
include/linux/sched.h| 122 +---
- On Sep 25, 2020, at 12:26 PM, rostedt rost...@goodmis.org wrote:
> On Fri, 25 Sep 2020 11:30:06 -0400 (EDT)
> Mathieu Desnoyers wrote:
>
>> > Anyway, I don't see any issues with the current patch set as is
>> > (besides the documentation fix, whic
- On Sep 25, 2020, at 11:14 AM, rostedt rost...@goodmis.org wrote:
> On Fri, 25 Sep 2020 10:41:56 -0400 (EDT)
> Mathieu Desnoyers wrote:
>
>> With the current dependencies of tracepoint.h, I would argue that we should
>> only do the trampoline work-a
- On Sep 24, 2020, at 4:33 PM, rostedt rost...@goodmis.org wrote:
> On Thu, 24 Sep 2020 16:27:34 -0400 (EDT)
> Mathieu Desnoyers wrote:
>
>> I'd be a bit more specific: so far, the msr.h use-case requires to include
>> directly tracepoint-defs.h and use a tracepoint_en
- On Sep 24, 2020, at 4:13 PM, rostedt rost...@goodmis.org wrote:
> On Thu, 24 Sep 2020 16:05:35 -0400 (EDT)
> Mathieu Desnoyers wrote:
>
>> If headers which happens to be included by include/trace/events/ headers are
>> the issue, and they happen to only be needed b
racepoint.h from include/linux/page_ref.h
and did not notice any compile issue. Am I missing something
to trigger an issue related to that scenario ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Sep 24, 2020, at 3:35 PM, rostedt rost...@goodmis.org wrote:
> On Thu, 24 Sep 2020 15:08:30 -0400 (EDT)
> Mathieu Desnoyers wrote:
>
>> - On Sep 24, 2020, at 2:30 PM, rostedt rost...@goodmis.org wrote:
>>
>> > On Thu, 24 Sep 2020 13:42:25 -0400 (EDT)
- On Sep 24, 2020, at 2:30 PM, rostedt rost...@goodmis.org wrote:
> On Thu, 24 Sep 2020 13:42:25 -0400 (EDT)
> Mathieu Desnoyers wrote:
>
>> > Signed-off-by: Steven Rostedt (VMware)
>> > ---
>> > Documentation/trace/tracepoints.rst | 25 +
- On Sep 24, 2020, at 2:19 PM, Axel Rasmussen axelrasmus...@google.com
wrote:
> On Thu, Sep 24, 2020 at 10:42 AM Mathieu Desnoyers
> wrote:
>>
>> - On Sep 24, 2020, at 1:09 PM, rostedt rost...@goodmis.org wrote:
>>
>> > From: "Steven Roste
oo_enabled() is not.
> + */
> +#define DECLARE_TRACEPOINT(tp) \
> + extern struct tracepoint __tracepoint_##tp
> +
> +#ifdef CONFIG_TRACEPOINTS
> +# define tracepoint_enabled(tp) \
> + static_key_false(&(__tracepoint_##tp).key)
> +#else
> +# define tracepoint_enabled(tracepoint) false
> +#endif
> +
> #endif
> --
> 2.28.0
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
m is NULL
r2 = load x
BUG_ON(r1 == 1 && r2 == 0)
Signed-off-by: Mathieu Desnoyers
Cc: Peter Zijlstra (Intel)
Cc: Boqun Feng
Cc: Will Deacon
Cc: Paul E. McKenney
Cc: Nicholas Piggin
Cc: Andy Lutomirski
Cc: Thomas Gleixner
Cc: Linus Torvalds
Cc: Alan
Document membarrier ordering scenarios in membarrier.c. Thanks to Alan
Stern for refreshing my memory. Now that I have those in mind, it seems
appropriate to serialize them to comments for posterity.
Signed-off-by: Mathieu Desnoyers
Cc: Peter Zijlstra (Intel)
Cc: Boqun Feng
Cc: Will Deacon
Cc
Please find the following membarrier updates series posted as RFC.
Feedback is welcome,
Thanks,
Mathieu
Mathieu Desnoyers (3):
sched: fix exit_mm vs membarrier (v3)
sched: membarrier: cover kthread_use_mm (v3)
sched: membarrier: document memory ordering scenarios
include/linux/sched
.
Signed-off-by: Mathieu Desnoyers
Cc: Peter Zijlstra (Intel)
Cc: Boqun Feng
Cc: Will Deacon
Cc: Paul E. McKenney
Cc: Nicholas Piggin
Cc: Andy Lutomirski
Cc: Andrew Morton
---
Changes since v1:
- Add WARN_ON_ONCE(current->mm) in play_idle_precise (PeterZ),
- Use smp_mb__after_spinlock rat
- On Aug 24, 2020, at 10:06 PM, Boqun Feng boqun.f...@gmail.com wrote:
> On Mon, Aug 24, 2020 at 11:27:49AM -0400, Mathieu Desnoyers wrote:
>> - On Aug 16, 2020, at 11:29 AM, Boqun Feng boqun.f...@gmail.com wrote:
>>
>> > On Fri, Aug 14, 2020 at 12:43:57PM -0400,
- On Aug 16, 2020, at 11:23 AM, Boqun Feng boqun.f...@gmail.com wrote:
> Hi Mathieu,
>
> On Fri, Aug 14, 2020 at 12:43:56PM -0400, Mathieu Desnoyers wrote:
>> exit_mm should issue memory barriers after user-space memory accesses,
>> before clearing current->mm, to
- On Sep 24, 2020, at 9:33 AM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> - On Sep 23, 2020, at 7:36 PM, Peter Oskolkov p...@google.com wrote:
>
> The patch title should state that it only adds rseq_offset_deref_addv
> to x86-64. Considering that other
, restarting
> a potentially active RSEQ critical section on the CPU.
>
Acked-by: Mathieu Desnoyers
For the next time, you should move the changelog below (vN->vN+1)
after a "---" line, which comes after all the Signed-off-by, acked-by
and others.
Thanks,
Mathieu
> v1->v2:
&g
gt; printf("[-v] Verbose output.\n");
> printf("[-h] Show this help.\n");
> @@ -1268,6 +1484,7 @@ int main(int argc, char **argv)
> case 'i':
> case 'b':
> case 'm':
> + case 'r':
> break;
> default:
> show_usage(argc, argv);
> @@ -1320,6 +1537,10 @@ int main(int argc, char **argv)
> printf_verbose("counter increment\n");
> test_percpu_inc();
> break;
> + case 'r':
> + printf_verbose("membarrier\n");
> + test_membarrier();
> + break;
> }
> if (!opt_disable_rseq && rseq_unregister_current_thread())
> abort();
> diff --git a/tools/testing/selftests/rseq/run_param_test.sh
> b/tools/testing/selftests/rseq/run_param_test.sh
> index e426304fd4a0..f51bc83c9e41 100755
> --- a/tools/testing/selftests/rseq/run_param_test.sh
> +++ b/tools/testing/selftests/rseq/run_param_test.sh
> @@ -15,6 +15,7 @@ TEST_LIST=(
> "-T m"
> "-T m -M"
> "-T i"
> + "-T r"
> )
>
> TEST_NAME=(
> @@ -25,6 +26,7 @@ TEST_NAME=(
> "memcpy"
> "memcpy with barrier"
> "increment"
> + "membarrier"
> )
> IFS="$OLDIFS"
>
> --
> 2.28.0.709.gb0816b6eb0-goog
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
+ );
> + return 0;
> +abort:
> + RSEQ_INJECT_FAILED
> + return -1;
> +#ifdef RSEQ_COMPARE_TWICE
> +error1:
> + rseq_bug("cpu_id comparison failed");
> +#endif
> +}
> +
> static inline __attribute__((always_inline))
> int rseq_cmpeqv_trystorev_storev(intptr_t *v, intptr_t expect,
>intptr_t *v2, intptr_t newv2,
> --
> 2.28.0.709.gb0816b6eb0-goog
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Sep 21, 2020, at 3:11 PM, David Ahern dsah...@gmail.com wrote:
> On 9/21/20 12:44 PM, Mathieu Desnoyers wrote:
>> - On Sep 21, 2020, at 2:36 PM, David Ahern dsah...@gmail.com wrote:
>>
>>> On 9/18/20 12:17 PM, Mathieu Desnoyers wrote:
>>>> Hi,
- On Sep 21, 2020, at 2:36 PM, David Ahern dsah...@gmail.com wrote:
> On 9/18/20 12:17 PM, Mathieu Desnoyers wrote:
>> Hi,
>>
>> Here is an updated series of fixes for ipv4 and ipv6 which which ensure
>> the route lookup is performed on the right routing table in
Mathieu Desnoyers (2):
ipv4/icmp: l3mdev: Perform icmp error route lookup on source device
routing table (v2)
ipv6/icmp: l3mdev: Perform icmp error route lookup on source device
routing table (v2)
Michael Jeanson (1):
selftests: Add VRF icmp error route lookup test
net/ipv4/icmp.c
1a6c4ea43e ("net: icmp_route_lookup should use rt dev to determine L3
domain")
Link: https://tools.ietf.org/html/rfc792
Signed-off-by: Mathieu Desnoyers
Cc: David Ahern
Cc: David S. Miller
Cc: net...@vger.kernel.org
---
Changes since v1:
- Introduce icmp_get_route_lookup_dev.
From: Michael Jeanson
The objective is to check that the incoming vrf routing table is selected
to send an ICMP error back to the source. We test two scenarios: when the
ttl of a packet reaches 1 while it is forwarded between different vrfs
and when a packet is bigger than the mtu of the second
. ]
[ Testing shows that similar issues exist with ipv6 unreachable /
fragmentation needed messages. However, investigation of this
additional failure mode is beyond this investigation's scope. ]
Link: https://tools.ietf.org/html/rfc4443
Signed-off-by: Mathieu Desnoyers
Cc: David Ahern
Cc
> lttng-dev mailing list
> lttng-dev@lists.lttng.org
> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
> + "addq %[off], %%rbx\n\t"
> + /* get pv */
> + "movq (%%rbx), %%rcx\n\t"
> + /* *pv += inc */
> + "addq %[inc], (%%rcx)\n\t"
> + "2:\n\t"
> + RSEQ_INJECT_ASM(4)
> + RSEQ_ASM_DEFINE_ABORT(4, "", abort)
> + : /* gcc asm goto does not allow outputs */
> + : [cpu_id] "r" (cpu),
> + [rseq_abi]"r" (&__rseq_abi),
> + /* final store input */
> + [ptr] "m" (*ptr),
> + [off] "er" (off),
> + [inc] "er" (inc)
> + : "memory", "cc", "rax", "rbx", "rcx"
> + RSEQ_INJECT_CLOBBER
> + : abort
> +#ifdef RSEQ_COMPARE_TWICE
> + , error1
> +#endif
> + );
> + return 0;
> +abort:
> + RSEQ_INJECT_FAILED
> + return -1;
> +#ifdef RSEQ_COMPARE_TWICE
> +error1:
> + rseq_bug("cpu_id comparison failed");
> +#endif
> +}
> +
> static inline __attribute__((always_inline))
> int rseq_cmpeqv_trystorev_storev(intptr_t *v, intptr_t expect,
>intptr_t *v2, intptr_t newv2,
> --
> 2.28.0.618.gf4bc123cb7-goog
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
BUG_ON(flags != 0);
Usually BUG_ON() is really for utterly unrecoverable situations, which is not
the
case here. I am tempted to just use WARN_ON_ONCE(flags) instead to make dmesg
yell (once) if an unexpected flags parameter is received. This is not a
user-space
input, so it should never trigge
, int, flags)
>> case MEMBARRIER_CMD_REGISTER_GLOBAL_EXPEDITED:
>> return membarrier_register_global_expedited();
>> case MEMBARRIER_CMD_PRIVATE_EXPEDITED:
>> - return membarrier_private_expedited(0);
>> + return membarrier_private_expedited(0, cpu_id);
>> case MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED:
>> return membarrier_register_private_expedited(0);
>> case MEMBARRIER_CMD_PRIVATE_EXPEDITED_SYNC_CORE:
>> - return
>> membarrier_private_expedited(MEMBARRIER_FLAG_SYNC_CORE);
>> + return
>> membarrier_private_expedited(MEMBARRIER_FLAG_SYNC_CORE,
>> cpu_id);
>> case MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED_SYNC_CORE:
>> return
>> membarrier_register_private_expedited(MEMBARRIER_FLAG_SYNC_CORE);
>> + case MEMBARRIER_CMD_PRIVATE_EXPEDITED_RSEQ:
>> + return membarrier_private_expedited(MEMBARRIER_FLAG_RSEQ,
>> cpu_id);
>> + case MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED_RSEQ:
>> + return
>> membarrier_register_private_expedited(MEMBARRIER_FLAG_RSEQ);
>> default:
>> return -EINVAL;
>> }
>> --
>> 2.28.0.402.g5ffc5be6b7-goog
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Sep 2, 2020, at 10:53 PM, 熊毓华 wrote:
> Thanks，now I understand the tracking policy of lttng.
> And I want to know，do you have any plans for "exclusion set"?
Not at this point. None of our customers expressed interest in that feature so
far.
Thanks,
Mathieu
--
M
_RSEQ:
> + if (flags == 0)
> + return
> membarrier_private_expedited(MEMBARRIER_FLAG_RSEQ, -1);
> + if (flags == MEMBARRIER_CMD_FLAG_CPU)
> + return
> membarrier_private_expedited(MEMBARRIER_FLAG_RSEQ, cpu_id);
> + return -EINVAL;
and here we can just call:
return membarrier_private_expedited(MEMBARRIER_FLAG_RSEQ, cpu_id);
Thanks,
Mathieu
> + case MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED_RSEQ:
> + return
> membarrier_register_private_expedited(MEMBARRIER_FLAG_RSEQ);
> default:
> return -EINVAL;
> }
> --
> 2.28.0.297.g1956fa8f8d-goog
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Aug 20, 2020, at 1:42 PM, Peter Oskolkov p...@posk.io wrote:
> On Wed, Aug 12, 2020 at 12:44 PM Mathieu Desnoyers
> wrote:
>>
> [...]
>>
>> > One way of doing what you suggest is to allow some commands to be
>> > bitwise-ORed.
>>
- On Aug 16, 2020, at 11:29 AM, Boqun Feng boqun.f...@gmail.com wrote:
> On Fri, Aug 14, 2020 at 12:43:57PM -0400, Mathieu Desnoyers wrote:
>> Add comments and memory barrier to kthread_use_mm and kthread_unuse_mm
>> to allow the effect of membarrier(2) to apply to kthreads ac
- On Aug 16, 2020, at 3:09 AM, Hillf Danton hdan...@sina.com wrote:
> On Fri, 14 Aug 2020 12:43:57 -0400 Mathieu Desnoyers wrote:
>>
>> Given that no prior kthread use this guarantee and that it only affects
>> kthreads, adding this guarantee does not affect user-sp
ABI.
Refine the check in membarrier_global_expedited to exclude runqueues
running the idle thread rather than all kthreads from the IPI cpumask.
Signed-off-by: Mathieu Desnoyers
Cc: Peter Zijlstra (Intel)
Cc: Will Deacon
Cc: Paul E. McKenney
Cc: Nicholas Piggin
Cc: Andy Lutomirski
Cc: Andrew
Document membarrier ordering scenarios in membarrier.c. Thanks to Alan
Stern for refreshing my memory. Now that I have those in mind, it seems
appropriate to serialize them to comments for posterity.
Signed-off-by: Mathieu Desnoyers
Cc: Peter Zijlstra (Intel)
Cc: Will Deacon
Cc: Paul E
mm = NULL;
r1 = load y
membarrier()
skips CPU 0 (no IPI) because its current mm is NULL
r2 = load x
BUG_ON(r1 == 1 && r2 == 0)
Signed-off-by: Mathieu Desnoyers
Cc: Pete
Hi,
Please find those three changes based on our recent discussions about
interaction between membarrier and exit_mm and kthread_use_mm. I added
documentation of memory ordering scenarios to membarrier.c as well.
Thanks,
Mathieu
Mathieu Desnoyers (3):
sched: fix exit_mm vs membarrier (v2
- On Aug 12, 2020, at 5:43 PM, David S. Miller da...@davemloft.net wrote:
> From: Mathieu Desnoyers
> Date: Tue, 11 Aug 2020 15:50:02 -0400
>
>> @@ -465,6 +465,7 @@ static struct rtable *icmp_route_lookup(struct net *net,
>>
; + ret = rseq_cmpeqv_cmpeqv_storev(>data, prev,
> + >percpu_list_ptr,
> + (intptr_t)list_ptr, prev + 1, cpu);
> +#endif
Please don't special-case the implementation of a test per archit
- On Aug 12, 2020, at 2:48 PM, Peter Oskolkov p...@posk.io wrote:
> On Wed, Aug 12, 2020 at 11:30 AM Mathieu Desnoyers
> wrote:
>
> [...]
>
>> "flags" is there to allow extensibility without requiring to add new
>> membarrier commands for every change.
membarrier_private_expedited(MEMBARRIER_FLAG_SYNC_CORE,
>> -1);
>> case MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED_SYNC_CORE:
>> return
>> membarrier_register_private_expedited(MEMBARRIER_FLAG_SYNC_CORE);
>> - case MEMBARRIER_CMD_PRIVATE_EXPEDITED_RSEQ:
>> - return membarrier_private_expedited(MEMBARRIER_FLAG_RSEQ,
>> flags);
>> case MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED_RSEQ:
>> return
>> membarrier_register_private_expedited(MEMBARRIER_FLAG_RSEQ);
>> +
>> + case MEMBARRIER_CMD_PRIVATE_EXPEDITED:
>> + return membarrier_private_expedited(cflags, cpuid);
>> +
>> default:
>> return -EINVAL;
>> }
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
From: Michael Jeanson
The objective is to check that the incoming vrf routing table is selected
to send an ICMP error back to the source when the ttl of a packet reaches 1
while it is forwarded between different vrfs.
The first test sends a ping with a ttl of 1 from h1 to h2 and parses the
Hi,
Here is a series of fixes for ipv4 and ipv6 which which ensure the route
lookup is performed on the right routing table in VRF configurations.
It includes a test for both ipv4 and ipv6.
The series has been rebased on the net tree.
Thanks,
Mathieu
Mathieu Desnoyers (2):
ipv4/icmp
sending ICMPv6 error
messages. If no source device is set, fall-back on the destination
device routing table.
Link: https://tools.ietf.org/html/rfc4443
Signed-off-by: Mathieu Desnoyers
Cc: David Ahern
Cc: David S. Miller
Cc: net...@vger.kernel.org
---
net/ipv6/icmp.c | 15
ce device is set, fall-back on the destination
device routing table.
Fixes: 9d1a6c4ea43e ("net: icmp_route_lookup should use rt dev to determine L3
domain")
Link: https://tools.ietf.org/html/rfc792
Signed-off-by: Mathieu Desnoyers
Cc: David Ahern
Cc: David S. Miller
Cc: net...@vge
- On Aug 11, 2020, at 3:14 PM, David Ahern dsah...@gmail.com wrote:
> On 8/11/20 1:11 PM, Mathieu Desnoyers wrote:
>> One thing I am missing before this series can be considered for upstreaming
>> is an Acked-by of the 2 fixes for ipv4 and ipv6 from you, as maintainer
>&
missing before this series can be considered for upstreaming
is an Acked-by of the 2 fixes for ipv4 and ipv6 from you, as maintainer
of l3mdev, if you think the approach I am taking with those fixes makes sense.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Aug 7, 2020, at 2:47 PM, Peter Oskolkov p...@posk.io wrote:
> On Fri, Aug 7, 2020 at 11:25 AM Mathieu Desnoyers
> wrote:
>>
>> - On Aug 7, 2020, at 1:55 PM, Peter Oskolkov p...@posk.io wrote:
>>
>> > On Thu, Aug 6, 2020 at 5:27 PM Boqun
ctions.
AFAIU moving the atomic_load(>percpu_list_ptr) into the critical section
should entirely solve this and guarantee exclusive access to the old list
after the manager's rseq-fence. I wonder why this simpler approach is not
favored ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Aug 7, 2020, at 1:48 PM, Peter Oskolkov p...@posk.io wrote:
> On Thu, Aug 6, 2020 at 10:37 AM Mathieu Desnoyers
> wrote:
>>
[...]
>> Also, should this belong to the membarrier or the rseq system call ? It just
>> looks like the membarrier happens to imple
?
> Meanwhile, that are some advance list operation API:
> 1. list_first_entry
> 2. list_first_entry_or_null
> Is it possible to integrate these into current urcu?
> Thanks
> ___
> lttng-dev mailing list
> lttng-dev@lists.lttng.o
t_thread(...)
>> failed(%d):
>> %s\n",
>> +errno, strerror(errno));
>> +abort();
>> +}
>> +return NULL;
>> +}
>> +
>> +/* Test MEMBARRIER_CMD_PRIVATE_RESTART_RSEQ_ON_CPU membarrier command. */
>> +void test_membarrier(void)
>> +{
>> +struct test_membarrier_thread_args thread_args;
>> +pthread_t worker_threads[CPU_SETSIZE];
>> +pthread_t manager_thread;
>> +int i;
>> +
>> +thread_args.stop = 0;
>> +thread_args.percpu_list_ptr = 0;
>> +pthread_create(_thread, NULL,
>> + test_membarrier_manager_thread, _args);
>> +
>> +for (i = 0; i < CPU_SETSIZE; i++)
>> +pthread_create(_threads[i], NULL,
>> + test_membarrier_worker_thread, _args);
>> +
>> +for (i = 0; i < CPU_SETSIZE; i++)
>> +pthread_join(worker_threads[i], NULL);
>> +
>> +atomic_store(_args.stop, 1);
>> +pthread_join(manager_thread, NULL);
>> +}
>> +
>> int main(int argc, char **argv)
>> {
>> if (rseq_register_current_thread()) {
>> @@ -300,6 +479,8 @@ int main(int argc, char **argv)
>> test_percpu_spinlock();
>> printf("percpu_list\n");
>> test_percpu_list();
>> +printf("membarrier\n");
>> +test_membarrier();
>> if (rseq_unregister_current_thread()) {
>> fprintf(stderr, "Error: rseq_unregister_current_thread(...)
>> failed(%d): %s\n",
>> errno, strerror(errno));
>> --
>> 2.28.0.163.g6104cc2f0b6-goog
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
ly do.
If cpu >= 0, only IPI that CPU if the thread currently running has the same mm.
Also, should this belong to the membarrier or the rseq system call ? It just
looks like the membarrier happens to implement very similar things for barriers,
but arguably this is really about rseq. I wonder if we should expose this
through
rseq instead, even if we end up using membarrier code.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Aug 6, 2020, at 8:13 AM, Will Deacon w...@kernel.org wrote:
> On Wed, Aug 05, 2020 at 11:22:36AM -0400, Mathieu Desnoyers wrote:
>> - On Aug 5, 2020, at 6:59 AM, Peter Zijlstra pet...@infradead.org wrote:
>> > On Tue, Aug 04, 2020 at 07:01:53PM +0200, pet...@i
- On Aug 5, 2020, at 6:59 AM, Peter Zijlstra pet...@infradead.org wrote:
> On Tue, Aug 04, 2020 at 07:01:53PM +0200, pet...@infradead.org wrote:
>> On Tue, Aug 04, 2020 at 10:59:33AM -0400, Mathieu Desnoyers wrote:
>> > - On Aug 4, 2020, at 10:51 AM, Peter Zijlstra pe
- On Aug 4, 2020, at 12:51 PM, Peter Zijlstra pet...@infradead.org wrote:
> On Tue, Aug 04, 2020 at 10:48:41AM -0400, Mathieu Desnoyers wrote:
>> Here is the scenario I have in mind:
>
>> Userspace variables:
>>
>> int x = 0, y = 0;
>>
>&g
601 - 700 of 11948 matches
Mail list logo
