- 18 Jul, 2016 14 commits
-
-
Jiri Olsa authored
It's used from 2 objects in perf, so it's better to keep just one copy. Signed-off-by:
Jiri Olsa <jolsa@kernel.org> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Pirko <jiri@mellanox.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Steven Rostedt <rostedt@goodmis.org> Link: http://lkml.kernel.org/r/1468685480-18951-3-git-send-email-jolsa@kernel.orgSigned-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com>
-
Jiri Olsa authored
Jirka reported that python code returns all arrays as strings. This makes impossible to get all items for byte array tracepoint field containing 0x00 value item. Fixing this by scanning full length of the array and returning it as PyByteArray object in case non printable byte is found. Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Cc: David Ahern <dsahern@gmail.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Steven Rostedt <rostedt@goodmis.org> Link: http://lkml.kernel.org/r/1468685480-18951-2-git-send-email-jolsa@kernel.orgSigned-off-by:
-
Masami Hiramatsu authored
Warn unmatched function filter correctly instead of warning "symbol-loading error", since that can be a filter issue. From the technical point of view, this adds a filter chech in map__load and if there is a filter, it returns -2 (filter-out), instead of -1 (error), and perf-probe checks it and change message. E.g. without this fix: # perf probe -F rt_sp* no symbols found in [kernel.kallsyms], maybe install a debug package? Failed to load symbols in kernel With this fix: # perf probe -F rt_sp* no symbols passed the given filter. Failed to find symbols matched to "rt_sp*" Error: Failed to show functions. Reported-and-Tested-by:Masami Hiramatsu <mhiramat@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/146885835596.16106.2293540792775552481.stgit@devboxSigned-off-by:
-
Mark Rutland authored
In some cases it's necessry to figure out the map-local index of a given Linux logical CPU ID. Add a new helper, cpu_map__idx, to acquire this. As the logic is largely the same as the existing cpu_map__has, this is rewritten in terms of the new helper. At the same time, add the inverse operation, cpu_map__cpu, which yields the logical CPU id for a map-local index. While this can be performed manually, wrapping this in a helper can make code more legible. Signed-off-by:
Mark Rutland <mark.rutland@arm.com> Acked-by:
-
Mark Rutland authored
In create_perf_stat_counter, when a target CPU has not been provided, we call __perf_evsel__open with empty_cpu_map, and open a single FD per thread. However, in read_counter we assume that we opened events for the product of threads and CPUs described in the evsel's cpu_map. Thus, if an evsel has a cpu_map with more than one entry, we will attempt to access FDs that we didn't open. This could result in a number of problems (e.g. blocking while reading from STDIN if the fd memory happened to be initialised to zero). This is problematic for systems were a logical CPU PMU covers some arbitrary subset of CPUs. The cpu_map of any evsel for that PMU will be initialised based on the cpumask exposed through sysfs, even if the user requests per-thread events. Signed-off-by:
-
Arnaldo Carvalho de Melo authored
We were also using this directly from the kernel sources, the two last cases, fix it. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Wang Nan <wangnan0@huawei.com> Link: http://lkml.kernel.org/n/tip-7o14xvacqcjc5llc7gvjjyl8@git.kernel.orgSigned-off-by:
-
Arnaldo Carvalho de Melo authored
It hasn't been used since we made tools/ self sufficiente wrt list.h. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Wang Nan <wangnan0@huawei.com> Fixes: d1b39d41 ("tools: Make list.h self-sufficient") Link: http://lkml.kernel.org/n/tip-w20ueqlf22kh7ctjqo0zjpig@git.kernel.orgSigned-off-by:
-
Arnaldo Carvalho de Melo authored
copy some more kernel files accessed from tools/, check for drift. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Wang Nan <wangnan0@huawei.com> Link: http://lkml.kernel.org/n/tip-omz8xdyvvxgjiuqzwj6ecm6j@git.kernel.orgSigned-off-by:
-
Arnaldo Carvalho de Melo authored
No need to copy it to a detached tarball as they aren't used anymore Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Wang Nan <wangnan0@huawei.com> Link: http://lkml.kernel.org/n/tip-lopmaqi439ke10g1j9cxrxwt@git.kernel.orgSigned-off-by:
-
Arnaldo Carvalho de Melo authored
Not used anymore, remove one more file referencing kernel sources, i.e. outside of tools/ Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Wang Nan <wangnan0@huawei.com> Link: http://lkml.kernel.org/n/tip-ykfjt3t8l0npxfwmekiwwyu6@git.kernel.orgSigned-off-by:
-
Arnaldo Carvalho de Melo authored
Not used anymore. This also stops include linux/swab.h directly from the kernel sources, remove that reference from the MANIFEST. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Wang Nan <wangnan0@huawei.com> Signed-off-by: -
Arnaldo Carvalho de Melo authored
It uses the likely/unlikely macros, so need to include <linux/compiler.h>. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Wang Nan <wangnan0@huawei.com> Link: http://lkml.kernel.org/n/tip-p0xrhgbkicsii9ohmhhprqpi@git.kernel.orgSigned-off-by:
-
Dan Carpenter authored
The 'info.e_machine' struct member is an uint16_t so 'm' is never less than zero. It looks like this was maybe left over code from earlier versions so I've just removed it. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: kernel-janitors@vger.kernel.org Link: http://lkml.kernel.org/r/20160715210836.GB19522@mwandaSigned-off-by:
-
Dan Carpenter authored
It doesn't change the runtime behavior, but my static checker complains that curly braces were intended. Signed-off-by:
-
- 16 Jul, 2016 1 commit
-
-
Ingo Molnar authored
Merge tag 'perf-core-for-mingo-20160715' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core Pull perf/core improvements and fixes from Arnaldo Carvalho de Melo: User visible changes: - Allow reading from a backward ring buffer (one setup via sys_perf_event_open() with perf_event_attr.write_backward = 1) (Wang Nan) Infrastructure changes: - Fix the build on Android NDK r12b (initially just for ARM), that is now port of my perf-build container collection and will get tested prior to sending patches upstream (Arnaldo Carvalho de Melo) - Add correct header for IPv6 definitions - Fix bitsperlong.h fallout (Arnaldo Carvalho de Melo, Peter Zijlstra) - Use base 0 (auto) in filename__read_ull(), so that we can handle hex values too (Jiri Olsa) Signed-off-by:
Ingo Molnar <mingo@kernel.org>
-
- 15 Jul, 2016 21 commits
-
-
Arnaldo Carvalho de Melo authored
gcc version 4.1.2 20080704 (Red Hat 4.1.2-55) barfs with: CC /tmp/build/objtool/builtin-check.o cc1: warnings being treated as errors builtin-check.c: In function 'cmd_check': builtin-check.c:667: warning: 'prev_rela' may be used uninitialized in this function mv: cannot stat `/tmp/build/objtool/.builtin-check.o.tmp': No such file or directory make[1]: *** [/tmp/build/objtool/builtin-check.o] Error 1 Init it to NULL to silence it. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Wang Nan <wangnan0@huawei.com> Link: http://lkml.kernel.org/n/tip-qolo31rl2ojlwj1lj9dhemyz@git.kernel.orgSigned-off-by: -
Arnaldo Carvalho de Melo authored
So that it can find asm/bitsperlong.h to get the __BITS_PER_LONG definition. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Wang Nan <wangnan0@huawei.com> Link: http://lkml.kernel.org/n/tip-pr3pvskh65pey4po7t122z4j@git.kernel.orgSigned-off-by:
-
Wang Nan authored
When working with overwritable ring buffer there's a inconvenience problem: if perf dumps data after a long period after it starts, non-sample events may lost, which makes following 'perf report' unable to identify proc name and mmap layout. For example: # perf record -m 4 -e raw_syscalls:* -g --overwrite --switch-output \ dd if=/dev/zero of=/dev/null send SIGUSR2 after dd runs long enough. The resuling perf.data lost correct comm and mmap events: # perf script -i perf.data.2016061522374354 perf 24478 [004] 2581325.601789: raw_syscalls:sys_exit: NR 0 = 512 ^^^^ Should be 'dd' 27b2e8 syscall_slow_exit_work+0xfe2000e3 (/lib/modules/4.6.0-rc3+/build/vmlinux) 203cc7 do_syscall_64+0xfe200117 (/lib/modules/4.6.0-rc3+/build/vmlinux) b18d83 return_from_SYSCALL_64+0xfe200000 (/lib/modules/4.6.0-rc3+/build/vmlinux) 7f47c417edf0 [unknown] ([unknown]) ^^^^^^^^^^^^ Fail to unwind This patch provides a '--tail-synthesize' option, allows perf to collect system status when finalizing output file. In resuling output file, the non-sample events reflect system status when dumping data. After this patch: # perf record -m 4 -e raw_syscalls:* -g --overwrite --switch-output --tail-synthesize \ dd if=/dev/zero of=/dev/null # perf script -i perf.data.2016061600544998 dd 27364 [004] 2583244.994464: raw_syscalls:sys_enter: NR 1 (1, ... ^^ Correct comm 203a18 syscall_trace_enter_phase2+0xfe2001a8 ([kernel.kallsyms]) 203aa5 syscall_trace_enter+0xfe200055 ([kernel.kallsyms]) 203caa do_syscall_64+0xfe2000fa ([kernel.kallsyms]) b18d83 return_from_SYSCALL_64+0xfe200000 ([kernel.kallsyms]) d8e50 __GI___libc_write+0xffff01d9639f4010 (/tmp/oxygen_root-w00229757/lib64/libc-2.18.so) ^^^^^ Correct unwind This option doesn't aim to solve this problem completely. If a process terminates before SIGUSR2, we still lost its COMM and MMAP events. For example, we can't unwind correctly from the final perf.data we get from the previous example, because when perf collects the final output file (when we press C-c), 'dd' has been terminated so its '/proc/<pid>/mmap' becomes empty. However, this is a cheaper choice. To completely solve this problem we need to continously output non-sample events. To satisify the requirement of daemonization, we need to merge them periodically. It is possible but requires much more code and cycles. Automatically select --tail-synthesize when --overwrite is provided. Signed-off-by:Wang Nan <wangnan0@huawei.com> Cc: He Kuang <hekuang@huawei.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Nilay Vaish <nilayvaish@gmail.com> Cc: Zefan Li <lizefan@huawei.com> Cc: pi3orama@163.com Link: http://lkml.kernel.org/r/1468485287-33422-16-git-send-email-wangnan0@huawei.comSigned-off-by:
-
Wang Nan authored
If write_backward attribute is set, records are written into kernel ring buffer from end to beginning, but read from beginning to end. To avoid 'XX out of order events recorded' warning message (timestamps of records is in reverse order when using write_backward), suppress the warning message if write_backward is selected by at lease one event. Result: Before this patch: # perf record -m 1 -e raw_syscalls:sys_exit/overwrite/ \ -e raw_syscalls:sys_enter \ dd if=/dev/zero of=/dev/null count=300 300+0 records in 300+0 records out 153600 bytes (154 kB) copied, 0.000601617 s, 255 MB/s [ perf record: Woken up 5 times to write data ] Warning: 40 out of order events recorded. [ perf record: Captured and wrote 0.096 MB perf.data (696 samples) ] After this patch: # perf record -m 1 -e raw_syscalls:sys_exit/overwrite/ \ -e raw_syscalls:sys_enter \ dd if=/dev/zero of=/dev/null count=300 300+0 records in 300+0 records out 153600 bytes (154 kB) copied, 0.000644873 s, 238 MB/s [ perf record: Woken up 5 times to write data ] [ perf record: Captured and wrote 0.096 MB perf.data (696 samples) ] Signed-off-by:He Kuang <hekuang@huawei.com> Signed-off-by:
-
Wang Nan authored
This patch allows following config terms and option: Globally setting events to overwrite; # perf record --overwrite ... Set specific events to be overwrite or no-overwrite. # perf record --event cycles/overwrite/ ... # perf record --event cycles/no-overwrite/ ... Add missing config terms and update the config term array size because the longest string length has changed. For overwritable events, it automatically selects attr.write_backward since perf requires it to be backward for reading. Test result: # perf record --overwrite -e syscalls:*enter_nanosleep* usleep 1 [ perf record: Woken up 2 times to write data ] [ perf record: Captured and wrote 0.011 MB perf.data (1 samples) ] # perf evlist -v syscalls:sys_enter_nanosleep: type: 2, size: 112, config: 0x134, { sample_period, sample_freq }: 1, sample_type: IP|TID|TIME|CPU|PERIOD|RAW, disabled: 1, inherit: 1, mmap: 1, comm: 1, enable_on_exec: 1, task: 1, sample_id_all: 1, exclude_guest: 1, mmap2: 1, comm_exec: 1, write_backward: 1 # Tip: use 'perf evlist --trace-fields' to show fields for tracepoint events Signed-off-by: -
Wang Nan authored
There's no user of these two function outside evlist.c. Remove them from public namespace. Signed-off-by:
-
Wang Nan authored
Drive the evlist->bkw_mmap_state state machine during draining and when SIGUSR2 is received. Read the backward ring buffer in record__mmap_read_all. Signed-off-by:
-
Wang Nan authored
Introduce a bkw_mmap_state state machine to evlist: .________________(forbid)_____________. | V NOTREADY --(0)--> RUNNING --(1)--> DATA_PENDING --(2)--> EMPTY ^ ^ | ^ | | |__(forbid)____/ |___(forbid)___/| | | \_________________(3)_______________/ NOTREADY : Backward ring buffers are not ready RUNNING : Backward ring buffers are recording DATA_PENDING : We are required to collect data from backward ring buffers EMPTY : We have collected data from backward ring buffers. (0): Setup backward ring buffer (1): Pause ring buffers for reading (2): Read from ring buffers (3): Resume ring buffers for recording We can't avoid this complexity. Since we deliberately drop records from overwritable ring buffer, there's no way for us to check remaining from ring buffer itself (by checking head and old pointers). Therefore, we need DATA_PENDING and EMPTY state to help us recording what we have done to the ring buffer. In record__mmap_read_evlist(), drive this state machine from DATA_PENDING to EMPTY. In perf_evlist__mmap_per_evsel(), drive this state machine from NOTREADY to RUNNING when creating backward mmap. Signed-off-by: -
Wang Nan authored
Now there's no real user of evlist->backward. Drop it. We are going to use evlist->backward_mmap as a container for backward ring buffer. Signed-off-by:
-
Wang Nan authored
In perf_evlist__mmap_per_evsel(), select backward_mmap for backward events. Utilize new perf_mmap APIs. Dynamically alloc backward_mmap. Remove useless functions. Signed-off-by:
-
Wang Nan authored
Add backward_mmap to evlist, free it together with normal mmap. Improve perf_evlist__pick_pc(), search backward_mmap if evlist->mmap is not available. This patch doesn't alloc this array. It will be allocated conditionally in the following commits. Signed-off-by:
-
Wang Nan authored
In perf_evlist__mmap_per_cpu() and perf_evlist__mmap_per_thread(), in case of mmap failure, successfully created maps should be cleared. Current code uses two loops calling __perf_evlist__munmap() for each function. This patch extracts common code to perf_evlist__munmap_nofree() and use previous introduced decoupled API perf_mmap__munmap(). Now __perf_evlist__munmap() can be removed because of no user. Signed-off-by:
-
Wang Nan authored
Insetad of saving a index into fdarray entries private field, save the corresponding 'struct perf_mmap' pointer, and release them directly using perf_mmap__put(). Following commits introduce multiple mmap arrays to evlist. Without this patch, perf_evlist__munmap_filtered() is unable to retrive correct 'struct perf_mmap' pointer. Signed-off-by:
-
Wang Nan authored
Perf evlist will have multiple mmap arrays. Update record__mmap_read(): it should read from 'struct perf_mmap' directly. Also, make record__mmap_read() ready to read from backward ring buffer. Signed-off-by:
-
Wang Nan authored
Currently, the evlist mmap related helpers and APIs accept evlist and idx, and dereference 'struct perf_mmap' by evlist->mmap[idx]. This is unnecessary, and force each evlist contains only one mmap array. Following commits are going to introduce multiple mmap arrays to a evlist. This patch refators these APIs and helpers, introduces functions accept perf_mmap pointer directly. New helpers and APIs are decoupled with perf_evlist, and become perf_mmap functions (so they have perf_mmap prefix). Old functions are reimplemented with new functions. Some of them will be removed in following commits. Signed-off-by:
-
Wang Nan authored
Add a 'ptr' field to fdarray->priv array. This feature will be used by following commits, which introduce muiltiple 'struct perf_mmap' arrays for different types of mapping. Because of this, during fdarray__filter(), a simple 'idx' is not enough. Add a pointer cookie that allows to directly associate a 'struct perf_mmap' pointer to an fdarray entry. Signed-off-by:
-
Peter Zijlstra authored
Do it using (__CHAR_BIT__ * __SIZEOF_LONG__), simpler, works everywhere, reduces the complexity by ditching CONFIG_64BIT, that was being synthesized from yet another set of defines, which proved fragile, breaking the build on linux-next for no obvious reasons. Committer Note: Except on: gcc version 4.1.2 20080704 (Red Hat 4.1.2-55) Fallback to __WORDSIZE in that case... Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
Peter Zijlstra <peterz@infradead.org> Tested-by:
-
Arnaldo Carvalho de Melo authored
evsel->overwrite indicator means an event should be put into overwritable ring buffer. In current implementation, it equals to evsel->attr.write_backward. To reduce compliexity, remove evsel->overwrite, use evsel->attr.write_backward instead. In addition, in __perf_evsel__open(), if kernel doesn't support write_backward and user explicitly set it in evsel, don't fallback like other missing feature, since it is meaningless to fall back to a forward ring buffer in this case: we are unable to stably read from an forward overwritable ring buffer. Cc: He Kuang <hekuang@huawei.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Nilay Vaish <nilayvaish@gmail.com> Cc: Wang Nan <wangnan0@huawei.com> Cc: Zefan Li <lizefan@huawei.com> Cc: pi3orama@163.com Link: http://lkml.kernel.org/r/1468485287-33422-2-git-send-email-wangnan0@huawei.comSigned-off-by:
-
Jiri Olsa authored
By using 0 for base, the strtoull() detects the base automatically (see 'man strtoull'). ATM we have just one user of this function, the cpu__get_max_freq function reading the "cpuinfo_max_freq" sysfs file. It should not get affected by this change. Committer note: This change seems motivated by this discussion: "[PATCH] [RFC V1]s390/perf: fix 'start' address of module's map" http://lkml.kernel.org/r/20160711120155.GA29929@krava I.e. this patches paves the way for filename__read_ull() to be used in a S/390 related fix. Signed-off-by:
-
Arnaldo Carvalho de Melo authored
There are cases where further work would be needed to overcome the fact that neither sysconf(_SC_LEVEL1_DCACHE_LINESIZE) nor /sys/devices/system/cpu/cpu0/cache/index0/coherency_line_size are available in some systems (Android, for instance), so bail out when such a situation takes place. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Wang Nan <wangnan0@huawei.com> Link: http://lkml.kernel.org/n/tip-ho8d8g8mh0o2dri7ckcccafi@git.kernel.orgSigned-off-by:
-
Arnaldo Carvalho de Melo authored
So far the cacheline_size is only useful for the "dcacheline" --sort order, i.e. if that is not used, which is the norm, then the user shouldn't care that he is running this, say, on an Android system where sysconf(_SC_LEVEL1_DCACHE_LINESIZE) and the /sys/devices/system/cpu/cpu0/cache/index0/coherency_line_size sysfs file isn't available. An upcoming patch will emit an warning only for "--sort ...,dcacheline,...". Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Chris Phlipot <cphlipot0@gmail.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Wang Nan <wangnan0@huawei.com> Link: http://lkml.kernel.org/n/tip-580cnkvftunyvt9n7unsholi@git.kernel.orgSigned-off-by:
-
- 14 Jul, 2016 4 commits
-
-
Arnaldo Carvalho de Melo authored
As the gcc there is producing tons of: "warning: always_inline function might not be inlinable" At least on android-ndk-r12/platforms/android-24/arch-arm, so, for the time being, use this big hammer. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Chris Phlipot <cphlipot0@gmail.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Wang Nan <wangnan0@huawei.com> Link: http://lkml.kernel.org/n/tip-97l3eg3fnk5shmo4rsyyvj2t@git.kernel.orgSigned-off-by:
-
Arnaldo Carvalho de Melo authored
The Bionic libc has this definition, so don't duplicate it. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Chris Phlipot <cphlipot0@gmail.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Wang Nan <wangnan0@huawei.com> Link: http://lkml.kernel.org/n/tip-rmd19832zkt07e4crdzyen9z@git.kernel.orgSigned-off-by:
-
Arnaldo Carvalho de Melo authored
We need to include netinet/in.h to get the in6_addr struct definition, needed to build it on the Android NDK: In file included from event-parse.c:36:0: /home/acme/android/android-ndk-r12/platforms/android-24/arch-arm/usr/include/netinet/ip6.h:82:18: error: field 'ip6_src' has incomplete type struct in6_addr ip6_src; /* source address */ And it is the canonical way of getting IPv6 definitions, as described, for instance, in Linux's 'man ipv6' Doing that uncovers another problem: this source file uses PRIu64 but doesn't include it, depending on it being included by chance via the now replaced header (netinet/ip6.h), fix it. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Chris Phlipot <cphlipot0@gmail.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Wang Nan <wangnan0@huawei.com> Link: http://lkml.kernel.org/n/tip-tilr31n3yaba1whsd47qlwa3@git.kernel.orgSigned-off-by: -
Ingo Molnar authored
Merge tag 'perf-core-for-mingo-20160713' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core Pull perf/core improvements and fixes from Arnaldo Carvalho de Melo: User visible changes: - Finish merging initial SDT (Statically Defined Traces) support, see cset comments for details about how it all works (Masami Hiramatsu) - Support attaching eBPF programs to tracepoints (Wang Nan) Infrastructure changes: - Fix up BITS_PER_LONG setting (Arnaldo Carvalho de Melo) - Add fallback from ELF_C_READ_MMAP to ELF_C_READ in objtool, fixing the build in libelf implementations lacking that elf_begin() cmd, such as Alpine Linux's (Arnaldo Carvalho de Melo) - Avoid checking code drift on busybox's diff in objtool (Arnaldo Carvalho de Melo) Signed-off-by:
-
