On 02/10/2017 06:22 AM, Alexei Starovoitov wrote:
On Thu, Feb 09, 2017 at 12:25:37PM +0100, Daniel Borkmann wrote:
Correct the overlap both use-cases share is the dump itself. It needs
to be in such a condition for CRIU, that it can be reloaded eventually,
I don't think it makes sense to drag
On Thu, Feb 09, 2017 at 12:25:37PM +0100, Daniel Borkmann wrote:
>
> Correct the overlap both use-cases share is the dump itself. It needs
> to be in such a condition for CRIU, that it can be reloaded eventually,
I don't think it makes sense to drag criu into this discussion.
I expressed my take o
On 02/08/2017 08:40 PM, David Ahern wrote:
On 2/8/17 3:52 AM, Daniel Borkmann wrote:
I agree that dumping might be useful particularly with further
tooling on top (f.e. decompiler), but in any case the interface for
that needs to be designed carefully and generic, so it covers various
use cases
On 2/8/17 12:40 PM, David Ahern wrote:
> On 2/8/17 3:52 AM, Daniel Borkmann wrote:
>> for cBPF dumps it looks like this in ss. Can you tell me what these
>> 11 insns do? Likely you can, but can a normal admin?
>>
>> # ss -0 -b
>> Netid Recv-Q Send-Q Local
>> A
On 2/8/17 3:52 AM, Daniel Borkmann wrote:
> I agree that dumping might be useful particularly with further
> tooling on top (f.e. decompiler), but in any case the interface for
> that needs to be designed carefully and generic, so it covers various
> use cases (meaning also CRIU). Above, I was rath
On 02/07/2017 06:22 PM, David Ahern wrote:
On 2/6/17 12:21 PM, Alexei Starovoitov wrote:
Well, worst case cost would be ~8 additional pages per program that
are very rarely used; assume you want to attach a prog per netdevice,
or worse, one for ingress, one for egress ... and yet we already
comp
On 2/6/17 12:21 PM, Alexei Starovoitov wrote:
>> Well, worst case cost would be ~8 additional pages per program that
>> are very rarely used; assume you want to attach a prog per netdevice,
>> or worse, one for ingress, one for egress ... and yet we already
>> complain that netdevice itself is way
On Mon, Feb 06, 2017 at 03:13:15PM +0100, Daniel Borkmann wrote:
> On 02/06/2017 11:56 AM, Quentin Monnet wrote:
> >2017-02-03 (15:28 -0700) ~ David Ahern
> >>On 2/3/17 2:09 PM, Daniel Borkmann wrote:
> >>>On 02/03/2017 09:38 PM, David Ahern wrote:
> Similar to classic bpf, support saving orig
On 02/06/2017 11:56 AM, Quentin Monnet wrote:
2017-02-03 (15:28 -0700) ~ David Ahern
On 2/3/17 2:09 PM, Daniel Borkmann wrote:
On 02/03/2017 09:38 PM, David Ahern wrote:
Similar to classic bpf, support saving original ebpf instructions
Signed-off-by: David Ahern
Not convinced that this is
Hi Daniel, David,
2017-02-03 (15:28 -0700) ~ David Ahern
> On 2/3/17 2:09 PM, Daniel Borkmann wrote:
>> On 02/03/2017 09:38 PM, David Ahern wrote:
>>> Similar to classic bpf, support saving original ebpf instructions
>>>
>>> Signed-off-by: David Ahern
>>
>> Not convinced that this is in the righ
On 2/3/17 2:09 PM, Daniel Borkmann wrote:
> On 02/03/2017 09:38 PM, David Ahern wrote:
>> Similar to classic bpf, support saving original ebpf instructions
>>
>> Signed-off-by: David Ahern
>
> Not convinced that this is in the right direction, this not only
> *significantly*
> increases mem foot
On 02/03/2017 09:38 PM, David Ahern wrote:
Similar to classic bpf, support saving original ebpf instructions
Signed-off-by: David Ahern
Not convinced that this is in the right direction, this not only *significantly*
increases mem footprint for each and every program, but also when you dump t
Similar to classic bpf, support saving original ebpf instructions
Signed-off-by: David Ahern
---
include/linux/filter.h | 5 -
kernel/bpf/syscall.c | 36
2 files changed, 40 insertions(+), 1 deletion(-)
diff --git a/include/linux/filter.h b/include/li
13 matches
Mail list logo
