<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/include/linux, branch v3.14.61</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v3.14.61</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v3.14.61'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2016-02-17T20:34:34+00:00</updated>
<entry>
<title>kernel/signal.c: unexport sigsuspend()</title>
<updated>2016-02-17T20:34:34+00:00</updated>
<author>
<name>Richard Weinberger</name>
<email>richard@nod.at</email>
</author>
<published>2015-11-20T23:57:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=79db232ae9a3a21c1c0dfe5f92b133fefd979cfe'/>
<id>urn:sha1:79db232ae9a3a21c1c0dfe5f92b133fefd979cfe</id>
<content type='text'>
commit 9d8a765211335cfdad464b90fb19f546af5706ae upstream.

sigsuspend() is nowhere used except in signal.c itself, so we can mark it
static do not pollute the global namespace.

But this patch is more than a boring cleanup patch, it fixes a real issue
on UserModeLinux.  UML has a special console driver to display ttys using
xterm, or other terminal emulators, on the host side.  Vegard reported
that sometimes UML is unable to spawn a xterm and he's facing the
following warning:

  WARNING: CPU: 0 PID: 908 at include/linux/thread_info.h:128 sigsuspend+0xab/0xc0()

It turned out that this warning makes absolutely no sense as the UML
xterm code calls sigsuspend() on the host side, at least it tries.  But
as the kernel itself offers a sigsuspend() symbol the linker choose this
one instead of the glibc wrapper.  Interestingly this code used to work
since ever but always blocked signals on the wrong side.  Some recent
kernel change made the WARN_ON() trigger and uncovered the bug.

It is a wonderful example of how much works by chance on computers. :-)

Fixes: 68f3f16d9ad0f1 ("new helper: sigsuspend()")
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
Reported-by: Vegard Nossum &lt;vegard.nossum@oracle.com&gt;
Tested-by: Vegard Nossum &lt;vegard.nossum@oracle.com&gt;
Acked-by: Oleg Nesterov &lt;oleg@redhat.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>arm64: fix building without CONFIG_UID16</title>
<updated>2016-01-29T05:57:15+00:00</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2015-11-20T11:12:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e858dfb67d8f286b33d730fbfa76846e9ba22bcc'/>
<id>urn:sha1:e858dfb67d8f286b33d730fbfa76846e9ba22bcc</id>
<content type='text'>
commit fbc416ff86183e2203cdf975e2881d7c164b0271 upstream.

As reported by Michal Simek, building an ARM64 kernel with CONFIG_UID16
disabled currently fails because the system call table still needs to
reference the individual function entry points that are provided by
kernel/sys_ni.c in this case, and the declarations are hidden inside
of #ifdef CONFIG_UID16:

arch/arm64/include/asm/unistd32.h:57:8: error: 'sys_lchown16' undeclared here (not in a function)
 __SYSCALL(__NR_lchown, sys_lchown16)

I believe this problem only exists on ARM64, because older architectures
tend to not need declarations when their system call table is built
in assembly code, while newer architectures tend to not need UID16
support. ARM64 only uses these system calls for compatibility with
32-bit ARM binaries.

This changes the CONFIG_UID16 check into CONFIG_HAVE_UID16, which is
set unconditionally on ARM64 with CONFIG_COMPAT, so we see the
declarations whenever we need them, but otherwise the behavior is
unchanged.

Fixes: af1839eb4bd4 ("Kconfig: clean up the long arch list for the UID16 config option")
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Acked-by: Will Deacon &lt;will.deacon@arm.com&gt;
Signed-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>unix: properly account for FDs passed over unix sockets</title>
<updated>2016-01-29T05:57:11+00:00</updated>
<author>
<name>willy tarreau</name>
<email>w@1wt.eu</email>
</author>
<published>2016-01-10T06:54:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=aa51d1c24ec3b6605f7cc7ef500c96cd71d7ef90'/>
<id>urn:sha1:aa51d1c24ec3b6605f7cc7ef500c96cd71d7ef90</id>
<content type='text'>
[ Upstream commit 712f4aad406bb1ed67f3f98d04c044191f0ff593 ]

It is possible for a process to allocate and accumulate far more FDs than
the process' limit by sending them over a unix socket then closing them
to keep the process' fd count low.

This change addresses this problem by keeping track of the number of FDs
in flight per user and preventing non-privileged processes from having
more FDs in flight than their configured FD limit.

Reported-by: socketpair@gmail.com
Reported-by: Tetsuo Handa &lt;penguin-kernel@I-love.SAKURA.ne.jp&gt;
Mitigates: CVE-2013-4312 (Linux 2.0+)
Suggested-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Acked-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Signed-off-by: Willy Tarreau &lt;w@1wt.eu&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>USB: add quirk for devices with broken LPM</title>
<updated>2016-01-23T04:34:52+00:00</updated>
<author>
<name>Alan Stern</name>
<email>stern@rowland.harvard.edu</email>
</author>
<published>2015-12-10T20:27:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4180d57beb422ce28d563fee25b5fc45bb9c3186'/>
<id>urn:sha1:4180d57beb422ce28d563fee25b5fc45bb9c3186</id>
<content type='text'>
commit ad87e03213b552a5c33d5e1e7a19a73768397010 upstream.

Some USB device / host controller combinations seem to have problems
with Link Power Management.  For example, Steinar found that his xHCI
controller wouldn't handle bandwidth calculations correctly for two
video cards simultaneously when LPM was enabled, even though the bus
had plenty of bandwidth available.

This patch introduces a new quirk flag for devices that should remain
disabled for LPM, and creates quirk entries for Steinar's devices.

Signed-off-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Reported-by: Steinar H. Gunderson &lt;sgunderson@bigfoot.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ext4, jbd2: ensure entering into panic after recording an error in superblock</title>
<updated>2016-01-23T04:34:50+00:00</updated>
<author>
<name>Daeho Jeong</name>
<email>daeho.jeong@samsung.com</email>
</author>
<published>2015-10-18T21:02:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9293f419d742b274f53428809be7388b30c0caca'/>
<id>urn:sha1:9293f419d742b274f53428809be7388b30c0caca</id>
<content type='text'>
commit 4327ba52afd03fc4b5afa0ee1d774c9c5b0e85c5 upstream.

If a EXT4 filesystem utilizes JBD2 journaling and an error occurs, the
journaling will be aborted first and the error number will be recorded
into JBD2 superblock and, finally, the system will enter into the
panic state in "errors=panic" option.  But, in the rare case, this
sequence is little twisted like the below figure and it will happen
that the system enters into panic state, which means the system reset
in mobile environment, before completion of recording an error in the
journal superblock. In this case, e2fsck cannot recognize that the
filesystem failure occurred in the previous run and the corruption
wouldn't be fixed.

Task A                        Task B
ext4_handle_error()
-&gt; jbd2_journal_abort()
  -&gt; __journal_abort_soft()
    -&gt; __jbd2_journal_abort_hard()
    | -&gt; journal-&gt;j_flags |= JBD2_ABORT;
    |
    |                         __ext4_abort()
    |                         -&gt; jbd2_journal_abort()
    |                         | -&gt; __journal_abort_soft()
    |                         |   -&gt; if (journal-&gt;j_flags &amp; JBD2_ABORT)
    |                         |           return;
    |                         -&gt; panic()
    |
    -&gt; jbd2_journal_update_sb_errno()

Tested-by: Hobin Woo &lt;hobin.woo@samsung.com&gt;
Signed-off-by: Daeho Jeong &lt;daeho.jeong@samsung.com&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>sched/preempt: Fix cond_resched_lock() and cond_resched_softirq()</title>
<updated>2015-10-27T00:45:59+00:00</updated>
<author>
<name>Konstantin Khlebnikov</name>
<email>khlebnikov@yandex-team.ru</email>
</author>
<published>2015-07-15T09:52:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e211cb68dd3c951b104ff0b47dbaed2c8b8d2399'/>
<id>urn:sha1:e211cb68dd3c951b104ff0b47dbaed2c8b8d2399</id>
<content type='text'>
commit fe32d3cd5e8eb0f82e459763374aa80797023403 upstream.

These functions check should_resched() before unlocking spinlock/bh-enable:
preempt_count always non-zero =&gt; should_resched() always returns false.
cond_resched_lock() worked iff spin_needbreak is set.

This patch adds argument "preempt_offset" to should_resched().

preempt_count offset constants for that:

  PREEMPT_DISABLE_OFFSET  - offset after preempt_disable()
  PREEMPT_LOCK_OFFSET     - offset after spin_lock()
  SOFTIRQ_DISABLE_OFFSET  - offset after local_bh_distable()
  SOFTIRQ_LOCK_OFFSET     - offset after spin_lock_bh()

Signed-off-by: Konstantin Khlebnikov &lt;khlebnikov@yandex-team.ru&gt;
Signed-off-by: Peter Zijlstra (Intel) &lt;peterz@infradead.org&gt;
Cc: Alexander Graf &lt;agraf@suse.de&gt;
Cc: Boris Ostrovsky &lt;boris.ostrovsky@oracle.com&gt;
Cc: David Vrabel &lt;david.vrabel@citrix.com&gt;
Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: Mike Galbraith &lt;efault@gmx.de&gt;
Cc: Paul Mackerras &lt;paulus@samba.org&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Fixes: bdb438065890 ("sched: Extract the basic add/sub preempt_count modifiers")
Link: http://lkml.kernel.org/r/20150715095204.12246.98268.stgit@buzz
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Signed-off-by: Mike Galbraith &lt;efault@gmx.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>sched/preempt: Rename PREEMPT_CHECK_OFFSET to PREEMPT_DISABLE_OFFSET</title>
<updated>2015-10-27T00:45:59+00:00</updated>
<author>
<name>Frederic Weisbecker</name>
<email>fweisbec@gmail.com</email>
</author>
<published>2015-05-12T14:41:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d379e64ca4fc535334a02dc0314cba6e50f4b720'/>
<id>urn:sha1:d379e64ca4fc535334a02dc0314cba6e50f4b720</id>
<content type='text'>
commit 90b62b5129d5cb50f62f40e684de7a1961e57197 upstream.

"CHECK" suggests it's only used as a comparison mask. But now it's used
further as a config-conditional preempt disabler offset. Lets
disambiguate this name.

Signed-off-by: Frederic Weisbecker &lt;fweisbec@gmail.com&gt;
Signed-off-by: Peter Zijlstra (Intel) &lt;peterz@infradead.org&gt;
Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Link: http://lkml.kernel.org/r/1431441711-29753-4-git-send-email-fweisbec@gmail.com
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Signed-off-by: Mike Galbraith &lt;efault@gmx.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;


</content>
</entry>
<entry>
<title>skbuff: Fix skb checksum partial check.</title>
<updated>2015-10-27T00:45:54+00:00</updated>
<author>
<name>Pravin B Shelar</name>
<email>pshelar@nicira.com</email>
</author>
<published>2015-09-29T00:24:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3e261933c5242b2eba6e5820967e34644d41c28b'/>
<id>urn:sha1:3e261933c5242b2eba6e5820967e34644d41c28b</id>
<content type='text'>
[ Upstream commit 31b33dfb0a144469dd805514c9e63f4993729a48 ]

Earlier patch 6ae459bda tried to detect void ckecksum partial
skb by comparing pull length to checksum offset. But it does
not work for all cases since checksum-offset depends on
updates to skb-&gt;data.

Following patch fixes it by validating checksum start offset
after skb-data pointer is updated. Negative value of checksum
offset start means there is no need to checksum.

Fixes: 6ae459bda ("skbuff: Fix skb checksum flag on skb pull")
Reported-by: Andrew Vagin &lt;avagin@odin.com&gt;
Signed-off-by: Pravin B Shelar &lt;pshelar@nicira.com&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>skbuff: Fix skb checksum flag on skb pull</title>
<updated>2015-10-27T00:45:54+00:00</updated>
<author>
<name>Pravin B Shelar</name>
<email>pshelar@nicira.com</email>
</author>
<published>2015-09-22T19:57:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=81feda9cbe3881504fe16d4e00a5bef69855761a'/>
<id>urn:sha1:81feda9cbe3881504fe16d4e00a5bef69855761a</id>
<content type='text'>
[ Upstream commit 6ae459bdaaeebc632b16e54dcbabb490c6931d61 ]

VXLAN device can receive skb with checksum partial. But the checksum
offset could be in outer header which is pulled on receive. This results
in negative checksum offset for the skb. Such skb can cause the assert
failure in skb_checksum_help(). Following patch fixes the bug by setting
checksum-none while pulling outer header.

Following is the kernel panic msg from old kernel hitting the bug.

------------[ cut here ]------------
kernel BUG at net/core/dev.c:1906!
RIP: 0010:[&lt;ffffffff81518034&gt;] skb_checksum_help+0x144/0x150
Call Trace:
&lt;IRQ&gt;
[&lt;ffffffffa0164c28&gt;] queue_userspace_packet+0x408/0x470 [openvswitch]
[&lt;ffffffffa016614d&gt;] ovs_dp_upcall+0x5d/0x60 [openvswitch]
[&lt;ffffffffa0166236&gt;] ovs_dp_process_packet_with_key+0xe6/0x100 [openvswitch]
[&lt;ffffffffa016629b&gt;] ovs_dp_process_received_packet+0x4b/0x80 [openvswitch]
[&lt;ffffffffa016c51a&gt;] ovs_vport_receive+0x2a/0x30 [openvswitch]
[&lt;ffffffffa0171383&gt;] vxlan_rcv+0x53/0x60 [openvswitch]
[&lt;ffffffffa01734cb&gt;] vxlan_udp_encap_recv+0x8b/0xf0 [openvswitch]
[&lt;ffffffff8157addc&gt;] udp_queue_rcv_skb+0x2dc/0x3b0
[&lt;ffffffff8157b56f&gt;] __udp4_lib_rcv+0x1cf/0x6c0
[&lt;ffffffff8157ba7a&gt;] udp_rcv+0x1a/0x20
[&lt;ffffffff8154fdbd&gt;] ip_local_deliver_finish+0xdd/0x280
[&lt;ffffffff81550128&gt;] ip_local_deliver+0x88/0x90
[&lt;ffffffff8154fa7d&gt;] ip_rcv_finish+0x10d/0x370
[&lt;ffffffff81550365&gt;] ip_rcv+0x235/0x300
[&lt;ffffffff8151ba1d&gt;] __netif_receive_skb+0x55d/0x620
[&lt;ffffffff8151c360&gt;] netif_receive_skb+0x80/0x90
[&lt;ffffffff81459935&gt;] virtnet_poll+0x555/0x6f0
[&lt;ffffffff8151cd04&gt;] net_rx_action+0x134/0x290
[&lt;ffffffff810683d8&gt;] __do_softirq+0xa8/0x210
[&lt;ffffffff8162fe6c&gt;] call_softirq+0x1c/0x30
[&lt;ffffffff810161a5&gt;] do_softirq+0x65/0xa0
[&lt;ffffffff810687be&gt;] irq_exit+0x8e/0xb0
[&lt;ffffffff81630733&gt;] do_IRQ+0x63/0xe0
[&lt;ffffffff81625f2e&gt;] common_interrupt+0x6e/0x6e

Reported-by: Anupam Chanda &lt;achanda@vmware.com&gt;
Signed-off-by: Pravin B Shelar &lt;pshelar@nicira.com&gt;
Acked-by: Tom Herbert &lt;tom@herbertland.com&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>jbd2: avoid infinite loop when destroying aborted journal</title>
<updated>2015-10-22T21:39:22+00:00</updated>
<author>
<name>Jan Kara</name>
<email>jack@suse.com</email>
</author>
<published>2015-07-28T18:57:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ae5137a8f24aa93ab8c56345edbfd3828db796f6'/>
<id>urn:sha1:ae5137a8f24aa93ab8c56345edbfd3828db796f6</id>
<content type='text'>
commit 841df7df196237ea63233f0f9eaa41db53afd70f upstream.

Commit 6f6a6fda2945 "jbd2: fix ocfs2 corrupt when updating journal
superblock fails" changed jbd2_cleanup_journal_tail() to return EIO
when the journal is aborted. That makes logic in
jbd2_log_do_checkpoint() bail out which is fine, except that
jbd2_journal_destroy() expects jbd2_log_do_checkpoint() to always make
a progress in cleaning the journal. Without it jbd2_journal_destroy()
just loops in an infinite loop.

Fix jbd2_journal_destroy() to cleanup journal checkpoint lists of
jbd2_log_do_checkpoint() fails with error.

Reported-by: Eryu Guan &lt;guaneryu@gmail.com&gt;
Tested-by: Eryu Guan &lt;guaneryu@gmail.com&gt;
Fixes: 6f6a6fda294506dfe0e3e0a253bb2d2923f28f0a
Signed-off-by: Jan Kara &lt;jack@suse.com&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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