state.
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_spinloc
current mm 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
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,
>>>
>>> FYI,
nicely as an extension of my KTLS prototype (extensible
rseq):
https://lore.kernel.org/lkml/20200925181518.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
nicely as an extension of my KTLS prototype (extensible
rseq):
https://lore.kernel.org/lkml/20200925181518.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
nicely as an extension of my KTLS prototype (extensible
rseq):
https://lore.kernel.org/lkml/20200925181518.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
/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
e 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
e 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 is
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 is
e. ]
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
Reviewed-by: David Ahern
Cc: David Ahern
Cc: Jakub Kicinski
Cc: David S. Miller
Cc: netdev@vger.ker
s investigation. ]
[ 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
Revi
e. ]
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
Reviewed-by: David Ahern
Cc: David Ahern
Cc: Jakub Kicinski
Cc: David S. Miller
Cc: net...@vger.ker
s investigation. ]
[ 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
Revi
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
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
- 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
alidate 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 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
>
ll_entry_openat: { cpu_id =
22 }, { procname = "exploit" }, { 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 = "ex
ll_entry_openat: { cpu_id =
22 }, { procname = "exploit" }, { 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 = "ex
- 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
ckaging 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
Fixed using "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.
> >
> >
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
e. ]
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: netdev@vger.kernel.org
---
Changes since v1:
- Introduce icmp_get_ro
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
e. ]
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...@vger.kernel.org
---
Changes since v1:
- Introduce icmp_get_ro
s investigation. ]
[ 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
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 is
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 is
s investigation. ]
[ 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
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/s
hould this 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, which
- 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-around for ca
- 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 tracepoi
- 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
ing tracepoint.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 Rostedt (
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
current mm 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
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
state.
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_spinloc
- 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
intf("[-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,
&g
- 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,
&g
- 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
- 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
e. ]
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: netdev@vger.kernel.org
---
Changes since v1:
- Introduce icmp_get_ro
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
s investigation. ]
[ 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
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 i
e. ]
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...@vger.kernel.org
---
Changes since v1:
- Introduce icmp_get_ro
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 i
s investigation. ]
[ 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
> 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
RSEQ_COMPARE_TWICE
> + RSEQ_ASM_CMP_CPU_ID(cpu_id, RSEQ_CPU_ID_OFFSET(%[rseq_abi]),
> %l[error1])
> +#endif
> + /* get p+v */
> + "movq %[ptr], %%rbx\n\t"
> + "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 neve
;> @@ -362,13 +438,17 @@ SYSCALL_DEFINE2(membarrier, int, cmd, 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
se MEMBARRIER_CMD_PRIVATE_EXPEDITED_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:
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,
>>
- 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,
>>
ial-case the implementation of a test per architecture.
We should instead "skip" (or even fail) the test on architectures that do
not support this, as an incentive for architecture maintainers to implement
the missing APIs in the test.
One way to do this would be to define RSEQ_ARCH_HAS_OFFSET_DEREF_ADDV in the
architecture header, and skip the test if the define is not present.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- 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.
return
>> 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
outpu
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
ting table when 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/ic
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
outpu
If no source 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:
ting table when 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: netdev@vger.kernel.org
---
net/ipv6/ic
If no source 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:
701 - 800 of 9486 matches
Mail list logo
