3.3.4-stable review
Subsystems (46)
Greg KH
maintainercover 3.3.4-stable review
This is the start of the stable review cycle for the 3.3.4 release. There are 62 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.
Responses should be made by Thu Apr 26 22:32:39 UTC 2012. 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/v3.0/stable-review/patch-3.3.4-rc1.gz
and the diffstat can be found below.
thanks,
greg k-h
-------------
Makefile | 4 +- arch/arm/mach-at91/board-sam9261ek.c | 5 +- arch/arm/mach-omap1/timer.c | 4 +- arch/arm/mach-omap2/serial.c | 8 ++- crypto/sha512_generic.c | 2 +- drivers/bluetooth/ath3k.c | 2 + drivers/bluetooth/btusb.c | 1 + drivers/hwmon/fam15h_power.c | 39 ++++++++++++++ drivers/md/md.c | 7 +-- drivers/media/dvb/dvb-core/dvb_frontend.c | 25 ++++++++- drivers/media/dvb/frontends/drxk_hard.c | 6 ++- drivers/media/rc/winbond-cir.c | 1 + drivers/mmc/card/block.c | 54 +++++++++++++------ drivers/mmc/card/queue.c | 2 +- drivers/mmc/core/core.c | 9 ++-- drivers/mmc/host/sdhci-esdhc-imx.c | 3 +- drivers/mmc/host/sdhci.c | 2 +- drivers/net/ethernet/ti/davinci_mdio.c | 5 ++ drivers/net/wireless/brcm80211/brcmsmac/main.c | 8 +++ drivers/net/wireless/mwifiex/pcie.h | 18 +++---- drivers/pci/quirks.c | 34 ++++++++++++ drivers/platform/x86/dell-laptop.c | 28 ++++++++++ drivers/staging/rtl8712/os_intfs.c | 3 -- drivers/staging/rtl8712/usb_intf.c | 5 ++ drivers/tty/amiserial.c | 4 +- drivers/tty/serial/clps711x.c | 14 ++--- drivers/tty/serial/pch_uart.c | 4 +- drivers/usb/core/hub.c | 3 -- drivers/usb/core/message.c | 6 +-- drivers/usb/gadget/f_fs.c | 2 +- drivers/usb/gadget/udc-core.c | 6 ++- drivers/usb/host/ehci-hcd.c | 9 +++- drivers/usb/misc/yurex.c | 10 ++-- drivers/usb/musb/omap2430.c | 9 ++-- drivers/usb/serial/cp210x.c | 9 ++-- drivers/usb/serial/sierra.c | 6 ++- drivers/uwb/hwa-rc.c | 3 +- drivers/uwb/neh.c | 12 ++++- drivers/xen/gntdev.c | 2 +- drivers/xen/xenbus/xenbus_probe_frontend.c | 69 ++++++++++++++++++------ fs/btrfs/ctree.h | 2 +- fs/ext4/extents.c | 2 +- fs/jbd2/commit.c | 4 +- fs/lockd/clnt4xdr.c | 2 +- fs/lockd/clntxdr.c | 2 +- fs/nfsd/nfs3xdr.c | 22 +++----- fs/nfsd/nfs4proc.c | 7 +-- fs/nfsd/nfs4state.c | 23 ++++---- fs/nfsd/nfs4xdr.c | 2 +- fs/ocfs2/alloc.c | 2 +- fs/ocfs2/refcounttree.c | 12 ++--- fs/ocfs2/suballoc.c | 4 +- include/linux/kvm_host.h | 6 +++ mm/memblock.c | 7 ++- mm/swap_state.c | 2 +- net/mac80211/ibss.c | 4 +- net/wireless/util.c | 2 +- scripts/mod/file2alias.c | 4 ++ sound/pci/hda/patch_conexant.c | 37 +++++++++++-- tools/perf/util/hist.c | 4 +- virt/kvm/iommu.c | 7 ++- virt/kvm/kvm_main.c | 5 +- 62 files changed, 441 insertions(+), 164 deletions(-)
Greg KH
maintainerPATCH 1/62 Perf: fix build breakage
3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zeev Tarantov <[email protected]>
[Patch not needed upstream as this is a backport build bugfix - gregkh
gcc correctly complains:
util/hist.c: In function ‘__hists__add_entry’:util/hist.c:240:27: error: invalid type argument of ‘->’ (have ‘struct hist_entry’) util/hist.c:241:23: error: invalid type argument of ‘->’ (have ‘struct hist_entry’)
for this new code:
+ if (he->ms.map != entry->ms.map) {
+ he->ms.map = entry->ms.map;
+ if (he->ms.map)
+ he->ms.map->referenced = true;
+ }
because "entry" is a "struct hist_entry", not a pointer to a struct.
In mainline, "entry" is a pointer to struct passed as argument to the function. So this is broken during backporting. But obviously not compile tested.
--- tools/perf/util/hist.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
tools/perf/util/hist.c +2 -2
@@ -237,8 +237,8 @@ struct hist_entry *__hists__add_entry(st* mis-adjust symbol addresses when computing * the history counter to increment. */ -if (he->ms.map != entry->ms.map) { - he->ms.map = entry->ms.map; +if (he->ms.map != entry.ms.map) { + he->ms.map = entry.ms.map;if (he->ms.map) he->ms.map->referenced = true; }
Greg KH
maintainerPATCH 2/62 crypto: sha512 - Fix byte counter overflow in SHA-512
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kent Yoder <[email protected]>
commit 25c3d30c918207556ae1d6e663150ebdf902186b upstream.
The current code only increments the upper 64 bits of the SHA-512 byte counter when the number of bytes hashed happens to hit 2^64 exactly.
This patch increments the upper 64 bits whenever the lower 64 bits overflows.
--- crypto/sha512_generic.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
crypto/sha512_generic.c +1 -1
@@ -174,7 +174,7 @@ sha512_update(struct shash_desc *desc, c index = sctx->count[0 ] &0x7f ;/* Update number of bytes */ -if (!(sctx->count[0 ] += len)) +if ((sctx->count[0 ] += len) < len) sctx->count[1 ]++; part_len =128 - index;
Greg KH
maintainerPATCH 3/62 hwmon: fam15h_power: fix bogus values with current BIOSes
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andre Przywara <[email protected]>
commit 00250ec90963b7ef6678438888f3244985ecde14 upstream.
Newer BKDG[1] versions recommend a different initialization value for the running average range register in the northbridge. This improves the power reading by avoiding counter saturations resulting in bogus values for anything below about 80% of TDP power consumption. Updated BIOSes will have this new value set up from the beginning, but meanwhile we correct this value ourselves.
This needs to be done on all northbridges, even on those where the driver itself does not register at.
This fixes the driver on all current machines to provide proper values for idle load.
[1]
http://support.amd.com/us/Processor_TechDocs/42301_15h_Mod_00h-0Fh_BKDG.pdf
Chapter 3.8: D18F5xE0 Processor TDP Running Average (p. 452)
--- drivers/hwmon/fam15h_power.c | 39 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 39 insertions(+)
drivers/hwmon/fam15h_power.c +39 -0
@@ -122,6 +122,38 @@ static bool __devinit fam15h_power_is_inreturn true; } +/* +* Newer BKDG versions have an updated recommendation on how to properly +* initialize the running average range (was: 0xE, now: 0x9). This avoids +* counter saturations resulting in bogus power readings. +* We correct this value ourselves to cope with older BIOSes. +*/ +static void __devinit tweak_runavg_range (struct pci_dev *pdev) +{ +u32 val; +const struct pci_device_id affected_device = { +PCI_VDEVICE (AMD ,PCI_DEVICE_ID_AMD_15H_NB_F4 ) }; + +/* +* let this quirk apply only to the current version of the +* northbridge, since future versions may change the behavior +*/ +if (!pci_match_id (&affected_device, pdev)) +return ; + +pci_bus_read_config_dword (pdev->bus, +PCI_DEVFN (PCI_SLOT (pdev->devfn),5 ), +REG_TDP_RUNNING_AVERAGE , &val); +if ((val &0xf ) !=0xe ) +return ; + + val &= ~0xf ; + val |=0x9 ; +pci_bus_write_config_dword (pdev->bus, +PCI_DEVFN (PCI_SLOT (pdev->devfn),5 ), +REG_TDP_RUNNING_AVERAGE , val); +} +static void __devinit fam15h_power_init_data (struct pci_dev *f4,struct fam15h_power_data *data) {
@@ -155,6 +187,13 @@ static int __devinit fam15h_power_probe(struct device *dev;int err; +/* +* though we ignore every other northbridge, we still have to +* do the tweaking on _each_ node in MCM processors as the counters +* are working hand-in-hand +*/ +tweak_runavg_range (pdev); +if (!fam15h_power_is_internal_node0 (pdev)) { err = -ENODEV ; goto exit;
Re: [ 03/62] hwmon: fam15h_power: fix bogus values with current BIOSes
Quoted 1 line · Greg KH
3.3-stable review patch. If anyone has any objections, please let me know.
[...]
drivers/hwmon/fam15h_power.c static bool __devinit fam15h_power_is_in · line 142
Quoted 12 lines
drivers/hwmon/fam15h_power.c +12
-0+static void __devinit tweak_runavg_range (struct pci_dev *pdev) +{ +u32 val; +const struct pci_device_id affected_device = { +PCI_VDEVICE (AMD ,PCI_DEVICE_ID_AMD_15H_NB_F4 ) }; + +/* +* let this quirk apply only to the current version of the +* northbridge, since future versions may change the behavior +*/ +if (!pci_match_id (&affected_device, pdev)) +return ;
[...]
pci_match_id() takes an *array* of IDs which must be properly zero- terminated. This change is bogus and should be fixed up before it goes into a stable update.
Ben.
Signature · 3 lines
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert CamusRe: [ 03/62] hwmon: fam15h_power: fix bogus values with current BIOSes
Quoted 17 lines · Ben Hutchings
Quoted 1 line · Greg KH
3.3-stable review patch. If anyone has any objections, please let me know.
[...]
Quoted 12 lines
drivers/hwmon/fam15h_power.c +12
-0+static void __devinit tweak_runavg_range (struct pci_dev *pdev) +{ +u32 val; +const struct pci_device_id affected_device = { +PCI_VDEVICE (AMD ,PCI_DEVICE_ID_AMD_15H_NB_F4 ) }; + +/* +* let this quirk apply only to the current version of the +* northbridge, since future versions may change the behavior +*/ +if (!pci_match_id (&affected_device, pdev)) +return ;[...]
Quoted 3 lines
pci_match_id()takes an *array* of IDs which must be properly zero- terminated. This change is bogus and should be fixed up before it goes into a stable update.
Good catch. I sent a patch to fix this in mainline a minute ago.
Guenter
Greg KH
maintainerRe: [ 03/62] hwmon: fam15h_power: fix bogus values with current BIOSes
Quoted 18 lines · Guenter Roeck
Quoted 17 lines · Ben Hutchings
Quoted 1 line · Greg KH
3.3-stable review patch. If anyone has any objections, please let me know.
[...]
Quoted 12 lines
drivers/hwmon/fam15h_power.c +12
-0+static void __devinit tweak_runavg_range (struct pci_dev *pdev) +{ +u32 val; +const struct pci_device_id affected_device = { +PCI_VDEVICE (AMD ,PCI_DEVICE_ID_AMD_15H_NB_F4 ) }; + +/* +* let this quirk apply only to the current version of the +* northbridge, since future versions may change the behavior +*/ +if (!pci_match_id (&affected_device, pdev)) +return ;[...]
Quoted 5 lines
Quoted 3 lines
pci_match_id()takes an *array* of IDs which must be properly zero- terminated. This change is bogus and should be fixed up before it goes into a stable update.Good catch. I sent a patch to fix this in mainline a minute ago.
Is it in Linus's tree yet? If so, what's the git commit id? If not, I'll have to drop it from this release.
thanks,
greg k-h
Re: [ 03/62] hwmon: fam15h_power: fix bogus values with current BIOSes
Quoted 19 lines · Greg KH
Quoted 18 lines · Guenter Roeck
Quoted 17 lines · Ben Hutchings
Quoted 1 line · Greg KH
3.3-stable review patch. If anyone has any objections, please let me know.
[...]
Quoted 12 lines
drivers/hwmon/fam15h_power.c +12
-0+static void __devinit tweak_runavg_range (struct pci_dev *pdev) +{ +u32 val; +const struct pci_device_id affected_device = { +PCI_VDEVICE (AMD ,PCI_DEVICE_ID_AMD_15H_NB_F4 ) }; + +/* +* let this quirk apply only to the current version of the +* northbridge, since future versions may change the behavior +*/ +if (!pci_match_id (&affected_device, pdev)) +return ;[...]
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
pci_match_id()takes an *array* of IDs which must be properly zero- terminated. This change is bogus and should be fixed up before it goes into a stable update.Good catch. I sent a patch to fix this in mainline a minute ago.
Is it in Linus's tree yet? If so, what's the git commit id? If not, I'll have to drop it from this release.
It is not in Linus' tree yet. I plan to send the pull request tomorrow, after having it rest for another night in my tree (with nightly builds) and in linux-next.
Please drop the patch for now. The fix will include a reference to it, so you can pull both patches once the fix shows up in Linus' tree.
Sorry for the trouble.
Thanks,
Guenter
Greg KH
maintainerRe: [ 03/62] hwmon: fam15h_power: fix bogus values with current BIOSes
Quoted 29 lines · Guenter Roeck
Quoted 19 lines · Greg KH
Quoted 18 lines · Guenter Roeck
Quoted 17 lines · Ben Hutchings
Quoted 1 line · Greg KH
3.3-stable review patch. If anyone has any objections, please let me know.
[...]
Quoted 12 lines
drivers/hwmon/fam15h_power.c +12
-0+static void __devinit tweak_runavg_range (struct pci_dev *pdev) +{ +u32 val; +const struct pci_device_id affected_device = { +PCI_VDEVICE (AMD ,PCI_DEVICE_ID_AMD_15H_NB_F4 ) }; + +/* +* let this quirk apply only to the current version of the +* northbridge, since future versions may change the behavior +*/ +if (!pci_match_id (&affected_device, pdev)) +return ;[...]
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
pci_match_id()takes an *array* of IDs which must be properly zero- terminated. This change is bogus and should be fixed up before it goes into a stable update.Good catch. I sent a patch to fix this in mainline a minute ago.
Is it in Linus's tree yet? If so, what's the git commit id? If not, I'll have to drop it from this release.
Quoted 6 lines
It is not in Linus' tree yet. I plan to send the pull request tomorrow, after having it rest for another night in my tree (with nightly builds) and in linux-next.
Please drop the patch for now. The fix will include a reference to it, so you can pull both patches once the fix shows up in Linus' tree.
Now dropped.
Greg KH
maintainerPATCH 4/62 ALSA: hda/conexant - Dont set HP pin-control bit unconditionally
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <[email protected]>
commit ca3649de026ff95c6f2847e8d096cf2f411c02b3 upstream.
Some output pins on Conexant chips have no HP control bit, but the auto-parser initializes these pins unconditionally with PIN_HP.
Check the pin-capability and avoid the HP bit if not supported.
--- sound/pci/hda/patch_conexant.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
sound/pci/hda/patch_conexant.c +7 -2
@@ -3951,9 +3951,14 @@ static void cx_auto_init_output(struct hint i;mute_outputs (codec, spec->multiout.num_dacs, spec->multiout.dac_nids); -for (i =0 ; i < cfg->hp_outs; i++) +for (i =0 ; i < cfg->hp_outs; i++) { +unsigned int val =PIN_OUT ; +if (snd_hda_query_pin_caps (codec, cfg->hp_pins[i]) & +AC_PINCAP_HP_DRV ) + val |=AC_PINCTL_HP_EN ;snd_hda_codec_write (codec, cfg->hp_pins[i],0 , -AC_VERB_SET_PIN_WIDGET_CONTROL ,PIN_HP ); +AC_VERB_SET_PIN_WIDGET_CONTROL , val); + }mute_outputs (codec, cfg->hp_outs, cfg->hp_pins);mute_outputs (codec, cfg->line_outs, cfg->line_out_pins);mute_outputs (codec, cfg->speaker_outs, cfg->speaker_pins);
Greg KH
maintainerPATCH 5/62 ALSA: hda/conexant - Set up the missing docking-station pins
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <[email protected]>
commit d70f363222ef373c2037412f09a600357cfa1c7a upstream.
ThinkPad 410,420,510,520 and X201 with cx50585 & co chips have the docking-station ports, but BIOS doesn't initialize for these pins. Thus, like the former X200, we need to set up the pins manually in the driver.
The odd part is that the same PCI SSID is used for X200 and T400, thus we need to prepare individual fixup tables for cx5051 and others.
Bugzilla entries:
https://bugzilla.redhat.com/show_bug.cgi?id=808559 https://bugzilla.redhat.com/show_bug.cgi?id=806217 https://bugzilla.redhat.com/show_bug.cgi?id=810697
--- sound/pci/hda/patch_conexant.c | 28 +++++++++++++++++++++++++--- 1 file changed, 25 insertions(+), 3 deletions(-)
sound/pci/hda/patch_conexant.c +25 -3
@@ -4367,8 +4367,10 @@ static void apply_pin_fixup(struct hda_cenum {CXT_PINCFG_LENOVO_X200 , +CXT_PINCFG_LENOVO_TP410 , }; +/* ThinkPad X200 & co with cxt5051 */ static const struct cxt_pincfg cxt_pincfg_lenovo_x200[] = { {0x16 ,0x042140ff },/* HP (seq# overridden) */ {0x17 ,0x21a11000 },/* dock-mic */
@@ -4376,15 +4378,33 @@ static const struct cxt_pincfg cxt_pincf {} }; +/* ThinkPad 410/420/510/520, X201 & co with cxt5066 */ +static const struct cxt_pincfg cxt_pincfg_lenovo_tp410[] = { + {0x19 ,0x042110ff },/* HP (seq# overridden) */ + {0x1a ,0x21a190f0 },/* dock-mic */ + {0x1c ,0x212140ff },/* dock-HP */ + {} +}; +static const struct cxt_pincfg *cxt_pincfg_tbl[] = { [CXT_PINCFG_LENOVO_X200 ] = cxt_pincfg_lenovo_x200, + [CXT_PINCFG_LENOVO_TP410 ] = cxt_pincfg_lenovo_tp410, }; -static const struct snd_pci_quirk cxt_fixups[] = { +static const struct snd_pci_quirk cxt5051_fixups[] = {SND_PCI_QUIRK (0x17aa ,0x20f2 ,"Lenovo X200" ,CXT_PINCFG_LENOVO_X200 ), {} }; +static const struct snd_pci_quirk cxt5066_fixups[] = { +SND_PCI_QUIRK (0x17aa ,0x20f2 ,"Lenovo T400" ,CXT_PINCFG_LENOVO_TP410 ), +SND_PCI_QUIRK (0x17aa ,0x215e ,"Lenovo T410" ,CXT_PINCFG_LENOVO_TP410 ), +SND_PCI_QUIRK (0x17aa ,0x215f ,"Lenovo T510" ,CXT_PINCFG_LENOVO_TP410 ), +SND_PCI_QUIRK (0x17aa ,0x21ce ,"Lenovo T420" ,CXT_PINCFG_LENOVO_TP410 ), +SND_PCI_QUIRK (0x17aa ,0x21cf ,"Lenovo T520" ,CXT_PINCFG_LENOVO_TP410 ), + {} +}; +/* add "fake" mute amp-caps to DACs on cx5051 so that mixer mute switches * can be created (bko#42825) */
@@ -4421,11 +4441,13 @@ static int patch_conexant_auto(struct hdbreak ;case 0x14f15051 :add_cx5051_fake_mutes (codec); +apply_pin_fixup (codec, cxt5051_fixups, cxt_pincfg_tbl); +break ; +default : +apply_pin_fixup (codec, cxt5066_fixups, cxt_pincfg_tbl);break ; } -apply_pin_fixup (codec, cxt_fixups, cxt_pincfg_tbl); - err =cx_auto_search_adcs (codec);if (err <0 )return err;
Greg KH
maintainerPATCH 6/62 memblock: memblock should be able to handle zero length operations
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tejun Heo <[email protected]>
commit b3dc627cabb33fc95f93da78457770c1b2a364d2 upstream.
Commit 24aa07882b ("memblock, x86: Replace memblock_x86_reserve/ free_range() with generic ones") replaced x86 specific memblock operations with the generic ones; unfortunately, it lost zero length operation handling in the process making the kernel panic if somebody tries to reserve zero length area.
There isn't much to be gained by being cranky to zero length operations and panicking is almost the worst response. Drop the BUG_ON() in memblock_reserve() and update memblock_add_region/isolate_range() so that all zero length operations are handled as noops.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43098
--- mm/memblock.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
mm/memblock.c +6 -1
@@ -330,6 +330,9 @@ static int __init_memblock memblock_add_phys_addr_t end = base +memblock_cap_size (base, &size);int i, nr_new; +if (!size) +return 0 ; +/* special case for empty array */ if (type->regions[0 ].size ==0 ) {WARN_ON (type->cnt !=1 || type->total_size);
@@ -430,6 +433,9 @@ static int __init_memblock memblock_isol *start_rgn = *end_rgn =0 ; +if (!size) +return 0 ; +/* we'll create at most two more regions */ while (type->cnt +2 > type->max)if (memblock_double_array (type) <0 )
@@ -514,7 +520,6 @@ int __init_memblock memblock_reserve(phy (unsigned long long )base, (unsigned long long )base + size, (void *)_RET_IP_); -BUG_ON (0 == size);return memblock_add_region (_rgn, base, size,MAX_NUMNODES ); }
Greg KH
maintainerPATCH 7/62 ARM: clps711x: serial driver hungs are a result of call disable_irq within ISR
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexander Shiyan <[email protected]>
commit 7a6fbc9a887193a1e9f8658703881c528040afbc upstream.
Since 2.6.30-rc1 clps711x serial driver hungs system. This is a result of call disable_irq from ISR. synchronize_irq waits for end of interrupt and goes to infinite loop. This patch fix this problem.
--- drivers/tty/serial/clps711x.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-)
drivers/tty/serial/clps711x.c +8 -6
@@ -154,10 +154,9 @@ static irqreturn_t clps711xuart_int_tx(i port->x_char =0 ;return IRQ_HANDLED ; } -if (uart_circ_empty (xmit) ||uart_tx_stopped (port)) { -clps711xuart_stop_tx (port); -return IRQ_HANDLED ; - } + +if (uart_circ_empty (xmit) ||uart_tx_stopped (port)) + goto disable_tx_irq; count = port->fifosize >>1 ; do {
@@ -171,8 +170,11 @@ static irqreturn_t clps711xuart_int_tx(iif (uart_circ_chars_pending (xmit) <WAKEUP_CHARS )uart_write_wakeup (port); -if (uart_circ_empty (xmit)) -clps711xuart_stop_tx (port); +if (uart_circ_empty (xmit)) { + disable_tx_irq: +disable_irq_nosync (TX_IRQ (port)); +tx_enabled (port) =0 ; + }return IRQ_HANDLED ; }
Greg KH
maintainerPATCH 8/62 ARM: at91: fix at91sam9261ek Ethernet dm9000 irq
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jean-Christophe PLAGNIOL-VILLARD <[email protected]>
commit ee9dd7631af6fb5c02964ed5b496217cd4ced059 upstream.
You need to setup the dm9000 irq via gpio_to_irq() since d0fbda9add (ARM: at91/gpio: drop PIN_BASE).
--- arch/arm/mach-at91/board-sam9261ek.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
arch/arm/mach-at91/board-sam9261ek.c +3 -2
@@ -85,8 +85,6 @@ static struct resource dm9000_resource[] .flags = IORESOURCE_MEM }, [2] = { - .start = AT91_PIN_PC11, - .end = AT91_PIN_PC11, .flags = IORESOURCE_IRQ | IORESOURCE_IRQ_LOWEDGE | IORESOURCE_IRQ_HIGHEDGE, }
@@ -130,6 +128,8 @@ static struct sam9_smc_config __initdatastatic void __init ek_add_device_dm9000 (void ) { +struct resource *r = &dm9000_resource[2 ]; +/* Configure chip-select 2 (DM9000) */ sam9_smc_configure (0 ,2 , &dm9000_smc_config);
@@ -139,6 +139,7 @@ static void __init ek_add_device_dm9000(/* Configure Interrupt pin as input, no pull-up */ at91_set_gpio_input (AT91_PIN_PC11 ,0 ); + r->start = r->end =gpio_to_irq (AT91_PIN_PC11 ); platform_device_register(&dm9000_device); }#else
Greg KH
maintainerPATCH 9/62 ARM: OMAP1: DMTIMER: fix broken timer clock source selection
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paul Walmsley <[email protected]>
commit 6aaec67da1e41a0752a2b903b989e73b9f02e182 upstream.
DMTIMER source selection on OMAP1 is broken. omap1_dm_timer_set_src() tries to use __raw_{read,write}l() to read from and write to physical addresses, but those functions take virtual addresses.
sparse caught this:
arch/arm/mach-omap1/timer.c:50:13: warning: incorrect type in argument 1 (different base types)arch/arm/mach-omap1/timer.c:50:13: expected void const volatile [noderef] <asn:2>*<noident>arch/arm/mach-omap1/timer.c:50:13: got unsigned intarch/arm/mach-omap1/timer.c:52:9: warning: incorrect type in argument 1 (different base types)arch/arm/mach-omap1/timer.c:52:9: expected void const volatile [noderef] <asn:2>*<noident>arch/arm/mach-omap1/timer.c:52:9: got unsigned int
Fix by using omap_{read,writel}(), just like the other users of the MOD_CONF_CTRL_1 register in the OMAP1 codebase. Of course, in the long term, removing omap_{read,write}l() is the appropriate thing to do; but this will take some work to do this cleanly.
Looks like this was caused by 97933d6 (ARM: OMAP1: dmtimer: conversion to platform devices) that dangerously moved code and changed it in the same patch.
--- arch/arm/mach-omap1/timer.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/arm/mach-omap1/timer.c +2 -2
@@ -47,9 +47,9 @@ static int omap1_dm_timer_set_src(structint n = (pdev->id -1 ) <<1 ;u32 l; - l =__raw_readl (MOD_CONF_CTRL_1 ) & ~(0x03 << n); + l =omap_readl (MOD_CONF_CTRL_1 ) & ~(0x03 << n); l |= source << n; -__raw_writel (l,MOD_CONF_CTRL_1 ); +omap_writel (l,MOD_CONF_CTRL_1 );return 0 ; }
Greg KH
maintainerPATCH 10/62 ARM: OMAP: serial: Fix the ocp smart idlemode handling bug
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Santosh Shilimkar <[email protected]>
commit 5ae256dcd91bf308826a4ac19598b27ebb86a536 upstream.
The current serial UART code, while fidling with ocp idlemode bits, forget about the smart idle wakeup bit even if it is supported by UART IP block. This will lead to missing the module wakeup on OMAP's where the smart idle wakeup is supported.
This was the root cause of the console sluggishness issue, I have been observing on OMAP4 devices and also can be potential reason for some other UART wakeup issues.
--- arch/arm/mach-omap2/serial.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
arch/arm/mach-omap2/serial.c +7 -1
@@ -110,8 +110,14 @@ static void omap_uart_set_noidle(structstatic void omap_uart_set_smartidle (struct platform_device *pdev) {struct omap_device *od =to_omap_device (pdev); +u8 idlemode; -omap_hwmod_set_slave_idlemode (od->hwmods[0 ],HWMOD_IDLEMODE_SMART ); +if (od->hwmods[0 ]->class->sysc->idlemodes &SIDLE_SMART_WKUP ) + idlemode =HWMOD_IDLEMODE_SMART_WKUP ; +else + idlemode =HWMOD_IDLEMODE_SMART ; + +omap_hwmod_set_slave_idlemode (od->hwmods[0 ], idlemode); }#else
Greg KH
maintainerPATCH 11/62 mmc: fixes for eMMC v4.5 discard operation
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Adrian Hunter <[email protected]>
commit 7194efb8f063ee3aa0cb50d9002348887e68ec10 upstream.
eMMC v4.5 discard operation is significantly different from the existing trim operation because it is not guaranteed to work with the new sanitize operation. Consequently mmc_can_trim() is separated from mmc_can_discard().
Also the new discard operation does not result in the sectors being set to all-zeros, so discard_zeroes_data must not be set.
In addition, the new discard has the same timeout as trim, but from v4.5 trim is defined to use the hc timeout. The timeout calculation is adjusted accordingly.
Fixes apply to linux 3.2 on.
--- drivers/mmc/card/queue.c | 2 +- drivers/mmc/core/core.c | 7 ++++--- 2 files changed, 5 insertions(+), 4 deletions(-)
drivers/mmc/card/queue.c +1 -1
@@ -139,7 +139,7 @@ static void mmc_queue_setup_discard(struqueue_flag_set_unlocked (QUEUE_FLAG_DISCARD , q); q->limits.max_discard_sectors = max_discard; -if (card->erased_byte ==0 ) +if (card->erased_byte ==0 && !mmc_can_discard (card)) q->limits.discard_zeroes_data =1 ; q->limits.discard_granularity = card->pref_erase <<9 ;/* granularity must not be greater than max. discard */
drivers/mmc/core/core.c +4 -3
@@ -1557,7 +1557,10 @@ static unsigned int mmc_mmc_erase_timeou {unsigned int erase_timeout; -if (card->ext_csd.erase_group_def &1 ) { +if (arg ==MMC_DISCARD_ARG || + (arg ==MMC_TRIM_ARG && card->ext_csd.rev >=6 )) { + erase_timeout = card->ext_csd.trim_timeout; + }else if (card->ext_csd.erase_group_def &1 ) {/* High Capacity Erase Group Size uses HC timeouts */ if (arg ==MMC_TRIM_ARG ) erase_timeout = card->ext_csd.trim_timeout;
@@ -1829,8 +1832,6 @@ int mmc_can_trim(struct mmc_card *card) {if (card->ext_csd.sec_feature_support &EXT_CSD_SEC_GB_CL_EN )return 1 ; -if (mmc_can_discard (card)) -return 1 ;return 0 ; }EXPORT_SYMBOL (mmc_can_trim);
Greg KH
maintainerPATCH 12/62 mmc: fixes for eMMC v4.5 sanitize operation
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Adrian Hunter <[email protected]>
commit 283028122db37621b124f079ca8eae5b64807ad4 upstream.
eMMC v4.5 sanitize operation erases all copies of unmapped data. However trim or erase operations must be used first to unmap the required sectors. That was not being done.
Fixes apply to linux 3.2 on.
--- drivers/mmc/card/block.c | 54 +++++++++++++++++++++++++++++++++-------------- drivers/mmc/core/core.c | 2 + 2 files changed, 40 insertions(+), 16 deletions(-)
drivers/mmc/card/block.c +38 -16
@@ -874,7 +874,7 @@ static int mmc_blk_issue_secdiscard_rq(s {struct mmc_blk_data *md = mq->data;struct mmc_card *card = md->queue.card; -unsigned int from, nr, arg; +unsigned int from, nr, arg, trim_arg, erase_arg;int err =0 , type =MMC_BLK_SECDISCARD ;if (!(mmc_can_secure_erase_trim (card) ||mmc_can_sanitize (card))) {
@@ -882,20 +882,26 @@ static int mmc_blk_issue_secdiscard_rq(s goto out; } + from =blk_rq_pos (req); + nr =blk_rq_sectors (req); +/* The sanitize operation is supported at v4.5 only */ if (mmc_can_sanitize (card)) { - err =mmc_switch (card,EXT_CSD_CMD_SET_NORMAL , -EXT_CSD_SANITIZE_START ,1 ,0 ); - goto out; + erase_arg =MMC_ERASE_ARG ; + trim_arg =MMC_TRIM_ARG ; + }else { + erase_arg =MMC_SECURE_ERASE_ARG ; + trim_arg =MMC_SECURE_TRIM1_ARG ; } - from =blk_rq_pos (req); - nr =blk_rq_sectors (req); - -if (mmc_can_trim (card) && !mmc_erase_group_aligned (card, from, nr)) - arg =MMC_SECURE_TRIM1_ARG ; -else - arg =MMC_SECURE_ERASE_ARG ; +if (mmc_erase_group_aligned (card, from, nr)) + arg = erase_arg; +else if (mmc_can_trim (card)) + arg = trim_arg; +else { + err = -EINVAL ; + goto out; + } retry:if (card->quirks &MMC_QUIRK_INAND_CMD38 ) { err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
@@ -905,25 +911,41 @@ retry:INAND_CMD38_ARG_SECERASE , 0);if (err) - goto out; + goto out_retry; } + err =mmc_erase (card, from, nr, arg); -if (!err && arg ==MMC_SECURE_TRIM1_ARG ) { +if (err == -EIO ) + goto out_retry; +if (err) + goto out; + +if (arg ==MMC_SECURE_TRIM1_ARG ) {if (card->quirks &MMC_QUIRK_INAND_CMD38 ) { err =mmc_switch (card,EXT_CSD_CMD_SET_NORMAL ,INAND_CMD38_ARG_EXT_CSD ,INAND_CMD38_ARG_SECTRIM2 ,0 );if (err) - goto out; + goto out_retry; } + err =mmc_erase (card, from, nr,MMC_SECURE_TRIM2_ARG ); +if (err == -EIO ) + goto out_retry; +if (err) + goto out; } -out: -if (err == -EIO && !mmc_blk_reset (md, card->host, type)) + +if (mmc_can_sanitize (card)) + err =mmc_switch (card,EXT_CSD_CMD_SET_NORMAL , +EXT_CSD_SANITIZE_START ,1 ,0 ); +out_retry: +if (err && !mmc_blk_reset (md, card->host, type)) goto retry;if (!err)mmc_blk_reset_success (md, type); +out:spin_lock_irq (&md->lock);__blk_end_request (req, err,blk_rq_bytes (req));spin_unlock_irq (&md->lock);
drivers/mmc/core/core.c +2 -0
@@ -1850,6 +1850,8 @@ EXPORT_SYMBOL(mmc_can_discard);int mmc_can_sanitize (struct mmc_card *card) { +if (!mmc_can_trim (card) && !mmc_can_erase (card)) +return 0 ;if (card->ext_csd.sec_feature_support &EXT_CSD_SEC_SANITIZE )return 1 ;return 0 ;
Greg KH
maintainerPATCH 13/62 mmc: sdhci: refine non-removable card checking for card detection
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Drake <[email protected]>
commit 87b87a3fc0eec58d95e4216392f889a26439ad22 upstream.
Commit c79396c191bc19 ("mmc: sdhci: prevent card detection activity for non-removable cards") disables card detection where the cards are marked as non-removable.
This makes sense, but the implementation detail of calling mmc_card_is_removable() causes some problems, because mmc_card_is_removable() is overloaded with CONFIG_MMC_UNSAFE_RESUME semantics.
In the OLPC XO case, we need CONFIG_MMC_UNSAFE_RESUME because our root filesystem is stored on SD, but we also have external SD card slots where we want automatic card detection.
Refine the check to only apply to hosts marked as MMC_CAP_NONREMOVABLE, which is defined to mean that the card is *really* nonremovable. This could be revisited in future if we find a way to improve CONFIG_MMC_UNSAFE_RESUME semantics.
--- drivers/mmc/host/sdhci.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/mmc/host/sdhci.c +1 -1
@@ -147,7 +147,7 @@ static void sdhci_set_card_detection(stru32 present, irqs;if ((host->quirks &SDHCI_QUIRK_BROKEN_CARD_DETECTION ) || - !mmc_card_is_removable (host->mmc)) + (host->mmc->caps &MMC_CAP_NONREMOVABLE ))return ; present = sdhci_readl(host, SDHCI_PRESENT_STATE) &
Greg KH
maintainerPATCH 14/62 mmc: unbreak sdhci-esdhc-imx on i.MX25
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Bénard <[email protected]>
commit b89152824f993a9572b47eb31f4579feadeac34c upstream.
This was broken by me in 37865fe91582582a6f6c00652f6a2b1ff71f8a78 ("mmc: sdhci-esdhc-imx: fix timeout on i.MX's sdhci") where more extensive tests would have shown that read or write of data to the card were failing (even if the partition table was correctly read).
--- drivers/mmc/host/sdhci-esdhc-imx.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/mmc/host/sdhci-esdhc-imx.c +1 -2
@@ -467,8 +467,7 @@ static int __devinit sdhci_esdhc_imx_proclk_enable (clk); pltfm_host->clk = clk; -if (!is_imx25_esdhc (imx_data)) - host->quirks |=SDHCI_QUIRK_BROKEN_TIMEOUT_VAL ; + host->quirks |=SDHCI_QUIRK_BROKEN_TIMEOUT_VAL ;if (is_imx25_esdhc (imx_data) ||is_imx35_esdhc (imx_data))/* Fix errata ENGcm07207 present on i.MX25 and i.MX35 */
Re: [ 14/62] mmc: unbreak sdhci-esdhc-imx on i.MX25
Hi,
Quoted 1 line · Greg KH
3.3-stable review patch.
[...]
Quoted 6 lines
commit
b89152824f993a9572b47eb31f4579feadeac34cupstream.This was broken by me in
37865fe91582582a6f6c00652f6a2b1ff71f8a78("mmc: sdhci-esdhc-imx: fix timeout on i.MX's sdhci") where more extensive tests would have shown that read or write of data to the card were failing (even if the partition table was correctly read).
37865fe91582 is v2.6.37-rc4~24^2~7 so it sounds like this patch should also be applied to 3.0.y.
Here's a straightforward backport to account for the lack of v3.1-rc1~321^2~77 ("mmc: sdhci: make sdhci-pltfm device drivers self registered") and v3.1-rc1~125^2^2~5 ("mmc: sdhci-esdhc-imx: get rid of the uses of cpu_is_mx"). Sensible?
-- >8 --
From: Eric Bénard <[email protected]>
Date: Wed, 18 Apr 2012 02:30:20 +0200
commit b89152824f993a9572b47eb31f4579feadeac34c upstream.
This was broken by me in 37865fe91582582a6f6c00652f6a2b1ff71f8a78 ("mmc: sdhci-esdhc-imx: fix timeout on i.MX's sdhci") where more extensive tests would have shown that read or write of data to the card were failing (even if the partition table was correctly read).
---
Thanks,
Jonathan
drivers/mmc/host/sdhci-esdhc-imx.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/mmc/host/sdhci-esdhc-imx.c +1 -2
@@ -245,8 +245,7 @@ static int esdhc_pltfm_init(struct sdhci_host *host, struct sdhci_pltfm_data *pd } pltfm_host->priv = imx_data; -if (!cpu_is_mx25 ()) - host->quirks |=SDHCI_QUIRK_BROKEN_TIMEOUT_VAL ; + host->quirks |=SDHCI_QUIRK_BROKEN_TIMEOUT_VAL ;if (cpu_is_mx25 () ||cpu_is_mx35 ()) {/* Fix errata ENGcm07207 present on i.MX25 and i.MX35 */
Signature · 1 line
1.7.10
Re: [ 14/62] mmc: unbreak sdhci-esdhc-imx on i.MX25
Quoted 13 lines · Jonathan Nieder
Hi,
Quoted 1 line · Greg KH
3.3-stable review patch.
[...]
Quoted 6 lines
commit
b89152824f993a9572b47eb31f4579feadeac34cupstream.This was broken by me in
37865fe91582582a6f6c00652f6a2b1ff71f8a78("mmc: sdhci-esdhc-imx: fix timeout on i.MX's sdhci") where more extensive tests would have shown that read or write of data to the card were failing (even if the partition table was correctly read).
Quoted 7 lines
37865fe91582is v2.6.37-rc4~24^2~7 so it sounds like this patch should also be applied to 3.0.y.Here's a straightforward backport to account for the lack of v3.1-rc1~321^2~77 ("mmc: sdhci: make sdhci-pltfm device drivers self registered") and v3.1-rc1~125^2^2~5 ("mmc: sdhci-esdhc-imx: get rid of the uses of
cpu_is_mx"). Sensible?
Yes, thanks.
Signature · 2 lines
Pengutronix e.K. | Wolfram Sang | Industrial Linux Solutions | http://www.pengutronix.de/ |
Greg KH
maintainerRe: [ 14/62] mmc: unbreak sdhci-esdhc-imx on i.MX25
In reply to Jonathan NiederQuoted 13 lines · Jonathan Nieder
Hi,
Quoted 1 line · Greg KH
3.3-stable review patch.
[...]
Quoted 6 lines
commit
b89152824f993a9572b47eb31f4579feadeac34cupstream.This was broken by me in
37865fe91582582a6f6c00652f6a2b1ff71f8a78("mmc: sdhci-esdhc-imx: fix timeout on i.MX's sdhci") where more extensive tests would have shown that read or write of data to the card were failing (even if the partition table was correctly read).
Quoted 7 lines
37865fe91582is v2.6.37-rc4~24^2~7 so it sounds like this patch should also be applied to 3.0.y.Here's a straightforward backport to account for the lack of v3.1-rc1~321^2~77 ("mmc: sdhci: make sdhci-pltfm device drivers self registered") and v3.1-rc1~125^2^2~5 ("mmc: sdhci-esdhc-imx: get rid of the uses of
cpu_is_mx"). Sensible?
Looks good to me, thanks for doing this.
Greg KH
maintainerPATCH 15/62 xen/gntdev: do not set VM_PFNMAP
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stefano Stabellini <[email protected]>
commit e8e937be971d706061dc56220ff3605ab77622a7 upstream.
Since we are using the m2p_override we do have struct pages corresponding to the user vma mmap'ed by gntdev.
Removing the VM_PFNMAP flag makes get_user_pages work on that vma. An example test case would be using a Xen userspace block backend (QDISK) on a file on NFS using O_DIRECT.
--- drivers/xen/gntdev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/xen/gntdev.c +1 -1
@@ -722,7 +722,7 @@ static int gntdev_mmap(struct file *flip vma->vm_flags |=VM_RESERVED |VM_DONTEXPAND ;if (use_ptemod) - vma->vm_flags |=VM_DONTCOPY |VM_PFNMAP ; + vma->vm_flags |=VM_DONTCOPY ; vma->vm_private_data = map;
Greg KH
maintainerPATCH 16/62 xen/xenbus: Add quirk to deal with misconfigured backends.
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Konrad Rzeszutek Wilk <[email protected]>
commit 3066616ce23aad5719c23a0f21f32676402cb44b upstream.
A rather annoying and common case is when booting a PVonHVM guest and exposing the PV KBD and PV VFB - as broken toolstacks don't always initialize the backends correctly.
Normally The HVM guest is using the VGA driver and the emulated keyboard for this (though upstream version of QEMU implements PV KBD, but still uses a VGA driver). We provide a very basic two-stage wait mechanism - where we wait for 30 seconds for all devices, and then for 270 for all them except the two mentioned.
That allows us to wait for the essential devices, like network or disk for the full 6 minutes.
To trigger this, put this in your guest config:
vfb = [ 'vnc=1, vnclisten=0.0.0.0 ,vncunused=1']
instead of this:
vnc=1
vnclisten="0.0.0.0"
[v3: Split delay in non-essential (30 seconds) and essential
devices per Ian and Stefano suggestion]
--- drivers/xen/xenbus/xenbus_probe_frontend.c | 69 ++++++++++++++++++++++------- 1 file changed, 53 insertions(+), 16 deletions(-)
drivers/xen/xenbus/xenbus_probe_frontend.c +53 -16
@@ -129,7 +129,7 @@ static int read_backend_details(struct xreturn xenbus_read_otherend_details (xendev,"backend-id" ,"backend" ); } -static int is_device_connecting (struct device *dev,void *data) +static int is_device_connecting (struct device *dev,void *data,bool ignore_nonessential) {struct xenbus_device *xendev =to_xenbus_device (dev);struct device_driver *drv = data;
@@ -146,16 +146,41 @@ static int is_device_connecting(struct dif (drv && (dev->driver != drv))return 0 ; +if (ignore_nonessential) { +/* With older QEMU, for PVonHVM guests the guest config files +* could contain: vfb = [ 'vnc=1, vnclisten=0.0.0.0'] +* which is nonsensical as there is no PV FB (there can be +* a PVKB) running as HVM guest. */ + +if ((strncmp (xendev->nodename,"device/vkbd" ,11 ) ==0 )) +return 0 ; + +if ((strncmp (xendev->nodename,"device/vfb" ,10 ) ==0 )) +return 0 ; + } xendrv =to_xenbus_driver (dev->driver);return (xendev->state < XenbusStateConnected || (xendev->state == XenbusStateConnected && xendrv->is_ready && !xendrv->is_ready (xendev))); } +static int essential_device_connecting (struct device *dev,void *data) +{ +return is_device_connecting (dev, data, true/* ignore PV[KBB+FB] */ ); +} +static int non_essential_device_connecting (struct device *dev,void *data) +{ +return is_device_connecting (dev, data, false); +} -static int exists_connecting_device (struct device_driver *drv) +static int exists_essential_connecting_device (struct device_driver *drv) {return bus_for_each_dev (&xenbus_frontend.bus,NULL , drv, - is_device_connecting); + essential_device_connecting); +} +static int exists_non_essential_connecting_device (struct device_driver *drv) +{ +return bus_for_each_dev (&xenbus_frontend.bus,NULL , drv, + non_essential_device_connecting); }static int print_device_status (struct device *dev,void *data)
@@ -186,6 +211,23 @@ static int print_device_status(struct de/* We only wait for device setup after most initcalls have run. */ static int ready_to_wait_for_devices; +static bool wait_loop (unsigned long start,unsigned int max_delay, +unsigned int *seconds_waited) +{ +if (time_after (jiffies, start + (*seconds_waited+5 )*HZ )) { +if (!*seconds_waited) +printk (KERN_WARNING "XENBUS: Waiting for " +"devices to initialise: " ); + *seconds_waited +=5 ; +printk ("%us..." , max_delay - *seconds_waited); +if (*seconds_waited == max_delay) +return true; + } + +schedule_timeout_interruptible (HZ /10 ); + +return false; +}/* * On a 5-minute timeout, wait for all devices currently configured. We need * to do this to guarantee that the filesystems and / or network devices
@@ -209,19 +251,14 @@ static void wait_for_devices(struct xenbif (!ready_to_wait_for_devices || !xen_domain ())return ; -while (exists_connecting_device (drv)) { -if (time_after (jiffies, start + (seconds_waited+5 )*HZ )) { -if (!seconds_waited) -printk (KERN_WARNING "XENBUS: Waiting for " -"devices to initialise: " ); - seconds_waited +=5 ; -printk ("%us..." ,300 - seconds_waited); -if (seconds_waited ==300 ) -break ; - } - -schedule_timeout_interruptible (HZ /10 ); - } +while (exists_non_essential_connecting_device (drv)) +if (wait_loop (start,30 , &seconds_waited)) +break ; + +/* Skips PVKB and PVFB check.*/ +while (exists_essential_connecting_device (drv)) +if (wait_loop (start,270 , &seconds_waited)) +break ;if (seconds_waited)printk ("\n" );
Greg KH
maintainerPATCH 17/62 USB: yurex: Remove allocation of coherent buffer for setup-packet buffer
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tomoki Sekiyama <[email protected]>
commit 523fc5c14f6cad283e5a266eba0e343aed6e73d5 upstream.
Removes allocation of coherent buffer for the control-request setup-packet buffer from the yurex driver. Using coherent buffers for setup-packet is obsolete and does not work with some USB host implementations.
--- drivers/usb/misc/yurex.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-)
drivers/usb/misc/yurex.c +2 -6
@@ -99,9 +99,7 @@ static void yurex_delete(struct kref *krusb_put_dev (dev->udev);if (dev->cntl_urb) {usb_kill_urb (dev->cntl_urb); -if (dev->cntl_req) -usb_free_coherent (dev->udev,YUREX_BUF_SIZE , - dev->cntl_req, dev->cntl_urb->setup_dma); +kfree (dev->cntl_req);if (dev->cntl_buffer)usb_free_coherent (dev->udev,YUREX_BUF_SIZE , dev->cntl_buffer, dev->cntl_urb->transfer_dma);
@@ -234,9 +232,7 @@ static int yurex_probe(struct usb_interf }/* allocate buffer for control req */ - dev->cntl_req =usb_alloc_coherent (dev->udev,YUREX_BUF_SIZE , -GFP_KERNEL , - &dev->cntl_urb->setup_dma); + dev->cntl_req =kmalloc (YUREX_BUF_SIZE ,GFP_KERNEL );if (!dev->cntl_req) {err ("Could not allocate cntl_req" ); goto error;
Greg KH
maintainerPATCH 18/62 USB: yurex: Fix missing URB_NO_TRANSFER_DMA_MAP flag in urb
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tomoki Sekiyama <[email protected]>
commit 532f17b5d59bf0deb6f1ff9bc1fb27d5b5011c09 upstream.
Current probing code is setting URB_NO_TRANSFER_DMA_MAP flag into a wrong urb structure, and this causes BUG_ON with some USB host implementations. This patch fixes the issue.
--- drivers/usb/misc/yurex.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/misc/yurex.c +1 -1
@@ -282,7 +282,7 @@ static int yurex_probe(struct usb_interfusb_rcvintpipe (dev->udev, dev->int_in_endpointAddr), dev->int_buffer,YUREX_BUF_SIZE , yurex_interrupt, dev, 1); - dev->cntl_urb->transfer_flags |=URB_NO_TRANSFER_DMA_MAP ; + dev->urb->transfer_flags |=URB_NO_TRANSFER_DMA_MAP ;if (usb_submit_urb (dev->urb,GFP_KERNEL )) { retval = -EIO ;err ("Could not submitting URB" );
Greg KH
maintainerPATCH 19/62 uwb: fix use of del_timer_sync() in interrupt
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Oliver Neukum <[email protected]>
commit 9426cd05682745d1024dbabdec5631309bd2f480 upstream.
del_timer_sync() cannot be used in interrupt.
Replace it with del_timer() and a flag
--- drivers/uwb/neh.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-)
drivers/uwb/neh.c +11 -1
@@ -107,6 +107,7 @@ struct uwb_rc_neh {u8 evt_type;__le16 evt;u8 context; +u8 completed;uwb_rc_cmd_cb_f cb;void *arg;
@@ -409,6 +410,7 @@ static void uwb_rc_neh_grok_event(structstruct device *dev = &rc->uwb_dev.dev;struct uwb_rc_neh *neh;struct uwb_rceb *notif; +unsigned long flags;if (rceb->bEventContext ==0 ) { notif =kmalloc (size,GFP_ATOMIC );
@@ -422,7 +424,11 @@ static void uwb_rc_neh_grok_event(struct }else { neh =uwb_rc_neh_lookup (rc, rceb);if (neh) { -del_timer_sync (&neh->timer); +spin_lock_irqsave (&rc->neh_lock, flags); +/* to guard against a timeout */ + neh->completed =1 ; +del_timer (&neh->timer); +spin_unlock_irqrestore (&rc->neh_lock, flags);uwb_rc_neh_cb (neh, rceb, size); }else dev_warn(dev, "event 0x%02x/%04x/%02x (%zu bytes): nobody cared\n",
@@ -568,6 +574,10 @@ static void uwb_rc_neh_timer(unsigned lounsigned long flags;spin_lock_irqsave (&rc->neh_lock, flags); +if (neh->completed) { +spin_unlock_irqrestore (&rc->neh_lock, flags); +return ; + }if (neh->context)__uwb_rc_neh_rm (rc, neh);else
Greg KH
maintainerPATCH 20/62 uwb: fix error handling
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Oliver Neukum <[email protected]>
commit 5bd7b419ef2eb4989b207753e088c3437159618a upstream.
Fatal errors such as a device disconnect must not trigger error handling. The error returns must be checked.
--- drivers/uwb/hwa-rc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/uwb/hwa-rc.c +2 -1
@@ -645,7 +645,8 @@ void hwarc_neep_cb(struct urb *urb)dev_err (dev,"NEEP: URB error %d\n" , urb->status); } result =usb_submit_urb (urb,GFP_ATOMIC ); -if (result <0 ) { +if (result <0 && result != -ENODEV && result != -EPERM ) { +/* ignoring unrecoverable errors */ dev_err (dev,"NEEP: Can't resubmit URB (%d) resetting device\n" , result); goto error;
Greg KH
maintainerPATCH 21/62 davinci_mdio: Fix MDIO timeout check
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christian Riesch <[email protected]>
commit 5b76d0600b2b08eef77f8e9226938b7b6bde3099 upstream.
Under heavy load (flood ping) it is possible for the MDIO timeout to expire before the loop checks the GO bit again. This patch adds an additional check whether the operation was done before actually returning -ETIMEDOUT.
To reproduce this bug, flood ping the device, e.g., ping -f -l 1000 After some time, a "timed out waiting for user access" warning may appear. And even worse, link may go down since the PHY reported a timeout.
--- drivers/net/ethernet/ti/davinci_mdio.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/net/ethernet/ti/davinci_mdio.c +5 -0
@@ -181,6 +181,11 @@ static inline int wait_for_user_access(s__davinci_mdio_reset (data);return -EAGAIN ; } + + reg =__raw_readl (®s->user[0 ].access); +if ((reg &USERACCESS_GO ) ==0 ) +return 0 ; +dev_err (data->dev,"timed out waiting for user access\n" );return -ETIMEDOUT ; }
Greg KH
maintainerPATCH 22/62 mwifiex: update pcie8766 scratch register addresses
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bing Zhao <[email protected]>
commit 428ca8a7065354877db63ceabfc493107686eebe upstream.
The scratch register addresses have been changed for newer chips. Since the old chip was never shipped and it will not be supported any more, just update register addresses to support the new chips.
--- drivers/net/wireless/mwifiex/pcie.h | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-)
drivers/net/wireless/mwifiex/pcie.h +9 -9
@@ -48,15 +48,15 @@#define PCIE_HOST_INT_STATUS_MASK 0xC3C#define PCIE_SCRATCH_2_REG 0xC40#define PCIE_SCRATCH_3_REG 0xC44 -#define PCIE_SCRATCH_4_REG 0xCC0 -#define PCIE_SCRATCH_5_REG 0xCC4 -#define PCIE_SCRATCH_6_REG 0xCC8 -#define PCIE_SCRATCH_7_REG 0xCCC -#define PCIE_SCRATCH_8_REG 0xCD0 -#define PCIE_SCRATCH_9_REG 0xCD4 -#define PCIE_SCRATCH_10_REG 0xCD8 -#define PCIE_SCRATCH_11_REG 0xCDC -#define PCIE_SCRATCH_12_REG 0xCE0 +#define PCIE_SCRATCH_4_REG 0xCD0 +#define PCIE_SCRATCH_5_REG 0xCD4 +#define PCIE_SCRATCH_6_REG 0xCD8 +#define PCIE_SCRATCH_7_REG 0xCDC +#define PCIE_SCRATCH_8_REG 0xCE0 +#define PCIE_SCRATCH_9_REG 0xCE4 +#define PCIE_SCRATCH_10_REG 0xCE8 +#define PCIE_SCRATCH_11_REG 0xCEC +#define PCIE_SCRATCH_12_REG 0xCF0#define CPU_INTR_DNLD_RDY BIT(0)#define CPU_INTR_DOOR_BELL BIT(1)
Greg KH
maintainerPATCH 23/62 brcm80211: smac: resume transmit fifo upon receiving frames
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arend van Spriel <[email protected]>
commit badc4f07622f0f7093a201638f45e85765f1b5e4 upstream.
There have been reports about not being able to use access-points on channel 12 and 13 or having connectivity issues when these channels were part of the selected regulatory domain. Upon switching to these channels the brcmsmac driver suspends the transmit dma fifos. This patch resumes them upon handing over the first received beacon to mac80211.
This patch is to be applied to the stable tree for kernel versions 3.2 and 3.3.
--- drivers/net/wireless/brcm80211/brcmsmac/main.c | 8 ++++++++ 1 file changed, 8 insertions(+)
drivers/net/wireless/brcm80211/brcmsmac/main.c +8 -0
@@ -7629,6 +7629,7 @@ brcms_c_recvctl(struct brcms_c_info *wlc {int len_mpdu;struct ieee80211_rx_status rx_status; +struct ieee80211_hdr *hdr;memset (&rx_status,0 ,sizeof (rx_status));prep_mac80211_status (wlc, rxh, p, &rx_status);
@@ -7638,6 +7639,13 @@ brcms_c_recvctl(struct brcms_c_info *wlcskb_pull (p,D11_PHY_HDR_LEN );__skb_trim (p, len_mpdu); +/* unmute transmit */ +if (wlc->hw->suspended_fifos) { + hdr = (struct ieee80211_hdr *)p->data; +if (ieee80211_is_beacon (hdr->frame_control)) +brcms_b_mute (wlc->hw, false); + } +memcpy (IEEE80211_SKB_RXCB (p), &rx_status,sizeof (rx_status));ieee80211_rx_irqsafe (wlc->pub->ieee_hw, p); }
Jonathan Nieder
Tested-by Francesco Saverio Schiavarelli Reviewed-by Pieter-Paul Giesberts Reviewed-by Brett Rudley on v1 23/62Re: [ 23/62] brcm80211: smac: resume transmit fifo upon receiving frames
Quoted 1 line · Greg KH
3.3-stable review patch.
[...]
Quoted 11 lines
commit
badc4f07622f0f7093a201638f45e85765f1b5e4upstream.There have been reports about not being able to use access-points on channel 12 and 13 or having connectivity issues when these channels were part of the selected regulatory domain. Upon switching to these channels the brcmsmac driver suspends the transmit dma fifos. This patch resumes them upon handing over the first received beacon to mac80211.
This patch is to be applied to the stable tree for kernel versions 3.2 and 3.3.
Here's a blind backport to 3.0.y for the next cycle. Nothing scary involved, though of course it's completely untested. Sensible?
Thanks,
Jonathan
-- >8 --
From: Arend van Spriel <[email protected]>
Date: Wed, 11 Apr 2012 11:52:51 +0200
commit badc4f07622f0f7093a201638f45e85765f1b5e4 upstream.
There have been reports about not being able to use access-points on channel 12 and 13 or having connectivity issues when these channels were part of the selected regulatory domain. Upon switching to these channels the brcmsmac driver suspends the transmit dma fifos. This patch resumes them upon handing over the first received beacon to mac80211.
This patch is to be applied to the stable tree for kernel versions 3.2 and 3.3.
--- drivers/staging/brcm80211/brcmsmac/wlc_bmac.c | 3 +-- drivers/staging/brcm80211/brcmsmac/wlc_bmac.h | 1 + drivers/staging/brcm80211/brcmsmac/wlc_main.c | 8 ++++++++ 3 files changed, 10 insertions(+), 2 deletions(-)
drivers/staging/brcm80211/brcmsmac/wlc_bmac.c +1 -2
@@ -143,7 +143,6 @@ static bool wlc_bmac_validate_chip_access(struct wlc_hw_info *wlc_hw);static char *wlc_get_macaddr (struct wlc_hw_info *wlc_hw);static void wlc_mhfdef (struct wlc_info *wlc,u16 *mhfs,u16 mhf2_init);static void wlc_mctrl_write (struct wlc_hw_info *wlc_hw); -static void wlc_bmac_mute (struct wlc_hw_info *wlc_hw,bool want,mbool flags);static void wlc_ucode_mute_override_set (struct wlc_hw_info *wlc_hw);static void wlc_ucode_mute_override_clear (struct wlc_hw_info *wlc_hw);static u32 wlc_wlintrsoff (struct wlc_info *wlc);
@@ -2725,7 +2724,7 @@ void wlc_intrsrestore(struct wlc_info *wlc, u32 macintmask)W_REG (&wlc_hw->regs->macintmask, wlc->macintmask); } -static void wlc_bmac_mute (struct wlc_hw_info *wlc_hw,bool on,mbool flags) +void wlc_bmac_mute (struct wlc_hw_info *wlc_hw,bool on,mbool flags) {u8 null_ether_addr[ETH_ALEN ] = {0 ,0 ,0 ,0 ,0 ,0 };
drivers/staging/brcm80211/brcmsmac/wlc_bmac.h +1 -0
@@ -103,6 +103,7 @@ extern void wlc_bmac_macphyclk_set(struct wlc_hw_info *wlc_hw, bool clk);extern void wlc_bmac_phy_reset (struct wlc_hw_info *wlc_hw);extern void wlc_bmac_corereset (struct wlc_hw_info *wlc_hw,u32 flags);extern void wlc_bmac_reset (struct wlc_hw_info *wlc_hw); +extern void wlc_bmac_mute (struct wlc_hw_info *wlc_hw,bool want,mbool flags);extern void wlc_bmac_init (struct wlc_hw_info *wlc_hw,chanspec_t chanspec,bool mute);extern int wlc_bmac_up_prep (struct wlc_hw_info *wlc_hw);
drivers/staging/brcm80211/brcmsmac/wlc_main.c +8 -0
@@ -6145,6 +6145,7 @@ wlc_recvctl(struct wlc_info *wlc, d11rxhdr_t *rxh, struct sk_buff *p) {int len_mpdu;struct ieee80211_rx_status rx_status; +struct ieee80211_hdr *hdr;memset (&rx_status,0 ,sizeof (rx_status));prep_mac80211_status (wlc, rxh, p, &rx_status);
@@ -6154,6 +6155,13 @@ wlc_recvctl(struct wlc_info *wlc, d11rxhdr_t *rxh, struct sk_buff *p)skb_pull (p,D11_PHY_HDR_LEN );__skb_trim (p, len_mpdu); +/* unmute transmit */ +if (wlc->hw->suspended_fifos) { + hdr = (struct ieee80211_hdr *)p->data; +if (ieee80211_is_beacon (hdr->frame_control)) +wlc_bmac_mute (wlc->hw, false,0 ); + } +memcpy (IEEE80211_SKB_RXCB (p), &rx_status,sizeof (rx_status));ieee80211_rx_irqsafe (wlc->pub->ieee_hw, p);return ;
Signature · 1 line
1.7.10
Arend van Spriel
Acked-byRe: [ 23/62] brcm80211: smac: resume transmit fifo upon receiving frames
Quoted 13 lines · Jonathan Nieder
Quoted 1 line · Greg KH
3.3-stable review patch.
[...]
Quoted 9 lines
commit
badc4f07622f0f7093a201638f45e85765f1b5e4upstream.There have been reports about not being able to use access-points on channel 12 and 13 or having connectivity issues when these channels were part of the selected regulatory domain. Upon switching to these channels the brcmsmac driver suspends the transmit dma fifos. This patch resumes them upon handing over the first received beacon to mac80211.
Quoted 8 lines
Quoted 2 lines
This patch is to be applied to the stable tree for kernel versions 3.2 and 3.3.
Here's a blind backport to 3.0.y for the next cycle. Nothing scary involved, though of course it's completely untested. Sensible?
Thanks,
Jonathan
We decided to only submit the patch for the mainline version of the driver, but your changes on the staging driver look fine. So if this patch is accepted in stable it is
Gr. AvS
Re: [ 23/62] brcm80211: smac: resume transmit fifo upon receiving frames
Quoted 5 lines · Arend van Spriel
We decided to only submit the patch for the mainline version of the driver, but your changes on the staging driver look fine. So if this patch is accepted in stable it is
Acked-by Arend van Spriel <[email protected]>
Thanks for looking it over.
Greg KH
maintainerRe: [ 23/62] brcm80211: smac: resume transmit fifo upon receiving frames
Quoted 9 lines · Jonathan Nieder
Quoted 5 lines · Arend van Spriel
We decided to only submit the patch for the mainline version of the driver, but your changes on the staging driver look fine. So if this patch is accepted in stable it is
Acked-by Arend van Spriel <[email protected]>Thanks for looking it over.
Thanks for doing the work, now applied.
greg k-h
Greg KH
maintainerPATCH 24/62 mac80211: fix logic error in ibss channel type check
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Felix Fietkau <[email protected]>
commit 6741e7f048dacc92e37c5d724ff5c64e45f6c2c9 upstream.
The broken check leads to rate control attempting to use HT40 while the driver is configured for HT20. This leads to interesting hardware issues.
HT40 can only be used if the channel type is either HT40- or HT40+ and if the channel type of the cell matches the local type.
--- net/mac80211/ibss.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
net/mac80211/ibss.c +2 -2
@@ -435,8 +435,8 @@ static void ieee80211_rx_bss_info(struct* fall back to HT20 if we don't use or use * the other extension channel */ -if ((channel_type ==NL80211_CHAN_HT40MINUS || - channel_type ==NL80211_CHAN_HT40PLUS ) && +if (!(channel_type ==NL80211_CHAN_HT40MINUS || + channel_type ==NL80211_CHAN_HT40PLUS ) || channel_type != sdata->u.ibss.channel_type) sta_ht_cap_new.cap &= ~IEEE80211_HT_CAP_SUP_WIDTH_20_40 ;
Greg KH
maintainerPATCH 25/62 media: rc-core: set mode for winbond-cir
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Härdeman <[email protected]>
commit d9b786955f80fb306471fdb9ea24c6d03af6ca36 upstream.
Setting the correct mode is required by rc-core or scancodes won't be generated (which isn't very user-friendly).
This one-line fix should be suitable for 3.4-rc2.
--- drivers/media/rc/winbond-cir.c | 1 + 1 file changed, 1 insertion(+)
drivers/media/rc/winbond-cir.c +1 -0
@@ -1046,6 +1046,7 @@ wbcir_probe(struct pnp_dev *device, cons goto exit_unregister_led; } + data->dev->driver_type =RC_DRIVER_IR_RAW ; data->dev->driver_name =WBCIR_NAME ; data->dev->input_name =WBCIR_NAME ; data->dev->input_phys ="wbcir/cir0" ;
Greg KH
maintainerPATCH 26/62 media: drxk: Does not unlock mutex if sanity check failed in scu_command()
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexey Khoroshilov <[email protected]>
commit e4459e1682c107d7ee1bf102c1ba534230e9b50b upstream.
If sanity check fails in scu_command(), goto error leads to unlock of an unheld mutex. The check should not fail in reality, but it nevertheless worth fixing.
Found by Linux Driver Verification project (linuxtesting.org).
--- drivers/media/dvb/frontends/drxk_hard.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/media/dvb/frontends/drxk_hard.c +4 -2
@@ -1525,8 +1525,10 @@ static int scu_command(struct drxk_statedprintk (1 ,"\n" );if ((cmd ==0 ) || ((parameterLen >0 ) && (parameter ==NULL )) || - ((resultLen >0 ) && (result ==NULL ))) - goto error; + ((resultLen >0 ) && (result ==NULL ))) { +printk (KERN_ERR "drxk: Error %d on %s\n" , status, __func__); +return status; + }mutex_lock (&state->mutex);
Greg KH
maintainerPATCH 27/62 media: dvb_frontend: Fix a regression when switching back to DVB-S
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mauro Carvalho Chehab <[email protected]>
commit 3626479e482aa3247aac03724094ba6c13ea1e46 upstream.
There are some softwares (Kaffeine and likely xine) that uses a DVBv5 call to switch to DVB-S2, but expects that a DVBv3 call to switch back to DVB-S. Well, this is not right, as a DVBv3 call doesn't know anything about delivery systems.
However, as, by accident, this used to work, we need to restore its behavior, in order to avoid regressions with those softwares.
Reported on this Fedora 16 bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=812895
--- drivers/media/dvb/dvb-core/dvb_frontend.c | 25 ++++++++++++++++++++++++- 1 file changed, 24 insertions(+), 1 deletion(-)
drivers/media/dvb/dvb-core/dvb_frontend.c +24 -1
@@ -1446,6 +1446,28 @@ static int set_delivery_system(struct dv __func__);return -EINVAL ; } +/* +* Get a delivery system that is compatible with DVBv3 +* NOTE: in order for this to work with softwares like Kaffeine that +* uses a DVBv5 call for DVB-S2 and a DVBv3 call to go back to +* DVB-S, drivers that support both should put the SYS_DVBS entry +* before the SYS_DVBS2, otherwise it won't switch back to DVB-S. +* The real fix is that userspace applications should not use DVBv3 +* and not trust on calling FE_SET_FRONTEND to switch the delivery +* system. +*/ + ncaps =0 ; +while (fe->ops.delsys[ncaps] && ncaps <MAX_DELSYS ) { +if (fe->ops.delsys[ncaps] == desired_system) { + delsys = desired_system; +break ; + } + ncaps++; + } +if (delsys ==SYS_UNDEFINED ) { +dprintk ("%s() Couldn't find a delivery system that matches %d\n" , + __func__, desired_system); + } }else {/* * This is a DVBv5 call. So, it likely knows the supported
@@ -1494,9 +1516,10 @@ static int set_delivery_system(struct dv __func__);return -EINVAL ; } - c->delivery_system = delsys; } + c->delivery_system = delsys; +/* * The DVBv3 or DVBv5 call is requesting a different system. So, * emulation is needed.
Greg KH
maintainerPATCH 28/62 cfg80211: fix interface combinations check.
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lukasz Kucharczyk <[email protected]>
commit e55a4046dab28c440c96890bdddcf02dc8981f2d upstream.
--- net/wireless/util.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/wireless/util.c +1 -1
@@ -988,7 +988,7 @@ int cfg80211_can_change_interface(structif (rdev->wiphy.software_iftypes &BIT (iftype))continue ;for (j =0 ; j < c->n_limits; j++) { -if (!(limits[j].types & iftype)) +if (!(limits[j].types &BIT (iftype)))continue ;if (limits[j].max < num[iftype]) goto cont;
Greg KH
maintainerPATCH 29/62 staging: r8712u: Fix regression caused by commit 8c213fa
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Larry Finger <[email protected]>
commit 2080913e017ab9f88379d93fd09546ad95faf87b upstream.
In commit 8c213fa "staging: r8712u: Use asynchronous firmware loading", the command to release the firmware was placed in the wrong routine.
In combination with the bug introduced in commit a5ee652 "staging: r8712u:
Interface-state not fully tracked", the driver attempts to upload firmware that had already been released. This bug is the source of one of the problems in https://bugs.archlinux.org/task/27996#comment89833.
--- drivers/staging/rtl8712/os_intfs.c | 3 --- drivers/staging/rtl8712/usb_intf.c | 5 +++++ 2 files changed, 5 insertions(+), 3 deletions(-)
drivers/staging/rtl8712/os_intfs.c +0 -3
@@ -476,9 +476,6 @@ static int netdev_close(struct net_devicr8712_free_assoc_resources (padapter);/*s2-4.*/ r8712_free_network_queue (padapter); -release_firmware (padapter->fw); -/* never exit with a firmware callback pending */ -wait_for_completion (&padapter->rtl8712_fw_ready);return 0 ; }
drivers/staging/rtl8712/usb_intf.c +5 -0
@@ -30,6 +30,7 @@#include <linux/usb.h> #include <linux/module.h> +#include <linux/firmware.h> #include "osdep_service.h" #include "drv_types.h"
@@ -621,6 +622,10 @@ static void r871xu_dev_remove(struct usbstruct _adapter *padapter =netdev_priv (pnetdev);struct usb_device *udev =interface_to_usbdev (pusb_intf); +if (padapter->fw_found) +release_firmware (padapter->fw); +/* never exit with a firmware callback pending */ +wait_for_completion (&padapter->rtl8712_fw_ready);usb_set_intfdata (pusb_intf,NULL );if (padapter) {if (drvpriv.drv_registered == true)
Greg KH
maintainerPATCH 30/62 Fix modpost failures in fedora 17
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Miller <[email protected]>
commit e88aa7bbbe3046a125ea1936b16bb921cc9c6349 upstream.
The symbol table on x86-64 starts to have entries that have names like:
_GLOBAL__sub_I_65535_0___mod_x86cpu_device_table
They are of type STT_FUNCTION and this one had a length of 18. This matched the device ID validation logic and it barfed because the length did not meet the device type's criteria.
--------------------
FATAL: arch/x86/crypto/aesni-intel: sizeof(struct x86cpu_device_id)=16 is not a modulo of the size of section __mod_x86cpu_device_table=18. Fix definition of struct x86cpu_device_id in mod_devicetable.h
--------------------
These are some kind of compiler tool internal stuff being emitted and not something we want to inspect in modpost's device ID table validation code.
So skip the symbol if it is not of type STT_OBJECT.
--- scripts/mod/file2alias.c | 4 ++++ 1 file changed, 4 insertions(+)
scripts/mod/file2alias.c +4 -0
@@ -1075,6 +1075,10 @@ void handle_moddevtable(struct module *mif (!sym->st_shndx ||get_secindex (info, sym) >= info->num_sections)return ; +/* We're looking for an object */ +if (ELF_ST_TYPE (sym->st_info) !=STT_OBJECT ) +return ; +/* All our symbols are of form <prefix>__mod_XXX_device_table. */ name =strstr (symname,"__mod_" );if (!name)
Re: [ 30/62] Fix modpost failures in fedora 17
Quoted 1 line · Greg KH
3.3-stable review patch.
[...]
Quoted 6 lines
commit
e88aa7bbbe3046a125ea1936b16bb921cc9c6349upstream.The symbol table on x86-64 starts to have entries that have names like:
_GLOBAL__sub_I_65535_0___mod_x86cpu_device_table
[...]
Quoted 1 line
FATAL:
arch/x86/crypto/aesni-intel:sizeof(struct x86cpu_device_id)=16 is not a modulo of the size of section __mod_x86cpu_device_table=18.
I haven't tested this, but I suspect 3.0.y has the same problem --- v3.3-rc1~66^2~12 ("modpost: use a table rather than a giant if/else statement") just clarified the code a little and does not seem to have gone wrong.
In other words, the conflict encountered when applying this to 3.0.y looks like a textual and not a meaningful one. Backport follows.
-- >8 --
From: David Miller <[email protected]>
Date: Thu, 12 Apr 2012 14:37:30 -0400
commit e88aa7bbbe3046a125ea1936b16bb921cc9c6349 upstream.
The symbol table on x86-64 starts to have entries that have names like:
_GLOBAL__sub_I_65535_0___mod_x86cpu_device_table
They are of type STT_FUNCTION and this one had a length of 18. This matched the device ID validation logic and it barfed because the length did not meet the device type's criteria.
--------------------
FATAL: arch/x86/crypto/aesni-intel: sizeof(struct x86cpu_device_id)=16 is not a modulo of the size of section __mod_x86cpu_device_table=18. Fix definition of struct x86cpu_device_id in mod_devicetable.h
--------------------
These are some kind of compiler tool internal stuff being emitted and not something we want to inspect in modpost's device ID table validation code.
So skip the symbol if it is not of type STT_OBJECT.
---
Thanks,
Jonathan
scripts/mod/file2alias.c | 4 ++++ 1 file changed, 4 insertions(+)
scripts/mod/file2alias.c +4 -0
@@ -905,6 +905,10 @@ void handle_moddevtable(struct module *mod, struct elf_info *info,if (!sym->st_shndx ||get_secindex (info, sym) >= info->num_sections)return ; +/* We're looking for an object */ +if (ELF_ST_TYPE (sym->st_info) !=STT_OBJECT ) +return ; +/* Handle all-NULL symbols allocated into .bss */ if (info->sechdrs[get_secindex (info, sym)].sh_type &SHT_NOBITS ) { zeros =calloc (1 , sym->st_size);
Signature · 1 line
1.7.10
David Miller
maintainerRe: [ 30/62] Fix modpost failures in fedora 17
From: Jonathan Nieder <[email protected]>
Date: Wed, 25 Apr 2012 19:41:32 -0500
Quoted 7 lines
I haven't tested this, but I suspect 3.0.y has the same problem --- v3.3-rc1~66^2~12 ("modpost: use a table rather than a giant if/else statement") just clarified the code a little and does not seem to have gone wrong.
In other words, the conflict encountered when applying this to 3.0.y looks like a textual and not a meaningful one. Backport follows.
This is %100 correct.
Greg KH
maintainerRe: [ 30/62] Fix modpost failures in fedora 17
Quoted 8 lines · David Miller
From: Jonathan Nieder <[email protected]>
Date: Wed, 25 Apr 2012 19:41:32 -0500Quoted 5 lines
I haven't tested this, but I suspect 3.0.y has the same problem --- v3.3-rc1~66^2~12 ("modpost: use a table rather than a giant if/else statement") just clarified the code a little and does not seem to have gone wrong.
Quoted 4 lines
Quoted 2 lines
In other words, the conflict encountered when applying this to 3.0.y looks like a textual and not a meaningful one. Backport follows.
This is %100 correct.
Great, now applied.
Greg KH
maintainerPATCH 31/62 mm: fix s390 BUG by __set_page_dirty_no_writeback on swap
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hugh Dickins <[email protected]>
commit aca50bd3b4c4bb5528a1878158ba7abce41de534 upstream.
Mel reports a BUG_ON(slot == NULL) in radix_tree_tag_set() on s390 3.0.13: called from __set_page_dirty_nobuffers() when page_remove_rmap() tries to transfer dirty flag from s390 storage key to struct page and radix_tree.
That would be because of reclaim's shrink_page_list() calling add_to_swap() on this page at the same time: first PageSwapCache is set (causing page_mapping(page) to appear as &swapper_space), then page->private set, then tree_lock taken, then page inserted into radix_tree - so there's an interval before taking the lock when the radix_tree slot is empty.
We could fix this by moving __add_to_swap_cache()'s spin_lock_irq up before the SetPageSwapCache. But a better fix is simply to do what's five years overdue: Ken Chen introduced __set_page_dirty_no_writeback() (if !PageDirty TestSetPageDirty) for tmpfs to skip all the radix_tree overhead, and swap is just the same - it ignores the radix_tree tag, and does not participate in dirty page accounting, so should be using __set_page_dirty_no_writeback() too.
s390 testing now confirms that this does indeed fix the problem.
--- mm/swap_state.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
mm/swap_state.c +1 -1
@@ -26,7 +26,7 @@*/ static const struct address_space_operations swap_aops = { .writepage = swap_writepage, - .set_page_dirty = __set_page_dirty_nobuffers, + .set_page_dirty = __set_page_dirty_no_writeback, .migratepage = migrate_page, };
Greg KH
maintainerPATCH 32/62 md: dont call ->add_disk unless there is good reason.
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: NeilBrown <[email protected]>
commit ed209584c38fb74b7eecc03e5b1bfe674e591bd8 upstream.
Commit 7bfec5f35c68121e7b18
md/raid5: If there is a spare and a want_replacement device, start replacement.
cause md_check_recovery to call ->add_disk much more often. Instead of only when the array is degraded, it is now called whenever md_check_recovery finds anything useful to do, which includes updating the metadata for clean<->dirty transition.
This causes unnecessary work, and causes info messages from ->add_disk to be reported much too often.
So refine md_check_recovery to only do any actual recovery checking (including ->add_disk) if MD_RECOVERY_NEEDED is set.
This fix is suitable for 3.3.y:
--- drivers/md/md.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/md/md.c +2 -2
@@ -7580,14 +7580,14 @@ void md_check_recovery(struct mddev *mdd* any transients in the value of "sync_action". */ set_bit (MD_RECOVERY_RUNNING , &mddev->recovery); -clear_bit (MD_RECOVERY_NEEDED , &mddev->recovery);/* Clear some bits that don't mean anything, but * might be left set */ clear_bit (MD_RECOVERY_INTR , &mddev->recovery);clear_bit (MD_RECOVERY_DONE , &mddev->recovery); -if (test_bit (MD_RECOVERY_FROZEN , &mddev->recovery)) +if (!test_and_clear_bit (MD_RECOVERY_NEEDED , &mddev->recovery) || +test_bit (MD_RECOVERY_FROZEN , &mddev->recovery)) goto unlock;/* no recovery is running. * remove any failed drives, then
Greg KH
maintainerPATCH 33/62 md: fix possible corruption of array metadata on shutdown.
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: NeilBrown <[email protected]>
commit 30b8aa9172dfeaac6d77897c67ee9f9fc574cdbb upstream.
commit c744a65c1e2d59acc54333ce8
md: don't set md arrays to readonly on shutdown.
removed the possibility of a 'BUG' when data is written to an array that has just been switched to read-only, but also introduced the possibility that the array metadata could be corrupted.
If, when md_notify_reboot gets the mddev lock, the array is in a state where it is assembled but hasn't been started (as can happen if the personality module is not available, or in other unusual situations), then incorrect metadata will be written out making it impossible to re-assemble the array.
So only call __md_stop_writes() if the array has actually been activated.
This patch is needed for any stable kernel which has had the above commit applied.
--- drivers/md/md.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/md/md.c +2 -1
@@ -8160,7 +8160,8 @@ static int md_notify_reboot(struct notiffor_each_mddev (mddev, tmp) {if (mddev_trylock (mddev)) { -__md_stop_writes (mddev); +if (mddev->pers) +__md_stop_writes (mddev); mddev->safemode =2 ;mddev_unlock (mddev); }
Greg KH
maintainerPATCH 34/62 jbd2: use GFP_NOFS for blkdev_issue_flush
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shaohua Li <[email protected]>
commit 99aa78466777083255b876293e9e83dec7cd809a upstream.
flush request is issued in transaction commit code path, so looks using GFP_KERNEL to allocate memory for flush request bio falls into the classic deadlock issue. I saw btrfs and dm get it right, but ext4, xfs and md are using GFP.
--- fs/jbd2/commit.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
fs/jbd2/commit.c +2 -2
@@ -689,7 +689,7 @@ start_journal_io:if (commit_transaction->t_need_data_flush && (journal->j_fs_dev != journal->j_dev) && (journal->j_flags &JBD2_BARRIER )) -blkdev_issue_flush (journal->j_fs_dev,GFP_KERNEL ,NULL ); +blkdev_issue_flush (journal->j_fs_dev,GFP_NOFS ,NULL );/* Done it all: now write the commit record asynchronously. */ if (JBD2_HAS_INCOMPAT_FEATURE(journal,
@@ -825,7 +825,7 @@ wait_for_iobuf:if (JBD2_HAS_INCOMPAT_FEATURE (journal,JBD2_FEATURE_INCOMPAT_ASYNC_COMMIT ) && journal->j_flags &JBD2_BARRIER ) { -blkdev_issue_flush (journal->j_dev,GFP_KERNEL ,NULL ); +blkdev_issue_flush (journal->j_dev,GFP_NOFS ,NULL ); }if (err)
Greg KH
maintainerPATCH 35/62 USB: serial: cp210x: Fixed usb_control_msg timeout values
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yuri Matylitski <[email protected]>
commit 2d5733fcd33dd451022d197cb6b476e970519ca7 upstream.
Fixed too small hardcoded timeout values for usb_control_msg in driver for SiliconLabs cp210x-based usb-to-serial adapters. Replaced with USB_CTRL_GET_TIMEOUT/USB_CTRL_SET_TIMEOUT.
--- drivers/usb/serial/cp210x.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)
drivers/usb/serial/cp210x.c +6 -3
@@ -285,7 +285,8 @@ static int cp210x_get_config(struct usb_/* Issue the request, attempting to read 'size' bytes */ result =usb_control_msg (serial->dev,usb_rcvctrlpipe (serial->dev,0 ), request,REQTYPE_DEVICE_TO_HOST ,0x0000 , - port_priv->bInterfaceNumber, buf, size,300 ); + port_priv->bInterfaceNumber, buf, size, +USB_CTRL_GET_TIMEOUT );/* Convert data into an array of integers */ for (i =0 ; i < length; i++)
@@ -338,12 +339,14 @@ static int cp210x_set_config(struct usb_ result =usb_control_msg (serial->dev,usb_sndctrlpipe (serial->dev,0 ), request,REQTYPE_HOST_TO_DEVICE ,0x0000 , - port_priv->bInterfaceNumber, buf, size,300 ); + port_priv->bInterfaceNumber, buf, size, +USB_CTRL_SET_TIMEOUT ); }else { result =usb_control_msg (serial->dev,usb_sndctrlpipe (serial->dev,0 ), request,REQTYPE_HOST_TO_DEVICE , data[0 ], - port_priv->bInterfaceNumber,NULL ,0 ,300 ); + port_priv->bInterfaceNumber,NULL ,0 , +USB_CTRL_SET_TIMEOUT ); }kfree (buf);
Greg KH
maintainerPATCH 36/62 pch_uart: Fix dma channel unallocated issue
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tomoya MORINAGA <[email protected]>
commit af6d17cdc8c89aeb3101f0d27cd32fc0592b40b2 upstream.
This driver anticipates pch_uart_verify_port() is not called during installation.
However, actually pch_uart_verify_port() is called during installation.
As a result, memory access violation occurs like below.
0. initial value: use_dma=0
1. starup()
- dma channel is not allocated because use_dma=0
2. pch_uart_verify_port()
- Set use_dma=1
3. UART processing acts DMA mode because use_dma=1
- memory access violation occurs!
This patch fixes the issue.
Solution:
Whenever pch_uart_verify_port() is called and then dma channel is not allocated, the channel should be allocated.
--- drivers/tty/serial/pch_uart.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/tty/serial/pch_uart.c +3 -1
@@ -1366,9 +1366,11 @@ static int pch_uart_verify_port(struct u __func__);return -EOPNOTSUPP ;#endif - priv->use_dma =1 ; priv->use_dma_flag =1 ;dev_info (priv->port.dev,"PCH UART : Use DMA Mode\n" ); +if (!priv->use_dma) +pch_request_dma (port); + priv->use_dma =1 ; }return 0 ;
Greg KH
maintainerPATCH 37/62 drivers/tty/amiserial.c: add missing tty_unlock
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Julia Lawall <[email protected]>
commit d3a7b83f865b46bb7b5e1ed18a129ce1af349db4 upstream.
tty_unlock is used on all other exits from the function.
--- drivers/tty/amiserial.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/tty/amiserial.c +3 -1
@@ -1113,8 +1113,10 @@ static int set_serial_info(struct async_ (new_serial.close_delay != state->close_delay) || (new_serial.xmit_fifo_size != state->xmit_fifo_size) || ((new_serial.flags & ~ASYNC_USR_MASK) != - (state->flags & ~ASYNC_USR_MASK))) + (state->flags & ~ASYNC_USR_MASK))) { +tty_unlock ();return -EPERM ; + } state->flags = ((state->flags & ~ASYNC_USR_MASK ) | (new_serial.flags &ASYNC_USR_MASK )); info->flags = ((info->flags & ~ASYNC_USR_MASK) |
Greg KH
maintainerPATCH 38/62 USB: sierra: avoid QMI/wwan interface on MC77xx
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bjørn Mork <[email protected]>
commit 749541d19e70905e3971f2a08335a206a98e4d0c upstream.
These devices have a number of non serial interfaces as well. Use the existing "Direct IP" blacklist to prevent binding to interfaces which are handled by other drivers.
We also extend the "Direct IP" blacklist with with interfaces only seen in "QMI" mode, assuming that these devices use the same interface numbers for serial interfaces both in "Direct IP" and in "QMI" mode.
--- drivers/usb/serial/sierra.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/usb/serial/sierra.c +4 -2
@@ -221,7 +221,7 @@ static const struct sierra_iface_info ty };/* 'blacklist' of interfaces not served by this driver */ -static const u8 direct_ip_non_serial_ifaces[] = {7 ,8 ,9 ,10 ,11 }; +static const u8 direct_ip_non_serial_ifaces[] = {7 ,8 ,9 ,10 ,11 ,19 ,20 };static const struct sierra_iface_info direct_ip_interface_blacklist = { .infolen =ARRAY_SIZE (direct_ip_non_serial_ifaces), .ifaceinfo = direct_ip_non_serial_ifaces,
@@ -289,7 +289,6 @@ static const struct usb_device_id id_tab { USB_DEVICE(0x1199, 0x6856) }, /* Sierra Wireless AirCard 881 U */ { USB_DEVICE(0x1199, 0x6859) }, /* Sierra Wireless AirCard 885 E */ { USB_DEVICE(0x1199, 0x685A) }, /* Sierra Wireless AirCard 885 E */ - { USB_DEVICE(0x1199, 0x68A2) }, /* Sierra Wireless MC7710 *//* Sierra Wireless C885 */ { USB_DEVICE_AND_INTERFACE_INFO(0x1199, 0x6880, 0xFF, 0xFF, 0xFF)},/* Sierra Wireless C888, Air Card 501, USB 303, USB 304 */
@@ -299,6 +298,9 @@ static const struct usb_device_id id_tab/* Sierra Wireless HSPA Non-Composite Device */ { USB_DEVICE_AND_INTERFACE_INFO(0x1199, 0x6892, 0xFF, 0xFF, 0xFF)}, { USB_DEVICE(0x1199, 0x6893) }, /* Sierra Wireless Device */ + { USB_DEVICE(0x1199, 0x68A2), /* Sierra Wireless MC77xx in QMI mode */ + .driver_info = (kernel_ulong_t)&direct_ip_interface_blacklist + }, { USB_DEVICE(0x1199, 0x68A3), /* Sierra Wireless Direct IP modems */ .driver_info = (kernel_ulong_t)&direct_ip_interface_blacklist },
Greg KH
maintainerPATCH 39/62 EHCI: fix criterion for resuming the root hub
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alan Stern <[email protected]>
commit dc75ce9d929aabeb0843a6b1a4ab320e58ba1597 upstream.
This patch (as1542) changes the criterion ehci-hcd uses to tell when it needs to resume the controller's root hub. A resume is needed when a port status change is detected, obviously, but only if the root hub is currently suspended.
Right now the driver tests whether the root hub is running, and that is not the correct test. In particular, if the controller has died then the root hub should not be restarted. In addition, some buggy hardware occasionally requires the root hub to be running and sending out SOF packets even while it is nominally supposed to be suspended.
In the end, the test needs to be changed. Rather than checking whether the root hub is currently running, the driver will now check whether the root hub is currently suspended. This will yield the correct behavior in all cases.
--- drivers/usb/host/ehci-hcd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/host/ehci-hcd.c +1 -1
@@ -909,7 +909,7 @@ static irqreturn_t ehci_irq (struct usb_ pcd_status = status;/* resume root hub? */ -if (!(cmd &CMD_RUN )) +if (ehci->rh_state ==EHCI_RH_SUSPENDED )usb_hcd_resume_root_hub (hcd);/* get per-port change detect bits */
Re: [ 39/62] EHCI: fix criterion for resuming the root hub
Hi Greg,
Quoted 1 line · Greg KH
3.3-stable review patch. If anyone has any objections, please let me know.
[...]
Quoted 6 lines
commit
dc75ce9d929aabeb0843a6b1a4ab320e58ba1597upstream.This patch (as1542) changes the criterion ehci-hcd uses to tell when it needs to resume the controller's root hub. A resume is needed when a port status change is detected, obviously, but only if the root hub is currently suspended.
Here's a blind backport to 3.0-stable (for next week, perhaps) that accounts for the lack of v3.2-rc1~183^2~179^2~19 ("USB: EHCI: remove usages of hcd->state", 2011-08-18).
Thanks,
Jonathan
-- >8 --
From: Alan Stern <[email protected]>
Date: Tue, 17 Apr 2012 15:24:15 -0400
commit dc75ce9d929aabeb0843a6b1a4ab320e58ba1597 upstream.
This patch (as1542) changes the criterion ehci-hcd uses to tell when it needs to resume the controller's root hub. A resume is needed when a port status change is detected, obviously, but only if the root hub is currently suspended.
Right now the driver tests whether the root hub is running, and that is not the correct test. In particular, if the controller has died then the root hub should not be restarted. In addition, some buggy hardware occasionally requires the root hub to be running and sending out SOF packets even while it is nominally supposed to be suspended.
In the end, the test needs to be changed. Rather than checking whether the root hub is currently running, the driver will now check whether the root hub is currently suspended. This will yield the correct behavior in all cases.
--- drivers/usb/host/ehci-hcd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/host/ehci-hcd.c +1 -1
@@ -860,7 +860,7 @@ static irqreturn_t ehci_irq (struct usb_hcd *hcd) pcd_status = status;/* resume root hub? */ -if (!(cmd &CMD_RUN )) +if (hcd->state ==HC_STATE_SUSPENDED )usb_hcd_resume_root_hub (hcd);/* get per-port change detect bits */
Signature · 1 line
1.7.10
Re: [ 39/62] EHCI: fix criterion for resuming the root hub
Quoted 8 lines · Jonathan Nieder
Hi Greg,
Quoted 1 line · Greg KH
3.3-stable review patch. If anyone has any objections, please let me know.
[...]
Quoted 2 lines
commit
dc75ce9d929aabeb0843a6b1a4ab320e58ba1597upstream.
Quoted 8 lines
Quoted 4 lines
This patch (as1542) changes the criterion ehci-hcd uses to tell when it needs to resume the controller's root hub. A resume is needed when a port status change is detected, obviously, but only if the root hub is currently suspended.
Here's a blind backport to 3.0-stable (for next week, perhaps) that accounts for the lack of v3.2-rc1~183^2~179^2~19 ("USB: EHCI: remove usages of
hcd->state", 2011-08-18).
Applied, thanks.
Greg KH
maintainerPATCH 40/62 EHCI: always clear the STS_FLR status bit
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alan Stern <[email protected]>
commit 2fbe2bf1fd37f9d99950bd8d8093623cf22cf08b upstream.
This patch (as1544) fixes a problem affecting some EHCI controllers. They can generate interrupts whenever the STS_FLR status bit is turned on, even though that bit is masked out in the Interrupt Enable register.
Since the driver doesn't use STS_FLR anyway, the patch changes the interrupt routine to clear that bit whenever it is set, rather than leaving it alone.
--- drivers/usb/host/ehci-hcd.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
drivers/usb/host/ehci-hcd.c +6 -1
@@ -857,8 +857,13 @@ static irqreturn_t ehci_irq (struct usb_ goto dead; } +/* +* We don't use STS_FLR, but some controllers don't like it to +* remain on, so mask it out along with the other status bits. +*/ + masked_status = status & (INTR_MASK |STS_FLR ); +/* Shared IRQ? */ - masked_status = status &INTR_MASK ;if (!masked_status ||unlikely (ehci->rh_state ==EHCI_RH_HALTED )) {spin_unlock (&ehci->lock);return IRQ_NONE ;
Greg KH
maintainerPATCH 41/62 USB: fix deadlock in bConfigurationValue attribute method
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alan Stern <[email protected]>
commit 8963c487a80b4688c9e68dcc504a90074aacc145 upstream.
This patch (as154) fixes a self-deadlock that occurs when userspace writes to the bConfigurationValue sysfs attribute for a hub with children. The task tries to lock the bandwidth_mutex at a time when it already owns the lock:
The attribute's method calls usb_set_configuration(), which calls usb_disable_device() with the bandwidth_mutex held.
usb_disable_device() unregisters the existing interfaces, which causes the hub driver to be unbound.
The hub_disconnect() routine calls hub_quiesce(), which calls usb_disconnect() for each of the hub's children.
usb_disconnect() attempts to acquire the bandwidth_mutex around a call to usb_disable_device().
The solution is to make usb_disable_device() acquire the mutex for itself instead of requiring the caller to hold it. Then the mutex can cover only the bandwidth deallocation operation and not the region where the interfaces are unregistered.
This has the potential to change system behavior slightly when a config change races with another config or altsetting change. Some of the bandwidth released from the old config might get claimed by the other config or altsetting, make it impossible to restore the old config in case of a failure. But since we don't try to recover from config-change failures anyway, this doesn't matter.
[This should be marked for stable kernels that contain the commit fccf4e86200b8f5edd9a65da26f150e32ba79808 "USB: Free bandwidth when usb_disable_device is called."
That commit was marked for stable kernels as old as 2.6.32.]
--- drivers/usb/core/hub.c | 3 --- drivers/usb/core/message.c | 6 +++--- 2 files changed, 3 insertions(+), 6 deletions(-)
drivers/usb/core/hub.c +0 -3
@@ -1643,7 +1643,6 @@ void usb_disconnect(struct usb_device ** {struct usb_device *udev = *pdev;int i; -struct usb_hcd *hcd =bus_to_hcd (udev->bus);/* mark the device as inactive, so any further urb submissions for * this device (and any of its children) will fail immediately.
@@ -1666,9 +1665,7 @@ void usb_disconnect(struct usb_device *** so that the hardware is now fully quiesced. */ dev_dbg (&udev->dev,"unregistering device\n" ); -mutex_lock (hcd->bandwidth_mutex);usb_disable_device (udev,0 ); -mutex_unlock (hcd->bandwidth_mutex);usb_hcd_synchronize_unlinks (udev);usb_remove_ep_devs (&udev->ep0);
drivers/usb/core/message.c +3 -3
@@ -1136,8 +1136,6 @@ void usb_disable_interface(struct usb_de* Deallocates hcd/hardware state for the endpoints (nuking all or most * pending urbs) and usbcore state for the interfaces, so that usbcore * must usb_set_configuration() before any interfaces could be used. -* -* Must be called with hcd->bandwidth_mutex held. */ void usb_disable_device (struct usb_device *dev,int skip_ep0) {
@@ -1190,7 +1188,9 @@ void usb_disable_device(struct usb_devicusb_disable_endpoint (dev, i +USB_DIR_IN , false); }/* Remove endpoints from the host controller internal state */ +mutex_lock (hcd->bandwidth_mutex);usb_hcd_alloc_bandwidth (dev,NULL ,NULL ,NULL ); +mutex_unlock (hcd->bandwidth_mutex);/* Second pass: remove endpoint pointers */ }for (i = skip_ep0; i <16 ; ++i) {
@@ -1750,7 +1750,6 @@ free_interfaces:/* if it's already configured, clear out old state first. * getting rid of old interfaces means unbinding their drivers. */ -mutex_lock (hcd->bandwidth_mutex);if (dev->state !=USB_STATE_ADDRESS )usb_disable_device (dev,1 );/* Skip ep0 */
@@ -1763,6 +1762,7 @@ free_interfaces:* host controller will not allow submissions to dropped endpoints. If * this call fails, the device state is unchanged. */ +mutex_lock (hcd->bandwidth_mutex); ret =usb_hcd_alloc_bandwidth (dev, cp,NULL ,NULL );if (ret <0 ) {mutex_unlock (hcd->bandwidth_mutex);
Greg KH
maintainerPATCH 42/62 usb: gadget: udc-core: stop UDC on device-initiated disconnect
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Felipe Balbi <[email protected]>
commit 6d258a4c42089229b855fd706622029decf316d6 upstream.
When we want to do device-initiated disconnect, let's make sure we stop the UDC in order to e.g. allow lower power states to be achieved by turning off unnecessary clocks and/or stoping PHYs.
When reconnecting, call ->udc_start() again to make sure UDC is reinitialized.
--- drivers/usb/gadget/udc-core.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/usb/gadget/udc-core.c +4 -0
@@ -359,8 +359,12 @@ static ssize_t usb_udc_softconn_store(st struct usb_udc *udc = container_of(dev, struct usb_udc, dev);if (sysfs_streq (buf,"connect" )) { +if (udc_is_newstyle (udc)) +usb_gadget_udc_start (udc->gadget, udc->driver);usb_gadget_connect (udc->gadget); }else if (sysfs_streq (buf,"disconnect" )) { +if (udc_is_newstyle (udc)) +usb_gadget_udc_stop (udc->gadget, udc->driver);usb_gadget_disconnect (udc->gadget); }else {dev_err (dev,"unsupported command '%s'\n" , buf);
Greg KH
maintainerPATCH 43/62 usb: gadget: udc-core: fix asymmetric calls in remove_driver
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kishon Vijay Abraham I <[email protected]>
commit 8ae8090c82eb407267001f75b3d256b3bd4ae691 upstream.
During modprobe of gadget driver, pullup is called after udc_start. In order to make the exit path symmetric when removing a gadget driver, call pullup before ->udc_stop.
This is needed to avoid issues with PM where udc_stop disables the module completely (put IP in reset state, cut functional and interface clocks, and so on), which prevents us from accessing the IP's address space, thus creating the possibility of an abort exception when we try to access IP's address space after clocks are off.
--- drivers/usb/gadget/udc-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/gadget/udc-core.c +1 -1
@@ -212,8 +212,8 @@ static void usb_gadget_remove_driver(strif (udc_is_newstyle (udc)) { udc->driver->disconnect (udc->gadget); udc->driver->unbind (udc->gadget); -usb_gadget_udc_stop (udc->gadget, udc->driver);usb_gadget_disconnect (udc->gadget); +usb_gadget_udc_stop (udc->gadget, udc->driver); }else {usb_gadget_stop (udc->gadget, udc->driver); }
Re: [ 43/62] usb: gadget: udc-core: fix asymmetric calls in remove_driver
Quoted 11 lines · Greg KH
3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kishon Vijay Abraham I <[email protected]>
commit
8ae8090c82eb407267001f75b3d256b3bd4ae691upstream.During modprobe of gadget driver, pullup is called after
udc_start. In order to make the exit path symmetric when removing a gadget driver, call pullup before ->udc_stop.
[...]
It looks like commit 6d258a4c42089229b855fd706622029decf316d6 (previous patch in this series!) added another case where the cleanup functions are called in the wrong order.
Ben.
Signature · 3 lines
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert CamusGreg KH
maintainerRe: [ 43/62] usb: gadget: udc-core: fix asymmetric calls in remove_driver
Quoted 9 lines · Ben Hutchings
Quoted 8 lines · Greg KH
3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kishon Vijay Abraham I <[email protected]>
commit
8ae8090c82eb407267001f75b3d256b3bd4ae691upstream.
Quoted 8 lines
Quoted 3 lines
During modprobe of gadget driver, pullup is called after
udc_start. In order to make the exit path symmetric when removing a gadget driver, call pullup before ->udc_stop.[...]
It looks like commit
6d258a4c42089229b855fd706622029decf316d6(previous patch in this series!) added another case where the cleanup functions are called in the wrong order.
Felipe? Any thoughts?
Re: [ 43/62] usb: gadget: udc-core: fix asymmetric calls in remove_driver
Quoted 13 lines · Greg KH
Quoted 12 lines · Ben Hutchings
Quoted 11 lines · Greg KH
3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kishon Vijay Abraham I <[email protected]>
commit
8ae8090c82eb407267001f75b3d256b3bd4ae691upstream.During modprobe of gadget driver, pullup is called after
udc_start. In order to make the exit path symmetric when removing a gadget driver, call pullup before ->udc_stop.
Quoted 7 lines
Quoted 5 lines
[...]
It looks like commit
6d258a4c42089229b855fd706622029decf316d6(previous patch in this series!) added another case where the cleanup functions are called in the wrong order.Felipe? Any thoughts?
oops, indeed. Will send a fix ASAP. Thanks for spotting that one.
Signature · 1 line
balbi
Greg KH
maintainerPATCH 44/62 usb: gadget: eliminate NULL pointer dereference (bugfix)
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andrzej Pietrasiewicz <[email protected]>
commit 92b0abf80c5c5f0e0d71d1309688a330fd74731b upstream.
usb: gadget: eliminate NULL pointer dereference (bugfix)
This patch fixes a bug which causes NULL pointer dereference in ffs_ep0_ioctl. The bug happens when the FunctionFS is not bound (either has not been bound yet or has been bound and then unbound) and can be reproduced with running the following commands:
$ insmod g_ffs.ko $ mount -t functionfs func /dev/usbgadget $ ./null
where null.c is:
#include <fcntl.h>
#include <linux/usb/functionfs.h>
int main(void)
{
int fd = open("/dev/usbgadget/ep0", O_RDWR);
ioctl(fd, FUNCTIONFS_CLEAR_HALT);
return 0;
}--- drivers/usb/gadget/f_fs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/gadget/f_fs.c +1 -1
@@ -712,7 +712,7 @@ static long ffs_ep0_ioctl(struct file *fif (code ==FUNCTIONFS_INTERFACE_REVMAP ) {struct ffs_function *func = ffs->func; ret = func ?ffs_func_revmap_intf (func, value) : -ENODEV ; - }else if (gadget->ops->ioctl) { + }else if (gadget && gadget->ops->ioctl) { ret = gadget->ops->ioctl (gadget, code, value); }else { ret = -ENOTTY ;
Greg KH
maintainerPATCH 45/62 usb: musb: omap: fix crash when musb glue (omap) gets initialized
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kishon Vijay Abraham I <[email protected]>
commit 3006dc8c627d738693e910c159630e4368c9e86c upstream.
pm_runtime_enable is being called after omap2430_musb_init. Hence pm_runtime_get_sync in omap2430_musb_init does not have any effect (does not enable clocks) resulting in a crash during register access. It is fixed here.
--- drivers/usb/musb/omap2430.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/usb/musb/omap2430.c +2 -2
@@ -451,14 +451,14 @@ static int __init omap2430_probe(struct goto err2; } +pm_runtime_enable (&pdev->dev); + ret =platform_device_add (musb);if (ret) {dev_err (&pdev->dev,"failed to register musb device\n" ); goto err2; } -pm_runtime_enable (&pdev->dev); -return 0 ; err2:
Re: [ 45/62] usb: musb: omap: fix crash when musb glue (omap) gets initialized
Quoted 24 lines · Greg KH
3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kishon Vijay Abraham I <[email protected]>
commit
3006dc8c627d738693e910c159630e4368c9e86cupstream.
pm_runtime_enableis being called afteromap2430_musb_init. Hencepm_runtime_get_syncinomap2430_musb_initdoes not have any effect (does not enable clocks) resulting in a crash during register access. It is fixed here.Signed-off-by Kishon Vijay Abraham I <[email protected]>Signed-off-by Felipe Balbi <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>--- drivers/usb/musb/omap2430.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/usb/musb/omap2430.c static int __init omap2430_probe(struct · line 458
Quoted 8 lines
drivers/usb/musb/omap2430.c +2
-0@@ -451,14 +451,14 @@ static int __init omap2430_probe(struct goto err2; } +pm_runtime_enable (&pdev->dev); + ret =platform_device_add (musb);if (ret) {dev_err (&pdev->dev,"failed to register musb device\n" );
This failure path now needs a call to pm_runtime_disable().
Ben.
Quoted 8 lines
drivers/usb/musb/omap2430.c +0
-2goto err2; } -pm_runtime_enable (&pdev->dev); -return 0 ; err2:
Signature · 3 lines
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert CamusGreg KH
maintainerPATCH 46/62 usb: musb: omap: fix the error check for pm_runtime_get_sync
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shubhrajyoti D <[email protected]>
commit ad579699c4f0274bf522a9252ff9b20c72197e48 upstream.
pm_runtime_get_sync returns a signed integer. In case of errors it returns a negative value. This patch fixes the error check by making it signed instead of unsigned thus preventing register access if get_sync_fails. Also passes the error cause to the debug message.
--- drivers/usb/musb/omap2430.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/usb/musb/omap2430.c +3 -2
@@ -281,7 +281,8 @@ static void musb_otg_notifier_work(strucstatic int omap2430_musb_init (struct musb *musb) { -u32 l, status =0 ; +u32 l; +int status =0 ;struct device *dev = musb->controller;struct musb_hdrc_platform_data *plat = dev->platform_data;struct omap_musb_board_data *data = plat->board_data;
@@ -300,7 +301,7 @@ static int omap2430_musb_init(struct mus status =pm_runtime_get_sync (dev);if (status <0 ) { -dev_err (dev,"pm_runtime_get_sync FAILED" ); +dev_err (dev,"pm_runtime_get_sync FAILED %d\n" , status); goto err1; }
Greg KH
maintainerPATCH 47/62 PCI: Add quirk for still enabled interrupts on Intel Sandy Bridge GPUs
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Jarosch <[email protected]>
commit f67fd55fa96f7d7295b43ffbc4a97d8f55e473aa upstream.
Some BIOS implementations leave the Intel GPU interrupts enabled, even though no one is handling them (f.e. i915 driver is never loaded). Additionally the interrupt destination is not set up properly and the interrupt ends up -somewhere-.
These spurious interrupts are "sticky" and the kernel disables the (shared) interrupt line after 100.000+ generated interrupts.
Fix it by disabling the still enabled interrupts. This resolves crashes often seen on monitor unplug.
Tested on the following boards:
- Intel DH61CR: Affected
- Intel DH67BL: Affected
- Intel S1200KP server board: Affected
- Asus P8H61-M LE: Affected, but system does not crash. Probably the IRQ ends up somewhere unnoticed.
According to reports on the net, the Intel DH61WW board is also affected.
Many thanks to Jesse Barnes from Intel for helping with the register configuration and to Intel in general for providing public hardware documentation.
--- drivers/pci/quirks.c | 34 ++++++++++++++++++++++++++++++++++ 1 file changed, 34 insertions(+)
drivers/pci/quirks.c +34 -0
@@ -2906,6 +2906,40 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_IDECLARE_PCI_FIXUP_HEADER (PCI_VENDOR_ID_INTEL ,0x65f9 , quirk_intel_mc_errata);DECLARE_PCI_FIXUP_HEADER (PCI_VENDOR_ID_INTEL ,0x65fa , quirk_intel_mc_errata); +/* +* Some BIOS implementations leave the Intel GPU interrupts enabled, +* even though no one is handling them (f.e. i915 driver is never loaded). +* Additionally the interrupt destination is not set up properly +* and the interrupt ends up -somewhere-. +* +* These spurious interrupts are "sticky" and the kernel disables +* the (shared) interrupt line after 100.000+ generated interrupts. +* +* Fix it by disabling the still enabled interrupts. +* This resolves crashes often seen on monitor unplug. +*/ +#define I915_DEIER_REG 0x4400c +static void __devinit disable_igfx_irq (struct pci_dev *dev) +{ +void __iomem *regs =pci_iomap (dev,0 ,0 ); +if (regs ==NULL ) { +dev_warn (&dev->dev,"igfx quirk: Can't iomap PCI device\n" ); +return ; + } + +/* Check if any interrupt line is still enabled */ +if (readl (regs +I915_DEIER_REG ) !=0 ) { +dev_warn (&dev->dev,"BIOS left Intel GPU interrupts enabled; " +"disabling\n" ); + +writel (0 , regs +I915_DEIER_REG ); + } + +pci_iounmap (dev, regs); +} +DECLARE_PCI_FIXUP_FINAL (PCI_VENDOR_ID_INTEL ,0x0102 , disable_igfx_irq); +DECLARE_PCI_FIXUP_FINAL (PCI_VENDOR_ID_INTEL ,0x010a , disable_igfx_irq); +static void pci_do_fixups (struct pci_dev *dev,struct pci_fixup *f,struct pci_fixup *end) {
Greg KH
maintainerPATCH 48/62 ext4: fix endianness breakage in ext4_split_extent_at()
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Al Viro <[email protected]>
commit af1584f570b19b0285e4402a0b54731495d31784 upstream.
->ee_len is __le16, so assigning cpu_to_le32() to it is going to do Bad Things(tm) on big-endian hosts...
--- fs/ext4/extents.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/ext4/extents.c +1 -1
@@ -2811,7 +2811,7 @@ static int ext4_split_extent_at(handle_tif (err) goto fix_extent_len;/* update the extent length and mark as initialized */ - ex->ee_len =cpu_to_le32 (ee_len); + ex->ee_len =cpu_to_le16 (ee_len);ext4_ext_try_to_merge (inode, path, ex); err =ext4_ext_dirty (handle, inode, path + depth); goto out;
Greg KH
maintainerPATCH 49/62 KVM: unmap pages from the iommu when slots are removed
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Williamson <[email protected]>
commit 32f6daad4651a748a58a3ab6da0611862175722f upstream.
We've been adding new mappings, but not destroying old mappings. This can lead to a page leak as pages are pinned using get_user_pages, but only unpinned with put_page if they still exist in the memslots list on vm shutdown. A memslot that is destroyed while an iommu domain is enabled for the guest will therefore result in an elevated page reference count that is never cleared.
Additionally, without this fix, the iommu is only programmed with the first translation for a gpa. This can result in peer-to-peer errors if a mapping is destroyed and replaced by a new mapping at the same gpa as the iommu will still be pointing to the original, pinned memory address.
--- include/linux/kvm_host.h | 6 ++++++ virt/kvm/iommu.c | 7 ++++++- virt/kvm/kvm_main.c | 5 +++-- 3 files changed, 15 insertions(+), 3 deletions(-)
include/linux/kvm_host.h +6 -0
@@ -593,6 +593,7 @@ void kvm_free_irq_source_id(struct kvm *#ifdef CONFIG_IOMMU_API int kvm_iommu_map_pages (struct kvm *kvm,struct kvm_memory_slot *slot); +void kvm_iommu_unmap_pages (struct kvm *kvm,struct kvm_memory_slot *slot);int kvm_iommu_map_guest (struct kvm *kvm);int kvm_iommu_unmap_guest (struct kvm *kvm); int kvm_assign_device(struct kvm *kvm,
@@ -606,6 +607,11 @@ static inline int kvm_iommu_map_pages(streturn 0 ; } +static inline void kvm_iommu_unmap_pages (struct kvm *kvm, +struct kvm_memory_slot *slot) +{ +} +static inline int kvm_iommu_map_guest (struct kvm *kvm) {return -ENODEV ;
virt/kvm/iommu.c +6 -1
@@ -310,6 +310,11 @@ static void kvm_iommu_put_pages(struct k } } +void kvm_iommu_unmap_pages (struct kvm *kvm,struct kvm_memory_slot *slot) +{ +kvm_iommu_put_pages (kvm, slot->base_gfn, slot->npages); +} +static int kvm_iommu_unmap_memslots (struct kvm *kvm) {int idx;
@@ -320,7 +325,7 @@ static int kvm_iommu_unmap_memslots(stru slots =kvm_memslots (kvm);kvm_for_each_memslot (memslot, slots) -kvm_iommu_put_pages (kvm, memslot->base_gfn, memslot->npages); +kvm_iommu_unmap_pages (kvm, memslot);srcu_read_unlock (&kvm->srcu, idx);
virt/kvm/kvm_main.c +3 -2
@@ -873,12 +873,13 @@ skip_lpage:if (r) goto out_free; -/* map the pages in iommu page table */ +/* map/unmap the pages in iommu page table */ if (npages) { r =kvm_iommu_map_pages (kvm, &new);if (r) goto out_free; - } + }else +kvm_iommu_unmap_pages (kvm, &old); r = -ENOMEM ; slots = kmemdup(kvm->memslots, sizeof(struct kvm_memslots),
Re: [ 49/62] KVM: unmap pages from the iommu when slots are removed
Hi,
Quoted 1 line · Greg KH
3.3-stable review patch.
[...]
Quoted 4 lines
commit
32f6daad4651a748a58a3ab6da0611862175722fupstream.We've been adding new mappings, but not destroying old mappings. This can lead to a page leak
Does 3.0.y need this? The patch does not apply as is to 3.0.y because the latter lacks v3.3-rc1~131^2~41 ("KVM: introduce kvm_for_each_memslot macro"), but a backport is straightforward.
Completely untested. Test results and other comments welcome.
-- >8 --
From: Alex Williamson <[email protected]>
Date: Wed, 11 Apr 2012 09:51:49 -0600
commit 32f6daad4651a748a58a3ab6da0611862175722f upstream.
We've been adding new mappings, but not destroying old mappings. This can lead to a page leak as pages are pinned using get_user_pages, but only unpinned with put_page if they still exist in the memslots list on vm shutdown. A memslot that is destroyed while an iommu domain is enabled for the guest will therefore result in an elevated page reference count that is never cleared.
Additionally, without this fix, the iommu is only programmed with the first translation for a gpa. This can result in peer-to-peer errors if a mapping is destroyed and replaced by a new mapping at the same gpa as the iommu will still be pointing to the original, pinned memory address.
--- include/linux/kvm_host.h | 6 ++++++ virt/kvm/iommu.c | 12 ++++++++---- virt/kvm/kvm_main.c | 5 +++-- 3 files changed, 17 insertions(+), 6 deletions(-)
include/linux/kvm_host.h +6 -0
@@ -554,6 +554,7 @@ void kvm_free_irq_source_id(struct kvm *kvm, int irq_source_id);#ifdef CONFIG_IOMMU_API int kvm_iommu_map_pages (struct kvm *kvm,struct kvm_memory_slot *slot); +void kvm_iommu_unmap_pages (struct kvm *kvm,struct kvm_memory_slot *slot);int kvm_iommu_map_guest (struct kvm *kvm);int kvm_iommu_unmap_guest (struct kvm *kvm); int kvm_assign_device(struct kvm *kvm,
@@ -567,6 +568,11 @@ static inline int kvm_iommu_map_pages(struct kvm *kvm,return 0 ; } +static inline void kvm_iommu_unmap_pages (struct kvm *kvm, +struct kvm_memory_slot *slot) +{ +} +static inline int kvm_iommu_map_guest (struct kvm *kvm) {return -ENODEV ;
virt/kvm/iommu.c +8 -4
@@ -285,6 +285,11 @@ static void kvm_iommu_put_pages(struct kvm *kvm, } } +void kvm_iommu_unmap_pages (struct kvm *kvm,struct kvm_memory_slot *slot) +{ +kvm_iommu_put_pages (kvm, slot->base_gfn, slot->npages); +} +static int kvm_iommu_unmap_memslots (struct kvm *kvm) {int i, idx;
@@ -293,10 +298,9 @@ static int kvm_iommu_unmap_memslots(struct kvm *kvm) idx =srcu_read_lock (&kvm->srcu); slots =kvm_memslots (kvm); -for (i =0 ; i < slots->nmemslots; i++) { -kvm_iommu_put_pages (kvm, slots->memslots[i].base_gfn, - slots->memslots[i].npages); - } +for (i =0 ; i < slots->nmemslots; i++) +kvm_iommu_unmap_pages (kvm, &slots->memslots[i]); +srcu_read_unlock (&kvm->srcu, idx);return 0 ;
virt/kvm/kvm_main.c +3 -2
@@ -796,12 +796,13 @@ skip_lpage:if (r) goto out_free; -/* map the pages in iommu page table */ +/* map/unmap the pages in iommu page table */ if (npages) { r =kvm_iommu_map_pages (kvm, &new);if (r) goto out_free; - } + }else +kvm_iommu_unmap_pages (kvm, &old); r = -ENOMEM ; slots =kzalloc (sizeof (struct kvm_memslots ),GFP_KERNEL );
Signature · 1 line
1.7.10
Alex Williamson
Acked-byRe: [ 49/62] KVM: unmap pages from the iommu when slots are removed
Quoted 4 lines · Jonathan Nieder
Hi,
Greg KH wrote:
Quoted 8 lines
Quoted 1 line
3.3-stable review patch.
[...]
Quoted 4 lines
commit
32f6daad4651a748a58a3ab6da0611862175722fupstream.We've been adding new mappings, but not destroying old mappings. This can lead to a page leak
Does 3.0.y need this?
Yep, same issues exists there.
Quoted 5 lines
The patch does not apply as is to 3.0.y because
the latter lacks v3.3-rc1~131^2~41 ("KVM: introducekvm_for_each_memslotmacro"), but a backport is straightforward.Completely untested. Test results and other comments welcome.
Looks correct to me.
Thanks,
Alex
Quoted 103 lines
-- >8 --
From: Alex Williamson <[email protected]>
Date: Wed, 11 Apr 2012 09:51:49 -0600commit
32f6daad4651a748a58a3ab6da0611862175722fupstream.We've been adding new mappings, but not destroying old mappings. This can lead to a page leak as pages are pinned using
get_user_pages, but only unpinned withput_pageif they still exist in the memslots list on vm shutdown. A memslot that is destroyed while an iommu domain is enabled for the guest will therefore result in an elevated page reference count that is never cleared.Additionally, without this fix, the iommu is only programmed with the first translation for a gpa. This can result in peer-to-peer errors if a mapping is destroyed and replaced by a new mapping at the same gpa as the iommu will still be pointing to the original, pinned memory address.
Signed-off-by Alex Williamson <[email protected]>Signed-off-by Marcelo Tosatti <[email protected]>Signed-off-by Jonathan Nieder <[email protected]>--- include/linux/kvm_host.h | 6 ++++++ virt/kvm/iommu.c | 12 ++++++++---- virt/kvm/kvm_main.c | 5 +++-- 3 files changed, 17 insertions(+), 6 deletions(-)include/linux/kvm_host.h +6
-0@@ -554,6 +554,7 @@ void kvm_free_irq_source_id(struct kvm *kvm, int irq_source_id);#ifdef CONFIG_IOMMU_API int kvm_iommu_map_pages (struct kvm *kvm,struct kvm_memory_slot *slot); +void kvm_iommu_unmap_pages (struct kvm *kvm,struct kvm_memory_slot *slot);int kvm_iommu_map_guest (struct kvm *kvm);int kvm_iommu_unmap_guest (struct kvm *kvm); int kvm_assign_device(struct kvm *kvm,@@ -567,6 +568,11 @@ static inline int kvm_iommu_map_pages(struct kvm *kvm,return 0 ; } +static inline void kvm_iommu_unmap_pages (struct kvm *kvm, +struct kvm_memory_slot *slot) +{ +} +static inline int kvm_iommu_map_guest (struct kvm *kvm) {return -ENODEV ;virt/kvm/iommu.c +8
-4@@ -285,6 +285,11 @@ static void kvm_iommu_put_pages(struct kvm *kvm, } } +void kvm_iommu_unmap_pages (struct kvm *kvm,struct kvm_memory_slot *slot) +{ +kvm_iommu_put_pages (kvm, slot->base_gfn, slot->npages); +} +static int kvm_iommu_unmap_memslots (struct kvm *kvm) {int i, idx;@@ -293,10 +298,9 @@ static int kvm_iommu_unmap_memslots(struct kvm *kvm) idx =srcu_read_lock (&kvm->srcu); slots =kvm_memslots (kvm); -for (i =0 ; i < slots->nmemslots; i++) { -kvm_iommu_put_pages (kvm, slots->memslots[i].base_gfn, - slots->memslots[i].npages); - } +for (i =0 ; i < slots->nmemslots; i++) +kvm_iommu_unmap_pages (kvm, &slots->memslots[i]); +srcu_read_unlock (&kvm->srcu, idx);return 0 ;virt/kvm/kvm_main.c +3
-2@@ -796,12 +796,13 @@ skip_lpage:if (r) goto out_free; -/* map the pages in iommu page table */ +/* map/unmap the pages in iommu page table */ if (npages) { r =kvm_iommu_map_pages (kvm, &new);if (r) goto out_free; - } + }else +kvm_iommu_unmap_pages (kvm, &old); r = -ENOMEM ; slots =kzalloc (sizeof (struct kvm_memslots ),GFP_KERNEL );
Greg KH
maintainerRe: [ 49/62] KVM: unmap pages from the iommu when slots are removed
Quoted 20 lines · Alex Williamson
Quoted 4 lines · Jonathan Nieder
Hi,
Greg KH wrote:
Quoted 8 lines
Quoted 1 line
3.3-stable review patch.
[...]
Quoted 4 lines
commit
32f6daad4651a748a58a3ab6da0611862175722fupstream.We've been adding new mappings, but not destroying old mappings. This can lead to a page leak
Does 3.0.y need this?
Yep, same issues exists there.
Quoted 4 lines
The patch does not apply as is to 3.0.y because
the latter lacks v3.3-rc1~131^2~41 ("KVM: introducekvm_for_each_memslotmacro"), but a backport is straightforward.
Quoted 5 lines
Quoted 1 line
Completely untested. Test results and other comments welcome.
Looks correct to me.
Acked-by Alex Williamson <[email protected]>
Wonderful, now applied.
Greg KH
maintainerPATCH 50/62 dell-laptop: add 3 machines that has touchpad LED
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: AceLan Kao <[email protected]>
commit 2a748853ca395c48ea75baa250f7cea6f0f23dbf upstream.
Add "Vostro 3555", "Inspiron N311z", and "Inspiron M5110" into quirks, so that they could have touchpad LED function work.
--- drivers/platform/x86/dell-laptop.c | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+)
drivers/platform/x86/dell-laptop.c +27 -0
@@ -184,6 +184,33 @@ static struct dmi_system_id __devinitdat }, .driver_data = &quirk_dell_vostro_v130, }, + { + .callback = dmi_matched, + .ident = "Dell Vostro 3555", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."), + DMI_MATCH(DMI_PRODUCT_NAME, "Vostro 3555"), + }, + .driver_data = &quirk_dell_vostro_v130, + }, + { + .callback = dmi_matched, + .ident = "Dell Inspiron N311z", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."), + DMI_MATCH(DMI_PRODUCT_NAME, "Inspiron N311z"), + }, + .driver_data = &quirk_dell_vostro_v130, + }, + { + .callback = dmi_matched, + .ident = "Dell Inspiron M5110", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."), + DMI_MATCH(DMI_PRODUCT_NAME, "Inspiron M5110"), + }, + .driver_data = &quirk_dell_vostro_v130, + }, }; static struct calling_interface_buffer *buffer;
Greg KH
maintainerPATCH 51/62 dell-laptop: touchpad LED should persist its status after S3
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: AceLan Kao <[email protected]>
commit 2d5de9e84928e35b4d9b46b4d8d5dcaac1cff1fa upstream.
Touchpad LED will not turn on after S3, it will make the touchpad status doesn't consist with the LED.
By adding one flag to let the LED device restore it's status.
--- drivers/platform/x86/dell-laptop.c | 1 + 1 file changed, 1 insertion(+)
drivers/platform/x86/dell-laptop.c +1 -0
@@ -642,6 +642,7 @@ static void touchpad_led_set(struct led_static struct led_classdev touchpad_led = { .name ="dell-laptop::touchpad" , .brightness_set = touchpad_led_set, + .flags =LED_CORE_SUSPENDRESUME , };static int __devinit touchpad_led_init (struct device *dev)
Greg KH
maintainerPATCH 52/62 Bluetooth: Add support for Atheros [04ca:3005]
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: AceLan Kao <[email protected]>
commit 55ed7d4d1469eafbe3ad7e8fcd44f5af27845a81 upstream.
Add another vendor specific ID for Atheros AR3012 device. This chip is wrapped by Lite-On Technology Corp.
output of usb-devices:
T: Bus=04 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=04ca ProdID=3005 Rev=00.02 S: Manufacturer=Atheros Communications S: Product=Bluetooth USB Host Controller S: SerialNumber=Alaska Day 2006 C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
--- drivers/bluetooth/ath3k.c | 2 ++ drivers/bluetooth/btusb.c | 1 + 2 files changed, 3 insertions(+)
drivers/bluetooth/ath3k.c +2 -0
@@ -74,6 +74,7 @@ static struct usb_device_id ath3k_table[ { USB_DEVICE(0x0CF3, 0x3004) }, { USB_DEVICE(0x0CF3, 0x311D) }, { USB_DEVICE(0x13d3, 0x3375) }, + { USB_DEVICE(0x04CA, 0x3005) },/* Atheros AR5BBU12 with sflash firmware */ { USB_DEVICE(0x0489, 0xE02C) },
@@ -92,6 +93,7 @@ static struct usb_device_id ath3k_blist_ { USB_DEVICE(0x0cf3, 0x3004), .driver_info = BTUSB_ATH3012 }, { USB_DEVICE(0x0cf3, 0x311D), .driver_info = BTUSB_ATH3012 }, { USB_DEVICE(0x13d3, 0x3375), .driver_info = BTUSB_ATH3012 }, + { USB_DEVICE(0x04ca, 0x3005), .driver_info = BTUSB_ATH3012 }, { } /* Terminating entry */ };
drivers/bluetooth/btusb.c +1 -0
@@ -130,6 +130,7 @@ static struct usb_device_id blacklist_ta { USB_DEVICE(0x0cf3, 0x3004), .driver_info = BTUSB_ATH3012 }, { USB_DEVICE(0x0cf3, 0x311d), .driver_info = BTUSB_ATH3012 }, { USB_DEVICE(0x13d3, 0x3375), .driver_info = BTUSB_ATH3012 }, + { USB_DEVICE(0x04ca, 0x3005), .driver_info = BTUSB_ATH3012 }, /* Atheros AR5BBU12 with sflash firmware */ { USB_DEVICE(0x0489, 0xe02c), .driver_info = BTUSB_IGNORE },
Greg KH
maintainerPATCH 53/62 nfsd: fix b0rken error value for setattr on read-only mount
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Al Viro <[email protected]>
commit 96f6f98501196d46ce52c2697dd758d9300c63f5 upstream.
..._want_write() returns -EROFS on failure, _not_ an NFS error value.
--- fs/nfsd/nfs4proc.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
fs/nfsd/nfs4proc.c +4 -3
@@ -826,6 +826,7 @@ nfsd4_setattr(struct svc_rqst *rqstp, st struct nfsd4_setattr *setattr) {__be32 status = nfs_ok; +int err;if (setattr->sa_iattr.ia_valid &ATTR_SIZE ) {nfs4_lock_state ();
@@ -837,9 +838,9 @@ nfsd4_setattr(struct svc_rqst *rqstp, streturn status; } } - status =fh_want_write (&cstate->current_fh); -if (status) -return status; + err =fh_want_write (&cstate->current_fh); +if (err) +return nfserrno (err); status = nfs_ok; status = check_attr_support(rqstp, cstate, setattr->sa_bmval,
Re: [ 53/62] nfsd: fix b0rken error value for setattr on read-only mount
Quoted 1 line · Greg KH
3.3-stable review patch.
[...]
Quoted 3 lines
commit
96f6f98501196d46ce52c2697dd758d9300c63f5upstream...._want_write() returns
-EROFSon failure, _not_ an NFS error value.
Here's the corresponding change for kernels without
static inline int fh_want_write(struct svc_fh *fh)
{
return mnt_want_write(fh->fh_export->ex_path.mnt);
}from v3.3-rc1~170^2~81 ("new helpers: fh_{want,drop}_write()"), such as the 3.0.y kernel. Thoughts and testing welcome as usual.
-- >8 --
From: Al Viro <[email protected]>
Date: Thu, 12 Apr 2012 23:47:00 -0400
commit 96f6f98501196d46ce52c2697dd758d9300c63f5 upstream.
..._want_write() returns -EROFS on failure, _not_ an NFS error value.
---
Thanks,
Jonathan
fs/nfsd/nfs4proc.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
fs/nfsd/nfs4proc.c +4 -3
@@ -812,6 +812,7 @@ nfsd4_setattr(struct svc_rqst *rqstp, struct nfsd4_compound_state *cstate, struct nfsd4_setattr *setattr) {__be32 status = nfs_ok; +int err;if (setattr->sa_iattr.ia_valid &ATTR_SIZE ) {nfs4_lock_state ();
@@ -823,9 +824,9 @@ nfsd4_setattr(struct svc_rqst *rqstp, struct nfsd4_compound_state *cstate,return status; } } - status =mnt_want_write (cstate->current_fh.fh_export->ex_path.mnt); -if (status) -return status; + err =mnt_want_write (cstate->current_fh.fh_export->ex_path.mnt); +if (err) +return nfserrno (err); status = nfs_ok; status = check_attr_support(rqstp, cstate, setattr->sa_bmval,
Signature · 1 line
1.7.10
Greg KH
maintainerPATCH 54/62 nfsd: fix error values returned by nfsd4_lockt() when nfsd_open() fails
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Al Viro <[email protected]>
commit 04da6e9d63427b2d0fd04766712200c250b3278f upstream.
nfsd_open() already returns an NFS error value; only vfs_test_lock() result needs to be fed through nfserrno(). Broken by commit 55ef12 (nfsd: Ensure nfsv4 calls the underlying filesystem on LOCKT) three years ago...
--- fs/nfsd/nfs4state.c | 23 +++++++++-------------- 1 file changed, 9 insertions(+), 14 deletions(-)
fs/nfsd/nfs4state.c +9 -14
@@ -4109,16 +4109,14 @@ out:* vfs_test_lock. (Arguably perhaps test_lock should be done with an * inode operation.) */ -static int nfsd_test_lock (struct svc_rqst *rqstp,struct svc_fh *fhp,struct file_lock *lock) +static __be32 nfsd_test_lock (struct svc_rqst *rqstp,struct svc_fh *fhp,struct file_lock *lock) {struct file *file; -int err; - - err =nfsd_open (rqstp, fhp,S_IFREG ,NFSD_MAY_READ , &file); -if (err) -return err; - err =vfs_test_lock (file, lock); -nfsd_close (file); +__be32 err =nfsd_open (rqstp, fhp,S_IFREG ,NFSD_MAY_READ , &file); +if (!err) { + err =nfserrno (vfs_test_lock (file, lock)); +nfsd_close (file); + }return err; }
@@ -4132,7 +4130,6 @@ nfsd4_lockt(struct svc_rqst *rqstp, strustruct inode *inode;struct file_lock file_lock;struct nfs4_lockowner *lo; -int error;__be32 status;if (locks_in_grace ())
@@ -4178,12 +4175,10 @@ nfsd4_lockt(struct svc_rqst *rqstp, strunfs4_transform_lock_offset (&file_lock); - status = nfs_ok; - error =nfsd_test_lock (rqstp, &cstate->current_fh, &file_lock); -if (error) { - status =nfserrno (error); + status =nfsd_test_lock (rqstp, &cstate->current_fh, &file_lock); +if (status) goto out; - } +if (file_lock.fl_type !=F_UNLCK ) { status = nfserr_denied;nfs4_set_lock_denied (&file_lock, &lockt->lt_denied);
Re: [ 54/62] nfsd: fix error values returned by nfsd4_lockt() when nfsd_open() fails
Quoted 1 line · Greg KH
3.3-stable review patch.
[...]
Quoted 6 lines
commit
04da6e9d63427b2d0fd04766712200c250b3278fupstream.
nfsd_open()already returns an NFS error value; onlyvfs_test_lock()result needs to be fed throughnfserrno(). Broken by commit 55ef12 (nfsd: Ensure nfsv4 calls the underlying filesystem on LOCKT) three years ago...
The regression was introduced in v2.6.29-rc1~177^2~14, so presumably 2.6.32.y and 3.0.y need this. Here's a blind backport to 3.0.y --- the only conflict encountered is of the unrelated-changes-on-adjacent- lines kind, against
v3.2-rc1~80^2~63 nfsd4: eliminate unused lt_stateowner v3.2-rc1~80^2~58 nfsd4: split stateowners into open and lockowners
Untested, so thoughts and testing would be welcome as usual.
-- >8 --
From: Al Viro <[email protected]>
Date: Fri, 13 Apr 2012 00:00:04 -0400
commit 04da6e9d63427b2d0fd04766712200c250b3278f upstream.
nfsd_open() already returns an NFS error value; only vfs_test_lock() result needs to be fed through nfserrno(). Broken by commit 55ef12 (nfsd: Ensure nfsv4 calls the underlying filesystem on LOCKT) three years ago...
---
Thanks,
Jonathan
fs/nfsd/nfs4state.c | 23 +++++++++-------------- 1 file changed, 9 insertions(+), 14 deletions(-)
fs/nfsd/nfs4state.c +9 -14
@@ -3956,16 +3956,14 @@ out:* vfs_test_lock. (Arguably perhaps test_lock should be done with an * inode operation.) */ -static int nfsd_test_lock (struct svc_rqst *rqstp,struct svc_fh *fhp,struct file_lock *lock) +static __be32 nfsd_test_lock (struct svc_rqst *rqstp,struct svc_fh *fhp,struct file_lock *lock) {struct file *file; -int err; - - err =nfsd_open (rqstp, fhp,S_IFREG ,NFSD_MAY_READ , &file); -if (err) -return err; - err =vfs_test_lock (file, lock); -nfsd_close (file); +__be32 err =nfsd_open (rqstp, fhp,S_IFREG ,NFSD_MAY_READ , &file); +if (!err) { + err =nfserrno (vfs_test_lock (file, lock)); +nfsd_close (file); + }return err; }
@@ -3978,7 +3976,6 @@ nfsd4_lockt(struct svc_rqst *rqstp, struct nfsd4_compound_state *cstate, {struct inode *inode;struct file_lock file_lock; -int error;__be32 status;if (locks_in_grace ())
@@ -4030,12 +4027,10 @@ nfsd4_lockt(struct svc_rqst *rqstp, struct nfsd4_compound_state *cstate,nfs4_transform_lock_offset (&file_lock); - status = nfs_ok; - error =nfsd_test_lock (rqstp, &cstate->current_fh, &file_lock); -if (error) { - status =nfserrno (error); + status =nfsd_test_lock (rqstp, &cstate->current_fh, &file_lock); +if (status) goto out; - } +if (file_lock.fl_type !=F_UNLCK ) { status = nfserr_denied;nfs4_set_lock_denied (&file_lock, &lockt->lt_denied);
Signature · 1 line
1.7.10
Greg KH
maintainerPATCH 55/62 nfsd: fix endianness breakage in TEST_STATEID handling
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Al Viro <[email protected]>
commit 02f5fde5df0ea930e70f93763dd48beff182b208 upstream.
->ts_id_status gets nfs errno, i.e. it's already big-endian; no need to apply htonl() to it. Broken by commit 174568 (NFSD: Added TEST_STATEID operation) last year...
--- fs/nfsd/nfs4xdr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/nfsd/nfs4xdr.c +1 -1
@@ -3410,7 +3410,7 @@ nfsd4_encode_test_stateid(struct nfsd4_cnfsd4_decode_stateid (argp, &si); valid =nfs4_validate_stateid (cl, &si);RESERVE_SPACE (4 ); - *p++ =htonl (valid); + *p++ = valid; resp->p = p; }nfs4_unlock_state ();
Greg KH
maintainerPATCH 56/62 nfsd: fix compose_entry_fh() failure exits
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Al Viro <[email protected]>
commit efe39651f08813180f37dc508d950fc7d92b29a8 upstream.
Restore the original logics ("fail on mountpoints, negatives and in case of fh_compose() failures"). Since commit 8177e (nfsd: clean up readdirplus encoding) that got broken -
rv = fh_compose(fhp, exp, dchild, &cd->fh); if (rv) goto out; if (!dchild->d_inode) goto out; rv = 0; out: is equivalent to rv = fh_compose(fhp, exp, dchild, &cd->fh);
out:
and the second check has no effect whatsoever...
--- fs/nfsd/nfs3xdr.c | 22 ++++++++-------------- 1 file changed, 8 insertions(+), 14 deletions(-)
fs/nfsd/nfs3xdr.c +8 -14
@@ -803,13 +803,13 @@ encode_entry_baggage(struct nfsd3_readdireturn p; } -static int +static __be32 compose_entry_fh (struct nfsd3_readdirres *cd,struct svc_fh *fhp,const char *name,int namlen) {struct svc_export *exp;struct dentry *dparent, *dchild; -int rv =0 ; +__be32 rv = nfserr_noent; dparent = cd->fh.fh_dentry; exp = cd->fh.fh_export;
@@ -817,26 +817,20 @@ compose_entry_fh(struct nfsd3_readdirresif (isdotent (name, namlen)) {if (namlen ==2 ) { dchild =dget_parent (dparent); -if (dchild == dparent) { -/* filesystem root - cannot return filehandle for ".." */ -dput (dchild); -return -ENOENT ; - } +/* filesystem root - cannot return filehandle for ".." */ +if (dchild == dparent) + goto out; }else dchild =dget (dparent); }else dchild =lookup_one_len (name, dparent, namlen);if (IS_ERR (dchild)) -return -ENOENT ; - rv = -ENOENT ; +return rv;if (d_mountpoint (dchild)) goto out; - rv =fh_compose (fhp, exp, dchild, &cd->fh); -if (rv) - goto out;if (!dchild->d_inode) goto out; - rv =0 ; + rv =fh_compose (fhp, exp, dchild, &cd->fh); out:dput (dchild);return rv;
@@ -845,7 +839,7 @@ out:static __be32 *encode_entryplus_baggage (struct nfsd3_readdirres *cd,__be32 *p,const char *name,int namlen) {struct svc_fh fh; -int err; +__be32 err;fh_init (&fh,NFS3_FHSIZE ); err =compose_entry_fh (cd, &fh, name, namlen);
Greg KH
maintainerPATCH 57/62 btrfs: btrfs_root_readonly() broken on big-endian
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Al Viro <[email protected]>
commit 6ed3cf2cdfce4c9f1d73171bd3f27d9cb77b734e upstream.
->root_flags is __le64 and all accesses to it go through the helpers that do proper conversions. Except for btrfs_root_readonly(), which checks bit 0 as in host-endian...
--- fs/btrfs/ctree.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/btrfs/ctree.h +1 -1
@@ -2115,7 +2115,7 @@ BTRFS_SETGET_STACK_FUNCS(root_last_snapsstatic inline bool btrfs_root_readonly (struct btrfs_root *root) { -return root->root_item.flags &BTRFS_ROOT_SUBVOL_RDONLY ; +return (root->root_item.flags &cpu_to_le64 (BTRFS_ROOT_SUBVOL_RDONLY )) !=0 ; }/* struct btrfs_root_backup */
Greg KH
maintainerPATCH 58/62 ocfs2: ->l_next_free_req breakage on big-endian
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Al Viro <[email protected]>
commit 3a251f04fe97c3d335b745c98e4b377e3c3899f2 upstream.
It's le16, not le32...
--- fs/ocfs2/alloc.c | 2 +- fs/ocfs2/refcounttree.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-)
fs/ocfs2/alloc.c +1 -1
@@ -1134,7 +1134,7 @@ static int ocfs2_adjust_rightmost_branch } el =path_leaf_el (path); - rec = &el->l_recs[le32_to_cpu (el->l_next_free_rec) -1 ]; + rec = &el->l_recs[le16_to_cpu (el->l_next_free_rec) -1 ];ocfs2_adjust_rightmost_records (handle, et, path, rec);
fs/ocfs2/refcounttree.c +2 -2
@@ -1036,14 +1036,14 @@ static int ocfs2_get_refcount_cpos_end(s tmp_el = left_path->p_node[subtree_root].el; blkno = left_path->p_node[subtree_root+1 ].bh->b_blocknr; -for (i =0 ; i <le32_to_cpu (tmp_el->l_next_free_rec); i++) { +for (i =0 ; i <le16_to_cpu (tmp_el->l_next_free_rec); i++) {if (le64_to_cpu (tmp_el->l_recs[i].e_blkno) == blkno) { *cpos_end =le32_to_cpu (tmp_el->l_recs[i+1 ].e_cpos);break ; } } -BUG_ON (i ==le32_to_cpu (tmp_el->l_next_free_rec)); +BUG_ON (i ==le16_to_cpu (tmp_el->l_next_free_rec)); out:ocfs2_free_path (left_path);
Greg KH
maintainerPATCH 59/62 ocfs: ->rl_used breakage on big-endian
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Al Viro <[email protected]>
commit e1bf4cc620fd143766ddfcee3b004a1d1bb34fd0 upstream.
it's le16, not le32 or le64...
--- fs/ocfs2/refcounttree.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
fs/ocfs2/refcounttree.c +4 -4
@@ -1468,7 +1468,7 @@ static int ocfs2_divide_leaf_refcount_bltrace_ocfs2_divide_leaf_refcount_block ( (unsigned long long )ref_leaf_bh->b_blocknr, -le32_to_cpu (rl->rl_count),le32_to_cpu (rl->rl_used)); +le32_to_cpu (rl->rl_count),le16_to_cpu (rl->rl_used));/* * XXX: Improvement later.
@@ -2411,7 +2411,7 @@ static int ocfs2_calc_refcount_meta_cred rb = (struct ocfs2_refcount_block *) prev_bh->b_data; -if (le64_to_cpu (rb->rf_records.rl_used) + +if (le16_to_cpu (rb->rf_records.rl_used) + recs_add >le16_to_cpu (rb->rf_records.rl_count)) ref_blocks++;
@@ -2476,7 +2476,7 @@ static int ocfs2_calc_refcount_meta_credif (prev_bh) { rb = (struct ocfs2_refcount_block *)prev_bh->b_data; -if (le64_to_cpu (rb->rf_records.rl_used) + recs_add > +if (le16_to_cpu (rb->rf_records.rl_used) + recs_add >le16_to_cpu (rb->rf_records.rl_count)) ref_blocks++;
@@ -3629,7 +3629,7 @@ int ocfs2_refcounted_xattr_delete_need(s* one will split a refcount rec, so totally we need * clusters * 2 new refcount rec. */ -if (le64_to_cpu (rb->rf_records.rl_used) + clusters *2 > +if (le16_to_cpu (rb->rf_records.rl_used) + clusters *2 >le16_to_cpu (rb->rf_records.rl_count)) ref_blocks++;
Greg KH
maintainerPATCH 60/62 ocfs2: ->rl_count endianness breakage
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Al Viro <[email protected]>
commit 28748b325dc2d730ccc312830a91c4ae0c0d9379 upstream.
le16, not le32...
--- fs/ocfs2/refcounttree.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/ocfs2/refcounttree.c +1 -1
@@ -1468,7 +1468,7 @@ static int ocfs2_divide_leaf_refcount_bltrace_ocfs2_divide_leaf_refcount_block ( (unsigned long long )ref_leaf_bh->b_blocknr, -le32_to_cpu (rl->rl_count),le16_to_cpu (rl->rl_used)); +le16_to_cpu (rl->rl_count),le16_to_cpu (rl->rl_used));/* * XXX: Improvement later.
Greg KH
maintainerPATCH 61/62 ocfs2: ->e_leaf_clusters endianness breakage
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Al Viro <[email protected]>
commit 72094e43e3af5020510f920321d71f1798fa896d upstream.
le16, not le32...
--- fs/ocfs2/suballoc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
fs/ocfs2/suballoc.c +2 -2
@@ -600,7 +600,7 @@ static void ocfs2_bg_alloc_cleanup(handl ret =ocfs2_free_clusters (handle, cluster_ac->ac_inode, cluster_ac->ac_bh,le64_to_cpu (rec->e_blkno), -le32_to_cpu (rec->e_leaf_clusters)); +le16_to_cpu (rec->e_leaf_clusters));if (ret)mlog_errno (ret);/* Try all the clusters to free */
@@ -1628,7 +1628,7 @@ static int ocfs2_bg_discontig_fix_by_rec {unsigned int bpc =le16_to_cpu (cl->cl_bpc);unsigned int bitoff =le32_to_cpu (rec->e_cpos) * bpc; -unsigned int bitcount =le32_to_cpu (rec->e_leaf_clusters) * bpc; +unsigned int bitcount =le16_to_cpu (rec->e_leaf_clusters) * bpc;if (res->sr_bit_offset < bitoff)return 0 ;
Greg KH
maintainerPATCH 62/62 lockd: fix the endianness bug
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Al Viro <[email protected]>
commit e847469bf77a1d339274074ed068d461f0c872bc upstream.
comparing be32 values for < is not doing the right thing...
--- fs/lockd/clnt4xdr.c | 2 +- fs/lockd/clntxdr.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
fs/lockd/clnt4xdr.c +1 -1
@@ -241,7 +241,7 @@ static int decode_nlm4_stat(struct xdr_s p =xdr_inline_decode (xdr,4 );if (unlikely (p ==NULL )) goto out_overflow; -if (unlikely (*p > nlm4_failed)) +if (unlikely (ntohl (*p) >ntohl (nlm4_failed))) goto out_bad_xdr; *stat = *p;return 0 ;
fs/lockd/clntxdr.c +1 -1
@@ -236,7 +236,7 @@ static int decode_nlm_stat(struct xdr_st p =xdr_inline_decode (xdr,4 );if (unlikely (p ==NULL )) goto out_overflow; -if (unlikely (*p > nlm_lck_denied_grace_period)) +if (unlikely (ntohl (*p) >ntohl (nlm_lck_denied_grace_period))) goto out_enum; *stat = *p;return 0 ;