2.6.32.12-stable review
Subsystems (68)
PATCH 143/197 ALSA: hda - enable snoop for Intel Cougar Point
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Seth Heasley <[email protected]>
commit 32679f95cac3b1bdf27dce8b5273e06af186fd91 upstream.
This patch enables snoop, eliminating static during playback. This patch supersedes the previous Cougar Point audio patch.
--- sound/pci/hda/hda_intel.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
sound/pci/hda/hda_intel.c +5 -1
@@ -438,6 +438,7 @@ struct azx {/* driver types */ enum {AZX_DRIVER_ICH , +AZX_DRIVER_PCH ,AZX_DRIVER_SCH ,AZX_DRIVER_ATI ,AZX_DRIVER_ATIHDMI ,
@@ -452,6 +453,7 @@ enum {static char *driver_short_names[]__devinitdata = { [AZX_DRIVER_ICH ] ="HDA Intel" , + [AZX_DRIVER_PCH ] ="HDA Intel PCH" , [AZX_DRIVER_SCH ] ="HDA Intel MID" , [AZX_DRIVER_ATI ] ="HDA ATI SB" , [AZX_DRIVER_ATIHDMI ] ="HDA ATI HDMI" ,
@@ -1040,6 +1042,7 @@ static void azx_init_pci(struct azx *chi 0x01, NVIDIA_HDA_ENABLE_COHBIT);break ;case AZX_DRIVER_SCH : +case AZX_DRIVER_PCH :pci_read_config_word (chip->pci,INTEL_SCH_HDA_DEVC , &snoop);if (snoop &INTEL_SCH_HDA_DEVC_NOSNOOP ) { pci_write_config_word(chip->pci, INTEL_SCH_HDA_DEVC,
@@ -2393,6 +2396,7 @@ static int __devinit azx_create(struct sif (bdl_pos_adj[dev] <0 ) {switch (chip->driver_type) {case AZX_DRIVER_ICH : +case AZX_DRIVER_PCH : bdl_pos_adj[dev] =1 ;break ;default :
@@ -2668,7 +2672,7 @@ static struct pci_device_id azx_ids[] =/* PCH */ { PCI_DEVICE(0x8086, 0x3b56), .driver_data = AZX_DRIVER_ICH }, /* CPT */ - { PCI_DEVICE(0x8086, 0x1c20), .driver_data = AZX_DRIVER_ICH }, + { PCI_DEVICE(0x8086, 0x1c20), .driver_data = AZX_DRIVER_PCH }, /* SCH */ { PCI_DEVICE(0x8086, 0x811b), .driver_data = AZX_DRIVER_SCH },/* ATI SB 450/600 */
PATCH 144/197 ata_piix: IDE Mode SATA patch for Intel Cougar Point DeviceIDs
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Seth Heasley <[email protected]>
commit 88e8201e67aace3d86de9e75122ea525f0e7248e upstream.
--- drivers/ata/ata_piix.c | 8 ++++++++ 1 file changed, 8 insertions(+)
drivers/ata/ata_piix.c +8 -0
@@ -291,6 +291,14 @@ static const struct pci_device_id piix_p { 0x8086, 0x3b2d, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata },/* SATA Controller IDE (PCH) */ { 0x8086, 0x3b2e, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata }, +/* SATA Controller IDE (CPT) */ + { 0x8086, 0x1c00, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata }, +/* SATA Controller IDE (CPT) */ + { 0x8086, 0x1c01, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata }, +/* SATA Controller IDE (CPT) */ + { 0x8086, 0x1c08, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata }, +/* SATA Controller IDE (CPT) */ + { 0x8086, 0x1c09, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata }, { } /* terminate list */ };
PATCH 145/197 ahci: AHCI and RAID mode SATA patch for Intel Cougar Point DeviceIDs
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Seth Heasley <[email protected]>
commit 5623cab83ea61e0420f2064216d83eab067a24c6 upstream.
--- drivers/ata/ahci.c | 6 ++++++ 1 file changed, 6 insertions(+)
drivers/ata/ahci.c +6 -0
@@ -570,6 +570,12 @@ static const struct pci_device_id ahci_p { PCI_VDEVICE(INTEL, 0x3b2b), board_ahci }, /* PCH RAID */ { PCI_VDEVICE(INTEL, 0x3b2c), board_ahci }, /* PCH RAID */ { PCI_VDEVICE(INTEL, 0x3b2f), board_ahci }, /* PCH AHCI */ + { PCI_VDEVICE(INTEL, 0x1c02), board_ahci }, /* CPT AHCI */ + { PCI_VDEVICE(INTEL, 0x1c03), board_ahci }, /* CPT AHCI */ + { PCI_VDEVICE(INTEL, 0x1c04), board_ahci }, /* CPT RAID */ + { PCI_VDEVICE(INTEL, 0x1c05), board_ahci }, /* CPT RAID */ + { PCI_VDEVICE(INTEL, 0x1c06), board_ahci }, /* CPT RAID */ + { PCI_VDEVICE(INTEL, 0x1c07), board_ahci }, /* CPT RAID *//* JMicron 360/1/3/5/6, match class to avoid IDE function */ { PCI_VENDOR_ID_JMICRON, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
PATCH 146/197 i2c-i801: Add Intel Cougar Point device IDs
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Seth Heasley <[email protected]>
commit 393764340beb595c1ad7dd2d2243c2b6551aaa71 upstream.
Add the Intel Cougar Point (PCH) SMBus controller device IDs.
--- Documentation/i2c/busses/i2c-i801 | 3 ++- drivers/i2c/busses/Kconfig | 5 +++-- drivers/i2c/busses/i2c-i801.c | 5 ++++- 3 files changed, 9 insertions(+), 4 deletions(-)
Documentation/i2c/busses/i2c-i801 +2 -1
@@ -15,7 +15,8 @@ Supported adapters: * Intel 82801I (ICH9) * Intel EP80579 (Tolapai) * Intel 82801JI (ICH10) - * Intel PCH + * Intel 3400/5 Series (PCH) + * Intel Cougar Point (PCH) Datasheets: Publicly available at the Intel website Authors:
drivers/i2c/busses/Kconfig +3 -2
@@ -77,7 +77,7 @@ config I2C_AMD8111 will be called i2c-amd8111. config I2C_I801 - tristate "Intel 82801 (ICH)" + tristate "Intel 82801 (ICH/PCH)" depends on PCI help If you say yes to this option, support will be included for the Intel
@@ -97,7 +97,8 @@ config I2C_I801 ICH9 Tolapai ICH10 - PCH + 3400/5 Series (PCH) + Cougar Point (PCH) This driver can also be built as a module. If so, the module will be called i2c-i801.
drivers/i2c/busses/i2c-i801.c +4 -1
@@ -41,7 +41,8 @@ Tolapai 0x5032 32 hard yes yes yes ICH10 0x3a30 32 hard yes yes yes ICH10 0x3a60 32 hard yes yes yes - PCH 0x3b30 32 hard yes yes yes + 3400/5 Series (PCH) 0x3b30 32 hard yes yes yes + Cougar Point (PCH) 0x1c22 32 hard yes yes yes Features supported by this driver: Software PEC no
@@ -580,6 +581,7 @@ static struct pci_device_id i801_ids[] = { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH10_4) }, { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH10_5) }, { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_PCH_SMBUS) }, + { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_CPT_SMBUS) }, { 0, } };
@@ -709,6 +711,7 @@ static int __devinit i801_probe(struct pcase PCI_DEVICE_ID_INTEL_ICH10_4 :case PCI_DEVICE_ID_INTEL_ICH10_5 :case PCI_DEVICE_ID_INTEL_PCH_SMBUS : +case PCI_DEVICE_ID_INTEL_CPT_SMBUS : i801_features |=FEATURE_I2C_BLOCK_READ ;/* fall through */ case PCI_DEVICE_ID_INTEL_82801DB_3 :
PATCH 147/197 b43: Remove reset after fatal DMA error
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Larry Finger <[email protected]>
commit 214ac9a4ead6cb254451c09d9c8234a76693feb1 upstream.
As shown in Kernel Bugzilla #14761, doing a controller restart after a fatal DMA error does not accomplish anything other than consume the CPU on an affected system. Accordingly, substitute a meaningful message for the restart.
--- drivers/net/wireless/b43/main.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/net/wireless/b43/main.c +4 -1
@@ -1788,7 +1788,10 @@ static void b43_do_interrupt_thread(stru dma_reason[0 ], dma_reason[1 ], dma_reason[2 ], dma_reason[3 ], dma_reason[4], dma_reason[5]); -b43_controller_restart (dev,"DMA error" ); +b43err (dev->wl,"This device does not support DMA " +"on your system. Please use PIO instead.\n" ); +b43err (dev->wl,"CONFIG_B43_FORCE_PIO must be set in " +"your kernel configuration.\n" );return ; }if (merged_dma_reason &B43_DMAIRQ_NONFATALMASK ) {
PATCH 148/197 b43: Allow PIO mode to be selected at module load
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Larry Finger <[email protected]>
commit b02914af4d7020828ce921a572589dd793517c09 upstream.
If userencounter the "Fatal DMA Problem" with a BCM43XX device, and still wish to use b43 as the driver, their only option is to rebuild the kernel with CONFIG_B43_FORCE_PIO. This patch removes this option and allows PIO mode to be selected with a load-time parameter for the module. Note that the configuration variable CONFIG_B43_PIO is also removed.
Once the DMA problem with the BCM4312 devices is solved, this patch will likely be reverted.
--- drivers/net/wireless/b43/Kconfig | 19 +----------------- drivers/net/wireless/b43/Makefile | 2 - drivers/net/wireless/b43/b43.h | 13 ------------ drivers/net/wireless/b43/dma.c | 2 - drivers/net/wireless/b43/main.c | 9 +++++--- drivers/net/wireless/b43/pio.h | 40 -------------------------------------- 6 files changed, 9 insertions(+), 76 deletions(-)
drivers/net/wireless/b43/Kconfig +2 -17
@@ -3,6 +3,7 @@ config B43 depends on SSB_POSSIBLE && MAC80211 && WLAN_80211 && HAS_DMA select SSB select FW_LOADER + select SSB_BLOCKIO ---help--- b43 is a driver for the Broadcom 43xx series wireless devices.
@@ -78,14 +79,6 @@ config B43_SDIO If unsure, say N. -# Data transfers to the device via PIO -# This is only needed on PCMCIA and SDIO devices. All others can do DMA properly. -config B43_PIO - bool - depends on B43 && (B43_SDIO || B43_PCMCIA || B43_FORCE_PIO) - select SSB_BLOCKIO - default y - config B43_NPHY bool "Pre IEEE 802.11n support (BROKEN)" depends on B43 && EXPERIMENTAL && BROKEN
@@ -137,12 +130,4 @@ config B43_DEBUG for production use. Only say Y, if you are debugging a problem in the b43 driver sourcecode. -config B43_FORCE_PIO - bool "Force usage of PIO instead of DMA" - depends on B43 && B43_DEBUG - ---help--- - This will disable DMA and always enable PIO instead. - - Say N! - This is only for debugging the PIO engine code. You do - _NOT_ want to enable this. +
drivers/net/wireless/b43/Makefile +1 -1
@@ -12,7 +12,7 @@ b43-y += xmit.o b43-y += lo.o b43-y += wa.o b43-y += dma.o -b43-$(CONFIG_B43_PIO) += pio.o +b43-y += pio.o b43-y += rfkill.o b43-$(CONFIG_B43_LEDS) += leds.o b43-$(CONFIG_B43_PCMCIA) += pcmcia.o
drivers/net/wireless/b43/b43.h +0 -13
@@ -830,7 +830,6 @@ struct b43_wl {/* The device LEDs. */ struct b43_leds leds; -#ifdef CONFIG_B43_PIO /* * RX/TX header/tail buffers used by the frame transmit functions. */
@@ -838,7 +837,6 @@ struct b43_wl {struct b43_txhdr txhdr;u8 rx_tail[4 ];u8 tx_tail[4 ]; -#endif /* CONFIG_B43_PIO */ };static inline struct b43_wl *hw_to_b43_wl (struct ieee80211_hw *hw)
@@ -889,20 +887,9 @@ static inline void b43_write32(struct b4static inline bool b43_using_pio_transfers (struct b43_wldev *dev) { -#ifdef CONFIG_B43_PIO return dev->__using_pio_transfers; -#else -return 0 ; -#endif } -#ifdef CONFIG_B43_FORCE_PIO -# define B43_FORCE_PIO 1 -#else -# define B43_FORCE_PIO 0 -#endif - -/* Message printing */ void b43info (struct b43_wl *wl,const char *fmt, ...) __attribute__ ((format (printf,2 ,3 )));
drivers/net/wireless/b43/dma.c +0 -2
@@ -1620,7 +1620,6 @@ void b43_dma_tx_resume(struct b43_wldevb43_power_saving_ctl_bits (dev,0 ); } -#ifdef CONFIG_B43_PIO static void direct_fifo_rx (struct b43_wldev *dev,enum b43_dmatype type,u16 mmio_base,bool enable) {
@@ -1654,4 +1653,3 @@ void b43_dma_direct_fifo_rx(struct b43_w mmio_base =b43_dmacontroller_base (type, engine_index);direct_fifo_rx (dev, type, mmio_base, enable); } -#endif /* CONFIG_B43_PIO */
drivers/net/wireless/b43/main.c +6 -3
@@ -102,6 +102,9 @@ int b43_modparam_verbose = B43_VERBOSITYmodule_param_named (verbose, b43_modparam_verbose, int,0644 );MODULE_PARM_DESC (verbose,"Log message verbosity: 0=error, 1=warn, 2=info(default), 3=debug" ); +static int modparam_pio; +module_param_named (pio, modparam_pio, int,0444 ); +MODULE_PARM_DESC (pio,"enable(1) / disable(0) PIO mode" );static const struct ssb_device_id b43_ssb_tbl[] = {SSB_DEVICE (SSB_VENDOR_BROADCOM ,SSB_DEV_80211 ,5 ),
@@ -1790,8 +1793,8 @@ static void b43_do_interrupt_thread(stru dma_reason[4], dma_reason[5]);b43err (dev->wl,"This device does not support DMA " "on your system. Please use PIO instead.\n" ); -b43err (dev->wl,"CONFIG_B43_FORCE_PIO must be set in " -"your kernel configuration.\n" ); +b43err (dev->wl,"Unload the b43 module and reload " +"with 'pio=1'\n" );return ; }if (merged_dma_reason &B43_DMAIRQ_NONFATALMASK ) {
@@ -4358,7 +4361,7 @@ static int b43_wireless_core_init(structif ((dev->dev->bus->bustype ==SSB_BUSTYPE_PCMCIA ) || (dev->dev->bus->bustype ==SSB_BUSTYPE_SDIO ) || -B43_FORCE_PIO ) { + modparam_pio) { dev->__using_pio_transfers =1 ; err =b43_pio_init (dev); }else {
drivers/net/wireless/b43/pio.h +0 -40
@@ -55,8 +55,6 @@#define B43_PIO_MAX_NR_TXPACKETS 32 -#ifdef CONFIG_B43_PIO -struct b43_pio_txpacket {/* Pointer to the TX queue we belong to. */ struct b43_pio_txqueue *queue;
@@ -169,42 +167,4 @@ void b43_pio_rx(struct b43_pio_rxqueue *void b43_pio_tx_suspend (struct b43_wldev *dev);void b43_pio_tx_resume (struct b43_wldev *dev); - -#else /* CONFIG_B43_PIO */ - - -static inline int b43_pio_init (struct b43_wldev *dev) -{ -return 0 ; -} -static inline void b43_pio_free (struct b43_wldev *dev) -{ -} -static inline void b43_pio_stop (struct b43_wldev *dev) -{ -} -static inline int b43_pio_tx (struct b43_wldev *dev, -struct sk_buff *skb) -{ -return 0 ; -} -static inline void b43_pio_handle_txstatus (struct b43_wldev *dev, -const struct b43_txstatus *status) -{ -} -static inline void b43_pio_get_tx_stats (struct b43_wldev *dev, -struct ieee80211_tx_queue_stats *stats) -{ -} -static inline void b43_pio_rx (struct b43_pio_rxqueue *q) -{ -} -static inline void b43_pio_tx_suspend (struct b43_wldev *dev) -{ -} -static inline void b43_pio_tx_resume (struct b43_wldev *dev) -{ -} - -#endif /* CONFIG_B43_PIO */ #endif /* B43_PIO_H_ */
PATCH 149/197 b43: fall back gracefully to PIO mode after fatal DMA errors
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Linus Torvalds <[email protected]>
commit 9e3bd9190800e8209b4a3e1d724c35f0738dcad2 upstream.
This makes the b43 driver just automatically fall back to PIO mode when DMA doesn't work.
The driver already told the user to do it, so rather than have the user reload the module with a new flag, just make the driver do it automatically. We keep the message as an indication that something is wrong, but now just automatically fall back to the hopefully working PIO case.
(Some post-2.6.33 merge fixups by Larry Finger <[email protected]> and yours truly... -- JWL)
--- drivers/net/wireless/b43/Kconfig | 19 +++++++++++++++++-- drivers/net/wireless/b43/b43.h | 7 +++++++ drivers/net/wireless/b43/main.c | 14 ++++++++------ 3 files changed, 32 insertions(+), 8 deletions(-)
drivers/net/wireless/b43/Kconfig +17 -2
@@ -3,7 +3,6 @@ config B43 depends on SSB_POSSIBLE && MAC80211 && WLAN_80211 && HAS_DMA select SSB select FW_LOADER - select SSB_BLOCKIO ---help--- b43 is a driver for the Broadcom 43xx series wireless devices.
@@ -79,6 +78,14 @@ config B43_SDIO If unsure, say N. +#Data transfers to the device via PIO. We want it as a fallback even +# if we can do DMA. +config B43_PIO + bool + depends on B43 + select SSB_BLOCKIO + default y + config B43_NPHY bool "Pre IEEE 802.11n support (BROKEN)" depends on B43 && EXPERIMENTAL && BROKEN
@@ -130,4 +137,12 @@ config B43_DEBUG for production use. Only say Y, if you are debugging a problem in the b43 driver sourcecode. - +config B43_FORCE_PIO + bool "Force usage of PIO instead of DMA" + depends on B43 && B43_DEBUG + ---help--- + This will disable DMA and always enable PIO instead. + + Say N! + This is only for debugging the PIO engine code. You do + _NOT_ want to enable this.
drivers/net/wireless/b43/b43.h +7 -0
@@ -696,6 +696,7 @@ struct b43_wldev {bool radio_hw_enable;/* saved state of radio hardware enabled state */ bool qos_enabled;/* TRUE, if QoS is used. */ bool hwcrypto_enabled;/* TRUE, if HW crypto acceleration is enabled. */ +bool use_pio;/* TRUE if next init should use PIO */ /* PHY/Radio device. */ struct b43_phy phy;
@@ -890,6 +891,12 @@ static inline bool b43_using_pio_transfereturn dev->__using_pio_transfers; } +#ifdef CONFIG_B43_FORCE_PIO +# define B43_PIO_DEFAULT 1 +#else +# define B43_PIO_DEFAULT 0 +#endif +/* Message printing */ void b43info (struct b43_wl *wl,const char *fmt, ...) __attribute__ ((format (printf,2 ,3 )));
drivers/net/wireless/b43/main.c +8 -6
@@ -102,9 +102,9 @@ int b43_modparam_verbose = B43_VERBOSITYmodule_param_named (verbose, b43_modparam_verbose, int,0644 );MODULE_PARM_DESC (verbose,"Log message verbosity: 0=error, 1=warn, 2=info(default), 3=debug" ); -static int modparam_pio; -module_param_named (pio, modparam_pio, int,0444 ); -MODULE_PARM_DESC (pio,"enable(1) / disable(0) PIO mode" ); +int b43_modparam_pio =B43_PIO_DEFAULT ; +module_param_named (pio, b43_modparam_pio, int,0644 ); +MODULE_PARM_DESC (pio,"Use PIO accesses by default: 0=DMA, 1=PIO" );static const struct ssb_device_id b43_ssb_tbl[] = {SSB_DEVICE (SSB_VENDOR_BROADCOM ,SSB_DEV_80211 ,5 ),
@@ -1793,8 +1793,9 @@ static void b43_do_interrupt_thread(stru dma_reason[4], dma_reason[5]);b43err (dev->wl,"This device does not support DMA " "on your system. Please use PIO instead.\n" ); -b43err (dev->wl,"Unload the b43 module and reload " -"with 'pio=1'\n" ); +/* Fall back to PIO transfers if we get fatal DMA errors! */ + dev->use_pio =1 ; +b43_controller_restart (dev,"DMA error" );return ; }if (merged_dma_reason &B43_DMAIRQ_NONFATALMASK ) {
@@ -4361,7 +4362,7 @@ static int b43_wireless_core_init(structif ((dev->dev->bus->bustype ==SSB_BUSTYPE_PCMCIA ) || (dev->dev->bus->bustype ==SSB_BUSTYPE_SDIO ) || - modparam_pio) { + dev->use_pio) { dev->__using_pio_transfers =1 ; err =b43_pio_init (dev); }else {
@@ -4829,6 +4830,7 @@ static int b43_one_core_attach(struct ssif (!wldev) goto out; + wldev->use_pio = b43_modparam_pio; wldev->dev = dev; wldev->wl = wl;b43_set_status (wldev,B43_STAT_UNINIT );
PATCH 150/197 ALSA: hda - Add position_fix quirk for Biostar mobo
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Takashi Iwai <[email protected]>
commit 8815cd030fdd73932a791d1f06194c8db807cde7 upstream.
The Biostar mobo seems to give a wrong DMA position, resulting in stuttering or skipping sounds on 2.6.34. Since the commit 7b3a177b0d4f92b3431b8dca777313a07533a710, "ALSA: pcm_lib: fix "something must be really wrong" condition", makes the position check more strictly, the DMA position problem is revealed more clearly now.
The fix is to use only LPIB for obtaining the position, i.e. passing position_fix=1. This patch adds a static quirk to achieve it as default.
--- sound/pci/hda/hda_intel.c | 1 + 1 file changed, 1 insertion(+)
sound/pci/hda/hda_intel.c +1 -0
@@ -2235,6 +2235,7 @@ static struct snd_pci_quirk position_fixSND_PCI_QUIRK (0x1458 ,0xa022 ,"ga-ma770-ud3" ,POS_FIX_LPIB ),SND_PCI_QUIRK (0x1462 ,0x1002 ,"MSI Wind U115" ,POS_FIX_LPIB ),SND_PCI_QUIRK (0x1565 ,0x820f ,"Biostar Microtech" ,POS_FIX_LPIB ), +SND_PCI_QUIRK (0x1565 ,0x8218 ,"Biostar Microtech" ,POS_FIX_LPIB ), SND_PCI_QUIRK(0x8086, 0xd601, "eMachines T5212", POS_FIX_LPIB), {} };
PATCH 151/197 agp/hp: fixup hp agp after ACPI changes
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Bjorn Helgaas <[email protected]>
commit 67fe63b0715ccfaefa0af8a6e705c5470ee5cada upstream.
Commit 15b8dd53f5ffa changed the string in info->hardware_id from a static array to a pointer and added a length field. But instead of changing "sizeof(array)" to "length", we changed it to "sizeof(length)" (== 4), which corrupts the string we're trying to null-terminate.
We no longer even need to null-terminate the string, but we *do* need to check whether we found a HID. If there's no HID, we used to have an empty array, but now we have a null pointer.
The combination of these defects causes this oops:
Unable to handle kernel NULL pointer dereference (address 0000000000000003) modprobe[895]: Oops 8804682956800 [1] ip is at zx1_gart_probe+0xd0/0xcc0 [hp_agp]
http://marc.info/?l=linux-ia64&m=126264484923647&w=2
--- drivers/char/agp/hp-agp.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/char/agp/hp-agp.c +1 -2
@@ -488,9 +488,8 @@ zx1_gart_probe (acpi_handle obj, u32 dep handle = obj; do { status = acpi_get_object_info(handle, &info); - if (ACPI_SUCCESS(status)) { + if (ACPI_SUCCESS(status) && (info->valid & ACPI_VALID_HID)) { /* TBD check _CID also */ - info->hardware_id.string[sizeof(info->hardware_id.length)-1] = '\0'; match = (strcmp(info->hardware_id.string, "HWP0001") == 0); kfree(info); if (match) {
PATCH 152/197 b43: Optimize PIO scratchbuffer usage
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Michael Buesch <[email protected]>
commit 88499ab3d8dbbf9c080416952603742666c71262 upstream.
This optimizes the PIO scratchbuffer usage.
--- drivers/net/wireless/b43/b43.h | 16 +------- drivers/net/wireless/b43/pio.c | 79 +++++++++++++++++++++++----------------- drivers/net/wireless/b43/xmit.c | 2 - 3 files changed, 51 insertions(+), 46 deletions(-)
drivers/net/wireless/b43/b43.h +3 -13
@@ -751,12 +751,6 @@ struct b43_wldev {#endif }; -/* -* Include goes here to avoid a dependency problem. -* A better fix would be to integrate xmit.h into b43.h. -*/ -#include "xmit.h" -/* Data structure for the WLAN parts (802.11 cores) of the b43 chip. */ struct b43_wl {/* Pointer to the active wireless device on this chip */
@@ -831,13 +825,9 @@ struct b43_wl {/* The device LEDs. */ struct b43_leds leds; -/* -* RX/TX header/tail buffers used by the frame transmit functions. -*/ -struct b43_rxhdr_fw4 rxhdr; -struct b43_txhdr txhdr; -u8 rx_tail[4 ]; -u8 tx_tail[4 ]; +/* Kmalloc'ed scratch space for PIO TX/RX. Protected by wl->mutex. */ + u8 pio_scratchspace[110] __attribute__((__aligned__(8))); + u8 pio_tailspace[4] __attribute__((__aligned__(8))); };static inline struct b43_wl *hw_to_b43_wl (struct ieee80211_hw *hw)
drivers/net/wireless/b43/pio.c +47 -32
180 lines not on this page · raw message
drivers/net/wireless/b43/xmit.c +1 -1
@@ -27,7 +27,7 @@*/ -#include "b43.h" +#include "xmit.h" #include "phy_common.h" #include "dma.h" #include "pio.h"
PATCH 153/197 ecryptfs: fix use with tmpfs by removing d_drop from ecryptfs_destroy_inode
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Jeff Mahoney <[email protected]>
commit 133b8f9d632cc23715c6d72d1c5ac449e054a12a upstream.
Since tmpfs has no persistent storage, it pins all its dentries in memory so they have d_count=1 when other file systems would have d_count=0. ->lookup is only used to create new dentries. If the caller doesn't instantiate it, it's freed immediately at dput(). ->readdir reads directly from the dcache and depends on the dentries being hashed.
When an ecryptfs mount is mounted, it associates the lower file and dentry with the ecryptfs files as they're accessed. When it's umounted and destroys all the in-memory ecryptfs inodes, it fput's the lower_files and d_drop's the lower_dentries. Commit 4981e081 added this and a d_delete in 2008 and several months later commit caeeeecf removed the d_delete. I believe the d_drop() needs to be removed as well.
The d_drop effectively hides any file that has been accessed via ecryptfs from the underlying tmpfs since it depends on it being hashed for it to be accessible. I've removed the d_drop on my development node and see no ill effects with basic testing on both tmpfs and persistent storage.
As a side effect, after ecryptfs d_drops the dentries on tmpfs, tmpfs BUGs on umount. This is due to the dentries being unhashed. tmpfs->kill_sb is kill_litter_super which calls d_genocide to drop the reference pinning the dentry. It skips unhashed and negative dentries, but shrink_dcache_for_umount_subtree doesn't. Since those dentries still have an elevated d_count, we get a BUG().
This patch removes the d_drop call and fixes both issues.
This issue was reported at:
https://bugzilla.novell.com/show_bug.cgi?id=567887
--- fs/ecryptfs/super.c | 1 - 1 file changed, 1 deletion(-)
fs/ecryptfs/super.c +0 -1
@@ -85,7 +85,6 @@ static void ecryptfs_destroy_inode(strucif (lower_dentry->d_inode) {fput (inode_info->lower_file); inode_info->lower_file =NULL ; -d_drop (lower_dentry); } }ecryptfs_destroy_crypt_stat (&inode_info->crypt_stat);
PATCH 154/197 eCryptfs: Decrypt symlink target for stat size
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Tyler Hicks <[email protected]>
commit 3a60a1686f0d51c99bd0df8ac93050fb6dfce647 upstream.
Create a getattr handler for eCryptfs symlinks that is capable of reading the lower target and decrypting its path. Prior to this patch, a stat's st_size field would represent the strlen of the encrypted path, while readlink() would return the strlen of the decrypted path. This could lead to confusion in some userspace applications, since the two values should be equal.
https://bugs.launchpad.net/bugs/524919
--- fs/ecryptfs/inode.c | 100 +++++++++++++++++++++++++++------------------------- 1 file changed, 52 insertions(+), 48 deletions(-)
fs/ecryptfs/inode.c +52 -48
@@ -638,38 +638,17 @@ out_lock:return rc; } -static int -ecryptfs_readlink (struct dentry *dentry,char __user *buf,int bufsiz) +static int ecryptfs_readlink_lower (struct dentry *dentry,char **buf, +size_t *bufsiz) { +struct dentry *lower_dentry =ecryptfs_dentry_to_lower (dentry);char *lower_buf; -size_t lower_bufsiz; -struct dentry *lower_dentry; -struct ecryptfs_mount_crypt_stat *mount_crypt_stat; -char *plaintext_name; -size_t plaintext_name_size; +size_t lower_bufsiz =PATH_MAX ;mm_segment_t old_fs;int rc; - lower_dentry =ecryptfs_dentry_to_lower (dentry); -if (!lower_dentry->d_inode->i_op->readlink) { - rc = -EINVAL ; - goto out; - } - mount_crypt_stat = &ecryptfs_superblock_to_private ( - dentry->d_sb)->mount_crypt_stat; -/* -* If the lower filename is encrypted, it will result in a significantly -* longer name. If needed, truncate the name after decode and decrypt. -*/ -if (mount_crypt_stat->flags &ECRYPTFS_GLOBAL_ENCRYPT_FILENAMES ) - lower_bufsiz =PATH_MAX ; -else - lower_bufsiz = bufsiz; -/* Released in this function */ lower_buf =kmalloc (lower_bufsiz,GFP_KERNEL ); -if (lower_buf ==NULL ) { -printk (KERN_ERR "%s: Out of memory whilst attempting to " -"kmalloc [%zd] bytes\n" , __func__, lower_bufsiz); +if (!lower_buf) { rc = -ENOMEM ; goto out; }
@@ -679,29 +658,31 @@ ecryptfs_readlink(struct dentry *dentry, (char __user *)lower_buf, lower_bufsiz);set_fs (old_fs); -if (rc >=0 ) { - rc =ecryptfs_decode_and_decrypt_filename (&plaintext_name, - &plaintext_name_size, - dentry, lower_buf, - rc); -if (rc) { -printk (KERN_ERR "%s: Error attempting to decode and " -"decrypt filename; rc = [%d]\n" , __func__, - rc); - goto out_free_lower_buf; - } -/* Check for bufsiz <= 0 done in sys_readlinkat() */ - rc =copy_to_user (buf, plaintext_name, -min ((size_t ) bufsiz, plaintext_name_size)); -if (rc) - rc = -EFAULT ; -else - rc = plaintext_name_size; -kfree (plaintext_name); -fsstack_copy_attr_atime (dentry->d_inode, lower_dentry->d_inode); - } -out_free_lower_buf: +if (rc <0 ) + goto out; + lower_bufsiz = rc; + rc =ecryptfs_decode_and_decrypt_filename (buf, bufsiz, dentry, + lower_buf, lower_bufsiz); +out:kfree (lower_buf); +return rc; +} + +static int +ecryptfs_readlink (struct dentry *dentry,char __user *buf,int bufsiz) +{ +char *kbuf; +size_t kbufsiz, copied; +int rc; + + rc =ecryptfs_readlink_lower (dentry, &kbuf, &kbufsiz); +if (rc) + goto out; + copied =min_t (size_t, bufsiz, kbufsiz); + rc =copy_to_user (buf, kbuf, copied) ? -EFAULT : copied; +kfree (kbuf); +fsstack_copy_attr_atime (dentry->d_inode, +ecryptfs_dentry_to_lower (dentry)->d_inode); out:return rc; }
@@ -971,6 +952,28 @@ out:return rc; } +int ecryptfs_getattr_link (struct vfsmount *mnt,struct dentry *dentry, +struct kstat *stat) +{ +struct ecryptfs_mount_crypt_stat *mount_crypt_stat; +int rc =0 ; + + mount_crypt_stat = &ecryptfs_superblock_to_private ( + dentry->d_sb)->mount_crypt_stat; +generic_fillattr (dentry->d_inode, stat); +if (mount_crypt_stat->flags &ECRYPTFS_GLOBAL_ENCRYPT_FILENAMES ) { +char *target; +size_t targetsiz; + + rc =ecryptfs_readlink_lower (dentry, &target, &targetsiz); +if (!rc) { +kfree (target); + stat->size = targetsiz; + } + } +return rc; +} +int ecryptfs_getattr (struct vfsmount *mnt,struct dentry *dentry,struct kstat *stat) {
@@ -1088,6 +1091,7 @@ const struct inode_operations ecryptfs_s .put_link = ecryptfs_put_link, .permission = ecryptfs_permission, .setattr = ecryptfs_setattr, + .getattr = ecryptfs_getattr_link, .setxattr = ecryptfs_setxattr, .getxattr = ecryptfs_getxattr, .listxattr = ecryptfs_listxattr,
PATCH 155/197 ecryptfs: fix error code for missing xattrs in lower fs
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Christian Pulvermacher <[email protected]>
commit cfce08c6bdfb20ade979284e55001ca1f100ed51 upstream.
If the lower file system driver has extended attributes disabled, ecryptfs' own access functions return -ENOSYS instead of -EOPNOTSUPP. This breaks execution of programs in the ecryptfs mount, since the kernel expects the latter error when checking for security capabilities in xattrs.
--- fs/ecryptfs/inode.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
fs/ecryptfs/inode.c +4 -4
@@ -998,7 +998,7 @@ ecryptfs_setxattr(struct dentry *dentry, lower_dentry =ecryptfs_dentry_to_lower (dentry);if (!lower_dentry->d_inode->i_op->setxattr) { - rc = -ENOSYS ; + rc = -EOPNOTSUPP ; goto out; }mutex_lock (&lower_dentry->d_inode->i_mutex);
@@ -1016,7 +1016,7 @@ ecryptfs_getxattr_lower(struct dentry *lint rc =0 ;if (!lower_dentry->d_inode->i_op->getxattr) { - rc = -ENOSYS ; + rc = -EOPNOTSUPP ; goto out; }mutex_lock (&lower_dentry->d_inode->i_mutex);
@@ -1043,7 +1043,7 @@ ecryptfs_listxattr(struct dentry *dentry lower_dentry =ecryptfs_dentry_to_lower (dentry);if (!lower_dentry->d_inode->i_op->listxattr) { - rc = -ENOSYS ; + rc = -EOPNOTSUPP ; goto out; }mutex_lock (&lower_dentry->d_inode->i_mutex);
@@ -1060,7 +1060,7 @@ static int ecryptfs_removexattr(struct d lower_dentry =ecryptfs_dentry_to_lower (dentry);if (!lower_dentry->d_inode->i_op->removexattr) { - rc = -ENOSYS ; + rc = -EOPNOTSUPP ; goto out; }mutex_lock (&lower_dentry->d_inode->i_mutex);
PATCH 156/197 sched: Fix a race between ttwu() and migrate_task()
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
Based on commit e2912009fb7b715728311b0d8fe327a1432b3f79 upstream, but done differently as this issue is not present in .33 or .34 kernels due to rework in this area.
If a task is in the TASK_WAITING state, then try_to_wake_up() is working on it, and it will place it on the correct cpu.
This commit ensures that neither migrate_task() nor __migrate_task() calls set_task_cpu(p) while p is in the TASK_WAKING state. Otherwise, there could be two concurrent calls to set_task_cpu(p), resulting in the task's cfs_rq being inconsistent with its cpu.
--- kernel/sched.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)
kernel/sched.c +5 -4
@@ -2116,12 +2116,10 @@ migrate_task(struct task_struct *p, int/* * If the task is not on a runqueue (and not running), then -* it is sufficient to simply update the task's cpu field. +* the next wake-up will properly place the task. */ -if (!p->se.on_rq && !task_running (rq, p)) { -set_task_cpu (p, dest_cpu); +if (!p->se.on_rq && !task_running (rq, p))return 0 ; - }init_completion (&req->done); req->task = p;
@@ -7167,6 +7165,9 @@ static int __migrate_task(struct task_st/* Already moved. */ if (task_cpu (p) != src_cpu) goto done; +/* Waking up, don't get in the way of try_to_wake_up(). */ +if (p->state ==TASK_WAKING ) + goto fail;/* Affinity changed (again). */ if (!cpumask_test_cpu (dest_cpu, &p->cpus_allowed)) goto fail;
PATCH 157/197 USB: cdc-acm: Update to new autopm API
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Oliver Neukum <[email protected]>
commit 97d35f95552c9a0ee4777a7f04431a9fd1260478 upstream.
Update cdc-acm to the async methods eliminating the workqueue
[This fixes a reported lockup for the cdc-acm driver - gregkh]
--- drivers/usb/class/cdc-acm.c | 43 ++++++++++++++++++++++--------------------- drivers/usb/class/cdc-acm.h | 1 - 2 files changed, 22 insertions(+), 22 deletions(-)
drivers/usb/class/cdc-acm.c +22 -21
@@ -170,6 +170,7 @@ static void acm_write_done(struct acm *a { wb->use =0 ; acm->transmitting--; +usb_autopm_put_interface_async (acm->control); }/*
@@ -211,9 +212,12 @@ static int acm_write_start(struct acm *a }dbg ("%s susp_count: %d" , __func__, acm->susp_count); +usb_autopm_get_interface_async (acm->control);if (acm->susp_count) { - acm->delayed_wb = wb; -schedule_work (&acm->waker); +if (!acm->delayed_wb) + acm->delayed_wb = wb; +else +usb_autopm_put_interface_async (acm->control);spin_unlock_irqrestore (&acm->write_lock, flags);return 0 ;/* A white lie */ }
@@ -534,23 +538,6 @@ static void acm_softint(struct work_strutty_kref_put (tty); } -static void acm_waker (struct work_struct *waker) -{ - struct acm *acm = container_of(waker, struct acm, waker); -int rv; - - rv =usb_autopm_get_interface (acm->control); -if (rv <0 ) { -dev_err (&acm->dev->dev,"Autopm failure in %s\n" , __func__); -return ; - } -if (acm->delayed_wb) { -acm_start_wb (acm, acm->delayed_wb); - acm->delayed_wb =NULL ; - } -usb_autopm_put_interface (acm->control); -} -/* * TTY handlers */
@@ -1178,7 +1165,6 @@ made_compressed_probe: acm->urb_task.func = acm_rx_tasklet; acm->urb_task.data = (unsigned long ) acm;INIT_WORK (&acm->work, acm_softint); -INIT_WORK (&acm->waker, acm_waker);init_waitqueue_head (&acm->drain_wait);spin_lock_init (&acm->throttle_lock);spin_lock_init (&acm->write_lock);
@@ -1343,7 +1329,6 @@ static void stop_data_traffic(struct acmtasklet_enable (&acm->urb_task);cancel_work_sync (&acm->work); -cancel_work_sync (&acm->waker); }static void acm_disconnect (struct usb_interface *intf)
@@ -1435,6 +1420,7 @@ static int acm_suspend(struct usb_interfstatic int acm_resume (struct usb_interface *intf) {struct acm *acm =usb_get_intfdata (intf); +struct acm_wb *wb;int rv =0 ;int cnt;
@@ -1449,6 +1435,21 @@ static int acm_resume(struct usb_interfamutex_lock (&acm->mutex);if (acm->port.count) { rv =usb_submit_urb (acm->ctrlurb,GFP_NOIO ); + +spin_lock_irq (&acm->write_lock); +if (acm->delayed_wb) { + wb = acm->delayed_wb; + acm->delayed_wb =NULL ; +spin_unlock_irq (&acm->write_lock); +acm_start_wb (acm, acm->delayed_wb); + }else { +spin_unlock_irq (&acm->write_lock); + } + +/* +* delayed error checking because we must +* do the write path at all cost +*/ if (rv <0 ) goto err_out;
drivers/usb/class/cdc-acm.h +0 -1
@@ -112,7 +112,6 @@ struct acm {struct mutex mutex;struct usb_cdc_line_coding line;/* bits, stop, parity */ struct work_struct work;/* work queue entry for line discipline waking up */ -struct work_struct waker;wait_queue_head_t drain_wait;/* close processing */ struct tasklet_struct urb_task;/* rx processing */ spinlock_t throttle_lock;/* synchronize throtteling and read callback */
PATCH 158/197 USB: cdc-acm: Fix stupid NULL pointer in resume()
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Oliver Neukum <[email protected]>
commit f0730924e9e32bb8935c60040a26d94179355088 upstream.
Stupid logic bug passing a just nulled pointer
--- drivers/usb/class/cdc-acm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/class/cdc-acm.c +1 -1
@@ -1441,7 +1441,7 @@ static int acm_resume(struct usb_interfa wb = acm->delayed_wb; acm->delayed_wb =NULL ;spin_unlock_irq (&acm->write_lock); -acm_start_wb (acm, acm->delayed_wb); +acm_start_wb (acm, wb); }else {spin_unlock_irq (&acm->write_lock); }
PATCH 159/197 iwlwifi: clear all tx queues when firmware ready
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Wey-Yi Guy <[email protected]>
commit dff010ac8e57e43669518a14c0e945dfeb80c2a7 upstream.
Reset and clear all the tx queues when finished downloading runtime uCode and ready to go into operation mode.
--- drivers/net/wireless/iwlwifi/iwl-4965.c | 2 ++ drivers/net/wireless/iwlwifi/iwl-5000.c | 2 ++ 2 files changed, 4 insertions(+)
drivers/net/wireless/iwlwifi/iwl-4965.c +2 -0
@@ -715,6 +715,8 @@ static int iwl4965_alive_notify(struct iiwl4965_set_wr_ptrs (priv,IWL_CMD_QUEUE_NUM ,0 ); +/* reset to 0 to enable all the queue first */ + priv->txq_ctx_active_msk =0 ;/* Map each Tx/cmd queue to its corresponding fifo */ for (i =0 ; i <ARRAY_SIZE (default_queue_to_tx_fifo); i++) {int ac = default_queue_to_tx_fifo[i];
drivers/net/wireless/iwlwifi/iwl-5000.c +2 -0
@@ -793,6 +793,8 @@ int iwl5000_alive_notify(struct iwl_priviwl5000_set_wr_ptrs (priv,IWL_CMD_QUEUE_NUM ,0 ); +/* reset to 0 to enable all the queue first */ + priv->txq_ctx_active_msk =0 ;/* map qos queues to fifos one-to-one */ for (i =0 ; i <ARRAY_SIZE (iwl5000_default_queue_to_tx_fifo); i++) {int ac = iwl5000_default_queue_to_tx_fifo[i];
PATCH 160/197 iwlwifi: fix scan race
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Reinette Chatre <[email protected]>
commit bbcbb9ef9735c67da303d30bd6beb9e699f0f508 upstream.
There is a problem if an "internal short scan" is in progress when a mac80211 requested scan arrives. If this new scan request arrives within the "next_scan_jiffies" period then driver will immediately return success and complete the scan. The problem here is that the scan has not been fully initialized at this time (is_internal_short_scan is still set to true because of the currently running scan), which results in the scan completion never to be sent to mac80211. At this time also, evan though the internal short scan is still running the state (is_internal_short_scan) will be set to false, so when the internal scan does complete then mac80211 will receive a scan completion.
Fix this by checking right away if a scan is in progress when a scan request arrives from mac80211.
--- drivers/net/wireless/iwlwifi/iwl-scan.c | 27 ++++++++++++--------------- 1 file changed, 12 insertions(+), 15 deletions(-)
drivers/net/wireless/iwlwifi/iwl-scan.c +12 -15
@@ -405,21 +405,6 @@ void iwl_init_scan_params(struct iwl_pristatic int iwl_scan_initiate (struct iwl_priv *priv) { -if (!iwl_is_ready_rf (priv)) { -IWL_DEBUG_SCAN (priv,"Aborting scan due to not ready.\n" ); -return -EIO ; - } - -if (test_bit (STATUS_SCANNING , &priv->status)) { -IWL_DEBUG_SCAN (priv,"Scan already in progress.\n" ); -return -EAGAIN ; - } - -if (test_bit (STATUS_SCAN_ABORTING , &priv->status)) { -IWL_DEBUG_SCAN (priv,"Scan request while abort pending\n" ); -return -EAGAIN ; - } -IWL_DEBUG_INFO (priv,"Starting scan...\n" );set_bit (STATUS_SCANNING , &priv->status); priv->scan_start = jiffies;
@@ -450,6 +435,18 @@ int iwl_mac_hw_scan(struct ieee80211_hw goto out_unlock; } +if (test_bit (STATUS_SCANNING , &priv->status)) { +IWL_DEBUG_SCAN (priv,"Scan already in progress.\n" ); + ret = -EAGAIN ; + goto out_unlock; + } + +if (test_bit (STATUS_SCAN_ABORTING , &priv->status)) { +IWL_DEBUG_SCAN (priv,"Scan request while abort pending\n" ); + ret = -EAGAIN ; + goto out_unlock; + } +/* We don't schedule scan within next_scan_jiffies period. * Avoid scanning during possible EAPOL exchange, return * success immediately.
PATCH 161/197 e1000e: stop cleaning when we reach tx_ring->next_to_use
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Terry Loftin <[email protected]>
commit dac876193cd79ced36d0462749ea47c05844fb49 upstream.
Tx ring buffers after tx_ring->next_to_use are volatile and could change, possibly causing a crash. Stop cleaning when we hit tx_ring->next_to_use.
--- drivers/net/e1000e/netdev.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/net/e1000e/netdev.c +2 -0
@@ -665,6 +665,8 @@ static bool e1000_clean_tx_irq(struct e1 i =0 ; } +if (i == tx_ring->next_to_use) +break ; eop = tx_ring->buffer_info[i].next_to_watch; eop_desc =E1000_TX_DESC (*tx_ring, eop); }
PATCH 162/197 r8169: offical fix for CVE-2009-4537 (overlength frame DMAs)
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Neil Horman <[email protected]>
commit c0cd884af045338476b8e69a61fceb3f34ff22f1 upstream.
Official patch to fix the r8169 frame length check error.
Based on this initial thread:
http://marc.info/?l=linux-netdev&m=126202972828626&w=1
This is the official patch to fix the frame length problems in the r8169 driver. As noted in the previous thread, while this patch incurs a performance hit on the driver, its possible to improve performance dynamically by updating the mtu and rx_copybreak values at runtime to return performance to what it was for those NICS which are unaffected by the ideosyncracy (if there are any).
Summary:
A while back Eric submitted a patch for r8169 in which the proper
allocated frame size was written to RXMaxSize to prevent the NIC from dmaing too much data. This was done in commit fdd7b4c3302c93f6833e338903ea77245eb510b4. A long time prior to that however, Francois posted 126fa4b9ca5d9d7cb7d46f779ad3bd3631ca387c, which expiclitly disabled the MaxSize setting due to the fact that the hardware behaved in odd ways when overlong frames were received on NIC's supported by this driver. This was mentioned in a security conference recently:
http://events.ccc.de/congress/2009/Fahrplan//events/3596.en.html
It seems that if we can't enable frame size filtering, then, as Eric correctly noticed, we can find ourselves DMA-ing too much data to a buffer, causing corruption. As a result is seems that we are forced to allocate a frame which is ready to handle a maximally sized receive.
This obviously has performance issues with it, so to mitigate that issue, this patch does two things:
1) Raises the copybreak value to the frame allocation size, which should force appropriately sized packets to get allocated on rx, rather than a full new 16k buffer.
2) This patch only disables frame filtering initially (i.e., during the NIC open), changing the MTU results in ring buffer allocation of a size in relation to the new mtu (along with a warning indicating that this is dangerous).
Because of item (2), individuals who can't cope with the performance hit (or can otherwise filter frames to prevent the bug), or who have hardware they are sure is unaffected by this issue, can manually lower the copybreak and reset the mtu such that performance is restored easily.
--- drivers/net/r8169.c | 29 ++++++++++++++++++++++++----- 1 file changed, 24 insertions(+), 5 deletions(-)
drivers/net/r8169.c +24 -5
@@ -186,7 +186,12 @@ static struct pci_device_id rtl8169_pci_MODULE_DEVICE_TABLE (pci, rtl8169_pci_tbl); -static int rx_copybreak =200 ; +/* +* we set our copybreak very high so that we don't have +* to allocate 16k frames all the time (see note in +* rtl8169_open() +*/ +static int rx_copybreak =16383 ;static int use_dac; static struct { u32 msg_enable;
@@ -3245,9 +3250,13 @@ static void __devexit rtl8169_remove_one }static void rtl8169_set_rxbufsize (struct rtl8169_private *tp, -struct net_device *dev) +unsigned int mtu) { -unsigned int max_frame = dev->mtu +VLAN_ETH_HLEN +ETH_FCS_LEN ; +unsigned int max_frame = mtu +VLAN_ETH_HLEN +ETH_FCS_LEN ; + +if (max_frame !=16383 ) +printk (KERN_WARNING "WARNING! Changing of MTU on this NIC" +"May lead to frame reception errors!\n" ); tp->rx_buf_sz = (max_frame >RX_BUF_SIZE ) ? max_frame :RX_BUF_SIZE ; }
@@ -3259,7 +3268,17 @@ static int rtl8169_open(struct net_devicint retval = -ENOMEM ; -rtl8169_set_rxbufsize (tp, dev); +/* +* Note that we use a magic value here, its wierd I know +* its done because, some subset of rtl8169 hardware suffers from +* a problem in which frames received that are longer than +* the size set in RxMaxSize register return garbage sizes +* when received. To avoid this we need to turn off filtering, +* which is done by setting a value of 16383 in the RxMaxSize register +* and allocating 16k frames to handle the largest possible rx value +* thats what the magic math below does. +*/ +rtl8169_set_rxbufsize (tp,16383 -VLAN_ETH_HLEN -ETH_FCS_LEN );/* * Rx and Tx desscriptors needs 256 bytes alignment.
@@ -3912,7 +3931,7 @@ static int rtl8169_change_mtu(struct netrtl8169_down (dev); -rtl8169_set_rxbufsize (tp, dev); +rtl8169_set_rxbufsize (tp, dev->mtu); ret =rtl8169_init_ring (dev);if (ret <0 )
PATCH 163/197 tcp: fix ICMP-RTO war
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Damian Lukowski <[email protected]>
commit 598856407d4e20ebb4de01a91a93d89325924d43 upstream.
Make sure, that TCP has a nonzero RTT estimation after three-way handshake. Currently, a listening TCP has a value of 0 for srtt, rttvar and rto right after the three-way handshake is completed with TCP timestamps disabled.
This will lead to corrupt RTO recalculation and retransmission flood when RTO is recalculated on backoff reversion as introduced in "Revert RTO on ICMP destination unreachable" (f1ecd5d9e7366609d640ff4040304ea197fbc618).
This behaviour can be provoked by connecting to a server which "responds first" (like SMTP) and rejecting every packet after the handshake with dest-unreachable, which will lead to softirq load on the server (up to 30% per socket in some tests).
Thanks to Ilpo Jarvinen for providing debug patches and to Denys Fedoryshchenko for reporting and testing.
Changes since v3: Removed bad characters in patchfile.
--- net/ipv4/tcp_input.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)
net/ipv4/tcp_input.c +2 -4
@@ -5699,11 +5699,9 @@ int tcp_rcv_state_process(struct sock *s/* tcp_ack considers this ACK as duplicate * and does not calculate rtt. -* Fix it at least with timestamps. +* Force it here. */ -if (tp->rx_opt.saw_tstamp && - tp->rx_opt.rcv_tsecr && !tp->srtt) -tcp_ack_saw_tstamp (sk,0 ); +tcp_ack_update_rtt (sk,0 ,0 );if (tp->rx_opt.tstamp_ok) tp->advmss -=TCPOLEN_TSTAMP_ALIGNED ;
PATCH 164/197 perf_events, x86: Implement Intel Westmere/Nehalem-EX support
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Peter Zijlstra <[email protected]>
original patch commit ids: 452a339a976e7f782c786eb3f73080401e2fa3a6 and 134fbadf028a5977a1b06b0253d3ee33e6f0c642
perf_events, x86: Implement Intel Westmere support
The new Intel documentation includes Westmere arch specific event maps that are significantly different from the Nehalem ones. Add support for this generation.
Found the CPUID model numbers on wikipedia.
Also ammend some Nehalem constraints, spotted those when looking for the differences between Nehalem and Westmere.
LKML-Reference: <[email protected]>
perf, x86: Enable Nehalem-EX support
According to Intel Software Devel Manual Volume 3B, the Nehalem-EX PMU is just like regular Nehalem (except for the uncore support, which is completely different).
LKML-Reference: <[email protected]>
---
--- arch/x86/kernel/cpu/perf_event.c | 104 ++++++++++++++++++++++++++++++++++++++- 1 file changed, 103 insertions(+), 1 deletion(-)
arch/x86/kernel/cpu/perf_event.c +103 -1
@@ -190,6 +190,97 @@ static u64 __read_mostly hw_cache_event_ [PERF_COUNT_HW_CACHE_OP_MAX ] [PERF_COUNT_HW_CACHE_RESULT_MAX ]; +static const u64 westmere_hw_cache_event_ids + [PERF_COUNT_HW_CACHE_MAX ] + [PERF_COUNT_HW_CACHE_OP_MAX ] + [PERF_COUNT_HW_CACHE_RESULT_MAX ] = +{ + [C (L1D ) ] = { + [C (OP_READ ) ] = { + [C (RESULT_ACCESS ) ] =0x010b ,/* MEM_INST_RETIRED.LOADS */ + [C (RESULT_MISS ) ] =0x0151 ,/* L1D.REPL */ + }, + [C (OP_WRITE ) ] = { + [C (RESULT_ACCESS ) ] =0x020b ,/* MEM_INST_RETURED.STORES */ + [C (RESULT_MISS ) ] =0x0251 ,/* L1D.M_REPL */ + }, + [C (OP_PREFETCH ) ] = { + [C (RESULT_ACCESS ) ] =0x014e ,/* L1D_PREFETCH.REQUESTS */ + [C (RESULT_MISS ) ] =0x024e ,/* L1D_PREFETCH.MISS */ + }, + }, + [C (L1I ) ] = { + [C (OP_READ ) ] = { + [C (RESULT_ACCESS ) ] =0x0380 ,/* L1I.READS */ + [C (RESULT_MISS ) ] =0x0280 ,/* L1I.MISSES */ + }, + [C (OP_WRITE ) ] = { + [C (RESULT_ACCESS ) ] =-1 , + [C (RESULT_MISS ) ] =-1 , + }, + [C (OP_PREFETCH ) ] = { + [C (RESULT_ACCESS ) ] =0x0 , + [C (RESULT_MISS ) ] =0x0 , + }, + }, + [C (LL ) ] = { + [C (OP_READ ) ] = { + [C (RESULT_ACCESS ) ] =0x0324 ,/* L2_RQSTS.LOADS */ + [C (RESULT_MISS ) ] =0x0224 ,/* L2_RQSTS.LD_MISS */ + }, + [C (OP_WRITE ) ] = { + [C (RESULT_ACCESS ) ] =0x0c24 ,/* L2_RQSTS.RFOS */ + [C (RESULT_MISS ) ] =0x0824 ,/* L2_RQSTS.RFO_MISS */ + }, + [C (OP_PREFETCH ) ] = { + [C (RESULT_ACCESS ) ] =0x4f2e ,/* LLC Reference */ + [C (RESULT_MISS ) ] =0x412e ,/* LLC Misses */ + }, + }, + [C (DTLB ) ] = { + [C (OP_READ ) ] = { + [C (RESULT_ACCESS ) ] =0x010b ,/* MEM_INST_RETIRED.LOADS */ + [C (RESULT_MISS ) ] =0x0108 ,/* DTLB_LOAD_MISSES.ANY */ + }, + [C (OP_WRITE ) ] = { + [C (RESULT_ACCESS ) ] =0x020b ,/* MEM_INST_RETURED.STORES */ + [C (RESULT_MISS ) ] =0x010c ,/* MEM_STORE_RETIRED.DTLB_MISS */ + }, + [C (OP_PREFETCH ) ] = { + [C (RESULT_ACCESS ) ] =0x0 , + [C (RESULT_MISS ) ] =0x0 , + }, + }, + [C (ITLB ) ] = { + [C (OP_READ ) ] = { + [C (RESULT_ACCESS ) ] =0x01c0 ,/* INST_RETIRED.ANY_P */ + [C (RESULT_MISS ) ] =0x0185 ,/* ITLB_MISSES.ANY */ + }, + [C (OP_WRITE ) ] = { + [C (RESULT_ACCESS ) ] =-1 , + [C (RESULT_MISS ) ] =-1 , + }, + [C (OP_PREFETCH ) ] = { + [C (RESULT_ACCESS ) ] =-1 , + [C (RESULT_MISS ) ] =-1 , + }, + }, + [C (BPU ) ] = { + [C (OP_READ ) ] = { + [C (RESULT_ACCESS ) ] =0x00c4 ,/* BR_INST_RETIRED.ALL_BRANCHES */ + [C (RESULT_MISS ) ] =0x03e8 ,/* BPU_CLEARS.ANY */ + }, + [C (OP_WRITE ) ] = { + [C (RESULT_ACCESS ) ] =-1 , + [C (RESULT_MISS ) ] =-1 , + }, + [C (OP_PREFETCH ) ] = { + [C (RESULT_ACCESS ) ] =-1 , + [C (RESULT_MISS ) ] =-1 , + }, + }, +}; +static const u64 nehalem_hw_cache_event_ids [PERF_COUNT_HW_CACHE_MAX ] [PERF_COUNT_HW_CACHE_OP_MAX ]
@@ -1999,6 +2090,7 @@ static int intel_pmu_init(void)* Install the hw-cache-events table: */ switch (boot_cpu_data.x86_model) { +case 15 :/* original 65 nm celeron/pentium/core2/xeon, "Merom"/"Conroe" */ case 22 :/* single-core 65 nm celeron/core2solo "Merom-L"/"Conroe-L" */ case 23 :/* current 45 nm celeron/core2/xeon "Penryn"/"Wolfdale" */
@@ -2009,7 +2101,9 @@ static int intel_pmu_init(void)pr_cont ("Core2 events, " );break ;default : -case 26 : +case 26 :/* 45 nm nehalem, "Bloomfield" */ +case 30 :/* 45 nm nehalem, "Lynnfield" */ +case 46 :/* 45 nm nehalem-ex, "Beckton" */ memcpy (hw_cache_event_ids, nehalem_hw_cache_event_ids,sizeof (hw_cache_event_ids));
@@ -2021,6 +2115,14 @@ static int intel_pmu_init(void)pr_cont ("Atom events, " );break ; + +case 37 :/* 32 nm nehalem, "Clarkdale" */ +case 44 :/* 32 nm nehalem, "Gulftown" */ +memcpy (hw_cache_event_ids, westmere_hw_cache_event_ids, +sizeof (hw_cache_event_ids)); + +pr_cont ("Westmere events, " ); +break ; }return 0 ; }
PATCH 165/197 ACPI: EC: Allow multibyte access to EC
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Alexey Starikovskiy <[email protected]>
commit dadf28a10c3eb29421837a2e413ab869ebd upstream
http://bugzilla.kernel.org/show_bug.cgi?id=14667
[bwh: Backport to 2.6.32; same applies to 2.6.33]
--- drivers/acpi/acpica/exprep.c | 12 ++++++++++++ drivers/acpi/ec.c | 35 +++++++++-------------------------- 2 files changed, 21 insertions(+), 26 deletions(-)
drivers/acpi/acpica/exprep.c +12 -0
@@ -468,6 +468,18 @@ acpi_status acpi_ex_prep_field_value(stracpi_ut_add_reference (obj_desc->field.region_obj); +/* allow full data read from EC address space */ +if (obj_desc->field.region_obj->region.space_id == +ACPI_ADR_SPACE_EC ) { +if (obj_desc->common_field.bit_length >8 ) + obj_desc->common_field.access_bit_width = +ACPI_ROUND_UP (obj_desc->common_field. + bit_length,8 ); + obj_desc->common_field.access_byte_width = +ACPI_DIV_8 (obj_desc->common_field. + access_bit_width); + } + ACPI_DEBUG_PRINT((ACPI_DB_BFIELD, "RegionField: BitOff %X, Off %X, Gran %X, Region %p\n", obj_desc->field.start_field_bit_offset,
drivers/acpi/ec.c +9 -26
@@ -588,12 +588,12 @@ static u32 acpi_ec_gpe_handler(void *datstatic acpi_status acpi_ec_space_handler (u32 function,acpi_physical_address address, -u32 bits,acpi_integer *value, +u32 bits,acpi_integer *value64,void *handler_context,void *region_context) {struct acpi_ec *ec = handler_context; -int result =0 , i; -u8 temp =0 ; +int result =0 , i, bytes = bits /8 ; +u8 *value = (u8 *)value64;if ((address >0xFF ) || !value || !handler_context)return AE_BAD_PARAMETER ;
@@ -601,32 +601,15 @@ acpi_ec_space_handler(u32 function, acpiif (function !=ACPI_READ && function !=ACPI_WRITE )return AE_BAD_PARAMETER ; -if (bits !=8 && acpi_strict) -return AE_BAD_PARAMETER ; - -if (EC_FLAGS_MSI ) +if (EC_FLAGS_MSI || bits >8 )acpi_ec_burst_enable (ec); -if (function ==ACPI_READ ) { - result =acpi_ec_read (ec, address, &temp); - *value = temp; - }else { - temp =0xff & (*value); - result =acpi_ec_write (ec, address, temp); - } - -for (i =8 ;unlikely (bits - i >0 ); i +=8 ) { - ++address; -if (function ==ACPI_READ ) { - result =acpi_ec_read (ec, address, &temp); - (*value) |= ((acpi_integer )temp) << i; - }else { - temp =0xff & ((*value) >> i); - result =acpi_ec_write (ec, address, temp); - } - } +for (i =0 ; i < bytes; ++i, ++address, ++value) + result = (function ==ACPI_READ ) ? +acpi_ec_read (ec, address, value) : +acpi_ec_write (ec, address, *value); -if (EC_FLAGS_MSI ) +if (EC_FLAGS_MSI || bits >8 )acpi_ec_burst_disable (ec);switch (result) {
Re: [165/197] ACPI: EC: Allow multibyte access to EC
Quoted 4 lines · Greg KH
From: Alexey Starikovskiy <[email protected]>
commit
dadf28a10c3eb29421837a2e413ab869ebdupstream
Hmm. Doesn't this need commit 2060c44576c79086ff24718878d7edaa7384a985 to fix things up for crazy access_bit_width values?
Maybe it's there in the series somewhere, but I didn't see it.
Linus
Re: [165/197] ACPI: EC: Allow multibyte access to EC
Quoted 4 lines · Linus Torvalds
Quoted 1 line · Greg KH
Quoted 8 lines
Quoted 3 lines
From: Alexey Starikovskiy <[email protected]>
commit
dadf28a10c3eb29421837a2e413ab869ebdupstreamHmm. Doesn't this need commit
2060c44576c79086ff24718878d7edaa7384a985to fix things up for crazyaccess_bit_widthvalues?Maybe it's there in the series somewhere, but I didn't see it.
Yes, it's two patches later:
Subject: [167/197] ACPI: EC: Limit burst to 64 bits
good catch.
thanks,
greg k-h
PATCH 166/197 md/raid5: allow for more than 2^31 chunks.
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: NeilBrown <[email protected]>
commit 35f2a591192d0a5d9f7fc696869c76f0b8e49c3d upstream.
With many large drives and small chunk sizes it is possible to create a RAID5 with more than 2^31 chunks. Make sure this works.
--- drivers/md/raid5.c | 19 +++++++------------ 1 file changed, 7 insertions(+), 12 deletions(-)
drivers/md/raid5.c +7 -12
@@ -1649,8 +1649,8 @@ static sector_t raid5_compute_sector(rai int previous, int *dd_idx, struct stripe_head *sh) { - long stripe; -unsigned long chunk_number; + sector_t stripe; +sector_t chunk_number;unsigned int chunk_offset;int pd_idx, qd_idx;int ddf_layout =0 ;
@@ -1670,17 +1670,12 @@ static sector_t raid5_compute_sector(rai*/ chunk_offset =sector_div (r_sector, sectors_per_chunk); chunk_number = r_sector; -BUG_ON (r_sector != chunk_number);/* * Compute the stripe number */ - stripe = chunk_number / data_disks; - -/* -* Compute the data disk and parity disk indexes inside the stripe -*/ - *dd_idx = chunk_number % data_disks; + stripe = chunk_number; + *dd_idx =sector_div (stripe, data_disks);/* * Select the parity disk based on the user selected algorithm.
@@ -1869,14 +1864,14 @@ static sector_t compute_blocknr(struct s : conf->algorithm;sector_t stripe;int chunk_offset; -int chunk_number, dummy1, dd_idx = i; +sector_t chunk_number; +int dummy1, dd_idx = i;sector_t r_sector;struct stripe_head sh2; chunk_offset =sector_div (new_sector, sectors_per_chunk); stripe = new_sector; -BUG_ON (new_sector != stripe);if (i == sh->pd_idx)return 0 ;
@@ -1969,7 +1964,7 @@ static sector_t compute_blocknr(struct s } chunk_number = stripe * data_disks + i; - r_sector = (sector_t )chunk_number * sectors_per_chunk + chunk_offset; + r_sector = chunk_number * sectors_per_chunk + chunk_offset; check =raid5_compute_sector (conf, r_sector, previous, &dummy1, &sh2);
Re: [Stable-review] [166/197] md/raid5: allow for more than 2^31 chunks.
Quoted 5 lines · On Thu, 22 Apr 2010 12:10:17 -0700 Greg KH <[email protected]> wrote:
2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
Quoted 7 lines
From: NeilBrown <[email protected]>
commit
35f2a591192d0a5d9f7fc696869c76f0b8e49c3dupstream.With many large drives and small chunk sizes it is possible to create a RAID5 with more than 2^31 chunks. Make sure this works.
Causes build failure on i686:
ERROR: "__umoddi3" [drivers/md/raid456.ko] undefined!
Re: [Stable-review] [166/197] md/raid5: allow for more than 2^31 chunks.
Quoted 12 lines · Chuck Ebbert
Quoted 9 lines · On Thu, 22 Apr 2010 12:10:17 -0700 Greg KH <[email protected]> wrote:
2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: NeilBrown <[email protected]>
commit
35f2a591192d0a5d9f7fc696869c76f0b8e49c3dupstream.
Quoted 8 lines
Quoted 3 lines
With many large drives and small chunk sizes it is possible to create a RAID5 with more than 2^31 chunks. Make sure this works.
Causes build failure on i686:
ERROR: "__umoddi3" [drivers/md/raid456.ko] undefined!
Yeah, that one is definitely not stable material as-is.
Linus
Re: [Stable-review] [166/197] md/raid5: allow for more than 2^31 chunks.
Quoted 20 lines · Linus Torvalds
Quoted 16 lines · Chuck Ebbert
Quoted 12 lines · On Thu, 22 Apr 2010 12:10:17 -0700 Greg KH <[email protected]> wrote:
2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: NeilBrown <[email protected]>
commit
35f2a591192d0a5d9f7fc696869c76f0b8e49c3dupstream.With many large drives and small chunk sizes it is possible to create a RAID5 with more than 2^31 chunks. Make sure this works.
Quoted 6 lines
Quoted 4 lines
Causes build failure on i686:
ERROR: "__umoddi3" [drivers/md/raid456.ko] undefined!Yeah, that one is definitely not stable material as-is.
Neil did post a patch to fix it, hopefully it gets into your tree soon.
thanks,
greg k-h
Re: [Stable-review] [166/197] md/raid5: allow for more than 2^31 chunks.
In reply to Chuck EbbertQuoted 12 lines · Chuck Ebbert
Quoted 9 lines · On Thu, 22 Apr 2010 12:10:17 -0700 Greg KH <[email protected]> wrote:
2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: NeilBrown <[email protected]>
commit
35f2a591192d0a5d9f7fc696869c76f0b8e49c3dupstream.
Quoted 8 lines
Quoted 3 lines
With many large drives and small chunk sizes it is possible to create a RAID5 with more than 2^31 chunks. Make sure this works.
Causes build failure on i686:
ERROR: "__umoddi3" [drivers/md/raid456.ko] undefined!
Ok, for now I've removed this patch from the .32 and .33 series, and will queue it up for the next round, once the build fix is in Linus's tree.
thanks,
greg k-h
PATCH 167/197 ACPI: EC: Limit burst to 64 bits
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Alexey Starikovskiy <[email protected]>
commit 2060c44576c79086ff24718878d7edaa7384a985 upstream.
access_bit_width field is u8 in ACPICA, thus 256 value written to it becomes 0, causing divide by zero later.
Proper fix would be to remove access_bit_width at all, just because we already have access_byte_width, which is access_bit_width / 8. Limit access width to 64 bit for now.
https://bugzilla.kernel.org/show_bug.cgi?id=15749
fixes regression caused by the fix for:
https://bugzilla.kernel.org/show_bug.cgi?id=14667
--- drivers/acpi/acpica/exprep.c | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-)
drivers/acpi/acpica/exprep.c +11 -6
@@ -471,13 +471,18 @@ acpi_status acpi_ex_prep_field_value(str/* allow full data read from EC address space */ if (obj_desc->field.region_obj->region.space_id ==ACPI_ADR_SPACE_EC ) { -if (obj_desc->common_field.bit_length >8 ) - obj_desc->common_field.access_bit_width = -ACPI_ROUND_UP (obj_desc->common_field. - bit_length,8 ); +if (obj_desc->common_field.bit_length >8 ) { +unsigned width = +ACPI_ROUND_BITS_UP_TO_BYTES ( + obj_desc->common_field.bit_length); +// access_bit_width is u8, don't overflow it +if (width >8 ) + width =8 ; obj_desc->common_field.access_byte_width = -ACPI_DIV_8 (obj_desc->common_field. - access_bit_width); + width; + obj_desc->common_field.access_bit_width = +8 * width; + } } ACPI_DEBUG_PRINT((ACPI_DB_BFIELD,
PATCH 168/197 Input: wacom - switch mode upon system resume
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Ping Cheng <[email protected]>
commit 014f61504af276ba9d9544d8a7401d8f8526eb73 upstream.
When Wacom devices wake up from a sleep, the switch mode command (wacom_query_tablet_data) is needed before wacom_open is called. wacom_query_tablet_data should not be executed inside wacom_open since wacom_open is called more than once during probe.
--- drivers/input/tablet/wacom_sys.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-)
drivers/input/tablet/wacom_sys.c +7 -3
@@ -562,11 +562,15 @@ static int wacom_resume(struct usb_interint rv;mutex_lock (&wacom->lock); -if (wacom->open) { + +/* switch to wacom mode first */ +wacom_query_tablet_data (intf); + +if (wacom->open) rv =usb_submit_urb (wacom->irq,GFP_NOIO ); -wacom_query_tablet_data (intf); - }else +else rv =0 ; +mutex_unlock (&wacom->lock);return rv;
PATCH 169/197 modules: fix incorrect percpu usage
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Mathieu Desnoyers <[email protected]>
Mainline does not need this fix, as commit 259354deaaf03d49a02dbb9975d6ec2a54675672 fixed the problem by refactoring.
Should use per_cpu_ptr() to obfuscate the per cpu pointers (RELOC_HIDE is needed for per cpu pointers).
Introduced by commit:
module.c: commit 6b588c18f8dacfa6d7957c33c5ff832096e752d3
This patch should be queued for the stable branch, for kernels 2.6.29.x to 2.6.33.x. (tested on 2.6.33.1 x86_64)
--- kernel/module.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/module.c +1 -1
@@ -555,7 +555,7 @@ static void percpu_modcopy(void *pcpudesint cpu;for_each_possible_cpu (cpu) - memcpy(pcpudest + per_cpu_offset(cpu), from, size); + memcpy(per_cpu_ptr(pcpudest, cpu), from, size); }#else /* ... !CONFIG_SMP */
Re: [169/197] modules: fix incorrect percpu usage
Quoted 12 lines · * Greg KH ([email protected]) wrote:
2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Mathieu Desnoyers <[email protected]>
Mainline does not need this fix, as commit
259354deaaf03d49a02dbb9975d6ec2a54675672fixed the problem by refactoring.Should use
per_cpu_ptr()to obfuscate the per cpu pointers (RELOC_HIDEis needed for per cpu pointers).
Quoted 6 lines
Introduced by commit:
module.c: commit6b588c18f8dacfa6d7957c33c5ff832096e752d3This patch should be queued for the stable branch, for kernels 2.6.29.x to 2.6.33.x. (tested on 2.6.33.1
x86_64)
Tejun, should this patch be applied to 2.6.32.x, or will it cause problems on ia64 ?
Thanks,
Mathieu
Quoted 31 lines
Signed-off-by Mathieu Desnoyers <[email protected]>CC Randy Dunlap <[email protected]>CC Eric Dumazet <[email protected]>CC Rusty Russell <[email protected]>CC Peter Zijlstra <[email protected]>CC Tejun Heo <[email protected]>CC Ingo Molnar <[email protected]>CC Andrew Morton <[email protected]>CC Linus Torvalds <[email protected]>CC Greg Kroah-Hartman <[email protected]>CC Steven Rostedt <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>--- kernel/module.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)kernel/module.c +1
-1@@ -555,7 +555,7 @@ static void percpu_modcopy(void *pcpudesint cpu;for_each_possible_cpu (cpu) - memcpy(pcpudest + per_cpu_offset(cpu), from, size); + memcpy(per_cpu_ptr(pcpudest, cpu), from, size); }#else /* ... !CONFIG_SMP */
Signature · 4 lines
Mathieu Desnoyers Operating System Efficiency R&D Consultant EfficiOS Inc. http://www.efficios.com
PATCH 170/197 lockdep: fix incorrect percpu usage
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Mathieu Desnoyers <[email protected]>
The mainline kernel as of 2.6.34-rc5 is not affected by this problem because commit 10fad5e46f6c7bdfb01b1a012380a38e3c6ab346 fixed it by refactoring.
lockdep fix incorrect percpu usage
Should use per_cpu_ptr() to obfuscate the per cpu pointers (RELOC_HIDE is needed for per cpu pointers).
git blame points to commit:
lockdep.c: commit 8e18257d29238311e82085152741f0c3aa18b74d
But it's really just moving the code around. But it's enough to say that the problems appeared before Jul 19 01:48:54 2007, which brings us back to 2.6.23.
It should be applied to stable 2.6.23.x to 2.6.33.x (or whichever of these stable branches are still maintained).
(tested on 2.6.33.1 x86_64)
--- kernel/lockdep.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
kernel/lockdep.c +3 -3
@@ -591,9 +591,9 @@ static int static_obj(void *obj)* percpu var? */ for_each_possible_cpu (i) { - start = (unsigned long ) &__per_cpu_start +per_cpu_offset (i); - end = (unsigned long ) &__per_cpu_start +PERCPU_ENOUGH_ROOM - +per_cpu_offset (i); + start = (unsigned long )per_cpu_ptr (&__per_cpu_start, i); + end = (unsigned long )per_cpu_ptr (&__per_cpu_start + +PERCPU_ENOUGH_ROOM , i);if ((addr >= start) && (addr < end))return 1 ;
Re: [Stable-review] [170/197] lockdep: fix incorrect percpu usage
Hi,
hmm,
this one seems to break compilation for me:kernel/lockdep.c: In function ‘static_obj’:kernel/lockdep.c:595: error: invalid use of array with unspecified bounds kernel/lockdep.c:595: error: invalid use of array with unspecified bounds make[1]: *** [kernel/lockdep.o] Error 1
I'm using gcc-4.1.2
regards
nik
Quoted 65 lines · Greg KH
2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Mathieu Desnoyers <[email protected]>
The mainline kernel as of 2.6.34-rc5 is not affected by this problem because commit
10fad5e46f6c7bdfb01b1a012380a38e3c6ab346fixed it by refactoring.lockdep fix incorrect percpu usage
Should use
per_cpu_ptr()to obfuscate the per cpu pointers (RELOC_HIDEis needed for per cpu pointers).git blame points to commit:
lockdep.c: commit8e18257d29238311e82085152741f0c3aa18b74dBut it's really just moving the code around. But it's enough to say that the problems appeared before Jul 19 01:48:54 2007, which brings us back to 2.6.23.
It should be applied to stable 2.6.23.x to 2.6.33.x (or whichever of these stable branches are still maintained).
(tested on 2.6.33.1
x86_64)Signed-off-by Mathieu Desnoyers <[email protected]>CC Randy Dunlap <[email protected]>CC Eric Dumazet <[email protected]>CC Rusty Russell <[email protected]>CC Peter Zijlstra <[email protected]>CC Tejun Heo <[email protected]>CC Ingo Molnar <[email protected]>CC Andrew Morton <[email protected]>CC Linus Torvalds <[email protected]>CC Greg Kroah-Hartman <[email protected]>CC Steven Rostedt <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>--- kernel/lockdep.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)kernel/lockdep.c +3
-3@@ -591,9 +591,9 @@ static int static_obj(void *obj)* percpu var? */ for_each_possible_cpu (i) { - start = (unsigned long ) &__per_cpu_start +per_cpu_offset (i); - end = (unsigned long ) &__per_cpu_start +PERCPU_ENOUGH_ROOM - +per_cpu_offset (i); + start = (unsigned long )per_cpu_ptr (&__per_cpu_start, i); + end = (unsigned long )per_cpu_ptr (&__per_cpu_start + +PERCPU_ENOUGH_ROOM , i);if ((addr >= start) && (addr < end))return 1 ;_______________________________________________
Stable-review mailing list
[email protected]
http://linux.kernel.org/mailman/listinfo/stable-review
Signature · 14 lines
------------------------------------- Ing. Nikola CIPRICH LinuxBox.cz, s.r.o. 28. rijna 168, 709 01 Ostrava tel.: +420 596 603 142 fax: +420 596 621 273 mobil: +420 777 093 799 www.linuxbox.cz mobil servis: +420 737 238 656 email servis: [email protected] -------------------------------------
Re: [Stable-review] [170/197] lockdep: fix incorrect percpu usage
Quoted 8 lines · * Nikola Ciprich ([email protected]) wrote:
Hi,
hmm,
this one seems to break compilation for me:kernel/lockdep.c: In function ‘static_obj’:kernel/lockdep.c:595: error: invalid use of array with unspecified boundskernel/lockdep.c:595: error: invalid use of array with unspecified bounds make[1]: *** [kernel/lockdep.o] Error 1
Quoted 4 lines
I'm using gcc-4.1.2
regards
nik
Oh, you are right. I tweaked a few config options and got your error. Here is an updated patch.
Greg, this v2 should replace the original patch you have. Sorry about the trouble.
lockdep fix incorrect percpu usage (v2)
Should use per_cpu_ptr() to obfuscate the per cpu pointers (RELOC_HIDE is needed for per cpu pointers).
Changelog since v1:
- Move PERCPU_ENOUGH_ROOM outside of per_cpu_ptr(), where it belongs.
git blame points to commit:
lockdep.c: commit 8e18257d29238311e82085152741f0c3aa18b74d
But it's really just moving the code around. But it's enough to say that the problems appeared before Jul 19 01:48:54 2007, which brings us back to 2.6.23.
This patch applies to mainline as of 2.6.34-rc2. It also should be applied to stable 2.6.23.x to 2.6.33.x (or whichever of these stable branches are still maintained).
(based on 2.6.33.1, also applies to 2.6.34-rc2 -tip)
--- kernel/lockdep.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
kernel/lockdep.c +3 -3
@@ -600,9 +600,9 @@ static int static_obj(void *obj)* percpu var? */ for_each_possible_cpu (i) { - start = (unsigned long ) &__per_cpu_start +per_cpu_offset (i); - end = (unsigned long ) &__per_cpu_start +PERCPU_ENOUGH_ROOM - +per_cpu_offset (i); + start = (unsigned long )per_cpu_ptr (&__per_cpu_start, i); + end = (unsigned long )per_cpu_ptr (&__per_cpu_start, i) + +PERCPU_ENOUGH_ROOM ;if ((addr >= start) && (addr < end))return 1 ;
Signature · 4 lines
Mathieu Desnoyers Operating System Efficiency R&D Consultant EfficiOS Inc. http://www.efficios.com
Re: [Stable-review] [170/197] lockdep: fix incorrect percpu usage
Quoted 14 lines · Mathieu Desnoyers
Quoted 8 lines · * Nikola Ciprich ([email protected]) wrote:
Hi,
hmm,
this one seems to break compilation for me:kernel/lockdep.c: In function ‘static_obj’:kernel/lockdep.c:595: error: invalid use of array with unspecified boundskernel/lockdep.c:595: error: invalid use of array with unspecified bounds make[1]: *** [kernel/lockdep.o] Error 1Quoted 4 lines
I'm using gcc-4.1.2
regards
nik
Quoted 5 lines
Oh, you are right. I tweaked a few config options and got your error. Here is an updated patch.
Greg, this v2 should replace the original patch you have. Sorry about the trouble.
No problem, I've fixed it up now.
thanks,
greg k-h
Re: [170/197] lockdep: fix incorrect percpu usage
In reply to Greg KHQuoted 16 lines · * Greg KH ([email protected]) wrote:
2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Mathieu Desnoyers <[email protected]>
The mainline kernel as of 2.6.34-rc5 is not affected by this problem because commit
10fad5e46f6c7bdfb01b1a012380a38e3c6ab346fixed it by refactoring.lockdep fix incorrect percpu usage
Should use
per_cpu_ptr()to obfuscate the per cpu pointers (RELOC_HIDEis needed for per cpu pointers).git blame points to commit:
Quoted 7 lines
lockdep.c: commit8e18257d29238311e82085152741f0c3aa18b74dBut it's really just moving the code around. But it's enough to say that the problems appeared before Jul 19 01:48:54 2007, which brings us back to 2.6.23.
It should be applied to stable 2.6.23.x to 2.6.33.x (or whichever of these stable branches are still maintained).
Tejun, (same as module.c patch) should this patch be applied to 2.6.32.x, or will it cause problems on ia64 ?
Thanks,
Mathieu
Quoted 37 lines
(tested on 2.6.33.1
x86_64)Signed-off-by Mathieu Desnoyers <[email protected]>CC Randy Dunlap <[email protected]>CC Eric Dumazet <[email protected]>CC Rusty Russell <[email protected]>CC Peter Zijlstra <[email protected]>CC Tejun Heo <[email protected]>CC Ingo Molnar <[email protected]>CC Andrew Morton <[email protected]>CC Linus Torvalds <[email protected]>CC Greg Kroah-Hartman <[email protected]>CC Steven Rostedt <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>--- kernel/lockdep.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)kernel/lockdep.c +3
-3@@ -591,9 +591,9 @@ static int static_obj(void *obj)* percpu var? */ for_each_possible_cpu (i) { - start = (unsigned long ) &__per_cpu_start +per_cpu_offset (i); - end = (unsigned long ) &__per_cpu_start +PERCPU_ENOUGH_ROOM - +per_cpu_offset (i); + start = (unsigned long )per_cpu_ptr (&__per_cpu_start, i); + end = (unsigned long )per_cpu_ptr (&__per_cpu_start + +PERCPU_ENOUGH_ROOM , i);if ((addr >= start) && (addr < end))return 1 ;
Signature · 4 lines
Mathieu Desnoyers Operating System Efficiency R&D Consultant EfficiOS Inc. http://www.efficios.com
PATCH 171/197 module: fix __module_ref_addr()
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Mathieu Desnoyers <[email protected]>
The __module_ref_addr() problem disappears in 2.6.34-rc kernels because these percpu accesses were re-factored.
__module_ref_addr() should use per_cpu_ptr() to obfuscate the pointer (RELOC_HIDE is needed for per cpu pointers).
This non-standard per-cpu pointer use has been introduced by commit 720eba31f47aeade8ec130ca7f4353223c49170f
It causes a NULL pointer exception on some configurations when CONFIG_TRACING is enabled on 2.6.33. This patch fixes the problem (acknowledged by Randy who reported the bug).
It did not appear to hurt previously because most of the accesses were done through local_inc, which probably obfuscated the access enough that no compiler optimizations were done. But with local_read() done when CONFIG_TRACING is active, this becomes a problem. Non-CONFIG_TRACING is probably affected as well (module.c contains local_set and local_read that use __module_ref_addr()), but I guess nobody noticed because we've been lucky enough that the compiler did not generate the inappropriate optimization pattern there.
This patch should be queued for the 2.6.29.x through 2.6.33.x stable branches. (tested on 2.6.33.1 x86_64)
--- include/linux/module.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
include/linux/module.h +1 -1
@@ -455,7 +455,7 @@ void symbol_put_addr(void *addr);static inline local_t *__module_ref_addr (struct module *mod,int cpu) {#ifdef CONFIG_SMP -return (local_t *) (mod->refptr +per_cpu_offset (cpu)); +return (local_t *)per_cpu_ptr (mod->refptr, cpu);#else return &mod->ref;#endif
Re: [171/197] module: fix __module_ref_addr()
Quoted 2 lines · Greg KH
__module_ref_addr()should useper_cpu_ptr()to obfuscate the pointer (RELOC_HIDEis needed for per cpu pointers).
Hi,
this patch triggers NaT consumption exception on IA64, at least with gcc 4.3.4:
------------
modprobe[151]: NaT consumption 2216203124768 [1]
Modules linked in:
Supported: Yes
Pid: 151, CPU 2, comm: modprobe
psr : 0000121009526030 ifs : 8000000000001430 ip : [<a000000100129871>] Not tainted (2.6.32.12-0.2-default)
ip is at load_module+0xdd1/0x2300
unat: 0000000000000000 pfs : 0000000000001430 rsc : 0000000000000003
rnat: a000000100b45e28 bsps: 0000000000000000 pr : 0000000000165a59
ldrs: 0000000000000000 ccv : 0000000000000000 fpsr: 0009804c0270033f csd : 0000000000000000 ssd : 0000000000000000
b0 : a000000100129830 b6 : a000000100122ae0 b7 : a000000100011370 f6 : 000000000000000000000 f7 : 1003ee21a291c077975b9 f8 : 1003e0000000000000089 f9 : 1003e0000000000000001 f10 : 1003e0000000000000089 f11 : 000000000000000000000 r1 : a0000001015befe0 r2 : 0000000000000000 r3 : 0000000000001000 r8 : 0000000000000000 r9 : a0000001013dcc70 r10 : a0000001013dcc70 r11 : 0000000000000008 r12 : e00000018b26fdc0 r13 : e00000018b260000 r14 : 0000000000000008 r15 : 0000000000000fc0 r16 : 0000000000000000 r17 : 0000000000000000 r18 : 0000000000000000 r19 : 0000000000000000 r20 : 00000000000000fe r21 : 0000000000000008 r22 : 0000000000004a68 r23 : 0000000000004a68 r24 : 0000000000004a68 r25 : 00000000ffff4a68 r26 : e0000001820f1ec0 r27 : 0000000000000000 r28 : 0000000000000000 r29 : 0000000000000003 r30 : 0000000000000004 r31 : 0000000000000002
Call Trace:
[<a000000100017a80>] show_stack+0x80/0xa0
sp=e00000018b26f910 bsp=e00000018b261438
[<a0000001000180e0>] show_regs+0x640/0x920
sp=e00000018b26fae0 bsp=e00000018b2613d8
[<a000000100029470>] die+0x190/0x2e0
sp=e00000018b26faf0 bsp=e00000018b261398
[<a000000100029610>] die_if_kernel+0x50/0x80
sp=e00000018b26faf0 bsp=e00000018b261368
[<a0000001008ea750>] ia64_fault+0xf0/0xda0
sp=e00000018b26faf0 bsp=e00000018b261320
[<a00000010000cb60>] ia64_native_leave_kernel+0x0/0x270
sp=e00000018b26fbf0 bsp=e00000018b261320
[<a000000100129870>] load_module+0xdd0/0x2300
sp=e00000018b26fdc0 bsp=e00000018b261198
[<a00000010012ae70>] sys_init_module+0xd0/0x620
sp=e00000018b26fe30 bsp=e00000018b261120
[<a00000010000c9c0>] ia64_ret_from_syscall+0x0/0x20
sp=e00000018b26fe30 bsp=e00000018b261120
[<a000000000010720>] __kernel_syscall_via_break+0x0/0x20
sp=e00000018b270000 bsp=e00000018b261120
------------It's dying here:
static inline local_t *__module_ref_addr(struct module *mod, int cpu) {
#ifdef CONFIG_SMP
---> return (local_t *) (mod->refptr + per_cpu_offset(cpu));
#else
return &mod->ref;#endif
}
This particular instance of __module_ref_addr is inlined in module_unload_init, which is inlined in load_module.
I don't know whether this is a gcc or a kernel bug but the code produced on IA64 is not what has been intended.
Comparing the code generated by gcc -S [1]. For the working case, i.e. (local_t *) (mod->refptr + per_cpu_offset(cpu)), per_cpu_offset(cpu) translates to:
ld8.mov r35 = [r83], __per_cpu_offset# // tmp2056, tmp2056,
...
sxt4 r18 = r8 // cpu, cpu
...
shladd r17 = r18, 3, r35 // tmp1140, cpu,, tmp2056
For the crashing case, i.e.
(local_t *) per_cpu_ptr(mod->refptr, cpu),per_cpu_offset(cpu) translates to:
sxt4 r17 = r8 // cpu, cpu
...
shladd r11 = r17, 3, r0 // tmp1140, cpu,
Note that r0 is always zero, which means __per_cpu_offset is considered to be always NULL.
The problem seems to be triggered by RELOC_HIDE. I don't understand gcc well enough to be able to tell what's going on here. Any ideas?
Thanks,
Jiri
[1] http://labs.suse.cz/jbenc/kernel/reloc_hide-ia64-crash/
Signature · 2 lines
Jiri Benc SUSE Labs
Re: [171/197] module: fix __module_ref_addr()
Quoted 92 lines · * Jiri Benc ([email protected]) wrote:
Quoted 2 lines · Greg KH
__module_ref_addr()should useper_cpu_ptr()to obfuscate the pointer (RELOC_HIDEis needed for per cpu pointers).Hi,
this patch triggers NaT consumption exception on IA64, at least with gcc 4.3.4:
------------
modprobe[151]: NaT consumption 2216203124768 [1]Modules linked in:Supported: Yes
Pid: 151, CPU 2, comm: modprobe
psr : 0000121009526030 ifs : 8000000000001430 ip : [<a000000100129871>] Not tainted (2.6.32.12-0.2-default)
ip is atload_module+0xdd1/0x2300
unat: 0000000000000000 pfs : 0000000000001430 rsc : 0000000000000003
rnat:a000000100b45e28bsps: 0000000000000000 pr :0000000000165a59
ldrs: 0000000000000000 ccv : 0000000000000000 fpsr:0009804c0270033fcsd : 0000000000000000 ssd : 0000000000000000
b0 :a000000100129830b6 :a000000100122ae0b7 :a000000100011370f6 : 000000000000000000000 f7 :1003ee21a291c077975b9f8 :1003e0000000000000089f9 :1003e0000000000000001f10 :1003e0000000000000089f11 : 000000000000000000000 r1 :a0000001015befe0r2 : 0000000000000000 r3 : 0000000000001000 r8 : 0000000000000000 r9 :a0000001013dcc70r10 :a0000001013dcc70r11 : 0000000000000008 r12 :e00000018b26fdc0r13 :e00000018b260000r14 : 0000000000000008 r15 :0000000000000fc0r16 : 0000000000000000 r17 : 0000000000000000 r18 : 0000000000000000 r19 : 0000000000000000 r20 :00000000000000fer21 : 0000000000000008 r22 :0000000000004a68r23 :0000000000004a68r24 :0000000000004a68r25 :00000000ffff4a68r26 :e0000001820f1ec0r27 : 0000000000000000 r28 : 0000000000000000 r29 : 0000000000000003 r30 : 0000000000000004 r31 : 0000000000000002Call Trace: [<a000000100017a80>] show_stack+0x80/0xa0 sp=e00000018b26f910 bsp=e00000018b261438 [<a0000001000180e0>] show_regs+0x640/0x920 sp=e00000018b26fae0 bsp=e00000018b2613d8 [<a000000100029470>] die+0x190/0x2e0 sp=e00000018b26faf0 bsp=e00000018b261398 [<a000000100029610>] die_if_kernel+0x50/0x80 sp=e00000018b26faf0 bsp=e00000018b261368 [<a0000001008ea750>] ia64_fault+0xf0/0xda0 sp=e00000018b26faf0 bsp=e00000018b261320 [<a00000010000cb60>] ia64_native_leave_kernel+0x0/0x270 sp=e00000018b26fbf0 bsp=e00000018b261320 [<a000000100129870>] load_module+0xdd0/0x2300 sp=e00000018b26fdc0 bsp=e00000018b261198 [<a00000010012ae70>] sys_init_module+0xd0/0x620 sp=e00000018b26fe30 bsp=e00000018b261120 [<a00000010000c9c0>] ia64_ret_from_syscall+0x0/0x20 sp=e00000018b26fe30 bsp=e00000018b261120 [<a000000000010720>] __kernel_syscall_via_break+0x0/0x20 sp=e00000018b270000 bsp=e00000018b261120 ------------It's dying here:
static inline
local_t*__module_ref_addr(struct module *mod, int cpu) {
#ifdefCONFIG_SMP
---> return (local_t*) (mod->refptr+per_cpu_offset(cpu));#else return &mod->ref;#endif
}This particular instance of
__module_ref_addris inlined inmodule_unload_init, which is inlined inload_module.I don't know whether this is a gcc or a kernel bug but the code produced on IA64 is not what has been intended.
Comparing the code generated by gcc -S [1]. For the working case, i.e. (
local_t*) (mod->refptr+per_cpu_offset(cpu)),per_cpu_offset(cpu)translates to:ld8.mov r35 = [r83], __per_cpu_offset# // tmp2056, tmp2056,
...
sxt4 r18 = r8 // cpu, cpu
...
shladd r17 = r18, 3, r35 // tmp1140, cpu,, tmp2056For the crashing case, i.e.
(local_t*)per_cpu_ptr(mod->refptr, cpu),per_cpu_offset(cpu)translates to:sxt4 r17 = r8 // cpu, cpu
...
shladd r11 = r17, 3, r0 // tmp1140, cpu,
Quoted 5 lines
Note that r0 is always zero, which means
__per_cpu_offsetis considered to be always NULL.The problem seems to be triggered by
RELOC_HIDE. I don't understand gcc well enough to be able to tell what's going on here. Any ideas?
Can you try reverting commit c8d52465f95c4187871f8e65666c07806ca06d41 and see if it helps ?
That would revert the =r constraint back to an =g in RELOC_HIDE. The move from =g to =r has originally been done to work around a ppc64 compiler bug in the first place. My gut feeling is that ia64 does something unexpected if we apply a =r constraint where we should not.
If you have other compiler versions handy, that would also be helpful to see if the problem is specific to the gcc version you are using.
Thanks,
Mathieu
Quoted 10 lines
Thanks,
Jiri
[1] http://labs.suse.cz/jbenc/kernel/reloc_hide-ia64-crash/
Signature · 2 lines
Jiri Benc SUSE Labs
Signature · 4 lines
Mathieu Desnoyers Operating System Efficiency R&D Consultant EfficiOS Inc. http://www.efficios.com
Re: [171/197] module: fix __module_ref_addr()
Quoted 2 lines · Mathieu Desnoyers
Can you try reverting commit
c8d52465f95c4187871f8e65666c07806ca06d41and see if it helps ?
It doesn't. The produced code is identical.
Quoted 2 lines
If you have other compiler versions handy, that would also be helpful to see if the problem is specific to the gcc version you are using.
Tried 4.5.0, the same problem (at least looking at the produced assembler code, I haven't booted the kernel, but it looks very similar to 4.3.3).
Thanks,
Jiri
Signature · 2 lines
Jiri Benc SUSE Labs
Re: [171/197] module: fix __module_ref_addr()
Quoted 11 lines · Jiri Benc
Quoted 2 lines · Mathieu Desnoyers
Can you try reverting commit
c8d52465f95c4187871f8e65666c07806ca06d41and see if it helps ?It doesn't. The produced code is identical.
Quoted 2 lines
If you have other compiler versions handy, that would also be helpful to see if the problem is specific to the gcc version you are using.
Tried 4.5.0, the same problem (at least looking at the produced assembler code, I haven't booted the kernel, but it looks very similar to 4.3.3).
I wrote on the bugzilla but this is not a compiler bug but the -stable patch shouldn't have been applied only to 2.6.33. Not 2.6.32. This is because till 2.6.32, ia64 hadn't been converted to dynamic percpu allocator, so its static and dynamic percpu areas were separate and the per_cpu_ptr() wouldn't do the offsetting the module code expects there. So, please revert the patch from 2.6.32.
Thanks.
Signature · 1 line
tejun
Re: [171/197] module: fix __module_ref_addr()
Quoted 13 lines · Tejun Heo
Quoted 11 lines · Jiri Benc
Quoted 2 lines · Mathieu Desnoyers
Can you try reverting commit
c8d52465f95c4187871f8e65666c07806ca06d41and see if it helps ?It doesn't. The produced code is identical.
Quoted 2 lines
If you have other compiler versions handy, that would also be helpful to see if the problem is specific to the gcc version you are using.
Tried 4.5.0, the same problem (at least looking at the produced assembler code, I haven't booted the kernel, but it looks very similar to 4.3.3).
Quoted 6 lines
I wrote on the bugzilla but this is not a compiler bug but the -stable patch shouldn't have been applied only to 2.6.33. Not 2.6.32. This is because till 2.6.32, ia64 hadn't been converted to dynamic percpu allocator, so its static and dynamic percpu areas were separate and the
per_cpu_ptr()wouldn't do the offsetting the module code expects there. So, please revert the patch from 2.6.32.
Ah crap, I missed that. I'll go revert it from .32 now, sorry about that.
greg k-h
Re: [171/197] module: fix __module_ref_addr()
Quoted 21 lines · * Greg KH ([email protected]) wrote:
Quoted 13 lines · Tejun Heo
Quoted 11 lines · Jiri Benc
Quoted 2 lines · Mathieu Desnoyers
Can you try reverting commit
c8d52465f95c4187871f8e65666c07806ca06d41and see if it helps ?It doesn't. The produced code is identical.
Quoted 2 lines
If you have other compiler versions handy, that would also be helpful to see if the problem is specific to the gcc version you are using.
Tried 4.5.0, the same problem (at least looking at the produced assembler code, I haven't booted the kernel, but it looks very similar to 4.3.3).
Quoted 6 lines
I wrote on the bugzilla but this is not a compiler bug but the -stable patch shouldn't have been applied only to 2.6.33. Not 2.6.32. This is because till 2.6.32, ia64 hadn't been converted to dynamic percpu allocator, so its static and dynamic percpu areas were separate and the
per_cpu_ptr()wouldn't do the offsetting the module code expects there. So, please revert the patch from 2.6.32.
Quoted 4 lines
Ah crap, I missed that. I'll go revert it from .32 now, sorry about that.
greg k-h
My bad, I indicated that it should be applied to 2.6.29.x through 2.6.33.x in the changelog.
Sorry,
Mathieu
Signature · 4 lines
Mathieu Desnoyers Operating System Efficiency R&D Consultant EfficiOS Inc. http://www.efficios.com
Re: [stable] [171/197] module: fix __module_ref_addr()
In reply to Greg KHQuoted 21 lines · Greg KH
Quoted 13 lines · Tejun Heo
Quoted 11 lines · Jiri Benc
Quoted 2 lines · Mathieu Desnoyers
Can you try reverting commit
c8d52465f95c4187871f8e65666c07806ca06d41and see if it helps ?It doesn't. The produced code is identical.
Quoted 2 lines
If you have other compiler versions handy, that would also be helpful to see if the problem is specific to the gcc version you are using.
Tried 4.5.0, the same problem (at least looking at the produced assembler code, I haven't booted the kernel, but it looks very similar to 4.3.3).
Quoted 6 lines
I wrote on the bugzilla but this is not a compiler bug but the -stable patch shouldn't have been applied only to 2.6.33. Not 2.6.32. This is because till 2.6.32, ia64 hadn't been converted to dynamic percpu allocator, so its static and dynamic percpu areas were separate and the
per_cpu_ptr()wouldn't do the offsetting the module code expects there. So, please revert the patch from 2.6.32.
Quoted 2 lines
Ah crap, I missed that. I'll go revert it from .32 now, sorry about that.
And of course, I forgot to do that before releasing the next .32 kernel. It will be in the one after this one. bah.
greg k-h
PATCH 172/197 md: deal with merge_bvec_fn in component devices better.
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: NeilBrown <[email protected]>
commit 627a2d3c29427637f4c5d31ccc7fcbd8d312cd71 upstream.
If a component device has a merge_bvec_fn then as we never call it we must ensure we never need to. Currently this is done by setting max_sector to 1 PAGE, however this does not stop a bio being created with several sub-page iovecs that would violate the merge_bvec_fn.
So instead set max_phys_segments to 1 and set the segment boundary to the same as a page boundary to ensure there is only ever one single-page segment of IO requested at a time.
This can particularly be an issue when 'xen' is used as it is known to submit multiple small buffers in a single bio.
--- drivers/md/linear.c | 12 +++++++----- drivers/md/multipath.c | 20 ++++++++++++-------- drivers/md/raid0.c | 13 +++++++------ drivers/md/raid10.c | 28 +++++++++++++++++----------- 4 files changed, 43 insertions(+), 30 deletions(-)
drivers/md/linear.c +7 -5
@@ -172,12 +172,14 @@ static linear_conf_t *linear_conf(mddev_disk_stack_limits (mddev->gendisk, rdev->bdev, rdev->data_offset <<9 );/* as we don't honour merge_bvec_fn, we must never risk -* violating it, so limit ->max_sector to one PAGE, as -* a one page request is never in violation. +* violating it, so limit max_phys_segments to 1 lying within +* a single page. */ -if (rdev->bdev->bd_disk->queue->merge_bvec_fn && -queue_max_sectors (mddev->queue) > (PAGE_SIZE >>9 )) -blk_queue_max_sectors (mddev->queue,PAGE_SIZE >>9 ); +if (rdev->bdev->bd_disk->queue->merge_bvec_fn) { +blk_queue_max_phys_segments (mddev->queue,1 ); +blk_queue_segment_boundary (mddev->queue, +PAGE_CACHE_SIZE -1 ); + } conf->array_sectors += rdev->sectors; cnt++;
drivers/md/multipath.c +12 -8
@@ -301,14 +301,16 @@ static int multipath_add_disk(mddev_t *m rdev->data_offset << 9);/* as we don't honour merge_bvec_fn, we must never risk -* violating it, so limit ->max_sector to one PAGE, as -* a one page request is never in violation. +* violating it, so limit ->max_phys_segments to one, lying +* within a single page. * (Note: it is very unlikely that a device with * merge_bvec_fn will be involved in multipath.) */ -if (q->merge_bvec_fn && -queue_max_sectors (q) > (PAGE_SIZE >>9 )) -blk_queue_max_sectors (mddev->queue,PAGE_SIZE >>9 ); +if (q->merge_bvec_fn) { +blk_queue_max_phys_segments (mddev->queue,1 ); +blk_queue_segment_boundary (mddev->queue, +PAGE_CACHE_SIZE -1 ); + } conf->working_disks++; mddev->degraded--;
@@ -476,9 +478,11 @@ static int multipath_run (mddev_t *mddev/* as we don't honour merge_bvec_fn, we must never risk * violating it, not that we ever expect a device with * a merge_bvec_fn to be involved in multipath */ -if (rdev->bdev->bd_disk->queue->merge_bvec_fn && -queue_max_sectors (mddev->queue) > (PAGE_SIZE >>9 )) -blk_queue_max_sectors (mddev->queue,PAGE_SIZE >>9 ); +if (rdev->bdev->bd_disk->queue->merge_bvec_fn) { +blk_queue_max_phys_segments (mddev->queue,1 ); +blk_queue_segment_boundary (mddev->queue, +PAGE_CACHE_SIZE -1 ); + }if (!test_bit (Faulty, &rdev->flags)) conf->working_disks++;
drivers/md/raid0.c +7 -6
@@ -176,14 +176,15 @@ static int create_strip_zones(mddev_t *mdisk_stack_limits (mddev->gendisk, rdev1->bdev, rdev1->data_offset <<9 );/* as we don't honour merge_bvec_fn, we must never risk -* violating it, so limit ->max_sector to one PAGE, as -* a one page request is never in violation. +* violating it, so limit ->max_phys_segments to 1, lying within +* a single page. */ -if (rdev1->bdev->bd_disk->queue->merge_bvec_fn && -queue_max_sectors (mddev->queue) > (PAGE_SIZE >>9 )) -blk_queue_max_sectors (mddev->queue,PAGE_SIZE >>9 ); - +if (rdev1->bdev->bd_disk->queue->merge_bvec_fn) { +blk_queue_max_phys_segments (mddev->queue,1 ); +blk_queue_segment_boundary (mddev->queue, +PAGE_CACHE_SIZE -1 ); + }if (!smallest || (rdev1->sectors < smallest->sectors)) smallest = rdev1; cnt++;
drivers/md/raid10.c +17 -11
@@ -1155,13 +1155,17 @@ static int raid10_add_disk(mddev_t *mddedisk_stack_limits (mddev->gendisk, rdev->bdev, rdev->data_offset <<9 ); -/* as we don't honour merge_bvec_fn, we must never risk -* violating it, so limit ->max_sector to one PAGE, as -* a one page request is never in violation. +/* as we don't honour merge_bvec_fn, we must +* never risk violating it, so limit +* ->max_phys_segments to one lying with a single +* page, as a one page request is never in +* violation. */ -if (rdev->bdev->bd_disk->queue->merge_bvec_fn && -queue_max_sectors (mddev->queue) > (PAGE_SIZE >>9 )) -blk_queue_max_sectors (mddev->queue,PAGE_SIZE >>9 ); +if (rdev->bdev->bd_disk->queue->merge_bvec_fn) { +blk_queue_max_phys_segments (mddev->queue,1 ); +blk_queue_segment_boundary (mddev->queue, +PAGE_CACHE_SIZE -1 ); + } p->head_position =0 ; rdev->raid_disk = mirror;
@@ -2155,12 +2159,14 @@ static int run(mddev_t *mddev)disk_stack_limits (mddev->gendisk, rdev->bdev, rdev->data_offset <<9 );/* as we don't honour merge_bvec_fn, we must never risk -* violating it, so limit ->max_sector to one PAGE, as -* a one page request is never in violation. +* violating it, so limit max_phys_segments to 1 lying +* within a single page. */ -if (rdev->bdev->bd_disk->queue->merge_bvec_fn && -queue_max_sectors (mddev->queue) > (PAGE_SIZE >>9 )) -blk_queue_max_sectors (mddev->queue,PAGE_SIZE >>9 ); +if (rdev->bdev->bd_disk->queue->merge_bvec_fn) { +blk_queue_max_phys_segments (mddev->queue,1 ); +blk_queue_segment_boundary (mddev->queue, +PAGE_CACHE_SIZE -1 ); + } disk->head_position =0 ; }
PATCH 173/197 nfsd4: dont try to map gids in generic rpc code
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: J. Bruce Fields <[email protected]>
commit dc83d6e27fa80babe31c80aa8568f125f72edf57 upstream.
For nfsd we provide users the option of mapping uid's to server-side supplementary group lists. That makes sense for nfsd, but not necessarily for other rpc users (such as the callback client).
So move that lookup to svcauth_unix_set_client, which is a program-specific method.
--- net/sunrpc/svcauth_unix.c | 53 ++++++++++++++++++++++++++-------------------- 1 file changed, 30 insertions(+), 23 deletions(-)
net/sunrpc/svcauth_unix.c +30 -23
@@ -655,23 +655,25 @@ static struct unix_gid *unix_gid_lookup(return NULL ; } -static int unix_gid_find (uid_t uid,struct group_info **gip, -struct svc_rqst *rqstp) +static struct group_info *unix_gid_find (uid_t uid,struct svc_rqst *rqstp) { -struct unix_gid *ug =unix_gid_lookup (uid); +struct unix_gid *ug; +struct group_info *gi; +int ret; + + ug =unix_gid_lookup (uid);if (!ug) -return -EAGAIN ; -switch (cache_check (&unix_gid_cache, &ug->h, &rqstp->rq_chandle)) { +return ERR_PTR (-EAGAIN ); + ret =cache_check (&unix_gid_cache, &ug->h, &rqstp->rq_chandle); +switch (ret) {case -ENOENT : - *gip =NULL ; -return 0 ; +return ERR_PTR (-ENOENT );case 0 : - *gip = ug->gi; -get_group_info (*gip); + gi =get_group_info (ug->gi);cache_put (&ug->h, &unix_gid_cache); -return 0 ; +return gi;default : -return -EAGAIN ; +return ERR_PTR (-EAGAIN ); } }
@@ -681,6 +683,8 @@ svcauth_unix_set_client(struct svc_rqststruct sockaddr_in *sin;struct sockaddr_in6 *sin6, sin6_storage;struct ip_map *ipm; +struct group_info *gi; +struct svc_cred *cred = &rqstp->rq_cred;switch (rqstp->rq_addr.ss_family) {case AF_INET :
@@ -722,6 +726,17 @@ svcauth_unix_set_client(struct svc_rqstip_map_cached_put (rqstp, ipm);break ; } + + gi =unix_gid_find (cred->cr_uid, rqstp); +switch (PTR_ERR (gi)) { +case -EAGAIN : +return SVC_DROP ; +case -ENOENT : +break ; +default : +put_group_info (cred->cr_group_info); + cred->cr_group_info = gi; + }return SVC_OK ; }
@@ -818,19 +833,11 @@ svcauth_unix_accept(struct svc_rqst *rqs slen =svc_getnl (argv);/* gids length */ if (slen >16 || (len -= (slen +2 )*4 ) <0 ) goto badcred; -if (unix_gid_find (cred->cr_uid, &cred->cr_group_info, rqstp) - == -EAGAIN ) + cred->cr_group_info =groups_alloc (slen); +if (cred->cr_group_info ==NULL )return SVC_DROP ; -if (cred->cr_group_info ==NULL ) { - cred->cr_group_info =groups_alloc (slen); -if (cred->cr_group_info ==NULL ) -return SVC_DROP ; -for (i =0 ; i < slen; i++) -GROUP_AT (cred->cr_group_info, i) =svc_getnl (argv); - }else { -for (i =0 ; i < slen ; i++) -svc_getnl (argv); - } +for (i =0 ; i < slen; i++) +GROUP_AT (cred->cr_group_info, i) =svc_getnl (argv);if (svc_getu32 (argv) !=htonl (RPC_AUTH_NULL ) ||svc_getu32 (argv) !=0 ) { *authp = rpc_autherr_badverf;return SVC_DENIED ;
PATCH 174/197 Revert "sunrpc: fix peername failed on closed listener"
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: J. Bruce Fields <[email protected]>
commit f5822754ea006563e1bf0a1f43faaad49c0d8bb2 upstream.
This reverts commit b292cf9ce70d221c3f04ff62db5ab13d9a249ca8. The commit that it attempted to patch up, b0401d725334a94d57335790b8ac2404144748ee, was fundamentally wrong, and will also be reverted.
--- net/sunrpc/svc_xprt.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
net/sunrpc/svc_xprt.c +1 -2
@@ -711,8 +711,7 @@ int svc_recv(struct svc_rqst *rqstp, lonspin_unlock_bh (&pool->sp_lock); len =0 ; -if (test_bit (XPT_LISTENER , &xprt->xpt_flags) && - !test_bit (XPT_CLOSE , &xprt->xpt_flags)) { +if (test_bit (XPT_LISTENER , &xprt->xpt_flags)) {struct svc_xprt *newxpt; newxpt = xprt->xpt_ops->xpo_accept (xprt);if (newxpt) {
PATCH 175/197 Revert "sunrpc: move the close processing after do recvfrom method"
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: J. Bruce Fields <[email protected]>
commit 1b644b6e6f6160ae35ce4b52c2ca89ed3e356e18 upstream.
This reverts commit b0401d725334a94d57335790b8ac2404144748ee, which moved svc_delete_xprt() outside of XPT_BUSY, and allowed it to be called after svc_xpt_recived(), removing its last reference and destroying it after it had already been queued for future processing.
--- net/sunrpc/svc_xprt.c | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-)
net/sunrpc/svc_xprt.c +5 -7
@@ -711,7 +711,10 @@ int svc_recv(struct svc_rqst *rqstp, lonspin_unlock_bh (&pool->sp_lock); len =0 ; -if (test_bit (XPT_LISTENER , &xprt->xpt_flags)) { +if (test_bit (XPT_CLOSE , &xprt->xpt_flags)) { +dprintk ("svc_recv: found XPT_CLOSE\n" ); +svc_delete_xprt (xprt); + }else if (test_bit (XPT_LISTENER , &xprt->xpt_flags)) {struct svc_xprt *newxpt; newxpt = xprt->xpt_ops->xpo_accept (xprt);if (newxpt) {
@@ -737,7 +740,7 @@ int svc_recv(struct svc_rqst *rqstp, lonsvc_xprt_received (newxpt); }svc_xprt_received (xprt); - }else if (!test_bit (XPT_CLOSE , &xprt->xpt_flags)) { + }else {dprintk ("svc: server %p, pool %u, transport %p, inuse=%d\n" , rqstp, pool->sp_id, xprt,atomic_read (&xprt->xpt_ref.refcount));
@@ -750,11 +753,6 @@ int svc_recv(struct svc_rqst *rqstp, londprintk ("svc: got len=%d\n" , len); } -if (test_bit (XPT_CLOSE , &xprt->xpt_flags)) { -dprintk ("svc_recv: found XPT_CLOSE\n" ); -svc_delete_xprt (xprt); - } -/* No data, incomplete (TCP) read, or accept() */ if (len ==0 || len == -EAGAIN ) { rqstp->rq_res.len =0 ;
PATCH 176/197 nfsd: ensure sockets are closed on error
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Neil Brown <[email protected]>
commit 301e99ce4a2f42a317129230fd42e6cd874c64b0 upstream.
One the changes in commit d7979ae4a "svc: Move close processing to a single place" is:
err_delete:
- svc_delete_socket(svsk);
+ set_bit(SK_CLOSE, &svsk->sk_flags);
return -EAGAIN;This is insufficient. The recvfrom methods must always call svc_xprt_received on completion so that the socket gets re-queued if there is any more work to do. This particular path did not make that call because it actually destroyed the svsk, making requeue pointless. When the svc_delete_socket was change to just set a bit, we should have added a call to svc_xprt_received,
This is the problem that b0401d7253 attempted to fix, incorrectly.
--- net/sunrpc/svcsock.c | 1 + 1 file changed, 1 insertion(+)
net/sunrpc/svcsock.c +1 -0
@@ -968,6 +968,7 @@ static int svc_tcp_recv_record(struct svreturn len; err_delete:set_bit (XPT_CLOSE , &svsk->sk_xprt.xpt_flags); +svc_xprt_received (&svsk->sk_xprt); err_again:return -EAGAIN ; }
PATCH 177/197 ALSA: hda: Set Front Mic to input vref 50% for Lenovo 3000 Y410
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Daniel T Chen <[email protected]>
commit e2595322a3a353a59cecd7f57e7aa421ecb02d12 upstream.
The OR has verified with hda-verb that the internal microphone needs VREF50 set for audible capture.
--- sound/pci/hda/patch_realtek.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-)
sound/pci/hda/patch_realtek.c +9 -1
@@ -10621,6 +10621,13 @@ static struct hda_verb alc262_lenovo_300 {} }; +static struct hda_verb alc262_lenovo_3000_init_verbs[] = { +/* Front Mic pin: input vref at 50% */ + {0x19 ,AC_VERB_SET_PIN_WIDGET_CONTROL ,PIN_VREF50 }, + {0x19 ,AC_VERB_SET_AMP_GAIN_MUTE ,AMP_OUT_MUTE }, + {} +}; +static struct hda_input_mux alc262_fujitsu_capture_source = { .num_items =3 , .items = {
@@ -11688,7 +11695,8 @@ static struct alc_config_preset alc262_p [ALC262_LENOVO_3000] = { .mixers = { alc262_lenovo_3000_mixer }, .init_verbs = { alc262_init_verbs, alc262_EAPD_verbs, - alc262_lenovo_3000_unsol_verbs }, + alc262_lenovo_3000_unsol_verbs, + alc262_lenovo_3000_init_verbs }, .num_dacs = ARRAY_SIZE(alc262_dac_nids), .dac_nids = alc262_dac_nids, .hp_nid = 0x03,
PATCH 178/197 mac80211: fix deferred hardware scan requests
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Johannes Berg <[email protected]>
commit c0ce77b8323c1a0d4eeef97caf16c0ea971222a9 upstream.
Reinette found the reason for the warnings that happened occasionally when a hw-offloaded scan finished; her description of the problem:
mac80211 will defer the handling of scan requests if it is busy with management work at the time. The scan requests are deferred and run after the work has completed. When this occurs there are currently two problems.
* The scan request for hardware scan is not fully populated with the band and channels to scan not initialized.
* When the scan is queued the state is not correctly updated to reflect that a scan is in progress. The problem here is that when the driver completes the scan and calls ieee80211_scan_completed() a warning will be triggered since mac80211 was not aware that a scan was in progress.
The reason is that the queued scan work will start the hw scan right away when the hw_scan_req struct has already been allocated. However, in the first pass it will not have been filled, which happens at the same time as setting the bits. To fix this, simply move the allocation after the pending work test as well, so that the first iteration of the scan work will call __ieee80211_start_scan() even in the hardware scan case.
--- net/mac80211/scan.c | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-)
net/mac80211/scan.c +10 -8
@@ -408,6 +408,16 @@ static int __ieee80211_start_scan(structif (local->scan_req)return -EBUSY ; +if (req != local->int_scan_req && + sdata->vif.type ==NL80211_IFTYPE_STATION && + !list_empty (&ifmgd->work_list)) { +/* actually wait for the work it's doing to finish/time out */ +set_bit (IEEE80211_STA_REQ_SCAN , &ifmgd->request); + local->scan_req = req; + local->scan_sdata = sdata; +return 0 ; + } +if (local->ops->hw_scan) {u8 *ies;int ielen;
@@ -428,14 +438,6 @@ static int __ieee80211_start_scan(struct local->scan_req = req; local->scan_sdata = sdata; -if (req != local->int_scan_req && - sdata->vif.type ==NL80211_IFTYPE_STATION && - !list_empty (&ifmgd->work_list)) { -/* actually wait for the work it's doing to finish/time out */ -set_bit (IEEE80211_STA_REQ_SCAN , &ifmgd->request); -return 0 ; - } -if (local->ops->hw_scan)__set_bit (SCAN_HW_SCANNING , &local->scanning);else
PATCH 178/197 mac80211: fix deferred hardware scan requests
As Luis Rodriguez pointed out, I should have cc'd linux-wireless on this from the beginning. I hope no one has any objections to this going out as part of the next stable drop.
Thanks
-- Chase
---------- Forwarded message ----------
From: Greg KH <[email protected]>
Date: Thu, Apr 22, 2010 at 3:10 PM
Subject: [178/197] mac80211: fix deferred hardware scan requests
To: [email protected], [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], Johannes Berg <[email protected]>, "John W. Linville" <[email protected]>, Chase Douglas <[email protected]>
2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Johannes Berg <[email protected]>
commit c0ce77b8323c1a0d4eeef97caf16c0ea971222a9 upstream.
Reinette found the reason for the warnings that
happened occasionally when a hw-offloaded scan
finished; her description of the problem:
mac80211 will defer the handling of scan requests if it is busy with management work at the time. The scan requests are deferred and run after the work has completed. When this occurs there are currently two problems.
* The scan request for hardware scan is not fully populated with the band and channels to scan not initialized.
* When the scan is queued the state is not correctly updated to reflect that a scan is in progress. The problem here is that when the driver completes the scan and calls ieee80211_scan_completed() a warning will be triggered since mac80211 was not aware that a scan was in progress.
The reason is that the queued scan work will start the hw scan right away when the hw_scan_req struct has already been allocated. However, in the first pass it will not have been filled, which happens at the same time as setting the bits. To fix this, simply move the allocation after the pending work test as well, so that the first iteration of the scan work will call __ieee80211_start_scan() even in the hardware scan case.
---
net/mac80211/scan.c | 18 ++++++++++--------
1 file changed, 10 insertions(+), 8 deletions(-)
net/mac80211/scan.c +0 -0
@@ -408,6 +408,16 @@ static int __ieee80211_start_scan(struct
if (local->scan_req)
return -EBUSY;
+ if (req != local->int_scan_req &&
+ sdata->vif.type == NL80211_IFTYPE_STATION &&
+ !list_empty(&ifmgd->work_list)) {
+ /* actually wait for the work it's doing to finish/time out */
+ set_bit(IEEE80211_STA_REQ_SCAN, &ifmgd->request);
+ local->scan_req = req;
+ local->scan_sdata = sdata;
+ return 0;
+ }
+
if (local->ops->hw_scan) {
u8 *ies;
int ielen;
@@ -428,14 +438,6 @@ static int __ieee80211_start_scan(struct local->scan_req = req;
local->scan_sdata = sdata;
- if (req != local->int_scan_req &&
- sdata->vif.type == NL80211_IFTYPE_STATION &&
- !list_empty(&ifmgd->work_list)) {
- /* actually wait for the work it's doing to finish/time out */
- set_bit(IEEE80211_STA_REQ_SCAN, &ifmgd->request);
- return 0;
- }
-
if (local->ops->hw_scan)
__set_bit(SCAN_HW_SCANNING, &local->scanning); else
PATCH 179/197 fs-writeback: Add helper function to start writeback if idle
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Eric Sandeen <[email protected]>
commit 17bd55d037a02b04d9119511cfd1a4b985d20f63 upstream.
ext4, at least, would like to start pushing on writeback if it starts to get close to ENOSPC when reserving worst-case blocks for delalloc writes. Writing out delalloc data will convert those worst-case predictions into usually smaller actual usage, freeing up space before we hit ENOSPC based on this speculation.
Thanks to Jens for the suggestion for the helper function, & the naming help.
I've made the helper return status on whether writeback was started even though I don't plan to use it in the ext4 patch; it seems like it would be potentially useful to test this in some cases.
--- fs/fs-writeback.c | 17 +++++++++++++++++ include/linux/writeback.h | 1 + 2 files changed, 18 insertions(+)
fs/fs-writeback.c +17 -0
@@ -1213,6 +1213,23 @@ void writeback_inodes_sb(struct super_blEXPORT_SYMBOL (writeback_inodes_sb);/** +* writeback_inodes_sb_if_idle - start writeback if none underway +* @sb: the superblock +* +* Invoke writeback_inodes_sb if no writeback is currently underway. +* Returns 1 if writeback was started, 0 if not. +*/ +int writeback_inodes_sb_if_idle (struct super_block *sb) +{ +if (!writeback_in_progress (sb->s_bdi)) { +writeback_inodes_sb (sb); +return 1 ; + }else +return 0 ; +} +EXPORT_SYMBOL (writeback_inodes_sb_if_idle); + +/** * sync_inodes_sb - sync sb inode pages * @sb: the superblock *
include/linux/writeback.h +1 -0
@@ -69,6 +69,7 @@ struct writeback_control {struct bdi_writeback ;int inode_wait (void *);void writeback_inodes_sb (struct super_block *); +int writeback_inodes_sb_if_idle (struct super_block *);void sync_inodes_sb (struct super_block *);void writeback_inodes_wbc (struct writeback_control *wbc);long wb_do_writeback (struct bdi_writeback *wb,int force_wait);
PATCH 180/197 ext4: flush delalloc blocks when space is low
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Eric Sandeen <[email protected]>
commit c8afb44682fcef6273e8b8eb19fab13ddd05b386 upstream.
Creating many small files in rapid succession on a small filesystem can lead to spurious ENOSPC; on a 104MB filesystem:
for i in seq 1 22500; do
echo -n > $SCRATCH_MNT/$i
echo XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > $SCRATCH_MNT/$i
done
leads to ENOSPC even though after a sync, 40% of the fs is free again.
This is because we reserve worst-case metadata for delalloc writes, and when data is allocated that worst-case reservation is not usually needed.
When freespace is low, kicking off an async writeback will start converting that worst-case space usage into something more realistic, almost always freeing up space to continue.
This resolves the testcase for me, and survives all 4 generic ENOSPC tests in xfstests.
We'll still need a hard synchronous sync to squeeze out the last bit, but this fixes things up to a large degree.
--- fs/ext4/inode.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-)
fs/ext4/inode.c +9 -2
@@ -3031,11 +3031,18 @@ static int ext4_nonda_switch(struct supeif (2 * free_blocks <3 * dirty_blocks || free_blocks < (dirty_blocks +EXT4_FREEBLOCKS_WATERMARK )) {/* -* free block count is less that 150% of dirty blocks -* or free blocks is less that watermark +* free block count is less than 150% of dirty blocks +* or free blocks is less than watermark */ return 1 ; } +/* +* Even if we don't switch but are nearing capacity, +* start pushing delalloc when 1/2 of free blocks are dirty. +*/ +if (free_blocks <2 * dirty_blocks) +writeback_inodes_sb_if_idle (sb); +return 0 ; }
PATCH 181/197 ext4: fix async i/o writes beyond 4GB to a sparse file
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Eric Sandeen <[email protected]>
commit a1de02dccf906faba2ee2d99cac56799bda3b96a upstream.
The "offset" member in ext4_io_end holds bytes, not blocks, so ext4_lblk_t is wrong - and too small (u32).
This caused the async i/o writes to sparse files beyond 4GB to fail when they wrapped around to 0.
Also fix up the type of arguments to ext4_convert_unwritten_extents(), it gets ssize_t from ext4_end_aio_dio_nolock() and ext4_ext_direct_IO().
--- fs/ext4/ext4.h | 6 +++--- fs/ext4/extents.c | 2 +- fs/ext4/inode.c | 2 +- 3 files changed, 5 insertions(+), 5 deletions(-)
fs/ext4/ext4.h +3 -3
@@ -139,8 +139,8 @@ typedef struct ext4_io_end {struct inode *inode;/* file being written to */ unsigned int flag;/* unwritten or not */ int error;/* I/O error code */ -ext4_lblk_t offset;/* offset in the file */ -size_t size;/* size of the extent */ +loff_t offset;/* offset in the file */ +ssize_t size;/* size of the extent */ struct work_struct work;/* data work queue */ } ext4_io_end_t;
@@ -1740,7 +1740,7 @@ extern void ext4_ext_release(struct supeextern long ext4_fallocate (struct inode *inode,int mode,loff_t offset,loff_t len);extern int ext4_convert_unwritten_extents (struct inode *inode,loff_t offset, -loff_t len); +ssize_t len);extern int ext4_get_blocks (handle_t *handle,struct inode *inode,sector_t block,unsigned int max_blocks,struct buffer_head *bh,int flags);
fs/ext4/extents.c +1 -1
@@ -3547,7 +3547,7 @@ retry:* Returns 0 on success. */ int ext4_convert_unwritten_extents (struct inode *inode,loff_t offset, -loff_t len) +ssize_t len) {handle_t *handle;ext4_lblk_t block;
fs/ext4/inode.c +1 -1
@@ -3547,7 +3547,7 @@ static int ext4_end_aio_dio_nolock(ext4_ {struct inode *inode = io->inode;loff_t offset = io->offset; -size_t size = io->size; +ssize_t size = io->size;int ret =0 ; ext4_debug("end_aio_dio_onlock: io 0x%p from inode %lu,list->next 0x%p,"
PATCH 182/197 tpm: autoload tpm_tis based on system PnP IDs
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Matt Domsch <[email protected]>
commit 31bde71c202722a76686c3cf69a254c8a912275a upstream.
The tpm_tis driver already has a list of supported pnp_device_ids. This patch simply exports that list as a MODULE_DEVICE_TABLE() so that the module autoloader will discover and load the module at boottime.
--- drivers/char/tpm/tpm_tis.c | 1 + 1 file changed, 1 insertion(+)
drivers/char/tpm/tpm_tis.c +1 -0
@@ -637,6 +637,7 @@ static struct pnp_device_id tpm_pnp_tbl[ {"", 0}, /* User Specified */ {"", 0} /* Terminator */ }; +MODULE_DEVICE_TABLE (pnp, tpm_pnp_tbl); static __devexit void tpm_tis_pnp_remove(struct pnp_dev *dev) {
PATCH 183/197 IB/iser: Rewrite SG handling for RDMA logic
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Or Gerlitz <[email protected]>
commit c1ccaf2478f84c2665cf57f981db143aa582d646 upstream.
After dma-mapping an SG list provided by the SCSI midlayer, iser has to make sure the mapped SG is "aligned for RDMA" in the sense that its possible to produce one mapping in the HCA IOMMU which represents the whole SG. Next, the mapped SG is formatted for registration with the HCA.
This patch re-writes the logic that does the above, to make it clearer and simpler. It also fixes a bug in the being aligned for RDMA checks, where a "start" check wasn't done but rather only "end" check.
[commit message in RH kernel tree: "Under heavy load, without the patch, the HCA can be programmed to write (corrupt) into pages/location which doesn't belong to the SG associated with the actual I/O and cause a kernel oops."]
--- drivers/infiniband/ulp/iser/iser_memory.c | 120 +++++++++++++----------------- 1 file changed, 55 insertions(+), 65 deletions(-)
drivers/infiniband/ulp/iser/iser_memory.c +55 -65
@@ -209,6 +209,8 @@ void iser_finalize_rdma_unaligned_sg(str mem_copy->copy_buf =NULL ; } +#define IS_4K_ALIGNED (addr) ((((unsigned long)addr) & ~MASK_4K) == 0) +/** * iser_sg_to_page_vec - Translates scatterlist entries to physical addresses * and returns the length of resulting physical address array (may be less than
@@ -221,62 +223,52 @@ void iser_finalize_rdma_unaligned_sg(str* where --few fragments of the same page-- are present in the SG as * consecutive elements. Also, it handles one entry SG. */ +static int iser_sg_to_page_vec (struct iser_data_buf *data,struct iser_page_vec *page_vec,struct ib_device *ibdev) { -struct scatterlist *sgl = (struct scatterlist *)data->buf; -struct scatterlist *sg; -u64 first_addr, last_addr, page; -int end_aligned; -unsigned int cur_page =0 ; +struct scatterlist *sg, *sgl = (struct scatterlist *)data->buf; +u64 start_addr, end_addr, page, chunk_start =0 ;unsigned long total_sz =0 ; -int i; +unsigned int dma_len; +int i, new_chunk, cur_page, last_ent = data->dma_nents -1 ;/* compute the offset of first element */ page_vec->offset = (u64 ) sgl[0 ].offset & ~MASK_4K ; + new_chunk =1 ; + cur_page =0 ;for_each_sg (sgl, sg, data->dma_nents, i) { -unsigned int dma_len =ib_sg_dma_len (ibdev, sg); - + start_addr =ib_sg_dma_address (ibdev, sg); +if (new_chunk) + chunk_start = start_addr; + dma_len =ib_sg_dma_len (ibdev, sg); + end_addr = start_addr + dma_len; total_sz += dma_len; - first_addr =ib_sg_dma_address (ibdev, sg); - last_addr = first_addr + dma_len; - - end_aligned = !(last_addr & ~MASK_4K ); - -/* continue to collect page fragments till aligned or SG ends */ -while (!end_aligned && (i +1 < data->dma_nents)) { - sg =sg_next (sg); - i++; - dma_len =ib_sg_dma_len (ibdev, sg); - total_sz += dma_len; - last_addr =ib_sg_dma_address (ibdev, sg) + dma_len; - end_aligned = !(last_addr & ~MASK_4K ); +/* collect page fragments until aligned or end of SG list */ +if (!IS_4K_ALIGNED (end_addr) && i < last_ent) { + new_chunk =0 ; +continue ; } + new_chunk =1 ; -/* handle the 1st page in the 1st DMA element */ -if (cur_page ==0 ) { - page = first_addr &MASK_4K ; - page_vec->pages[cur_page] = page; - cur_page++; +/* address of the first page in the contiguous chunk; +masking relevant for the very first SG entry, +which might be unaligned */ + page = chunk_start &MASK_4K ; +do { + page_vec->pages[cur_page++] = page; page +=SIZE_4K ; - }else - page = first_addr; - -for (; page < last_addr; page +=SIZE_4K ) { - page_vec->pages[cur_page] = page; - cur_page++; - } - + }while (page < end_addr); } + page_vec->data_size = total_sz;iser_dbg ("page_vec->data_size:%d cur_page %d\n" , page_vec->data_size,cur_page);return cur_page; } -#define IS_4K_ALIGNED (addr) ((((unsigned long)addr) & ~MASK_4K) == 0)/** * iser_data_buf_aligned_len - Tries to determine the maximal correctly aligned
@@ -284,42 +276,40 @@ static int iser_sg_to_page_vec(struct is* the number of entries which are aligned correctly. Supports the case where * consecutive SG elements are actually fragments of the same physcial page. */ -static unsigned int iser_data_buf_aligned_len (struct iser_data_buf *data, -struct ib_device *ibdev) +static int iser_data_buf_aligned_len (struct iser_data_buf *data, +struct ib_device *ibdev) { -struct scatterlist *sgl, *sg; -u64 end_addr, next_addr; -int i, cnt; -unsigned int ret_len =0 ; +struct scatterlist *sgl, *sg, *next_sg =NULL ; +u64 start_addr, end_addr; +int i, ret_len, start_check =0 ; + +if (data->dma_nents ==1 ) +return 1 ; sgl = (struct scatterlist *)data->buf; + start_addr =ib_sg_dma_address (ibdev, sgl); - cnt =0 ;for_each_sg (sgl, sg, data->dma_nents, i) { -/* iser_dbg("Checking sg iobuf [%d]: phys=0x%08lX " -"offset: %ld sz: %ld\n", i, -(unsigned long)sg_phys(sg), -(unsigned long)sg->offset, -(unsigned long)sg->length); */ - end_addr =ib_sg_dma_address (ibdev, sg) + -ib_sg_dma_len (ibdev, sg); -/* iser_dbg("Checking sg iobuf end address " -"0x%08lX\n", end_addr); */ -if (i +1 < data->dma_nents) { - next_addr =ib_sg_dma_address (ibdev,sg_next (sg)); -/* are i, i+1 fragments of the same page? */ -if (end_addr == next_addr) { - cnt++; -continue ; - }else if (!IS_4K_ALIGNED (end_addr)) { - ret_len = cnt +1 ; -break ; - } - } - cnt++; +if (start_check && !IS_4K_ALIGNED (start_addr)) +break ; + + next_sg =sg_next (sg); +if (!next_sg) +break ; + + end_addr = start_addr +ib_sg_dma_len (ibdev, sg); + start_addr =ib_sg_dma_address (ibdev, next_sg); + +if (end_addr == start_addr) { + start_check =0 ; +continue ; + }else + start_check =1 ; + +if (!IS_4K_ALIGNED (end_addr)) +break ; } -if (i == data->dma_nents) - ret_len = cnt;/* loop ended */ + ret_len = (next_sg) ? i : i+1 ;iser_dbg ("Found %d aligned entries out of %d in sg:0x%p\n" , ret_len, data->dma_nents, data);return ret_len;
PATCH 184/197 mptctl : Remove printk which floods unnecessary messages to var/log/message
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Kashyap, Desai <[email protected]>
commit e39e145dfb78d4e20d89139d2576306b4279c126 upstream.
--- drivers/message/fusion/mptctl.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-)
drivers/message/fusion/mptctl.c +1 -4
@@ -621,11 +621,8 @@ __mptctl_ioctl(struct file *file, unsign*/ iocnumX = khdr.iocnum &0xFF ;if (((iocnum =mpt_verify_adapter (iocnumX, &iocp)) <0 ) || - (iocp ==NULL )) { - printk(KERN_DEBUG MYNAM "%s::mptctl_ioctl() @%d - ioc%d not found!\n", - __FILE__, __LINE__, iocnumX); + (iocp ==NULL ))return -ENODEV ; - }if (!iocp->active) { printk(KERN_DEBUG MYNAM "%s::mptctl_ioctl() @%d - Controller disabled.\n",
PATCH 185/197 mptspi: Fix for incorrect data underrun errata
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Kashyap, Desai <[email protected]>
commit 9b53b39243cf23a0b68eaa16c37ce16eada69a46 upstream.
Errata:
Certain conditions on the scsi bus may casue the 53C1030 to incorrectly signal a SCSI_DATA_UNDERRUN to the host.
Workaround 1:
For an Errata on LSI53C1030 When the length of request data and transfer data are different with result of command (READ or VERIFY), DID_SOFT_ERROR is set.
Workaround 2:
For potential trouble on LSI53C1030. It is checked whether the length of request data is equal to the length of transfer and residual. MEDIUM_ERROR is set by incorrect data.
--- drivers/message/fusion/mptscsih.c | 86 +++++++++++++++++++++++++++++++++++--- 1 file changed, 81 insertions(+), 5 deletions(-)
drivers/message/fusion/mptscsih.c +81 -5
@@ -792,11 +792,36 @@ mptscsih_io_done(MPT_ADAPTER *ioc, MPT_F* precedence! */ sc->result = (DID_OK <<16 ) | scsi_status; -if (scsi_state &MPI_SCSI_STATE_AUTOSENSE_VALID ) { -/* Have already saved the status and sense data +if (!(scsi_state &MPI_SCSI_STATE_AUTOSENSE_VALID )) { + +/* +* For an Errata on LSI53C1030 +* When the length of request data +* and transfer data are different +* with result of command (READ or VERIFY), +* DID_SOFT_ERROR is set. */ - ; - }else { +if (ioc->bus_type ==SPI ) { +if (pScsiReq->CDB[0 ] ==READ_6 || + pScsiReq->CDB[0 ] ==READ_10 || + pScsiReq->CDB[0 ] ==READ_12 || + pScsiReq->CDB[0 ] ==READ_16 || + pScsiReq->CDB[0 ] ==VERIFY || + pScsiReq->CDB[0 ] ==VERIFY_16 ) { +if (scsi_bufflen (sc) != + xfer_cnt) { + sc->result = +DID_SOFT_ERROR <<16 ; +printk (KERN_WARNING "Errata" +"on LSI53C1030 occurred." +"sc->req_bufflen=0x%02x," +"xfer_cnt=0x%02x\n" , +scsi_bufflen (sc), + xfer_cnt); + } + } + } +if (xfer_cnt < sc->underflow) {if (scsi_status ==SAM_STAT_BUSY ) sc->result =SAM_STAT_BUSY ;
@@ -835,7 +860,58 @@ mptscsih_io_done(MPT_ADAPTER *ioc, MPT_F sc->result = (DID_OK <<16 ) | scsi_status;if (scsi_state ==0 ) { ; - }else if (scsi_state &MPI_SCSI_STATE_AUTOSENSE_VALID ) { + }else if (scsi_state & +MPI_SCSI_STATE_AUTOSENSE_VALID ) { + +/* +* For potential trouble on LSI53C1030. +* (date:2007.xx.) +* It is checked whether the length of +* request data is equal to +* the length of transfer and residual. +* MEDIUM_ERROR is set by incorrect data. +*/ +if ((ioc->bus_type ==SPI ) && + (sc->sense_buffer[2 ] &0x20 )) { +u32 difftransfer; + difftransfer = + sc->sense_buffer[3 ] <<24 | + sc->sense_buffer[4 ] <<16 | + sc->sense_buffer[5 ] <<8 | + sc->sense_buffer[6 ]; +if (((sc->sense_buffer[3 ] &0x80 ) == +0x80 ) && (scsi_bufflen (sc) + != xfer_cnt)) { + sc->sense_buffer[2 ] = +MEDIUM_ERROR ; + sc->sense_buffer[12 ] =0xff ; + sc->sense_buffer[13 ] =0xff ; +printk (KERN_WARNING "Errata" +"on LSI53C1030 occurred." +"sc->req_bufflen=0x%02x," +"xfer_cnt=0x%02x\n" , +scsi_bufflen (sc), + xfer_cnt); + } +if (((sc->sense_buffer[3 ] &0x80 ) + !=0x80 ) && + (scsi_bufflen (sc) != + xfer_cnt + difftransfer)) { + sc->sense_buffer[2 ] = +MEDIUM_ERROR ; + sc->sense_buffer[12 ] =0xff ; + sc->sense_buffer[13 ] =0xff ; +printk (KERN_WARNING +"Errata on LSI53C1030 occurred" +"sc->req_bufflen=0x%02x," +" xfer_cnt=0x%02x," +"difftransfer=0x%02x\n" , +scsi_bufflen (sc), + xfer_cnt, + difftransfer); + } + } +/* * If running against circa 200003dd 909 MPT f/w, * may get this (AUTOSENSE_VALID) for actual TASK_SET_FULL
PATCH 186/197 sched: Use proper type in sched_getaffinity()
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: KOSAKI Motohiro <[email protected]>
commit 8bc037fb89bb3104b9ae290d18c877624cd7d9cc upstream.
Using the proper type fixes the following compiler warning:
kernel/sched.c:4850: warning: comparison of distinct pointer types lacks a cast
LKML-Reference: <[email protected]>
--- kernel/sched.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/sched.c +1 -1
@@ -6677,7 +6677,7 @@ SYSCALL_DEFINE3(sched_getaffinity, pid_t ret =sched_getaffinity (pid, mask);if (ret ==0 ) { -int retlen =min (len,cpumask_size ()); +size_t retlen =min_t (size_t, len,cpumask_size ());if (copy_to_user (user_mask_ptr, mask, retlen)) ret = -EFAULT ;
PATCH 187/197 KVM: SVM: Fix memory leaks that happen when svm_create_vcpu() fails
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Takuya Yoshikawa <[email protected]>
(Cherry-picked from commit b7af40433870aa0636932ad39b0c48a0cb319057)
svm_create_vcpu() does not free the pages allocated during the creation when it fails to complete the allocations. This patch fixes it.
--- arch/x86/kvm/svm.c | 25 +++++++++++++++---------- 1 file changed, 15 insertions(+), 10 deletions(-)
arch/x86/kvm/svm.c +15 -10
@@ -694,29 +694,28 @@ static struct kvm_vcpu *svm_create_vcpu(if (err) goto free_svm; + err = -ENOMEM ; page =alloc_page (GFP_KERNEL ); -if (!page) { - err = -ENOMEM ; +if (!page) goto uninit; - } - err = -ENOMEM ; msrpm_pages =alloc_pages (GFP_KERNEL ,MSRPM_ALLOC_ORDER );if (!msrpm_pages) - goto uninit; + goto free_page1; nested_msrpm_pages =alloc_pages (GFP_KERNEL ,MSRPM_ALLOC_ORDER );if (!nested_msrpm_pages) - goto uninit; - - svm->msrpm =page_address (msrpm_pages); -svm_vcpu_init_msrpm (svm->msrpm); + goto free_page2; hsave_page =alloc_page (GFP_KERNEL );if (!hsave_page) - goto uninit; + goto free_page3; + svm->nested.hsave =page_address (hsave_page); + svm->msrpm =page_address (msrpm_pages); +svm_vcpu_init_msrpm (svm->msrpm); + svm->nested.msrpm =page_address (nested_msrpm_pages); svm->vmcb =page_address (page);
@@ -733,6 +732,12 @@ static struct kvm_vcpu *svm_create_vcpu(return &svm->vcpu; +free_page3: +__free_pages (nested_msrpm_pages,MSRPM_ALLOC_ORDER ); +free_page2: +__free_pages (msrpm_pages,MSRPM_ALLOC_ORDER ); +free_page1: +__free_page (page); uninit:kvm_vcpu_uninit (&svm->vcpu); free_svm:
PATCH 188/197 KVM: Dont spam kernel log when injecting exceptions due to bad cr writes
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Avi Kivity <[email protected]>
(Cherry-picked from commit d6a23895aa82353788a1cc5a1d9a1c963465463e)
These are guest-triggerable.
--- arch/x86/kvm/x86.c | 27 --------------------------- 1 file changed, 27 deletions(-)
arch/x86/kvm/x86.c +0 -27
@@ -297,21 +297,16 @@ out:void kvm_set_cr0 (struct kvm_vcpu *vcpu,unsigned long cr0) {if (cr0 &CR0_RESERVED_BITS ) { -printk (KERN_DEBUG "set_cr0: 0x%lx #GP, reserved bits 0x%lx\n" , - cr0, vcpu->arch.cr0);kvm_inject_gp (vcpu,0 );return ; }if ((cr0 &X86_CR0_NW ) && !(cr0 &X86_CR0_CD )) { -printk (KERN_DEBUG "set_cr0: #GP, CD == 0 && NW == 1\n" );kvm_inject_gp (vcpu,0 );return ; }if ((cr0 &X86_CR0_PG ) && !(cr0 &X86_CR0_PE )) { -printk (KERN_DEBUG "set_cr0: #GP, set PG flag " -"and a clear PE flag\n" );kvm_inject_gp (vcpu,0 );return ; }
@@ -322,15 +317,11 @@ void kvm_set_cr0(struct kvm_vcpu *vcpu,int cs_db, cs_l;if (!is_pae (vcpu)) { -printk (KERN_DEBUG "set_cr0: #GP, start paging " -"in long mode while PAE is disabled\n" );kvm_inject_gp (vcpu,0 );return ; } kvm_x86_ops->get_cs_db_l_bits (vcpu, &cs_db, &cs_l);if (cs_l) { -printk (KERN_DEBUG "set_cr0: #GP, start paging " -"in long mode while CS.L == 1\n" );kvm_inject_gp (vcpu,0 );return ;
@@ -338,8 +329,6 @@ void kvm_set_cr0(struct kvm_vcpu *vcpu, } else#endif if (is_pae (vcpu) && !load_pdptrs (vcpu, vcpu->arch.cr3)) { -printk (KERN_DEBUG "set_cr0: #GP, pdptrs " -"reserved bits\n" );kvm_inject_gp (vcpu,0 );return ; }
@@ -366,28 +355,23 @@ void kvm_set_cr4(struct kvm_vcpu *vcpu,unsigned long pdptr_bits =X86_CR4_PGE |X86_CR4_PSE |X86_CR4_PAE ;if (cr4 &CR4_RESERVED_BITS ) { -printk (KERN_DEBUG "set_cr4: #GP, reserved bits\n" );kvm_inject_gp (vcpu,0 );return ; }if (is_long_mode (vcpu)) {if (!(cr4 &X86_CR4_PAE )) { -printk (KERN_DEBUG "set_cr4: #GP, clearing PAE while " -"in long mode\n" );kvm_inject_gp (vcpu,0 );return ; } }else if (is_paging (vcpu) && (cr4 &X86_CR4_PAE ) && ((cr4 ^ old_cr4) & pdptr_bits) && !load_pdptrs (vcpu, vcpu->arch.cr3)) { -printk (KERN_DEBUG "set_cr4: #GP, pdptrs reserved bits\n" );kvm_inject_gp (vcpu,0 );return ; }if (cr4 &X86_CR4_VMXE ) { -printk (KERN_DEBUG "set_cr4: #GP, setting VMXE\n" );kvm_inject_gp (vcpu,0 );return ; }
@@ -408,21 +392,16 @@ void kvm_set_cr3(struct kvm_vcpu *vcpu,if (is_long_mode (vcpu)) {if (cr3 &CR3_L_MODE_RESERVED_BITS ) { -printk (KERN_DEBUG "set_cr3: #GP, reserved bits\n" );kvm_inject_gp (vcpu,0 );return ; } }else {if (is_pae (vcpu)) {if (cr3 &CR3_PAE_RESERVED_BITS ) { -printk (KERN_DEBUG -"set_cr3: #GP, reserved bits\n" );kvm_inject_gp (vcpu,0 );return ; }if (is_paging (vcpu) && !load_pdptrs (vcpu, cr3)) { -printk (KERN_DEBUG "set_cr3: #GP, pdptrs " -"reserved bits\n" );kvm_inject_gp (vcpu,0 );return ; }
@@ -454,7 +433,6 @@ EXPORT_SYMBOL_GPL(kvm_set_cr3);void kvm_set_cr8 (struct kvm_vcpu *vcpu,unsigned long cr8) {if (cr8 &CR8_RESERVED_BITS ) { -printk (KERN_DEBUG "set_cr8: #GP, reserved bits 0x%lx\n" , cr8);kvm_inject_gp (vcpu,0 );return ; }
@@ -508,15 +486,12 @@ static u32 emulated_msrs[] = {static void set_efer (struct kvm_vcpu *vcpu,u64 efer) {if (efer & efer_reserved_bits) { -printk (KERN_DEBUG "set_efer: 0x%llx #GP, reserved bits\n" , - efer);kvm_inject_gp (vcpu,0 );return ; }if (is_paging (vcpu) && (vcpu->arch.shadow_efer &EFER_LME ) != (efer &EFER_LME )) { -printk (KERN_DEBUG "set_efer: #GP, change LME while paging\n" );kvm_inject_gp (vcpu,0 );return ; }
@@ -526,7 +501,6 @@ static void set_efer(struct kvm_vcpu *vc feat =kvm_find_cpuid_entry (vcpu,0x80000001 ,0 );if (!feat || !(feat->edx &bit (X86_FEATURE_FXSR_OPT ))) { -printk (KERN_DEBUG "set_efer: #GP, enable FFXSR w/o CPUID capability\n" );kvm_inject_gp (vcpu,0 );return ; }
@@ -537,7 +511,6 @@ static void set_efer(struct kvm_vcpu *vc feat =kvm_find_cpuid_entry (vcpu,0x80000001 ,0 );if (!feat || !(feat->ecx &bit (X86_FEATURE_SVM ))) { -printk (KERN_DEBUG "set_efer: #GP, enable SVM w/o SVM\n" );kvm_inject_gp (vcpu,0 );return ; }
PATCH 189/197 KVM: allow bit 10 to be cleared in MSR_IA32_MC4_CTL
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Andre Przywara <[email protected]>
(Cherry-picked from commit 114be429c8cd44e57f312af2bbd6734e5a185b0d)
There is a quirk for AMD K8 CPUs in many Linux kernels (see arch/x86/kernel/cpu/mcheck/mce.c:__mcheck_cpu_apply_quirks()) that clears bit 10 in that MCE related MSR. KVM can only cope with all zeros or all ones, so it will inject a #GP into the guest, which will let it panic.
So lets add a quirk to the quirk and ignore this single cleared bit. This fixes -cpu kvm64 on all machines and -cpu host on K8 machines with some guest Linux kernels.
--- arch/x86/kvm/x86.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
arch/x86/kvm/x86.c +6 -2
@@ -799,9 +799,13 @@ static int set_msr_mce(struct kvm_vcpu *if (msr >=MSR_IA32_MC0_CTL && msr <MSR_IA32_MC0_CTL +4 * bank_num) {u32 offset = msr -MSR_IA32_MC0_CTL ; -/* only 0 or all 1s can be written to IA32_MCi_CTL */ +/* only 0 or all 1s can be written to IA32_MCi_CTL +* some Linux kernels though clear bit 10 in bank 4 to +* workaround a BIOS/GART TBL issue on AMD K8s, ignore +* this to avoid an uncatched #GP in the guest +*/ if ((offset &0x3 ) ==0 && - data !=0 && data != ~(u64 )0 ) + data !=0 && (data | (1 <<10 )) != ~(u64 )0 )return -1 ; vcpu->arch.mce_banks[offset] = data;break ;
PATCH 190/197 KVM: VMX: Save/restore rflags.vm correctly in real mode
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Avi Kivity <[email protected]>
(Cherry-picked from commit 78ac8b47c566dd6177a3b9b291b756ccb70670b7)
Currently we set eflags.vm unconditionally when entering real mode emulation through virtual-8086 mode, and clear it unconditionally when we enter protected mode. The means that the following sequence
KVM_SET_REGS (rflags.vm=1)
KVM_SET_SREGS (cr0.pe=1)
Ends up with rflags.vm clear due to KVM_SET_SREGS triggering enter_pmode().
Fix by shadowing rflags.vm (and rflags.iopl) correctly while in real mode:
reads and writes to those bits access a shadow register instead of the actual register.
--- arch/x86/kvm/vmx.c | 24 +++++++++++++++--------- 1 file changed, 15 insertions(+), 9 deletions(-)
arch/x86/kvm/vmx.c +15 -9
@@ -61,6 +61,8 @@ module_param_named(unrestricted_guest,static int __read_mostly emulate_invalid_guest_state =0 ;module_param (emulate_invalid_guest_state, bool,S_IRUGO ); +#define RMODE_GUEST_OWNED_EFLAGS_BITS (~(X86_EFLAGS_IOPL | X86_EFLAGS_VM)) +struct vmcs {u32 revision_id;u32 abort;
@@ -92,7 +94,7 @@ struct vcpu_vmx { } host_state;struct {int vm86_active; -u8 save_iopl; +ulong save_rflags;struct kvm_save_segment {u16 selector;unsigned long base;
@@ -783,18 +785,23 @@ static void vmx_fpu_deactivate(struct kvstatic unsigned long vmx_get_rflags (struct kvm_vcpu *vcpu) { -unsigned long rflags; +unsigned long rflags, save_rflags; rflags =vmcs_readl (GUEST_RFLAGS ); -if (to_vmx (vcpu)->rmode.vm86_active) - rflags &= ~(unsigned long )(X86_EFLAGS_IOPL |X86_EFLAGS_VM ); +if (to_vmx (vcpu)->rmode.vm86_active) { + rflags &=RMODE_GUEST_OWNED_EFLAGS_BITS ; + save_rflags =to_vmx (vcpu)->rmode.save_rflags; + rflags |= save_rflags & ~RMODE_GUEST_OWNED_EFLAGS_BITS ; + }return rflags; }static void vmx_set_rflags (struct kvm_vcpu *vcpu,unsigned long rflags) { -if (to_vmx (vcpu)->rmode.vm86_active) +if (to_vmx (vcpu)->rmode.vm86_active) { +to_vmx (vcpu)->rmode.save_rflags = rflags; rflags |=X86_EFLAGS_IOPL |X86_EFLAGS_VM ; + }vmcs_writel (GUEST_RFLAGS , rflags); }
@@ -1431,8 +1438,8 @@ static void enter_pmode(struct kvm_vcpuvmcs_write32 (GUEST_TR_AR_BYTES , vmx->rmode.tr.ar); flags =vmcs_readl (GUEST_RFLAGS ); - flags &= ~(X86_EFLAGS_IOPL |X86_EFLAGS_VM ); - flags |= (vmx->rmode.save_iopl <<IOPL_SHIFT ); + flags &=RMODE_GUEST_OWNED_EFLAGS_BITS ; + flags |= vmx->rmode.save_rflags & ~RMODE_GUEST_OWNED_EFLAGS_BITS ;vmcs_writel (GUEST_RFLAGS , flags); vmcs_writel(GUEST_CR4, (vmcs_readl(GUEST_CR4) & ~X86_CR4_VME) |
@@ -1501,8 +1508,7 @@ static void enter_rmode(struct kvm_vcpuvmcs_write32 (GUEST_TR_AR_BYTES ,0x008b ); flags =vmcs_readl (GUEST_RFLAGS ); - vmx->rmode.save_iopl - = (flags &X86_EFLAGS_IOPL ) >>IOPL_SHIFT ; + vmx->rmode.save_rflags = flags; flags |=X86_EFLAGS_IOPL |X86_EFLAGS_VM ;
PATCH 191/197 KVM: MMU: fix kvm_mmu_zap_page() and its calling path
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Xiao Guangrong <[email protected]>
(Cherry-picked from commit 77662e0028c7c63e34257fda03ff9625c59d939d)
This patch fix:
- calculate zapped page number properly in mmu_zap_unsync_children()
- calculate freeed page number properly kvm_mmu_change_mmu_pages()
- if zapped children page it shoud restart hlist walking
KVM-Stable-Tag.
--- arch/x86/kvm/mmu.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-)
arch/x86/kvm/mmu.c +7 -4
@@ -1496,8 +1496,8 @@ static int mmu_zap_unsync_children(strucfor_each_sp (pages, sp, parents, i) {kvm_mmu_zap_page (kvm, sp);mmu_pages_clear_parents (&parents); + zapped++; } - zapped += pages.nr;kvm_mmu_pages_init (parent, &parents, &pages); }
@@ -1548,14 +1548,16 @@ void kvm_mmu_change_mmu_pages(struct kvm*/ if (used_pages > kvm_nr_mmu_pages) { -while (used_pages > kvm_nr_mmu_pages) { +while (used_pages > kvm_nr_mmu_pages && + !list_empty (&kvm->arch.active_mmu_pages)) {struct kvm_mmu_page *page; page =container_of (kvm->arch.active_mmu_pages.prev, struct kvm_mmu_page, link); -kvm_mmu_zap_page (kvm, page); + used_pages -=kvm_mmu_zap_page (kvm, page); used_pages--; } + kvm_nr_mmu_pages = used_pages; kvm->arch.n_free_mmu_pages =0 ; }else
@@ -1602,7 +1604,8 @@ static void mmu_unshadow(struct kvm *kvm && !sp->role.invalid) {pgprintk ("%s: zap %lx %x\n" , __func__, gfn, sp->role.word); -kvm_mmu_zap_page (kvm, sp); +if (kvm_mmu_zap_page (kvm, sp)) + nn = bucket->first; } } }
PATCH 192/197 KVM: fix the handling of dirty bitmaps to avoid overflows
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Takuya Yoshikawa <[email protected]>
(Cherry-picked from commit 87bf6e7de1134f48681fd2ce4b7c1ec45458cb6d)
Int is not long enough to store the size of a dirty bitmap.
This patch fixes this problem with the introduction of a wrapper function to calculate the sizes of dirty bitmaps.
Note: in mark_page_dirty(), we have to consider the fact that
__set_bit() takes the offset as int, not long.
--- arch/ia64/kvm/kvm-ia64.c | 9 +++++---- arch/x86/kvm/x86.c | 4 ++-- include/linux/kvm_host.h | 5 +++++ virt/kvm/kvm_main.c | 13 ++++++++----- 4 files changed, 20 insertions(+), 11 deletions(-)
arch/ia64/kvm/kvm-ia64.c +5 -4
@@ -1797,7 +1797,8 @@ static int kvm_ia64_sync_dirty_log(struc {struct kvm_memory_slot *memslot;int r, i; -long n, base; +long base; +unsigned long n;unsigned long *dirty_bitmap = (unsigned long *)(kvm->arch.vm_base + offsetof(struct kvm_vm_data , kvm_mem_dirty_log));
@@ -1810,7 +1811,7 @@ static int kvm_ia64_sync_dirty_log(strucif (!memslot->dirty_bitmap) goto out; - n =ALIGN (memslot->npages,BITS_PER_LONG ) /8 ; + n =kvm_dirty_bitmap_bytes (memslot); base = memslot->base_gfn /BITS_PER_LONG ;for (i =0 ; i < n/sizeof (long ); ++i) {
@@ -1826,7 +1827,7 @@ int kvm_vm_ioctl_get_dirty_log(struct kv struct kvm_dirty_log *log) {int r; -int n; +unsigned long n;struct kvm_memory_slot *memslot;int is_dirty =0 ;
@@ -1844,7 +1845,7 @@ int kvm_vm_ioctl_get_dirty_log(struct kvif (is_dirty) {kvm_flush_remote_tlbs (kvm); memslot = &kvm->memslots[log->slot]; - n =ALIGN (memslot->npages,BITS_PER_LONG ) /8 ; + n =kvm_dirty_bitmap_bytes (memslot);memset (memslot->dirty_bitmap,0 , n); } r =0 ;
arch/x86/kvm/x86.c +2 -2
@@ -2133,7 +2133,7 @@ int kvm_vm_ioctl_get_dirty_log(struct kv struct kvm_dirty_log *log) {int r; -int n; +unsigned long n;struct kvm_memory_slot *memslot;int is_dirty =0 ;
@@ -2149,7 +2149,7 @@ int kvm_vm_ioctl_get_dirty_log(struct kvkvm_mmu_slot_remove_write_access (kvm, log->slot);spin_unlock (&kvm->mmu_lock); memslot = &kvm->memslots[log->slot]; - n =ALIGN (memslot->npages,BITS_PER_LONG ) /8 ; + n =kvm_dirty_bitmap_bytes (memslot);memset (memslot->dirty_bitmap,0 , n); } r =0 ;
include/linux/kvm_host.h +5 -0
@@ -116,6 +116,11 @@ struct kvm_memory_slot {int user_alloc; }; +static inline unsigned long kvm_dirty_bitmap_bytes (struct kvm_memory_slot *memslot) +{ +return ALIGN (memslot->npages,BITS_PER_LONG ) /8 ; +} +struct kvm_kernel_irq_routing_entry {u32 gsi;u32 type;
virt/kvm/kvm_main.c +8 -5
@@ -1226,7 +1226,7 @@ skip_lpage:/* Allocate page dirty bitmap if needed */ if ((new.flags &KVM_MEM_LOG_DIRTY_PAGES ) && !new.dirty_bitmap) { -unsigned dirty_bytes =ALIGN (npages,BITS_PER_LONG ) /8 ; +unsigned long dirty_bytes =kvm_dirty_bitmap_bytes (&new); new.dirty_bitmap =vmalloc (dirty_bytes);if (!new.dirty_bitmap)
@@ -1309,7 +1309,7 @@ int kvm_get_dirty_log(struct kvm *kvm, {struct kvm_memory_slot *memslot;int r, i; -int n; +unsigned long n;unsigned long any =0 ; r = -EINVAL ;
@@ -1321,7 +1321,7 @@ int kvm_get_dirty_log(struct kvm *kvm,if (!memslot->dirty_bitmap) goto out; - n =ALIGN (memslot->npages,BITS_PER_LONG ) /8 ; + n =kvm_dirty_bitmap_bytes (memslot);for (i =0 ; !any && i < n/sizeof (long ); ++i) any = memslot->dirty_bitmap[i];
@@ -1663,10 +1663,13 @@ void mark_page_dirty(struct kvm *kvm, gf memslot =gfn_to_memslot_unaliased (kvm, gfn);if (memslot && memslot->dirty_bitmap) {unsigned long rel_gfn = gfn - memslot->base_gfn; +unsigned long *p = memslot->dirty_bitmap + + rel_gfn /BITS_PER_LONG ; +int offset = rel_gfn %BITS_PER_LONG ;/* avoid RMW */ -if (!test_bit (rel_gfn, memslot->dirty_bitmap)) -set_bit (rel_gfn, memslot->dirty_bitmap); +if (!test_bit (offset, p)) +set_bit (offset, p); } }
PATCH 193/197 KVM: Increase NR_IOBUS_DEVS limit to 200
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Sridhar Samudrala <[email protected]>
(Cherry-picked from commit e80e2a60ff7914dae691345a976c80bbbff3ec74)
This patch increases the current hardcoded limit of NR_IOBUS_DEVS from 6 to 200. We are hitting this limit when creating a guest with more than 1 virtio-net device using vhost-net backend. Each virtio-net device requires 2 such devices to service notifications from rx/tx queues.
--- include/linux/kvm_host.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
include/linux/kvm_host.h +1 -1
@@ -53,7 +53,7 @@ extern struct kmem_cache *kvm_vcpu_cache*/ struct kvm_io_bus {int dev_count; -#define NR_IOBUS_DEVS 6 +#define NR_IOBUS_DEVS 200struct kvm_io_device *devs[NR_IOBUS_DEVS ]; };
PATCH 194/197 KVM: x86: Fix TSS size check for 16-bit tasks
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Jan Kiszka <[email protected]>
(Cherry-picked from commit e8861cfe2c75bdce36655b64d7ce02c2b31b604d)
A 16-bit TSS is only 44 bytes long. So make sure to test for the correct size on task switch.
--- arch/x86/kvm/x86.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
arch/x86/kvm/x86.c +5 -1
@@ -4543,6 +4543,7 @@ int kvm_task_switch(struct kvm_vcpu *vcpint ret =0 ;u32 old_tss_base =get_segment_base (vcpu,VCPU_SREG_TR );u16 old_tss_sel =get_segment_selector (vcpu,VCPU_SREG_TR ); +u32 desc_limit; old_tss_base =kvm_mmu_gva_to_gpa_write (vcpu, old_tss_base,NULL );
@@ -4565,7 +4566,10 @@ int kvm_task_switch(struct kvm_vcpu *vcp } } -if (!nseg_desc.p ||get_desc_limit (&nseg_desc) <0x67 ) { + desc_limit =get_desc_limit (&nseg_desc); +if (!nseg_desc.p || + ((desc_limit <0x67 && (nseg_desc.type &8 )) || + desc_limit <0x2b )) {kvm_queue_exception_e (vcpu,TS_VECTOR , tss_selector &0xfffc );return 1 ; }
PATCH 195/197 x86/gart: Disable GART explicitly before initialization
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Joerg Roedel <[email protected]>
commit 4b83873d3da0704987cb116833818ed96214ee29 upstream.
If we boot into a crash-kernel the gart might still be enabled and its caches might be dirty. This can result in undefined behavior later. Fix it by explicitly disabling the gart hardware before initialization and flushing the caches after enablement.
--- arch/x86/kernel/aperture_64.c | 15 ++++++++++++++- arch/x86/kernel/pci-gart_64.c | 3 +++ 2 files changed, 17 insertions(+), 1 deletion(-)
arch/x86/kernel/aperture_64.c +14 -1
@@ -389,6 +389,7 @@ void __init gart_iommu_hole_init(void)for (i =0 ; i <ARRAY_SIZE (bus_dev_ranges); i++) {int bus;int dev_base, dev_limit; +u32 ctl; bus = bus_dev_ranges[i].bus; dev_base = bus_dev_ranges[i].dev_base;
@@ -401,7 +402,19 @@ void __init gart_iommu_hole_init(void) iommu_detected =1 ; gart_iommu_aperture =1 ; - aper_order = (read_pci_config (bus, slot,3 ,AMD64_GARTAPERTURECTL ) >>1 ) &7 ; + ctl =read_pci_config (bus, slot,3 , +AMD64_GARTAPERTURECTL ); + +/* +* Before we do anything else disable the GART. It may +* still be enabled if we boot into a crash-kernel here. +* Reconfiguring the GART while it is enabled could have +* unknown side-effects. +*/ + ctl &= ~GARTEN ; +write_pci_config (bus, slot,3 ,AMD64_GARTAPERTURECTL , ctl); + + aper_order = (ctl >>1 ) &7 ; aper_size = (32 *1024 *1024 ) << aper_order; aper_base =read_pci_config (bus, slot,3 ,AMD64_GARTAPERTUREBASE ) &0x7fff ; aper_base <<=25 ;
arch/x86/kernel/pci-gart_64.c +3 -0
@@ -553,6 +553,9 @@ static void enable_gart_translations(voienable_gart_translation (dev,__pa (agp_gatt_table)); } + +/* Flush the GART-TLB to remove stale entries */ +k8_flush_garts (); }/*
PATCH 196/197 MIPS: uasm: Add OR instruction.
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Ralf Baechle <[email protected]>
This is the manual fixup of cherry picking from 5808184 ("MIPS: uasm: Add OR instruction.")
This is needed for the fix of the M3 workaround.
--- arch/mips/mm/uasm.c | 4 +++- arch/mips/mm/uasm.h | 1 + 2 files changed, 4 insertions(+), 1 deletion(-)
arch/mips/mm/uasm.c +3 -1
@@ -62,7 +62,7 @@ enum opcode { insn_dmtc0, insn_dsll, insn_dsll32, insn_dsra, insn_dsrl, insn_dsrl32, insn_dsubu, insn_eret, insn_j, insn_jal, insn_jr, insn_ld, insn_ll, insn_lld, insn_lui, insn_lw, insn_mfc0, - insn_mtc0, insn_ori, insn_pref, insn_rfe, insn_sc, insn_scd, + insn_mtc0, insn_or, insn_ori, insn_pref, insn_rfe, insn_sc, insn_scd, insn_sd, insn_sll, insn_sra, insn_srl, insn_subu, insn_sw, insn_tlbp, insn_tlbwi, insn_tlbwr, insn_xor, insn_xori };
@@ -116,6 +116,7 @@ static struct insn insn_table[] __cpuini { insn_lw, M(lw_op, 0, 0, 0, 0, 0), RS | RT | SIMM }, { insn_mfc0, M(cop0_op, mfc_op, 0, 0, 0, 0), RT | RD | SET}, { insn_mtc0, M(cop0_op, mtc_op, 0, 0, 0, 0), RT | RD | SET}, + { insn_or, M(spec_op, 0, 0, 0, 0, or_op), RS | RT | RD }, { insn_ori, M(ori_op, 0, 0, 0, 0, 0), RS | RT | UIMM }, { insn_pref, M(pref_op, 0, 0, 0, 0, 0), RS | RT | SIMM }, { insn_rfe, M(cop0_op, cop_op, 0, 0, 0, rfe_op), 0 },
@@ -362,6 +363,7 @@ I_u2s3u1(_lw) I_u1u2u3(_mfc0) I_u1u2u3(_mtc0) I_u2u1u3(_ori) +I_u3u1u2(_or) I_u2s3u1(_pref) I_0(_rfe) I_u2s3u1(_sc)
arch/mips/mm/uasm.h +1 -0
@@ -78,6 +78,7 @@ Ip_u2s3u1(_lw);Ip_u1u2u3 (_mfc0);Ip_u1u2u3 (_mtc0);Ip_u2u1u3 (_ori); +Ip_u3u1u2 (_or);Ip_u2s3u1 (_pref);Ip_0 (_rfe);Ip_u2s3u1 (_sc);
PATCH 197/197 MIPS: Sibyte: Fix M3 TLB exception handler workaround.
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Ralf Baechle <[email protected]>
commit 3d45285dd1ff4d4a1361b95e2d6508579a4402b5 upstream.
The M3 workaround needs to cmpare the region and VPN2 fields only.
--- arch/mips/mm/tlbex.c | 22 ++++++++++++++++------ 1 file changed, 16 insertions(+), 6 deletions(-)
arch/mips/mm/tlbex.c +16 -6
@@ -725,10 +725,15 @@ static void __cpuinit build_r4000_tlb_re* create the plain linear handler */ if (bcm1250_m3_war ()) { -UASM_i_MFC0 (&p,K0 ,C0_BADVADDR ); -UASM_i_MFC0 (&p,K1 ,C0_ENTRYHI ); +unsigned int segbits =44 ; + +uasm_i_dmfc0 (&p,K0 ,C0_BADVADDR ); +uasm_i_dmfc0 (&p,K1 ,C0_ENTRYHI );uasm_i_xor (&p,K0 ,K0 ,K1 ); -UASM_i_SRL (&p,K0 ,K0 ,PAGE_SHIFT +1 ); +uasm_i_dsrl32 (&p,K1 ,K0 ,62 -32 ); +uasm_i_dsrl (&p,K0 ,K0 ,12 +1 ); +uasm_i_dsll32 (&p,K0 ,K0 ,64 +12 +1 - segbits -32 ); +uasm_i_or (&p,K0 ,K0 ,K1 );uasm_il_bnez (&p, &r,K0 , label_leave);/* No need for uasm_i_nop */ }
@@ -1242,10 +1247,15 @@ static void __cpuinit build_r4000_tlb_lomemset (relocs,0 ,sizeof (relocs));if (bcm1250_m3_war ()) { -UASM_i_MFC0 (&p,K0 ,C0_BADVADDR ); -UASM_i_MFC0 (&p,K1 ,C0_ENTRYHI ); +unsigned int segbits =44 ; + +uasm_i_dmfc0 (&p,K0 ,C0_BADVADDR ); +uasm_i_dmfc0 (&p,K1 ,C0_ENTRYHI );uasm_i_xor (&p,K0 ,K0 ,K1 ); -UASM_i_SRL (&p,K0 ,K0 ,PAGE_SHIFT +1 ); +uasm_i_dsrl32 (&p,K1 ,K0 ,62 -32 ); +uasm_i_dsrl (&p,K0 ,K0 ,12 +1 ); +uasm_i_dsll32 (&p,K0 ,K0 ,64 +12 +1 - segbits -32 ); +uasm_i_or (&p,K0 ,K0 ,K1 );uasm_il_bnez (&p, &r,K0 , label_leave);/* No need for uasm_i_nop */ }
Quoted 11 lines · Greg KH
This is the start of the stable review cycle for the 2.6.32.12 release. There are 197 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 Saturday, April 24, 15:00:00 UTC. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.32.12-rc1.gzand the diffstat can be found below.
I now have a -rc2 release out at:
kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.32.12-rc2.gz
that fixes a few build issues with the rc1 patch.
thanks,
greg k-h