Message-ID: <CAFfO_h4cX0+L=ieA_JF7QBvH-dDYsHnTUuN4gApguqxVpWyy2g@mail.gmail.com>
Date: Wed, 21 Jan 2026 00:26:55 +0600
From: Dorjoy Chowdhury <dorjoychy111@...il.com>
To: Eric Dumazet <edumazet@...gle.com>
Cc: netdev@...r.kernel.org, davem@...emloft.net, kuba@...nel.org, 
	pabeni@...hat.com, horms@...nel.org, ncardwell@...gle.com, kuniyu@...gle.com, 
	willemdebruijn.kernel@...il.com, willemb@...gle.com
Subject: Re: Question about timeout bug in recvmmsg

Hi Eric,

On Wed, Jan 21, 2026 at 12:14 AM Eric Dumazet <edumazet@...gle.com> wrote:
>
> On Tue, Jan 20, 2026 at 7:09 PM Dorjoy Chowdhury <dorjoychy111@...il.com> wrote:
> >
> > (Note: I had posted this before in
> > https://lore.kernel.org/netdev/CAFfO_h5k7n7pJrSimuUaexwbMh9s+f0_n6jJ0TX4=+ywQyUaeg@mail.gmail.com/
> > 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!
>
> I think it is too late to change behavior, set in stone for more than 18 years.
>
> This could break many applications.

Understood. Thanks!

If there are other smaller fixes/improvements that need to be looked
into, I can take a look if anyone can point me to them. I would
appreciate any suggestion on this.

Regards,
Dorjoy

Powered by blists - more mailing lists