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]
Date:	Fri, 5 Feb 2016 12:39:03 -0800
From:	John Stultz <john.stultz@...aro.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	lkml <linux-kernel@...r.kernel.org>,
	Ruchi Kandoi <kandoiruchi@...gle.com>,
	Arjan van de Ven <arjan@...ux.intel.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Oren Laadan <orenl@...lrox.com>,
	Rom Lemarchand <romlem@...roid.com>,
	Kees Cook <keescook@...omium.org>,
	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 12:32 PM, Andrew Morton
<akpm@...ux-foundation.org> wrote:
> On Fri, 5 Feb 2016 12:23:13 -0800 John Stultz <john.stultz@...aro.org> wrote:
>> On Fri, Feb 5, 2016 at 12:13 PM, Andrew Morton
>> <akpm@...ux-foundation.org> wrote:
>>>
>>> IOW, it would be more consistent to add sys_set_timer_slack()?
>>
>> I'm fine with moving this way.
>>
>> Ruchi/Rom: Any objections to that idea?
>>
>> Thomas/Arjan: Any other functionality we should consider including
>> when adding a syscall to tweak timer slack?
>
> A syscall is quite a bit more fuss - implement it on x86_64, provide a
> no-op default in sys_ni.c, add a test suite into
> tools/testing/selftests (mainly for arch maintainers), wait for the
> various arch maintainers to wire it up.

Yea. It is. And I'm not excited to start over on this, but this
functionality has already run into trouble in the Android tree, as the
PR_SET_TIMERSLACK_PID value has hit multiple collisions over time.  So
this functionality upstream would help resolve that pain.

> Fortunately the build system now emits little messages which tell
> maintainers that there's a new syscall which needs looking at.
>
> And a manpage will be needed, but a prctl manpage patch would have been
> needed anyway.

Yea.

thanks
-john

Powered by blists - more mailing lists