From 3995614d9b0320e10ce202836c8477e1bcf1a2d4 Mon Sep 17 00:00:00 2001 From: Arnaldo Carvalho de Melo Date: Thu, 5 Mar 2015 15:27:28 -0300 Subject: perf annotate: Fix fallback to unparsed disassembler line When annotating source/disasm lines the perf tools parse the output of objdump, trying to provide augmented output that allows navigating jumps, calls, etc. But when a line output by objdump can't be parsed the annotation code falls back to just presenting the unparsed line. When fixing a leak in the 0fb9f2aab738 commit ("perf annotate: Fix memory leaks in LOCK handling") we failed to take that into account and instead tried to free one of the data structures that should be freed only when successfully allocated, oops, segfault. There was a change in the way the objdump output for lock prefixed instructions is formatted that lead the relevant parser to fail to grok it. At least RHEL7 works ok, but Fedora 20 segfaults. Fix it by making the ins__delete() destructor work like the most basic destructor: free(). Namely make it accept a NULL pointer and when handling it just do nothing. Further investigation is needed to figure out the nature of the objdump output change so as to make the parser grok it. Reported-by: Linus Torvalds Cc: David Ahern Cc: Jiri Olsa Cc: Namhyung Kim Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Rabin Vincent Link: http://lkml.kernel.org/n/tip-7wsy0zo292pif0yjoqpfryrz@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/util/annotate.c | 2 ++ 1 file changed, 2 insertions(+) (limited to 'tools') diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c index 61bf9128e1f2..9d9db3b296dd 100644 --- a/tools/perf/util/annotate.c +++ b/tools/perf/util/annotate.c @@ -30,6 +30,8 @@ static int disasm_line__parse(char *line, char **namep, char **rawp); static void ins__delete(struct ins_operands *ops) { + if (ops == NULL) + return; zfree(&ops->source.raw); zfree(&ops->source.name); zfree(&ops->target.raw); -- cgit v1.2.1 From 9a0b57451ae8142c74d65bddb6d7765818babbed Mon Sep 17 00:00:00 2001 From: Michael Ellerman Date: Tue, 3 Feb 2015 14:53:08 +1100 Subject: selftests/exec: Check if the syscall exists and bail if not On systems which don't implement sys_execveat(), this test produces a lot of output. Add a check at the beginning to see if the syscall is present, and if not just note one error and return. When we run on a system that doesn't implement the syscall we will get ENOSYS back from the kernel, so change the logic that handles __NR_execveat not being defined to also use ENOSYS rather than -ENOSYS. Signed-off-by: Michael Ellerman Acked-by: David Drysdale Signed-off-by: Shuah Khan --- tools/testing/selftests/exec/execveat.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) (limited to 'tools') diff --git a/tools/testing/selftests/exec/execveat.c b/tools/testing/selftests/exec/execveat.c index e238c9559caf..8d5d1d2ee7c1 100644 --- a/tools/testing/selftests/exec/execveat.c +++ b/tools/testing/selftests/exec/execveat.c @@ -30,7 +30,7 @@ static int execveat_(int fd, const char *path, char **argv, char **envp, #ifdef __NR_execveat return syscall(__NR_execveat, fd, path, argv, envp, flags); #else - errno = -ENOSYS; + errno = ENOSYS; return -1; #endif } @@ -234,6 +234,14 @@ static int run_tests(void) int fd_cloexec = open_or_die("execveat", O_RDONLY|O_CLOEXEC); int fd_script_cloexec = open_or_die("script", O_RDONLY|O_CLOEXEC); + /* Check if we have execveat at all, and bail early if not */ + errno = 0; + execveat_(-1, NULL, NULL, NULL, 0); + if (errno == ENOSYS) { + printf("[FAIL] ENOSYS calling execveat - no kernel support?\n"); + return 1; + } + /* Change file position to confirm it doesn't affect anything */ lseek(fd, 10, SEEK_SET); -- cgit v1.2.1 From b8ea351b0e154c9dc28609db58eddc6c2934c954 Mon Sep 17 00:00:00 2001 From: Josh Boyer Date: Tue, 10 Mar 2015 20:26:36 -0400 Subject: Revert "cpupower Makefile change to help run the tool without 'make install'" This reverts commit 5c1de006e8e66b0be05be422416629e344c71652. While the original commit makes it easier to run cpupower from the local build directory, it also leaves the binary with a rather poor rpath of './' in it after it is installed on a system via 'make install'. This is considered bad practice and can cause cpupower to fail in rpmbuild with the following error: ERROR 0004: file '/usr/bin/cpupower' contains an insecure rpath './' in [./] error: Bad exit status from /var/tmp/rpm-tmp.A6u26r (%install) Bad exit status from /var/tmp/rpm-tmp.A6u26r (%install) Developers should be able to use LD_LIBRARY_PATH to achieve the same effect and not introduce rpath into the binary. Signed-off-by: Josh Boyer Signed-off-by: Rafael J. Wysocki --- tools/power/cpupower/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'tools') diff --git a/tools/power/cpupower/Makefile b/tools/power/cpupower/Makefile index 3ed7c0476d48..2e2ba2efa0d9 100644 --- a/tools/power/cpupower/Makefile +++ b/tools/power/cpupower/Makefile @@ -209,7 +209,7 @@ $(OUTPUT)%.o: %.c $(OUTPUT)cpupower: $(UTIL_OBJS) $(OUTPUT)libcpupower.so.$(LIB_MAJ) $(ECHO) " CC " $@ - $(QUIET) $(CC) $(CFLAGS) $(LDFLAGS) $(UTIL_OBJS) -lcpupower -Wl,-rpath=./ -lrt -lpci -L$(OUTPUT) -o $@ + $(QUIET) $(CC) $(CFLAGS) $(LDFLAGS) $(UTIL_OBJS) -lcpupower -lrt -lpci -L$(OUTPUT) -o $@ $(QUIET) $(STRIPCMD) $@ $(OUTPUT)po/$(PACKAGE).pot: $(UTIL_SRC) -- cgit v1.2.1