On Fri, Feb 3, 2017 at 5:52 AM, Jesper Dangaard Brouer <[email protected]> wrote: > On Thu, 2 Feb 2017 20:27:15 -0800 > Alexei Starovoitov <[email protected]> wrote: > >> On Thu, Feb 02, 2017 at 06:00:09PM +0100, Jesper Dangaard Brouer wrote: > [...] >> Comments below: > [...] > >> > +Interacting with maps >> > +===================== >> > + >> > +Interacting with an eBPF maps from **userspace**, happens through the >> > +`bpf`_ syscall and a file descriptor. The kernel >> > +`tools/lib/bpf/bpf.h`_ define some ``bpf_map_*()`` helper functions >> > +for wrapping the `bpf_cmd`_ relating to manipulating the map elements. >> > + >> > +.. code-block:: c >> > + >> > + enum bpf_cmd { >> > + [...] >> > + BPF_MAP_LOOKUP_ELEM, >> > + BPF_MAP_UPDATE_ELEM, >> > + BPF_MAP_DELETE_ELEM, >> > + BPF_MAP_GET_NEXT_KEY, >> > + [...] >> > + }; >> > + /* Corresponding helper functions */ >> > + int bpf_map_lookup_elem(int fd, void *key, void *value); >> > + int bpf_map_update_elem(int fd, void *key, void *value, __u64 flags); >> > + int bpf_map_delete_elem(int fd, void *key); >> > + int bpf_map_get_next_key(int fd, void *key, void *next_key); >> > + >> > +Notice from userspace, there is no call to atomically increment or >> > +decrement the value 'in-place'. The bpf_map_update_elem() call will >> > +overwrite the existing value. >> >> will overwrite in _atomic_ way. Meaning that the whole value will >> be replaced atomically regardless whether update() is called from >> kernel or from user space. > > Looking at the memcpy code in array_map_update_elem(), I don't see > anything preventing two processes from data-update racing with > each-other, especially when the value_size is large.
yes. my comment above applies to hash map only. _______________________________________________ iovisor-dev mailing list [email protected] https://lists.iovisor.org/mailman/listinfo/iovisor-dev
