Skip to content

Conversation

@jongwu
Copy link

@jongwu jongwu commented Mar 9, 2022

To measure kernel boot up time, reserved region in pl011 is used as trap
MMIO region to record kernel boot timestamp.
For now, we trap at 2 point: the first is nearly the first instruction of
kernel start; the second is just before call the init bin for userspace.
These 2 points can cover the whole kernel boot time.

If there is no pl011, the first write is still there but the second
won't happen.

Signed-off-by: Jianyong Wu jianyong.wu@arm.com

To measure kernel boot up time, reserved region in pl011 is used as trap
MMIO region to record kernel boot timestamp.
For now, we trap at 2 point: the first is nearly the first instruction of
kernel start; the second is just before call the init bin for userspace.
These 2 points can cover the whole kernel boot time.

If there is no pl011, the first write is still there but the second
won't happen.

Signed-off-by: Jianyong Wu <jianyong.wu@arm.com>
@rbradford rbradford requested a review from MrXinWang March 11, 2022 11:33
@MrXinWang
Copy link
Member

MrXinWang commented Mar 11, 2022

Hi @rbradford, me and @michael2012z would suggest that maybe we can review this PR and cloud-hypervisor/cloud-hypervisor#3838 at the same time to minimize the side effect to our CI :)

I will give both a test first - but from the CI in the cloud hypervisor repo, this time the kernel change looks fine.

@MrXinWang
Copy link
Member

By checking CI in cloud-hypervisor/cloud-hypervisor#3838, this time the kernel patch will not break CI.

@michael2012z michael2012z merged commit 7d768fa into cloud-hypervisor:ch-5.15.12 Mar 17, 2022
rbradford pushed a commit that referenced this pull request Jan 14, 2025
[ Upstream commit 5bf1557 ]

test_progs uses glibc specific functions backtrace() and
backtrace_symbols_fd() to print backtrace in case of SIGSEGV.

Recent commit (see fixes) updated test_progs.c to define stub versions
of the same functions with attriubte "weak" in order to allow linking
test_progs against musl libc. Unfortunately this broke the backtrace
handling for glibc builds.

As it turns out, glibc defines backtrace() and backtrace_symbols_fd()
as weak:

  $ llvm-readelf --symbols /lib64/libc.so.6 \
     | grep -P '( backtrace_symbols_fd| backtrace)$'
  4910: 0000000000126b40   161 FUNC    WEAK   DEFAULT    16 backtrace
  6843: 0000000000126f90   852 FUNC    WEAK   DEFAULT    16 backtrace_symbols_fd

So does test_progs:

 $ llvm-readelf --symbols test_progs \
    | grep -P '( backtrace_symbols_fd| backtrace)$'
  2891: 00000000006ad190    15 FUNC    WEAK   DEFAULT    13 backtrace
 11215: 00000000006ad1a0    41 FUNC    WEAK   DEFAULT    13 backtrace_symbols_fd

In such situation dynamic linker is not obliged to favour glibc
implementation over the one defined in test_progs.

Compiling with the following simple modification to test_progs.c
demonstrates the issue:

  $ git diff
  ...
  \--- a/tools/testing/selftests/bpf/test_progs.c
  \+++ b/tools/testing/selftests/bpf/test_progs.c
  \@@ -1817,6 +1817,7 @@ int main(int argc, char **argv)
          if (err)
                  return err;

  +       *(int *)0xdeadbeef  = 42;
          err = cd_flavor_subdir(argv[0]);
          if (err)
                  return err;

  $ ./test_progs
  [0]: Caught signal #11!
  Stack trace:
  <backtrace not supported>
  Segmentation fault (core dumped)

Resolve this by hiding stub definitions behind __GLIBC__ macro check
instead of using "weak" attribute.

Fixes: c9a83e7 ("selftests/bpf: Fix compile if backtrace support missing in libc")
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Tested-by: Tony Ambardar <tony.ambardar@gmail.com>
Reviewed-by: Tony Ambardar <tony.ambardar@gmail.com>
Acked-by: Daniel Xu <dxu@dxuuu.xyz>
Link: https://lore.kernel.org/bpf/20241003210307.3847907-1-eddyz87@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants