linux-kernel - Re: [RFC/PATCH] 2.6.24-rcx: Make sys

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 19 Dec 2007 13:55:25 +0100
From:	Karsten Wiese <fzu@...gehoertderstaat.de>
To:	Robert Hancock <hancockr@...w.ca>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [RFC/PATCH] 2.6.24-rcx: Make sys_poll() wait at least timeout ms

Am Mittwoch, 19. Dezember 2007 schrieb Robert Hancock:
> Karsten Wiese wrote:
> > Am Mittwoch, 19. Dezember 2007 schrieb Robert Hancock:
> >> That seems fishy. What is your value of HZ and what is the timeout value 
> >> that was passed in the bad case?
> > 
> > HZ set to 250, timeout to 4ms.
> > Time spent in poll() taken by clock_gettime(CLOCK_MONOTONIC, &time)
> > before and after poll()call: i.e 62us.
> > Time measured with hpet gave 166us once.
> 
> msecs_to_jiffies (kernel/time.c) has this:
> 
> #if HZ <= MSEC_PER_SEC && !(MSEC_PER_SEC % HZ)
> 	/*
> 	 * HZ is equal to or smaller than 1000, and 1000 is a nice
> 	 * round multiple of HZ, divide with the factor between them,
> 	 * but round upwards:
> 	 */
> 	return (m + (MSEC_PER_SEC / HZ) - 1) / (MSEC_PER_SEC / HZ);
> 
> With HZ=250 and m=4 this gives 7/4 or only 1 jiffy, which is not more 
> than 4ms, but if we are already at near the end of the current jiffy it 
> could be much less than that (potentially almost no time at all).
> 
> Maybe we could convert poll to use a hrtimer for this instead?

That wouldn't fix configs without hrtimers.

The linux manpage reflects current behaviour:
from man2/poll.2.gz
"The timeout argument specifies an upper limit on the time for which
poll() will block, in milliseconds."
To achieve "at least" timeouts we'd have to add a jiffy's ms to the
timeout in userspace.

I'd like to let sys_poll() behave according to posix's manpage:
from man3p/poll.3p.gz
"poll() shall wait at least timeout milliseconds"
Thats easier to specify in userspace. No need to know the running kernel's
HZ.

Above posix/linux difference also shows in select() manpages.
epoll_wait() (linux only) manpage also says "maximum time of timeout"
A more complete patch would tweek (p)poll (p)select and epoll_(p)wait.
There are possibly more syscalls affected that I'm not aware off.

Is there upstream interest?

      Karsten
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/