netdev - Re: FAILED unresolved symbol vfs_truncate on arm64 with LLVM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 11 Feb 2021 17:07:20 +0100
From:   Jiri Olsa <jolsa@...hat.com>
To:     Sedat Dilek <sedat.dilek@...il.com>
Cc:     Andrii Nakryiko <andrii.nakryiko@...il.com>,
        Nathan Chancellor <nathan@...nel.org>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Andrii Nakryiko <andrii@...nel.org>,
        Martin KaFai Lau <kafai@...com>,
        Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
        John Fastabend <john.fastabend@...il.com>,
        KP Singh <kpsingh@...nel.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>,
        clang-built-linux <clang-built-linux@...glegroups.com>,
        Veronika Kabatova <vkabatov@...hat.com>,
        Jiri Olsa <jolsa@...nel.org>
Subject: Re: FAILED unresolved symbol vfs_truncate on arm64 with LLVM

On Thu, Feb 11, 2021 at 04:43:48PM +0100, Sedat Dilek wrote:

SNIP

> > > filled with elf functions start/end values, right?
> > >
> > > >                         /*
> > > >                          * 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?
> >
> > heya,
> > with your approach I ended up with change below, it gives me same
> > results as with the previous change
> >
> > I think I'll separate the kmod bool address computation later on,
> > but I did not want to confuse this change for now
> >
> 
> I have applied your diff on top of pahole-v1.20 with Yonghong Son's
> "btf_encoder: sanitize non-regular int base type" applied.
> This is on x86-64 with LLVM-12, so I am not directly affected.
> If it is out of interest I can offer vmlinux (or .*btf* files) w/ and
> w/o your diff.

if you could run your tests/workloads and check the new change does not
break your stuff, that'd be great

we need soem testsuite ;-) I have some stupid test script which runs over
few vmlinux binaries and check the diff in BTF data.. problem is that these
vmlinux binaries are ~300M each, so it's not great for sharing

also I was checking if we could use BPF_BTF_LOAD syscall and load BTF in
kernel and back at the end of pahole processing to check it's valid ;-)

thanks,
jirka