[patch 00/26] 2.6.31.4-stable review

[patch 00/26] 2.6.31.4-stable review

[Greg KH]

This is the start of the stable review cycle for the 2.6.31.4 release.
There are 26 patches in this series, all will be posted as a response to
this one.  If anyone has any issues with these being applied, please let
us know.  If anyone is a maintainer of the proper subsystem, and wants
to add a Signed-off-by: line to the patch, please respond with it.

Responses should be made by Sunday October 11, 23:00:00 UTC.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
	kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.31.4-rc1.gz
and the diffstat can be found below.


thanks,

greg k-h

-----------

 .../networking/timestamping/timestamping.c         |    2 +-
 Makefile                                           |    2 +-
 arch/x86/ia32/ia32entry.S                          |   36 +++++++----
 arch/x86/include/asm/checksum_32.h                 |    3 +-
 arch/x86/kernel/acpi/cstate.c                      |    2 +-
 arch/x86/kernel/i8253.c                            |   27 ++++++--
 arch/x86/kvm/lapic.c                               |    2 +-
 arch/x86/kvm/svm.c                                 |    2 +
 arch/x86/kvm/vmx.c                                 |    2 +-
 arch/x86/kvm/x86.c                                 |    2 +
 drivers/acpi/osl.c                                 |    8 ++-
 drivers/ata/libata-eh.c                            |   50 +++++++++-----
 drivers/char/tty_ldisc.c                           |    7 +--
 drivers/ide/sis5513.c                              |   10 ++-
 drivers/net/iseries_veth.c                         |    2 +-
 fs/ecryptfs/main.c                                 |    7 ++-
 fs/namei.c                                         |    6 +-
 include/linux/ftrace.h                             |    2 +-
 kernel/exit.c                                      |    2 -
 kernel/fork.c                                      |   10 ++-
 kernel/futex.c                                     |    3 +-
 kernel/time/tick-sched.c                           |    9 ++-
 kernel/trace/ftrace.c                              |   23 ++-----
 mm/swap_state.c                                    |   70 +++++++++++++-------
 sound/pci/hda/patch_realtek.c                      |    1 +
 sound/pci/via82xx.c                                |   27 +++++---
 sound/soc/codecs/wm8350.c                          |    4 +-
 27 files changed, 203 insertions(+), 118 deletions(-)

[patch 01/26] x86: fix csum_ipv6_magic asm memory clobber

[Greg KH]

[-- Attachment #1: x86-fix-csum_ipv6_magic-asm-memory-clobber.patch --]
[-- Type: text/plain, Size: 1411 bytes --]

2.6.31-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Samuel Thibault <samuel.thibault@ens-lyon.org>

commit 392d814daf460a9564d29b2cebc51e1ea34e0504 upstream.

Just like ip_fast_csum, the assembly snippet in csum_ipv6_magic needs a
memory clobber, as it is only passed the address of the buffer, not a
memory reference to the buffer itself.

This caused failures in Hurd's pfinetv4 when we tried to compile it with
gcc-4.3 (bogus checksums).

Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Acked-by: "David S. Miller" <davem@davemloft.net>
Cc: Andi Kleen <andi@firstfloor.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 arch/x86/include/asm/checksum_32.h |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/arch/x86/include/asm/checksum_32.h
+++ b/arch/x86/include/asm/checksum_32.h
@@ -161,7 +161,8 @@ static inline __sum16 csum_ipv6_magic(co
 	    "adcl $0, %0	;\n"
 	    : "=&r" (sum)
 	    : "r" (saddr), "r" (daddr),
-	      "r" (htonl(len)), "r" (htonl(proto)), "0" (sum));
+	      "r" (htonl(len)), "r" (htonl(proto)), "0" (sum)
+	    : "memory");
 
 	return csum_fold(sum);
 }

[patch 02/26] tty: Avoid dropping ldisc_mutex over hangup tty re-initialization

[Greg KH]

[-- Attachment #1: tty-avoid-dropping-ldisc_mutex-over-hangup-tty-re-initialization.patch --]
[-- Type: text/plain, Size: 2455 bytes --]

2.6.31-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Linus Torvalds <torvalds@linux-foundation.org>

commit 0b5759c654e74c8dc317ea2c6b3a7476160f688a upstream.

A couple of people have hit the WARN_ON() in drivers/char/tty_io.c,
tty_open() that is unhappy about seeing the tty line discipline go away
during the tty hangup. See for example

	http://bugzilla.kernel.org/show_bug.cgi?id=14255

and the reason is that we do the tty_ldisc_halt() outside the
ldisc_mutex in order to be able to flush the scheduled work without a
deadlock with vhangup_work.

However, it turns out that we can solve this particular case by

 - using "cancel_delayed_work_sync()" in tty_ldisc_halt(), which waits
   for just the particular work, rather than synchronizing with any
   random outstanding pending work.

   This won't deadlock, since the buf.work we synchronize with doesn't
   care about the ldisc_mutex, it just flushes the tty ldisc buffers.

 - realize that for this particular case, we don't need to wait for any
   hangup work, because we are inside the hangup codepaths ourselves.

so as a result we can just drop the flush_scheduled_work() entirely, and
then move the tty_ldisc_halt() call to inside the mutex.  That way we
never expose the partially torn down ldisc state to tty_open(), and hold
the ldisc_mutex over the whole sequence.

Reported-by: Ingo Molnar <mingo@elte.hu>
Reported-by: Heinz Diehl <htd@fancy-poultry.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/char/tty_ldisc.c |    7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

--- a/drivers/char/tty_ldisc.c
+++ b/drivers/char/tty_ldisc.c
@@ -516,7 +516,7 @@ static void tty_ldisc_restore(struct tty
 static int tty_ldisc_halt(struct tty_struct *tty)
 {
 	clear_bit(TTY_LDISC, &tty->flags);
-	return cancel_delayed_work(&tty->buf.work);
+	return cancel_delayed_work_sync(&tty->buf.work);
 }
 
 /**
@@ -754,12 +754,9 @@ void tty_ldisc_hangup(struct tty_struct 
 	 * N_TTY.
 	 */
 	if (tty->driver->flags & TTY_DRIVER_RESET_TERMIOS) {
-		/* Make sure the old ldisc is quiescent */
-		tty_ldisc_halt(tty);
-		flush_scheduled_work();
-
 		/* Avoid racing set_ldisc or tty_ldisc_release */
 		mutex_lock(&tty->ldisc_mutex);
+		tty_ldisc_halt(tty);
 		if (tty->ldisc) {	/* Not yet closed */
 			/* Switch back to N_TTY */
 			tty_ldisc_reinit(tty);

[patch 03/26] x86: Dont leak 64-bit kernel register values to 32-bit processes

[Greg KH]

[-- Attachment #1: x86-don-t-leak-64-bit-kernel-register-values-to-32-bit-processes.patch --]
[-- Type: text/plain, Size: 3204 bytes --]

2.6.31-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Jan Beulich <JBeulich@novell.com>

commit 24e35800cdc4350fc34e2bed37b608a9e13ab3b6 upstream.

While 32-bit processes can't directly access R8...R15, they can
gain access to these registers by temporarily switching themselves
into 64-bit mode.

Therefore, registers not preserved anyway by called C functions
(i.e. R8...R11) must be cleared prior to returning to user mode.

Signed-off-by: Jan Beulich <jbeulich@novell.com>
LKML-Reference: <4AC34D73020000780001744A@vpn.id2.novell.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

--- a/arch/x86/ia32/ia32entry.S
+++ b/arch/x86/ia32/ia32entry.S
@@ -21,8 +21,8 @@
 #define __AUDIT_ARCH_LE	   0x40000000
 
 #ifndef CONFIG_AUDITSYSCALL
-#define sysexit_audit int_ret_from_sys_call
-#define sysretl_audit int_ret_from_sys_call
+#define sysexit_audit ia32_ret_from_sys_call
+#define sysretl_audit ia32_ret_from_sys_call
 #endif
 
 #define IA32_NR_syscalls ((ia32_syscall_end - ia32_sys_call_table)/8)
@@ -39,12 +39,12 @@
 	.endm 
 
 	/* clobbers %eax */	
-	.macro  CLEAR_RREGS _r9=rax
+	.macro  CLEAR_RREGS offset=0, _r9=rax
 	xorl 	%eax,%eax
-	movq	%rax,R11(%rsp)
-	movq	%rax,R10(%rsp)
-	movq	%\_r9,R9(%rsp)
-	movq	%rax,R8(%rsp)
+	movq	%rax,\offset+R11(%rsp)
+	movq	%rax,\offset+R10(%rsp)
+	movq	%\_r9,\offset+R9(%rsp)
+	movq	%rax,\offset+R8(%rsp)
 	.endm
 
 	/*
@@ -172,6 +172,10 @@ sysexit_from_sys_call:
 	movl	RIP-R11(%rsp),%edx		/* User %eip */
 	CFI_REGISTER rip,rdx
 	RESTORE_ARGS 1,24,1,1,1,1
+	xorq	%r8,%r8
+	xorq	%r9,%r9
+	xorq	%r10,%r10
+	xorq	%r11,%r11
 	popfq
 	CFI_ADJUST_CFA_OFFSET -8
 	/*CFI_RESTORE rflags*/
@@ -202,7 +206,7 @@ sysexit_from_sys_call:
 
 	.macro auditsys_exit exit,ebpsave=RBP
 	testl $(_TIF_ALLWORK_MASK & ~_TIF_SYSCALL_AUDIT),TI_flags(%r10)
-	jnz int_ret_from_sys_call
+	jnz ia32_ret_from_sys_call
 	TRACE_IRQS_ON
 	sti
 	movl %eax,%esi		/* second arg, syscall return value */
@@ -218,8 +222,9 @@ sysexit_from_sys_call:
 	cli
 	TRACE_IRQS_OFF
 	testl %edi,TI_flags(%r10)
-	jnz int_with_check
-	jmp \exit
+	jz \exit
+	CLEAR_RREGS -ARGOFFSET
+	jmp int_with_check
 	.endm
 
 sysenter_auditsys:
@@ -329,6 +334,9 @@ sysretl_from_sys_call:
 	CFI_REGISTER rip,rcx
 	movl EFLAGS-ARGOFFSET(%rsp),%r11d	
 	/*CFI_REGISTER rflags,r11*/
+	xorq	%r10,%r10
+	xorq	%r9,%r9
+	xorq	%r8,%r8
 	TRACE_IRQS_ON
 	movl RSP-ARGOFFSET(%rsp),%esp
 	CFI_RESTORE rsp
@@ -353,7 +361,7 @@ cstar_tracesys:
 #endif
 	xchgl %r9d,%ebp
 	SAVE_REST
-	CLEAR_RREGS r9
+	CLEAR_RREGS 0, r9
 	movq $-ENOSYS,RAX(%rsp)	/* ptrace can change this for a bad syscall */
 	movq %rsp,%rdi        /* &pt_regs -> arg1 */
 	call syscall_trace_enter
@@ -425,6 +433,8 @@ ia32_do_call:
 	call *ia32_sys_call_table(,%rax,8) # xxx: rip relative
 ia32_sysret:
 	movq %rax,RAX-ARGOFFSET(%rsp)
+ia32_ret_from_sys_call:
+	CLEAR_RREGS -ARGOFFSET
 	jmp int_ret_from_sys_call 
 
 ia32_tracesys:			 
@@ -442,8 +452,8 @@ END(ia32_syscall)
 
 ia32_badsys:
 	movq $0,ORIG_RAX-ARGOFFSET(%rsp)
-	movq $-ENOSYS,RAX-ARGOFFSET(%rsp)
-	jmp int_ret_from_sys_call
+	movq $-ENOSYS,%rax
+	jmp ia32_sysret
 
 quiet_ni_syscall:
 	movq $-ENOSYS,%rax

[patch 04/26] ALSA: hda - Added quirk to enable sound on Toshiba NB200

[Greg KH]

[-- Attachment #1: alsa-hda-added-quirk-to-enable-sound-on-toshiba-nb200.patch --]
[-- Type: text/plain, Size: 1006 bytes --]

2.6.31-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Manoj Iyer <manoj.iyer@canonical.com>

commit 3db6c037c6954ed6d98ef199938e4004fea96908 upstream.

Patch was tested on Toshiba NB200 and is found to enable sound.

Signed-off-by: Manoj Iyer <manoj.iyer@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 sound/pci/hda/patch_realtek.c |    1 +
 1 file changed, 1 insertion(+)

--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -16876,6 +16876,7 @@ static struct snd_pci_quirk alc662_cfg_t
 	SND_PCI_QUIRK(0x105b, 0x0cd6, "Foxconn", ALC662_ECS),
 	SND_PCI_QUIRK(0x105b, 0x0d47, "Foxconn 45CMX/45GMX/45CMX-K",
 		      ALC662_3ST_6ch_DIG),
+	SND_PCI_QUIRK(0x1179, 0xff6e, "Toshiba NB200", ALC663_ASUS_MODE4),
 	SND_PCI_QUIRK(0x144d, 0xca00, "Samsung NC10", ALC272_SAMSUNG_NC10),
 	SND_PCI_QUIRK(0x1458, 0xa002, "Gigabyte 945GCM-S2L",
 		      ALC662_3ST_6ch_DIG),

[patch 05/26] tracing: correct module boundaries for ftrace_release

[Greg KH]

[-- Attachment #1: tracing-correct-module-boundaries-for-ftrace_release.patch --]
[-- Type: text/plain, Size: 2334 bytes --]

2.6.31-stable review patch.  If anyone has any objections, please let us know.

------------------
From: jolsa@redhat.com <jolsa@redhat.com>

commit e7247a15ff3bbdab0a8b402dffa1171e5c05a8e0 upstream.

When the module is about the unload we release its call records.
The ftrace_release function was given wrong values representing
the module core boundaries, thus not releasing its call records.

Plus making ftrace_release function module specific.

Signed-off-by: Jiri Olsa <jolsa@redhat.com>
LKML-Reference: <1254934835-363-3-git-send-email-jolsa@redhat.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 include/linux/ftrace.h |    2 +-
 kernel/trace/ftrace.c  |   12 ++++--------
 2 files changed, 5 insertions(+), 9 deletions(-)

--- a/include/linux/ftrace.h
+++ b/include/linux/ftrace.h
@@ -241,7 +241,7 @@ extern void ftrace_enable_daemon(void);
 # define ftrace_set_filter(buf, len, reset)	do { } while (0)
 # define ftrace_disable_daemon()		do { } while (0)
 # define ftrace_enable_daemon()			do { } while (0)
-static inline void ftrace_release(void *start, unsigned long size) { }
+static inline void ftrace_release_mod(struct module *mod) {}
 static inline int register_ftrace_command(struct ftrace_func_command *cmd)
 {
 	return -EINVAL;
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -2801,19 +2801,17 @@ static int ftrace_convert_nops(struct mo
 }
 
 #ifdef CONFIG_MODULES
-void ftrace_release(void *start, void *end)
+void ftrace_release_mod(struct module *mod)
 {
 	struct dyn_ftrace *rec;
 	struct ftrace_page *pg;
-	unsigned long s = (unsigned long)start;
-	unsigned long e = (unsigned long)end;
 
-	if (ftrace_disabled || !start || start == end)
+	if (ftrace_disabled)
 		return;
 
 	mutex_lock(&ftrace_lock);
 	do_for_each_ftrace_rec(pg, rec) {
-		if ((rec->ip >= s) && (rec->ip < e)) {
+		if (within_module_core(rec->ip, mod)) {
 			/*
 			 * rec->ip is changed in ftrace_free_rec()
 			 * It should not between s and e if record was freed.
@@ -2845,9 +2843,7 @@ static int ftrace_module_notify(struct n
 				   mod->num_ftrace_callsites);
 		break;
 	case MODULE_STATE_GOING:
-		ftrace_release(mod->ftrace_callsites,
-			       mod->ftrace_callsites +
-			       mod->num_ftrace_callsites);
+		ftrace_release_mod(mod);
 		break;
 	}
 

[patch 06/26] ftrace: check for failure for all conversions

[Greg KH]

[-- Attachment #1: ftrace-check-for-failure-for-all-conversions.patch --]
[-- Type: text/plain, Size: 1156 bytes --]

2.6.31-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Steven Rostedt <srostedt@redhat.com>

commit 3279ba37db5d65c4ab0dcdee3b211ccb85bb563f upstream.

Due to legacy code from back when the dynamic tracer used a daemon,
only core kernel code was checking for failures. This is no longer
the case. We must check for failures any time we perform text modifications.

Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 kernel/trace/ftrace.c |   11 +++--------
 1 file changed, 3 insertions(+), 8 deletions(-)

--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -1110,14 +1110,9 @@ static void ftrace_replace_code(int enab
 		failed = __ftrace_replace_code(rec, enable);
 		if (failed) {
 			rec->flags |= FTRACE_FL_FAILED;
-			if ((system_state == SYSTEM_BOOTING) ||
-			    !core_kernel_text(rec->ip)) {
-				ftrace_free_rec(rec);
-				} else {
-				ftrace_bug(failed, rec->ip);
-					/* Stop processing */
-					return;
-				}
+			ftrace_bug(failed, rec->ip);
+			/* Stop processing */
+			return;
 		}
 	} while_for_each_ftrace_rec();
 }

[patch 07/26] futex: fix requeue_pi key imbalance

[Greg KH]

[-- Attachment #1: futex-fix-requeue_pi-key-imbalance.patch --]
[-- Type: text/plain, Size: 1297 bytes --]

2.6.31-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Darren Hart <dvhltc@us.ibm.com>

commit da085681014fb43d67d9bf6d14bc068e9254bd49 upstream.

If futex_wait_requeue_pi() wakes prior to requeue, we drop the
reference to the source futex_key twice, once in
handle_early_requeue_pi_wakeup() and once on our way out.

Remove the drop from the handle_early_requeue_pi_wakeup() and keep
the get/drops together in futex_wait_requeue_pi().

Reported-by: Helge Bahmann <hcb@chaoticmind.net>
Signed-off-by: Darren Hart <dvhltc@us.ibm.com>
Cc: Helge Bahmann <hcb@chaoticmind.net>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Dinakar Guniguntala <dino@in.ibm.com>
Cc: John Stultz <johnstul@us.ibm.com>
LKML-Reference: <4ACCE21E.5030805@us.ibm.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 kernel/futex.c |    1 -
 1 file changed, 1 deletion(-)

--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -2087,7 +2087,6 @@ int handle_early_requeue_pi_wakeup(struc
 		 * Unqueue the futex_q and determine which it was.
 		 */
 		plist_del(&q->list, &q->list.plist);
-		drop_futex_key_refs(&q->key);
 
 		if (timeout && !timeout->task)
 			ret = -ETIMEDOUT;

[patch 08/26] futex: Move exit_pi_state() call to release_mm()

[Greg KH]

[-- Attachment #1: futex-move-exit_pi_state-call-to-release_mm.patch --]
[-- Type: text/plain, Size: 1287 bytes --]

2.6.31-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Thomas Gleixner <tglx@linutronix.de>

commit 322a2c100a8998158445599ea437fb556aa95b11 upstream.

exit_pi_state() is called from do_exit() but not from do_execve().
Move it to release_mm() so it gets called from do_execve() as well.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
LKML-Reference: <new-submission>
Cc: Anirban Sinha <ani@anirban.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 kernel/exit.c |    2 --
 kernel/fork.c |    2 ++
 2 files changed, 2 insertions(+), 2 deletions(-)

--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -987,8 +987,6 @@ NORET_TYPE void do_exit(long code)
 	tsk->mempolicy = NULL;
 #endif
 #ifdef CONFIG_FUTEX
-	if (unlikely(!list_empty(&tsk->pi_state_list)))
-		exit_pi_state_list(tsk);
 	if (unlikely(current->pi_state_cache))
 		kfree(current->pi_state_cache);
 #endif
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -550,6 +550,8 @@ void mm_release(struct task_struct *tsk,
 	if (unlikely(tsk->compat_robust_list))
 		compat_exit_robust_list(tsk);
 #endif
+	if (unlikely(!list_empty(&tsk->pi_state_list)))
+		exit_pi_state_list(tsk);
 #endif
 
 	/* Get rid of any cached register state */

[patch 09/26] futex: Nullify robust lists after cleanup

[Greg KH]

[-- Attachment #1: futex-nullify-robust-lists-after-cleanup.patch --]
[-- Type: text/plain, Size: 1502 bytes --]

2.6.31-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Peter Zijlstra <peterz@infradead.org>

commit fc6b177dee33365ccb29fe6d2092223cf8d679f9 upstream.

The robust list pointers of user space held futexes are kept intact
over an exec() call. When the exec'ed task exits exit_robust_list() is
called with the stale pointer. The risk of corruption is minimal, but
still it is incorrect to keep the pointers valid. Actually glibc
should uninstall the robust list before calling exec() but we have to
deal with it anyway.

Nullify the pointers after [compat_]exit_robust_list() has been
called.

Reported-by: Anirban Sinha <ani@anirban.org>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 kernel/fork.c |    8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -544,11 +544,15 @@ void mm_release(struct task_struct *tsk,
 
 	/* Get rid of any futexes when releasing the mm */
 #ifdef CONFIG_FUTEX
-	if (unlikely(tsk->robust_list))
+	if (unlikely(tsk->robust_list)) {
 		exit_robust_list(tsk);
+		tsk->robust_list = NULL;
+	}
 #ifdef CONFIG_COMPAT
-	if (unlikely(tsk->compat_robust_list))
+	if (unlikely(tsk->compat_robust_list)) {
 		compat_exit_robust_list(tsk);
+		tsk->compat_robust_list = NULL;
+	}
 #endif
 	if (unlikely(!list_empty(&tsk->pi_state_list)))
 		exit_pi_state_list(tsk);

[patch 10/26] futex: Fix locking imbalance

[Greg KH]

[-- Attachment #1: futex-fix-locking-imbalance.patch --]
[-- Type: text/plain, Size: 1258 bytes --]

2.6.31-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Thomas Gleixner <tglx@linutronix.de>

commit eaaea8036d0261d87d7072c5bc88c7ea730c18ac upstream.

Rich reported a lock imbalance in the futex code:

   http://bugzilla.kernel.org/show_bug.cgi?id=14288

It's caused by the displacement of the retry_private label in
futex_wake_op(). The code unlocks the hash bucket locks in the
error handling path and retries without locking them again which
makes the next unlock fail.

Move retry_private so we lock the hash bucket locks when we retry.

Reported-by: Rich Ercolany <rercola@acm.jhu.edu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Darren Hart <dvhltc@us.ibm.com>
LKML-Reference: <new-submission>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 kernel/futex.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -912,8 +912,8 @@ retry:
 	hb1 = hash_futex(&key1);
 	hb2 = hash_futex(&key2);
 
-	double_lock_hb(hb1, hb2);
 retry_private:
+	double_lock_hb(hb1, hb2);
 	op_ret = futex_atomic_op_inuser(op, uaddr2);
 	if (unlikely(op_ret < 0)) {
 

[patch 11/26] NOHZ: update idle state also when NOHZ is inactive

[Greg KH]

[-- Attachment #1: nohz-update-idle-state-also-when-nohz-is-inactive.patch --]
[-- Type: text/plain, Size: 1959 bytes --]

2.6.31-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Eero Nurkkala <ext-eero.nurkkala@nokia.com>

commit fdc6f192e7e1ae80565af23cc33dc88e3dcdf184 upstream.

Commit f2e21c9610991e95621a81407cdbab881226419b had unfortunate side
effects with cpufreq governors on some systems.

If the system did not switch into NOHZ mode ts->inidle is not set when
tick_nohz_stop_sched_tick() is called from the idle routine. Therefor
all subsequent calls from irq_exit() to tick_nohz_stop_sched_tick()
fail to call tick_nohz_start_idle(). This results in bogus idle
accounting information which is passed to cpufreq governors.

Set the inidle flag unconditionally of the NOHZ active state to keep
the idle time accounting correct in any case.

[ tglx: Added comment and tweaked the changelog ]

Reported-by: Steven Noonan <steven@uplinklabs.net>
Signed-off-by: Eero Nurkkala <ext-eero.nurkkala@nokia.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Cc: Steven Noonan <steven@uplinklabs.net>
LKML-Reference: <1254907901.30157.93.camel@eenurkka-desktop>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 kernel/time/tick-sched.c |    9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -231,6 +231,13 @@ void tick_nohz_stop_sched_tick(int inidl
 	if (!inidle && !ts->inidle)
 		goto end;
 
+	/*
+	 * Set ts->inidle unconditionally. Even if the system did not
+	 * switch to NOHZ mode the cpu frequency governers rely on the
+	 * update of the idle time accounting in tick_nohz_start_idle().
+	 */
+	ts->inidle = 1;
+
 	now = tick_nohz_start_idle(ts);
 
 	/*
@@ -248,8 +255,6 @@ void tick_nohz_stop_sched_tick(int inidl
 	if (unlikely(ts->nohz_mode == NOHZ_MODE_INACTIVE))
 		goto end;
 
-	ts->inidle = 1;
-
 	if (need_resched())
 		goto end;
 

[patch 12/26] ima: ecryptfs fix imbalance message

[Greg KH]

[-- Attachment #1: ima-ecryptfs-fix-imbalance-message.patch --]
[-- Type: text/plain, Size: 1672 bytes --]

2.6.31-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Mimi Zohar <zohar@linux.vnet.ibm.com>

commit 36520be8e32b49bd85a63b7b8b40cd07c3da59a5 upstream.

The unencrypted files are being measured.  Update the counters to get
rid of the ecryptfs imbalance message. (http://bugzilla.redhat.com/519737)

Reported-by: Sachin Garg
Cc: Eric Paris <eparis@redhat.com>
Cc: Dustin Kirkland <kirkland@canonical.com>
Cc: James Morris <jmorris@namei.org>
Cc: David Safford <safford@watson.ibm.com>
Signed-off-by: Mimi Zohar <zohar@us.ibm.com>
Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 fs/ecryptfs/main.c |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

--- a/fs/ecryptfs/main.c
+++ b/fs/ecryptfs/main.c
@@ -35,6 +35,7 @@
 #include <linux/key.h>
 #include <linux/parser.h>
 #include <linux/fs_stack.h>
+#include <linux/ima.h>
 #include "ecryptfs_kernel.h"
 
 /**
@@ -118,6 +119,7 @@ int ecryptfs_init_persistent_file(struct
 	const struct cred *cred = current_cred();
 	struct ecryptfs_inode_info *inode_info =
 		ecryptfs_inode_to_private(ecryptfs_dentry->d_inode);
+	int opened_lower_file = 0;
 	int rc = 0;
 
 	mutex_lock(&inode_info->lower_file_mutex);
@@ -134,9 +136,12 @@ int ecryptfs_init_persistent_file(struct
 			       "for lower_dentry [0x%p] and lower_mnt [0x%p]; "
 			       "rc = [%d]\n", lower_dentry, lower_mnt, rc);
 			inode_info->lower_file = NULL;
-		}
+		} else
+			opened_lower_file = 1;
 	}
 	mutex_unlock(&inode_info->lower_file_mutex);
+	if (opened_lower_file)
+		ima_counts_get(inode_info->lower_file);
 	return rc;
 }
 

[patch 13/26] libata: fix incorrect link online check during probe

[Greg KH]

[-- Attachment #1: libata-fix-incorrect-link-online-check-during-probe.patch --]
[-- Type: text/plain, Size: 4217 bytes --]

2.6.31-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Tejun Heo <tj@kernel.org>

commit 3b761d3d437cffcaf160a5d37eb6b3b186e491d5 upstream.

While trying to work around spurious detection retries for
non-existent devices on slave links, commit
816ab89782ac139a8b65147cca990822bb7e8675 incorrectly added link
offline check logic before ata_eh_thaw() was called.  This means that
if an occupied link goes down briefly at the time that offline check
was performed, device class will be cleared to ATA_DEV_NONE and libata
wouldn't retry thus failing detection of the device.

The offline check should be done after the port is thawed together
with online check so that such link glitches can be detected by the
interrupt handler and handled properly.

Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Tim Blechmann <tim@klingt.org>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/ata/libata-eh.c |   50 ++++++++++++++++++++++++++++++------------------
 1 file changed, 32 insertions(+), 18 deletions(-)

--- a/drivers/ata/libata-eh.c
+++ b/drivers/ata/libata-eh.c
@@ -2541,14 +2541,14 @@ int ata_eh_reset(struct ata_link *link, 
 		dev->pio_mode = XFER_PIO_0;
 		dev->flags &= ~ATA_DFLAG_SLEEPING;
 
-		if (!ata_phys_link_offline(ata_dev_phys_link(dev))) {
-			/* apply class override */
-			if (lflags & ATA_LFLAG_ASSUME_ATA)
-				classes[dev->devno] = ATA_DEV_ATA;
-			else if (lflags & ATA_LFLAG_ASSUME_SEMB)
-				classes[dev->devno] = ATA_DEV_SEMB_UNSUP;
-		} else
-			classes[dev->devno] = ATA_DEV_NONE;
+		if (ata_phys_link_offline(ata_dev_phys_link(dev)))
+			continue;
+
+		/* apply class override */
+		if (lflags & ATA_LFLAG_ASSUME_ATA)
+			classes[dev->devno] = ATA_DEV_ATA;
+		else if (lflags & ATA_LFLAG_ASSUME_SEMB)
+			classes[dev->devno] = ATA_DEV_SEMB_UNSUP;
 	}
 
 	/* record current link speed */
@@ -2581,34 +2581,48 @@ int ata_eh_reset(struct ata_link *link, 
 		slave->eh_info.serror = 0;
 	spin_unlock_irqrestore(link->ap->lock, flags);
 
-	/* Make sure onlineness and classification result correspond.
+	/*
+	 * Make sure onlineness and classification result correspond.
 	 * Hotplug could have happened during reset and some
 	 * controllers fail to wait while a drive is spinning up after
 	 * being hotplugged causing misdetection.  By cross checking
-	 * link onlineness and classification result, those conditions
-	 * can be reliably detected and retried.
+	 * link on/offlineness and classification result, those
+	 * conditions can be reliably detected and retried.
 	 */
 	nr_unknown = 0;
 	ata_for_each_dev(dev, link, ALL) {
-		/* convert all ATA_DEV_UNKNOWN to ATA_DEV_NONE */
-		if (classes[dev->devno] == ATA_DEV_UNKNOWN) {
-			classes[dev->devno] = ATA_DEV_NONE;
-			if (ata_phys_link_online(ata_dev_phys_link(dev)))
+		if (ata_phys_link_online(ata_dev_phys_link(dev))) {
+			if (classes[dev->devno] == ATA_DEV_UNKNOWN) {
+				ata_dev_printk(dev, KERN_DEBUG, "link online "
+					       "but device misclassifed\n");
+				classes[dev->devno] = ATA_DEV_NONE;
 				nr_unknown++;
+			}
+		} else if (ata_phys_link_offline(ata_dev_phys_link(dev))) {
+			if (ata_class_enabled(classes[dev->devno]))
+				ata_dev_printk(dev, KERN_DEBUG, "link offline, "
+					       "clearing class %d to NONE\n",
+					       classes[dev->devno]);
+			classes[dev->devno] = ATA_DEV_NONE;
+		} else if (classes[dev->devno] == ATA_DEV_UNKNOWN) {
+			ata_dev_printk(dev, KERN_DEBUG, "link status unknown, "
+				       "clearing UNKNOWN to NONE\n");
+			classes[dev->devno] = ATA_DEV_NONE;
 		}
 	}
 
 	if (classify && nr_unknown) {
 		if (try < max_tries) {
 			ata_link_printk(link, KERN_WARNING, "link online but "
-				       "device misclassified, retrying\n");
+					"%d devices misclassified, retrying\n",
+					nr_unknown);
 			failed_link = link;
 			rc = -EAGAIN;
 			goto fail;
 		}
 		ata_link_printk(link, KERN_WARNING,
-			       "link online but device misclassified, "
-			       "device detection might fail\n");
+				"link online but %d devices misclassified, "
+				"device detection might fail\n", nr_unknown);
 	}
 
 	/* reset successful, schedule revalidation */

[patch 14/26] sound: via82xx: move DXS volume controls to PCM interface

[Greg KH]

[-- Attachment #1: sound-via82xx-move-dxs-volume-controls-to-pcm-interface.patch --]
[-- Type: text/plain, Size: 3089 bytes --]

2.6.31-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Clemens Ladisch <clemens@ladisch.de>

commit 2fb930b53f513cbc4c102d415d2923a8a7091337 upstream.

The "VIA DXS" controls are actually volume controls that apply to the
four PCM substreams, so we better indicate this connection by moving the
controls to the PCM interface.

Commit b452e08e73c0e3dbb0be82130217be4b7084299e in 2.6.30 broke the
restoring of these volumes by "alsactl restore" that most distributions
use; the renaming in this patch cures that regression by preventing
alsactl from applying the old, wrong volume levels to the new controls.
http://bugzilla.kernel.org/show_bug.cgi?id=14151
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=532613

Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 sound/pci/via82xx.c |   27 ++++++++++++++++++---------
 1 file changed, 18 insertions(+), 9 deletions(-)

--- a/sound/pci/via82xx.c
+++ b/sound/pci/via82xx.c
@@ -1626,7 +1626,7 @@ static int snd_via8233_dxs_volume_get(st
 				      struct snd_ctl_elem_value *ucontrol)
 {
 	struct via82xx *chip = snd_kcontrol_chip(kcontrol);
-	unsigned int idx = snd_ctl_get_ioff(kcontrol, &ucontrol->id);
+	unsigned int idx = kcontrol->id.subdevice;
 
 	ucontrol->value.integer.value[0] = VIA_DXS_MAX_VOLUME - chip->playback_volume[idx][0];
 	ucontrol->value.integer.value[1] = VIA_DXS_MAX_VOLUME - chip->playback_volume[idx][1];
@@ -1646,7 +1646,7 @@ static int snd_via8233_dxs_volume_put(st
 				      struct snd_ctl_elem_value *ucontrol)
 {
 	struct via82xx *chip = snd_kcontrol_chip(kcontrol);
-	unsigned int idx = snd_ctl_get_ioff(kcontrol, &ucontrol->id);
+	unsigned int idx = kcontrol->id.subdevice;
 	unsigned long port = chip->port + 0x10 * idx;
 	unsigned char val;
 	int i, change = 0;
@@ -1705,11 +1705,12 @@ static struct snd_kcontrol_new snd_via82
 };
 
 static struct snd_kcontrol_new snd_via8233_dxs_volume_control __devinitdata = {
-	.name = "VIA DXS Playback Volume",
-	.iface = SNDRV_CTL_ELEM_IFACE_MIXER,
+	.iface = SNDRV_CTL_ELEM_IFACE_PCM,
+	.device = 0,
+	/* .subdevice set later */
+	.name = "PCM Playback Volume",
 	.access = (SNDRV_CTL_ELEM_ACCESS_READWRITE |
 		   SNDRV_CTL_ELEM_ACCESS_TLV_READ),
-	.count = 4,
 	.info = snd_via8233_dxs_volume_info,
 	.get = snd_via8233_dxs_volume_get,
 	.put = snd_via8233_dxs_volume_put,
@@ -1936,10 +1937,18 @@ static int __devinit snd_via8233_init_mi
 		}
 		else /* Using DXS when PCM emulation is enabled is really weird */
 		{
-			/* Standalone DXS controls */
-			err = snd_ctl_add(chip->card, snd_ctl_new1(&snd_via8233_dxs_volume_control, chip));
-			if (err < 0)
-				return err;
+			for (i = 0; i < 4; ++i) {
+				struct snd_kcontrol *kctl;
+
+				kctl = snd_ctl_new1(
+					&snd_via8233_dxs_volume_control, chip);
+				if (!kctl)
+					return -ENOMEM;
+				kctl->id.subdevice = i;
+				err = snd_ctl_add(chip->card, kctl);
+				if (err < 0)
+					return err;
+			}
 		}
 	}
 	/* select spdif data slot 10/11 */

[patch 15/26] ASoC: WM8350 capture PGA mutes are inverted

[Greg KH]

[-- Attachment #1: asoc-wm8350-capture-pga-mutes-are-inverted.patch --]
[-- Type: text/plain, Size: 1123 bytes --]

2.6.31-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Mark Brown <broonie@opensource.wolfsonmicro.com>

commit 5b7dde346881b12246669ae97b3a2793c27b32b6 upstream.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 sound/soc/codecs/wm8350.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/sound/soc/codecs/wm8350.c
+++ b/sound/soc/codecs/wm8350.c
@@ -580,7 +580,7 @@ static const struct snd_kcontrol_new wm8
 	SOC_DAPM_SINGLE_TLV("L3 Capture Volume",
 			    WM8350_INPUT_MIXER_VOLUME_L, 9, 7, 0, out_mix_tlv),
 	SOC_DAPM_SINGLE("PGA Capture Switch",
-			WM8350_LEFT_INPUT_VOLUME, 14, 1, 0),
+			WM8350_LEFT_INPUT_VOLUME, 14, 1, 1),
 };
 
 /* Right Input Mixer */
@@ -590,7 +590,7 @@ static const struct snd_kcontrol_new wm8
 	SOC_DAPM_SINGLE_TLV("L3 Capture Volume",
 			    WM8350_INPUT_MIXER_VOLUME_R, 13, 7, 0, out_mix_tlv),
 	SOC_DAPM_SINGLE("PGA Capture Switch",
-			WM8350_RIGHT_INPUT_VOLUME, 14, 1, 0),
+			WM8350_RIGHT_INPUT_VOLUME, 14, 1, 1),
 };
 
 /* Left Mic Mixer */

[patch 16/26] KVM: Prevent overflow in KVM_GET_SUPPORTED_CPUID

[Greg KH]

[-- Attachment #1: kvm-prevent-overflow-in-kvm_get_supported_cpuid.patch --]
[-- Type: text/plain, Size: 875 bytes --]

2.6.31-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Avi Kivity <avi@redhat.com>

commit 6a54435560efdab1a08f429a954df4d6c740bddf upstream.

The number of entries is multiplied by the entry size, which can
overflow on 32-bit hosts.  Bound the entry count instead.

Reported-by: David Wagner <daw@cs.berkeley.edu>
Signed-off-by: Avi Kivity <avi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 arch/x86/kvm/x86.c |    2 ++
 1 file changed, 2 insertions(+)

--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1429,6 +1429,8 @@ static int kvm_dev_ioctl_get_supported_c
 
 	if (cpuid->nent < 1)
 		goto out;
+	if (cpuid->nent > KVM_MAX_CPUID_ENTRIES)
+		cpuid->nent = KVM_MAX_CPUID_ENTRIES;
 	r = -ENOMEM;
 	cpuid_entries = vmalloc(sizeof(struct kvm_cpuid_entry2) * cpuid->nent);
 	if (!cpuid_entries)

[patch 17/26] KVM: VMX: flush TLB with INVEPT on cpu migration

[Greg KH]

[-- Attachment #1: kvm-vmx-flush-tlb-with-invept-on-cpu-migration.patch --]
[-- Type: text/plain, Size: 981 bytes --]

2.6.31-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Marcelo Tosatti <mtosatti@redhat.com>

commit eb5109e311b5152c0614a28d7d615d087f268f19 upstream.

It is possible that stale EPTP-tagged mappings are used, if a
vcpu migrates to a different pcpu.

Set KVM_REQ_TLB_FLUSH in vmx_vcpu_load, when switching pcpus, which
will invalidate both VPID and EPT mappings on the next vm-entry.

Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 arch/x86/kvm/vmx.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -661,7 +661,7 @@ static void vmx_vcpu_load(struct kvm_vcp
 	if (vcpu->cpu != cpu) {
 		vcpu_clear(vmx);
 		kvm_migrate_timers(vcpu);
-		vpid_sync_vcpu_all(vmx);
+		set_bit(KVM_REQ_TLB_FLUSH, &vcpu->requests);
 		local_irq_disable();
 		list_add(&vmx->local_vcpus_link,
 			 &per_cpu(vcpus_on_cpu, cpu));

[patch 18/26] KVM: fix LAPIC timer period overflow

[Greg KH]

[-- Attachment #1: kvm-fix-lapic-timer-period-overflow.patch --]
[-- Type: text/plain, Size: 953 bytes --]

2.6.31-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Aurelien Jarno <aurelien@aurel32.net>

commit b2d83cfa3fdefe5c6573d443d099a18dc3a93c5f upstream.

Don't overflow when computing the 64-bit period from 32-bit registers.

Fixes sourceforge bug #2826486.

Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 arch/x86/kvm/lapic.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -567,7 +567,7 @@ static void start_apic_timer(struct kvm_
 {
 	ktime_t now = apic->lapic_timer.timer.base->get_time();
 
-	apic->lapic_timer.period = apic_get_reg(apic, APIC_TMICT) *
+	apic->lapic_timer.period = (u64)apic_get_reg(apic, APIC_TMICT) *
 		    APIC_BUS_CYCLE_NS * apic->divide_count;
 	atomic_set(&apic->lapic_timer.pending, 0);
 

[patch 19/26] KVM: SVM: Fix tsc offset adjustment when running nested

[Greg KH]

[-- Attachment #1: kvm-svm-fix-tsc-offset-adjustment-when-running-nested.patch --]
[-- Type: text/plain, Size: 1106 bytes --]

2.6.31-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Joerg Roedel <joerg.roedel@amd.com>

commit 77b1ab1732feb5e3dcbaf31d2f7547c5229f5f3a upstream.

When svm_vcpu_load is called while the vcpu is running in
guest mode the tsc adjustment made there is lost on the next
emulated #vmexit. This causes the tsc running backwards in
the guest. This patch fixes the issue by also adjusting the
tsc_offset in the emulated hsave area so that it will not
get lost.

Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 arch/x86/kvm/svm.c |    2 ++
 1 file changed, 2 insertions(+)

--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -709,6 +709,8 @@ static void svm_vcpu_load(struct kvm_vcp
 		rdtscll(tsc_this);
 		delta = vcpu->arch.host_tsc - tsc_this;
 		svm->vmcb->control.tsc_offset += delta;
+		if (is_nested(svm))
+			svm->nested.hsave->control.tsc_offset += delta;
 		vcpu->cpu = cpu;
 		kvm_migrate_timers(vcpu);
 		svm->asid_generation = 0;

[patch 20/26] net: Fix wrong sizeof

[Greg KH]

[-- Attachment #1: net-fix-wrong-sizeof.patch --]
[-- Type: text/plain, Size: 1537 bytes --]

2.6.31-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Jean Delvare <khali@linux-fr.org>

commit b607bd900051efc3308c4edc65dd98b34b230021 upstream.

Which is why I have always preferred sizeof(struct foo) over
sizeof(var).

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 Documentation/networking/timestamping/timestamping.c |    2 +-
 drivers/net/iseries_veth.c                           |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

--- a/Documentation/networking/timestamping/timestamping.c
+++ b/Documentation/networking/timestamping/timestamping.c
@@ -381,7 +381,7 @@ int main(int argc, char **argv)
 	memset(&hwtstamp, 0, sizeof(hwtstamp));
 	strncpy(hwtstamp.ifr_name, interface, sizeof(hwtstamp.ifr_name));
 	hwtstamp.ifr_data = (void *)&hwconfig;
-	memset(&hwconfig, 0, sizeof(&hwconfig));
+	memset(&hwconfig, 0, sizeof(hwconfig));
 	hwconfig.tx_type =
 		(so_timestamping_flags & SOF_TIMESTAMPING_TX_HARDWARE) ?
 		HWTSTAMP_TX_ON : HWTSTAMP_TX_OFF;
--- a/drivers/net/iseries_veth.c
+++ b/drivers/net/iseries_veth.c
@@ -495,7 +495,7 @@ static void veth_take_cap_ack(struct vet
 			   cnx->remote_lp);
 	} else {
 		memcpy(&cnx->cap_ack_event, event,
-		       sizeof(&cnx->cap_ack_event));
+		       sizeof(cnx->cap_ack_event));
 		cnx->state |= VETH_STATE_GOTCAPACK;
 		veth_kick_statemachine(cnx);
 	}

[patch 21/26] mm: add_to_swap_cache() must not sleep

[Greg KH]

[-- Attachment #1: mm-add_to_swap_cache-must-not-sleep.patch --]
[-- Type: text/plain, Size: 4846 bytes --]

2.6.31-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>

commit 31a5639623a487d6db996c8138c9e53fef2e2d91 upstream.

After commit 355cfa73 ("mm: modify swap_map and add SWAP_HAS_CACHE flag"),
read_swap_cache_async() will busy-wait while a entry doesn't exist in swap
cache but it has SWAP_HAS_CACHE flag.

Such entries can exist on add/delete path of swap cache.  On add path,
add_to_swap_cache() is called soon after SWAP_HAS_CACHE flag is set, and
on delete path, swapcache_free() will be called (SWAP_HAS_CACHE flag is
cleared) soon after __delete_from_swap_cache() is called.  So, the
busy-wait works well in most cases.

But this mechanism can cause soft lockup if add_to_swap_cache() sleeps and
read_swap_cache_async() tries to swap-in the same entry on the same cpu.

This patch calls radix_tree_preload() before swapcache_prepare() and
divides add_to_swap_cache() into two part: radix_tree_preload() part and
radix_tree_insert() part(define it as __add_to_swap_cache()).

Signed-off-by: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Balbir Singh <balbir@linux.vnet.ibm.com>
Cc: Hugh Dickins <hugh.dickins@tiscali.co.uk>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 mm/swap_state.c |   70 ++++++++++++++++++++++++++++++++++++--------------------
 1 file changed, 46 insertions(+), 24 deletions(-)

--- a/mm/swap_state.c
+++ b/mm/swap_state.c
@@ -66,10 +66,10 @@ void show_swap_cache_info(void)
 }
 
 /*
- * add_to_swap_cache resembles add_to_page_cache_locked on swapper_space,
+ * __add_to_swap_cache resembles add_to_page_cache_locked on swapper_space,
  * but sets SwapCache flag and private instead of mapping and index.
  */
-int add_to_swap_cache(struct page *page, swp_entry_t entry, gfp_t gfp_mask)
+static int __add_to_swap_cache(struct page *page, swp_entry_t entry)
 {
 	int error;
 
@@ -77,28 +77,37 @@ int add_to_swap_cache(struct page *page,
 	VM_BUG_ON(PageSwapCache(page));
 	VM_BUG_ON(!PageSwapBacked(page));
 
+	page_cache_get(page);
+	SetPageSwapCache(page);
+	set_page_private(page, entry.val);
+
+	spin_lock_irq(&swapper_space.tree_lock);
+	error = radix_tree_insert(&swapper_space.page_tree, entry.val, page);
+	if (likely(!error)) {
+		total_swapcache_pages++;
+		__inc_zone_page_state(page, NR_FILE_PAGES);
+		INC_CACHE_INFO(add_total);
+	}
+	spin_unlock_irq(&swapper_space.tree_lock);
+
+	if (unlikely(error)) {
+		set_page_private(page, 0UL);
+		ClearPageSwapCache(page);
+		page_cache_release(page);
+	}
+
+	return error;
+}
+
+
+int add_to_swap_cache(struct page *page, swp_entry_t entry, gfp_t gfp_mask)
+{
+	int error;
+
 	error = radix_tree_preload(gfp_mask);
 	if (!error) {
-		page_cache_get(page);
-		SetPageSwapCache(page);
-		set_page_private(page, entry.val);
-
-		spin_lock_irq(&swapper_space.tree_lock);
-		error = radix_tree_insert(&swapper_space.page_tree,
-						entry.val, page);
-		if (likely(!error)) {
-			total_swapcache_pages++;
-			__inc_zone_page_state(page, NR_FILE_PAGES);
-			INC_CACHE_INFO(add_total);
-		}
-		spin_unlock_irq(&swapper_space.tree_lock);
+		error = __add_to_swap_cache(page, entry);
 		radix_tree_preload_end();
-
-		if (unlikely(error)) {
-			set_page_private(page, 0UL);
-			ClearPageSwapCache(page);
-			page_cache_release(page);
-		}
 	}
 	return error;
 }
@@ -289,13 +298,24 @@ struct page *read_swap_cache_async(swp_e
 		}
 
 		/*
+		 * call radix_tree_preload() while we can wait.
+		 */
+		err = radix_tree_preload(gfp_mask & GFP_KERNEL);
+		if (err)
+			break;
+
+		/*
 		 * Swap entry may have been freed since our caller observed it.
 		 */
 		err = swapcache_prepare(entry);
-		if (err == -EEXIST) /* seems racy */
+		if (err == -EEXIST) {	/* seems racy */
+			radix_tree_preload_end();
 			continue;
-		if (err)           /* swp entry is obsolete ? */
+		}
+		if (err) {		/* swp entry is obsolete ? */
+			radix_tree_preload_end();
 			break;
+		}
 
 		/*
 		 * Associate the page with swap entry in the swap cache.
@@ -307,8 +327,9 @@ struct page *read_swap_cache_async(swp_e
 		 */
 		__set_page_locked(new_page);
 		SetPageSwapBacked(new_page);
-		err = add_to_swap_cache(new_page, entry, gfp_mask & GFP_KERNEL);
+		err = __add_to_swap_cache(new_page, entry);
 		if (likely(!err)) {
+			radix_tree_preload_end();
 			/*
 			 * Initiate read into locked page and return.
 			 */
@@ -316,6 +337,7 @@ struct page *read_swap_cache_async(swp_e
 			swap_readpage(new_page);
 			return new_page;
 		}
+		radix_tree_preload_end();
 		ClearPageSwapBacked(new_page);
 		__clear_page_locked(new_page);
 		swapcache_free(entry, NULL);

[patch 22/26] sis5513: fix PIO setup for ATAPI devices

[Greg KH]

[-- Attachment #1: sis5513-fix-pio-setup-for-atapi-devices.patch --]
[-- Type: text/plain, Size: 1969 bytes --]

2.6.31-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>

commit e13ee546bb06453939014c7b854e77fb643fd6f1 upstream.

Clear prefetch setting before potentially (re-)enabling it in
config_drive_art_rwp() so the transition of the device type on
the port from ATA to ATAPI (i.e. during warm-plug operation)
is handled correctly.

This is a really old bug (it probably goes back to very early
days of the driver) but it was only affecting warm-plug operation
until the recent "ide: try to use PIO Mode 0 during probe if
possible" change (commit 6029336426a2b43e4bc6f4a84be8789a047d139e).

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Tested-by: David Fries <david@fries.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/ide/sis5513.c |   10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

--- a/drivers/ide/sis5513.c
+++ b/drivers/ide/sis5513.c
@@ -2,7 +2,7 @@
  * Copyright (C) 1999-2000	Andre Hedrick <andre@linux-ide.org>
  * Copyright (C) 2002		Lionel Bouton <Lionel.Bouton@inet6.fr>, Maintainer
  * Copyright (C) 2003		Vojtech Pavlik <vojtech@suse.cz>
- * Copyright (C) 2007		Bartlomiej Zolnierkiewicz
+ * Copyright (C) 2007-2009	Bartlomiej Zolnierkiewicz
  *
  * May be copied or modified under the terms of the GNU General Public License
  *
@@ -281,11 +281,13 @@ static void config_drive_art_rwp(ide_dri
 
 	pci_read_config_byte(dev, 0x4b, &reg4bh);
 
+	rw_prefetch = reg4bh & ~(0x11 << drive->dn);
+
 	if (drive->media == ide_disk)
-		rw_prefetch = 0x11 << drive->dn;
+		rw_prefetch |= 0x11 << drive->dn;
 
-	if ((reg4bh & (0x11 << drive->dn)) != rw_prefetch)
-		pci_write_config_byte(dev, 0x4b, reg4bh|rw_prefetch);
+	if (reg4bh != rw_prefetch)
+		pci_write_config_byte(dev, 0x4b, rw_prefetch);
 }
 
 static void sis_set_pio_mode(ide_drive_t *drive, const u8 pio)

[patch 23/26] PIT fixes to unbreak suspend/resume (bug #14222)

[Greg KH]

[-- Attachment #1: pit-fixes-to-unbreak-suspend-resume.patch --]
[-- Type: text/plain, Size: 3329 bytes --]

2.6.31-stable review patch.  If anyone has any objections, please let us know.

------------------
From: john stultz <johnstul@us.ibm.com>

Resolved differently upstream in commit 8cab02dc3c58a12235c6d463ce684dded9696848

Ondrej Zary reported a suspend/resume hang with 2.6.31 in bug #14222.

http://bugzilla.kernel.org/show_bug.cgi?id=14222

The hang was bisected to c7121843685de2bf7f3afd3ae1d6a146010bf1fc
however, that was really just the last straw that caused the issue.

The problem was that on suspend, the PIT is removed as a clocksource,
and was using the mult value essentially as a is_enabled() flag. The
mult adjustments done in the commit above caused that usage to break,
causing bad list manipulation and the oops.

Further, on resume, the PIT clocksource is never restored, causing the
system to run in a degraded mode with jiffies as the clocksource.

This issue has since been resolved in 2.6.32-rc by commit
8cab02dc3c58a12235c6d463ce684dded9696848 which removes the clocksource
disabling on suspend. Testing shows no issues there.

So the following patch rectifies the situation for 2.6.31 users of the
PIT clocksource that use suspend and resume (which is probably not that
many).

Many thanks to Ondrej for helping narrow down what was happening, what
caused it, and verifying the fix.

---------------

Avoid using the unprotected clocksource.mult value as an "is_registered"
flag, instead us an explicit flag variable. This avoids possible list
corruption if the clocksource is double-unregistered.

Also re-register the PIT clocksource on resume so folks don't have to
use jiffies after suspend.


Signed-off-by: John Stultz <johnstul@us.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 arch/x86/kernel/i8253.c |   27 ++++++++++++++++++++-------
 1 file changed, 20 insertions(+), 7 deletions(-)

--- a/arch/x86/kernel/i8253.c
+++ b/arch/x86/kernel/i8253.c
@@ -21,8 +21,10 @@ EXPORT_SYMBOL(i8253_lock);
 
 #ifdef CONFIG_X86_32
 static void pit_disable_clocksource(void);
+static void pit_enable_clocksource(void);
 #else
 static inline void pit_disable_clocksource(void) { }
+static inline void pit_enable_clocksource(void) { }
 #endif
 
 /*
@@ -67,7 +69,7 @@ static void init_pit_timer(enum clock_ev
 		break;
 
 	case CLOCK_EVT_MODE_RESUME:
-		/* Nothing to do here */
+		pit_enable_clocksource();
 		break;
 	}
 	spin_unlock(&i8253_lock);
@@ -200,19 +202,27 @@ static struct clocksource pit_cs = {
 	.shift		= 20,
 };
 
+int pit_cs_registered;
 static void pit_disable_clocksource(void)
 {
-	/*
-	 * Use mult to check whether it is registered or not
-	 */
-	if (pit_cs.mult) {
+	if (pit_cs_registered) {
 		clocksource_unregister(&pit_cs);
-		pit_cs.mult = 0;
+		pit_cs_registered = 0;
+	}
+}
+
+static void pit_enable_clocksource(void)
+{
+	if (!pit_cs_registered && !clocksource_register(&pit_cs)) {
+		pit_cs_registered = 1;
 	}
 }
 
+
+
 static int __init init_pit_clocksource(void)
 {
+	int ret;
 	 /*
 	  * Several reasons not to register PIT as a clocksource:
 	  *
@@ -226,7 +236,10 @@ static int __init init_pit_clocksource(v
 
 	pit_cs.mult = clocksource_hz2mult(CLOCK_TICK_RATE, pit_cs.shift);
 
-	return clocksource_register(&pit_cs);
+	ret = clocksource_register(&pit_cs);
+	if (!ret)
+		pit_cs_registered = 1;
+	return ret;
 }
 arch_initcall(init_pit_clocksource);
 

[patch 24/26] IMA: open new file for read

[Greg KH]

[-- Attachment #1: ima-open-new-file-for-read.patch --]
[-- Type: text/plain, Size: 1006 bytes --]

2.6.31-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Mimi Zohar <zohar@linux.vnet.ibm.com>

commit 6c1488fd581a447ec87c4b59f0d33f95f0aa441b upstream.

When creating a new file, ima_path_check() assumed the new file
was being opened for write. Call ima_path_check() with the
appropriate acc_mode so that the read/write counters are
incremented correctly.

Signed-off-by: Mimi Zohar <zohar@us.ibm.com>
Signed-off-by: James Morris <jmorris@namei.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

--- a/fs/namei.c
+++ b/fs/namei.c
@@ -1533,9 +1533,11 @@ int may_open(struct path *path, int acc_mode, int flag)
 	if (error)
 		return error;
 
-	error = ima_path_check(path,
-			       acc_mode & (MAY_READ | MAY_WRITE | MAY_EXEC),
+	error = ima_path_check(path, acc_mode ?
+			       acc_mode & (MAY_READ | MAY_WRITE | MAY_EXEC) :
+			       ACC_MODE(flag) & (MAY_READ | MAY_WRITE),
 			       IMA_COUNT_UPDATE);
+
 	if (error)
 		return error;
 	/*

[patch 25/26] ACPI: Clarify resource conflict message

[Greg KH]

[-- Attachment #1: acpi-clarify-resource-conflict-message.patch --]
[-- Type: text/plain, Size: 1920 bytes --]

2.6.31-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Jean Delvare <jdelvare@suse.de>

commit 14f03343ad1080c2fea29ab2c13f05b976c4584e upstream.

The message "ACPI: Device needs an ACPI driver" is misleading. The
device _may_ need an ACPI driver, if the BIOS implemented a custom
API for the device in question (which, AFAIK, can't be checked.) If
not, then either a generic ACPI driver may be used (for example
"thermal"), or nothing can be done (other than a white list).

I propose to reword the message to:

ACPI: If an ACPI driver is available for this device, you should use
it instead of the native driver

which I think is more correct. Comments and suggestions welcome.

I also added a message warning about possible problems and system
instability when users pass acpi_enforce_resources=lax, as suggested
by Len.

Signed-off-by: Jean Delvare <jdelvare@suse.de>
Cc: Thomas Renninger <trenn@suse.de>
Cc: Alan Jenkins <sourcejedi.lkml@googlemail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/acpi/osl.c |    8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -1182,7 +1182,13 @@ int acpi_check_resource_conflict(struct 
 			       res_list_elem->name,
 			       (long long) res_list_elem->start,
 			       (long long) res_list_elem->end);
-			printk(KERN_INFO "ACPI: Device needs an ACPI driver\n");
+			if (acpi_enforce_resources == ENFORCE_RESOURCES_LAX)
+				printk(KERN_NOTICE "ACPI: This conflict may"
+				       " cause random problems and system"
+				       " instability\n");
+			printk(KERN_INFO "ACPI: If an ACPI driver is available"
+			       " for this device, you should use it instead of"
+			       " the native driver\n");
 		}
 		if (acpi_enforce_resources == ENFORCE_RESOURCES_STRICT)
 			return -EBUSY;

[patch 26/26] ACPI: fix Compaq Evo N800c (Pentium 4m) boot hang regression

[Greg KH]

[-- Attachment #1: acpi-fix-compaq-evo-n800c-boot-hang-regression.patch --]
[-- Type: text/plain, Size: 1049 bytes --]

2.6.31-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Zhao Yakui <yakui.zhao@intel.com>

commit 3e2ada5867b7e9fa0b296d30fa8f3726ebd0a8b7 upstream.

Don't disable ARB_DISABLE when the familary ID is 0x0F.

http://bugzilla.kernel.org/show_bug.cgi?id=14211

This was a 2.6.31 regression, and so this patch
needs to be applied to 2.6.31.stable

Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 arch/x86/kernel/acpi/cstate.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/x86/kernel/acpi/cstate.c
+++ b/arch/x86/kernel/acpi/cstate.c
@@ -48,7 +48,7 @@ void acpi_processor_power_init_bm_check(
 	 * P4, Core and beyond CPUs
 	 */
 	if (c->x86_vendor == X86_VENDOR_INTEL &&
-	    (c->x86 > 0x6 || (c->x86 == 6 && c->x86_model >= 14)))
+	    (c->x86 > 0xf || (c->x86 == 6 && c->x86_model >= 14)))
 			flags->bm_control = 0;
 }
 EXPORT_SYMBOL(acpi_processor_power_init_bm_check);

Re: [patch 00/26] 2.6.31.4-stable review

[Greg KH]

On Fri, Oct 09, 2009 at 04:12:49PM -0700, Greg KH wrote:
> This is the start of the stable review cycle for the 2.6.31.4 release.
> There are 26 patches in this series, all will be posted as a response to
> this one.  If anyone has any issues with these being applied, please let
> us know.  If anyone is a maintainer of the proper subsystem, and wants
> to add a Signed-off-by: line to the patch, please respond with it.

Oops, a bunch of network patches came in right when this went out, and I
don't want to have to wait to get them on, so I've rolled a -rc2 version
now.

There's now 37 patches in this series, I'll attach the rest to this
thread now.

The whole patch series can be found in one patch at:
	kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.31.4-rc2.gz
and the diffstat can be found below.


thanks,

greg k-h

-----------

 .../networking/timestamping/timestamping.c         |    2 +-
 Makefile                                           |    2 +-
 arch/x86/ia32/ia32entry.S                          |   36 +++++++----
 arch/x86/include/asm/checksum_32.h                 |    3 +-
 arch/x86/kernel/acpi/cstate.c                      |    2 +-
 arch/x86/kernel/i8253.c                            |   27 ++++++--
 arch/x86/kvm/lapic.c                               |    2 +-
 arch/x86/kvm/svm.c                                 |    2 +
 arch/x86/kvm/vmx.c                                 |    2 +-
 arch/x86/kvm/x86.c                                 |    2 +
 drivers/acpi/osl.c                                 |    8 ++-
 drivers/ata/libata-eh.c                            |   50 +++++++++-----
 drivers/char/tty_ldisc.c                           |    7 +--
 drivers/ide/sis5513.c                              |   10 ++-
 drivers/net/appletalk/ipddp.c                      |    3 +-
 drivers/net/iseries_veth.c                         |    2 +-
 drivers/net/sky2.c                                 |    4 +-
 drivers/net/tun.c                                  |    4 +-
 drivers/net/usb/smsc95xx.c                         |    2 +-
 drivers/net/usb/usbnet.c                           |    2 +-
 fs/ecryptfs/main.c                                 |    7 ++-
 fs/namei.c                                         |    6 +-
 include/linux/ftrace.h                             |    2 +-
 include/linux/usb/usbnet.h                         |    1 +
 kernel/exit.c                                      |    2 -
 kernel/fork.c                                      |   10 ++-
 kernel/futex.c                                     |    3 +-
 kernel/time/tick-sched.c                           |    9 ++-
 kernel/trace/ftrace.c                              |   23 ++-----
 mm/swap_state.c                                    |   70 +++++++++++++-------
 net/appletalk/aarp.c                               |   16 +++--
 net/appletalk/ddp.c                                |   58 +++++++++--------
 net/ax25/af_ax25.c                                 |    6 +-
 net/core/dev.c                                     |    6 +-
 net/core/sock.c                                    |   19 ++++--
 net/ipv4/tcp_minisocks.c                           |    2 +-
 net/ipv6/sit.c                                     |    2 +-
 net/unix/af_unix.c                                 |    5 +-
 sound/pci/hda/patch_realtek.c                      |    1 +
 sound/pci/via82xx.c                                |   27 +++++---
 sound/soc/codecs/wm8350.c                          |    4 +-
 41 files changed, 277 insertions(+), 174 deletions(-)

[patch 27/37] net: restore tx timestamping for accelerated vlans

[Greg KH]

[-- Attachment #1: net-restore-tx-timestamping-for-accelerated-vlans.patch --]
[-- Type: text/plain, Size: 1755 bytes --]

2.6.31-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Eric Dumazet <eric.dumazet@gmail.com>

[ Upstream commit 81bbb3d4048cf577b5babcb0834230de391a35c5 ]

Since commit 9b22ea560957de1484e6b3e8538f7eef202e3596
( net: fix packet socket delivery in rx irq handler )

We lost rx timestamping of packets received on accelerated vlans.

Effect is that tcpdump on real dev can show strange timings, since it gets rx timestamps
too late (ie at skb dequeueing time, not at skb queueing time)

14:47:26.986871 IP 192.168.20.110 > 192.168.20.141: icmp 64: echo request seq 1
14:47:26.986786 IP 192.168.20.141 > 192.168.20.110: icmp 64: echo reply seq 1

14:47:27.986888 IP 192.168.20.110 > 192.168.20.141: icmp 64: echo request seq 2
14:47:27.986781 IP 192.168.20.141 > 192.168.20.110: icmp 64: echo reply seq 2

14:47:28.986896 IP 192.168.20.110 > 192.168.20.141: icmp 64: echo request seq 3
14:47:28.986780 IP 192.168.20.141 > 192.168.20.110: icmp 64: echo reply seq 3

Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 net/core/dev.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2248,6 +2248,9 @@ int netif_receive_skb(struct sk_buff *sk
 	int ret = NET_RX_DROP;
 	__be16 type;
 
+	if (!skb->tstamp.tv64)
+		net_timestamp(skb);
+
 	if (skb->vlan_tci && vlan_hwaccel_do_receive(skb))
 		return NET_RX_SUCCESS;
 
@@ -2255,9 +2258,6 @@ int netif_receive_skb(struct sk_buff *sk
 	if (netpoll_receive_skb(skb))
 		return NET_RX_DROP;
 
-	if (!skb->tstamp.tv64)
-		net_timestamp(skb);
-
 	if (!skb->iif)
 		skb->iif = skb->dev->ifindex;
 

[patch 28/37] net: unix: fix sending fds in multiple buffers

[Greg KH]

[-- Attachment #1: net-unix-fix-sending-fds-in-multiple-buffers.patch --]
[-- Type: text/plain, Size: 2447 bytes --]

2.6.31-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Miklos Szeredi <mszeredi@suse.cz>

[ Upstream commit 8ba69ba6a324b13e1190fc31e41954d190fd4f1d ]

Kalle Olavi Niemitalo reported that:

  "..., when one process calls sendmsg once to send 43804 bytes of
  data and one file descriptor, and another process then calls recvmsg
  three times to receive the 16032+16032+11740 bytes, each of those
  recvmsg calls returns the file descriptor in the ancillary data.  I
  confirmed this with strace.  The behaviour differs from Linux
  2.6.26, where reportedly only one of those recvmsg calls (I think
  the first one) returned the file descriptor."

This bug was introduced by a patch from me titled "net: unix: fix inflight
counting bug in garbage collector", commit 6209344f5.

And the reason is, quoting Kalle:

  "Before your patch, unix_attach_fds() would set scm->fp = NULL, so
  that if the loop in unix_stream_sendmsg() ran multiple iterations,
  it could not call unix_attach_fds() again.  But now,
  unix_attach_fds() leaves scm->fp unchanged, and I think this causes
  it to be called multiple times and duplicate the same file
  descriptors to each struct sk_buff."

Fix this by introducing a flag that is cleared at the start and set
when the fds attached to the first buffer.  The resulting code should
work equivalently to the one on 2.6.26.

Reported-by: Kalle Olavi Niemitalo <kon@iki.fi>
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 net/unix/af_unix.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -1501,6 +1501,7 @@ static int unix_stream_sendmsg(struct ki
 	struct sk_buff *skb;
 	int sent = 0;
 	struct scm_cookie tmp_scm;
+	bool fds_sent = false;
 
 	if (NULL == siocb->scm)
 		siocb->scm = &tmp_scm;
@@ -1562,12 +1563,14 @@ static int unix_stream_sendmsg(struct ki
 		size = min_t(int, size, skb_tailroom(skb));
 
 		memcpy(UNIXCREDS(skb), &siocb->scm->creds, sizeof(struct ucred));
-		if (siocb->scm->fp) {
+		/* Only send the fds in the first buffer */
+		if (siocb->scm->fp && !fds_sent) {
 			err = unix_attach_fds(siocb->scm, skb);
 			if (err) {
 				kfree_skb(skb);
 				goto out_err;
 			}
+			fds_sent = true;
 		}
 
 		err = memcpy_fromiovec(skb_put(skb, size), msg->msg_iov, size);

[patch 29/37] tun: Return -EINVAL if neither IFF_TUN nor IFF_TAP is set.

[Greg KH]

[-- Attachment #1: tun-return-einval-if-neither-iff_tun-nor-iff_tap-is-set.patch --]
[-- Type: text/plain, Size: 1099 bytes --]

2.6.31-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Kusanagi Kouichi <slash@ma.neweb.ne.jp>

[ Upstream commit 36989b90879c785f95b877bdcf65a2527dadd893 ]

After commit 2b980dbd77d229eb60588802162c9659726b11f4
("lsm: Add hooks to the TUN driver") tun_set_iff doesn't
return -EINVAL though neither IFF_TUN nor IFF_TAP is set.

Signed-off-by: Kusanagi Kouichi <slash@ma.neweb.ne.jp>
Reviewed-by: Paul Moore <paul.moore@hp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 drivers/net/tun.c |    4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -943,8 +943,6 @@ static int tun_set_iff(struct net *net, 
 		char *name;
 		unsigned long flags = 0;
 
-		err = -EINVAL;
-
 		if (!capable(CAP_NET_ADMIN))
 			return -EPERM;
 
@@ -958,7 +956,7 @@ static int tun_set_iff(struct net *net, 
 			flags |= TUN_TAP_DEV;
 			name = "tap%d";
 		} else
-			goto failed;
+			return -EINVAL;
 
 		if (*ifr->ifr_name)
 			name = ifr->ifr_name;

Re: [Stable-review] [patch 29/37] tun: Return -EINVAL if neither IFF_TUN nor IFF_TAP is set.

[Stefan Bader]

Just as a note (as I am too late for proper review), this patch is doing 
nothing in the case of 2.6.31 as it lacks the previous commit to break things. 
But it does not hurt either as it is functionally the same as before.

-Stefan

[patch 30/37] tcp: fix CONFIG_TCP_MD5SIG + CONFIG_PREEMPT timer BUG()

[Greg KH]

[-- Attachment #1: tcp-fix-config_tcp_md5sig-config_preempt-timer-bug.patch --]
[-- Type: text/plain, Size: 1413 bytes --]

2.6.31-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Robert Varga <nite@hq.alert.sk>

[ Upstream commit 657e9649e745b06675aa5063c84430986cdc3afa ]

I have recently came across a preemption imbalance detected by:

<4>huh, entered ffffffff80644630 with preempt_count 00000102, exited with 00000101?
<0>------------[ cut here ]------------
<2>kernel BUG at /usr/src/linux/kernel/timer.c:664!
<0>invalid opcode: 0000 [1] PREEMPT SMP

with ffffffff80644630 being inet_twdr_hangman().

This appeared after I enabled CONFIG_TCP_MD5SIG and played with it a
bit, so I looked at what might have caused it.

One thing that struck me as strange is tcp_twsk_destructor(), as it
calls tcp_put_md5sig_pool() -- which entails a put_cpu(), causing the
detected imbalance. Found on 2.6.23.9, but 2.6.31 is affected as well,
as far as I can tell.

Signed-off-by: Robert Varga <nite@hq.alert.sk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 net/ipv4/tcp_minisocks.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/net/ipv4/tcp_minisocks.c
+++ b/net/ipv4/tcp_minisocks.c
@@ -363,7 +363,7 @@ void tcp_twsk_destructor(struct sock *sk
 #ifdef CONFIG_TCP_MD5SIG
 	struct tcp_timewait_sock *twsk = tcp_twsk(sk);
 	if (twsk->tw_md5_keylen)
-		tcp_put_md5sig_pool();
+		tcp_free_md5sig_pool();
 #endif
 }
 

[patch 31/37] net: Fix sock_wfree() race

[Greg KH]

[-- Attachment #1: net-fix-sock_wfree-race.patch --]
[-- Type: text/plain, Size: 1756 bytes --]

2.6.31-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Eric Dumazet <eric.dumazet@gmail.com>

[ Upstream commit d99927f4d93f36553699573b279e0ff98ad7dea6 ]

Commit 2b85a34e911bf483c27cfdd124aeb1605145dc80
(net: No more expensive sock_hold()/sock_put() on each tx)
opens a window in sock_wfree() where another cpu
might free the socket we are working on.

A fix is to call sk->sk_write_space(sk) while still
holding a reference on sk.

Reported-by: Jike Song <albcamus@gmail.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 net/core/sock.c |   19 ++++++++++++-------
 1 file changed, 12 insertions(+), 7 deletions(-)

--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -1218,17 +1218,22 @@ void __init sk_init(void)
 void sock_wfree(struct sk_buff *skb)
 {
 	struct sock *sk = skb->sk;
-	int res;
+	unsigned int len = skb->truesize;
 
-	/* In case it might be waiting for more memory. */
-	res = atomic_sub_return(skb->truesize, &sk->sk_wmem_alloc);
-	if (!sock_flag(sk, SOCK_USE_WRITE_QUEUE))
+	if (!sock_flag(sk, SOCK_USE_WRITE_QUEUE)) {
+		/*
+		 * Keep a reference on sk_wmem_alloc, this will be released
+		 * after sk_write_space() call
+		 */
+		atomic_sub(len - 1, &sk->sk_wmem_alloc);
 		sk->sk_write_space(sk);
+		len = 1;
+	}
 	/*
-	 * if sk_wmem_alloc reached 0, we are last user and should
-	 * free this sock, as sk_free() call could not do it.
+	 * if sk_wmem_alloc reaches 0, we must finish what sk_free()
+	 * could not do because of in-flight packets
 	 */
-	if (res == 0)
+	if (atomic_sub_and_test(len, &sk->sk_wmem_alloc))
 		__sk_free(sk);
 }
 EXPORT_SYMBOL(sock_wfree);

[patch 32/37] smsc95xx: fix transmission where ZLP is expected

[Greg KH]

[-- Attachment #1: smsc95xx-fix-transmission-where-zlp-is-expected.patch --]
[-- Type: text/plain, Size: 2248 bytes --]

2.6.31-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Steve Glendinning <steve.glendinning@smsc.com>

[ Upstream commit ec4756238239f1a331d9fb95bad8b281dad56855 ]

Usbnet framework assumes USB hardware doesn't handle zero length
packets, but SMSC LAN95xx requires these to be sent for correct
operation.

This patch fixes an easily reproducible tx lockup when sending a frame
that results in exactly 512 bytes in a USB transmission (e.g. a UDP
frame with 458 data bytes, due to IP headers and our USB headers).  It
adds an extra flag to usbnet for the hardware driver to indicate that
it can handle and requires the zero length packets.

This patch should not affect other usbnet users, please also consider
for -stable.

Signed-off-by: Steve Glendinning <steve.glendinning@smsc.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 drivers/net/usb/smsc95xx.c |    2 +-
 drivers/net/usb/usbnet.c   |    2 +-
 include/linux/usb/usbnet.h |    1 +
 3 files changed, 3 insertions(+), 2 deletions(-)

--- a/drivers/net/usb/smsc95xx.c
+++ b/drivers/net/usb/smsc95xx.c
@@ -1232,7 +1232,7 @@ static const struct driver_info smsc95xx
 	.rx_fixup	= smsc95xx_rx_fixup,
 	.tx_fixup	= smsc95xx_tx_fixup,
 	.status		= smsc95xx_status,
-	.flags		= FLAG_ETHER,
+	.flags		= FLAG_ETHER | FLAG_SEND_ZLP,
 };
 
 static const struct usb_device_id products[] = {
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -988,7 +988,7 @@ int usbnet_start_xmit (struct sk_buff *s
 	 * NOTE:  strictly conforming cdc-ether devices should expect
 	 * the ZLP here, but ignore the one-byte packet.
 	 */
-	if ((length % dev->maxpacket) == 0) {
+	if (!(info->flags & FLAG_SEND_ZLP) && (length % dev->maxpacket) == 0) {
 		urb->transfer_buffer_length++;
 		if (skb_tailroom(skb)) {
 			skb->data[skb->len] = 0;
--- a/include/linux/usb/usbnet.h
+++ b/include/linux/usb/usbnet.h
@@ -86,6 +86,7 @@ struct driver_info {
 
 #define FLAG_FRAMING_AX 0x0040		/* AX88772/178 packets */
 #define FLAG_WLAN	0x0080		/* use "wlan%d" names */
+#define FLAG_SEND_ZLP	0x0200		/* hw requires ZLPs are sent */
 
 
 	/* init device ... can sleep, or cause probe() failure */

[patch 33/37] sky2: Set SKY2_HW_RAM_BUFFER in sky2_init

[Greg KH]

[-- Attachment #1: sky2-set-sky2_hw_ram_buffer-in-sky2_init.patch --]
[-- Type: text/plain, Size: 1184 bytes --]

2.6.31-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Mike McCormack <mikem@ring3k.org>

[ Upstream commit 74a61ebf653c6abe459f228eb40e9f24f7ef1fb7 ]

The SKY2_HW_RAM_BUFFER bit in hw->flags was checked in sky2_mac_init(),
 before being set later in sky2_up().

Setting SKY2_HW_RAM_BUFFER in sky2_init() where other hw->flags are set
 should avoid this problem recurring.

Signed-off-by: Mike McCormack <mikem@ring3k.org>
Acked-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 drivers/net/sky2.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

--- a/drivers/net/sky2.c
+++ b/drivers/net/sky2.c
@@ -1455,7 +1455,6 @@ static int sky2_up(struct net_device *de
 	if (ramsize > 0) {
 		u32 rxspace;
 
-		hw->flags |= SKY2_HW_RAM_BUFFER;
 		pr_debug(PFX "%s: ram buffer %dK\n", dev->name, ramsize);
 		if (ramsize < 16)
 			rxspace = ramsize / 2;
@@ -2942,6 +2941,9 @@ static int __devinit sky2_init(struct sk
 			++hw->ports;
 	}
 
+	if (sky2_read8(hw, B2_E_0))
+		hw->flags |= SKY2_HW_RAM_BUFFER;
+
 	return 0;
 }
 

[patch 34/37] appletalk: Fix skb leak when ipddp interface is not loaded

[Greg KH]

[-- Attachment #1: appletalk-fix-skb-leak-when-ipddp-interface-is-not-loaded.patch --]
[-- Type: text/plain, Size: 6105 bytes --]

2.6.31-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Arnaldo Carvalho de Melo <acme@redhat.com>

[ Upstream commit ffcfb8db540ff879c2a85bf7e404954281443414 ]

And also do a better job of returning proper NET_{RX,XMIT}_ values.

Based on a patch by Mark Smith.

This fixes CVE-2009-2903

Reported-by: Mark Smith <lk-netdev@lk-netdev.nosense.org>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 drivers/net/appletalk/ipddp.c |    3 --
 net/appletalk/aarp.c          |   16 +++++++----
 net/appletalk/ddp.c           |   58 ++++++++++++++++++++++--------------------
 3 files changed, 43 insertions(+), 34 deletions(-)

--- a/drivers/net/appletalk/ipddp.c
+++ b/drivers/net/appletalk/ipddp.c
@@ -176,8 +176,7 @@ static int ipddp_xmit(struct sk_buff *sk
 	dev->stats.tx_packets++;
 	dev->stats.tx_bytes += skb->len;
 
-        if(aarp_send_ddp(rt->dev, skb, &rt->at, NULL) < 0)
-                dev_kfree_skb(skb);
+	aarp_send_ddp(rt->dev, skb, &rt->at, NULL);
 
 	spin_unlock(&ipddp_route_lock);
 
--- a/net/appletalk/aarp.c
+++ b/net/appletalk/aarp.c
@@ -599,7 +599,7 @@ int aarp_send_ddp(struct net_device *dev
 
 	/* Non ELAP we cannot do. */
 	if (dev->type != ARPHRD_ETHER)
-		return -1;
+		goto free_it;
 
 	skb->dev = dev;
 	skb->protocol = htons(ETH_P_ATALK);
@@ -634,7 +634,7 @@ int aarp_send_ddp(struct net_device *dev
 	if (!a) {
 		/* Whoops slipped... good job it's an unreliable protocol 8) */
 		write_unlock_bh(&aarp_lock);
-		return -1;
+		goto free_it;
 	}
 
 	/* Set up the queue */
@@ -663,15 +663,21 @@ out_unlock:
 	write_unlock_bh(&aarp_lock);
 
 	/* Tell the ddp layer we have taken over for this frame. */
-	return 0;
+	goto sent;
 
 sendit:
 	if (skb->sk)
 		skb->priority = skb->sk->sk_priority;
-	dev_queue_xmit(skb);
+	if (dev_queue_xmit(skb))
+		goto drop;
 sent:
-	return 1;
+	return NET_XMIT_SUCCESS;
+free_it:
+	kfree_skb(skb);
+drop:
+	return NET_XMIT_DROP;
 }
+EXPORT_SYMBOL(aarp_send_ddp);
 
 /*
  *	An entry in the aarp unresolved queue has become resolved. Send
--- a/net/appletalk/ddp.c
+++ b/net/appletalk/ddp.c
@@ -1270,8 +1270,10 @@ static int handle_ip_over_ddp(struct sk_
 	struct net_device_stats *stats;
 
 	/* This needs to be able to handle ipddp"N" devices */
-	if (!dev)
-		return -ENODEV;
+	if (!dev) {
+		kfree_skb(skb);
+		return NET_RX_DROP;
+	}
 
 	skb->protocol = htons(ETH_P_IP);
 	skb_pull(skb, 13);
@@ -1281,8 +1283,7 @@ static int handle_ip_over_ddp(struct sk_
 	stats = netdev_priv(dev);
 	stats->rx_packets++;
 	stats->rx_bytes += skb->len + 13;
-	netif_rx(skb);  /* Send the SKB up to a higher place. */
-	return 0;
+	return netif_rx(skb);  /* Send the SKB up to a higher place. */
 }
 #else
 /* make it easy for gcc to optimize this test out, i.e. kill the code */
@@ -1290,9 +1291,8 @@ static int handle_ip_over_ddp(struct sk_
 #define handle_ip_over_ddp(skb) 0
 #endif
 
-static void atalk_route_packet(struct sk_buff *skb, struct net_device *dev,
-			       struct ddpehdr *ddp, __u16 len_hops,
-			       int origlen)
+static int atalk_route_packet(struct sk_buff *skb, struct net_device *dev,
+			      struct ddpehdr *ddp, __u16 len_hops, int origlen)
 {
 	struct atalk_route *rt;
 	struct atalk_addr ta;
@@ -1359,8 +1359,6 @@ static void atalk_route_packet(struct sk
 		/* 22 bytes - 12 ether, 2 len, 3 802.2 5 snap */
 		struct sk_buff *nskb = skb_realloc_headroom(skb, 32);
 		kfree_skb(skb);
-		if (!nskb)
-			goto out;
 		skb = nskb;
 	} else
 		skb = skb_unshare(skb, GFP_ATOMIC);
@@ -1369,12 +1367,18 @@ static void atalk_route_packet(struct sk
 	 * If the buffer didn't vanish into the lack of space bitbucket we can
 	 * send it.
 	 */
-	if (skb && aarp_send_ddp(rt->dev, skb, &ta, NULL) == -1)
-		goto free_it;
-out:
-	return;
+	if (skb == NULL)
+		goto drop;
+
+	/*
+	 * It is OK, NET_XMIT_SUCCESS == NET_RX_SUCCESS and
+	 * NET_XMIT_DROP == NET_RX_DROP
+	 */
+	return aarp_send_ddp(rt->dev, skb, &ta, NULL);
 free_it:
 	kfree_skb(skb);
+drop:
+	return NET_RX_DROP;
 }
 
 /**
@@ -1404,7 +1408,7 @@ static int atalk_rcv(struct sk_buff *skb
 
 	/* Don't mangle buffer if shared */
 	if (!(skb = skb_share_check(skb, GFP_ATOMIC)))
-		goto out;
+		goto drop;
 
 	/* Size check and make sure header is contiguous */
 	if (!pskb_may_pull(skb, sizeof(*ddp)))
@@ -1448,8 +1452,7 @@ static int atalk_rcv(struct sk_buff *skb
 		/* Not ours, so we route the packet via the correct
 		 * AppleTalk iface
 		 */
-		atalk_route_packet(skb, dev, ddp, len_hops, origlen);
-		goto out;
+		return atalk_route_packet(skb, dev, ddp, len_hops, origlen);
 	}
 
 	/* if IP over DDP is not selected this code will be optimized out */
@@ -1472,11 +1475,12 @@ static int atalk_rcv(struct sk_buff *skb
 
 	if (sock_queue_rcv_skb(sock, skb) < 0)
 		goto freeit;
-out:
-	return 0;
+
+	return NET_RX_SUCCESS;
 freeit:
 	kfree_skb(skb);
-	goto out;
+drop:
+	return NET_RX_DROP;
 }
 
 /*
@@ -1652,10 +1656,10 @@ static int atalk_sendmsg(struct kiocb *i
 		if (skb2) {
 			loopback = 1;
 			SOCK_DEBUG(sk, "SK %p: send out(copy).\n", sk);
-			if (aarp_send_ddp(dev, skb2,
-					  &usat->sat_addr, NULL) == -1)
-				kfree_skb(skb2);
-				/* else queued/sent above in the aarp queue */
+			/*
+			 * If it fails it is queued/sent above in the aarp queue
+			 */
+			aarp_send_ddp(dev, skb2, &usat->sat_addr, NULL);
 		}
 	}
 
@@ -1685,9 +1689,10 @@ static int atalk_sendmsg(struct kiocb *i
 		    usat = &gsat;
 		}
 
-		if (aarp_send_ddp(dev, skb, &usat->sat_addr, NULL) == -1)
-			kfree_skb(skb);
-		/* else queued/sent above in the aarp queue */
+		/*
+		 * If it fails it is queued/sent above in the aarp queue
+		 */
+		aarp_send_ddp(dev, skb, &usat->sat_addr, NULL);
 	}
 	SOCK_DEBUG(sk, "SK %p: Done write (%Zd).\n", sk, len);
 
@@ -1865,7 +1870,6 @@ static struct packet_type ppptalk_packet
 static unsigned char ddp_snap_id[] = { 0x08, 0x00, 0x07, 0x80, 0x9B };
 
 /* Export symbols for use by drivers when AppleTalk is a module */
-EXPORT_SYMBOL(aarp_send_ddp);
 EXPORT_SYMBOL(atrtr_get_dev);
 EXPORT_SYMBOL(atalk_find_dev_addr);
 

[patch 35/37] ax25: Fix possible oops in ax25_make_new

[Greg KH]

[-- Attachment #1: ax25-fix-possible-oops-in-ax25_make_new.patch --]
[-- Type: text/plain, Size: 1166 bytes --]

2.6.31-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Jarek Poplawski <jarkao2@gmail.com>

[ Upstream commit 8c185ab6185bf5e67766edb000ce428269364c86 ]

In ax25_make_new, if kmemdup of digipeat returns an error, there would
be an oops in sk_free while calling sk_destruct, because sk_protinfo
is NULL at the moment; move sk->sk_destruct initialization after this.

BTW of reported-by: Bernard Pidoux F6BVP <f6bvp@free.fr>

Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 net/ax25/af_ax25.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/net/ax25/af_ax25.c
+++ b/net/ax25/af_ax25.c
@@ -893,7 +893,6 @@ struct sock *ax25_make_new(struct sock *
 
 	sock_init_data(NULL, sk);
 
-	sk->sk_destruct = ax25_free_sock;
 	sk->sk_type     = osk->sk_type;
 	sk->sk_priority = osk->sk_priority;
 	sk->sk_protocol = osk->sk_protocol;
@@ -931,6 +930,7 @@ struct sock *ax25_make_new(struct sock *
 	}
 
 	sk->sk_protinfo = ax25;
+	sk->sk_destruct = ax25_free_sock;
 	ax25->sk    = sk;
 
 	return sk;

[patch 36/37] ax25: Fix SIOCAX25GETINFO ioctl

[Greg KH]

[-- Attachment #1: ax25-fix-siocax25getinfo-ioctl.patch --]
[-- Type: text/plain, Size: 1223 bytes --]

2.6.31-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Eric Dumazet <eric.dumazet@gmail.com>

[ Upstream commit 407fc5cf019fc5cb990458a2e38d2c0a27b3cb30 ]

rcv_q & snd_q initializations were reversed in commit
31e6d363abcd0d05766c82f1a9c905a4c974a199
(net: correct off-by-one write allocations reports)

Signed-off-by: Jan Rafaj <jr+netfilter-devel@cedric.unob.cz>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 net/ax25/af_ax25.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/net/ax25/af_ax25.c
+++ b/net/ax25/af_ax25.c
@@ -1781,8 +1781,8 @@ static int ax25_ioctl(struct socket *soc
 		ax25_info.idletimer = ax25_display_timer(&ax25->idletimer) / (60 * HZ);
 		ax25_info.n2count   = ax25->n2count;
 		ax25_info.state     = ax25->state;
-		ax25_info.rcv_q     = sk_wmem_alloc_get(sk);
-		ax25_info.snd_q     = sk_rmem_alloc_get(sk);
+		ax25_info.rcv_q     = sk_rmem_alloc_get(sk);
+		ax25_info.snd_q     = sk_wmem_alloc_get(sk);
 		ax25_info.vs        = ax25->vs;
 		ax25_info.vr        = ax25->vr;
 		ax25_info.va        = ax25->va;

[patch 37/37] sit: fix off-by-one in ipip6_tunnel_get_prl

[Greg KH]

[-- Attachment #1: sit-fix-off-by-one-in-ipip6_tunnel_get_prl.patch --]
[-- Type: text/plain, Size: 1070 bytes --]

2.6.31-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Sascha Hlusiak <contact@saschahlusiak.de>

[ Upstream commit 298bf12ddb25841804f26234a43b89da1b1c0e21 ]

When requesting all prl entries (kprl.addr == INADDR_ANY) and there are
more prl entries than there is space passed from userspace, the existing
code would always copy cmax+1 entries, which is more than can be handled.

This patch makes the kernel copy only exactly cmax entries.

Signed-off-by: Sascha Hlusiak <contact@saschahlusiak.de>
Acked-By: Fred L. Templin <Fred.L.Templin@boeing.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 net/ipv6/sit.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
@@ -313,7 +313,7 @@ static int ipip6_tunnel_get_prl(struct i
 
 	c = 0;
 	for (prl = t->prl; prl; prl = prl->next) {
-		if (c > cmax)
+		if (c >= cmax)
 			break;
 		if (kprl.addr != htonl(INADDR_ANY) && prl->addr != kprl.addr)
 			continue;

RE: [patch 37/37] sit: fix off-by-one in ipip6_tunnel_get_prl

[Templin, Fred L]

Wait a moment - I remember now that this code came
from Yoshifuji, and I believe there was a reason for
the cmax+1. The application is expected to know this
and to post a large enough buffer.

Can we put this on hold until I have had a chance to
check my e-mail archives and my local iproute changes
(will respond on monday)?

Thanks - Fred
fred.l.templin@boeing.com

> -----Original Message-----
> From: Greg KH [mailto:gregkh@suse.de]
> Sent: Friday, October 09, 2009 4:35 PM
> To: linux-kernel@vger.kernel.org; stable@kernel.org
> Cc: stable-review@kernel.org; torvalds@linux-foundation.org; akpm@linux-foundation.org;
> alan@lxorguk.ukuu.org.uk; Sascha Hlusiak; Templin, Fred L; David S. Miller
> Subject: [patch 37/37] sit: fix off-by-one in ipip6_tunnel_get_prl
> 
> 2.6.31-stable review patch.  If anyone has any objections, please let us know.
> 
> ------------------
> From: Sascha Hlusiak <contact@saschahlusiak.de>
> 
> [ Upstream commit 298bf12ddb25841804f26234a43b89da1b1c0e21 ]
> 
> When requesting all prl entries (kprl.addr == INADDR_ANY) and there are
> more prl entries than there is space passed from userspace, the existing
> code would always copy cmax+1 entries, which is more than can be handled.
> 
> This patch makes the kernel copy only exactly cmax entries.
> 
> Signed-off-by: Sascha Hlusiak <contact@saschahlusiak.de>
> Acked-By: Fred L. Templin <Fred.L.Templin@boeing.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> ---
>  net/ipv6/sit.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> --- a/net/ipv6/sit.c
> +++ b/net/ipv6/sit.c
> @@ -313,7 +313,7 @@ static int ipip6_tunnel_get_prl(struct i
> 
>  	c = 0;
>  	for (prl = t->prl; prl; prl = prl->next) {
> -		if (c > cmax)
> +		if (c >= cmax)
>  			break;
>  		if (kprl.addr != htonl(INADDR_ANY) && prl->addr != kprl.addr)
>  			continue;
> 

Re: [patch 37/37] sit: fix off-by-one in ipip6_tunnel_get_prl

[David Miller]

From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
Date: Fri, 9 Oct 2009 17:34:49 -0700

> Wait a moment - I remember now that this code came
> from Yoshifuji, and I believe there was a reason for
> the cmax+1. The application is expected to know this
> and to post a large enough buffer.
> 
> Can we put this on hold until I have had a chance to
> check my e-mail archives and my local iproute changes
> (will respond on monday)?

Sure, we can keep it out of -stable for now.

But it is in Linus's tree so if you find we shouldn't do this
you'll need to send me a revert for net-2.6

Otherwise if it's good, you'll have to remind me to resubmit
it to -stable.

Thanks!

Re: [patch 37/37] sit: fix off-by-one in ipip6_tunnel_get_prl

[Wolfgang Walter]

On Saturday 10 October 2009, David Miller wrote:
> From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
> Date: Fri, 9 Oct 2009 17:34:49 -0700
> 
> > Wait a moment - I remember now that this code came
> > from Yoshifuji, and I believe there was a reason for
> > the cmax+1. The application is expected to know this
> > and to post a large enough buffer.

But wouldn't this corrupt kernel memory?

It seems:

kp is never larger then

	sizeof(struct ip_tunnel_prl) * cmax

so kp[cmax] is of by one.

userspace can't allocate a large enough buffer as doesn't know the size of the 
prl.

If the comment is correct and non-root can call this function it could set
	a.addr = htonl(INADDR_ANY);
	a.datalen = sizeof(*kp);

=> cmax == 1
=> kp[1] would be written if prl has 2 or more entries.

So I think the patch is correct.

Probably it would even be better to check for

	c >= ca

as this even more obviously correct.

> > 
> > Can we put this on hold until I have had a chance to
> > check my e-mail archives and my local iproute changes
> > (will respond on monday)?
> 
> Sure, we can keep it out of -stable for now.
> 
> But it is in Linus's tree so if you find we shouldn't do this
> you'll need to send me a revert for net-2.6
> 
> Otherwise if it's good, you'll have to remind me to resubmit
> it to -stable.
> 

This function seems to be a bit strange:

1)

	if (!kp) {
		/* We don't try hard to allocate much memory for
		 * non-root users.
		 * For root users, retry allocating enough memory for
		 * the answer.
		 */
		kp = kcalloc(ca, sizeof(*kp), GFP_ATOMIC);
		if (!kp) {
			ret = -ENOMEM;
			goto out;

why ist ret set to -ENOMEM
it will be set to 0  here:

	out:
		read_unlock(&ipip6_lock);

		len = sizeof(*kp) * c;
		ret = 0;


Because c == 0 len will be 0, so only
	put_user(len, &a->datalen)

will be executed
I'm not sure what this means for put_user(len, &a->datalen) but probably it 
will succed. Therefor the return value is 0 in this case.


I think the

	ret = 0

should be removed as ret is initialized to 0 so it will be zero if not 
modifiied.

And either

	if (! ret) {
		len = sizeof(*kp) * c;
		if ((len && copy_to_user(a + 1, kp, len)) || put_user(len, &a->datalen))
			ret = -EFAULT;
	}

or

	len = sizeof(*kp) * c;
	if (len && (opy_to_user(a + 1, kp, len) || put_user(len, &a->datalen))
		ret = -EFAULT;




2) Then

	c = 0;
	for (prl = t->prl; prl; prl = prl->next) {


c is already 0 here, so this seems to be unecessary


3)  If the caller should know that the list is to large for the buffer he 
supplied by returning -EFAULT then cmax should be increased by one:

	cmax = kprl.datalen / sizeof(kprl) + 1;


But probably user space should initialise its buffer with 0 and assume that the 
list was to large if the last entry's addr  != 0.


Regards,
-- 
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts

RE: [patch 37/37] sit: fix off-by-one in ipip6_tunnel_get_prl

[Templin, Fred L]

Wolfgang,

Thanks for your comments. As I wrote to David and Greg,
I tested the patch and it is indeed good. I'd really
rather not get into changing other code that has
already been tested at this time, however.

Regards - Fred
fred.l.templin@boeing.com

> -----Original Message-----
> From: Wolfgang Walter [mailto:wolfgang.walter@stwm.de]
> Sent: Saturday, October 10, 2009 6:30 PM
> To: David Miller
> Cc: Templin, Fred L; gregkh@suse.de; linux-kernel@vger.kernel.org; stable@kernel.org; stable-
> review@kernel.org; torvalds@linux-foundation.org; akpm@linux-foundation.org;
> alan@lxorguk.ukuu.org.uk; contact@saschahlusiak.de; yoshfuji@linux-ipv6.org
> Subject: Re: [patch 37/37] sit: fix off-by-one in ipip6_tunnel_get_prl
> 
> On Saturday 10 October 2009, David Miller wrote:
> > From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
> > Date: Fri, 9 Oct 2009 17:34:49 -0700
> >
> > > Wait a moment - I remember now that this code came
> > > from Yoshifuji, and I believe there was a reason for
> > > the cmax+1. The application is expected to know this
> > > and to post a large enough buffer.
> 
> But wouldn't this corrupt kernel memory?
> 
> It seems:
> 
> kp is never larger then
> 
> 	sizeof(struct ip_tunnel_prl) * cmax
> 
> so kp[cmax] is of by one.
> 
> userspace can't allocate a large enough buffer as doesn't know the size of the
> prl.
> 
> If the comment is correct and non-root can call this function it could set
> 	a.addr = htonl(INADDR_ANY);
> 	a.datalen = sizeof(*kp);
> 
> => cmax == 1
> => kp[1] would be written if prl has 2 or more entries.
> 
> So I think the patch is correct.
> 
> Probably it would even be better to check for
> 
> 	c >= ca
> 
> as this even more obviously correct.
> 
> > >
> > > Can we put this on hold until I have had a chance to
> > > check my e-mail archives and my local iproute changes
> > > (will respond on monday)?
> >
> > Sure, we can keep it out of -stable for now.
> >
> > But it is in Linus's tree so if you find we shouldn't do this
> > you'll need to send me a revert for net-2.6
> >
> > Otherwise if it's good, you'll have to remind me to resubmit
> > it to -stable.
> >
> 
> This function seems to be a bit strange:
> 
> 1)
> 
> 	if (!kp) {
> 		/* We don't try hard to allocate much memory for
> 		 * non-root users.
> 		 * For root users, retry allocating enough memory for
> 		 * the answer.
> 		 */
> 		kp = kcalloc(ca, sizeof(*kp), GFP_ATOMIC);
> 		if (!kp) {
> 			ret = -ENOMEM;
> 			goto out;
> 
> why ist ret set to -ENOMEM
> it will be set to 0  here:
> 
> 	out:
> 		read_unlock(&ipip6_lock);
> 
> 		len = sizeof(*kp) * c;
> 		ret = 0;
> 
> 
> Because c == 0 len will be 0, so only
> 	put_user(len, &a->datalen)
> 
> will be executed
> I'm not sure what this means for put_user(len, &a->datalen) but probably it
> will succed. Therefor the return value is 0 in this case.
> 
> 
> I think the
> 
> 	ret = 0
> 
> should be removed as ret is initialized to 0 so it will be zero if not
> modifiied.
> 
> And either
> 
> 	if (! ret) {
> 		len = sizeof(*kp) * c;
> 		if ((len && copy_to_user(a + 1, kp, len)) || put_user(len, &a->datalen))
> 			ret = -EFAULT;
> 	}
> 
> or
> 
> 	len = sizeof(*kp) * c;
> 	if (len && (opy_to_user(a + 1, kp, len) || put_user(len, &a->datalen))
> 		ret = -EFAULT;
> 
> 
> 
> 
> 2) Then
> 
> 	c = 0;
> 	for (prl = t->prl; prl; prl = prl->next) {
> 
> 
> c is already 0 here, so this seems to be unecessary
> 
> 
> 3)  If the caller should know that the list is to large for the buffer he
> supplied by returning -EFAULT then cmax should be increased by one:
> 
> 	cmax = kprl.datalen / sizeof(kprl) + 1;
> 
> 
> But probably user space should initialise its buffer with 0 and assume that the
> list was to large if the last entry's addr  != 0.
> 
> 
> Regards,
> --
> Wolfgang Walter
> Studentenwerk München
> Anstalt des öffentlichen Rechts

Re: [stable] [patch 37/37] sit: fix off-by-one in ipip6_tunnel_get_prl

[Greg KH]

On Fri, Oct 09, 2009 at 08:42:31PM -0700, David Miller wrote:
> From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
> Date: Fri, 9 Oct 2009 17:34:49 -0700
> 
> > Wait a moment - I remember now that this code came
> > from Yoshifuji, and I believe there was a reason for
> > the cmax+1. The application is expected to know this
> > and to post a large enough buffer.
> > 
> > Can we put this on hold until I have had a chance to
> > check my e-mail archives and my local iproute changes
> > (will respond on monday)?
> 
> Sure, we can keep it out of -stable for now.
> 
> But it is in Linus's tree so if you find we shouldn't do this
> you'll need to send me a revert for net-2.6
> 
> Otherwise if it's good, you'll have to remind me to resubmit
> it to -stable.

Ah crap, I just commited it.

Is it really broken?  If so, I'll go revert it and cut a new release.

Sorry about this.

greg k-h

RE: [stable] [patch 37/37] sit: fix off-by-one inipip6_tunnel_get_prl

[Templin, Fred L]

Greg,

> -----Original Message-----
> From: Greg KH [mailto:greg@kroah.com]
> Sent: Monday, October 12, 2009 3:05 PM
> To: David Miller
> Cc: Templin, Fred L; contact@saschahlusiak.de; yoshfuji@linux-ipv6.org; gregkh@suse.de; linux-
> kernel@vger.kernel.org; stable@kernel.org; akpm@linux-foundation.org; torvalds@linux-foundation.org;
> stable-review@kernel.org; alan@lxorguk.ukuu.org.uk
> Subject: Re: [stable] [patch 37/37] sit: fix off-by-one inipip6_tunnel_get_prl
> 
> On Fri, Oct 09, 2009 at 08:42:31PM -0700, David Miller wrote:
> > From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
> > Date: Fri, 9 Oct 2009 17:34:49 -0700
> >
> > > Wait a moment - I remember now that this code came
> > > from Yoshifuji, and I believe there was a reason for
> > > the cmax+1. The application is expected to know this
> > > and to post a large enough buffer.
> > >
> > > Can we put this on hold until I have had a chance to
> > > check my e-mail archives and my local iproute changes
> > > (will respond on monday)?
> >
> > Sure, we can keep it out of -stable for now.
> >
> > But it is in Linus's tree so if you find we shouldn't do this
> > you'll need to send me a revert for net-2.6
> >
> > Otherwise if it's good, you'll have to remind me to resubmit
> > it to -stable.
> 
> Ah crap, I just commited it.
> 
> Is it really broken?  If so, I'll go revert it and cut a new release.
> 
> Sorry about this.

As I just mentioned to David, I tested and the patch is
good. To test, I allocated a buffer in the application
that was too small to hold the entire PRL. Without the
patch, the system crashes. With the patch, the kernel
returns the maximum number of PRL entries without
crashing and without overrunning the application's buffer.

Please apply the patch if you have not already done so.

Fred
fred.l.templin@boeing.com

> greg k-h

Re: [stable] [patch 37/37] sit: fix off-by-one inipip6_tunnel_get_prl

[Greg KH]

On Mon, Oct 12, 2009 at 04:29:53PM -0700, Templin, Fred L wrote:
> Greg,
> 
> > -----Original Message-----
> > From: Greg KH [mailto:greg@kroah.com]
> > Sent: Monday, October 12, 2009 3:05 PM
> > To: David Miller
> > Cc: Templin, Fred L; contact@saschahlusiak.de; yoshfuji@linux-ipv6.org; gregkh@suse.de; linux-
> > kernel@vger.kernel.org; stable@kernel.org; akpm@linux-foundation.org; torvalds@linux-foundation.org;
> > stable-review@kernel.org; alan@lxorguk.ukuu.org.uk
> > Subject: Re: [stable] [patch 37/37] sit: fix off-by-one inipip6_tunnel_get_prl
> > 
> > On Fri, Oct 09, 2009 at 08:42:31PM -0700, David Miller wrote:
> > > From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
> > > Date: Fri, 9 Oct 2009 17:34:49 -0700
> > >
> > > > Wait a moment - I remember now that this code came
> > > > from Yoshifuji, and I believe there was a reason for
> > > > the cmax+1. The application is expected to know this
> > > > and to post a large enough buffer.
> > > >
> > > > Can we put this on hold until I have had a chance to
> > > > check my e-mail archives and my local iproute changes
> > > > (will respond on monday)?
> > >
> > > Sure, we can keep it out of -stable for now.
> > >
> > > But it is in Linus's tree so if you find we shouldn't do this
> > > you'll need to send me a revert for net-2.6
> > >
> > > Otherwise if it's good, you'll have to remind me to resubmit
> > > it to -stable.
> > 
> > Ah crap, I just commited it.
> > 
> > Is it really broken?  If so, I'll go revert it and cut a new release.
> > 
> > Sorry about this.
> 
> As I just mentioned to David, I tested and the patch is
> good. To test, I allocated a buffer in the application
> that was too small to hold the entire PRL. Without the
> patch, the system crashes. With the patch, the kernel
> returns the maximum number of PRL entries without
> crashing and without overrunning the application's buffer.
> 
> Please apply the patch if you have not already done so.

Which patch?  I need it to be in Linus's tree before we can apply it to
a stable release.

thanks,

greg k-h

Re: [stable] [patch 37/37] sit: fix off-by-one inipip6_tunnel_get_prl

[David Miller]

From: Greg KH <gregkh@suse.de>
Date: Mon, 12 Oct 2009 16:58:06 -0700

> Which patch?  I need it to be in Linus's tree before we can apply it to
> a stable release.

It's already upstream, and I already submitted it to -stable a few
days ago, remember?  This one below.

Greg, it's the one that you said "I already commited this one, is it
reall so broken?" about earlier today.

>From a9cb3db986f8bceaa741175cf016b0b7df59caf0 Mon Sep 17 00:00:00 2001
From: Sascha Hlusiak <contact@saschahlusiak.de>
Date: Tue, 29 Sep 2009 11:27:05 +0000
Subject: [PATCH 11/11] sit: fix off-by-one in ipip6_tunnel_get_prl

[ Upstream commit 298bf12ddb25841804f26234a43b89da1b1c0e21 ]

When requesting all prl entries (kprl.addr == INADDR_ANY) and there are
more prl entries than there is space passed from userspace, the existing
code would always copy cmax+1 entries, which is more than can be handled.

This patch makes the kernel copy only exactly cmax entries.

Signed-off-by: Sascha Hlusiak <contact@saschahlusiak.de>
Acked-By: Fred L. Templin <Fred.L.Templin@boeing.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/ipv6/sit.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
index 98b7327..2e41849 100644
--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
@@ -313,7 +313,7 @@ static int ipip6_tunnel_get_prl(struct ip_tunnel *t,
 
 	c = 0;
 	for (prl = t->prl; prl; prl = prl->next) {
-		if (c > cmax)
+		if (c >= cmax)
 			break;
 		if (kprl.addr != htonl(INADDR_ANY) && prl->addr != kprl.addr)
 			continue;
-- 
1.6.4.4

RE: [patch 37/37] sit: fix off-by-one in ipip6_tunnel_get_prl

[Templin, Fred L]

David,

> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Friday, October 09, 2009 8:43 PM
> To: Templin, Fred L
> Cc: gregkh@suse.de; linux-kernel@vger.kernel.org; stable@kernel.org; stable-review@kernel.org;
> torvalds@linux-foundation.org; akpm@linux-foundation.org; alan@lxorguk.ukuu.org.uk;
> contact@saschahlusiak.de; yoshfuji@linux-ipv6.org
> Subject: Re: [patch 37/37] sit: fix off-by-one in ipip6_tunnel_get_prl
> 
> From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
> Date: Fri, 9 Oct 2009 17:34:49 -0700
> 
> > Wait a moment - I remember now that this code came
> > from Yoshifuji, and I believe there was a reason for
> > the cmax+1. The application is expected to know this
> > and to post a large enough buffer.
> >
> > Can we put this on hold until I have had a chance to
> > check my e-mail archives and my local iproute changes
> > (will respond on monday)?
> 
> Sure, we can keep it out of -stable for now.
> 
> But it is in Linus's tree so if you find we shouldn't do this
> you'll need to send me a revert for net-2.6
> 
> Otherwise if it's good, you'll have to remind me to resubmit
> it to -stable.

I just got done testing with the patch applied to my kernel,
and the patch is good. Please submit to -stable if you have
not already done so.

Update - this may be overcome by the message I just rec'd
from Greg KH. I will go look at his message now.

Thanks - Fred
fred.l.templin@boeing.com

> Thanks!

Re: [Stable-review] [patch 00/26] 2.6.31.4-stable review

[Willy Tarreau]

On Fri, Oct 09, 2009 at 04:38:12PM -0700, Greg KH wrote:
> On Fri, Oct 09, 2009 at 04:12:49PM -0700, Greg KH wrote:
> > This is the start of the stable review cycle for the 2.6.31.4 release.
> > There are 26 patches in this series, all will be posted as a response to
> > this one.  If anyone has any issues with these being applied, please let
> > us know.  If anyone is a maintainer of the proper subsystem, and wants
> > to add a Signed-off-by: line to the patch, please respond with it.
> 
> Oops, a bunch of network patches came in right when this went out, and I
> don't want to have to wait to get them on, so I've rolled a -rc2 version
> now.

Nice! Will you queue them for 2.6.27.38 too ?

Willy

Re: [stable] [Stable-review] [patch 00/26] 2.6.31.4-stable review

[Greg KH]

On Sat, Oct 10, 2009 at 09:17:53AM +0200, Willy Tarreau wrote:
> On Fri, Oct 09, 2009 at 04:38:12PM -0700, Greg KH wrote:
> > On Fri, Oct 09, 2009 at 04:12:49PM -0700, Greg KH wrote:
> > > This is the start of the stable review cycle for the 2.6.31.4 release.
> > > There are 26 patches in this series, all will be posted as a response to
> > > this one.  If anyone has any issues with these being applied, please let
> > > us know.  If anyone is a maintainer of the proper subsystem, and wants
> > > to add a Signed-off-by: line to the patch, please respond with it.
> > 
> > Oops, a bunch of network patches came in right when this went out, and I
> > don't want to have to wait to get them on, so I've rolled a -rc2 version
> > now.
> 
> Nice! Will you queue them for 2.6.27.38 too ?

Nope, they were not sent for the .27 tree, only for .31.  If David sends
me network patches for .27, or people ask me to take specific ones for
the .27 tree, I'll be glad to queue them up for the next .27 release
after this one.

thanks,

greg k-h

Re: [stable] [Stable-review] [patch 00/26] 2.6.31.4-stable review

[Willy Tarreau]

On Sat, Oct 10, 2009 at 12:22:43AM -0700, Greg KH wrote:
> On Sat, Oct 10, 2009 at 09:17:53AM +0200, Willy Tarreau wrote:
> > On Fri, Oct 09, 2009 at 04:38:12PM -0700, Greg KH wrote:
> > > On Fri, Oct 09, 2009 at 04:12:49PM -0700, Greg KH wrote:
> > > > This is the start of the stable review cycle for the 2.6.31.4 release.
> > > > There are 26 patches in this series, all will be posted as a response to
> > > > this one.  If anyone has any issues with these being applied, please let
> > > > us know.  If anyone is a maintainer of the proper subsystem, and wants
> > > > to add a Signed-off-by: line to the patch, please respond with it.
> > > 
> > > Oops, a bunch of network patches came in right when this went out, and I
> > > don't want to have to wait to get them on, so I've rolled a -rc2 version
> > > now.
> > 
> > Nice! Will you queue them for 2.6.27.38 too ?
> 
> Nope, they were not sent for the .27 tree, only for .31.  If David sends
> me network patches for .27, or people ask me to take specific ones for
> the .27 tree, I'll be glad to queue them up for the next .27 release
> after this one.

OK thanks for this clarification.

Willy

Re: [patch 00/26] 2.6.31.4-stable review

[Thomas Voegtle]

On Fri, 9 Oct 2009, Greg KH wrote:

> On Fri, Oct 09, 2009 at 04:12:49PM -0700, Greg KH wrote:
>> This is the start of the stable review cycle for the 2.6.31.4 release.
>> There are 26 patches in this series, all will be posted as a response to
>> this one.  If anyone has any issues with these being applied, please let
>> us know.  If anyone is a maintainer of the proper subsystem, and wants
>> to add a Signed-off-by: line to the patch, please respond with it.
>
> Oops, a bunch of network patches came in right when this went out, and I
> don't want to have to wait to get them on, so I've rolled a -rc2 version
> now.
>
> There's now 37 patches in this series, I'll attach the rest to this
> thread now.
>
> The whole patch series can be found in one patch at:
> 	kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.31.4-rc2.gz
> and the diffstat can be found below.


This ends up for me in:

   CC      arch/x86/kernel/init_task.o
   LDS     arch/x86/kernel/vmlinux.lds
   CC [M]  arch/x86/kernel/msr.o
   CC [M]  arch/x86/kernel/cpuid.o
   CC [M]  arch/x86/kernel/microcode_core.o
   CC [M]  arch/x86/kernel/microcode_intel.o
   CC [M]  arch/x86/kernel/microcode_amd.o
   LD [M]  arch/x86/kernel/microcode.o
   LD      arch/x86/kvm/built-in.o
   CC [M]  arch/x86/kvm/svm.o
arch/x86/kvm/svm.c: In function 'svm_vcpu_load':
arch/x86/kvm/svm.c:713: error: 'struct vcpu_svm' has no member named 
'nested'
make[2]: *** [arch/x86/kvm/svm.o] Error 1
make[1]: *** [arch/x86/kvm] Error 2
make: *** [arch/x86] Error 2


CONFIG_VIRTUALIZATION=y
CONFIG_KVM=m
CONFIG_KVM_INTEL=m
CONFIG_KVM_AMD=m

gcc version 4.2.4

using kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.31.4-rc2.gz

Re: [Stable-review] [patch 00/26] 2.6.31.4-stable review

[Chuck Ebbert]

On Mon, 12 Oct 2009 13:09:56 +0200 (CEST)
Thomas Voegtle <tv@lio96.de> wrote:

> arch/x86/kvm/svm.c: In function 'svm_vcpu_load':
> arch/x86/kvm/svm.c:713: error: 'struct vcpu_svm' has no member named 
> 'nested'

Replacement patch for:
kvm-svm-fix-tsc-offset-adjustment-when-running-nested.patch

Fixes:
arch/x86/kvm/svm.c: In function 'svm_vcpu_load':
arch/x86/kvm/svm.c:713: error: 'struct vcpu_svm' has no member named 'nested' 


>From 77b1ab1732feb5e3dcbaf31d2f7547c5229f5f3a Mon Sep 17 00:00:00 2001
From: Joerg Roedel <joerg.roedel@amd.com>
Date: Wed, 16 Sep 2009 15:24:17 +0200
Subject: KVM: SVM: Fix tsc offset adjustment when running nested

From: Joerg Roedel <joerg.roedel@amd.com>

commit 77b1ab1732feb5e3dcbaf31d2f7547c5229f5f3a upstream.
[ backport to 2.6.31 by Chuck Ebbert <cebbert@redhat.com> ]

When svm_vcpu_load is called while the vcpu is running in
guest mode the tsc adjustment made there is lost on the next
emulated #vmexit. This causes the tsc running backwards in
the guest. This patch fixes the issue by also adjusting the
tsc_offset in the emulated hsave area so that it will not
get lost.

Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 arch/x86/kvm/svm.c |    2 ++
 1 file changed, 2 insertions(+)

--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -709,6 +709,8 @@ static void svm_vcpu_load(struct kvm_vcp
 		rdtscll(tsc_this);
 		delta = vcpu->arch.host_tsc - tsc_this;
 		svm->vmcb->control.tsc_offset += delta;
+		if (is_nested(svm))
+			svm->hsave->control.tsc_offset += delta;
 		vcpu->cpu = cpu;
 		kvm_migrate_timers(vcpu);
 		svm->asid_generation = 0;