From: Stanislav Fomichev <sdf@fomichev.me>
To: Ivan Vecera <ivecera@redhat.com>
Cc: netdev@vger.kernel.org, Shuah Khan <shuah@kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Martin KaFai Lau <kafai@fb.com>, Song Liu <songliubraving@fb.com>,
Yonghong Song <yhs@fb.com>,
"open list:KERNEL SELFTEST FRAMEWORK"
<linux-kselftest@vger.kernel.org>,
"open list:BPF (Safe dynamic programs and tools)"
<bpf@vger.kernel.org>, open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH net-next] selftests: bpf: modify urandom_read and link it non-statically
Date: Fri, 15 Mar 2019 13:56:52 -0700 [thread overview]
Message-ID: <20190315205652.GD5481@mini-arch.hsd1.ca.comcast.net> (raw)
In-Reply-To: <2dcdc11c-4d04-4b0e-ddb7-04d969d04651@redhat.com>
On 03/15, Ivan Vecera wrote:
> On 15. 03. 19 21:08, Stanislav Fomichev wrote:
> > On 03/15, Ivan Vecera wrote:
> > > After some experiences I found that urandom_read does not need to be
> > > linked statically. When the 'read' syscall call is moved to separate
> > > non-inlined function then bpf_get_stackid() is able to find
> > > the executable in stack trace and extract its build_id from it.
> > But why? Do you have some problems with it being linked statically?
> >
> Dependency... you don't need to install static glibc to compile the bpf
> samples. Shared libc is available everytime.
Oh, the distros that do -devel _and_ -static packages :-)
So your patch essentially adds a call, that leaves a trace on the stack
with our build-id. I guess that works as well.
>
> Ivan
WARNING: multiple messages have this Message-ID (diff)
From: sdf at fomichev.me (Stanislav Fomichev)
Subject: [PATCH net-next] selftests: bpf: modify urandom_read and link it non-statically
Date: Fri, 15 Mar 2019 13:56:52 -0700 [thread overview]
Message-ID: <20190315205652.GD5481@mini-arch.hsd1.ca.comcast.net> (raw)
In-Reply-To: <2dcdc11c-4d04-4b0e-ddb7-04d969d04651@redhat.com>
On 03/15, Ivan Vecera wrote:
> On 15. 03. 19 21:08, Stanislav Fomichev wrote:
> > On 03/15, Ivan Vecera wrote:
> > > After some experiences I found that urandom_read does not need to be
> > > linked statically. When the 'read' syscall call is moved to separate
> > > non-inlined function then bpf_get_stackid() is able to find
> > > the executable in stack trace and extract its build_id from it.
> > But why? Do you have some problems with it being linked statically?
> >
> Dependency... you don't need to install static glibc to compile the bpf
> samples. Shared libc is available everytime.
Oh, the distros that do -devel _and_ -static packages :-)
So your patch essentially adds a call, that leaves a trace on the stack
with our build-id. I guess that works as well.
>
> Ivan
WARNING: multiple messages have this Message-ID (diff)
From: sdf@fomichev.me (Stanislav Fomichev)
Subject: [PATCH net-next] selftests: bpf: modify urandom_read and link it non-statically
Date: Fri, 15 Mar 2019 13:56:52 -0700 [thread overview]
Message-ID: <20190315205652.GD5481@mini-arch.hsd1.ca.comcast.net> (raw)
Message-ID: <20190315205652.IArJsq3eHk5diRItdE7n7_eOiJHPJTukCecRk7h9yDM@z> (raw)
In-Reply-To: <2dcdc11c-4d04-4b0e-ddb7-04d969d04651@redhat.com>
On 03/15, Ivan Vecera wrote:
> On 15. 03. 19 21:08, Stanislav Fomichev wrote:
> > On 03/15, Ivan Vecera wrote:
> > > After some experiences I found that urandom_read does not need to be
> > > linked statically. When the 'read' syscall call is moved to separate
> > > non-inlined function then bpf_get_stackid() is able to find
> > > the executable in stack trace and extract its build_id from it.
> > But why? Do you have some problems with it being linked statically?
> >
> Dependency... you don't need to install static glibc to compile the bpf
> samples. Shared libc is available everytime.
Oh, the distros that do -devel _and_ -static packages :-)
So your patch essentially adds a call, that leaves a trace on the stack
with our build-id. I guess that works as well.
>
> Ivan
next prev parent reply other threads:[~2019-03-15 20:57 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-15 20:04 [PATCH net-next] selftests: bpf: modify urandom_read and link it non-statically Ivan Vecera
2019-03-15 20:04 ` Ivan Vecera
2019-03-15 20:04 ` ivecera
2019-03-15 20:08 ` Stanislav Fomichev
2019-03-15 20:08 ` Stanislav Fomichev
2019-03-15 20:08 ` sdf
2019-03-15 20:14 ` Ivan Vecera
2019-03-15 20:14 ` Ivan Vecera
2019-03-15 20:14 ` ivecera
2019-03-15 20:56 ` Stanislav Fomichev [this message]
2019-03-15 20:56 ` Stanislav Fomichev
2019-03-15 20:56 ` sdf
2019-03-15 21:50 ` Ivan Vecera
2019-03-15 21:50 ` Ivan Vecera
2019-03-15 21:50 ` ivecera
2019-03-15 22:05 ` Stanislav Fomichev
2019-03-15 22:05 ` Stanislav Fomichev
2019-03-15 22:05 ` sdf
2019-03-22 2:39 ` Alexei Starovoitov
2019-03-22 2:39 ` Alexei Starovoitov
2019-03-22 2:39 ` alexei.starovoitov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190315205652.GD5481@mini-arch.hsd1.ca.comcast.net \
--to=sdf@fomichev.me \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=ivecera@redhat.com \
--cc=kafai@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=shuah@kernel.org \
--cc=songliubraving@fb.com \
--cc=yhs@fb.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.