On Mon, Jun 24, 2019 at 2:24 PM Stanislav Fomichev wrote:
>
> On 06/24, Andrii Nakryiko wrote:
> > On Sun, Jun 23, 2019 at 5:59 PM Rong Chen wrote:
> > >
> > > On 6/22/19 6:27 AM, Stanislav Fomichev wrote:
> > > > On 06/21, Andrii Nakryiko wrote:
> &g
y: Michal Rostecki
> ---
Acked-by: Andrii Nakryiko
> samples/bpf/ibumad_kern.c | 18 ++
> 1 file changed, 6 insertions(+), 12 deletions(-)
>
On Tue, Jun 25, 2019 at 7:12 AM Ivan Khoronzhuk
wrote:
>
> It fixes build error for 32bit coused by type mistmatch
typo: coused -> caused, mistmatch -> mismatch
> size_t/unsigned long.
>
> Signed-off-by: Ivan Khoronzhuk
> ---
>
> Based on net-next/master
libbpf changes should be based against
ctor map initialization")
With that:
Acked-by: Andrii Nakryiko
> tools/lib/bpf/libbpf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index 68f45a96769f..5186b7710430 100644
> --- a/tools/lib/bpf/libbp
On Mon, Jun 10, 2019 at 9:39 AM Ilya Maximets wrote:
>
> Device that bound to XDP socket will not have zero refcount until the
> userspace application will not close it. This leads to hang inside
> 'netdev_wait_allrefs()' if device unregistering requested:
>
> # ip link del p1
> < hang on recv
other warnings,
> which become more visible in comparison.
>
> Signed-off-by: Valdis Kletnieks
Thanks! Please include bpf-next in [PATCH] prefix in the future. I've
also CC'ed b...@vger.kernel.org list.
Acked-by: Andrii Nakryiko
>
> diff --git a/kernel/bpf/Makefile
On Tue, Jun 11, 2019 at 7:05 AM Gustavo A. R. Silva
wrote:
>
> In preparation to enabling -Wimplicit-fallthrough, this patch silences
> the following warning:
Your patch doesn't apply cleanly to neither bpf nor bpf-next tree.
Could you please rebase and re-submit? Please also include which tree
(
On Tue, Jun 11, 2019 at 10:41 AM Gustavo A. R. Silva
wrote:
>
>
>
> On 6/11/19 12:27 PM, Gustavo A. R. Silva wrote:
> >
> >
> > On 6/11/19 12:22 PM, Andrii Nakryiko wrote:
> >> On Tue, Jun 11, 2019 at 7:05 AM Gustavo A. R. Silva
> >> wrote:
&
On Thu, Jun 6, 2019 at 1:17 PM Matt Mullins wrote:
>
> BPF_PROG_TYPE_RAW_TRACEPOINTs can be executed nested on the same CPU, as
> they do not increment bpf_prog_active while executing.
>
> This enables three levels of nesting, to support
> - a kprobe or raw tp or perf event,
> - another one of
On Thu, Jun 27, 2019 at 8:50 AM Stanislav Fomichev wrote:
>
> On 06/27, kernel test robot wrote:
> > FYI, we noticed the following commit (built with gcc-7):
> >
> > commit: cd17d77705780e2270937fb3cbd2b985adab3edc ("bpf/tools: sync bpf.h")
> > https://git.kernel.org/cgit/linux/kernel/git/next/lin
On Thu, Jun 27, 2019 at 10:29 AM Stanislav Fomichev wrote:
>
> On 06/27, Stanislav Fomichev wrote:
> > On 06/27, kernel test robot wrote:
> > > FYI, we noticed the following commit (built with gcc-7):
> > >
> > > commit: cd17d77705780e2270937fb3cbd2b985adab3edc ("bpf/tools: sync bpf.h")
> > > http
On Thu, Jun 27, 2019 at 7:38 PM Stanislav Fomichev wrote:
>
> On 06/27, Andrii Nakryiko wrote:
> > On Thu, Jun 27, 2019 at 10:29 AM Stanislav Fomichev
> > wrote:
> > >
> > > On 06/27, Stanislav Fomichev wrote:
> > > > On 06/27, kernel test robo
On Fri, Jul 5, 2019 at 2:53 PM Daniel Borkmann wrote:
>
> On 07/05/2019 10:44 PM, Anton Protopopov wrote:
> > Add a new API bpf_object__reuse_maps() which can be used to replace all
> > maps in
> > an object by maps pinned to a directory provided in the path argument.
> > Namely,
> > each map M
#syz test: https://github.com/anakryiko/linux bpf-fix-precise-bpf_st
#syz test: https://github.com/anakryiko/linux bpf-fix-precise-bpf_st
On Mon, Jul 8, 2019 at 1:37 PM Anton Protopopov
wrote:
>
> пн, 8 июл. 2019 г. в 13:54, Andrii Nakryiko :
> >
> > On Fri, Jul 5, 2019 at 2:53 PM Daniel Borkmann wrote:
> > >
> > > On 07/05/2019 10:44 PM, Anton Protopopov wrote:
> > > > Add a new A
Original reproducer is almost identical to the one that is fixed by
https://patchwork.ozlabs.org/patch/1129479/.
bpf_prog_free_deferred bug that's undeterministically exposed after
this fix seems to be the cause of a bunch of other bug reports and is
not related to verifier precision tracking.
#s
On Tue, Jul 9, 2019 at 9:08 PM Hillf Danton wrote:
>
>
> Mon, 08 Jul 2019 21:25:00 -0700 (PDT)
> > Hello,
> >
> > syzbot has tested the proposed patch but the reproducer still triggered
> > crash:
> > WARNING in bpf_jit_free
> >
> > WARNING: CPU: 0 PID: 9077 at kernel/bpf/core.c:851 bpf_jit_free+0
On Mon, Jul 8, 2019 at 3:42 PM Krzesimir Nowak wrote:
>
> This prints a message when the error is about program type being not
> supported by the test runner or because of permissions problem. This
> is to see if the program we expected to run was actually executed.
>
> The messages are open-coded
On Mon, Jul 8, 2019 at 3:42 PM Krzesimir Nowak wrote:
>
> Save errno right after bpf_prog_test_run returns, so we later check
> the error code actually set by bpf_prog_test_run, not by some libcap
> function.
>
> Changes since v1:
> - Fix the "Fixes:" tag to mention actual commit that introduced t
rted
> program types")
> Cc: Stanislav Fomichev
> Signed-off-by: Krzesimir Nowak
> ---
Acked-by: Andrii Nakryiko
> tools/testing/selftests/bpf/test_verifier.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/tools/testing/selftests
f-by: Krzesimir Nowak
> ---
lgtm, with some nits below
Acked-by: Andrii Nakryiko
> tools/testing/selftests/bpf/test_verifier.c | 16 +++-
> 1 file changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/tools/testing/selftests/bpf/test_verifier.c
> b/tools/testin
On Mon, Jul 8, 2019 at 3:42 PM Krzesimir Nowak wrote:
>
> The test case can now specify a custom length of the data member,
> context data and its length, which will be passed to
> bpf_prog_test_run_xattr. For backward compatilibity, if the data
> length is 0 (which is what will happen when the fi
On Tue, May 26, 2020 at 7:09 PM Daniel Xu wrote:
>
> Right now the libbpf model encourages loading the entire object at once.
> In this model, libbpf handles loading BTF from vmlinux for us. However,
> it can be useful to selectively load certain maps and programs inside an
> object without loadin
On Wed, May 27, 2020 at 10:12 AM Daniel Xu wrote:
>
> Hi Andrii,
>
> On Tue May 26, 2020 at 3:09 PM PST, Andrii Nakryiko wrote:
> > On Tue, May 26, 2020 at 7:09 PM Daniel Xu wrote:
> > >
> > > Right now the libbpf model encourages loading the entire object
On Wed, May 27, 2020 at 7:53 PM 王贇 wrote:
>
> This is a tool to trace the related schedule events of a
> specified task, eg the migration, sched in/out, wakeup and
> sleep/block.
>
> The event was translated into sentence to be more readable,
> by execute command 'task_detector -p 49870' we contin
t; create mode 100644 tools/testing/selftests/bpf/progs/bpf_iter_task_stack.c
>
> --
> 2.24.1
Thanks for working on this! This will enable a whole new set of tools
and applications.
Acked-by: Andrii Nakryiko
On Tue, Jun 23, 2020 at 11:46 PM Li Xinhai wrote:
>
> - information of machine
> Linux localhost.localdomain 4.18.0-193.6.3.el8_2.x86_64 #1 SMP Wed Jun 10
> 11:09:32 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
>
> - configurations
> make defconfig
> make kvmconfig
>
> - failed logs on v5.6
> ```
>
On Fri, Jul 3, 2020 at 7:47 AM Alan Maguire wrote:
>
> The bpf helper bpf_trace_printk() uses trace_printk() under the hood.
> This leads to an alarming warning message originating from trace
> buffer allocation which occurs the first time a program using
> bpf_trace_printk() is loaded.
>
> We can
On Fri, Jul 3, 2020 at 7:45 AM Alan Maguire wrote:
>
> Simple selftest that verifies bpf_trace_printk() returns a sensible
> value and tracing messages appear.
>
> Signed-off-by: Alan Maguire
> ---
> .../selftests/bpf/prog_tests/trace_printk.c| 71
> ++
> tools/testi
On Mon, Jul 13, 2020 at 5:43 PM Peilin Ye wrote:
>
> Prevent __btf_resolve_helper_id() from dereferencing `btf_vmlinux`
> as NULL. This patch fixes the following syzbot bug:
>
>
> https://syzkaller.appspot.com/bug?id=5edd146856fd513747c1992442732e5a0e9ba355
>
> Reported-by: syzbot+ee09bda7017
> Reported-by: syzbot+ee09bda7017345f1f...@syzkaller.appspotmail.com
> Signed-off-by: Peilin Ye
> ---
> Thank you for reviewing my patch! I am new to Linux kernel development; would
> the log message and errno be appropriate for this case?
I think it's good enough, thanks for the fix.
On Tue, Oct 6, 2020 at 4:45 PM Hao Luo wrote:
>
> Commit 4976b718c355 ("bpf: Introduce pseudo_btf_id") switched
> the order of check_subprogs() and resolve_pseudo_ldimm() in
> the verifier. Now an empty prog and the prog of a single
> invalid ldimm expect to see the error "last insn is not an
> ex
On Tue, Oct 6, 2020 at 5:51 PM Hao Luo wrote:
>
> On Tue, Oct 6, 2020 at 5:43 PM Andrii Nakryiko
> wrote:
> >
> > On Tue, Oct 6, 2020 at 4:45 PM Hao Luo wrote:
> > >
> > > Commit 4976b718c355 ("bpf: Introduce pseudo_btf_id") switched
> > &
On Thu, Oct 1, 2020 at 12:25 AM Alexei Starovoitov
wrote:
>
> On Wed, Sep 30, 2020 at 10:28:33AM +0100, Lorenz Bauer wrote:
> > On Tue, 29 Sep 2020 at 16:48, Alexei Starovoitov
> > wrote:
> >
> > ...
> >
> > > There was a warning. I noticed it while applying and fixed it up.
> > > Lorenz, please
On Tue, Aug 25, 2020 at 4:21 PM Udip Pant wrote:
>
> This adds a selftest that tests the behavior when a freplace target program
> attempts to make a write access on a packet. The expectation is that the read
> or write
> access is granted based on the program type of the linked program and
> not
d redefine
> them to work around this.
>
> Fixes: b72091bd4ee4 ("selftests/bpf: Add test for bpf_seq_printf_btf helper")
> Fixes: 076a95f5aff2 ("selftests/bpf: Add bpf_snprintf_btf helper tests")
> Reported-by: Andrii Nakryiko
> Signed-off-by: Alan Maguire
&g
On Thu, Sep 24, 2020 at 5:51 PM Alexei Starovoitov
wrote:
>
> On Wed, Sep 23, 2020 at 06:46:26PM +0100, Alan Maguire wrote:
> > +static int __strncmp(const void *m1, const void *m2, size_t len)
> > +{
> > + const unsigned char *s1 = m1;
> > + const unsigned char *s2 = m2;
> > + int i,
On Mon, Sep 28, 2020 at 7:14 AM Alan Maguire wrote:
>
>
>
> On Thu, 24 Sep 2020, Alexei Starovoitov wrote:
>
> > to whatever number, but printing single task_struct needs ~800 lines and
> > ~18kbytes. Humans can scroll through that much spam, but can we make it less
> > verbose by default somehow?
On Mon, Sep 28, 2020 at 4:36 AM Alan Maguire wrote:
>
> Add a test verifying iterating over tasks and displaying BTF
> representation of task_struct succeeds.
>
> Suggested-by: Alexei Starovoitov
> Signed-off-by: Alan Maguire
> ---
Hey Alan,
These selftests rely on having struct btf_ptr and BT
On Thu, May 28, 2020 at 1:14 AM 王贇 wrote:
>
> Hi, Andrii
>
> Thanks for your comments :-)
>
> On 2020/5/28 下午2:36, Andrii Nakryiko wrote:
> [snip]
> >> ---
> >
> > I haven't looked through implementation thoroughly yet. But I have few
> >
roofpoint.com/v2/url?u=https-3A__syzkaller.appspot.com_x_repro.c-3Fx-3D1553834a10&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=vxqvl81C2rT6GOGdPyz8iQ&m=sMAtpavBBjBzFzT0V8c6FcH8cu2M9da3ZozO5Lc8do0&s=r6sGJDOgosZDE9sRxqFnVibDNJFt_6IteSWeqEQLbNE&e=
The bug was bisected to:
commit af6ee
On Thu, May 28, 2020 at 2:48 PM Joel Fernandes wrote:
>
> On Mon, May 25, 2020 at 11:38:23AM -0700, Andrii Nakryiko wrote:
> > On Mon, May 25, 2020 at 7:53 AM Boqun Feng wrote:
> > >
> > > Hi Andrii,
> > >
> > > On Fri, May 22, 2020 at 12:38:21PM
On Thu, May 28, 2020 at 3:17 PM Peter Zijlstra wrote:
>
> On Thu, May 28, 2020 at 06:00:47PM -0400, Joel Fernandes wrote:
>
> > Any idea why this choice of locking-based ring buffer implementation in BPF?
> > The ftrace ring buffer can support NMI interruptions as well for writes.
> >
> > Also, is
On Thu, May 28, 2020 at 3:54 PM Joel Fernandes wrote:
>
> Hello Andrii,
> This is quite exciting. Some comments below:
>
> On Wed, May 27, 2020 at 11:24:08PM -0700, Andrii Nakryiko wrote:
> [...]
> > diff --git a/Documentation/litmus-tests/bpf-rb/bpf-rb+1p1c+bounded.lit
On 5/28/20 2:27 PM, Eric Dumazet wrote:
On 5/28/20 2:01 PM, Andrii Nakryiko wrote:
On 5/28/20 9:44 AM, syzbot wrote:
Hello,
syzbot found the following crash on:
HEAD commit: dc0f3ed1 net: phy: at803x: add cable diagnostics support f..
git tree: net-next
console output:
https
On 5/28/20 11:23 PM, Dmitry Vyukov wrote:
On Thu, May 28, 2020 at 11:01 PM 'Andrii Nakryiko' via syzkaller-bugs
wrote:
On 5/28/20 9:44 AM, syzbot wrote:
Hello,
syzbot found the following crash on:
HEAD commit:dc0f3ed1 net: phy: at803x: add cable diagnostics support f.
On Fri, May 29, 2020 at 5:36 AM Peter Zijlstra wrote:
>
> On Thu, May 28, 2020 at 10:14:21PM -0700, Andrii Nakryiko wrote:
>
> > There is another cluster of applications which are unnecessarily more
> > complicated just for the fact that there is no ordering between
>
On Fri, May 29, 2020 at 10:23 AM Joel Fernandes wrote:
>
> On Thu, May 28, 2020 at 09:38:35PM -0700, Andrii Nakryiko wrote:
> > On Thu, May 28, 2020 at 2:48 PM Joel Fernandes
> > wrote:
> > >
> > > On Mon, May 25, 2020 at 11:38:23AM -0700, Andrii Nakryiko wr
On Fri, May 29, 2020 at 10:34 AM Joel Fernandes wrote:
>
> Hi Andrii,
>
> On Thu, May 28, 2020 at 10:50:30PM -0700, Andrii Nakryiko wrote:
> > > [...]
> > > > diff --git
> > > > a/Documentation/litmus-tests/bpf-rb/bpf-rb+1p1c+bounded.litmus
>
On 5/29/20 10:32 AM, Eric Dumazet wrote:
On 5/28/20 11:32 PM, Andrii Nakryiko wrote:
On 5/28/20 11:23 PM, Dmitry Vyukov wrote:
On Thu, May 28, 2020 at 11:01 PM 'Andrii Nakryiko' via syzkaller-bugs
wrote:
On 5/28/20 9:44 AM, syzbot wrote:
Hello,
syzbot found the following crash
On Sun, May 24, 2020 at 5:09 AM Akira Yokosawa wrote:
>
> On Fri, 22 May 2020 12:38:21 -0700, Andrii Nakryiko wrote:
> > On 5/22/20 10:43 AM, Paul E. McKenney wrote:
> >> On Fri, May 22, 2020 at 10:32:01AM -0400, Alan Stern wrote:
> >>> On Fri, May 22, 2020 at
On Mon, May 25, 2020 at 7:53 AM Boqun Feng wrote:
>
> Hi Andrii,
>
> On Fri, May 22, 2020 at 12:38:21PM -0700, Andrii Nakryiko wrote:
> > On 5/22/20 10:43 AM, Paul E. McKenney wrote:
> > > On Fri, May 22, 2020 at 10:32:01AM -0400, Alan Stern wrote:
> > > > O
On Mon, May 25, 2020 at 3:01 PM Akira Yokosawa wrote:
>
> On Mon, 25 May 2020 11:31:27 -0700, Andrii Nakryiko wrote:
> > On Sun, May 24, 2020 at 5:09 AM Akira Yokosawa wrote:
> >>
> >> On Fri, 22 May 2020 12:38:21 -0700, Andrii Nakryiko wrote:
> >>> O
On Tue, May 26, 2020 at 3:50 AM Akira Yokosawa wrote:
>
> On Mon, 25 May 2020 16:31:05 -0700, Andrii Nakryiko wrote:
> > On Mon, May 25, 2020 at 3:01 PM Akira Yokosawa wrote:
> >>
> [...]
> >> Yes, that should work.
> >
> > Ok, assigning t
On Tue, May 26, 2020 at 7:02 AM Akira Yokosawa wrote:
>
> On Tue, 26 May 2020 19:50:47 +0900, Akira Yokosawa wrote:
> > On Mon, 25 May 2020 16:31:05 -0700, Andrii Nakryiko wrote:
> >> On Mon, May 25, 2020 at 3:01 PM Akira Yokosawa wrote:
> >>>
> > [...]
&g
On Tue, May 26, 2020 at 4:00 PM Akira Yokosawa wrote:
>
> On Tue, 26 May 2020 13:19:36 -0700, Andrii Nakryiko wrote:
> > On Tue, May 26, 2020 at 7:02 AM Akira Yokosawa wrote:
> >>
> >> On Tue, 26 May 2020 19:50:47 +0900, Akira Yokosawa wrote:
> >>>
On Fri, May 8, 2020 at 8:39 AM Christoph Hellwig wrote:
>
> Use __anon_inode_getfd instead of opencoding the logic using
> get_unused_fd_flags + anon_inode_getfile. Also switch the
> bpf_link_new_file calling conventions to match __anon_inode_getfd.
>
> Signed-off-by: Christoph Hellwig
> ---
>
On Fri, May 8, 2020 at 12:21 AM Ian Rogers wrote:
>
> On Fri, May 8, 2020 at 12:12 AM Andrii Nakryiko
> wrote:
> >
> > On Thu, May 7, 2020 at 11:40 PM Ian Rogers wrote:
> > >
> > > If bits is 0, the case when the map is empty, then the >> is the
On 5/22/20 10:43 AM, Paul E. McKenney wrote:
On Fri, May 22, 2020 at 10:32:01AM -0400, Alan Stern wrote:
On Fri, May 22, 2020 at 11:44:07AM +0200, Peter Zijlstra wrote:
On Thu, May 21, 2020 at 05:38:50PM -0700, Paul E. McKenney wrote:
Hello!
Just wanted to call your attention to some pretty c
On Mon, May 11, 2020 at 10:59 PM Alan Maguire wrote:
>
> tests verify we get > 0 return value from bpf_trace_print()
> using %pT format specifier with various modifiers/pointer
> values.
>
> Signed-off-by: Alan Maguire
> ---
There is no need to use perf buffer for returning results to
user-space
On Fri, May 15, 2020 at 9:51 AM Ian Rogers wrote:
>
> Remove #include of libbpf_internal.h that is unused.
> Discussed in this thread:
> https://lore.kernel.org/lkml/caef4bzzrmieds_8r8g4vaaewvjzpb4xylnpf0x2vny8otzk...@mail.gmail.com/
>
> Signed-off-by: Ian Rogers
> ---
Acke
On Fri, May 15, 2020 at 9:51 AM Ian Rogers wrote:
>
> Use a hashmap between a char* string and a double* value. While bpf's
> hashmap entries are size_t in size, we can't guarantee sizeof(size_t) >=
> sizeof(double). Avoid a memory allocation when gathering ids by making 0.0
> a special value enco
> 150 | for (bkt = 0; bkt < map->cap; bkt++)\
>
> Signed-off-by: Ian Rogers
> ---
Acked-by: Andrii Nakryiko
> tools/lib/bpf/hashmap.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/tools/lib/bpf/hashmap.c b/tools/lib/bp
uild.
>
> Signed-off-by: Ian Rogers
> ---
Given you want to make sure they stay 1 to 1, would just creating a
symlink work instead of copying the code?
Either way, I think hashmap is stable and not going to change
frequently, so whichever way is fine with me.
Acked-by: Andrii N
#x27; and 'make -C tools/perf build-test'.
> >
> > The hashmap change was originally part of an RFC:
> > https://lore.kernel.org/lkml/20200508053629.210324-1-irog...@google.com/
> >
> > v2. moves hashmap into tools/perf/util rather than libapi, to allow
> >
here is actually __SIZEOF_SIZE_T__, which is more directly what
hash_bits work with, but I don't think it matters for any reasonable
system in use :)
So yeah,
Acked-by: Andrii Nakryiko
Are you going to do this change for libbpf's variant, or should I
submit a separate patch?
>
> static inline size_t hash_bits(size_t h, int bits)
On Mon, Aug 31, 2020 at 4:03 PM Barret Rhoden wrote:
>
> The max_entries for a BPF map may depend on runtime parameters.
> Currently, we need to know the maximum value at BPF compile time. For
> instance, if you want an array map with NR_CPUS entries, you would hard
> code your architecture's lar
On Thu, Sep 3, 2020 at 11:02 AM Hao Luo wrote:
>
> The returned value of bpf_object__open_file() should be checked with
> IS_ERR() rather than NULL. This fix makes test_progs not crash when
> test_global_data.o is not present.
>
> Signed-off-by: Hao Luo
> ---
> tools/testing/selftests/bpf/prog_t
--
thanks!
Acked-by: Andrii Nakryiko
> tools/testing/selftests/bpf/prog_tests/global_data_init.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/tools/testing/selftests/bpf/prog_tests/global_data_init.c
> b/tools/testing/selftests/bpf/prog_tests/glo
On Thu, Aug 27, 2020 at 3:29 PM Hao Luo wrote:
>
> On Fri, Aug 21, 2020 at 3:37 PM Andrii Nakryiko
> wrote:
> >
> > On Wed, Aug 19, 2020 at 3:42 PM Hao Luo wrote:
> > >
> > > If a ksym is defined with a type, libbpf will try to find the ksym's btf
&
On Thu, Aug 27, 2020 at 8:42 PM Hao Luo wrote:
>
> Thanks for taking a look!
>
> On Fri, Aug 21, 2020 at 8:30 PM Andrii Nakryiko
> wrote:
> >
> > On Wed, Aug 19, 2020 at 3:42 PM Hao Luo wrote:
> > >
> > > Test bpf_per_cpu_ptr(). Test two paths in th
On Tue, Sep 1, 2020 at 1:35 PM Hao Luo wrote:
>
> On Tue, Sep 1, 2020 at 11:11 AM Andrii Nakryiko
> wrote:
> >
> > On Thu, Aug 27, 2020 at 3:29 PM Hao Luo wrote:
> > >
> > > On Fri, Aug 21, 2020 at 3:37 PM Andrii Nakryiko
> > > wrote:
> &g
On Thu, Sep 3, 2020 at 3:34 PM Hao Luo wrote:
>
> Pseudo_btf_id is a type of ld_imm insn that associates a btf_id to a
> ksym so that further dereferences on the ksym can use the BTF info
> to validate accesses. Internally, when seeing a pseudo_btf_id ld insn,
> the verifier reads the btf_id store
On Thu, Sep 3, 2020 at 3:34 PM Hao Luo wrote:
>
> If a ksym is defined with a type, libbpf will try to find the ksym's btf
> information from kernel btf. If a valid btf entry for the ksym is found,
> libbpf can pass in the found btf id to the verifier, which validates the
> ksym's type and value.
On Thu, Sep 3, 2020 at 3:35 PM Hao Luo wrote:
>
> Selftests for typed ksyms. Tests two types of ksyms: one is a struct,
> the other is a plain int. This tests two paths in the kernel. Struct
> ksyms will be converted into PTR_TO_BTF_ID by the verifier while int
> typed ksyms will be converted into
the caller must check the returned value.
>
> Acked-by: Andrii Nakryiko
> Signed-off-by: Hao Luo
> ---
> include/linux/bpf.h| 3 ++
> include/linux/btf.h| 11 ++
> include/uapi/linux/bpf.h | 17 +
> kernel/bpf/btf.c
means that the returned pointer is stable
> during all the execution of the program.
>
> Signed-off-by: Hao Luo
> ---
looks good, few small things, but otherwise:
Acked-by: Andrii Nakryiko
> include/linux/bpf.h| 1 +
> include/uapi/linux/bpf.h | 14 ++
le. If the base pointer isn't a struct, the
> returned reg is of type PTR_TO_MEM, which also supports direct pointer
> dereference.
>
> Acked-by: Andrii Nakryiko
> Signed-off-by: Hao Luo
> ---
> .../selftests/bpf/prog_tests/ksyms_btf.c | 10 +++
> .../se
On Mon, Aug 3, 2020 at 6:18 PM Song Liu wrote:
>
>
>
> > On Aug 2, 2020, at 6:40 PM, Andrii Nakryiko
> > wrote:
> >
> > On Sat, Aug 1, 2020 at 1:50 AM Song Liu wrote:
> >>
>
> [...]
>
> >
> >> };
> >>
> >> L
On Tue, Aug 4, 2020 at 2:01 PM Song Liu wrote:
>
>
>
> > On Aug 2, 2020, at 10:10 PM, Andrii Nakryiko
> > wrote:
> >
> > On Sun, Aug 2, 2020 at 9:47 PM Song Liu wrote:
> >>
> >>
> >>> On Aug 2, 2020, at 6:51 PM, Andrii Nakryiko
&
On Tue, Aug 4, 2020 at 8:59 PM Song Liu wrote:
>
>
>
> > On Aug 4, 2020, at 6:38 PM, Andrii Nakryiko
> > wrote:
> >
> > On Mon, Aug 3, 2020 at 6:18 PM Song Liu wrote:
> >>
> >>
> >>
> >>> On Aug 2, 2020, at 6:40 PM, Andrii
On Tue, Aug 4, 2020 at 9:47 PM Song Liu wrote:
>
>
>
> > On Aug 4, 2020, at 6:52 PM, Andrii Nakryiko
> > wrote:
> >
> > On Tue, Aug 4, 2020 at 2:01 PM Song Liu wrote:
> >>
> >>
> >>
> >>> On Aug 2, 2020, at 10:10 PM, A
On Tue, Aug 4, 2020 at 11:26 PM Song Liu wrote:
>
>
>
> > On Aug 4, 2020, at 10:32 PM, Andrii Nakryiko
> > wrote:
> >
> > On Tue, Aug 4, 2020 at 8:59 PM Song Liu wrote:
> >>
> >>
> >>
> >>> On Aug 4, 2020, at 6:38 PM, A
On 9/7/20 8:08 PM, Stephen Rothwell wrote:
Hi all,
After merging the bpf-next tree, today's linux-next build (powerpcle perf)
failed like this:
util/bpf-loader.c: In function 'config_bpf_program':
util/bpf-loader.c:331:2: error: 'bpf_program__title' is deprecated: BPF program
title is confusin
On Fri, Aug 14, 2020 at 2:58 AM Miaohe Lin wrote:
>
> Convert the uses of fallthrough comments to fallthrough macro.
>
> Signed-off-by: Miaohe Lin
> ---
> kernel/bpf/cgroup.c | 2 +-
> kernel/bpf/cpumap.c | 2 +-
> kernel/bpf/syscall.c | 2 +-
> kernel/bpf/verifier.c | 6 +++---
> 4 files c
ernel.org
Fixes: f2683bd8d5bd ("[PATCH] fix d_absolute_path() interplay with fsmount()")
Signed-off-by: Andrii Nakryiko
---
fs/d_path.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/fs/d_path.c b/fs/d_path.c
index 0f1fc1743302..a69e2cd36e6e 100644
--- a/fs/d
On Wed, Oct 14, 2020 at 4:08 PM Al Viro wrote:
>
> On Wed, Oct 14, 2020 at 01:45:28PM -0700, Andrii Nakryiko wrote:
> > Fix data race in prepend_path() with re-reading mnt->mnt_ns twice without
> > holding the lock. is_mounted() does check for NULL, but
> > is_anon_n
Add is_real_ns() helper validating that mount namespace is a valid one.
Use that from is_mounted() and clean up prepare_path() that open-coded similar
check.
Suggested-by: Alexander Viro
Signed-off-by: Andrii Nakryiko
---
fs/d_path.c | 3 +--
fs/mount.h | 9 +++--
2 files changed, 8
On Mon, Oct 19, 2020 at 10:38 AM wrote:
>
> From: Tom Rix
>
> A break is not needed if it is preceded by a return
>
> Signed-off-by: Tom Rix
> ---
Probably refactoring left over, looks good:
Acked-by: Andrii Nakryiko
> kernel/bpf/syscall.c | 1 -
> 1 file chan
On Tue, Oct 20, 2020 at 10:05 AM Hao Luo wrote:
>
> Thanks for reporting this and cc'ing me. I forgot to update the error
> messages when renaming the flags. I will send a patch to fix the error
> message.
>
> The commit
>
> commit f3d9054ba8ff1df0fc44e507e3a01c0964cabd42
> Author: Hao Luo
>
On Tue, Oct 20, 2020 at 3:51 AM Jiri Slaby wrote:
>
> Hi,
>
> On 19. 10. 20, 1:18, Érico Rolim wrote:
> > I'm trying to build kernel 5.9.1 for arm64, and my dotconfig has
> > `CONFIG_DEBUG_INFO_BTF=y`, which requires pahole for building. However,
> > pahole
> > version 1.18 segfaults during the b
On Wed, Oct 21, 2020 at 6:48 AM Arnaldo Carvalho de Melo
wrote:
>
> Em Wed, Oct 21, 2020 at 08:22:40AM +0200, Jiri Slaby escreveu:
> > On 20. 10. 20, 14:20, Arnaldo Carvalho de Melo wrote:
> > > > Yeah, I observe the very same. I reported it at:
> > > > https://bugzilla.suse.com/show_bug.cgi?id=11
On Tue, Oct 27, 2020 at 4:37 PM Ian Rogers wrote:
>
> The bpf_caps array is shorter without CAP_BPF, avoid out of bounds reads
> if this isn't defined. Working around this avoids -Wno-array-bounds with
> clang.
>
> Signed-off-by: Ian Rogers
> ---
Acked-by: Andrii Nakry
On Tue, Oct 27, 2020 at 4:37 PM Ian Rogers wrote:
>
> Avoid an unused variable warning.
>
> Signed-off-by: Ian Rogers
> ---
Acked-by: Andrii Nakryiko
> tools/bpf/bpftool/skeleton/profiler.bpf.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> dif
fix all the locals in that macro with __ to avoid most of
> these warnings.
>
> Fixes: 492ecee892c2 ("bpf: enable program stats")
> Signed-off-by: Arnd Bergmann
> ---
Acked-by: Andrii Nakryiko
> include/linux/filter.h | 22 +++---
> 1 file chang
>
> This appears to be intentional, so change the cast in a way that
> suppresses the warning.
>
> Signed-off-by: Arnd Bergmann
> ---
LGTM.
Acked-by: Andrii Nakryiko
> include/linux/filter.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --g
On Mon, Oct 26, 2020 at 2:04 PM Arnd Bergmann wrote:
>
> From: Arnd Bergmann
>
> gcc -Wextra points out that a field may get overridden in some
> configurations such as x86 allmodconfig, when the next index after the one
> that has been assigned last already had a value, in this case for index
>
On Thu, Oct 29, 2020 at 9:11 AM Ian Rogers wrote:
>
> If bits is 0, the case when the map is empty, then the >> is the size of
> the register which is undefined behavior - on x86 it is the same as a
> shift by 0. Fix by handling the 0 case explicitly when running with
> address sanitizer.
>
> A va
Hao,
This seems to be coming from resolve_pseudo_ldimm64(), could you
please take a look? Thanks!
-- Andrii
On Thu, Oct 29, 2020 at 5:58 AM kernel test robot wrote:
>
> Greeting,
>
> FYI, we noticed the following commit (built with gcc-9):
>
> commit: 472547778de24e2764ab325268dd5b77e6923939 ("
501 - 600 of 737 matches
Mail list logo
