On Wed, Oct 23, 2019 at 12:23:06PM -0400, Steven Rostedt wrote:
> On Tue, 22 Oct 2019 14:58:43 -0700
> Alexei Starovoitov wrote:
>
> > Neither of two statements are true. The per-function generated trampoline
> > I'm talking about is bpf specific. For a function with two arg
On Wed, Oct 23, 2019 at 8:40 AM KP Singh wrote:
>
> From: KP Singh
>
> On compiling samples with this change, one gets an error:
>
> error: ‘strncat’ specified bound 118 equals destination size
> [-Werror=stringop-truncation]
>
> strncat(dst, name + section_names[i].len,
>
On Tue, Oct 22, 2019 at 03:45:26PM -0700, Andy Lutomirski wrote:
>
>
> >> On Oct 22, 2019, at 2:58 PM, Alexei Starovoitov
> >> wrote:
> >>
> >> On Tue, Oct 22, 2019 at 05:04:30PM -0400, Steven Rostedt wrote:
> >> I gave a solution
On Tue, Oct 22, 2019 at 05:04:30PM -0400, Steven Rostedt wrote:
>
> I gave a solution for this. And that is to add another flag to allow
> for just the minimum to change the ip. And we can even add another flag
> to allow for changing the stack if needed (to emulate a call with the
> same
On Tue, Oct 22, 2019 at 02:10:21PM -0400, Steven Rostedt wrote:
> On Tue, 22 Oct 2019 10:50:56 -0700
> Alexei Starovoitov wrote:
>
> > > +static void my_hijack_func(unsigned long ip, unsigned long pip,
> > > +struct ftrace_ops *ops, struct
On Tue, Oct 22, 2019 at 09:44:55AM -0400, Steven Rostedt wrote:
> On Tue, 22 Oct 2019 07:19:56 -0400
> Steven Rostedt wrote:
>
> > > I'm not touching dyn_ftrace.
> > > Actually calling my stuff ftrace+bpf is probably not correct either.
> > > I'm reusing code patching of nop into call that
On Mon, Oct 21, 2019 at 11:19:04PM -0400, Steven Rostedt wrote:
> On Mon, 21 Oct 2019 23:16:30 -0400
> Steven Rostedt wrote:
>
> > > what bugs you're seeing?
> > > The IPI frequency that was mentioned in this thread or something else?
> > > I'm hacking ftrace+bpf stuff in the same spot and would
On Mon, Oct 21, 2019 at 11:16:30PM -0400, Steven Rostedt wrote:
> On Mon, 21 Oct 2019 20:10:09 -0700
> Alexei Starovoitov wrote:
>
> > On Mon, Oct 21, 2019 at 5:43 PM Steven Rostedt wrote:
> > >
> > > On Mon, 21 Oct 2019 17:36:54 -0700
> > > Alexei Star
On Mon, Oct 21, 2019 at 5:43 PM Steven Rostedt wrote:
>
> On Mon, 21 Oct 2019 17:36:54 -0700
> Alexei Starovoitov wrote:
>
>
> > What is the status of this set ?
> > Steven, did you apply it ?
>
> There's still bugs to figure out.
what bugs you're seeing?
The
On Fri, Oct 4, 2019 at 6:45 AM Steven Rostedt wrote:
>
> On Fri, 4 Oct 2019 13:22:37 +0200
> Peter Zijlstra wrote:
>
> > On Thu, Oct 03, 2019 at 06:10:45PM -0400, Steven Rostedt wrote:
> > > But still, we are going from 120 to 660 IPIs for every CPU. Not saying
> > > it's a problem, but
On Fri, Oct 18, 2019 at 11:18:48AM +0800, Kefeng Wang wrote:
> For kernel logging macro, pr_warning is completely removed and
> replaced by pr_warn, using pr_warn in tools lib bpf for symmetry
> to kernel logging macro, then we could drop pr_warning in the
> whole linux code.
>
On Fri, Oct 18, 2019 at 10:56:57AM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the bpf-next tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
>
> WARNING: 2 bad relocations
> c1998a48 R_PPC64_ADDR64_binary__btf_vmlinux_bin_start
>
On Fri, Oct 18, 2019 at 01:31:39PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the tip tree got a conflict in:
>
> samples/bpf/Makefile
>
> between commit:
>
> 1d97c6c2511f ("samples/bpf: Base target programs rules on Makefile.target")
>
> from the net-next
On Wed, Oct 16, 2019 at 01:18:07PM +0200, Christian Brauner wrote:
> Hey everyone,
>
> This is v4. If you still feel that I should leave this code alone then
> simply ignore it. I won't send another version. Relevant tests pass and
> I've verified that other failures were already present without
If the irqs are disabled, postpone up_read() in irq_work.
>
> Fixes: commit 615755a77b24 ("bpf: extend stackmap to save
> binary_build_id+offset instead of address")
> Cc: sta...@vger.kernel.org # v4.17+
> Cc: Peter Zijlstra
> Cc: Alexei Starovoitov
> Cc: Daniel Borkmann
> Signed-off-by: Song Liu
I fixed 'Fixes' tag and applied to bpf-next.
Thanks
exactly what copy_struct_from_user() is doing.
> Note that copy_struct_from_user() is calling min() already. So
> technically, the min_t() call could go. But the info_len is used further
> below so leave it.
>
> [1]: f5a1a536fa14 ("lib: introduce copy_struct_from_user() helper")
&
f
> using their own hand-rolled version.
>
> [1]: f5a1a536fa14 ("lib: introduce copy_struct_from_user() helper")
> Cc: Alexei Starovoitov
> Cc: Daniel Borkmann
> Cc: b...@vger.kernel.org
> Acked-by: Aleksa Sarai
> Signed-off-by: Christian Brauner
> ---
&
On Tue, Oct 15, 2019 at 5:41 PM Christian Brauner
wrote:
>
> Hey everyone,
>
> In v5.4-rc2 we added two new helpers check_zeroed_user() and
> copy_struct_from_user() including selftests (cf. [1]). It is a generic
> interface designed to copy a struct from userspace. The helpers will be
>
On Tue, Oct 15, 2019 at 3:55 PM Christian Brauner
wrote:
>
> On Tue, Oct 15, 2019 at 03:45:54PM -0700, Alexei Starovoitov wrote:
> > On Thu, Oct 10, 2019 at 2:26 AM Christian Brauner
> > wrote:
> > >
> > > On Wed, Oct 09, 2019 at 04:06:18PM -0700, Alexei Star
On Thu, Oct 10, 2019 at 2:26 AM Christian Brauner
wrote:
>
> On Wed, Oct 09, 2019 at 04:06:18PM -0700, Alexei Starovoitov wrote:
> > On Wed, Oct 9, 2019 at 9:09 AM Christian Brauner
> > wrote:
> > >
> > > Hey everyone,
> > >
> > >
On Sat, Oct 12, 2019 at 9:52 PM Ilya Maximets wrote:
>
> 'struct xdp_umem_reg' has 4 bytes of padding at the end that makes
> valgrind complain about passing uninitialized stack memory to the
> syscall:
>
> Syscall param socketcall.setsockopt() points to uninitialised byte(s)
> at
On Wed, Oct 09, 2019 at 06:49:29PM +0200, Ilya Maximets wrote:
> 'struct xdp_umem_reg' has 4 bytes of padding at the end that makes
> valgrind complain about passing uninitialized stack memory to the
> syscall:
>
> Syscall param socketcall.setsockopt() points to uninitialised byte(s)
> at
On Fri, Oct 11, 2019 at 5:07 AM Ilias Apalodimas
wrote:
>
> On Fri, Oct 11, 2019 at 03:27:53AM +0300, Ivan Khoronzhuk wrote:
> > This series contains mainly fixes/improvements for cross-compilation
> > but not only, tested for arm, arm64, and intended for any arch.
> > Also verified on native
On Fri, Oct 11, 2019 at 3:15 AM Tetsuo Handa
wrote:
>
> Hello.
>
> I noticed that syzbot is reporting that refcount incremented by
> bpf(BPF_MAP_UPDATE_ELEM)
> syscall is not decremented when unregister_netdevice() is called. Is this a
> BPF bug?
Jesper, Toke,
please take a look.
> Kernel:
On 10/10/19 10:46 AM, Peter Zijlstra wrote:
> On Thu, Oct 10, 2019 at 05:19:01PM +0000, Alexei Starovoitov wrote:
>> On 10/10/19 12:36 AM, Peter Zijlstra wrote:
>>> On Wed, Oct 09, 2019 at 11:19:16PM -0700, Song Liu wrote:
>>>> bpf stackmap with build-id lookup (BPF
On 10/10/19 12:36 AM, Peter Zijlstra wrote:
> On Wed, Oct 09, 2019 at 11:19:16PM -0700, Song Liu wrote:
>> bpf stackmap with build-id lookup (BPF_F_STACK_BUILD_ID) can trigger A-A
>> deadlock on rq_lock():
>>
>> rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
>> [...]
>> Call Trace:
>>
On Wed, Oct 9, 2019 at 9:09 AM Christian Brauner
wrote:
>
> Hey everyone,
>
> In v5.4-rc2 we added two new helpers check_zeroed_user() and
> copy_struct_from_user() including selftests (cf. [1]). It is a generic
> interface designed to copy a struct from userspace. The helpers will be
>
On Wed, Oct 9, 2019 at 9:49 AM Ilya Maximets wrote:
>
> 'struct xdp_umem_reg' has 4 bytes of padding at the end that makes
> valgrind complain about passing uninitialized stack memory to the
> syscall:
>
> Syscall param socketcall.setsockopt() points to uninitialised byte(s)
> at 0x4E7AB7E:
On Wed, Oct 02, 2019 at 07:46:32PM +0200, KP Singh wrote:
> From: KP Singh
>
> Rename asm_goto_workaround.h to asm_workaround.h and add a
> workaround for the newly added "asm_inline" in:
>
> commit eb111869301e ("compiler-types.h: add asm_inline definition")
>
> Add missing include for
On Wed, Sep 18, 2019 at 8:13 AM Jinshan Xiong wrote:
>
> The problem with the current approach is that it would be difficult to filter
> cgroup, especially the cgroup in question has descendents, and also it would
> spawn new descendents after BPF program is installed. it's hard to filter it
>
On Wed, Sep 18, 2019 at 05:51:10AM +, Yonghong Song wrote:
>
> Adding cc to b...@vger.kernel.org mailing list since this is really
> bpf related.
>
> On 9/17/19 10:24 PM, jinshan.xi...@gmail.com wrote:
> > From: Jinshan Xiong
> >
> > Invoking bpf program only if kprobe based perf_event has
On Fri, Sep 6, 2019 at 4:52 PM Ivan Khoronzhuk
wrote:
>
> On Fri, Sep 06, 2019 at 04:31:39PM -0700, Alexei Starovoitov wrote:
> >On Thu, Sep 05, 2019 at 12:22:06AM +0300, Ivan Khoronzhuk wrote:
> >> No need to set --target for native build, at least for arm, the
> >&g
On Thu, Sep 05, 2019 at 12:22:12AM +0300, Ivan Khoronzhuk wrote:
> +
> +If need to use environment of target board, the SYSROOT also can be set,
> +pointing on FS of target board:
> +
> +make samples/bpf/ LLC=~/git/llvm/build/bin/llc \
> + CLANG=~/git/llvm/build/bin/clang \
> +
On Thu, Sep 05, 2019 at 12:22:06AM +0300, Ivan Khoronzhuk wrote:
> No need to set --target for native build, at least for arm, the
> default target will be used anyway. In case of arm, for at least
> clang 5 - 10 it causes error like:
>
> clang: warning: unknown platform, assuming
On Fri, Sep 6, 2019 at 3:03 AM Yonghong Song wrote:
>
>
>
> On 9/5/19 2:15 PM, Sami Tolvanen wrote:
> > Instead of invoking struct bpf_prog::bpf_func directly, use the
> > BPF_PROG_RUN macro.
> >
> > Signed-off-by: Sami Tolvanen
>
> Acked-by: Yonghong Song
Applied. Thanks
On Thu, Sep 5, 2019 at 1:08 PM syzbot
wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:6d028043 Add linux-next specific files for 20190830
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=135c1a9260
> kernel config:
On Thu, Sep 05, 2019 at 10:13:10AM +0200, Ingo Molnar wrote:
>
> * Alexei Starovoitov wrote:
>
> > On Wed, Sep 4, 2019 at 10:47 AM Peter Zijlstra wrote:
> > >
> > > On Wed, Sep 04, 2019 at 08:51:21AM -0700, Alexei Starovoitov wrote:
> > > > Anythi
On Wed, Sep 4, 2019 at 10:47 AM Peter Zijlstra wrote:
>
> On Wed, Sep 04, 2019 at 08:51:21AM -0700, Alexei Starovoitov wrote:
> > Anything in tracing can be deleted.
> > Tracing is about debugging and introspection.
> > When underlying kernel code changes the introspecti
On Wed, Sep 4, 2019 at 8:40 AM Joel Fernandes wrote:
>
> On Wed, Sep 04, 2019 at 08:25:27AM -0700, Alexei Starovoitov wrote:
> > On Wed, Sep 4, 2019 at 6:10 AM Joel Fernandes
> > wrote:
> > >
> > > I wonder if this distinction of "tracepoin
On Wed, Sep 4, 2019 at 8:33 AM Joel Fernandes wrote:
>
> On Wed, Sep 04, 2019 at 08:26:52AM -0700, Alexei Starovoitov wrote:
> > On Wed, Sep 4, 2019 at 6:14 AM Joel Fernandes
> > wrote:
> > >
> > > True. However, for kprobes-based BPF program - it does chec
On Wed, Sep 4, 2019 at 6:14 AM Joel Fernandes wrote:
>
> True. However, for kprobes-based BPF program - it does check for kernel
> version to ensure that the BPF program is built against the right kernel
> version (in order to ensure the program is built against the right set of
> kernel
On Wed, Sep 4, 2019 at 6:10 AM Joel Fernandes wrote:
>
> I wonder if this distinction of "tracepoint" being non-ABI can be documented
> somewhere. I would be happy to do that if there is a place for the same. I
> really want some general "policy" in the kernel on where we draw a line in
> the
On Thu, Aug 29, 2019 at 4:28 AM syzbot
wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:47ee6e86 selftests/bpf: remove wrong nhoff in flow dissect..
> git tree: bpf-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=16227fa660
> kernel config:
On Mon, Aug 19, 2019 at 7:34 PM Daniel Xu wrote:
>
> Ah yes, sorry. Will add that.
Also please fix build errors.
It looks like buildbot is not happy about few things.
On Fri, Aug 16, 2019 at 3:33 PM Daniel Xu wrote:
>
> It's useful to know [uk]probe's nmissed and nhit stats. For example with
> tracing tools, it's important to know when events may have been lost.
> debugfs currently exposes a control file to get this information, but
> it is not compatible with
On Wed, Jul 31, 2019 at 09:11:10PM +0200, Mickaël Salaün wrote:
>
>
> On 31/07/2019 20:58, Alexei Starovoitov wrote:
> > On Wed, Jul 31, 2019 at 11:46 AM Mickaël Salaün
> > wrote:
> >>>> +for (i = 0; i < htab->n_buckets; i++) {
> &
On Wed, Jul 31, 2019 at 11:46 AM Mickaël Salaün
wrote:
> >> +for (i = 0; i < htab->n_buckets; i++) {
> >> +head = select_bucket(htab, i);
> >> +hlist_nulls_for_each_entry_safe(l, n, head, hash_node) {
> >> +landlock_inode_remove_map(*((struct inode
On Sun, Jul 21, 2019 at 11:31:12PM +0200, Mickaël Salaün wrote:
> FIXME: 64-bits in the doc
>
> This new map store arbitrary values referenced by inode keys. The map
> can be updated from user space with file descriptor pointing to inodes
> tied to a file system. From an eBPF (Landlock) program
On Wed, Jul 24, 2019 at 09:57:14AM -0400, Joel Fernandes wrote:
> On Tue, Jul 23, 2019 at 03:11:10PM -0700, Alexei Starovoitov wrote:
> > > > > > I think allowing one tracepoint and disallowing another is pointless
> > > > > > from security po
On Thu, Jul 25, 2019 at 04:25:53PM -0700, Brian Vazquez wrote:
> > > > If prev_key is deleted before map_get_next_key(), we get the first key
> > > > again. This is pretty weird.
> > >
> > > Yes, I know. But note that the current scenario happens even for the
> > > old interface (imagine you are
On Wed, Jul 17, 2019 at 10:51:43PM -0400, Joel Fernandes wrote:
> Hi Alexei,
>
> On Wed, Jul 17, 2019 at 02:40:42PM -0700, Alexei Starovoitov wrote:
> > On Wed, Jul 17, 2019 at 6:01 AM Joel Fernandes
> > wrote:
> >
> > I trimmed cc. some emails were bounci
On Wed, Jul 17, 2019 at 6:01 AM Joel Fernandes wrote:
I trimmed cc. some emails were bouncing.
> > I think allowing one tracepoint and disallowing another is pointless
> > from security point of view. Tracing bpf program can do bpf_probe_read
> > of anything.
>
> I think the assumption here is
On Tue, Jul 16, 2019 at 06:31:17PM -0400, Steven Rostedt wrote:
> On Tue, 16 Jul 2019 17:30:50 -0400
> Joel Fernandes wrote:
>
> > I don't see why a new bpf node for a trace event is a bad idea, really.
> > tracefs is how we deal with trace events on Android. We do it in production
> > systems.
On Tue, Jul 16, 2019 at 07:55:00PM -0400, Joel Fernandes wrote:
> On Tue, Jul 16, 2019 at 06:41:50PM -0400, Joel Fernandes wrote:
> > On Tue, Jul 16, 2019 at 03:26:52PM -0700, Alexei Starovoitov wrote:
> > > On Tue, Jul 16, 2019 at 05:30:50PM -0400, Joel Fernandes wrote:
>
On Tue, Jul 16, 2019 at 05:30:50PM -0400, Joel Fernandes wrote:
>
> I also thought about the pinning idea before, but we also want to add support
> for not just raw tracepoints, but also regular tracepoints (events if you
> will). I am hesitant to add a new BPF API just for creating regular
>
On Wed, Jul 10, 2019 at 10:15:44AM -0400, Joel Fernandes (Google) wrote:
> Hi,
why are you cc-ing the whole world for this patch set?
I'll reply to all as well, but I suspect a bunch of folks consider it spam.
Please read Documentation/bpf/bpf_devel_QA.rst
Also, I think, netdev@vger rejects
On Tue, Jul 9, 2019 at 10:48 AM Josh Poimboeuf wrote:
>
> On Mon, Jul 08, 2019 at 04:16:25PM -0700, Alexei Starovoitov wrote:
> > total time is hard to compare.
> > Could you compare few tests?
> > like two that are called "tcpdump *"
> >
> > I thi
On Mon, Jul 8, 2019 at 4:02 PM Josh Poimboeuf wrote:
> > >
> > > modprobe test_bpf
> > > selftests/bpf/test_progs
> > > both print runtime.
> > > Some of test_progs have high run-to-run variations though.
> >
> > Thanks, I'll give it a shot.
>
> I modprobed test_bpf with JIT disabled.
>
> Before:
On Mon, Jul 8, 2019 at 3:38 PM Josh Poimboeuf wrote:
>
> On Mon, Jul 08, 2019 at 03:15:37PM -0700, Alexei Starovoitov wrote:
> > > 2)
> > >
> > > After doing the first optimization, GCC then does another one which is
> > > a little trickier. It
On Sat, Jul 6, 2019 at 10:52 PM Josh Poimboeuf wrote:
>
> On Sat, Jul 06, 2019 at 08:32:06PM -0500, Josh Poimboeuf wrote:
> > On Sat, Jul 06, 2019 at 10:29:42PM +0200, Ingo Molnar wrote:
> > > Hm, I get this new build warning on x86-64 defconfig-ish kernels plus
> > > these enabled:
> > >
> > >
spits out warnings.
>
> Fixes: d15d356887e7 ("perf/x86: Make perf callchains work without
> CONFIG_FRAME_POINTER")
> Reported-by: Song Liu
> Signed-off-by: Josh Poimboeuf
I'm traveling atm, but the set looks good.
Acked-by: Alexei Starovoitov
If tip maintainers can rou
On Thu, Jun 27, 2019 at 01:24:11PM -0700, Brian Vazquez wrote:
> This introduces a new command to retrieve a variable number of entries
> from a bpf map.
>
> This new command can be executed from the existing BPF syscall as
> follows:
>
> err = bpf(BPF_MAP_DUMP, union bpf_attr *attr, u32 size)
On Thu, Jun 27, 2019 at 01:24:13PM -0700, Brian Vazquez wrote:
> This introduces a new command to retrieve a variable number of entries
> from a bpf map wrapping the existing bpf methods:
> map_get_next_key and map_lookup_elem
>
> Note that map_dump doesn't guarantee that reading the entire table
On Thu, Jun 27, 2019 at 9:54 AM Shuah Khan wrote:
>
> On 6/27/19 10:22 AM, David Miller wrote:
> > From: Shuah Khan
> > Date: Wed, 26 Jun 2019 21:32:52 -0600
> >
> >> On 6/26/19 9:25 PM, Jiunn Chang wrote:
> >>> Shifting signed 32-bit value by 31 bits is undefined. Changing most
> >>>
On Wed, Jun 26, 2019 at 8:56 PM Josh Poimboeuf wrote:
>
> The last patch was based weird, this one's based on upstream. Will test
> tomorrow.
Great. Once it passes your tests I'll be happy to test it on my side.
On Wed, Jun 26, 2019 at 7:47 PM Josh Poimboeuf wrote:
>
> On Wed, Jun 26, 2019 at 06:42:40PM -0700, Alexei Starovoitov wrote:
> > > @@ -1035,9 +1038,18 @@ static struct rela *find_switch_table(struct
> > > objtool_file *file,
> > >
> > >
e in the same format as
> +* switch jump tables. Each jump table should be a static
> +* local const array named "jump_table" for objtool to
> +* recognize it.
Nacked-by: Alexei Starovoitov
It's not acceptable for objtool to dictate kernel naming convention.
On Wed, Jun 26, 2019 at 6:07 PM Josh Poimboeuf wrote:
>
> On Wed, Jun 26, 2019 at 05:57:08PM -0700, Alexei Starovoitov wrote:
> > On Wed, Jun 26, 2019 at 5:36 PM Josh Poimboeuf wrote:
> > >
> > > Objtool previously ignored ___bpf_prog_run() because it didn't
&
On Wed, Jun 26, 2019 at 5:36 PM Josh Poimboeuf wrote:
>
> Objtool previously ignored ___bpf_prog_run() because it didn't
> understand the jump table. This resulted in the ORC unwinder not being
> able to unwind through non-JIT BPF code.
>
> Now that objtool knows how to read jump tables, remove
On Wed, Jun 26, 2019 at 3:14 PM Roman Gushchin wrote:
>
> On Thu, Jun 27, 2019 at 08:05:21AM +1000, Stephen Rothwell wrote:
> > Hi all,
> >
> > In commit
> >
> > 12771345a467 ("bpf: fix cgroup bpf release synchronization")
> >
> > Fixes tag
> >
> > Fixes: 4bfc0bb2c60e ("bpf: decouple the
On Tue, Jun 25, 2019 at 2:39 PM Roman Gushchin wrote:
>
> Since commit 4bfc0bb2c60e ("bpf: decouple the lifetime of cgroup_bpf
> from cgroup itself"), cgroup_bpf release occurs asynchronously
> (from a worker context), and before the release of the cgroup itself.
>
> This introduced a previously
ype (see
> next commits) but this could be used by other program types in the
> future.
>
> Signed-off-by: Mickaël Salaün
> Cc: Alexei Starovoitov
> Cc: Daniel Borkmann
> Cc: David S. Miller
> Link: https://lkml.kernel.org/r/20160827205559.ga43...@ast-mbp.thefacebook
On Tue, Jun 25, 2019 at 3:23 PM allanzhang wrote:
>
> Signed-off-by: allanzhang
As Daniel mentioned SOB needs to have real name.
If you keep ignoring feedback we'll keep rejecting patches without comments.
On Tue, Jun 25, 2019 at 8:32 AM Dan Rue wrote:
>
> On Mon, Jun 24, 2019 at 12:58:15PM -0700, Alexei Starovoitov wrote:
> > On Mon, Jun 24, 2019 at 12:53 PM Dan Rue wrote:
> > >
> > > I would say if it's not possible to check at runtime, and it requires
> >
On 6/23/19 9:02 PM, Roman Gushchin wrote:
> On Sun, Jun 23, 2019 at 08:29:21PM -0700, Alexei Starovoitov wrote:
>> On 6/23/19 7:30 PM, Roman Gushchin wrote:
>>> Since commit 4bfc0bb2c60e ("bpf: decouple the lifetime of cgroup_bpf
>>> from cgroup itself"), cgr
On Mon, Jun 24, 2019 at 12:53 PM Dan Rue wrote:
>
> I would say if it's not possible to check at runtime, and it requires
> clang 9.0, that this test should not be enabled by default.
The latest clang is the requirement.
If environment has old clang or no clang at all these tests will be
On 6/23/19 7:30 PM, Roman Gushchin wrote:
> Since commit 4bfc0bb2c60e ("bpf: decouple the lifetime of cgroup_bpf
> from cgroup itself"), cgroup_bpf release occurs asynchronously
> (from a worker context), and before the release of the cgroup itself.
>
> This introduced a previously non-existing
On Wed, Jun 19, 2019 at 9:02 AM Gustavo A. R. Silva
wrote:
>
> Notice that in this case, it's much clearer to explicitly add a break
> rather than letting the code to fall through. It also avoid potential
> future fall-through warnings[1].
>
> This patch is part of the ongoing efforts to enable
>
On Mon, Jun 17, 2019 at 6:54 PM Kris Van Hees wrote:
>
> It is not hypothetical. The folowing example works fine:
>
> static int noinline bpf_action(void *ctx, long fd, long buf, long count)
> {
> int cpu = bpf_get_smp_processor_id();
> struct data {
>
On Mon, Jun 17, 2019 at 6:25 PM Kris Van Hees wrote:
>
> On Thu, May 23, 2019 at 01:28:44PM -0700, Alexei Starovoitov wrote:
>
> << stuff skipped because it is not relevant to the technical discussion... >>
>
> > > > In particular you brought u
On Mon, Jun 17, 2019 at 4:13 PM Matt Mullins wrote:
> >
> > The bug (really just a warning) reported is exactly here.
>
> I don't think bpf_send_signal is tied to modules at all;
> send_signal_irq_work_init and the corresponding initcall should be
> moved outside that #ifdef.
right. I guess
On Mon, Jun 17, 2019 at 5:59 AM Arnd Bergmann wrote:
>
> When CONFIG_MODULES is disabled, this function is never called:
>
> kernel/trace/bpf_trace.c:581:13: error: 'do_bpf_send_signal' defined but not
> used [-Werror=unused-function]
hmm. it should work just fine without modules.
the bug is
On Tue, Jun 11, 2019 at 2:54 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
On Fri, Jun 14, 2019 at 4:10 PM Alexei Starovoitov wrote:
>
> Since commit 177366bf7ceb the %rbp stopped pointing to %rbp of the
> previous stack frame. That broke frame pointer based stack unwinding.
> This commit is a partial revert of it.
> Note that the location of tail_ca
On Fri, Jun 14, 2019 at 3:36 PM Daniel Borkmann wrote:
> >
> >> Force the minimum number of locks to two.
> >>
> >> Signed-off-by: Arthur Fabre
> >> Fixes: 6ac99e8f23d4 ("bpf: Introduce bpf sk local storage")
>
> The offending commit is already in Linus tree hence if so bpf tree. Arthur,
>
On Fri, Jun 14, 2019 at 9:27 PM Josh Poimboeuf wrote:
>
> On Fri, Jun 14, 2019 at 05:02:36PM -0700, Alexei Starovoitov wrote:
> > On Fri, Jun 14, 2019 at 4:54 PM Josh Poimboeuf wrote:
> > > The previous patch you posted has my patch description, push/pop and
> > > c
On Fri, Jun 14, 2019 at 5:02 PM Josh Poimboeuf wrote:
>
> On Fri, Jun 14, 2019 at 04:30:15PM -0700, Alexei Starovoitov wrote:
> > On Fri, Jun 14, 2019 at 4:17 PM Josh Poimboeuf wrote:
> > >
> > > On Fri, Jun 14, 2019 at 02:22:59PM -0700, Alexei Starovoitov wrote
On Fri, Jun 14, 2019 at 4:54 PM Josh Poimboeuf wrote:
>
> On Fri, Jun 14, 2019 at 04:23:41PM -0700, Alexei Starovoitov wrote:
> > On Fri, Jun 14, 2019 at 4:13 PM Josh Poimboeuf wrote:
> > >
> > > On Fri, Jun 14, 2019 at 02:27:30PM -0700, Alexei Starovoitov wrote
On Fri, Jun 14, 2019 at 4:17 PM Josh Poimboeuf wrote:
>
> On Fri, Jun 14, 2019 at 02:22:59PM -0700, Alexei Starovoitov wrote:
> > On Fri, Jun 14, 2019 at 2:19 PM Josh Poimboeuf wrote:
> > > > > > >
> > > > > > > +#define JUMP_TABLE_SYM_PREFI
On Fri, Jun 14, 2019 at 4:13 PM Josh Poimboeuf wrote:
>
> On Fri, Jun 14, 2019 at 02:27:30PM -0700, Alexei Starovoitov wrote:
> > On Fri, Jun 14, 2019 at 2:19 PM Josh Poimboeuf wrote:
> > >
> > > On Fri, Jun 14, 2019 at 02:05:56PM -0700, Alexei Starovoitov
with tail calls.
Fixes: 177366bf7ceb ("bpf: change x86 JITed program stack layout")
Signed-off-by: Alexei Starovoitov
---
arch/x86/net/bpf_jit_comp.c | 74 +++--
1 file changed, 21 insertions(+), 53 deletions(-)
diff --git a/arch/x86/net/bpf_jit_comp.c b/ar
On Fri, Jun 14, 2019 at 2:19 PM Josh Poimboeuf wrote:
>
> On Fri, Jun 14, 2019 at 02:05:56PM -0700, Alexei Starovoitov wrote:
> > Have you tested it ?
> > I really doubt, since in my test both CONFIG_UNWINDER_ORC and
> > CONFIG_UNWINDER_FRAME_POINTER failed to unwin
On Fri, Jun 14, 2019 at 2:19 PM Josh Poimboeuf wrote:
> > > > >
> > > > > +#define JUMP_TABLE_SYM_PREFIX "jump_table."
> > > >
> > > > since external tool will be looking at it should it be named
> > > > "bpf_jump_table." to avoid potential name conflicts?
> > > > Or even more unique name?
> > >
On Fri, Jun 14, 2019 at 2:07 PM Josh Poimboeuf wrote:
>
> On Fri, Jun 14, 2019 at 01:58:42PM -0700, Alexei Starovoitov wrote:
> > On Fri, Jun 14, 2019 at 12:56:41PM -0500, Josh Poimboeuf wrote:
> > > Objtool currently ignores ___bpf_prog_run() because it doesn't
> >
is much simple patch that I mentioned in the email yesterday,
but you failed to listen instead of focusing on perceived 'code readability'.
It makes one proper frame and both frame and orc unwinders are happy.
>From 442d91571a7f7f92a5cd3bd4a1b139390befbee3 Mon Sep 17 00:00:00 2001
From: Al
On Fri, Jun 14, 2019 at 12:56:41PM -0500, Josh Poimboeuf wrote:
> Objtool currently ignores ___bpf_prog_run() because it doesn't
> understand the jump table. This results in the ORC unwinder not being
> able to unwind through non-JIT BPF code.
>
> Luckily, the BPF jump table resembles a GCC
On Fri, Jun 14, 2019 at 12:56:40PM -0500, Josh Poimboeuf wrote:
> From: Song Liu
>
> The stacktrace_map_raw_tp BPF selftest is failing because the RIP saved
> by perf_arch_fetch_caller_regs() isn't getting saved by
> perf_callchain_kernel().
>
> This was broken by the following commit:
>
>
On 6/14/19 7:52 AM, Tejun Heo wrote:
> Hello, Quentin.
>
> On Fri, Jun 14, 2019 at 12:32:09PM +0100, Quentin Monnet wrote:
>> Please make sure to update the documentation and bash
>> completion when adding the new type to bpftool. You
>> probably want something like the diff below.
>
> Thank you
On Fri, Jun 14, 2019 at 6:34 AM Josh Poimboeuf wrote:
>
> On Thu, Jun 13, 2019 at 11:00:09PM -0700, Alexei Starovoitov wrote:
> > > + if (src_reg == BPF_REG_FP) {
> > > + /*
> > > +* If the value was copied from RBP (real frame poin
On Fri, Jun 14, 2019 at 12:41 AM Peter Zijlstra wrote:
>
> On Thu, Jun 13, 2019 at 11:00:09PM -0700, Alexei Starovoitov wrote:
>
> > There is something wrong with
> > commit d15d356887e7 ("perf/x86: Make perf callchains work without
> > CONFIG_FRAME_POINTER"
301 - 400 of 4150 matches
Mail list logo
