<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/kernel, branch v3.4.5</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/kernel?h=v3.4.5</id>
<link rel='self' href='https://git.amat.us/linux/atom/kernel?h=v3.4.5'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2012-07-16T16:04:42Z</updated>
<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>
<entry>
<title>tracing: change CPU ring buffer state from tracing_cpumask</title>
<updated>2012-07-16T16:04:40Z</updated>
<author>
<name>Vaibhav Nagarnaik</name>
<email>vnagarnaik@google.com</email>
</author>
<published>2012-05-04T01:59:52Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=4943d9cb7d82218d196ccc034ecaf933298e7e95'/>
<id>urn:sha1:4943d9cb7d82218d196ccc034ecaf933298e7e95</id>
<content type='text'>
commit 71babb2705e2203a64c27ede13ae3508a0d2c16c upstream.

According to Documentation/trace/ftrace.txt:

tracing_cpumask:

        This is a mask that lets the user only trace
        on specified CPUS. The format is a hex string
        representing the CPUS.

The tracing_cpumask currently doesn't affect the tracing state of
per-CPU ring buffers.

This patch enables/disables CPU recording as its corresponding bit in
tracing_cpumask is set/unset.

Link: http://lkml.kernel.org/r/1336096792-25373-3-git-send-email-vnagarnaik@google.com

Cc: Frederic Weisbecker &lt;fweisbec@gmail.com&gt;
Cc: Ingo Molnar &lt;mingo@redhat.com&gt;
Cc: Laurent Chavey &lt;chavey@google.com&gt;
Cc: Justin Teravest &lt;teravest@google.com&gt;
Cc: David Sharp &lt;dhsharp@google.com&gt;
Signed-off-by: Vaibhav Nagarnaik &lt;vnagarnaik@google.com&gt;
Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mm: correctly synchronize rss-counters at exit/exec</title>
<updated>2012-07-16T16:04:08Z</updated>
<author>
<name>Konstantin Khlebnikov</name>
<email>khlebnikov@openvz.org</email>
</author>
<published>2012-06-20T19:53:01Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=21017faf87a93117ca7a14aa8f0dd2f315fdeb08'/>
<id>urn:sha1:21017faf87a93117ca7a14aa8f0dd2f315fdeb08</id>
<content type='text'>
commit 4fe7efdbdfb1c7e7a7f31decfd831c0f31d37091 upstream.

do_exit() and exec_mmap() call sync_mm_rss() before mm_release() does
put_user(clear_child_tid) which can update task-&gt;rss_stat and thus make
mm-&gt;rss_stat inconsistent.  This triggers the "BUG:" printk in check_mm().

Let's fix this bug in the safest way, and optimize/cleanup this later.

Reported-by: Markus Trippelsdorf &lt;markus@trippelsdorf.de&gt;
Signed-off-by: Konstantin Khlebnikov &lt;khlebnikov@openvz.org&gt;
Cc: Oleg Nesterov &lt;oleg@redhat.com&gt;
Cc: KAMEZAWA Hiroyuki &lt;kamezawa.hiroyu@jp.fujitsu.com&gt;
Cc: Hugh Dickins &lt;hughd@google.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ntp: Correct TAI offset during leap second</title>
<updated>2012-06-22T18:37:16Z</updated>
<author>
<name>Richard Cochran</name>
<email>richardcochran@gmail.com</email>
</author>
<published>2012-04-26T12:11:32Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=c17f648b6e8adb8379b2d2972e24953285332f44'/>
<id>urn:sha1:c17f648b6e8adb8379b2d2972e24953285332f44</id>
<content type='text'>
commit dd48d708ff3e917f6d6b6c2b696c3f18c019feed upstream.

When repeating a UTC time value during a leap second (when the UTC
time should be 23:59:60), the TAI timescale should not stop. The kernel
NTP code increments the TAI offset one second too late. This patch fixes
the issue by incrementing the offset during the leap second itself.

Signed-off-by: Richard Cochran &lt;richardcochran@gmail.com&gt;
Signed-off-by: John Stultz &lt;john.stultz@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>kdump: Execute kmsg_dump(KMSG_DUMP_PANIC) after smp_send_stop()</title>
<updated>2012-06-22T18:36:56Z</updated>
<author>
<name>Seiji Aguchi</name>
<email>seiji.aguchi@hds.com</email>
</author>
<published>2012-05-15T21:35:09Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=d64cbbc9603861015cd616327f63b10394c0418a'/>
<id>urn:sha1:d64cbbc9603861015cd616327f63b10394c0418a</id>
<content type='text'>
commit 62be73eafaa045d3233337303fb140f7f8a61135 upstream.

This patch moves kmsg_dump(KMSG_DUMP_PANIC) below smp_send_stop(),
to serialize the crash-logging process via smp_send_stop() and to
thus retrieve a more stable crash image of all CPUs stopped.

Signed-off-by: Seiji Aguchi &lt;seiji.aguchi@hds.com&gt;
Acked-by: Don Zickus &lt;dzickus@redhat.com&gt;
Cc: dle-develop@lists.sourceforge.net &lt;dle-develop@lists.sourceforge.net&gt;
Cc: Satoru Moriya &lt;satoru.moriya@hds.com&gt;
Cc: Tony Luck &lt;tony.luck@intel.com&gt;
Cc: a.p.zijlstra@chello.nl &lt;a.p.zijlstra@chello.nl&gt;
Link: http://lkml.kernel.org/r/5C4C569E8A4B9B42A84A977CF070A35B2E4D7A5CE2@USINDEVS01.corp.hds.com
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>tracing: Have tracing_off() actually turn tracing off</title>
<updated>2012-06-22T18:36:55Z</updated>
<author>
<name>Steven Rostedt</name>
<email>srostedt@redhat.com</email>
</author>
<published>2012-06-06T23:50:40Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=3993b24649773080897fde524ea2d9f311eba2aa'/>
<id>urn:sha1:3993b24649773080897fde524ea2d9f311eba2aa</id>
<content type='text'>
commit f2bf1f6f5f89d031245067512449fc889b2f4bb2 upstream.

A recent update to have tracing_on/off() only affect the ftrace ring
buffers instead of all ring buffers had a cut and paste error.
The tracing_off() did the exact same thing as tracing_on() and
would not actually turn off tracing. Unfortunately, tracing_off()
is more important to be working than tracing_on() as this is a key
development tool, as it lets the developer turn off tracing as soon
as a problem is discovered. It is also used by panic and oops code.

This bug also breaks the 'echo func:traceoff &gt; set_ftrace_filter'

Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>sched: Fix the relax_domain_level boot parameter</title>
<updated>2012-06-17T18:21:28Z</updated>
<author>
<name>Dimitri Sivanich</name>
<email>sivanich@sgi.com</email>
</author>
<published>2012-06-05T18:44:36Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=8997b2223b9d81f6085764d08f9de3a2da760333'/>
<id>urn:sha1:8997b2223b9d81f6085764d08f9de3a2da760333</id>
<content type='text'>
commit a841f8cef4bb124f0f5563314d0beaf2e1249d72 upstream.

It does not get processed because sched_domain_level_max is 0 at the
time that setup_relax_domain_level() is run.

Simply accept the value as it is, as we don't know the value of
sched_domain_level_max until sched domain construction is completed.

Fix sched_relax_domain_level in cpuset.  The build_sched_domain() routine calls
the set_domain_attribute() routine prior to setting the sd-&gt;level, however,
the set_domain_attribute() routine relies on the sd-&gt;level to decide whether
idle load balancing will be off/on.

Signed-off-by: Dimitri Sivanich &lt;sivanich@sgi.com&gt;
Signed-off-by: Peter Zijlstra &lt;a.p.zijlstra@chello.nl&gt;
Link: http://lkml.kernel.org/r/20120605184436.GA15668@sgi.com
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>timekeeping: Fix CLOCK_MONOTONIC inconsistency during leapsecond</title>
<updated>2012-06-17T18:21:23Z</updated>
<author>
<name>John Stultz</name>
<email>john.stultz@linaro.org</email>
</author>
<published>2012-05-30T17:54:57Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=d913c02b0a172d5dca6280da5b17a407d69bbce4'/>
<id>urn:sha1:d913c02b0a172d5dca6280da5b17a407d69bbce4</id>
<content type='text'>
commit fad0c66c4bb836d57a5f125ecd38bed653ca863a upstream.

Commit 6b43ae8a61 (ntp: Fix leap-second hrtimer livelock) broke the
leapsecond update of CLOCK_MONOTONIC. The missing leapsecond update to
wall_to_monotonic causes discontinuities in CLOCK_MONOTONIC.

Adjust wall_to_monotonic when NTP inserted a leapsecond.

Reported-by: Richard Cochran &lt;richardcochran@gmail.com&gt;
Signed-off-by: John Stultz &lt;john.stultz@linaro.org&gt;
Tested-by: Richard Cochran &lt;richardcochran@gmail.com&gt;
Link: http://lkml.kernel.org/r/1338400497-12420-1-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>mm/fork: fix overflow in vma length when copying mmap on clone</title>
<updated>2012-06-09T15:36:06Z</updated>
<author>
<name>Siddhesh Poyarekar</name>
<email>siddhesh.poyarekar@gmail.com</email>
</author>
<published>2012-05-29T22:06:22Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=3876c722319d9b8463b9e82394d81f6d0c45021e'/>
<id>urn:sha1:3876c722319d9b8463b9e82394d81f6d0c45021e</id>
<content type='text'>
commit 7edc8b0ac16cbaed7cb4ea4c6b95ce98d2997e84 upstream.

The vma length in dup_mmap is calculated and stored in a unsigned int,
which is insufficient and hence overflows for very large maps (beyond
16TB). The following program demonstrates this:

#include &lt;stdio.h&gt;
#include &lt;unistd.h&gt;
#include &lt;sys/mman.h&gt;

#define GIG 1024 * 1024 * 1024L
#define EXTENT 16393

int main(void)
{
        int i, r;
        void *m;
        char buf[1024];

        for (i = 0; i &lt; EXTENT; i++) {
                m = mmap(NULL, (size_t) 1 * 1024 * 1024 * 1024L,
                         PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, 0, 0);

                if (m == (void *)-1)
                        printf("MMAP Failed: %d\n", m);
                else
                        printf("%d : MMAP returned %p\n", i, m);

                r = fork();

                if (r == 0) {
                        printf("%d: successed\n", i);
                        return 0;
                } else if (r &lt; 0)
                        printf("FORK Failed: %d\n", r);
                else if (r &gt; 0)
                        wait(NULL);
        }
        return 0;
}

Increase the storage size of the result to unsigned long, which is
sufficient for storing the difference between addresses.

Signed-off-by: Siddhesh Poyarekar &lt;siddhesh.poyarekar@gmail.com&gt;
Cc: Tejun Heo &lt;tj@kernel.org&gt;
Cc: Oleg Nesterov &lt;oleg@redhat.com&gt;
Cc: Jens Axboe &lt;axboe@kernel.dk&gt;
Cc: Peter Zijlstra &lt;a.p.zijlstra@chello.nl&gt;
Acked-by: Hugh Dickins &lt;hughd@google.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>workqueue: skip nr_running sanity check in worker_enter_idle() if trustee is active</title>
<updated>2012-06-01T07:18:19Z</updated>
<author>
<name>Tejun Heo</name>
<email>tj@kernel.org</email>
</author>
<published>2012-05-14T22:04:50Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=24312d34c95702e51240f58c073db30630170fbf'/>
<id>urn:sha1:24312d34c95702e51240f58c073db30630170fbf</id>
<content type='text'>
commit 544ecf310f0e7f51fa057ac2a295fc1b3b35a9d3 upstream.

worker_enter_idle() has WARN_ON_ONCE() which triggers if nr_running
isn't zero when every worker is idle.  This can trigger spuriously
while a cpu is going down due to the way trustee sets %WORKER_ROGUE
and zaps nr_running.

It first sets %WORKER_ROGUE on all workers without updating
nr_running, releases gcwq-&gt;lock, schedules, regrabs gcwq-&gt;lock and
then zaps nr_running.  If the last running worker enters idle
inbetween, it would see stale nr_running which hasn't been zapped yet
and trigger the WARN_ON_ONCE().

Fix it by performing the sanity check iff the trustee is idle.

Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Reported-by: "Paul E. McKenney" &lt;paulmck@linux.vnet.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
