Question about timeout bug in recvmmsg

(Note: I had posted this before in
https://lore.kernel.org/netdev/CAFfO_h5k7n7pJrSimuUaexwbMh9s+f0_n6jJ0TX4=+ywQyUaeg@mail.gmail.com/ (local)
but got no reply, so trying again. I would really appreciate
suggestions on this request. Thanks!)

Hi,
Hope everyone is doing well. I came upon this timeout bug in the
recvmmsg system call from this URL:
https://bugzilla.kernel.org/show_bug.cgi?id=75371 . I am not familiar
with the linux kernel code. I thought it would be a good idea to try
to fix it and as a side effect I can get to know the code a bit
better. As far as I can see, the system call eventually goes through
the do_recvmmsg function in the net/socket.c file. There is a while
loop that checks for timeout after the call to ___sys_recvmmsg(...).
So this probably is still a bug where if the socket was not configured
with any SO_RCVTIMEO (i.e., sk_rcvtimeo in struct sock), the call can
block indefinitely. Is this considered something that should ideally
be fixed?

If this is something that should be fixed, I can try to take a look
into it. I have tried to follow the codepath a bit and from what I
understand, if we keep following the main function calls i.e.,
do_recvmmsg, ___sys_recvmmsg ... we eventually reach
tcp_recvmsg_locked function in net/ipv4/tcp.c (there are of course
other ipv6, udp code paths as well). In this function, the timeo
variable represents the timeout I think and it gets the timeout value
from the sock_rcvtimeo function. I think this is where we need to use
the smaller one between sk_rcvtimeo and the remaining timeout
(converted to 'long' from struct timespec) from the recvmmsg call (we
need to consider the case of timeout values 0 here of course). It
probably would have been easier if we could add a new member in struct
sock after sk_rcvtimeo, that way the change would only have to be in
sock_rcvtimeo function implementation. But this new timeout  value
from the recvmmsg call probably doesn't make sense to be part of
struct sock. So we need to pass this remaining timeout from
do_recvmmsg all the way to tcp_recvmsg_locked (and similar other
places) and do the check for smaller between the passed parameter and
return value from sock_rcvtimeo function. As we need to pass a new
timeout parameter anyway, it probably then makes sense to move the
sock_rcvtimeo call all the way up the call chain to do_recvmmsg and
compare and send the finalized timeout value to the function calls
upto tcp_recvmsg_locked, right?

I would really appreciate any suggestion about this issue so that I
can try to fix it. Thank you!

Regards,
Dorjoy