<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/kernel, branch v4.4.2</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.4.2</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.4.2'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2016-02-17T20:31:02Z</updated>
<entry>
<title>sched: Fix crash in sched_init_numa()</title>
<updated>2016-02-17T20:31:02Z</updated>
<author>
<name>Raghavendra K T</name>
<email>raghavendra.kt@linux.vnet.ibm.com</email>
</author>
<published>2016-01-15T19:01:23Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=a800cbddbc2042b042491867e96e2f3c5c0d3e3b'/>
<id>urn:sha1:a800cbddbc2042b042491867e96e2f3c5c0d3e3b</id>
<content type='text'>
commit 9c03ee147193645be4c186d3688232fa438c57c7 upstream.

The following PowerPC commit:

  c118baf80256 ("arch/powerpc/mm/numa.c: do not allocate bootmem memory for non existing nodes")

avoids allocating bootmem memory for non existent nodes.

But when DEBUG_PER_CPU_MAPS=y is enabled, my powerNV system failed to boot
because in sched_init_numa(), cpumask_or() operation was done on
unallocated nodes.

Fix that by making cpumask_or() operation only on existing nodes.

[ Tested with and w/o DEBUG_PER_CPU_MAPS=y on x86 and PowerPC. ]

Reported-by: Jan Stancek &lt;jstancek@redhat.com&gt;
Tested-by: Jan Stancek &lt;jstancek@redhat.com&gt;
Signed-off-by: Raghavendra K T &lt;raghavendra.kt@linux.vnet.ibm.com&gt;
Cc: &lt;gkurz@linux.vnet.ibm.com&gt;
Cc: &lt;grant.likely@linaro.org&gt;
Cc: &lt;nikunj@linux.vnet.ibm.com&gt;
Cc: &lt;vdavydov@parallels.com&gt;
Cc: &lt;linuxppc-dev@lists.ozlabs.org&gt;
Cc: &lt;linux-mm@kvack.org&gt;
Cc: &lt;peterz@infradead.org&gt;
Cc: &lt;benh@kernel.crashing.org&gt;
Cc: &lt;paulus@samba.org&gt;
Cc: &lt;mpe@ellerman.id.au&gt;
Cc: &lt;anton@samba.org&gt;
Link: http://lkml.kernel.org/r/1452884483-11676-1-git-send-email-raghavendra.kt@linux.vnet.ibm.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>hrtimer: Handle remaining time proper for TIME_LOW_RES</title>
<updated>2016-02-17T20:30:57Z</updated>
<author>
<name>Thomas Gleixner</name>
<email>tglx@linutronix.de</email>
</author>
<published>2016-01-14T16:54:46Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=dd0d511548ea1ad8f233e9fa4a4acfb83af9bd29'/>
<id>urn:sha1:dd0d511548ea1ad8f233e9fa4a4acfb83af9bd29</id>
<content type='text'>
commit 203cbf77de59fc8f13502dcfd11350c6d4a5c95f upstream.

If CONFIG_TIME_LOW_RES is enabled we add a jiffie to the relative timeout to
prevent short sleeps, but we do not account for that in interfaces which
retrieve the remaining time.

Helge observed that timerfd can return a remaining time larger than the
relative timeout. That's not expected and breaks userland test programs.

Store the information that the timer was armed relative and provide functions
to adjust the remaining time. To avoid bloating the hrtimer struct make state
a u8, which as a bonus results in better code on x86 at least.

Reported-and-tested-by: Helge Deller &lt;deller@gmx.de&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: John Stultz &lt;john.stultz@linaro.org&gt;
Cc: linux-m68k@lists.linux-m68k.org
Cc: dhowells@redhat.com
Link: http://lkml.kernel.org/r/20160114164159.273328486@linutronix.de
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>printk: do cond_resched() between lines while outputting to consoles</title>
<updated>2016-02-17T20:30:57Z</updated>
<author>
<name>Tejun Heo</name>
<email>tj@kernel.org</email>
</author>
<published>2016-01-16T00:58:24Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=a623f87a72de35096a9eae7cc7764d0c9533c2e9'/>
<id>urn:sha1:a623f87a72de35096a9eae7cc7764d0c9533c2e9</id>
<content type='text'>
commit 8d91f8b15361dfb438ab6eb3b319e2ded43458ff upstream.

@console_may_schedule tracks whether console_sem was acquired through
lock or trylock.  If the former, we're inside a sleepable context and
console_conditional_schedule() performs cond_resched().  This allows
console drivers which use console_lock for synchronization to yield
while performing time-consuming operations such as scrolling.

However, the actual console outputting is performed while holding
irq-safe logbuf_lock, so console_unlock() clears @console_may_schedule
before starting outputting lines.  Also, only a few drivers call
console_conditional_schedule() to begin with.  This means that when a
lot of lines need to be output by console_unlock(), for example on a
console registration, the task doing console_unlock() may not yield for
a long time on a non-preemptible kernel.

If this happens with a slow console devices, for example a serial
console, the outputting task may occupy the cpu for a very long time.
Long enough to trigger softlockup and/or RCU stall warnings, which in
turn pile more messages, sometimes enough to trigger the next cycle of
warnings incapacitating the system.

Fix it by making console_unlock() insert cond_resched() between lines if
@console_may_schedule.

Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Reported-by: Calvin Owens &lt;calvinowens@fb.com&gt;
Acked-by: Jan Kara &lt;jack@suse.com&gt;
Cc: Dave Jones &lt;davej@codemonkey.org.uk&gt;
Cc: Kyle McMartin &lt;kyle@kernel.org&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>tracing/stacktrace: Show entire trace if passed in function not found</title>
<updated>2016-02-17T20:30:57Z</updated>
<author>
<name>Steven Rostedt</name>
<email>rostedt@goodmis.org</email>
</author>
<published>2016-01-29T15:22:41Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=bf46aa7ec7417cab8b4402dc8117e17af54f5d8e'/>
<id>urn:sha1:bf46aa7ec7417cab8b4402dc8117e17af54f5d8e</id>
<content type='text'>
commit 6ccd83714a009ee301b50c15f6c3a5dc1f30164c upstream.

When a max stack trace is discovered, the stack dump is saved. In order to
not record the overhead of the stack tracer, the ip of the traced function
is looked for within the dump. The trace is started from the location of
that function. But if for some reason the ip is not found, the entire stack
trace is then truncated. That's not very useful. Instead, print everything
if the ip of the traced function is not found within the trace.

This issue showed up on s390.

Link: http://lkml.kernel.org/r/20160129102241.1b3c9c04@gandalf.local.home

Fixes: 72ac426a5bb0 ("tracing: Clean up stack tracing and fix fentry updates")
Reported-by: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
Tested-by: Heiko Carstens &lt;heiko.carstens@de.ibm.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>tracing: Fix stacktrace skip depth in trace_buffer_unlock_commit_regs()</title>
<updated>2016-02-17T20:30:56Z</updated>
<author>
<name>Steven Rostedt (Red Hat)</name>
<email>rostedt@goodmis.org</email>
</author>
<published>2016-01-13T20:48:54Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=cc6d98006b1a713abaa8852de02a3c6f7ce62941'/>
<id>urn:sha1:cc6d98006b1a713abaa8852de02a3c6f7ce62941</id>
<content type='text'>
commit 7717c6be699975f6733d278b13b7c4295d73caf6 upstream.

While cleaning the stacktrace code I unintentially changed the skip depth of
trace_buffer_unlock_commit_regs() from 0 to 6. kprobes uses this function,
and with skipping 6 call backs, it can easily produce no stack.

Here's how I tested it:

 # echo 'p:ext4_sync_fs ext4_sync_fs ' &gt; /sys/kernel/debug/tracing/kprobe_events
 # echo 1 &gt; /sys/kernel/debug/tracing/events/kprobes/enable
 # cat /sys/kernel/debug/trace
            sync-2394  [005]   502.457060: ext4_sync_fs: (ffffffff81317650)
            sync-2394  [005]   502.457063: kernel_stack:         &lt;stack trace&gt;
            sync-2394  [005]   502.457086: ext4_sync_fs: (ffffffff81317650)
            sync-2394  [005]   502.457087: kernel_stack:         &lt;stack trace&gt;
            sync-2394  [005]   502.457091: ext4_sync_fs: (ffffffff81317650)

After putting back the skip stack to zero, we have:

            sync-2270  [000]   748.052693: ext4_sync_fs: (ffffffff81317650)
            sync-2270  [000]   748.052695: kernel_stack:         &lt;stack trace&gt;
 =&gt; iterate_supers (ffffffff8126412e)
 =&gt; sys_sync (ffffffff8129c4b6)
 =&gt; entry_SYSCALL_64_fastpath (ffffffff8181f0b2)
            sync-2270  [000]   748.053017: ext4_sync_fs: (ffffffff81317650)
            sync-2270  [000]   748.053019: kernel_stack:         &lt;stack trace&gt;
 =&gt; iterate_supers (ffffffff8126412e)
 =&gt; sys_sync (ffffffff8129c4b6)
 =&gt; entry_SYSCALL_64_fastpath (ffffffff8181f0b2)
            sync-2270  [000]   748.053381: ext4_sync_fs: (ffffffff81317650)
            sync-2270  [000]   748.053383: kernel_stack:         &lt;stack trace&gt;
 =&gt; iterate_supers (ffffffff8126412e)
 =&gt; sys_sync (ffffffff8129c4b6)
 =&gt; entry_SYSCALL_64_fastpath (ffffffff8181f0b2)

Fixes: 73dddbb57bb0 "tracing: Only create stacktrace option when STACKTRACE is configured"
Reported-by: Brendan Gregg &lt;brendan.d.gregg@gmail.com&gt;
Tested-by: Brendan Gregg &lt;brendan.d.gregg@gmail.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>net: bpf: reject invalid shifts</title>
<updated>2016-01-31T19:29:01Z</updated>
<author>
<name>Rabin Vincent</name>
<email>rabin@rab.in</email>
</author>
<published>2016-01-12T19:17:08Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=35987ff2eaa05d70154c5bd28ebb2b70a7d8368b'/>
<id>urn:sha1:35987ff2eaa05d70154c5bd28ebb2b70a7d8368b</id>
<content type='text'>
[ Upstream commit 229394e8e62a4191d592842cf67e80c62a492937 ]

On ARM64, a BUG() is triggered in the eBPF JIT if a filter with a
constant shift that can't be encoded in the immediate field of the
UBFM/SBFM instructions is passed to the JIT.  Since these shifts
amounts, which are negative or &gt;= regsize, are invalid, reject them in
the eBPF verifier and the classic BPF filter checker, for all
architectures.

Signed-off-by: Rabin Vincent &lt;rabin@rab.in&gt;
Acked-by: Alexei Starovoitov &lt;ast@kernel.org&gt;
Acked-by: Daniel Borkmann &lt;daniel@iogearbox.net&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>Merge branch 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip</title>
<updated>2016-01-08T21:57:13Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2016-01-08T21:57:13Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=de030179584833ddac77ab847d7083199e30a877'/>
<id>urn:sha1:de030179584833ddac77ab847d7083199e30a877</id>
<content type='text'>
Pull scheduler fixes from Ingo Molnar:
 "Misc scheduler fixes"

* 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  sched/core: Reset task's lockless wake-queues on fork()
  sched/core: Fix unserialized r-m-w scribbling stuff
  sched/core: Check tgid in is_global_init()
  sched/fair: Fix multiplication overflow on 32-bit systems
</content>
</entry>
<entry>
<title>Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip</title>
<updated>2016-01-08T21:52:59Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2016-01-08T21:52:59Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=3ab6d1ebd54bc377e9cd6c1792aaffa0a1fd11f8'/>
<id>urn:sha1:3ab6d1ebd54bc377e9cd6c1792aaffa0a1fd11f8</id>
<content type='text'>
Pull perf fixes from Ingo Molnar:
 "Two core subsystem fixes, plus a handful of tooling fixes"

* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  perf: Fix race in swevent hash
  perf: Fix race in perf_event_exec()
  perf list: Robustify event printing routine
  perf list: Add support for PERF_COUNT_SW_BPF_OUT
  perf hists browser: Fix segfault if use symbol filter in cmdline
  perf hists browser: Reset selection when refresh
  perf hists browser: Add NULL pointer check to prevent crash
  perf buildid-list: Fix return value of perf buildid-list -k
  perf buildid-list: Show running kernel build id fix
</content>
</entry>
<entry>
<title>Merge branch 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip</title>
<updated>2016-01-08T21:46:59Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2016-01-08T21:46:59Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=ea83ae2fb30cd134d0220221bcf81efb579f8d73'/>
<id>urn:sha1:ea83ae2fb30cd134d0220221bcf81efb579f8d73</id>
<content type='text'>
Pull irq fix from Ingo Molnar:
 "Fixes a core IRQ subsystem deadlock"

* 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  genirq: Prevent chip buslock deadlock
</content>
</entry>
<entry>
<title>Merge tag 'trace-v4.4-rc4-4' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace</title>
<updated>2016-01-07T20:42:22Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2016-01-07T20:42:22Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=2626820d838f9e98f323bf47b4fb7722d1c52e53'/>
<id>urn:sha1:2626820d838f9e98f323bf47b4fb7722d1c52e53</id>
<content type='text'>
Pull ftrace fix from Steven Rostedt:
 "PeiyangX Qiu reported that if a module fails to load between calling
  ftrace_module_init() and do_init_module() that the allocations made in
  ftrace_module_init() will not be freed, resulting in a memory leak.

  The solution is to call ftrace_release_mod() on the failing module in
  the fail path befor do_init_module() is called.  This will remove any
  allocations made for that module, and nothing if ftrace_module_init()
  wasn't called yet for that module.

  Note, once do_init_module() is called, the MODULE_GOING notifiers are
  called for the failed module, which calls into the ftrace code to do
  the proper clean up (basically calling ftrace_release_mod())"

* tag 'trace-v4.4-rc4-4' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
  ftrace/module: Call clean up function when module init fails early
</content>
</entry>
</feed>
