ses RCU tricks and is more complex, but
> can be an alternative if this solution becomes an issue.
>
> Link:
> https://lore.kernel.org/lkml/20210127170721.58bce...@gandalf.local.home/
> ]
>
> Cc: Peter Zijlstra
> Cc: Josh Poimboeuf
> Cc: Mathieu Desnoyers
> C
p the original version.
It works for me. Bonus points if you can document in a comment that this
trick depends on the cdecl calling convention.
Thanks,
Mathieu
>
> This way Alexei can't complain about adding a check in the fast path of
> more than one callback attached.
>
> -- Steve
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
llees prototypes are compatible at runtime when the actual
calls happen, this all works fine.
Thanks,
Mathieu
>
> -- Steve
>
>
> } while ((++it_func_ptr)->func);\
> return 0; \
> } \
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Nov 17, 2020, at 5:16 PM, rostedt rost...@goodmis.org wrote:
> On Tue, 17 Nov 2020 16:22:23 -0500 (EST)
> Mathieu Desnoyers wrote:
>
>> If we don't call the stub, then there is no point in having the stub at
>> all, and we should just compare to a constant
- On Nov 16, 2020, at 5:10 PM, rostedt rost...@goodmis.org wrote:
> On Mon, 16 Nov 2020 16:34:41 -0500 (EST)
> Mathieu Desnoyers wrote:
[...]
>> I think you'll want a WRITE_ONCE(old[i].func, tp_stub_func) here, matched
>> with a READ_ONCE() in __DO_TRACE. This int
he stub, then there is no point in having the stub at
all, and we should just compare to a constant value, e.g. 0x1UL. As far
as I can recall, comparing with a small immediate constant is more efficient
than comparing with a loaded value on many architectures.
Thanks,
Mathieu
--
Mathieu Desnoy
- On Nov 17, 2020, at 3:34 PM, rostedt rost...@goodmis.org wrote:
> On Tue, 17 Nov 2020 14:47:20 -0500 (EST)
> Mathieu Desnoyers wrote:
>
>> There seems to be more effect on the data size: adding the "stub_func" field
>> in struct tracepoint adds 8320 b
- On Nov 17, 2020, at 2:21 PM, rostedt rost...@goodmis.org wrote:
> On Tue, 17 Nov 2020 14:15:10 -0500 (EST)
> Mathieu Desnoyers wrote:
>
>
>> diff --git a/include/linux/tracepoint-defs.h
>> b/include/linux/tracepoint-defs.h
>> index e7c2276be33e..e0351b
+ .funcs = NULL, \
+ .stub_func = __tracepoint_stub_func_##_name, }; \
__TRACEPOINT_ENTRY(_name); \
int __traceiter_##_name(void *__data, proto)\
{ \
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
bug_print_probes(*funcs);
> return old;
> @@ -300,6 +312,10 @@ static int tracepoint_remove_func(struct tracepoint *tp,
> return PTR_ERR(old);
> }
>
> + if (tp_funcs == old)
> + /* Failed allocating new tp_funcs, replaced func with stub */
> + return 0;
> +
> if (!tp_funcs) {
> /* Removed last function */
> if (tp->unregfunc && static_key_enabled(&tp->key))
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Nov 16, 2020, at 3:44 PM, rostedt rost...@goodmis.org wrote:
> On Mon, 16 Nov 2020 15:37:27 -0500 (EST)
> Mathieu Desnoyers wrote:
>> >
>> > Mathieu,
>> >
>> > Can't we do something that would still allow to unregister a probe even if
>
at much about using slightly more memory
than required after a failed reallocation due to ENOMEM. Perhaps the irq work
is not even needed. Chances are that the irq work would fail again and again if
it's in low memory conditions. So maybe it's better to just keep the tombstone
in place u
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
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
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 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
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
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
- 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
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
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
- 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,
>>
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
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:
- 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
>&
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
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
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
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:
Adding IPv4/IPv6 maintainers in CC, along with David Ahern's k.org email
address.
- On Jul 20, 2020, at 6:11 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> As per RFC792, ICMP errors should be sent to the source host.
>
> However, in configurations with Virt
ttps://tools.ietf.org/html/rfc792
Signed-off-by: Mathieu Desnoyers
Cc: David Ahern
Cc: David S. Miller
Cc: netdev@vger.kernel.org
---
net/ipv4/icmp.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c
index e30515f89802..3d1da70c7293 100
p_md5_hash_key()")
> Commit e6ced831ef11 ("tcp: md5: refine tcp_md5_do_add()/tcp_md5_hash_key()
> barriers")
>
> Fixes: 721230326891 "tcp: md5: reject TCP_MD5SIG or TCP_MD5SIG_EXT on
> established sockets"
> Signed-off-by: Eric Dumaze
_md5_hash_key()")
> Signed-off-by: Eric Dumazet
> Cc: Mathieu Desnoyers
Reviewed-by: Mathieu Desnoyers
Thanks !
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
KCSAN reports,
> this can safely be removed in stable backports, if data_race() is
> not yet backported.
>
> Fixes: 6a2febec338d ("tcp: md5: add missing memory barriers in
> tcp_md5_do_add()/tcp_md5_hash_key()")
> Signed-off-by: Eric Dumazet
> Cc: Mathieu Desnoyers
= newkeylen;
>return 0;
>}
>
> @@ -1132,7 +1136,7 @@ int tcp_md5_do_add(struct sock *sk, const union
> tcp_md5_addr *addr,
>rcu_assign_pointer(tp->md5sig_info, md5sig);
>}
>
> - key = sock_kmalloc(sk, sizeof(*key), gfp);
> + key = sock_kmalloc(sk, sizeof(*key), gfp | __GFP_ZERO);
>if (!key)
>return -ENOMEM;
> if (!tcp_alloc_md5sig_pool()) {
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
keylen
>> > is changed, cpus in tcp_md5_hash_key() wont try to use
>> > uninitialized data, or crash because key->keylen was
>> > read twice to feed sg_init_one() and ahash_request_set_crypt()
>> >
>> > Fixes: 9ea88a153001 ("tcp: md5: c
- On Jun 30, 2020, at 8:34 PM, Eric Dumazet eduma...@google.com wrote:
> On Tue, Jun 30, 2020 at 5:27 PM Mathieu Desnoyers
> wrote:
>>
>> - On Jun 30, 2020, at 7:50 PM, Eric Dumazet eduma...@google.com wrote:
>>
>> > On Tue, Jun 30, 2020 at 4:47
- On Jun 30, 2020, at 7:50 PM, Eric Dumazet eduma...@google.com wrote:
> On Tue, Jun 30, 2020 at 4:47 PM Mathieu Desnoyers
> wrote:
>>
>> - On Jun 30, 2020, at 7:41 PM, Eric Dumazet eduma...@google.com wrote:
>>
>> > MD5 keys are read with RCU protection
t;
> Fixes: 9ea88a153001 ("tcp: md5: check md5 signature without socket lock")
> Signed-off-by: Eric Dumazet
> Cc: Mathieu Desnoyers
> ---
> net/ipv4/tcp.c | 7 +--
> net/ipv4/tcp_ipv4.c | 3 +++
> 2 files changed, 8 insertions(+), 2 deletions(-)
>
> d
> @@ -1113,6 +1113,9 @@ int tcp_md5_do_add(struct sock *sk, const union
> tcp_md5_addr *addr,
>if (key) {
>/* Pre-existing entry - just update that one. */
>memcpy(key->key, newkey, newkeylen);
> +
> + smp_wmb(); /* pairs with smp_rmb() in tcp_md5_hash_key() */
> +
>key->keylen = newkeylen;
>return 0;
> }
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
ases is do determine the behavior
> of all these stacks vs :
> SACK option
> TCP TS option.
I will ask my customer's networking team to investigate these behaviors,
which will allow me to prepare a thorough reply to the questions raised
by Eric and David. I expect to have an answer within 2-3 weeks at most.
Thank you!
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
x27;)
I'm helping a customer increase their contributions and feedback to upstream.
As we can see, they have accumulated some backlog over time.
Clearly reverting a security fix is not acceptable here. Coming up with a
proper ABI-compatible fix should not be out of our reach though.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
t exceeding the available space.
I welcome advice on what should be the end goal here.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On May 13, 2020, at 3:56 PM, Eric Dumazet eduma...@google.com wrote:
> On Wed, May 13, 2020 at 12:49 PM Eric Dumazet wrote:
>>
>>
>> On Wed, May 13, 2020 at 12:38 PM Mathieu Desnoyers
>> wrote:
>> >
>> > Hi,
>> >
>> > I am
as the resulting combination of options does not exceed the available
header space.
Can we please fix this KASAN report in a way that does not break user-space
applications expectations about Linux' implementation of RFC2385 ?
Thanks,
Mathieu
[1] RFC2385: https://tools.ietf.org/html/rfc2
y proposed patch. (I have not looked at the specifics
though, so I may be wrong.)
Do you have a preference between those two approaches, or perhaps you
have an alternative solution in mind ?
Thanks!
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Nov 12, 2018, at 3:46 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> - On Nov 12, 2018, at 3:40 PM, rostedt rost...@goodmis.org wrote:
>
>> On Mon, 12 Nov 2018 15:20:55 -0500 (EST)
>> Mathieu Desnoyers wrote:
>>
>>>
>>>
- On Nov 12, 2018, at 3:40 PM, rostedt rost...@goodmis.org wrote:
> On Mon, 12 Nov 2018 15:20:55 -0500 (EST)
> Mathieu Desnoyers wrote:
>
>>
>> Hrm, looking at this again, I notice that there is a single DEFINE_EVENT
>> using net_dev_template_simple.
- On Nov 12, 2018, at 3:20 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> - On Nov 12, 2018, at 3:09 PM, Mathieu Desnoyers
> mathieu.desnoy...@efficios.com wrote:
>
>> - On Nov 12, 2018, at 2:44 PM, Geneviève Bastien gbast...@versatic.net
>>
- On Nov 12, 2018, at 3:09 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> - On Nov 12, 2018, at 2:44 PM, Geneviève Bastien gbast...@versatic.net
> wrote:
>
>> Trace events are already present for the receive entry points, to indicate
>> how the recept
ge.
Also, I wonder if we should use "net_dev_template_exit" for the event
class rather than "net_dev_template_return" ?
Thanks,
Mathieu
>
> Signed-off-by: Geneviève Bastien
> CC: Mathieu Desnoyers
> CC: Steven Rostedt
> CC: Ingo Molnar
> CC: David S. Mil
, so I think
the use case justifies adding the missing "exit" events.
It might be great if you can provide a glimpse of the wakeup dependency chain
analysis prototypes you have created, which rely on this new event, in order
to justify adding it.
Thanks,
Mathieu
>
> Signed-of
es not run in user-space, so it would "work".
But the guarantees provided by membarrier are not to synchronize against
preempt off per se. It's just that the current implementation happens to
do that. The point of membarrier is to turn user-space memory barriers
into compiler barriers.
If what you need is to wait for a RCU grace period for whatever RCU flavor
ebpf is using, I would against using membarrier for this. I would rather
recommend adding a dedicated BPF_SYNCHRONIZE so you won't leak
implementation details to user-space, *and* you can eventually change you
RCU implementation for e.g. SRCU in the future if needed.
Thanks,
Mathieu
>
> thanks!
>
> - Joel
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
he funcs from the tracepoint structure like I posted.
>>
>> I very much prefer to land this v8 as-is and optimize later.
>>
>> I still have bpfilter/microkernel patches to finish which were
>> practically ready two weeks ago and got delayed but this set.
>
t; -- Steve
>
>
>> if (it_func_ptr) { \
> > do {\
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
de.
>> Also what it will address?
>
> 32bit bloat ;-)
>
> But I agree, it's not worth uglifying it.
>
> -- Steve
>
> > cache hot/cold argument clearly doesn't apply.
In the current situation I'm fine with adding this extra field
- On Mar 28, 2018, at 12:43 PM, Alexei Starovoitov a...@fb.com wrote:
> On 3/28/18 6:49 AM, Mathieu Desnoyers wrote:
>> - On Mar 27, 2018, at 10:11 PM, Alexei Starovoitov a...@fb.com wrote:
>>
>>> From: Alexei Starovoitov
>>>
>>> compute number
proto, args, print)\
> - DEFINE_TRACE(name)
> + DEFINE_TRACE(name, COUNT_ARGS(args))
>
> #undef DEFINE_EVENT_CONDITION
> #define DEFINE_EVENT_CONDITION(template, name, proto, args, cond) \
> @@ -64,7 +64,7 @@
>
> #undef DECLARE_TRACE
> #define DECLARE_TRACE(name, proto, args) \
> - DEFINE_TRACE(name)
> + DEFINE_TRACE(name, COUNT_ARGS(args))
>
> #undef TRACE_INCLUDE
> #undef __TRACE_INCLUDE
> --
> 2.9.5
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Mar 27, 2018, at 8:00 PM, Alexei Starovoitov a...@fb.com wrote:
> On 3/27/18 4:13 PM, Mathieu Desnoyers wrote:
>> - On Mar 27, 2018, at 6:48 PM, Alexei Starovoitov a...@fb.com wrote:
>>
>>> On 3/27/18 2:04 PM, Steven Rostedt wrote:
>>>>
>>
x380
>
> for some reason the start_bpf_raw_tp is off by 8.
> Not sure how it works for you.
>
> (gdb) p &__bpf_trace_tp_map_sys_exit
> $10 = (struct bpf_raw_event_map *) 0x84642440
> <__bpf_trace_tp_map_sys_exit>
>
> (gdb) p &__start__bpf_raw_tp
> $7 = ( *) 0xff
tra 8bytes * number_of_tracepoints just for lack of trust
>> in kallsyms doesn't sound like good trade off to me.
>> If kallsyms are inaccurate all sorts of things will break:
>> kprobes, livepatch, etc.
>> I'd rather suggest for ftrace to use kallsyms approach as
- On Mar 27, 2018, at 11:53 AM, Alexei Starovoitov a...@fb.com wrote:
> On 3/27/18 7:42 AM, Steven Rostedt wrote:
>> On Tue, 27 Mar 2018 10:18:24 -0400 (EDT)
>> Mathieu Desnoyers wrote:
>>
>>> - On Mar 27, 2018, at 10:07 AM, rostedt rost...@goodmis.org wrote
y name and later attach bpf probe to a tracepoint
>>
>> Signed-off-by: Alexei Starovoitov
>
> Reviewed-by: Steven Rostedt (VMware)
Steven showed preference for tracepoint_kernel_find_by_name() at some
point (starting with a tracepoint_ prefix). I'm find with either of
the n
some maintainers refuse to add them.
Since when has it become accepted to push commits into maintainer's
subsystems without their acknowledgment first ?
The minefield you are currently walking through appears to be of your
own making, so please just rework your initial patch before it reaches
upstream.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
fore submitting a patch involving tracepoints.
But this patch should not even be needed in the first place, because it
partially reverts changes that were introduced in the bpf-next tree without
any Acked-by from the tracing maintainers. I don't see any need to obfuscate
the git log of tr
ts associated changelog is fine
with me. Please submit it as a separate commit from the rest
of the tracepoint.{c,h} changes.
[...]
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
on: what are Alexei's plan to handle tracepoints
in modules, considering module load/unload scenarios ? The tracepoint API
has module notifiers for this, but it does not appear to be used in this
patch series.
Thanks,
Mathieu
>
> -- Steve
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Mar 26, 2018, at 12:08 PM, Alexei Starovoitov a...@fb.com wrote:
> On 3/26/18 8:55 AM, Mathieu Desnoyers wrote:
>> - On Mar 26, 2018, at 11:42 AM, Alexei Starovoitov a...@fb.com wrote:
>>
>>> On 3/26/18 8:14 AM, Mathieu Desnoyers wrote:
>>>>
- On Mar 26, 2018, at 11:42 AM, Alexei Starovoitov a...@fb.com wrote:
> On 3/26/18 8:14 AM, Mathieu Desnoyers wrote:
>> - On Mar 26, 2018, at 11:02 AM, rostedt rost...@goodmis.org wrote:
>>
>>> On Fri, 23 Mar 2018 19:30:34 -0700
>>> Alexei Starovoi
;> *priv),
>> + void *priv)
>> {
>> struct tracepoint * const *iter;
>> +void *ret;
>>
>> if (!begin)
>> -return;
>> -for (iter = begin; iter < end; iter++)
>> -fct(*iter, priv);
>> +return NULL;
>> +for (iter = begin; iter < end; iter++) {
>> +ret = fct(*iter, priv);
>> +if (ret)
>> +return ret;
>> +}
>> +return NULL;
>> }
>>
>> /**
>> @@ -520,11 +525,11 @@ static void for_each_tracepoint_range(struct
>> tracepoint *
>> const *begin,
>> * @fct: callback
>> * @priv: private data
>> */
>> -void for_each_kernel_tracepoint(void (*fct)(struct tracepoint *tp, void
>> *priv),
>> -void *priv)
>> +void *for_each_kernel_tracepoint(void *(*fct)(struct tracepoint *tp, void
>> *priv),
>> + void *priv)
>> {
>> -for_each_tracepoint_range(__start___tracepoints_ptrs,
>> -__stop___tracepoints_ptrs, fct, priv);
>> +return for_each_tracepoint_range(__start___tracepoints_ptrs,
>> + __stop___tracepoints_ptrs, fct, priv);
>> }
>> EXPORT_SYMBOL_GPL(for_each_kernel_tracepoint);
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Feb 17, 2016, at 7:47 AM, Phil Sutter p...@nwl.cc wrote:
> Hi,
>
> On Tue, Feb 16, 2016 at 07:56:23PM -0500, Mathieu Desnoyers wrote:
>> This reverts commit 348e3435cbefa815bd56a5205c1412b5afe7b92e.
>> It breaks HTB classful qdiscs on the loopback interface.
>
limits to ${limit}kbits, ${ctrlportlimit} for
control and ${dataportlimit} for data"
}
function reset_bw_limit
{
tc qdisc del dev $DEFAULT_IF root
echo "Reset bandwith limits"
}
trap reset_bw_limit SIGINT SIGTERM
set_bw_limit 3200
sleep 1
ping localhost
Signed-
Network core events.
Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
CC: netdev@vger.kernel.org
---
net/core/dev.c |5 +
net/ipv4/devinet.c |5 +
net/socket.c | 18 ++
3 files changed, 28 insertions(+)
Index: linux-2.6-lttng/net/core
Network core events.
Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
CC: netdev@vger.kernel.org
---
net/core/dev.c |5 +
net/ipv4/devinet.c |5 +
net/socket.c | 18 ++
3 files changed, 28 insertions(+)
Index: linux-2.6-lttng/net/core
* Oleg Nesterov ([EMAIL PROTECTED]) wrote:
> On 10/12, Andrew Morton wrote:
> >
> > On Fri, 12 Oct 2007 15:47:59 -0400
> > Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
> >
> > > Hi Andrew,
> > >
> > > I noticed a regression between 2.
84 matches
Mail list logo
