--- /dev/null
+From dc99be47667c56046555e89e62f1ac17fa06329a Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Wed, 20 Jan 2010 08:35:06 +0100
+Subject: ALSA: hda - Fix HP T5735 automute
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit dc99be47667c56046555e89e62f1ac17fa06329a upstream.
+
+This patch fixes the aut-mute setup on HP T5735 with ALC262 codec.
+Instead of wrong amp, use pin control toggling for muting the speaker now.
+
+Tested-by: Lee Trager <lee.trager@hp.com>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ sound/pci/hda/patch_realtek.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/sound/pci/hda/patch_realtek.c
++++ b/sound/pci/hda/patch_realtek.c
+@@ -10154,7 +10154,7 @@ static void alc262_hp_t5735_setup(struct
+ struct alc_spec *spec = codec->spec;
+
+ spec->autocfg.hp_pins[0] = 0x15;
+- spec->autocfg.speaker_pins[0] = 0x0c; /* HACK: not actually a pin */
++ spec->autocfg.speaker_pins[0] = 0x14;
+ }
+
+ static struct snd_kcontrol_new alc262_hp_t5735_mixer[] = {
+@@ -11588,9 +11588,9 @@ static struct alc_config_preset alc262_p
+ .num_channel_mode = ARRAY_SIZE(alc262_modes),
+ .channel_mode = alc262_modes,
+ .input_mux = &alc262_capture_source,
+- .unsol_event = alc_automute_amp_unsol_event,
++ .unsol_event = alc_sku_unsol_event,
+ .setup = alc262_hp_t5735_setup,
+- .init_hook = alc_automute_amp,
++ .init_hook = alc_inithook,
+ },
+ [ALC262_HP_RP5700] = {
+ .mixers = { alc262_hp_rp5700_mixer },
--- /dev/null
+From 40aa7030e5213a43e9e0554fd7f95534ea310bf3 Mon Sep 17 00:00:00 2001
+From: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
+Date: Fri, 22 Jan 2010 18:00:03 +0100
+Subject: ASoC: fix a memory-leak in wm8903
+
+From: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
+
+commit 40aa7030e5213a43e9e0554fd7f95534ea310bf3 upstream.
+
+Remember to free the temporary register-cache.
+
+Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
+Acked-by: Liam Girdwood <lrg@slimlogic.co.uk>
+Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ sound/soc/codecs/wm8903.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/sound/soc/codecs/wm8903.c
++++ b/sound/soc/codecs/wm8903.c
+@@ -1506,7 +1506,7 @@ static int wm8903_resume(struct platform
+ struct i2c_client *i2c = codec->control_data;
+ int i;
+ u16 *reg_cache = codec->reg_cache;
+- u16 *tmp_cache = kmemdup(codec->reg_cache, sizeof(wm8903_reg_defaults),
++ u16 *tmp_cache = kmemdup(reg_cache, sizeof(wm8903_reg_defaults),
+ GFP_KERNEL);
+
+ /* Bring the codec back up to standby first to minimise pop/clicks */
+@@ -1518,6 +1518,7 @@ static int wm8903_resume(struct platform
+ for (i = 2; i < ARRAY_SIZE(wm8903_reg_defaults); i++)
+ if (tmp_cache[i] != reg_cache[i])
+ snd_soc_write(codec, i, tmp_cache[i]);
++ kfree(tmp_cache);
+ } else {
+ dev_err(&i2c->dev, "Failed to allocate temporary cache\n");
+ }
--- /dev/null
+From 5f6120335c701ba07d5151206071f4d6ccaa684f Mon Sep 17 00:00:00 2001
+From: Abhijeet Kolekar <abhijeet.kolekar@intel.com>
+Date: Wed, 13 Jan 2010 13:23:14 -0800
+Subject: cfg80211: fix channel setting for wext
+
+From: Abhijeet Kolekar <abhijeet.kolekar@intel.com>
+
+commit 5f6120335c701ba07d5151206071f4d6ccaa684f upstream.
+
+Patch fixes the bug at
+http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2139
+
+Currently we cannot set the channel using wext extension
+if we have already associated and disconnected. As
+cfg80211_mgd_wext_siwfreq will not switch the channel if ssid is set.
+This fixes it by clearing the ssid.
+Following is the sequence which it tries to fix.
+modprobe iwlagn
+iwconfig wlan0 essid ""
+ifconfig wlan0 down
+iwconfig wlan0 chan X
+
+wext is marked as deprecate.If we use nl80211 we can easily play with
+setting the channel.
+
+Signed-off-by: Abhijeet Kolekar <abhijeet.kolekar@intel.com>
+Acked-by: Samuel Ortiz <sameo@linux.intel.com>
+Signed-off-by: John W. Linville <linville@tuxdriver.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ net/wireless/sme.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/net/wireless/sme.c
++++ b/net/wireless/sme.c
+@@ -655,6 +655,7 @@ void __cfg80211_disconnected(struct net_
+ memset(&wrqu, 0, sizeof(wrqu));
+ wrqu.ap_addr.sa_family = ARPHRD_ETHER;
+ wireless_send_event(dev, SIOCGIWAP, &wrqu, NULL);
++ wdev->wext.connect.ssid_len = 0;
+ #endif
+ }
+
--- /dev/null
+From c453615f77aa51593c1c9c9031b4278797d3fd19 Mon Sep 17 00:00:00 2001
+From: Hans de Goede <hdegoede@redhat.com>
+Date: Mon, 25 Jan 2010 15:00:50 +0100
+Subject: hwmon: (fschmd) Fix a memleak on multiple opens of /dev/watchdog
+
+From: Hans de Goede <hdegoede@redhat.com>
+
+commit c453615f77aa51593c1c9c9031b4278797d3fd19 upstream.
+
+When /dev/watchdog gets opened a second time we return -EBUSY, but
+we already have got a kref then, so we end up leaking our data struct.
+
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Signed-off-by: Jean Delvare <khali@linux-fr.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/hwmon/fschmd.c | 7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+--- a/drivers/hwmon/fschmd.c
++++ b/drivers/hwmon/fschmd.c
+@@ -767,6 +767,7 @@ leave:
+ static int watchdog_open(struct inode *inode, struct file *filp)
+ {
+ struct fschmd_data *pos, *data = NULL;
++ int watchdog_is_open;
+
+ /* We get called from drivers/char/misc.c with misc_mtx hold, and we
+ call misc_register() from fschmd_probe() with watchdog_data_mutex
+@@ -781,10 +782,12 @@ static int watchdog_open(struct inode *i
+ }
+ }
+ /* Note we can never not have found data, so we don't check for this */
+- kref_get(&data->kref);
++ watchdog_is_open = test_and_set_bit(0, &data->watchdog_is_open);
++ if (!watchdog_is_open)
++ kref_get(&data->kref);
+ mutex_unlock(&watchdog_data_mutex);
+
+- if (test_and_set_bit(0, &data->watchdog_is_open))
++ if (watchdog_is_open)
+ return -EBUSY;
+
+ /* Start the watchdog */
--- /dev/null
+From 0c6ddcebd8303ada6faefa6f72ac18b6230320c4 Mon Sep 17 00:00:00 2001
+From: Jiri Slaby <jirislaby@gmail.com>
+Date: Fri, 25 Sep 2009 09:33:38 +0200
+Subject: KVM: fix lock imbalance in kvm_*_irq_source_id()
+
+From: Jiri Slaby <jirislaby@gmail.com>
+
+commit 0c6ddcebd8303ada6faefa6f72ac18b6230320c4 upstream.
+
+Stanse found 2 lock imbalances in kvm_request_irq_source_id and
+kvm_free_irq_source_id. They omit to unlock kvm->irq_lock on fail paths.
+
+Fix that by adding unlock labels at the end of the functions and jump
+there from the fail paths.
+
+Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
+Cc: Marcelo Tosatti <mtosatti@redhat.com>
+Signed-off-by: Avi Kivity <avi@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ virt/kvm/irq_comm.c | 7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+--- a/virt/kvm/irq_comm.c
++++ b/virt/kvm/irq_comm.c
+@@ -209,11 +209,13 @@ int kvm_request_irq_source_id(struct kvm
+
+ if (irq_source_id >= BITS_PER_LONG) {
+ printk(KERN_WARNING "kvm: exhaust allocatable IRQ sources!\n");
+- return -EFAULT;
++ irq_source_id = -EFAULT;
++ goto unlock;
+ }
+
+ ASSERT(irq_source_id != KVM_USERSPACE_IRQ_SOURCE_ID);
+ set_bit(irq_source_id, bitmap);
++unlock:
+ mutex_unlock(&kvm->irq_lock);
+
+ return irq_source_id;
+@@ -229,11 +231,12 @@ void kvm_free_irq_source_id(struct kvm *
+ if (irq_source_id < 0 ||
+ irq_source_id >= BITS_PER_LONG) {
+ printk(KERN_ERR "kvm: IRQ source ID out of range!\n");
+- return;
++ goto unlock;
+ }
+ for (i = 0; i < KVM_IOAPIC_NUM_PINS; i++)
+ clear_bit(irq_source_id, &kvm->arch.irq_states[i]);
+ clear_bit(irq_source_id, &kvm->arch.irq_sources_bitmap);
++unlock:
+ mutex_unlock(&kvm->irq_lock);
+ }
+
--- /dev/null
+From a5d36f82c4f3e852b61fdf1fee13463c8aa91b90 Mon Sep 17 00:00:00 2001
+From: Avi Kivity <avi@redhat.com>
+Date: Tue, 29 Dec 2009 12:42:16 +0200
+Subject: KVM: Fix race between APIC TMR and IRR
+
+From: Avi Kivity <avi@redhat.com>
+
+commit a5d36f82c4f3e852b61fdf1fee13463c8aa91b90 upstream.
+
+When we queue an interrupt to the local apic, we set the IRR before the TMR.
+The vcpu can pick up the IRR and inject the interrupt before setting the TMR,
+and perhaps even EOI it, causing incorrect behaviour.
+
+The race is really insignificant since it can only occur on the first
+interrupt (usually following interrupts will not change TMR), but it's better
+closed than open.
+
+Fixed by reordering setting the TMR vs IRR.
+
+Signed-off-by: Avi Kivity <avi@redhat.com>
+Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ arch/x86/kvm/lapic.c | 11 ++++++-----
+ 1 file changed, 6 insertions(+), 5 deletions(-)
+
+--- a/arch/x86/kvm/lapic.c
++++ b/arch/x86/kvm/lapic.c
+@@ -374,6 +374,12 @@ static int __apic_accept_irq(struct kvm_
+ if (unlikely(!apic_enabled(apic)))
+ break;
+
++ if (trig_mode) {
++ apic_debug("level trig mode for vector %d", vector);
++ apic_set_vector(vector, apic->regs + APIC_TMR);
++ } else
++ apic_clear_vector(vector, apic->regs + APIC_TMR);
++
+ result = !apic_test_and_set_irr(vector, apic);
+ trace_kvm_apic_accept_irq(vcpu->vcpu_id, delivery_mode,
+ trig_mode, vector, !result);
+@@ -384,11 +390,6 @@ static int __apic_accept_irq(struct kvm_
+ break;
+ }
+
+- if (trig_mode) {
+- apic_debug("level trig mode for vector %d", vector);
+- apic_set_vector(vector, apic->regs + APIC_TMR);
+- } else
+- apic_clear_vector(vector, apic->regs + APIC_TMR);
+ kvm_vcpu_kick(vcpu);
+ break;
+
--- /dev/null
+From a6085fbaf65ab09bfb5ec8d902d6d21680fe1895 Mon Sep 17 00:00:00 2001
+From: Marcelo Tosatti <mtosatti@redhat.com>
+Date: Thu, 14 Jan 2010 17:41:27 -0200
+Subject: KVM: MMU: bail out pagewalk on kvm_read_guest error
+
+From: Marcelo Tosatti <mtosatti@redhat.com>
+
+commit a6085fbaf65ab09bfb5ec8d902d6d21680fe1895 upstream.
+
+Exit the guest pagetable walk loop if reading gpte failed. Otherwise its
+possible to enter an endless loop processing the previous present pte.
+
+Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ arch/x86/kvm/paging_tmpl.h | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/arch/x86/kvm/paging_tmpl.h
++++ b/arch/x86/kvm/paging_tmpl.h
+@@ -150,7 +150,9 @@ walk:
+ walker->table_gfn[walker->level - 1] = table_gfn;
+ walker->pte_gpa[walker->level - 1] = pte_gpa;
+
+- kvm_read_guest(vcpu->kvm, pte_gpa, &pte, sizeof(pte));
++ if (kvm_read_guest(vcpu->kvm, pte_gpa, &pte, sizeof(pte)))
++ goto not_present;
++
+ trace_kvm_mmu_paging_element(pte, walker->level);
+
+ if (!is_present_gpte(pte))
--- /dev/null
+From f1d1c309f35e9b0fb961cffd70fbd04f450ec47c Mon Sep 17 00:00:00 2001
+From: Michael S. Tsirkin <mst@redhat.com>
+Date: Wed, 13 Jan 2010 18:58:09 +0200
+Subject: KVM: only allow one gsi per fd
+
+From: Michael S. Tsirkin <mst@redhat.com>
+
+commit f1d1c309f35e9b0fb961cffd70fbd04f450ec47c upstream.
+
+Looks like repeatedly binding same fd to multiple gsi's with irqfd can
+use up a ton of kernel memory for irqfd structures.
+
+A simple fix is to allow each fd to only trigger one gsi: triggering a
+storm of interrupts in guest is likely useless anyway, and we can do it
+by binding a single gsi to many interrupts if we really want to.
+
+Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
+Acked-by: Acked-by: Gregory Haskins <ghaskins@novell.com>
+Signed-off-by: Avi Kivity <avi@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ virt/kvm/eventfd.c | 15 +++++++++++++--
+ 1 file changed, 13 insertions(+), 2 deletions(-)
+
+--- a/virt/kvm/eventfd.c
++++ b/virt/kvm/eventfd.c
+@@ -168,7 +168,7 @@ irqfd_ptable_queue_proc(struct file *fil
+ static int
+ kvm_irqfd_assign(struct kvm *kvm, int fd, int gsi)
+ {
+- struct _irqfd *irqfd;
++ struct _irqfd *irqfd, *tmp;
+ struct file *file = NULL;
+ struct eventfd_ctx *eventfd = NULL;
+ int ret;
+@@ -205,9 +205,20 @@ kvm_irqfd_assign(struct kvm *kvm, int fd
+ init_waitqueue_func_entry(&irqfd->wait, irqfd_wakeup);
+ init_poll_funcptr(&irqfd->pt, irqfd_ptable_queue_proc);
+
++ spin_lock_irq(&kvm->irqfds.lock);
++
++ ret = 0;
++ list_for_each_entry(tmp, &kvm->irqfds.items, list) {
++ if (irqfd->eventfd != tmp->eventfd)
++ continue;
++ /* This fd is used for another irq already. */
++ ret = -EBUSY;
++ spin_unlock_irq(&kvm->irqfds.lock);
++ goto fail;
++ }
++
+ events = file->f_op->poll(file, &irqfd->pt);
+
+- spin_lock_irq(&kvm->irqfds.lock);
+ list_add_tail(&irqfd->list, &kvm->irqfds.items);
+ spin_unlock_irq(&kvm->irqfds.lock);
+
--- /dev/null
+From e50212bb51356f0df48d6cce0aae5acf41df336d Mon Sep 17 00:00:00 2001
+From: Marcelo Tosatti <mtosatti@redhat.com>
+Date: Thu, 29 Oct 2009 13:44:17 -0200
+Subject: KVM: only clear irq_source_id if irqchip is present
+
+From: Marcelo Tosatti <mtosatti@redhat.com>
+
+commit e50212bb51356f0df48d6cce0aae5acf41df336d upstream.
+
+Otherwise kvm might attempt to dereference a NULL pointer.
+
+Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
+Signed-off-by: Avi Kivity <avi@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ virt/kvm/irq_comm.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/virt/kvm/irq_comm.c
++++ b/virt/kvm/irq_comm.c
+@@ -233,9 +233,12 @@ void kvm_free_irq_source_id(struct kvm *
+ printk(KERN_ERR "kvm: IRQ source ID out of range!\n");
+ goto unlock;
+ }
++ clear_bit(irq_source_id, &kvm->arch.irq_sources_bitmap);
++ if (!irqchip_in_kernel(kvm))
++ goto unlock;
++
+ for (i = 0; i < KVM_IOAPIC_NUM_PINS; i++)
+ clear_bit(irq_source_id, &kvm->arch.irq_states[i]);
+- clear_bit(irq_source_id, &kvm->arch.irq_sources_bitmap);
+ unlock:
+ mutex_unlock(&kvm->irq_lock);
+ }
--- /dev/null
+From 062d5e9b0d714f449b261bb522eadaaf6f00f438 Mon Sep 17 00:00:00 2001
+From: Christian Borntraeger <borntraeger@de.ibm.com>
+Date: Thu, 21 Jan 2010 12:19:07 +0100
+Subject: KVM: S390: fix potential array overrun in intercept handling
+
+From: Christian Borntraeger <borntraeger@de.ibm.com>
+
+commit 062d5e9b0d714f449b261bb522eadaaf6f00f438 upstream.
+
+kvm_handle_sie_intercept uses a jump table to get the intercept handler
+for a SIE intercept. Static code analysis revealed a potential problem:
+the intercept_funcs jump table was defined to contain (0x48 >> 2) entries,
+but we only checked for code > 0x48 which would cause an off-by-one
+array overflow if code == 0x48.
+
+Use the compiler and ARRAY_SIZE to automatically set the limits.
+
+Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
+Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ arch/s390/kvm/intercept.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/arch/s390/kvm/intercept.c
++++ b/arch/s390/kvm/intercept.c
+@@ -213,7 +213,7 @@ static int handle_instruction_and_prog(s
+ return rc2;
+ }
+
+-static const intercept_handler_t intercept_funcs[0x48 >> 2] = {
++static const intercept_handler_t intercept_funcs[] = {
+ [0x00 >> 2] = handle_noop,
+ [0x04 >> 2] = handle_instruction,
+ [0x08 >> 2] = handle_prog,
+@@ -230,7 +230,7 @@ int kvm_handle_sie_intercept(struct kvm_
+ intercept_handler_t func;
+ u8 code = vcpu->arch.sie_block->icptcode;
+
+- if (code & 3 || code > 0x48)
++ if (code & 3 || (code >> 2) >= ARRAY_SIZE(intercept_funcs))
+ return -ENOTSUPP;
+ func = intercept_funcs[code >> 2];
+ if (func)
--- /dev/null
+From 82b7005f0e72d8d1a8226e4c192cbb0850d10b3f Mon Sep 17 00:00:00 2001
+From: Sheng Yang <sheng@linux.intel.com>
+Date: Tue, 5 Jan 2010 19:02:28 +0800
+Subject: KVM: x86: Fix host_mapping_level()
+
+From: Sheng Yang <sheng@linux.intel.com>
+
+commit 82b7005f0e72d8d1a8226e4c192cbb0850d10b3f upstream.
+
+When found a error hva, should not return PAGE_SIZE but the level...
+
+Also clean up the coding style of the following loop.
+
+Signed-off-by: Sheng Yang <sheng@linux.intel.com>
+Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ arch/x86/kvm/mmu.c | 6 ++----
+ 1 file changed, 2 insertions(+), 4 deletions(-)
+
+--- a/arch/x86/kvm/mmu.c
++++ b/arch/x86/kvm/mmu.c
+@@ -477,7 +477,7 @@ static int host_mapping_level(struct kvm
+
+ addr = gfn_to_hva(kvm, gfn);
+ if (kvm_is_error_hva(addr))
+- return page_size;
++ return PT_PAGE_TABLE_LEVEL;
+
+ down_read(¤t->mm->mmap_sem);
+ vma = find_vma(current->mm, addr);
+@@ -515,11 +515,9 @@ static int mapping_level(struct kvm_vcpu
+ if (host_level == PT_PAGE_TABLE_LEVEL)
+ return host_level;
+
+- for (level = PT_DIRECTORY_LEVEL; level <= host_level; ++level) {
+-
++ for (level = PT_DIRECTORY_LEVEL; level <= host_level; ++level)
+ if (has_wrprotected_page(vcpu->kvm, large_gfn, level))
+ break;
+- }
+
+ return level - 1;
+ }
--- /dev/null
+From 443c39bc9ef7d8f648408d74c97e943f3bb3f48a Mon Sep 17 00:00:00 2001
+From: Wei Yongjun <yjwei@cn.fujitsu.com>
+Date: Fri, 22 Jan 2010 14:21:29 +0800
+Subject: KVM: x86: Fix leak of free lapic date in kvm_arch_vcpu_init()
+
+From: Wei Yongjun <yjwei@cn.fujitsu.com>
+
+commit 443c39bc9ef7d8f648408d74c97e943f3bb3f48a upstream.
+
+In function kvm_arch_vcpu_init(), if the memory malloc for
+vcpu->arch.mce_banks is fail, it does not free the memory
+of lapic date. This patch fixed it.
+
+Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
+Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ arch/x86/kvm/x86.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/arch/x86/kvm/x86.c
++++ b/arch/x86/kvm/x86.c
+@@ -4766,12 +4766,13 @@ int kvm_arch_vcpu_init(struct kvm_vcpu *
+ GFP_KERNEL);
+ if (!vcpu->arch.mce_banks) {
+ r = -ENOMEM;
+- goto fail_mmu_destroy;
++ goto fail_free_lapic;
+ }
+ vcpu->arch.mcg_cap = KVM_MAX_MCE_BANKS;
+
+ return 0;
+-
++fail_free_lapic:
++ kvm_free_lapic(vcpu);
+ fail_mmu_destroy:
+ kvm_mmu_destroy(vcpu);
+ fail_free_pio_data:
--- /dev/null
+From 36cb93fd6b6bf7e9163a69a8bf20207aed5fea44 Mon Sep 17 00:00:00 2001
+From: Wei Yongjun <yjwei@cn.fujitsu.com>
+Date: Fri, 22 Jan 2010 14:18:47 +0800
+Subject: KVM: x86: Fix probable memory leak of vcpu->arch.mce_banks
+
+From: Wei Yongjun <yjwei@cn.fujitsu.com>
+
+commit 36cb93fd6b6bf7e9163a69a8bf20207aed5fea44 upstream.
+
+vcpu->arch.mce_banks is malloc in kvm_arch_vcpu_init(), but
+never free in any place, this may cause memory leak. So this
+patch fixed to free it in kvm_arch_vcpu_uninit().
+
+Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
+Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ arch/x86/kvm/x86.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/arch/x86/kvm/x86.c
++++ b/arch/x86/kvm/x86.c
+@@ -4782,6 +4782,7 @@ fail:
+
+ void kvm_arch_vcpu_uninit(struct kvm_vcpu *vcpu)
+ {
++ kfree(vcpu->arch.mce_banks);
+ kvm_free_lapic(vcpu);
+ down_read(&vcpu->kvm->slots_lock);
+ kvm_mmu_destroy(vcpu);
--- /dev/null
+From e5de30c9bf4a39db9f54c4a373470ce65881ade0 Mon Sep 17 00:00:00 2001
+From: Benoit Papillault <benoit.papillault@free.fr>
+Date: Fri, 15 Jan 2010 12:21:37 +0100
+Subject: mac80211: check that ieee80211_set_power_mgmt only handles STA interfaces.
+
+From: Benoit Papillault <benoit.papillault@free.fr>
+
+commit e5de30c9bf4a39db9f54c4a373470ce65881ade0 upstream.
+
+ieee80211_set_power_mgmt is meant for STA interfaces only. Moreover,
+since sdata->u.mgd.mtx is only initialized for STA interfaces, using
+this code for any other type of interface (like creating a monitor
+interface) will result in a oops.
+
+Signed-off-by: Benoit Papillault <benoit.papillault@free.fr>
+Signed-off-by: John W. Linville <linville@tuxdriver.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ net/mac80211/cfg.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/net/mac80211/cfg.c
++++ b/net/mac80211/cfg.c
+@@ -1306,6 +1306,9 @@ static int ieee80211_set_power_mgmt(stru
+ struct ieee80211_local *local = wdev_priv(dev->ieee80211_ptr);
+ struct ieee80211_conf *conf = &local->hw.conf;
+
++ if (sdata->vif.type != NL80211_IFTYPE_STATION)
++ return -EOPNOTSUPP;
++
+ if (!(local->hw.flags & IEEE80211_HW_SUPPORTS_PS))
+ return -EOPNOTSUPP;
+
cio-dont-panic-in-non-fatal-conditions.patch
netiucv-displayed-tx-bytes-value-much-too-high.patch
ipc-ns-fix-memory-leak-idr.patch
+alsa-hda-fix-hp-t5735-automute.patch
+hwmon-fschmd-fix-a-memleak-on-multiple-opens-of-dev-watchdog.patch
+ubi-fix-memory-leak-in-update-path.patch
+ubi-initialise-update-marker.patch
+asoc-fix-a-memory-leak-in-wm8903.patch
+mac80211-check-that-ieee80211_set_power_mgmt-only-handles-sta-interfaces.patch
+cfg80211-fix-channel-setting-for-wext.patch
+kvm-s390-fix-potential-array-overrun-in-intercept-handling.patch
+kvm-only-allow-one-gsi-per-fd.patch
+kvm-fix-race-between-apic-tmr-and-irr.patch
+kvm-mmu-bail-out-pagewalk-on-kvm_read_guest-error.patch
+kvm-x86-fix-host_mapping_level.patch
+kvm-x86-fix-probable-memory-leak-of-vcpu-arch.mce_banks.patch
+kvm-x86-fix-leak-of-free-lapic-date-in-kvm_arch_vcpu_init.patch
+kvm-fix-lock-imbalance-in-kvm_-_irq_source_id.patch
+kvm-only-clear-irq_source_id-if-irqchip-is-present.patch
--- /dev/null
+From ebddd63b74dcf1cb676d14328d5852f1fee19a8a Mon Sep 17 00:00:00 2001
+From: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
+Date: Mon, 18 Jan 2010 16:43:44 +0200
+Subject: UBI: fix memory leak in update path
+
+From: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
+
+commit ebddd63b74dcf1cb676d14328d5852f1fee19a8a upstream.
+
+When truncating an UBI volume, UBI should allocates a PEB-sized
+buffer but does not release it, which leads to memory leaks.
+This patch fixes the issue.
+
+Reported-by: Marek Skuczynski <mareksk7@gmail.com>
+Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
+Tested-by: Marek Skuczynski <mareksk7@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/mtd/ubi/upd.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/mtd/ubi/upd.c
++++ b/drivers/mtd/ubi/upd.c
+@@ -155,6 +155,7 @@ int ubi_start_update(struct ubi_device *
+ if (err)
+ return err;
+ vol->updating = 0;
++ return 0;
+ }
+
+ vol->upd_buf = vmalloc(ubi->leb_size);
--- /dev/null
+From ff998793288b49a3b22d929bf8e56362320905ff Mon Sep 17 00:00:00 2001
+From: Peter Horton <zero@colonel-panic.org>
+Date: Tue, 5 Jan 2010 11:14:36 +0000
+Subject: UBI: initialise update marker
+
+From: Peter Horton <zero@colonel-panic.org>
+
+commit ff998793288b49a3b22d929bf8e56362320905ff upstream.
+
+The in kernel copy of a volume's update marker is not initialised from the
+volume table. This means that volumes where an update was unfinnished will
+not be treated as "forbidden to use". This is basically that the update
+functionality was broken.
+
+Signed-off-by: Peter Horton <zero@colonel-panic.org>
+Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/mtd/ubi/vtbl.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/mtd/ubi/vtbl.c
++++ b/drivers/mtd/ubi/vtbl.c
+@@ -566,6 +566,7 @@ static int init_volumes(struct ubi_devic
+ vol->reserved_pebs = be32_to_cpu(vtbl[i].reserved_pebs);
+ vol->alignment = be32_to_cpu(vtbl[i].alignment);
+ vol->data_pad = be32_to_cpu(vtbl[i].data_pad);
++ vol->upd_marker = vtbl[i].upd_marker;
+ vol->vol_type = vtbl[i].vol_type == UBI_VID_DYNAMIC ?
+ UBI_DYNAMIC_VOLUME : UBI_STATIC_VOLUME;
+ vol->name_len = be16_to_cpu(vtbl[i].name_len);
projects / thirdparty / kernel / stable-queue.git / commitdiff
