[packages/kernel.git] / kernel-small_fixes.patch

--- linux-2.6.33/scripts/mod/modpost.c~	2010-02-24 19:52:17.000000000 +0100
+++ linux-2.6.33/scripts/mod/modpost.c	2010-03-07 14:26:47.242168558 +0100
@@ -15,7 +15,8 @@
 #include <stdio.h>
 #include <ctype.h>
 #include "modpost.h"
-#include "../../include/generated/autoconf.h"
+// PLD architectures don't use CONFIG_SYMBOL_PREFIX
+//#include "../../include/generated/autoconf.h"
 #include "../../include/linux/license.h"
 
 /* Some toolchains use a `_' prefix for all user symbols. */

--- linux-3.0/scripts/kconfig/lxdialog/check-lxdialog.sh~	2011-07-22 04:17:23.000000000 +0200
+++ linux-3.0/scripts/kconfig/lxdialog/check-lxdialog.sh	2011-08-25 21:26:04.799150642 +0200
@@ -9,6 +9,12 @@
 			$cc -print-file-name=lib${lib}.${ext} | grep -q /
 			if [ $? -eq 0 ]; then
 				echo "-l${lib}"
+				for libt in tinfow tinfo ; do
+					$cc -print-file-name=lib${libt}.${ext} | grep -q /
+					if [ $? -eq 0 ]; then
+						echo "-l${libt}"
+					fi
+				done
 				exit
 			fi
 		done

From 30927520dbae297182990bb21d08762bcc35ce1d Mon Sep 17 00:00:00 2001
From: Eric Dumazet <edumazet@google.com>
Date: Wed, 9 Sep 2015 21:55:07 -0700
Subject: [PATCH] tcp_cubic: better follow cubic curve after idle period

Jana Iyengar found an interesting issue on CUBIC :

The epoch is only updated/reset initially and when experiencing losses.
The delta "t" of now - epoch_start can be arbitrary large after app idle
as well as the bic_target. Consequentially the slope (inverse of
ca->cnt) would be really large, and eventually ca->cnt would be
lower-bounded in the end to 2 to have delayed-ACK slow-start behavior.

This particularly shows up when slow_start_after_idle is disabled
as a dangerous cwnd inflation (1.5 x RTT) after few seconds of idle
time.

Jana initial fix was to reset epoch_start if app limited,
but Neal pointed out it would ask the CUBIC algorithm to recalculate the
curve so that we again start growing steeply upward from where cwnd is
now (as CUBIC does just after a loss). Ideally we'd want the cwnd growth
curve to be the same shape, just shifted later in time by the amount of
the idle period.

Reported-by: Jana Iyengar <jri@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>
Cc: Sangtae Ha <sangtae.ha@gmail.com>
Cc: Lawrence Brakmo <lawrence@brakmo.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/ipv4/tcp_cubic.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/net/ipv4/tcp_cubic.c b/net/ipv4/tcp_cubic.c
index 28011fb1..c6ded6b 100644
--- a/net/ipv4/tcp_cubic.c
+++ b/net/ipv4/tcp_cubic.c
@@ -151,6 +151,21 @@ static void bictcp_init(struct sock *sk)
 		tcp_sk(sk)->snd_ssthresh = initial_ssthresh;
 }
 
+static void bictcp_cwnd_event(struct sock *sk, enum tcp_ca_event event)
+{
+	if (event == CA_EVENT_TX_START) {
+		s32 delta = tcp_time_stamp - tcp_sk(sk)->lsndtime;
+		struct bictcp *ca = inet_csk_ca(sk);
+
+		/* We were application limited (idle) for a while.
+		 * Shift epoch_start to keep cwnd growth to cubic curve.
+		 */
+		if (ca->epoch_start && delta > 0)
+			ca->epoch_start += delta;
+		return;
+	}
+}
+
 /* calculate the cubic root of x using a table lookup followed by one
  * Newton-Raphson iteration.
  * Avg err ~= 0.195%
@@ -450,6 +465,7 @@ static struct tcp_congestion_ops cubictcp __read_mostly = {
 	.cong_avoid	= bictcp_cong_avoid,
 	.set_state	= bictcp_state,
 	.undo_cwnd	= bictcp_undo_cwnd,
+	.cwnd_event	= bictcp_cwnd_event,
 	.pkts_acked     = bictcp_acked,
 	.owner		= THIS_MODULE,
 	.name		= "cubic",
From 7a29ac474a47eb8cf212b45917683ae89d6fa13b Mon Sep 17 00:00:00 2001
From: Chris Mason <clm@fb.com>
Date: Tue, 10 Nov 2015 10:10:34 +1100
Subject: xfs: give all workqueues rescuer threads

We're consistently hitting deadlocks here with XFS on recent kernels.
After some digging through the crash files, it looks like everyone in
the system is waiting for XFS to reclaim memory.

Something like this:

PID: 2733434  TASK: ffff8808cd242800  CPU: 19  COMMAND: "java"
 #0 [ffff880019c53588] __schedule at ffffffff818c4df2
 #1 [ffff880019c535d8] schedule at ffffffff818c5517
 #2 [ffff880019c535f8] _xfs_log_force_lsn at ffffffff81316348
 #3 [ffff880019c53688] xfs_log_force_lsn at ffffffff813164fb
 #4 [ffff880019c536b8] xfs_iunpin_wait at ffffffff8130835e
 #5 [ffff880019c53728] xfs_reclaim_inode at ffffffff812fd453
 #6 [ffff880019c53778] xfs_reclaim_inodes_ag at ffffffff812fd8c7
 #7 [ffff880019c53928] xfs_reclaim_inodes_nr at ffffffff812fe433
 #8 [ffff880019c53958] xfs_fs_free_cached_objects at ffffffff8130d3b9
 #9 [ffff880019c53968] super_cache_scan at ffffffff811a6f73
#10 [ffff880019c539c8] shrink_slab at ffffffff811460e6
#11 [ffff880019c53aa8] shrink_zone at ffffffff8114a53f
#12 [ffff880019c53b48] do_try_to_free_pages at ffffffff8114a8ba
#13 [ffff880019c53be8] try_to_free_pages at ffffffff8114ad5a
#14 [ffff880019c53c78] __alloc_pages_nodemask at ffffffff8113e1b8
#15 [ffff880019c53d88] alloc_kmem_pages_node at ffffffff8113e671
#16 [ffff880019c53dd8] copy_process at ffffffff8104f781
#17 [ffff880019c53ec8] do_fork at ffffffff8105129c
#18 [ffff880019c53f38] sys_clone at ffffffff810515b6
#19 [ffff880019c53f48] stub_clone at ffffffff818c8e4d

xfs_log_force_lsn is waiting for logs to get cleaned, which is waiting
for IO, which is waiting for workers to complete the IO which is waiting
for worker threads that don't exist yet:

PID: 2752451  TASK: ffff880bd6bdda00  CPU: 37  COMMAND: "kworker/37:1"
 #0 [ffff8808d20abbb0] __schedule at ffffffff818c4df2
 #1 [ffff8808d20abc00] schedule at ffffffff818c5517
 #2 [ffff8808d20abc20] schedule_timeout at ffffffff818c7c6c
 #3 [ffff8808d20abcc0] wait_for_completion_killable at ffffffff818c6495
 #4 [ffff8808d20abd30] kthread_create_on_node at ffffffff8106ec82
 #5 [ffff8808d20abdf0] create_worker at ffffffff8106752f
 #6 [ffff8808d20abe40] worker_thread at ffffffff810699be
 #7 [ffff8808d20abec0] kthread at ffffffff8106ef59
 #8 [ffff8808d20abf50] ret_from_fork at ffffffff818c8ac8

I think we should be using WQ_MEM_RECLAIM to make sure this thread
pool makes progress when we're not able to allocate new workers.

[dchinner: make all workqueues WQ_MEM_RECLAIM]

Signed-off-by: Chris Mason <clm@fb.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
---
 fs/xfs/xfs_super.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c
index 29531ec..65fbfb7 100644
--- a/fs/xfs/xfs_super.c
+++ b/fs/xfs/xfs_super.c
@@ -838,17 +838,18 @@ xfs_init_mount_workqueues(
 		goto out_destroy_unwritten;
 
 	mp->m_reclaim_workqueue = alloc_workqueue("xfs-reclaim/%s",
-			WQ_FREEZABLE, 0, mp->m_fsname);
+			WQ_MEM_RECLAIM|WQ_FREEZABLE, 0, mp->m_fsname);
 	if (!mp->m_reclaim_workqueue)
 		goto out_destroy_cil;
 
 	mp->m_log_workqueue = alloc_workqueue("xfs-log/%s",
-			WQ_FREEZABLE|WQ_HIGHPRI, 0, mp->m_fsname);
+			WQ_MEM_RECLAIM|WQ_FREEZABLE|WQ_HIGHPRI, 0,
+			mp->m_fsname);
 	if (!mp->m_log_workqueue)
 		goto out_destroy_reclaim;
 
 	mp->m_eofblocks_workqueue = alloc_workqueue("xfs-eofblocks/%s",
-			WQ_FREEZABLE, 0, mp->m_fsname);
+			WQ_MEM_RECLAIM|WQ_FREEZABLE, 0, mp->m_fsname);
 	if (!mp->m_eofblocks_workqueue)
 		goto out_destroy_log;
 
-- 
cgit v0.11.2
Commit	Line	Data
08aa9d92	1	--- linux-2.6.33/scripts/mod/modpost.c~ 2010-02-24 19:52:17.000000000 +0100
	2	+++ linux-2.6.33/scripts/mod/modpost.c 2010-03-07 14:26:47.242168558 +0100
	3	@@ -15,7 +15,8 @@
	4	#include <stdio.h>
	5	#include <ctype.h>
	6	#include "modpost.h"
	7	-#include "../../include/generated/autoconf.h"
	8	+// PLD architectures don't use CONFIG_SYMBOL_PREFIX
	9	+//#include "../../include/generated/autoconf.h"
	10	#include "../../include/linux/license.h"
	11
	12	/* Some toolchains use a `_' prefix for all user symbols. */
	13
2136e199 AM	14	--- linux-3.0/scripts/kconfig/lxdialog/check-lxdialog.sh~ 2011-07-22 04:17:23.000000000 +0200
	15	+++ linux-3.0/scripts/kconfig/lxdialog/check-lxdialog.sh 2011-08-25 21:26:04.799150642 +0200
	16	@@ -9,6 +9,12 @@
	17	$cc -print-file-name=lib${lib}.${ext} \| grep -q /
	18	if [ $? -eq 0 ]; then
	19	echo "-l${lib}"
	20	+ for libt in tinfow tinfo ; do
	21	+ $cc -print-file-name=lib${libt}.${ext} \| grep -q /
	22	+ if [ $? -eq 0 ]; then
	23	+ echo "-l${libt}"
	24	+ fi
	25	+ done
	26	exit
	27	fi
	28	done
7e7bde06	29
723407aa AM	30	From 30927520dbae297182990bb21d08762bcc35ce1d Mon Sep 17 00:00:00 2001
	31	From: Eric Dumazet <edumazet@google.com>
	32	Date: Wed, 9 Sep 2015 21:55:07 -0700
	33	Subject: [PATCH] tcp_cubic: better follow cubic curve after idle period
	34
	35	Jana Iyengar found an interesting issue on CUBIC :
	36
	37	The epoch is only updated/reset initially and when experiencing losses.
	38	The delta "t" of now - epoch_start can be arbitrary large after app idle
	39	as well as the bic_target. Consequentially the slope (inverse of
	40	ca->cnt) would be really large, and eventually ca->cnt would be
	41	lower-bounded in the end to 2 to have delayed-ACK slow-start behavior.
	42
	43	This particularly shows up when slow_start_after_idle is disabled
	44	as a dangerous cwnd inflation (1.5 x RTT) after few seconds of idle
	45	time.
	46
	47	Jana initial fix was to reset epoch_start if app limited,
	48	but Neal pointed out it would ask the CUBIC algorithm to recalculate the
	49	curve so that we again start growing steeply upward from where cwnd is
	50	now (as CUBIC does just after a loss). Ideally we'd want the cwnd growth
	51	curve to be the same shape, just shifted later in time by the amount of
	52	the idle period.
	53
	54	Reported-by: Jana Iyengar <jri@google.com>
	55	Signed-off-by: Eric Dumazet <edumazet@google.com>
	56	Signed-off-by: Yuchung Cheng <ycheng@google.com>
	57	Signed-off-by: Neal Cardwell <ncardwell@google.com>
	58	Cc: Stephen Hemminger <stephen@networkplumber.org>
	59	Cc: Sangtae Ha <sangtae.ha@gmail.com>
	60	Cc: Lawrence Brakmo <lawrence@brakmo.org>
	61	Signed-off-by: David S. Miller <davem@davemloft.net>
	62	---
	63	net/ipv4/tcp_cubic.c \| 16 ++++++++++++++++
	64	1 file changed, 16 insertions(+)
	65
	66	diff --git a/net/ipv4/tcp_cubic.c b/net/ipv4/tcp_cubic.c
	67	index 28011fb1..c6ded6b 100644
	68	--- a/net/ipv4/tcp_cubic.c
	69	+++ b/net/ipv4/tcp_cubic.c
	70	@@ -151,6 +151,21 @@ static void bictcp_init(struct sock *sk)
	71	tcp_sk(sk)->snd_ssthresh = initial_ssthresh;
	72	}
	73
	74	+static void bictcp_cwnd_event(struct sock *sk, enum tcp_ca_event event)
	75	+{
	76	+ if (event == CA_EVENT_TX_START) {
	77	+ s32 delta = tcp_time_stamp - tcp_sk(sk)->lsndtime;
	78	+ struct bictcp *ca = inet_csk_ca(sk);
	79	+
	80	+ /* We were application limited (idle) for a while.
	81	+ * Shift epoch_start to keep cwnd growth to cubic curve.
	82	+ */
	83	+ if (ca->epoch_start && delta > 0)
	84	+ ca->epoch_start += delta;
	85	+ return;
	86	+ }
	87	+}
	88	+
	89	/* calculate the cubic root of x using a table lookup followed by one
	90	* Newton-Raphson iteration.
	91	* Avg err ~= 0.195%
	92	@@ -450,6 +465,7 @@ static struct tcp_congestion_ops cubictcp __read_mostly = {
	93	.cong_avoid = bictcp_cong_avoid,
94	.set_state = bictcp_state,
95	.undo_cwnd = bictcp_undo_cwnd,
96	+ .cwnd_event = bictcp_cwnd_event,
97	.pkts_acked = bictcp_acked,
98	.owner = THIS_MODULE,
99	.name = "cubic",
99992ee3 AM	100	From 7a29ac474a47eb8cf212b45917683ae89d6fa13b Mon Sep 17 00:00:00 2001
	101	From: Chris Mason <clm@fb.com>
	102	Date: Tue, 10 Nov 2015 10:10:34 +1100
	103	Subject: xfs: give all workqueues rescuer threads
	104
	105	We're consistently hitting deadlocks here with XFS on recent kernels.
	106	After some digging through the crash files, it looks like everyone in
	107	the system is waiting for XFS to reclaim memory.
	108
	109	Something like this:
	110
	111	PID: 2733434 TASK: ffff8808cd242800 CPU: 19 COMMAND: "java"
	112	#0 [ffff880019c53588] __schedule at ffffffff818c4df2
	113	#1 [ffff880019c535d8] schedule at ffffffff818c5517
	114	#2 [ffff880019c535f8] _xfs_log_force_lsn at ffffffff81316348
	115	#3 [ffff880019c53688] xfs_log_force_lsn at ffffffff813164fb
	116	#4 [ffff880019c536b8] xfs_iunpin_wait at ffffffff8130835e
	117	#5 [ffff880019c53728] xfs_reclaim_inode at ffffffff812fd453
	118	#6 [ffff880019c53778] xfs_reclaim_inodes_ag at ffffffff812fd8c7
	119	#7 [ffff880019c53928] xfs_reclaim_inodes_nr at ffffffff812fe433
	120	#8 [ffff880019c53958] xfs_fs_free_cached_objects at ffffffff8130d3b9
	121	#9 [ffff880019c53968] super_cache_scan at ffffffff811a6f73
	122	#10 [ffff880019c539c8] shrink_slab at ffffffff811460e6
	123	#11 [ffff880019c53aa8] shrink_zone at ffffffff8114a53f
	124	#12 [ffff880019c53b48] do_try_to_free_pages at ffffffff8114a8ba
	125	#13 [ffff880019c53be8] try_to_free_pages at ffffffff8114ad5a
	126	#14 [ffff880019c53c78] __alloc_pages_nodemask at ffffffff8113e1b8
	127	#15 [ffff880019c53d88] alloc_kmem_pages_node at ffffffff8113e671
	128	#16 [ffff880019c53dd8] copy_process at ffffffff8104f781
	129	#17 [ffff880019c53ec8] do_fork at ffffffff8105129c
	130	#18 [ffff880019c53f38] sys_clone at ffffffff810515b6
	131	#19 [ffff880019c53f48] stub_clone at ffffffff818c8e4d
	132
	133	xfs_log_force_lsn is waiting for logs to get cleaned, which is waiting
	134	for IO, which is waiting for workers to complete the IO which is waiting
	135	for worker threads that don't exist yet:
	136
	137	PID: 2752451 TASK: ffff880bd6bdda00 CPU: 37 COMMAND: "kworker/37:1"
	138	#0 [ffff8808d20abbb0] __schedule at ffffffff818c4df2
	139	#1 [ffff8808d20abc00] schedule at ffffffff818c5517
	140	#2 [ffff8808d20abc20] schedule_timeout at ffffffff818c7c6c
	141	#3 [ffff8808d20abcc0] wait_for_completion_killable at ffffffff818c6495
	142	#4 [ffff8808d20abd30] kthread_create_on_node at ffffffff8106ec82
	143	#5 [ffff8808d20abdf0] create_worker at ffffffff8106752f
	144	#6 [ffff8808d20abe40] worker_thread at ffffffff810699be
	145	#7 [ffff8808d20abec0] kthread at ffffffff8106ef59
	146	#8 [ffff8808d20abf50] ret_from_fork at ffffffff818c8ac8
	147
	148	I think we should be using WQ_MEM_RECLAIM to make sure this thread
	149	pool makes progress when we're not able to allocate new workers.
	150
	151	[dchinner: make all workqueues WQ_MEM_RECLAIM]
	152
	153	Signed-off-by: Chris Mason <clm@fb.com>
	154	Reviewed-by: Dave Chinner <dchinner@redhat.com>
	155	Signed-off-by: Dave Chinner <david@fromorbit.com>
	156	---
	157	fs/xfs/xfs_super.c \| 7 ++++---
	158	1 file changed, 4 insertions(+), 3 deletions(-)
	159
	160	diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c
	161	index 29531ec..65fbfb7 100644
	162	--- a/fs/xfs/xfs_super.c
	163	+++ b/fs/xfs/xfs_super.c
164	@@ -838,17 +838,18 @@ xfs_init_mount_workqueues(
165	goto out_destroy_unwritten;
166
167	mp->m_reclaim_workqueue = alloc_workqueue("xfs-reclaim/%s",
168	- WQ_FREEZABLE, 0, mp->m_fsname);
169	+ WQ_MEM_RECLAIM\|WQ_FREEZABLE, 0, mp->m_fsname);
170	if (!mp->m_reclaim_workqueue)
171	goto out_destroy_cil;
172
173	mp->m_log_workqueue = alloc_workqueue("xfs-log/%s",
174	- WQ_FREEZABLE\|WQ_HIGHPRI, 0, mp->m_fsname);
175	+ WQ_MEM_RECLAIM\|WQ_FREEZABLE\|WQ_HIGHPRI, 0,
176	+ mp->m_fsname);
177	if (!mp->m_log_workqueue)
178	goto out_destroy_reclaim;
179
180	mp->m_eofblocks_workqueue = alloc_workqueue("xfs-eofblocks/%s",
181	- WQ_FREEZABLE, 0, mp->m_fsname);
182	+ WQ_MEM_RECLAIM\|WQ_FREEZABLE, 0, mp->m_fsname);
183	if (!mp->m_eofblocks_workqueue)
184	goto out_destroy_log;
185
186	--
187	cgit v0.11.2
188