mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Rolf Eike Beer <eike-kernel@sf-tec.de>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	John Stultz <johnstul@us.ibm.com>,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH] fix msecs_to_jiffies() to not return values greater than MAX_JIFFY_OFFSET
Date: Sun, 08 May 2011 20:46:02 +0200	[thread overview]
Message-ID: <2449315.uFq6U1Y0gp@donald.sf-tec.de> (raw)
In-Reply-To: <alpine.LFD.2.00.1103292103070.2774@localhost6.localdomain6>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="US-ASCII", Size: 3029 bytes --]

Am Dienstag, 29. März 2011, 21:42:59 schrieb Thomas Gleixner:
> On Tue, 29 Mar 2011, Rolf Eike Beer wrote:
> > The documentation of msecs_to_jiffies() says:
> >  * - negative values mean 'infinite timeout' (MAX_JIFFY_OFFSET)
> >  *
> >  * - 'too large' values [that would result in larger than
> >  *   MAX_JIFFY_OFFSET values] mean 'infinite timeout' too.
> > 
> > But when you pass in e.g. MAX_JIFFY_OFFSET + 1000 for HZ = 1000 it will
> > not return MAX_JIFFY_OFFSET, but the bigger value. This makes sure that
> > the value
> 
> That's only true for 32 bit.
> 
> > returned from this function can never be bigger than MAX_JIFFY_OFFSET.
> > Also use DIV_ROUND_UP() in one place where that is open coded.
> > 
> >  unsigned long msecs_to_jiffies(const unsigned int m)
> >  {
> > 
> > +	unsigned long r;
> > 
> >  	/*
> >  	
> >  	 * Negative value, means infinite timeout:
> >  	 */
> > 
> > @@ -445,7 +446,7 @@ unsigned long msecs_to_jiffies(const unsigned int m)
> > 
> >  	 * round multiple of HZ, divide with the factor between them,
> >  	 * but round upwards:
> >  	 */
> > 
> > -	return (m + (MSEC_PER_SEC / HZ) - 1) / (MSEC_PER_SEC / HZ);
> > +	r = DIV_ROUND_UP(m, MSEC_PER_SEC / HZ);
> > 
> >  #elif HZ > MSEC_PER_SEC && !(HZ % MSEC_PER_SEC)
> >  
> >  	/*
> >  	
> >  	 * HZ is larger than 1000, and HZ is a nice round multiple of
> > 
> > @@ -457,7 +458,7 @@ unsigned long msecs_to_jiffies(const unsigned int m)
> > 
> >  	if (m > jiffies_to_msecs(MAX_JIFFY_OFFSET))
> >  	
> >  		return MAX_JIFFY_OFFSET;
> > 
> > -	return m * (HZ / MSEC_PER_SEC);
> > +	r = m * (HZ / MSEC_PER_SEC);
> 
> For this case the jiffies_to_msec() check should be sufficient.
> 
> >  #else
> >  
> >  	/*
> >  	
> >  	 * Generic case - multiply, round and divide. But first
> > 
> > @@ -467,9 +468,10 @@ unsigned long msecs_to_jiffies(const unsigned int
> > m)
> > 
> >  	if (HZ > MSEC_PER_SEC && m > jiffies_to_msecs(MAX_JIFFY_OFFSET))
> >  	
> >  		return MAX_JIFFY_OFFSET;
> 
> Hmm, this check is silly. MUL32 is chosen, so that we cannot overflow.
> 
> > -	return (MSEC_TO_HZ_MUL32 * m + MSEC_TO_HZ_ADJ32)
> > +	r = (MSEC_TO_HZ_MUL32 * m + MSEC_TO_HZ_ADJ32)
> > 
>   		>> MSEC_TO_HZ_SHR32;
> >  
> >  #endif
> > 
> > +	return min_t(unsigned long, r, MAX_JIFFY_OFFSET);
> > 
> >  }
> >  EXPORT_SYMBOL(msecs_to_jiffies);
> 
> I start to wonder whether we really need these three variants or
> whether we just could go with that MUL/SHIFT based implementation and
> a final check for MAX_JIFFY_OFFSET. That would boil down to:
> 
> unsigned long msecs_to_jiffies(const unsigned int m)
> {
> 	u64 res = (MSEC_TO_HZ_MUL32 * m + MSEC_TO_HZ_ADJ32) >> MSEC_TO_HZ_SHR32;
> 
> 	return min_t(unsigned long, (unsigned long)res, MAX_JIFFY_OFFSET);
> }
> 
> That'd avoid the whole division and msecs_to_jiffies() is not really a
> high precision function.

Ping? Is anyone going to either take my patch or do it's own reworking of that 
function?

Eike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

      parent reply	other threads:[~2011-05-08 18:46 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-29 16:38 Rolf Eike Beer
2011-03-29 19:42 ` Thomas Gleixner
2011-03-29 21:03   ` Rolf Eike Beer
2011-05-08 18:46   ` Rolf Eike Beer [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2449315.uFq6U1Y0gp@donald.sf-tec.de \
    --to=eike-kernel@sf-tec.de \
    --cc=akpm@linux-foundation.org \
    --cc=hpa@zytor.com \
    --cc=johnstul@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®