Re: [PATCH] perf sched: fix wrong conversion of task state

On 7/27/16 9:10 PM, Tomoki Sekiyama wrote: But that means we cannot handle preemption correctly as far as sched:sched_switch event uses TASK_STATE_MAX to mark preempted tasks. Should we stop using TASK_STATE_MAX for preempted tasks in ftrace and use (1 << 63) or something that doesn't change on

Re: [PATCH v2] perf sched: fix wrong conversion of task state

. you reference fixing the order of XZ as well. Signed-off-by: Tomoki Sekiyama <tomoki.sekiyama...@hitachi.com> Cc: Jiri Olsa <jo...@kernel.org> Cc: David Ahern <dsah...@gmail.com> Cc: Namhyung Kim <namhy...@kernel.org> Cc: Peter Zijlstra <a.p.zijls...@chello.nl&g

Re: [PATCH v2] perf sched: fix wrong conversion of task state

. you reference fixing the order of XZ as well. Signed-off-by: Tomoki Sekiyama Cc: Jiri Olsa Cc: David Ahern Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Masami Hiramatsu --- tools/perf/builtin-sched.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/tools/perf

Re: [PATCH] perf sched: fix wrong conversion of task state

On 7/27/16 9:58 AM, 関山友輝 / SEKIYAMA，TOMOKI wrote: diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c index 0dfe8df..eb2f7f4 100644 --- a/tools/perf/builtin-sched.c +++ b/tools/perf/builtin-sched.c @@ -71,6 +71,7 @@ struct sched_atom { }; #define TASK_STATE_TO_CHAR_STR

Re: [PATCH] perf sched: fix wrong conversion of task state

On 7/27/16 9:58 AM, 関山友輝 / SEKIYAMA，TOMOKI wrote: diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c index 0dfe8df..eb2f7f4 100644 --- a/tools/perf/builtin-sched.c +++ b/tools/perf/builtin-sched.c @@ -71,6 +71,7 @@ struct sched_atom { }; #define TASK_STATE_TO_CHAR_STR

Re: [PATCH] perf sched: fix wrong conversion of task state

sa <jo...@kernel.org> Cc: David Ahern <dsah...@gmail.com> Cc: Namhyung Kim <namhy...@kernel.org> Cc: Peter Zijlstra <a.p.zijls...@chello.nl> Cc: Masami Hiramatsu <mhira...@kernel.org> --- tools/perf/builtin-sched.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion

Re: [PATCH] perf sched: fix wrong conversion of task state

On 7/27/16 6:54 AM, Tomoki Sekiyama wrote: sched_out_state() converts the prev_state u64 bitmask to a char in a wrong way, which may cause wrong results of 'perf sched latency'. This patch fixes the conversion. Signed-off-by: Tomoki Sekiyama Cc: Jiri Olsa Cc: David Ahern Cc: Namhyung Kim Cc

Re: [BUG] perf test 29 crashing

On 6/30/16 10:18 AM, Jiri Olsa wrote: it was the setup in my .perfconfig: [call-graph] threshold=10 caused some of the callchains to disappear and screw the test, Did you find out why it caused a segfault? I think we should make that test using default values, like in attached patch

Re: [BUG] perf test 29 crashing

On 6/30/16 10:18 AM, Jiri Olsa wrote: it was the setup in my .perfconfig: [call-graph] threshold=10 caused some of the callchains to disappear and screw the test, Did you find out why it caused a segfault? I think we should make that test using default values, like in attached patch

Re: [BUG] perf test 29 crashing

On 6/28/16 10:59 AM, Arnaldo Carvalho de Melo wrote: Em Tue, Jun 28, 2016 at 02:34:10PM +0200, Jiri Olsa escreveu: hi, I'm having test 29 crashing on latest Arnaldo's perf/core: [jolsa@krava perf]$ ./perf test hist 15: Test matching and linking multiple hists : Ok 25: Test

Re: [BUG] perf test 29 crashing

On 6/28/16 10:59 AM, Arnaldo Carvalho de Melo wrote: Em Tue, Jun 28, 2016 at 02:34:10PM +0200, Jiri Olsa escreveu: hi, I'm having test 29 crashing on latest Arnaldo's perf/core: [jolsa@krava perf]$ ./perf test hist 15: Test matching and linking multiple hists : Ok 25: Test

chain_key collision with 4.7.0-rec2+

Peter/Ingo: I have this hit many times over the past few weeks, but I do not have a reliable reproducer to attempt a git bisect. There 2 dumps below I hit last night within a few minutes of each other (reboot in between). First dump is for ipv4 (first login to VM after boot) and second dump

chain_key collision with 4.7.0-rec2+

Peter/Ingo: I have this hit many times over the past few weeks, but I do not have a reliable reproducer to attempt a git bisect. There 2 dumps below I hit last night within a few minutes of each other (reboot in between). First dump is for ipv4 (first login to VM after boot) and second dump

Re: chain_key collision with 4.7.0-rec2+

On 6/21/16 7:13 AM, Peter Zijlstra wrote: Plz as to not wrap dmesg output when pasting not wrapped on my end -- the copy in Send folder in or the ouptut in your response. IPv4 one: [ 189.171084] == [ 189.171555] [chain_key collision ] [ 189.172020] 4.7.0-rc2+

Re: chain_key collision with 4.7.0-rec2+

On 6/21/16 7:13 AM, Peter Zijlstra wrote: Plz as to not wrap dmesg output when pasting not wrapped on my end -- the copy in Send folder in or the ouptut in your response. IPv4 one: [ 189.171084] == [ 189.171555] [chain_key collision ] [ 189.172020] 4.7.0-rc2+

Re: [PATCH] net: vrf: replace hard tab with space in assignment

ackham <chris.pack...@alliedtelesis.co.nz> --- drivers/net/vrf.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Acked-by: David Ahern <d...@cumulusnetworks.com>

Re: [PATCH] net: vrf: replace hard tab with space in assignment

ackham --- drivers/net/vrf.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Acked-by: David Ahern

Re: [PATCH 2/2] perf record: Add --dry-run option to check cmdline options

On 6/20/16 8:02 PM, Namhyung Kim wrote: On Tue, Jun 21, 2016 at 3:13 AM, Arnaldo Carvalho de Melo wrote: Em Mon, Jun 20, 2016 at 09:22:11AM -0700, Alexei Starovoitov escreveu: On Mon, Jun 20, 2016 at 11:38:18AM -0300, Arnaldo Carvalho de Melo wrote: Doing: perf bcc -c

Re: [PATCH 2/2] perf record: Add --dry-run option to check cmdline options

On 6/20/16 8:02 PM, Namhyung Kim wrote: On Tue, Jun 21, 2016 at 3:13 AM, Arnaldo Carvalho de Melo wrote: Em Mon, Jun 20, 2016 at 09:22:11AM -0700, Alexei Starovoitov escreveu: On Mon, Jun 20, 2016 at 11:38:18AM -0300, Arnaldo Carvalho de Melo wrote: Doing: perf bcc -c foo.c Looks

Re: [PATCH 2/2] perf record: Add --dry-run option to check cmdline options

On 6/20/16 12:13 PM, Arnaldo Carvalho de Melo wrote: 'perf cc' seems sensible, and has the added bonus of being one letter shorter :-) perf is now a general front-end to a compiler?

Re: [PATCH 2/2] perf record: Add --dry-run option to check cmdline options

On 6/20/16 12:13 PM, Arnaldo Carvalho de Melo wrote: 'perf cc' seems sensible, and has the added bonus of being one letter shorter :-) perf is now a general front-end to a compiler?

Re: [PATCH v4 1/6] perf tools: Set buildid dir under symfs when --symfs is provided

| 23 +++ tools/perf/util/symbol.h | 2 ++ 8 files changed, 41 insertions(+), 13 deletions(-) Acked-by: David Ahern <dsah...@gmail.com>

Re: [PATCH v4 1/6] perf tools: Set buildid dir under symfs when --symfs is provided

/util/symbol.h | 2 ++ 8 files changed, 41 insertions(+), 13 deletions(-) Acked-by: David Ahern

Re: [PATCH v3 3/7 UPDATE] perf tools: Add option for the path of buildid dsos under symfs

On 5/17/16 8:48 PM, Hekuang wrote: I don't understand why dso-prefix option is needed? Why make me type yet more options to the analysis command? Why can't the directory be located under the symfs tree in a known location and populated the same way it is without symfs? Because the default

Re: [PATCH v3 3/7 UPDATE] perf tools: Add option for the path of buildid dsos under symfs

On 5/17/16 8:48 PM, Hekuang wrote: I don't understand why dso-prefix option is needed? Why make me type yet more options to the analysis command? Why can't the directory be located under the symfs tree in a known location and populated the same way it is without symfs? Because the default

Re: [PATCH v3 3/7 UPDATE] perf tools: Add option for the path of buildid dsos under symfs

On 5/17/16 7:47 PM, Hekuang wrote: 在 2016/5/16 10:50, David Ahern 写道: On 5/15/16 7:30 PM, Hekuang wrote: In previous patch, I use 'perf buildid-cache -a' to add vdso binary into the HOST buildid dir. So 'perf buildid-cache' needs the symfs option? With this patch 'PATCH v3 3/7 UPDATE

Re: [PATCH v3 3/7 UPDATE] perf tools: Add option for the path of buildid dsos under symfs

On 5/17/16 7:47 PM, Hekuang wrote: 在 2016/5/16 10:50, David Ahern 写道: On 5/15/16 7:30 PM, Hekuang wrote: In previous patch, I use 'perf buildid-cache -a' to add vdso binary into the HOST buildid dir. So 'perf buildid-cache' needs the symfs option? With this patch 'PATCH v3 3/7 UPDATE

Re: [PATCH v3 3/7 UPDATE] perf tools: Add option for the path of buildid dsos under symfs

On 5/15/16 7:30 PM, Hekuang wrote: In previous patch, I use 'perf buildid-cache -a' to add vdso binary into the HOST buildid dir. So 'perf buildid-cache' needs the symfs option?

Re: [PATCH v3 3/7 UPDATE] perf tools: Add option for the path of buildid dsos under symfs

On 5/15/16 7:30 PM, Hekuang wrote: In previous patch, I use 'perf buildid-cache -a' to add vdso binary into the HOST buildid dir. So 'perf buildid-cache' needs the symfs option?

Re: [PATCH v3 3/7 UPDATE] perf tools: Add option for the path of buildid dsos under symfs

On 5/14/16 2:19 AM, He Kuang wrote: In the cross-platform perf record/script scenario, we need vdsos in buildid-cache dir and other libs in symfs dir at the same time. For the reason that to have every single file opened by perf is relative to symfs dirctory, perf skips the buildid dir if symfs

Re: [PATCH v3 3/7 UPDATE] perf tools: Add option for the path of buildid dsos under symfs

On 5/14/16 2:19 AM, He Kuang wrote: In the cross-platform perf record/script scenario, we need vdsos in buildid-cache dir and other libs in symfs dir at the same time. For the reason that to have every single file opened by perf is relative to symfs dirctory, perf skips the buildid dir if symfs

Re: [PATCH v3 3/7] perf tools: Remove the logical that skip buildid cache if symfs is given

On 5/13/16 1:19 AM, Hekuang wrote: What about putting the build id cache under the symfs? so instead of dropping the symfs check and it to the path for the build id cache. I think your intention is to reference symbol files in one place instead of two. So there're two possible approaches, one

Re: [PATCH v3 3/7] perf tools: Remove the logical that skip buildid cache if symfs is given

On 5/13/16 1:19 AM, Hekuang wrote: What about putting the build id cache under the symfs? so instead of dropping the symfs check and it to the path for the build id cache. I think your intention is to reference symbol files in one place instead of two. So there're two possible approaches, one

Re: [PATCH v3 3/7] perf tools: Remove the logical that skip buildid cache if symfs is given

On 5/12/16 7:09 AM, Arnaldo Carvalho de Melo wrote: Em Thu, May 12, 2016 at 08:43:12AM +, He Kuang escreveu: Symfs dir and buildid dir are two places that perf looks into for symbols, currently, if symfs dir is given, buildid-cache is skipped. In the cross-platform perf record/script

Re: [PATCH v3 3/7] perf tools: Remove the logical that skip buildid cache if symfs is given

On 5/12/16 7:09 AM, Arnaldo Carvalho de Melo wrote: Em Thu, May 12, 2016 at 08:43:12AM +, He Kuang escreveu: Symfs dir and buildid dir are two places that perf looks into for symbols, currently, if symfs dir is given, buildid-cache is skipped. In the cross-platform perf record/script

Re: [PATCH/RFC v3] perf core: Allow setting up max frame stack depth via sysctl

On 4/27/16 10:09 AM, Frederic Weisbecker wrote: I first thought that this should be a tunable per event instead of a global sysctl Yeah, I'll work on that too. There is no rush though. The sysfs limit will probably be enough for most users. Unless someone requested it? I have. I spent

Re: [PATCH/RFC v3] perf core: Allow setting up max frame stack depth via sysctl

On 4/27/16 10:09 AM, Frederic Weisbecker wrote: I first thought that this should be a tunable per event instead of a global sysctl Yeah, I'll work on that too. There is no rush though. The sysfs limit will probably be enough for most users. Unless someone requested it? I have. I spent

Re: [PATCH/RFC v3] perf core: Allow setting up max frame stack depth via sysctl

On 4/26/16 10:33 AM, Arnaldo Carvalho de Melo wrote: So, for completeness, further testing it to see how far it goes on a 8GB machine I got: [root@emilia ~]# echo 131100 > /proc/sys/kernel/perf_event_max_stack [root@emilia ~]# perf record -g ls Error: The sys_perf_event_open() syscall returned

Re: [PATCH/RFC v3] perf core: Allow setting up max frame stack depth via sysctl

On 4/26/16 10:33 AM, Arnaldo Carvalho de Melo wrote: So, for completeness, further testing it to see how far it goes on a 8GB machine I got: [root@emilia ~]# echo 131100 > /proc/sys/kernel/perf_event_max_stack [root@emilia ~]# perf record -g ls Error: The sys_perf_event_open() syscall returned

Re: [PATCH/RFC v2] perf core: Allow setting up max frame stack depth via sysctl

On 4/22/16 2:52 PM, Arnaldo Carvalho de Melo wrote: Em Wed, Apr 20, 2016 at 04:04:12PM -0700, Alexei Starovoitov escreveu: On Wed, Apr 20, 2016 at 07:47:30PM -0300, Arnaldo Carvalho de Melo wrote: Nice. I like it. That's a great approach to hard problem. Java guys will be happy too. Please

Re: [PATCH/RFC v2] perf core: Allow setting up max frame stack depth via sysctl

On 4/22/16 2:52 PM, Arnaldo Carvalho de Melo wrote: Em Wed, Apr 20, 2016 at 04:04:12PM -0700, Alexei Starovoitov escreveu: On Wed, Apr 20, 2016 at 07:47:30PM -0300, Arnaldo Carvalho de Melo wrote: Nice. I like it. That's a great approach to hard problem. Java guys will be happy too. Please

Re: [PATCH/RFC] perf core: Allow setting up max frame stack depth via sysctl

On 4/20/16 4:47 PM, Arnaldo Carvalho de Melo wrote: The new file is: # cat /proc/sys/kernel/perf_event_max_stack 127 Chaging it: # echo 256 > /proc/sys/kernel/perf_event_max_stack # cat /proc/sys/kernel/perf_event_max_stack 256 But as soon as there is some event using

Re: [PATCH/RFC] perf core: Allow setting up max frame stack depth via sysctl

On 4/20/16 4:47 PM, Arnaldo Carvalho de Melo wrote: The new file is: # cat /proc/sys/kernel/perf_event_max_stack 127 Chaging it: # echo 256 > /proc/sys/kernel/perf_event_max_stack # cat /proc/sys/kernel/perf_event_max_stack 256 But as soon as there is some event using

Re: [PATCH 17/19] perf tools: Build syscall table .c header from kernel's syscall_64.tbl

Upon further review ... On 4/7/16 2:58 PM, Arnaldo Carvalho de Melo wrote: From: Arnaldo Carvalho de Melo We used libaudit to map ids to syscall names and vice-versa, but that imposes a delay in supporting new syscalls, having to wait for libaudit to get those new syscalls on

Re: [PATCH 17/19] perf tools: Build syscall table .c header from kernel's syscall_64.tbl

Upon further review ... On 4/7/16 2:58 PM, Arnaldo Carvalho de Melo wrote: From: Arnaldo Carvalho de Melo We used libaudit to map ids to syscall names and vice-versa, but that imposes a delay in supporting new syscalls, having to wait for libaudit to get those new syscalls on its tables. To

Re: [PATCH 17/19] perf tools: Build syscall table .c header from kernel's syscall_64.tbl

On 4/7/16 2:58 PM, Arnaldo Carvalho de Melo wrote: We used libaudit to map ids to syscall names and vice-versa, but that imposes a delay in supporting new syscalls, having to wait for libaudit to get those new syscalls on its tables. and for the distribution to get the new libaudit. To

Re: [PATCH 17/19] perf tools: Build syscall table .c header from kernel's syscall_64.tbl

On 4/7/16 2:58 PM, Arnaldo Carvalho de Melo wrote: We used libaudit to map ids to syscall names and vice-versa, but that imposes a delay in supporting new syscalls, having to wait for libaudit to get those new syscalls on its tables. and for the distribution to get the new libaudit. To

Re: [PATCH] tools lib traceevent: Add '~' operation within arg_num_eval()

On 2/26/16 4:45 PM, David Ahern wrote: On 2/26/16 4:13 PM, Steven Rostedt wrote: When evaluating values for print flags, if the value included a '~' operator, the parsing would fail. This broke kmalloc's parsing of: __print_flags(REC->gfp_flags, "|", {(unsigned long)((( gfp

Re: [PATCH] tools lib traceevent: Add '~' operation within arg_num_eval()

On 2/26/16 4:45 PM, David Ahern wrote: On 2/26/16 4:13 PM, Steven Rostedt wrote: When evaluating values for print flags, if the value included a '~' operator, the parsing would fail. This broke kmalloc's parsing of: __print_flags(REC->gfp_flags, "|", {(unsigned long)((( gfp

Re: [REGRESSION, bisect] net: ipv6: unregister_netdevice: waiting for lo to become free. Usage count = 2

On 3/2/16 12:31 PM, Jeremiah Mahler wrote: On Tue, Mar 01, 2016 at 08:11:54AM +, Dexuan Cui wrote: Hi, I got this line every 10 seconds with today's linux-next in a Hyper-V guest, even when I didn't configure any NIC for the guest: [ 72.604249] unregister_netdevice: waiting for lo to

Re: [REGRESSION, bisect] net: ipv6: unregister_netdevice: waiting for lo to become free. Usage count = 2

On 3/2/16 12:31 PM, Jeremiah Mahler wrote: On Tue, Mar 01, 2016 at 08:11:54AM +, Dexuan Cui wrote: Hi, I got this line every 10 seconds with today's linux-next in a Hyper-V guest, even when I didn't configure any NIC for the guest: [ 72.604249] unregister_netdevice: waiting for lo to

Re: [lkp] [net] 21bb45b419: kmsg.unregister_netdevice:waiting_for_br-lan_to_become_free.Usage_count=

On 2/29/16 12:50 AM, kernel test robot wrote: FYI, we noticed the below changes on https://github.com/0day-ci/linux David-Ahern/net-ipv6-Make-address-flushing-on-ifdown-optional/20160214-062626 commit 21bb45b419243ee4d9d74f1d1f97164fbfc481c3 ("net: ipv6: Make address flushing on i

Re: [lkp] [net] 21bb45b419: kmsg.unregister_netdevice:waiting_for_br-lan_to_become_free.Usage_count=

On 2/29/16 12:50 AM, kernel test robot wrote: FYI, we noticed the below changes on https://github.com/0day-ci/linux David-Ahern/net-ipv6-Make-address-flushing-on-ifdown-optional/20160214-062626 commit 21bb45b419243ee4d9d74f1d1f97164fbfc481c3 ("net: ipv6: Make address flushing on i

Re: [PATCH] tools lib traceevent: Add '~' operation within arg_num_eval()

gfp_t)0x200u)) ^ | here Signed-off-by: Steven Rostedt <rost...@goodmis.org> --- I've been meaning to chase this down for a few weeks. Worked for me. Tested-by: David Ahern <dsah...@gmail.com>

Re: [PATCH] tools lib traceevent: Add '~' operation within arg_num_eval()

gfp_t)0x200u)) ^ | here Signed-off-by: Steven Rostedt --- I've been meaning to chase this down for a few weeks. Worked for me. Tested-by: David Ahern

Re: [RFC] sysfs: defer instantiation of default attrs

Hi Ed: Thank for taking the to look into this. On 2/20/16 3:42 AM, Edward Cree wrote: Testing this in a VM, and with udevd disabled (being too lazy to do it properly), created 1024 bridges. On ls'ing /sys/class/net/bridge*/queues/*/, saw free memory drop by 64kB, suggesting that much

Re: [RFC] sysfs: defer instantiation of default attrs

Hi Ed: Thank for taking the to look into this. On 2/20/16 3:42 AM, Edward Cree wrote: Testing this in a VM, and with udevd disabled (being too lazy to do it properly), created 1024 bridges. On ls'ing /sys/class/net/bridge*/queues/*/, saw free memory drop by 64kB, suggesting that much

Re: Idea for reducing sysfs memory usage

On 2/16/16 5:47 PM, Greg Kroah-Hartman wrote: How many sysfs entries are you creating for that 20kb? And how did you measure it? If you don't access the files, the backing store is not allocated, saving you a lot of memory. If you do access it, it will be freed later on afterward, so it's

Re: Idea for reducing sysfs memory usage

On 2/16/16 5:47 PM, Greg Kroah-Hartman wrote: How many sysfs entries are you creating for that 20kb? And how did you measure it? If you don't access the files, the backing store is not allocated, saving you a lot of memory. If you do access it, it will be freed later on afterward, so it's

Re: Idea for reducing sysfs memory usage

than having to instantiate them all? Shorter version, why do you think it is? :) Have you done some testing of the amount of memory that sysfs entries consume and found any problems with it? Two reasons: a) in his netdev1.1 talk "Scaling the Number of Network Interfaces on Linux",

Re: Idea for reducing sysfs memory usage

than having to instantiate them all? Shorter version, why do you think it is? :) Have you done some testing of the amount of memory that sysfs entries consume and found any problems with it? Two reasons: a) in his netdev1.1 talk "Scaling the Number of Network Interfaces on Linux",

Re: [PATCH v11 2/4] perf,kvm/{x86,s390}: Remove const from kvm_events_tp

depending on the machine type. Signed-off-by: Hemant Kumar --- Acked-by: David Ahern

Re: [PATCH v11 1/4] perf,kvm/{x86,s390}: Remove dependency on uapi/kvm_perf.h

Acked-by: Alexander Yarygin Acked-by: David Ahern

Re: [PATCH v11 2/4] perf,kvm/{x86,s390}: Remove const from kvm_events_tp

depending on the machine type. Signed-off-by: Hemant Kumar<hem...@linux.vnet.ibm.com> --- Acked-by: David Ahern <dsah...@gmail.com>

Re: [PATCH v11 1/4] perf,kvm/{x86,s390}: Remove dependency on uapi/kvm_perf.h

hem...@linux.vnet.ibm.com> Acked-by: Alexander Yarygin<yary...@linux.vnet.ibm.com> Acked-by: David Ahern <dsah...@gmail.com>

Re: [PATCH 4.3 2/2] vrf: fix double free and memory corruption on register_netdevice failure

(vrf_ptr); - free_netdev(dev); return err; } Acked-by: David Ahern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please re

Re: [PATCH 4.3 1/2] Revert "vrf: fix double free and memory corruption on register_netdevice failure"

of action -- revert the old and do over. Acked-by: David Ahern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FA

Re: [PATCH 4.3] vrf: Fix memory leak on registration failure in vrf_newlink()

On 12/15/15 8:12 AM, Ben Hutchings wrote: @@ -598,7 +599,10 @@ static int vrf_newlink(struct net *src_net, struct net_device *dev, rcu_assign_pointer(dev->vrf_ptr, vrf_ptr); - return register_netdev(dev); + err = register_netdev(dev); + if (err) +

Re: [PATCH 4.3 1/2] Revert "vrf: fix double free and memory corruption on register_netdevice failure"

t;b...@decadent.org.uk> --- Best course of action -- revert the old and do over. Acked-by: David Ahern <d...@cumulusnetworks.com> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vge

Re: [PATCH 4.3 2/2] vrf: fix double free and memory corruption on register_netdevice failure

(vrf_ptr); - free_netdev(dev); return err; } Acked-by: David Ahern <d...@cumulusnetworks.com> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kern

Re: [PATCH 4.3] vrf: Fix memory leak on registration failure in vrf_newlink()

On 12/15/15 8:12 AM, Ben Hutchings wrote: @@ -598,7 +599,10 @@ static int vrf_newlink(struct net *src_net, struct net_device *dev, rcu_assign_pointer(dev->vrf_ptr, vrf_ptr); - return register_netdev(dev); + err = register_netdev(dev); + if (err) +

Re: [RFC/PATCHSET 0/6] perf tools: Support dynamic sort keys for tracepoints (v1)

On 12/14/15 10:47 AM, Arnaldo Carvalho de Melo wrote: With dynamic sort keys, you can use as a sort key. Those dynamic keys are checked and created on demand. For instance, below is to sort by next_pid field on the same data file. $ perf report -s comm,sched:sched_switch.next_pid --stdio

Re: [PATCH 4.3 34/71] vrf: fix double free and memory corruption on register_netdevice failure

On 12/14/15 10:45 AM, Ben Hutchings wrote: On Sat, 2015-12-12 at 12:05 -0800, Greg Kroah-Hartman wrote: 4.3-stable review patch. If anyone has any objections, please let me know. -- From: Nikolay Aleksandrov [ Upstream commit 7f109f7cc37108cba7243bc832988525b0d85909 ]

Re: [PATCHSET 00/16] perf top: Add multi-thread support (v1)

On 12/14/15 2:38 AM, Ingo Molnar wrote: And in an unrelated note, I absolutely detest --buildid being the default, it makes perf-record blow chunks. Yes, a .debug directory that gets bloated fast and being a dot-directory is off the primary radar. I forget about it and too often forget to

Re: [PATCHSET 00/16] perf top: Add multi-thread support (v1)

On 12/14/15 2:26 AM, Peter Zijlstra wrote: On Fri, Dec 11, 2015 at 08:01:31AM -0700, David Ahern wrote: On 12/11/15 1:11 AM, Ingo Molnar wrote: * Namhyung Kim wrote: IIRC David said that thread per cpu seems too much especially on a large system (like ~1024 cpu). [...] Too much in what

Re: [PATCHSET 00/16] perf top: Add multi-thread support (v1)

On 12/14/15 2:38 AM, Ingo Molnar wrote: And in an unrelated note, I absolutely detest --buildid being the default, it makes perf-record blow chunks. Yes, a .debug directory that gets bloated fast and being a dot-directory is off the primary radar. I forget about it and too often forget to

Re: [PATCHSET 00/16] perf top: Add multi-thread support (v1)

On 12/14/15 2:26 AM, Peter Zijlstra wrote: On Fri, Dec 11, 2015 at 08:01:31AM -0700, David Ahern wrote: On 12/11/15 1:11 AM, Ingo Molnar wrote: * Namhyung Kim <namhy...@gmail.com> wrote: IIRC David said that thread per cpu seems too much especially on a large system (like ~10

Re: [PATCH 4.3 34/71] vrf: fix double free and memory corruption on register_netdevice failure

On 12/14/15 10:45 AM, Ben Hutchings wrote: On Sat, 2015-12-12 at 12:05 -0800, Greg Kroah-Hartman wrote: 4.3-stable review patch. If anyone has any objections, please let me know. -- From: Nikolay Aleksandrov [ Upstream commit

Re: [RFC/PATCHSET 0/6] perf tools: Support dynamic sort keys for tracepoints (v1)

On 12/14/15 10:47 AM, Arnaldo Carvalho de Melo wrote: With dynamic sort keys, you can use as a sort key. Those dynamic keys are checked and created on demand. For instance, below is to sort by next_pid field on the same data file. $ perf report -s comm,sched:sched_switch.next_pid --stdio

Re: [PATCHSET 00/16] perf top: Add multi-thread support (v1)

On 12/11/15 1:11 AM, Ingo Molnar wrote: * Namhyung Kim wrote: IIRC David said that thread per cpu seems too much especially on a large system (like ~1024 cpu). [...] Too much in what fashion? For recording I think it's the fastest, most natural model - anything else will create cache line

Re: [PATCHSET 00/16] perf top: Add multi-thread support (v1)

On 12/11/15 1:11 AM, Ingo Molnar wrote: * Namhyung Kim wrote: IIRC David said that thread per cpu seems too much especially on a large system (like ~1024 cpu). [...] Too much in what fashion? For recording I think it's the fastest, most natural model - anything else

Re: [PATCH 2/3] perf callchain: Stop resolving callchains after invalid address

On 11/26/15 8:00 AM, Namhyung Kim wrote: Hi David, On Thu, Nov 26, 2015 at 06:14:57AM -0700, David Ahern wrote: On 11/26/15 12:08 AM, Namhyung Kim wrote: @@ -528,11 +529,16 @@ int main(int argc, const char **argv) { const char *cmd; char sbuf[STRERR_BUFSIZE]; + int

Re: [PATCH 3/3] perf script: Align event name properly

On 11/26/15 7:30 AM, Jiri Olsa wrote: On Thu, Nov 26, 2015 at 07:25:17AM -0700, David Ahern wrote: On 11/26/15 6:55 AM, Jiri Olsa wrote: Adding code to align event names, so we get aligned output in case of multiple events with different names. Before: $ perf script :13757 13757

Re: [PATCH 3/3] perf script: Align event name properly

... What's up with the ":13757" for the process name? Patches LGTM Acked-by: David Ahern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-i

Re: [PATCH 2/3] perf callchain: Stop resolving callchains after invalid address

On 11/26/15 12:08 AM, Namhyung Kim wrote: @@ -528,11 +529,16 @@ int main(int argc, const char **argv) { const char *cmd; char sbuf[STRERR_BUFSIZE]; + int min_addr; /* The page_size is placed in util object. */ page_size = sysconf(_SC_PAGE_SIZE);

Re: [PATCH 2/3] perf callchain: Stop resolving callchains after invalid address

On 11/26/15 12:08 AM, Namhyung Kim wrote: @@ -528,11 +529,16 @@ int main(int argc, const char **argv) { const char *cmd; char sbuf[STRERR_BUFSIZE]; + int min_addr; /* The page_size is placed in util object. */ page_size = sysconf(_SC_PAGE_SIZE);

Re: [PATCH 3/3] perf script: Align event name properly

... What's up with the ":13757" for the process name? Patches LGTM Acked-by: David Ahern <dsah...@gmail.com> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http:/

Re: [PATCH 3/3] perf script: Align event name properly

On 11/26/15 7:30 AM, Jiri Olsa wrote: On Thu, Nov 26, 2015 at 07:25:17AM -0700, David Ahern wrote: On 11/26/15 6:55 AM, Jiri Olsa wrote: Adding code to align event names, so we get aligned output in case of multiple events with different names. Before: $ perf script :13757 13757

Re: [PATCH 2/3] perf callchain: Stop resolving callchains after invalid address

On 11/26/15 8:00 AM, Namhyung Kim wrote: Hi David, On Thu, Nov 26, 2015 at 06:14:57AM -0700, David Ahern wrote: On 11/26/15 12:08 AM, Namhyung Kim wrote: @@ -528,11 +529,16 @@ int main(int argc, const char **argv) { const char *cmd; char sbuf[STRERR_BUFSIZE]; + int

Re: [PATCH] perf record: Add snapshot mode support for perf's regular events

On 11/24/15 8:50 PM, Wangnan (F) wrote: Actually we are discussing about this problem. For such tracking events (PERF_RECORD_FORK...), we have dummy event so it is possible for us to receive tracking events from a separated channel, therefore we don't have to parse every events to pick those

Re: [PATCH] perf record: Add snapshot mode support for perf's regular events

On 11/24/15 8:40 AM, Arnaldo Carvalho de Melo wrote: perf-record without his patch? yes, but with his patch it does: __cmd_record() for (;;) record__mmap_read_all() record__write() perf_memory__write()

Re: [PATCH] perf record: Add snapshot mode support for perf's regular events

On 11/24/15 8:20 AM, Arnaldo Carvalho de Melo wrote: Em Tue, Nov 24, 2015 at 08:06:41AM -0700, David Ahern escreveu: On 11/24/15 7:00 AM, Yunlong Song wrote: +static int record__write(struct record *rec, void *bf, size_t size) +{ + if (rec->memory.size && mem

Re: [PATCH] perf record: Add snapshot mode support for perf's regular events

On 11/24/15 7:00 AM, Yunlong Song wrote: +static int record__write(struct record *rec, void *bf, size_t size) +{ + if (rec->memory.size && memory_enabled) { + if (perf_memory__write(>memory, bf, size) < 0) { + pr_err("failed to write memory data, error:

Re: [PATCH] perf record: Add snapshot mode support for perf's regular events

On 11/24/15 8:40 AM, Arnaldo Carvalho de Melo wrote: perf-record without his patch? yes, but with his patch it does: __cmd_record() for (;;) record__mmap_read_all() record__write() perf_memory__write()

Re: [PATCH] perf record: Add snapshot mode support for perf's regular events

On 11/24/15 8:50 PM, Wangnan (F) wrote: Actually we are discussing about this problem. For such tracking events (PERF_RECORD_FORK...), we have dummy event so it is possible for us to receive tracking events from a separated channel, therefore we don't have to parse every events to pick those

Re: [PATCH] perf record: Add snapshot mode support for perf's regular events

On 11/24/15 7:00 AM, Yunlong Song wrote: +static int record__write(struct record *rec, void *bf, size_t size) +{ + if (rec->memory.size && memory_enabled) { + if (perf_memory__write(>memory, bf, size) < 0) { + pr_err("failed to write memory data, error:

Re: [PATCH] perf record: Add snapshot mode support for perf's regular events

On 11/24/15 8:20 AM, Arnaldo Carvalho de Melo wrote: Em Tue, Nov 24, 2015 at 08:06:41AM -0700, David Ahern escreveu: On 11/24/15 7:00 AM, Yunlong Song wrote: +static int record__write(struct record *rec, void *bf, size_t size) +{ + if (rec->memory.size && mem

Re: linux-next network throughput performance regression

On 11/6/15 2:18 PM, Simon Xiao wrote: The .config file used to build linux-next kernel is attached to this mail. Thanks. Failed to notice this on the first response; my brain filled in. Why linux-next tree? Can you try net-next which is more relevant for this mailing list, post the top

Re: linux-next network throughput performance regression

On 11/6/15 1:31 PM, Simon Xiao wrote: I compared the network throughput performance on SLES12 bare metal servers, between SLES12 default kernel and latest linux-next (2015-11-05) kernel, based on the test results, I suspect there is a network regression exists on Linux-Next over the 40G

Re: linux-next network throughput performance regression

On 11/6/15 1:31 PM, Simon Xiao wrote: I compared the network throughput performance on SLES12 bare metal servers, between SLES12 default kernel and latest linux-next (2015-11-05) kernel, based on the test results, I suspect there is a network regression exists on Linux-Next over the 40G

<    2   3   4   5   6   7   8   9   10   11   >