[PATCH net-next 0/5] net: convert four more protocols to getsockopt_iter

[Breno Leitao <leitao@debian.org>]

Continue the work to convert protocols to the new getsockopt_iter API.

Convert four additional getsockopt implementations to the new
sockopt_t/getsockopt_iter callback:

  - CAN ISO-TP
  - MCTP
  - CAN J1939
  - LLC

These are mechanical, ABI-preserving conversions following the same
pattern as the previously converted protocols (af_packet, can/raw,
af_netlink, af_vsock): the (char __user *optval, int __user *optlen)
pair is replaced with a single sockopt_t *opt that carries the buffer
length on input and the returned size on output, and exposes an iov_iter
for the copy-out path. put_user()/copy_to_user() pairs are replaced with
a single copy_to_iter() per option, and the wrapper in
do_sock_getsockopt() handles writing optlen back to userspace.

I picked these four because each is small and self-contained, with only
one getsockopt callback and a handful of options, so the conversions are
easy to audit individually.

NOTE: optlen is always updated (returned to userspace) even when optval
fails to copy. I.e, userspace will get the "new" optlen even when the
getsockop() fails. That seems wrong, but, this just preserve the
previous behaviour, not changing it.

Signed-off-by: Breno Leitao <leitao@debian.org>
---
Breno Leitao (5):
      can: isotp: convert to getsockopt_iter
      can: j1939: convert to getsockopt_iter
      mctp: convert to getsockopt_iter
      llc: convert to getsockopt_iter
      selftests: net: getsockopt_iter: address review nits

 net/can/isotp.c                               |  12 ++-
 net/can/j1939/socket.c                        |  21 +++--
 net/llc/af_llc.c                              |  15 ++--
 net/mctp/af_mctp.c                            |  10 +--
 tools/testing/selftests/net/getsockopt_iter.c | 109 +++++++++++++++++++++++---
 5 files changed, 128 insertions(+), 39 deletions(-)
---
base-commit: c1e5127b577c6b88fa48e532616932ae978528d5
change-id: 20260505-getsock_two-abad19643336

Best regards,
--  
Breno Leitao <leitao@debian.org>