From: Alexei Starovoitov
Date: Fri, 19 Sep 2014 14:04:50 -0700
> the 'changes requested' status means that you want me to
> address this forward compatibility now instead of later?
I want you to address this now.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
On Thu, Sep 18, 2014 at 10:28 AM, Daniel Borkmann wrote:
> On 09/18/2014 05:24 PM, Alexei Starovoitov wrote:
> ...
>>
>> solve or not. If we decide to solve it, we need to have
>> a plan to solve it all the way. Partial fix for size of bpf_attr
>> is not a plan. It's something that is not
On Thu, Sep 18, 2014 at 10:28 AM, Daniel Borkmann dbork...@redhat.com wrote:
On 09/18/2014 05:24 PM, Alexei Starovoitov wrote:
...
solve or not. If we decide to solve it, we need to have
a plan to solve it all the way. Partial fix for size of bpf_attr
is not a plan. It's something that is
From: Alexei Starovoitov a...@plumgrid.com
Date: Fri, 19 Sep 2014 14:04:50 -0700
the 'changes requested' status means that you want me to
address this forward compatibility now instead of later?
I want you to address this now.
--
To unsubscribe from this list: send the line unsubscribe
On 09/18/2014 05:24 PM, Alexei Starovoitov wrote:
...
solve or not. If we decide to solve it, we need to have
a plan to solve it all the way. Partial fix for size of bpf_attr
is not a plan. It's something that is not addressing the problem
completely. Little bit of help is not useful for
On Thu, Sep 18, 2014 at 7:50 AM, Daniel Borkmann wrote:
> On 09/18/2014 04:34 PM, Alexei Starovoitov wrote:
>>
>> On Wed, Sep 17, 2014 at 11:44 PM, Daniel Borkmann
>> wrote:
>
> ...
>>>
>>> Sure, you will never get a full compatibility on that regard
>>> while backwards compatibility needs to be
On 09/18/2014 04:34 PM, Alexei Starovoitov wrote:
On Wed, Sep 17, 2014 at 11:44 PM, Daniel Borkmann wrote:
...
Sure, you will never get a full compatibility on that regard
while backwards compatibility needs to be guaranteed on the
other hand. I looked at perf_copy_attr() implementation and I
On Wed, Sep 17, 2014 at 11:44 PM, Daniel Borkmann wrote:
> On 09/18/2014 01:45 AM, Alexei Starovoitov wrote:
>>
>> On Wed, Sep 17, 2014 at 12:37 PM, Alexei Starovoitov
>> wrote:
>>>
>>>
Hm, thinking out loudly ... perhaps this could be made a library
problem.
Such that the library
On 09/18/2014 01:45 AM, Alexei Starovoitov wrote:
On Wed, Sep 17, 2014 at 12:37 PM, Alexei Starovoitov wrote:
Hm, thinking out loudly ... perhaps this could be made a library problem.
Such that the library which wraps the syscall needs to be aware of a
marker where the initial version ends,
On 09/18/2014 01:45 AM, Alexei Starovoitov wrote:
On Wed, Sep 17, 2014 at 12:37 PM, Alexei Starovoitov a...@plumgrid.com wrote:
Hm, thinking out loudly ... perhaps this could be made a library problem.
Such that the library which wraps the syscall needs to be aware of a
marker where the
On Wed, Sep 17, 2014 at 11:44 PM, Daniel Borkmann dbork...@redhat.com wrote:
On 09/18/2014 01:45 AM, Alexei Starovoitov wrote:
On Wed, Sep 17, 2014 at 12:37 PM, Alexei Starovoitov a...@plumgrid.com
wrote:
Hm, thinking out loudly ... perhaps this could be made a library
problem.
Such that
On 09/18/2014 04:34 PM, Alexei Starovoitov wrote:
On Wed, Sep 17, 2014 at 11:44 PM, Daniel Borkmann dbork...@redhat.com wrote:
...
Sure, you will never get a full compatibility on that regard
while backwards compatibility needs to be guaranteed on the
other hand. I looked at perf_copy_attr()
On Thu, Sep 18, 2014 at 7:50 AM, Daniel Borkmann dbork...@redhat.com wrote:
On 09/18/2014 04:34 PM, Alexei Starovoitov wrote:
On Wed, Sep 17, 2014 at 11:44 PM, Daniel Borkmann dbork...@redhat.com
wrote:
...
Sure, you will never get a full compatibility on that regard
while backwards
On 09/18/2014 05:24 PM, Alexei Starovoitov wrote:
...
solve or not. If we decide to solve it, we need to have
a plan to solve it all the way. Partial fix for size of bpf_attr
is not a plan. It's something that is not addressing the problem
completely. Little bit of help is not useful for
On Wed, Sep 17, 2014 at 12:37 PM, Alexei Starovoitov wrote:
>
>> Hm, thinking out loudly ... perhaps this could be made a library problem.
>> Such that the library which wraps the syscall needs to be aware of a
>> marker where the initial version ends, and if the application doesn't
>> make use
On Wed, Sep 17, 2014 at 12:17 PM, Daniel Borkmann wrote:
> On 09/17/2014 07:03 PM, Daniel Borkmann wrote:
>>
>> You built your shiny new binary on that uapi setting, and later on
>> decide to run it on an older kernel. What will happen is that in your
>> bpf syscall handler you will return with
On 09/17/2014 07:03 PM, Daniel Borkmann wrote:
On 09/17/2014 06:08 PM, Alexei Starovoitov wrote:
On Tue, Sep 16, 2014 at 11:51 PM, Daniel Borkmann wrote:
/* last field in 'union bpf_attr' used by this command */
-#defineBPF_PROG_LOAD_LAST_FIELD license
+#define
On 09/17/2014 06:08 PM, Alexei Starovoitov wrote:
On Tue, Sep 16, 2014 at 11:51 PM, Daniel Borkmann wrote:
/* last field in 'union bpf_attr' used by this command */
-#defineBPF_PROG_LOAD_LAST_FIELD license
+#defineBPF_PROG_LOAD_LAST_FIELD log_buf
I was looking to find a
On Tue, Sep 16, 2014 at 11:51 PM, Daniel Borkmann wrote:
>>
>> /* last field in 'union bpf_attr' used by this command */
>> -#defineBPF_PROG_LOAD_LAST_FIELD license
>> +#defineBPF_PROG_LOAD_LAST_FIELD log_buf
>
>
> I was looking to find a use case for this item, but couldn't
On 09/17/2014 02:39 AM, Alexei Starovoitov wrote:
add optional attributes for BPF_PROG_LOAD syscall:
union bpf_attr {
struct {
...
__u32 log_level; /* verbosity level of eBPF verifier */
__u32 log_size; /* size of user buffer */
__aligned_u64
On 09/17/2014 02:39 AM, Alexei Starovoitov wrote:
add optional attributes for BPF_PROG_LOAD syscall:
union bpf_attr {
struct {
...
__u32 log_level; /* verbosity level of eBPF verifier */
__u32 log_size; /* size of user buffer */
__aligned_u64
On Tue, Sep 16, 2014 at 11:51 PM, Daniel Borkmann dbork...@redhat.com wrote:
/* last field in 'union bpf_attr' used by this command */
-#defineBPF_PROG_LOAD_LAST_FIELD license
+#defineBPF_PROG_LOAD_LAST_FIELD log_buf
I was looking to find a use case for this item, but
On 09/17/2014 06:08 PM, Alexei Starovoitov wrote:
On Tue, Sep 16, 2014 at 11:51 PM, Daniel Borkmann dbork...@redhat.com wrote:
/* last field in 'union bpf_attr' used by this command */
-#defineBPF_PROG_LOAD_LAST_FIELD license
+#defineBPF_PROG_LOAD_LAST_FIELD log_buf
I was
On 09/17/2014 07:03 PM, Daniel Borkmann wrote:
On 09/17/2014 06:08 PM, Alexei Starovoitov wrote:
On Tue, Sep 16, 2014 at 11:51 PM, Daniel Borkmann dbork...@redhat.com wrote:
/* last field in 'union bpf_attr' used by this command */
-#defineBPF_PROG_LOAD_LAST_FIELD license
+#define
On Wed, Sep 17, 2014 at 12:17 PM, Daniel Borkmann dbork...@redhat.com wrote:
On 09/17/2014 07:03 PM, Daniel Borkmann wrote:
You built your shiny new binary on that uapi setting, and later on
decide to run it on an older kernel. What will happen is that in your
bpf syscall handler you will
On Wed, Sep 17, 2014 at 12:37 PM, Alexei Starovoitov a...@plumgrid.com wrote:
Hm, thinking out loudly ... perhaps this could be made a library problem.
Such that the library which wraps the syscall needs to be aware of a
marker where the initial version ends, and if the application doesn't
add optional attributes for BPF_PROG_LOAD syscall:
union bpf_attr {
struct {
...
__u32 log_level; /* verbosity level of eBPF verifier */
__u32 log_size; /* size of user buffer */
__aligned_u64 log_buf; /* user supplied 'char *buffer' */
};
add optional attributes for BPF_PROG_LOAD syscall:
union bpf_attr {
struct {
...
__u32 log_level; /* verbosity level of eBPF verifier */
__u32 log_size; /* size of user buffer */
__aligned_u64 log_buf; /* user supplied 'char *buffer' */
};
28 matches
Mail list logo
