Re: [PATCH net-next v2 2/4] net: call getsockopt_iter if available

[Breno Leitao <leitao@debian.org>]

On Wed, Apr 01, 2026 at 09:34:04AM -0700, Stanislav Fomichev wrote:
> > +static int do_sock_getsockopt_iter(struct socket *sock,
> > +				   const struct proto_ops *ops, int level,
> > +				   int optname, sockptr_t optval,
> > +				   sockptr_t optlen)
>
> If we want to eventually remove sockptr_t, why not make this new handler
> work with iov_iters from the beginning? The callers can have some new temporary
> sockptr_to_iter() or something?

The goal is to eliminate __user memory from the callbacks entirely, which
would make sockptr_t unnecessary. This series removes the callbacks that
originally necessitated sockptr_t's existence.

Therefore, working from the callbacks back to userspace seem to be a more
logical approach than replacing the middle layers of the implementation,
and then touching the callbacks.

So, yes, the sockptr_t() is used here as temporary glue to be able to
get rid of the elephant in the room.

> > +	/* iter is initialized as ITER_DEST. Callbacks that need to read
> > +	 * from optval (e.g. PACKET_HDRLEN) must flip data_source to
> > +	 * ITER_SOURCE, then restore ITER_DEST before writing back.
> > +	 */
>
> Have you considered creating two iters? opt.iter_in and opt.iter_out.
> That way you don't have to flip the source back and forth in the
> handlers.

That's a good suggestion I hadn't considered. My initial thought was to
create a helper like sockopt_read_val() to handle the flip-read-flip
dance.

Would opt.iter_in and opt.iter_out be clearer than the helper approach?

Thanks for the review,
--breno