Re: Re: [PATCH bpf-next v3 1/2] bpf: Support multi-level pointer params via SCALAR_VALUE for trampolines

[Slava Imameev]

I think support for broader types can be provided in a compatible way
with future annotated support, as I explained in my reply to the v2
review:

"
  > so I suggest treating 'void **' as a scalar as Eduard suggested.
  > This particular sb_eat_lsm_opts() hook
  > doesn't have a useful type behind it anyway.
  > I'm less certain about 'char **'. If we make it scalar too
  > it will be harder to make it a pointer to nul terminated string later.

  > So I would do 'void **' -> scalar for now only.

  I changed to scalar in v3, keeping broader scope for pointer types.

  We encountered double pointers of various types that required
  workarounds, such as:

  int __posix_acl_chmod(struct posix_acl **acl, gfp_t gfp, umode_t mode)

  Adding support for void** alone doesn't address the broader issue
  with other double pointer types.

  When annotated array support (including char**) is added in the
  future, it should remain compatible with the scalar approach for
  legacy (unannotated) parameters. Unannotated parameters will
  continue using scalar handling.
"