On Thu, Jan 31, 2019 at 10:47:50AM -0800, Alexei Starovoitov wrote:
> On Thu, Jan 31, 2019 at 06:01:56AM -0800, Paul E. McKenney wrote:
> > On Wed, Jan 30, 2019 at 02:57:43PM -0800, Alexei Starovoitov wrote:
> > > On Wed, Jan 30, 2019 at 01:05:36PM -0800, Paul E. McKenney wrote:
> > > > On Wed, Jan
On Thu, Jan 31, 2019 at 06:01:56AM -0800, Paul E. McKenney wrote:
> On Wed, Jan 30, 2019 at 02:57:43PM -0800, Alexei Starovoitov wrote:
> > On Wed, Jan 30, 2019 at 01:05:36PM -0800, Paul E. McKenney wrote:
> > > On Wed, Jan 30, 2019 at 11:51:14AM -0800, Alexei Starovoitov wrote:
> > > > On Wed, Jan
On Wed, Jan 30, 2019 at 02:57:43PM -0800, Alexei Starovoitov wrote:
> On Wed, Jan 30, 2019 at 01:05:36PM -0800, Paul E. McKenney wrote:
> > On Wed, Jan 30, 2019 at 11:51:14AM -0800, Alexei Starovoitov wrote:
> > > On Wed, Jan 30, 2019 at 10:36:18AM -0800, Paul E. McKenney wrote:
> > > > On Wed, Jan
On Wed, Jan 30, 2019 at 01:05:36PM -0800, Paul E. McKenney wrote:
> On Wed, Jan 30, 2019 at 11:51:14AM -0800, Alexei Starovoitov wrote:
> > On Wed, Jan 30, 2019 at 10:36:18AM -0800, Paul E. McKenney wrote:
> > > On Wed, Jan 30, 2019 at 06:11:00PM +, Will Deacon wrote:
> > > > Hi Alexei,
> > > >
On Wed, Jan 30, 2019 at 11:51:14AM -0800, Alexei Starovoitov wrote:
> On Wed, Jan 30, 2019 at 10:36:18AM -0800, Paul E. McKenney wrote:
> > On Wed, Jan 30, 2019 at 06:11:00PM +, Will Deacon wrote:
> > > Hi Alexei,
> > >
> > > On Mon, Jan 28, 2019 at 01:56:24PM -0800, Alexei Starovoitov wrote:
On Wed, Jan 30, 2019 at 10:36:18AM -0800, Paul E. McKenney wrote:
> On Wed, Jan 30, 2019 at 06:11:00PM +, Will Deacon wrote:
> > Hi Alexei,
> >
> > On Mon, Jan 28, 2019 at 01:56:24PM -0800, Alexei Starovoitov wrote:
> > > On Mon, Jan 28, 2019 at 10:24:08AM +0100, Peter Zijlstra wrote:
> > > >
On Wed, Jan 30, 2019 at 06:11:00PM +, Will Deacon wrote:
> Assuming that a desirable property of an eBPF program is portability between
> CPU architectures, then you're effectively forcing the programmer to "assume
that is fundamental misunderstanding that being thrown in this thread.
bpf is n
On Wed, Jan 30, 2019 at 09:58:50AM +0100, Peter Zijlstra wrote:
> On Tue, Jan 29, 2019 at 06:32:13PM -0800, Alexei Starovoitov wrote:
> > On Tue, Jan 29, 2019 at 10:16:54AM +0100, Peter Zijlstra wrote:
> > > On Mon, Jan 28, 2019 at 01:56:24PM -0800, Alexei Starovoitov wrote:
> > > > On Mon, Jan 28,
On Wed, Jan 30, 2019 at 06:11:00PM +, Will Deacon wrote:
> Hi Alexei,
>
> On Mon, Jan 28, 2019 at 01:56:24PM -0800, Alexei Starovoitov wrote:
> > On Mon, Jan 28, 2019 at 10:24:08AM +0100, Peter Zijlstra wrote:
> > > On Fri, Jan 25, 2019 at 04:17:26PM -0800, Alexei Starovoitov wrote:
> > > > Wh
Hi Alexei,
On Mon, Jan 28, 2019 at 01:56:24PM -0800, Alexei Starovoitov wrote:
> On Mon, Jan 28, 2019 at 10:24:08AM +0100, Peter Zijlstra wrote:
> > On Fri, Jan 25, 2019 at 04:17:26PM -0800, Alexei Starovoitov wrote:
> > > What I want to avoid is to define the whole execution ordering model
> > >
On Tue, Jan 29, 2019 at 06:32:13PM -0800, Alexei Starovoitov wrote:
> On Tue, Jan 29, 2019 at 10:16:54AM +0100, Peter Zijlstra wrote:
> > On Mon, Jan 28, 2019 at 01:56:24PM -0800, Alexei Starovoitov wrote:
> > > On Mon, Jan 28, 2019 at 10:24:08AM +0100, Peter Zijlstra wrote:
> >
> > > > Ah, but th
On Tue, Jan 29, 2019 at 10:16:54AM +0100, Peter Zijlstra wrote:
> On Mon, Jan 28, 2019 at 01:56:24PM -0800, Alexei Starovoitov wrote:
> > On Mon, Jan 28, 2019 at 10:24:08AM +0100, Peter Zijlstra wrote:
>
> > > Ah, but the loop won't be in the BPF program itself. The BPF program
> > > would only ha
On Tue, Jan 29, 2019 at 09:59:03AM +0100, Peter Zijlstra wrote:
> On Mon, Jan 28, 2019 at 01:37:12PM -0800, Alexei Starovoitov wrote:
> > On Mon, Jan 28, 2019 at 09:43:10AM +0100, Peter Zijlstra wrote:
>
> > > Isn't that still broken? AFAIU networking progs can happen in task
> > > context (TX) an
On Mon, Jan 28, 2019 at 01:56:24PM -0800, Alexei Starovoitov wrote:
> On Mon, Jan 28, 2019 at 10:24:08AM +0100, Peter Zijlstra wrote:
> > Ah, but the loop won't be in the BPF program itself. The BPF program
> > would only have had the BPF_SPIN_LOCK instruction, the JIT them emits
> > code similar
On Mon, Jan 28, 2019 at 01:37:12PM -0800, Alexei Starovoitov wrote:
> On Mon, Jan 28, 2019 at 09:43:10AM +0100, Peter Zijlstra wrote:
> > Isn't that still broken? AFAIU networking progs can happen in task
> > context (TX) and SoftIRQ context (RX), which can nest.
>
> Sure. sendmsg side of network
On Mon, Jan 28, 2019 at 10:24:08AM +0100, Peter Zijlstra wrote:
> On Fri, Jan 25, 2019 at 04:17:26PM -0800, Alexei Starovoitov wrote:
> > On Fri, Jan 25, 2019 at 11:23:12AM +0100, Peter Zijlstra wrote:
> > > On Thu, Jan 24, 2019 at 03:58:59PM -0800, Alexei Starovoitov wrote:
> > > > On Thu, Jan 24,
On Mon, Jan 28, 2019 at 09:43:10AM +0100, Peter Zijlstra wrote:
> On Fri, Jan 25, 2019 at 03:42:43PM -0800, Alexei Starovoitov wrote:
> > On Fri, Jan 25, 2019 at 10:10:57AM +0100, Peter Zijlstra wrote:
>
> > > What about the progs that run from SoftIRQ ? Since that bpf_prog_active
> > > thing isn'
On Mon, Jan 28, 2019 at 09:35:08AM +0100, Peter Zijlstra wrote:
> On Mon, Jan 28, 2019 at 09:31:23AM +0100, Peter Zijlstra wrote:
> > On Fri, Jan 25, 2019 at 03:42:43PM -0800, Alexei Starovoitov wrote:
> > > On Fri, Jan 25, 2019 at 10:10:57AM +0100, Peter Zijlstra wrote:
> > > > On Thu, Jan 24, 201
On Fri, Jan 25, 2019 at 04:17:26PM -0800, Alexei Starovoitov wrote:
> On Fri, Jan 25, 2019 at 11:23:12AM +0100, Peter Zijlstra wrote:
> > On Thu, Jan 24, 2019 at 03:58:59PM -0800, Alexei Starovoitov wrote:
> > > On Thu, Jan 24, 2019 at 07:01:09PM +0100, Peter Zijlstra wrote:
> >
> > > > And this w
On Fri, Jan 25, 2019 at 03:42:43PM -0800, Alexei Starovoitov wrote:
> On Fri, Jan 25, 2019 at 10:10:57AM +0100, Peter Zijlstra wrote:
> > What about the progs that run from SoftIRQ ? Since that bpf_prog_active
> > thing isn't inside BPF_PROG_RUN() what is to stop say:
> >
> >reuseport_select_
On Mon, Jan 28, 2019 at 09:31:23AM +0100, Peter Zijlstra wrote:
> On Fri, Jan 25, 2019 at 03:42:43PM -0800, Alexei Starovoitov wrote:
> > On Fri, Jan 25, 2019 at 10:10:57AM +0100, Peter Zijlstra wrote:
> > > On Thu, Jan 24, 2019 at 03:58:59PM -0800, Alexei Starovoitov wrote:
>
> > > > nmi checks
On Fri, Jan 25, 2019 at 03:42:43PM -0800, Alexei Starovoitov wrote:
> On Fri, Jan 25, 2019 at 10:10:57AM +0100, Peter Zijlstra wrote:
> > On Thu, Jan 24, 2019 at 03:58:59PM -0800, Alexei Starovoitov wrote:
> > > nmi checks for bpf_prog_active==0. See bpf_overflow_handler.
> > yuck yuck yuck.. Th
On Fri, Jan 25, 2019 at 03:42:43PM -0800, Alexei Starovoitov wrote:
> On Fri, Jan 25, 2019 at 10:10:57AM +0100, Peter Zijlstra wrote:
> > Do we want something like (the completely untested) below to avoid
> > having to manually audit this over and over?
> >
> > ---
> > include/linux/filter.h |
On Sat, Jan 26, 2019 at 1:43 AM Jann Horn wrote:
> On Sat, Jan 26, 2019 at 12:44 AM Alexei Starovoitov
> wrote:
> >
> > On Fri, Jan 25, 2019 at 02:51:12PM -0800, Paul E. McKenney wrote:
> > > > >
> > > > > So no more than (say) 100 milliseconds?
> > > >
> > > > Depends on RLIMIT_MEMLOCK and on ho
On Sat, Jan 26, 2019 at 12:44 AM Alexei Starovoitov
wrote:
>
> On Fri, Jan 25, 2019 at 02:51:12PM -0800, Paul E. McKenney wrote:
> > > >
> > > > So no more than (say) 100 milliseconds?
> > >
> > > Depends on RLIMIT_MEMLOCK and on how hard userspace is trying to make
> > > things slow, I guess - if
On Fri, Jan 25, 2019 at 11:23:12AM +0100, Peter Zijlstra wrote:
> On Thu, Jan 24, 2019 at 03:58:59PM -0800, Alexei Starovoitov wrote:
> > On Thu, Jan 24, 2019 at 07:01:09PM +0100, Peter Zijlstra wrote:
>
> > > And this would again be the moment where I go pester you about the BPF
> > > memory mode
On Fri, Jan 25, 2019 at 02:51:12PM -0800, Paul E. McKenney wrote:
> > >
> > > So no more than (say) 100 milliseconds?
> >
> > Depends on RLIMIT_MEMLOCK and on how hard userspace is trying to make
> > things slow, I guess - if userspace manages to create a hashtable,
> > with a few dozen megabytes
On Fri, Jan 25, 2019 at 10:10:57AM +0100, Peter Zijlstra wrote:
> On Thu, Jan 24, 2019 at 03:58:59PM -0800, Alexei Starovoitov wrote:
> > On Thu, Jan 24, 2019 at 07:01:09PM +0100, Peter Zijlstra wrote:
> > >
> > > Thanks for having kernel/locking people on Cc...
> > >
> > > On Wed, Jan 23, 2019 a
On Fri, Jan 25, 2019 at 05:18:12PM +0100, Jann Horn wrote:
> On Fri, Jan 25, 2019 at 5:12 AM Paul E. McKenney
> wrote:
> > On Fri, Jan 25, 2019 at 02:46:55AM +0100, Jann Horn wrote:
> > > On Fri, Jan 25, 2019 at 2:22 AM Paul E. McKenney
> > > wrote:
> > > > On Thu, Jan 24, 2019 at 04:05:16PM -0
On Fri, Jan 25, 2019 at 5:12 AM Paul E. McKenney wrote:
> On Fri, Jan 25, 2019 at 02:46:55AM +0100, Jann Horn wrote:
> > On Fri, Jan 25, 2019 at 2:22 AM Paul E. McKenney
> > wrote:
> > > On Thu, Jan 24, 2019 at 04:05:16PM -0800, Alexei Starovoitov wrote:
> > > > On Thu, Jan 24, 2019 at 03:42:32P
On Fri, Jan 25, 2019 at 04:47:20AM +, Alexei Starovoitov wrote:
> On 1/24/19 8:31 PM, Paul E. McKenney wrote:
> > On Fri, Jan 25, 2019 at 04:27:02AM +, Alexei Starovoitov wrote:
> >> On 1/24/19 6:38 PM, Alexei Starovoitov wrote:
> For programs created with CAP_SYS_ADMIN,
> things
On Thu, Jan 24, 2019 at 03:58:59PM -0800, Alexei Starovoitov wrote:
> On Thu, Jan 24, 2019 at 07:01:09PM +0100, Peter Zijlstra wrote:
> > And this would again be the moment where I go pester you about the BPF
> > memory model :-)
>
> hehe :)
> How do you propose to define it in a way that it appl
On Thu, Jan 24, 2019 at 03:58:59PM -0800, Alexei Starovoitov wrote:
> On Thu, Jan 24, 2019 at 07:01:09PM +0100, Peter Zijlstra wrote:
> > So clearly this map stuff is shared between bpf proglets, otherwise
> > there would not be a need for locking. But what happens if one is from
> > task context
On Thu, Jan 24, 2019 at 03:58:59PM -0800, Alexei Starovoitov wrote:
> On Thu, Jan 24, 2019 at 07:01:09PM +0100, Peter Zijlstra wrote:
> > > - on architectures that don't support queued_spin_lock trivial lock is
> > > used.
> > > Note that arch_spin_lock cannot be used, since not all archs agree
On Thu, Jan 24, 2019 at 03:58:59PM -0800, Alexei Starovoitov wrote:
> On Thu, Jan 24, 2019 at 07:01:09PM +0100, Peter Zijlstra wrote:
> >
> > Thanks for having kernel/locking people on Cc...
> >
> > On Wed, Jan 23, 2019 at 08:13:55PM -0800, Alexei Starovoitov wrote:
> >
> > > Implementation deta
On Thu, Jan 24, 2019 at 06:57:00PM -0800, Alexei Starovoitov wrote:
> On Thu, Jan 24, 2019 at 06:44:20PM -0800, Eric Dumazet wrote:
> > Let see if we understood this well.
> >
> > 1. create perf event PERF_TYPE_HARDWARE:PERF_COUNT_HW_CPU_CYCLES
> > 2. attach bpf probram to this event
> > 3. since
On 1/24/19 8:31 PM, Paul E. McKenney wrote:
> On Fri, Jan 25, 2019 at 04:27:02AM +, Alexei Starovoitov wrote:
>> On 1/24/19 6:38 PM, Alexei Starovoitov wrote:
For programs created with CAP_SYS_ADMIN,
things get more tricky because you can create your own functions and
call them r
On Fri, Jan 25, 2019 at 04:27:02AM +, Alexei Starovoitov wrote:
> On 1/24/19 6:38 PM, Alexei Starovoitov wrote:
> >> For programs created with CAP_SYS_ADMIN,
> >> things get more tricky because you can create your own functions and
> >> call them repeatedly; I'm not sure whether the pessimal ru
On 1/24/19 6:38 PM, Alexei Starovoitov wrote:
>> For programs created with CAP_SYS_ADMIN,
>> things get more tricky because you can create your own functions and
>> call them repeatedly; I'm not sure whether the pessimal runtime there
>> becomes exponential, or whether there is some check that catc
On Fri, Jan 25, 2019 at 02:46:55AM +0100, Jann Horn wrote:
> On Fri, Jan 25, 2019 at 2:22 AM Paul E. McKenney
> wrote:
> > On Thu, Jan 24, 2019 at 04:05:16PM -0800, Alexei Starovoitov wrote:
> > > On Thu, Jan 24, 2019 at 03:42:32PM -0800, Paul E. McKenney wrote:
> > > > On Thu, Jan 24, 2019 at 07
On Thu, Jan 24, 2019 at 06:44:20PM -0800, Eric Dumazet wrote:
>
>
> On 01/24/2019 06:34 PM, Alexei Starovoitov wrote:
> > On Thu, Jan 24, 2019 at 06:29:55PM -0800, Eric Dumazet wrote:
> >>
> >>
> >> On 01/24/2019 03:58 PM, Alexei Starovoitov wrote:
> >>> On Thu, Jan 24, 2019 at 07:01:09PM +0100,
On Fri, Jan 25, 2019 at 01:18:04AM +0100, Jann Horn wrote:
> On Fri, Jan 25, 2019 at 12:59 AM Alexei Starovoitov
> wrote:
> > On Thu, Jan 24, 2019 at 07:01:09PM +0100, Peter Zijlstra wrote:
> > > Thanks for having kernel/locking people on Cc...
> > >
> > > On Wed, Jan 23, 2019 at 08:13:55PM -0800,
On 01/24/2019 06:34 PM, Alexei Starovoitov wrote:
> On Thu, Jan 24, 2019 at 06:29:55PM -0800, Eric Dumazet wrote:
>>
>>
>> On 01/24/2019 03:58 PM, Alexei Starovoitov wrote:
>>> On Thu, Jan 24, 2019 at 07:01:09PM +0100, Peter Zijlstra wrote:
>>
and from NMI ...
>>>
>>> progs are not preempta
On Fri, Jan 25, 2019 at 02:46:55AM +0100, Jann Horn wrote:
> On Fri, Jan 25, 2019 at 2:22 AM Paul E. McKenney
> wrote:
> > On Thu, Jan 24, 2019 at 04:05:16PM -0800, Alexei Starovoitov wrote:
> > > On Thu, Jan 24, 2019 at 03:42:32PM -0800, Paul E. McKenney wrote:
> > > > On Thu, Jan 24, 2019 at 07
On Thu, Jan 24, 2019 at 06:29:55PM -0800, Eric Dumazet wrote:
>
>
> On 01/24/2019 03:58 PM, Alexei Starovoitov wrote:
> > On Thu, Jan 24, 2019 at 07:01:09PM +0100, Peter Zijlstra wrote:
>
> >> and from NMI ...
> >
> > progs are not preemptable and map syscall accessors have bpf_prog_active
> >
On 01/24/2019 03:58 PM, Alexei Starovoitov wrote:
> On Thu, Jan 24, 2019 at 07:01:09PM +0100, Peter Zijlstra wrote:
>> and from NMI ...
>
> progs are not preemptable and map syscall accessors have bpf_prog_active
> counters.
> So nmi/kprobe progs will not be running when syscall is running.
>
On Fri, Jan 25, 2019 at 2:22 AM Paul E. McKenney wrote:
> On Thu, Jan 24, 2019 at 04:05:16PM -0800, Alexei Starovoitov wrote:
> > On Thu, Jan 24, 2019 at 03:42:32PM -0800, Paul E. McKenney wrote:
> > > On Thu, Jan 24, 2019 at 07:56:52PM +0100, Peter Zijlstra wrote:
> > > > On Thu, Jan 24, 2019 at
On Thu, Jan 24, 2019 at 04:05:16PM -0800, Alexei Starovoitov wrote:
> On Thu, Jan 24, 2019 at 03:42:32PM -0800, Paul E. McKenney wrote:
> > On Thu, Jan 24, 2019 at 07:56:52PM +0100, Peter Zijlstra wrote:
> > > On Thu, Jan 24, 2019 at 07:01:09PM +0100, Peter Zijlstra wrote:
> > > >
> > > > Thanks f
On Fri, Jan 25, 2019 at 12:59 AM Alexei Starovoitov
wrote:
> On Thu, Jan 24, 2019 at 07:01:09PM +0100, Peter Zijlstra wrote:
> > Thanks for having kernel/locking people on Cc...
> >
> > On Wed, Jan 23, 2019 at 08:13:55PM -0800, Alexei Starovoitov wrote:
> >
> > > Implementation details:
> > > - on
On Thu, Jan 24, 2019 at 03:42:32PM -0800, Paul E. McKenney wrote:
> On Thu, Jan 24, 2019 at 07:56:52PM +0100, Peter Zijlstra wrote:
> > On Thu, Jan 24, 2019 at 07:01:09PM +0100, Peter Zijlstra wrote:
> > >
> > > Thanks for having kernel/locking people on Cc...
> > >
> > > On Wed, Jan 23, 2019 at
On Thu, Jan 24, 2019 at 07:01:09PM +0100, Peter Zijlstra wrote:
>
> Thanks for having kernel/locking people on Cc...
>
> On Wed, Jan 23, 2019 at 08:13:55PM -0800, Alexei Starovoitov wrote:
>
> > Implementation details:
> > - on !SMP bpf_spin_lock() becomes nop
>
> Because no BPF program is pree
On Thu, Jan 24, 2019 at 07:56:52PM +0100, Peter Zijlstra wrote:
> On Thu, Jan 24, 2019 at 07:01:09PM +0100, Peter Zijlstra wrote:
> >
> > Thanks for having kernel/locking people on Cc...
> >
> > On Wed, Jan 23, 2019 at 08:13:55PM -0800, Alexei Starovoitov wrote:
> >
> > > Implementation details:
On Thu, Jan 24, 2019 at 07:01:09PM +0100, Peter Zijlstra wrote:
>
> Thanks for having kernel/locking people on Cc...
>
> On Wed, Jan 23, 2019 at 08:13:55PM -0800, Alexei Starovoitov wrote:
>
> > Implementation details:
> > - on !SMP bpf_spin_lock() becomes nop
>
> Because no BPF program is pree
Thanks for having kernel/locking people on Cc...
On Wed, Jan 23, 2019 at 08:13:55PM -0800, Alexei Starovoitov wrote:
> Implementation details:
> - on !SMP bpf_spin_lock() becomes nop
Because no BPF program is preemptible? I don't see any assertions or
even a comment that says this code is non-
Introduce 'struct bpf_spin_lock' and bpf_spin_lock/unlock() helpers to let
bpf program serialize access to other variables.
Example:
struct hash_elem {
int cnt;
struct bpf_spin_lock lock;
};
struct hash_elem * val = bpf_map_lookup_elem(&hash_map, &key);
if (val) {
bpf_spin_lock(&val->l
55 matches
Mail list logo
