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
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 +/-.
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.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.13.4 on an i686 machine (5589.55 BogoMips).
Warning : 98.36% of all statistics are fiction.
.
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
On 11/4/05, linux-os (Dick Johnson) <[email protected]> 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
On 11/4/05, Nish Aravamudan <[email protected]>
>
> 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)
>> Exactly right.
> 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...
>
>> I don't see any problem from the kernel side but the application
times out immediately causing certain failures as the schedule_timeout
returns immediately in case of negative values. Shouldn't there be a
check for negative values and return error to the application so that
it can handle it.
- Show quoted text -
> This could be, and I think is what Ram was asking about -- I've asked
> for some clarification.
>
> Thanks,
> Nish
>
regards
Ram Gupta
On 11/7/05, Ram Gupta <[email protected]> wrote:
> On 11/4/05, Nish Aravamudan <[email protected]>
> >
> > 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)
>
> >> Exactly right.
Ok.
> > 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...
> >
> I don't see any problem from the kernel side but the application
> times out immediately causing certain failures as the schedule_timeout
> returns immediately in case of negative values. Shouldn't there be a
> check for negative values and return error to the application so that
> it can handle it.
I mean more along the lines of what does a man-page say the kernel
should be doing if you request a negative timeout? More explicitly,
what made you think negative timeouts should have a specific effect?
When you say schedule_timeout() returns immediately, I assume your
logs are filling up with "schedule_timeout: wrong timeout ..." ? (You
may need to bump your loglevel). If not, then schedule_timeout() isn't
getting a negative value.
Thanks,
Nish
On 11/7/05, Ram Gupta <[email protected]> wrote:
> On 11/4/05, Nish Aravamudan <[email protected]>
> >
> > 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)
>
> >> Exactly right.
Ok.
> > 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...
> >
> I don't see any problem from the kernel side but the application
> times out immediately causing certain failures as the schedule_timeout
> returns immediately in case of negative values. Shouldn't there be a
> check for negative values and return error to the application so that
> it can handle it.
I mean more along the lines of what does a man-page say the kernel
should be doing if you request a negative timeout? More explicitly,
what made you think negative timeouts should have a specific effect?
>> The man page is silent about the timeout behaviour in case of its
being negative. I believe that negative timeout is a mistake on behalf
of an application and hence should be treated as such (i.e should be
notified accordingly)
When you say schedule_timeout() returns immediately, I assume your
logs are filling up with "schedule_timeout: wrong timeout ..." ? (You
may need to bump your loglevel). If not, then schedule_timeout() isn't
getting a negative value.
>> Yes I am getting the "schedule_timeout: wrong timeout ..."
messages so I am sure the timeout has negative value.
Thanks,
Nish
regards
Ram Gupta
On 11/7/05, Ram Gupta <[email protected]> wrote:
>
> On 11/7/05, Ram Gupta <[email protected]> wrote:
> > On 11/4/05, Nish Aravamudan <[email protected]>
> > >
> > > 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)
> >
> > >> Exactly right.
>
> Ok.
>
> > > 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...
> > >
> > I don't see any problem from the kernel side but the application
> > times out immediately causing certain failures as the schedule_timeout
> > returns immediately in case of negative values. Shouldn't there be a
> > check for negative values and return error to the application so that
> > it can handle it.
>
> I mean more along the lines of what does a man-page say the kernel
> should be doing if you request a negative timeout? More explicitly,
> what made you think negative timeouts should have a specific effect?
>
> > The man page is silent about the timeout behaviour in case of its
> > being negative. I believe that negative timeout is a mistake on behalf
> > of an application and hence should be treated as such (i.e should be
> > notified accordingly)
Well, the problem is that there is no defined behavior for specifying
a negative timeout (unlike poll(), for instance). So I'm not sure what
the best approach is (beyond complaining to the application developers
that their app is busted).
> When you say schedule_timeout() returns immediately, I assume your
> logs are filling up with "schedule_timeout: wrong timeout ..." ? (You
> may need to bump your loglevel). If not, then schedule_timeout() isn't
> getting a negative value.
>
> >> Yes I am getting the "schedule_timeout: wrong timeout ..."
> messages so I am sure the timeout has negative value.
Ok, maybe bring this up with the networking folks, as they may have a
better idea of what to do.
Thanks,
Nish