FAILED unresolved symbol vfs_truncate on arm64 with LLVM

Hi all,

Recently, an issue with CONFIG_DEBUG_INFO_BTF was reported for arm64:
https://groups.google.com/g/clang-built-linux/c/de_mNh23FOc/m/E7cu5BwbBAAJ

$ make -skj"$(nproc)" ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- \
                      LLVM=1 O=build/aarch64 defconfig

$ scripts/config \
    --file build/aarch64/.config \
    -e BPF_SYSCALL \
    -e DEBUG_INFO_BTF \
    -e FTRACE \
    -e FUNCTION_TRACER

$ make -skj"$(nproc)" ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- \
                      LLVM=1 O=build/aarch64 olddefconfig all
...
FAILED unresolved symbol vfs_truncate
...

My bisect landed on commit 6e22ab9da793 ("bpf: Add d_path helper")
although that seems obvious given that is what introduced
BTF_ID(func, vfs_truncate).

I am using the latest pahole v1.20 and LLVM is at
https://github.com/llvm/llvm-project/commit/14da287e18846ea86e45b421dc47f78ecc5aa7cb
although I can reproduce back to LLVM 10.0.1, which is the earliest
version that the kernel supports. I am very unfamiliar with BPF so I
have no idea what is going wrong here. Is this a known issue?

Cheers,
Nathan

On Mon, Feb 8, 2021 at 7:44 PM Nathan Chancellor [off-list ref] wrote:

Hi all,

Recently, an issue with CONFIG_DEBUG_INFO_BTF was reported for arm64:
https://groups.google.com/g/clang-built-linux/c/de_mNh23FOc/m/E7cu5BwbBAAJ

$ make -skj"$(nproc)" ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- \
                      LLVM=1 O=build/aarch64 defconfig

$ scripts/config \
    --file build/aarch64/.config \
    -e BPF_SYSCALL \
    -e DEBUG_INFO_BTF \
    -e FTRACE \
    -e FUNCTION_TRACER

$ make -skj"$(nproc)" ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- \
                      LLVM=1 O=build/aarch64 olddefconfig all
...
FAILED unresolved symbol vfs_truncate
...

My bisect landed on commit 6e22ab9da793 ("bpf: Add d_path helper")
although that seems obvious given that is what introduced
BTF_ID(func, vfs_truncate).

I am using the latest pahole v1.20 and LLVM is at
https://github.com/llvm/llvm-project/commit/14da287e18846ea86e45b421dc47f78ecc5aa7cb
although I can reproduce back to LLVM 10.0.1, which is the earliest
version that the kernel supports. I am very unfamiliar with BPF so I
have no idea what is going wrong here. Is this a known issue?

I'll skip the reproduction games this time and will just request the
vmlinux image. Please upload somewhere so that we can look at DWARF
and see what's going on. Thanks.

Cheers,
Nathan

On Mon, Feb 08, 2021 at 08:45:43PM -0800, Andrii Nakryiko wrote:

On Mon, Feb 8, 2021 at 7:44 PM Nathan Chancellor [off-list ref] wrote:

quoted

Hi all,

Recently, an issue with CONFIG_DEBUG_INFO_BTF was reported for arm64:
https://groups.google.com/g/clang-built-linux/c/de_mNh23FOc/m/E7cu5BwbBAAJ

$ make -skj"$(nproc)" ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- \
                      LLVM=1 O=build/aarch64 defconfig

$ scripts/config \
    --file build/aarch64/.config \
    -e BPF_SYSCALL \
    -e DEBUG_INFO_BTF \
    -e FTRACE \
    -e FUNCTION_TRACER

$ make -skj"$(nproc)" ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- \
                      LLVM=1 O=build/aarch64 olddefconfig all
...
FAILED unresolved symbol vfs_truncate
...

My bisect landed on commit 6e22ab9da793 ("bpf: Add d_path helper")
although that seems obvious given that is what introduced
BTF_ID(func, vfs_truncate).

I am using the latest pahole v1.20 and LLVM is at
https://github.com/llvm/llvm-project/commit/14da287e18846ea86e45b421dc47f78ecc5aa7cb
although I can reproduce back to LLVM 10.0.1, which is the earliest
version that the kernel supports. I am very unfamiliar with BPF so I
have no idea what is going wrong here. Is this a known issue?

I'll skip the reproduction games this time and will just request the
vmlinux image. Please upload somewhere so that we can look at DWARF
and see what's going on. Thanks.

Sure thing, let me know if this works. I uploaded in two places to make
it easier to grab:

zstd compressed:
https://github.com/nathanchance/bug-files/blob/3b2873751e29311e084ae2c71604a1963f5e1a48/btf-aarch64/vmlinux.zst

uncompressed:
https://1drv.ms/u/s!AsQNYeB-IEbqjQiUOspbEdXx49o7?e=ipA9Hv

Cheers,
Nathan

On Mon, Feb 8, 2021 at 9:23 PM Nathan Chancellor [off-list ref] wrote:

On Mon, Feb 08, 2021 at 08:45:43PM -0800, Andrii Nakryiko wrote:

quoted

On Mon, Feb 8, 2021 at 7:44 PM Nathan Chancellor [off-list ref] wrote:

quoted

Hi all,

Recently, an issue with CONFIG_DEBUG_INFO_BTF was reported for arm64:
https://groups.google.com/g/clang-built-linux/c/de_mNh23FOc/m/E7cu5BwbBAAJ

$ make -skj"$(nproc)" ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- \
                      LLVM=1 O=build/aarch64 defconfig

$ scripts/config \
    --file build/aarch64/.config \
    -e BPF_SYSCALL \
    -e DEBUG_INFO_BTF \
    -e FTRACE \
    -e FUNCTION_TRACER

$ make -skj"$(nproc)" ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- \
                      LLVM=1 O=build/aarch64 olddefconfig all
...
FAILED unresolved symbol vfs_truncate
...

My bisect landed on commit 6e22ab9da793 ("bpf: Add d_path helper")
although that seems obvious given that is what introduced
BTF_ID(func, vfs_truncate).

I am using the latest pahole v1.20 and LLVM is at
https://github.com/llvm/llvm-project/commit/14da287e18846ea86e45b421dc47f78ecc5aa7cb
although I can reproduce back to LLVM 10.0.1, which is the earliest
version that the kernel supports. I am very unfamiliar with BPF so I
have no idea what is going wrong here. Is this a known issue?

I'll skip the reproduction games this time and will just request the
vmlinux image. Please upload somewhere so that we can look at DWARF
and see what's going on. Thanks.

Sure thing, let me know if this works. I uploaded in two places to make
it easier to grab:

zstd compressed:
https://github.com/nathanchance/bug-files/blob/3b2873751e29311e084ae2c71604a1963f5e1a48/btf-aarch64/vmlinux.zst

Thanks. I clearly see at least one instance of seemingly well-formed
vfs_truncate DWARF declaration. Also there is a proper ELF symbol for
it. Which means it should have been generated in BTF, but it doesn't
appear to be, so it does seem like a pahole bug. I (or someone else
before me) will continue tomorrow.

$ llvm-dwarfdump vmlinux
...

0x00052e6f:   DW_TAG_subprogram
                DW_AT_name      ("vfs_truncate")
                DW_AT_decl_file
("/home/nathan/cbl/src/linux/include/linux/fs.h")
                DW_AT_decl_line (2520)
                DW_AT_prototyped        (true)
                DW_AT_type      (0x000452cb "long int")
                DW_AT_declaration       (true)
                DW_AT_external  (true)

0x00052e7b:     DW_TAG_formal_parameter
                  DW_AT_type    (0x00045fc6 "const path*")

0x00052e80:     DW_TAG_formal_parameter
                  DW_AT_type    (0x00045213 "long long int")

...

$ llvm-readelf -s vmlinux | rg vfs_truncate
 15013: ffff800011c22418     4 OBJECT  LOCAL  DEFAULT    24
__BTF_ID__func__vfs_truncate__609
 22531: ffff80001189fe0d     0 NOTYPE  LOCAL  DEFAULT    17
__kstrtab_vfs_truncate
 22532: ffff8000118a985b     0 NOTYPE  LOCAL  DEFAULT    17
__kstrtabns_vfs_truncate
 22534: ffff800011873b7c     0 NOTYPE  LOCAL  DEFAULT     8
__ksymtab_vfs_truncate
176099: ffff80001031f430   360 FUNC    GLOBAL DEFAULT     2 vfs_truncate

$ bpftool btf dump file vmlinux | rg vfs_truncate
<nothing>

uncompressed:
https://1drv.ms/u/s!AsQNYeB-IEbqjQiUOspbEdXx49o7?e=ipA9Hv

Cheers,
Nathan

On Mon, Feb 8, 2021 at 10:09 PM Andrii Nakryiko
[off-list ref] wrote:

On Mon, Feb 8, 2021 at 9:23 PM Nathan Chancellor [off-list ref] wrote:

quoted

On Mon, Feb 08, 2021 at 08:45:43PM -0800, Andrii Nakryiko wrote:

quoted

On Mon, Feb 8, 2021 at 7:44 PM Nathan Chancellor [off-list ref] wrote:

quoted

Hi all,

Recently, an issue with CONFIG_DEBUG_INFO_BTF was reported for arm64:
https://groups.google.com/g/clang-built-linux/c/de_mNh23FOc/m/E7cu5BwbBAAJ

$ make -skj"$(nproc)" ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- \
                      LLVM=1 O=build/aarch64 defconfig

$ scripts/config \
    --file build/aarch64/.config \
    -e BPF_SYSCALL \
    -e DEBUG_INFO_BTF \
    -e FTRACE \
    -e FUNCTION_TRACER

$ make -skj"$(nproc)" ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- \
                      LLVM=1 O=build/aarch64 olddefconfig all
...
FAILED unresolved symbol vfs_truncate
...

My bisect landed on commit 6e22ab9da793 ("bpf: Add d_path helper")
although that seems obvious given that is what introduced
BTF_ID(func, vfs_truncate).

I am using the latest pahole v1.20 and LLVM is at
https://github.com/llvm/llvm-project/commit/14da287e18846ea86e45b421dc47f78ecc5aa7cb
although I can reproduce back to LLVM 10.0.1, which is the earliest
version that the kernel supports. I am very unfamiliar with BPF so I
have no idea what is going wrong here. Is this a known issue?

I'll skip the reproduction games this time and will just request the
vmlinux image. Please upload somewhere so that we can look at DWARF
and see what's going on. Thanks.

Sure thing, let me know if this works. I uploaded in two places to make
it easier to grab:

zstd compressed:
https://github.com/nathanchance/bug-files/blob/3b2873751e29311e084ae2c71604a1963f5e1a48/btf-aarch64/vmlinux.zst

Thanks. I clearly see at least one instance of seemingly well-formed
vfs_truncate DWARF declaration. Also there is a proper ELF symbol for
it. Which means it should have been generated in BTF, but it doesn't
appear to be, so it does seem like a pahole bug. I (or someone else
before me) will continue tomorrow.

$ llvm-dwarfdump vmlinux
...

0x00052e6f:   DW_TAG_subprogram
                DW_AT_name      ("vfs_truncate")
                DW_AT_decl_file
("/home/nathan/cbl/src/linux/include/linux/fs.h")
                DW_AT_decl_line (2520)
                DW_AT_prototyped        (true)
                DW_AT_type      (0x000452cb "long int")
                DW_AT_declaration       (true)
                DW_AT_external  (true)

0x00052e7b:     DW_TAG_formal_parameter
                  DW_AT_type    (0x00045fc6 "const path*")

0x00052e80:     DW_TAG_formal_parameter
                  DW_AT_type    (0x00045213 "long long int")

...

... and here's the *only* other one (not marked as declaration, but I
thought we already handle that, Jiri?):

0x01d0da35:   DW_TAG_subprogram
                DW_AT_low_pc    (0xffff80001031f430)
                DW_AT_high_pc   (0xffff80001031f598)
                DW_AT_frame_base        (DW_OP_reg29)
                DW_AT_GNU_all_call_sites        (true)
                DW_AT_name      ("vfs_truncate")
                DW_AT_decl_file ("/home/nathan/cbl/src/linux/fs/open.c")
                DW_AT_decl_line (69)
                DW_AT_prototyped        (true)
                DW_AT_type      (0x01cfdfe4 "long int")
                DW_AT_external  (true)

$ llvm-readelf -s vmlinux | rg vfs_truncate
 15013: ffff800011c22418     4 OBJECT  LOCAL  DEFAULT    24
__BTF_ID__func__vfs_truncate__609
 22531: ffff80001189fe0d     0 NOTYPE  LOCAL  DEFAULT    17
__kstrtab_vfs_truncate
 22532: ffff8000118a985b     0 NOTYPE  LOCAL  DEFAULT    17
__kstrtabns_vfs_truncate
 22534: ffff800011873b7c     0 NOTYPE  LOCAL  DEFAULT     8
__ksymtab_vfs_truncate
176099: ffff80001031f430   360 FUNC    GLOBAL DEFAULT     2 vfs_truncate

$ bpftool btf dump file vmlinux | rg vfs_truncate
<nothing>

quoted

uncompressed:
https://1drv.ms/u/s!AsQNYeB-IEbqjQiUOspbEdXx49o7?e=ipA9Hv

Cheers,
Nathan

On Mon, Feb 8, 2021 at 10:13 PM Andrii Nakryiko
[off-list ref] wrote:

On Mon, Feb 8, 2021 at 10:09 PM Andrii Nakryiko
[off-list ref] wrote:

quoted

On Mon, Feb 8, 2021 at 9:23 PM Nathan Chancellor [off-list ref] wrote:

quoted

On Mon, Feb 08, 2021 at 08:45:43PM -0800, Andrii Nakryiko wrote:

quoted

On Mon, Feb 8, 2021 at 7:44 PM Nathan Chancellor [off-list ref] wrote:

quoted

Hi all,

Recently, an issue with CONFIG_DEBUG_INFO_BTF was reported for arm64:
https://groups.google.com/g/clang-built-linux/c/de_mNh23FOc/m/E7cu5BwbBAAJ

$ make -skj"$(nproc)" ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- \
                      LLVM=1 O=build/aarch64 defconfig

$ scripts/config \
    --file build/aarch64/.config \
    -e BPF_SYSCALL \
    -e DEBUG_INFO_BTF \
    -e FTRACE \
    -e FUNCTION_TRACER

$ make -skj"$(nproc)" ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- \
                      LLVM=1 O=build/aarch64 olddefconfig all
...
FAILED unresolved symbol vfs_truncate
...

My bisect landed on commit 6e22ab9da793 ("bpf: Add d_path helper")
although that seems obvious given that is what introduced
BTF_ID(func, vfs_truncate).

I am using the latest pahole v1.20 and LLVM is at
https://github.com/llvm/llvm-project/commit/14da287e18846ea86e45b421dc47f78ecc5aa7cb
although I can reproduce back to LLVM 10.0.1, which is the earliest
version that the kernel supports. I am very unfamiliar with BPF so I
have no idea what is going wrong here. Is this a known issue?

I'll skip the reproduction games this time and will just request the
vmlinux image. Please upload somewhere so that we can look at DWARF
and see what's going on. Thanks.

Sure thing, let me know if this works. I uploaded in two places to make
it easier to grab:

zstd compressed:
https://github.com/nathanchance/bug-files/blob/3b2873751e29311e084ae2c71604a1963f5e1a48/btf-aarch64/vmlinux.zst

Thanks. I clearly see at least one instance of seemingly well-formed
vfs_truncate DWARF declaration. Also there is a proper ELF symbol for
it. Which means it should have been generated in BTF, but it doesn't
appear to be, so it does seem like a pahole bug. I (or someone else
before me) will continue tomorrow.

$ llvm-dwarfdump vmlinux
...

0x00052e6f:   DW_TAG_subprogram
                DW_AT_name      ("vfs_truncate")
                DW_AT_decl_file
("/home/nathan/cbl/src/linux/include/linux/fs.h")
                DW_AT_decl_line (2520)
                DW_AT_prototyped        (true)
                DW_AT_type      (0x000452cb "long int")
                DW_AT_declaration       (true)
                DW_AT_external  (true)

0x00052e7b:     DW_TAG_formal_parameter
                  DW_AT_type    (0x00045fc6 "const path*")

0x00052e80:     DW_TAG_formal_parameter
                  DW_AT_type    (0x00045213 "long long int")

...

... and here's the *only* other one (not marked as declaration, but I
thought we already handle that, Jiri?):

0x01d0da35:   DW_TAG_subprogram
                DW_AT_low_pc    (0xffff80001031f430)
                DW_AT_high_pc   (0xffff80001031f598)
                DW_AT_frame_base        (DW_OP_reg29)
                DW_AT_GNU_all_call_sites        (true)
                DW_AT_name      ("vfs_truncate")
                DW_AT_decl_file ("/home/nathan/cbl/src/linux/fs/open.c")
                DW_AT_decl_line (69)
                DW_AT_prototyped        (true)
                DW_AT_type      (0x01cfdfe4 "long int")
                DW_AT_external  (true)

Ok, the problem appears to be not in DWARF, but in mcount_loc data.
vfs_truncate's address is not recorded as ftrace-attachable, and thus
pahole ignores it. I don't know why this happens and it's quite
strange, given vfs_truncate is just a normal global function.

I'd like to understand this issue before we try to fix it, but there
is at least one improvement we can make: pahole should check ftrace
addresses only for static functions, not the global ones (global ones
should be always attachable, unless they are special, e.g., notrace
and stuff). We can easily check that by looking at the corresponding
symbol. But I'd like to verify that vfs_truncate is ftrace-attachable
for that particular kernel. For that we'll need Nathan's cooperation,
unless someone else can build an arm64 kernel with the same problem
and check.

quoted

$ llvm-readelf -s vmlinux | rg vfs_truncate
 15013: ffff800011c22418     4 OBJECT  LOCAL  DEFAULT    24
__BTF_ID__func__vfs_truncate__609
 22531: ffff80001189fe0d     0 NOTYPE  LOCAL  DEFAULT    17
__kstrtab_vfs_truncate
 22532: ffff8000118a985b     0 NOTYPE  LOCAL  DEFAULT    17
__kstrtabns_vfs_truncate
 22534: ffff800011873b7c     0 NOTYPE  LOCAL  DEFAULT     8
__ksymtab_vfs_truncate
176099: ffff80001031f430   360 FUNC    GLOBAL DEFAULT     2 vfs_truncate

$ bpftool btf dump file vmlinux | rg vfs_truncate
<nothing>

quoted

uncompressed:
https://1drv.ms/u/s!AsQNYeB-IEbqjQiUOspbEdXx49o7?e=ipA9Hv

Cheers,
Nathan

On Mon, Feb 08, 2021 at 10:56:36PM -0800, Andrii Nakryiko wrote:

On Mon, Feb 8, 2021 at 10:13 PM Andrii Nakryiko
[off-list ref] wrote:

quoted

On Mon, Feb 8, 2021 at 10:09 PM Andrii Nakryiko
[off-list ref] wrote:

quoted

On Mon, Feb 8, 2021 at 9:23 PM Nathan Chancellor [off-list ref] wrote:

quoted

On Mon, Feb 08, 2021 at 08:45:43PM -0800, Andrii Nakryiko wrote:

quoted

On Mon, Feb 8, 2021 at 7:44 PM Nathan Chancellor [off-list ref] wrote:

quoted

Hi all,

Recently, an issue with CONFIG_DEBUG_INFO_BTF was reported for arm64:
https://groups.google.com/g/clang-built-linux/c/de_mNh23FOc/m/E7cu5BwbBAAJ

$ make -skj"$(nproc)" ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- \
                      LLVM=1 O=build/aarch64 defconfig

$ scripts/config \
    --file build/aarch64/.config \
    -e BPF_SYSCALL \
    -e DEBUG_INFO_BTF \
    -e FTRACE \
    -e FUNCTION_TRACER

$ make -skj"$(nproc)" ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- \
                      LLVM=1 O=build/aarch64 olddefconfig all
...
FAILED unresolved symbol vfs_truncate
...

My bisect landed on commit 6e22ab9da793 ("bpf: Add d_path helper")
although that seems obvious given that is what introduced
BTF_ID(func, vfs_truncate).

I am using the latest pahole v1.20 and LLVM is at
https://github.com/llvm/llvm-project/commit/14da287e18846ea86e45b421dc47f78ecc5aa7cb
although I can reproduce back to LLVM 10.0.1, which is the earliest
version that the kernel supports. I am very unfamiliar with BPF so I
have no idea what is going wrong here. Is this a known issue?

I'll skip the reproduction games this time and will just request the
vmlinux image. Please upload somewhere so that we can look at DWARF
and see what's going on. Thanks.

Sure thing, let me know if this works. I uploaded in two places to make
it easier to grab:

zstd compressed:
https://github.com/nathanchance/bug-files/blob/3b2873751e29311e084ae2c71604a1963f5e1a48/btf-aarch64/vmlinux.zst

Thanks. I clearly see at least one instance of seemingly well-formed
vfs_truncate DWARF declaration. Also there is a proper ELF symbol for
it. Which means it should have been generated in BTF, but it doesn't
appear to be, so it does seem like a pahole bug. I (or someone else
before me) will continue tomorrow.

$ llvm-dwarfdump vmlinux
...

0x00052e6f:   DW_TAG_subprogram
                DW_AT_name      ("vfs_truncate")
                DW_AT_decl_file
("/home/nathan/cbl/src/linux/include/linux/fs.h")
                DW_AT_decl_line (2520)
                DW_AT_prototyped        (true)
                DW_AT_type      (0x000452cb "long int")
                DW_AT_declaration       (true)
                DW_AT_external  (true)

0x00052e7b:     DW_TAG_formal_parameter
                  DW_AT_type    (0x00045fc6 "const path*")

0x00052e80:     DW_TAG_formal_parameter
                  DW_AT_type    (0x00045213 "long long int")

...

... and here's the *only* other one (not marked as declaration, but I
thought we already handle that, Jiri?):

0x01d0da35:   DW_TAG_subprogram
                DW_AT_low_pc    (0xffff80001031f430)
                DW_AT_high_pc   (0xffff80001031f598)
                DW_AT_frame_base        (DW_OP_reg29)
                DW_AT_GNU_all_call_sites        (true)
                DW_AT_name      ("vfs_truncate")
                DW_AT_decl_file ("/home/nathan/cbl/src/linux/fs/open.c")
                DW_AT_decl_line (69)
                DW_AT_prototyped        (true)
                DW_AT_type      (0x01cfdfe4 "long int")
                DW_AT_external  (true)

Ok, the problem appears to be not in DWARF, but in mcount_loc data.
vfs_truncate's address is not recorded as ftrace-attachable, and thus
pahole ignores it. I don't know why this happens and it's quite
strange, given vfs_truncate is just a normal global function.

I'd like to understand this issue before we try to fix it, but there
is at least one improvement we can make: pahole should check ftrace
addresses only for static functions, not the global ones (global ones
should be always attachable, unless they are special, e.g., notrace
and stuff). We can easily check that by looking at the corresponding
symbol. But I'd like to verify that vfs_truncate is ftrace-attachable
for that particular kernel. For that we'll need Nathan's cooperation,
unless someone else can build an arm64 kernel with the same problem
and check.

Sure, just let me know what I need to do and I can do it!

Cheers,
Nathan

quoted

quoted

$ llvm-readelf -s vmlinux | rg vfs_truncate
 15013: ffff800011c22418     4 OBJECT  LOCAL  DEFAULT    24
__BTF_ID__func__vfs_truncate__609
 22531: ffff80001189fe0d     0 NOTYPE  LOCAL  DEFAULT    17
__kstrtab_vfs_truncate
 22532: ffff8000118a985b     0 NOTYPE  LOCAL  DEFAULT    17
__kstrtabns_vfs_truncate
 22534: ffff800011873b7c     0 NOTYPE  LOCAL  DEFAULT     8
__ksymtab_vfs_truncate
176099: ffff80001031f430   360 FUNC    GLOBAL DEFAULT     2 vfs_truncate

$ bpftool btf dump file vmlinux | rg vfs_truncate
<nothing>

quoted

uncompressed:
https://1drv.ms/u/s!AsQNYeB-IEbqjQiUOspbEdXx49o7?e=ipA9Hv

Cheers,
Nathan

-- 
You received this message because you are subscribed to the Google Groups "Clang Built Linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clang-built-linux+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/clang-built-linux/CAEf4Bzax90hn_5axpnCpW%2BE6gVc1mtUgCXWqmxV0tJ4Ud7bsaA%40mail.gmail.com.

On Tue, Feb 09, 2021 at 12:49:04AM -0700, Nathan Chancellor wrote:

On Mon, Feb 08, 2021 at 10:56:36PM -0800, Andrii Nakryiko wrote:

quoted

On Mon, Feb 8, 2021 at 10:13 PM Andrii Nakryiko
[off-list ref] wrote:

quoted

On Mon, Feb 8, 2021 at 10:09 PM Andrii Nakryiko
[off-list ref] wrote:

quoted

On Mon, Feb 8, 2021 at 9:23 PM Nathan Chancellor [off-list ref] wrote:

quoted

On Mon, Feb 08, 2021 at 08:45:43PM -0800, Andrii Nakryiko wrote:

quoted

On Mon, Feb 8, 2021 at 7:44 PM Nathan Chancellor [off-list ref] wrote:

quoted

Hi all,

Recently, an issue with CONFIG_DEBUG_INFO_BTF was reported for arm64:
https://groups.google.com/g/clang-built-linux/c/de_mNh23FOc/m/E7cu5BwbBAAJ

$ make -skj"$(nproc)" ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- \
                      LLVM=1 O=build/aarch64 defconfig

$ scripts/config \
    --file build/aarch64/.config \
    -e BPF_SYSCALL \
    -e DEBUG_INFO_BTF \
    -e FTRACE \
    -e FUNCTION_TRACER

$ make -skj"$(nproc)" ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- \
                      LLVM=1 O=build/aarch64 olddefconfig all
...
FAILED unresolved symbol vfs_truncate
...

My bisect landed on commit 6e22ab9da793 ("bpf: Add d_path helper")
although that seems obvious given that is what introduced
BTF_ID(func, vfs_truncate).

I am using the latest pahole v1.20 and LLVM is at
https://github.com/llvm/llvm-project/commit/14da287e18846ea86e45b421dc47f78ecc5aa7cb
although I can reproduce back to LLVM 10.0.1, which is the earliest
version that the kernel supports. I am very unfamiliar with BPF so I
have no idea what is going wrong here. Is this a known issue?

I'll skip the reproduction games this time and will just request the
vmlinux image. Please upload somewhere so that we can look at DWARF
and see what's going on. Thanks.

Sure thing, let me know if this works. I uploaded in two places to make
it easier to grab:

zstd compressed:
https://github.com/nathanchance/bug-files/blob/3b2873751e29311e084ae2c71604a1963f5e1a48/btf-aarch64/vmlinux.zst

Thanks. I clearly see at least one instance of seemingly well-formed
vfs_truncate DWARF declaration. Also there is a proper ELF symbol for
it. Which means it should have been generated in BTF, but it doesn't
appear to be, so it does seem like a pahole bug. I (or someone else
before me) will continue tomorrow.

$ llvm-dwarfdump vmlinux
...

0x00052e6f:   DW_TAG_subprogram
                DW_AT_name      ("vfs_truncate")
                DW_AT_decl_file
("/home/nathan/cbl/src/linux/include/linux/fs.h")
                DW_AT_decl_line (2520)
                DW_AT_prototyped        (true)
                DW_AT_type      (0x000452cb "long int")
                DW_AT_declaration       (true)
                DW_AT_external  (true)

0x00052e7b:     DW_TAG_formal_parameter
                  DW_AT_type    (0x00045fc6 "const path*")

0x00052e80:     DW_TAG_formal_parameter
                  DW_AT_type    (0x00045213 "long long int")

...

... and here's the *only* other one (not marked as declaration, but I
thought we already handle that, Jiri?):

0x01d0da35:   DW_TAG_subprogram
                DW_AT_low_pc    (0xffff80001031f430)
                DW_AT_high_pc   (0xffff80001031f598)
                DW_AT_frame_base        (DW_OP_reg29)
                DW_AT_GNU_all_call_sites        (true)
                DW_AT_name      ("vfs_truncate")
                DW_AT_decl_file ("/home/nathan/cbl/src/linux/fs/open.c")
                DW_AT_decl_line (69)
                DW_AT_prototyped        (true)
                DW_AT_type      (0x01cfdfe4 "long int")
                DW_AT_external  (true)

Ok, the problem appears to be not in DWARF, but in mcount_loc data.
vfs_truncate's address is not recorded as ftrace-attachable, and thus
pahole ignores it. I don't know why this happens and it's quite
strange, given vfs_truncate is just a normal global function.

right, I can't see it in mcount adresses.. but it begins with instructions
that appears to be nops, which would suggest it's traceable

	ffff80001031f430 <vfs_truncate>:
	ffff80001031f430: 5f 24 03 d5   hint    #34
	ffff80001031f434: 1f 20 03 d5   nop
	ffff80001031f438: 1f 20 03 d5   nop
	ffff80001031f43c: 3f 23 03 d5   hint    #25

quoted

I'd like to understand this issue before we try to fix it, but there
is at least one improvement we can make: pahole should check ftrace
addresses only for static functions, not the global ones (global ones
should be always attachable, unless they are special, e.g., notrace
and stuff). We can easily check that by looking at the corresponding
symbol. But I'd like to verify that vfs_truncate is ftrace-attachable
for that particular kernel. For that we'll need Nathan's cooperation,
unless someone else can build an arm64 kernel with the same problem
and check.

I'm building on arm now, let's see

Sure, just let me know what I need to do and I can do it!

could you please verify that you don't see vfs_truncate in
available_filter_functions?

 # cat /sys/kernel/debug/tracing/available_filter_functions | grep vfs_truncate

thanks,
jirka

Cheers,
Nathan

quoted

quoted

quoted

$ llvm-readelf -s vmlinux | rg vfs_truncate
 15013: ffff800011c22418     4 OBJECT  LOCAL  DEFAULT    24
__BTF_ID__func__vfs_truncate__609
 22531: ffff80001189fe0d     0 NOTYPE  LOCAL  DEFAULT    17
__kstrtab_vfs_truncate
 22532: ffff8000118a985b     0 NOTYPE  LOCAL  DEFAULT    17
__kstrtabns_vfs_truncate
 22534: ffff800011873b7c     0 NOTYPE  LOCAL  DEFAULT     8
__ksymtab_vfs_truncate
176099: ffff80001031f430   360 FUNC    GLOBAL DEFAULT     2 vfs_truncate

$ bpftool btf dump file vmlinux | rg vfs_truncate
<nothing>

quoted

uncompressed:
https://1drv.ms/u/s!AsQNYeB-IEbqjQiUOspbEdXx49o7?e=ipA9Hv

Cheers,
Nathan

-- 
You received this message because you are subscribed to the Google Groups "Clang Built Linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clang-built-linux+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/clang-built-linux/CAEf4Bzax90hn_5axpnCpW%2BE6gVc1mtUgCXWqmxV0tJ4Ud7bsaA%40mail.gmail.com.

On Tue, Feb 09, 2021 at 01:36:41PM +0100, Jiri Olsa wrote:

On Tue, Feb 09, 2021 at 12:49:04AM -0700, Nathan Chancellor wrote:

quoted

On Mon, Feb 08, 2021 at 10:56:36PM -0800, Andrii Nakryiko wrote:

quoted

On Mon, Feb 8, 2021 at 10:13 PM Andrii Nakryiko
[off-list ref] wrote:

quoted

On Mon, Feb 8, 2021 at 10:09 PM Andrii Nakryiko
[off-list ref] wrote:

quoted

On Mon, Feb 8, 2021 at 9:23 PM Nathan Chancellor [off-list ref] wrote:

quoted

On Mon, Feb 08, 2021 at 08:45:43PM -0800, Andrii Nakryiko wrote:

quoted

On Mon, Feb 8, 2021 at 7:44 PM Nathan Chancellor [off-list ref] wrote:

quoted

Hi all,

Recently, an issue with CONFIG_DEBUG_INFO_BTF was reported for arm64:
https://groups.google.com/g/clang-built-linux/c/de_mNh23FOc/m/E7cu5BwbBAAJ

$ make -skj"$(nproc)" ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- \
                      LLVM=1 O=build/aarch64 defconfig

$ scripts/config \
    --file build/aarch64/.config \
    -e BPF_SYSCALL \
    -e DEBUG_INFO_BTF \
    -e FTRACE \
    -e FUNCTION_TRACER

$ make -skj"$(nproc)" ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- \
                      LLVM=1 O=build/aarch64 olddefconfig all
...
FAILED unresolved symbol vfs_truncate
...

My bisect landed on commit 6e22ab9da793 ("bpf: Add d_path helper")
although that seems obvious given that is what introduced
BTF_ID(func, vfs_truncate).

I am using the latest pahole v1.20 and LLVM is at
https://github.com/llvm/llvm-project/commit/14da287e18846ea86e45b421dc47f78ecc5aa7cb
although I can reproduce back to LLVM 10.0.1, which is the earliest
version that the kernel supports. I am very unfamiliar with BPF so I
have no idea what is going wrong here. Is this a known issue?

I'll skip the reproduction games this time and will just request the
vmlinux image. Please upload somewhere so that we can look at DWARF
and see what's going on. Thanks.

Sure thing, let me know if this works. I uploaded in two places to make
it easier to grab:

zstd compressed:
https://github.com/nathanchance/bug-files/blob/3b2873751e29311e084ae2c71604a1963f5e1a48/btf-aarch64/vmlinux.zst

Thanks. I clearly see at least one instance of seemingly well-formed
vfs_truncate DWARF declaration. Also there is a proper ELF symbol for
it. Which means it should have been generated in BTF, but it doesn't
appear to be, so it does seem like a pahole bug. I (or someone else
before me) will continue tomorrow.

$ llvm-dwarfdump vmlinux
...

0x00052e6f:   DW_TAG_subprogram
                DW_AT_name      ("vfs_truncate")
                DW_AT_decl_file
("/home/nathan/cbl/src/linux/include/linux/fs.h")
                DW_AT_decl_line (2520)
                DW_AT_prototyped        (true)
                DW_AT_type      (0x000452cb "long int")
                DW_AT_declaration       (true)
                DW_AT_external  (true)

0x00052e7b:     DW_TAG_formal_parameter
                  DW_AT_type    (0x00045fc6 "const path*")

0x00052e80:     DW_TAG_formal_parameter
                  DW_AT_type    (0x00045213 "long long int")

...

... and here's the *only* other one (not marked as declaration, but I
thought we already handle that, Jiri?):

0x01d0da35:   DW_TAG_subprogram
                DW_AT_low_pc    (0xffff80001031f430)
                DW_AT_high_pc   (0xffff80001031f598)
                DW_AT_frame_base        (DW_OP_reg29)
                DW_AT_GNU_all_call_sites        (true)
                DW_AT_name      ("vfs_truncate")
                DW_AT_decl_file ("/home/nathan/cbl/src/linux/fs/open.c")
                DW_AT_decl_line (69)
                DW_AT_prototyped        (true)
                DW_AT_type      (0x01cfdfe4 "long int")
                DW_AT_external  (true)

Ok, the problem appears to be not in DWARF, but in mcount_loc data.
vfs_truncate's address is not recorded as ftrace-attachable, and thus
pahole ignores it. I don't know why this happens and it's quite
strange, given vfs_truncate is just a normal global function.

right, I can't see it in mcount adresses.. but it begins with instructions
that appears to be nops, which would suggest it's traceable

	ffff80001031f430 <vfs_truncate>:
	ffff80001031f430: 5f 24 03 d5   hint    #34
	ffff80001031f434: 1f 20 03 d5   nop
	ffff80001031f438: 1f 20 03 d5   nop
	ffff80001031f43c: 3f 23 03 d5   hint    #25

quoted

quoted

I'd like to understand this issue before we try to fix it, but there
is at least one improvement we can make: pahole should check ftrace
addresses only for static functions, not the global ones (global ones
should be always attachable, unless they are special, e.g., notrace
and stuff). We can easily check that by looking at the corresponding
symbol. But I'd like to verify that vfs_truncate is ftrace-attachable

I'm still trying to build the kernel.. however ;-)

patch below adds the ftrace check only for static functions
and lets the externa go through.. but as you said, in this
case we'll need to figure out the 'notrace' and other checks
ftrace is doing

jirka


---

diff --git a/btf_encoder.c b/btf_encoder.c
index b124ec20a689..4d147406cfa5 100644
--- a/btf_encoder.c
+++ b/btf_encoder.c

@@ -734,7 +734,7 @@ int cu__encode_btf(struct cu *cu, int verbose, bool force,
 			continue;
 		if (!has_arg_names(cu, &fn->proto))
 			continue;
-		if (functions_cnt) {
+		if (!fn->external && functions_cnt) {
 			struct elf_function *func;
 			const char *name;
 

@@ -746,9 +746,6 @@ int cu__encode_btf(struct cu *cu, int verbose, bool force,
 			if (!func || func->generated)
 				continue;
 			func->generated = true;
-		} else {
-			if (!fn->external)
-				continue;
 		}
 
 		btf_fnproto_id = btf_elf__add_func_proto(btfe, cu, &fn->proto, type_id_off);

On Tue, Feb 09, 2021 at 04:09:36PM +0100, Jiri Olsa wrote:

SNIP

quoted

quoted

quoted

quoted

                DW_AT_prototyped        (true)
                DW_AT_type      (0x01cfdfe4 "long int")
                DW_AT_external  (true)

Ok, the problem appears to be not in DWARF, but in mcount_loc data.
vfs_truncate's address is not recorded as ftrace-attachable, and thus
pahole ignores it. I don't know why this happens and it's quite
strange, given vfs_truncate is just a normal global function.

right, I can't see it in mcount adresses.. but it begins with instructions
that appears to be nops, which would suggest it's traceable

	ffff80001031f430 <vfs_truncate>:
	ffff80001031f430: 5f 24 03 d5   hint    #34
	ffff80001031f434: 1f 20 03 d5   nop
	ffff80001031f438: 1f 20 03 d5   nop
	ffff80001031f43c: 3f 23 03 d5   hint    #25

quoted

quoted

I'd like to understand this issue before we try to fix it, but there
is at least one improvement we can make: pahole should check ftrace
addresses only for static functions, not the global ones (global ones
should be always attachable, unless they are special, e.g., notrace
and stuff). We can easily check that by looking at the corresponding
symbol. But I'd like to verify that vfs_truncate is ftrace-attachable

I'm still trying to build the kernel.. however ;-)

I finally reproduced.. however arm's not using mcount_loc
but some other special section.. so it's new mess for me

however I tried the same build without LLVM=1 and it passed,
so my guess is that clang is doing something unexpected

jirka

On Tue, Feb 09, 2021 at 05:13:38PM +0100, Jiri Olsa wrote:

On Tue, Feb 09, 2021 at 04:09:36PM +0100, Jiri Olsa wrote:

SNIP

quoted

quoted

quoted

quoted

quoted

                DW_AT_prototyped        (true)
                DW_AT_type      (0x01cfdfe4 "long int")
                DW_AT_external  (true)

Ok, the problem appears to be not in DWARF, but in mcount_loc data.
vfs_truncate's address is not recorded as ftrace-attachable, and thus
pahole ignores it. I don't know why this happens and it's quite
strange, given vfs_truncate is just a normal global function.

right, I can't see it in mcount adresses.. but it begins with instructions
that appears to be nops, which would suggest it's traceable

	ffff80001031f430 <vfs_truncate>:
	ffff80001031f430: 5f 24 03 d5   hint    #34
	ffff80001031f434: 1f 20 03 d5   nop
	ffff80001031f438: 1f 20 03 d5   nop
	ffff80001031f43c: 3f 23 03 d5   hint    #25

quoted

quoted

I'd like to understand this issue before we try to fix it, but there
is at least one improvement we can make: pahole should check ftrace
addresses only for static functions, not the global ones (global ones
should be always attachable, unless they are special, e.g., notrace
and stuff). We can easily check that by looking at the corresponding
symbol. But I'd like to verify that vfs_truncate is ftrace-attachable

I'm still trying to build the kernel.. however ;-)

I finally reproduced.. however arm's not using mcount_loc
but some other special section.. so it's new mess for me

however I tried the same build without LLVM=1 and it passed,
so my guess is that clang is doing something unexpected

jirka

Additionally, if I remove the btfid generation section in
scripts/link-vmlinux.sh to bypass that and get a working Image.gz,
vfs_truncate is in the list of available functions:

/ # grep vfs_truncate /sys/kernel/debug/tracing/available_filter_functions
vfs_truncate

/ # cat /proc/version
Linux version 5.11.0-rc7-dirty (nathan@ubuntu-m3-large-x86) (ClangBuiltLinux clang version 13.0.0 (https://github.com/llvm/llvm-project 8f130f108fedfcf6cb80ef594560a87341028a37), LLD 13.0.0 (https://github.com/llvm/llvm-project 8f130f108fedfcf6cb80ef594560a87341028a37)) #1 SMP PREEMPT Tue Feb 9 09:25:36 MST 2021

/ # zcat /proc/config.gz | grep "DEBUG_INFO_BTF\|FTRACE\|BPF"
# CONFIG_CGROUP_BPF is not set
CONFIG_BPF=y
# CONFIG_BPF_LSM is not set
CONFIG_BPF_SYSCALL=y
CONFIG_ARCH_WANT_DEFAULT_BPF_JIT=y
# CONFIG_BPF_JIT_ALWAYS_ON is not set
CONFIG_BPF_JIT_DEFAULT_ON=y
# CONFIG_BPF_PRELOAD is not set
# CONFIG_NETFILTER_XT_MATCH_BPF is not set
# CONFIG_BPFILTER is not set
# CONFIG_NET_CLS_BPF is not set
# CONFIG_NET_ACT_BPF is not set
CONFIG_BPF_JIT=y
CONFIG_HAVE_EBPF_JIT=y
# CONFIG_PSTORE_FTRACE is not set
CONFIG_DEBUG_INFO_BTF=y
CONFIG_DEBUG_INFO_BTF_MODULES=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_DYNAMIC_FTRACE_WITH_REGS=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_FTRACE=y
CONFIG_DYNAMIC_FTRACE=y
CONFIG_DYNAMIC_FTRACE_WITH_REGS=y
# CONFIG_FTRACE_SYSCALLS is not set
CONFIG_BPF_EVENTS=y
CONFIG_FTRACE_MCOUNT_RECORD=y
# CONFIG_FTRACE_RECORD_RECURSION is not set
# CONFIG_FTRACE_STARTUP_TEST is not set
# CONFIG_TEST_BPF is not set

Cheers,
Nathan

On Tue, Feb 9, 2021 at 5:35 PM Nathan Chancellor [off-list ref] wrote:

On Tue, Feb 09, 2021 at 05:13:38PM +0100, Jiri Olsa wrote:

quoted

On Tue, Feb 09, 2021 at 04:09:36PM +0100, Jiri Olsa wrote:

SNIP

quoted

quoted

quoted

quoted

quoted

                DW_AT_prototyped        (true)
                DW_AT_type      (0x01cfdfe4 "long int")
                DW_AT_external  (true)

Ok, the problem appears to be not in DWARF, but in mcount_loc data.
vfs_truncate's address is not recorded as ftrace-attachable, and thus
pahole ignores it. I don't know why this happens and it's quite
strange, given vfs_truncate is just a normal global function.

right, I can't see it in mcount adresses.. but it begins with instructions
that appears to be nops, which would suggest it's traceable

  ffff80001031f430 <vfs_truncate>:
  ffff80001031f430: 5f 24 03 d5   hint    #34
  ffff80001031f434: 1f 20 03 d5   nop
  ffff80001031f438: 1f 20 03 d5   nop
  ffff80001031f43c: 3f 23 03 d5   hint    #25

quoted

quoted

I'd like to understand this issue before we try to fix it, but there
is at least one improvement we can make: pahole should check ftrace
addresses only for static functions, not the global ones (global ones
should be always attachable, unless they are special, e.g., notrace
and stuff). We can easily check that by looking at the corresponding
symbol. But I'd like to verify that vfs_truncate is ftrace-attachable

I'm still trying to build the kernel.. however ;-)

I finally reproduced.. however arm's not using mcount_loc
but some other special section.. so it's new mess for me

however I tried the same build without LLVM=1 and it passed,
so my guess is that clang is doing something unexpected

jirka

Additionally, if I remove the btfid generation section in
scripts/link-vmlinux.sh to bypass that and get a working Image.gz,
vfs_truncate is in the list of available functions:

I did the same trick by commenting in that section to provide a BROKEN
vmlinux file for linux-bpf folks.

[ BTFIDS-vmlinux.diff ]

diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
index eef40fa9485d..40f1b6aae553 100755
--- a/scripts/link-vmlinux.sh
+++ b/scripts/link-vmlinux.sh

@@ -330,7 +330,7 @@ vmlinux_link vmlinux "${kallsymso}" ${btf_vmlinux_bin_o}

# fill in BTF IDs
if [ -n "${CONFIG_DEBUG_INFO_BTF}" -a -n "${CONFIG_BPF}" ]; then
       info BTFIDS vmlinux
-       ${RESOLVE_BTFIDS} vmlinux
+       ##${RESOLVE_BTFIDS} vmlinux
fi

if [ -n "${CONFIG_BUILDTIME_TABLE_SORT}" ]; then
- EOF -

We should ask linux-kbuild/Masahiro to have an option to OVERRIDE:
When scripts/link-vmlinux.sh fails all generated files like vmlinux get removed.
For further debugging they should be kept.

My €0.02.

- Sedat -

/ # grep vfs_truncate /sys/kernel/debug/tracing/available_filter_functions
vfs_truncate

/ # cat /proc/version
Linux version 5.11.0-rc7-dirty (nathan@ubuntu-m3-large-x86) (ClangBuiltLinux clang version 13.0.0 (https://github.com/llvm/llvm-project 8f130f108fedfcf6cb80ef594560a87341028a37), LLD 13.0.0 (https://github.com/llvm/llvm-project 8f130f108fedfcf6cb80ef594560a87341028a37)) #1 SMP PREEMPT Tue Feb 9 09:25:36 MST 2021

/ # zcat /proc/config.gz | grep "DEBUG_INFO_BTF\|FTRACE\|BPF"
# CONFIG_CGROUP_BPF is not set
CONFIG_BPF=y
# CONFIG_BPF_LSM is not set
CONFIG_BPF_SYSCALL=y
CONFIG_ARCH_WANT_DEFAULT_BPF_JIT=y
# CONFIG_BPF_JIT_ALWAYS_ON is not set
CONFIG_BPF_JIT_DEFAULT_ON=y
# CONFIG_BPF_PRELOAD is not set
# CONFIG_NETFILTER_XT_MATCH_BPF is not set
# CONFIG_BPFILTER is not set
# CONFIG_NET_CLS_BPF is not set
# CONFIG_NET_ACT_BPF is not set
CONFIG_BPF_JIT=y
CONFIG_HAVE_EBPF_JIT=y
# CONFIG_PSTORE_FTRACE is not set
CONFIG_DEBUG_INFO_BTF=y
CONFIG_DEBUG_INFO_BTF_MODULES=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_DYNAMIC_FTRACE_WITH_REGS=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_FTRACE=y
CONFIG_DYNAMIC_FTRACE=y
CONFIG_DYNAMIC_FTRACE_WITH_REGS=y
# CONFIG_FTRACE_SYSCALLS is not set
CONFIG_BPF_EVENTS=y
CONFIG_FTRACE_MCOUNT_RECORD=y
# CONFIG_FTRACE_RECORD_RECURSION is not set
# CONFIG_FTRACE_STARTUP_TEST is not set
# CONFIG_TEST_BPF is not set

Cheers,
Nathan

--
You received this message because you are subscribed to the Google Groups "Clang Built Linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clang-built-linux+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/clang-built-linux/20210209163514.GA1226277%40ubuntu-m3-large-x86.

On Tue, Feb 9, 2021 at 9:07 AM Sedat Dilek [off-list ref] wrote:

We should ask linux-kbuild/Masahiro to have an option to OVERRIDE:
When scripts/link-vmlinux.sh fails all generated files like vmlinux get removed.
For further debugging they should be kept.

I find it annoying, too.  But I usually just comment out the body of
cleanup() in scripts/link-vmlinux.sh.
-- 
Thanks,
~Nick Desaulniers

On Tue, Feb 9, 2021 at 6:12 PM Nick Desaulniers [off-list ref] wrote:

On Tue, Feb 9, 2021 at 9:07 AM Sedat Dilek [off-list ref] wrote:

quoted

We should ask linux-kbuild/Masahiro to have an option to OVERRIDE:
When scripts/link-vmlinux.sh fails all generated files like vmlinux get removed.
For further debugging they should be kept.

I find it annoying, too.  But I usually just comment out the body of
cleanup() in scripts/link-vmlinux.sh.

That's fine with me.

- Sedat -

On Tue, Feb 09, 2021 at 05:13:42PM +0100, Jiri Olsa wrote:

On Tue, Feb 09, 2021 at 04:09:36PM +0100, Jiri Olsa wrote:

SNIP

quoted

quoted

quoted

quoted

quoted

                DW_AT_prototyped        (true)
                DW_AT_type      (0x01cfdfe4 "long int")
                DW_AT_external  (true)

Ok, the problem appears to be not in DWARF, but in mcount_loc data.
vfs_truncate's address is not recorded as ftrace-attachable, and thus
pahole ignores it. I don't know why this happens and it's quite
strange, given vfs_truncate is just a normal global function.

right, I can't see it in mcount adresses.. but it begins with instructions
that appears to be nops, which would suggest it's traceable

	ffff80001031f430 <vfs_truncate>:
	ffff80001031f430: 5f 24 03 d5   hint    #34
	ffff80001031f434: 1f 20 03 d5   nop
	ffff80001031f438: 1f 20 03 d5   nop
	ffff80001031f43c: 3f 23 03 d5   hint    #25

quoted

quoted

I'd like to understand this issue before we try to fix it, but there
is at least one improvement we can make: pahole should check ftrace
addresses only for static functions, not the global ones (global ones
should be always attachable, unless they are special, e.g., notrace
and stuff). We can easily check that by looking at the corresponding
symbol. But I'd like to verify that vfs_truncate is ftrace-attachable

I'm still trying to build the kernel.. however ;-)

I finally reproduced.. however arm's not using mcount_loc
but some other special section.. so it's new mess for me

so ftrace data actualy has vfs_truncate address but with extra 4 bytes:

	ffff80001031f434

real vfs_truncate address:

	ffff80001031f430 g     F .text  0000000000000168 vfs_truncate

vfs_truncate disasm:

	ffff80001031f430 <vfs_truncate>:
	ffff80001031f430: 5f 24 03 d5   hint    #34
	ffff80001031f434: 1f 20 03 d5   nop
	ffff80001031f438: 1f 20 03 d5   nop
	ffff80001031f43c: 3f 23 03 d5   hint    #25

thats why we don't match it in pahole.. I checked few other functions
and some have the same problem and some match the function boundary

those that match don't have that first hint instrucion, like:

	ffff800010321e40 <do_faccessat>:
	ffff800010321e40: 1f 20 03 d5   nop
	ffff800010321e44: 1f 20 03 d5   nop
	ffff800010321e48: 3f 23 03 d5   hint    #25

any hints about hint instructions? ;-)

jirka

adding Arnaldo to the loop

jirka

On Tue, Feb 09, 2021 at 08:06:16PM +0100, Jiri Olsa wrote:

On Tue, Feb 09, 2021 at 05:13:42PM +0100, Jiri Olsa wrote:

quoted

On Tue, Feb 09, 2021 at 04:09:36PM +0100, Jiri Olsa wrote:

SNIP

quoted

quoted

quoted

quoted

quoted

                DW_AT_prototyped        (true)
                DW_AT_type      (0x01cfdfe4 "long int")
                DW_AT_external  (true)

Ok, the problem appears to be not in DWARF, but in mcount_loc data.
vfs_truncate's address is not recorded as ftrace-attachable, and thus
pahole ignores it. I don't know why this happens and it's quite
strange, given vfs_truncate is just a normal global function.

right, I can't see it in mcount adresses.. but it begins with instructions
that appears to be nops, which would suggest it's traceable

	ffff80001031f430 <vfs_truncate>:
	ffff80001031f430: 5f 24 03 d5   hint    #34
	ffff80001031f434: 1f 20 03 d5   nop
	ffff80001031f438: 1f 20 03 d5   nop
	ffff80001031f43c: 3f 23 03 d5   hint    #25

quoted

quoted

I'd like to understand this issue before we try to fix it, but there
is at least one improvement we can make: pahole should check ftrace
addresses only for static functions, not the global ones (global ones
should be always attachable, unless they are special, e.g., notrace
and stuff). We can easily check that by looking at the corresponding
symbol. But I'd like to verify that vfs_truncate is ftrace-attachable

I'm still trying to build the kernel.. however ;-)

I finally reproduced.. however arm's not using mcount_loc
but some other special section.. so it's new mess for me

so ftrace data actualy has vfs_truncate address but with extra 4 bytes:

	ffff80001031f434

real vfs_truncate address:

	ffff80001031f430 g     F .text  0000000000000168 vfs_truncate

vfs_truncate disasm:

	ffff80001031f430 <vfs_truncate>:
	ffff80001031f430: 5f 24 03 d5   hint    #34
	ffff80001031f434: 1f 20 03 d5   nop
	ffff80001031f438: 1f 20 03 d5   nop
	ffff80001031f43c: 3f 23 03 d5   hint    #25

thats why we don't match it in pahole.. I checked few other functions
and some have the same problem and some match the function boundary

those that match don't have that first hint instrucion, like:

	ffff800010321e40 <do_faccessat>:
	ffff800010321e40: 1f 20 03 d5   nop
	ffff800010321e44: 1f 20 03 d5   nop
	ffff800010321e48: 3f 23 03 d5   hint    #25

any hints about hint instructions? ;-)

jirka

On Tue, Feb 9, 2021 at 11:06 AM Jiri Olsa [off-list ref] wrote:

On Tue, Feb 09, 2021 at 05:13:42PM +0100, Jiri Olsa wrote:

quoted

On Tue, Feb 09, 2021 at 04:09:36PM +0100, Jiri Olsa wrote:

SNIP

quoted

quoted

quoted

quoted

quoted

                DW_AT_prototyped        (true)
                DW_AT_type      (0x01cfdfe4 "long int")
                DW_AT_external  (true)

Ok, the problem appears to be not in DWARF, but in mcount_loc data.
vfs_truncate's address is not recorded as ftrace-attachable, and thus
pahole ignores it. I don't know why this happens and it's quite
strange, given vfs_truncate is just a normal global function.

right, I can't see it in mcount adresses.. but it begins with instructions
that appears to be nops, which would suggest it's traceable

  ffff80001031f430 <vfs_truncate>:
  ffff80001031f430: 5f 24 03 d5   hint    #34
  ffff80001031f434: 1f 20 03 d5   nop
  ffff80001031f438: 1f 20 03 d5   nop
  ffff80001031f43c: 3f 23 03 d5   hint    #25

quoted

quoted

I'd like to understand this issue before we try to fix it, but there
is at least one improvement we can make: pahole should check ftrace
addresses only for static functions, not the global ones (global ones
should be always attachable, unless they are special, e.g., notrace
and stuff). We can easily check that by looking at the corresponding
symbol. But I'd like to verify that vfs_truncate is ftrace-attachable

I'm still trying to build the kernel.. however ;-)

I finally reproduced.. however arm's not using mcount_loc
but some other special section.. so it's new mess for me

so ftrace data actualy has vfs_truncate address but with extra 4 bytes:

        ffff80001031f434

real vfs_truncate address:

        ffff80001031f430 g     F .text  0000000000000168 vfs_truncate

vfs_truncate disasm:

        ffff80001031f430 <vfs_truncate>:
        ffff80001031f430: 5f 24 03 d5   hint    #34
        ffff80001031f434: 1f 20 03 d5   nop
        ffff80001031f438: 1f 20 03 d5   nop
        ffff80001031f43c: 3f 23 03 d5   hint    #25

thats why we don't match it in pahole.. I checked few other functions
and some have the same problem and some match the function boundary

those that match don't have that first hint instrucion, like:

        ffff800010321e40 <do_faccessat>:
        ffff800010321e40: 1f 20 03 d5   nop
        ffff800010321e44: 1f 20 03 d5   nop
        ffff800010321e48: 3f 23 03 d5   hint    #25

any hints about hint instructions? ;-)

aarch64 makes *some* newer instructions reuse the "hint" ie "nop"
encoding space to make software backwards compatible on older hardware
that doesn't support such instructions.  Is this BTI, perhaps? (The
function is perhaps the destination of an indirect call?)
-- 
Thanks,
~Nick Desaulniers

On Tue, Feb 09, 2021 at 12:09:31PM -0800, Nick Desaulniers wrote:

On Tue, Feb 9, 2021 at 11:06 AM Jiri Olsa [off-list ref] wrote:

quoted

On Tue, Feb 09, 2021 at 05:13:42PM +0100, Jiri Olsa wrote:

quoted

On Tue, Feb 09, 2021 at 04:09:36PM +0100, Jiri Olsa wrote:

SNIP

quoted

quoted

quoted

quoted

quoted

                DW_AT_prototyped        (true)
                DW_AT_type      (0x01cfdfe4 "long int")
                DW_AT_external  (true)

Ok, the problem appears to be not in DWARF, but in mcount_loc data.
vfs_truncate's address is not recorded as ftrace-attachable, and thus
pahole ignores it. I don't know why this happens and it's quite
strange, given vfs_truncate is just a normal global function.

right, I can't see it in mcount adresses.. but it begins with instructions
that appears to be nops, which would suggest it's traceable

  ffff80001031f430 <vfs_truncate>:
  ffff80001031f430: 5f 24 03 d5   hint    #34
  ffff80001031f434: 1f 20 03 d5   nop
  ffff80001031f438: 1f 20 03 d5   nop
  ffff80001031f43c: 3f 23 03 d5   hint    #25

quoted

quoted

I'd like to understand this issue before we try to fix it, but there
is at least one improvement we can make: pahole should check ftrace
addresses only for static functions, not the global ones (global ones
should be always attachable, unless they are special, e.g., notrace
and stuff). We can easily check that by looking at the corresponding
symbol. But I'd like to verify that vfs_truncate is ftrace-attachable

I'm still trying to build the kernel.. however ;-)

I finally reproduced.. however arm's not using mcount_loc
but some other special section.. so it's new mess for me

so ftrace data actualy has vfs_truncate address but with extra 4 bytes:

        ffff80001031f434

real vfs_truncate address:

        ffff80001031f430 g     F .text  0000000000000168 vfs_truncate

vfs_truncate disasm:

        ffff80001031f430 <vfs_truncate>:
        ffff80001031f430: 5f 24 03 d5   hint    #34
        ffff80001031f434: 1f 20 03 d5   nop
        ffff80001031f438: 1f 20 03 d5   nop
        ffff80001031f43c: 3f 23 03 d5   hint    #25

thats why we don't match it in pahole.. I checked few other functions
and some have the same problem and some match the function boundary

those that match don't have that first hint instrucion, like:

        ffff800010321e40 <do_faccessat>:
        ffff800010321e40: 1f 20 03 d5   nop
        ffff800010321e44: 1f 20 03 d5   nop
        ffff800010321e48: 3f 23 03 d5   hint    #25

any hints about hint instructions? ;-)

aarch64 makes *some* newer instructions reuse the "hint" ie "nop"
encoding space to make software backwards compatible on older hardware
that doesn't support such instructions.  Is this BTI, perhaps? (The
function is perhaps the destination of an indirect call?)

I see, I think we can't take ftrace addresses as start of the function
because there could be extra instruction(s) related to the call before
it like here

we need to check ftrace address be within the function/symbol,
not exact start

jirka

On Tue, Feb 9, 2021 at 7:09 AM Jiri Olsa [off-list ref] wrote:

I wouldn't trust DWARF, honestly. Wouldn't checking GLOBAL vs LOCAL
FUNC ELF symbol be more reliable?

On Tue, Feb 09, 2021 at 12:59:51PM -0800, Andrii Nakryiko wrote:

On Tue, Feb 9, 2021 at 7:09 AM Jiri Olsa [off-list ref] wrote:

quoted

On Tue, Feb 09, 2021 at 01:36:41PM +0100, Jiri Olsa wrote:

quoted

On Tue, Feb 09, 2021 at 12:49:04AM -0700, Nathan Chancellor wrote:

quoted

On Mon, Feb 08, 2021 at 10:56:36PM -0800, Andrii Nakryiko wrote:

quoted

On Mon, Feb 8, 2021 at 10:13 PM Andrii Nakryiko
[off-list ref] wrote:

quoted

On Mon, Feb 8, 2021 at 10:09 PM Andrii Nakryiko
[off-list ref] wrote:

quoted

On Mon, Feb 8, 2021 at 9:23 PM Nathan Chancellor [off-list ref] wrote:

quoted

On Mon, Feb 08, 2021 at 08:45:43PM -0800, Andrii Nakryiko wrote:

quoted

On Mon, Feb 8, 2021 at 7:44 PM Nathan Chancellor [off-list ref] wrote:

quoted

Hi all,

Recently, an issue with CONFIG_DEBUG_INFO_BTF was reported for arm64:
https://groups.google.com/g/clang-built-linux/c/de_mNh23FOc/m/E7cu5BwbBAAJ

$ make -skj"$(nproc)" ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- \
                      LLVM=1 O=build/aarch64 defconfig

$ scripts/config \
    --file build/aarch64/.config \
    -e BPF_SYSCALL \
    -e DEBUG_INFO_BTF \
    -e FTRACE \
    -e FUNCTION_TRACER

$ make -skj"$(nproc)" ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- \
                      LLVM=1 O=build/aarch64 olddefconfig all
...
FAILED unresolved symbol vfs_truncate
...

My bisect landed on commit 6e22ab9da793 ("bpf: Add d_path helper")
although that seems obvious given that is what introduced
BTF_ID(func, vfs_truncate).

I am using the latest pahole v1.20 and LLVM is at
https://github.com/llvm/llvm-project/commit/14da287e18846ea86e45b421dc47f78ecc5aa7cb
although I can reproduce back to LLVM 10.0.1, which is the earliest
version that the kernel supports. I am very unfamiliar with BPF so I
have no idea what is going wrong here. Is this a known issue?

I'll skip the reproduction games this time and will just request the
vmlinux image. Please upload somewhere so that we can look at DWARF
and see what's going on. Thanks.

Sure thing, let me know if this works. I uploaded in two places to make
it easier to grab:

zstd compressed:
https://github.com/nathanchance/bug-files/blob/3b2873751e29311e084ae2c71604a1963f5e1a48/btf-aarch64/vmlinux.zst

Thanks. I clearly see at least one instance of seemingly well-formed
vfs_truncate DWARF declaration. Also there is a proper ELF symbol for
it. Which means it should have been generated in BTF, but it doesn't
appear to be, so it does seem like a pahole bug. I (or someone else
before me) will continue tomorrow.

$ llvm-dwarfdump vmlinux
...

0x00052e6f:   DW_TAG_subprogram
                DW_AT_name      ("vfs_truncate")
                DW_AT_decl_file
("/home/nathan/cbl/src/linux/include/linux/fs.h")
                DW_AT_decl_line (2520)
                DW_AT_prototyped        (true)
                DW_AT_type      (0x000452cb "long int")
                DW_AT_declaration       (true)
                DW_AT_external  (true)

0x00052e7b:     DW_TAG_formal_parameter
                  DW_AT_type    (0x00045fc6 "const path*")

0x00052e80:     DW_TAG_formal_parameter
                  DW_AT_type    (0x00045213 "long long int")

...

... and here's the *only* other one (not marked as declaration, but I
thought we already handle that, Jiri?):

0x01d0da35:   DW_TAG_subprogram
                DW_AT_low_pc    (0xffff80001031f430)
                DW_AT_high_pc   (0xffff80001031f598)
                DW_AT_frame_base        (DW_OP_reg29)
                DW_AT_GNU_all_call_sites        (true)
                DW_AT_name      ("vfs_truncate")
                DW_AT_decl_file ("/home/nathan/cbl/src/linux/fs/open.c")
                DW_AT_decl_line (69)
                DW_AT_prototyped        (true)
                DW_AT_type      (0x01cfdfe4 "long int")
                DW_AT_external  (true)

Ok, the problem appears to be not in DWARF, but in mcount_loc data.
vfs_truncate's address is not recorded as ftrace-attachable, and thus
pahole ignores it. I don't know why this happens and it's quite
strange, given vfs_truncate is just a normal global function.

right, I can't see it in mcount adresses.. but it begins with instructions
that appears to be nops, which would suggest it's traceable

      ffff80001031f430 <vfs_truncate>:
      ffff80001031f430: 5f 24 03 d5   hint    #34
      ffff80001031f434: 1f 20 03 d5   nop
      ffff80001031f438: 1f 20 03 d5   nop
      ffff80001031f43c: 3f 23 03 d5   hint    #25

quoted

quoted

I'd like to understand this issue before we try to fix it, but there
is at least one improvement we can make: pahole should check ftrace
addresses only for static functions, not the global ones (global ones
should be always attachable, unless they are special, e.g., notrace
and stuff). We can easily check that by looking at the corresponding
symbol. But I'd like to verify that vfs_truncate is ftrace-attachable

I'm still trying to build the kernel.. however ;-)

patch below adds the ftrace check only for static functions
and lets the externa go through.. but as you said, in this
case we'll need to figure out the 'notrace' and other checks
ftrace is doing

jirka


---

diff --git a/btf_encoder.c b/btf_encoder.c
index b124ec20a689..4d147406cfa5 100644
--- a/btf_encoder.c
+++ b/btf_encoder.c

@@ -734,7 +734,7 @@ int cu__encode_btf(struct cu *cu, int verbose, bool force,
                        continue;
                if (!has_arg_names(cu, &fn->proto))
                        continue;
-               if (functions_cnt) {
+               if (!fn->external && functions_cnt) {

I wouldn't trust DWARF, honestly. Wouldn't checking GLOBAL vs LOCAL
FUNC ELF symbol be more reliable?

that'd mean extra bsearch on each processed function,
on the ther hand, we'are already slow ;-) I'll check
how big the slowdown would be

jirka

On Tue, Feb 09, 2021 at 09:50:48PM +0100, Jiri Olsa wrote:

On Tue, Feb 09, 2021 at 12:09:31PM -0800, Nick Desaulniers wrote:

quoted

On Tue, Feb 9, 2021 at 11:06 AM Jiri Olsa [off-list ref] wrote:

quoted

On Tue, Feb 09, 2021 at 05:13:42PM +0100, Jiri Olsa wrote:

quoted

On Tue, Feb 09, 2021 at 04:09:36PM +0100, Jiri Olsa wrote:

SNIP

quoted

quoted

quoted

quoted

quoted

                DW_AT_prototyped        (true)
                DW_AT_type      (0x01cfdfe4 "long int")
                DW_AT_external  (true)

Ok, the problem appears to be not in DWARF, but in mcount_loc data.
vfs_truncate's address is not recorded as ftrace-attachable, and thus
pahole ignores it. I don't know why this happens and it's quite
strange, given vfs_truncate is just a normal global function.

right, I can't see it in mcount adresses.. but it begins with instructions
that appears to be nops, which would suggest it's traceable

  ffff80001031f430 <vfs_truncate>:
  ffff80001031f430: 5f 24 03 d5   hint    #34
  ffff80001031f434: 1f 20 03 d5   nop
  ffff80001031f438: 1f 20 03 d5   nop
  ffff80001031f43c: 3f 23 03 d5   hint    #25

quoted

quoted

I'd like to understand this issue before we try to fix it, but there
is at least one improvement we can make: pahole should check ftrace
addresses only for static functions, not the global ones (global ones
should be always attachable, unless they are special, e.g., notrace
and stuff). We can easily check that by looking at the corresponding
symbol. But I'd like to verify that vfs_truncate is ftrace-attachable

I'm still trying to build the kernel.. however ;-)

I finally reproduced.. however arm's not using mcount_loc
but some other special section.. so it's new mess for me

so ftrace data actualy has vfs_truncate address but with extra 4 bytes:

        ffff80001031f434

real vfs_truncate address:

        ffff80001031f430 g     F .text  0000000000000168 vfs_truncate

vfs_truncate disasm:

        ffff80001031f430 <vfs_truncate>:
        ffff80001031f430: 5f 24 03 d5   hint    #34
        ffff80001031f434: 1f 20 03 d5   nop
        ffff80001031f438: 1f 20 03 d5   nop
        ffff80001031f43c: 3f 23 03 d5   hint    #25

thats why we don't match it in pahole.. I checked few other functions
and some have the same problem and some match the function boundary

those that match don't have that first hint instrucion, like:

        ffff800010321e40 <do_faccessat>:
        ffff800010321e40: 1f 20 03 d5   nop
        ffff800010321e44: 1f 20 03 d5   nop
        ffff800010321e48: 3f 23 03 d5   hint    #25

any hints about hint instructions? ;-)

aarch64 makes *some* newer instructions reuse the "hint" ie "nop"
encoding space to make software backwards compatible on older hardware
that doesn't support such instructions.  Is this BTI, perhaps? (The
function is perhaps the destination of an indirect call?)

I see, I think we can't take ftrace addresses as start of the function
because there could be extra instruction(s) related to the call before
it like here

we need to check ftrace address be within the function/symbol,
not exact start

the build with gcc passed only because mcount data are all zeros
and pahole falls back to 'not-ftrace' mode

	$ llvm-objdump -t build/aarch64-gcc/vmlinux | grep mcount
	ffff800011eb4840 g       .init.data     0000000000000000 __stop_mcount_loc
	ffff800011e47d58 g       .init.data     0000000000000000 __start_mcount_loc

	$ llvm-objdump -s build/aarch64-gcc/vmlinux	
	ffff800011e47d50 00000000 00000000 00000000 00000000  ................
	ffff800011e47d60 00000000 00000000 00000000 00000000  ................
	ffff800011e47d70 00000000 00000000 00000000 00000000  ................
	ffff800011e47d80 00000000 00000000 00000000 00000000  ................
	ffff800011e47d90 00000000 00000000 00000000 00000000  ................
	...

	we should check on why it's zero

	Nathan, any chance you could run kernel built with gcc and check on ftrace?


the build with clang fails because the ftrace data are there,
but pahole takes them as 'start' of the function, which is wrong

	$ llvm-objdump -t build/aarch64/vmlinux | grep mcount
	ffff800011d27d10 g       .init.data     0000000000000000 __start_mcount_loc
	ffff800011d90038 g       .init.data     0000000000000000 __stop_mcount_loc

	$ llvm-objdump -s build/aarch64-gcc/vmlinux	
	ffff800011d27d10 cc330110 0080ffff 1c340110 0080ffff  .3.......4......
	ffff800011d27d20 6c340110 0080ffff 1004c111 0080ffff  l4..............
	ffff800011d27d30 3804c111 0080ffff 6004c111 0080ffff  8.......`.......
	ffff800011d27d40 8804c111 0080ffff 0405c111 0080ffff  ................
	ffff800011d27d50 3805c111 0080ffff 7c05c111 0080ffff  8.......|.......
	...

I think if we fix pahole to take check the ftrace address is
within the processed function, we should be fine.. I'll try to
send something soon

jirka

On Tue, Feb 9, 2021 at 1:55 PM Jiri Olsa [off-list ref] wrote:

On Tue, Feb 09, 2021 at 12:59:51PM -0800, Andrii Nakryiko wrote:

quoted

On Tue, Feb 9, 2021 at 7:09 AM Jiri Olsa [off-list ref] wrote:

quoted

On Tue, Feb 09, 2021 at 01:36:41PM +0100, Jiri Olsa wrote:

quoted

On Tue, Feb 09, 2021 at 12:49:04AM -0700, Nathan Chancellor wrote:

quoted

On Mon, Feb 08, 2021 at 10:56:36PM -0800, Andrii Nakryiko wrote:

quoted

On Mon, Feb 8, 2021 at 10:13 PM Andrii Nakryiko
[off-list ref] wrote:

quoted

On Mon, Feb 8, 2021 at 10:09 PM Andrii Nakryiko
[off-list ref] wrote:

quoted

On Mon, Feb 8, 2021 at 9:23 PM Nathan Chancellor [off-list ref] wrote:

quoted

On Mon, Feb 08, 2021 at 08:45:43PM -0800, Andrii Nakryiko wrote:

quoted

On Mon, Feb 8, 2021 at 7:44 PM Nathan Chancellor [off-list ref] wrote:

quoted

Hi all,

Recently, an issue with CONFIG_DEBUG_INFO_BTF was reported for arm64:
https://groups.google.com/g/clang-built-linux/c/de_mNh23FOc/m/E7cu5BwbBAAJ

$ make -skj"$(nproc)" ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- \
                      LLVM=1 O=build/aarch64 defconfig

$ scripts/config \
    --file build/aarch64/.config \
    -e BPF_SYSCALL \
    -e DEBUG_INFO_BTF \
    -e FTRACE \
    -e FUNCTION_TRACER

$ make -skj"$(nproc)" ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- \
                      LLVM=1 O=build/aarch64 olddefconfig all
...
FAILED unresolved symbol vfs_truncate
...

My bisect landed on commit 6e22ab9da793 ("bpf: Add d_path helper")
although that seems obvious given that is what introduced
BTF_ID(func, vfs_truncate).

I am using the latest pahole v1.20 and LLVM is at
https://github.com/llvm/llvm-project/commit/14da287e18846ea86e45b421dc47f78ecc5aa7cb
although I can reproduce back to LLVM 10.0.1, which is the earliest
version that the kernel supports. I am very unfamiliar with BPF so I
have no idea what is going wrong here. Is this a known issue?

I'll skip the reproduction games this time and will just request the
vmlinux image. Please upload somewhere so that we can look at DWARF
and see what's going on. Thanks.

Sure thing, let me know if this works. I uploaded in two places to make
it easier to grab:

zstd compressed:
https://github.com/nathanchance/bug-files/blob/3b2873751e29311e084ae2c71604a1963f5e1a48/btf-aarch64/vmlinux.zst

Thanks. I clearly see at least one instance of seemingly well-formed
vfs_truncate DWARF declaration. Also there is a proper ELF symbol for
it. Which means it should have been generated in BTF, but it doesn't
appear to be, so it does seem like a pahole bug. I (or someone else
before me) will continue tomorrow.

$ llvm-dwarfdump vmlinux
...

0x00052e6f:   DW_TAG_subprogram
                DW_AT_name      ("vfs_truncate")
                DW_AT_decl_file
("/home/nathan/cbl/src/linux/include/linux/fs.h")
                DW_AT_decl_line (2520)
                DW_AT_prototyped        (true)
                DW_AT_type      (0x000452cb "long int")
                DW_AT_declaration       (true)
                DW_AT_external  (true)

0x00052e7b:     DW_TAG_formal_parameter
                  DW_AT_type    (0x00045fc6 "const path*")

0x00052e80:     DW_TAG_formal_parameter
                  DW_AT_type    (0x00045213 "long long int")

...

... and here's the *only* other one (not marked as declaration, but I
thought we already handle that, Jiri?):

0x01d0da35:   DW_TAG_subprogram
                DW_AT_low_pc    (0xffff80001031f430)
                DW_AT_high_pc   (0xffff80001031f598)
                DW_AT_frame_base        (DW_OP_reg29)
                DW_AT_GNU_all_call_sites        (true)
                DW_AT_name      ("vfs_truncate")
                DW_AT_decl_file ("/home/nathan/cbl/src/linux/fs/open.c")
                DW_AT_decl_line (69)
                DW_AT_prototyped        (true)
                DW_AT_type      (0x01cfdfe4 "long int")
                DW_AT_external  (true)

Ok, the problem appears to be not in DWARF, but in mcount_loc data.
vfs_truncate's address is not recorded as ftrace-attachable, and thus
pahole ignores it. I don't know why this happens and it's quite
strange, given vfs_truncate is just a normal global function.

right, I can't see it in mcount adresses.. but it begins with instructions
that appears to be nops, which would suggest it's traceable

      ffff80001031f430 <vfs_truncate>:
      ffff80001031f430: 5f 24 03 d5   hint    #34
      ffff80001031f434: 1f 20 03 d5   nop
      ffff80001031f438: 1f 20 03 d5   nop
      ffff80001031f43c: 3f 23 03 d5   hint    #25

quoted

quoted

I'd like to understand this issue before we try to fix it, but there
is at least one improvement we can make: pahole should check ftrace
addresses only for static functions, not the global ones (global ones
should be always attachable, unless they are special, e.g., notrace
and stuff). We can easily check that by looking at the corresponding
symbol. But I'd like to verify that vfs_truncate is ftrace-attachable

I'm still trying to build the kernel.. however ;-)

patch below adds the ftrace check only for static functions
and lets the externa go through.. but as you said, in this
case we'll need to figure out the 'notrace' and other checks
ftrace is doing

jirka


---

diff --git a/btf_encoder.c b/btf_encoder.c
index b124ec20a689..4d147406cfa5 100644
--- a/btf_encoder.c
+++ b/btf_encoder.c

@@ -734,7 +734,7 @@ int cu__encode_btf(struct cu *cu, int verbose, bool force,
                        continue;
                if (!has_arg_names(cu, &fn->proto))
                        continue;
-               if (functions_cnt) {
+               if (!fn->external && functions_cnt) {

I wouldn't trust DWARF, honestly. Wouldn't checking GLOBAL vs LOCAL
FUNC ELF symbol be more reliable?

that'd mean extra bsearch on each processed function,
on the ther hand, we'are already slow ;-) I'll check
how big the slowdown would be

We currently record addresses and do binary search. Now we need to
record address + size and still do binary search with a slightly
different semantics (find closest entry >= addr). Then just check that
it overlaps, taking into account the length of the function code. It
shouldn't result in a noticeable slowdown. Might be actually faster,
because we might avoid callback function call costs.

jirka

On Tue, Feb 09, 2021 at 10:41:44PM +0100, Jiri Olsa wrote:

On Tue, Feb 09, 2021 at 09:50:48PM +0100, Jiri Olsa wrote:

quoted

On Tue, Feb 09, 2021 at 12:09:31PM -0800, Nick Desaulniers wrote:

quoted

On Tue, Feb 9, 2021 at 11:06 AM Jiri Olsa [off-list ref] wrote:

quoted

On Tue, Feb 09, 2021 at 05:13:42PM +0100, Jiri Olsa wrote:

quoted

On Tue, Feb 09, 2021 at 04:09:36PM +0100, Jiri Olsa wrote:

SNIP

quoted

quoted

quoted

quoted

quoted

                DW_AT_prototyped        (true)
                DW_AT_type      (0x01cfdfe4 "long int")
                DW_AT_external  (true)

Ok, the problem appears to be not in DWARF, but in mcount_loc data.
vfs_truncate's address is not recorded as ftrace-attachable, and thus
pahole ignores it. I don't know why this happens and it's quite
strange, given vfs_truncate is just a normal global function.

right, I can't see it in mcount adresses.. but it begins with instructions
that appears to be nops, which would suggest it's traceable

  ffff80001031f430 <vfs_truncate>:
  ffff80001031f430: 5f 24 03 d5   hint    #34
  ffff80001031f434: 1f 20 03 d5   nop
  ffff80001031f438: 1f 20 03 d5   nop
  ffff80001031f43c: 3f 23 03 d5   hint    #25

quoted

quoted

I'd like to understand this issue before we try to fix it, but there
is at least one improvement we can make: pahole should check ftrace
addresses only for static functions, not the global ones (global ones
should be always attachable, unless they are special, e.g., notrace
and stuff). We can easily check that by looking at the corresponding
symbol. But I'd like to verify that vfs_truncate is ftrace-attachable

I'm still trying to build the kernel.. however ;-)

I finally reproduced.. however arm's not using mcount_loc
but some other special section.. so it's new mess for me

so ftrace data actualy has vfs_truncate address but with extra 4 bytes:

        ffff80001031f434

real vfs_truncate address:

        ffff80001031f430 g     F .text  0000000000000168 vfs_truncate

vfs_truncate disasm:

        ffff80001031f430 <vfs_truncate>:
        ffff80001031f430: 5f 24 03 d5   hint    #34
        ffff80001031f434: 1f 20 03 d5   nop
        ffff80001031f438: 1f 20 03 d5   nop
        ffff80001031f43c: 3f 23 03 d5   hint    #25

thats why we don't match it in pahole.. I checked few other functions
and some have the same problem and some match the function boundary

those that match don't have that first hint instrucion, like:

        ffff800010321e40 <do_faccessat>:
        ffff800010321e40: 1f 20 03 d5   nop
        ffff800010321e44: 1f 20 03 d5   nop
        ffff800010321e48: 3f 23 03 d5   hint    #25

any hints about hint instructions? ;-)

aarch64 makes *some* newer instructions reuse the "hint" ie "nop"
encoding space to make software backwards compatible on older hardware
that doesn't support such instructions.  Is this BTI, perhaps? (The
function is perhaps the destination of an indirect call?)

I see, I think we can't take ftrace addresses as start of the function
because there could be extra instruction(s) related to the call before
it like here

we need to check ftrace address be within the function/symbol,
not exact start

the build with gcc passed only because mcount data are all zeros
and pahole falls back to 'not-ftrace' mode

	$ llvm-objdump -t build/aarch64-gcc/vmlinux | grep mcount
	ffff800011eb4840 g       .init.data     0000000000000000 __stop_mcount_loc
	ffff800011e47d58 g       .init.data     0000000000000000 __start_mcount_loc

	$ llvm-objdump -s build/aarch64-gcc/vmlinux	
	ffff800011e47d50 00000000 00000000 00000000 00000000  ................
	ffff800011e47d60 00000000 00000000 00000000 00000000  ................
	ffff800011e47d70 00000000 00000000 00000000 00000000  ................
	ffff800011e47d80 00000000 00000000 00000000 00000000  ................
	ffff800011e47d90 00000000 00000000 00000000 00000000  ................
	...

	we should check on why it's zero

	Nathan, any chance you could run kernel built with gcc and check on ftrace?

Sure, with GCC 10.2.0:

/ # cat /proc/version
Linux version 5.11.0-rc7 (nathan@ubuntu-m3-large-x86) (aarch64-linux-gcc (GCC) 10.2.0, GNU ld (GNU Binutils) 2.35) #1 SMP PREEMPT Tue Feb 9 16:04:19 MST 2021

/ # grep vfs_truncate /sys/kernel/debug/tracing/available_filter_functions
vfs_truncate

/ # zcat /proc/config.gz | grep "DEBUG_INFO_BTF\|FTRACE\|BPF"
# CONFIG_CGROUP_BPF is not set
CONFIG_BPF=y
# CONFIG_BPF_LSM is not set
CONFIG_BPF_SYSCALL=y
CONFIG_ARCH_WANT_DEFAULT_BPF_JIT=y
# CONFIG_BPF_JIT_ALWAYS_ON is not set
CONFIG_BPF_JIT_DEFAULT_ON=y
# CONFIG_BPF_PRELOAD is not set
# CONFIG_NETFILTER_XT_MATCH_BPF is not set
# CONFIG_BPFILTER is not set
# CONFIG_NET_CLS_BPF is not set
# CONFIG_NET_ACT_BPF is not set
CONFIG_BPF_JIT=y
CONFIG_HAVE_EBPF_JIT=y
# CONFIG_PSTORE_FTRACE is not set
CONFIG_DEBUG_INFO_BTF=y
CONFIG_DEBUG_INFO_BTF_MODULES=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_DYNAMIC_FTRACE_WITH_REGS=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_FTRACE=y
CONFIG_DYNAMIC_FTRACE=y
CONFIG_DYNAMIC_FTRACE_WITH_REGS=y
# CONFIG_FTRACE_SYSCALLS is not set
CONFIG_BPF_EVENTS=y
CONFIG_FTRACE_MCOUNT_RECORD=y
# CONFIG_FTRACE_RECORD_RECURSION is not set
# CONFIG_FTRACE_STARTUP_TEST is not set
# CONFIG_TEST_BPF is not set

Cheers,
Nathan

the build with clang fails because the ftrace data are there,
but pahole takes them as 'start' of the function, which is wrong

	$ llvm-objdump -t build/aarch64/vmlinux | grep mcount
	ffff800011d27d10 g       .init.data     0000000000000000 __start_mcount_loc
	ffff800011d90038 g       .init.data     0000000000000000 __stop_mcount_loc

	$ llvm-objdump -s build/aarch64-gcc/vmlinux	
	ffff800011d27d10 cc330110 0080ffff 1c340110 0080ffff  .3.......4......
	ffff800011d27d20 6c340110 0080ffff 1004c111 0080ffff  l4..............
	ffff800011d27d30 3804c111 0080ffff 6004c111 0080ffff  8.......`.......
	ffff800011d27d40 8804c111 0080ffff 0405c111 0080ffff  ................
	ffff800011d27d50 3805c111 0080ffff 7c05c111 0080ffff  8.......|.......
	...

I think if we fix pahole to take check the ftrace address is
within the processed function, we should be fine.. I'll try to
send something soon

jirka

On Tue, Feb 09, 2021 at 12:09:31PM -0800, Nick Desaulniers wrote:

On Tue, Feb 9, 2021 at 11:06 AM Jiri Olsa [off-list ref] wrote:

quoted

On Tue, Feb 09, 2021 at 05:13:42PM +0100, Jiri Olsa wrote:

quoted

On Tue, Feb 09, 2021 at 04:09:36PM +0100, Jiri Olsa wrote:

SNIP

quoted

quoted

quoted

quoted

quoted

                DW_AT_prototyped        (true)
                DW_AT_type      (0x01cfdfe4 "long int")
                DW_AT_external  (true)

Ok, the problem appears to be not in DWARF, but in mcount_loc data.
vfs_truncate's address is not recorded as ftrace-attachable, and thus
pahole ignores it. I don't know why this happens and it's quite
strange, given vfs_truncate is just a normal global function.

right, I can't see it in mcount adresses.. but it begins with instructions
that appears to be nops, which would suggest it's traceable

  ffff80001031f430 <vfs_truncate>:
  ffff80001031f430: 5f 24 03 d5   hint    #34
  ffff80001031f434: 1f 20 03 d5   nop
  ffff80001031f438: 1f 20 03 d5   nop
  ffff80001031f43c: 3f 23 03 d5   hint    #25

quoted

quoted

I'd like to understand this issue before we try to fix it, but there
is at least one improvement we can make: pahole should check ftrace
addresses only for static functions, not the global ones (global ones
should be always attachable, unless they are special, e.g., notrace
and stuff). We can easily check that by looking at the corresponding
symbol. But I'd like to verify that vfs_truncate is ftrace-attachable

I'm still trying to build the kernel.. however ;-)

I finally reproduced.. however arm's not using mcount_loc
but some other special section.. so it's new mess for me

so ftrace data actualy has vfs_truncate address but with extra 4 bytes:

        ffff80001031f434

real vfs_truncate address:

        ffff80001031f430 g     F .text  0000000000000168 vfs_truncate

vfs_truncate disasm:

        ffff80001031f430 <vfs_truncate>:
        ffff80001031f430: 5f 24 03 d5   hint    #34
        ffff80001031f434: 1f 20 03 d5   nop
        ffff80001031f438: 1f 20 03 d5   nop
        ffff80001031f43c: 3f 23 03 d5   hint    #25

thats why we don't match it in pahole.. I checked few other functions
and some have the same problem and some match the function boundary

those that match don't have that first hint instrucion, like:

        ffff800010321e40 <do_faccessat>:
        ffff800010321e40: 1f 20 03 d5   nop
        ffff800010321e44: 1f 20 03 d5   nop
        ffff800010321e48: 3f 23 03 d5   hint    #25

any hints about hint instructions? ;-)

aarch64 makes *some* newer instructions reuse the "hint" ie "nop"
encoding space to make software backwards compatible on older hardware
that doesn't support such instructions.  Is this BTI, perhaps? (The
function is perhaps the destination of an indirect call?)

It seems like it. The issue is not reproducible when
CONFIG_ARM64_BTI_KERNEL is not set.

Cheers,
Nathan

On 10 Feb 2021, at 01:02, Nathan Chancellor [off-list ref] wrote:

On Tue, Feb 09, 2021 at 12:09:31PM -0800, Nick Desaulniers wrote:

quoted

On Tue, Feb 9, 2021 at 11:06 AM Jiri Olsa [off-list ref] wrote:

quoted

On Tue, Feb 09, 2021 at 05:13:42PM +0100, Jiri Olsa wrote:

quoted

On Tue, Feb 09, 2021 at 04:09:36PM +0100, Jiri Olsa wrote:

SNIP

quoted

quoted

quoted

quoted

quoted

               DW_AT_prototyped        (true)
               DW_AT_type      (0x01cfdfe4 "long int")
               DW_AT_external  (true)

Ok, the problem appears to be not in DWARF, but in mcount_loc data.
vfs_truncate's address is not recorded as ftrace-attachable, and thus
pahole ignores it. I don't know why this happens and it's quite
strange, given vfs_truncate is just a normal global function.

right, I can't see it in mcount adresses.. but it begins with instructions
that appears to be nops, which would suggest it's traceable

 ffff80001031f430 <vfs_truncate>:
 ffff80001031f430: 5f 24 03 d5   hint    #34
 ffff80001031f434: 1f 20 03 d5   nop
 ffff80001031f438: 1f 20 03 d5   nop
 ffff80001031f43c: 3f 23 03 d5   hint    #25

quoted

quoted

I'd like to understand this issue before we try to fix it, but there
is at least one improvement we can make: pahole should check ftrace
addresses only for static functions, not the global ones (global ones
should be always attachable, unless they are special, e.g., notrace
and stuff). We can easily check that by looking at the corresponding
symbol. But I'd like to verify that vfs_truncate is ftrace-attachable

I'm still trying to build the kernel.. however ;-)

I finally reproduced.. however arm's not using mcount_loc
but some other special section.. so it's new mess for me

so ftrace data actualy has vfs_truncate address but with extra 4 bytes:

       ffff80001031f434

real vfs_truncate address:

       ffff80001031f430 g     F .text  0000000000000168 vfs_truncate

vfs_truncate disasm:

       ffff80001031f430 <vfs_truncate>:
       ffff80001031f430: 5f 24 03 d5   hint    #34
       ffff80001031f434: 1f 20 03 d5   nop
       ffff80001031f438: 1f 20 03 d5   nop
       ffff80001031f43c: 3f 23 03 d5   hint    #25

thats why we don't match it in pahole.. I checked few other functions
and some have the same problem and some match the function boundary

those that match don't have that first hint instrucion, like:

       ffff800010321e40 <do_faccessat>:
       ffff800010321e40: 1f 20 03 d5   nop
       ffff800010321e44: 1f 20 03 d5   nop
       ffff800010321e48: 3f 23 03 d5   hint    #25

any hints about hint instructions? ;-)

aarch64 makes *some* newer instructions reuse the "hint" ie "nop"
encoding space to make software backwards compatible on older hardware
that doesn't support such instructions.  Is this BTI, perhaps? (The
function is perhaps the destination of an indirect call?)

It seems like it. The issue is not reproducible when
CONFIG_ARM64_BTI_KERNEL is not set.

llvm-objdump --mattr=pa —mattr=bti -d … will print new mnemonic for the hint space instructions.

It is intentional to put a landing pad (BTI) at the very beginning for the patchable functions.
       ffff80001031f430 <vfs_truncate>:
       ffff80001031f430: 5f 24 03 d5   hint    #34 // BTI C <— landing pad for indirect calls.
       ffff80001031f434: 1f 20 03 d5   nop   // <— the to be patched area.
       ffff80001031f438: 1f 20 03 d5   nop
       ffff80001031f43c: 3f 23 03 d5   hint    #25 // paciasp <— protecting the link register..
The ftrace data(ffff80001031f434) seems correct because it should point to the “nops".

HTH

Cheers,
Daniel

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

quoted

quoted

vfs_truncate disasm:

        ffff80001031f430 <vfs_truncate>:
        ffff80001031f430: 5f 24 03 d5   hint    #34
        ffff80001031f434: 1f 20 03 d5   nop
        ffff80001031f438: 1f 20 03 d5   nop
        ffff80001031f43c: 3f 23 03 d5   hint    #25

thats why we don't match it in pahole.. I checked few other functions
and some have the same problem and some match the function boundary

those that match don't have that first hint instrucion, like:

        ffff800010321e40 <do_faccessat>:
        ffff800010321e40: 1f 20 03 d5   nop
        ffff800010321e44: 1f 20 03 d5   nop
        ffff800010321e48: 3f 23 03 d5   hint    #25

any hints about hint instructions? ;-)

aarch64 makes *some* newer instructions reuse the "hint" ie "nop"
encoding space to make software backwards compatible on older hardware
that doesn't support such instructions.  Is this BTI, perhaps? (The
function is perhaps the destination of an indirect call?)

It seems like it. The issue is not reproducible when
CONFIG_ARM64_BTI_KERNEL is not set.

Is the compiler/linker doing something 'crazy'?

If a function address is taken then the BTI instruction is placed
before the function body and the symbol moved.
But non-indirect calls still jump to the original start of the function.
(In this case the first nop.)

This saves the execution time of the BTI instruction for non-indirect
calls.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

On Wed, Feb 10, 2021 at 11:34:25AM +0000, David Laight wrote:

quoted

quoted

quoted

vfs_truncate disasm:

        ffff80001031f430 <vfs_truncate>:
        ffff80001031f430: 5f 24 03 d5   hint    #34
        ffff80001031f434: 1f 20 03 d5   nop
        ffff80001031f438: 1f 20 03 d5   nop
        ffff80001031f43c: 3f 23 03 d5   hint    #25

thats why we don't match it in pahole.. I checked few other functions
and some have the same problem and some match the function boundary

those that match don't have that first hint instrucion, like:

        ffff800010321e40 <do_faccessat>:
        ffff800010321e40: 1f 20 03 d5   nop
        ffff800010321e44: 1f 20 03 d5   nop
        ffff800010321e48: 3f 23 03 d5   hint    #25

any hints about hint instructions? ;-)

aarch64 makes *some* newer instructions reuse the "hint" ie "nop"
encoding space to make software backwards compatible on older hardware
that doesn't support such instructions.  Is this BTI, perhaps? (The
function is perhaps the destination of an indirect call?)

It seems like it. The issue is not reproducible when
CONFIG_ARM64_BTI_KERNEL is not set.

Is the compiler/linker doing something 'crazy'?

I need to check the gcc build, where pahole in my test sees
zero ftrace addresses, while booted kernel shows ftrace working

If a function address is taken then the BTI instruction is placed
before the function body and the symbol moved.
But non-indirect calls still jump to the original start of the function.
(In this case the first nop.)

for clang build, it looks like pahole needs fix not to assume that
ftrace address match with function start, I'll send it later today

thanks,
jirka

This saves the execution time of the BTI instruction for non-indirect
calls.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

On Tue, Feb 09, 2021 at 02:00:29PM -0800, Andrii Nakryiko wrote:

SNIP

quoted

quoted

quoted

I'm still trying to build the kernel.. however ;-)

patch below adds the ftrace check only for static functions
and lets the externa go through.. but as you said, in this
case we'll need to figure out the 'notrace' and other checks
ftrace is doing

jirka


---

diff --git a/btf_encoder.c b/btf_encoder.c
index b124ec20a689..4d147406cfa5 100644
--- a/btf_encoder.c
+++ b/btf_encoder.c

@@ -734,7 +734,7 @@ int cu__encode_btf(struct cu *cu, int verbose, bool force,
                        continue;
                if (!has_arg_names(cu, &fn->proto))
                        continue;
-               if (functions_cnt) {
+               if (!fn->external && functions_cnt) {

I wouldn't trust DWARF, honestly. Wouldn't checking GLOBAL vs LOCAL
FUNC ELF symbol be more reliable?

that'd mean extra bsearch on each processed function,
on the ther hand, we'are already slow ;-) I'll check
how big the slowdown would be

We currently record addresses and do binary search. Now we need to
record address + size and still do binary search with a slightly
different semantics (find closest entry >= addr). Then just check that
it overlaps, taking into account the length of the function code. It
shouldn't result in a noticeable slowdown. Might be actually faster,
because we might avoid callback function call costs.

I'm still not sure how to handle the external check for function via elf,
but below is change for checking that ftrace addrs are within elf functions

seems to work in my tests, I'll run some more tests and send full patch

jirka


---

diff --git a/btf_encoder.c b/btf_encoder.c
index b124ec20a689..548a12847f99 100644
--- a/btf_encoder.c
+++ b/btf_encoder.c

@@ -36,6 +36,7 @@ struct funcs_layout {
 struct elf_function {
 	const char	*name;
 	unsigned long	 addr;
+	unsigned long	 end;
 	unsigned long	 sh_addr;
 	bool		 generated;
 };

@@ -44,7 +45,7 @@ static struct elf_function *functions;
 static int functions_alloc;
 static int functions_cnt;
 
-static int functions_cmp(const void *_a, const void *_b)
+static int functions_cmp_name(const void *_a, const void *_b)
 {
 	const struct elf_function *a = _a;
 	const struct elf_function *b = _b;

@@ -52,6 +53,16 @@ static int functions_cmp(const void *_a, const void *_b)
 	return strcmp(a->name, b->name);
 }
 
+static int functions_cmp_addr(const void *_a, const void *_b)
+{
+	const struct elf_function *a = _a;
+	const struct elf_function *b = _b;
+
+	if (a->addr == b->addr)
+		return 0;
+	return a->addr < b->addr ? -1 : 1;
+}
+
 static void delete_functions(void)
 {
 	free(functions);

@@ -98,6 +109,7 @@ static int collect_function(struct btf_elf *btfe, GElf_Sym *sym,
 
 	functions[functions_cnt].name = name;
 	functions[functions_cnt].addr = elf_sym__value(sym);
+	functions[functions_cnt].end = (__u64) -1;
 	functions[functions_cnt].sh_addr = sh.sh_addr;
 	functions[functions_cnt].generated = false;
 	functions_cnt++;

@@ -236,9 +248,25 @@ get_kmod_addrs(struct btf_elf *btfe, __u64 **paddrs, __u64 *pcount)
 	return 0;
 }
 
+static bool is_addr_in_func(__u64 addr, struct elf_function *func, bool kmod)
+{
+	/*
+	 * For vmlinux image both addrs[x] and functions[x]::addr
+	 * values are final address and are comparable.
+	 *
+	 * For kernel module addrs[x] is final address, but
+	 * functions[x]::addr is relative address within section
+	 * and needs to be relocated by adding sh_addr.
+	 */
+	__u64 start = kmod ? func->addr + func->sh_addr : func->addr;
+	__u64 end = kmod ? func->end+ func->sh_addr : func->end;
+
+	return start <= addr && addr < end;
+}
+
 static int setup_functions(struct btf_elf *btfe, struct funcs_layout *fl)
 {
-	__u64 *addrs, count, i;
+	__u64 *addrs, count, i_func, i_addr;
 	int functions_valid = 0;
 	bool kmod = false;
 

@@ -266,43 +294,62 @@ static int setup_functions(struct btf_elf *btfe, struct funcs_layout *fl)
 		return 0;
 	}
 
-	qsort(addrs, count, sizeof(addrs[0]), addrs_cmp);
-	qsort(functions, functions_cnt, sizeof(functions[0]), functions_cmp);
-
 	/*
-	 * Let's got through all collected functions and filter
-	 * out those that are not in ftrace.
+	 * Sort both functions and addrs so we can iterate
+	 * both of them simultaneously and found matching
+	 * func/addr pairs.
 	 */
-	for (i = 0; i < functions_cnt; i++) {
-		struct elf_function *func = &functions[i];
-		/*
-		 * For vmlinux image both addrs[x] and functions[x]::addr
-		 * values are final address and are comparable.
-		 *
-		 * For kernel module addrs[x] is final address, but
-		 * functions[x]::addr is relative address within section
-		 * and needs to be relocated by adding sh_addr.
-		 */
-		__u64 addr = kmod ? func->addr + func->sh_addr : func->addr;
+	qsort(addrs, count, sizeof(addrs[0]), addrs_cmp);
+	qsort(functions, functions_cnt, sizeof(functions[0]), functions_cmp_addr);
+
+	for (i_func = 0, i_addr = 0; i_func < functions_cnt; i_func++) {
+		struct elf_function *func = &functions[i_func];
+
+		if (i_func + 1 < functions_cnt)
+			func->end = functions[i_func + 1].addr;
+
+		for (; i_addr < count; i_addr++) {
+			__u64 addr = addrs[i_addr];
+
+			/* Functions are  ahead, catch up with addrs. */
+			if (addr < func->addr)
+				continue;
+
+			/* Addr is within function - mark function as valid. */
+			if (is_addr_in_func(addr, func, kmod)) {
+				/*
+				 * We iterate over sorted array, so we can easily skip
+				 * not valid item and move following valid field into
+				 * its place, and still keep the 'new' array sorted.
+				 */
+				if (i_func != functions_valid)
+					functions[functions_valid] = functions[i_func];
+				functions_valid++;
+				i_addr++;
+			}
 
-		/* Make sure function is within ftrace addresses. */
-		if (bsearch(&addr, addrs, count, sizeof(addrs[0]), addrs_cmp)) {
 			/*
-			 * We iterate over sorted array, so we can easily skip
-			 * not valid item and move following valid field into
-			 * its place, and still keep the 'new' array sorted.
+			 * Addrs are ahead, catch up with functions, or we just
+			 * found valid function and want to move to another.
 			 */
-			if (i != functions_valid)
-				functions[functions_valid] = functions[i];
-			functions_valid++;
+			break;
 		}
 	}
 
+	if (btf_elf__verbose) {
+		printf("Found %d functions out of %d symbols and %llu ftrace addresses.\n",
+			functions_valid, functions_cnt, count);
+	}
+
 	functions_cnt = functions_valid;
 	free(addrs);
 
-	if (btf_elf__verbose)
-		printf("Found %d functions!\n", functions_cnt);
+	/*
+	 * And finaly sort 'valid' functions by name,
+	 * so find_function can be used.
+	 */
+	qsort(functions, functions_cnt, sizeof(functions[0]), functions_cmp_name);
+
 	return 0;
 }
 

@@ -312,7 +359,7 @@ static struct elf_function *find_function(const struct btf_elf *btfe,
 	struct elf_function key = { .name = name };
 
 	return bsearch(&key, functions, functions_cnt, sizeof(functions[0]),
-		       functions_cmp);
+		       functions_cmp_name);
 }
 
 static bool btf_name_char_ok(char c, bool first)

On Wed, Feb 10, 2021 at 02:26:43PM +0100, Jiri Olsa wrote:

On Tue, Feb 09, 2021 at 02:00:29PM -0800, Andrii Nakryiko wrote:

SNIP

quoted

quoted

quoted

quoted

I'm still trying to build the kernel.. however ;-)

patch below adds the ftrace check only for static functions
and lets the externa go through.. but as you said, in this
case we'll need to figure out the 'notrace' and other checks
ftrace is doing

jirka


---

diff --git a/btf_encoder.c b/btf_encoder.c
index b124ec20a689..4d147406cfa5 100644
--- a/btf_encoder.c
+++ b/btf_encoder.c

@@ -734,7 +734,7 @@ int cu__encode_btf(struct cu *cu, int verbose, bool force,
                        continue;
                if (!has_arg_names(cu, &fn->proto))
                        continue;
-               if (functions_cnt) {
+               if (!fn->external && functions_cnt) {

I wouldn't trust DWARF, honestly. Wouldn't checking GLOBAL vs LOCAL
FUNC ELF symbol be more reliable?

that'd mean extra bsearch on each processed function,
on the ther hand, we'are already slow ;-) I'll check
how big the slowdown would be

We currently record addresses and do binary search. Now we need to
record address + size and still do binary search with a slightly
different semantics (find closest entry >= addr). Then just check that
it overlaps, taking into account the length of the function code. It
shouldn't result in a noticeable slowdown. Might be actually faster,
because we might avoid callback function call costs.

I'm still not sure how to handle the external check for function via elf,
but below is change for checking that ftrace addrs are within elf functions

seems to work in my tests, I'll run some more tests and send full patch

jirka

This passes the build test with the initial problematic configuration
file and the reduced one that I came up with. That is about the extent
to which I can verify that it works though :)

On Wed, Feb 10, 2021 at 7:20 PM Andrii Nakryiko
[off-list ref] wrote:

On Wed, Feb 10, 2021 at 5:26 AM Jiri Olsa [off-list ref] wrote:

quoted

On Tue, Feb 09, 2021 at 02:00:29PM -0800, Andrii Nakryiko wrote:

SNIP

quoted

quoted

quoted

quoted

I'm still trying to build the kernel.. however ;-)

patch below adds the ftrace check only for static functions
and lets the externa go through.. but as you said, in this
case we'll need to figure out the 'notrace' and other checks
ftrace is doing

jirka


---

diff --git a/btf_encoder.c b/btf_encoder.c
index b124ec20a689..4d147406cfa5 100644
--- a/btf_encoder.c
+++ b/btf_encoder.c

@@ -734,7 +734,7 @@ int cu__encode_btf(struct cu *cu, int verbose, bool force,
                        continue;
                if (!has_arg_names(cu, &fn->proto))
                        continue;
-               if (functions_cnt) {
+               if (!fn->external && functions_cnt) {

I wouldn't trust DWARF, honestly. Wouldn't checking GLOBAL vs LOCAL
FUNC ELF symbol be more reliable?

that'd mean extra bsearch on each processed function,
on the ther hand, we'are already slow ;-) I'll check
how big the slowdown would be

We currently record addresses and do binary search. Now we need to
record address + size and still do binary search with a slightly
different semantics (find closest entry >= addr). Then just check that
it overlaps, taking into account the length of the function code. It
shouldn't result in a noticeable slowdown. Might be actually faster,
because we might avoid callback function call costs.

I'm still not sure how to handle the external check for function via elf,

I might be missing something, but don't all functions have
corresponding ELF symbols? And then symbol can have LOCAL or GLOBAL
type. LOCALs are supposed to be not visible outside respective CUs (so
correspond to static functions), while GLOBALs are extern-able funcs.
So if func's symbol is GLOBAL, it should be ok to assume it's
attachable (not inlined, at least).

quoted

but below is change for checking that ftrace addrs are within elf functions

seems to work in my tests, I'll run some more tests and send full patch

It seems unnecessarily convoluted. I was thinking about something like
this (the diff will totally be screwed up by gmail, and I haven't even
compiled it):

Now, I know why vfs_truncate is so problematic.
Let's split it: "vfs + trunc + ate".
Eaten by Gmail :-).

- Sedat -

On Wed, Feb 10, 2021 at 5:26 AM Jiri Olsa [off-list ref] wrote:

On Tue, Feb 09, 2021 at 02:00:29PM -0800, Andrii Nakryiko wrote:

SNIP

quoted

quoted

quoted

quoted

I'm still trying to build the kernel.. however ;-)

patch below adds the ftrace check only for static functions
and lets the externa go through.. but as you said, in this
case we'll need to figure out the 'notrace' and other checks
ftrace is doing

jirka


---

diff --git a/btf_encoder.c b/btf_encoder.c
index b124ec20a689..4d147406cfa5 100644
--- a/btf_encoder.c
+++ b/btf_encoder.c

@@ -734,7 +734,7 @@ int cu__encode_btf(struct cu *cu, int verbose, bool force,
                        continue;
                if (!has_arg_names(cu, &fn->proto))
                        continue;
-               if (functions_cnt) {
+               if (!fn->external && functions_cnt) {

I wouldn't trust DWARF, honestly. Wouldn't checking GLOBAL vs LOCAL
FUNC ELF symbol be more reliable?

that'd mean extra bsearch on each processed function,
on the ther hand, we'are already slow ;-) I'll check
how big the slowdown would be

We currently record addresses and do binary search. Now we need to
record address + size and still do binary search with a slightly
different semantics (find closest entry >= addr). Then just check that
it overlaps, taking into account the length of the function code. It
shouldn't result in a noticeable slowdown. Might be actually faster,
because we might avoid callback function call costs.

I'm still not sure how to handle the external check for function via elf,

I might be missing something, but don't all functions have
corresponding ELF symbols? And then symbol can have LOCAL or GLOBAL
type. LOCALs are supposed to be not visible outside respective CUs (so
correspond to static functions), while GLOBALs are extern-able funcs.
So if func's symbol is GLOBAL, it should be ok to assume it's
attachable (not inlined, at least).

but below is change for checking that ftrace addrs are within elf functions

seems to work in my tests, I'll run some more tests and send full patch

It seems unnecessarily convoluted. I was thinking about something like
this (the diff will totally be screwed up by gmail, and I haven't even
compiled it):

diff --git a/btf_encoder.c b/btf_encoder.c
index b124ec20a689..8162b238bd43 100644
--- a/btf_encoder.c
+++ b/btf_encoder.c

@@ -236,6 +236,23 @@ get_kmod_addrs(struct btf_elf *btfe, __u64

**paddrs, __u64 *pcount)
        return 0;
 }

+struct func_seg { __u64 start; __u64 end; };
+
+static int func_exists(struct func_seg *segs, size_t len, __u64 addr)
+{
+       size_t l = 0, r = len - 1, m;
+
+       while (l < r) {
+               m = l + (r - l + 1) / 2;
+               if (segs[m].start <= addr)
+                       l = m;
+               else
+                       r = m - 1;
+       }
+
+       return segs[l].start <= addr && addr < segs[l].end;
+}
+
 static int setup_functions(struct btf_elf *btfe, struct funcs_layout *fl)
 {
        __u64 *addrs, count, i;

@@ -286,7 +303,7 @@ static int setup_functions(struct btf_elf *btfe,

struct funcs_layout *fl)
                __u64 addr = kmod ? func->addr + func->sh_addr : func->addr;

                /* Make sure function is within ftrace addresses. */
-               if (bsearch(&addr, addrs, count, sizeof(addrs[0]), addrs_cmp)) {
+               if (func_exists(addrs, count, addr))
                        /*
                         * We iterate over sorted array, so we can easily skip
                         * not valid item and move following valid field into


So the idea is to use address segments and check whether there is a
segment that overlaps with a given address by first binary searching
for a segment with the largest starting address that is <= addr. And
then just confirming that segment does overlap with the requested
address.

WDYT?