linux-kernel - Re: [PATCH] prctl: Add PR_SET_TIMERSLACK_PID for setting timer slack of an arbitrary thread.

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALAqxLX6vNdowBEiJ2DtcUiCRrwSe7dDhCJQ=U7476xTKf20FA@mail.gmail.com>
Date:	Fri, 5 Feb 2016 18:50:31 -0800
From:	John Stultz <john.stultz@...aro.org>
To:	Arjan van de Ven <arjan@...ux.intel.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Kees Cook <keescook@...omium.org>,
	lkml <linux-kernel@...r.kernel.org>,
	Ruchi Kandoi <kandoiruchi@...gle.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Oren Laadan <orenl@...lrox.com>,
	Rom Lemarchand <romlem@...roid.com>,
	Android Kernel Team <kernel-team@...roid.com>
Subject: Re: [PATCH] prctl: Add PR_SET_TIMERSLACK_PID for setting timer slack
 of an arbitrary thread.

On Fri, Feb 5, 2016 at 6:15 PM, Arjan van de Ven <arjan@...ux.intel.com> wrote:
> On 2/5/2016 4:51 PM, John Stultz wrote:
>>
>> Arjan/Thomas:  One curious thing I noticed here while writing some
>> documentation. The timer_slack_ns value in the task struct is a
>> unsigned long.
>>
>> So this means PR_SET_TIMERSLACK limits the maximum slack on 32 bit
>> machines to ~4 seconds. Where on 64bit machines it can be quite a bit
>> longer (unreasonably long, really :).
>
>
> originally when we created timerslack, 4 seconds was an eternity and good
> enough for everyone
> by a mile... (assumption was practical upper limit being in the 15 msec
> range)
> and most of the RT guys would only tolerate a little bit of it
>
> is there any real/practial use of going longer than 4 seconds? if there
> is then yeah fixing it makes sense.
> if it's just theoretical... shrug... 32 bit systems have a bunch of
> other limits/differences a well.

So I'd think it would be mostly theoretical, but in my testing on a
VM, setting the timerslack for bash to 10 secs made time sleep 1 take
~10.5 seconds. So its apparently not too hard to coalesce fairly far
out (I need to spend a bit more time to verify that events really
weren't happening during that time and we're not just doing
unnecessary delays with the extra slack).

But yea. My main concern is that if we do a consistent 64bit interface
for all arches in the /proc/<pid>/timerslack_ns interface, it will
make PR_GET_TIMERSLACK return incorrect results on 32bit systems when
the slack is >= 2^32.

I've got a first pass of the patch done which just uses ULONG_MAX on
the respective arch, but I've got to close up for the day, so I'll see
about doing a follow on patch that makes the task timer_slack_ns value
be a u64 and extends the interface to use that as well on all arches,
and send out both on monday so folks can see which they prefer.

thanks
-john

thanks
-john