<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 14, 2021 at 12:25 PM Y Song <<a href="mailto:ys114321@gmail.com">ys114321@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, Jun 11, 2021 at 9:59 AM Alexei Starovoitov<br>
<<a href="mailto:alexei.starovoitov@gmail.com" target="_blank">alexei.starovoitov@gmail.com</a>> wrote:<br>
><br>
> On Fri, Jun 11, 2021 at 07:17:32AM -0400, Aaron Ballman wrote:<br>
> > On Thu, Jun 10, 2021 at 8:47 PM Alexei Starovoitov<br>
> > <<a href="mailto:alexei.starovoitov@gmail.com" target="_blank">alexei.starovoitov@gmail.com</a>> wrote:<br>
> > ><br>
> > > On Thu, Jun 10, 2021 at 12:42 PM David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br>
> > > ><br>
> > > >> ><br>
> > > >> ><br>
> > > >> > Any suggestions/preferences for the spelling, Aaron?<br>
> > > >><br>
> > > >> I don't know this domain particularly well, so takes these suggestions<br>
> > > >> with a giant grain of salt:<br>
> > > >><br>
> > > >> If the concept is specific to DWARF and you don't think it'll need to<br>
> > > >> extend into other debug formats, you could go with `dwarf_annotate`.<br>
> > > >> If it's not really a DWARF thing but is more about B[P|T]F, then<br>
> > > >> `btf_annotate`  or `bpf_annotate` could work, but those may be a bit<br>
> > > >> mysterious to folks outside of the domain. If it's a generic debug<br>
> > > >> info concept, probably `debug_info_annotate` or something.<br>
> > > ><br>
> > > ><br>
> > > > Arguably it can/could be a generic debug info or dwarf thing, but for now we don't have any use for it other than to squirrel info along to BTF/BPF so I'm on the fence about which prefix to use exactly<br>
> > > ><br>
> > ><br>
> > > A bit more bike shedding colors...<br>
> > ><br>
> > > The __rcu and __user annations might be used by the clang itself eventually.<br>
> > > Currently the "sparse" tool is doing this analysis and warns users<br>
> > > when __rcu pointer is incorrectly accessed in the kernel C code.<br>
> > > If clang can do that directly that could be a huge selling point<br>
> > > for folks to switch from gcc to clang for kernel builds.<br>
> > > The front-end would treat such annotations as arbitrary string, but<br>
> > > special "building-linux-kernel-pass" would interpret the semantical context.<br>
> ><br>
> > Are __rcu and __user annotations notionally distinct things from bpf<br>
> > (and perhaps each other as well)? Distinct enough that it would make<br>
> > sense to use a different attribute name for user source for each need?<br>
> > I suspect the answer is yes given that the existing annotations have<br>
> > their own names which are distinct, but I don't know this domain<br>
> > enough to be sure.<br>
><br>
> __rcu and __user don't overlap. __rcu is not a single annotation though.<br>
> It's a combination of annotations in pointers, functions, macros.<br>
> Some functions have:<br>
> __acquires(rcu)<br>
> another function might have:<br>
> __acquires(rcu_bh)<br>
> There are several flavors of the RCU in the kernel.<br>
> So single __attribute__((rcu_annotate("foo"))) won't work even within RCU scope.<br>
> But if we do:<br>
> struct foo {<br>
>   void * __attribute__((tag("ptr.rcu_bh")) ptr;<br>
> };<br>
> int bar(int) __attribute__((tag("acquires.rcu_bh")) { ... }<br>
> int baz(int) __attribute__((tag("releases.rcu_bh")) { ... }<br>
> int qux(int) __attribute__((tag("acquires.rcu_sched")) { ... }<br>
> ...<br>
> The clang pass can parse these strings and correlate one tag to another.<br>
> RCU flavors come and go, so clang cannot hard code the names.<br>
<br>
Maybe we can name it as "bpf_tag" as it is a "tag" for "bpf" use case?<br>
<br>
David, in one of your early emails, you mentioned:<br>
<br>
===<br>
Arguably it can/could be a generic debug info or dwarf thing, but for<br>
now we don't have any use for it other than to squirrel info along to<br>
BTF/BPF so I'm on the fence about which prefix to use exactly<br>
===<br>
<br>
and suggests since it might be used in the future for non-bpf things,<br>
maybe the name could be a little more generic then bpf-specific.<br>
<br>
Do you have any suggestions on what name to pick?<br></blockquote><div><br></div><div>Nah, not especially. bpf_tag sounds OK-ish to me if it suits you.</div><div> </div></div></div>