November 2018 - Linux-stable-mirror

[PATCH 2/2] btrfs: run delayed items before dropping the snapshot

by Josef Bacik

From: Josef Bacik <jbacik(a)fb.com> With my delayed refs patches in place we started seeing a large amount of aborts in __btrfs_free_extent BTRFS error (device sdb1): unable to find ref byte nr 91947008 parent 0 root 35964 owner 1 offset 0 Call Trace: ? btrfs_merge_delayed_refs+0xaf/0x340 __btrfs_run_delayed_refs+0x6ea/0xfc0 ? btrfs_set_path_blocking+0x31/0x60 btrfs_run_delayed_refs+0xeb/0x180 btrfs_commit_transaction+0x179/0x7f0 ? btrfs_check_space_for_delayed_refs+0x30/0x50 ? should_end_transaction.isra.19+0xe/0x40 btrfs_drop_snapshot+0x41c/0x7c0 btrfs_clean_one_deleted_snapshot+0xb5/0xd0 cleaner_kthread+0xf6/0x120 kthread+0xf8/0x130 ? btree_invalidatepage+0x90/0x90 ? kthread_bind+0x10/0x10 ret_from_fork+0x35/0x40 This was because btrfs_drop_snapshot depends on the root not being modified while it's dropping the snapshot. It will unlock the root node (and really every node) as it walks down the tree, only to re-lock it when it needs to do something. This is a problem because if we modify the tree we could cow a block in our path, which free's our reference to that block. Then once we get back to that shared block we'll free our reference to it again, and get ENOENT when trying to lookup our extent reference to that block in __btrfs_free_extent. This is ultimately happening because we have delayed items left to be processed for our deleted snapshot _after_ all of the inodes are closed for the snapshot. We only run the delayed inode item if we're deleting the inode, and even then we do not run the delayed insertions or delayed removals. These can be run at any point after our final inode does it's last iput, which is what triggers the snapshot deletion. We can end up with the snapshot deletion happening and then have the delayed items run on that file system, resulting in the above problem. This problem has existed forever, however my patches made it much easier to hit as I wake up the cleaner much more often to deal with delayed iputs, which made us more likely to start the snapshot dropping work before the transaction commits, which is when the delayed items would generally be run. Before, generally speaking, we would run the delayed items, commit the transaction, and wakeup the cleaner thread to start deleting snapshots, which means we were less likely to hit this problem. You could still hit it if you had multiple snapshots to be deleted and ended up with lots of delayed items, but it was definitely harder. Fix for now by simply running all the delayed items before starting to drop the snapshot. We could make this smarter in the future by making the delayed items per-root, and then simply drop any delayed items for roots that we are going to delete. But for now just a quick and easy solution is the safest. Cc: stable(a)vger.kernel.org Signed-off-by: Josef Bacik <josef(a)toxicpanda.com> --- fs/btrfs/extent-tree.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c index dcb699dd57f3..965702034b22 100644 --- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/extent-tree.c @@ -9330,6 +9330,8 @@ int btrfs_drop_snapshot(struct btrfs_root *root, goto out_free; } + btrfs_run_delayed_items(trans); + if (block_rsv) trans->block_rsv = block_rsv; -- 2.14.3

5 years, 6 months

2
2
0 0

stable-rc/linux-4.19.y boot: 128 boots: 0 failed, 125 passed with 3 offline (v4.19.5-107-g048192fdfd84)

by kernelci.org bot

stable-rc/linux-4.19.y boot: 128 boots: 0 failed, 125 passed with 3 offline (v4.19.5-107-g048192fdfd84) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.19.y/kernel/v4.1… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.19.y/kernel/v4.19.5-107… Tree: stable-rc Branch: linux-4.19.y Git Describe: v4.19.5-107-g048192fdfd84 Git Commit: 048192fdfd8468e130937cd697f117a144fa71e9 Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 66 unique boards, 23 SoC families, 15 builds out of 202 Offline Platforms: arm: multi_v7_defconfig: stih410-b2120: 1 offline lab arm64: defconfig: meson-gxl-s905d-p230: 1 offline lab meson-gxl-s905x-p212: 1 offline lab --- For more info write to <info(a)kernelci.org>

5 years, 6 months

1
0
0 0

stable-rc/linux-4.9.y boot: 114 boots: 0 failed, 112 passed with 1 offline, 1 conflict (v4.9.141-91-gdc9fc9db643c)

by kernelci.org bot

stable-rc/linux-4.9.y boot: 114 boots: 0 failed, 112 passed with 1 offline, 1 conflict (v4.9.141-91-gdc9fc9db643c) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.9.y/kernel/v4.9.… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.9.y/kernel/v4.9.141-91-… Tree: stable-rc Branch: linux-4.9.y Git Describe: v4.9.141-91-gdc9fc9db643c Git Commit: dc9fc9db643c21aa7e4bdb297ebae94afed0a9e2 Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 51 unique boards, 21 SoC families, 16 builds out of 193 Boot Regressions Detected: arm64: defconfig: meson-gxbb-p200: lab-baylibre: new failure (last pass: v4.9.141-93-gf46aebe62697) Offline Platforms: arm: multi_v7_defconfig: stih410-b2120: 1 offline lab Conflicting Boot Failure Detected: (These likely are not failures as other labs are reporting PASS. Needs review.) arm64: defconfig: meson-gxbb-p200: lab-baylibre: FAIL lab-baylibre-seattle: PASS --- For more info write to <info(a)kernelci.org>

5 years, 6 months

1
0
0 0

stable-rc/linux-4.4.y boot: 105 boots: 1 failed, 102 passed with 1 offline, 1 untried/unknown (v4.4.165-85-gf00ba91a41ec)

by kernelci.org bot

stable-rc/linux-4.4.y boot: 105 boots: 1 failed, 102 passed with 1 offline, 1 untried/unknown (v4.4.165-85-gf00ba91a41ec) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.165-85-… Tree: stable-rc Branch: linux-4.4.y Git Describe: v4.4.165-85-gf00ba91a41ec Git Commit: f00ba91a41ec3c7d118e82e5d963c3b638dd458c Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 46 unique boards, 20 SoC families, 15 builds out of 187 Boot Failure Detected: arm64: defconfig qcom-qdf2400: 1 failed lab Offline Platforms: arm: multi_v7_defconfig: stih410-b2120: 1 offline lab --- For more info write to <info(a)kernelci.org>

5 years, 6 months

1
0
0 0

stable-rc/linux-3.18.y boot: 66 boots: 5 failed, 61 passed (v3.18.127-83-gc3953c334bf6)

by kernelci.org bot

stable-rc/linux-3.18.y boot: 66 boots: 5 failed, 61 passed (v3.18.127-83-gc3953c334bf6) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-3.18.y/kernel/v3.1… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-3.18.y/kernel/v3.18.127-8… Tree: stable-rc Branch: linux-3.18.y Git Describe: v3.18.127-83-gc3953c334bf6 Git Commit: c3953c334bf69d55078523ec935831a28dee8134 Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 26 unique boards, 12 SoC families, 14 builds out of 185 Boot Failures Detected: arm: exynos_defconfig exynos4412-odroidx2: 1 failed lab x86: x86_64_defconfig qemu: 3 failed labs x86-atom330: 1 failed lab --- For more info write to <info(a)kernelci.org>

5 years, 6 months

1
0
0 0

PASS: Test report for kernel 4.19.6-rc2.skt+ (linux-stable-rc)

by CKI

Hello, We ran automated tests on a recent commit from this kernel tree: Kernel repo: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Commit: 048192fdfd84 Linux 4.19.6-rc2 The results of these automated tests are provided below. Overall result: PASSED Patch merge: OK Compile: OK Kernel tests: OK Please reply to this email if you have any questions about the tests that we ran or if you have any suggestions on how to make future tests more effective. ,-. ,-. ( C ) ( K ) Continuous `-',-.`-' Kernel ( I ) Integration `-' ______________________________________________________________________________ Compile testing --------------- We compiled the kernel for 2 architectures: x86_64: make options: make INSTALL_MOD_STRIP=1 -j56 targz-pkg configuration: https://artifacts.cki-project.org/builds/x86_64/048192fdfd8468e130937cd697f… aarch64: make options: make INSTALL_MOD_STRIP=1 -j56 targz-pkg configuration: https://artifacts.cki-project.org/builds/aarch64/048192fdfd8468e130937cd697… Hardware testing ---------------- We booted each kernel and ran the following tests: x86_64: /distribution/kpkginstall (boot test) LTP lite - release 20180515 xfstests: ext4 xfstests: xfs /kernel/misc/amtu arm64: /distribution/kpkginstall (boot test) LTP lite - release 20180515 xfstests: ext4 xfstests: xfs /kernel/misc/amtu

5 years, 6 months

1
0
0 0

[PATCH 09/22] perf script: Use fallbacks for branch stacks

by Arnaldo Carvalho de Melo

From: Adrian Hunter <adrian.hunter(a)intel.com> Branch stacks do not necessarily have the same cpumode as the 'ip'. Use the fallback functions in those cases. This patch depends on patch "perf tools: Add fallback functions for cases where cpumode is insufficient". Signed-off-by: Adrian Hunter <adrian.hunter(a)intel.com> Cc: Andi Kleen <ak(a)linux.intel.com> Cc: David S. Miller <davem(a)davemloft.net> Cc: Jiri Olsa <jolsa(a)redhat.com> Cc: Leo Yan <leo.yan(a)linaro.org> Cc: Mathieu Poirier <mathieu.poirier(a)linaro.org> Cc: stable(a)vger.kernel.org Link: http://lkml.kernel.org/r/20181106210712.12098-4-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> --- tools/perf/builtin-script.c | 12 ++++++------ .../util/scripting-engines/trace-event-python.c | 16 ++++++++-------- 2 files changed, 14 insertions(+), 14 deletions(-) diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c index 04913136bac9..3ea98fe72f7f 100644 --- a/tools/perf/builtin-script.c +++ b/tools/perf/builtin-script.c @@ -724,8 +724,8 @@ static int perf_sample__fprintf_brstack(struct perf_sample *sample, if (PRINT_FIELD(DSO)) { memset(&alf, 0, sizeof(alf)); memset(&alt, 0, sizeof(alt)); - thread__find_map(thread, sample->cpumode, from, &alf); - thread__find_map(thread, sample->cpumode, to, &alt); + thread__find_map_fb(thread, sample->cpumode, from, &alf); + thread__find_map_fb(thread, sample->cpumode, to, &alt); } printed += fprintf(fp, " 0x%"PRIx64, from); @@ -771,8 +771,8 @@ static int perf_sample__fprintf_brstacksym(struct perf_sample *sample, from = br->entries[i].from; to = br->entries[i].to; - thread__find_symbol(thread, sample->cpumode, from, &alf); - thread__find_symbol(thread, sample->cpumode, to, &alt); + thread__find_symbol_fb(thread, sample->cpumode, from, &alf); + thread__find_symbol_fb(thread, sample->cpumode, to, &alt); printed += symbol__fprintf_symname_offs(alf.sym, &alf, fp); if (PRINT_FIELD(DSO)) { @@ -816,11 +816,11 @@ static int perf_sample__fprintf_brstackoff(struct perf_sample *sample, from = br->entries[i].from; to = br->entries[i].to; - if (thread__find_map(thread, sample->cpumode, from, &alf) && + if (thread__find_map_fb(thread, sample->cpumode, from, &alf) && !alf.map->dso->adjust_symbols) from = map__map_ip(alf.map, from); - if (thread__find_map(thread, sample->cpumode, to, &alt) && + if (thread__find_map_fb(thread, sample->cpumode, to, &alt) && !alt.map->dso->adjust_symbols) to = map__map_ip(alt.map, to); diff --git a/tools/perf/util/scripting-engines/trace-event-python.c b/tools/perf/util/scripting-engines/trace-event-python.c index 69aa93d4ee99..0c4b050f6fc2 100644 --- a/tools/perf/util/scripting-engines/trace-event-python.c +++ b/tools/perf/util/scripting-engines/trace-event-python.c @@ -494,14 +494,14 @@ static PyObject *python_process_brstack(struct perf_sample *sample, pydict_set_item_string_decref(pyelem, "cycles", PyLong_FromUnsignedLongLong(br->entries[i].flags.cycles)); - thread__find_map(thread, sample->cpumode, - br->entries[i].from, &al); + thread__find_map_fb(thread, sample->cpumode, + br->entries[i].from, &al); dsoname = get_dsoname(al.map); pydict_set_item_string_decref(pyelem, "from_dsoname", _PyUnicode_FromString(dsoname)); - thread__find_map(thread, sample->cpumode, - br->entries[i].to, &al); + thread__find_map_fb(thread, sample->cpumode, + br->entries[i].to, &al); dsoname = get_dsoname(al.map); pydict_set_item_string_decref(pyelem, "to_dsoname", _PyUnicode_FromString(dsoname)); @@ -576,14 +576,14 @@ static PyObject *python_process_brstacksym(struct perf_sample *sample, if (!pyelem) Py_FatalError("couldn't create Python dictionary"); - thread__find_symbol(thread, sample->cpumode, - br->entries[i].from, &al); + thread__find_symbol_fb(thread, sample->cpumode, + br->entries[i].from, &al); get_symoff(al.sym, &al, true, bf, sizeof(bf)); pydict_set_item_string_decref(pyelem, "from", _PyUnicode_FromString(bf)); - thread__find_symbol(thread, sample->cpumode, - br->entries[i].to, &al); + thread__find_symbol_fb(thread, sample->cpumode, + br->entries[i].to, &al); get_symoff(al.sym, &al, true, bf, sizeof(bf)); pydict_set_item_string_decref(pyelem, "to", _PyUnicode_FromString(bf)); -- 2.19.1

5 years, 6 months

1
0
0 0

[PATCH 08/22] perf tools: Use fallback for sample_addr_correlates_sym() cases

by Arnaldo Carvalho de Melo

From: Adrian Hunter <adrian.hunter(a)intel.com> thread__resolve() is used in the sample_addr_correlates_sym() cases where 'addr' is a destination of a branch which does not necessarily have the same cpumode as the 'ip'. Use the fallback function in that case. This patch depends on patch "perf tools: Add fallback functions for cases where cpumode is insufficient". Signed-off-by: Adrian Hunter <adrian.hunter(a)intel.com> Cc: Andi Kleen <ak(a)linux.intel.com> Cc: David S. Miller <davem(a)davemloft.net> Cc: Jiri Olsa <jolsa(a)redhat.com> Cc: Leo Yan <leo.yan(a)linaro.org> Cc: Mathieu Poirier <mathieu.poirier(a)linaro.org> Cc: stable(a)vger.kernel.org Link: http://lkml.kernel.org/r/20181106210712.12098-3-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> --- tools/perf/util/event.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c index 9431b20c1337..24493200cf80 100644 --- a/tools/perf/util/event.c +++ b/tools/perf/util/event.c @@ -1706,7 +1706,7 @@ bool sample_addr_correlates_sym(struct perf_event_attr *attr) void thread__resolve(struct thread *thread, struct addr_location *al, struct perf_sample *sample) { - thread__find_map(thread, sample->cpumode, sample->addr, al); + thread__find_map_fb(thread, sample->cpumode, sample->addr, al); al->cpu = sample->cpu; al->sym = NULL; -- 2.19.1

5 years, 6 months

1
0
0 0

[PATCH 07/22] perf thread: Add fallback functions for cases where cpumode is insufficient

by Arnaldo Carvalho de Melo

From: Adrian Hunter <adrian.hunter(a)intel.com> For branch stacks or branch samples, the sample cpumode might not be correct because it applies only to the sample 'ip' and not necessary to 'addr' or branch stack addresses. Add fallback functions that can be used to deal with those cases Signed-off-by: Adrian Hunter <adrian.hunter(a)intel.com> Cc: Andi Kleen <ak(a)linux.intel.com> Cc: David S. Miller <davem(a)davemloft.net> Cc: Jiri Olsa <jolsa(a)redhat.com> Cc: Leo Yan <leo.yan(a)linaro.org> Cc: Mathieu Poirier <mathieu.poirier(a)linaro.org> Cc: stable(a)vger.kernel.org Link: http://lkml.kernel.org/r/20181106210712.12098-2-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> --- tools/perf/util/event.c | 27 +++++++++++++++++++++++++++ tools/perf/util/machine.c | 27 +++++++++++++++++++++++++++ tools/perf/util/machine.h | 2 ++ tools/perf/util/thread.h | 4 ++++ 4 files changed, 60 insertions(+) diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c index e9c108a6b1c3..9431b20c1337 100644 --- a/tools/perf/util/event.c +++ b/tools/perf/util/event.c @@ -1577,6 +1577,24 @@ struct map *thread__find_map(struct thread *thread, u8 cpumode, u64 addr, return al->map; } +/* + * For branch stacks or branch samples, the sample cpumode might not be correct + * because it applies only to the sample 'ip' and not necessary to 'addr' or + * branch stack addresses. If possible, use a fallback to deal with those cases. + */ +struct map *thread__find_map_fb(struct thread *thread, u8 cpumode, u64 addr, + struct addr_location *al) +{ + struct map *map = thread__find_map(thread, cpumode, addr, al); + struct machine *machine = thread->mg->machine; + u8 addr_cpumode = machine__addr_cpumode(machine, cpumode, addr); + + if (map || addr_cpumode == cpumode) + return map; + + return thread__find_map(thread, addr_cpumode, addr, al); +} + struct symbol *thread__find_symbol(struct thread *thread, u8 cpumode, u64 addr, struct addr_location *al) { @@ -1586,6 +1604,15 @@ struct symbol *thread__find_symbol(struct thread *thread, u8 cpumode, return al->sym; } +struct symbol *thread__find_symbol_fb(struct thread *thread, u8 cpumode, + u64 addr, struct addr_location *al) +{ + al->sym = NULL; + if (thread__find_map_fb(thread, cpumode, addr, al)) + al->sym = map__find_symbol(al->map, al->addr); + return al->sym; +} + /* * Callers need to drop the reference to al->thread, obtained in * machine__findnew_thread() diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c index 8f36ce813bc5..9397e3f2444d 100644 --- a/tools/perf/util/machine.c +++ b/tools/perf/util/machine.c @@ -2592,6 +2592,33 @@ int machine__get_kernel_start(struct machine *machine) return err; } +u8 machine__addr_cpumode(struct machine *machine, u8 cpumode, u64 addr) +{ + u8 addr_cpumode = cpumode; + bool kernel_ip; + + if (!machine->single_address_space) + goto out; + + kernel_ip = machine__kernel_ip(machine, addr); + switch (cpumode) { + case PERF_RECORD_MISC_KERNEL: + case PERF_RECORD_MISC_USER: + addr_cpumode = kernel_ip ? PERF_RECORD_MISC_KERNEL : + PERF_RECORD_MISC_USER; + break; + case PERF_RECORD_MISC_GUEST_KERNEL: + case PERF_RECORD_MISC_GUEST_USER: + addr_cpumode = kernel_ip ? PERF_RECORD_MISC_GUEST_KERNEL : + PERF_RECORD_MISC_GUEST_USER; + break; + default: + break; + } +out: + return addr_cpumode; +} + struct dso *machine__findnew_dso(struct machine *machine, const char *filename) { return dsos__findnew(&machine->dsos, filename); diff --git a/tools/perf/util/machine.h b/tools/perf/util/machine.h index ca897a73014c..ebde3ea70225 100644 --- a/tools/perf/util/machine.h +++ b/tools/perf/util/machine.h @@ -100,6 +100,8 @@ static inline bool machine__kernel_ip(struct machine *machine, u64 ip) return ip >= kernel_start; } +u8 machine__addr_cpumode(struct machine *machine, u8 cpumode, u64 addr); + struct thread *machine__find_thread(struct machine *machine, pid_t pid, pid_t tid); struct comm *machine__thread_exec_comm(struct machine *machine, diff --git a/tools/perf/util/thread.h b/tools/perf/util/thread.h index 30e2b4c165fe..5920c3bb8ffe 100644 --- a/tools/perf/util/thread.h +++ b/tools/perf/util/thread.h @@ -96,9 +96,13 @@ struct thread *thread__main_thread(struct machine *machine, struct thread *threa struct map *thread__find_map(struct thread *thread, u8 cpumode, u64 addr, struct addr_location *al); +struct map *thread__find_map_fb(struct thread *thread, u8 cpumode, u64 addr, + struct addr_location *al); struct symbol *thread__find_symbol(struct thread *thread, u8 cpumode, u64 addr, struct addr_location *al); +struct symbol *thread__find_symbol_fb(struct thread *thread, u8 cpumode, + u64 addr, struct addr_location *al); void thread__find_cpumode_addr_location(struct thread *thread, u64 addr, struct addr_location *al); -- 2.19.1

5 years, 6 months

1
0
0 0

[PATCH 06/22] perf machine: Record if a arch has a single user/kernel address space

by Arnaldo Carvalho de Melo

From: Adrian Hunter <adrian.hunter(a)intel.com> Some architectures have a single address space for kernel and user addresses, which makes it possible to determine if an address is in kernel space or user space. Some don't, e.g.: sparc. Cache that info in perf_env so that, for instance, code needing to fallback failed symbol lookups at the kernel space in single address space arches can lookup at userspace. Signed-off-by: Adrian Hunter <adrian.hunter(a)intel.com> Cc: Andi Kleen <ak(a)linux.intel.com> Cc: David S. Miller <davem(a)davemloft.net> Cc: Jiri Olsa <jolsa(a)redhat.com> Cc: Leo Yan <leo.yan(a)linaro.org> Cc: Mathieu Poirier <mathieu.poirier(a)linaro.org> Cc: stable(a)vger.kernel.org Link: http://lkml.kernel.org/r/20181106210712.12098-2-adrian.hunter@intel.com [ split from a larger patch ] Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> --- tools/perf/arch/common.c | 10 ++++++++++ tools/perf/arch/common.h | 1 + tools/perf/util/machine.h | 1 + tools/perf/util/session.c | 4 ++++ 4 files changed, 16 insertions(+) diff --git a/tools/perf/arch/common.c b/tools/perf/arch/common.c index 82657c01a3b8..5f69fd0b745a 100644 --- a/tools/perf/arch/common.c +++ b/tools/perf/arch/common.c @@ -200,3 +200,13 @@ int perf_env__lookup_objdump(struct perf_env *env, const char **path) return perf_env__lookup_binutils_path(env, "objdump", path); } + +/* + * Some architectures have a single address space for kernel and user addresses, + * which makes it possible to determine if an address is in kernel space or user + * space. + */ +bool perf_env__single_address_space(struct perf_env *env) +{ + return strcmp(perf_env__arch(env), "sparc"); +} diff --git a/tools/perf/arch/common.h b/tools/perf/arch/common.h index 2167001b18c5..c298a446d1f6 100644 --- a/tools/perf/arch/common.h +++ b/tools/perf/arch/common.h @@ -5,5 +5,6 @@ #include "../util/env.h" int perf_env__lookup_objdump(struct perf_env *env, const char **path); +bool perf_env__single_address_space(struct perf_env *env); #endif /* ARCH_PERF_COMMON_H */ diff --git a/tools/perf/util/machine.h b/tools/perf/util/machine.h index d856b85862e2..ca897a73014c 100644 --- a/tools/perf/util/machine.h +++ b/tools/perf/util/machine.h @@ -42,6 +42,7 @@ struct machine { u16 id_hdr_size; bool comm_exec; bool kptr_restrict_warned; + bool single_address_space; char *root_dir; char *mmap_name; struct threads threads[THREADS__TABLE_SIZE]; diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c index 7d2c8ce6cfad..f8eab197f35c 100644 --- a/tools/perf/util/session.c +++ b/tools/perf/util/session.c @@ -24,6 +24,7 @@ #include "thread.h" #include "thread-stack.h" #include "stat.h" +#include "arch/common.h" static int perf_session__deliver_event(struct perf_session *session, union perf_event *event, @@ -150,6 +151,9 @@ struct perf_session *perf_session__new(struct perf_data *data, session->machines.host.env = &perf_env; } + session->machines.host.single_address_space = + perf_env__single_address_space(session->machines.host.env); + if (!data || perf_data__is_write(data)) { /* * In O_RDONLY mode this will be performed when reading the -- 2.19.1

5 years, 6 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror November 2018