mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* [RFC][PATCH 0/2] /proc/<pid>/timerslack_ns & changes to extend timer_slack_ns to u64 on 32bit systems
@ 2016-02-08 23:23 John Stultz
  2016-02-08 23:23 ` [RFC][PATCH 1/2] timer: Convert timer_slack_ns from unsigned long to u64 John Stultz
  2016-02-08 23:23 ` [RFC][PATCH 2/2] proc: Add /proc/<pid>/timerslack_ns interface John Stultz
  0 siblings, 2 replies; 3+ messages in thread
From: John Stultz @ 2016-02-08 23:23 UTC (permalink / raw)
  To: lkml
  Cc: John Stultz, Arjan van de Ven, Thomas Gleixner, Oren Laadan,
	Ruchi Kandoi, Rom Lemarchand, Kees Cook, Andrew Morton,
	Android Kernel Team

Here's a first pass on some patches discussed on Friday, to add
a /proc/<pid>/timerslack_ns interface which would allow
controlling processes to be able to set the timerslack value on
other processes in order to save power by avoiding wakeups
(Something Android currently does via out-of-tree patches).

The first patch tries to fix the internal timer_slack_ns usage
which was defined as a long, which limits the slack range to
~4 seconds on 32bit systems. It converts it to a u64, which
provides the same basically unlimited slack (500 years) on both
32bit and 64bit machines.

The second patch introduces the /proc/<pid>/timerslack_ns
interface which allows the full 64bit slack range for a task
to be read or set on both 32bit and 64bit machines.

With these two patches, on a 32bit machine, after setting the
slack on bash to 10 seconds:
$ time sleep 1

real    0m10.747s
user    0m0.001s
sys     0m0.005s


The first patch is a little ugly, since I had to chase the slack
delta arguments through a number of functions converting them to
u64s. Let me know if it makes sense to break that up more or not.

The second patch is fairly straight forward. My only slight
concern is that I'm worried the change suggested to move from
CAP_SYS_NICE to PTRACE_MODE_ATTACH might be problematic, because
it means the controlling thread will need elevated permissions.

While I agree CAP_SYS_NICE normally can only tweak scheduling
priority, and can't stall processes as much as adjusting
timerslack, I worry PTRACE_MODE_ATTACH might be too high,
allowing for much more invasive interactions, making the
controlling task a problematic attack surface. So if there are
suggestions for some in-between permission to use, that might
be helpful.

Feedback and review thoughts would be greatly appreciated!

thanks
-john

Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Oren Laadan <orenl@cellrox.com>
Cc: Ruchi Kandoi <kandoiruchi@google.com>
Cc: Rom Lemarchand <romlem@android.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Android Kernel Team <kernel-team@android.com>

John Stultz (2):
  timer: Convert timer_slack_ns from unsigned long to u64
  proc: Add /proc/<pid>/timerslack_ns interface

 Documentation/filesystems/proc.txt | 18 ++++++++++
 fs/eventpoll.c                     |  2 +-
 fs/proc/base.c                     | 69 ++++++++++++++++++++++++++++++++++++++
 fs/select.c                        |  8 ++---
 include/linux/freezer.h            |  2 +-
 include/linux/hrtimer.h            | 12 ++++---
 include/linux/poll.h               |  2 +-
 include/linux/sched.h              |  4 +--
 kernel/sys.c                       |  5 ++-
 kernel/time/hrtimer.c              |  8 ++---
 kernel/time/timer.c                |  4 +--
 11 files changed, 113 insertions(+), 21 deletions(-)

-- 
1.9.1

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2016-02-08 23:23 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-02-08 23:23 [RFC][PATCH 0/2] /proc/<pid>/timerslack_ns & changes to extend timer_slack_ns to u64 on 32bit systems John Stultz
2016-02-08 23:23 ` [RFC][PATCH 1/2] timer: Convert timer_slack_ns from unsigned long to u64 John Stultz
2016-02-08 23:23 ` [RFC][PATCH 2/2] proc: Add /proc/<pid>/timerslack_ns interface John Stultz

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®