On 09/10/2014 07:09 AM, Alexei Starovoitov wrote:
....
BPF(2) Linux Programmer's Manual BPF(2)
...
union bpf_attr {
struct { /* anonymous struct used by BPF_MAP_CREATE command */
enum bpf_map_type map_type;
__u32 key_size; /* size of key in bytes */
__u32 value_size; /* size of value in bytes */
__u32 max_entries; /* max number of entries in a
map */
};
struct { /* anonymous struct used by BPF_MAP_*_ELEM commands */
int map_fd;
void *key;
union {
void *value;
void *next_key;
};
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?
As an example, for the current way to load BPF although we export ...
struct sock_fprog {
unsigned short len;
struct sock_filter __user *filter;
};
... through uapi, we still need to handle this via compat_sock_fprog
to take care of different pointer sizes via compat_uptr_t :
#ifdef CONFIG_COMPAT
struct compat_sock_fprog {
u16 len;
compat_uptr_t filter;
};
#endif
Perhaps I'm missing something, but I think, that would currently break in
your syscall handler, no?
};
struct { /* anonymous struct used by BPF_PROG_LOAD command */
enum bpf_prog_type prog_type;
__u32 insn_cnt;
const struct bpf_insn *insns;
const char *license;
__u32 log_level; /* verbosity level of eBPF
verifier */
__u32 log_size; /* size of user buffer */
void *log_buf; /* user supplied buffer */
};
};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
