4 -stable kernel review cycles starting
Subsystems (87)
PATCH 144/164 KVM: SVM: Fix wrong interrupt injection in enable_irq_windows
In reply to Greg KH2.6.33-stable review patch. If anyone has any objections, please let me know.
------------------
From: Joerg Roedel <[email protected]>
The nested_svm_intr() function does not execute the vmexit anymore. Therefore we may still be in the nested state after that function ran. This patch changes the nested_svm_intr() function to return wether the irq window could be enabled.
--- arch/x86/kvm/svm.c | 17 ++++++++--------- 1 file changed, 8 insertions(+), 9 deletions(-)
arch/x86/kvm/svm.c +8 -9
@@ -1377,16 +1377,17 @@ static int nested_svm_check_exception(streturn vmexit; } -static inline int nested_svm_intr (struct vcpu_svm *svm) +/* This function returns true if it is save to enable the irq window */ +static inline bool nested_svm_intr (struct vcpu_svm *svm) {if (!is_nested (svm)) -return 0 ; +return true;if (!(svm->vcpu.arch.hflags &HF_VINTR_MASK )) -return 0 ; +return true;if (!(svm->vcpu.arch.hflags &HF_HIF_MASK )) -return 0 ; +return false; svm->vmcb->control.exit_code =SVM_EXIT_INTR ;
@@ -1399,10 +1400,10 @@ static inline int nested_svm_intr(struct*/ svm->nested.exit_required = true;trace_kvm_nested_intr_vmexit (svm->vmcb->save.rip); -return 1 ; +return false; } -return 0 ; +return true; }static void *nested_svm_map (struct vcpu_svm *svm,u64 gpa,struct page **_page)
@@ -2567,13 +2568,11 @@ static void enable_irq_window(struct kvm {struct vcpu_svm *svm =to_svm (vcpu); -nested_svm_intr (svm); -/* In case GIF=0 we can't rely on the CPU to tell us when * GIF becomes 1, because that's a separate STGI/VMRUN intercept. * The next time we get that intercept, this function will be * called again though and we'll get the vintr intercept. */ -if (gif_set (svm)) { +if (gif_set (svm) &&nested_svm_intr (svm)) {svm_set_vintr (svm);svm_inject_irq (svm,0x0 ); }
PATCH 145/164 KVM: s390: Fix possible memory leak of in kvm_arch_vcpu_create()
In reply to Greg KH2.6.33-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wei Yongjun <[email protected]>
This patch fixed possible memory leak in kvm_arch_vcpu_create() under s390, which would happen when kvm_arch_vcpu_create() fails.
--- arch/s390/kvm/kvm-s390.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
arch/s390/kvm/kvm-s390.c +3 -1
@@ -339,11 +339,13 @@ struct kvm_vcpu *kvm_arch_vcpu_create(st rc =kvm_vcpu_init (vcpu, kvm, id);if (rc) - goto out_free_cpu; + goto out_free_sie_block;VM_EVENT (kvm,3 ,"create cpu %d at %p, sie block at %p" , id, vcpu, vcpu->arch.sie_block);return vcpu; +out_free_sie_block: +free_page ((unsigned long )(vcpu->arch.sie_block)); out_free_cpu:kfree (vcpu); out_nomem:
PATCH 146/164 KVM: PPC: Do not create debugfs if fail to create vcpu
In reply to Greg KH2.6.33-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wei Yongjun <[email protected]>
If fail to create the vcpu, we should not create the debugfs for it.
--- arch/powerpc/kvm/powerpc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
arch/powerpc/kvm/powerpc.c +2 -1
@@ -181,7 +181,8 @@ struct kvm_vcpu *kvm_arch_vcpu_create(st {struct kvm_vcpu *vcpu; vcpu =kvmppc_core_vcpu_create (kvm, id); -kvmppc_create_vcpu_debugfs (vcpu, id); +if (!IS_ERR (vcpu)) +kvmppc_create_vcpu_debugfs (vcpu, id);return vcpu; }
PATCH 147/164 KVM: x86: Add callback to let modules decide over some supported cpuid bits
In reply to Greg KH2.6.33-stable review patch. If anyone has any objections, please let me know.
------------------
From: Joerg Roedel <[email protected]>
This patch adds the get_supported_cpuid callback to kvm_x86_ops. It will be used in do_cpuid_ent to delegate the decission about some supported cpuid bits to the architecture modules.
(cherry picked from commit d4330ef2fb2236a1e3a176f0f68360f4c0a8661b)
--- arch/x86/include/asm/kvm_host.h | 2 ++ arch/x86/kvm/svm.c | 5 +++++ arch/x86/kvm/vmx.c | 5 +++++ arch/x86/kvm/x86.c | 3 +++ 4 files changed, 15 insertions(+)
arch/x86/include/asm/kvm_host.h +2 -0
@@ -533,6 +533,8 @@ struct kvm_x86_ops {u64 (*get_mt_mask)(struct kvm_vcpu *vcpu,gfn_t gfn,bool is_mmio);bool (*gb_page_enable)(void ); +void (*set_supported_cpuid)(u32 func,struct kvm_cpuid_entry2 *entry); +const struct trace_print_flags *exit_reasons_str; };
arch/x86/kvm/svm.c +5 -0
@@ -2885,6 +2885,10 @@ static u64 svm_get_mt_mask(struct kvm_vcreturn 0 ; } +static void svm_set_supported_cpuid (u32 func,struct kvm_cpuid_entry2 *entry) +{ +} +static const struct trace_print_flags svm_exit_reasons_str[] = { {SVM_EXIT_READ_CR0 ,"read_cr0" }, {SVM_EXIT_READ_CR3 ,"read_cr3" },
@@ -3009,6 +3013,7 @@ static struct kvm_x86_ops svm_x86_ops = .exit_reasons_str = svm_exit_reasons_str, .gb_page_enable = svm_gb_page_enable, + .set_supported_cpuid = svm_set_supported_cpuid, };static int __init svm_init (void )
arch/x86/kvm/vmx.c +5 -0
@@ -3993,6 +3993,10 @@ static bool vmx_gb_page_enable(void)return false; } +static void vmx_set_supported_cpuid (u32 func,struct kvm_cpuid_entry2 *entry) +{ +} +static struct kvm_x86_ops vmx_x86_ops = { .cpu_has_kvm_support = cpu_has_kvm_support, .disabled_by_bios = vmx_disabled_by_bios,
@@ -4057,6 +4061,7 @@ static struct kvm_x86_ops vmx_x86_ops = .exit_reasons_str = vmx_exit_reasons_str, .gb_page_enable = vmx_gb_page_enable, + .set_supported_cpuid = vmx_set_supported_cpuid, };static int __init vmx_init (void )
arch/x86/kvm/x86.c +3 -0
@@ -1688,6 +1688,9 @@ static void do_cpuid_ent(struct kvm_cpui entry->ecx &= kvm_supported_word6_x86_features;break ; } + + kvm_x86_ops->set_supported_cpuid (function, entry); +put_cpu (); }
PATCH 148/164 KVM: SVM: Report emulated SVM features to userspace
In reply to Greg KH2.6.33-stable review patch. If anyone has any objections, please let me know.
------------------
From: Joerg Roedel <[email protected]>
This patch implements the reporting of the emulated SVM features to userspace instead of the real hardware capabilities. Every real hardware capability needs emulation in nested svm so the old behavior was broken.
--- arch/x86/kvm/svm.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
arch/x86/kvm/svm.c +10 -0
@@ -2887,6 +2887,16 @@ static u64 svm_get_mt_mask(struct kvm_vcstatic void svm_set_supported_cpuid (u32 func,struct kvm_cpuid_entry2 *entry) { +switch (func) { +case 0x8000000A : + entry->eax =1 ;/* SVM revision 1 */ + entry->ebx =8 ;/* Lets support 8 ASIDs in case we add proper +ASID emulation to nested SVM */ + entry->ecx =0 ;/* Reserved */ + entry->edx =0 ;/* Do not support any additional features */ + +break ; + } }static const struct trace_print_flags svm_exit_reasons_str[] = {
PATCH 149/164 x86, paravirt: Add a global synchronization point for pvclock
In reply to Greg KH2.6.33-stable review patch. If anyone has any objections, please let me know.
------------------
From: Glauber Costa <[email protected]>
In recent stress tests, it was found that pvclock-based systems could seriously warp in smp systems. Using ingo's time-warp-test.c, I could trigger a scenario as bad as 1.5mi warps a minute in some systems. (to be fair, it wasn't that bad in most of them). Investigating further, I found out that such warps were caused by the very offset-based calculation pvclock is based on.
This happens even on some machines that report constant_tsc in its tsc flags, specially on multi-socket ones.
Two reads of the same kernel timestamp at approx the same time, will likely have tsc timestamped in different occasions too. This means the delta we calculate is unpredictable at best, and can probably be smaller in a cpu that is legitimately reading clock in a forward ocasion.
Some adjustments on the host could make this window less likely to happen, but still, it pretty much poses as an intrinsic problem of the mechanism.
A while ago, I though about using a shared variable anyway, to hold clock last state, but gave up due to the high contention locking was likely to introduce, possibly rendering the thing useless on big machines. I argue, however, that locking is not necessary.
We do a read-and-return sequence in pvclock, and between read and return, the global value can have changed. However, it can only have changed by means of an addition of a positive value. So if we detected that our clock timestamp is less than the current global, we know that we need to return a higher one, even though it is not exactly the one we compared to.
OTOH, if we detect we're greater than the current time source, we atomically replace the value with our new readings. This do causes contention on big boxes (but big here means *BIG*), but it seems like a good trade off, since it provide us with a time source guaranteed to be stable wrt time warps.
After this patch is applied, I don't see a single warp in time during 5 days of execution, in any of the machines I saw them before.
--- arch/x86/kernel/pvclock.c | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+)
arch/x86/kernel/pvclock.c +24 -0
@@ -109,11 +109,14 @@ unsigned long pvclock_tsc_khz(struct pvcreturn pv_tsc_khz; } +static atomic64_t last_value =ATOMIC64_INIT (0 ); +cycle_t pvclock_clocksource_read (struct pvclock_vcpu_time_info *src) {struct pvclock_shadow_time shadow;unsigned version;cycle_t ret, offset; +u64 last; do { version = pvclock_get_time_values(&shadow, src);
@@ -123,6 +126,27 @@ cycle_t pvclock_clocksource_read(structbarrier (); }while (version != src->version); +/* +* Assumption here is that last_value, a global accumulator, always goes +* forward. If we are less than that, we should not be much smaller. +* We assume there is an error marging we're inside, and then the correction +* does not sacrifice accuracy. +* +* For reads: global may have changed between test and return, +* but this means someone else updated poked the clock at a later time. +* We just need to make sure we are not seeing a backwards event. +* +* For updates: last_value = ret is not enough, since two vcpus could be +* updating at the same time, and one of them could be slightly behind, +* making the assumption that last_value always go forward fail to hold. +*/ + last =atomic64_read (&last_value); +do { +if (ret < last) +return last; + last =atomic64_cmpxchg (&last_value, last, ret); + }while (unlikely (last != ret)); +return ret; }
PATCH 150/164 KVM: Dont allow lmsw to clear cr0.pe
In reply to Greg KH2.6.33-stable review patch. If anyone has any objections, please let me know.
------------------
From: Avi Kivity <[email protected]>
The current lmsw implementation allows the guest to clear cr0.pe, contrary to the manual, which breaks EMM386.EXE.
Fix by ORing the old cr0.pe with lmsw's operand.
--- arch/x86/kvm/x86.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/x86/kvm/x86.c +1 -1
@@ -432,7 +432,7 @@ EXPORT_SYMBOL_GPL(kvm_set_cr0);void kvm_lmsw (struct kvm_vcpu *vcpu,unsigned long msw) { -kvm_set_cr0 (vcpu, (vcpu->arch.cr0 & ~0x0ful ) | (msw &0x0f )); +kvm_set_cr0 (vcpu, (vcpu->arch.cr0 & ~0x0eul ) | (msw &0x0f )); }EXPORT_SYMBOL_GPL (kvm_lmsw);
PATCH 151/164 KVM: x86: Check LMA bit before set_efer
In reply to Greg KH2.6.33-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sheng Yang <[email protected]>
kvm_x86_ops->set_efer() would execute vcpu->arch.efer = efer, so the checking of LMA bit didn't work.
--- arch/x86/kvm/x86.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/x86/kvm/x86.c +2 -2
@@ -603,11 +603,11 @@ static void set_efer(struct kvm_vcpu *vc } } - kvm_x86_ops->set_efer (vcpu, efer); - efer &= ~EFER_LMA ; efer |= vcpu->arch.shadow_efer &EFER_LMA ; + kvm_x86_ops->set_efer (vcpu, efer); + vcpu->arch.shadow_efer = efer; vcpu->arch.mmu.base_role.nxe = (efer &EFER_NX ) && !tdp_enabled;
PATCH 152/164 KVM: MMU: Segregate shadow pages with different cr0.wp
In reply to Greg KH2.6.33-stable review patch. If anyone has any objections, please let me know.
------------------
From: Avi Kivity <[email protected]>
When cr0.wp=0, we may shadow a gpte having u/s=1 and r/w=0 with an spte having u/s=0 and r/w=1. This allows excessive access if the guest sets cr0.wp=1 and accesses through this spte.
Fix by making cr0.wp part of the base role; we'll have different sptes for the two cases and the problem disappears.
--- arch/x86/include/asm/kvm_host.h | 1 + arch/x86/kvm/mmu.c | 3 ++- 2 files changed, 3 insertions(+), 1 deletion(-)
arch/x86/include/asm/kvm_host.h +1 -0
@@ -193,6 +193,7 @@ union kvm_mmu_page_role { unsigned invalid:1; unsigned cr4_pge:1; unsigned nxe:1; + unsigned cr0_wp:1; }; };
arch/x86/kvm/mmu.c +2 -1
@@ -227,7 +227,7 @@ void kvm_mmu_set_mask_ptes(u64 user_mask }EXPORT_SYMBOL_GPL (kvm_mmu_set_mask_ptes); -static int is_write_protection (struct kvm_vcpu *vcpu) +static bool is_write_protection (struct kvm_vcpu *vcpu) {return vcpu->arch.cr0 &X86_CR0_WP ; }
@@ -2448,6 +2448,7 @@ static int init_kvm_softmmu(struct kvm_v r =paging32_init_context (vcpu); vcpu->arch.mmu.base_role.glevels = vcpu->arch.mmu.root_level; + vcpu->arch.mmu.base_role.cr0_wp =is_write_protection (vcpu);return r; }
PATCH 153/164 KVM: VMX: enable VMXON check with SMX enabled (Intel TXT)
In reply to Greg KH2.6.33-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shane Wang <[email protected]>
Per document, for feature control MSR:
Bit 1 enables VMXON in SMX operation. If the bit is clear, execution
of VMXON in SMX operation causes a general-protection exception.
Bit 2 enables VMXON outside SMX operation. If the bit is clear, execution
of VMXON outside SMX operation causes a general-protection exception.
This patch is to enable this kind of check with SMX for VMXON in KVM.
--- arch/x86/include/asm/msr-index.h | 5 +++-- arch/x86/kernel/tboot.c | 1 + arch/x86/kvm/vmx.c | 32 +++++++++++++++++++++----------- include/linux/tboot.h | 1 + 4 files changed, 26 insertions(+), 13 deletions(-)
arch/x86/include/asm/msr-index.h +3 -2
@@ -199,8 +199,9 @@#define MSR_IA32_EBL_CR_POWERON 0x0000002a#define MSR_IA32_FEATURE_CONTROL 0x0000003a -#define FEATURE_CONTROL_LOCKED (1<<0) -#define FEATURE_CONTROL_VMXON_ENABLED (1<<2) +#define FEATURE_CONTROL_LOCKED (1<<0) +#define FEATURE_CONTROL_VMXON_ENABLED_INSIDE_SMX (1<<1) +#define FEATURE_CONTROL_VMXON_ENABLED_OUTSIDE_SMX (1<<2)#define MSR_IA32_APICBASE 0x0000001b#define MSR_IA32_APICBASE_BSP (1<<8)
arch/x86/kernel/tboot.c +1 -0
@@ -46,6 +46,7 @@/* Global pointer to shared data; NULL means no measured launch. */ struct tboot *tboot__read_mostly ; +EXPORT_SYMBOL (tboot);/* timeout for APs (in secs) to enter wait-for-SIPI state during shutdown */ #define AP_WAIT_TIMEOUT 1
arch/x86/kvm/vmx.c +21 -11
@@ -26,6 +26,7 @@#include <linux/sched.h> #include <linux/moduleparam.h> #include <linux/ftrace_event.h> +#include <linux/tboot.h> #include "kvm_cache_regs.h" #include "x86.h"
@@ -1125,9 +1126,16 @@ static __init int vmx_disabled_by_bios(vu64 msr;rdmsrl (MSR_IA32_FEATURE_CONTROL , msr); -return (msr & (FEATURE_CONTROL_LOCKED | -FEATURE_CONTROL_VMXON_ENABLED )) - ==FEATURE_CONTROL_LOCKED ; +if (msr &FEATURE_CONTROL_LOCKED ) { +if (!(msr &FEATURE_CONTROL_VMXON_ENABLED_INSIDE_SMX ) + &&tboot_enabled ()) +return 1 ; +if (!(msr &FEATURE_CONTROL_VMXON_ENABLED_OUTSIDE_SMX ) + && !tboot_enabled ()) +return 1 ; + } + +return 0 ;/* locked but not enabled */ }
@@ -1135,21 +1143,23 @@ static int hardware_enable(void *garbage {int cpu =raw_smp_processor_id ();u64 phys_addr =__pa (per_cpu (vmxarea, cpu)); -u64 old; +u64 old, test_bits;if (read_cr4 () &X86_CR4_VMXE )return -EBUSY ;INIT_LIST_HEAD (&per_cpu (vcpus_on_cpu, cpu));rdmsrl (MSR_IA32_FEATURE_CONTROL , old); -if ((old & (FEATURE_CONTROL_LOCKED | -FEATURE_CONTROL_VMXON_ENABLED )) - != (FEATURE_CONTROL_LOCKED | -FEATURE_CONTROL_VMXON_ENABLED )) + + test_bits =FEATURE_CONTROL_LOCKED ; + test_bits |=FEATURE_CONTROL_VMXON_ENABLED_OUTSIDE_SMX ; +if (tboot_enabled ()) + test_bits |=FEATURE_CONTROL_VMXON_ENABLED_INSIDE_SMX ; + +if ((old & test_bits) != test_bits) {/* enable and lock */ -wrmsrl (MSR_IA32_FEATURE_CONTROL , old | -FEATURE_CONTROL_LOCKED | -FEATURE_CONTROL_VMXON_ENABLED ); +wrmsrl (MSR_IA32_FEATURE_CONTROL , old | test_bits); + }write_cr4 (read_cr4 () |X86_CR4_VMXE );/* FIXME: not cpu hotplug safe */ asmvolatile (ASM_VMX_VMXON_RAX : : "a"(&phys_addr), "m"(phys_addr)
include/linux/tboot.h +1 -0
@@ -150,6 +150,7 @@ extern int tboot_force_iommu(void);#else +#define tboot_enabled () 0#define tboot_probe () do { } while (0)#define tboot_shutdown (shutdown_type) do { } while (0)#define tboot_sleep (sleep_state, pm1a_control, pm1b_control) \
PATCH 154/164 KVM: MMU: Dont read pdptrs with mmu spinlock held in mmu_alloc_roots
In reply to Greg KH2.6.33-stable review patch. If anyone has any objections, please let me know.
------------------
From: Avi Kivity <[email protected]>
On svm, kvm_read_pdptr() may require reading guest memory, which can sleep.
Push the spinlock into mmu_alloc_roots(), and only take it after we've read the pdptr.
--- arch/x86/kvm/mmu.c | 9 +++++++++ 1 file changed, 9 insertions(+)
arch/x86/kvm/mmu.c +9 -0
@@ -2097,11 +2097,14 @@ static int mmu_alloc_roots(struct kvm_vc direct =1 ;if (mmu_check_root (vcpu, root_gfn))return 1 ; + +spin_lock (&vcpu->kvm->mmu_lock); sp =kvm_mmu_get_page (vcpu, root_gfn,0 ,PT64_ROOT_LEVEL , direct,ACC_ALL ,NULL ); root =__pa (sp->spt); ++sp->root_count; +spin_unlock (&vcpu->kvm->mmu_lock); vcpu->arch.mmu.root_hpa = root;return 0 ; }
@@ -2123,11 +2126,15 @@ static int mmu_alloc_roots(struct kvm_vc root_gfn =0 ;if (mmu_check_root (vcpu, root_gfn))return 1 ; + +spin_lock (&vcpu->kvm->mmu_lock); sp =kvm_mmu_get_page (vcpu, root_gfn, i <<30 ,PT32_ROOT_LEVEL , direct,ACC_ALL ,NULL ); root =__pa (sp->spt); ++sp->root_count; +spin_unlock (&vcpu->kvm->mmu_lock); + vcpu->arch.mmu.pae_root[i] = root |PT_PRESENT_MASK ; } vcpu->arch.mmu.root_hpa =__pa (vcpu->arch.mmu.pae_root);
@@ -2488,7 +2495,9 @@ int kvm_mmu_load(struct kvm_vcpu *vcpu) goto out;spin_lock (&vcpu->kvm->mmu_lock);kvm_mmu_free_some_pages (vcpu); +spin_unlock (&vcpu->kvm->mmu_lock); r =mmu_alloc_roots (vcpu); +spin_lock (&vcpu->kvm->mmu_lock);mmu_sync_roots (vcpu);spin_unlock (&vcpu->kvm->mmu_lock);if (r)
PATCH 155/164 KVM: Fix wallclock version writing race
In reply to Greg KH2.6.33-stable review patch. If anyone has any objections, please let me know.
------------------
From: Avi Kivity <[email protected]>
Wallclock writing uses an unprotected global variable to hold the version; this can cause one guest to interfere with another if both write their wallclock at the same time.
--- arch/x86/kvm/x86.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-)
arch/x86/kvm/x86.c +10 -2
@@ -641,14 +641,22 @@ static int do_set_msr(struct kvm_vcpu *vstatic void kvm_write_wall_clock (struct kvm *kvm,gpa_t wall_clock) { -static int version; +int version; +int r;struct pvclock_wall_clock wc;struct timespec boot;if (!wall_clock)return ; - version++; + r =kvm_read_guest (kvm, wall_clock, &version,sizeof (version)); +if (r) +return ; + +if (version &1 ) + ++version;/* first time write, random junk */ + + ++version;kvm_write_guest (kvm, wall_clock, &version,sizeof (version));
PATCH 156/164 KVM: PPC: Add missing vcpu_load()/vcpu_put() in vcpu ioctls
In reply to Greg KH2.6.33-stable review patch. If anyone has any objections, please let me know.
------------------
From: Avi Kivity <[email protected]>
--- arch/powerpc/kvm/book3s.c | 10 ++++++++++ arch/powerpc/kvm/booke.c | 15 ++++++++++++++- 2 files changed, 24 insertions(+), 1 deletion(-)
arch/powerpc/kvm/book3s.c +10 -0
@@ -766,6 +766,8 @@ int kvm_arch_vcpu_ioctl_get_sregs(structstruct kvmppc_vcpu_book3s *vcpu3s =to_book3s (vcpu);int i; +vcpu_load (vcpu); + sregs->pvr = vcpu->arch.pvr; sregs->u.s.sdr1 =to_book3s (vcpu)->sdr1;
@@ -784,6 +786,9 @@ int kvm_arch_vcpu_ioctl_get_sregs(struct sregs->u.s.ppc32.dbat[i] = vcpu3s->dbat[i].raw; } } + +vcpu_put (vcpu); +return 0 ; }
@@ -793,6 +798,8 @@ int kvm_arch_vcpu_ioctl_set_sregs(structstruct kvmppc_vcpu_book3s *vcpu3s =to_book3s (vcpu);int i; +vcpu_load (vcpu); +kvmppc_set_pvr (vcpu, sregs->pvr); vcpu3s->sdr1 = sregs->u.s.sdr1;
@@ -819,6 +826,9 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct/* Flush the MMU after messing with the segments */ kvmppc_mmu_pte_flush (vcpu,0 ,0 ); + +vcpu_put (vcpu); +return 0 ; }
arch/powerpc/kvm/booke.c +14 -1
@@ -443,6 +443,8 @@ int kvm_arch_vcpu_ioctl_get_regs(struct {int i; +vcpu_load (vcpu); + regs->pc = vcpu->arch.pc; regs->cr = vcpu->arch.cr; regs->ctr = vcpu->arch.ctr;
@@ -463,6 +465,8 @@ int kvm_arch_vcpu_ioctl_get_regs(structfor (i =0 ; i <ARRAY_SIZE (regs->gpr); i++) regs->gpr[i] = vcpu->arch.gpr[i]; +vcpu_put (vcpu); +return 0 ; }
@@ -470,6 +474,8 @@ int kvm_arch_vcpu_ioctl_set_regs(struct {int i; +vcpu_load (vcpu); + vcpu->arch.pc = regs->pc; vcpu->arch.cr = regs->cr; vcpu->arch.ctr = regs->ctr;
@@ -489,6 +495,8 @@ int kvm_arch_vcpu_ioctl_set_regs(structfor (i =0 ; i <ARRAY_SIZE (vcpu->arch.gpr); i++) vcpu->arch.gpr[i] = regs->gpr[i]; +vcpu_put (vcpu); +return 0 ; }
@@ -517,7 +525,12 @@ int kvm_arch_vcpu_ioctl_set_fpu(struct kint kvm_arch_vcpu_ioctl_translate (struct kvm_vcpu *vcpu,struct kvm_translation *tr) { -return kvmppc_core_vcpu_translate (vcpu, tr); +int r; + +vcpu_load (vcpu); + r =kvmppc_core_vcpu_translate (vcpu, tr); +vcpu_put (vcpu); +return r; }int kvm_vm_ioctl_get_dirty_log (struct kvm *kvm,struct kvm_dirty_log *log)
PATCH 157/164 KVM: x86: Add missing locking to arch specific vcpu ioctls
In reply to Greg KH2.6.33-stable review patch. If anyone has any objections, please let me know.
------------------
From: Avi Kivity <[email protected]>
--- arch/x86/kvm/x86.c | 6 ++++++ 1 file changed, 6 insertions(+)
arch/x86/kvm/x86.c +6 -0
@@ -1550,6 +1550,7 @@ static int kvm_vcpu_ioctl_get_cpuid2(str {int r; +vcpu_load (vcpu); r = -E2BIG ;if (cpuid->nent < vcpu->arch.cpuid_nent) goto out;
@@ -1561,6 +1562,7 @@ static int kvm_vcpu_ioctl_get_cpuid2(str out: cpuid->nent = vcpu->arch.cpuid_nent; +vcpu_put (vcpu);return r; }
@@ -1813,6 +1815,7 @@ static int kvm_vcpu_ioctl_x86_setup_mce(int r;unsigned bank_num = mcg_cap &0xff , bank; +vcpu_load (vcpu); r = -EINVAL ;if (!bank_num || bank_num >=KVM_MAX_MCE_BANKS ) goto out;
@@ -1827,6 +1830,7 @@ static int kvm_vcpu_ioctl_x86_setup_mce(for (bank =0 ; bank < bank_num; bank++) vcpu->arch.mce_banks[bank*4 ] = ~(u64 )0 ; out: +vcpu_put (vcpu);return r; }
@@ -2094,7 +2098,9 @@ long kvm_arch_vcpu_ioctl(struct file *fi r = -EFAULT ;if (copy_from_user (&mce, argp,sizeof mce)) goto out; +vcpu_load (vcpu); r =kvm_vcpu_ioctl_x86_set_mce (vcpu, &mce); +vcpu_put (vcpu);break ; }case KVM_GET_VCPU_EVENTS : {
PATCH 158/164 KVM: x86: Inject #GP with the right rip on efer writes
In reply to Greg KH2.6.33-stable review patch. If anyone has any objections, please let me know.
------------------
From: Roedel, Joerg <[email protected]>
This patch fixes a bug in the KVM efer-msr write path. If a guest writes to a reserved efer bit the set_efer function injects the #GP directly. The architecture dependent wrmsr function does not see this, assumes success and advances the rip. This results in a #GP in the guest with the wrong rip. This patch fixes this by reporting efer write errors back to the architectural wrmsr function.
--- arch/x86/kvm/x86.c | 31 ++++++++++++------------------- 1 file changed, 12 insertions(+), 19 deletions(-)
arch/x86/kvm/x86.c +12 -19
@@ -570,37 +570,29 @@ static u32 emulated_msrs[] = { MSR_IA32_MISC_ENABLE, }; -static void set_efer (struct kvm_vcpu *vcpu,u64 efer) +static int set_efer (struct kvm_vcpu *vcpu,u64 efer) { -if (efer & efer_reserved_bits) { -kvm_inject_gp (vcpu,0 ); -return ; - } +if (efer & efer_reserved_bits) +return 1 ;if (is_paging (vcpu) - && (vcpu->arch.shadow_efer &EFER_LME ) != (efer &EFER_LME )) { -kvm_inject_gp (vcpu,0 ); -return ; - } + && (vcpu->arch.shadow_efer &EFER_LME ) != (efer &EFER_LME )) +return 1 ;if (efer &EFER_FFXSR ) {struct kvm_cpuid_entry2 *feat; feat =kvm_find_cpuid_entry (vcpu,0x80000001 ,0 ); -if (!feat || !(feat->edx &bit (X86_FEATURE_FXSR_OPT ))) { -kvm_inject_gp (vcpu,0 ); -return ; - } +if (!feat || !(feat->edx &bit (X86_FEATURE_FXSR_OPT ))) +return 1 ; }if (efer &EFER_SVME ) {struct kvm_cpuid_entry2 *feat; feat =kvm_find_cpuid_entry (vcpu,0x80000001 ,0 ); -if (!feat || !(feat->ecx &bit (X86_FEATURE_SVM ))) { -kvm_inject_gp (vcpu,0 ); -return ; - } +if (!feat || !(feat->ecx &bit (X86_FEATURE_SVM ))) +return 1 ; } efer &= ~EFER_LMA ;
@@ -612,6 +604,8 @@ static void set_efer(struct kvm_vcpu *vc vcpu->arch.mmu.base_role.nxe = (efer &EFER_NX ) && !tdp_enabled;kvm_mmu_reset_context (vcpu); + +return 0 ; }void kvm_enable_efer_bits (u64 mask)
@@ -946,8 +940,7 @@ int kvm_set_msr_common(struct kvm_vcpu * {switch (msr) {case MSR_EFER : -set_efer (vcpu, data); -break ; +return set_efer (vcpu, data);case MSR_K7_HWCR : data &= ~(u64 )0x40 ;/* ignore flush filter disable */ if (data !=0 ) {
PATCH 159/164 KVM: SVM: Dont allow nested guest to VMMCALL into host
In reply to Greg KH2.6.33-stable review patch. If anyone has any objections, please let me know.
------------------
From: Joerg Roedel <[email protected]>
This patch disables the possibility for a l2-guest to do a VMMCALL directly into the host. This would happen if the l1-hypervisor doesn't intercept VMMCALL and the l2-guest executes this instruction.
--- arch/x86/kvm/svm.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
arch/x86/kvm/svm.c +7 -2
@@ -1829,8 +1829,13 @@ static bool nested_svm_vmrun(struct vcpu svm->vmcb->control.intercept_cr_write &= ~INTERCEPT_CR8_MASK ; } -/* We don't want a nested guest to be more powerful than the guest, -so all intercepts are ORed */ +/* We don't want to see VMMCALLs from a nested guest */ + svm->vmcb->control.intercept &= ~(1ULL <<INTERCEPT_VMMCALL ); + +/* +* We don't want a nested guest to be more powerful than the guest, so +* all intercepts are ORed +*/ svm->vmcb->control.intercept_cr_read |= nested_vmcb->control.intercept_cr_read; svm->vmcb->control.intercept_cr_write |=
PATCH 160/164 parisc: clear floating point exception flag on SIGFPE signal
In reply to Greg KH2.6.33-stable review patch. If anyone has any objections, please let me know.
------------------
From: Helge Deller <[email protected]>
commit 550f0d922286556c7ea43974bb7921effb5a5278 upstream.
Clear the floating point exception flag before returning to user space. This is needed, else the libc trampoline handler may hit the same SIGFPE again while building up a trampoline to a signal handler.
Fixes debian bug #559406.
--- arch/parisc/math-emu/decode_exc.c | 1 + 1 file changed, 1 insertion(+)
arch/parisc/math-emu/decode_exc.c +1 -0
@@ -342,6 +342,7 @@ decode_fpu(unsigned int Fpu_register[],return SIGNALCODE (SIGFPE ,FPE_FLTINV );case DIVISIONBYZEROEXCEPTION :update_trap_counts (Fpu_register, aflags, bflags, trap_counts); +Clear_excp_register (exception_index);return SIGNALCODE (SIGFPE ,FPE_FLTDIV );case INEXACTEXCEPTION :update_trap_counts (Fpu_register, aflags, bflags, trap_counts);
PATCH 161/164 KEYS: Return more accurate error codes
In reply to Greg KH2.6.33-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <[email protected]>
commit 4d09ec0f705cf88a12add029c058b53f288cfaa2 upstream.
We were using the wrong variable here so the error codes weren't being returned properly. The original code returns -ENOKEY.
--- security/keys/process_keys.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
security/keys/process_keys.c +3 -3
@@ -509,7 +509,7 @@ try_again: ret =install_thread_keyring ();if (ret <0 ) { - key =ERR_PTR (ret); + key_ref =ERR_PTR (ret); goto error; } goto reget_creds;
@@ -527,7 +527,7 @@ try_again: ret =install_process_keyring ();if (ret <0 ) { - key =ERR_PTR (ret); + key_ref =ERR_PTR (ret); goto error; } goto reget_creds;
@@ -586,7 +586,7 @@ try_again:case KEY_SPEC_GROUP_KEYRING :/* group keyrings are not yet supported */ - key =ERR_PTR (-EINVAL ); + key_ref =ERR_PTR (-EINVAL ); goto error;case KEY_SPEC_REQKEY_AUTH_KEY :
PATCH 162/164 KEYS: find_keyring_by_name() can gain access to a freed keyring
In reply to Greg KH2.6.33-stable review patch. If anyone has any objections, please let me know.
------------------
From: Toshiyuki Okajima <[email protected]>
commit cea7daa3589d6b550546a8c8963599f7c1a3ae5c upstream.
find_keyring_by_name() can gain access to a keyring that has had its reference count reduced to zero, and is thus ready to be freed. This then allows the dead keyring to be brought back into use whilst it is being destroyed.
The following timeline illustrates the process:
|(cleaner) (user)
|
| free_user(user) sys_keyctl()
| | |
| key_put(user->session_keyring) keyctl_get_keyring_ID()
| || //=> keyring->usage = 0 |
| |schedule_work(&key_cleanup_task) lookup_user_key()
| || |
| kmem_cache_free(,user) |
| . |[KEY_SPEC_USER_KEYRING]
| . install_user_keyrings()
| . ||
| key_cleanup() [<= worker_thread()] ||
| | ||
| [spin_lock(&key_serial_lock)] |[mutex_lock(&key_user_keyr..mutex)]
| | ||
| atomic_read() == 0 ||
| |{ rb_ease(&key->serial_node,) } ||
| | ||
| [spin_unlock(&key_serial_lock)] |find_keyring_by_name()
| | |||
| keyring_destroy(keyring) ||[read_lock(&keyring_name_lock)]
| || |||
| |[write_lock(&keyring_name_lock)] ||atomic_inc(&keyring->usage)
| |. ||| *** GET freeing keyring ***
| |. ||[read_unlock(&keyring_name_lock)]
| || ||
| |list_del() |[mutex_unlock(&key_user_k..mutex)]
| || |
| |[write_unlock(&keyring_name_lock)] ** INVALID keyring is returned **
| | .
| kmem_cache_free(,keyring) .
| .
| atomic_dec(&keyring->usage)v *** DESTROYED ***
TIME
If CONFIG_SLUB_DEBUG=y then we may see the following message generated:
============================================================================= BUG key_jar: Poison overwritten ----------------------------------------------------------------------------- INFO: 0xffff880197a7e200-0xffff880197a7e200. First byte 0x6a instead of 0x6b INFO: Allocated in key_alloc+0x10b/0x35f age=25 cpu=1 pid=5086 INFO: Freed in key_cleanup+0xd0/0xd5 age=12 cpu=1 pid=10 INFO: Slab 0xffffea000592cb90 objects=16 used=2 fp=0xffff880197a7e200 flags=0x200000000000c3 INFO: Object 0xffff880197a7e200 @offset=512 fp=0xffff880197a7e300 Bytes b4 0xffff880197a7e1f0: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ Object 0xffff880197a7e200: 6a 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b jkkkkkkkkkkkkkkk
Alternatively, we may see a system panic happen, such as:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000001 IP: [<ffffffff810e61a3>] kmem_cache_alloc+0x5b/0xe9 PGD 6b2b4067 PUD 6a80d067 PMD 0 Oops: 0000 [#1] SMP last sysfs file: /sys/kernel/kexec_crash_loaded CPU 1 ... Pid: 31245, comm: su Not tainted 2.6.34-rc5-nofixed-nodebug #2 D2089/PRIMERGY RIP: 0010:[<ffffffff810e61a3>] [<ffffffff810e61a3>] kmem_cache_alloc+0x5b/0xe9 RSP: 0018:ffff88006af3bd98 EFLAGS: 00010002 RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffff88007d19900b RDX: 0000000100000000 RSI: 00000000000080d0 RDI: ffffffff81828430 RBP: ffffffff81828430 R08: ffff88000a293750 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000100000 R12: 00000000000080d0 R13: 00000000000080d0 R14: 0000000000000296 R15: ffffffff810f20ce FS: 00007f97116bc700(0000) GS:ffff88000a280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000001 CR3: 000000006a91c000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process su (pid: 31245, threadinfo ffff88006af3a000, task ffff8800374414c0) Stack: 0000000512e0958e 0000000000008000 ffff880037f8d180 0000000000000001 0000000000000000 0000000000008001 ffff88007d199000 ffffffff810f20ce 0000000000008000 ffff88006af3be48 0000000000000024 ffffffff810face3 Call Trace: [<ffffffff810f20ce>] ? get_empty_filp+0x70/0x12f [<ffffffff810face3>] ? do_filp_open+0x145/0x590 [<ffffffff810ce208>] ? tlb_finish_mmu+0x2a/0x33 [<ffffffff810ce43c>] ? unmap_region+0xd3/0xe2 [<ffffffff810e4393>] ? virt_to_head_page+0x9/0x2d [<ffffffff81103916>] ? alloc_fd+0x69/0x10e [<ffffffff810ef4ed>] ? do_sys_open+0x56/0xfc [<ffffffff81008a02>] ? system_call_fastpath+0x16/0x1b Code: 0f 1f 44 00 00 49 89 c6 fa 66 0f 1f 44 00 00 65 4c 8b 04 25 60 e8 00 00 48 8b 45 00 49 01 c0 49 8b 18 48 85 db 74 0d 48 63 45 18 <48> 8b 04 03 49 89 00 eb 14 4c 89 f9 83 ca ff 44 89 e6 48 89 ef RIP [<ffffffff810e61a3>] kmem_cache_alloc+0x5b/0xe9
This problem is that find_keyring_by_name does not confirm that the keyring is valid before accepting it.
Skipping keyrings that have been reduced to a zero count seems the way to go. To this end, use atomic_inc_not_zero() to increment the usage count and skip the candidate keyring if that returns false.
The following script _may_ cause the bug to happen, but there's no guarantee as the window of opportunity is small:
#!/bin/sh
LOOP=100000
USER=dummy_user
/bin/su -c "exit;" $USER || { /usr/sbin/adduser -m $USER; add=1; }
for ((i=0; i<LOOP; i++))
do
/bin/su -c "echo '$i' > /dev/null" $USER
done
(( add == 1 )) && /usr/sbin/userdel -r $USER
exitNote that the nominated user must not be in use.
An alternative way of testing this may be:
for ((i=0; i<100000; i++)) do keyctl session foo /bin/true || break done >&/dev/null
as that uses a keyring named "foo" rather than relying on the user and user-session named keyrings.
--- security/keys/keyring.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-)
security/keys/keyring.c +9 -9
@@ -524,9 +524,8 @@ struct key *find_keyring_by_name(const cstruct key *keyring;int bucket; - keyring =ERR_PTR (-EINVAL );if (!name) - goto error; +return ERR_PTR (-EINVAL ); bucket =keyring_hash (name);
@@ -553,17 +552,18 @@ struct key *find_keyring_by_name(const c KEY_SEARCH) < 0)continue ; -/* we've got a match */ -atomic_inc (&keyring->usage); -read_unlock (&keyring_name_lock); - goto error; +/* we've got a match but we might end up racing with +* key_cleanup() if the keyring is currently 'dead' +* (ie. it has a zero usage count) */ +if (!atomic_inc_not_zero (&keyring->usage)) +continue ; + goto out; } } -read_unlock (&keyring_name_lock); keyring =ERR_PTR (-ENOKEY ); - - error: +out: +read_unlock (&keyring_name_lock);return keyring; }/* end find_keyring_by_name() */
PATCH 163/164 qla2xxx: Disable MSI on qla24xx chips other than QLA2432.
In reply to Greg KH2.6.33-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ben Hutchings <[email protected]>
commit 6377a7ae1ab82859edccdbc8eaea63782efb134d upstream.
On specific platforms, MSI is unreliable on some of the QLA24xx chips, resulting in fatal I/O errors under load, as reported in <http://bugs.debian.org/572322>
and by some RHEL customers.
--- drivers/scsi/qla2xxx/qla_isr.c | 28 +++++++++++++--------------- 1 file changed, 13 insertions(+), 15 deletions(-)
drivers/scsi/qla2xxx/qla_isr.c +13 -15
@@ -2169,30 +2169,28 @@ qla2x00_request_irqs(struct qla_hw_data/* If possible, enable MSI-X. */ if (!IS_QLA2432 (ha) && !IS_QLA2532 (ha) && - !IS_QLA8432 (ha) && !IS_QLA8001 (ha)) - goto skip_msix; + !IS_QLA8432 (ha) && !IS_QLA8001 (ha)) + goto skip_msi; + +if (ha->pdev->subsystem_vendor ==PCI_VENDOR_ID_HP && + (ha->pdev->subsystem_device ==0x7040 || + ha->pdev->subsystem_device ==0x7041 || + ha->pdev->subsystem_device ==0x1705 )) { +DEBUG2 (qla_printk (KERN_WARNING , ha, +"MSI-X: Unsupported ISP2432 SSVID/SSDID (0x%X,0x%X).\n" , + ha->pdev->subsystem_vendor, + ha->pdev->subsystem_device)); + goto skip_msi; + }if (IS_QLA2432 (ha) && (ha->pdev->revision <QLA_MSIX_CHIP_REV_24XX || !QLA_MSIX_FW_MODE_1 (ha->fw_attributes))) {DEBUG2 (qla_printk (KERN_WARNING , ha,"MSI-X: Unsupported ISP2432 (0x%X, 0x%X).\n" , ha->pdev->revision, ha->fw_attributes)); - goto skip_msix; } -if (ha->pdev->subsystem_vendor ==PCI_VENDOR_ID_HP && - (ha->pdev->subsystem_device ==0x7040 || - ha->pdev->subsystem_device ==0x7041 || - ha->pdev->subsystem_device ==0x1705 )) { -DEBUG2 (qla_printk (KERN_WARNING , ha, -"MSI-X: Unsupported ISP2432 SSVID/SSDID (0x%X, 0x%X).\n" , - ha->pdev->subsystem_vendor, - ha->pdev->subsystem_device)); - - goto skip_msi; - } - ret =qla24xx_enable_msix (ha, rsp);if (!ret) { DEBUG2(qla_printk(KERN_INFO, ha,
PATCH 164/164 sctp: fix append error cause to ERROR chunk correctly
In reply to Greg KH2.6.33-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wei Yongjun <[email protected]>
commit 2e3219b5c8a2e44e0b83ae6e04f52f20a82ac0f2 upstream.
commit 5fa782c2f5ef6c2e4f04d3e228412c9b4a4c8809
sctp: Fix skb_over_panic resulting from multiple invalid \
parameter errors (CVE-2010-1173) (v4)
cause 'error cause' never be add the the ERROR chunk due to some typo when check valid length in sctp_init_cause_fixed().
--- net/sctp/sm_make_chunk.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
net/sctp/sm_make_chunk.c +2 -2
@@ -140,7 +140,7 @@ int sctp_init_cause_fixed(struct sctp_ch len =sizeof (sctp_errhdr_t) + paylen; err.length =htons (len); -if (skb_tailroom (chunk->skb) > len) +if (skb_tailroom (chunk->skb) < len)return -ENOSPC ; chunk->subh.err_hdr = sctp_addto_chunk_fixed(chunk, sizeof(sctp_errhdr_t),
@@ -1420,7 +1420,7 @@ void *sctp_addto_chunk(struct sctp_chunkvoid *sctp_addto_chunk_fixed (struct sctp_chunk *chunk,int len,const void *data) { -if (skb_tailroom (chunk->skb) > len) +if (skb_tailroom (chunk->skb) >= len)return sctp_addto_chunk (chunk, len, data);else return NULL ;
cover 2.6.32.16 stable review
In reply to Greg KHThis is the start of the stable review cycle for the 2.6.32.16 release. There are 149 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 me 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 Sat, July 3, 17:00:00 UTC 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.32.16-rc1.gz
and the diffstat can be found below.
thanks,
greg k-h
Documentation/hwmon/ltc4245 | 4 +- Documentation/networking/3c509.txt | 12 +- Makefile | 2 +- arch/arm/common/sa1111.c | 9 +- arch/arm/mm/copypage-feroceon.c | 4 +- arch/arm/mm/copypage-v4wb.c | 4 +- arch/arm/mm/copypage-v4wt.c | 4 +- arch/arm/mm/copypage-xsc3.c | 4 +- arch/arm/mm/fault.c | 3 + arch/arm/mm/init.c | 6 +- arch/arm/vfp/vfphw.S | 2 +- arch/blackfin/include/asm/cache.h | 2 + arch/frv/include/asm/cache.h | 2 + arch/m68k/include/asm/cache.h | 2 + arch/mn10300/include/asm/cache.h | 2 + arch/parisc/math-emu/decode_exc.c | 1 + arch/powerpc/kvm/powerpc.c | 3 +- arch/powerpc/lib/string.S | 4 +- arch/powerpc/oprofile/op_model_cell.c | 2 +- arch/powerpc/platforms/pseries/smp.c | 6 + arch/s390/kvm/kvm-s390.c | 4 +- arch/x86/include/asm/kvm_host.h | 1 + arch/x86/include/asm/msr-index.h | 5 +- arch/x86/kernel/amd_iommu.c | 2 +- arch/x86/kernel/cpu/perf_event.c | 5 +- arch/x86/kernel/pvclock.c | 24 +++ arch/x86/kernel/setup.c | 11 ++ arch/x86/kernel/tboot.c | 1 + arch/x86/kvm/mmu.c | 10 +- arch/x86/kvm/vmx.c | 32 +++-- arch/x86/kvm/x86.c | 55 ++++--- arch/x86/oprofile/nmi_int.c | 10 +- arch/x86/xen/suspend.c | 4 +- arch/xtensa/include/asm/cache.h | 1 + drivers/acpi/video_detect.c | 2 +- drivers/ata/libata-core.c | 7 +- drivers/ata/libata-sff.c | 2 +- drivers/ata/sata_nv.c | 5 +- drivers/ata/sata_via.c | 13 ++ drivers/base/cpu.c | 2 +- drivers/char/ipmi/ipmi_si_intf.c | 11 +- drivers/clocksource/sh_cmt.c | 21 ++- drivers/firewire/core-card.c | 24 +++- drivers/gpu/drm/drm_edid.c | 2 +- drivers/gpu/drm/i915/i915_gem.c | 19 +++ drivers/gpu/drm/i915/intel_lvds.c | 4 + drivers/gpu/drm/radeon/radeon_atombios.c | 2 +- drivers/gpu/drm/radeon/radeon_cp.c | 1 + drivers/gpu/drm/radeon/radeon_drv.h | 2 + drivers/gpu/drm/radeon/radeon_state.c | 7 + drivers/hid/hid-core.c | 1 + drivers/hid/hid-gyration.c | 1 + drivers/hid/hid-ids.h | 1 + drivers/hwmon/ltc4245.c | 18 +-- drivers/input/mouse/psmouse-base.c | 14 ++- drivers/md/dm-exception-store.h | 2 +- drivers/md/md.c | 29 ++++ drivers/md/raid1.c | 9 +- drivers/md/raid10.c | 2 +- drivers/media/video/gspca/stv06xx/stv06xx.c | 2 - drivers/net/arcnet/com20020-pci.c | 4 +- drivers/net/atl1e/atl1e_ethtool.c | 2 + drivers/net/can/sja1000/sja1000.c | 20 ++- drivers/net/can/sja1000/sja1000.h | 1 + drivers/net/mlx4/icm.c | 3 +- drivers/net/pppol2tp.c | 3 +- drivers/net/tulip/Kconfig | 4 + drivers/net/tulip/dmfe.c | 21 +++ drivers/net/tulip/tulip_core.c | 32 +++- drivers/net/ucc_geth.c | 12 +- drivers/net/via-velocity.c | 8 +- drivers/net/virtio_net.c | 3 +- drivers/net/wireless/ath/ar9170/hw.h | 1 + drivers/net/wireless/ath/ar9170/main.c | 2 +- drivers/net/wireless/ath/ar9170/usb.c | 10 ++ drivers/net/wireless/ath/ath5k/base.c | 4 +- drivers/net/wireless/ath/ath9k/hw.c | 7 +- drivers/net/wireless/ath/ath9k/hw.h | 1 + drivers/net/wireless/ath/ath9k/main.c | 4 +- drivers/net/wireless/ath/ath9k/pci.c | 1 + drivers/net/wireless/iwlwifi/iwl-5000.c | 23 +++- drivers/net/wireless/iwlwifi/iwl-agn-rs.c | 24 +++- drivers/net/wireless/iwlwifi/iwl-agn.c | 74 +++++++-- drivers/net/wireless/iwlwifi/iwl-dev.h | 3 +- drivers/net/wireless/iwlwifi/iwl-tx.c | 18 ++- drivers/net/wireless/p54/p54usb.c | 1 + drivers/net/wireless/rtl818x/rtl8180_dev.c | 1 + drivers/net/wireless/wl12xx/wl1251_sdio.c | 1 + drivers/oprofile/cpu_buffer.c | 63 ++------ drivers/pci/quirks.c | 14 ++- drivers/rtc/rtc-cmos.c | 5 +- drivers/rtc/rtc-s3c.c | 5 +- drivers/scsi/qla2xxx/qla_isr.c | 28 ++-- drivers/staging/comedi/drivers/ni_mio_cs.c | 2 +- drivers/staging/rtl8192su/r8192U_core.c | 1 + drivers/staging/vt6655/device_main.c | 2 + drivers/usb/class/cdc-acm.c | 6 +- drivers/usb/gadget/fsl_udc_core.c | 2 +- drivers/usb/host/ehci-hub.c | 17 ++ drivers/usb/host/xhci-hcd.c | 54 ++++++- drivers/usb/host/xhci-ring.c | 37 ++++- drivers/usb/serial/cp210x.c | 11 ++ drivers/usb/serial/ftdi_sio.c | 4 + drivers/usb/serial/ir-usb.c | 2 + drivers/usb/serial/kl5kusb105.c | 1 + drivers/usb/serial/kobil_sct.c | 3 +- drivers/usb/serial/mos7840.c | 1 - drivers/usb/serial/option.c | 226 +++++++++++++++++++++++++++ drivers/usb/serial/visor.c | 1 + drivers/usb/storage/unusual_devs.h | 15 ++ drivers/xen/xenbus/xenbus_xs.c | 2 +- fs/btrfs/acl.c | 3 + fs/cifs/cifsproto.h | 6 +- fs/cifs/dir.c | 20 ++- fs/cifs/file.c | 11 +- fs/exofs/dir.c | 2 +- fs/ext4/move_extent.c | 3 + fs/ext4/resize.c | 3 +- fs/fs-writeback.c | 14 ++- fs/gfs2/file.c | 7 + fs/jbd/journal.c | 2 +- fs/jbd2/journal.c | 3 +- fs/libfs.c | 3 +- fs/namespace.c | 9 +- fs/nfsd/nfssvc.c | 2 +- include/linux/fs.h | 4 +- include/linux/pci_ids.h | 1 + include/linux/swap.h | 10 -- include/linux/tboot.h | 1 + include/net/sctp/structs.h | 1 + kernel/compat.c | 25 ++-- kernel/mutex.c | 7 + kernel/perf_event.c | 40 +++-- kernel/posix-timers.c | 11 +- kernel/signal.c | 6 +- mm/filemap.c | 10 +- mm/hugetlb.c | 2 +- net/mac80211/Kconfig | 9 + net/mac80211/rx.c | 3 +- net/mac80211/tx.c | 5 +- net/sctp/sm_make_chunk.c | 62 +++++++- net/tipc/bearer.c | 37 +---- net/tipc/bearer.h | 2 +- net/tipc/net.c | 25 +--- net/wireless/core.h | 2 + net/wireless/nl80211.c | 37 +---- net/wireless/util.c | 33 ++++ net/wireless/wext-compat.c | 5 +- security/keys/keyring.c | 18 +- security/keys/process_keys.c | 6 +- sound/pci/hda/hda_intel.c | 11 +- sound/pci/hda/patch_realtek.c | 1 + sound/pci/hda/patch_sigmatel.c | 2 +- sound/soc/codecs/wm8350.c | 4 +- sound/soc/codecs/wm8400.c | 18 +- sound/soc/codecs/wm8990.c | 18 +- 156 files changed, 1251 insertions(+), 489 deletions(-)
PATCH 1/149 oprofile/x86: fix uninitialized counter usage during cpu hotplug
2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Robert Richter <[email protected]>
commit 2623a1d55a6260c855e1f6d1895900b50b40a896 upstream.
This fixes a NULL pointer dereference that is triggered when taking a cpu offline after oprofile was initialized, e.g.:
$ opcontrol --init $ opcontrol --start-daemon $ opcontrol --shutdown $ opcontrol --deinit $ echo 0 > /sys/devices/system/cpu/cpu1/online
See the crash dump below. Though the counter has been disabled the cpu notifier is still active and trying to use already freed counter data.
This fix is for linux-stable. To proper fix this, the hotplug code must be rewritten. Thus I will leave a WARN_ON_ONCE() message with this patch.
BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<ffffffff8132ad57>] op_amd_stop+0x2d/0x8e PGD 0 Oops: 0000 [#1] SMP last sysfs file: /sys/devices/system/cpu/cpu1/online CPU 1 Modules linked in:
Pid: 0, comm: swapper Not tainted 2.6.34-rc5-oprofile-x86_64-standard-00210-g8c00f06 #16 Anaheim/Anaheim
RIP: 0010:[<ffffffff8132ad57>] [<ffffffff8132ad57>] op_amd_stop+0x2d/0x8e RSP: 0018:ffff880001843f28 EFLAGS: 00010006 RAX: 0000000000000000 RBX: 0000000000000000 RCX: dead000000200200 RDX: ffff880001843f68 RSI: dead000000100100 RDI: 0000000000000000 RBP: ffff880001843f48 R08: 0000000000000000 R09: ffff880001843f08 R10: ffffffff8102c9a5 R11: ffff88000184ea80 R12: 0000000000000000 R13: ffff88000184f6c0 R14: 0000000000000000 R15: 0000000000000000 FS: 00007fec6a92e6f0(0000) GS:ffff880001840000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000000 CR3: 000000000163b000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process swapper (pid: 0, threadinfo ffff88042fcd8000, task ffff88042fcd51d0) Stack: ffff880001843f48 0000000000000001 ffff88042e9f7d38 ffff880001843f68 <0> ffff880001843f58 ffffffff8132a602 ffff880001843f98 ffffffff810521b3 <0> ffff880001843f68 ffff880001843f68 ffff880001843f88 ffff88042fcd9fd8 Call Trace: <IRQ> [<ffffffff8132a602>] nmi_cpu_stop+0x21/0x23 [<ffffffff810521b3>] generic_smp_call_function_single_interrupt+0xdf/0x11b [<ffffffff8101804f>] smp_call_function_single_interrupt+0x22/0x31 [<ffffffff810029f3>] call_function_single_interrupt+0x13/0x20 <EOI> [<ffffffff8102c9a5>] ? wake_up_process+0x10/0x12 [<ffffffff81008701>] ? default_idle+0x22/0x37 [<ffffffff8100896d>] c1e_idle+0xdf/0xe6 [<ffffffff813f1170>] ? atomic_notifier_call_chain+0x13/0x15 [<ffffffff810012fb>] cpu_idle+0x4b/0x7e [<ffffffff813e8a4e>] start_secondary+0x1ae/0x1b2 Code: 89 e5 41 55 49 89 fd 41 54 45 31 e4 53 31 db 48 83 ec 08 89 df e8 be f8 ff ff 48 98 48 83 3c c5 10 67 7a 81 00 74 1f 49 8b 45 08 <42> 8b 0c 20 0f 32 48 c1 e2 20 25 ff ff bf ff 48 09 d0 48 89 c2 RIP [<ffffffff8132ad57>] op_amd_stop+0x2d/0x8e RSP <ffff880001843f28> CR2: 0000000000000000 ---[ end trace 679ac372d674b757 ]--- Kernel panic - not syncing: Fatal exception in interrupt Pid: 0, comm: swapper Tainted: G D 2.6.34-rc5-oprofile-x86_64-standard-00210-g8c00f06 #16 Call Trace: <IRQ> [<ffffffff813ebd6a>] panic+0x9e/0x10c [<ffffffff810474b0>] ? up+0x34/0x39 [<ffffffff81031ccc>] ? kmsg_dump+0x112/0x12c [<ffffffff813eeff1>] oops_end+0x81/0x8e [<ffffffff8101efee>] no_context+0x1f3/0x202 [<ffffffff8101f1b7>] __bad_area_nosemaphore+0x1ba/0x1e0 [<ffffffff81028d24>] ? enqueue_task_fair+0x16d/0x17a [<ffffffff810264dc>] ? activate_task+0x42/0x53 [<ffffffff8102c967>] ? try_to_wake_up+0x272/0x284 [<ffffffff8101f1eb>] bad_area_nosemaphore+0xe/0x10 [<ffffffff813f0f3f>] do_page_fault+0x1c8/0x37c [<ffffffff81028d24>] ? enqueue_task_fair+0x16d/0x17a [<ffffffff813ee55f>] page_fault+0x1f/0x30 [<ffffffff8102c9a5>] ? wake_up_process+0x10/0x12 [<ffffffff8132ad57>] ? op_amd_stop+0x2d/0x8e [<ffffffff8132ad46>] ? op_amd_stop+0x1c/0x8e [<ffffffff8132a602>] nmi_cpu_stop+0x21/0x23 [<ffffffff810521b3>] generic_smp_call_function_single_interrupt+0xdf/0x11b [<ffffffff8101804f>] smp_call_function_single_interrupt+0x22/0x31 [<ffffffff810029f3>] call_function_single_interrupt+0x13/0x20 <EOI> [<ffffffff8102c9a5>] ? wake_up_process+0x10/0x12 [<ffffffff81008701>] ? default_idle+0x22/0x37 [<ffffffff8100896d>] c1e_idle+0xdf/0xe6 [<ffffffff813f1170>] ? atomic_notifier_call_chain+0x13/0x15 [<ffffffff810012fb>] cpu_idle+0x4b/0x7e [<ffffffff813e8a4e>] start_secondary+0x1ae/0x1b2 ------------[ cut here ]------------ WARNING: at /local/rrichter/.source/linux/arch/x86/kernel/smp.c:118 native_smp_send_reschedule+0x27/0x53() Hardware name: Anaheim Modules linked in: Pid: 0, comm: swapper Tainted: G D 2.6.34-rc5-oprofile-x86_64-standard-00210-g8c00f06 #16 Call Trace: <IRQ> [<ffffffff81017f32>] ? native_smp_send_reschedule+0x27/0x53 [<ffffffff81030ee2>] warn_slowpath_common+0x77/0xa4 [<ffffffff81030f1e>] warn_slowpath_null+0xf/0x11 [<ffffffff81017f32>] native_smp_send_reschedule+0x27/0x53 [<ffffffff8102634b>] resched_task+0x60/0x62 [<ffffffff8102653a>] check_preempt_curr_idle+0x10/0x12 [<ffffffff8102c8ea>] try_to_wake_up+0x1f5/0x284 [<ffffffff8102c986>] default_wake_function+0xd/0xf [<ffffffff810a110d>] pollwake+0x57/0x5a [<ffffffff8102c979>] ? default_wake_function+0x0/0xf [<ffffffff81026be5>] __wake_up_common+0x46/0x75 [<ffffffff81026ed0>] __wake_up+0x38/0x50 [<ffffffff81031694>] printk_tick+0x39/0x3b [<ffffffff8103ac37>] update_process_times+0x3f/0x5c [<ffffffff8104dc63>] tick_periodic+0x5d/0x69 [<ffffffff8104dc90>] tick_handle_periodic+0x21/0x71 [<ffffffff81018fd0>] smp_apic_timer_interrupt+0x82/0x95 [<ffffffff81002853>] apic_timer_interrupt+0x13/0x20 [<ffffffff81030cb5>] ? panic_blink_one_second+0x0/0x7b [<ffffffff813ebdd6>] ? panic+0x10a/0x10c [<ffffffff810474b0>] ? up+0x34/0x39 [<ffffffff81031ccc>] ? kmsg_dump+0x112/0x12c [<ffffffff813eeff1>] ? oops_end+0x81/0x8e [<ffffffff8101efee>] ? no_context+0x1f3/0x202 [<ffffffff8101f1b7>] ? __bad_area_nosemaphore+0x1ba/0x1e0 [<ffffffff81028d24>] ? enqueue_task_fair+0x16d/0x17a [<ffffffff810264dc>] ? activate_task+0x42/0x53 [<ffffffff8102c967>] ? try_to_wake_up+0x272/0x284 [<ffffffff8101f1eb>] ? bad_area_nosemaphore+0xe/0x10 [<ffffffff813f0f3f>] ? do_page_fault+0x1c8/0x37c [<ffffffff81028d24>] ? enqueue_task_fair+0x16d/0x17a [<ffffffff813ee55f>] ? page_fault+0x1f/0x30 [<ffffffff8102c9a5>] ? wake_up_process+0x10/0x12 [<ffffffff8132ad57>] ? op_amd_stop+0x2d/0x8e [<ffffffff8132ad46>] ? op_amd_stop+0x1c/0x8e [<ffffffff8132a602>] ? nmi_cpu_stop+0x21/0x23 [<ffffffff810521b3>] ? generic_smp_call_function_single_interrupt+0xdf/0x11b [<ffffffff8101804f>] ? smp_call_function_single_interrupt+0x22/0x31 [<ffffffff810029f3>] ? call_function_single_interrupt+0x13/0x20 <EOI> [<ffffffff8102c9a5>] ? wake_up_process+0x10/0x12 [<ffffffff81008701>] ? default_idle+0x22/0x37 [<ffffffff8100896d>] ? c1e_idle+0xdf/0xe6 [<ffffffff813f1170>] ? atomic_notifier_call_chain+0x13/0x15 [<ffffffff810012fb>] ? cpu_idle+0x4b/0x7e [<ffffffff813e8a4e>] ? start_secondary+0x1ae/0x1b2 ---[ end trace 679ac372d674b758 ]---
--- arch/x86/oprofile/nmi_int.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-)
arch/x86/oprofile/nmi_int.c +8 -2
@@ -95,7 +95,10 @@ static void nmi_cpu_save_registers(strucstatic void nmi_cpu_start (void *dummy) {struct op_msrs const *msrs = &__get_cpu_var (cpu_msrs); - model->start (msrs); +if (!msrs->controls) +WARN_ON_ONCE (1 ); +else + model->start (msrs); }static int nmi_start (void )
@@ -107,7 +110,10 @@ static int nmi_start(void)static void nmi_cpu_stop (void *dummy) {struct op_msrs const *msrs = &__get_cpu_var (cpu_msrs); - model->stop (msrs); +if (!msrs->controls) +WARN_ON_ONCE (1 ); +else + model->stop (msrs); }static void nmi_stop (void )
PATCH 2/149 oprofile: remove double ring buffering
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Andi Kleen <[email protected]>
commit cb6e943ccf19ab6d3189147e9d625a992e016084 upstream.
oprofile used a double buffer scheme for its cpu event buffer to avoid races on reading with the old locked ring buffer.
But that is obsolete now with the new ring buffer, so simply use a single buffer. This greatly simplifies the code and avoids a lot of sample drops on large runs, especially with call graph.
Based on suggestions from Steven Rostedt
For stable kernels from v2.6.32, but not earlier.
--- drivers/oprofile/cpu_buffer.c | 63 ++++++++---------------------------------- 1 file changed, 13 insertions(+), 50 deletions(-)
drivers/oprofile/cpu_buffer.c +13 -50
@@ -30,23 +30,7 @@#define OP_BUFFER_FLAGS 0 -/* -* Read and write access is using spin locking. Thus, writing to the -* buffer by NMI handler (x86) could occur also during critical -* sections when reading the buffer. To avoid this, there are 2 -* buffers for independent read and write access. Read access is in -* process context only, write access only in the NMI handler. If the -* read buffer runs empty, both buffers are swapped atomically. There -* is potentially a small window during swapping where the buffers are -* disabled and samples could be lost. -* -* Using 2 buffers is a little bit overhead, but the solution is clear -* and does not require changes in the ring buffer implementation. It -* can be changed to a single buffer solution when the ring buffer -* access is implemented as non-locking atomic code. -*/ -static struct ring_buffer *op_ring_buffer_read; -static struct ring_buffer *op_ring_buffer_write; +static struct ring_buffer *op_ring_buffer; DEFINE_PER_CPU(struct oprofile_cpu_buffer, cpu_buffer);static void wq_sync_buffer (struct work_struct *work);
@@ -69,12 +53,9 @@ void oprofile_cpu_buffer_inc_smpl_lost(vvoid free_cpu_buffers (void ) { -if (op_ring_buffer_read) -ring_buffer_free (op_ring_buffer_read); - op_ring_buffer_read =NULL ; -if (op_ring_buffer_write) -ring_buffer_free (op_ring_buffer_write); - op_ring_buffer_write =NULL ; +if (op_ring_buffer) +ring_buffer_free (op_ring_buffer); + op_ring_buffer =NULL ; }#define RB_EVENT_HDR_SIZE 4
@@ -87,11 +68,8 @@ int alloc_cpu_buffers(void)unsigned long byte_size = buffer_size * (sizeof (struct op_sample ) +RB_EVENT_HDR_SIZE ); - op_ring_buffer_read =ring_buffer_alloc (byte_size,OP_BUFFER_FLAGS ); -if (!op_ring_buffer_read) - goto fail; - op_ring_buffer_write =ring_buffer_alloc (byte_size,OP_BUFFER_FLAGS ); -if (!op_ring_buffer_write) + op_ring_buffer =ring_buffer_alloc (byte_size,OP_BUFFER_FLAGS ); +if (!op_ring_buffer) goto fail;for_each_possible_cpu (i) {
@@ -163,16 +141,11 @@ struct op_sample *op_cpu_buffer_write_reserve(struct op_entry *entry, unsigned long size) { entry->event =ring_buffer_lock_reserve - (op_ring_buffer_write,sizeof (struct op_sample ) + + (op_ring_buffer,sizeof (struct op_sample ) + size *sizeof (entry->sample->data[0 ])); -if (entry->event) - entry->sample =ring_buffer_event_data (entry->event); -else - entry->sample =NULL ; - -if (!entry->sample) +if (!entry->event)return NULL ; - + entry->sample =ring_buffer_event_data (entry->event); entry->size = size; entry->data = entry->sample->data;
@@ -181,25 +154,16 @@ struct op_sampleint op_cpu_buffer_write_commit (struct op_entry *entry) { -return ring_buffer_unlock_commit (op_ring_buffer_write, entry->event); +return ring_buffer_unlock_commit (op_ring_buffer, entry->event); }struct op_sample *op_cpu_buffer_read_entry (struct op_entry *entry,int cpu) {struct ring_buffer_event *e; - e =ring_buffer_consume (op_ring_buffer_read, cpu,NULL ); -if (e) - goto event; -if (ring_buffer_swap_cpu (op_ring_buffer_read, - op_ring_buffer_write, - cpu)) + e =ring_buffer_consume (op_ring_buffer, cpu,NULL ); +if (!e)return NULL ; - e =ring_buffer_consume (op_ring_buffer_read, cpu,NULL ); -if (e) - goto event; -return NULL ; -event: entry->event = e; entry->sample =ring_buffer_event_data (e); entry->size = (ring_buffer_event_length (e) -sizeof (struct op_sample ))
@@ -210,8 +174,7 @@ event:unsigned long op_cpu_buffer_entries (int cpu) { -return ring_buffer_entries_cpu (op_ring_buffer_read, cpu) - +ring_buffer_entries_cpu (op_ring_buffer_write, cpu); +return ring_buffer_entries_cpu (op_ring_buffer, cpu); } static int
PATCH 3/149 cpumask: fix compat getaffinity
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: KOSAKI Motohiro <[email protected]>
commit fa9dc265ace9774e62f0e31108e5f47911124bda upstream.
Commit a45185d2d "cpumask: convert kernel/compat.c" broke libnuma, which abuses sched_getaffinity to find out NR_CPUS in order to parse /sys/devices/system/node/node*/cpumap.
On NUMA systems with less than 32 possibly CPUs, the current compat_sys_sched_getaffinity now returns '4' instead of the actual NR_CPUS/8, which makes libnuma bail out when parsing the cpumap.
The libnuma call sched_getaffinity(0, bitmap, 4096) at first. It mean the libnuma expect the return value of sched_getaffinity() is either len argument or NR_CPUS. But it doesn't expect to return nr_cpu_ids.
Strictly speaking, userland requirement are
1) Glibc assume the return value mean the lengh of initialized of mask argument. E.g. if sched_getaffinity(1024) return 128, glibc make zero fill rest 896 byte.
2) Libnuma assume the return value can be used to guess NR_CPUS in kernel. It assume len-arg<NR_CPUS makes -EINVAL. But it try len=4096 at first and 4096 is always bigger than NR_CPUS. Then, if we remove strange min_length normalization, we never hit -EINVAL case.
sched_getaffinity() already solved this issue. This patch adapts compat_sys_sched_getaffinity() to match the non-compat case.
--- kernel/compat.c | 25 +++++++++++-------------- 1 file changed, 11 insertions(+), 14 deletions(-)
kernel/compat.c +11 -14
@@ -494,29 +494,26 @@ asmlinkage long compat_sys_sched_getaffi {int ret;cpumask_var_t mask; -unsigned long *k; -unsigned int min_length =cpumask_size (); -if (nr_cpu_ids <=BITS_PER_COMPAT_LONG ) - min_length =sizeof (compat_ulong_t); - -if (len < min_length) +if ((len *BITS_PER_BYTE ) < nr_cpu_ids) +return -EINVAL ; +if (len & (sizeof (compat_ulong_t)-1 ))return -EINVAL ;if (!alloc_cpumask_var (&mask,GFP_KERNEL ))return -ENOMEM ; ret =sched_getaffinity (pid, mask); -if (ret <0 ) - goto out; +if (ret ==0 ) { +size_t retlen =min_t (size_t, len,cpumask_size ()); - k =cpumask_bits (mask); - ret =compat_put_bitmap (user_mask_ptr, k, min_length *8 ); -if (ret ==0 ) - ret = min_length; - -out: +if (compat_put_bitmap (user_mask_ptr,cpumask_bits (mask), retlen *8 )) + ret = -EFAULT ; +else + ret = retlen; + }free_cpumask_var (mask); +return ret; }
PATCH 4/149 NFSD: dont report compiled-out versions as present
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Pavel Emelyanov <[email protected]>
commit 15ddb4aec54422ead137b03ea4e9b3f5db3f7cc2 upstream.
The /proc/fs/nfsd/versions file calls nfsd_vers() to check whether the particular nfsd version is present/available. The problem is that once I turn off e.g. NFSD-V4 this call returns -1 which is true from the callers POV which is wrong.
The proposal is to report false in that case.
The bug has existed since 6658d3a7bbfd1768 "[PATCH] knfsd: remove nfsd_versbits as intermediate storage for desired versions".
--- fs/nfsd/nfssvc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/nfsd/nfssvc.c +1 -1
@@ -136,7 +136,7 @@ u32 nfsd_supported_minorversion;int nfsd_vers (int vers,enum vers_op change) {if (vers <NFSD_MINVERS || vers >=NFSD_NRVERS ) -return -1 ; +return 0 ;switch (change) {case NFSD_SET : nfsd_versions[vers] = nfsd_version[vers];
PATCH 5/149 sata_nv: use ata_pci_sff_activate_host() instead of ata_host_activate()
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Tejun Heo <[email protected]>
commit 95cc2c70c139936a2142bcd583da8af6f9d88efb upstream.
sata_nv was incorrectly using ata_host_activate() instead of ata_pci_sff_activate_host() leading to IRQ assignment failure in legacy mode. Fix it.
--- drivers/ata/sata_nv.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/ata/sata_nv.c +1 -2
@@ -2478,8 +2478,7 @@ static int nv_init_one(struct pci_dev *p }pci_set_master (pdev); -return ata_host_activate (host, pdev->irq, ipriv->irq_handler, -IRQF_SHARED , ipriv->sht); +return ata_pci_sff_activate_host (host, ipriv->irq_handler, ipriv->sht); }#ifdef CONFIG_PM
PATCH 6/149 ARCNET: Limit com20020 PCI ID matches for SOHARD cards
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Andreas Bombe <[email protected]>
commit e7971c80a8e0299f91272ad8e8ac4167623e1862 upstream.
The SH SOHARD ARCNET cards are implemented using generic PLX Technology PCI<->IOBus bridges. Subvendor and subdevice IDs were not specified, causing the driver to attach to any such bridge and likely crash the system by attempting to initialize an unrelated device.
Fix by specifying subvendor and subdevice according to the values found in the PCI-ID Repository at http://pci-ids.ucw.cz/ .
--- drivers/net/arcnet/com20020-pci.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/net/arcnet/com20020-pci.c +2 -2
@@ -165,8 +165,8 @@ static struct pci_device_id com20020pci_ { 0x1571, 0xa204, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ARC_CAN_10MBIT }, { 0x1571, 0xa205, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ARC_CAN_10MBIT }, { 0x1571, 0xa206, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ARC_CAN_10MBIT }, - { 0x10B5, 0x9030, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ARC_CAN_10MBIT }, - { 0x10B5, 0x9050, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ARC_CAN_10MBIT }, + { 0x10B5, 0x9030, 0x10B5, 0x2978, 0, 0, ARC_CAN_10MBIT }, + { 0x10B5, 0x9050, 0x10B5, 0x2273, 0, 0, ARC_CAN_10MBIT }, { 0x14BA, 0x6000, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ARC_CAN_10MBIT }, { 0x10B5, 0x2200, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ARC_CAN_10MBIT }, {0,}
PATCH 7/149 rtl8180: fix tx status reporting
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: John W. Linville <[email protected]>
commit d989ff7cf8d14f1b523f63ba0bf2ec1a9b7c25bc upstream.
When reporting Tx status, indicate that only one rate was used. Otherwise, the rate is frozen at rate index 0 (i.e. 1Mb/s).
--- drivers/net/wireless/rtl818x/rtl8180_dev.c | 1 + 1 file changed, 1 insertion(+)
drivers/net/wireless/rtl818x/rtl8180_dev.c +1 -0
@@ -190,6 +190,7 @@ static void rtl8180_handle_tx(struct iee info->flags |=IEEE80211_TX_STAT_ACK ; info->status.rates[0 ].count = (flags &0xFF ) +1 ; + info->status.rates[1 ].idx =-1 ;ieee80211_tx_status_irqsafe (dev, skb);if (ring->entries -skb_queue_len (&ring->queue) ==2 )
PATCH 8/149 Staging: add Add Sitecom WL-349 to rtl8192su
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Rodrigo Linfati <[email protected]>
commit 64a5a09218626464be35e0229d85b2ab0fcf03fd upstream.
Add usb id of Sitecom WL-349 to rtl8192su
--- drivers/staging/rtl8192su/r8192U_core.c | 1 + 1 file changed, 1 insertion(+)
drivers/staging/rtl8192su/r8192U_core.c +1 -0
@@ -120,6 +120,7 @@ static struct usb_device_id rtl8192_usb_ {USB_DEVICE(0x050d, 0x805E)},/* Sitecom */ {USB_DEVICE(0x0df6, 0x0031)}, + {USB_DEVICE(0x0df6, 0x004b)}, /* WL-349 *//* EnGenius */ {USB_DEVICE(0x1740, 0x9201)},/* Dlink */
PATCH 9/149 staging: vt6655: Fix kernel BUG on driver wpa initialization
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Larry Finger <[email protected]>
commit f65515275ea3e45fdcd0fb78455f542d6fdca086 upstream.
In http://bugzilla.novell.com/show_bug.cgi?id=597299, the vt6655 driver generates a kernel BUG on a NULL pointer dereference at NULL. This problem has been traced to a failure in the wpa_set_wpadev() routine. As the vt6656 driver does not call this routine, the vt6655 code is similarly set to skip the call.
--- drivers/staging/vt6655/device_main.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/staging/vt6655/device_main.c +2 -0
@@ -1089,11 +1089,13 @@ device_found1(struct pci_dev *pcid, cons }//2008-07-21-01<Add>by MikeLiu //register wpadev +#if 0 if (wpa_set_wpadev (pDevice,1 )!=0 ) {printk ("Fail to Register WPADEV?\n" );unregister_netdev (pDevice->dev);free_netdev (dev); } +#endif device_print_info (pDevice);pci_set_drvdata (pcid, pDevice);return 0 ;
PATCH 10/149 Fix racy use of anon_inode_getfd() in perf_event.c
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Al Viro <[email protected]>
commit ea635c64e007061f6468ece5cc9cc62d41d4ecf2 upstream.
once anon_inode_getfd() is called, you can't expect *anything* about struct file that descriptor points to - another thread might be doing whatever it likes with descriptor table at that point.
--- kernel/perf_event.c | 40 ++++++++++++++++++++++------------------ 1 file changed, 22 insertions(+), 18 deletions(-)
kernel/perf_event.c +22 -18
@@ -4510,8 +4510,8 @@ SYSCALL_DEFINE5(perf_event_open,struct perf_event_context *ctx;struct file *event_file =NULL ;struct file *group_file =NULL ; +int event_fd;int fput_needed =0 ; -int fput_needed2 =0 ;int err;/* for future expandability... */
@@ -4532,12 +4532,18 @@ SYSCALL_DEFINE5(perf_event_open,return -EINVAL ; } + event_fd =get_unused_fd_flags (O_RDWR ); +if (event_fd <0 ) +return event_fd; +/* * Get the target context (task or percpu): */ ctx =find_get_context (pid, cpu); -if (IS_ERR (ctx)) -return PTR_ERR (ctx); +if (IS_ERR (ctx)) { + err =PTR_ERR (ctx); + goto err_fd; + }/* * Look up the group leader (we will attach this event to it):
@@ -4577,13 +4583,11 @@ SYSCALL_DEFINE5(perf_event_open,if (IS_ERR (event)) goto err_put_context; - err =anon_inode_getfd ("[perf_event]" , &perf_fops, event,0 ); -if (err <0 ) - goto err_free_put_context; - - event_file =fget_light (err, &fput_needed2); -if (!event_file) + event_file =anon_inode_getfile ("[perf_event]" , &perf_fops, event,O_RDWR ); +if (IS_ERR (event_file)) { + err =PTR_ERR (event_file); goto err_free_put_context; + }if (flags &PERF_FLAG_FD_OUTPUT ) { err =perf_event_set_output (event, group_fd);
@@ -4604,19 +4608,19 @@ SYSCALL_DEFINE5(perf_event_open,list_add_tail (&event->owner_entry, ¤t->perf_event_list);mutex_unlock (¤t->perf_event_mutex); -err_fput_free_put_context: -fput_light (event_file, fput_needed2); +fput_light (group_file, fput_needed); +fd_install (event_fd, event_file); +return event_fd; +err_fput_free_put_context: +fput (event_file); err_free_put_context: -if (err <0 ) -free_event (event); - +free_event (event); err_put_context: -if (err <0 ) -put_ctx (ctx); -fput_light (group_file, fput_needed); - +put_ctx (ctx); +err_fd: +put_unused_fd (event_fd);return err; }
PATCH 11/149 posix_timer: Fix error path in timer_create
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Andrey Vagin <[email protected]>
commit 45e0fffc8a7778282e6a1514a6ae3e7ae6545111 upstream.
Move CLOCK_DISPATCH(which_clock, timer_create, (new_timer)) after all posible EFAULT erros.
*_timer_create may allocate/get resources.
(for example posix_cpu_timer_create does get_task_struct)
[ tglx: fold the remove crappy comment patch into this ]
kernel/posix-timers.c +4 -7
@@ -559,14 +559,7 @@ SYSCALL_DEFINE3(timer_create, const clockid_t, which_clock, new_timer->it_id = (timer_t ) new_timer_id; new_timer->it_clock = which_clock; new_timer->it_overrun =-1 ; - error =CLOCK_DISPATCH (which_clock, timer_create, (new_timer)); -if (error) - goto out; -/* -* return the timer_id now. The next step is hard to -* back out if there is an error. -*/ if (copy_to_user (created_timer_id, &new_timer_id,sizeof (new_timer_id))) { error = -EFAULT ;
@@ -597,6 +590,10 @@ SYSCALL_DEFINE3(timer_create, const clockid_t, which_clock, new_timer->sigq->info.si_tid = new_timer->it_id; new_timer->sigq->info.si_code =SI_TIMER ; + error =CLOCK_DISPATCH (which_clock, timer_create, (new_timer)); +if (error) + goto out; +spin_lock_irq (¤t->sighand->siglock); new_timer->it_signal = current->signal;list_add (&new_timer->list, ¤t->signal->posix_timers);
PATCH 12/149 libata: disable ATAPI AN by default
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Tejun Heo <[email protected]>
commit e7ecd435692ca9bde9d124be30b3a26e672ea6c2 upstream.
There are ATAPI devices which raise AN when hit by commands issued by open(). This leads to infinite loop of AN -> MEDIA_CHANGE uevent -> udev open() to check media -> AN.
Both ACS and SerialATA standards don't define in which case ATAPI devices are supposed to raise or not raise AN. They both list media insertion event as a possible use case for ATAPI ANs but there is no clear description of what constitutes such events. As such, it seems a bit too naive to export ANs directly to userland as MEDIA_CHANGE events without further verification (which should behave similarly to windows as it apparently is the only thing that some hardware vendors are testing against).
This patch adds libata.atapi_an module parameter and disables ATAPI AN by default for now.
--- drivers/ata/libata-core.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
drivers/ata/libata-core.c +6 -1
@@ -159,6 +159,10 @@ int libata_allow_tpm = 0;module_param_named (allow_tpm, libata_allow_tpm, int,0444 );MODULE_PARM_DESC (allow_tpm,"Permit the use of TPM commands (0=off [default], 1=on)" ); +static int atapi_an; +module_param (atapi_an, int,0444 ); +MODULE_PARM_DESC (atapi_an,"Enable ATAPI AN media presence notification (0=0ff [default], 1=on)" ); +MODULE_AUTHOR ("Jeff Garzik" );MODULE_DESCRIPTION ("Library module for ATA devices" );MODULE_LICENSE ("GPL" );
@@ -2570,7 +2574,8 @@ int ata_dev_configure(struct ata_device* to enable ATAPI AN to discern between PHY status * changed notifications and ATAPI ANs. */ -if ((ap->flags &ATA_FLAG_AN ) &&ata_id_has_atapi_AN (id) && +if (atapi_an && + (ap->flags &ATA_FLAG_AN ) &&ata_id_has_atapi_AN (id) && (!sata_pmp_attached (ap) ||sata_scr_read (&ap->link,SCR_NOTIFICATION , &sntf) ==0 )) {unsigned int err_mask;
PATCH 13/149 libata: dont flush dcache on slab pages
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Sebastian Andrzej Siewior <[email protected]>
commit 3842e835490cdf17013b30a788f6311bdcfd0571 upstream.
page_mapping() check this via VM_BUG_ON(PageSlab(page)) so we bug here with the according debuging turned on.
Future TODO: replace this with a flush_dcache_page_for_pio() API
--- drivers/ata/libata-sff.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/ata/libata-sff.c +1 -1
@@ -893,7 +893,7 @@ static void ata_pio_sector(struct ata_qu do_write); } -if (!do_write) +if (!do_write && !PageSlab (page))flush_dcache_page (page); qc->curbytes += qc->sect_size;
PATCH 14/149 mutex: Fix optimistic spinning vs. BKL
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Tony Breeds <[email protected]>
commit fd6be105b883244127a734ac9f14ae94a022dcc0 upstream.
Currently, we can hit a nasty case with optimistic spinning on mutexes:
CPU A tries to take a mutex, while holding the BKL
CPU B tried to take the BLK while holding the mutex
This looks like a AB-BA scenario but in practice, is allowed and happens due to the auto-release on schedule() nature of the BKL.
In that case, the optimistic spinning code can get us into a situation where instead of going to sleep, A will spin waiting for B who is spinning waiting for A, and the only way out of that loop is the need_resched() test in mutex_spin_on_owner().
This patch fixes it by completely disabling spinning if we own the BKL. This adds one more detail to the extensive list of reasons why it's a bad idea for kernel code to be holding the BKL.
LKML-Reference: <[email protected]>
--- kernel/mutex.c | 7 +++++++ 1 file changed, 7 insertions(+)
kernel/mutex.c +7 -0
@@ -172,6 +172,13 @@ __mutex_lock_common(struct mutex *lock,struct thread_info *owner;/* +* If we own the BKL, then don't spin. The owner of +* the mutex might be waiting on us to release the BKL. +*/ +if (unlikely (current->lock_depth >=0 )) +break ; + +/* * If there's an owner, wait for it to either * release the lock or go to sleep. */
PATCH 15/149 ALSA: hda: Fix model quirk for Dell M1730
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Daniel T Chen <[email protected]>
commit 66668b6fb6861fad7f6bfef6646ac84693474c9a upstream.
Symptom: Currently (2.6.32.12) the Dell M1730 uses the 3stack model quirk. Unfortunately this means that capture is not functional out- of-the-box despite ensuring that capture settings are unmuted and raised fully.
Test case: boot from Ubuntu 10.04 LTS live cd; capture does not work.
Resolution: Correct the model quirk for Dell M1730 to rely on the BIOS configuration.
This patch also trivially sorts the quirk into the correct section based on the comments.
--- sound/pci/hda/patch_sigmatel.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
sound/pci/hda/patch_sigmatel.c +1 -1
@@ -2059,12 +2059,12 @@ static struct snd_pci_quirk stac927x_cfgSND_PCI_QUIRK_MASK (PCI_VENDOR_ID_INTEL ,0xff00 ,0x2000 ,"Intel D965" ,STAC_D965_3ST ),/* Dell 3 stack systems */ -SND_PCI_QUIRK (PCI_VENDOR_ID_DELL ,0x01f7 ,"Dell XPS M1730" ,STAC_DELL_3ST ),SND_PCI_QUIRK (PCI_VENDOR_ID_DELL ,0x01dd ,"Dell Dimension E520" ,STAC_DELL_3ST ),SND_PCI_QUIRK (PCI_VENDOR_ID_DELL ,0x01ed ,"Dell " ,STAC_DELL_3ST ),SND_PCI_QUIRK (PCI_VENDOR_ID_DELL ,0x01f4 ,"Dell " ,STAC_DELL_3ST ),/* Dell 3 stack systems with verb table in BIOS */ SND_PCI_QUIRK (PCI_VENDOR_ID_DELL ,0x01f3 ,"Dell Inspiron 1420" ,STAC_DELL_BIOS ), +SND_PCI_QUIRK (PCI_VENDOR_ID_DELL ,0x01f7 ,"Dell XPS M1730" ,STAC_DELL_BIOS ),SND_PCI_QUIRK (PCI_VENDOR_ID_DELL ,0x0227 ,"Dell Vostro 1400 " ,STAC_DELL_BIOS ),SND_PCI_QUIRK (PCI_VENDOR_ID_DELL ,0x022e ,"Dell " ,STAC_DELL_BIOS ), SND_PCI_QUIRK(PCI_VENDOR_ID_DELL, 0x022f, "Dell Inspiron 1525", STAC_DELL_BIOS),
PATCH 16/149 ALSA: hda: Use LPIB for Toshiba A100-259
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Daniel T Chen <[email protected]>
commit 4e0938dba7fccf37a4aecba4d937da7f312b5d55 upstream.
Symptom: on a significant number of hardware, booting from a live cd results in capture working correctly, but once the distribution is installed, booting from the install results in capture not working.
Test case: boot from Ubuntu 10.04 LTS live cd; capture works correctly. Install to HD and reboot; capture does not work. Reproduced with 2.6.32 mainline build (vanilla kernel.org compile)
Resolution: add SSID for Toshiba A100-259 to the position_fix quirk table, explicitly specifying the LPIB method.
I'll be sending additional patches for these SSIDs as bug reports are confirmed.
This patch also trivially sorts the quirk table in ascending order by subsystem vendor.
--- sound/pci/hda/hda_intel.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
sound/pci/hda/hda_intel.c +3 -2
@@ -2229,9 +2229,10 @@ static struct snd_pci_quirk position_fixSND_PCI_QUIRK (0x1028 ,0x01cc ,"Dell D820" ,POS_FIX_LPIB ),SND_PCI_QUIRK (0x1028 ,0x01de ,"Dell Precision 390" ,POS_FIX_LPIB ),SND_PCI_QUIRK (0x103c ,0x306d ,"HP dv3" ,POS_FIX_LPIB ), -SND_PCI_QUIRK (0x1106 ,0x3288 ,"ASUS M2V-MX SE" ,POS_FIX_LPIB ), -SND_PCI_QUIRK (0x1043 ,0x813d ,"ASUS P5AD2" ,POS_FIX_LPIB ),SND_PCI_QUIRK (0x1028 ,0x01f6 ,"Dell Latitude 131L" ,POS_FIX_LPIB ), +SND_PCI_QUIRK (0x1043 ,0x813d ,"ASUS P5AD2" ,POS_FIX_LPIB ), +SND_PCI_QUIRK (0x1106 ,0x3288 ,"ASUS M2V-MX SE" ,POS_FIX_LPIB ), +SND_PCI_QUIRK (0x1179 ,0xff10 ,"Toshiba A100-259" ,POS_FIX_LPIB ),SND_PCI_QUIRK (0x1458 ,0xa022 ,"ga-ma770-ud3" ,POS_FIX_LPIB ),SND_PCI_QUIRK (0x1462 ,0x1002 ,"MSI Wind U115" ,POS_FIX_LPIB ), SND_PCI_QUIRK(0x1565, 0x820f, "Biostar Microtech", POS_FIX_LPIB),
PATCH 17/149 ALSA: hda: Use LPIB for Acer Aspire 5110
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Daniel T Chen <[email protected]>
commit 7a68be94e22e7643038726ebc14360752a91800b upstream.
Symptom: on a significant number of hardware, booting from a live cd results in capture working correctly, but once the distribution is installed, booting from the install results in capture not working.
Test case: boot from Ubuntu 10.04 LTS live cd; capture works correctly. Install to HD and reboot; capture does not work. Reproduced with 2.6.32 mainline build (vanilla kernel.org compile).
Resolution: add SSID for Acer Aspire 5110 to the position_fix quirk table, explicitly specifying the LPIB method.
I'll be sending additional patches for these SSIDs as bug reports are confirmed.
--- sound/pci/hda/hda_intel.c | 1 + 1 file changed, 1 insertion(+)
sound/pci/hda/hda_intel.c +1 -0
@@ -2226,6 +2226,7 @@ static int azx_dev_free(struct snd_devic* white/black-listing for position_fix */ static struct snd_pci_quirk position_fix_list[]__devinitdata = { +SND_PCI_QUIRK (0x1025 ,0x009f ,"Acer Aspire 5110" ,POS_FIX_LPIB ),SND_PCI_QUIRK (0x1028 ,0x01cc ,"Dell D820" ,POS_FIX_LPIB ),SND_PCI_QUIRK (0x1028 ,0x01de ,"Dell Precision 390" ,POS_FIX_LPIB ),SND_PCI_QUIRK (0x103c ,0x306d ,"HP dv3" ,POS_FIX_LPIB ),
PATCH 18/149 ALSA: hda: Use LPIB for Sony VPCS11V9E
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Daniel T Chen <[email protected]>
commit e96d3127760a2fc509bca6bf7e61e8bc61497aeb upstream.
Symptom: On the Sony VPCS11V9E, using GStreamer-based applications with PulseAudio in Ubuntu 10.04 LTS results in stuttering audio. It appears to worsen with increased I/O.
Test case: use Rhythmbox under increased I/O pressure. This symptom is reproducible in the current daily stable alsa-driver snapshots (at least up until 21 May 2010; later snapshots fail to build from source due to missing preprocessor directives when compiled against 2.6.32).
Resolution: add SSID for this machine to the position_fix quirk table, explicitly specifying the LPIB method.
--- sound/pci/hda/hda_intel.c | 1 + 1 file changed, 1 insertion(+)
sound/pci/hda/hda_intel.c +1 -0
@@ -2232,6 +2232,7 @@ static struct snd_pci_quirk position_fixSND_PCI_QUIRK (0x103c ,0x306d ,"HP dv3" ,POS_FIX_LPIB ),SND_PCI_QUIRK (0x1028 ,0x01f6 ,"Dell Latitude 131L" ,POS_FIX_LPIB ),SND_PCI_QUIRK (0x1043 ,0x813d ,"ASUS P5AD2" ,POS_FIX_LPIB ), +SND_PCI_QUIRK (0x104d ,0x9069 ,"Sony VPCS11V9E" ,POS_FIX_LPIB ),SND_PCI_QUIRK (0x1106 ,0x3288 ,"ASUS M2V-MX SE" ,POS_FIX_LPIB ),SND_PCI_QUIRK (0x1179 ,0xff10 ,"Toshiba A100-259" ,POS_FIX_LPIB ), SND_PCI_QUIRK(0x1458, 0xa022, "ga-ma770-ud3", POS_FIX_LPIB),
PATCH 19/149 ALSA: hda: Use LPIB for a Shuttle device
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Daniel T Chen <[email protected]>
commit 61bb42c37dfa9016dcacc86bcd41362ab2457d4a upstream.
Symptom: On the reporter's Shuttle device, using PulseAudio in Ubuntu 10.04 LTS results in "popping clicking" audio with the PA crashing shortly thereafter.
Test case: Using Ubuntu 10.04 LTS (Linux 2.6.32.12), Linux 2.6.33, or Linux 2.6.34, adjust the HDA device's volume with PulseAudio.
Resolution: add SSID for this machine to the position_fix quirk table, explicitly specifying the LPIB method.
--- sound/pci/hda/hda_intel.c | 1 + 1 file changed, 1 insertion(+)
sound/pci/hda/hda_intel.c +1 -0
@@ -2235,6 +2235,7 @@ static struct snd_pci_quirk position_fixSND_PCI_QUIRK (0x104d ,0x9069 ,"Sony VPCS11V9E" ,POS_FIX_LPIB ),SND_PCI_QUIRK (0x1106 ,0x3288 ,"ASUS M2V-MX SE" ,POS_FIX_LPIB ),SND_PCI_QUIRK (0x1179 ,0xff10 ,"Toshiba A100-259" ,POS_FIX_LPIB ), +SND_PCI_QUIRK (0x1297 ,0x3166 ,"Shuttle" ,POS_FIX_LPIB ),SND_PCI_QUIRK (0x1458 ,0xa022 ,"ga-ma770-ud3" ,POS_FIX_LPIB ),SND_PCI_QUIRK (0x1462 ,0x1002 ,"MSI Wind U115" ,POS_FIX_LPIB ), SND_PCI_QUIRK(0x1565, 0x820f, "Biostar Microtech", POS_FIX_LPIB),
PATCH 20/149 ACPI: video: fix acpi_backlight=video
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Kamal Mostafa <[email protected]>
commit eeb4bcb4771679d7b3446c0293334faee11b090a upstream.
Make "acpi_backlight=video" param enable ACPI_VIDEO_BACKLIGHT_FORCE_VIDEO as intended, instead of incorrectly enabling video output switching.
--- drivers/acpi/video_detect.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/acpi/video_detect.c +1 -1
@@ -250,7 +250,7 @@ static int __init acpi_backlight(char *sACPI_VIDEO_BACKLIGHT_FORCE_VENDOR ;if (!strcmp ("video" , str)) acpi_video_support |= -ACPI_VIDEO_OUTPUT_SWITCHING_FORCE_VIDEO ; +ACPI_VIDEO_BACKLIGHT_FORCE_VIDEO ; }return 1 ; }
PATCH 21/149 V4L/DVB: gspca - stv06xx: Remove the 046d:08da from the stv06xx driver
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Erik Andrén <[email protected]>
commit 55e0b489a39bb635a44f769d620e44c70d9c065b upstream.
The 046d:08da usb id shouldn't be associated with the stv06xx driver as they're not compatible with each other.
This fixes a bug where Quickcam Messenger cams fail to use its proper driver (gspca-zc3xx), rendering the camera inoperable.
--- drivers/media/video/gspca/stv06xx/stv06xx.c | 2 -- 1 file changed, 2 deletions(-)
drivers/media/video/gspca/stv06xx/stv06xx.c +0 -2
@@ -497,8 +497,6 @@ static const __devinitdata struct usb_de {USB_DEVICE(0x046D, 0x08F5), .driver_info = BRIDGE_ST6422 }, /* QuickCam Messenger (new) */ {USB_DEVICE(0x046D, 0x08F6), .driver_info = BRIDGE_ST6422 }, - /* QuickCam Messenger (new) */ - {USB_DEVICE(0x046D, 0x08DA), .driver_info = BRIDGE_ST6422 }, {} };MODULE_DEVICE_TABLE (usb, device_table);
PATCH 22/149 HID: Add the GYR4101US USB ID to hid-gyration
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Cory Maccarrone <[email protected]>
commit c2fd1a4ebf9127c280d227acb635eb1df213439c upstream.
This change adds in the USB product ID for the Gyration GYR4101US USB media center remote control. This remote is similar enough to the other two devices that this driver can be used without any other changes to get full support for the remote.
--- drivers/hid/hid-core.c | 1 + drivers/hid/hid-gyration.c | 1 + drivers/hid/hid-ids.h | 1 + 3 files changed, 3 insertions(+)
drivers/hid/hid-core.c +1 -0
@@ -1306,6 +1306,7 @@ static const struct hid_device_id hid_bl { HID_USB_DEVICE(USB_VENDOR_ID_GREENASIA, 0x0012) }, { HID_USB_DEVICE(USB_VENDOR_ID_GYRATION, USB_DEVICE_ID_GYRATION_REMOTE) }, { HID_USB_DEVICE(USB_VENDOR_ID_GYRATION, USB_DEVICE_ID_GYRATION_REMOTE_2) }, + { HID_USB_DEVICE(USB_VENDOR_ID_GYRATION, USB_DEVICE_ID_GYRATION_REMOTE_3) }, { HID_USB_DEVICE(USB_VENDOR_ID_KENSINGTON, USB_DEVICE_ID_KS_SLIMBLADE) }, { HID_USB_DEVICE(USB_VENDOR_ID_KYE, USB_DEVICE_ID_KYE_ERGO_525V) }, { HID_USB_DEVICE(USB_VENDOR_ID_LABTEC, USB_DEVICE_ID_LABTEC_WIRELESS_KEYBOARD) },
drivers/hid/hid-gyration.c +1 -0
@@ -73,6 +73,7 @@ static int gyration_event(struct hid_devstatic const struct hid_device_id gyration_devices[] = { {HID_USB_DEVICE (USB_VENDOR_ID_GYRATION ,USB_DEVICE_ID_GYRATION_REMOTE ) }, {HID_USB_DEVICE (USB_VENDOR_ID_GYRATION ,USB_DEVICE_ID_GYRATION_REMOTE_2 ) }, + {HID_USB_DEVICE (USB_VENDOR_ID_GYRATION ,USB_DEVICE_ID_GYRATION_REMOTE_3 ) }, { } };MODULE_DEVICE_TABLE (hid, gyration_devices);
drivers/hid/hid-ids.h +1 -0
@@ -251,6 +251,7 @@#define USB_VENDOR_ID_GYRATION 0x0c16#define USB_DEVICE_ID_GYRATION_REMOTE 0x0002#define USB_DEVICE_ID_GYRATION_REMOTE_2 0x0003 +#define USB_DEVICE_ID_GYRATION_REMOTE_3 0x0008#define USB_VENDOR_ID_HAPP 0x078b#define USB_DEVICE_ID_UGCI_DRIVING 0x0010
PATCH 23/149 ar9170usb: add a couple more USB IDs
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Christian Lamparter <[email protected]>
commit 94d0bbe849190255b93fede8eb46809a38f9b8bf upstream.
This patch adds the following 5 entries to the usbid device table:
* Netgear WNA1000
* Proxim ORiNOCO Dual Band 802.11n USB Adapter
* 3Com Dual Band 802.11n USB Adapter
* H3C Dual Band 802.11n USB Adapter
* WNC Generic 11n USB dongle
--- drivers/net/wireless/ath/ar9170/usb.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
drivers/net/wireless/ath/ar9170/usb.c +10 -0
@@ -66,18 +66,28 @@ static struct usb_device_id ar9170_usb_i { USB_DEVICE(0x0cf3, 0x1001) },/* TP-Link TL-WN821N v2 */ { USB_DEVICE(0x0cf3, 0x1002) }, +/* 3Com Dual Band 802.11n USB Adapter */ + { USB_DEVICE(0x0cf3, 0x1010) }, +/* H3C Dual Band 802.11n USB Adapter */ + { USB_DEVICE(0x0cf3, 0x1011) },/* Cace Airpcap NX */ { USB_DEVICE(0xcace, 0x0300) },/* D-Link DWA 160 A1 */ { USB_DEVICE(0x07d1, 0x3c10) },/* D-Link DWA 160 A2 */ { USB_DEVICE(0x07d1, 0x3a09) }, +/* Netgear WNA1000 */ + { USB_DEVICE(0x0846, 0x9040) },/* Netgear WNDA3100 */ { USB_DEVICE(0x0846, 0x9010) },/* Netgear WN111 v2 */ { USB_DEVICE(0x0846, 0x9001) },/* Zydas ZD1221 */ { USB_DEVICE(0x0ace, 0x1221) }, +/* Proxim ORiNOCO 802.11n USB */ + { USB_DEVICE(0x1435, 0x0804) }, +/* WNC Generic 11n USB Dongle */ + { USB_DEVICE(0x1435, 0x0326) },/* ZyXEL NWD271N */ { USB_DEVICE(0x0586, 0x3417) }, /* Z-Com UB81 BG */
PATCH 24/149 ar9170usb: fix panic triggered by undersized rxstream buffer
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Christian Lamparter <[email protected]>
commit 879999cec9489f8942ebce3ec1b5f23ef948dda7 upstream.
While ar9170's USB transport packet size is currently set to 8KiB, the PHY is capable of receiving AMPDUs with up to 64KiB. Such a large frame will be split over several rx URBs and exceed the previously allocated space for rx stream reconstruction.
This patch increases the buffer size to 64KiB which is in fact the phy & rx stream designed size limit.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=15591
--- drivers/net/wireless/ath/ar9170/hw.h | 1 + drivers/net/wireless/ath/ar9170/main.c | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-)
drivers/net/wireless/ath/ar9170/hw.h +1 -0
@@ -422,5 +422,6 @@ enum ar9170_txq {#define AR9170_TXQ_DEPTH 32#define AR9170_TX_MAX_PENDING 128 +#define AR9170_RX_STREAM_MAX_SIZE 65535#endif /* __AR9170_HW_H */
drivers/net/wireless/ath/ar9170/main.c +1 -1
@@ -2526,7 +2526,7 @@ void *ar9170_alloc(size_t priv_size)* tends to split the streams into seperate rx descriptors. */ - skb =__dev_alloc_skb (AR9170_MAX_RX_BUFFER_SIZE ,GFP_KERNEL ); + skb =__dev_alloc_skb (AR9170_RX_STREAM_MAX_SIZE ,GFP_KERNEL );if (!skb) goto err_nomem;
PATCH 25/149 USB: visor: fix memory leak
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Johan Hovold <[email protected]>
commit 199b113978015309dd02c69844c19a1be3f4dbcf upstream.
Fix memory leak for some devices (Sony Clie 3.5) due to port private data not being freed on release.
drivers/usb/serial/visor.c +1 -0
@@ -249,6 +249,7 @@ static struct usb_serial_driver clie_3_5_device = { .throttle = visor_throttle, .unthrottle = visor_unthrottle, .attach = clie_3_5_startup, + .release = visor_release, .write = visor_write, .write_room = visor_write_room, .write_bulk_callback = visor_write_bulk_callback,
PATCH 26/149 USB: CP210x New Device IDs 11 New device IDs
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Craig Shelley <[email protected]>
commit eefd9029fde4d90d59804eeb54880ab8db5c1866 upstream.
--- drivers/usb/serial/cp210x.c | 11 +++++++++++ 1 file changed, 11 insertions(+)
drivers/usb/serial/cp210x.c +11 -0
@@ -61,6 +61,8 @@ static struct usb_device_id id_table [] { USB_DEVICE(0x0745, 0x1000) }, /* CipherLab USB CCD Barcode Scanner 1000 */ { USB_DEVICE(0x08e6, 0x5501) }, /* Gemalto Prox-PU/CU contactless smartcard reader */ { USB_DEVICE(0x08FD, 0x000A) }, /* Digianswer A/S , ZigBee/802.15.4 MAC Device */ + { USB_DEVICE(0x0BED, 0x1100) }, /* MEI (TM) Cashflow-SC Bill/Voucher Acceptor */ + { USB_DEVICE(0x0BED, 0x1101) }, /* MEI series 2000 Combo Acceptor */ { USB_DEVICE(0x0FCF, 0x1003) }, /* Dynastream ANT development board */ { USB_DEVICE(0x0FCF, 0x1004) }, /* Dynastream ANT2USB */ { USB_DEVICE(0x0FCF, 0x1006) }, /* Dynastream ANT development board */
@@ -72,9 +74,12 @@ static struct usb_device_id id_table [] { USB_DEVICE(0x10C4, 0x1601) }, /* Arkham Technology DS101 Adapter */ { USB_DEVICE(0x10C4, 0x800A) }, /* SPORTident BSM7-D-USB main station */ { USB_DEVICE(0x10C4, 0x803B) }, /* Pololu USB-serial converter */ + { USB_DEVICE(0x10C4, 0x8044) }, /* Cygnal Debug Adapter */ + { USB_DEVICE(0x10C4, 0x804E) }, /* Software Bisque Paramount ME build-in converter */ { USB_DEVICE(0x10C4, 0x8053) }, /* Enfora EDG1228 */ { USB_DEVICE(0x10C4, 0x8054) }, /* Enfora GSM2228 */ { USB_DEVICE(0x10C4, 0x8066) }, /* Argussoft In-System Programmer */ + { USB_DEVICE(0x10C4, 0x806F) }, /* IMS USB to RS422 Converter Cable */ { USB_DEVICE(0x10C4, 0x807A) }, /* Crumb128 board */ { USB_DEVICE(0x10C4, 0x80CA) }, /* Degree Controls Inc */ { USB_DEVICE(0x10C4, 0x80DD) }, /* Tracient RFID */
@@ -82,12 +87,15 @@ static struct usb_device_id id_table [] { USB_DEVICE(0x10C4, 0x8115) }, /* Arygon NFC/Mifare Reader */ { USB_DEVICE(0x10C4, 0x813D) }, /* Burnside Telecom Deskmobile */ { USB_DEVICE(0x10C4, 0x813F) }, /* Tams Master Easy Control */ + { USB_DEVICE(0x10C4, 0x8149) }, /* West Mountain Radio Computerized Battery Analyzer */ { USB_DEVICE(0x10C4, 0x814A) }, /* West Mountain Radio RIGblaster P&P */ { USB_DEVICE(0x10C4, 0x814B) }, /* West Mountain Radio RIGtalk */ { USB_DEVICE(0x10C4, 0x815E) }, /* Helicomm IP-Link 1220-DVM */ + { USB_DEVICE(0x10C4, 0x818B) }, /* AVIT Research USB to TTL */ { USB_DEVICE(0x10C4, 0x819F) }, /* MJS USB Toslink Switcher */ { USB_DEVICE(0x10C4, 0x81A6) }, /* ThinkOptics WavIt */ { USB_DEVICE(0x10C4, 0x81AC) }, /* MSD Dash Hawk */ + { USB_DEVICE(0x10C4, 0x81AD) }, /* INSYS USB Modem */ { USB_DEVICE(0x10C4, 0x81C8) }, /* Lipowsky Industrie Elektronik GmbH, Baby-JTAG */ { USB_DEVICE(0x10C4, 0x81E2) }, /* Lipowsky Industrie Elektronik GmbH, Baby-LIN */ { USB_DEVICE(0x10C4, 0x81E7) }, /* Aerocomm Radio */
@@ -105,6 +113,7 @@ static struct usb_device_id id_table [] { USB_DEVICE(0x10C4, 0x846E) }, /* BEI USB Sensor Interface (VCP) */ { USB_DEVICE(0x10C4, 0xEA60) }, /* Silicon Labs factory default */ { USB_DEVICE(0x10C4, 0xEA61) }, /* Silicon Labs factory default */ + { USB_DEVICE(0x10C4, 0xEA71) }, /* Infinity GPS-MIC-1 Radio Monophone */ { USB_DEVICE(0x10C4, 0xF001) }, /* Elan Digital Systems USBscope50 */ { USB_DEVICE(0x10C4, 0xF002) }, /* Elan Digital Systems USBwave12 */ { USB_DEVICE(0x10C4, 0xF003) }, /* Elan Digital Systems USBpulse100 */
@@ -115,6 +124,8 @@ static struct usb_device_id id_table [] { USB_DEVICE(0x1555, 0x0004) }, /* Owen AC4 USB-RS485 Converter */ { USB_DEVICE(0x166A, 0x0303) }, /* Clipsal 5500PCU C-Bus USB interface */ { USB_DEVICE(0x16D6, 0x0001) }, /* Jablotron serial interface */ + { USB_DEVICE(0x17F4, 0xAAAA) }, /* Wavesense Jazz blood glucose meter */ + { USB_DEVICE(0x1843, 0x0200) }, /* Vaisala USB Instrument Cable */ { USB_DEVICE(0x18EF, 0xE00F) }, /* ELV USB-I2C-Interface */ { USB_DEVICE(0x413C, 0x9500) }, /* DW700 GPS USB interface */ { } /* Terminating Entry */
PATCH 27/149 USB: kobil: fix memory leak
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Johan Hovold <[email protected]>
commit c0f631d1948658b27349545b2cbcb4b32f010c7a upstream.
An urb transfer buffer is allocated at every open but was never freed.
This driver is a bit of a mess...
--- drivers/usb/serial/kobil_sct.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/usb/serial/kobil_sct.c +2 -1
@@ -345,7 +345,8 @@ static void kobil_close(struct usb_seria/* FIXME: Add rts/dtr methods */ if (port->write_urb) { -usb_kill_urb (port->write_urb); +usb_poison_urb (port->write_urb); +kfree (port->write_urb->transfer_buffer);usb_free_urb (port->write_urb); port->write_urb =NULL ; }
PATCH 28/149 USB: option: add PID for ZTE product
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: zhao1980ming <[email protected]>
commit a71ee85e1d74e862d68cc9b2f2ab6a806d2550c9 upstream.
this patch adds ZTE modem devices
--- drivers/usb/serial/option.c | 174 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 174 insertions(+)
drivers/usb/serial/option.c +174 -0
@@ -621,6 +621,180 @@ static struct usb_device_id option_ids[] { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0160, 0xff, 0xff, 0xff) }, { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0161, 0xff, 0xff, 0xff) }, { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0162, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1008, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1010, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1012, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1057, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1058, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1059, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1060, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1061, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1062, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1063, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1064, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1065, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1066, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1067, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1068, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1069, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1070, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1071, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1072, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1073, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1074, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1075, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1076, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1077, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1078, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1079, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1080, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1081, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1082, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1083, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1084, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1085, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1086, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1087, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1088, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1089, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1090, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1091, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1092, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1093, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1094, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1095, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1096, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1097, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1098, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1099, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1100, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1101, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1102, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1103, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1104, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1105, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1106, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1107, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1108, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1109, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1110, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1111, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1112, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1113, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1114, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1115, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1116, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1117, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1118, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1119, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1120, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1121, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1122, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1123, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1124, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1125, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1126, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1127, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1128, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1129, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1130, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1131, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1132, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1133, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1134, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1135, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1136, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1137, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1138, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1139, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1140, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1141, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1142, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1143, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1144, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1145, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1146, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1147, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1148, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1149, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1150, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1151, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1152, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1153, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1154, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1155, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1156, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1157, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1158, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1159, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1160, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1161, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1162, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1163, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1164, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1165, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1166, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1167, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1168, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1169, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1170, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1244, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1245, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1246, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1247, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1248, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1249, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1250, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1251, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1252, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1253, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1254, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1255, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1256, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1257, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1258, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1259, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1260, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1261, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1262, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1263, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1264, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1265, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1266, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1267, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1268, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1269, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1270, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1271, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1272, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1273, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1274, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1275, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1276, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1277, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1278, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1279, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1280, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1281, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1282, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1283, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1284, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1285, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1286, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1287, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1288, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1289, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1290, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1291, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1292, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1293, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1294, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1295, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1296, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1297, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1298, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1299, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1300, 0xff, 0xff, 0xff) }, { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0014, 0xff, 0xff, 0xff) }, /* ZTE CDMA products */ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0027, 0xff, 0xff, 0xff) }, { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0059, 0xff, 0xff, 0xff) },
PATCH 29/149 USB: option.c: Add Pirelli VID/PID and indicate Pirellis modem interface is 0xff
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: spark <[email protected]>
commit 33c387529b7931248c6637bf9720ac7504a0b28b upstream.
--- drivers/usb/serial/option.c | 43 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+)
drivers/usb/serial/option.c +43 -0
@@ -334,6 +334,24 @@ static int option_resume(struct usb_ser#define ALCATEL_VENDOR_ID 0x1bbb#define ALCATEL_PRODUCT_X060S 0x0000 +#define PIRELLI_VENDOR_ID 0x1266 +#define PIRELLI_PRODUCT_C100_1 0x1002 +#define PIRELLI_PRODUCT_C100_2 0x1003 +#define PIRELLI_PRODUCT_1004 0x1004 +#define PIRELLI_PRODUCT_1005 0x1005 +#define PIRELLI_PRODUCT_1006 0x1006 +#define PIRELLI_PRODUCT_1007 0x1007 +#define PIRELLI_PRODUCT_1008 0x1008 +#define PIRELLI_PRODUCT_1009 0x1009 +#define PIRELLI_PRODUCT_100A 0x100a +#define PIRELLI_PRODUCT_100B 0x100b +#define PIRELLI_PRODUCT_100C 0x100c +#define PIRELLI_PRODUCT_100D 0x100d +#define PIRELLI_PRODUCT_100E 0x100e +#define PIRELLI_PRODUCT_100F 0x100f +#define PIRELLI_PRODUCT_1011 0x1011 +#define PIRELLI_PRODUCT_1012 0x1012 +/* Airplus products */ #define AIRPLUS_VENDOR_ID 0x1011#define AIRPLUS_PRODUCT_MCD650 0x3198
@@ -823,6 +841,24 @@ static struct usb_device_id option_ids[] { USB_DEVICE(TLAYTECH_VENDOR_ID, TLAYTECH_PRODUCT_TEU800) }, { USB_DEVICE(FOUR_G_SYSTEMS_VENDOR_ID, FOUR_G_SYSTEMS_PRODUCT_W14) }, { USB_DEVICE(HAIER_VENDOR_ID, HAIER_PRODUCT_CE100) }, +/* Pirelli */ + { USB_DEVICE(PIRELLI_VENDOR_ID, PIRELLI_PRODUCT_C100_1)}, + { USB_DEVICE(PIRELLI_VENDOR_ID, PIRELLI_PRODUCT_C100_2)}, + { USB_DEVICE(PIRELLI_VENDOR_ID, PIRELLI_PRODUCT_1004)}, + { USB_DEVICE(PIRELLI_VENDOR_ID, PIRELLI_PRODUCT_1005)}, + { USB_DEVICE(PIRELLI_VENDOR_ID, PIRELLI_PRODUCT_1006)}, + { USB_DEVICE(PIRELLI_VENDOR_ID, PIRELLI_PRODUCT_1007)}, + { USB_DEVICE(PIRELLI_VENDOR_ID, PIRELLI_PRODUCT_1008)}, + { USB_DEVICE(PIRELLI_VENDOR_ID, PIRELLI_PRODUCT_1009)}, + { USB_DEVICE(PIRELLI_VENDOR_ID, PIRELLI_PRODUCT_100A)}, + { USB_DEVICE(PIRELLI_VENDOR_ID, PIRELLI_PRODUCT_100B) }, + { USB_DEVICE(PIRELLI_VENDOR_ID, PIRELLI_PRODUCT_100C) }, + { USB_DEVICE(PIRELLI_VENDOR_ID, PIRELLI_PRODUCT_100D) }, + { USB_DEVICE(PIRELLI_VENDOR_ID, PIRELLI_PRODUCT_100E) }, + { USB_DEVICE(PIRELLI_VENDOR_ID, PIRELLI_PRODUCT_100F) }, + { USB_DEVICE(PIRELLI_VENDOR_ID, PIRELLI_PRODUCT_1011)}, + { USB_DEVICE(PIRELLI_VENDOR_ID, PIRELLI_PRODUCT_1012)}, + { } /* Terminating entry */ };MODULE_DEVICE_TABLE (usb, option_ids);
@@ -945,12 +981,19 @@ static int option_probe(struct usb_seria const struct usb_device_id *id) {struct option_intf_private *data; +/* D-Link DWM 652 still exposes CD-Rom emulation interface in modem mode */ if (serial->dev->descriptor.idVendor ==DLINK_VENDOR_ID && serial->dev->descriptor.idProduct ==DLINK_PRODUCT_DWM_652 && serial->interface->cur_altsetting->desc.bInterfaceClass ==0x8 )return -ENODEV ; +/* Bandrich modem and AT command interface is 0xff */ +if ((serial->dev->descriptor.idVendor ==BANDRICH_VENDOR_ID || + serial->dev->descriptor.idVendor ==PIRELLI_VENDOR_ID ) && + serial->interface->cur_altsetting->desc.bInterfaceClass !=0xff ) +return -ENODEV ; + data = serial->private =kzalloc (sizeof (struct option_intf_private ),GFP_KERNEL );if (!data)return -ENOMEM ;
PATCH 30/149 USB: serial: option: add cinterion device id
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Greg Kroah-Hartman <[email protected]>
commit 6f44bcb60bfa58590142545096b64f44144f0bc1 upstream.
This adds a device id for a Cinterion device.
--- drivers/usb/serial/option.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/usb/serial/option.c +3 -0
@@ -364,6 +364,8 @@ static int option_resume(struct usb_ser#define HAIER_VENDOR_ID 0x201e#define HAIER_PRODUCT_CE100 0x2009 +#define CINTERION_VENDOR_ID 0x0681 +static struct usb_device_id option_ids[] = { {USB_DEVICE (OPTION_VENDOR_ID ,OPTION_PRODUCT_COLT ) }, {USB_DEVICE (OPTION_VENDOR_ID ,OPTION_PRODUCT_RICOLA ) },
@@ -859,6 +861,7 @@ static struct usb_device_id option_ids[] { USB_DEVICE(PIRELLI_VENDOR_ID, PIRELLI_PRODUCT_1011)}, { USB_DEVICE(PIRELLI_VENDOR_ID, PIRELLI_PRODUCT_1012)}, + { USB_DEVICE(CINTERION_VENDOR_ID, 0x0047) }, { } /* Terminating entry */ };MODULE_DEVICE_TABLE (usb, option_ids);
PATCH 31/149 USB: option.c: OLIVETTI OLICARD100 support
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Nils Radtke <[email protected]>
commit 86234d4975ce084d14711283a3bfc69305f97602 upstream.
This patch adds support for an olivetti olicard100 HЅDPA usb-stick.
This device is a zeroCD one with ID 0b3c:c700 that needs switching via eject or usb-modeswitch with MessageContent="5553424312345678000000000000061b000000030000000000000000000000". After switching it has ID 0b3c:c000 and provides 5 serial ports ttyUSB[0-4]. Port 0 (modem) and 4 are interrupt ports.
--- drivers/usb/serial/option.c | 6 ++++++ 1 file changed, 6 insertions(+)
drivers/usb/serial/option.c +6 -0
@@ -366,6 +366,10 @@ static int option_resume(struct usb_ser#define CINTERION_VENDOR_ID 0x0681 +/* Olivetti products */ +#define OLIVETTI_VENDOR_ID 0x0b3c +#define OLIVETTI_PRODUCT_OLICARD100 0xc000 +static struct usb_device_id option_ids[] = { {USB_DEVICE (OPTION_VENDOR_ID ,OPTION_PRODUCT_COLT ) }, {USB_DEVICE (OPTION_VENDOR_ID ,OPTION_PRODUCT_RICOLA ) },
@@ -862,6 +866,8 @@ static struct usb_device_id option_ids[] { USB_DEVICE(PIRELLI_VENDOR_ID, PIRELLI_PRODUCT_1012)}, { USB_DEVICE(CINTERION_VENDOR_ID, 0x0047) }, + + { USB_DEVICE(OLIVETTI_VENDOR_ID, OLIVETTI_PRODUCT_OLICARD100) }, { } /* Terminating entry */ };MODULE_DEVICE_TABLE (usb, option_ids);
PATCH 32/149 USB: ir-usb: fix double free
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Johan Hovold <[email protected]>
commit 2ff78c0c2b67120c8e503268da3f177cae2228a2 upstream.
If the user specifies a custom bulk buffer size we get a double free at port release.
--- drivers/usb/serial/ir-usb.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/usb/serial/ir-usb.c +2 -0
@@ -312,6 +312,7 @@ static int ir_open(struct tty_struct *ttkfree (port->read_urb->transfer_buffer); port->read_urb->transfer_buffer = buffer; port->read_urb->transfer_buffer_length = buffer_size; + port->bulk_in_buffer = buffer; buffer =kmalloc (buffer_size,GFP_KERNEL );if (!buffer) {
@@ -321,6 +322,7 @@ static int ir_open(struct tty_struct *ttkfree (port->write_urb->transfer_buffer); port->write_urb->transfer_buffer = buffer; port->write_urb->transfer_buffer_length = buffer_size; + port->bulk_out_buffer = buffer; port->bulk_out_size = buffer_size; }
PATCH 33/149 USB: kl5usb105: fix memory leak
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Johan Hovold <[email protected]>
commit 313b0d80c1717ffe8f64b455a4d323996748b91a upstream.
Private data was not freed on error path in startup.
--- drivers/usb/serial/kl5kusb105.c | 1 + 1 file changed, 1 insertion(+)
drivers/usb/serial/kl5kusb105.c +1 -0
@@ -310,6 +310,7 @@ err_cleanup:usb_free_urb (priv->write_urb_pool[j]); } } +kfree (priv);usb_set_serial_port_data (serial->port[i],NULL ); }return -ENOMEM ;
PATCH 34/149 USB: mxc: gadget: Fix bitfield for calculating maximum packet size
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Dinh Nguyen <[email protected]>
commit 88e3b59b5adce5b12e205af0e34d518ba0dcdc0c upstream.
The max packet length bit mask used for isochronous endpoints should be 0x7FF instead of 0x8FF. 0x8FF will actually clear higher-order bits in the max packet length field.
This patch applies to 2.6.34-rc6.
--- drivers/usb/gadget/fsl_udc_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/gadget/fsl_udc_core.c +1 -1
@@ -489,7 +489,7 @@ static int fsl_ep_enable(struct usb_ep *case USB_ENDPOINT_XFER_ISOC :/* Calculate transactions needed for high bandwidth iso */ mult = (unsigned char )(1 + ((max >>11 ) &0x03 )); - max = max &0x8ff ;/* bit 0~10 */ + max = max &0x7ff ;/* bit 0~10 */ /* 3 transactions at most */ if (mult >3 ) goto en_done;
PATCH 35/149 USB: unusual-dev: Add bad sense flag for Appotech ax203 based picture frames
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Hans de Goede <[email protected]>
commit a78f4f1a16d87f3d33158d036af94e48e32f8aad upstream.
These Appotech controllers are found in Picture Frames, they provide a (buggy) emulation of a cdrom drive which contains the windows software Uploading of pictures happens over the corresponding /dev/sg device.
--- drivers/usb/storage/unusual_devs.h | 15 +++++++++++++++ 1 file changed, 15 insertions(+)
drivers/usb/storage/unusual_devs.h +15 -0
@@ -1858,6 +1858,21 @@ UNUSUAL_DEV( 0x1652, 0x6600, 0x0201, 0x US_SC_DEVICE, US_PR_DEVICE, NULL, US_FL_IGNORE_RESIDUE ), +/* Reported by Hans de Goede <[email protected]> +* These Appotech controllers are found in Picture Frames, they provide a +* (buggy) emulation of a cdrom drive which contains the windows software +* Uploading of pictures happens over the corresponding /dev/sg device. */ +UNUSUAL_DEV (0x1908 ,0x1315 ,0x0000 ,0x0000 , +"BUILDWIN" , +"Photo Frame" , +US_SC_DEVICE ,US_PR_DEVICE ,NULL , +US_FL_BAD_SENSE ), +UNUSUAL_DEV (0x1908 ,0x1320 ,0x0000 ,0x0000 , +"BUILDWIN" , +"Photo Frame" , +US_SC_DEVICE ,US_PR_DEVICE ,NULL , +US_FL_BAD_SENSE ), + UNUSUAL_DEV( 0x2116, 0x0320, 0x0001, 0x0001, "ST", "2A",
PATCH 36/149 USB: EHCI: clear PHCD before resuming
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Alek Du <[email protected]>
commit eab80de01cb398419ef3305f35abcb367c647c8b upstream.
This is a bug fix for PHCD (phy clock disable) low power feature:
After PHCD is set, any write to PORTSC register is illegal, so when resume ports, clear PHCD bit first.
--- drivers/usb/host/ehci-hub.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+)
drivers/usb/host/ehci-hub.c +17 -0
@@ -292,6 +292,16 @@ static int ehci_bus_resume (struct usb_h/* manually resume the ports we suspended during bus_suspend() */ i =HCS_N_PORTS (ehci->hcs_params);while (i--) { +/* clear phy low power mode before resume */ +if (ehci->has_hostpc) { +u32 __iomem *hostpc_reg = + (u32 __iomem *)((u8 *)ehci->regs + +HOSTPC0 +4 * (i &0xff )); + temp =ehci_readl (ehci, hostpc_reg); +ehci_writel (ehci, temp & ~HOSTPC_PHCD , + hostpc_reg); +mdelay (5 ); + } temp =ehci_readl (ehci, &ehci->regs->port_status [i]); temp &= ~(PORT_RWC_BITS |PORT_WAKE_BITS ); if (test_bit(i, &ehci->bus_suspended) &&
@@ -676,6 +686,13 @@ static int ehci_hub_control (if (temp &PORT_SUSPEND ) {if ((temp &PORT_PE ) ==0 ) goto error; +/* clear phy low power mode before resume */ +if (hostpc_reg) { + temp1 =ehci_readl (ehci, hostpc_reg); +ehci_writel (ehci, temp1 & ~HOSTPC_PHCD , + hostpc_reg); +mdelay (5 ); + }/* resume signaling for 20 msec */ temp &= ~(PORT_RWC_BITS |PORT_WAKE_BITS ); ehci_writel(ehci, temp | PORT_RESUME,
PATCH 37/149 USB: xhci: Fix issue with set interface after stall.
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Sarah Sharp <[email protected]>
commit 1624ae1c19e227096ba85bfc389d9b99cb6f7dde upstream.
When the USB core installs a new interface, it unconditionally clears the halts on all the endpoints on the new interface. Usually the xHCI host needs to know when an endpoint is reset, so it can change its internal endpoint state. In this case, it doesn't care, because the endpoints were never halted in the first place.
To avoid issuing a redundant Reset Endpoint command, the xHCI driver looks at xhci_virt_ep->stopped_td to determine if the endpoint was actually halted. However, the functions that handle the stall never set that variable to NULL after it dealt with the stall. So if an endpoint stalled and a Reset Endpoint command completed, and then the class driver tried to install a new alternate setting, the xHCI driver would access the old xhci_virt_ep->stopped_td pointer. A similar problem occurs if the endpoint has been stopped to cancel a transfer.
--- drivers/usb/host/xhci-hcd.c | 2 ++ drivers/usb/host/xhci-ring.c | 7 +++++++ 2 files changed, 9 insertions(+)
drivers/usb/host/xhci-hcd.c +2 -0
@@ -1414,6 +1414,8 @@ void xhci_endpoint_reset(struct usb_hcdkfree (virt_ep->stopped_td);xhci_ring_cmd_db (xhci); } + virt_ep->stopped_td =NULL ; + virt_ep->stopped_trb =NULL ;spin_unlock_irqrestore (&xhci->lock, flags);if (ret)
drivers/usb/host/xhci-ring.c +7 -0
@@ -548,6 +548,8 @@ static void handle_stopped_endpoint(stru/* Otherwise just ring the doorbell to restart the ring */ ring_ep_doorbell (xhci, slot_id, ep_index); } + ep->stopped_td =NULL ; + ep->stopped_trb =NULL ;/* * Drop the lock and complete the URBs in the cancelled TD list.
@@ -1065,8 +1067,13 @@ static int handle_tx_event(struct xhci_h ep->stopped_td = td; ep->stopped_trb = event_trb; +xhci_queue_reset_ep (xhci, slot_id, ep_index);xhci_cleanup_stalled_ring (xhci, td->urb->dev, ep_index); + + ep->stopped_td =NULL ; + ep->stopped_trb =NULL ; +xhci_ring_cmd_db (xhci); goto td_cleanup;default :
PATCH 38/149 USB: xhci: Fix check for room on the ring.
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Sarah Sharp <[email protected]>
commit 44ebd037c54f80db3121ac9f5fe6e677b76e11d5 upstream.
The length of the scatter gather list a driver can enqueue is limited by the bus' sg_tablesize to 62 entries. Each entry will be described by at least one transfer request block (TRB). If the entry's buffer crosses a 64KB boundary, then that entry will have to be described by two or more TRBs. So even if the USB device driver respects sg_tablesize, the whole scatter list may take more than 62 TRBs to describe, and won't fit on the ring.
Don't assume that an empty ring means there is enough room on the transfer ring. The old code would unconditionally queue this too-large transfer, and over write the beginning of the transfer. This would mean the cycle bit was unchanged in those overwritten transfers, causing the hardware to think it didn't own the TRBs, and the host would seem to hang.
Now drivers may see submit_urb() fail with -ENOMEM if the transfers are too big to fit on the ring.
--- drivers/usb/host/xhci-ring.c | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-)
drivers/usb/host/xhci-ring.c +18 -1
@@ -241,10 +241,27 @@ static int room_on_ring(struct xhci_hcdint i;union xhci_trb *enq = ring->enqueue;struct xhci_segment *enq_seg = ring->enq_seg; +struct xhci_segment *cur_seg; +unsigned int left_on_ring;/* Check if ring is empty */ -if (enq == ring->dequeue) +if (enq == ring->dequeue) { +/* Can't use link trbs */ + left_on_ring =TRBS_PER_SEGMENT -1 ; +for (cur_seg = enq_seg->next; cur_seg != enq_seg; + cur_seg = cur_seg->next) + left_on_ring +=TRBS_PER_SEGMENT -1 ; + +/* Always need one TRB free in the ring. */ + left_on_ring -=1 ; +if (num_trbs > left_on_ring) { +xhci_warn (xhci,"Not enough room on ring; " +"need %u TRBs, %u TRBs left\n" , + num_trbs, left_on_ring); +return 0 ; + }return 1 ; + }/* Make sure there's an extra empty TRB available */ for (i =0 ; i <= num_trbs; ++i) {if (enq == ring->dequeue)
PATCH 39/149 USB: xHCI: Fix wrong usage of macro TRB_TYPE
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Andiry Xu <[email protected]>
commit 54b5acf3acb7a1f83ec281d111d3e2812cd7ad9d upstream.
Macro TRB_TYPE is misused in some places. Fix the wrong usage.
--- drivers/usb/host/xhci-ring.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-)
drivers/usb/host/xhci-ring.c +7 -4
@@ -350,7 +350,8 @@ static struct xhci_segment *find_trb_segwhile (cur_seg->trbs > trb || &cur_seg->trbs[TRBS_PER_SEGMENT -1 ] < trb) { generic_trb = &cur_seg->trbs[TRBS_PER_SEGMENT -1 ].generic; -if (TRB_TYPE (generic_trb->field[3 ]) ==TRB_LINK && +if ((generic_trb->field[3 ] &TRB_TYPE_BITMASK ) == +TRB_TYPE (TRB_LINK ) && (generic_trb->field[3 ] &LINK_TOGGLE )) *cycle_state = ~(*cycle_state) &0x1 ; cur_seg = cur_seg->next;
@@ -406,7 +407,7 @@ void xhci_find_new_dequeue_state(structBUG (); trb = &state->new_deq_ptr->generic; -if (TRB_TYPE (trb->field[3 ]) ==TRB_LINK && +if ((trb->field[3 ] &TRB_TYPE_BITMASK ) ==TRB_TYPE (TRB_LINK ) && (trb->field[3 ] &LINK_TOGGLE )) state->new_cycle_state = ~(state->new_cycle_state) &0x1 ;next_trb (xhci, ep_ring, &state->new_deq_seg, &state->new_deq_ptr);
@@ -1210,8 +1211,10 @@ static int handle_tx_event(struct xhci_hfor (cur_trb = ep_ring->dequeue, cur_seg = ep_ring->deq_seg; cur_trb != event_trb;next_trb (xhci, ep_ring, &cur_seg, &cur_trb)) { -if (TRB_TYPE (cur_trb->generic.field[3 ]) !=TRB_TR_NOOP && -TRB_TYPE (cur_trb->generic.field[3 ]) !=TRB_LINK ) +if ((cur_trb->generic.field[3 ] & +TRB_TYPE_BITMASK ) !=TRB_TYPE (TRB_TR_NOOP ) && + (cur_trb->generic.field[3 ] & +TRB_TYPE_BITMASK ) !=TRB_TYPE (TRB_LINK )) td->urb->actual_length +=TRB_LEN (cur_trb->generic.field[2 ]); }
PATCH 40/149 mac80211: give warning if building w/out rate ctrl algorithm
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Andres Salomon <[email protected]>
commit c2ef355bf3ef0b8006b96128726684fba47ac928 upstream.
I discovered that if EMBEDDED=y, one can accidentally build a mac80211 stack and drivers w/ no rate control algorithm. For drivers like RTL8187 that don't supply their own RC algorithms, this will cause ieee80211_register_hw to fail (making the driver unusable).
This will tell kconfig to provide a warning if no rate control algorithms have been selected. That'll at least warn the user; users that know that their drivers supply a rate control algorithm can safely ignore the warning, and those who don't know (or who expect to be using multiple drivers) can select a default RC algorithm.
--- net/mac80211/Kconfig | 9 +++++++++ 1 file changed, 9 insertions(+)
net/mac80211/Kconfig +9 -0
@@ -15,8 +15,12 @@ comment "CFG80211 needs to be enabled fo if MAC80211 != n +config MAC80211_HAS_RC + def_bool n + config MAC80211_RC_PID bool "PID controller based rate control algorithm" if EMBEDDED + select MAC80211_HAS_RC ---help--- This option enables a TX rate control algorithm for mac80211 that uses a PID controller to select the TX
@@ -24,12 +28,14 @@ config MAC80211_RC_PID config MAC80211_RC_MINSTREL bool "Minstrel" if EMBEDDED + select MAC80211_HAS_RC default y ---help--- This option enables the 'minstrel' TX rate control algorithm choice prompt "Default rate control algorithm" + depends on MAC80211_HAS_RC default MAC80211_RC_DEFAULT_MINSTREL ---help--- This option selects the default rate control algorithm
@@ -62,6 +68,9 @@ config MAC80211_RC_DEFAULT endif +comment "Some wireless drivers require a rate control algorithm" + depends on MAC80211_HAS_RC=n + config MAC80211_MESH bool "Enable mac80211 mesh networking (pre-802.11s) support" depends on MAC80211 && EXPERIMENTAL
PATCH 41/149 mac80211: Fix robust management frame handling (MFP)
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Jouni Malinen <[email protected]>
commit d211e90e28a074447584729018a39910d691d1a8 upstream.
Commit e34e09401ee9888dd662b2fca5d607794a56daf2 incorrectly removed use of ieee80211_has_protected() from the management frame case and in practice, made this validation drop all Action frames when MFP is enabled. This should have only been done for frames with Protected field set to zero.
--- net/mac80211/rx.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
net/mac80211/rx.c +2 -1
@@ -1220,7 +1220,8 @@ ieee80211_drop_unencrypted(struct ieee80 (rx->key || rx->sdata->drop_unencrypted)))return -EACCES ;if (rx->sta &&test_sta_flags (rx->sta,WLAN_STA_MFP )) { -if (unlikely (ieee80211_is_unicast_robust_mgmt_frame (rx->skb) && +if (unlikely (!ieee80211_has_protected (fc) && +ieee80211_is_unicast_robust_mgmt_frame (rx->skb) && rx->key))return -EACCES ;/* BIP does not use Protected field, so need to check MMIE */
PATCH 42/149 mac80211: fix rts threshold check
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Shanyu Zhao <[email protected]>
commit a2c40249a36d0b4d76d1caf6bf806e4ae5b06e8a upstream.
Currently whenever rts thresold is set, every packet will use RTS protection no matter its size exceeds the threshold or not. This is due to a bug in the rts threshold check.
if (len > tx->local->hw.wiphy->rts_threshold) {
txrc.rts = rts = true;
}
Basically it is comparing an int (len) and a u32 (rts_threshold),
and the variable len is assigned as:
len = min_t(int, tx->skb->len + FCS_LEN,
tx->local->hw.wiphy->frag_threshold);However, when frag_threshold is "-1", len is always "-1", which is 0xffffffff therefore rts is always set to true.
--- net/mac80211/tx.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
net/mac80211/tx.c +3 -2
@@ -496,7 +496,8 @@ ieee80211_tx_h_rate_ctrl(struct ieee8021struct ieee80211_hdr *hdr = (void *)tx->skb->data;struct ieee80211_supported_band *sband;struct ieee80211_rate *rate; -int i, len; +int i; +u32 len;bool inval = false, rts = false, short_preamble = false;struct ieee80211_tx_rate_control txrc;u32 sta_flags;
@@ -505,7 +506,7 @@ ieee80211_tx_h_rate_ctrl(struct ieee8021 sband = tx->local->hw.wiphy->bands[tx->channel->band]; - len =min_t (int, tx->skb->len +FCS_LEN , + len =min_t (u32, tx->skb->len +FCS_LEN , tx->local->hw.wiphy->frag_threshold);/* set up the tx rate control struct we give the RC algo */
PATCH 43/149 drm/i915: Reject bind_to_gtt() early if object > aperture
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Chris Wilson <[email protected]>
commit 654fc6073f68efa3b6c466825749e73e7fbb92cd upstream.
If the object is bigger than the entire aperture, reject it early before evicting everything in a vain attempt to find space.
v2: Use E2BIG as suggested by Owain G. Ainsworth.
--- drivers/gpu/drm/i915/i915_gem.c | 8 ++++++++ 1 file changed, 8 insertions(+)
drivers/gpu/drm/i915/i915_gem.c +8 -0
@@ -2615,6 +2615,14 @@ i915_gem_object_bind_to_gtt(struct drm_greturn -EINVAL ; } +/* If the object is bigger than the entire aperture, reject it early +* before evicting everything in a vain attempt to find space. +*/ +if (obj->size > dev->gtt_total) { +DRM_ERROR ("Attempting to bind an object larger than the aperture\n" ); +return -E2BIG ; + } + search_free: free_space =drm_mm_search_free (&dev_priv->mm.gtt_space, obj->size, alignment,0 );
PATCH 44/149 drivers/base/cpu.c: fix the output from /sys/devices/system/cpu/offline
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Jan Beulich <[email protected]>
commit cdc6e3d3968052cebb2f2ddcd742bff29fbd1a90 upstream.
Without CONFIG_CPUMASK_OFFSTACK, simply inverting cpu_online_mask leads to CPUs beyond nr_cpu_ids to be displayed twice and CPUs not even possible to be displayed as offline.
--- drivers/base/cpu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/base/cpu.c +1 -1
@@ -149,7 +149,7 @@ static ssize_t print_cpus_offline(struct/* display offline cpus < nr_cpu_ids */ if (!alloc_cpumask_var (&offline,GFP_KERNEL ))return -ENOMEM ; -cpumask_complement (offline, cpu_online_mask); +cpumask_andnot (offline, cpu_possible_mask, cpu_online_mask); n =cpulist_scnprintf (buf, len, offline);free_cpumask_var (offline);
PATCH 45/149 can: Fix SJA1000 command register writes on SMP systems
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Oliver Hartkopp <[email protected]>
commit 57c8a456640fa3ca777652f11f2db4179a3e66b6 upstream.
The SJA1000 command register is concurrently written in the rx-path to free the receive buffer _and_ in the tx-path to start the transmission.
The SJA1000 data sheet, 6.4.4 COMMAND REGISTER (CMR) states:
"Between two commands at least one internal clock cycle is needed in order to proceed. The internal clock is half of the external oscillator frequency."
On SMP systems the current implementation leads to a write stall in the tx-path, which can be solved by adding some general locking and some time to settle the write_reg() operation for the command register.
Thanks to Klaus Hitschler for the original fix and detailed problem description.
This patch applies on net-2.6 and (with some offsets) on net-next-2.6 .
--- drivers/net/can/sja1000/sja1000.c | 20 +++++++++++++++++--- drivers/net/can/sja1000/sja1000.h | 1 + 2 files changed, 18 insertions(+), 3 deletions(-)
drivers/net/can/sja1000/sja1000.c +17 -3
@@ -84,6 +84,20 @@ static struct can_bittiming_const sja100 .brp_inc = 1, }; +static void sja1000_write_cmdreg (struct sja1000_priv *priv,u8 val) +{ +unsigned long flags; + +/* +* The command register needs some locking and time to settle +* the write_reg() operation - especially on SMP systems. +*/ +spin_lock_irqsave (&priv->cmdreg_lock, flags); + priv->write_reg (priv,REG_CMR , val); + priv->read_reg (priv,REG_SR ); +spin_unlock_irqrestore (&priv->cmdreg_lock, flags); +} +static int sja1000_probe_chip (struct net_device *dev) {struct sja1000_priv *priv =netdev_priv (dev);
@@ -279,7 +293,7 @@ static netdev_tx_t sja1000_start_xmit(stcan_put_echo_skb (skb, dev,0 ); - priv->write_reg (priv,REG_CMR ,CMD_TR ); +sja1000_write_cmdreg (priv,CMD_TR );return NETDEV_TX_OK ; }
@@ -334,7 +348,7 @@ static void sja1000_rx(struct net_device cf->data[i++] =0 ;/* release receive buffer */ - priv->write_reg (priv,REG_CMR ,CMD_RRB ); +sja1000_write_cmdreg (priv,CMD_RRB );netif_rx (skb);
@@ -368,7 +382,7 @@ static int sja1000_err(struct net_device cf->data[1 ] =CAN_ERR_CRTL_RX_OVERFLOW ; stats->rx_over_errors++; stats->rx_errors++; - priv->write_reg (priv,REG_CMR ,CMD_CDO );/* clear bit */ +sja1000_write_cmdreg (priv,CMD_CDO );/* clear bit */ }if (isrc &IRQ_EI ) {
drivers/net/can/sja1000/sja1000.h +1 -0
@@ -165,6 +165,7 @@ struct sja1000_priv {void __iomem *reg_base;/* ioremap'ed address to registers */ unsigned long irq_flags;/* for request_irq() */ +spinlock_t cmdreg_lock;/* lock for concurrent cmd register writes */ u16 flags;/* custom mode flags */ u8 ocr;/* output control register */
PATCH 46/149 PCI quirk: Disable MSI on VIA K8T890 systems
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Matthew Wilcox <[email protected]>
commit 134b345081534235dbf228b1005c14590e0570ba upstream.
Bugzilla 15287 indicates that there's a problem with Message Signalled Interrupts on VIA K8T890 systems. Add a quirk to disable MSI on these systems.
--- drivers/pci/quirks.c | 1 + 1 file changed, 1 insertion(+)
drivers/pci/quirks.c +1 -0
@@ -2092,6 +2092,7 @@ static void __devinit quirk_disable_msi( } }DECLARE_PCI_FIXUP_FINAL (PCI_VENDOR_ID_AMD ,PCI_DEVICE_ID_AMD_8131_BRIDGE , quirk_disable_msi); +DECLARE_PCI_FIXUP_FINAL (PCI_VENDOR_ID_VIA ,0xa238 , quirk_disable_msi);/* Go through the list of Hypertransport capabilities and * return 1 if a HT MSI capability is found and enabled */
PATCH 47/149 PCI quirks: disable msi on AMD rs4xx internal gfx bridges
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Alex Deucher <[email protected]>
commit 9313ff450400e6a2ab10fe6b9bdb12a828329410 upstream.
Doesn't work reliably for internal gfx. Fixes kernel bug
https://bugzilla.kernel.org/show_bug.cgi?id=15626.
--- drivers/pci/quirks.c | 1 + 1 file changed, 1 insertion(+)
drivers/pci/quirks.c +1 -0
@@ -2093,6 +2093,7 @@ static void __devinit quirk_disable_msi( }DECLARE_PCI_FIXUP_FINAL (PCI_VENDOR_ID_AMD ,PCI_DEVICE_ID_AMD_8131_BRIDGE , quirk_disable_msi);DECLARE_PCI_FIXUP_FINAL (PCI_VENDOR_ID_VIA ,0xa238 , quirk_disable_msi); +DECLARE_PCI_FIXUP_FINAL (PCI_VENDOR_ID_ATI ,0x5a3f , quirk_disable_msi);/* Go through the list of Hypertransport capabilities and * return 1 if a HT MSI capability is found and enabled */
PATCH 48/149 PCI: Disable MSI for MCP55 on P5N32-E SLI
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Ben Hutchings <[email protected]>
commit e4146bb9088c01c8b6e82be11f0c371f8aff023c upstream.
As reported in <http://bugs.debian.org/552299>, MSI appears to be broken for this on-board device. We already have a quirk for the P5N32-SLI Premium; extend it to cover both variants of the board.
--- drivers/pci/quirks.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
drivers/pci/quirks.c +4 -3
@@ -2185,15 +2185,16 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_SDECLARE_PCI_FIXUP_HEADER (PCI_VENDOR_ID_AMD ,PCI_DEVICE_ID_AMD_8132_BRIDGE , ht_enable_msi_mapping); -/* The P5N32-SLI Premium motherboard from Asus has a problem with msi +/* The P5N32-SLI motherboards from Asus have a problem with msi * for the MCP55 NIC. It is not yet determined whether the msi problem * also affects other devices. As for now, turn off msi for this device. */ static void __devinit nvenet_msi_disable (struct pci_dev *dev) { -if (dmi_name_in_vendors ("P5N32-SLI PREMIUM" )) { +if (dmi_name_in_vendors ("P5N32-SLI PREMIUM" ) || +dmi_name_in_vendors ("P5N32-E SLI" )) {dev_info (&dev->dev, -"Disabling msi for MCP55 NIC on P5N32-SLI Premium\n" ); +"Disabling msi for MCP55 NIC on P5N32-SLI\n" ); dev->no_msi =1 ; } }
PATCH 49/149 virtio_net: Make delayed refill more reliable
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Herbert Xu <[email protected]>
commit 39d321577405e8e269fd238b278aaf2425fa788a upstream.
I have seen RX stalls on a machine that experienced a suspected OOM. After the stall, the RX buffer is empty on the guest side and there are exactly 16 entries available on the host side. As the number of entries is less than that required by a maximal skb, the host cannot proceed.
The guest did not have a refill job scheduled.
My diagnosis is that an OOM had occured, with the delayed refill job scheduled. The job was able to allocate at least one skb, but not enough to overcome the minimum required by the host to proceed.
As the refill job would only reschedule itself if it failed completely to allocate any skbs, this would lead to an RX stall.
The following patch removes this stall possibility by always rescheduling the refill job until the ring is totally refilled.
Testing has shown that the RX stall no longer occurs whereas previously it would occur within a day.
--- drivers/net/virtio_net.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/net/virtio_net.c +1 -2
@@ -398,8 +398,7 @@ static void refill_work(struct work_stru vi = container_of(work, struct virtnet_info, refill.work);napi_disable (&vi->napi); -try_fill_recv (vi,GFP_KERNEL ); - still_empty = (vi->num ==0 ); + still_empty = !try_fill_recv (vi,GFP_KERNEL );napi_enable (&vi->napi);/* In theory, this can happen: if we don't get any buffers in
PATCH 50/149 mm: hugetlb: fix clear_huge_page()
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Andrea Arcangeli <[email protected]>
commit 74dbdd239bb1348ad86d28b18574d9c1f28b62ca upstream.
sz is in bytes, MAX_ORDER_NR_PAGES is in pages.
--- mm/hugetlb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
mm/hugetlb.c +1 -1
@@ -401,7 +401,7 @@ static void clear_huge_page(struct page {int i; -if (unlikely (sz >MAX_ORDER_NR_PAGES )) { +if (unlikely (sz/PAGE_SIZE >MAX_ORDER_NR_PAGES )) {clear_gigantic_page (page, addr, sz);return ; }
PATCH 51/149 drm/edid: Fix 1024x768@85Hz
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Adam Jackson <[email protected]>
commit 61dd98fad58f945ed720ba132681acb58fcee015 upstream.
Having hsync both start and end on pixel 1072 ain't gonna work very well. Matches the X server's list.
--- drivers/gpu/drm/drm_edid.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/drm_edid.c +1 -1
@@ -324,7 +324,7 @@ static struct drm_display_mode drm_dmt_m DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },/* 1024x768@85Hz */ {DRM_MODE ("1024x768" ,DRM_MODE_TYPE_DRIVER ,94500 ,1024 ,1072 , -1072 ,1376 ,0 ,768 ,769 ,772 ,808 ,0 , +1168 ,1376 ,0 ,768 ,769 ,772 ,808 ,0 , DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },/* 1152x864@75Hz */ { DRM_MODE("1152x864", DRM_MODE_TYPE_DRIVER, 108000, 1152, 1216,
PATCH 52/149 drm/radeon/kms/atom: fix typo in LVDS panel info parsing
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Alex Deucher <[email protected]>
commit 1ff26a3604d0292988d4cade0e49ba9918dbfd46 upstream.
Fixes LVDS issues on some laptops; notably laptops with 2048x1536 panels.
--- drivers/gpu/drm/radeon/radeon_atombios.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/radeon/radeon_atombios.c +1 -1
@@ -942,7 +942,7 @@ struct radeon_encoder_atom_dig *radeon_a lvds->native_mode.vtotal = lvds->native_mode.vdisplay +le16_to_cpu (lvds_info->info.sLCDTiming.usVBlanking_Time); lvds->native_mode.vsync_start = lvds->native_mode.vdisplay + -le16_to_cpu (lvds_info->info.sLCDTiming.usVSyncWidth); +le16_to_cpu (lvds_info->info.sLCDTiming.usVSyncOffset); lvds->native_mode.vsync_end = lvds->native_mode.vsync_start +le16_to_cpu (lvds_info->info.sLCDTiming.usVSyncWidth); lvds->panel_pwr_delay =
PATCH 53/149 powerpc: Fix handling of strncmp with zero len
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Jeff Mahoney <[email protected]>
commit 637a99022fb119b90fb281715d13172f0394fc12 upstream.
Commit 0119536c, which added the assembly version of strncmp to powerpc, mentions that it adds two instructions to the version from boot/string.S to allow it to handle len=0. Unfortunately, it doesn't always return 0 when that is the case. The length is passed in r5, but the return value is passed back in r3. In certain cases, this will happen to work. Otherwise it will pass back the address of the first string as the return value.
This patch lifts the len <= 0 handling code from memcpy to handle that case.
Reported by: [email protected]
--- arch/powerpc/lib/string.S | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
arch/powerpc/lib/string.S +3 -1
@@ -71,7 +71,7 @@ _GLOBAL(strcmp) _GLOBAL(strncmp) PPC_LCMPI r5,0 - beqlr + ble- 2f mtctr r5 addi r5,r3,-1 addi r4,r4,-1
@@ -82,6 +82,8 @@ _GLOBAL(strncmp) beqlr 1 bdnzt eq,1b blr +2: li r3,0 + blr _GLOBAL(strlen) addi r4,r3,-1
PATCH 54/149 powerpc/pseries: Only call start-cpu when a CPU is stopped
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Michael Neuling <[email protected]>
commit aef40e87d866355ffd279ab21021de733242d0d5 upstream.
Currently we always call start-cpu irrespective of if the CPU is stopped or not. Unfortunatley on POWER7, firmware seems to not like start-cpu being called when a cpu already been started. This was not the case on POWER6 and earlier.
This patch checks to see if the CPU is stopped or not via an query-cpu-stopped-state call, and only calls start-cpu on CPUs which are stopped.
This fixes a bug with kexec on POWER7 on PHYP where only the primary thread would make it to the second kernel.
--- arch/powerpc/platforms/pseries/smp.c | 6 ++++++ 1 file changed, 6 insertions(+)
arch/powerpc/platforms/pseries/smp.c +6 -0
@@ -81,6 +81,12 @@ static inline int __devinit smp_startup_ pcpu =get_hard_smp_processor_id (lcpu); +/* Check to see if the CPU out of FW already for kexec */ +if (smp_query_cpu_stopped (pcpu) ==QCSS_NOT_STOPPED ){ +cpu_set (lcpu, of_spin_map); +return 1 ; + } +/* Fixup atomic count: it exited inside IRQ handler. */ task_thread_info (paca[lcpu].__current)->preempt_count =0 ;
Re: [patch 054/149] powerpc/pseries: Only call start-cpu when a CPU is stopped
This is not going to work without:f8b67691828321f5c85bb853283aa101ae673130
It'll get a build failure.
You seemed to have pulled this one the 33 stable.
Mikey
Quoted 1 line · In message <[email protected]> you wrote:
2.6.32-stable review patch. If anyone has any objections, please let us know
.
Quoted 45 lines
------------------
From: Michael Neuling <[email protected]>
commit
aef40e87d866355ffd279ab21021de733242d0d5upstream.Currently we always call start-cpu irrespective of if the CPU is stopped or not. Unfortunatley on POWER7, firmware seems to not like start-cpu being called when a cpu already been started. This was not the case on POWER6 and earlier.
This patch checks to see if the CPU is stopped or not via an query-cpu-stopped-state call, and only calls start-cpu on CPUs which are stopped.
This fixes a bug with kexec on POWER7 on PHYP where only the primary thread would make it to the second kernel.
Reported-by Ankita Garg <[email protected]>Signed-off-by Michael Neuling <[email protected]>Signed-off-by Benjamin Herrenschmidt <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>--- arch/powerpc/platforms/pseries/smp.c | 6 ++++++ 1 file changed, 6 insertions(+)arch/powerpc/platforms/pseries/smp.c +6
-0@@ -81,6 +81,12 @@ static inline int __devinit smp_startup_ pcpu =get_hard_smp_processor_id (lcpu); +/* Check to see if the CPU out of FW already for kexec */ +if (smp_query_cpu_stopped (pcpu) ==QCSS_NOT_STOPPED ){ +cpu_set (lcpu, of_spin_map); +return 1 ; + } +/* Fixup atomic count: it exited inside IRQ handler. */ task_thread_info (paca[lcpu].__current)->preempt_count =0 ;
Re: [patch 054/149] powerpc/pseries: Only call start-cpu when a CPU is stopped
Quoted 4 lines · Michael Neuling
This is not going to work without:
f8b67691828321f5c85bb853283aa101ae673130It'll get a build failure.
That is because that patch does not apply to the .32 series. If it is needed, can you please send me a backported version to apply?
thanks,
greg k-h
Re: [patch 054/149] powerpc/pseries: Only call start-cpu when a CPU is stopped
Quoted 7 lines
Quoted 4 lines
This is not going to work without:
f8b67691828321f5c85bb853283aa101ae673130It'll get a build failure.
That is because that patch does not apply to the .32 series. If it is needed, can you please send me a backported version to apply?
Sure... Compile and boot tested only.
Thanks,
Mikey
From: Michael Neuling <[email protected]>
powerpc/pseries: Make query_cpu_stopped callable outside hotplug cpu
This moves query_cpu_stopped() out of the hotplug cpu code and into smp.c so it can called in other places and renames it to smp_query_cpu_stopped().
It also cleans up the return values by adding some #defines
arch/powerpc/platforms/pseries/hotplug-cpu.c +4 -26
@@ -66,30 +66,6 @@ static void pseries_mach_cpu_die(void)for (;;); } -static int qcss_tok;/* query-cpu-stopped-state token */ - -/* Get state of physical CPU. -* Return codes: -* 0 - The processor is in the RTAS stopped state -* 1 - stop-self is in progress -* 2 - The processor is not in the RTAS stopped state -* -1 - Hardware Error -* -2 - Hardware Busy, Try again later. -*/ -static int query_cpu_stopped (unsigned int pcpu) -{ -int cpu_status, status; - - status =rtas_call (qcss_tok,1 ,2 , &cpu_status, pcpu); -if (status !=0 ) { -printk (KERN_ERR -"RTAS query-cpu-stopped-state failed: %i\n" , status); -return status; - } - -return cpu_status; -} -static int pseries_cpu_disable (void ) {int cpu =smp_processor_id ();
@@ -113,8 +89,9 @@ static void pseries_cpu_die(unsigned intunsigned int pcpu =get_hard_smp_processor_id (cpu);for (tries =0 ; tries <25 ; tries++) { - cpu_status =query_cpu_stopped (pcpu); -if (cpu_status ==0 || cpu_status ==-1 ) + cpu_status =smp_query_cpu_stopped (pcpu); +if (cpu_status ==QCSS_STOPPED || + cpu_status ==QCSS_HARDWARE_ERROR )break ;cpu_relax (); }
@@ -256,6 +233,7 @@ static int __init pseries_cpu_hotplug_in {struct device_node *np;const char *typep; +int qcss_tok;for_each_node_by_name (np,"interrupt-controller" ) { typep =of_get_property (np,"compatible" ,NULL );
arch/powerpc/platforms/pseries/plpar_wrappers.h +8 -0
@@ -4,6 +4,14 @@#include <asm/hvcall.h> #include <asm/page.h> +/* Get state of physical CPU from query_cpu_stopped */ +int smp_query_cpu_stopped (unsigned int pcpu); +#define QCSS_STOPPED 0 +#define QCSS_STOPPING 1 +#define QCSS_NOT_STOPPED 2 +#define QCSS_HARDWARE_ERROR -1 +#define QCSS_HARDWARE_BUSY -2 +static inline long poll_pending (void ) {return plpar_hcall_norets (H_POLL_PENDING );
arch/powerpc/platforms/pseries/smp.c +22 -0
@@ -56,6 +56,28 @@*/ static cpumask_t of_spin_map; +/* Query where a cpu is now. Return codes #defined in plpar_wrappers.h */ +int smp_query_cpu_stopped (unsigned int pcpu) +{ +int cpu_status, status; +int qcss_tok =rtas_token ("query-cpu-stopped-state" ); + +if (qcss_tok ==RTAS_UNKNOWN_SERVICE ) { +printk (KERN_INFO "Firmware doesn't support " +"query-cpu-stopped-state\n" ); +return QCSS_HARDWARE_ERROR ; + } + + status =rtas_call (qcss_tok,1 ,2 , &cpu_status, pcpu); +if (status !=0 ) { +printk (KERN_ERR +"RTAS query-cpu-stopped-state failed: %i\n" , status); +return status; + } + +return cpu_status; +} +/** * smp_startup_cpu() - start the given cpu *
Re: [patch 054/149] powerpc/pseries: Only call start-cpu when a CPU is stopped
Quoted 9 lines · Michael Neuling
Quoted 7 lines
Quoted 4 lines
This is not going to work without:
f8b67691828321f5c85bb853283aa101ae673130It'll get a build failure.
That is because that patch does not apply to the .32 series. If it is needed, can you please send me a backported version to apply?
Sure... Compile and boot tested only.
Applied now, thanks,
greg k-h
PATCH 55/149 powerpc/oprofile: fix potential buffer overrun in op_model_cell.c
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Denis Kirjanov <[email protected]>
commit 238c1a78c957f3dc7cb848b161dcf4805793ed56 upstream.
Fix potential initial_lfsr buffer overrun.
Writing past the end of the buffer could happen when index == ENTRIES
--- arch/powerpc/oprofile/op_model_cell.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/powerpc/oprofile/op_model_cell.c +1 -1
@@ -1077,7 +1077,7 @@ static int calculate_lfsr(int n) index =ENTRIES -1 ;/* make sure index is valid */ -if ((index >ENTRIES ) || (index <0 )) +if ((index >=ENTRIES ) || (index <0 )) index =ENTRIES -1 ;return initial_lfsr[index];
PATCH 56/149 writeback: disable periodic old data writeback for !dirty_writeback_centisecs
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Jens Axboe <[email protected]>
commit 69b62d01ec44fe0d505d89917392347732135a4d upstream.
Prior to 2.6.32, setting /proc/sys/vm/dirty_writeback_centisecs disabled periodic dirty writeback from kupdate. This got broken and now causes excessive sys CPU usage if set to zero, as we'll keep beating on schedule().
--- fs/fs-writeback.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-)
fs/fs-writeback.c +12 -2
@@ -859,6 +859,12 @@ static long wb_check_old_data_flush(struunsigned long expired;long nr_pages; +/* +* When set to zero, disable periodic writeback +*/ +if (!dirty_writeback_interval) +return 0 ; + expired = wb->last_old_flush +msecs_to_jiffies (dirty_writeback_interval *10 );if (time_before (jiffies, expired))
@@ -954,8 +960,12 @@ int bdi_writeback_task(struct bdi_writebbreak ; } - wait_jiffies =msecs_to_jiffies (dirty_writeback_interval *10 ); -schedule_timeout_interruptible (wait_jiffies); +if (dirty_writeback_interval) { + wait_jiffies =msecs_to_jiffies (dirty_writeback_interval *10 ); +schedule_timeout_interruptible (wait_jiffies); + }else +schedule (); +try_to_freeze (); }
PATCH 57/149 md/raid1: fix counting of write targets.
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: NeilBrown <[email protected]>
commit 964147d5c86d63be79b442c30f3783d49860c078 upstream.
There is a very small race window when writing to a RAID1 such that if a device is marked faulty at exactly the wrong time, the write-in-progress will not be sent to the device, but the bitmap (if present) will be updated to say that the write was sent.
Then if the device turned out to still be usable as was re-added to the array, the bitmap-based-resync would skip resyncing that block, possibly leading to corruption. This would only be a problem if no further writes were issued to that area of the device (i.e. that bitmap chunk).
Suitable for any pending -stable kernel.
--- drivers/md/raid1.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/md/raid1.c +3 -2
@@ -891,9 +891,10 @@ static int make_request(struct request_qif (test_bit (Faulty, &rdev->flags)) {rdev_dec_pending (rdev, mddev); r1_bio->bios[i] =NULL ; - }else + }else { r1_bio->bios[i] = bio; - targets++; + targets++; + } }else r1_bio->bios[i] =NULL ; }
PATCH 58/149 md: Fix read balancing in RAID1 and RAID10 on drives > 2TB
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: NeilBrown <[email protected]>
commit af3a2cd6b8a479345786e7fe5e199ad2f6240e56 upstream.
read_balance uses a "unsigned long" for a sector number which will get truncated beyond 2TB.
This will cause read-balancing to be non-optimal, and can cause data to be read from the 'wrong' branch during a resync. This has a very small chance of returning wrong data.
--- drivers/md/raid1.c | 4 ++-- drivers/md/raid10.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-)
drivers/md/raid1.c +2 -2
@@ -417,7 +417,7 @@ static void raid1_end_write_request(stru*/ static int read_balance (conf_t *conf,r1bio_t *r1_bio) { -const unsigned long this_sector = r1_bio->sector; +const sector_t this_sector = r1_bio->sector;int new_disk = conf->last_used, disk = new_disk;int wonly_disk =-1 ;const int sectors = r1_bio->sectors;
@@ -433,7 +433,7 @@ static int read_balance(conf_t *conf, r1 retry:if (conf->mddev->recovery_cp < MaxSector && (this_sector + sectors >= conf->next_resync)) { -/* Choose the first operation device, for consistancy */ +/* Choose the first operational device, for consistancy */ new_disk =0 ; for (rdev = rcu_dereference(conf->mirrors[new_disk].rdev);
drivers/md/raid10.c +1 -1
@@ -493,7 +493,7 @@ static int raid10_mergeable_bvec(struct*/ static int read_balance (conf_t *conf,r10bio_t *r10_bio) { -const unsigned long this_sector = r10_bio->sector; +const sector_t this_sector = r10_bio->sector;int disk, slot, nslot;const int sectors = r10_bio->sectors;sector_t new_distance, current_distance;
PATCH 59/149 md: set mddev readonly flag on blkdev BLKROSET ioctl
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Dan Williams <[email protected]>
commit e2218350465e7e0931676b4849b594c978437bce upstream.
When the user sets the block device to readwrite then the mddev should follow suit. Otherwise, the BUG_ON in md_write_start() will be set to trigger.
The reverse direction, setting mddev->ro to match a set readonly request, can be ignored because the blkdev level readonly flag precludes the need to have mddev->ro set correctly. Nevermind the fact that setting mddev->ro to 1 may fail if the array is in use.
--- drivers/md/md.c | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+)
drivers/md/md.c +29 -0
@@ -5334,6 +5334,7 @@ static int md_ioctl(struct block_deviceint err =0 ;void __user *argp = (void __user *)arg;mddev_t *mddev =NULL ; +int ro;if (!capable (CAP_SYS_ADMIN ))return -EACCES ;
@@ -5469,6 +5470,34 @@ static int md_ioctl(struct block_device err =do_md_stop (mddev,1 ,1 ); goto done_unlock; +case BLKROSET : +if (get_user (ro, (int __user *)(arg))) { + err = -EFAULT ; + goto done_unlock; + } + err = -EINVAL ; + +/* if the bdev is going readonly the value of mddev->ro +* does not matter, no writes are coming +*/ +if (ro) + goto done_unlock; + +/* are we are already prepared for writes? */ +if (mddev->ro !=1 ) + goto done_unlock; + +/* transitioning to readauto need only happen for +* arrays that call md_write_start +*/ +if (mddev->pers) { + err =restart_array (mddev); +if (err ==0 ) { + mddev->ro =2 ; +set_disk_ro (mddev->gendisk,0 ); + } + } + goto done_unlock; }/*
PATCH 60/149 x86/amd-iommu: Fix suspend/resume with IOMMU
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Joerg Roedel <[email protected]>
This is a suspend resume fix for 2.6.32-stable inclusion. The problem with this patch is that it is not upstream because the code changed with 2.6.33 and the function where this bug is in was removed. So this fix does not make sense anymore for anything later than 2.6.32. The patch was tested by multiple partys and is confirmed to fix the broken suspend/resume issue with the 2.6.32 kernel.
This patch fixes suspend/resume with AMD IOMMU enabled.
--- arch/x86/kernel/amd_iommu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/x86/kernel/amd_iommu.c +1 -1
@@ -544,7 +544,7 @@ static void flush_devices_by_domain(strufor (i =0 ; i <= amd_iommu_last_bdf; ++i) {if ((domain ==NULL && amd_iommu_pd_table[i] ==NULL ) || - (amd_iommu_pd_table[i] != domain)) + (domain !=NULL && amd_iommu_pd_table[i] != domain))continue ; iommu = amd_iommu_rlookup_table[i];
PATCH 61/149 exofs: confusion between kmap() and kmap_atomic() api
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Dan Carpenter <[email protected]>
commit ddf08f4b90a413892bbb9bb2e8a57aed991cd47d upstream.
For kmap_atomic() we call kunmap_atomic() on the returned pointer. That's different from kmap() and kunmap() and so it's easy to get them backwards.
--- fs/exofs/dir.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/exofs/dir.c +1 -1
@@ -608,7 +608,7 @@ int exofs_make_empty(struct inode *inode de->inode_no =cpu_to_le64 (parent->i_ino);memcpy (de->name,PARENT_DIR ,sizeof (PARENT_DIR ));exofs_set_de_type (de, inode); -kunmap_atomic (page,KM_USER0 ); +kunmap_atomic (kaddr,KM_USER0 ); err =exofs_commit_chunk (page,0 , chunk_size); fail:page_cache_release (page);
PATCH 62/149 mn10300: set ARCH_KMALLOC_MINALIGN
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: FUJITA Tomonori <[email protected]>
commit 6cdafaae41d52e6ef9a5c5be23602ef083e4d0f9 upstream.
Architectures that handle DMA-non-coherent memory need to set ARCH_KMALLOC_MINALIGN to make sure that kmalloc'ed buffer is DMA-safe: the buffer doesn't share a cache with the others.
--- arch/mn10300/include/asm/cache.h | 2 ++ 1 file changed, 2 insertions(+)
arch/mn10300/include/asm/cache.h +2 -0
@@ -21,6 +21,8 @@#define L1_CACHE_DISPARITY L1_CACHE_NENTRIES * L1_CACHE_BYTES#endif +#define ARCH_KMALLOC_MINALIGN L1_CACHE_BYTES +/* data cache purge registers * - read from the register to unconditionally purge that cache line * - write address & 0xffffff00 to conditionally purge that cache line
PATCH 63/149 m68k: set ARCH_KMALLOC_MINALIGN
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: FUJITA Tomonori <[email protected]>
commit dd6c26a66bdc629a500174ffe73b010b070b9f1b upstream.
Architectures that handle DMA-non-coherent memory need to set ARCH_KMALLOC_MINALIGN to make sure that kmalloc'ed buffer is DMA-safe: the buffer doesn't share a cache with the others.
--- arch/m68k/include/asm/cache.h | 2 ++ 1 file changed, 2 insertions(+)
arch/m68k/include/asm/cache.h +2 -0
@@ -8,4 +8,6 @@#define L1_CACHE_SHIFT 4#define L1_CACHE_BYTES (1<< L1_CACHE_SHIFT) +#define ARCH_KMALLOC_MINALIGN L1_CACHE_BYTES +#endif
PATCH 64/149 rtc-cmos: do dev_set_drvdata() earlier in the initialization
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Dan Carpenter <[email protected]>
commit 6ba8bcd457d9fc793ac9435aa2e4138f571d4ec5 upstream.
The bug is an oops when dev_get_drvdata() returned null in cmos_update_irq_enable(). The call tree looks like this:
rtc_dev_ioctl()
=> rtc_update_irq_enable()
=> cmos_update_irq_enable()It's caused by a race condition in the module initialization. It is rtc_device_register() which makes the ioctl operations live so I moved the call to dev_set_drvdata() before the call to rtc_device_register().
Addresses https://bugzilla.kernel.org/show_bug.cgi?id=15963
--- drivers/rtc/rtc-cmos.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/rtc/rtc-cmos.c +3 -2
@@ -723,6 +723,9 @@ cmos_do_probe(struct device *dev, struct } } + cmos_rtc.dev = dev; +dev_set_drvdata (dev, &cmos_rtc); + cmos_rtc.rtc =rtc_device_register (driver_name, dev, &cmos_rtc_ops,THIS_MODULE );if (IS_ERR (cmos_rtc.rtc)) {
@@ -730,8 +733,6 @@ cmos_do_probe(struct device *dev, struct goto cleanup0; } - cmos_rtc.dev = dev; -dev_set_drvdata (dev, &cmos_rtc);rename_region (ports,dev_name (&cmos_rtc.rtc->dev));spin_lock_irq (&rtc_lock);
PATCH 65/149 rtc: s3c: initialize driver data before using it
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Maurus Cuelenaere <[email protected]>
commit e893de59a4982791368b3ce412bc67dd601a88a0 upstream.
s3c_rtc_setfreq() uses the platform driver data to derive struct rtc_device, so make sure drvdata is set _before_ s3c_rtc_setfreq() is called.
--- drivers/rtc/rtc-s3c.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/rtc/rtc-s3c.c +3 -2
@@ -456,8 +456,6 @@ static int __devinit s3c_rtc_probe(strucpr_debug ("s3c2410_rtc: RTCCON=%02x\n" ,readb (s3c_rtc_base +S3C2410_RTCCON )); -s3c_rtc_setfreq (&pdev->dev,1 ); -device_init_wakeup (&pdev->dev,1 );/* register RTC and exit */
@@ -474,6 +472,9 @@ static int __devinit s3c_rtc_probe(struc rtc->max_user_freq =128 ;platform_set_drvdata (pdev, rtc); + +s3c_rtc_setfreq (&pdev->dev,1 ); +return 0 ; err_nortc:
PATCH 66/149 frv: set ARCH_KMALLOC_MINALIGN
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: FUJITA Tomonori <[email protected]>
commit 69dcf3db03626c4f18de624e8632454ea12ff260 upstream.
Architectures that handle DMA-non-coherent memory need to set ARCH_KMALLOC_MINALIGN to make sure that kmalloc'ed buffer is DMA-safe: the buffer doesn't share a cache with the others.
--- arch/frv/include/asm/cache.h | 2 ++ 1 file changed, 2 insertions(+)
arch/frv/include/asm/cache.h +2 -0
@@ -17,6 +17,8 @@#define L1_CACHE_SHIFT (CONFIG_FRV_L1_CACHE_SHIFT)#define L1_CACHE_BYTES (1 << L1_CACHE_SHIFT) +#define ARCH_KMALLOC_MINALIGN L1_CACHE_BYTES +#define __cacheline_aligned __attribute__((aligned(L1_CACHE_BYTES)))#define ____cacheline_aligned __attribute__((aligned(L1_CACHE_BYTES)))
PATCH 67/149 xtensa: set ARCH_KMALLOC_MINALIGN
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: FUJITA Tomonori <[email protected]>
commit 498900fc9cd1adbad1ba6b55ed9d8f2f5d655ca3 upstream.
Architectures that handle DMA-non-coherent memory need to set ARCH_KMALLOC_MINALIGN to make sure that kmalloc'ed buffer is DMA-safe: the buffer doesn't share a cache with the others.
--- arch/xtensa/include/asm/cache.h | 1 + 1 file changed, 1 insertion(+)
arch/xtensa/include/asm/cache.h +1 -0
@@ -29,5 +29,6 @@# define CACHE_WAY_SIZE ICACHE_WAY_SIZE#endif +#define ARCH_KMALLOC_MINALIGN L1_CACHE_BYTES#endif /* _XTENSA_CACHE_H */
PATCH 68/149 Blackfin: set ARCH_KMALLOC_MINALIGN
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: FUJITA Tomonori <[email protected]>
commit 76b99699a2bbf9efdb578f9a38a202af2ecb354b upstream.
Architectures that handle DMA-non-coherent memory need to set ARCH_KMALLOC_MINALIGN to make sure that kmalloc'ed buffer is DMA-safe:
the buffer doesn't share a cache with the others.
--- arch/blackfin/include/asm/cache.h | 2 ++ 1 file changed, 2 insertions(+)
arch/blackfin/include/asm/cache.h +2 -0
@@ -15,6 +15,8 @@#define L1_CACHE_BYTES (1 << L1_CACHE_SHIFT)#define SMP_CACHE_BYTES L1_CACHE_BYTES +#define ARCH_KMALLOC_MINALIGN L1_CACHE_BYTES +#ifdef CONFIG_SMP #define __cacheline_aligned#else
PATCH 69/149 tmpfs: insert tmpfs cache pages to inactive list at first
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: KOSAKI Motohiro <[email protected]>
commit e9d6c157385e4efa61cb8293e425c9d8beba70d3 upstream.
Shaohua Li reported parallel file copy on tmpfs can lead to OOM killer. This is regression of caused by commit 9ff473b9a7 ("vmscan: evict streaming IO first"). Wow, It is 2 years old patch!
Currently, tmpfs file cache is inserted active list at first. This means that the insertion doesn't only increase numbers of pages in anon LRU, but it also reduces anon scanning ratio. Therefore, vmscan will get totally confused. It scans almost only file LRU even though the system has plenty unused tmpfs pages.
Historically, lru_cache_add_active_anon() was used for two reasons.
1) Intend to priotize shmem page rather than regular file cache.
2) Intend to avoid reclaim priority inversion of used once pages.
But we've lost both motivation because (1) Now we have separate anon and file LRU list. then, to insert active list doesn't help such priotize.
(2) In past, one pte access bit will cause page activation. then to insert inactive list with pte access bit mean higher priority than to insert active list. Its priority inversion may lead to uninteded lru chun. but it was already solved by commit 645747462 (vmscan: detect mapped file pages used only once). (Thanks Hannes, you are great!)
Thus, now we can use lru_cache_add_anon() instead.
--- include/linux/swap.h | 10 ---------- mm/filemap.c | 4 ++-- 2 files changed, 2 insertions(+), 12 deletions(-)
include/linux/swap.h +0 -10
@@ -218,21 +218,11 @@ static inline void lru_cache_add_anon(st__lru_cache_add (page,LRU_INACTIVE_ANON ); } -static inline void lru_cache_add_active_anon (struct page *page) -{ -__lru_cache_add (page,LRU_ACTIVE_ANON ); -} -static inline void lru_cache_add_file (struct page *page) {__lru_cache_add (page,LRU_INACTIVE_FILE ); } -static inline void lru_cache_add_active_file (struct page *page) -{ -__lru_cache_add (page,LRU_ACTIVE_FILE ); -} -/* linux/mm/vmscan.c */ extern unsigned long try_to_free_pages (struct zonelist *zonelist,int order,gfp_t gfp_mask,nodemask_t *mask);
mm/filemap.c +2 -2
@@ -462,7 +462,7 @@ int add_to_page_cache_lru(struct page *p/* * Splice_read and readahead add shmem/tmpfs pages into the page cache * before shmem_readpage has a chance to mark them as SwapBacked: they -* need to go on the active_anon lru below, and mem_cgroup_cache_charge +* need to go on the anon lru below, and mem_cgroup_cache_charge * (called in add_to_page_cache) needs to know where they're going too. */ if (mapping_cap_swap_backed (mapping))
@@ -473,7 +473,7 @@ int add_to_page_cache_lru(struct page *pif (page_is_file_cache (page))lru_cache_add_file (page);else -lru_cache_add_active_anon (page); +lru_cache_add_anon (page); }return ret; }
PATCH 70/149 mlx4_core: Fix possible chunk sg list overflow in mlx4_alloc_icm()
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Sebastien Dugue <[email protected]>
commit c0dc72bad9cf21071f5e4005de46f7c8b67a138a upstream.
If the number of sg entries in the ICM chunk reaches MLX4_ICM_CHUNK_LEN, we must set chunk to NULL even for coherent mappings so that the next time through the loop will allocate another chunk. Otherwise we'll overflow the sg list the next time through the loop. This will lead to memory corruption if this case is hit.
mthca does not have this bug.
--- drivers/net/mlx4/icm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/net/mlx4/icm.c +2 -1
@@ -174,9 +174,10 @@ struct mlx4_icm *mlx4_alloc_icm(struct mif (chunk->nsg <=0 ) goto fail; + } +if (chunk->npages ==MLX4_ICM_CHUNK_LEN ) chunk =NULL ; - } npages -=1 << cur_order; }else {
PATCH 71/149 ARM: 6166/1: Proper prefetch abort handling on pre-ARMv6
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Anfei <[email protected]>
commit 5e27fb78df95e027723af2c90ecc9b4527ae59e9 upstream.
Instruction faults on pre-ARMv6 CPUs are interpreted as a 'translation fault', but do_translation_fault doesn't handle well if user mode trying to run instruction above TASK_SIZE, and result in the infinite retry of that instruction.
--- arch/arm/mm/fault.c | 3 +++ 1 file changed, 3 insertions(+)
arch/arm/mm/fault.c +3 -0
@@ -386,6 +386,9 @@ do_translation_fault(unsigned long addr,if (addr <TASK_SIZE )return do_page_fault (addr, fsr, regs); +if (user_mode (regs)) + goto bad_area; + index =pgd_index (addr);/*
Re: [patch 071/149] ARM: 6166/1: Proper prefetch abort handling on pre-ARMv6
Quoted 6 lines · Greg KH
2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Anfei <[email protected]>
Quoted 7 lines
commit
5e27fb78df95e027723af2c90ecc9b4527ae59e9upstream.Instruction faults on pre-ARMv6 CPUs are interpreted as a 'translation fault', but
do_translation_faultdoesn't handle well if user mode trying to run instruction aboveTASK_SIZE, and result in the infinite retry of that instruction.
Actually, this patch helps also on ARMv6+. Probably, better to correct commit message for stable.
Quoted 27 lines
Signed-off-by Anfei Zhou <[email protected]>Signed-off-by Russell King <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>--- arch/arm/mm/fault.c | 3 +++ 1 file changed, 3 insertions(+)arch/arm/mm/fault.c +3
-1@@ -386,6 +386,9 @@ do_translation_fault(unsigned long addr,if (addr <TASK_SIZE )return do_page_fault (addr, fsr, regs); +if (user_mode (regs)) + goto bad_area; + index =pgd_index (addr);/* -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Signature · 1 line
Kirill A. Shutemov
Re: [patch 071/149] ARM: 6166/1: Proper prefetch abort handling on pre-ARMv6
Quoted 9 lines · Kirill A. Shutemov
Quoted 8 lines · Greg KH
2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Anfei <[email protected]>
commit
5e27fb78df95e027723af2c90ecc9b4527ae59e9upstream.
Quoted 8 lines
Quoted 5 lines
Instruction faults on pre-ARMv6 CPUs are interpreted as a 'translation fault', but
do_translation_faultdoesn't handle well if user mode trying to run instruction aboveTASK_SIZE, and result in the infinite retry of that instruction.Actually, this patch helps also on ARMv6+. Probably, better to correct commit message for stable.
We (well, I) like to keep the commit log identical to what is upstream just to make things easier all around. Otherwise people start asking for spelling fixes, clarifications, and all sorts of other stuff (like this.)
thanks,
greg k-h
Re: [patch 071/149] ARM: 6166/1: Proper prefetch abort handling on pre-ARMv6
Quoted 16 lines · Greg KH
Quoted 15 lines · Kirill A. Shutemov
Quoted 13 lines · Greg KH
2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Anfei <[email protected]>
commit
5e27fb78df95e027723af2c90ecc9b4527ae59e9upstream.Instruction faults on pre-ARMv6 CPUs are interpreted as a 'translation fault', but
do_translation_faultdoesn't handle well if user mode trying to run instruction aboveTASK_SIZE, and result in the infinite retry of that instruction.
Quoted 7 lines
Quoted 2 lines
Actually, this patch helps also on ARMv6+. Probably, better to correct commit message for stable.
We (well, I) like to keep the commit log identical to what is upstream just to make things easier all around. Otherwise people start asking for spelling fixes, clarifications, and all sorts of other stuff (like this.)
Ok, fair enough.
I asked for it because I was confused by this commit message while investigate (the same) problem on ARMv7 CPU.
Signature · 1 line
Kirill A. Shutemov
Re: [patch 071/149] ARM: 6166/1: Proper prefetch abort handling on pre-ARMv6
Quoted 10 lines · Kirill A. Shutemov
Quoted 4 lines · Greg KH
We (well, I) like to keep the commit log identical to what is upstream just to make things easier all around. Otherwise people start asking for spelling fixes, clarifications, and all sorts of other stuff (like this.)
Ok, fair enough.
I asked for it because I was confused by this commit message while investigate (the same) problem on ARMv7 CPU.
You shouldn't get anywhere near this on ARMv7, because we know the cause of the prefetch abort on those CPUs.
On pre-ARMv6 CPUs, we always treat all prefetch aborts as a translation faults. The problem which this commit addresses occurs when userspace tries to execute code above TASK_SIZE - we're sent into a loop of prefetch aborts (because we are unable to determine that it is a permission fault.)
ARMv6 and ARMv7 CPUs have an instruction fault status register, which tells us why the abort happened. On these CPUs, permission faults go nowhere near the translation fault handler.
One possibility is that for some reason you're using the legacy prefetch abort code or pre-IFSR code, which will always tell the kernel that its a translation fault - and in this case, this patch would improve the situation. What kernel version are you using?
The commit message is accurate for the kernel version to which it was originally applied.
Signature · 3 lines
Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of:
Re: [patch 071/149] ARM: 6166/1: Proper prefetch abort handling on pre-ARMv6
Quoted 15 lines · Russell King
Quoted 10 lines · Kirill A. Shutemov
Quoted 4 lines · Greg KH
We (well, I) like to keep the commit log identical to what is upstream just to make things easier all around. Otherwise people start asking for spelling fixes, clarifications, and all sorts of other stuff (like this.)
Ok, fair enough.
I asked for it because I was confused by this commit message while investigate (the same) problem on ARMv7 CPU.
You shouldn't get anywhere near this on ARMv7, because we know the cause of the prefetch abort on those CPUs.
Quoted 8 lines
On pre-ARMv6 CPUs, we always treat all prefetch aborts as a translation faults. The problem which this commit addresses occurs when userspace tries to execute code above
TASK_SIZE- we're sent into a loop of prefetch aborts (because we are unable to determine that it is a permission fault.)ARMv6 and ARMv7 CPUs have an instruction fault status register, which tells us why the abort happened. On these CPUs, permission faults go nowhere near the translation fault handler.
I know it. I was involved in writing this code.
Quoted 4 lines
One possibility is that for some reason you're using the legacy prefetch abort code or pre-IFSR code, which will always tell the kernel that its a translation fault - and in this case, this patch would improve the situation. What kernel version are you using?
2.6.32
Quoted 2 lines
The commit message is accurate for the kernel version to which it was originally applied.
Simple testcase:
#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
int main(int argc, char **argv)
{
int fd;
void (*p)(void);
fd = open("/dev/urandom", O_RDONLY);
read(0, &p, sizeof(p));
printf("p: %p\n", p);
p();
return 0;
}If you run this test in loop on kernel without the patch you'll finally get hung instead SIGSEGV.
It seems the patch fixes more than it was written for. :)
Signature · 1 line
Kirill A. Shutemov
Re: [patch 071/149] ARM: 6166/1: Proper prefetch abort handling on pre-ARMv6
Quoted 7 lines · Kirill A. Shutemov
Quoted 4 lines · Russell King
One possibility is that for some reason you're using the legacy prefetch abort code or pre-IFSR code, which will always tell the kernel that its a translation fault - and in this case, this patch would improve the situation. What kernel version are you using?
2.6.32
Should be recent enough.
Quoted 4 lines
If you run this test in loop on kernel without the patch you'll finally get hung instead SIGSEGV.
It seems the patch fixes more than it was written for. :)
Have you investigated the IFSR and IFAR values, and the corresponding page table state? I'm not going to be able to run your test code for a few days.
Signature · 3 lines
Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of:
Re: [patch 071/149] ARM: 6166/1: Proper prefetch abort handling on pre-ARMv6
Quoted 11 lines · Russell King
Quoted 7 lines · Kirill A. Shutemov
Quoted 4 lines · Russell King
One possibility is that for some reason you're using the legacy prefetch abort code or pre-IFSR code, which will always tell the kernel that its a translation fault - and in this case, this patch would improve the situation. What kernel version are you using?
2.6.32
Should be recent enough.
Quoted 7 lines
Quoted 4 lines
If you run this test in loop on kernel without the patch you'll finally get hung instead SIGSEGV.
It seems the patch fixes more than it was written for. :)
Have you investigated the IFSR and IFAR values, and the corresponding page table state?
In oprofile dump, I saw do_PrefetchAbort() and do_translation_fault() at the top, so I guess IFSR is 5. I don't known value IFAR, but I'll see.
Quoted 2 lines
I'm not going to be able to run your test code for a few days.
It's only few minutes or less if you are lucky.
Signature · 1 line
Kirill A. Shutemov
Re: [patch 071/149] ARM: 6166/1: Proper prefetch abort handling on pre-ARMv6
In reply to Russell KingQuoted 11 lines · Russell King
Quoted 7 lines · Kirill A. Shutemov
Quoted 4 lines · Russell King
One possibility is that for some reason you're using the legacy prefetch abort code or pre-IFSR code, which will always tell the kernel that its a translation fault - and in this case, this patch would improve the situation. What kernel version are you using?
2.6.32
Should be recent enough.
Quoted 8 lines
Quoted 4 lines
If you run this test in loop on kernel without the patch you'll finally get hung instead SIGSEGV.
It seems the patch fixes more than it was written for. :)
Have you investigated the IFSR and IFAR values, and the corresponding page table state? I'm not going to be able to run your test code for a few days.
I've investigated the issue. It's reproducible if you try to jump to the megabyte next to section mapping.
On my OMAP3-based device I use address 0xfc1XXXXX for debugging propose. It's a megabyte next to OMAP343X_SMS mapping.
On ARM one Linux PGD entry contains two hardware entry. But there is error in do_translation_fault(). It's always call pmd_none() check for the first entry of two, not for the entry corresponded to address. So in case if we try to jump the megabyte next to section mapping, we will have inifinity loop of translation faults.
---
arch/arm/mm/fault.c +2 -1
@@ -406,7 +406,8 @@ do_translation_fault(unsigned long addr, unsigned int fsr, pmd_k =pmd_offset (pgd_k, addr); pmd =pmd_offset (pgd, addr); -if (pmd_none (*pmd_k)) + index = (addr >>SECTION_SHIFT ) &1 ; +if (pmd_none (pmd_k[index])) goto bad_area;copy_pmd (pmd, pmd_k);
Signature · 1 line
Kirill A. Shutemov
Re: [patch 071/149] ARM: 6166/1: Proper prefetch abort handling on pre-ARMv6
Quoted 2 lines · Kirill A. Shutemov
I've investigated the issue. It's reproducible if you try to jump to the megabyte next to section mapping.
Okay, this is specific to the way that OMAP sets up its mappings, which is why it doesn't appear everywhere.
Quoted 5 lines
On ARM one Linux PGD entry contains two hardware entry. But there is error in
do_translation_fault(). It's always callpmd_none()check for the first entry of two, not for the entry corresponded to address. So in case if we try to jump the megabyte next to section mapping, we will have inifinity loop of translation faults.
Okay, now that we know _why_ it happens, I'm satisfied that the fix previously committed will help this situation.
arch/arm/mm/fault.c do_translation_fault(unsigned long addr, unsigned int fsr, · line 410
Quoted 11 lines
arch/arm/mm/fault.c +2
-1@@ -406,7 +406,8 @@ do_translation_fault(unsigned long addr, unsigned int fsr, pmd_k =pmd_offset (pgd_k, addr); pmd =pmd_offset (pgd, addr); -if (pmd_none (*pmd_k)) + index = (addr >>SECTION_SHIFT ) &1 ; +if (pmd_none (pmd_k[index]))
I do think this is extremely obscure, and therefore requires a comment to help people understand what is going on here and why. Leaving it in the commit log would be an invitation for this to be needlessly cut'n'pasted.
Signature · 3 lines
Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of:
Re: [patch 071/149] ARM: 6166/1: Proper prefetch abort handling on pre-ARMv6
Quoted 24 lines · Russell King
Quoted 2 lines · Kirill A. Shutemov
I've investigated the issue. It's reproducible if you try to jump to the megabyte next to section mapping.
Okay, this is specific to the way that OMAP sets up its mappings, which is why it doesn't appear everywhere.
Quoted 5 lines
On ARM one Linux PGD entry contains two hardware entry. But there is error in
do_translation_fault(). It's always callpmd_none()check for the first entry of two, not for the entry corresponded to address. So in case if we try to jump the megabyte next to section mapping, we will have inifinity loop of translation faults.Okay, now that we know _why_ it happens, I'm satisfied that the fix previously committed will help this situation.
Quoted 8 lines
arch/arm/mm/fault.c +0
-0@@ -406,7 +406,8 @@ do_translation_fault(unsigned long addr, unsigned int fsr, pmd_k =pmd_offset (pgd_k, addr); pmd =pmd_offset (pgd, addr);
Quoted 8 lines
arch/arm/mm/fault.c do_translation_fault(unsigned long addr, unsigned int fsr, · line 410
Quoted 3 lines
arch/arm/mm/fault.c +2
-1-if (pmd_none (*pmd_k)) + index = (addr >>SECTION_SHIFT ) &1 ; +if (pmd_none (pmd_k[index]))I do think this is extremely obscure, and therefore requires a comment to help people understand what is going on here and why. Leaving it in the commit log would be an invitation for this to be needlessly cut'n'pasted.
Ok, I'll fix it.
But it seems that the problem is more global. Potentially, any of pmd_none() check may produce false results. I don't see an easy way to fix it.
It's not so big problem since we don't have [super]section in userspace, but I guess, we want to have huge pages support in the future.
Any ideas how to fix it in the right way?
Does Linux VM still expect one PTE table per page?
CC list modified. Removed persons who unlikely interested in ARM-specific stuff. linux-arm-kernel and linux-mm added.
Signature · 1 line
Kirill A. Shutemov
Re: [patch 071/149] ARM: 6166/1: Proper prefetch abort handling on pre-ARMv6
Quoted 3 lines · Kirill A. Shutemov
But it seems that the problem is more global. Potentially, any of
pmd_none()check may produce false results. I don't see an easy way to fix it.
It isn't. We normally guarantee that we always fill on both L1 entries. The only exception is for the mappings specified via create_mapping() which is used for the static platform mappings.
Quoted 1 line
Does Linux VM still expect one PTE table per page?
Yes, and as far as I can see probably always will. Hence why we need to put two L1 entries in one page and lie to the kernel about the sizes of the hardware entries.
Re: [patch 071/149] ARM: 6166/1: Proper prefetch abort handling on pre-ARMv6
Quoted 8 lines · Russell King - ARM Linux
Quoted 3 lines · Kirill A. Shutemov
But it seems that the problem is more global. Potentially, any of
pmd_none()check may produce false results. I don't see an easy way to fix it.It isn't. We normally guarantee that we always fill on both L1 entries. The only exception is for the mappings specified via
create_mapping()which is used for the static platform mappings.
Why do not to change create_mapping() to follow the same rules? I mean, create sections only if it asked for 2*SECTION_SIZE with appropriate alignment. It reduces number of section mappings, but, probably, will be a bit cleaner and less error-prune.
Quoted 5 lines
Quoted 1 line
Does Linux VM still expect one PTE table per page?
Yes, and as far as I can see probably always will. Hence why we need to put two L1 entries in one page and lie to the kernel about the sizes of the hardware entries.
Another option is leave half of page with PTE table free. Is it very bad idea?
How other architectures handle it? Or only on ARM PTL table size is less than page size?
Signature · 1 line
Kirill A. Shutemov
Re: [patch 071/149] ARM: 6166/1: Proper prefetch abort handling on pre-ARMv6
Quoted 21 lines · Kirill A. Shutemov
Quoted 8 lines · Russell King - ARM Linux
Quoted 3 lines · Kirill A. Shutemov
But it seems that the problem is more global. Potentially, any of
pmd_none()check may produce false results. I don't see an easy way to fix it.It isn't. We normally guarantee that we always fill on both L1 entries. The only exception is for the mappings specified via
create_mapping()which is used for the static platform mappings.Why do not to change
create_mapping()to follow the same rules? I mean, create sections only if it asked for 2*SECTION_SIZE with appropriate alignment. It reduces number of section mappings, but, probably, will be a bit cleaner and less error-prune.Quoted 5 lines
Quoted 1 line
Does Linux VM still expect one PTE table per page?
Yes, and as far as I can see probably always will. Hence why we need to put two L1 entries in one page and lie to the kernel about the sizes of the hardware entries.
Quoted 5 lines
Another option is leave half of page with PTE table free. Is it very bad idea?
How other architectures handle it? Or only on ARM PTL table size is less than page size?
Russell, any comments? I would like to fix it in a right way.
Signature · 1 line
Kirill A. Shutemov
PATCH 72/149 ARM: 6164/1: Add kto and kfrom to input operands list.
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Khem Raj <[email protected]>
commit 9a40ac86152c9cffd3dca482a15ddf9a8c5716b3 upstream.
When functions incoming parameters are not in input operands list gcc 4.5 does not load the parameters into registers before calling this function but the inline assembly assumes valid addresses inside this function. This breaks the code because r0 and r1 are invalid when execution enters v4wb_copy_user_page ()
Also the constant needs to be used as third input operand so account for that as well.
Tested on qemu arm.
--- arch/arm/mm/copypage-feroceon.c | 4 ++-- arch/arm/mm/copypage-v4wb.c | 4 ++-- arch/arm/mm/copypage-v4wt.c | 4 ++-- arch/arm/mm/copypage-xsc3.c | 4 ++-- 4 files changed, 8 insertions(+), 8 deletions(-)
arch/arm/mm/copypage-feroceon.c +2 -2
@@ -18,7 +18,7 @@ feroceon_copy_user_page(void *kto, const { asm("\ stmfd sp!, {r4-r9, lr} \n\ - mov ip, %0 \n\ + mov ip, %2 \n\ 1: mov lr, r1 \n\ ldmia r1!, {r2 - r9} \n\ pld [lr, #32] \n\
@@ -64,7 +64,7 @@ feroceon_copy_user_page(void *kto, const mcr p15, 0, ip, c7, c10, 4 @ drain WB\n\ ldmfd sp!, {r4-r9, pc}" : - : "I" (PAGE_SIZE)); + : "r" (kto), "r" (kfrom), "I" (PAGE_SIZE)); } void feroceon_copy_user_highpage(struct page *to, struct page *from,
arch/arm/mm/copypage-v4wb.c +2 -2
@@ -27,7 +27,7 @@ v4wb_copy_user_page(void *kto, const voi { asm("\ stmfd sp!, {r4, lr} @ 2\n\ - mov r2, %0 @ 1\n\ + mov r2, %2 @ 1\n\ ldmia r1!, {r3, r4, ip, lr} @ 4\n\ 1: mcr p15, 0, r0, c7, c6, 1 @ 1 invalidate D line\n\ stmia r0!, {r3, r4, ip, lr} @ 4\n\
@@ -44,7 +44,7 @@ v4wb_copy_user_page(void *kto, const voi mcr p15, 0, r1, c7, c10, 4 @ 1 drain WB\n\ ldmfd sp!, {r4, pc} @ 3" : - : "I" (PAGE_SIZE / 64)); + : "r" (kto), "r" (kfrom), "I" (PAGE_SIZE / 64)); } void v4wb_copy_user_highpage(struct page *to, struct page *from,
arch/arm/mm/copypage-v4wt.c +2 -2
@@ -25,7 +25,7 @@ v4wt_copy_user_page(void *kto, const voi { asm("\ stmfd sp!, {r4, lr} @ 2\n\ - mov r2, %0 @ 1\n\ + mov r2, %2 @ 1\n\ ldmia r1!, {r3, r4, ip, lr} @ 4\n\ 1: stmia r0!, {r3, r4, ip, lr} @ 4\n\ ldmia r1!, {r3, r4, ip, lr} @ 4+1\n\
@@ -40,7 +40,7 @@ v4wt_copy_user_page(void *kto, const voi mcr p15, 0, r2, c7, c7, 0 @ flush ID cache\n\ ldmfd sp!, {r4, pc} @ 3" : - : "I" (PAGE_SIZE / 64)); + : "r" (kto), "r" (kfrom), "I" (PAGE_SIZE / 64)); } void v4wt_copy_user_highpage(struct page *to, struct page *from,
arch/arm/mm/copypage-xsc3.c +2 -2
@@ -34,7 +34,7 @@ xsc3_mc_copy_user_page(void *kto, const { asm("\ stmfd sp!, {r4, r5, lr} \n\ - mov lr, %0 \n\ + mov lr, %2 \n\ \n\ pld [r1, #0] \n\ pld [r1, #32] \n\
@@ -67,7 +67,7 @@ xsc3_mc_copy_user_page(void *kto, const \n\ ldmfd sp!, {r4, r5, pc}" : - : "I" (PAGE_SIZE / 64 - 1)); + : "r" (kto), "r" (kfrom), "I" (PAGE_SIZE / 64 - 1)); } void xsc3_mc_copy_user_highpage(struct page *to, struct page *from,
PATCH 73/149 ARM: 6146/1: sa1111: Prevent deadlock in resume path
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: =?UTF-8?q?Marek=20Va=C5=A1ut?= <[email protected]>
commit 3defb2476166445982a90c12d33f8947e75476c4 upstream.
This patch reorganises the sa1111_resume() function in a manner the spinlock happens after calling the sa1111_wake(). This fixes two bugs:
1) This function called sa1111_wake() which tried to claim the same spinlock the sa1111_resume() already claimed. This would result in certain deadlock.
Original idea for this part: Russell King <[email protected]>
2) The function didn't unlock the spinlock in case the chip didn't report correct ID.
Original idea for this part: Julia Lawall <[email protected]>
--- arch/arm/common/sa1111.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
arch/arm/common/sa1111.c +7 -2
@@ -887,8 +887,6 @@ static int sa1111_resume(struct platformif (!save)return 0 ; -spin_lock_irqsave (&sachip->lock, flags); -/* * Ensure that the SA1111 is still here. * FIXME: shouldn't do this here.
@@ -905,6 +903,13 @@ static int sa1111_resume(struct platform* First of all, wake up the chip. */ sa1111_wake (sachip); + +/* +* Only lock for write ops. Also, sa1111_wake must be called with +* released spinlock! +*/ +spin_lock_irqsave (&sachip->lock, flags); +sa1111_writel (0 , sachip->base +SA1111_INTC +SA1111_INTEN0 );sa1111_writel (0 , sachip->base +SA1111_INTC +SA1111_INTEN1 );
PATCH 74/149 ARM: 6144/1: TCM memory bug freeing bug
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Linus Walleij <[email protected]>
commit ea208f646c8fb91c39c852e952fc911e1ad045ab upstream.
This fixes a bug in mm/init.c when freeing the TCM compile memory, this was being referred to as a char * which is incorrect: this will dereference the pointer and feed in the value at the location instead of the address to it. Change it to a plain char and use &(char) to reference it.
--- arch/arm/mm/init.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
arch/arm/mm/init.c +3 -3
@@ -632,10 +632,10 @@ void __init mem_init(void)void free_initmem (void ) {#ifdef CONFIG_HAVE_TCM -extern char *__tcm_start, *__tcm_end; +extern char __tcm_start, __tcm_end; - totalram_pages +=free_area (__phys_to_pfn (__pa (__tcm_start)), -__phys_to_pfn (__pa (__tcm_end)), + totalram_pages +=free_area (__phys_to_pfn (__pa (&__tcm_start)), +__phys_to_pfn (__pa (&__tcm_end)),"TCM link" );#endif
PATCH 75/149 ARM: VFP: Fix vfp_put_double() for d16-d31
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Russell King <[email protected]>
commit 138de1c44a8e0606501cd8593407e9248e84f1b7 upstream.
vfp_put_double() takes the double value in r0,r1 not r1,r2.
--- arch/arm/vfp/vfphw.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/vfp/vfphw.S +1 -1
@@ -277,7 +277,7 @@ ENTRY(vfp_put_double) #ifdef CONFIG_VFPv3 @ d16 - d31 registers .irp dr,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15 -1: mcrr p11, 3, r1, r2, c\dr @ fmdrr r1, r2, d\dr +1: mcrr p11, 3, r0, r1, c\dr @ fmdrr r0, r1, d\dr mov pc, lr .org 1b + 8 .endr
PATCH 76/149 ASoC: Fix dB scales for WM835x
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Mark Brown <[email protected]>
commit e6a08c5a8990102bcd1f4bae84b668da6c23caa9 upstream.
These should be regular rather than linear scales.
--- sound/soc/codecs/wm8350.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
sound/soc/codecs/wm8350.c +2 -2
@@ -423,8 +423,8 @@ static const struct soc_enum wm8350_enum SOC_ENUM_SINGLE(WM8350_INPUT_MIXER_VOLUME, 15, 2, wm8350_lr), }; -static DECLARE_TLV_DB_LINEAR(pre_amp_tlv, -1200, 3525); -static DECLARE_TLV_DB_LINEAR(out_pga_tlv, -5700, 600); +static DECLARE_TLV_DB_SCALE(pre_amp_tlv, -1200, 3525, 0); +static DECLARE_TLV_DB_SCALE(out_pga_tlv, -5700, 600, 0); static DECLARE_TLV_DB_SCALE(dac_pcm_tlv, -7163, 36, 1); static DECLARE_TLV_DB_SCALE(adc_pcm_tlv, -12700, 50, 1); static DECLARE_TLV_DB_SCALE(out_mix_tlv, -1500, 300, 1);
PATCH 77/149 ASoC: Fix dB scales for WM8400
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Mark Brown <[email protected]>
commit 3351e9fbb0fda6498ee149ee88c67f5849813c57 upstream.
These scales should be regular, not linear.
--- sound/soc/codecs/wm8400.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-)
sound/soc/codecs/wm8400.c +9 -9
@@ -106,21 +106,21 @@ static void wm8400_codec_reset(struct snwm8400_reset_codec_reg_cache (wm8400->wm8400); } -static const DECLARE_TLV_DB_LINEAR(rec_mix_tlv, -1500, 600); +static const DECLARE_TLV_DB_SCALE(rec_mix_tlv, -1500, 600, 0); -static const DECLARE_TLV_DB_LINEAR(in_pga_tlv, -1650, 3000); +static const DECLARE_TLV_DB_SCALE(in_pga_tlv, -1650, 3000, 0); -static const DECLARE_TLV_DB_LINEAR(out_mix_tlv, -2100, 0); +static const DECLARE_TLV_DB_SCALE(out_mix_tlv, -2100, 0, 0); -static const DECLARE_TLV_DB_LINEAR(out_pga_tlv, -7300, 600); +static const DECLARE_TLV_DB_SCALE(out_pga_tlv, -7300, 600, 0); -static const DECLARE_TLV_DB_LINEAR(out_omix_tlv, -600, 0); +static const DECLARE_TLV_DB_SCALE(out_omix_tlv, -600, 0, 0); -static const DECLARE_TLV_DB_LINEAR(out_dac_tlv, -7163, 0); +static const DECLARE_TLV_DB_SCALE(out_dac_tlv, -7163, 0, 0); -static const DECLARE_TLV_DB_LINEAR(in_adc_tlv, -7163, 1763); +static const DECLARE_TLV_DB_SCALE(in_adc_tlv, -7163, 1763, 0); -static const DECLARE_TLV_DB_LINEAR(out_sidetone_tlv, -3600, 0); +static const DECLARE_TLV_DB_SCALE(out_sidetone_tlv, -3600, 0, 0);static int wm8400_outpga_put_volsw_vu (struct snd_kcontrol *kcontrol,struct snd_ctl_elem_value *ucontrol)
@@ -439,7 +439,7 @@ static int outmixer_event (struct snd_so/* INMIX dB values */ static const unsigned int in_mix_tlv[] = {TLV_DB_RANGE_HEAD (1 ), -0 ,7 ,TLV_DB_LINEAR_ITEM (-1200 ,600 ), +0 ,7 ,TLV_DB_SCALE_ITEM (-1200 ,600 ,0 ), };/* Left In PGA Connections */
PATCH 78/149 ASoC: Fix dB scales for WM8990
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Mark Brown <[email protected]>
commit f68596c6d8711650722b2a54328a088a2c21bc5b upstream.
These should be regular, not linear.
--- sound/soc/codecs/wm8990.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-)
sound/soc/codecs/wm8990.c +9 -9
@@ -110,21 +110,21 @@ static const u16 wm8990_reg[] = {#define wm8990_reset (c) snd_soc_write(c, WM8990_RESET, 0) -static const DECLARE_TLV_DB_LINEAR(rec_mix_tlv, -1500, 600); +static const DECLARE_TLV_DB_SCALE(rec_mix_tlv, -1500, 600, 0); -static const DECLARE_TLV_DB_LINEAR(in_pga_tlv, -1650, 3000); +static const DECLARE_TLV_DB_SCALE(in_pga_tlv, -1650, 3000, 0); -static const DECLARE_TLV_DB_LINEAR(out_mix_tlv, 0, -2100); +static const DECLARE_TLV_DB_SCALE(out_mix_tlv, 0, -2100, 0); -static const DECLARE_TLV_DB_LINEAR(out_pga_tlv, -7300, 600); +static const DECLARE_TLV_DB_SCALE(out_pga_tlv, -7300, 600, 0); -static const DECLARE_TLV_DB_LINEAR(out_omix_tlv, -600, 0); +static const DECLARE_TLV_DB_SCALE(out_omix_tlv, -600, 0, 0); -static const DECLARE_TLV_DB_LINEAR(out_dac_tlv, -7163, 0); +static const DECLARE_TLV_DB_SCALE(out_dac_tlv, -7163, 0, 0); -static const DECLARE_TLV_DB_LINEAR(in_adc_tlv, -7163, 1763); +static const DECLARE_TLV_DB_SCALE(in_adc_tlv, -7163, 1763, 0); -static const DECLARE_TLV_DB_LINEAR(out_sidetone_tlv, -3600, 0); +static const DECLARE_TLV_DB_SCALE(out_sidetone_tlv, -3600, 0, 0);static int wm899x_outpga_put_volsw_vu (struct snd_kcontrol *kcontrol,struct snd_ctl_elem_value *ucontrol)
@@ -450,7 +450,7 @@ static int outmixer_event(struct snd_soc/* INMIX dB values */ static const unsigned int in_mix_tlv[] = {TLV_DB_RANGE_HEAD (1 ), -0 ,7 ,TLV_DB_LINEAR_ITEM (-1200 ,600 ), +0 ,7 ,TLV_DB_SCALE_ITEM (-1200 ,600 ,0 ), };/* Left In PGA Connections */
PATCH 79/149 drm/radeon: r100/r200 ums: block ability for userspace app to trash 0 page and beyond
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Dave Airlie <[email protected]>
commit 566d84d172161cb6c0c4dd834c34abbac6bf7b38 upstream.
radeon's have a special ability to passthrough writes in their internal memory space directly to PCI, this ability means that if some of the internal surfaces like the depth buffer point at 0x0, any writes to these will go directly to RAM at 0x0 via PCI busmastering.
Now mesa used to always emit clears after emitting state, since the radeon mesa driver was refactored a year or more ago, it was found it could generate a clear request without ever sending any setup state to the card. So the clear would attempt to clear the depth buffer at 0x0, which would overwrite main memory at this point. fs corruption ensues.
Also once one app did this correctly, it would never get set back to 0 making this messy to reproduce.
The kernel should block this from happening as mesa runs without privs, though it does require the user be connected to the current running X session.
This patch implements a check to make sure the depth offset has been set before a depth clear occurs and if it finds one it prints a warning and ignores the depth clear request. There is also a mesa fix to avoid sending the badness going into mesa.
This only affects r100/r200 GPUs in user modesetting mode.
--- drivers/gpu/drm/radeon/radeon_cp.c | 1 + drivers/gpu/drm/radeon/radeon_drv.h | 2 ++ drivers/gpu/drm/radeon/radeon_state.c | 6 ++++++ 3 files changed, 9 insertions(+)
drivers/gpu/drm/radeon/radeon_cp.c +1 -0
@@ -1646,6 +1646,7 @@ static int radeon_do_resume_cp(struct drradeon_cp_load_microcode (dev_priv);radeon_cp_init_ring_buffer (dev, dev_priv, file_priv); + dev_priv->have_z_offset =0 ;radeon_do_engine_reset (dev);radeon_irq_set_state (dev,RADEON_SW_INT_ENABLE ,1 );
drivers/gpu/drm/radeon/radeon_drv.h +2 -0
@@ -267,6 +267,8 @@ typedef struct drm_radeon_private {u32 scratch_ages[5 ]; +int have_z_offset; +/* starting from here on, data is preserved accross an open */ uint32_t flags;/* see radeon_chip_flags */ resource_size_t fb_aper_offset;
drivers/gpu/drm/radeon/radeon_state.c +6 -0
@@ -101,6 +101,7 @@ static __inline__ int radeon_check_and_fDRM_ERROR ("Invalid depth buffer offset\n" );return -EINVAL ; } + dev_priv->have_z_offset =1 ;break ;case RADEON_EMIT_PP_CNTL :
@@ -876,6 +877,11 @@ static void radeon_cp_dispatch_clear(strif (tmp &RADEON_BACK ) flags |=RADEON_FRONT ; } +if (flags & (RADEON_DEPTH |RADEON_STENCIL )) { +if (!dev_priv->have_z_offset) +printk_once (KERN_ERR "radeon: illegal depth clear request. Buggy mesa detected - please update.\n" ); + flags &= ~(RADEON_DEPTH |RADEON_STENCIL ); + }if (flags & (RADEON_FRONT |RADEON_BACK )) {
PATCH 80/149 drm/radeon: fix the r100/r200 ums block 0 page fix
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Dave Airlie <[email protected]>
commit cf22f20ade30f8c03955324aaf27b1049e182600 upstream.
airlied -> brown paper bag.
I blame Hi-5 or the Wiggles for lowering my IQ, move the fix inside some brackets instead of breaking everything in site.
--- drivers/gpu/drm/radeon/radeon_state.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/gpu/drm/radeon/radeon_state.c +3 -2
@@ -878,9 +878,10 @@ static void radeon_cp_dispatch_clear(str flags |=RADEON_FRONT ; }if (flags & (RADEON_DEPTH |RADEON_STENCIL )) { -if (!dev_priv->have_z_offset) +if (!dev_priv->have_z_offset) {printk_once (KERN_ERR "radeon: illegal depth clear request. Buggy mesa detected - please update.\n" ); - flags &= ~(RADEON_DEPTH |RADEON_STENCIL ); + flags &= ~(RADEON_DEPTH |RADEON_STENCIL ); + } }if (flags & (RADEON_FRONT |RADEON_BACK )) {
PATCH 81/149 hwmon: (ltc4245) Read only one GPIO pin
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Ira W. Snyder <[email protected]>
commit df16dd53c575d0cb9dbee20a3149927c862a9ff6 upstream.
Read only one of the GPIO pins as an analog voltage. The ADC can be switched to a different GPIO pin at runtime, but this is not supported.
Previously, this driver would report the analog voltage of the currently selected GPIO pin as all three GPIO voltages: in9_input, in10_input and in11_input.
--- Documentation/hwmon/ltc4245 | 4 +--- drivers/hwmon/ltc4245.c | 18 +++++------------- 2 files changed, 6 insertions(+), 16 deletions(-)
Documentation/hwmon/ltc4245 +1 -3
@@ -72,9 +72,7 @@ in6_min_alarm 5v output undervoltage a in7_min_alarm 3v output undervoltage alarm in8_min_alarm Vee (-12v) output undervoltage alarm -in9_input GPIO #1 voltage data -in10_input GPIO #2 voltage data -in11_input GPIO #3 voltage data +in9_input GPIO voltage data power1_input 12v power usage (mW) power2_input 5v power usage (mW)
drivers/hwmon/ltc4245.c +5 -13
@@ -45,9 +45,7 @@ enum ltc4245_cmd {LTC4245_VEEIN =0x19 ,LTC4245_VEESENSE =0x1a ,LTC4245_VEEOUT =0x1b , -LTC4245_GPIOADC1 =0x1c , -LTC4245_GPIOADC2 =0x1d , - LTC4245_GPIOADC3 = 0x1e, + LTC4245_GPIOADC = 0x1c, }; struct ltc4245_data {
@@ -61,7 +59,7 @@ struct ltc4245_data {u8 cregs[0x08 ];/* Voltage registers */ -u8 vregs[0x0f ]; +u8 vregs[0x0d ]; };static struct ltc4245_data *ltc4245_update_device (struct device *dev)
@@ -86,7 +84,7 @@ static struct ltc4245_data *ltc4245_upda data->cregs[i] = val; } -/* Read voltage registers -- 0x10 to 0x1f */ +/* Read voltage registers -- 0x10 to 0x1c */ for (i =0 ; i <ARRAY_SIZE (data->vregs); i++) { val =i2c_smbus_read_byte_data (client, i+0x10 );if (unlikely (val <0 ))
@@ -128,9 +126,7 @@ static int ltc4245_get_voltage(struct decase LTC4245_VEEOUT : voltage = regval *-55 ;break ; -case LTC4245_GPIOADC1 : -case LTC4245_GPIOADC2 : -case LTC4245_GPIOADC3 : +case LTC4245_GPIOADC : voltage = regval *10 ;break ;default :
@@ -297,9 +293,7 @@ LTC4245_ALARM(in7_min_alarm, (1 << 2), LLTC4245_ALARM (in8_min_alarm, (1 <<3 ),LTC4245_FAULT2 );/* GPIO voltages */ -LTC4245_VOLTAGE (in9_input,LTC4245_GPIOADC1 ); -LTC4245_VOLTAGE (in10_input,LTC4245_GPIOADC2 ); -LTC4245_VOLTAGE (in11_input,LTC4245_GPIOADC3 ); +LTC4245_VOLTAGE (in9_input,LTC4245_GPIOADC );/* Power Consumption (virtual) */ LTC4245_POWER (power1_input,LTC4245_12VSENSE );
@@ -342,8 +336,6 @@ static struct attribute *ltc4245_attribu &sensor_dev_attr_in8_min_alarm.dev_attr.attr, &sensor_dev_attr_in9_input.dev_attr.attr, - &sensor_dev_attr_in10_input.dev_attr.attr, - &sensor_dev_attr_in11_input.dev_attr.attr, &sensor_dev_attr_power1_input.dev_attr.attr, &sensor_dev_attr_power2_input.dev_attr.attr,
PATCH 82/149 signals: check_kill_permission(): dont check creds if same_thread_group()
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Oleg Nesterov <[email protected]>
commit 065add3941bdca54fe04ed3471a96bce9af88793 upstream.
Andrew Tridgell reports that aio_read(SIGEV_SIGNAL) can fail if the notification from the helper thread races with setresuid(), see
http://samba.org/~tridge/junkcode/aio_uid.c
This happens because check_kill_permission() doesn't permit sending a signal to the task with the different cred->xids. But there is not any security reason to check ->cred's when the task sends a signal (private or group-wide) to its sub-thread. Whatever we do, any thread can bypass all security checks and send SIGKILL to all threads, or it can block a signal SIG and do kill(gettid(), SIG) to deliver this signal to another sub-thread. Not to mention that CLONE_THREAD implies CLONE_VM.
Change check_kill_permission() to avoid the credentials check when the sender and the target are from the same thread group.
Also, move "cred = current_cred()" down to avoid calling get_current() twice.
Note: David Howells pointed out we could relax this even more, the CLONE_SIGHAND (without CLONE_THREAD) case probably does not need these checks too.
Roland said:
: The glibc (libpthread) that does set*id across threads has
: been in use for a while (2.3.4?), probably in distro's using kernels as old : or older than any active -stable streams. In the race in question, this : kernel bug is breaking valid POSIX application expectations.
--- kernel/signal.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
kernel/signal.c +4 -2
@@ -591,7 +591,7 @@ static int rm_from_queue(unsigned long mstatic int check_kill_permission (int sig,struct siginfo *info,struct task_struct *t) { -const struct cred *cred =current_cred (), *tcred; +const struct cred *cred, *tcred;struct pid *sid;int error;
@@ -605,8 +605,10 @@ static int check_kill_permission(int sigif (error)return error; + cred =current_cred (); tcred =__task_cred (t); - if ((cred->euid ^ tcred->suid) && + if (!same_thread_group(current, t) && + (cred->euid ^ tcred->suid) && (cred->euid ^ tcred->uid) && (cred->uid ^ tcred->suid) && (cred->uid ^ tcred->uid) &&
PATCH 83/149 do_generic_file_read: clear page errors when issuing a fresh read of the page
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Jeff Moyer <[email protected]>
commit 91803b499cca2fe558abad709ce83dc896b80950 upstream.
I/O errors can happen due to temporary failures, like multipath errors or losing network contact with the iSCSI server. Because of that, the VM will retry readpage on the page.
However, do_generic_file_read does not clear PG_error. This causes the system to be unable to actually use the data in the page cache page, even if the subsequent readpage completes successfully!
The function filemap_fault has had a ClearPageError before readpage forever. This patch simply adds the same to do_generic_file_read.
--- mm/filemap.c | 6 ++++++ 1 file changed, 6 insertions(+)
mm/filemap.c +6 -0
@@ -1120,6 +1120,12 @@ page_not_up_to_date_locked: } readpage: +/* +* A previous I/O error may have been due to temporary +* failures, eg. multipath errors. +* PG_error will be set again if readpage fails. +*/ +ClearPageError (page);/* Start the actual read. The read will unlock the page. */ error = mapping->a_ops->readpage (filp, page);
PATCH 84/149 ipmi: handle run_to_completion properly in deliver_recv_msg()
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Jiri Kosina <[email protected]>
commit a747c5abc329611220f16df0bb4cf0ca4a7fdf0c upstream.
If run_to_completion flag is set, it means that we are running in a single-threaded mode, and thus no locks are held.
This fixes a deadlock when IPMI notifier is being called during panic.
--- drivers/char/ipmi/ipmi_si_intf.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-)
drivers/char/ipmi/ipmi_si_intf.c +8 -3
@@ -310,9 +310,14 @@ static void deliver_recv_msg(struct smi_ {/* Deliver the message to the upper layer with the lock released. */ -spin_unlock (&(smi_info->si_lock)); -ipmi_smi_msg_received (smi_info->intf, msg); -spin_lock (&(smi_info->si_lock)); + +if (smi_info->run_to_completion) { +ipmi_smi_msg_received (smi_info->intf, msg); + }else { +spin_unlock (&(smi_info->si_lock)); +ipmi_smi_msg_received (smi_info->intf, msg); +spin_lock (&(smi_info->si_lock)); + } }static void return_hosed_msg (struct smi_info *smi_info,int cCode)
PATCH 85/149 x86, setup: Phoenix BIOS fixup is needed on Dell Inspiron Mini 1012
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Gabor Gombas <[email protected]>
commit 3d6e77a3ddb8e4156b89f4273ff8c7d37abaf781 upstream.
The low-memory corruption checker triggers during suspend/resume, so we need to reserve the low 64k. Don't be fooled that the BIOS identifies itself as "Dell Inc.", it's still Phoenix BIOS.
[ hpa: I think we blacklist almost every BIOS in existence. We should either change this to a whitelist or just make it unconditional. ]
LKML-Reference: <[email protected]>
--- arch/x86/kernel/setup.c | 11 +++++++++++ 1 file changed, 11 insertions(+)
arch/x86/kernel/setup.c +11 -0
@@ -688,6 +688,17 @@ static struct dmi_system_id __initdata b DMI_MATCH(DMI_BOARD_NAME, "DG45FC"), }, }, + /* + * The Dell Inspiron Mini 1012 has DMI_BIOS_VENDOR = "Dell Inc.", so + * match on the product name. + */ + { + .callback = dmi_low_memory_corruption, + .ident = "Phoenix BIOS", + .matches = { + DMI_MATCH(DMI_PRODUCT_NAME, "Inspiron 1012"), + }, + }, #endif {} };
PATCH 86/149 xen: ensure timer tick is resumed even on CPU driving the resume
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Ian Campbell <[email protected]>
commit cd52e17ea8278f8449b6174a8e5ed439a2e44ffb upstream.
The core suspend/resume code is run from stop_machine on CPU0 but parts of the suspend/resume machinery (including xen_arch_resume) are run on whichever CPU happened to schedule the xenwatch kernel thread.
As part of the non-core resume code xen_arch_resume is called in order to restart the timer tick on non-boot processors. The boot processor itself is taken care of by core timekeeping code.
xen_arch_resume uses smp_call_function which does not call the given function on the current processor. This means that we can end up with one CPU not receiving timer ticks if the xenwatch thread happened to be scheduled on CPU > 0.
Use on_each_cpu instead of smp_call_function to ensure the timer tick is resumed everywhere.
--- arch/x86/xen/suspend.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/x86/xen/suspend.c +2 -2
@@ -60,6 +60,6 @@ static void xen_vcpu_notify_restore(voidvoid xen_arch_resume (void ) { -smp_call_function (xen_vcpu_notify_restore, - (void *)CLOCK_EVT_NOTIFY_RESUME ,1 ); +on_each_cpu (xen_vcpu_notify_restore, + (void *)CLOCK_EVT_NOTIFY_RESUME ,1 ); }
PATCH 87/149 xen: avoid allocation causing potential swap activity on the resume path
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Ian Campbell <[email protected]>
commit b3831cb55d383e8eb55d3b56c715fb48459b87c9 upstream.
Since the device we are resuming could be the device containing the swap device we should ensure that the allocation cannot cause IO.
On resume, this path is triggered when the running system tries to continue using its devices. If it cannot then the resume will fail; to try to avoid this we let it dip into the emergency pools.
The majority of these changes were made when linux-2.6.18-xen.hg changeset e8b49cfbdac0 was ported upstream in a144ff09bc52ef3f3684ed23eadc9c7c0e57b3aa but somehow this hunk was dropped.
--- drivers/xen/xenbus/xenbus_xs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/xen/xenbus/xenbus_xs.c +1 -1
@@ -499,7 +499,7 @@ int xenbus_printf(struct xenbus_transact#define PRINTF_BUFFER_SIZE 4096char *printf_buffer; - printf_buffer =kmalloc (PRINTF_BUFFER_SIZE ,GFP_KERNEL ); + printf_buffer =kmalloc (PRINTF_BUFFER_SIZE ,GFP_NOIO | __GFP_HIGH);if (printf_buffer ==NULL )return -ENOMEM ;
PATCH 88/149 ALSA: hda: Use LPIB for an ASUS device
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Daniel T Chen <[email protected]>
commit dd37f8e8659bc617c3f2a84e007a4824ccdac458 upstream.
Symptom: On the reporter's ASUS device, using PulseAudio in Ubuntu 10.04 LTS results in the PA daemon crashing shortly after attempting to select capture or to configure the audio hardware profile.
Test case: Using Ubuntu 10.04 LTS (Linux 2.6.32.12), Linux 2.6.33, or Linux 2.6.34, adjust the HDA device's capture volume with PulseAudio.
Resolution: add SSID for this machine to the position_fix quirk table, explicitly specifying the LPIB method.
--- sound/pci/hda/hda_intel.c | 1 + 1 file changed, 1 insertion(+)
sound/pci/hda/hda_intel.c +1 -0
@@ -2232,6 +2232,7 @@ static struct snd_pci_quirk position_fixSND_PCI_QUIRK (0x103c ,0x306d ,"HP dv3" ,POS_FIX_LPIB ),SND_PCI_QUIRK (0x1028 ,0x01f6 ,"Dell Latitude 131L" ,POS_FIX_LPIB ),SND_PCI_QUIRK (0x1043 ,0x813d ,"ASUS P5AD2" ,POS_FIX_LPIB ), +SND_PCI_QUIRK (0x1043 ,0x81b3 ,"ASUS" ,POS_FIX_LPIB ),SND_PCI_QUIRK (0x104d ,0x9069 ,"Sony VPCS11V9E" ,POS_FIX_LPIB ),SND_PCI_QUIRK (0x1106 ,0x3288 ,"ASUS M2V-MX SE" ,POS_FIX_LPIB ), SND_PCI_QUIRK(0x1179, 0xff10, "Toshiba A100-259", POS_FIX_LPIB),
PATCH 89/149 ALSA: hda: Use mb31 quirk for an iMac model
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Daniel T Chen <[email protected]>
commit 26fd74fc01991a18f0e3bd54f8b1b75945ee3dbb upstream.
Symptom: On the reporter's iMac, in Ubuntu 10.04 LTS neither playback nor capture appear audible out-of-the-box.
Test case: Boot from an Ubuntu 10.04 LTS live cd or from an installed configuration and attempt to play or capture audio.
Resolution: Specify the mb31 quirk for this machine in the codec SSID table.
--- sound/pci/hda/patch_realtek.c | 1 + 1 file changed, 1 insertion(+)
sound/pci/hda/patch_realtek.c +1 -0
@@ -8937,6 +8937,7 @@ static struct snd_pci_quirk alc882_ssid_SND_PCI_QUIRK (0x106b ,0x1000 ,"iMac 24" ,ALC885_IMAC24 ),SND_PCI_QUIRK (0x106b ,0x2800 ,"AppleTV" ,ALC885_IMAC24 ),SND_PCI_QUIRK (0x106b ,0x2c00 ,"MacbookPro rev3" ,ALC885_MBP3 ), +SND_PCI_QUIRK (0x106b ,0x3000 ,"iMac" ,ALC889A_MB31 ),SND_PCI_QUIRK (0x106b ,0x3600 ,"Macbook 3,1" ,ALC889A_MB31 ),SND_PCI_QUIRK (0x106b ,0x3800 ,"MacbookPro 4,1" ,ALC885_MBP3 ), SND_PCI_QUIRK(0x106b, 0x3e00, "iMac 24 Aluminum", ALC885_IMAC24),
PATCH 90/149 ALSA: hda: Use LPIB for another mainboard
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Daniel T Chen <[email protected]>
commit b90c076424da8166797bdc34187660fd0124f530 upstream.
Symptom: on the original reporter's VIA VT1708-based board, the PulseAudio daemon dies shortly after the user attempts to play an audio file.
Test case: boot from Ubuntu 10.04 LTS live cd; attempt to play an audio file.
Resolution: add SSID for the original reporter's hardware to the position_fix quirk table, explicitly specifying the LPIB method.
--- sound/pci/hda/hda_intel.c | 1 + 1 file changed, 1 insertion(+)
sound/pci/hda/hda_intel.c +1 -0
@@ -2241,6 +2241,7 @@ static struct snd_pci_quirk position_fixSND_PCI_QUIRK (0x1462 ,0x1002 ,"MSI Wind U115" ,POS_FIX_LPIB ),SND_PCI_QUIRK (0x1565 ,0x820f ,"Biostar Microtech" ,POS_FIX_LPIB ),SND_PCI_QUIRK (0x1565 ,0x8218 ,"Biostar Microtech" ,POS_FIX_LPIB ), +SND_PCI_QUIRK (0x1849 ,0x0888 ,"775Dual-VSTA" ,POS_FIX_LPIB ),SND_PCI_QUIRK (0x8086 ,0x2503 ,"DG965OT AAD63733-203" ,POS_FIX_LPIB ), SND_PCI_QUIRK(0x8086, 0xd601, "eMachines T5212", POS_FIX_LPIB), {}
PATCH 91/149 ALSA: hda: Use LPIB for ASUS M2V
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Daniel T Chen <[email protected]>
commit 9f75c1b12c5ef392ddcea575b13560842c28b1b3 upstream.
Symptom: On the reporter's ASUS M2V, using PulseAudio in Ubuntu 10.04 LTS results in the PA daemon crashing shortly after attempting playback of an audio file.
Test case: Using Ubuntu 10.04 LTS (Linux 2.6.32.12), Linux 2.6.33, or Linux 2.6.34, attempt playback of an audio file while PulseAudio is active.
Resolution: add SSID for this machine to the position_fix quirk table, explicitly specifying the LPIB method.
--- sound/pci/hda/hda_intel.c | 1 + 1 file changed, 1 insertion(+)
sound/pci/hda/hda_intel.c +1 -0
@@ -2233,6 +2233,7 @@ static struct snd_pci_quirk position_fixSND_PCI_QUIRK (0x1028 ,0x01f6 ,"Dell Latitude 131L" ,POS_FIX_LPIB ),SND_PCI_QUIRK (0x1043 ,0x813d ,"ASUS P5AD2" ,POS_FIX_LPIB ),SND_PCI_QUIRK (0x1043 ,0x81b3 ,"ASUS" ,POS_FIX_LPIB ), +SND_PCI_QUIRK (0x1043 ,0x81e7 ,"ASUS M2V" ,POS_FIX_LPIB ),SND_PCI_QUIRK (0x104d ,0x9069 ,"Sony VPCS11V9E" ,POS_FIX_LPIB ),SND_PCI_QUIRK (0x1106 ,0x3288 ,"ASUS M2V-MX SE" ,POS_FIX_LPIB ), SND_PCI_QUIRK(0x1179, 0xff10, "Toshiba A100-259", POS_FIX_LPIB),
PATCH 92/149 Staging: comedi - correct parameter gainlkup for DAQCard-6024E in driver ni_mio_cs.c
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Martin Homuth-Rosemann <[email protected]>
commit ebe8622342f12bed387f7de4b5fb7c52005ccb29 upstream.
Correct at least one of the incorrect specs for a national instrument data acquisition card DAQCard-6024E. This card has only four different gain settings (+-10V, +-5V, +-0.5V, +-0.05V).
--- drivers/staging/comedi/drivers/ni_mio_cs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/staging/comedi/drivers/ni_mio_cs.c +1 -1
@@ -123,7 +123,7 @@ static const struct ni_board_struct ni_b .adbits = 12, .ai_fifo_depth = 1024, .alwaysdither = 0, - .gainlkup = ai_gain_16, + .gainlkup = ai_gain_4, .ai_speed = 5000, .n_aochan = 2, .aobits = 12,
PATCH 93/149 clocksource: sh_cmt: compute mult and shift before registration
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Paul Mundt <[email protected]>
commit f4d7c3565c1692c54d9152b52090fe73f0029e37 upstream.
Based on the sh_tmu change in 66f49121ffa41a19c59965b31b046d8368fec3c7 ("clocksource: sh_tmu: compute mult and shift before registration"). The same issues impact the sh_cmt driver, so we take the same approach here.
--- drivers/clocksource/sh_cmt.c | 21 ++++++++++++--------- 1 file changed, 12 insertions(+), 9 deletions(-)
drivers/clocksource/sh_cmt.c +12 -9
@@ -413,18 +413,10 @@ static cycle_t sh_cmt_clocksource_read(sstatic int sh_cmt_clocksource_enable (struct clocksource *cs) {struct sh_cmt_priv *p =cs_to_sh_cmt (cs); -int ret; p->total_cycles =0 ; - ret =sh_cmt_start (p,FLAG_CLOCKSOURCE ); -if (ret) -return ret; - -/* TODO: calculate good shift from rate and counter bit width */ - cs->shift =0 ; - cs->mult =clocksource_hz2mult (p->rate, cs->shift); -return 0 ; +return sh_cmt_start (p,FLAG_CLOCKSOURCE ); }static void sh_cmt_clocksource_disable (struct clocksource *cs)
@@ -444,7 +436,18 @@ static int sh_cmt_register_clocksource(s cs->disable = sh_cmt_clocksource_disable; cs->mask =CLOCKSOURCE_MASK (sizeof (unsigned long ) *8 ); cs->flags =CLOCK_SOURCE_IS_CONTINUOUS ; + +/* clk_get_rate() needs an enabled clock */ +clk_enable (p->clk); + p->rate =clk_get_rate (p->clk) / (p->width ==16 ) ?512 :8 ; +clk_disable (p->clk); + +/* TODO: calculate good shift from rate and counter bit width */ + cs->shift =10 ; + cs->mult =clocksource_hz2mult (p->rate, cs->shift); +pr_info ("sh_cmt: %s used as clock source\n" , cs->name); +clocksource_register (cs);return 0 ; }
PATCH 94/149 ath5k: retain promiscuous setting
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Bob Copeland <[email protected]>
commit 6b5dcccb495b66b3b0b9581cdccfed038e5d68a2 upstream.
Commit 56d1de0a21db28e41741cfa0a66e18bc8d920554, "ath5k: clean up filter flags setting" introduced a regression in monitor mode such that the promisc filter flag would get lost.
Although we set the promisc flag when it changed, we did not preserve it across subsequent calls to configure_filter. This patch restores the original functionality.
--- drivers/net/wireless/ath/ath5k/base.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/net/wireless/ath/ath5k/base.c +3 -1
@@ -2975,13 +2975,15 @@ static void ath5k_configure_filter(strucif (changed_flags & (FIF_PROMISC_IN_BSS |FIF_OTHER_BSS )) {if (*new_flags &FIF_PROMISC_IN_BSS ) { - rfilt |=AR5K_RX_FILTER_PROM ;__set_bit (ATH_STAT_PROMISC , sc->status); }else {__clear_bit (ATH_STAT_PROMISC , sc->status); } } +if (test_bit (ATH_STAT_PROMISC , sc->status)) + rfilt |=AR5K_RX_FILTER_PROM ; +/* Note, AR5K_RX_FILTER_MCAST is already enabled */ if (*new_flags &FIF_ALLMULTI ) { mfilt[0 ] = ~0 ;
PATCH 95/149 ahci: add pci quirk for JMB362
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Tejun Heo <[email protected]>
commit 4daedcfe8c6851aa01cc1997220f2577f4039c13 upstream.
JMB362 is a new variant of jmicron controller which is similar to JMB360 but has two SATA ports instead of one. As there is no PATA port, single function AHCI mode can be used as in JMB360. Add pci quirk for JMB362.
--- drivers/pci/quirks.c | 5 ++++- include/linux/pci_ids.h | 1 + 2 files changed, 5 insertions(+), 1 deletion(-)
drivers/pci/quirks.c +4 -1
@@ -1444,7 +1444,8 @@ static void quirk_jmicron_ata(struct pci conf5 &= ~(1 <<24 );/* Clear bit 24 */ switch (pdev->device) { -case PCI_DEVICE_ID_JMICRON_JMB360 : +case PCI_DEVICE_ID_JMICRON_JMB360 :/* SATA single port */ +case PCI_DEVICE_ID_JMICRON_JMB362 :/* SATA dual ports */ /* The controller should be in single function ahci mode */ conf1 |=0x0002A100 ;/* Set 8, 13, 15, 17 */ break ;
@@ -1480,12 +1481,14 @@ static void quirk_jmicron_ata(struct pci }DECLARE_PCI_FIXUP_EARLY (PCI_VENDOR_ID_JMICRON ,PCI_DEVICE_ID_JMICRON_JMB360 , quirk_jmicron_ata);DECLARE_PCI_FIXUP_EARLY (PCI_VENDOR_ID_JMICRON ,PCI_DEVICE_ID_JMICRON_JMB361 , quirk_jmicron_ata); +DECLARE_PCI_FIXUP_EARLY (PCI_VENDOR_ID_JMICRON ,PCI_DEVICE_ID_JMICRON_JMB362 , quirk_jmicron_ata);DECLARE_PCI_FIXUP_EARLY (PCI_VENDOR_ID_JMICRON ,PCI_DEVICE_ID_JMICRON_JMB363 , quirk_jmicron_ata);DECLARE_PCI_FIXUP_EARLY (PCI_VENDOR_ID_JMICRON ,PCI_DEVICE_ID_JMICRON_JMB365 , quirk_jmicron_ata);DECLARE_PCI_FIXUP_EARLY (PCI_VENDOR_ID_JMICRON ,PCI_DEVICE_ID_JMICRON_JMB366 , quirk_jmicron_ata);DECLARE_PCI_FIXUP_EARLY (PCI_VENDOR_ID_JMICRON ,PCI_DEVICE_ID_JMICRON_JMB368 , quirk_jmicron_ata);DECLARE_PCI_FIXUP_RESUME_EARLY (PCI_VENDOR_ID_JMICRON ,PCI_DEVICE_ID_JMICRON_JMB360 , quirk_jmicron_ata);DECLARE_PCI_FIXUP_RESUME_EARLY (PCI_VENDOR_ID_JMICRON ,PCI_DEVICE_ID_JMICRON_JMB361 , quirk_jmicron_ata); +DECLARE_PCI_FIXUP_RESUME_EARLY (PCI_VENDOR_ID_JMICRON ,PCI_DEVICE_ID_JMICRON_JMB362 , quirk_jmicron_ata);DECLARE_PCI_FIXUP_RESUME_EARLY (PCI_VENDOR_ID_JMICRON ,PCI_DEVICE_ID_JMICRON_JMB363 , quirk_jmicron_ata);DECLARE_PCI_FIXUP_RESUME_EARLY (PCI_VENDOR_ID_JMICRON ,PCI_DEVICE_ID_JMICRON_JMB365 , quirk_jmicron_ata);DECLARE_PCI_FIXUP_RESUME_EARLY (PCI_VENDOR_ID_JMICRON ,PCI_DEVICE_ID_JMICRON_JMB366 , quirk_jmicron_ata);
include/linux/pci_ids.h +1 -0
@@ -2317,6 +2317,7 @@#define PCI_VENDOR_ID_JMICRON 0x197B#define PCI_DEVICE_ID_JMICRON_JMB360 0x2360#define PCI_DEVICE_ID_JMICRON_JMB361 0x2361 +#define PCI_DEVICE_ID_JMICRON_JMB362 0x2362#define PCI_DEVICE_ID_JMICRON_JMB363 0x2363#define PCI_DEVICE_ID_JMICRON_JMB365 0x2365#define PCI_DEVICE_ID_JMICRON_JMB366 0x2366
PATCH 96/149 firewire: core: check for 1394a compliant IRM, fix inaccessibility of Sony camcorder
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Stefan Richter <[email protected]>
commit 10389536742cefbedecb67a5b2906f155cf3a1c3 upstream.
Per IEEE 1394 clause 8.4.2.3, a contender for the IRM role shall check whether the current IRM complies to 1394a-2000 or later. If not force a compliant node (e.g. itself) to become IRM. This was implemented in the older ieee1394 driver but not yet in firewire-core.
An older Sony camcorder (Sony DCR-TRV25) which implements 1394-1995 IRM but neither 1394a-2000 IRM nor BM was now found to cause an interoperability bug:
- Camcorder becomes root node when plugged in, hence gets IRM role.
- firewire-core successfully contends for BM role, proceeds to perform gap count optimization and resets the bus.
- Sony camcorder ignores presence of a BM (against the spec, this is a firmware bug), performs its idea of gap count optimization and resets the bus.
- Preceding two steps are repeated endlessly, bus never settles, regular I/O is practically impossible.
http://thread.gmane.org/gmane.linux.kernel.firewire.user/3913
This is an interoperability regression from the old to the new drivers. Fix it indirectly by adding the 1394a IRM check. The spec suggests three and a half methods to determine 1394a compliance of a remote IRM; we choose the method of testing the Config_ROM.Bus_Info.generation field. This is data that firewire-core should have readily available at this point, i.e. does not require extra I/O.
--- drivers/firewire/core-card.c | 24 +++++++++++++++++++----- 1 file changed, 19 insertions(+), 5 deletions(-)
drivers/firewire/core-card.c +19 -5
@@ -239,7 +239,7 @@ void fw_schedule_bm_work(struct fw_cardstatic void fw_card_bm_work (struct work_struct *work) { struct fw_card *card = container_of(work, struct fw_card, work.work); -struct fw_device *root_device; +struct fw_device *root_device, *irm_device;struct fw_node *root_node;unsigned long flags;int root_id, new_root_id, irm_id, local_id;
@@ -247,6 +247,7 @@ static void fw_card_bm_work(struct work_bool do_reset = false;bool root_device_is_running;bool root_device_is_cmc; +bool irm_is_1394_1995_only;spin_lock_irqsave (&card->lock, flags);
@@ -256,12 +257,18 @@ static void fw_card_bm_work(struct work_ } generation = card->generation; + root_node = card->root_node;fw_node_get (root_node); root_device = root_node->data; root_device_is_running = root_device &&atomic_read (&root_device->state) ==FW_DEVICE_RUNNING ; root_device_is_cmc = root_device && root_device->cmc; + + irm_device = card->irm_node->data; + irm_is_1394_1995_only = irm_device && irm_device->config_rom && + (irm_device->config_rom[2 ] &0x000000f0 ) ==0 ; + root_id = root_node->node_id; irm_id = card->irm_node->node_id; local_id = card->local_node->node_id;
@@ -284,8 +291,15 @@ static void fw_card_bm_work(struct work_if (!card->irm_node->link_on) { new_root_id = local_id; -fw_notify ("IRM has link off, making local node (%02x) root.\n" , - new_root_id); +fw_notify ("%s, making local node (%02x) root.\n" , +"IRM has link off" , new_root_id); + goto pick_me; + } + +if (irm_is_1394_1995_only) { + new_root_id = local_id; +fw_notify ("%s, making local node (%02x) root.\n" , +"IRM is not 1394a compliant" , new_root_id); goto pick_me; }
@@ -324,8 +338,8 @@ static void fw_card_bm_work(struct work_* root, and thus, IRM. */ new_root_id = local_id; -fw_notify ("BM lock failed, making local node (%02x) root.\n" , - new_root_id); +fw_notify ("%s, making local node (%02x) root.\n" , +"BM lock failed" , new_root_id); goto pick_me; } }else if (card->bm_generation != generation) {
PATCH 97/149 perf_events: Fix resource leak in x86 __hw_perf_event_init()
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Stephane Eranian <[email protected]>
commit 4b24a88b35e15e04bd8f2c5dda65b5dc8ebca05f upstream.
If reserve_pmc_hardware() succeeds but reserve_ds_buffers() fails, then we need to release_pmc_hardware. It won't be done by the destroy() callback because we return before setting it in case of error.
LKML-Reference: <[email protected]>
--- arch/x86/kernel/cpu/perf_event.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
arch/x86/kernel/cpu/perf_event.c +4 -1
@@ -1005,8 +1005,11 @@ static int __hw_perf_event_init(struct pif (atomic_read (&active_events) ==0 ) {if (!reserve_pmc_hardware ()) err = -EBUSY ; -else +else { err =reserve_bts_hardware (); +if (err) +release_pmc_hardware (); + } }if (!err)atomic_inc (&active_events);
PATCH 98/149 sata_nv: dont diddle with nIEN on mcp55
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Tejun Heo <[email protected]>
commit f3faf8fc3fab45c3526efe8c9e99bb23f8723350 upstream.
On mcp55, nIEN gets stuck once set and liteon blueray rom iHOS104-08 violates ATA specification and fails to set I on D2H Reg FIS if nIEN is set when the command was issued. When the other party is following the spec, both devices can work fine but when the two flaws are put together, they can't talk to each other.
mcp55 has its own IRQ masking mechanism and there's no reason to mess with nIEN in the first place. Fix it by dropping nIEN diddling from nv_mcp55_freeze/thaw().
This was originally reported by Cengiz. Although Cengiz hasn't verified the fix yet, I could reproduce this problem and verfiy the fix. Even if Cengiz is experiencing different or additional problems, this patch is needed.
--- drivers/ata/sata_nv.c | 2 -- 1 file changed, 2 deletions(-)
drivers/ata/sata_nv.c +0 -2
@@ -1673,7 +1673,6 @@ static void nv_mcp55_freeze(struct ata_p mask =readl (mmio_base +NV_INT_ENABLE_MCP55 ); mask &= ~(NV_INT_ALL_MCP55 << shift);writel (mask, mmio_base +NV_INT_ENABLE_MCP55 ); -ata_sff_freeze (ap); }static void nv_mcp55_thaw (struct ata_port *ap)
@@ -1687,7 +1686,6 @@ static void nv_mcp55_thaw(struct ata_por mask =readl (mmio_base +NV_INT_ENABLE_MCP55 ); mask |= (NV_INT_MASK_MCP55 << shift);writel (mask, mmio_base +NV_INT_ENABLE_MCP55 ); -ata_sff_thaw (ap); }static void nv_adma_error_handler (struct ata_port *ap)
PATCH 99/149 sata_via: magic vt6421 fix for transmission problems w/ WD drives
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Tejun Heo <[email protected]>
commit 8b27ff4cf6d15964aa2987aeb58db4dfb1f87a19 upstream.
vt6421 has problems talking to recent WD drives. It causes a lot of transmission errors while high bandwidth transfer as reported in the following bugzilla entry.
https://bugzilla.kernel.org/show_bug.cgi?id=15173
Joseph Chan provided the following fix. I don't have any idea what it does but I can verify the issue is gone with the patch applied.
Originally-from: Joseph Chan <[email protected]>
--- drivers/ata/sata_via.c | 13 +++++++++++++ 1 file changed, 13 insertions(+)
drivers/ata/sata_via.c +13 -0
@@ -558,6 +558,19 @@ static void svia_configure(struct pci_de tmp8 |=NATIVE_MODE_ALL ;pci_write_config_byte (pdev,SATA_NATIVE_MODE , tmp8); } + +/* +* vt6421 has problems talking to some drives. The following +* is the magic fix from Joseph Chan <[email protected]>. +* Please add proper documentation if possible. +* +* https://bugzilla.kernel.org/show_bug.cgi?id=15173 +*/ +if (pdev->device ==0x3249 ) { +pci_read_config_byte (pdev,0x52 , &tmp8); + tmp8 |=1 <<2 ; +pci_write_config_byte (pdev,0x52 , tmp8); + } }static int svia_init_one (struct pci_dev *pdev,const struct pci_device_id *ent)
PATCH 100/149 drm/i915: Rebind bo if currently bound with incorrect alignment.
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Chris Wilson <[email protected]>
commit ac0c6b5ad3b3b513e1057806d4b7627fcc0ecc27 upstream.
Whilst pinning the buffer, check that that its current alignment matches the requested alignment. If it does not, rebind.
This should clear up any final render errors whilst resuming, for reference:
Bug 27070 - [i915] Page table errors with empty ringbuffer
https://bugs.freedesktop.org/show_bug.cgi?id=27070
Bug 15502 - render error detected, EIR: 0x00000010
https://bugzilla.kernel.org/show_bug.cgi?id=15502
Bug 13844 - i915 error: "render error detected"
https://bugzilla.kernel.org/show_bug.cgi?id=13844
--- drivers/gpu/drm/i915/i915_gem.c | 11 +++++++++++ 1 file changed, 11 insertions(+)
drivers/gpu/drm/i915/i915_gem.c +11 -0
@@ -3947,6 +3947,17 @@ i915_gem_object_pin(struct drm_gem_objecint ret;i915_verify_inactive (dev, __FILE__, __LINE__); + +if (obj_priv->gtt_space !=NULL ) { +if (alignment ==0 ) + alignment =i915_gem_get_gtt_alignment (obj); +if (obj_priv->gtt_offset & (alignment -1 )) { + ret =i915_gem_object_unbind (obj); +if (ret) +return ret; + } + } +if (obj_priv->gtt_space ==NULL ) { ret =i915_gem_object_bind_to_gtt (obj, alignment);if (ret)
PATCH 101/149 USB: mos7840: fix null-pointer dereference
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Johan Hovold <[email protected]>
commit b41709f1263bb1ad37efc43fea0bb0b670c12e78 upstream.
Fix null-pointer dereference on error path.
drivers/usb/serial/mos7840.c +0 -1
@@ -730,7 +730,6 @@ static void mos7840_bulk_in_callback(struct urb *urb) mos7840_port = urb->context;if (!mos7840_port) {dbg ("%s" ,"NULL mos7840_port pointer" ); - mos7840_port->read_urb_busy = false;return ; }
PATCH 102/149 USB: xhci: Wait for host to start running.
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Sarah Sharp <[email protected]>
commit ed07453fd356025cc25272629e982f5e4607632c upstream.
When the run bit is set in the xHCI command register, it may take a few microseconds for the host to start running. We cannot ring any doorbells until the host is actually running, so wait until the status register says the host is running.
--- drivers/usb/host/xhci-hcd.c | 39 ++++++++++++++++++++++++++++++++------- 1 file changed, 32 insertions(+), 7 deletions(-)
drivers/usb/host/xhci-hcd.c +32 -7
@@ -97,6 +97,33 @@ int xhci_halt(struct xhci_hcd *xhci) }/* +* Set the run bit and wait for the host to be running. +*/ +int xhci_start (struct xhci_hcd *xhci) +{ +u32 temp; +int ret; + + temp =xhci_readl (xhci, &xhci->op_regs->command); + temp |= (CMD_RUN ); +xhci_dbg (xhci,"// Turn on HC, cmd = 0x%x.\n" , + temp); +xhci_writel (xhci, temp, &xhci->op_regs->command); + +/* +* Wait for the HCHalted Status bit to be 0 to indicate the host is +* running. +*/ + ret =handshake (xhci, &xhci->op_regs->status, +STS_HALT ,0 ,XHCI_MAX_HALT_USEC ); +if (ret == -ETIMEDOUT ) +xhci_err (xhci,"Host took too long to start, " +"waited %u microseconds.\n" , +XHCI_MAX_HALT_USEC ); +return ret; +} + +/* * Reset a halted HC, and set the internal HC state to HC_STATE_HALT. * * This resets pipelines, timers, counters, state machines, etc.
@@ -460,13 +487,11 @@ int xhci_run(struct usb_hcd *hcd)if (NUM_TEST_NOOPS >0 ) doorbell =xhci_setup_one_noop (xhci); - temp =xhci_readl (xhci, &xhci->op_regs->command); - temp |= (CMD_RUN ); -xhci_dbg (xhci,"// Turn on HC, cmd = 0x%x.\n" , - temp); -xhci_writel (xhci, temp, &xhci->op_regs->command); -/* Flush PCI posted writes */ - temp =xhci_readl (xhci, &xhci->op_regs->command); +if (xhci_start (xhci)) { +xhci_halt (xhci); +return -ENODEV ; + } +xhci_dbg (xhci,"// @%p = 0x%x\n" , &xhci->op_regs->command, temp);if (doorbell) (*doorbell)(xhci);
PATCH 103/149 USB: xhci: Wait for controller to be ready after reset.
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Sarah Sharp <[email protected]>
commit 2d62f3eea98354d61f90d6b115eecf9be5f4bdfe upstream.
After software resets an xHCI host controller, it must wait for the "Controller Not Ready" (CNR) bit in the status register to be cleared. Software is not supposed to ring any doorbells or write to any registers except the status register until this bit is cleared.
--- drivers/usb/host/xhci-hcd.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-)
drivers/usb/host/xhci-hcd.c +12 -1
@@ -134,6 +134,7 @@ int xhci_reset(struct xhci_hcd *xhci) {u32 command;u32 state; +int ret; state =xhci_readl (xhci, &xhci->op_regs->status);if ((state &STS_HALT ) ==0 ) {
@@ -148,7 +149,17 @@ int xhci_reset(struct xhci_hcd *xhci)/* XXX: Why does EHCI set this here? Shouldn't other code do this? */ xhci_to_hcd (xhci)->state =HC_STATE_HALT ; -return handshake (xhci, &xhci->op_regs->command,CMD_RESET ,0 ,250 *1000 ); + ret =handshake (xhci, &xhci->op_regs->command, +CMD_RESET ,0 ,250 *1000 ); +if (ret) +return ret; + +xhci_dbg (xhci,"Wait for controller to be ready for doorbell rings\n" ); +/* +* xHCI cannot write to any doorbells or operational registers other +* than status until the "Controller Not Ready" flag is cleared. +*/ +return handshake (xhci, &xhci->op_regs->status,STS_CNR ,0 ,250 *1000 ); }/*
PATCH 104/149 USB: ftdi_sio: fix DTR/RTS line modes
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Daniel Mack <[email protected]>
commit 6a1a82df91fa0eb1cc76069a9efe5714d087eccd upstream.
Call set_mctrl() and clear_mctrl() according to the flow control mode selected. This makes serial communication for FT232 connected devices work when CRTSCTS is not set.
This fixes a regression introduced by 4175f3e31 ("tty_port: If we are opened non blocking we still need to raise the carrier"). This patch calls the low-level driver's dtr_rts() function which consequently sets TIOCM_DTR | TIOCM_RTS. A later call to set_termios() without CRTSCTS in cflags, however, does not reset these bits, and so data is not actually sent out on the serial wire.
--- drivers/usb/serial/ftdi_sio.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/usb/serial/ftdi_sio.c +4 -0
@@ -2306,6 +2306,8 @@ static void ftdi_set_termios(struct tty_ "urb failed to set to rts/cts flow control\n"); } +/* raise DTR/RTS */ +set_mctrl (port,TIOCM_DTR |TIOCM_RTS ); }else {/* * Xon/Xoff code
@@ -2353,6 +2355,8 @@ static void ftdi_set_termios(struct tty_ } } +/* lower DTR/RTS */ +clear_mctrl (port,TIOCM_DTR |TIOCM_RTS ); }return ; }
PATCH 105/149 USB: cdc-acm: fix resource reclaim in error path of acm_probe
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Axel Lin <[email protected]>
commit c2572b78aa0447244a38e555ebb1b3b48a0088a5 upstream.
This patch fixes resource reclaim in error path of acm_probe:
1. In the case of "out of memory (read urbs usb_alloc_urb)\n")", there is no need to call acm_read_buffers_free(acm) here. Fix it by goto alloc_fail6 instead of alloc_fail7.
2. In the case of "out of memory (write urbs usb_alloc_urb)", usb_alloc_urb may fail in any iteration of the for loop. Current implementation does not properly free allocated snd->urb. Fix it by goto alloc_fail8 instead of alloc_fail7.
3. In the case of device_create_file(&intf->dev,&dev_attr_iCountryCodeRelDate) fail, acm->country_codes is kfreed. As a result, device_remove_file for dev_attr_wCountryCodes will not be executed in acm_disconnect. Fix it by calling device_remove_file for dev_attr_wCountryCodes before goto skip_countries.
--- drivers/usb/class/cdc-acm.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/usb/class/cdc-acm.c +4 -2
@@ -1201,7 +1201,7 @@ made_compressed_probe:if (rcv->urb ==NULL ) {dev_dbg (&intf->dev,"out of memory (read urbs usb_alloc_urb)\n" ); - goto alloc_fail7; + goto alloc_fail6; } rcv->urb->transfer_flags |=URB_NO_TRANSFER_DMA_MAP ;
@@ -1225,7 +1225,7 @@ made_compressed_probe:if (snd->urb ==NULL ) {dev_dbg (&intf->dev,"out of memory (write urbs usb_alloc_urb)" ); - goto alloc_fail7; + goto alloc_fail8; }if (usb_endpoint_xfer_int (epwrite))
@@ -1264,6 +1264,7 @@ made_compressed_probe: i =device_create_file (&intf->dev, &dev_attr_iCountryCodeRelDate);if (i <0 ) { +device_remove_file (&intf->dev, &dev_attr_wCountryCodes);kfree (acm->country_codes); goto skip_countries; }
@@ -1300,6 +1301,7 @@ alloc_fail8:usb_free_urb (acm->wb[i].urb); alloc_fail7:acm_read_buffers_free (acm); +alloc_fail6:for (i =0 ; i < num_rx_buf; i++)usb_free_urb (acm->ru[i].urb);usb_free_urb (acm->ctrlurb);
PATCH 106/149 p54usb: Add device ID for Dell WLA3310 USB
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Jason Dravet <[email protected]>
commit 0f666a08901f8b01f294ca0ad751019375240ae3 upstream.
Add Dell WLA3310 USB wireless card, which has a Z-Com XG-705A chipset, to the USB Ids in p54usb.
--- drivers/net/wireless/p54/p54usb.c | 1 + 1 file changed, 1 insertion(+)
drivers/net/wireless/p54/p54usb.c +1 -0
@@ -78,6 +78,7 @@ static struct usb_device_id p54u_table[] {USB_DEVICE(0x1413, 0x5400)}, /* Telsey 802.11g USB2.0 Adapter */ {USB_DEVICE(0x1435, 0x0427)}, /* Inventel UR054G */ {USB_DEVICE(0x2001, 0x3704)}, /* DLink DWL-G122 rev A2 */ + {USB_DEVICE(0x413c, 0x5513)}, /* Dell WLA3310 USB Wireless Adapter */ {USB_DEVICE(0x413c, 0x8102)}, /* Spinnaker DUT */ {USB_DEVICE(0x413c, 0x8104)}, /* Cohiba Proto board */ {}
PATCH 107/149 atl1e: Allow TX checksum offload and TSO to be disabled and reenabled
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Ben Hutchings <[email protected]>
commit ac936929092dc6a5409b627c4c67305ab9b626b3 upstream.
--- drivers/net/atl1e/atl1e_ethtool.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/net/atl1e/atl1e_ethtool.c +2 -0
@@ -394,11 +394,13 @@ static const struct ethtool_ops atl1e_et .get_eeprom = atl1e_get_eeprom, .set_eeprom = atl1e_set_eeprom, .get_tx_csum = atl1e_get_tx_csum, + .set_tx_csum = ethtool_op_set_tx_hw_csum, .get_sg = ethtool_op_get_sg, .set_sg = ethtool_op_set_sg, #ifdef NETIF_F_TSO .get_tso = ethtool_op_get_tso, #endif + .set_tso = ethtool_op_set_tso, };void atl1e_set_ethtool_ops (struct net_device *netdev)
PATCH 108/149 via-velocity: Give RX descriptors to the NIC later on open or MTU change
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Ben Hutchings <[email protected]>
commit 35bb5cadc8c7b1462df57e32e08d964f1be7a75c upstream.
velocity_open() calls velocity_give_many_rx_descs(), which gives RX descriptors to the NIC, before installing an interrupt handler or calling velocity_init_registers(). I think this is very unsafe and it appears to explain the bug report <http://bugs.debian.org/508527>.
On MTU change, velocity_give_many_rx_descs() is again called before velocity_init_registers(). I'm not sure whether this is unsafe but it does look wrong.
Therefore, move the calls to velocity_give_many_rx_descs() after request_irq() and velocity_init_registers().
--- drivers/net/via-velocity.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/net/via-velocity.c +4 -4
@@ -2186,8 +2186,6 @@ static int velocity_open(struct net_devi/* Ensure chip is running */ pci_set_power_state (vptr->pdev,PCI_D0 ); -velocity_give_many_rx_descs (vptr); -velocity_init_registers (vptr,VELOCITY_INIT_COLD ); ret = request_irq(vptr->pdev->irq, &velocity_intr, IRQF_SHARED,
@@ -2199,6 +2197,8 @@ static int velocity_open(struct net_devi goto out; } +velocity_give_many_rx_descs (vptr); +mac_enable_int (vptr->mac_regs);netif_start_queue (dev); vptr->flags |=VELOCITY_FLAGS_OPENED ;
@@ -2287,10 +2287,10 @@ static int velocity_change_mtu(struct ne dev->mtu = new_mtu; -velocity_give_many_rx_descs (vptr); -velocity_init_registers (vptr,VELOCITY_INIT_COLD ); +velocity_give_many_rx_descs (vptr); +mac_enable_int (vptr->mac_regs);netif_start_queue (dev);
PATCH 109/149 dmfe/tulip: Let dmfe handle DM910x except for SPARC on-board chips
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Ben Hutchings <[email protected]>
commit 4d907069bc1b745f4abd4745c332d33098e733b8 upstream.
The Davicom DM9100 and DM9102 chips are used on the motherboards of some SPARC systems (supported by the tulip driver) and also in PCI expansion cards (supported by the dmfe driver). There is no difference in the PCI device ids for the two different configurations, so these drivers both claim the device ids. However, it is possible to distinguish the two configurations by the presence of Open Firmware properties for them, so we do that.
--- drivers/net/tulip/Kconfig | 4 ++++ drivers/net/tulip/dmfe.c | 21 +++++++++++++++++++++ drivers/net/tulip/tulip_core.c | 32 +++++++++++++++++++++++++------- 3 files changed, 50 insertions(+), 7 deletions(-)
drivers/net/tulip/Kconfig +4 -0
@@ -101,6 +101,10 @@ config TULIP_NAPI_HW_MITIGATION If in doubt, say Y. +config TULIP_DM910X + def_bool y + depends on TULIP && SPARC + config DE4X5 tristate "Generic DECchip & DIGITAL EtherWORKS PCI/EISA" depends on PCI || EISA
drivers/net/tulip/dmfe.c +21 -0
@@ -92,6 +92,10 @@#include <asm/uaccess.h> #include <asm/irq.h> +#ifdef CONFIG_TULIP_DM910X +#include <linux/of.h> +#endif +/* Board/System/Debug information/definition ---------------- */ #define PCI_DM9132_ID 0x91321282/* Davicom DM9132 ID */
@@ -377,6 +381,23 @@ static int __devinit dmfe_init_one (struif (!printed_version++)printk (version); +/* +* SPARC on-board DM910x chips should be handled by the main +* tulip driver, except for early DM9100s. +*/ +#ifdef CONFIG_TULIP_DM910X +if ((ent->driver_data ==PCI_DM9100_ID && pdev->revision >=0x30 ) || + ent->driver_data ==PCI_DM9102_ID ) { +struct device_node *dp =pci_device_to_OF_node (pdev); + +if (dp &&of_get_property (dp,"local-mac-address" ,NULL )) { + printk(KERN_INFO DRV_NAME + ": skipping on-board DM910x (use tulip)\n"); +return -ENODEV ; + } + } +#endif +/* Init network device */ dev =alloc_etherdev (sizeof (*db));if (dev ==NULL )
drivers/net/tulip/tulip_core.c +25 -7
@@ -196,9 +196,13 @@ struct tulip_chip_table tulip_tbl[] = { | HAS_NWAY | HAS_PCI_MWI, tulip_timer, tulip_media_task },/* DM910X */ +#ifdef CONFIG_TULIP_DM910X {"Davicom DM9102/DM9102A" ,128 ,0x0001ebef ,HAS_MII |HAS_MEDIA_TABLE |CSR12_IN_SROM |HAS_ACPI , tulip_timer, tulip_media_task }, +#else + { NULL }, +#endif /* RS7112 */ { "Conexant LANfinity", 256, 0x0001ebef,
@@ -228,8 +232,10 @@ static struct pci_device_id tulip_pci_tb { 0x1259, 0xa120, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET }, { 0x11F6, 0x9881, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMPEX9881 }, { 0x8086, 0x0039, PCI_ANY_ID, PCI_ANY_ID, 0, 0, I21145 }, +#ifdef CONFIG_TULIP_DM910X { 0x1282, 0x9100, PCI_ANY_ID, PCI_ANY_ID, 0, 0, DM910X }, { 0x1282, 0x9102, PCI_ANY_ID, PCI_ANY_ID, 0, 0, DM910X }, +#endif { 0x1113, 0x1216, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET }, { 0x1113, 0x1217, PCI_ANY_ID, PCI_ANY_ID, 0, 0, MX98715 }, { 0x1113, 0x9511, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
@@ -1299,18 +1305,30 @@ static int __devinit tulip_init_one (str }/* -* Early DM9100's need software CRC and the DMFE driver +* DM910x chips should be handled by the dmfe driver, except +* on-board chips on SPARC systems. Also, early DM9100s need +* software CRC which only the dmfe driver supports. */ -if (pdev->vendor ==0x1282 && pdev->device ==0x9100 ) - { -/* Read Chip revision */ -if (pdev->revision <0x30 ) - { - printk(KERN_ERR PFX "skipping early DM9100 with Crc bug (use dmfe)\n"); +#ifdef CONFIG_TULIP_DM910X +if (chip_idx ==DM910X ) { +struct device_node *dp; + +if (pdev->vendor ==0x1282 && pdev->device ==0x9100 && + pdev->revision <0x30 ) { + printk(KERN_INFO PFX + "skipping early DM9100 with Crc bug (use dmfe)\n"); +return -ENODEV ; + } + + dp =pci_device_to_OF_node (pdev); +if (!(dp &&of_get_property (dp,"local-mac-address" ,NULL ))) { + printk(KERN_INFO PFX + "skipping DM910x expansion card (use dmfe)\n");return -ENODEV ; } } +#endif /* * Looks for early PCI chipsets where people report hangs
PATCH 110/149 Documentation/3c509: document ethtool support
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Ben Hutchings <[email protected]>
commit aa4e2e171385bb77b4da8b760d26dea2aa291587 upstream.
3c509 was changed to support ethtool in 2002, making the 'xcvr' module parameter obsolete in most cases. More recently 3c509 was converted to the modern driver model and this parameter was removed. Fix the documentation to refer to ethtool rather than the module parameter.
--- Documentation/networking/3c509.txt | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-)
Documentation/networking/3c509.txt +8 -4
@@ -48,11 +48,11 @@ for LILO parameters for doing this: This configures the first found 3c509 card for IRQ 10, base I/O 0x310, and transceiver type 3 (10base2). The flag "0x3c509" must be set to avoid conflicts with other card types when overriding the I/O address. When the driver is -loaded as a module, only the IRQ and transceiver setting may be overridden. -For example, setting two cards to 10base2/IRQ10 and AUI/IRQ11 is done by using -the xcvr and irq module options: +loaded as a module, only the IRQ may be overridden. For example, +setting two cards to IRQ10 and IRQ11 is done by using the irq module +option: - options 3c509 xcvr=3,1 irq=10,11 + options 3c509 irq=10,11 (2) Full-duplex mode
@@ -77,6 +77,8 @@ operation. itself full-duplex capable. This is almost certainly one of two things: a full- duplex-capable Ethernet switch (*not* a hub), or a full-duplex-capable NIC on another system that's connected directly to the 3c509B via a crossover cable. + +Full-duplex mode can be enabled using 'ethtool'. /////Extremely important caution concerning full-duplex mode///// Understand that the 3c509B's hardware's full-duplex support is much more
@@ -113,6 +115,8 @@ This insured that merely upgrading the d never automatically enable full-duplex mode in an existing installation; it must always be explicitly enabled via one of these code in order to be activated. + +The transceiver type can be changed using 'ethtool'. (4a) Interpretation of error messages and common problems
PATCH 111/149 wireless: report reasonable bitrate for MCS rates through wext
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: John W. Linville <[email protected]>
commit 254416aae70ab2e6b57fd79782c8a67196234d02 upstream.
Previously, cfg80211 had reported "0" for MCS (i.e. 802.11n) bitrates through the wireless extensions interface. However, nl80211 was converting MCS rates into a reasonable bitrate number. This patch moves the nl80211 code to cfg80211 where it is now shared between both the nl80211 interface and the wireless extensions interface.
--- net/wireless/core.h | 2 ++ net/wireless/nl80211.c | 37 ++----------------------------------- net/wireless/util.c | 33 +++++++++++++++++++++++++++++++++ net/wireless/wext-compat.c | 5 +---- 4 files changed, 38 insertions(+), 39 deletions(-)
net/wireless/core.h +2 -0
@@ -385,6 +385,8 @@ int rdev_set_freq(struct cfg80211_registstruct wireless_dev *for_wdev, int freq, enum nl80211_channel_type channel_type); +u16 cfg80211_calculate_bitrate (struct rate_info *rate); +#ifdef CONFIG_CFG80211_DEVELOPER_WARNINGS #define CFG80211_DEV_WARN_ON (cond) WARN_ON(cond)#else
net/wireless/nl80211.c +2 -35
@@ -1562,39 +1562,6 @@ static int parse_station_flags(struct gereturn 0 ; } -static u16 nl80211_calculate_bitrate (struct rate_info *rate) -{ -int modulation, streams, bitrate; - -if (!(rate->flags &RATE_INFO_FLAGS_MCS )) -return rate->legacy; - -/* the formula below does only work for MCS values smaller than 32 */ -if (rate->mcs >=32 ) -return 0 ; - - modulation = rate->mcs &7 ; - streams = (rate->mcs >>3 ) +1 ; - - bitrate = (rate->flags &RATE_INFO_FLAGS_40_MHZ_WIDTH ) ? -13500000 :6500000 ; - -if (modulation <4 ) - bitrate *= (modulation +1 ); -else if (modulation ==4 ) - bitrate *= (modulation +2 ); -else - bitrate *= (modulation +3 ); - - bitrate *= streams; - -if (rate->flags &RATE_INFO_FLAGS_SHORT_GI ) - bitrate = (bitrate /9 ) *10 ; - -/* do NOT round down here */ -return (bitrate +50000 ) /100000 ; -} -static int nl80211_send_station (struct sk_buff *msg,u32 pid,u32 seq,int flags,struct net_device *dev,u8 *mac_addr,struct station_info *sinfo)
@@ -1641,8 +1608,8 @@ static int nl80211_send_station(struct sif (!txrate) goto nla_put_failure; -/* nl80211_calculate_bitrate will return 0 for mcs >= 32 */ - bitrate =nl80211_calculate_bitrate (&sinfo->txrate); +/* cfg80211_calculate_bitrate will return 0 for mcs >= 32 */ + bitrate =cfg80211_calculate_bitrate (&sinfo->txrate);if (bitrate >0 )NLA_PUT_U16 (msg,NL80211_RATE_INFO_BITRATE , bitrate);
net/wireless/util.c +33 -0
@@ -682,3 +682,36 @@ int cfg80211_change_iface(struct cfg8021return err; } + +u16 cfg80211_calculate_bitrate (struct rate_info *rate) +{ +int modulation, streams, bitrate; + +if (!(rate->flags &RATE_INFO_FLAGS_MCS )) +return rate->legacy; + +/* the formula below does only work for MCS values smaller than 32 */ +if (rate->mcs >=32 ) +return 0 ; + + modulation = rate->mcs &7 ; + streams = (rate->mcs >>3 ) +1 ; + + bitrate = (rate->flags &RATE_INFO_FLAGS_40_MHZ_WIDTH ) ? +13500000 :6500000 ; + +if (modulation <4 ) + bitrate *= (modulation +1 ); +else if (modulation ==4 ) + bitrate *= (modulation +2 ); +else + bitrate *= (modulation +3 ); + + bitrate *= streams; + +if (rate->flags &RATE_INFO_FLAGS_SHORT_GI ) + bitrate = (bitrate /9 ) *10 ; + +/* do NOT round down here */ +return (bitrate +50000 ) /100000 ; +}
net/wireless/wext-compat.c +1 -4
@@ -1227,10 +1227,7 @@ int cfg80211_wext_giwrate(struct net_devif (!(sinfo.filled &STATION_INFO_TX_BITRATE ))return -EOPNOTSUPP ; - rate->value =0 ; - -if (!(sinfo.txrate.flags &RATE_INFO_FLAGS_MCS )) - rate->value =100000 * sinfo.txrate.legacy; + rate->value =100000 *cfg80211_calculate_bitrate (&sinfo.txrate);return 0 ; }
PATCH 112/149 ath9k: add support for 802.11n bonded out AR2427
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Luis R. Rodriguez <[email protected]>
commit 5ffaf8a361b4c9025963959a744f21d8173c7669 upstream.
Some single chip family devices are sold in the market with 802.11n bonded out, these have no hardware capability for 802.11n but ath9k can still support them. These are called AR2427.
--- drivers/net/wireless/ath/ath9k/hw.c | 7 ++++++- drivers/net/wireless/ath/ath9k/hw.h | 1 + drivers/net/wireless/ath/ath9k/main.c | 4 +++- drivers/net/wireless/ath/ath9k/pci.c | 1 + 4 files changed, 11 insertions(+), 2 deletions(-)
drivers/net/wireless/ath/ath9k/hw.c +6 -1
@@ -398,7 +398,6 @@ static void ath9k_hw_init_config(struct ah->config.pcie_clock_req =0 ; ah->config.pcie_waen =0 ; ah->config.analog_shiftreg =1 ; - ah->config.ht_enable =1 ; ah->config.ofdm_trig_low =200 ; ah->config.ofdm_trig_high =500 ; ah->config.cck_trig_high =200 ;
@@ -412,6 +411,11 @@ static void ath9k_hw_init_config(struct ah->config.spurchans[i][1 ] =AR_NO_SPUR ; } +if (ah->hw_version.devid !=AR2427_DEVID_PCIE ) + ah->config.ht_enable =1 ; +else + ah->config.ht_enable =0 ; + ah->config.intr_mitigation = true;/*
@@ -617,6 +621,7 @@ static bool ath9k_hw_devid_supported(u16case AR9285_DEVID_PCIE :case AR5416_DEVID_AR9287_PCI :case AR5416_DEVID_AR9287_PCIE : +case AR2427_DEVID_PCIE :return true;default :break ;
drivers/net/wireless/ath/ath9k/hw.h +1 -0
@@ -37,6 +37,7 @@#define AR9280_DEVID_PCI 0x0029#define AR9280_DEVID_PCIE 0x002a#define AR9285_DEVID_PCIE 0x002b +#define AR2427_DEVID_PCIE 0x002c#define AR5416_AR9100_DEVID 0x000b#define AR_SUBVENDOR_ID_NOG 0x0e11#define AR_SUBVENDOR_ID_NEW_A 0x7065
drivers/net/wireless/ath/ath9k/main.c +3 -1
@@ -1541,12 +1541,14 @@ void ath_set_hw_capab(struct ath_softc * hw->flags =IEEE80211_HW_RX_INCLUDES_FCS |IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING |IEEE80211_HW_SIGNAL_DBM | -IEEE80211_HW_AMPDU_AGGREGATION |IEEE80211_HW_SUPPORTS_PS |IEEE80211_HW_PS_NULLFUNC_STACK |IEEE80211_HW_REPORTS_TX_ACK_STATUS |IEEE80211_HW_SPECTRUM_MGMT ; +if (sc->sc_ah->caps.hw_caps &ATH9K_HW_CAP_HT ) + hw->flags |=IEEE80211_HW_AMPDU_AGGREGATION ; +if (AR_SREV_9160_10_OR_LATER (sc->sc_ah) || modparam_nohwcrypt) hw->flags |=IEEE80211_HW_MFP_CAPABLE ;
drivers/net/wireless/ath/ath9k/pci.c +1 -0
@@ -25,6 +25,7 @@ static struct pci_device_id ath_pci_id_t { PCI_VDEVICE(ATHEROS, 0x0029) }, /* PCI */ { PCI_VDEVICE(ATHEROS, 0x002A) }, /* PCI-E */ { PCI_VDEVICE(ATHEROS, 0x002B) }, /* PCI-E */ + { PCI_VDEVICE(ATHEROS, 0x002C) }, /* PCI-E 802.11n bonded out */ { PCI_VDEVICE(ATHEROS, 0x002D) }, /* PCI */ { PCI_VDEVICE(ATHEROS, 0x002E) }, /* PCI-E */ { 0 }
PATCH 113/149 drm/i915: give up on 8xx lid status
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Jesse Barnes <[email protected]>
commit 7b9c5abee98c54f85bcc04bd4d7ec8d5094c73f4 upstream.
These old machines more often than not lie about their lid state. So don't use it to detect LVDS presence, but leave the event handler to deal with lid open/close, when we might need to reset the mode.
Fixes kernel bug #15248
--- drivers/gpu/drm/i915/intel_lvds.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/gpu/drm/i915/intel_lvds.c +4 -0
@@ -648,8 +648,12 @@ static const struct dmi_system_id bad_li*/ static enum drm_connector_status intel_lvds_detect (struct drm_connector *connector) { +struct drm_device *dev = connector->dev;enum drm_connector_status status = connector_status_connected; +if (IS_I8XX (dev)) +return connector_status_connected; +if (!acpi_lid_open () && !dmi_check_system (bad_lid_status)) status = connector_status_disconnected;
PATCH 114/149 wrong type for magic argument in simple_fill_super()
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Roberto Sassu <[email protected]>
commit 7d683a09990ff095a91b6e724ecee0ff8733274a upstream.
It's used to superblock ->s_magic, which is unsigned long.
--- fs/libfs.c | 3 ++- include/linux/fs.h | 2 +- 2 files changed, 3 insertions(+), 2 deletions(-)
fs/libfs.c +2 -1
@@ -415,7 +415,8 @@ int simple_write_end(struct file *file,* unique inode values later for this filesystem, then you must take care * to pass it an appropriate max_reserved value to avoid collisions. */ -int simple_fill_super (struct super_block *s,int magic,struct tree_descr *files) +int simple_fill_super (struct super_block *s,unsigned long magic, +struct tree_descr *files) {struct inode *inode;struct dentry *root;
include/linux/fs.h +1 -1
@@ -2376,7 +2376,7 @@ extern const struct file_operations simpextern const struct inode_operations simple_dir_inode_operations;struct tree_descr {char *name;const struct file_operations *ops;int mode; };struct dentry *d_alloc_name (struct dentry *,const char *); -extern int simple_fill_super (struct super_block *,int ,struct tree_descr *); +extern int simple_fill_super (struct super_block *,unsigned long ,struct tree_descr *);extern int simple_pin_fs (struct file_system_type *,struct vfsmount **mount,int *count);extern void simple_release_fs (struct vfsmount **mount,int *count);
PATCH 115/149 iwlwifi: check for aggregation frame and queue
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Wey-Yi Guy <[email protected]>
commit 45d427001b5eec03cecaacddb53c73af46bb263e upstream.
Error checking for aggregation frames should go into aggregation queue, if aggregation queue not available, use legacy queue instead. Also make sure the aggregation queue is available to activate, if driver and mac80211 is out-of-sync, try to disable the queue and sync-up with mac80211.
--- drivers/net/wireless/iwlwifi/iwl-agn-rs.c | 15 ++++++++++++++- drivers/net/wireless/iwlwifi/iwl-tx.c | 18 ++++++++++++------ 2 files changed, 26 insertions(+), 7 deletions(-)
drivers/net/wireless/iwlwifi/iwl-agn-rs.c +14 -1
@@ -402,10 +402,23 @@ static void rs_tl_turn_on_agg_for_tid(st struct iwl_lq_sta *lq_data, u8 tid, struct ieee80211_sta *sta) { + int ret; +if (rs_tl_get_load (lq_data, tid) >IWL_AGG_LOAD_THRESHOLD ) {IWL_DEBUG_HT (priv,"Starting Tx agg: STA: %pM tid: %d\n" , sta->addr, tid); -ieee80211_start_tx_ba_session (priv->hw, sta->addr, tid); + ret =ieee80211_start_tx_ba_session (priv->hw, sta->addr, tid); +if (ret == -EAGAIN ) { +/* +* driver and mac80211 is out of sync +* this might be cause by reloading firmware +* stop the tx ba session here +*/ +IWL_DEBUG_HT (priv,"Fail start Tx agg on tid: %d\n" , + tid); + ret =ieee80211_stop_tx_ba_session (priv->hw, sta->addr, tid, +WLAN_BACK_INITIATOR ); + } } }
drivers/net/wireless/iwlwifi/iwl-tx.c +12 -6
@@ -791,8 +791,10 @@ int iwl_tx_skb(struct iwl_priv *priv, st hdr->seq_ctrl |=cpu_to_le16 (seq_number); seq_number +=0x10 ;/* aggregation is on for this <sta,tid> */ -if (info->flags &IEEE80211_TX_CTL_AMPDU ) +if (info->flags &IEEE80211_TX_CTL_AMPDU && + priv->stations[sta_id].tid[tid].agg.state ==IWL_AGG_ON ) { txq_id = priv->stations[sta_id].tid[tid].agg.txq_id; + } } txq = &priv->txq[txq_id];
@@ -1273,7 +1275,7 @@ int iwl_tx_agg_stop(struct iwl_priv *pri {int tx_fifo_id, txq_id, sta_id, ssn =-1 ;struct iwl_tid_data *tid_data; -int ret, write_ptr, read_ptr; +int write_ptr, read_ptr;unsigned long flags;if (!ra) {
@@ -1325,13 +1327,17 @@ int iwl_tx_agg_stop(struct iwl_priv *pri priv->stations[sta_id].tid[tid].agg.state =IWL_AGG_OFF ;spin_lock_irqsave (&priv->lock, flags); - ret = priv->cfg->ops->lib->txq_agg_disable (priv, txq_id, ssn, +/* +* the only reason this call can fail is queue number out of range, +* which can happen if uCode is reloaded and all the station +* information are lost. if it is outside the range, there is no need +* to deactivate the uCode queue, just return "success" to allow +* mac80211 to clean up it own data. +*/ + priv->cfg->ops->lib->txq_agg_disable (priv, txq_id, ssn, tx_fifo_id);spin_unlock_irqrestore (&priv->lock, flags); -if (ret) -return ret; -ieee80211_stop_tx_ba_cb_irqsafe (priv->hw, ra, tid);return 0 ;
PATCH 116/149 iwlwifi: recalculate average tpt if not current
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Reinette Chatre <[email protected]>
commit 3d79b2a9eeaa066b35c49fbb17e3156a3c482c3e upstream.
We currently have this check as a BUG_ON, which is being hit by people. Previously it was an error with a recalculation if not current, return that code.
The BUG_ON was introduced by:
commit 3110bef78cb4282c58245bc8fd6d95d9ccb19749
Author: Guy Cohen <[email protected]> Date: Tue Sep 9 10:54:54 2008 +0800
iwlwifi: Added support for 3 antennas
... the portion adding the BUG_ON is reverted since we are encountering the error and BUG_ON was created with assumption that error is not encountered.
--- drivers/net/wireless/iwlwifi/iwl-agn-rs.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)
drivers/net/wireless/iwlwifi/iwl-agn-rs.c +6 -3
@@ -2193,9 +2193,12 @@ static void rs_rate_scale_perform(struct/* Else we have enough samples; calculate estimate of * actual average throughput */ - -BUG_ON (window->average_tpt != ((window->success_ratio * - tbl->expected_tpt[index] +64 ) /128 )); +if (window->average_tpt != ((window->success_ratio * + tbl->expected_tpt[index] +64 ) /128 )) { +IWL_ERR (priv,"expected_tpt should have been calculated by now\n" ); + window->average_tpt = ((window->success_ratio * + tbl->expected_tpt[index] +64 ) /128 ); + }/* If we are searching for better modulation mode, check success. */ if (lq_sta->search_better_tbl &&
PATCH 117/149 iwlwifi: update supported PCI_ID list for 5xx0 series
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Wey-Yi Guy <[email protected]>
commit ac592574a577162183b5c1dd040a188caa068a29 upstream.
Update the PCI_ID list for 5xx0 series.
Remove all the PCI_IDs which never made into production or not longer in production.
Also make sure the supported bands(a/b/g/n) match specified PCI_IDs
--- drivers/net/wireless/iwlwifi/iwl-5000.c | 23 ++++++++- drivers/net/wireless/iwlwifi/iwl-agn.c | 74 ++++++++++++++++++++++++-------- drivers/net/wireless/iwlwifi/iwl-dev.h | 3 - 3 files changed, 78 insertions(+), 22 deletions(-)
drivers/net/wireless/iwlwifi/iwl-5000.c +19 -4
@@ -1674,12 +1674,12 @@ struct iwl_cfg iwl5300_agn_cfg = { .use_rts_for_ht = true, /* use rts/cts protection */ }; -struct iwl_cfg iwl5100_bg_cfg = { - .name ="5100BG" , +struct iwl_cfg iwl5100_bgn_cfg = { + .name ="5100BGN" , .fw_name_pre =IWL5000_FW_PRE , .ucode_api_max =IWL5000_UCODE_API_MAX , .ucode_api_min =IWL5000_UCODE_API_MIN , - .sku =IWL_SKU_G , + .sku =IWL_SKU_G |IWL_SKU_N , .ops = &iwl5000_ops, .eeprom_size =IWL_5000_EEPROM_IMG_SIZE , .eeprom_ver =EEPROM_5000_EEPROM_VERSION ,
@@ -1705,7 +1705,6 @@ struct iwl_cfg iwl5100_abg_cfg = { .valid_tx_ant = ANT_B, .valid_rx_ant = ANT_AB, .need_pll_cfg = true, - .ht_greenfield_support = true, };struct iwl_cfg iwl5100_agn_cfg = {
@@ -1762,6 +1761,22 @@ struct iwl_cfg iwl5150_agn_cfg = { .use_rts_for_ht = true, /* use rts/cts protection */ }; +struct iwl_cfg iwl5150_abg_cfg = { + .name ="5150ABG" , + .fw_name_pre =IWL5150_FW_PRE , + .ucode_api_max =IWL5150_UCODE_API_MAX , + .ucode_api_min =IWL5150_UCODE_API_MIN , + .sku =IWL_SKU_A |IWL_SKU_G , + .ops = &iwl5150_ops, + .eeprom_size =IWL_5000_EEPROM_IMG_SIZE , + .eeprom_ver =EEPROM_5050_EEPROM_VERSION , + .eeprom_calib_ver =EEPROM_5050_TX_POWER_VERSION , + .mod_params = &iwl50_mod_params, + .valid_tx_ant =ANT_A , + .valid_rx_ant =ANT_AB , + .need_pll_cfg = true, +}; +MODULE_FIRMWARE (IWL5000_MODULE_FIRMWARE (IWL5000_UCODE_API_MAX ));MODULE_FIRMWARE (IWL5150_MODULE_FIRMWARE (IWL5150_UCODE_API_MAX ));
drivers/net/wireless/iwlwifi/iwl-agn.c +57 -17
80 lines not on this page · raw message
drivers/net/wireless/iwlwifi/iwl-dev.h +2 -1
@@ -53,9 +53,10 @@ extern struct iwl_cfg iwl4965_agn_cfg;extern struct iwl_cfg iwl5300_agn_cfg;extern struct iwl_cfg iwl5100_agn_cfg;extern struct iwl_cfg iwl5350_agn_cfg; -extern struct iwl_cfg iwl5100_bg_cfg; +extern struct iwl_cfg iwl5100_bgn_cfg;extern struct iwl_cfg iwl5100_abg_cfg;extern struct iwl_cfg iwl5150_agn_cfg; +extern struct iwl_cfg iwl5150_abg_cfg;extern struct iwl_cfg iwl6000h_2agn_cfg;extern struct iwl_cfg iwl6000i_2agn_cfg;extern struct iwl_cfg iwl6000_3agn_cfg;
PATCH 118/149 wl1251: fix a memory leak in probe
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Grazvydas Ignotas <[email protected]>
commit aa679c36756003f1fabdb9fc6f00eb159559f7c3 upstream.
wl1251_sdio_probe() error path is missing wl1251_free_hw, add it.
--- drivers/net/wireless/wl12xx/wl1251_sdio.c | 1 + 1 file changed, 1 insertion(+)
drivers/net/wireless/wl12xx/wl1251_sdio.c +1 -0
@@ -160,6 +160,7 @@ disable:sdio_disable_func (func); release:sdio_release_host (func); +wl1251_free_hw (wl);return ret; }
PATCH 119/149 ext4: check s_log_groups_per_flex in online resize code
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Eric Sandeen <[email protected]>
commit 42007efd569f1cf3bfb9a61da60ef6c2179508ca upstream.
If groups_per_flex < 2, sbi->s_flex_groups[] doesn't get filled out, and every other access to this first tests s_log_groups_per_flex; same thing needs to happen in resize or we'll wander off into a null pointer when doing an online resize of the file system.
Thanks to Christoph Biedl, who came up with the trivial testcase:
# truncate --size 128M fsfile # mkfs.ext3 -F fsfile # tune2fs -O extents,uninit_bg,dir_index,flex_bg,huge_file,dir_nlink,extra_isize fsfile # e2fsck -yDf -C0 fsfile # truncate --size 132M fsfile # losetup /dev/loop0 fsfile # mount /dev/loop0 mnt # resize2fs -p /dev/loop0
https://bugzilla.kernel.org/show_bug.cgi?id=13549
--- fs/ext4/resize.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
fs/ext4/resize.c +2 -1
@@ -930,7 +930,8 @@ int ext4_group_add(struct super_block *spercpu_counter_add (&sbi->s_freeinodes_counter,EXT4_INODES_PER_GROUP (sb)); -if (EXT4_HAS_INCOMPAT_FEATURE (sb,EXT4_FEATURE_INCOMPAT_FLEX_BG )) { +if (EXT4_HAS_INCOMPAT_FEATURE (sb,EXT4_FEATURE_INCOMPAT_FLEX_BG ) && + sbi->s_log_groups_per_flex) {ext4_group_t flex_group; flex_group =ext4_flex_group (sbi, input->group); atomic_add(input->free_blocks_count,
[email protected]
maintainerRe: [patch 119/149] ext4: check s_log_groups_per_flex in online resize code
Quoted 1 line · Greg KH
2.6.32-stable review patch. If anyone has any objections, please let us know.
My only objection to these patches is that I don't know if they are going to cause patch conflicts with the 50 or so patches which I sent you for 2.6.32, which include both this patch and the next one. When I backported the patches I did have to adjust some of them to make sure they would apply cleanly to the latest 2.6.32.X release. By cherry picking them, it could be that dropping those patches from could cause no problems at all; or it could be a bit of a headache.
So it might be easier to drop these two and then wait for the next 2.6.32 stable release (which will hopefully be coming soon!) and just take my whole set of patches....
- Ted
Re: [patch 119/149] ext4: check s_log_groups_per_flex in online resize code
Quoted 11 lines · On Fri, Jul 02, 2010 at 12:11:02AM -0400, [email protected] wrote:
Quoted 1 line · Greg KH
2.6.32-stable review patch. If anyone has any objections, please let us know.
My only objection to these patches is that I don't know if they are going to cause patch conflicts with the 50 or so patches which I sent you for 2.6.32, which include both this patch and the next one. When I backported the patches I did have to adjust some of them to make sure they would apply cleanly to the latest 2.6.32.X release. By cherry picking them, it could be that dropping those patches from could cause no problems at all; or it could be a bit of a headache.
Quoted 3 lines
So it might be easier to drop these two and then wait for the next 2.6.32 stable release (which will hopefully be coming soon!) and just take my whole set of patches....
Ok, I've now dropped them and will pick them up for the next release with the full series that you have sent me.
thanks,
greg k-h
PATCH 120/149 ext4: Make sure the MOVE_EXT ioctl cant overwrite append-only files
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Theodore Ts'o <[email protected]>
commit 1f5a81e41f8b1a782c68d3843e9ec1bfaadf7d72 upstream.
Dan Roseberg has reported a problem with the MOVE_EXT ioctl. If the donor file is an append-only file, we should not allow the operation to proceed, lest we end up overwriting the contents of an append-only file.
--- fs/ext4/move_extent.c | 3 +++ 1 file changed, 3 insertions(+)
fs/ext4/move_extent.c +3 -0
@@ -964,6 +964,9 @@ mext_check_arguments(struct inode *orig_return -EINVAL ; } +if (IS_IMMUTABLE (donor_inode) ||IS_APPEND (donor_inode)) +return -EPERM ; +/* Ext4 move extent does not support swapfile */ if (IS_SWAPFILE (orig_inode) ||IS_SWAPFILE (donor_inode)) { ext4_debug("ext4 move extent: The argument files should "
PATCH 121/149 GFS2: Fix permissions checking for setflags ioctl()
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Steven Whitehouse <[email protected]>
commit 7df0e0397b9a18358573274db9fdab991941062f upstream.
We should be checking for the ownership of the file for which flags are being set, rather than just for write access.
--- fs/gfs2/file.c | 7 +++++++ 1 file changed, 7 insertions(+)
fs/gfs2/file.c +7 -0
@@ -218,6 +218,11 @@ static int do_gfs2_set_flags(struct fileif (error) goto out_drop_write; + error = -EACCES ; +if (!is_owner_or_cap (inode)) + goto out; + + error =0 ; flags = ip->i_diskflags; new_flags = (flags & ~mask) | (reqflags & mask);if ((new_flags ^ flags) ==0 )
@@ -275,8 +280,10 @@ static int gfs2_set_flags(struct file *f {struct inode *inode = filp->f_path.dentry->d_inode;u32 fsflags, gfsflags; +if (get_user (fsflags, ptr))return -EFAULT ; + gfsflags =fsflags_cvt (fsflags_to_gfs2, fsflags);if (!S_ISDIR (inode->i_mode)) {if (gfsflags &GFS2_DIF_INHERIT_JDATA )
PATCH 122/149 sctp: Fix skb_over_panic resulting from multiple invalid parameter errors (CVE-2010-1173) (v4)
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Neil Horman <[email protected]>
commit 5fa782c2f5ef6c2e4f04d3e228412c9b4a4c8809 upstream.
Ok, version 4
Change Notes:
1) Minor cleanups, from Vlads notes
Summary:
Hey-
Recently, it was reported to me that the kernel could oops in the
following way:
<5> kernel BUG at net/core/skbuff.c:91!
<5> invalid operand: 0000 [#1]
<5> Modules linked in: sctp netconsole nls_utf8 autofs4 sunrpc iptable_filter ip_tables cpufreq_powersave parport_pc lp parport vmblock(U) vsock(U) vmci(U) vmxnet(U) vmmemctl(U) vmhgfs(U) acpiphp dm_mirror dm_mod button battery ac md5 ipv6 uhci_hcd ehci_hcd snd_ens1371 snd_rawmidi snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd_ac97_codec snd soundcore pcnet32 mii floppy ext3 jbd ata_piix libata mptscsih mptsas mptspi mptscsi mptbase sd_mod scsi_mod
<5> CPU: 0
<5> EIP: 0060:[<c02bff27>] Not tainted VLI
<5> EFLAGS: 00010216 (2.6.9-89.0.25.EL)
<5> EIP is at skb_over_panic+0x1f/0x2d
<5> eax: 0000002c ebx: c033f461 ecx: c0357d96 edx: c040fd44 <5> esi: c033f461 edi: df653280 ebp: 00000000 esp: c040fd40
<5> ds: 007b es: 007b ss: 0068
<5> Process swapper (pid: 0, threadinfo=c040f000 task=c0370be0) <5> Stack: c0357d96 e0c29478 00000084 00000004 c033f461 df653280 d7883180 e0c2947d
<5> 00000000 00000080 df653490 00000004 de4f1ac0 de4f1ac0 00000004df653490
<5> 00000001 e0c2877a 08000800 de4f1ac0 df653490 00000000 e0c29d2e
00000004
<5> Call Trace:
<5> [<e0c29478>] sctp_addto_chunk+0xb0/0x128 [sctp] <5> [<e0c2947d>] sctp_addto_chunk+0xb5/0x128 [sctp] <5> [<e0c2877a>] sctp_init_cause+0x3f/0x47 [sctp] <5> [<e0c29d2e>] sctp_process_unk_param+0xac/0xb8 [sctp] <5> [<e0c29e90>] sctp_verify_init+0xcc/0x134 [sctp] <5> [<e0c20322>] sctp_sf_do_5_1B_init+0x83/0x28e [sctp] <5> [<e0c25333>] sctp_do_sm+0x41/0x77 [sctp] <5> [<c01555a4>] cache_grow+0x140/0x233 <5> [<e0c26ba1>] sctp_endpoint_bh_rcv+0xc5/0x108 [sctp] <5> [<e0c2b863>] sctp_inq_push+0xe/0x10 [sctp] <5> [<e0c34600>] sctp_rcv+0x454/0x509 [sctp] <5> [<e084e017>] ipt_hook+0x17/0x1c [iptable_filter] <5> [<c02d005e>] nf_iterate+0x40/0x81 <5> [<c02e0bb9>] ip_local_deliver_finish+0x0/0x151 <5> [<c02e0c7f>] ip_local_deliver_finish+0xc6/0x151 <5> [<c02d0362>] nf_hook_slow+0x83/0xb5 <5> [<c02e0bb2>] ip_local_deliver+0x1a2/0x1a9 <5> [<c02e0bb9>] ip_local_deliver_finish+0x0/0x151 <5> [<c02e103e>] ip_rcv+0x334/0x3b4 <5> [<c02c66fd>] netif_receive_skb+0x320/0x35b <5> [<e0a0928b>] init_stall_timer+0x67/0x6a [uhci_hcd] <5> [<c02c67a4>] process_backlog+0x6c/0xd9 <5> [<c02c690f>] net_rx_action+0xfe/0x1f8 <5> [<c012a7b1>] __do_softirq+0x35/0x79 <5> [<c0107efb>] handle_IRQ_event+0x0/0x4f <5> [<c01094de>] do_softirq+0x46/0x4d
Its an skb_over_panic BUG halt that results from processing an init chunk in which too many of its variable length parameters are in some way malformed.
The problem is in sctp_process_unk_param:
if (NULL == *errp)
*errp = sctp_make_op_error_space(asoc, chunk,
ntohs(chunk->chunk_hdr->length));
if (*errp) {
sctp_init_cause(*errp, SCTP_ERROR_UNKNOWN_PARAM,
WORD_ROUND(ntohs(param.p->length)));
sctp_addto_chunk(*errp,
WORD_ROUND(ntohs(param.p->length)),
param.v);When we allocate an error chunk, we assume that the worst case scenario requires that we have chunk_hdr->length data allocated, which would be correct nominally, given that we call sctp_addto_chunk for the violating parameter. Unfortunately, we also, in sctp_init_cause insert a sctp_errhdr_t structure into the error chunk, so the worst case situation in which all parameters are in violation requires chunk_hdr->length+(sizeof(sctp_errhdr_t)*param_count) bytes of data.
The result of this error is that a deliberately malformed packet sent to a listening host can cause a remote DOS, described in CVE-2010-1173:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=2010-1173
I've tested the below fix and confirmed that it fixes the issue. We move to a strategy whereby we allocate a fixed size error chunk and ignore errors we don't have space to report. Tested by me successfully
--- include/net/sctp/structs.h | 1 net/sctp/sm_make_chunk.c | 62 +++++++++++++++++++++++++++++++++++++++++---- 2 files changed, 58 insertions(+), 5 deletions(-)
include/net/sctp/structs.h +1 -0
@@ -772,6 +772,7 @@ int sctp_user_addto_chunk(struct sctp_ch struct iovec *data);void sctp_chunk_free (struct sctp_chunk *);void *sctp_addto_chunk (struct sctp_chunk *,int len,const void *data); +void *sctp_addto_chunk_fixed (struct sctp_chunk *,int len,const void *data);struct sctp_chunk *sctp_chunkify (struct sk_buff *,const struct sctp_association *,struct sock *);
net/sctp/sm_make_chunk.c +57 -5
95 lines not on this page · raw message
PATCH 123/149 CIFS: Allow null nd (as nfs server uses) on create
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Steve French <[email protected]>
commit fa588e0c57048b3d4bfcd772d80dc0615f83fd35 upstream.
While creating a file on a server which supports unix extensions such as Samba, if a file is being created which does not supply nameidata (i.e. nd is null), cifs client can oops when calling cifs_posix_open.
--- fs/cifs/cifsproto.h | 6 ++++-- fs/cifs/dir.c | 20 ++++++++++++-------- fs/cifs/file.c | 11 +++++++---- 3 files changed, 23 insertions(+), 14 deletions(-)
fs/cifs/cifsproto.h +4 -2
@@ -95,8 +95,10 @@ extern struct cifsFileInfo *cifs_new_fil __u16 fileHandle, struct file *file, struct vfsmount *mnt, unsigned int oflags);extern int cifs_posix_open (char *full_path,struct inode **pinode, -struct vfsmount *mnt,int mode,int oflags, -__u32 *poplock,__u16 *pnetfid,int xid); +struct vfsmount *mnt, +struct super_block *sb, +int mode,int oflags, +__u32 *poplock,__u16 *pnetfid,int xid);extern void cifs_unix_basic_to_fattr (struct cifs_fattr *fattr,FILE_UNIX_BASIC_INFO *info,struct cifs_sb_info *cifs_sb);
fs/cifs/dir.c +12 -8
@@ -183,13 +183,14 @@ cifs_new_fileinfo(struct inode *newinode }int cifs_posix_open (char *full_path,struct inode **pinode, -struct vfsmount *mnt,int mode,int oflags, -__u32 *poplock,__u16 *pnetfid,int xid) +struct vfsmount *mnt,struct super_block *sb, +int mode,int oflags, +__u32 *poplock,__u16 *pnetfid,int xid) {int rc;FILE_UNIX_BASIC_INFO *presp_data;__u32 posix_flags =0 ; -struct cifs_sb_info *cifs_sb =CIFS_SB (mnt->mnt_sb); +struct cifs_sb_info *cifs_sb =CIFS_SB (sb);struct cifs_fattr fattr;cFYI (1 , ("posix open %s" , full_path));
@@ -241,7 +242,7 @@ int cifs_posix_open(char *full_path, str/* get new inode and set it up */ if (*pinode ==NULL ) { - *pinode =cifs_iget (mnt->mnt_sb, &fattr); + *pinode =cifs_iget (sb, &fattr);if (!*pinode) { rc = -ENOMEM ; goto posix_open_ret;
@@ -250,7 +251,8 @@ int cifs_posix_open(char *full_path, strcifs_fattr_to_inode (*pinode, &fattr); } -cifs_new_fileinfo (*pinode, *pnetfid,NULL , mnt, oflags); +if (mnt) +cifs_new_fileinfo (*pinode, *pnetfid,NULL , mnt, oflags); posix_open_ret:kfree (presp_data);
@@ -314,13 +316,14 @@ cifs_create(struct inode *inode, structif (nd && (nd->flags &LOOKUP_OPEN )) oflags = nd->intent.open.flags;else - oflags =FMODE_READ ; + oflags =FMODE_READ |SMB_O_CREAT ;if (tcon->unix_ext && (tcon->ses->capabilities &CAP_UNIX ) && (CIFS_UNIX_POSIX_PATH_OPS_CAP &le64_to_cpu (tcon->fsUnixInfo.Capability))) { - rc =cifs_posix_open (full_path, &newinode, nd->path.mnt, - mode, oflags, &oplock, &fileHandle, xid); + rc =cifs_posix_open (full_path, &newinode, + nd ? nd->path.mnt :NULL , + inode->i_sb, mode, oflags, &oplock, &fileHandle, xid);/* EIO could indicate that (posix open) operation is not supported, despite what server claimed in capability negotation. EREMOTE indicates DFS junction, which is not
@@ -677,6 +680,7 @@ cifs_lookup(struct inode *parent_dir_ino (nd->flags & LOOKUP_OPEN) && !pTcon->broken_posix_open && (nd->intent.open.flags & O_CREAT)) { rc =cifs_posix_open (full_path, &newInode, nd->path.mnt, + parent_dir_inode->i_sb, nd->intent.open.create_mode, nd->intent.open.flags, &oplock, &fileHandle, xid);
fs/cifs/file.c +7 -4
@@ -295,10 +295,12 @@ int cifs_open(struct inode *inode, struc (CIFS_UNIX_POSIX_PATH_OPS_CAP & le64_to_cpu(tcon->fsUnixInfo.Capability))) {int oflags = (int )cifs_posix_convert_flags (file->f_flags); + oflags |=SMB_O_CREAT ;/* can not refresh inode info since size could be stale */ rc =cifs_posix_open (full_path, &inode, file->f_path.mnt, - cifs_sb->mnt_file_mode/* ignored */ , - oflags, &oplock, &netfid, xid); + inode->i_sb, + cifs_sb->mnt_file_mode/* ignored */ , + oflags, &oplock, &netfid, xid);if (rc ==0 ) {cFYI (1 , ("posix open succeeded" ));/* no need for special case handling of setting mode
@@ -510,8 +512,9 @@ reopen_error_exit:int oflags = (int )cifs_posix_convert_flags (file->f_flags);/* can not refresh inode info since size could be stale */ rc =cifs_posix_open (full_path,NULL , file->f_path.mnt, - cifs_sb->mnt_file_mode/* ignored */ , - oflags, &oplock, &netfid, xid); + inode->i_sb, + cifs_sb->mnt_file_mode/* ignored */ , + oflags, &oplock, &netfid, xid);if (rc ==0 ) {cFYI (1 , ("posix reopen succeeded" )); goto reopen_success;
PATCH 124/149 vfs: add NOFOLLOW flag to umount(2)
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Miklos Szeredi <[email protected]>
commit db1f05bb85d7966b9176e293f3ceead1cb8b5d79 upstream.
Add a new UMOUNT_NOFOLLOW flag to umount(2). This is needed to prevent symlink attacks in unprivileged unmounts (fuse, samba, ncpfs).
Additionally, return -EINVAL if an unknown flag is used (and specify an explicitly unused flag: UMOUNT_UNUSED). This makes it possible for the caller to determine if a flag is supported or not.
--- fs/namespace.c | 9 ++++++++- include/linux/fs.h | 2 ++ 2 files changed, 10 insertions(+), 1 deletion(-)
fs/namespace.c +8 -1
@@ -1119,8 +1119,15 @@ SYSCALL_DEFINE2(umount, char __user *, n {struct path path;int retval; +int lookup_flags =0 ; - retval =user_path (name, &path); +if (flags & ~(MNT_FORCE |MNT_DETACH |MNT_EXPIRE |UMOUNT_NOFOLLOW )) +return -EINVAL ; + +if (!(flags &UMOUNT_NOFOLLOW )) + lookup_flags |=LOOKUP_FOLLOW ; + + retval =user_path_at (AT_FDCWD , name, lookup_flags, &path);if (retval) goto out; retval = -EINVAL ;
include/linux/fs.h +2 -0
@@ -1310,6 +1310,8 @@ extern int send_sigurg(struct fown_struc#define MNT_FORCE 0x00000001/* Attempt to forcibily umount */ #define MNT_DETACH 0x00000002/* Just detach from the tree */ #define MNT_EXPIRE 0x00000004/* Mark for expiry */ +#define UMOUNT_NOFOLLOW 0x00000008/* Don't follow symlink on umount */ +#define UMOUNT_UNUSED 0x80000000/* Flag guaranteed to be unused */ extern struct list_head super_blocks;extern spinlock_t sb_lock;
PATCH 125/149 l2tp: Fix oops in pppol2tp_xmit
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: James Chapman <[email protected]>
commit 3feec9095d12e311b7d4eb7fe7e5dfa75d4a72a5 upstream.
When transmitting L2TP frames, we derive the outgoing interface's UDP checksum hardware assist capabilities from the tunnel dst dev. This can sometimes be NULL, especially when routing protocols are used and routing changes occur. This patch just checks for NULL dst or dev pointers when checking for netdev hardware assist features.
BUG: unable to handle kernel NULL pointer dereference at 0000000c IP: [<f89d074c>] pppol2tp_xmit+0x341/0x4da [pppol2tp] *pde = 00000000 Oops: 0000 [#1] SMP last sysfs file: /sys/class/net/lo/operstate Modules linked in: pppol2tp pppox ppp_generic slhc ipv6 dummy loop snd_hda_codec_atihdmi snd_hda_intel snd_hda_codec snd_pcm snd_timer snd soundcore snd_page_alloc evdev psmouse serio_raw processor button i2c_piix4 i2c_core ati_agp agpgart pcspkr ext3 jbd mbcache sd_mod ide_pci_generic atiixp ide_core ahci ata_generic floppy ehci_hcd ohci_hcd libata e1000e scsi_mod usbcore nls_base thermal fan thermal_sys [last unloaded: scsi_wait_scan]
Pid: 0, comm: swapper Not tainted (2.6.32.8 #1)
EIP: 0060:[<f89d074c>] EFLAGS: 00010297 CPU: 3
EIP is at pppol2tp_xmit+0x341/0x4da [pppol2tp]
EAX: 00000000 EBX: f64d1680 ECX: 000005b9 EDX: 00000000
ESI: f6b91850 EDI: f64d16ac EBP: f6a0c4c0 ESP: f70a9cac
DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
Process swapper (pid: 0, ti=f70a8000 task=f70a31c0 task.ti=f70a8000)
Stack: 000005a9 000005b9 f734c400 f66652c0 f7352e00 f67dc800 00000000 f6b91800 <0> 000005a3 f70ef6c4 f67dcda9 000005a3 f89b192e 00000246 000005a3 f64d1680 <0> f63633e0 f6363320 f64d1680 f65a7320 f65a7364 f65856c0 f64d1680 f679f02f Call Trace: [<f89b192e>] ? ppp_push+0x459/0x50e [ppp_generic] [<f89b217f>] ? ppp_xmit_process+0x3b6/0x430 [ppp_generic] [<f89b2306>] ? ppp_start_xmit+0x10d/0x120 [ppp_generic] [<c11c15cb>] ? dev_hard_start_xmit+0x21f/0x2b2 [<c11d0947>] ? sch_direct_xmit+0x48/0x10e [<c11c19a0>] ? dev_queue_xmit+0x263/0x3a6 [<c11e2a9f>] ? ip_finish_output+0x1f7/0x221 [<c11df682>] ? ip_forward_finish+0x2e/0x30 [<c11de645>] ? ip_rcv_finish+0x295/0x2a9 [<c11c0b19>] ? netif_receive_skb+0x3e9/0x404 [<f814b791>] ? e1000_clean_rx_irq+0x253/0x2fc [e1000e] [<f814cb7a>] ? e1000_clean+0x63/0x1fc [e1000e] [<c1047eff>] ? sched_clock_local+0x15/0x11b [<c11c1095>] ? net_rx_action+0x96/0x195 [<c1035750>] ? __do_softirq+0xaa/0x151 [<c1035828>] ? do_softirq+0x31/0x3c [<c10358fe>] ? irq_exit+0x26/0x58 [<c1004b21>] ? do_IRQ+0x78/0x89 [<c1003729>] ? common_interrupt+0x29/0x30 [<c101ac28>] ? native_safe_halt+0x2/0x3 [<c1008c54>] ? default_idle+0x55/0x75 [<c1009045>] ? c1e_idle+0xd2/0xd5 [<c100233c>] ? cpu_idle+0x46/0x62 Code: 8d 45 08 f0 ff 45 08 89 6b 08 c7 43 68 7e fb 9c f8 8a 45 24 83 e0 0c 3c 04 75 09 80 63 64 f3 e9 b4 00 00 00 8b 43 18 8b 4c 24 04 <8b> 40 0c 8d 79 11 f6 40 44 0e 8a 43 64 75 51 6a 00 8b 4c 24 08 EIP: [<f89d074c>] pppol2tp_xmit+0x341/0x4da [pppol2tp] SS:ESP 0068:f70a9cac
CR2: 000000000000000c
--- drivers/net/pppol2tp.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/net/pppol2tp.c +2 -1
@@ -1178,7 +1178,8 @@ static int pppol2tp_xmit(struct ppp_chan/* Calculate UDP checksum if configured to do so */ if (sk_tun->sk_no_check ==UDP_CSUM_NOXMIT ) skb->ip_summed =CHECKSUM_NONE ; -else if (!(skb_dst (skb)->dev->features &NETIF_F_V4_CSUM )) { +else if ((skb_dst (skb) &&skb_dst (skb)->dev) && + (!(skb_dst (skb)->dev->features &NETIF_F_V4_CSUM ))) { skb->ip_summed =CHECKSUM_COMPLETE ; csum =skb_checksum (skb,0 , udp_len,0 ); uh->check = csum_tcpudp_magic(inet->saddr, inet->daddr,
PATCH 126/149 Btrfs: should add a permission check for setfacl
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Shi Weihua <[email protected]>
commit 2f26afba46f0ebf155cf9be746496a0304a5b7cf upstream.
On btrfs, do the following
------------------
# su user1 # cd btrfs-part/ # touch aaa # getfacl aaa # file: aaa # owner: user1 # group: user1 user::rw- group::rw- other::r-- # su user2 # cd btrfs-part/ # setfacl -m u::rwx aaa # getfacl aaa # file: aaa # owner: user1 # group: user1 user::rwx <- successed to setfacl group::rw- other::r-- ------------------ but we should prohibit it that user2 changing user1's acl. In fact, on ext3 and other fs, a message occurs: setfacl: aaa: Operation not permitted
This patch fixed it.
--- fs/btrfs/acl.c | 3 +++ 1 file changed, 3 insertions(+)
fs/btrfs/acl.c +3 -0
@@ -157,6 +157,9 @@ static int btrfs_xattr_set_acl(struct inint ret =0 ;struct posix_acl *acl =NULL ; +if (!is_owner_or_cap (inode)) +return -EPERM ; +if (value) { acl =posix_acl_from_xattr (value, size);if (acl ==NULL ) {
PATCH 127/149 ucc_geth: Fix empty TX queue processing
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Anton Vorontsov <[email protected]>
commit 7583605b6d29f1f7f6fc505b883328089f3485ad upstream.
Following oops was seen with the ucc_geth driver:
Unable to handle kernel paging request for data at address 0x00000058 Faulting instruction address: 0xc024f2fc Oops: Kernel access of bad area, sig: 11 [#1] [...] NIP [c024f2fc] skb_recycle_check+0x14/0x100 LR [e30aa0a4] ucc_geth_poll+0xd8/0x4e0 [ucc_geth_driver] Call Trace: [df857d50] [c000b03c] __ipipe_grab_irq+0x3c/0xa4 (unreliable) [df857d60] [e30aa0a4] ucc_geth_poll+0xd8/0x4e0 [ucc_geth_driver] [df857dd0] [c0258cf8] net_rx_action+0xf8/0x1b8 [df857e10] [c0032a38] __do_softirq+0xb8/0x13c [df857e60] [c00065cc] do_softirq+0xa0/0xac [...]
This is because ucc_geth_tx() tries to process an empty queue when queues are logically stopped. Stopping the queues doesn't disable polling, and since nowadays ucc_geth_tx() is actually called from the polling routine, the oops above might pop up.
Fix this by removing 'netif_queue_stopped() == 0' check.
--- drivers/net/ucc_geth.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ucc_geth.c +1 -1
@@ -3273,7 +3273,7 @@ static int ucc_geth_tx(struct net_device/* Handle the transmitted buffer and release */ /* the BD to be used with the current frame */ -if ((bd == ugeth->txBd[txQ]) && (netif_queue_stopped (dev) ==0 )) +if (bd == ugeth->txBd[txQ])/* queue empty? */ break ; dev->stats.tx_packets++;
PATCH 128/149 ucc_geth: Fix netdev watchdog triggering on link changes
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Anton Vorontsov <[email protected]>
commit 08b5e1c91ce95793c59a59529a362a1bcc81faae upstream.
Since commit 864fdf884e82bacbe8ca5e93bd43393a61d2e2b4 ("ucc_geth:
Fix hangs after switching from full to half duplex") ucc_geth driver disables the controller during MAC configuration changes. Though, disabling the controller might take quite awhile, and so the netdev watchdog might get upset:
NETDEV WATCHDOG: eth2 (ucc_geth): transmit queue 0 timed out
------------[ cut here ]------------ Badness at c02729a8 [verbose debug info unavailable] NIP: c02729a8 LR: c02729a8 CTR: c01b6088 REGS: c0451c40 TRAP: 0700 Not tainted (2.6.32-trunk-8360e) [...] NIP [c02729a8] dev_watchdog+0x280/0x290 LR [c02729a8] dev_watchdog+0x280/0x290 Call Trace: [c0451cf0] [c02729a8] dev_watchdog+0x280/0x290 (unreliable) [c0451d50] [c00377c4] run_timer_softirq+0x164/0x224 [c0451da0] [c0032a38] __do_softirq+0xb8/0x13c [c0451df0] [c00065cc] do_softirq+0xa0/0xac [c0451e00] [c003280c] irq_exit+0x7c/0x9c [c0451e10] [c00640c4] __ipipe_sync_stage+0x248/0x24c [...]
This patch fixes the issue by detaching the netdev during the time we change the configuration.
--- drivers/net/ucc_geth.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
drivers/net/ucc_geth.c +5 -2
@@ -1563,7 +1563,10 @@ static int ugeth_disable(struct ucc_gethstatic void ugeth_quiesce (struct ucc_geth_private *ugeth) { -/* Wait for and prevent any further xmits. */ +/* Prevent any further xmits, plus detach the device. */ +netif_device_detach (ugeth->ndev); + +/* Wait for any current xmits to finish. */ netif_tx_disable (ugeth->ndev);/* Disable the interrupt to avoid NAPI rescheduling. */
@@ -1577,7 +1580,7 @@ static void ugeth_activate(struct ucc_ge {napi_enable (&ugeth->napi);enable_irq (ugeth->ug_info->uf_info.irq); -netif_tx_wake_all_queues (ugeth->ndev); +netif_device_attach (ugeth->ndev); }/* Called every time the controller might need to be made
PATCH 129/149 ucc_geth: Fix full TX queue processing
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Jiajun Wu <[email protected]>
commit 34692421bc7d6145ef383b014860f4fde10b7505 upstream.
commit 7583605b6d29f1f7f6fc505b883328089f3485ad ("ucc_geth: Fix empty TX queue processing") fixed empty TX queue mishandling, but didn't account another corner case: when TX queue becomes full.
Without this patch the driver will stop transmiting when TX queue becomes full since 'bd == ugeth->txBd[txQ]' actually checks for two things: queue empty or full.
Let's better check for NULL skb, which unambiguously signals an empty queue.
--- drivers/net/ucc_geth.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
drivers/net/ucc_geth.c +2 -3
@@ -3276,13 +3276,12 @@ static int ucc_geth_tx(struct net_device/* Handle the transmitted buffer and release */ /* the BD to be used with the current frame */ -if (bd == ugeth->txBd[txQ])/* queue empty? */ + skb = ugeth->tx_skbuff[txQ][ugeth->skb_dirtytx[txQ]]; +if (!skb)break ; dev->stats.tx_packets++; - skb = ugeth->tx_skbuff[txQ][ugeth->skb_dirtytx[txQ]]; -if (skb_queue_len (&ugeth->rx_recycle) <RX_BD_RING_LEN && skb_recycle_check(skb, ugeth->ug_info->uf_info.max_rx_buf_length +
PATCH 130/149 tipc: Fix oops on send prior to entering networked mode (v3)
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Neil Horman <[email protected]>
commit d0021b252eaf65ca07ed14f0d66425dd9ccab9a6 upstream.
Fix TIPC to disallow sending to remote addresses prior to entering NET_MODE
user programs can oops the kernel by sending datagrams via AF_TIPC prior to entering networked mode. The following backtrace has been observed:
ID: 13459 TASK: ffff810014640040 CPU: 0 COMMAND: "tipc-client"
[exception RIP: tipc_node_select_next_hop+90]
RIP: ffffffff8869d3c3 RSP: ffff81002d9a5ab8 RFLAGS: 00010202 RAX: 0000000000000001 RBX: 0000000000000001 RCX: 0000000000000001 RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000001001001 RBP: 0000000001001001 R8: 0074736575716552 R9: 0000000000000000 R10: ffff81003fbd0680 R11: 00000000000000c8 R12: 0000000000000008 R13: 0000000000000001 R14: 0000000000000001 R15: ffff810015c6ca00 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 RIP: 0000003cbd8d49a3 RSP: 00007fffc84e0be8 RFLAGS: 00010206 RAX: 000000000000002c RBX: ffffffff8005d116 RCX: 0000000000000000 RDX: 0000000000000008 RSI: 00007fffc84e0c00 RDI: 0000000000000003 RBP: 0000000000000000 R8: 00007fffc84e0c10 R9: 0000000000000010 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fffc84e0d10 R14: 0000000000000000 R15: 00007fffc84e0c30 ORIG_RAX: 000000000000002c CS: 0033 SS: 002b
What happens is that, when the tipc module in inserted it enters a standalone node mode in which communication to its own address is allowed <0.0.0> but not to other addresses, since the appropriate data structures have not been allocated yet (specifically the tipc_net pointer). There is nothing stopping a client from trying to send such a message however, and if that happens, we attempt to dereference tipc_net.zones while the pointer is still NULL, and explode. The fix is pretty straightforward. Since these oopses all arise from the dereference of global pointers prior to their assignment to allocated values, and since these allocations are small (about 2k total), lets convert these pointers to static arrays of the appropriate size. All the accesses to these bits consider 0/NULL to be a non match when searching, so all the lookups still work properly, and there is no longer a chance of a bad dererence anywhere. As a bonus, this lets us eliminate the setup/teardown routines for those pointers, and elimnates the need to preform any locking around them to prevent access while their being allocated/freed.
I've updated the tipc_net structure to behave this way to fix the exact reported problem, and also fixed up the tipc_bearers and media_list arrays to fix an obvious simmilar problem that arises from issuing tipc-config commands to manipulate bearers/links prior to entering networked mode
I've tested this for a few hours by running the sanity tests and stress test with the tipcutils suite, and nothing has fallen over. There have been a few lockdep warnings, but those were there before, and can be addressed later, as they didn't actually result in any deadlock.
--- net/tipc/bearer.c | 37 ++++++------------------------------- net/tipc/bearer.h | 2 +- net/tipc/net.c | 25 ++++--------------------- 3 files changed, 11 insertions(+), 53 deletions(-)
net/tipc/bearer.c +6 -31
@@ -45,10 +45,10 @@#define MAX_ADDR_STR 32 -static struct media *media_list =NULL ; +static struct media media_list[MAX_MEDIA ];static u32 media_count =0 ; -struct bearer *tipc_bearers =NULL ; +struct bearer tipc_bearers[MAX_BEARERS ];/** * media_name_valid - validate media name
@@ -108,9 +108,11 @@ int tipc_register_media(u32 media_type,int res = -EINVAL ;write_lock_bh (&tipc_net_lock); -if (!media_list) - goto exit; +if (tipc_mode !=TIPC_NET_MODE ) { +warn ("Media <%s> rejected, not in networked mode yet\n" , name); + goto exit; + }if (!media_name_valid (name)) {warn ("Media <%s> rejected, illegal name\n" , name); goto exit;
@@ -660,33 +662,10 @@ int tipc_disable_bearer(const char *name -int tipc_bearer_init (void ) -{ -int res; - -write_lock_bh (&tipc_net_lock); - tipc_bearers =kcalloc (MAX_BEARERS ,sizeof (struct bearer ),GFP_ATOMIC ); - media_list =kcalloc (MAX_MEDIA ,sizeof (struct media ),GFP_ATOMIC ); -if (tipc_bearers && media_list) { - res =0 ; - }else { -kfree (tipc_bearers); -kfree (media_list); - tipc_bearers =NULL ; - media_list =NULL ; - res = -ENOMEM ; - } -write_unlock_bh (&tipc_net_lock); -return res; -} -void tipc_bearer_stop (void ) {u32 i; -if (!tipc_bearers) -return ; -for (i =0 ; i <MAX_BEARERS ; i++) {if (tipc_bearers[i].active) tipc_bearers[i].publ.blocked =1 ;
@@ -695,10 +674,6 @@ void tipc_bearer_stop(void)if (tipc_bearers[i].active)bearer_disable (tipc_bearers[i].publ.name); } -kfree (tipc_bearers); -kfree (media_list); - tipc_bearers =NULL ; - media_list =NULL ; media_count =0 ; }
net/tipc/bearer.h +1 -1
@@ -114,7 +114,7 @@ struct bearer_name {struct link ; -extern struct bearer *tipc_bearers; +extern struct bearer tipc_bearers[];void tipc_media_addr_printf (struct print_buf *pb,struct tipc_media_addr *a);struct sk_buff *tipc_media_get_names (void );
net/tipc/net.c +4 -21
@@ -116,7 +116,8 @@*/ DEFINE_RWLOCK (tipc_net_lock); -struct network tipc_net = {NULL }; +struct _zone *tipc_zones[256 ] = {NULL , }; +struct network tipc_net = { tipc_zones };struct tipc_node *tipc_net_select_remote_node (u32 addr,u32 ref) {
@@ -158,28 +159,12 @@ void tipc_net_send_external_routes(u32 d } } -static int net_init (void ) -{ -memset (&tipc_net,0 ,sizeof (tipc_net)); - tipc_net.zones =kcalloc (tipc_max_zones +1 ,sizeof (struct _zone *),GFP_ATOMIC ); -if (!tipc_net.zones) { -return -ENOMEM ; - } -return 0 ; -} -static void net_stop (void ) {u32 z_num; -if (!tipc_net.zones) -return ; - -for (z_num =1 ; z_num <= tipc_max_zones; z_num++) { +for (z_num =1 ; z_num <= tipc_max_zones; z_num++)tipc_zone_delete (tipc_net.zones[z_num]); - } -kfree (tipc_net.zones); - tipc_net.zones =NULL ; }static void net_route_named_msg (struct sk_buff *buf)
@@ -282,9 +267,7 @@ int tipc_net_start(u32 addr)tipc_named_reinit ();tipc_port_reinit (); -if ((res =tipc_bearer_init ()) || - (res =net_init ()) || - (res =tipc_cltr_init ()) || +if ((res =tipc_cltr_init ()) || (res =tipc_bclink_init ())) {return res; }
PATCH 131/149 Input: psmouse - reset all types of mice before reconnecting
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Dmitry Torokhov <[email protected]>
commit ef110b24e28f36620f63dab94708a17c7e267358 upstream.
Synaptics hardware requires resetting device after suspend to ram in order for the device to be operational. The reset lives in synaptics-specific reconnect handler, but it is not being invoked if synaptics support is disabled and the device is handled as a standard PS/2 device (bare or IntelliMouse protocol).
Let's add reset into generic reconnect handler as well.
--- drivers/input/mouse/psmouse-base.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-)
drivers/input/mouse/psmouse-base.c +10 -4
@@ -1349,6 +1349,7 @@ static int psmouse_reconnect(struct seristruct psmouse *psmouse =serio_get_drvdata (serio);struct psmouse *parent =NULL ;struct serio_driver *drv = serio->drv; +unsigned char type;int rc =-1 ;if (!drv || !psmouse) {
@@ -1368,10 +1369,15 @@ static int psmouse_reconnect(struct seriif (psmouse->reconnect) {if (psmouse->reconnect (psmouse)) goto out; - }else if (psmouse_probe (psmouse) <0 || - psmouse->type !=psmouse_extensions (psmouse, - psmouse_max_proto, false)) { - goto out; + }else { +psmouse_reset (psmouse); + +if (psmouse_probe (psmouse) <0 ) + goto out; + + type =psmouse_extensions (psmouse, psmouse_max_proto, false); +if (psmouse->type != type) + goto out; }/* ok, the device type (and capabilities) match the old one,
PATCH 132/149 KVM: s390: Fix possible memory leak of in kvm_arch_vcpu_create()
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Wei Yongjun <[email protected]>
This patch fixed possible memory leak in kvm_arch_vcpu_create() under s390, which would happen when kvm_arch_vcpu_create() fails.
--- arch/s390/kvm/kvm-s390.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
arch/s390/kvm/kvm-s390.c +3 -1
@@ -338,11 +338,13 @@ struct kvm_vcpu *kvm_arch_vcpu_create(st rc =kvm_vcpu_init (vcpu, kvm, id);if (rc) - goto out_free_cpu; + goto out_free_sie_block;VM_EVENT (kvm,3 ,"create cpu %d at %p, sie block at %p" , id, vcpu, vcpu->arch.sie_block);return vcpu; +out_free_sie_block: +free_page ((unsigned long )(vcpu->arch.sie_block)); out_free_cpu:kfree (vcpu); out_nomem:
PATCH 133/149 KVM: PPC: Do not create debugfs if fail to create vcpu
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Wei Yongjun <[email protected]>
If fail to create the vcpu, we should not create the debugfs for it.
--- arch/powerpc/kvm/powerpc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
arch/powerpc/kvm/powerpc.c +2 -1
@@ -176,7 +176,8 @@ struct kvm_vcpu *kvm_arch_vcpu_create(st {struct kvm_vcpu *vcpu; vcpu =kvmppc_core_vcpu_create (kvm, id); -kvmppc_create_vcpu_debugfs (vcpu, id); +if (!IS_ERR (vcpu)) +kvmppc_create_vcpu_debugfs (vcpu, id);return vcpu; }
PATCH 134/149 x86, paravirt: Add a global synchronization point for pvclock
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Glauber Costa <[email protected]>
In recent stress tests, it was found that pvclock-based systems could seriously warp in smp systems. Using ingo's time-warp-test.c, I could trigger a scenario as bad as 1.5mi warps a minute in some systems. (to be fair, it wasn't that bad in most of them). Investigating further, I found out that such warps were caused by the very offset-based calculation pvclock is based on.
This happens even on some machines that report constant_tsc in its tsc flags, specially on multi-socket ones.
Two reads of the same kernel timestamp at approx the same time, will likely have tsc timestamped in different occasions too. This means the delta we calculate is unpredictable at best, and can probably be smaller in a cpu that is legitimately reading clock in a forward ocasion.
Some adjustments on the host could make this window less likely to happen, but still, it pretty much poses as an intrinsic problem of the mechanism.
A while ago, I though about using a shared variable anyway, to hold clock last state, but gave up due to the high contention locking was likely to introduce, possibly rendering the thing useless on big machines. I argue, however, that locking is not necessary.
We do a read-and-return sequence in pvclock, and between read and return, the global value can have changed. However, it can only have changed by means of an addition of a positive value. So if we detected that our clock timestamp is less than the current global, we know that we need to return a higher one, even though it is not exactly the one we compared to.
OTOH, if we detect we're greater than the current time source, we atomically replace the value with our new readings. This do causes contention on big boxes (but big here means *BIG*), but it seems like a good trade off, since it provide us with a time source guaranteed to be stable wrt time warps.
After this patch is applied, I don't see a single warp in time during 5 days of execution, in any of the machines I saw them before.
--- arch/x86/kernel/pvclock.c | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+)
arch/x86/kernel/pvclock.c +24 -0
@@ -109,11 +109,14 @@ unsigned long pvclock_tsc_khz(struct pvcreturn pv_tsc_khz; } +static atomic64_t last_value =ATOMIC64_INIT (0 ); +cycle_t pvclock_clocksource_read (struct pvclock_vcpu_time_info *src) {struct pvclock_shadow_time shadow;unsigned version;cycle_t ret, offset; +u64 last; do { version = pvclock_get_time_values(&shadow, src);
@@ -123,6 +126,27 @@ cycle_t pvclock_clocksource_read(structbarrier (); }while (version != src->version); +/* +* Assumption here is that last_value, a global accumulator, always goes +* forward. If we are less than that, we should not be much smaller. +* We assume there is an error marging we're inside, and then the correction +* does not sacrifice accuracy. +* +* For reads: global may have changed between test and return, +* but this means someone else updated poked the clock at a later time. +* We just need to make sure we are not seeing a backwards event. +* +* For updates: last_value = ret is not enough, since two vcpus could be +* updating at the same time, and one of them could be slightly behind, +* making the assumption that last_value always go forward fail to hold. +*/ + last =atomic64_read (&last_value); +do { +if (ret < last) +return last; + last =atomic64_cmpxchg (&last_value, last, ret); + }while (unlikely (last != ret)); +return ret; }
Re: [patch 134/149] x86, paravirt: Add a global synchronization point for pvclock
Hey,
Greg KH schrieb am Donnerstag, dem 01. Juli 2010:
Quoted 1 line
2.6.32-stable review patch. If anyone has any objections, please let us know.
2.6.32.16 fails to boot on my KVM domains using qemu-kvm 0.11.1.
Bisecting between 2.6.32.14 which worked and .16 turned up this commit as the first culprit[0].
The host is still running 2.6.32.14 and has 8 cores on 2 CPUs. The single-cpu KVM domain hangs just after printing 'Write protecting the
kernel read-only data: 9492k'[1]. On a successful boot this line would
usually be followed by 'INIT: version 2.86 booting'.
A 2.6.32.16 with this patch reverted boots fine.
If there's any info you need please just ask.
Cheers,
Peter
0. http://asteria.noreply.org/~weasel/volatile/2010-07-07-x9KxN34l17c/fileztnjyZ 1. http://asteria.noreply.org/~weasel/volatile/2010-07-07-VTRuAQGOKlY/zoe-2.6.32.16.png 2. http://asteria.noreply.org/~weasel/volatile/2010-07-07-Fq0PVc1ecsc/config-2.6.32.16-dsa-amd64
Signature · 4 lines
| .''`. ** Debian GNU/Linux **
Peter Palfrader | : :' : The universal
http://www.palfrader.org/ | `. `' Operating System
| `- http://www.debian.org/Re: [patch 134/149] x86, paravirt: Add a global synchronization point for pvclock
Quoted 11 lines · Peter Palfrader
Hey,
Greg KH schrieb am Donnerstag, dem 01. Juli 2010:
Quoted 1 line
2.6.32-stable review patch. If anyone has any objections, please let us know.
2.6.32.16 fails to boot on my KVM domains using qemu-kvm 0.11.1.
Bisecting between 2.6.32.14 which worked and .16 turned up this commit as the first culprit[0].
Quoted 8 lines
The host is still running 2.6.32.14 and has 8 cores on 2 CPUs. The single-cpu KVM domain hangs just after printing 'Write protecting the
kernel read-only data: 9492k'[1]. On a successful boot this line would
usually be followed by 'INIT: version 2.86 booting'.A 2.6.32.16 with this patch reverted boots fine.
If there's any info you need please just ask.
if you boot with another clocksource, and then switch to kvmclock with the machine already running, do you see anything strange or suspicious?
Re: [patch 134/149] x86, paravirt: Add a global synchronization point for pvclock
Quoted 10 lines · Glauber Costa
Quoted 10 lines
2.6.32.16 fails to boot on my KVM domains using qemu-kvm 0.11.1.
Bisecting between 2.6.32.14 which worked and .16 turned up this commit as the first culprit[0].
The host is still running 2.6.32.14 and has 8 cores on 2 CPUs. The single-cpu KVM domain hangs just after printing 'Write protecting the
kernel read-only data: 9492k'[1]. On a successful boot this line would
usually be followed by 'INIT: version 2.86 booting'.
Quoted 6 lines
Quoted 3 lines
A 2.6.32.16 with this patch reverted boots fine.
If there's any info you need please just ask.
if you boot with another clocksource, and then switch to kvmclock with the machine already running, do you see anything strange or suspicious?
Booting with various clocksource=xxx kernel parameters does not change the behaviour at all, i.e. the boot still hangs.
Cheers,
Peter
Signature · 4 lines
| .''`. ** Debian GNU/Linux **
Peter Palfrader | : :' : The universal
http://www.palfrader.org/ | `. `' Operating System
| `- http://www.debian.org/Re: [patch 134/149] x86, paravirt: Add a global synchronization point for pvclock
Quoted 14 lines · Peter Palfrader
Quoted 12 lines · Glauber Costa
Quoted 12 lines
2.6.32.16 fails to boot on my KVM domains using qemu-kvm 0.11.1.
Bisecting between 2.6.32.14 which worked and .16 turned up this commit as the first culprit[0].
The host is still running 2.6.32.14 and has 8 cores on 2 CPUs. The single-cpu KVM domain hangs just after printing 'Write protecting the
kernel read-only data: 9492k'[1]. On a successful boot this line would
usually be followed by 'INIT: version 2.86 booting'.A 2.6.32.16 with this patch reverted boots fine.
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
If there's any info you need please just ask.
if you boot with another clocksource, and then switch to kvmclock with the machine already running, do you see anything strange or suspicious?
Booting with various clocksource=xxx kernel parameters does not change the behaviour at all, i.e. the boot still hangs.
And what if you provide -cpu qemu64,-kvmclock to qemu command line?
--
Gleb.
Re: [patch 134/149] x86, paravirt: Add a global synchronization point for pvclock
Quoted 17 lines · Gleb Natapov
Quoted 16 lines · Peter Palfrader
Quoted 13 lines · Glauber Costa
Quoted 13 lines
2.6.32.16 fails to boot on my KVM domains using qemu-kvm 0.11.1.
Bisecting between 2.6.32.14 which worked and .16 turned up this commit as the first culprit[0].
The host is still running 2.6.32.14 and has 8 cores on 2 CPUs. The single-cpu KVM domain hangs just after printing 'Write protecting the
kernel read-only data: 9492k'[1]. On a successful boot this line would
usually be followed by 'INIT: version 2.86 booting'.A 2.6.32.16 with this patch reverted boots fine.
If there's any info you need please just ask.
Quoted 7 lines
Quoted 6 lines
Quoted 2 lines
if you boot with another clocksource, and then switch to kvmclock with the machine already running, do you see anything strange or suspicious?
Booting with various clocksource=xxx kernel parameters does not change the behaviour at all, i.e. the boot still hangs.
And what if you provide -cpu qemu64,-kvmclock to qemu command line?
Adding that to the glob of options that already were there from libvirt didn't disable it, but using an LD_PRELOAD wrapper[1] to that purpose on the host when starting kvm did help.
Now, with kvmclock no longer being available at all the system picks tsc and indeed boots 2.6.32.16 successfully.
- Peter
1. http://people.debian.org/~paravoid/kvm-noclock-3.tar.gz
Signature · 4 lines
| .''`. ** Debian GNU/Linux **
Peter Palfrader | : :' : The universal
http://www.palfrader.org/ | `. `' Operating System
| `- http://www.debian.org/Re: [patch 134/149] x86, paravirt: Add a global synchronization point for pvclock
Quoted 22 lines · Peter Palfrader
Quoted 20 lines · Gleb Natapov
Quoted 19 lines · Peter Palfrader
Quoted 16 lines · Glauber Costa
Quoted 5 lines
2.6.32.16 fails to boot on my KVM domains using qemu-kvm 0.11.1.
Bisecting between 2.6.32.14 which worked and .16 turned up this commit as the first culprit[0].
Quoted 8 lines
The host is still running 2.6.32.14 and has 8 cores on 2 CPUs. The single-cpu KVM domain hangs just after printing 'Write protecting the
kernel read-only data: 9492k'[1]. On a successful boot this line would
usually be followed by 'INIT: version 2.86 booting'.A 2.6.32.16 with this patch reverted boots fine.
If there's any info you need please just ask.
if you boot with another clocksource, and then switch to kvmclock with the machine already running, do you see anything strange or suspicious?
Quoted 9 lines
Quoted 4 lines
Quoted 3 lines
Booting with various clocksource=xxx kernel parameters does not change the behaviour at all, i.e. the boot still hangs.
And what if you provide -cpu qemu64,-kvmclock to qemu command line?
Adding that to the glob of options that already were there from libvirt didn't disable it, but using an
LD_PRELOADwrapper[1] to that purpose on the host when starting kvm did help.
Strange. -kvmclock should have had the same effect. What qemu is it? What is your command line?
Quoted 10 lines
Now, with kvmclock no longer being available at all the system picks tsc and indeed boots 2.6.32.16 successfully.
- Peter
1. http://people.debian.org/~paravoid/kvm-noclock-3.tar.gzSignature · 4 lines
| .''`. ** Debian GNU/Linux ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `- http://www.debian.org/
--
Gleb.
Re: [patch 134/149] x86, paravirt: Add a global synchronization point for pvclock
Quoted 8 lines · Gleb Natapov
Quoted 6 lines
Quoted 1 line
And what if you provide -cpu qemu64,-kvmclock to qemu command line?
Adding that to the glob of options that already were there from libvirt didn't disable it, but using an
LD_PRELOADwrapper[1] to that purpose on the host when starting kvm did help.Strange. -kvmclock should have had the same effect. What qemu is it? What is your command line?
| QEMU PC emulator version 0.11.1 (qemu-kvm-0.11.1), Copyright (c) 2003-2008 Fabrice Bellard from the debian package qemu-kvm (0.11.1+dfsg-1~bpo50+1)
/usr/bin/kvm -S -M pc-0.11 -enable-kvm -m 512 -smp 1 -name zoe -uuid 1885e784-c831-4ef8-9576-8eaa9abf3a8b -monitor unix:/var/lib/libvirt/qemu/zoe.monitor,server,nowait -boot c -drive file=/dev/vg_sookie_system/zoe-boot,if=ide,bus=0,unit=0,boot=on -drive file=/dev/vg_sookie_system/zoe-root,if=virtio -drive file=/dev/vg_sookie_system/zoe-swap,if=virtio -net nic,macaddr=00:16:36:40:00:0b,vlan=0,model=virtio,name=net0 -net tap,fd=25,vlan=0,name=hostnet0 -net nic,macaddr=00:16:36:40:05:0b,vlan=1,model=virtio,name=net1 -net tap,fd=28,vlan=1,name=hostnet1 -serial none -parallel none -usb -vnc 127.0.0.1:10 -vga cirrus -balloon virtio
And I had added "-cpu qemu64,-kvmclock" to that at either the front or the end.
Cheers,
[should we trim the CC list? If yes, to what?]
Signature · 4 lines
| .''`. ** Debian GNU/Linux **
Peter Palfrader | : :' : The universal
http://www.palfrader.org/ | `. `' Operating System
| `- http://www.debian.org/Re: [patch 134/149] x86, paravirt: Add a global synchronization point for pvclock
Quoted 8 lines · Peter Palfrader
Quoted 6 lines · Gleb Natapov
Quoted 6 lines
Quoted 1 line
And what if you provide -cpu qemu64,-kvmclock to qemu command line?
Adding that to the glob of options that already were there from libvirt didn't disable it, but using an
LD_PRELOADwrapper[1] to that purpose on the host when starting kvm did help.
Quoted 5 lines
Quoted 2 lines
Strange. -kvmclock should have had the same effect. What qemu is it? What is your command line?
| QEMU PC emulator version 0.11.1 (qemu-kvm-0.11.1), Copyright (c) 2003-2008 Fabrice Bellard from the debian package qemu-kvm (0.11.1+dfsg-1~bpo50+1)
That explain it. 0.11 is really old. Don't have this ability.
Quoted 1 line
[should we trim the CC list? If yes, to what?]
Better not to.
--
Gleb.
Re: [patch 134/149] x86, paravirt: Add a global synchronization point for pvclock
In reply to Peter PalfraderQuoted 14 lines · Peter Palfrader
Quoted 12 lines · Glauber Costa
Quoted 12 lines
2.6.32.16 fails to boot on my KVM domains using qemu-kvm 0.11.1.
Bisecting between 2.6.32.14 which worked and .16 turned up this commit as the first culprit[0].
The host is still running 2.6.32.14 and has 8 cores on 2 CPUs. The single-cpu KVM domain hangs just after printing 'Write protecting the
kernel read-only data: 9492k'[1]. On a successful boot this line would
usually be followed by 'INIT: version 2.86 booting'.A 2.6.32.16 with this patch reverted boots fine.
Quoted 7 lines
Quoted 4 lines
Quoted 1 line
If there's any info you need please just ask.
if you boot with another clocksource, and then switch to kvmclock with the machine already running, do you see anything strange or suspicious?
Booting with various clocksource=xxx kernel parameters does not change the behaviour at all, i.e. the boot still hangs.
wow, it is really weird then.
that patch shouldn't affect anything outside the pvclock realm.
Re: [patch 134/149] x86, paravirt: Add a global synchronization point for pvclock
Quoted 23 lines · Glauber Costa
Quoted 21 lines · Peter Palfrader
Quoted 18 lines · Glauber Costa
Quoted 5 lines
2.6.32.16 fails to boot on my KVM domains using qemu-kvm 0.11.1.
Bisecting between 2.6.32.14 which worked and .16 turned up this commit as the first culprit[0].
Quoted 9 lines
The host is still running 2.6.32.14 and has 8 cores on 2 CPUs. The single-cpu KVM domain hangs just after printing 'Write protecting the
kernel read-only data: 9492k'[1]. On a successful boot this line would
usually be followed by 'INIT: version 2.86 booting'.A 2.6.32.16 with this patch reverted boots fine.
If there's any info you need please just ask.
if you boot with another clocksource, and then switch to kvmclock with the machine already running, do you see anything strange or suspicious?
Quoted 7 lines
Quoted 3 lines
Booting with various clocksource=xxx kernel parameters does not change the behaviour at all, i.e. the boot still hangs.
wow, it is really weird then.
that patch shouldn't affect anything outside the pvclock realm.
Unless you added data which is mistakenly in read-only section, I can't see how it would affect anything either. Of course, you have changed the data and text size, it is possible this triggered another bug.
What exact section does the per-cpu pvclock data fall into? It's read-only in the kernel, but writeable from the hypervisor.
Also, did this patch arrive before or after the pvclock reboot bugfix? Because if the hypervisor is still writing the pvclock page, clocksource=xxx would not change that behavior without that fix.
Zach
Re: [patch 134/149] x86, paravirt: Add a global synchronization point for pvclock
Quoted 21 lines · Zachary Amsden
Quoted 20 lines · Glauber Costa
Quoted 19 lines · Peter Palfrader
Quoted 10 lines · Glauber Costa
Quoted 10 lines
2.6.32.16 fails to boot on my KVM domains using qemu-kvm 0.11.1.
Bisecting between 2.6.32.14 which worked and .16 turned up this commit as the first culprit[0].
The host is still running 2.6.32.14 and has 8 cores on 2 CPUs. The single-cpu KVM domain hangs just after printing 'Write protecting the
kernel read-only data: 9492k'[1]. On a successful boot this line would
usually be followed by 'INIT: version 2.86 booting'.Quoted 5 lines
Quoted 3 lines
A 2.6.32.16 with this patch reverted boots fine.
If there's any info you need please just ask.
if you boot with another clocksource, and then switch to kvmclock with the machine already running, do you see anything strange or suspicious?
Booting with various clocksource=xxx kernel parameters does not change the behaviour at all, i.e. the boot still hangs.
Quoted 8 lines
Quoted 3 lines
wow, it is really weird then.
that patch shouldn't affect anything outside the pvclock realm.
Unless you added data which is mistakenly in read-only section, I can't see how it would affect anything either. Of course, you have changed the data and text size, it is possible this triggered another bug.
Yes, but at least this patch alone, does not touch anything on that regard (or at least should not).
Quoted 2 lines
What exact section does the per-cpu pvclock data fall into? It's read-only in the kernel, but writeable from the hypervisor.
it is not explicitly marked read only in the kernel, afaik. we just trust the kernel not to use it.
Quoted 5 lines
Also, did this patch arrive before or after the pvclock reboot bugfix? Because if the hypervisor is still writing the pvclock page, clocksource=xxx would not change that behavior without that fix.
Dunno in which order they got applied in stable. But from what I understood, this is not a reboot scenario. It happens on first boot, right?
Re: [patch 134/149] x86, paravirt: Add a global synchronization point for pvclock
In reply to Peter PalfraderQuoted 12 lines · Peter Palfrader
Hey,
Greg KH schrieb am Donnerstag, dem 01. Juli 2010:
Quoted 2 lines
2.6.32-stable review patch. If anyone has any objections, please let us know.
2.6.32.16 fails to boot on my KVM domains using qemu-kvm 0.11.1.
Bisecting between 2.6.32.14 which worked and .16 turned up this commit as the first culprit[0].
Quoted 9 lines
The host is still running 2.6.32.14 and has 8 cores on 2 CPUs. The single-cpu KVM domain hangs just after printing 'Write protecting the
kernel read-only data: 9492k'[1]. On a successful boot this line would
usually be followed by 'INIT: version 2.86 booting'.A 2.6.32.16 with this patch reverted boots fine.
If there's any info you need please just ask.
I'm unable to reproduce.
Can you provide the stack trace where this hangs? Add CONFIG_DEBUG_INFO, and then
- copy vmlinux somewhere on the host filesystem
- start the guest
- when it hangs, type 'gdbserver' in the qemu monitor
- on the host, the 'gdb /path/to/vmlinux'
- 'target remote :1234'
- 'backtrace'
Signature · 1 line
error compiling committee.c: too many arguments to function