On Fri, Jun 14, 2019 at 1:11 AM Peter Zijlstra wrote:
>
> On Fri, Jun 14, 2019 at 12:35:38AM -0700, Alexei Starovoitov wrote:
> > On Fri, Jun 14, 2019 at 09:08:52AM +0200, Peter Zijlstra wrote:
> > > On Thu, Jun 13, 2019 at 08:20:30PM -0500, Josh Poimboeuf wrote:
> &g
On Fri, Jun 14, 2019 at 09:08:52AM +0200, Peter Zijlstra wrote:
> On Thu, Jun 13, 2019 at 08:20:30PM -0500, Josh Poimboeuf wrote:
> > On Thu, Jun 13, 2019 at 01:57:11PM -0700, Alexei Starovoitov wrote:
>
> > > and to patches 8 and 9.
> >
> > Well, it's
On Thu, Jun 13, 2019 at 11:50:37PM -0500, Josh Poimboeuf wrote:
> On Thu, Jun 13, 2019 at 09:28:48PM -0500, Josh Poimboeuf wrote:
> > On Thu, Jun 13, 2019 at 08:58:48PM -0500, Josh Poimboeuf wrote:
> > > On Thu, Jun 13, 2019 at 06:42:45PM -0700, Alexei Starovoitov wrote:
>
On Thu, Jun 13, 2019 at 08:30:51PM -0500, Josh Poimboeuf wrote:
> On Thu, Jun 13, 2019 at 03:00:55PM -0700, Alexei Starovoitov wrote:
> > > @@ -392,8 +402,16 @@ bool unwind_next_frame(struct unwind_state *state)
> > >* calls and calls to noreturn functions.
> > >
On Thu, Jun 13, 2019 at 08:22:48PM -0500, Josh Poimboeuf wrote:
> On Thu, Jun 13, 2019 at 02:58:09PM -0700, Alexei Starovoitov wrote:
> > On Thu, Jun 13, 2019 at 08:21:03AM -0500, Josh Poimboeuf wrote:
> > > The BPF JIT code clobbers RBP. This breaks frame pointer convent
On Thu, Jun 13, 2019 at 08:20:30PM -0500, Josh Poimboeuf wrote:
> On Thu, Jun 13, 2019 at 01:57:11PM -0700, Alexei Starovoitov wrote:
> > On Thu, Jun 13, 2019 at 08:20:59AM -0500, Josh Poimboeuf wrote:
> > > Objtool currently ignores ___bpf_prog_run() because it doesn't
> &g
On Thu, Jun 13, 2019 at 5:52 PM Matt Mullins wrote:
>
> On Fri, 2019-06-14 at 00:47 +0200, Daniel Borkmann wrote:
> > On 06/12/2019 07:00 AM, Andrii Nakryiko wrote:
> > > On Tue, Jun 11, 2019 at 8:48 PM Matt Mullins wrote:
> > > >
> > > > BPF_PROG_TYPE_RAW_TRACEPOINTs can be executed nested on
On Thu, Jun 13, 2019 at 08:21:04AM -0500, Josh Poimboeuf wrote:
> The ORC unwinder can't unwind through BPF JIT generated code because
> there are no ORC entries associated with the code.
>
> If an ORC entry isn't available, try to fall back to frame pointers. If
> BPF and other generated code
On Thu, Jun 13, 2019 at 08:21:03AM -0500, Josh Poimboeuf wrote:
> The BPF JIT code clobbers RBP. This breaks frame pointer convention and
> thus prevents the FP unwinder from unwinding through JIT generated code.
>
> RBP is currently used as the BPF stack frame pointer register. The
> actual
On Thu, Jun 13, 2019 at 08:20:59AM -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 Mon, Jun 3, 2019 at 5:44 PM Daniel Borkmann wrote:
>
> On 06/04/2019 01:54 AM, Alexei Starovoitov wrote:
> > On Mon, Jun 3, 2019 at 4:48 PM Daniel Borkmann wrote:
> >> On 06/04/2019 01:27 AM, Alexei Starovoitov wrote:
> >>> On Mon, Jun 3, 20
On Mon, Jun 3, 2019 at 4:48 PM Daniel Borkmann wrote:
>
> On 06/04/2019 01:27 AM, Alexei Starovoitov wrote:
> > On Mon, Jun 3, 2019 at 3:59 PM Matt Mullins wrote:
> >>
> >> If these are invariably non-nested, I can easily keep bpf_misc_sd when
> >> I r
On Mon, Jun 3, 2019 at 3:59 PM Matt Mullins wrote:
>
> If these are invariably non-nested, I can easily keep bpf_misc_sd when
> I resubmit. There was no technical reason other than keeping the two
> codepaths as similar as possible.
>
> What resource gives you worry about doing this for the
On Fri, May 31, 2019 at 6:28 PM Song Liu wrote:
>
>
>
> > On May 31, 2019, at 3:37 PM, Matt Mullins wrote:
> >
> > It is possible that a BPF program can be called while another BPF
> > program is executing bpf_perf_event_output. This has been observed with
> > I/O completion occurring as a
On Fri, May 31, 2019 at 1:40 PM Palmer Dabbelt wrote:
>
> On Thu, 30 May 2019 15:29:22 PDT (-0700), luke.r.n...@gmail.com wrote:
> > In BPF, 32-bit ALU operations should zero-extend their results into
> > the 64-bit registers.
> >
> > The current BPF JIT on RISC-V emits incorrect instructions
On Thu, May 30, 2019 at 2:34 PM Song Liu wrote:
>
> On Wed, May 29, 2019 at 11:30 AM Michal Rostecki
> wrote:
> >
> > Before this change, function load_sk_storage_btf expected that
> > libbpf__probe_raw_btf was returning a BTF descriptor, but in fact it was
> > returning an information about
On Wed, May 29, 2019 at 6:04 PM Roman Gushchin wrote:
>
> During my work on memcg-based memory accounting for bpf maps
> I've done some cleanups and refactorings of the existing
> memlock rlimit-based code. It makes it more robust, unifies
> size to pages conversion, size checks and corresponding
On Wed, May 29, 2019 at 6:10 AM Tony Lu wrote:
>
> This series introduces two new tracepoints trace_udp_send and
> trace_udp_queue_rcv, and removes redundant new line from
> tcp_event_sk_skb.
Though I like new tracepoints this patch set gets a nack, since commit log
says nothing about use case.
On Sat, May 25, 2019 at 9:37 AM Roman Gushchin wrote:
>
> This patchset implements a cgroup bpf auto-detachment functionality:
> bpf programs are detached as soon as possible after removal of the
> cgroup, without waiting for the release of all associated resources.
>
> Patches 2 and 3 are
On Fri, May 24, 2019 at 12:59 PM Matteo Croce wrote:
>
> This commit adds ibumad to .gitignore which is
> currently ommited from the ignore file.
>
> Signed-off-by: Matteo Croce
Applied. Thanks
On Fri, May 24, 2019 at 4:52 PM Roman Gushchin wrote:
>
> This patchset implements a cgroup bpf auto-detachment functionality:
> bpf programs are detached as soon as possible after removal of the
> cgroup, without waiting for the release of all associated resources.
>
> Patches 2 and 3 are
On Thu, May 23, 2019 at 12:45:28PM -0700, Roman Gushchin wrote:
> This patchset implements a cgroup bpf auto-detachment functionality:
> bpf programs are detached as soon as possible after removal of the
> cgroup, without waiting for the release of all associated resources.
The idea looks great,
On Thu, May 23, 2019 at 9:52 AM Yonghong Song wrote:
>
>
>
> On 5/23/19 5:53 AM, Michal Rostecki wrote:
> > This series of patches move the commonly used bpf_printk macro to
> > bpf_helpers.h which is already included in all BPF programs which
> > defined that macro on their own.
> >
> > v1->v2:
On Thu, May 23, 2019 at 09:57:37PM -0400, Steven Rostedt wrote:
> On Thu, 23 May 2019 17:31:50 -0700
> Alexei Starovoitov wrote:
>
>
> > > Now from what I'm reading, it seams that the Dtrace layer may be
> > > abstracting out fields from the kernel. This is actual
On Thu, May 23, 2019 at 07:02:43PM -0400, Steven Rostedt wrote:
> On Thu, 23 May 2019 14:13:31 -0700
> Alexei Starovoitov wrote:
>
> > > In DTrace, people write scripts based on UAPI-style interfaces and they
> > > don't
> > > have to concern themselves wi
On Thu, May 23, 2019 at 01:46:10AM -0400, Kris Van Hees wrote:
>
> I think there is a difference between a solution and a good solution. Adding
> a lot of knowledge in the userspace component about how things are
> imeplemented
> at the kernel level makes for a more fragile infrastructure and
On Thu, May 23, 2019 at 01:16:08AM -0400, Kris Van Hees wrote:
> On Wed, May 22, 2019 at 01:16:25PM -0700, Alexei Starovoitov wrote:
> > On Wed, May 22, 2019 at 12:12:53AM -0400, Kris Van Hees wrote:
> > >
> > > Could you elaborate on why you believe my pat
On 5/22/19 11:07 AM, Josh Poimboeuf wrote:
> On Fri, May 17, 2019 at 04:15:39PM +0800, Kairui Song wrote:
>> On Fri, May 17, 2019 at 4:11 PM Peter Zijlstra wrote:
>>>
>>> On Fri, May 17, 2019 at 09:46:00AM +0200, Peter Zijlstra wrote:
On Thu, May 16, 2019 at 11:51:55PM +, Song Liu wrote:
On Wed, May 22, 2019 at 01:23:27AM -0400, Kris Van Hees wrote:
>
> Userspace aside, there are various features that are not currently available
> such as retrieving the ppid of the current task, and various other data items
> that relate to the current task that triggered a probe. There are ways
On Wed, May 22, 2019 at 12:12:53AM -0400, Kris Van Hees wrote:
>
> Could you elaborate on why you believe my patches are not adding generic
> features? I can certainly agree that the DTrace-specific portions are less
> generic (although they are certainly available for anyone to use), but I
>
On Wed, May 22, 2019 at 02:22:15PM -0400, Kris Van Hees wrote:
> On Wed, May 22, 2019 at 04:25:32PM +0200, Peter Zijlstra wrote:
> > On Tue, May 21, 2019 at 10:56:18AM -0700, Alexei Starovoitov wrote:
> >
> > > and no changes are necessary in kernel/events/ring_buffer.c
On 5/22/19 7:02 AM, Peter Zijlstra wrote:
>
>> If the unwinder could trace back through the bpf func call then there
>> will be no such problem.
>
> Why couldn't it trace back through the bpf stuff? And how can we fix
> that?
Most of the time there is no 'tracing through bpf stuff'.
bpf infra
On Tue, May 21, 2019 at 05:36:49PM -0400, Kris Van Hees wrote:
> On Tue, May 21, 2019 at 01:55:34PM -0700, Alexei Starovoitov wrote:
> > On Tue, May 21, 2019 at 02:41:37PM -0400, Kris Van Hees wrote:
> > > On Tue, May 21, 2019 at 10:56:18AM -0700, Alexei Starovoitov wrote:
>
On Tue, May 21, 2019 at 05:36:18PM -0400, Steven Rostedt wrote:
> On Tue, 21 May 2019 13:55:34 -0700
> Alexei Starovoitov wrote:
>
> > > The reasons for these patches is because I cannot do the same with the
> > > existing
> > > implementation. Yes, I can d
On Tue, May 21, 2019 at 04:48:48PM -0400, Kris Van Hees wrote:
> As suggested, I resent the patch set as replies to the cover letter post
> to support threaded access to the patches.
As explained in the other email it's a Nack.
Please stop this email spam.
On Tue, May 21, 2019 at 02:41:37PM -0400, Kris Van Hees wrote:
> On Tue, May 21, 2019 at 10:56:18AM -0700, Alexei Starovoitov wrote:
> > On Mon, May 20, 2019 at 11:47:00PM +, Kris Van Hees wrote:
> > >
> > > 2. bpf: add BPF_PROG_TYPE_DTRACE
>
On Mon, May 20, 2019 at 11:47:00PM +, Kris Van Hees wrote:
>
> 2. bpf: add BPF_PROG_TYPE_DTRACE
>
> This patch adds BPF_PROG_TYPE_DTRACE as a new BPF program type, without
> actually providing an implementation. The actual implementation is
> added in patch 4 (see
On 5/17/19 11:40 AM, Song Liu wrote:
> +Alexei, Daniel, and bpf
>
>> On May 17, 2019, at 2:10 AM, Peter Zijlstra wrote:
>>
>> On Fri, May 17, 2019 at 04:15:39PM +0800, Kairui Song wrote:
>>> Hi, I think the actual problem is that bpf_get_stackid_tp (and maybe
>>> some other bfp functions) is now
On Thu, May 16, 2019 at 4:21 AM Michal Rostecki wrote:
>
> This series of patches move the commonly used bpf_printk macro to
> bpf_helpers.h which is already included in all BPF programs which
> defined that macro on their own.
makes sense, but it needs to wait until bpf-next reopens.
On Wed, Apr 24, 2019 at 5:52 AM Peter Zijlstra wrote:
>
> On Wed, Apr 24, 2019 at 08:42:40AM -0400, Kairui Song wrote:
>
> > Sure, the updated comments looks much better. Will the maintainer
> > squash the comment update or should I send a V5?
>
> I've squashed it, I've just not gotten around to
lock()/rcu_read_unlock() from there if we're disabling
> preemption anyway.
>
> ---
> Subject: bpf: Fix preempt_enable_no_resched() abuse
>
> Unless the very next line is schedule(), or implies it, one must not use
> preempt_enable_no_resched(). It can cause a preemption
On Thu, Apr 18, 2019 at 11:06 AM Wang YanQing wrote:
>
> I meet below compile errors:
> "
> In file included from test_tcpnotify_kern.c:12:
> /usr/include/netinet/in.h:101:5: error: expected identifier
> IPPROTO_HOPOPTS = 0, /* IPv6 Hop-by-Hop options. */
> ^
>
On Tue, Apr 16, 2019 at 10:55 AM Al Viro wrote:
>
> From: Al Viro
>
> Signed-off-by: Al Viro
Acked-by: Alexei Starovoitov
> ---
> kernel/bpf/inode.c | 10 ++
> 1 file changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/kernel/bpf/inode.c b
On Tue, Apr 16, 2019 at 07:30:07PM +0800, Kairui Song wrote:
> On Tue, Apr 16, 2019 at 12:59 AM Josh Poimboeuf wrote:
> >
> > On Mon, Apr 15, 2019 at 05:36:22PM +0200, Peter Zijlstra wrote:
> > >
> > > I'll mostly defer to Josh on unwinding, but a few comments below.
> > >
> > > On Tue, Apr 09,
On Sat, Apr 13, 2019 at 10:02:42PM +0100, Al Viro wrote:
> What's the point of using fget_raw(), if you do
> _not_ accept O_PATH descriptors? That should be fget()...
I think you're talking about commit e03e7ee34fdd ("perf/bpf: Convert
perf_event_array to use struct file")
I don't really
On Mon, Mar 25, 2019 at 11:37:32PM +, Al Viro wrote:
>
> For debugfs it's clearly "use default ->evict_inode(), have explicit
> ->destroy_inode() using free_inode_nonrcu()" - there we have nothing
> else done in ->evict_inode() and kfree is obviously safe in softirq.
> I'll post that (or push
On Thu, Mar 14, 2019 at 4:00 AM Paolo Bonzini wrote:
>
> On 14/03/19 00:44, Andrea Arcangeli wrote:
> > Then I thought we can add a tristate so an open of /dev/kvm would also
> > allow the syscall to make things more user friendly because
> > unprivileged containers ideally should have writable
On Wed, Feb 27, 2019 at 5:31 PM Stephen Rothwell wrote:
>
> Hi all,
>
> After merging the bpf-next tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> kernel/sysctl.c:1238:13: error: 'sysctl_bpf_stats_enabled' undeclared here
> (not in a function); did you mean
On Wed, Feb 27, 2019 at 04:52:16PM +, Martin Lau wrote:
> On Wed, Feb 27, 2019 at 10:36:25PM +0800, zerons wrote:
> > In bpf/syscall.c, map_create() first set map->usercnt to 1, a file
> > descriptor is
> > supposed to return to userspace. When bpf_map_new_fd() fails, drop the
> > refcount.
On Wed, Feb 27, 2019 at 11:42:15PM +0900, Masami Hiramatsu wrote:
>
> For perf-probe, we can add some attribute for each argument
> which indicate that the variable in user space. But still
> we can not decide it automatically by DWARF since __user attribute
> is not transrated to DWARF
On Fri, Feb 22, 2019 at 04:08:59PM -0800, Linus Torvalds wrote:
> On Fri, Feb 22, 2019 at 3:56 PM Alexei Starovoitov
> wrote:
> >
> > It will preserve existing bpf_probe_read() behavior on x86.
>
> ... but that's the worst possible situation.
>
> It appears
On Fri, Feb 22, 2019 at 03:59:30PM -0800, Andy Lutomirski wrote:
> >
> > A relatively simple approach might be to teach BPF not to run kprobe
> > programs and such in contexts where current->mm isn't the active mm?
> > Maybe using nmi_uaccess_okay(), or something like that? It looks like
> >
On Fri, Feb 22, 2019 at 03:16:35PM -0800, Linus Torvalds wrote:
>
> So a kernel pointer value of 0x12345678 could be a value kernel
> pointer pointing to some random kmalloc'ed kernel memory, and a user
> pointer value of 0x12345678 could be a valid _user_ pointer pointing
> to some user mapping.
On Fri, Feb 22, 2019 at 01:59:10PM -0800, Linus Torvalds wrote:
> On Fri, Feb 22, 2019 at 1:38 PM David Miller wrote:
> >
> > Don't be surprised if we see more separation like this in the future too.
>
> Yes, with the whole meltdown fiasco, there's actually more pressure to
> add more support
On Fri, Feb 22, 2019 at 02:30:26PM -0500, Steven Rostedt wrote:
> On Fri, 22 Feb 2019 11:27:05 -0800
> Alexei Starovoitov wrote:
>
> > On Fri, Feb 22, 2019 at 09:43:14AM -0800, Linus Torvalds wrote:
> > >
> > > Then we should still probably fix up "__probe_
On Fri, Feb 22, 2019 at 09:43:14AM -0800, Linus Torvalds wrote:
>
> Then we should still probably fix up "__probe_kernel_read()" to not
> allow user accesses. The easiest way to do that is actually likely to
> use the "unsafe_get_user()" functions *without* doing a
> uaccess_begin(), which will
On Tue, Feb 19, 2019 at 4:37 PM Stephen Rothwell wrote:
>
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
> tools/testing/selftests/bpf/test_progs.c
>
> between commit:
>
> f6be4d16039b ("selftests/bpf: make sure signal interrupts
> BPF_PROG_TEST_RUN")
Ouch.
On Tue, Feb 19, 2019 at 01:14:11PM +0900, Masahiro Yamada wrote:
>
> I was able to compile it in-tree
> but it makes the incremental build extremely slow.
>
> (Here, the incremental build means
> "make" without changing any code after the full build.)
>
> Before this patch, "make -j8" took 11
On Mon, Feb 11, 2019 at 09:35:59AM -0500, Joel Fernandes (Google) wrote:
> Introduce in-kernel headers and other artifacts which are made available
> as an archive through proc (/proc/kheaders.txz file). This archive makes
> it possible to build kernel modules, run eBPF programs, and other
>
On Tue, Feb 12, 2019 at 6:15 PM Eric Dumazet wrote:
>
> Do not add more debugging stuff unless you can demonstrate
> they actually allowed you to find a real bug and that you sent a
> public fix for it.
>
> Just adding "cool stuff" in TCP stack does not please me, it is only
> more complexity for
On Mon, Feb 11, 2019 at 09:54:01AM +0200, Adrian Hunter wrote:
>
> Which is not really a real use-case.
..
> > perf analysis with PT becomes inaccurate and main goal
> > of retaining accurate instruction info is not achieved.
>
> For the majority of real use-cases, yes it is.
In our fleet not a
On Thu, Feb 07, 2019 at 01:19:01PM +0200, Adrian Hunter wrote:
> Subject to memory pressure and other limits, retain executable code, such
> as JIT-compiled bpf, in memory instead of freeing it immediately it is no
> longer needed for execution.
>
> While perf is primarily aimed at statistical
On Thu, Jan 31, 2019 at 12:15:35PM +0900, Masahiro Yamada wrote:
> Currently, the header search paths -Itools/include and
> -Itools/include/uapi are not used. Let's drop the unused code.
>
> We can remove -I. too by fixing up one C file.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> Perhaps,
the kernel side update failed to remove the boiler
> plate. Do so now.
>
> Fixes: 907b22365115 ("tools: bpftool: dual license all files")
> Signed-off-by: Thomas Gleixner
> Cc: Jakub Kicinski
> Cc: Roman Gushchin
> Cc: YueHaibing
> Cc: Yonghong Song
> Cc: Stanis
| 2 +
> kernel/events/core.c| 120 ++++++++++++
> 6 files changed, 164 insertions(+), 2 deletions(-)
Acked-by: Alexei Starovoitov
The bpf bits are small comparing to perf bits, so it's probably
better to get the whole thing via tip tree in one go.
Splitting perf patches into perf tree also seems unnecessary.
Peter, Arnaldo, thoughts?
On Tue, Jan 08, 2019 at 05:41:37PM -0800, Tim Chen wrote:
> On 1/8/19 5:11 PM, Alexei Starovoitov wrote:
>
> >>
> >> Alexi,
> >>
> >> Do you have any suggestions on how to rewrite this two paragraphs? You
> >> are probably the best person to
On Tue, Jan 08, 2019 at 01:12:45PM -0800, Tim Chen wrote:
> On 12/23/18 3:11 PM, Alexei Starovoitov wrote:
> > On Fri, Dec 21, 2018 at 09:44:44AM -0800, Tim Chen wrote:
> >> +
> >> +4. Kernel sandbox attacking kernel
> >> +^^
On 1/8/19 10:41 AM, Peter Zijlstra wrote:
> On Thu, Dec 20, 2018 at 10:29:00AM -0800, Song Liu wrote:
>> @@ -986,9 +987,35 @@ enum perf_event_type {
>> */
>> PERF_RECORD_KSYMBOL = 17,
>>
>> +/*
>> + * Record bpf events:
>> + * enum perf_bpf_event_type
On 1/8/19 12:29 PM, Peter Zijlstra wrote:
> On Thu, Dec 20, 2018 at 10:29:00AM -0800, Song Liu wrote:
>> The following example shows kernel symbols for a BPF program with 7
>> sub programs:
>>
>> a0257cf9 t bpf_prog_b07ccb89267cf242_F
>> a02592e1 t
On Tue, Dec 25, 2018 at 01:17:10AM -0600, Kangjie Lu wrote:
> check_reg_arg() may fail. This fix inserts checks for its return value.
> If check_reg_arg() fails, issues an error message.
>
> Signed-off-by: Kangjie Lu
> ---
> kernel/bpf/verifier.c | 15 ---
> 1 file changed, 12
On Fri, Dec 21, 2018 at 09:44:44AM -0800, Tim Chen wrote:
> +
> +4. Kernel sandbox attacking kernel
> +^^
> +
> +The kernel has support for running user-supplied programs within the
> +kernel. Specific rules (such as bounds checking) are enforced on these
>
On Sat, Dec 22, 2018 at 11:03:31PM -0600, Gustavo A. R. Silva wrote:
> Alexei,
>
> On 12/22/18 10:12 PM, Alexei Starovoitov wrote:
> > On Sat, Dec 22, 2018 at 09:37:02PM -0600, Gustavo A. R. Silva wrote:
> > >
> > > Can't we have the case in which
On Sat, Dec 22, 2018 at 09:37:02PM -0600, Gustavo A. R. Silva wrote:
>
> Can't we have the case in which the code can be "trained" to read
> perfectly valid values for prog->len for quite a while, making the
> microcode come into place and speculate about:
>
> 1013 if (flen == 0 || flen
On Sat, Dec 22, 2018 at 08:53:40PM -0600, Gustavo A. R. Silva wrote:
> Hi,
>
> On 12/22/18 8:40 PM, David Miller wrote:
> > From: Alexei Starovoitov
> > Date: Sat, 22 Dec 2018 15:59:54 -0800
> >
> > > On Sat, Dec 22, 2018 at 03:07:22PM -0800, David Mille
On Sat, Dec 22, 2018 at 03:07:22PM -0800, David Miller wrote:
> From: "Gustavo A. R. Silva"
> Date: Fri, 21 Dec 2018 14:49:01 -0600
>
> > flen is indirectly controlled by user-space, hence leading to
> > a potential exploitation of the Spectre variant 1 vulnerability.
> >
> > This issue was
On Thu, Dec 20, 2018 at 01:45:56PM -0600, Kangjie Lu wrote:
> check_reg_arg() may fail and not mark correct data in "env". This
> fix inserts a check that ensures check_reg_arg() is successful, and
> if it is not, the fix stops further operations and returns an error
> upstream.
>
>
On Wed, Dec 12, 2018 at 04:42:37PM -0800, Matt Mullins wrote:
> Distributions build drivers as modules, including network and filesystem
> drivers which export numerous tracepoints. This enables
> bpf(BPF_RAW_TRACEPOINT_OPEN) to attach to those tracepoints.
>
> Signed-off-by: Matt Mullins
> ---
On Thu, Dec 13, 2018 at 04:37:28PM +1100, Stephen Rothwell wrote:
> Hi Alexei,
>
> On Wed, 12 Dec 2018 20:33:41 -0800 Alexei Starovoitov
> wrote:
> >
> > If Stephen's scripts can recognize SOB anywhere in the log then
> > --signoff can theoretically solve it.
On Wed, Dec 12, 2018 at 04:45:26PM -0800, David Miller wrote:
> From: Alexei Starovoitov
> Date: Wed, 12 Dec 2018 15:39:10 -0800
>
> > But this approach doesn't scale.
> > We do rebase our trees when we need to fixup or drop patches and
> > at any give
On Wed, Dec 12, 2018 at 3:45 PM Bart Van Assche wrote:
>
> Are you aware of Linus' opinion about rebasing? If not, please have a look
> at https://lkml.org/lkml/2016/3/26/71 or https://lwn.net/Articles/328436/.
very much aware.
above is not applicable to this use case.
On Thu, Dec 13, 2018 at 09:48:20AM +1100, Stephen Rothwell wrote:
> Hi Alexei,
>
> On Wed, 12 Dec 2018 12:53:11 -0800 Alexei Starovoitov
> wrote:
> >
> > On Thu, Dec 13, 2018 at 07:32:45AM +1100, Stephen Rothwell wrote:
> > > Hi all,
> > >
> > &
On Thu, Dec 13, 2018 at 07:32:45AM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Commits
>
> 3bdc28aa2340 ("selftests/bpf: add btf annotations for cgroup_local_storage
> maps")
> 1dfd1959fed4 ("bpf: add bpffs pretty print for cgroup local storage maps")
> 3adc62d9a5be ("bpf: pass struct
On Wed, Nov 28, 2018 at 01:51:42PM -0500, Aaron Conole wrote:
> Alexei Starovoitov writes:
>
> > On Tue, Nov 27, 2018 at 09:24:05AM -0500, Aaron Conole wrote:
> >>
> >> 1. Introduce flowmap again, this time, basically having it close to a
> >>
On Wed, Nov 28, 2018 at 01:51:42PM -0500, Aaron Conole wrote:
> Alexei Starovoitov writes:
>
> > On Tue, Nov 27, 2018 at 09:24:05AM -0500, Aaron Conole wrote:
> >>
> >> 1. Introduce flowmap again, this time, basically having it close to a
> >>
On Fri, Oct 19, 2018 at 1:22 AM Peter Zijlstra wrote:
>
> On Thu, Oct 18, 2018 at 10:00:53PM -0700, Alexei Starovoitov wrote:
> > >
> > > >
> > > > Another example is __BPF_PROG_RUN_ARRAY(), which also uses
> > > > preempt_enable_no_resched().
On Fri, Oct 19, 2018 at 1:22 AM Peter Zijlstra wrote:
>
> On Thu, Oct 18, 2018 at 10:00:53PM -0700, Alexei Starovoitov wrote:
> > >
> > > >
> > > > Another example is __BPF_PROG_RUN_ARRAY(), which also uses
> > > > preempt_enable_no_resched().
>
> >
> > Another example is __BPF_PROG_RUN_ARRAY(), which also uses
> > preempt_enable_no_resched().
>
> Alexei, I think this code is just wrong.
why 'just wrong' ?
> Do you know why it uses
> preempt_enable_no_resched()?
dont recall precisely.
we could be preemptable at the point where
>
> >
> > Another example is __BPF_PROG_RUN_ARRAY(), which also uses
> > preempt_enable_no_resched().
>
> Alexei, I think this code is just wrong.
why 'just wrong' ?
> Do you know why it uses
> preempt_enable_no_resched()?
dont recall precisely.
we could be preemptable at the point where
On Fri, Sep 28, 2018 at 11:37:26AM +0100, Roman Gushchin wrote:
> > > > > +
> > > > > + /* Let's check that bytes counter value is reasonable */
> > > > > + if (netcnt.bytes < packets * 500 || netcnt.bytes > packets *
> > > > > 1500) {
> > > >
> > > > since packet count is accurate why
On Fri, Sep 28, 2018 at 11:37:26AM +0100, Roman Gushchin wrote:
> > > > > +
> > > > > + /* Let's check that bytes counter value is reasonable */
> > > > > + if (netcnt.bytes < packets * 500 || netcnt.bytes > packets *
> > > > > 1500) {
> > > >
> > > > since packet count is accurate why
mpliance management.
>
> Cc: Alexei Starovoitov
ohh. did you get a reply from that address? ;)
> Cc: Daniel Borkmann
> Signed-off-by: Steven Rostedt (VMware)
Acked-by: Alexei Starovoitov
mpliance management.
>
> Cc: Alexei Starovoitov
ohh. did you get a reply from that address? ;)
> Cc: Daniel Borkmann
> Signed-off-by: Steven Rostedt (VMware)
Acked-by: Alexei Starovoitov
On Fri, Aug 10, 2018 at 5:57 AM Jonathan Corbet wrote:
>
> The objective actually is to have SPDX tags in all files in the kernel.
> That includes documentation, even though people, as always, care less
> about the docs than they do the code.
right, but let's do that as a separate patch set.
In
On Fri, Aug 10, 2018 at 5:57 AM Jonathan Corbet wrote:
>
> The objective actually is to have SPDX tags in all files in the kernel.
> That includes documentation, even though people, as always, care less
> about the docs than they do the code.
right, but let's do that as a separate patch set.
In
On Thu, Jun 07, 2018 at 02:19:16PM +0200, Dmitry Vyukov wrote:
> On Mon, Jun 4, 2018 at 10:21 PM, syzbot
> wrote:
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit:69b450789136 Merge branch 'misc-BPF-improvements'
> > git tree: bpf-next
> > console output:
On Thu, Jun 07, 2018 at 02:19:16PM +0200, Dmitry Vyukov wrote:
> On Mon, Jun 4, 2018 at 10:21 PM, syzbot
> wrote:
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit:69b450789136 Merge branch 'misc-BPF-improvements'
> > git tree: bpf-next
> > console output:
On Fri, May 18, 2018 at 03:07:29PM +0100, Sean Young wrote:
> Add support for BPF_PROG_LIRC_MODE2. This type of BPF program can call
> rc_keydown() to reported decoded IR scancodes, or rc_repeat() to report
> that the last key should be repeated.
>
> The bpf program can be attached to using the
On Fri, May 18, 2018 at 03:07:29PM +0100, Sean Young wrote:
> Add support for BPF_PROG_LIRC_MODE2. This type of BPF program can call
> rc_keydown() to reported decoded IR scancodes, or rc_repeat() to report
> that the last key should be repeated.
>
> The bpf program can be attached to using the
On Fri, May 25, 2018 at 06:50:09PM +0200, Eugene Syromiatnikov wrote:
> On Thu, May 24, 2018 at 04:34:51PM -0700, Alexei Starovoitov wrote:
> > On Thu, May 24, 2018 at 09:41:08AM +0200, Jesper Dangaard Brouer wrote:
> > > On Wed, 23 May 2018 15:02:45 -0700
> > > Alexei S
On Fri, May 25, 2018 at 06:50:09PM +0200, Eugene Syromiatnikov wrote:
> On Thu, May 24, 2018 at 04:34:51PM -0700, Alexei Starovoitov wrote:
> > On Thu, May 24, 2018 at 09:41:08AM +0200, Jesper Dangaard Brouer wrote:
> > > On Wed, 23 May 2018 15:02:45 -0700
> > >
401 - 500 of 4150 matches
Mail list logo
