Re: [PATCH net-next v4 4/7] ipv4: igmp: convert ip_mc_gsfget() to sockopt_t

[Joe Damato <joe@dama.to>]

On Tue, Nov 03, 2026 at 03:01:03AM -0800, Breno Leitao wrote:
> MCAST_MSFILTER reads its reply through ip_mc_gsfget(), reached from
> do_ip_getsockopt() and from nowhere else. Convert it the same way as
> the ipv6 side, and build the sockopt_t at the call site for as long as
> the caller still carries a sockptr_t pair.
> 
> optlen here only has to cover the fixed part, and the real reply size
> comes from the gf_numsrc field inside it. This is nasty, but userspace
> relies on it, so sockopt_expand_out() preserves the same mechanism: it
> grows optval only for a user address, and only far enough for the
> sources the socket has.
> 
> ip_mc_gsfget() writes the source list, and its two callers write the
> fixed part afterwards, at the head of optval. iter_out only moves
> forward, so the callee advances over the fixed part rather than
> addressing each source by offset.
> 
> The callers then rewind. The reply length they already compute is
> exactly what the callee consumed, ss_offset plus the sources it wrote,
> so both land back where they used to write: offset 0 for the native
> reply, gf_fmode for the compat one. The bytes are the same.
> 
> ip_get_mcast_msfilter() and compat_ip_get_mcast_msfilter() only store
> *optlen after their own copy succeeds, so a copy failure can't report
> a changed length: -EINVAL, -EADDRNOTAVAIL and -EFAULT all leave the
> caller's optlen word unchanged.
> 
> The old code stored *optlen before writing the fixed part, so an
> unwritable optlen word stopped the fixed part from being written. Now
> the fixed part is written first.
> 
> Acked-by: Stanislav Fomichev <sdf@fomichev.me>
> Acked-by: Ido Schimmel <idosch@nvidia.com>
> Signed-off-by: Breno Leitao <leitao@debian.org>
> ---
>  include/linux/igmp.h   |  2 +-
>  net/ipv4/igmp.c        | 20 +++++++++++++-----
>  net/ipv4/ip_sockglue.c | 57 +++++++++++++++++++++++++++++++-------------------
>  3 files changed, 52 insertions(+), 27 deletions(-)

Reviewed-by: Joe Damato <joe@dama.to>