From: Greg Kroah-Hartman Date: Tue, 20 Nov 2012 19:03:14 +0000 (-0800) Subject: 3.4-stable patches X-Git-Tag: v3.0.53~23^2~7 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=c638b4b0ebbf02666007c5bf6d8136323f9af691;p=thirdparty%2Fkernel%2Fstable-queue.git 3.4-stable patches added patches: r8169-use-unlimited-dma-burst-for-tx.patch tmpfs-change-final-i_blocks-bug-to-warning.patch xen-events-fix-rcu-warning-or-call-idle-notifier-after-irq_enter.patch --- diff --git a/queue-3.4/module-fix-out-by-one-error-in-kallsyms.patch b/queue-3.4/module-fix-out-by-one-error-in-kallsyms.patch index 008739c567f..80a28cf63d9 100644 --- a/queue-3.4/module-fix-out-by-one-error-in-kallsyms.patch +++ b/queue-3.4/module-fix-out-by-one-error-in-kallsyms.patch @@ -23,6 +23,7 @@ This bug exists since the following commit was introduced. LKML: http://lkml.org/lkml/2012/10/24/27 Reported-by: Masaki Kimura +Signed-off-by: Rusty Russell Signed-off-by: Greg Kroah-Hartman --- diff --git a/queue-3.4/r8169-use-unlimited-dma-burst-for-tx.patch b/queue-3.4/r8169-use-unlimited-dma-burst-for-tx.patch new file mode 100644 index 00000000000..b1e1ec646b7 --- /dev/null +++ b/queue-3.4/r8169-use-unlimited-dma-burst-for-tx.patch @@ -0,0 +1,65 @@ +From aee77e4accbeb2c86b1d294cd84fec4a12dde3bd Mon Sep 17 00:00:00 2001 +From: Michal Schmidt +Date: Sun, 9 Sep 2012 13:55:26 +0000 +Subject: r8169: use unlimited DMA burst for TX + +From: Michal Schmidt + +commit aee77e4accbeb2c86b1d294cd84fec4a12dde3bd upstream. + +The r8169 driver currently limits the DMA burst for TX to 1024 bytes. I have +a box where this prevents the interface from using the gigabit line to its full +potential. This patch solves the problem by setting TX_DMA_BURST to unlimited. + +The box has an ASRock B75M motherboard with on-board RTL8168evl/8111evl +(XID 0c900880). TSO is enabled. + +I used netperf (TCP_STREAM test) to measure the dependency of TX throughput +on MTU. I did it for three different values of TX_DMA_BURST ('5'=512, '6'=1024, +'7'=unlimited). This chart shows the results: +http://michich.fedorapeople.org/r8169/r8169-effects-of-TX_DMA_BURST.png + +Interesting points: + - With the current DMA burst limit (1024): + - at the default MTU=1500 I get only 842 Mbit/s. + - when going from small MTU, the performance rises monotonically with + increasing MTU only up to a peak at MTU=1076 (908 MBit/s). Then there's + a sudden drop to 762 MBit/s from which the throughput rises monotonically + again with further MTU increases. + - With a smaller DMA burst limit (512): + - there's a similar peak at MTU=1076 and another one at MTU=564. + - With unlimited DMA burst: + - at the default MTU=1500 I get nice 940 Mbit/s. + - the throughput rises monotonically with increasing MTU with no strange + peaks. + +Notice that the peaks occur at MTU sizes that are multiples of the DMA burst +limit plus 52. Why 52? Because: + 20 (IP header) + 20 (TCP header) + 12 (TCP options) = 52 + +The Realtek-provided r8168 driver (v8.032.00) uses unlimited TX DMA burst too, +except for CFG_METHOD_1 where the TX DMA burst is set to 512 bytes. +CFG_METHOD_1 appears to be the oldest MAC version of "RTL8168B/8111B", +i.e. RTL_GIGA_MAC_VER_11 in r8169. Not sure if this MAC version really needs +the smaller burst limit, or if any other versions have similar requirements. + +Signed-off-by: Michal Schmidt +Acked-by: Francois Romieu +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/ethernet/realtek/r8169.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/net/ethernet/realtek/r8169.c ++++ b/drivers/net/ethernet/realtek/r8169.c +@@ -73,7 +73,7 @@ + static const int multicast_filter_limit = 32; + + #define MAX_READ_REQUEST_SHIFT 12 +-#define TX_DMA_BURST 6 /* Maximum PCI burst, '6' is 1024 */ ++#define TX_DMA_BURST 7 /* Maximum PCI burst, '7' is unlimited */ + #define SafeMtu 0x1c20 /* ... actually life sucks beyond ~7k */ + #define InterFrameGap 0x03 /* 3 means InterFrameGap = the shortest one */ + diff --git a/queue-3.4/series b/queue-3.4/series index eedfe19a3b1..a51ced4b904 100644 --- a/queue-3.4/series +++ b/queue-3.4/series @@ -24,3 +24,6 @@ ipv4-avoid-undefined-behavior-in-do_ip_setsockopt.patch ipv6-setsockopt-ipipproto_ipv6-ipv6_minhopcount-forgot-to-set-return-value.patch net-correct-check-in-dev_addr_del.patch net-rps-fix-brokeness-causing-ooo-packets.patch +tmpfs-change-final-i_blocks-bug-to-warning.patch +r8169-use-unlimited-dma-burst-for-tx.patch +xen-events-fix-rcu-warning-or-call-idle-notifier-after-irq_enter.patch diff --git a/queue-3.4/tmpfs-change-final-i_blocks-bug-to-warning.patch b/queue-3.4/tmpfs-change-final-i_blocks-bug-to-warning.patch new file mode 100644 index 00000000000..afc9821ab68 --- /dev/null +++ b/queue-3.4/tmpfs-change-final-i_blocks-bug-to-warning.patch @@ -0,0 +1,51 @@ +From 0f3c42f522dc1ad7e27affc0a4aa8c790bce0a66 Mon Sep 17 00:00:00 2001 +From: Hugh Dickins +Date: Fri, 16 Nov 2012 14:15:04 -0800 +Subject: tmpfs: change final i_blocks BUG to WARNING + +From: Hugh Dickins + +commit 0f3c42f522dc1ad7e27affc0a4aa8c790bce0a66 upstream. + +Under a particular load on one machine, I have hit shmem_evict_inode()'s +BUG_ON(inode->i_blocks), enough times to narrow it down to a particular +race between swapout and eviction. + +It comes from the "if (freed > 0)" asymmetry in shmem_recalc_inode(), +and the lack of coherent locking between mapping's nrpages and shmem's +swapped count. There's a window in shmem_writepage(), between lowering +nrpages in shmem_delete_from_page_cache() and then raising swapped +count, when the freed count appears to be +1 when it should be 0, and +then the asymmetry stops it from being corrected with -1 before hitting +the BUG. + +One answer is coherent locking: using tree_lock throughout, without +info->lock; reasonable, but the raw_spin_lock in percpu_counter_add() on +used_blocks makes that messier than expected. Another answer may be a +further effort to eliminate the weird shmem_recalc_inode() altogether, +but previous attempts at that failed. + +So far undecided, but for now change the BUG_ON to WARN_ON: in usual +circumstances it remains a useful consistency check. + +Signed-off-by: Hugh Dickins +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + + +--- + mm/shmem.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/mm/shmem.c ++++ b/mm/shmem.c +@@ -595,7 +595,7 @@ static void shmem_evict_inode(struct ino + kfree(xattr->name); + kfree(xattr); + } +- BUG_ON(inode->i_blocks); ++ WARN_ON(inode->i_blocks); + shmem_free_inode(inode->i_sb); + end_writeback(inode); + } diff --git a/queue-3.4/xen-events-fix-rcu-warning-or-call-idle-notifier-after-irq_enter.patch b/queue-3.4/xen-events-fix-rcu-warning-or-call-idle-notifier-after-irq_enter.patch new file mode 100644 index 00000000000..434a4f66b53 --- /dev/null +++ b/queue-3.4/xen-events-fix-rcu-warning-or-call-idle-notifier-after-irq_enter.patch @@ -0,0 +1,75 @@ +From 772aebcefeff310f80e32b874988af0076cb799d Mon Sep 17 00:00:00 2001 +From: Mojiong Qiu +Date: Tue, 6 Nov 2012 16:08:15 +0800 +Subject: xen/events: fix RCU warning, or Call idle notifier after irq_enter() + +From: Mojiong Qiu + +commit 772aebcefeff310f80e32b874988af0076cb799d upstream. + +exit_idle() should be called after irq_enter(), otherwise it throws: + +[ INFO: suspicious RCU usage. ] +3.6.5 #1 Not tainted +------------------------------- +include/linux/rcupdate.h:725 rcu_read_lock() used illegally while idle! + +other info that might help us debug this: + +RCU used illegally from idle CPU! +rcu_scheduler_active = 1, debug_locks = 1 +RCU used illegally from extended quiescent state! +1 lock held by swapper/0/0: + #0: (rcu_read_lock){......}, at: [] __atomic_notifier_call_chain+0x0/0x140 + +stack backtrace: +Pid: 0, comm: swapper/0 Not tainted 3.6.5 #1 +Call Trace: + [] lockdep_rcu_suspicious+0xe2/0x130 + [] __atomic_notifier_call_chain+0x12c/0x140 + [] ? atomic_notifier_chain_unregister+0x90/0x90 + [] ? trace_hardirqs_off+0xd/0x10 + [] atomic_notifier_call_chain+0x16/0x20 + [] exit_idle+0x43/0x50 + [] xen_evtchn_do_upcall+0x25/0x50 + [] xen_do_hypervisor_callback+0x1e/0x30 + [] ? hypercall_page+0x3aa/0x1000 + [] ? hypercall_page+0x3aa/0x1000 + [] ? xen_safe_halt+0x10/0x20 + [] ? default_idle+0xba/0x570 + [] ? cpu_idle+0xdf/0x140 + [] ? rest_init+0x135/0x144 + [] ? csum_partial_copy_generic+0x16c/0x16c + [] ? start_kernel+0x3db/0x3e8 + [] ? repair_env_string+0x5a/0x5a + [] ? x86_64_start_reservations+0x131/0x135 + [] ? xen_start_kernel+0x465/0x46 + +Git commit 98ad1cc14a5c4fd658f9d72c6ba5c86dfd3ce0d5 +Author: Frederic Weisbecker +Date: Fri Oct 7 18:22:09 2011 +0200 + + x86: Call idle notifier after irq_enter() + +did this, but it missed the Xen code. + +Signed-off-by: Mojiong Qiu +Signed-off-by: Konrad Rzeszutek Wilk +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/xen/events.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/xen/events.c ++++ b/drivers/xen/events.c +@@ -1365,8 +1365,8 @@ void xen_evtchn_do_upcall(struct pt_regs + { + struct pt_regs *old_regs = set_irq_regs(regs); + +- exit_idle(); + irq_enter(); ++ exit_idle(); + + __xen_evtchn_do_upcall(); +