linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* msecs_to_jiffies() still returns values greater then MAX_JIFFY_OFFSET
@ 2012-04-20  6:51 Andreas Herz
  0 siblings, 0 replies; only message in thread
From: Andreas Herz @ 2012-04-20  6:51 UTC (permalink / raw)
  To: linux-kernel; +Cc: tglx

Hi,

i'm new to the LKML and so i couldn't reply to the old mail from Mar
2011.

On 29 Mar 2011 there was already a disucssion about this issue:

http://lkml.org/lkml/2011/3/29/262

The problem still exists, as /kernel/time.c wasn't patched. I stumbled
upon this "bug" when i modified the ipset sourcecode that uses
msecs_to_jiffies() for timeout calculations.

When i call msecs_to_jiffies(2147483000) the return value is 2147483000
on my x86 32-Bit System with 1000Hz. When i call the function with
msecs_to_jiffies(2147484000) the return value is MAX_JIFFY_OFFSET what's
1073741822 on my system. That isn't the behaviour i expect from this
comment in time.c:

 * - 'too large' values [that would result in larger than
 *   MAX_JIFFY_OFFSET values] mean 'infinite timeout' too.

So you can pass values greater then MAX_JIFFY_OFFSET up to INT_MAX in
this example although the limit should be at INT_MAX/2 for
MAX_JIFFY_OFFSET. 

I'm not sure if the solution is to increase MAX_JIFFY_OFFSET or to catch
values between this gap. I also don't understand why the function
returns a unsigned long but is limited to integer. It could be nice to
increase the values that can be handled with this function.

Greetings

-- 
Andreas Herz

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2012-04-20  7:01 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-04-20  6:51 msecs_to_jiffies() still returns values greater then MAX_JIFFY_OFFSET Andreas Herz

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).