<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/kernel, branch v3.4.7</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/kernel?h=v3.4.7</id>
<link rel='self' href='https://git.amat.us/linux/atom/kernel?h=v3.4.7'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2012-07-29T15:04:18Z</updated>
<entry>
<title>ntp: Fix STA_INS/DEL clearing bug</title>
<updated>2012-07-29T15:04:18Z</updated>
<author>
<name>John Stultz</name>
<email>johnstul@us.ibm.com</email>
</author>
<published>2012-07-13T05:21:50Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=fd25080998d00a94a87bf7fc9f843291db7250a6'/>
<id>urn:sha1:fd25080998d00a94a87bf7fc9f843291db7250a6</id>
<content type='text'>
commit 6b1859dba01c7d512b72d77e3fd7da8354235189 upstream.

In commit 6b43ae8a619d17c4935c3320d2ef9e92bdeed05d, I
introduced a bug that kept the STA_INS or STA_DEL bit
from being cleared from time_status via adjtimex()
without forcing STA_PLL first.

Usually once the STA_INS is set, it isn't cleared
until the leap second is applied, so its unlikely this
affected anyone. However during testing I noticed it
took some effort to cancel a leap second once STA_INS
was set.

Signed-off-by: John Stultz &lt;johnstul@us.ibm.com&gt;
Cc: Ingo Molnar &lt;mingo@kernel.org&gt;
Cc: Peter Zijlstra &lt;a.p.zijlstra@chello.nl&gt;
Cc: Richard Cochran &lt;richardcochran@gmail.com&gt;
Cc: Prarit Bhargava &lt;prarit@redhat.com&gt;
Link: http://lkml.kernel.org/r/1342156917-25092-2-git-send-email-john.stultz@linaro.org
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>timekeeping: Add missing update call in timekeeping_resume()</title>
<updated>2012-07-19T15:59:00Z</updated>
<author>
<name>Thomas Gleixner</name>
<email>tglx@linutronix.de</email>
</author>
<published>2012-07-17T06:39:56Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=3cdeda1e763ccb2287c6ee76ece14145027653a9'/>
<id>urn:sha1:3cdeda1e763ccb2287c6ee76ece14145027653a9</id>
<content type='text'>
This is a backport of 3e997130bd2e8c6f5aaa49d6e3161d4d29b43ab0

The leap second rework unearthed another issue of inconsistent data.

On timekeeping_resume() the timekeeper data is updated, but nothing
calls timekeeping_update(), so now the update code in the timer
interrupt sees stale values.

This has been the case before those changes, but then the timer
interrupt was using stale data as well so this went unnoticed for quite
some time.

Add the missing update call, so all the data is consistent everywhere.

Reported-by: Andreas Schwab &lt;schwab@linux-m68k.org&gt;
Reported-and-tested-by: "Rafael J. Wysocki" &lt;rjw@sisk.pl&gt;
Reported-and-tested-by: Martin Steigerwald &lt;Martin@lichtvoll.de&gt;
Cc: John Stultz &lt;johnstul@us.ibm.com&gt;
Cc: Ingo Molnar &lt;mingo@kernel.org&gt;
Cc: Peter Zijlstra &lt;a.p.zijlstra@chello.nl&gt;,
Cc: Prarit Bhargava &lt;prarit@redhat.com&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Signed-off-by: John Stultz &lt;johnstul@us.ibm.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: Prarit Bhargava &lt;prarit@redhat.com&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Signed-off-by: John Stultz &lt;johnstul@us.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>hrtimer: Update hrtimer base offsets each hrtimer_interrupt</title>
<updated>2012-07-19T15:59:00Z</updated>
<author>
<name>John Stultz</name>
<email>johnstul@us.ibm.com</email>
</author>
<published>2012-07-17T06:39:55Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=6321a0a1a3a9d6c9cbd73d9a4159a97ac3bc0919'/>
<id>urn:sha1:6321a0a1a3a9d6c9cbd73d9a4159a97ac3bc0919</id>
<content type='text'>
This is a backport of 5baefd6d84163443215f4a99f6a20f054ef11236

The update of the hrtimer base offsets on all cpus cannot be made
atomically from the timekeeper.lock held and interrupt disabled region
as smp function calls are not allowed there.

clock_was_set(), which enforces the update on all cpus, is called
either from preemptible process context in case of do_settimeofday()
or from the softirq context when the offset modification happened in
the timer interrupt itself due to a leap second.

In both cases there is a race window for an hrtimer interrupt between
dropping timekeeper lock, enabling interrupts and clock_was_set()
issuing the updates. Any interrupt which arrives in that window will
see the new time but operate on stale offsets.

So we need to make sure that an hrtimer interrupt always sees a
consistent state of time and offsets.

ktime_get_update_offsets() allows us to get the current monotonic time
and update the per cpu hrtimer base offsets from hrtimer_interrupt()
to capture a consistent state of monotonic time and the offsets. The
function replaces the existing ktime_get() calls in hrtimer_interrupt().

The overhead of the new function vs. ktime_get() is minimal as it just
adds two store operations.

This ensures that any changes to realtime or boottime offsets are
noticed and stored into the per-cpu hrtimer base structures, prior to
any hrtimer expiration and guarantees that timers are not expired early.

Signed-off-by: John Stultz &lt;johnstul@us.ibm.com&gt;
Reviewed-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Acked-by: Peter Zijlstra &lt;a.p.zijlstra@chello.nl&gt;
Acked-by: Prarit Bhargava &lt;prarit@redhat.com&gt;
Link: http://lkml.kernel.org/r/1341960205-56738-8-git-send-email-johnstul@us.ibm.com
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: Prarit Bhargava &lt;prarit@redhat.com&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Signed-off-by: John Stultz &lt;johnstul@us.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>timekeeping: Provide hrtimer update function</title>
<updated>2012-07-19T15:59:00Z</updated>
<author>
<name>Thomas Gleixner</name>
<email>tglx@linutronix.de</email>
</author>
<published>2012-07-17T06:39:54Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=765bdc4d82fadcddfec19222a545e904633c7816'/>
<id>urn:sha1:765bdc4d82fadcddfec19222a545e904633c7816</id>
<content type='text'>
This is a backport of f6c06abfb3972ad4914cef57d8348fcb2932bc3b

To finally fix the infamous leap second issue and other race windows
caused by functions which change the offsets between the various time
bases (CLOCK_MONOTONIC, CLOCK_REALTIME and CLOCK_BOOTTIME) we need a
function which atomically gets the current monotonic time and updates
the offsets of CLOCK_REALTIME and CLOCK_BOOTTIME with minimalistic
overhead. The previous patch which provides ktime_t offsets allows us
to make this function almost as cheap as ktime_get() which is going to
be replaced in hrtimer_interrupt().

Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Reviewed-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Acked-by: Peter Zijlstra &lt;a.p.zijlstra@chello.nl&gt;
Acked-by: Prarit Bhargava &lt;prarit@redhat.com&gt;
Signed-off-by: John Stultz &lt;johnstul@us.ibm.com&gt;
Link: http://lkml.kernel.org/r/1341960205-56738-7-git-send-email-johnstul@us.ibm.com
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: Prarit Bhargava &lt;prarit@redhat.com&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Signed-off-by: John Stultz &lt;johnstul@us.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>hrtimers: Move lock held region in hrtimer_interrupt()</title>
<updated>2012-07-19T15:58:59Z</updated>
<author>
<name>Thomas Gleixner</name>
<email>tglx@linutronix.de</email>
</author>
<published>2012-07-17T06:39:53Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=dd3cded0f516201d3b72999e588a6d67e00cb82f'/>
<id>urn:sha1:dd3cded0f516201d3b72999e588a6d67e00cb82f</id>
<content type='text'>
This is a backport of 196951e91262fccda81147d2bcf7fdab08668b40

We need to update the base offsets from this code and we need to do
that under base-&gt;lock. Move the lock held region around the
ktime_get() calls. The ktime_get() calls are going to be replaced with
a function which gets the time and the offsets atomically.

Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Reviewed-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Acked-by: Peter Zijlstra &lt;a.p.zijlstra@chello.nl&gt;
Acked-by: Prarit Bhargava &lt;prarit@redhat.com&gt;
Signed-off-by: John Stultz &lt;johnstul@us.ibm.com&gt;
Link: http://lkml.kernel.org/r/1341960205-56738-6-git-send-email-johnstul@us.ibm.com
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: Prarit Bhargava &lt;prarit@redhat.com&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Signed-off-by: John Stultz &lt;johnstul@us.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>timekeeping: Maintain ktime_t based offsets for hrtimers</title>
<updated>2012-07-19T15:58:59Z</updated>
<author>
<name>Thomas Gleixner</name>
<email>tglx@linutronix.de</email>
</author>
<published>2012-07-17T06:39:52Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=7d1f07113b1b32da1eabce0dc74d9f96bbb7b90a'/>
<id>urn:sha1:7d1f07113b1b32da1eabce0dc74d9f96bbb7b90a</id>
<content type='text'>
This is a backport of 5b9fe759a678e05be4937ddf03d50e950207c1c0

We need to update the hrtimer clock offsets from the hrtimer interrupt
context. To avoid conversions from timespec to ktime_t maintain a
ktime_t based representation of those offsets in the timekeeper. This
puts the conversion overhead into the code which updates the
underlying offsets and provides fast accessible values in the hrtimer
interrupt.

Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Signed-off-by: John Stultz &lt;johnstul@us.ibm.com&gt;
Reviewed-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Acked-by: Peter Zijlstra &lt;a.p.zijlstra@chello.nl&gt;
Acked-by: Prarit Bhargava &lt;prarit@redhat.com&gt;
Link: http://lkml.kernel.org/r/1341960205-56738-4-git-send-email-johnstul@us.ibm.com
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: Prarit Bhargava &lt;prarit@redhat.com&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Signed-off-by: John Stultz &lt;johnstul@us.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>timekeeping: Fix leapsecond triggered load spike issue</title>
<updated>2012-07-19T15:58:59Z</updated>
<author>
<name>John Stultz</name>
<email>johnstul@us.ibm.com</email>
</author>
<published>2012-07-17T06:39:51Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=2e947d469fba2c2036ff50a2e58a1875ab2ea6b6'/>
<id>urn:sha1:2e947d469fba2c2036ff50a2e58a1875ab2ea6b6</id>
<content type='text'>
This is a backport of 4873fa070ae84a4115f0b3c9dfabc224f1bc7c51

The timekeeping code misses an update of the hrtimer subsystem after a
leap second happened. Due to that timers based on CLOCK_REALTIME are
either expiring a second early or late depending on whether a leap
second has been inserted or deleted until an operation is initiated
which causes that update. Unless the update happens by some other
means this discrepancy between the timekeeping and the hrtimer data
stays forever and timers are expired either early or late.

The reported immediate workaround - $ data -s "`date`" - is causing a
call to clock_was_set() which updates the hrtimer data structures.
See: http://www.sheeri.com/content/mysql-and-leap-second-high-cpu-and-fix

Add the missing clock_was_set() call to update_wall_time() in case of
a leap second event. The actual update is deferred to softirq context
as the necessary smp function call cannot be invoked from hard
interrupt context.

Signed-off-by: John Stultz &lt;johnstul@us.ibm.com&gt;
Reported-by: Jan Engelhardt &lt;jengelh@inai.de&gt;
Reviewed-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Acked-by: Peter Zijlstra &lt;a.p.zijlstra@chello.nl&gt;
Acked-by: Prarit Bhargava &lt;prarit@redhat.com&gt;
Link: http://lkml.kernel.org/r/1341960205-56738-3-git-send-email-johnstul@us.ibm.com
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: Prarit Bhargava &lt;prarit@redhat.com&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Signed-off-by: John Stultz &lt;johnstul@us.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>hrtimer: Provide clock_was_set_delayed()</title>
<updated>2012-07-19T15:58:59Z</updated>
<author>
<name>John Stultz</name>
<email>johnstul@us.ibm.com</email>
</author>
<published>2012-07-17T06:39:50Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=5e5006e64cae9603841405af9febb67064869d83'/>
<id>urn:sha1:5e5006e64cae9603841405af9febb67064869d83</id>
<content type='text'>
This is a backport of f55a6faa384304c89cfef162768e88374d3312cb

clock_was_set() cannot be called from hard interrupt context because
it calls on_each_cpu().

For fixing the widely reported leap seconds issue it is necessary to
call it from hard interrupt context, i.e. the timer tick code, which
does the timekeeping updates.

Provide a new function which denotes it in the hrtimer cpu base
structure of the cpu on which it is called and raise the hrtimer
softirq. We then execute the clock_was_set() notificiation from
softirq context in run_hrtimer_softirq(). The hrtimer softirq is
rarely used, so polling the flag there is not a performance issue.

[ tglx: Made it depend on CONFIG_HIGH_RES_TIMERS. We really should get
  rid of all this ifdeffery ASAP ]

Signed-off-by: John Stultz &lt;johnstul@us.ibm.com&gt;
Reported-by: Jan Engelhardt &lt;jengelh@inai.de&gt;
Reviewed-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Acked-by: Peter Zijlstra &lt;a.p.zijlstra@chello.nl&gt;
Acked-by: Prarit Bhargava &lt;prarit@redhat.com&gt;
Link: http://lkml.kernel.org/r/1341960205-56738-2-git-send-email-johnstul@us.ibm.com
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: Prarit Bhargava &lt;prarit@redhat.com&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Signed-off-by: John Stultz &lt;johnstul@us.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>sched/nohz: Rewrite and fix load-avg computation -- again</title>
<updated>2012-07-19T15:58:56Z</updated>
<author>
<name>Peter Zijlstra</name>
<email>a.p.zijlstra@chello.nl</email>
</author>
<published>2012-06-22T13:52:09Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=7490d0a4cfefa16f9d8ce636eb5b2e13d2432db3'/>
<id>urn:sha1:7490d0a4cfefa16f9d8ce636eb5b2e13d2432db3</id>
<content type='text'>
commit 5167e8d5417bf5c322a703d2927daec727ea40dd upstream.

Thanks to Charles Wang for spotting the defects in the current code:

 - If we go idle during the sample window -- after sampling, we get a
   negative bias because we can negate our own sample.

 - If we wake up during the sample window we get a positive bias
   because we push the sample to a known active period.

So rewrite the entire nohz load-avg muck once again, now adding
copious documentation to the code.

Reported-and-tested-by: Doug Smythies &lt;dsmythies@telus.net&gt;
Reported-and-tested-by: Charles Wang &lt;muming.wq@gmail.com&gt;
Signed-off-by: Peter Zijlstra &lt;a.p.zijlstra@chello.nl&gt;
Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Link: http://lkml.kernel.org/r/1340373782.18025.74.camel@twins
[ minor edits ]
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>splice: fix racy pipe-&gt;buffers uses</title>
<updated>2012-07-16T16:04:42Z</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2012-06-12T13:24:40Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=2c07f25ea7800adb36cd8da9b58c4ecd3fc3d064'/>
<id>urn:sha1:2c07f25ea7800adb36cd8da9b58c4ecd3fc3d064</id>
<content type='text'>
commit 047fe3605235888f3ebcda0c728cb31937eadfe6 upstream.

Dave Jones reported a kernel BUG at mm/slub.c:3474! triggered
by splice_shrink_spd() called from vmsplice_to_pipe()

commit 35f3d14dbbc5 (pipe: add support for shrinking and growing pipes)
added capability to adjust pipe-&gt;buffers.

Problem is some paths don't hold pipe mutex and assume pipe-&gt;buffers
doesn't change for their duration.

Fix this by adding nr_pages_max field in struct splice_pipe_desc, and
use it in place of pipe-&gt;buffers where appropriate.

splice_shrink_spd() loses its struct pipe_inode_info argument.

Reported-by: Dave Jones &lt;davej@redhat.com&gt;
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Cc: Jens Axboe &lt;axboe@kernel.dk&gt;
Cc: Alexander Viro &lt;viro@zeniv.linux.org.uk&gt;
Cc: Tom Herbert &lt;therbert@google.com&gt;
Tested-by: Dave Jones &lt;davej@redhat.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
[bwh: Backported to 3.2:
 - Adjust context in vmsplice_to_pipe()
 - Update one more call to splice_shrink_spd(), from skb_splice_bits()]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
