All of lore.kernel.org
 help / color / mirror / Atom feed
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:08:47 -0700	[thread overview]
Message-ID: <20190315200847.GC5481@mini-arch.hsd1.ca.comcast.net> (raw)
In-Reply-To: <20190315200414.32346-1-ivecera@redhat.com>

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?

> 
> Signed-off-by: Ivan Vecera <ivecera@redhat.com>
> ---
>  tools/testing/selftests/bpf/Makefile       |  2 +-
>  tools/testing/selftests/bpf/urandom_read.c | 15 +++++++++++----
>  2 files changed, 12 insertions(+), 5 deletions(-)
> 
> diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
> index 2aed37ea61a4..c33900a8fec0 100644
> --- a/tools/testing/selftests/bpf/Makefile
> +++ b/tools/testing/selftests/bpf/Makefile
> @@ -69,7 +69,7 @@ TEST_CUSTOM_PROGS = $(OUTPUT)/urandom_read
>  all: $(TEST_CUSTOM_PROGS)
>  
>  $(OUTPUT)/urandom_read: $(OUTPUT)/%: %.c
> -	$(CC) -o $@ -static $< -Wl,--build-id
> +	$(CC) -o $@ $< -Wl,--build-id
>  
>  BPFOBJ := $(OUTPUT)/libbpf.a
>  
> diff --git a/tools/testing/selftests/bpf/urandom_read.c b/tools/testing/selftests/bpf/urandom_read.c
> index 9de8b7cb4e6d..db781052758d 100644
> --- a/tools/testing/selftests/bpf/urandom_read.c
> +++ b/tools/testing/selftests/bpf/urandom_read.c
> @@ -7,11 +7,19 @@
>  
>  #define BUF_SIZE 256
>  
> +static __attribute__((noinline))
> +void urandom_read(int fd, int count)
> +{
> +       char buf[BUF_SIZE];
> +       int i;
> +
> +       for (i = 0; i < count; ++i)
> +               read(fd, buf, BUF_SIZE);
> +}
> +
>  int main(int argc, char *argv[])
>  {
>  	int fd = open("/dev/urandom", O_RDONLY);
> -	int i;
> -	char buf[BUF_SIZE];
>  	int count = 4;
>  
>  	if (fd < 0)
> @@ -20,8 +28,7 @@ int main(int argc, char *argv[])
>  	if (argc == 2)
>  		count = atoi(argv[1]);
>  
> -	for (i = 0; i < count; ++i)
> -		read(fd, buf, BUF_SIZE);
> +	urandom_read(fd, count);
>  
>  	close(fd);
>  	return 0;
> -- 
> 2.19.2
> 

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:08:47 -0700	[thread overview]
Message-ID: <20190315200847.GC5481@mini-arch.hsd1.ca.comcast.net> (raw)
In-Reply-To: <20190315200414.32346-1-ivecera@redhat.com>

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?

> 
> Signed-off-by: Ivan Vecera <ivecera at redhat.com>
> ---
>  tools/testing/selftests/bpf/Makefile       |  2 +-
>  tools/testing/selftests/bpf/urandom_read.c | 15 +++++++++++----
>  2 files changed, 12 insertions(+), 5 deletions(-)
> 
> diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
> index 2aed37ea61a4..c33900a8fec0 100644
> --- a/tools/testing/selftests/bpf/Makefile
> +++ b/tools/testing/selftests/bpf/Makefile
> @@ -69,7 +69,7 @@ TEST_CUSTOM_PROGS = $(OUTPUT)/urandom_read
>  all: $(TEST_CUSTOM_PROGS)
>  
>  $(OUTPUT)/urandom_read: $(OUTPUT)/%: %.c
> -	$(CC) -o $@ -static $< -Wl,--build-id
> +	$(CC) -o $@ $< -Wl,--build-id
>  
>  BPFOBJ := $(OUTPUT)/libbpf.a
>  
> diff --git a/tools/testing/selftests/bpf/urandom_read.c b/tools/testing/selftests/bpf/urandom_read.c
> index 9de8b7cb4e6d..db781052758d 100644
> --- a/tools/testing/selftests/bpf/urandom_read.c
> +++ b/tools/testing/selftests/bpf/urandom_read.c
> @@ -7,11 +7,19 @@
>  
>  #define BUF_SIZE 256
>  
> +static __attribute__((noinline))
> +void urandom_read(int fd, int count)
> +{
> +       char buf[BUF_SIZE];
> +       int i;
> +
> +       for (i = 0; i < count; ++i)
> +               read(fd, buf, BUF_SIZE);
> +}
> +
>  int main(int argc, char *argv[])
>  {
>  	int fd = open("/dev/urandom", O_RDONLY);
> -	int i;
> -	char buf[BUF_SIZE];
>  	int count = 4;
>  
>  	if (fd < 0)
> @@ -20,8 +28,7 @@ int main(int argc, char *argv[])
>  	if (argc == 2)
>  		count = atoi(argv[1]);
>  
> -	for (i = 0; i < count; ++i)
> -		read(fd, buf, BUF_SIZE);
> +	urandom_read(fd, count);
>  
>  	close(fd);
>  	return 0;
> -- 
> 2.19.2
> 

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:08:47 -0700	[thread overview]
Message-ID: <20190315200847.GC5481@mini-arch.hsd1.ca.comcast.net> (raw)
Message-ID: <20190315200847.9yBXnYB96-FWn4MjVUTdBfjXtJ1Ip0c_DtHXoDmtEfM@z> (raw)
In-Reply-To: <20190315200414.32346-1-ivecera@redhat.com>

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?

> 
> Signed-off-by: Ivan Vecera <ivecera at redhat.com>
> ---
>  tools/testing/selftests/bpf/Makefile       |  2 +-
>  tools/testing/selftests/bpf/urandom_read.c | 15 +++++++++++----
>  2 files changed, 12 insertions(+), 5 deletions(-)
> 
> diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
> index 2aed37ea61a4..c33900a8fec0 100644
> --- a/tools/testing/selftests/bpf/Makefile
> +++ b/tools/testing/selftests/bpf/Makefile
> @@ -69,7 +69,7 @@ TEST_CUSTOM_PROGS = $(OUTPUT)/urandom_read
>  all: $(TEST_CUSTOM_PROGS)
>  
>  $(OUTPUT)/urandom_read: $(OUTPUT)/%: %.c
> -	$(CC) -o $@ -static $< -Wl,--build-id
> +	$(CC) -o $@ $< -Wl,--build-id
>  
>  BPFOBJ := $(OUTPUT)/libbpf.a
>  
> diff --git a/tools/testing/selftests/bpf/urandom_read.c b/tools/testing/selftests/bpf/urandom_read.c
> index 9de8b7cb4e6d..db781052758d 100644
> --- a/tools/testing/selftests/bpf/urandom_read.c
> +++ b/tools/testing/selftests/bpf/urandom_read.c
> @@ -7,11 +7,19 @@
>  
>  #define BUF_SIZE 256
>  
> +static __attribute__((noinline))
> +void urandom_read(int fd, int count)
> +{
> +       char buf[BUF_SIZE];
> +       int i;
> +
> +       for (i = 0; i < count; ++i)
> +               read(fd, buf, BUF_SIZE);
> +}
> +
>  int main(int argc, char *argv[])
>  {
>  	int fd = open("/dev/urandom", O_RDONLY);
> -	int i;
> -	char buf[BUF_SIZE];
>  	int count = 4;
>  
>  	if (fd < 0)
> @@ -20,8 +28,7 @@ int main(int argc, char *argv[])
>  	if (argc == 2)
>  		count = atoi(argv[1]);
>  
> -	for (i = 0; i < count; ++i)
> -		read(fd, buf, BUF_SIZE);
> +	urandom_read(fd, count);
>  
>  	close(fd);
>  	return 0;
> -- 
> 2.19.2
> 

  reply	other threads:[~2019-03-15 20:08 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 [this message]
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
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=20190315200847.GC5481@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.