Re: negative timeout can be set up by setsockopt system call

[Nish Aravamudan <nish.aravamudan@gmail.com>]

On 11/4/05, linux-os (Dick Johnson) <linux-os@analogic.com> wrote:
>
> On Fri, 4 Nov 2005, Ram Gupta wrote:
>
> > I observed that the the setsockopt system call can  setup negative
> > timeout. As a matter of fact the function sock_set_timeout checks for
> > zero timeout but does not check for negative timeouts. I tested this
> > against 2.6.14  kernel but it is so in all previous release also. So I
> > am wondering if it is a bug or there is some reason for keeping it that
> > way which I am missing.
> >
> > Regards
> > Ram gupta
>
> As a parameter it takes a void pointer to the value plus a
> length of the object to which the value points. Given this,
> I don't understand "negative". The pointer can point to
> anything of a specified size so it doesn't have a sense
> of +/-.

Huh?

In Ram's specific case, I think, the call path is sys_setsockopt() ->
sock_setsockopt() -> sock_set_timeout, which has a definition of:

static int sock_set_timeout(long *timeo_p, char __user *optval, int optlen)

where optval is the same optval in sys_setsockopt():

sys_setsockopt(int fd, int level, int optname, char __user *optval, int optlen)

and is a pointer to a userspace timeval structure, in this case.
timeval's have two members, both of which are signed, so it makes
perfect sense for one of them to be (potentially) negative:

struct timeval {
        time_t          tv_sec;         /* seconds */
        suseconds_t     tv_usec;        /* microseconds */
};

(time_t --> __kernel_time_t --> long on all archs; suseconds_t -->
__kernel_suseconds_t --> int or long on all archs)

Ram, what is the expected behavior of negative values in the timeval?
And what are you seeing happen right now?

As of 2.6.14, looks like we convert any non-zero values into jiffies
and store them in sk->sk_{rcv,snd}timeo...

> If the socket call itself checked for sign it would
> severly limit what options could be adjusted. Perhaps
> the SO_SNDTIMEO/SO_RCVTIMEO might do some checking, but
> I think it's valid to set the timeout to -1, meaning it
> never times-out.

This could be, and I think is what Ram was asking about -- I've asked
for some clarification.

Thanks,
Nish