linux-stable.git/kernel/time, branch linux-3.17.y

posix-timers: Fix stack info leak in timer_create()

2014-11-14T18:10:38+00:00

commit 6891c4509c792209c44ced55a60f13954cb50ef4 upstream.

If userland creates a timer without specifying a sigevent info, we'll
create one ourself, using a stack local variable. Particularly will we
use the timer ID as sival_int. But as sigev_value is a union containing
a pointer and an int, that assignment will only partially initialize
sigev_value on systems where the size of a pointer is bigger than the
size of an int. On such systems we'll copy the uninitialized stack bytes
from the timer_create() call to userland when the timer actually fires
and we're going to deliver the signal.

Initialize sigev_value with 0 to plug the stack info leak.

Found in the PaX patch, written by the PaX Team.

Fixes: 5a9fa7307285 ("posix-timers: kill ->it_sigev_signo and...")
Signed-off-by: Mathias Krause 
Cc: Oleg Nesterov 
Cc: Brad Spengler 
Cc: PaX Team 
Link: http://lkml.kernel.org/r/1412456799-32339-1-git-send-email-minipli@googlemail.com
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

irq_work: Force raised irq work to run on irq work interrupt

2014-10-15T10:29:23+00:00

commit 76a33061b9323b7fdb220ae5fa116c10833ec22e upstream.

The nohz full kick, which restarts the tick when any resource depend
on it, can't be executed anywhere given the operation it does on timers.
If it is called from the scheduler or timers code, chances are that
we run into a deadlock.

This is why we run the nohz full kick from an irq work. That way we make
sure that the kick runs on a virgin context.

However if that's the case when irq work runs in its own dedicated
self-ipi, things are different for the big bunch of archs that don't
support the self triggered way. In order to support them, irq works are
also handled by the timer interrupt as fallback.

Now when irq works run on the timer interrupt, the context isn't blank.
More precisely, they can run in the context of the hrtimer that runs the
tick. But the nohz kick cancels and restarts this hrtimer and cancelling
an hrtimer from itself isn't allowed. This is why we run in an endless
loop:

	Kernel panic - not syncing: Watchdog detected hard LOCKUP on cpu 2
	CPU: 2 PID: 7538 Comm: kworker/u8:8 Not tainted 3.16.0+ #34
	Workqueue: btrfs-endio-write normal_work_helper [btrfs]
	 ffff880244c06c88 000000001b486fe1 ffff880244c06bf0 ffffffff8a7f1e37
	 ffffffff8ac52a18 ffff880244c06c78 ffffffff8a7ef928 0000000000000010
	 ffff880244c06c88 ffff880244c06c20 000000001b486fe1 0000000000000000
	Call Trace:
	 ] dump_stack+0x4e/0x7a
	 [] panic+0xd4/0x207
	 [] watchdog_overflow_callback+0x118/0x120
	 [] __perf_event_overflow+0xae/0x350
	 [] ? perf_event_task_disable+0xa0/0xa0
	 [] ? x86_perf_event_set_period+0xbf/0x150
	 [] perf_event_overflow+0x14/0x20
	 [] intel_pmu_handle_irq+0x206/0x410
	 [] perf_event_nmi_handler+0x2b/0x50
	 [] nmi_handle+0xd2/0x390
	 [] ? nmi_handle+0x5/0x390
	 [] ? match_held_lock+0x8/0x1b0
	 [] default_do_nmi+0x72/0x1c0
	 [] do_nmi+0xb8/0x100
	 [] end_repeat_nmi+0x1e/0x2e
	 [] ? match_held_lock+0x8/0x1b0
	 [] ? match_held_lock+0x8/0x1b0
	 [] ? match_held_lock+0x8/0x1b0
	 <] lock_acquired+0xaf/0x450
	 [] ? lock_hrtimer_base.isra.20+0x25/0x50
	 [] _raw_spin_lock_irqsave+0x78/0x90
	 [] ? lock_hrtimer_base.isra.20+0x25/0x50
	 [] lock_hrtimer_base.isra.20+0x25/0x50
	 [] hrtimer_try_to_cancel+0x33/0x1e0
	 [] hrtimer_cancel+0x1a/0x30
	 [] tick_nohz_restart+0x17/0x90
	 [] __tick_nohz_full_check+0xc3/0x100
	 [] nohz_full_kick_work_func+0xe/0x10
	 [] irq_work_run_list+0x44/0x70
	 [] irq_work_run+0x2a/0x50
	 [] update_process_times+0x5b/0x70
	 [] tick_sched_handle.isra.21+0x25/0x60
	 [] tick_sched_timer+0x41/0x60
	 [] __run_hrtimer+0x72/0x470
	 [] ? tick_sched_do_timer+0xb0/0xb0
	 [] hrtimer_interrupt+0x117/0x270
	 [] local_apic_timer_interrupt+0x37/0x60
	 [] smp_apic_timer_interrupt+0x3f/0x50
	 [] apic_timer_interrupt+0x6f/0x80

To fix this we force non-lazy irq works to run on irq work self-IPIs
when available. That ability of the arch to trigger irq work self IPIs
is available with arch_irq_work_has_interrupt().

Reported-by: Catalin Iacob 
Reported-by: Dave Jones 
Acked-by: Peter Zijlstra (Intel) 
Cc: Ingo Molnar 
Cc: Paul E. McKenney 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Signed-off-by: Frederic Weisbecker 
Signed-off-by: Greg Kroah-Hartman

alarmtimer: Lock k_itimer during timer callback

2014-09-12T20:59:12+00:00

Locks the k_itimer's it_lock member when handling the alarm timer's
expiry callback.

The regular posix timers defined in posix-timers.c have this lock held
during timout processing because their callbacks are routed through
posix_timer_fn().  The alarm timers follow a different path, so they
ought to grab the lock somewhere else.

Cc: stable@vger.kernel.org
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Richard Cochran 
Cc: Prarit Bhargava 
Cc: Sharvil Nanavati 
Signed-off-by: Richard Larocque 
Signed-off-by: John Stultz

alarmtimer: Do not signal SIGEV_NONE timers

2014-09-12T20:59:12+00:00

Avoids sending a signal to alarm timers created with sigev_notify set to
SIGEV_NONE by checking for that special case in the timeout callback.

The regular posix timers avoid sending signals to SIGEV_NONE timers by
not scheduling any callbacks for them in the first place.  Although it
would be possible to do something similar for alarm timers, it's simpler
to handle this as a special case in the timeout.

Prior to this patch, the alarm timer would ignore the sigev_notify value
and try to deliver signals to the process anyway.  Even worse, the
sanity check for the value of sigev_signo is skipped when SIGEV_NONE was
specified, so the signal number could be bogus.  If sigev_signo was an
unitialized value (as it often would be if SIGEV_NONE is used), then
it's hard to predict which signal will be sent.

Cc: stable@vger.kernel.org
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Richard Cochran 
Cc: Prarit Bhargava 
Cc: Sharvil Nanavati 
Signed-off-by: Richard Larocque 
Signed-off-by: John Stultz

alarmtimer: Return relative times in timer_gettime

2014-09-12T20:59:11+00:00

Returns the time remaining for an alarm timer, rather than the time at
which it is scheduled to expire.  If the timer has already expired or it
is not currently scheduled, the it_value's members are set to zero.

This new behavior matches that of the other posix-timers and the POSIX
specifications.

This is a change in user-visible behavior, and may break existing
applications.  Hopefully, few users rely on the old incorrect behavior.

Cc: stable@vger.kernel.org
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Richard Cochran 
Cc: Prarit Bhargava 
Cc: Sharvil Nanavati 
Signed-off-by: Richard Larocque 
[jstultz: minor style tweak]
Signed-off-by: John Stultz

jiffies: Fix timeval conversion to jiffies

2014-09-12T20:59:03+00:00

timeval_to_jiffies tried to round a timeval up to an integral number
of jiffies, but the logic for doing so was incorrect: intervals
corresponding to exactly N jiffies would become N+1. This manifested
itself particularly repeatedly stopping/starting an itimer:

setitimer(ITIMER_PROF, &val, NULL);
setitimer(ITIMER_PROF, NULL, &val);

would add a full tick to val, _even if it was exactly representable in
terms of jiffies_ (say, the result of a previous rounding.)  Doing
this repeatedly would cause unbounded growth in val.  So fix the math.

Here's what was wrong with the conversion: we essentially computed
(eliding seconds)

jiffies = usec  * (NSEC_PER_USEC/TICK_NSEC)

by using scaling arithmetic, which took the best approximation of
NSEC_PER_USEC/TICK_NSEC with denominator of 2^USEC_JIFFIE_SC =
x/(2^USEC_JIFFIE_SC), and computed:

jiffies = (usec * x) >> USEC_JIFFIE_SC

and rounded this calculation up in the intermediate form (since we
can't necessarily exactly represent TICK_NSEC in usec.) But the
scaling arithmetic is a (very slight) *over*approximation of the true
value; that is, instead of dividing by (1 usec/ 1 jiffie), we
effectively divided by (1 usec/1 jiffie)-epsilon (rounding
down). This would normally be fine, but we want to round timeouts up,
and we did so by adding 2^USEC_JIFFIE_SC - 1 before the shift; this
would be fine if our division was exact, but dividing this by the
slightly smaller factor was equivalent to adding just _over_ 1 to the
final result (instead of just _under_ 1, as desired.)

In particular, with HZ=1000, we consistently computed that 10000 usec
was 11 jiffies; the same was true for any exact multiple of
TICK_NSEC.

We could possibly still round in the intermediate form, adding
something less than 2^USEC_JIFFIE_SC - 1, but easier still is to
convert usec->nsec, round in nanoseconds, and then convert using
time*spec*_to_jiffies.  This adds one constant multiplication, and is
not observably slower in microbenchmarks on recent x86 hardware.

Tested: the following program:

int main() {
  struct itimerval zero = {{0, 0}, {0, 0}};
  /* Initially set to 10 ms. */
  struct itimerval initial = zero;
  initial.it_interval.tv_usec = 10000;
  setitimer(ITIMER_PROF, &initial, NULL);
  /* Save and restore several times. */
  for (size_t i = 0; i < 10; ++i) {
    struct itimerval prev;
    setitimer(ITIMER_PROF, &zero, &prev);
    /* on old kernels, this goes up by TICK_USEC every iteration */
    printf("previous value: %ld %ld %ld %ld\n",
           prev.it_interval.tv_sec, prev.it_interval.tv_usec,
           prev.it_value.tv_sec, prev.it_value.tv_usec);
    setitimer(ITIMER_PROF, &prev, NULL);
  }
    return 0;
}

Cc: stable@vger.kernel.org
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Paul Turner 
Cc: Richard Cochran 
Cc: Prarit Bhargava 
Reviewed-by: Paul Turner 
Reported-by: Aaron Jacobs 
Signed-off-by: Andrew Hunter 
[jstultz: Tweaked to apply to 3.17-rc]
Signed-off-by: John Stultz

timekeeping: Update timekeeper before updating vsyscall and pvclock

2014-09-06T10:58:18+00:00

The update_walltime() code works on the shadow timekeeper to make the
seqcount protected region as short as possible. But that update to the
shadow timekeeper does not update all timekeeper fields because it's
sufficient to do that once before it becomes life. One of these fields
is tkr.base_mono. That stays stale in the shadow timekeeper unless an
operation happens which copies the real timekeeper to the shadow.

The update function is called after the update calls to vsyscall and
pvclock. While not correct, it did not cause any problems because none
of the invoked update functions used base_mono.

commit cbcf2dd3b3d4 (x86: kvm: Make kvm_get_time_and_clockread()
nanoseconds based) changed that in the kvm pvclock update function, so
the stale mono_base value got used and caused kvm-clock to malfunction.

Put the update where it belongs and fix the issue.

Reported-by: Chris J Arges 
Reported-by: Paolo Bonzini 
Cc: Gleb Natapov 
Cc: John Stultz 
Link: http://lkml.kernel.org/r/alpine.DEB.2.10.1409050000570.3333@nanos
Signed-off-by: Thomas Gleixner

nohz: Restore NMI safe local irq work for local nohz kick

2014-09-04T20:35:59+00:00

The local nohz kick is currently used by perf which needs it to be
NMI-safe. Recent commit though (7d1311b93e58ed55f3a31cc8f94c4b8fe988a2b9)
changed its implementation to fire the local kick using the remote kick
API. It was convenient to make the code more generic but the remote kick
isn't NMI-safe.

As a result:

	WARNING: CPU: 3 PID: 18062 at kernel/irq_work.c:72 irq_work_queue_on+0x11e/0x140()
	CPU: 3 PID: 18062 Comm: trinity-subchil Not tainted 3.16.0+ #34
	0000000000000009 00000000903774d1 ffff880244e06c00 ffffffff9a7f1e37
	0000000000000000 ffff880244e06c38 ffffffff9a0791dd ffff880244fce180
	0000000000000003 ffff880244e06d58 ffff880244e06ef8 0000000000000000
	Call Trace:
	  [] dump_stack+0x4e/0x7a
	[] warn_slowpath_common+0x7d/0xa0
	[] warn_slowpath_null+0x1a/0x20
	[] irq_work_queue_on+0x11e/0x140
	[] tick_nohz_full_kick_cpu+0x57/0x90
	[] __perf_event_overflow+0x275/0x350
	[] ? perf_event_task_disable+0xa0/0xa0
	[] ? x86_perf_event_set_period+0xbf/0x150
	[] perf_event_overflow+0x14/0x20
	[] intel_pmu_handle_irq+0x206/0x410
	[] ? arch_vtime_task_switch+0x63/0x130
	[] perf_event_nmi_handler+0x2b/0x50
	[] nmi_handle+0xd2/0x390
	[] ? nmi_handle+0x5/0x390
	[] ? lock_release+0xab/0x330
	[] default_do_nmi+0x72/0x1c0
	[] ? cpuacct_account_field+0xcf/0x200
	[] do_nmi+0xb8/0x100

Lets fix this by restoring the use of local irq work for the nohz local
kick.

Reported-by: Catalin Iacob 
Reported-and-tested-by: Dave Jones 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Signed-off-by: Frederic Weisbecker

timekeeping: Another fix to the VSYSCALL_OLD update_vsyscall

2014-08-14T17:04:11+00:00

Benjamin Herrenschmidt pointed out that I further missed modifying
update_vsyscall after the wall_to_mono value was changed to a
timespec64.  This causes issues on powerpc32, which expects a 32bit
timespec.

This patch fixes the problem by properly converting from a timespec64 to
a timespec before passing the value on to the arch-specific vsyscall
logic.

[ Thomas is currently on vacation, but reviewed it and wanted me to send
  this fix on to you directly. ]

Cc: LKML 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Benjamin Herrenschmidt 
Reported-by: Benjamin Herrenschmidt 
Reviewed-by: Thomas Gleixner 
Signed-off-by: John Stultz 
Signed-off-by: Linus Torvalds

Merge branch 'timers-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2014-08-06T00:46:42+00:00

Pull timer and time updates from Thomas Gleixner:
"A rather large update of timers, timekeeping & co

- Core timekeeping code is year-2038 safe now for 32bit machines.
Now we just need to fix all in kernel users and the gazillion of
user space interfaces which rely on timespec/timeval :)

- Better cache layout for the timekeeping internal data structures.

- Proper nanosecond based interfaces for in kernel users.

- Tree wide cleanup of code which wants nanoseconds but does hoops
and loops to convert back and forth from timespecs. Some of it
definitely belongs into the ugly code museum.

- Consolidation of the timekeeping interface zoo.

- A fast NMI safe accessor to clock monotonic for tracing. This is a
long standing request to support correlated user/kernel space
traces. With proper NTP frequency correction it's also suitable
for correlation of traces accross separate machines.

- Checkpoint/restart support for timerfd.

- A few NOHZ[_FULL] improvements in the [hr]timer code.

- Code move from kernel to kernel/time of all time* related code.

- New clocksource/event drivers from the ARM universe. I'm really
impressed that despite an architected timer in the newer chips SoC
manufacturers insist on inventing new and differently broken SoC
specific timers.

[ Ed. "Impressed"? I don't think that word means what you think it means ]

- Another round of code move from arch to drivers. Looks like most
of the legacy mess in ARM regarding timers is sorted out except for
a few obnoxious strongholds.

- The usual updates and fixlets all over the place"

* 'timers-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (114 commits)
timekeeping: Fixup typo in update_vsyscall_old definition
clocksource: document some basic timekeeping concepts
timekeeping: Use cached ntp_tick_length when accumulating error
timekeeping: Rework frequency adjustments to work better w/ nohz
timekeeping: Minor fixup for timespec64->timespec assignment
ftrace: Provide trace clocks monotonic
timekeeping: Provide fast and NMI safe access to CLOCK_MONOTONIC
seqcount: Add raw_write_seqcount_latch()
seqcount: Provide raw_read_seqcount()
timekeeping: Use tk_read_base as argument for timekeeping_get_ns()
timekeeping: Create struct tk_read_base and use it in struct timekeeper
timekeeping: Restructure the timekeeper some more
clocksource: Get rid of cycle_last
clocksource: Move cycle_last validation to core code
clocksource: Make delta calculation a function
wireless: ath9k: Get rid of timespec conversions
drm: vmwgfx: Use nsec based interfaces
drm: i915: Use nsec based interfaces
timekeeping: Provide ktime_get_raw()
hangcheck-timer: Use ktime_get_ns()
...