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(-)
2.6.31-stable review patch. If anyone has any objections, please let us know.
------------------
From: Samuel Thibault <[email protected]>
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 <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: "H. Peter Anvin" <[email protected]>
Acked-by: "David S. Miller" <[email protected]>
Cc: Andi Kleen <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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);
}
2.6.31-stable review patch. If anyone has any objections, please let us know.
------------------
From: Linus Torvalds <[email protected]>
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 <[email protected]>
Reported-by: Heinz Diehl <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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);
2.6.31-stable review patch. If anyone has any objections, please let us know.
------------------
From: Jan Beulich <[email protected]>
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 <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
--- 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
2.6.31-stable review patch. If anyone has any objections, please let us know.
------------------
From: Manoj Iyer <[email protected]>
commit 3db6c037c6954ed6d98ef199938e4004fea96908 upstream.
Patch was tested on Toshiba NB200 and is found to enable sound.
Signed-off-by: Manoj Iyer <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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),
2.6.31-stable review patch. If anyone has any objections, please let us know.
------------------
From: [email protected] <[email protected]>
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 <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Steven Rostedt <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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;
}
2.6.31-stable review patch. If anyone has any objections, please let us know.
------------------
From: Steven Rostedt <[email protected]>
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 <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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();
}
2.6.31-stable review patch. If anyone has any objections, please let us know.
------------------
From: Darren Hart <[email protected]>
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 <[email protected]>
Signed-off-by: Darren Hart <[email protected]>
Cc: Helge Bahmann <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Eric Dumazet <[email protected]>
Cc: Dinakar Guniguntala <[email protected]>
Cc: John Stultz <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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;
2.6.31-stable review patch. If anyone has any objections, please let us know.
------------------
From: Thomas Gleixner <[email protected]>
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 <[email protected]>
LKML-Reference: <new-submission>
Cc: Anirban Sinha <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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 */
2.6.31-stable review patch. If anyone has any objections, please let us know.
------------------
From: Peter Zijlstra <[email protected]>
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 <[email protected]>
Signed-off-by: Peter Zijlstra <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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);
2.6.31-stable review patch. If anyone has any objections, please let us know.
------------------
From: Thomas Gleixner <[email protected]>
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 <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Darren Hart <[email protected]>
LKML-Reference: <new-submission>
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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)) {
2.6.31-stable review patch. If anyone has any objections, please let us know.
------------------
From: Eero Nurkkala <[email protected]>
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 <[email protected]>
Signed-off-by: Eero Nurkkala <[email protected]>
Cc: Rik van Riel <[email protected]>
Cc: Venkatesh Pallipadi <[email protected]>
Cc: Steven Noonan <[email protected]>
LKML-Reference: <1254907901.30157.93.camel@eenurkka-desktop>
Signed-off-by: Thomas Gleixner <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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;
2.6.31-stable review patch. If anyone has any objections, please let us know.
------------------
From: Mimi Zohar <[email protected]>
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 <[email protected]>
Cc: Dustin Kirkland <[email protected]>
Cc: James Morris <[email protected]>
Cc: David Safford <[email protected]>
Signed-off-by: Mimi Zohar <[email protected]>
Signed-off-by: Tyler Hicks <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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;
}
2.6.31-stable review patch. If anyone has any objections, please let us know.
------------------
From: Tejun Heo <[email protected]>
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 <[email protected]>
Reported-by: Tim Blechmann <[email protected]>
Signed-off-by: Jeff Garzik <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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 */
2.6.31-stable review patch. If anyone has any objections, please let us know.
------------------
From: Clemens Ladisch <[email protected]>
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 <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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 */
2.6.31-stable review patch. If anyone has any objections, please let us know.
------------------
From: Mark Brown <[email protected]>
commit 5b7dde346881b12246669ae97b3a2793c27b32b6 upstream.
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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 */
2.6.31-stable review patch. If anyone has any objections, please let us know.
------------------
From: Avi Kivity <[email protected]>
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 <[email protected]>
Signed-off-by: Avi Kivity <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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)
2.6.31-stable review patch. If anyone has any objections, please let us know.
------------------
From: Marcelo Tosatti <[email protected]>
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 <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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));
2.6.31-stable review patch. If anyone has any objections, please let us know.
------------------
From: Aurelien Jarno <[email protected]>
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 <[email protected]>
Signed-off-by: Marcelo Tosatti <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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);
2.6.31-stable review patch. If anyone has any objections, please let us know.
------------------
From: Joerg Roedel <[email protected]>
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 <[email protected]>
Signed-off-by: Marcelo Tosatti <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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;
2.6.31-stable review patch. If anyone has any objections, please let us know.
------------------
From: Jean Delvare <[email protected]>
commit b607bd900051efc3308c4edc65dd98b34b230021 upstream.
Which is why I have always preferred sizeof(struct foo) over
sizeof(var).
Signed-off-by: Jean Delvare <[email protected]>
Acked-by: Randy Dunlap <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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);
}
2.6.31-stable review patch. If anyone has any objections, please let us know.
------------------
From: Daisuke Nishimura <[email protected]>
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 <[email protected]>
Cc: KAMEZAWA Hiroyuki <[email protected]>
Cc: Balbir Singh <[email protected]>
Cc: Hugh Dickins <[email protected]>
Cc: Johannes Weiner <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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);
2.6.31-stable review patch. If anyone has any objections, please let us know.
------------------
From: Bartlomiej Zolnierkiewicz <[email protected]>
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 <[email protected]>
Tested-by: David Fries <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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 <[email protected]>
* Copyright (C) 2002 Lionel Bouton <[email protected]>, Maintainer
* Copyright (C) 2003 Vojtech Pavlik <[email protected]>
- * 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, ®4bh);
+ 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)
2.6.31-stable review patch. If anyone has any objections, please let us know.
------------------
From: john stultz <[email protected]>
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 <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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);
2.6.31-stable review patch. If anyone has any objections, please let us know.
------------------
From: Mimi Zohar <[email protected]>
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 <[email protected]>
Signed-off-by: James Morris <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
--- 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;
/*
2.6.31-stable review patch. If anyone has any objections, please let us know.
------------------
From: Jean Delvare <[email protected]>
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 <[email protected]>
Cc: Thomas Renninger <[email protected]>
Cc: Alan Jenkins <[email protected]>
Signed-off-by: Len Brown <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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;
2.6.31-stable review patch. If anyone has any objections, please let us know.
------------------
From: Zhao Yakui <[email protected]>
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 <[email protected]>
Signed-off-by: Len Brown <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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);
2.6.31-stable review patch. If anyone has any objections, please let us know.
------------------
From: Eric Dumazet <[email protected]>
[ 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 <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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;
2.6.31-stable review patch. If anyone has any objections, please let us know.
------------------
From: Miklos Szeredi <[email protected]>
[ 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 <[email protected]>
Signed-off-by: Miklos Szeredi <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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);
2.6.31-stable review patch. If anyone has any objections, please let us know.
------------------
From: Kusanagi Kouichi <[email protected]>
[ 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 <[email protected]>
Reviewed-by: Paul Moore <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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;
2.6.31-stable review patch. If anyone has any objections, please let us know.
------------------
From: Robert Varga <[email protected]>
[ 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 <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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
}
2.6.31-stable review patch. If anyone has any objections, please let us know.
------------------
From: Eric Dumazet <[email protected]>
[ 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 <[email protected]>
Signed-off-by: Eric Dumazet <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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);
2.6.31-stable review patch. If anyone has any objections, please let us know.
------------------
From: Steve Glendinning <[email protected]>
[ 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 <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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 */
2.6.31-stable review patch. If anyone has any objections, please let us know.
------------------
From: Mike McCormack <[email protected]>
[ 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 <[email protected]>
Acked-by: Stephen Hemminger <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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;
}
2.6.31-stable review patch. If anyone has any objections, please let us know.
------------------
From: Arnaldo Carvalho de Melo <[email protected]>
[ 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 <[email protected]>
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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);
2.6.31-stable review patch. If anyone has any objections, please let us know.
------------------
From: Jarek Poplawski <[email protected]>
[ 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 <[email protected]>
Signed-off-by: Jarek Poplawski <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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;
2.6.31-stable review patch. If anyone has any objections, please let us know.
------------------
From: Eric Dumazet <[email protected]>
[ 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 <[email protected]>
Signed-off-by: Eric Dumazet <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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;
2.6.31-stable review patch. If anyone has any objections, please let us know.
------------------
From: Sascha Hlusiak <[email protected]>
[ 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 <[email protected]>
Acked-By: Fred L. Templin <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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;
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(-)
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
[email protected]
> -----Original Message-----
> From: Greg KH [mailto:[email protected]]
> Sent: Friday, October 09, 2009 4:35 PM
> To: [email protected]; [email protected]
> Cc: [email protected]; [email protected]; [email protected];
> [email protected]; 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 <[email protected]>
>
> [ 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 <[email protected]>
> Acked-By: Fred L. Templin <[email protected]>
> Signed-off-by: David S. Miller <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> 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;
>
From: "Templin, Fred L" <[email protected]>
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!
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
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
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
On Saturday 10 October 2009, David Miller wrote:
> From: "Templin, Fred L" <[email protected]>
> 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
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
On Mon, 12 Oct 2009 13:09:56 +0200 (CEST)
Thomas Voegtle <[email protected]> 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 <[email protected]>
Date: Wed, 16 Sep 2009 15:24:17 +0200
Subject: KVM: SVM: Fix tsc offset adjustment when running nested
From: Joerg Roedel <[email protected]>
commit 77b1ab1732feb5e3dcbaf31d2f7547c5229f5f3a upstream.
[ backport to 2.6.31 by Chuck Ebbert <[email protected]> ]
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 <[email protected]>
Signed-off-by: Marcelo Tosatti <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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;
On Fri, Oct 09, 2009 at 08:42:31PM -0700, David Miller wrote:
> From: "Templin, Fred L" <[email protected]>
> 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
David,
> -----Original Message-----
> From: David Miller [mailto:[email protected]]
> Sent: Friday, October 09, 2009 8:43 PM
> To: Templin, Fred L
> Cc: [email protected]; [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]
> Subject: Re: [patch 37/37] sit: fix off-by-one in ipip6_tunnel_get_prl
>
> From: "Templin, Fred L" <[email protected]>
> 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
[email protected]
> Thanks!
Greg,
> -----Original Message-----
> From: Greg KH [mailto:[email protected]]
> Sent: Monday, October 12, 2009 3:05 PM
> To: David Miller
> Cc: Templin, Fred L; [email protected]; [email protected]; [email protected]; linux-
> [email protected]; [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]
> 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" <[email protected]>
> > 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
[email protected]
> greg k-h
On Mon, Oct 12, 2009 at 04:29:53PM -0700, Templin, Fred L wrote:
> Greg,
>
> > -----Original Message-----
> > From: Greg KH [mailto:[email protected]]
> > Sent: Monday, October 12, 2009 3:05 PM
> > To: David Miller
> > Cc: Templin, Fred L; [email protected]; [email protected]; [email protected]; linux-
> > [email protected]; [email protected]; [email protected]; [email protected];
> > [email protected]; [email protected]
> > 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" <[email protected]>
> > > 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
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
[email protected]
> -----Original Message-----
> From: Wolfgang Walter [mailto:[email protected]]
> Sent: Saturday, October 10, 2009 6:30 PM
> To: David Miller
> Cc: Templin, Fred L; [email protected]; [email protected]; [email protected]; stable-
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected]
> 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" <[email protected]>
> > 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
From: Greg KH <[email protected]>
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 <[email protected]>
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 <[email protected]>
Acked-By: Fred L. Templin <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
---
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
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