- Linux-stable-mirror - lists.linaro.org

Patch "perf session: Don't rely on evlist in pipe mode" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled perf session: Don't rely on evlist in pipe mode to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: perf-session-don-t-rely-on-evlist-in-pipe-mode.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Sun Mar 18 16:55:33 CET 2018 From: David Carrillo-Cisneros <davidcc(a)google.com> Date: Mon, 10 Apr 2017 13:14:30 -0700 Subject: perf session: Don't rely on evlist in pipe mode From: David Carrillo-Cisneros <davidcc(a)google.com> [ Upstream commit 0973ad97c187e06aece61f685b9c3b2d93290a73 ] Session sets a number parameters that rely on evlist. These parameters are not used in pipe-mode and should not be set, since evlist is unavailable. Fix that. Signed-off-by: David Carrillo-Cisneros <davidcc(a)google.com> Acked-by: Jiri Olsa <jolsa(a)kernel.org> Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com> Cc: Andi Kleen <ak(a)linux.intel.com> Cc: He Kuang <hekuang(a)huawei.com> Cc: Masami Hiramatsu <mhiramat(a)kernel.org> Cc: Paul Turner <pjt(a)google.com> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Simon Que <sque(a)chromium.org> Cc: Stephane Eranian <eranian(a)google.com> Cc: Wang Nan <wangnan0(a)huawei.com> Link: http://lkml.kernel.org/r/20170410201432.24807-6-davidcc@google.com [ Check if file != NULL in perf_session__new(), like when used by builtin-top.c ] Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/perf/util/session.c | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) --- a/tools/perf/util/session.c +++ b/tools/perf/util/session.c @@ -139,8 +139,14 @@ struct perf_session *perf_session__new(s if (perf_session__open(session) < 0) goto out_close; - perf_session__set_id_hdr_size(session); - perf_session__set_comm_exec(session); + /* + * set session attributes that are present in perf.data + * but not in pipe-mode. + */ + if (!file->is_pipe) { + perf_session__set_id_hdr_size(session); + perf_session__set_comm_exec(session); + } } } else { session->machines.host.env = &perf_env; @@ -155,7 +161,11 @@ struct perf_session *perf_session__new(s pr_warning("Cannot read kernel map\n"); } - if (tool && tool->ordering_requires_timestamps && + /* + * In pipe-mode, evlist is empty until PERF_RECORD_HEADER_ATTR is + * processed, so perf_evlist__sample_id_all is not meaningful here. + */ + if ((!file || !file->is_pipe) && tool && tool->ordering_requires_timestamps && tool->ordered_events && !perf_evlist__sample_id_all(session->evlist)) { dump_printf("WARNING: No sample_id_all support, falling back to unordered processing\n"); tool->ordered_events = false; Patches currently in stable-queue which might be from davidcc(a)google.com are queue-4.9/perf-session-don-t-rely-on-evlist-in-pipe-mode.patch queue-4.9/perf-inject-copy-events-when-reordering-events-in-pipe-mode.patch queue-4.9/perf-stat-fix-bug-in-handling-events-in-error-state.patch

7 years, 6 months

1
0
0 0

Patch "perf probe: Return errno when not hitting any event" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled perf probe: Return errno when not hitting any event to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: perf-probe-return-errno-when-not-hitting-any-event.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Sun Mar 18 16:55:33 CET 2018 From: Kefeng Wang <wangkefeng.wang(a)huawei.com> Date: Fri, 17 Mar 2017 16:16:32 +0800 Subject: perf probe: Return errno when not hitting any event From: Kefeng Wang <wangkefeng.wang(a)huawei.com> [ Upstream commit 70946723eeb859466f026274b29c6196e39149c4 ] On old perf, when using 'perf probe -d' to delete an inexistent event, it returns errno, eg, -bash-4.3# perf probe -d xxx || echo $? Info: Event "*:xxx" does not exist. Error: Failed to delete events. 255 But now perf_del_probe_events() will always set ret = 0, different from previous del_perf_probe_events(). After this, it returns errno again, eg, -bash-4.3# ./perf probe -d xxx || echo $? "xxx" does not hit any event. Error: Failed to delete events. 254 And it is more appropriate to return -ENOENT instead of -EPERM. Signed-off-by: Kefeng Wang <wangkefeng.wang(a)huawei.com> Acked-by: Masami Hiramatsu <mhiramat(a)kernel.org> Cc: Hanjun Guo <guohanjun(a)huawei.com> Cc: Jiri Olsa <jolsa(a)kernel.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Wang Nan <wangnan0(a)huawei.com> Fixes: dddc7ee32fa1 ("perf probe: Fix an error when deleting probes successfully") Link: http://lkml.kernel.org/r/1489738592-61011-1-git-send-email-wangkefeng.wang@… Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/perf/builtin-probe.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/tools/perf/builtin-probe.c +++ b/tools/perf/builtin-probe.c @@ -442,9 +442,9 @@ static int perf_del_probe_events(struct } if (ret == -ENOENT && ret2 == -ENOENT) - pr_debug("\"%s\" does not hit any event.\n", str); - /* Note that this is silently ignored */ - ret = 0; + pr_warning("\"%s\" does not hit any event.\n", str); + else + ret = 0; error: if (kfd >= 0) Patches currently in stable-queue which might be from wangkefeng.wang(a)huawei.com are queue-4.9/perf-probe-return-errno-when-not-hitting-any-event.patch

7 years, 6 months

1
0
0 0

Patch "perf probe: Fix concat_probe_trace_events" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled perf probe: Fix concat_probe_trace_events to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: perf-probe-fix-concat_probe_trace_events.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Sun Mar 18 16:55:33 CET 2018 From: Ravi Bangoria <ravi.bangoria(a)linux.vnet.ibm.com> Date: Wed, 8 Mar 2017 12:29:07 +0530 Subject: perf probe: Fix concat_probe_trace_events From: Ravi Bangoria <ravi.bangoria(a)linux.vnet.ibm.com> [ Upstream commit f0a30dca5f84fe8048271799b56677ac2279de66 ] '*ntevs' contains number of elements present in 'tevs' array. If there are no elements in array, 'tevs2' can be directly assigned to 'tevs' without allocating more space. So the condition should be '*ntevs == 0' not 'ntevs == 0'. Signed-off-by: Ravi Bangoria <ravi.bangoria(a)linux.vnet.ibm.com> Acked-by: Masami Hiramatsu <mhiramat(a)kernel.org> Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com> Cc: Peter Zijlstra <peterz(a)infradead.org> Fixes: 42bba263eb58 ("perf probe: Allow wildcard for cached events") Link: http://lkml.kernel.org/r/20170308065908.4128-1-ravi.bangoria@linux.vnet.ibm… Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/perf/util/probe-event.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/tools/perf/util/probe-event.c +++ b/tools/perf/util/probe-event.c @@ -3060,7 +3060,7 @@ concat_probe_trace_events(struct probe_t struct probe_trace_event *new_tevs; int ret = 0; - if (ntevs == 0) { + if (*ntevs == 0) { *tevs = *tevs2; *ntevs = ntevs2; *tevs2 = NULL; Patches currently in stable-queue which might be from ravi.bangoria(a)linux.vnet.ibm.com are queue-4.9/perf-probe-fix-concat_probe_trace_events.patch

7 years, 6 months

1
0
0 0

Patch "perf inject: Copy events when reordering events in pipe mode" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled perf inject: Copy events when reordering events in pipe mode to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: perf-inject-copy-events-when-reordering-events-in-pipe-mode.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Sun Mar 18 16:55:33 CET 2018 From: David Carrillo-Cisneros <davidcc(a)google.com> Date: Mon, 10 Apr 2017 13:14:27 -0700 Subject: perf inject: Copy events when reordering events in pipe mode From: David Carrillo-Cisneros <davidcc(a)google.com> [ Upstream commit 1e0d4f0200e4dbdfc38d818f329d8a0955f7c6f5 ] __perf_session__process_pipe_events reuses the same memory buffer to process all events in the pipe. When reordering is needed (e.g. -b option), events are not immediately flushed, but kept around until reordering is possible, causing memory corruption. The problem is usually observed by a "Unknown sample error" output. It can easily be reproduced by: perf record -o - noploop | perf inject -b > output Committer testing: Before: $ perf record -o - stress -t 2 -c 2 | perf inject -b > /dev/null stress: info: [8297] dispatching hogs: 2 cpu, 0 io, 0 vm, 0 hdd stress: info: [8297] successful run completed in 2s [ perf record: Woken up 3 times to write data ] [ perf record: Captured and wrote 0.000 MB - ] Warning: Found 1 unknown events! Is this an older tool processing a perf.data file generated by a more recent tool? If that is not the case, consider reporting to linux-kernel(a)vger.kernel.org. $ After: $ perf record -o - stress -t 2 -c 2 | perf inject -b > /dev/null stress: info: [9027] dispatching hogs: 2 cpu, 0 io, 0 vm, 0 hdd stress: info: [9027] successful run completed in 2s [ perf record: Woken up 3 times to write data ] [ perf record: Captured and wrote 0.000 MB - ] no symbols found in /usr/bin/stress, maybe install a debug package? no symbols found in /usr/bin/stress, maybe install a debug package? $ Signed-off-by: David Carrillo-Cisneros <davidcc(a)google.com> Tested-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> Acked-by: Jiri Olsa <jolsa(a)kernel.org> Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com> Cc: Andi Kleen <ak(a)linux.intel.com> Cc: He Kuang <hekuang(a)huawei.com> Cc: Masami Hiramatsu <mhiramat(a)kernel.org> Cc: Paul Turner <pjt(a)google.com> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Simon Que <sque(a)chromium.org> Cc: Stephane Eranian <eranian(a)google.com> Cc: Wang Nan <wangnan0(a)huawei.com> Link: http://lkml.kernel.org/r/20170410201432.24807-3-davidcc@google.com Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/perf/util/ordered-events.c | 3 ++- tools/perf/util/session.c | 1 + 2 files changed, 3 insertions(+), 1 deletion(-) --- a/tools/perf/util/ordered-events.c +++ b/tools/perf/util/ordered-events.c @@ -79,7 +79,7 @@ static union perf_event *dup_event(struc static void free_dup_event(struct ordered_events *oe, union perf_event *event) { - if (oe->copy_on_queue) { + if (event && oe->copy_on_queue) { oe->cur_alloc_size -= event->header.size; free(event); } @@ -150,6 +150,7 @@ void ordered_events__delete(struct order list_move(&event->list, &oe->cache); oe->nr_events--; free_dup_event(oe, event->event); + event->event = NULL; } int ordered_events__queue(struct ordered_events *oe, union perf_event *event, --- a/tools/perf/util/session.c +++ b/tools/perf/util/session.c @@ -1628,6 +1628,7 @@ static int __perf_session__process_pipe_ buf = malloc(cur_size); if (!buf) return -errno; + ordered_events__set_copy_on_queue(oe, true); more: event = buf; err = readn(fd, event, sizeof(struct perf_event_header)); Patches currently in stable-queue which might be from davidcc(a)google.com are queue-4.9/perf-session-don-t-rely-on-evlist-in-pipe-mode.patch queue-4.9/perf-inject-copy-events-when-reordering-events-in-pipe-mode.patch queue-4.9/perf-stat-fix-bug-in-handling-events-in-error-state.patch

7 years, 6 months

1
0
0 0

Patch "perf evsel: Return exact sub event which failed with EPERM for wildcards" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled perf evsel: Return exact sub event which failed with EPERM for wildcards to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: perf-evsel-return-exact-sub-event-which-failed-with-eperm-for-wildcards.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Sun Mar 18 16:55:33 CET 2018 From: Jin Yao <yao.jin(a)linux.intel.com> Date: Fri, 7 Apr 2017 20:08:52 +0800 Subject: perf evsel: Return exact sub event which failed with EPERM for wildcards From: Jin Yao <yao.jin(a)linux.intel.com> [ Upstream commit 32ccb130f5325abc81b32b1a538390f46e4860f6 ] The kernel has a special check for a specific irq_vectors trace event. TRACE_EVENT_PERF_PERM(irq_work_exit, is_sampling_event(p_event) ? -EPERM : 0); The perf-record fails for this irq_vectors event when it is present, like when using a wildcard: root@skl:/tmp# perf record -a -e irq_vectors:* sleep 2 Error: You may not have permission to collect system-wide stats. Consider tweaking /proc/sys/kernel/perf_event_paranoid, which controls use of the performance events system by unprivileged users (without CAP_SYS_ADMIN). The current value is 2: -1: Allow use of (almost) all events by all users >= 0: Disallow raw tracepoint access by users without CAP_IOC_LOCK >= 1: Disallow CPU event access by users without CAP_SYS_ADMIN >= 2: Disallow kernel profiling by users without CAP_SYS_ADMIN To make this setting permanent, edit /etc/sysctl.conf too, e.g.: kernel.perf_event_paranoid = -1 This patch prints out the exact sub event that failed with EPERM for wildcards to help in understanding what went wrong when this event is present: After the patch: root@skl:/tmp# perf record -a -e irq_vectors:* sleep 2 Error: No permission to enable irq_vectors:irq_work_exit event. You may not have permission to collect system-wide stats. ...... Committer notes: So we have a lot of irq_vectors events: [root@jouet ~]# perf list irq_vectors:* List of pre-defined events (to be used in -e): irq_vectors:call_function_entry [Tracepoint event] irq_vectors:call_function_exit [Tracepoint event] irq_vectors:call_function_single_entry [Tracepoint event] irq_vectors:call_function_single_exit [Tracepoint event] irq_vectors:deferred_error_apic_entry [Tracepoint event] irq_vectors:deferred_error_apic_exit [Tracepoint event] irq_vectors:error_apic_entry [Tracepoint event] irq_vectors:error_apic_exit [Tracepoint event] irq_vectors:irq_work_entry [Tracepoint event] irq_vectors:irq_work_exit [Tracepoint event] irq_vectors:local_timer_entry [Tracepoint event] irq_vectors:local_timer_exit [Tracepoint event] irq_vectors:reschedule_entry [Tracepoint event] irq_vectors:reschedule_exit [Tracepoint event] irq_vectors:spurious_apic_entry [Tracepoint event] irq_vectors:spurious_apic_exit [Tracepoint event] irq_vectors:thermal_apic_entry [Tracepoint event] irq_vectors:thermal_apic_exit [Tracepoint event] irq_vectors:threshold_apic_entry [Tracepoint event] irq_vectors:threshold_apic_exit [Tracepoint event] irq_vectors:x86_platform_ipi_entry [Tracepoint event] irq_vectors:x86_platform_ipi_exit [Tracepoint event] # And some may be sampled: [root@jouet ~]# perf record -e irq_vectors:local* sleep 20s [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.020 MB perf.data (2 samples) ] [root@jouet ~]# perf report -D | egrep 'stats:|events:' Aggregated stats: TOTAL events: 155 MMAP events: 144 COMM events: 2 EXIT events: 1 SAMPLE events: 2 MMAP2 events: 4 FINISHED_ROUND events: 1 TIME_CONV events: 1 irq_vectors:local_timer_entry stats: TOTAL events: 1 SAMPLE events: 1 irq_vectors:local_timer_exit stats: TOTAL events: 1 SAMPLE events: 1 [root@jouet ~]# But, as shown in the tracepoint definition at the start of this message, some, like "irq_vectors:irq_work_exit", may not be sampled, just counted, i.e. if we try to sample, as when using 'perf record', we get an error: [root@jouet ~]# perf record -e irq_vectors:irq_work_exit Error: You may not have permission to collect system-wide stats. Consider tweaking /proc/sys/kernel/perf_event_paranoid, <SNIP> The error message is misleading, this patch will help in pointing out what is the event causing such an error, but the error message needs improvement, i.e. we need to figure out a way to check if a tracepoint is counting only, like this one, when all we can do is to count it with 'perf stat', at most printing the delta using interval printing, as in: [root@jouet ~]# perf stat -I 5000 -e irq_vectors:irq_work_* # time counts unit events 5.000168871 0 irq_vectors:irq_work_entry 5.000168871 0 irq_vectors:irq_work_exit 10.000676730 0 irq_vectors:irq_work_entry 10.000676730 0 irq_vectors:irq_work_exit 15.001122415 0 irq_vectors:irq_work_entry 15.001122415 0 irq_vectors:irq_work_exit 20.001298051 0 irq_vectors:irq_work_entry 20.001298051 0 irq_vectors:irq_work_exit 25.001485020 1 irq_vectors:irq_work_entry 25.001485020 1 irq_vectors:irq_work_exit 30.001658706 0 irq_vectors:irq_work_entry 30.001658706 0 irq_vectors:irq_work_exit ^C 32.045711878 0 irq_vectors:irq_work_entry 32.045711878 0 irq_vectors:irq_work_exit [root@jouet ~]# But at least, when we use a wildcard, this patch helps a bit. Signed-off-by: Yao Jin <yao.jin(a)linux.intel.com> Tested-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com> Cc: Andi Kleen <ak(a)linux.intel.com> Cc: Jiri Olsa <jolsa(a)kernel.org> Cc: Kan Liang <kan.liang(a)intel.com> Cc: Peter Zijlstra <peterz(a)infradead.org> Link: http://lkml.kernel.org/r/1491566932-503-1-git-send-email-yao.jin@linux.inte… Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/perf/util/evsel.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) --- a/tools/perf/util/evsel.c +++ b/tools/perf/util/evsel.c @@ -2400,11 +2400,17 @@ int perf_evsel__open_strerror(struct per int err, char *msg, size_t size) { char sbuf[STRERR_BUFSIZE]; + int printed = 0; switch (err) { case EPERM: case EACCES: - return scnprintf(msg, size, + if (err == EPERM) + printed = scnprintf(msg, size, + "No permission to enable %s event.\n\n", + perf_evsel__name(evsel)); + + return scnprintf(msg + printed, size - printed, "You may not have permission to collect %sstats.\n\n" "Consider tweaking /proc/sys/kernel/perf_event_paranoid,\n" "which controls use of the performance events system by\n" Patches currently in stable-queue which might be from yao.jin(a)linux.intel.com are queue-4.9/perf-evsel-return-exact-sub-event-which-failed-with-eperm-for-wildcards.patch

7 years, 6 months

1
0
0 0

Patch "perf buildid: Do not assume that readlink() returns a null terminated string" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled perf buildid: Do not assume that readlink() returns a null terminated string to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: perf-buildid-do-not-assume-that-readlink-returns-a-null-terminated-string.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Sun Mar 18 16:55:33 CET 2018 From: Tommi Rantala <tommi.t.rantala(a)nokia.com> Date: Wed, 22 Mar 2017 15:06:20 +0200 Subject: perf buildid: Do not assume that readlink() returns a null terminated string From: Tommi Rantala <tommi.t.rantala(a)nokia.com> [ Upstream commit 5a2342111c68e623e27ee7ea3d0492d8dad6bda0 ] Valgrind was complaining: $ valgrind ./perf list >/dev/null ==11643== Memcheck, a memory error detector ==11643== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==11643== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info ==11643== Command: ./perf list ==11643== ==11643== Conditional jump or move depends on uninitialised value(s) ==11643== at 0x4C30620: rindex (vg_replace_strmem.c:199) ==11643== by 0x49DAA9: build_id_cache__origname (build-id.c:198) ==11643== by 0x49E1C7: build_id_cache__valid_id (build-id.c:222) ==11643== by 0x49E1C7: build_id_cache__list_all (build-id.c:507) ==11643== by 0x4B9C8F: print_sdt_events (parse-events.c:2067) ==11643== by 0x4BB0B3: print_events (parse-events.c:2313) ==11643== by 0x439501: cmd_list (builtin-list.c:53) ==11643== by 0x497150: run_builtin (perf.c:359) ==11643== by 0x428CE0: handle_internal_command (perf.c:421) ==11643== by 0x428CE0: run_argv (perf.c:467) ==11643== by 0x428CE0: main (perf.c:614) [...] Additionally, a zero length result from readlink() is not very interesting. Signed-off-by: Tommi Rantala <tommi.t.rantala(a)nokia.com> Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com> Cc: Peter Zijlstra <peterz(a)infradead.org> Link: http://lkml.kernel.org/r/20170322130624.21881-3-tommi.t.rantala@nokia.com Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/perf/util/build-id.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) --- a/tools/perf/util/build-id.c +++ b/tools/perf/util/build-id.c @@ -182,13 +182,17 @@ char *build_id_cache__origname(const cha char buf[PATH_MAX]; char *ret = NULL, *p; size_t offs = 5; /* == strlen("../..") */ + ssize_t len; linkname = build_id_cache__linkname(sbuild_id, NULL, 0); if (!linkname) return NULL; - if (readlink(linkname, buf, PATH_MAX) < 0) + len = readlink(linkname, buf, sizeof(buf) - 1); + if (len <= 0) goto out; + buf[len] = '\0'; + /* The link should be "../..<origpath>/<sbuild_id>" */ p = strrchr(buf, '/'); /* Cut off the "/<sbuild_id>" */ if (p && (p > buf + offs)) { Patches currently in stable-queue which might be from tommi.t.rantala(a)nokia.com are queue-4.9/perf-buildid-do-not-assume-that-readlink-returns-a-null-terminated-string.patch

7 years, 6 months

1
0
0 0

Patch "perf annotate: Fix a bug following symbolic link of a build-id file" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled perf annotate: Fix a bug following symbolic link of a build-id file to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: perf-annotate-fix-a-bug-following-symbolic-link-of-a-build-id-file.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Sun Mar 18 16:55:33 CET 2018 From: Taeung Song <treeze.taeung(a)gmail.com> Date: Mon, 27 Mar 2017 16:10:36 +0900 Subject: perf annotate: Fix a bug following symbolic link of a build-id file From: Taeung Song <treeze.taeung(a)gmail.com> [ Upstream commit 6ebd2547dd24daf95a21b2bc59931de8502afcc3 ] It is wrong way to read link name from a build-id file. Because a build-id file is not anymore a symbolic link but build-id directory of it is symbolic link, so fix it. For example, if build-id file name gotten from dso__build_id_filename() is as below, /root/.debug/.build-id/4f/75c7d197c951659d1c1b8b5fd49bcdf8f3f8b1/elf To correctly read link name of build-id, use the build-id dir path that is a symbolic link, instead of the above build-id file name like below. /root/.debug/.build-id/4f/75c7d197c951659d1c1b8b5fd49bcdf8f3f8b1 Signed-off-by: Taeung Song <treeze.taeung(a)gmail.com> Cc: Jiri Olsa <jolsa(a)redhat.com> Cc: Masami Hiramatsu <mhiramat(a)kernel.org> Cc: Namhyung Kim <namhyung(a)kernel.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Wang Nan <wangnan0(a)huawei.com> Link: http://lkml.kernel.org/r/1490598638-13947-2-git-send-email-treeze.taeung@gm… Fixes: 01412261d994 ("perf buildid-cache: Use path/to/bin/buildid/elf instead of path/to/bin/buildid") Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/perf/util/annotate.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) --- a/tools/perf/util/annotate.c +++ b/tools/perf/util/annotate.c @@ -1250,6 +1250,7 @@ static int dso__disassemble_filename(str { char linkname[PATH_MAX]; char *build_id_filename; + char *build_id_path = NULL; if (dso->symtab_type == DSO_BINARY_TYPE__KALLSYMS && !dso__is_kcore(dso)) @@ -1265,8 +1266,14 @@ static int dso__disassemble_filename(str goto fallback; } + build_id_path = strdup(filename); + if (!build_id_path) + return -1; + + dirname(build_id_path); + if (dso__is_kcore(dso) || - readlink(filename, linkname, sizeof(linkname)) < 0 || + readlink(build_id_path, linkname, sizeof(linkname)) < 0 || strstr(linkname, DSO__NAME_KALLSYMS) || access(filename, R_OK)) { fallback: @@ -1278,6 +1285,7 @@ fallback: __symbol__join_symfs(filename, filename_size, dso->long_name); } + free(build_id_path); return 0; } Patches currently in stable-queue which might be from treeze.taeung(a)gmail.com are queue-4.9/perf-annotate-fix-a-bug-following-symbolic-link-of-a-build-id-file.patch

7 years, 6 months

1
0
0 0

Patch "PCI/MSI: Stop disabling MSI/MSI-X in pci_device_shutdown()" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled PCI/MSI: Stop disabling MSI/MSI-X in pci_device_shutdown() to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: pci-msi-stop-disabling-msi-msi-x-in-pci_device_shutdown.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Sun Mar 18 16:55:33 CET 2018 From: Prarit Bhargava <prarit(a)redhat.com> Date: Thu, 26 Jan 2017 14:07:47 -0500 Subject: PCI/MSI: Stop disabling MSI/MSI-X in pci_device_shutdown() From: Prarit Bhargava <prarit(a)redhat.com> [ Upstream commit fda78d7a0ead144f4b2cdb582dcba47911f4952c ] The pci_bus_type .shutdown method, pci_device_shutdown(), is called from device_shutdown() in the kernel restart and shutdown paths. Previously, pci_device_shutdown() called pci_msi_shutdown() and pci_msix_shutdown(). This disables MSI and MSI-X, which causes the device to fall back to raising interrupts via INTx. But the driver is still bound to the device, it doesn't know about this change, and it likely doesn't have an INTx handler, so these INTx interrupts cause "nobody cared" warnings like this: irq 16: nobody cared (try booting with the "irqpoll" option) CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.8.2-1.el7_UNSUPPORTED.x86_64 #1 Hardware name: Hewlett-Packard HP Z820 Workstation/158B, BIOS J63 v03.90 06/ ... The MSI disabling code was added by d52877c7b1af ("pci/irq: let pci_device_shutdown to call pci_msi_shutdown v2") because a driver left MSI enabled and kdump failed because the kexeced kernel wasn't prepared to receive the MSI interrupts. Subsequent commits 1851617cd2da ("PCI/MSI: Disable MSI at enumeration even if kernel doesn't support MSI") and e80e7edc55ba ("PCI/MSI: Initialize MSI capability for all architectures") changed the kexeced kernel to disable all MSIs itself so it no longer depends on the crashed kernel to clean up after itself. Stop disabling MSI/MSI-X in pci_device_shutdown(). This resolves the "nobody cared" unhandled IRQ issue above. It also allows PCI serial devices, which may rely on the MSI interrupts, to continue outputting messages during reboot/shutdown. [bhelgaas: changelog, drop pci_msi_shutdown() and pci_msix_shutdown() calls altogether] Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=187351 Signed-off-by: Prarit Bhargava <prarit(a)redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com> CC: Alex Williamson <alex.williamson(a)redhat.com> CC: David Arcari <darcari(a)redhat.com> CC: Myron Stowe <mstowe(a)redhat.com> CC: Lukas Wunner <lukas(a)wunner.de> CC: Keith Busch <keith.busch(a)intel.com> CC: Mika Westerberg <mika.westerberg(a)linux.intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/pci/pci-driver.c | 2 -- 1 file changed, 2 deletions(-) --- a/drivers/pci/pci-driver.c +++ b/drivers/pci/pci-driver.c @@ -463,8 +463,6 @@ static void pci_device_shutdown(struct d if (drv && drv->shutdown) drv->shutdown(pci_dev); - pci_msi_shutdown(pci_dev); - pci_msix_shutdown(pci_dev); /* * If this is a kexec reboot, turn off Bus Master bit on the Patches currently in stable-queue which might be from prarit(a)redhat.com are queue-4.9/pci-msi-stop-disabling-msi-msi-x-in-pci_device_shutdown.patch

7 years, 6 months

1
0
0 0

Patch "PCI: hv: Properly handle PCI bus remove" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled PCI: hv: Properly handle PCI bus remove to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: pci-hv-properly-handle-pci-bus-remove.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Sun Mar 18 16:55:33 CET 2018 From: Long Li <longli(a)microsoft.com> Date: Thu, 23 Mar 2017 14:58:10 -0700 Subject: PCI: hv: Properly handle PCI bus remove From: Long Li <longli(a)microsoft.com> [ Upstream commit d3a78d8bf759d8848339dcc367c4c1678b57a08b ] hv_pci_devices_present() is called in hv_pci_remove() when we remove a PCI device from the host, e.g., by disabling SR-IOV on a device. In hv_pci_remove(), the bus is already removed before the call, so we don't need to rescan the bus in the workqueue scheduled from hv_pci_devices_present(). By introducing bus state hv_pcibus_removed, we can avoid this situation. Reported-by: Xiaofeng Wang <xiaofwan(a)redhat.com> Signed-off-by: Long Li <longli(a)microsoft.com> Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com> Acked-by: K. Y. Srinivasan <kys(a)microsoft.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/pci/host/pci-hyperv.c | 20 +++++++++++++++++--- 1 file changed, 17 insertions(+), 3 deletions(-) --- a/drivers/pci/host/pci-hyperv.c +++ b/drivers/pci/host/pci-hyperv.c @@ -351,6 +351,7 @@ enum hv_pcibus_state { hv_pcibus_init = 0, hv_pcibus_probed, hv_pcibus_installed, + hv_pcibus_removed, hv_pcibus_maximum }; @@ -1489,13 +1490,24 @@ static void pci_devices_present_work(str put_pcichild(hpdev, hv_pcidev_ref_initial); } - /* Tell the core to rescan bus because there may have been changes. */ - if (hbus->state == hv_pcibus_installed) { + switch(hbus->state) { + case hv_pcibus_installed: + /* + * Tell the core to rescan bus + * because there may have been changes. + */ pci_lock_rescan_remove(); pci_scan_child_bus(hbus->pci_bus); pci_unlock_rescan_remove(); - } else { + break; + + case hv_pcibus_init: + case hv_pcibus_probed: survey_child_resources(hbus); + break; + + default: + break; } up(&hbus->enum_sem); @@ -2170,6 +2182,7 @@ static int hv_pci_probe(struct hv_device hbus = kzalloc(sizeof(*hbus), GFP_KERNEL); if (!hbus) return -ENOMEM; + hbus->state = hv_pcibus_init; /* * The PCI bus "domain" is what is called "segment" in ACPI and @@ -2312,6 +2325,7 @@ static int hv_pci_remove(struct hv_devic pci_stop_root_bus(hbus->pci_bus); pci_remove_root_bus(hbus->pci_bus); pci_unlock_rescan_remove(); + hbus->state = hv_pcibus_removed; } ret = hv_send_resources_released(hdev); Patches currently in stable-queue which might be from longli(a)microsoft.com are queue-4.9/pci-hv-lock-pci-bus-on-device-eject.patch queue-4.9/pci-hv-properly-handle-pci-bus-remove.patch

7 years, 6 months

1
0
0 0

Patch "PCI: hv: Lock PCI bus on device eject" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled PCI: hv: Lock PCI bus on device eject to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: pci-hv-lock-pci-bus-on-device-eject.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Sun Mar 18 16:55:33 CET 2018 From: Long Li <longli(a)microsoft.com> Date: Thu, 23 Mar 2017 14:58:32 -0700 Subject: PCI: hv: Lock PCI bus on device eject From: Long Li <longli(a)microsoft.com> [ Upstream commit 414428c5da1c71986727c2fa5cdf1ed071e398d7 ] A PCI_EJECT message can arrive at the same time we are calling pci_scan_child_bus() in the workqueue for the previous PCI_BUS_RELATIONS message or in create_root_hv_pci_bus(). In this case we could potentially modify the bus from multiple places. Properly lock the bus access. Thanks Dexuan Cui <decui(a)microsoft.com> for pointing out the race condition in create_root_hv_pci_bus(). Reported-by: Xiaofeng Wang <xiaofwan(a)redhat.com> Signed-off-by: Long Li <longli(a)microsoft.com> Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com> Acked-by: K. Y. Srinivasan <kys(a)microsoft.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/pci/host/pci-hyperv.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/drivers/pci/host/pci-hyperv.c +++ b/drivers/pci/host/pci-hyperv.c @@ -1206,9 +1206,11 @@ static int create_root_hv_pci_bus(struct hbus->pci_bus->msi = &hbus->msi_chip; hbus->pci_bus->msi->dev = &hbus->hdev->device; + pci_lock_rescan_remove(); pci_scan_child_bus(hbus->pci_bus); pci_bus_assign_resources(hbus->pci_bus); pci_bus_add_devices(hbus->pci_bus); + pci_unlock_rescan_remove(); hbus->state = hv_pcibus_installed; return 0; } @@ -1597,8 +1599,10 @@ static void hv_eject_device_work(struct pdev = pci_get_domain_bus_and_slot(hpdev->hbus->sysdata.domain, 0, wslot); if (pdev) { + pci_lock_rescan_remove(); pci_stop_and_remove_bus_device(pdev); pci_dev_put(pdev); + pci_unlock_rescan_remove(); } memset(&ctxt, 0, sizeof(ctxt)); Patches currently in stable-queue which might be from longli(a)microsoft.com are queue-4.9/pci-hv-lock-pci-bus-on-device-eject.patch queue-4.9/pci-hv-properly-handle-pci-bus-remove.patch

7 years, 6 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror