lkml.org 
[lkml]   [2018]   [Jul]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
From
Date
SubjectRe: [PATCH v2] Add BPF_SYNCHRONIZE_MAPS bpf(2) command
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Jul 29, 2018 at 8:51 AM, Alexei Starovoitov <span dir="ltr">&lt;<a href="mailto:alexei.starovoitov@gmail.com" target="_blank">alexei.starovoitov@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, Jul 26, 2018 at 7:51 PM, Daniel Colascione &lt;<a href="mailto:dancol@google.com">dancol@google.com</a>&gt; wrote:<br>
&gt; BPF_SYNCHRONIZE_MAPS waits for the release of any references to a BPF<br>
&gt; map made by a BPF program that is running at the time the<br>
&gt; BPF_SYNCHRONIZE_MAPS command is issued. The purpose of this command is<br>
&gt; to provide a means for userspace to replace a BPF map with another,<br>
&gt; newer version, then ensure that no component is still using the &quot;old&quot;<br>
&gt; map before manipulating the &quot;old&quot; map in some way.<br>
&gt;<br>
&gt; Signed-off-by: Daniel Colascione &lt;<a href="mailto:dancol@google.com">dancol@google.com</a>&gt;<br>
&gt; ---<br>
&gt;  include/uapi/linux/bpf.h |  9 +++++++++<br>
&gt;  kernel/bpf/syscall.c     | 13 +++++++++++++<br>
&gt;  2 files changed, 22 insertions(+)<br>
&gt;<br>
&gt; diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h<br>
&gt; index b7db3261c62d..5b27e9117d3e 100644<br>
&gt; --- a/include/uapi/linux/bpf.h<br>
&gt; +++ b/include/uapi/linux/bpf.h<br>
&gt; @@ -75,6 +75,14 @@ struct bpf_lpm_trie_key {<br>
&gt;         __u8    data[0];        /* Arbitrary size */<br>
&gt;  };<br>
&gt;<br>
&gt; +/* BPF_SYNCHRONIZE_MAPS waits for the release of any references to a<br>
&gt; + * BPF map made by a BPF program that is running at the time the<br>
&gt; + * BPF_SYNCHRONIZE_MAPS command is issued. The purpose of this command<br>
<br>
</span>that doesn&#39;t sound right to me.<br>
such command won&#39;t wait for the release of the references.<br>
in case of map-in-map the program does not hold<br>
the references to inner map (only to outer map).<br></blockquote><div><br></div><div>Well, today that&#39;s the guarantee it provides. :-) I figured it&#39;d be simpler to explain the guarantee this way.</div><div><br></div><div>How about &quot;waits for the release of any reference to a map obtained from another map&quot;?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
&gt; + * is to provide a means for userspace to replace a BPF map with<br>
&gt; + * another, newer version, then ensure that no component is still<br>
&gt; + * using the &quot;old&quot; map before manipulating the &quot;old&quot; map in some way.<br>
&gt; + */<br>
<br>
</span>that&#39;s correct, but the whole paragraph still reads too<br>
&#39;generic&#39; which will lead to confusion,<br>
whereas the use case is map-in-map only.<br>
I think bpf_sync_inner_map or<br>
bpf_sync_map_in_map would be better<br>
choices for the name.</blockquote><div><br></div><div>I worry that a name like that would be too specific.</div></div></div></div>
\
 
 \ /
  Last update: 2018-07-29 22:47    [W:0.104 / U:1.088 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site