Hi All,
the list of things I fixed so far from V11:
- dropped patch 11 and copied few macros to libbpf.h (suggested by Daniel)
- replaced 'enum bpf_prog_type' with u32 to be safe in compat (.. Andy)
- implemented and tested compat support (.. Daniel)
- changed 'void *log_buf' to 'char *' (..
Hi All,
the list of things I fixed so far from V11:
- dropped patch 11 and copied few macros to libbpf.h (suggested by Daniel)
- replaced 'enum bpf_prog_type' with u32 to be safe in compat (.. Andy)
- implemented and tested compat support (.. Daniel)
- changed 'void *log_buf' to 'char *' (..
On Thu, Sep 11, 2014 at 6:17 PM, Andy Lutomirski wrote:
> On Thu, Sep 11, 2014 at 3:29 PM, Alexei Starovoitov wrote:
>> On Thu, Sep 11, 2014 at 2:54 PM, Andy Lutomirski wrote:
the verifier log contains full trace. Last unsafe instruction + error
in many cases is useless. What we
On Thu, Sep 11, 2014 at 3:29 PM, Alexei Starovoitov wrote:
> On Thu, Sep 11, 2014 at 2:54 PM, Andy Lutomirski wrote:
>>>
>>> the verifier log contains full trace. Last unsafe instruction + error
>>> in many cases is useless. What we found empirically from using
>>> it over last 2 years is that
On Thu, Sep 11, 2014 at 2:54 PM, Andy Lutomirski wrote:
>>
>> the verifier log contains full trace. Last unsafe instruction + error
>> in many cases is useless. What we found empirically from using
>> it over last 2 years is that developers have different learning curve
>> to adjust to 'safe'
On Thu, Sep 11, 2014 at 1:33 PM, Alexei Starovoitov wrote:
> On Thu, Sep 11, 2014 at 12:47 PM, Daniel Borkmann wrote:
>> On 09/10/2014 07:32 PM, Alexei Starovoitov wrote:
>>>
>>> On Wed, Sep 10, 2014 at 2:03 AM, Daniel Borkmann
>>> wrote:
>
> struct { /* anonymous struct
On Thu, Sep 11, 2014 at 12:54 PM, Daniel Borkmann wrote:
> On 09/10/2014 10:21 PM, Alexei Starovoitov wrote:
> ...
char bpf_log_buf[LOG_BUF_SIZE];
>>>
>>>
>>> What happens if the size isn't LOG_BUF_SIZE?
>>
>>
>> would do you mean?
>> LOG_BUF_SIZE is just a user defined
On Thu, Sep 11, 2014 at 12:47 PM, Daniel Borkmann wrote:
> On 09/10/2014 07:32 PM, Alexei Starovoitov wrote:
>>
>> On Wed, Sep 10, 2014 at 2:03 AM, Daniel Borkmann
>> wrote:
struct { /* anonymous struct used by BPF_PROG_LOAD command
*/
enum
On 09/10/2014 10:21 PM, Alexei Starovoitov wrote:
...
char bpf_log_buf[LOG_BUF_SIZE];
What happens if the size isn't LOG_BUF_SIZE?
would do you mean?
LOG_BUF_SIZE is just a user defined macro.
Can be anything.
I believe, Andy means, what would happen if log_level > 0 but
the
On 09/10/2014 07:32 PM, Alexei Starovoitov wrote:
On Wed, Sep 10, 2014 at 2:03 AM, Daniel Borkmann wrote:
struct { /* anonymous struct used by BPF_PROG_LOAD command */
enum bpf_prog_typeprog_type;
__u32 insn_cnt;
On Thu, Sep 11, 2014 at 1:33 PM, Alexei Starovoitov a...@plumgrid.com wrote:
On Thu, Sep 11, 2014 at 12:47 PM, Daniel Borkmann dbork...@redhat.com wrote:
On 09/10/2014 07:32 PM, Alexei Starovoitov wrote:
On Wed, Sep 10, 2014 at 2:03 AM, Daniel Borkmann dbork...@redhat.com
wrote:
On Thu, Sep 11, 2014 at 2:54 PM, Andy Lutomirski l...@amacapital.net wrote:
the verifier log contains full trace. Last unsafe instruction + error
in many cases is useless. What we found empirically from using
it over last 2 years is that developers have different learning curve
to adjust to
On Thu, Sep 11, 2014 at 3:29 PM, Alexei Starovoitov a...@plumgrid.com wrote:
On Thu, Sep 11, 2014 at 2:54 PM, Andy Lutomirski l...@amacapital.net wrote:
the verifier log contains full trace. Last unsafe instruction + error
in many cases is useless. What we found empirically from using
it over
On Thu, Sep 11, 2014 at 6:17 PM, Andy Lutomirski l...@amacapital.net wrote:
On Thu, Sep 11, 2014 at 3:29 PM, Alexei Starovoitov a...@plumgrid.com wrote:
On Thu, Sep 11, 2014 at 2:54 PM, Andy Lutomirski l...@amacapital.net wrote:
the verifier log contains full trace. Last unsafe instruction +
On 09/10/2014 07:32 PM, Alexei Starovoitov wrote:
On Wed, Sep 10, 2014 at 2:03 AM, Daniel Borkmann dbork...@redhat.com wrote:
struct { /* anonymous struct used by BPF_PROG_LOAD command */
enum bpf_prog_typeprog_type;
__u32
On 09/10/2014 10:21 PM, Alexei Starovoitov wrote:
...
char bpf_log_buf[LOG_BUF_SIZE];
What happens if the size isn't LOG_BUF_SIZE?
would do you mean?
LOG_BUF_SIZE is just a user defined macro.
Can be anything.
I believe, Andy means, what would happen if log_level 0 but
the
On Thu, Sep 11, 2014 at 12:47 PM, Daniel Borkmann dbork...@redhat.com wrote:
On 09/10/2014 07:32 PM, Alexei Starovoitov wrote:
On Wed, Sep 10, 2014 at 2:03 AM, Daniel Borkmann dbork...@redhat.com
wrote:
struct { /* anonymous struct used by BPF_PROG_LOAD command
*/
On Thu, Sep 11, 2014 at 12:54 PM, Daniel Borkmann dbork...@redhat.com wrote:
On 09/10/2014 10:21 PM, Alexei Starovoitov wrote:
...
char bpf_log_buf[LOG_BUF_SIZE];
What happens if the size isn't LOG_BUF_SIZE?
would do you mean?
LOG_BUF_SIZE is just a user defined macro.
On Wed, Sep 10, 2014 at 11:22 AM, Andy Lutomirski wrote:
>>
>>attr is a pointer to a union of type bpf_attr as defined below.
>>
>>size is the size of the union.
>
> I find this strange. Why not just make attr be a pointer to the
> relevant struct for the operation being
On Tue, Sep 9, 2014 at 10:09 PM, Alexei Starovoitov wrote:
> Hi David,
>
> I've managed to reduce this set to 12:
> Patches 1-4 establish BPF syscall shell for maps and programs.
> Patches 5-10 add verifier step by step
> Patch 11 exposes existing instruction macros to user space
> Patch 12 adds
On Wed, Sep 10, 2014 at 2:21 AM, Daniel Borkmann wrote:
>
> When you pass in these structs with pointers in it to other user space
> buffers, how do you handle this with mixed 32/64 bit user/kernel space?
...
> Perhaps I'm missing something, but I think, that would currently break in
> your
On Wed, Sep 10, 2014 at 2:03 AM, Daniel Borkmann wrote:
>> struct { /* anonymous struct used by BPF_PROG_LOAD command */
>> enum bpf_prog_typeprog_type;
>> __u32 insn_cnt;
>> const struct bpf_insn *insns;
>>
On Wed, Sep 10, 2014 at 1:19 AM, Daniel Borkmann wrote:
>>
>> In the future maps can have different types: hash, array, bloom
>> filter,
>> radix-tree, but currently only hash type is supported:
>> enum bpf_map_type {
>>BPF_MAP_TYPE_UNSPEC,
>>
On 09/10/2014 07:09 AM, Alexei Starovoitov wrote:
BPF(2) Linux Programmer's ManualBPF(2)
...
union bpf_attr {
struct { /* anonymous struct used by BPF_MAP_CREATE command */
enum bpf_map_type map_type;
On 09/10/2014 07:09 AM, Alexei Starovoitov wrote:
...
struct { /* anonymous struct used by BPF_MAP_*_ELEM commands */
int map_fd;
void *key;
union {
void *value;
void *next_key;
};
On 09/10/2014 07:09 AM, Alexei Starovoitov wrote:
...
As requested by Andy and others, here is the man page:
BPF(2) Linux Programmer's ManualBPF(2)
...
In the future maps can have different types: hash, array, bloom filter,
radix-tree,
On 09/10/2014 07:09 AM, Alexei Starovoitov wrote:
...
As requested by Andy and others, here is the man page:
BPF(2) Linux Programmer's ManualBPF(2)
...
In the future maps can have different types: hash, array, bloom filter,
radix-tree,
On 09/10/2014 07:09 AM, Alexei Starovoitov wrote:
...
struct { /* anonymous struct used by BPF_MAP_*_ELEM commands */
int map_fd;
void *key;
union {
void *value;
void *next_key;
};
On 09/10/2014 07:09 AM, Alexei Starovoitov wrote:
BPF(2) Linux Programmer's ManualBPF(2)
...
union bpf_attr {
struct { /* anonymous struct used by BPF_MAP_CREATE command */
enum bpf_map_type map_type;
On Wed, Sep 10, 2014 at 1:19 AM, Daniel Borkmann dbork...@redhat.com wrote:
In the future maps can have different types: hash, array, bloom
filter,
radix-tree, but currently only hash type is supported:
enum bpf_map_type {
BPF_MAP_TYPE_UNSPEC,
On Wed, Sep 10, 2014 at 2:03 AM, Daniel Borkmann dbork...@redhat.com wrote:
struct { /* anonymous struct used by BPF_PROG_LOAD command */
enum bpf_prog_typeprog_type;
__u32 insn_cnt;
const struct bpf_insn *insns;
On Wed, Sep 10, 2014 at 2:21 AM, Daniel Borkmann dbork...@redhat.com wrote:
When you pass in these structs with pointers in it to other user space
buffers, how do you handle this with mixed 32/64 bit user/kernel space?
...
Perhaps I'm missing something, but I think, that would currently break
On Tue, Sep 9, 2014 at 10:09 PM, Alexei Starovoitov a...@plumgrid.com wrote:
Hi David,
I've managed to reduce this set to 12:
Patches 1-4 establish BPF syscall shell for maps and programs.
Patches 5-10 add verifier step by step
Patch 11 exposes existing instruction macros to user space
On Wed, Sep 10, 2014 at 11:22 AM, Andy Lutomirski l...@amacapital.net wrote:
attr is a pointer to a union of type bpf_attr as defined below.
size is the size of the union.
I find this strange. Why not just make attr be a pointer to the
relevant struct for the operation
Hi David,
I've managed to reduce this set to 12:
Patches 1-4 establish BPF syscall shell for maps and programs.
Patches 5-10 add verifier step by step
Patch 11 exposes existing instruction macros to user space
Patch 12 adds test stubs and verifier testsuite from user space
I don't know how to
Hi David,
I've managed to reduce this set to 12:
Patches 1-4 establish BPF syscall shell for maps and programs.
Patches 5-10 add verifier step by step
Patch 11 exposes existing instruction macros to user space
Patch 12 adds test stubs and verifier testsuite from user space
I don't know how to
36 matches
Mail list logo
