union field priorities

[Dmitry Vyukov]

This come on https://github.com/google/syzkaller/pull/1813
Re selection priority for union fields. Consider here we want cgroup
to be select 10x more frequently than map:

bpf_attach_targets [
cgroup fd_cgroup[opt]
map fd_bpf_map[opt]
]

I am reposting my reply to the mailing list for the records and b/c if
there will be any discussion, it belongs to the mailing list.

Regarding fine-tuning priorities, I think long term going forward it
would be wrong to considerably over-complicate descriptions
(introducing sub-unions, splitting structures) in the name of the
fine-tuning. "This field is probably somewhat more important than that
one" affects just everything. And if we go and rework all descriptions
around this, this will massively complicate descriptions and make them
more obscure.
Overall I am leaning towards more scalable solutions and keeping as
much readability as possible. Improving fuzzing logic to make better
choices and/or using learned sequences in the corpus better looks like
much better direction. This will benefit just everything and will also
allow us to fine tune these heuristics later, rather than having
hard-coded in every piece of descriptions.
One thing I see as more or less reasonable (if somebody would analyze
existing descriptions and make a strong case) is addition of priority
attribute for union options. I recently added call attributes and I
think sooner or later we will end up with struct/union attributes
anyway, e.g. for direction/alignment, etc. So I see we could have
something along the lines of:

bpf_attach_targets [
cgroup fd_cgroup[opt] (dir[in], prio[1])
map fd_bpf_map[opt] (dir[out], prio[10])
]

At least this does not force us to split unions and encodes what we
want to say very explicitly and precisely.

[Dmitry Vyukov]

Moved this to an issue:
https://github.com/google/syzkaller/issues/1832
because I think we can potentially do this without any user input:
https://github.com/google/syzkaller/issues/1832#issuecomment-644059692