kernel: update kernel 4.4 to version 4.4.3
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> SVN-Revision: 48783v19.07.3_mercusys_ac12_duma
Hauke Mehrtens
8 years ago
parent
53814290e7
commit
cb04b8d582
@ -1,70 +0,0 @@
|
||||
From 7ca88764d45c209791e8813131c1457c2e9e51e7 Mon Sep 17 00:00:00 2001
|
||||
From: Yevgeny Pats <yevgeny@perception-point.io>
|
||||
Date: Mon, 11 Jan 2016 12:05:28 +0000
|
||||
Subject: KEYS: Fix keyring ref leak in join_session_keyring()
|
||||
|
||||
If a thread is asked to join as a session keyring the keyring that's already
|
||||
set as its session, we leak a keyring reference.
|
||||
|
||||
This can be tested with the following program:
|
||||
|
||||
#include <stddef.h>
|
||||
#include <stdio.h>
|
||||
#include <sys/types.h>
|
||||
#include <keyutils.h>
|
||||
|
||||
int main(int argc, const char *argv[])
|
||||
{
|
||||
int i = 0;
|
||||
key_serial_t serial;
|
||||
|
||||
serial = keyctl(KEYCTL_JOIN_SESSION_KEYRING,
|
||||
"leaked-keyring");
|
||||
if (serial < 0) {
|
||||
perror("keyctl");
|
||||
return -1;
|
||||
}
|
||||
|
||||
if (keyctl(KEYCTL_SETPERM, serial,
|
||||
KEY_POS_ALL | KEY_USR_ALL) < 0) {
|
||||
perror("keyctl");
|
||||
return -1;
|
||||
}
|
||||
|
||||
for (i = 0; i < 100; i++) {
|
||||
serial = keyctl(KEYCTL_JOIN_SESSION_KEYRING,
|
||||
"leaked-keyring");
|
||||
if (serial < 0) {
|
||||
perror("keyctl");
|
||||
return -1;
|
||||
}
|
||||
}
|
||||
|
||||
return 0;
|
||||
}
|
||||
|
||||
If, after the program has run, there something like the following line in
|
||||
/proc/keys:
|
||||
|
||||
3f3d898f I--Q--- 100 perm 3f3f0000 0 0 keyring leaked-keyring: empty
|
||||
|
||||
with a usage count of 100 * the number of times the program has been run,
|
||||
then the kernel is malfunctioning. If leaked-keyring has zero usages or
|
||||
has been garbage collected, then the problem is fixed.
|
||||
|
||||
Reported-by: Yevgeny Pats <yevgeny@perception-point.io>
|
||||
Signed-off-by: David Howells <dhowells@redhat.com>
|
||||
---
|
||||
security/keys/process_keys.c | 1 +
|
||||
1 file changed, 1 insertion(+)
|
||||
|
||||
--- a/security/keys/process_keys.c
|
||||
+++ b/security/keys/process_keys.c
|
||||
@@ -794,6 +794,7 @@ long join_session_keyring(const char *na
|
||||
ret = PTR_ERR(keyring);
|
||||
goto error2;
|
||||
} else if (keyring == new->session_keyring) {
|
||||
+ key_put(keyring);
|
||||
ret = 0;
|
||||
goto error2;
|
||||
}
|
||||
@ -1,118 +0,0 @@
|
||||
From: Eric Dumazet <edumazet@google.com>
|
||||
Date: Fri, 22 Jan 2016 23:06:44 -0800
|
||||
Subject: [PATCH] dump_stack: avoid potential deadlocks
|
||||
|
||||
Some servers experienced fatal deadlocks because of a combination
|
||||
of bugs, leading to multiple cpus calling dump_stack().
|
||||
|
||||
The checksumming bug was fixed in commit 34ae6a1aa054
|
||||
("ipv6: update skb->csum when CE mark is propagated").
|
||||
|
||||
The second problem is a faulty locking in dump_stack()
|
||||
|
||||
CPU1 runs in process context and calls dump_stack(), grabs dump_lock.
|
||||
|
||||
CPU2 receives a TCP packet under softirq, grabs socket spinlock, and
|
||||
call dump_stack() from netdev_rx_csum_fault().
|
||||
|
||||
dump_stack() spins on atomic_cmpxchg(&dump_lock, -1, 2), since
|
||||
dump_lock is owned by CPU1
|
||||
|
||||
While dumping its stack, CPU1 is interrupted by a softirq, and happens
|
||||
to process a packet for the TCP socket locked by CPU2.
|
||||
|
||||
CPU1 spins forever in spin_lock() : deadlock
|
||||
|
||||
Stack trace on CPU1 looked like :
|
||||
|
||||
[306295.402231] NMI backtrace for cpu 1
|
||||
[306295.402238] RIP: 0010:[<ffffffffa9804e95>] [<ffffffffa9804e95>] _raw_spin_lock+0x25/0x30
|
||||
...
|
||||
[306295.402255] Stack:
|
||||
[306295.402256] ffff88407f023cb0 ffffffffa99cbdc3 ffff88407f023ca0 ffff88012f496bb0
|
||||
[306295.402266] ffffffffaa4dc1f0 ffff8820d94f0dc0 000000000000000a ffffffffaa4b4280
|
||||
[306295.402275] ffff88407f023ce0 ffffffffa98a21d0 ffff88407f023cc0 ffff88407f023ca0
|
||||
[306295.402284] Call Trace:
|
||||
[306295.402286] <IRQ>
|
||||
[306295.402288]
|
||||
[306295.402291] [<ffffffffa99cbdc3>] tcp_v6_rcv+0x243/0x620
|
||||
[306295.402304] [<ffffffffa99c38af>] ip6_input_finish+0x11f/0x330
|
||||
[306295.402309] [<ffffffffa99c3b38>] ip6_input+0x38/0x40
|
||||
[306295.402313] [<ffffffffa99c3b7c>] ip6_rcv_finish+0x3c/0x90
|
||||
[306295.402318] [<ffffffffa99c3e79>] ipv6_rcv+0x2a9/0x500
|
||||
[306295.402323] [<ffffffffa989a1a1>] process_backlog+0x461/0xaa0
|
||||
[306295.402332] [<ffffffffa9899a57>] net_rx_action+0x147/0x430
|
||||
[306295.402337] [<ffffffffa980cca7>] __do_softirq+0x167/0x2d0
|
||||
[306295.402341] [<ffffffffa9d912dc>] call_softirq+0x1c/0x30
|
||||
[306295.402345] [<ffffffffa980687f>] do_softirq+0x3f/0x80
|
||||
[306295.402350] [<ffffffffa980cf7e>] irq_exit+0x6e/0xc0
|
||||
[306295.402355] [<ffffffffa980a5b5>] smp_call_function_single_interrupt+0x35/0x40
|
||||
[306295.402360] [<ffffffffa9d90bfa>] call_function_single_interrupt+0x6a/0x70
|
||||
[306295.402361] <EOI>
|
||||
[306295.402364]
|
||||
[306295.402376] [<ffffffffa9a3fa32>] printk+0x4d/0x4f
|
||||
[306295.402390] [<ffffffffa99e1726>] printk_address+0x31/0x33
|
||||
[306295.402395] [<ffffffffa99e175b>] print_trace_address+0x33/0x3c
|
||||
[306295.402408] [<ffffffffa99e165b>] print_context_stack+0x7f/0x119
|
||||
[306295.402412] [<ffffffffa99e07f1>] dump_trace+0x26b/0x28e
|
||||
[306295.402417] [<ffffffffa99e17b3>] show_trace_log_lvl+0x4f/0x5c
|
||||
[306295.402421] [<ffffffffa99e0a14>] show_stack_log_lvl+0x104/0x113
|
||||
[306295.402425] [<ffffffffa99e1819>] show_stack+0x42/0x44
|
||||
[306295.402429] [<ffffffffa9ba350a>] dump_stack+0x46/0x58
|
||||
[306295.402434] [<ffffffffa9d0957d>] netdev_rx_csum_fault+0x38/0x3c
|
||||
[306295.402439] [<ffffffffa9988e0e>] __skb_checksum_complete_head+0x6e/0x80
|
||||
[306295.402444] [<ffffffffa9988e31>] __skb_checksum_complete+0x11/0x20
|
||||
[306295.402449] [<ffffffffa98acf65>] tcp_rcv_established+0x2bd5/0x2fd0
|
||||
[306295.402468] [<ffffffffa99cb69c>] tcp_v6_do_rcv+0x13c/0x620
|
||||
[306295.402477] [<ffffffffa9984be5>] sk_backlog_rcv+0x15/0x30
|
||||
[306295.402482] [<ffffffffa98931e2>] release_sock+0xd2/0x150
|
||||
[306295.402486] [<ffffffffa98a51b1>] tcp_recvmsg+0x1c1/0xfc0
|
||||
[306295.402491] [<ffffffffa98b637d>] inet_recvmsg+0x7d/0x90
|
||||
[306295.402495] [<ffffffffa9891fcf>] sock_recvmsg+0xaf/0xe0
|
||||
[306295.402505] [<ffffffffa9892611>] ___sys_recvmsg+0x111/0x3b0
|
||||
[306295.402528] [<ffffffffa9892f5c>] SyS_recvmsg+0x5c/0xb0
|
||||
[306295.402532] [<ffffffffa9d8fba2>] system_call_fastpath+0x16/0x1b
|
||||
|
||||
Fixes: b58d977432c8 ("dump_stack: serialize the output from dump_stack()")
|
||||
Signed-off-by: Eric Dumazet <edumazet@google.com>
|
||||
Cc: Alex Thorlton <athorlton@sgi.com>
|
||||
---
|
||||
|
||||
--- a/lib/dump_stack.c
|
||||
+++ b/lib/dump_stack.c
|
||||
@@ -25,6 +25,7 @@ static atomic_t dump_lock = ATOMIC_INIT(
|
||||
|
||||
asmlinkage __visible void dump_stack(void)
|
||||
{
|
||||
+ unsigned long flags;
|
||||
int was_locked;
|
||||
int old;
|
||||
int cpu;
|
||||
@@ -33,9 +34,8 @@ asmlinkage __visible void dump_stack(voi
|
||||
* Permit this cpu to perform nested stack dumps while serialising
|
||||
* against other CPUs
|
||||
*/
|
||||
- preempt_disable();
|
||||
-
|
||||
retry:
|
||||
+ local_irq_save(flags);
|
||||
cpu = smp_processor_id();
|
||||
old = atomic_cmpxchg(&dump_lock, -1, cpu);
|
||||
if (old == -1) {
|
||||
@@ -43,6 +43,7 @@ retry:
|
||||
} else if (old == cpu) {
|
||||
was_locked = 1;
|
||||
} else {
|
||||
+ local_irq_restore(flags);
|
||||
cpu_relax();
|
||||
goto retry;
|
||||
}
|
||||
@@ -52,7 +53,7 @@ retry:
|
||||
if (!was_locked)
|
||||
atomic_set(&dump_lock, -1);
|
||||
|
||||
- preempt_enable();
|
||||
+ local_irq_restore(flags);
|
||||
}
|
||||
#else
|
||||
asmlinkage __visible void dump_stack(void)
|
||||
@ -1,37 +0,0 @@
|
||||
From 4f9ea86604e3ba64edd2817795798168fbb3c1a6 Mon Sep 17 00:00:00 2001
|
||||
From: LABBE Corentin <clabbe.montjoie@gmail.com>
|
||||
Date: Mon, 16 Nov 2015 09:35:54 +0100
|
||||
Subject: [PATCH] crypto: sun4i-ss - add missing statesize
|
||||
|
||||
sun4i-ss implementaton of md5/sha1 is via ahash algorithms.
|
||||
Commit 8996eafdcbad ("crypto: ahash - ensure statesize is non-zero")
|
||||
made impossible to load them without giving statesize. This patch
|
||||
specifiy statesize for sha1 and md5.
|
||||
|
||||
Fixes: 6298e948215f ("crypto: sunxi-ss - Add Allwinner Security System crypto accelerator")
|
||||
Cc: <stable@vger.kernel.org> # v4.3+
|
||||
Tested-by: Chen-Yu Tsai <wens@csie.org>
|
||||
Signed-off-by: LABBE Corentin <clabbe.montjoie@gmail.com>
|
||||
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
||||
---
|
||||
drivers/crypto/sunxi-ss/sun4i-ss-core.c | 2 ++
|
||||
1 file changed, 2 insertions(+)
|
||||
|
||||
--- a/drivers/crypto/sunxi-ss/sun4i-ss-core.c
|
||||
+++ b/drivers/crypto/sunxi-ss/sun4i-ss-core.c
|
||||
@@ -39,6 +39,7 @@ static struct sun4i_ss_alg_template ss_a
|
||||
.import = sun4i_hash_import_md5,
|
||||
.halg = {
|
||||
.digestsize = MD5_DIGEST_SIZE,
|
||||
+ .statesize = sizeof(struct md5_state),
|
||||
.base = {
|
||||
.cra_name = "md5",
|
||||
.cra_driver_name = "md5-sun4i-ss",
|
||||
@@ -66,6 +67,7 @@ static struct sun4i_ss_alg_template ss_a
|
||||
.import = sun4i_hash_import_sha1,
|
||||
.halg = {
|
||||
.digestsize = SHA1_DIGEST_SIZE,
|
||||
+ .statesize = sizeof(struct sha1_state),
|
||||
.base = {
|
||||
.cra_name = "sha1",
|
||||
.cra_driver_name = "sha1-sun4i-ss",
|
||||
Loading…
Reference in New Issue