Skip to contentSkip to conversation

4 -stable kernel review cycles starting

PATCH New Greg KH 22 participants 658 messages Jul 1, 2010 – Sep 24, 2010 Page 4 of 4

Subsystems (87)
lore
Share & tools
lore
#537 lore raw

PATCH 89/200 md: set mddev readonly flag on blkdev BLKROSET ioctl

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Dan Williams <[email protected]>

commit e2218350465e7e0931676b4849b594c978437bce upstream.

When the user sets the block device to readwrite then the mddev should follow suit. Otherwise, the BUG_ON in md_write_start() will be set to trigger.

The reverse direction, setting mddev->ro to match a set readonly request, can be ignored because the blkdev level readonly flag precludes the need to have mddev->ro set correctly. Nevermind the fact that setting mddev->ro to 1 may fail if the array is in use.

---
 drivers/md/md.c |   29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)
drivers/md/md.c +29 -0
@@ -5517,6 +5517,7 @@ static int md_ioctl(struct block_device
 	int err = 0;
 	void __user *argp = (void __user *)arg;
 	mddev_t *mddev = NULL;
+	int ro;
 
 	if (!capable(CAP_SYS_ADMIN))
 		return -EACCES;
@@ -5652,6 +5653,34 @@ static int md_ioctl(struct block_device
 			err = do_md_stop(mddev, 1, 1);
 			goto done_unlock;
 
+		case BLKROSET:
+			if (get_user(ro, (int __user *)(arg))) {
+				err = -EFAULT;
+				goto done_unlock;
+			}
+			err = -EINVAL;
+
+			/* if the bdev is going readonly the value of mddev->ro
+			 * does not matter, no writes are coming
+			 */
+			if (ro)
+				goto done_unlock;
+
+			/* are we are already prepared for writes? */
+			if (mddev->ro != 1)
+				goto done_unlock;
+
+			/* transitioning to readauto need only happen for
+			 * arrays that call md_write_start
+			 */
+			if (mddev->pers) {
+				err = restart_array(mddev);
+				if (err == 0) {
+					mddev->ro = 2;
+					set_disk_ro(mddev->gendisk, 0);
+				}
+			}
+			goto done_unlock;
 	}
 
 	/*
#538 lore raw

PATCH 90/200 x86/amd-iommu: Fix crash when request_mem_region fails

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Joerg Roedel <[email protected]>

commit e82752d8b5a7e0a5e4d607fd8713549e2a4e2741 upstream.

When request_mem_region fails the error path tries to disable the IOMMUs. This accesses the mmio-region which was not allocated leading to a kernel crash. This patch fixes the issue.

---
 arch/x86/kernel/amd_iommu_init.c |   11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)
arch/x86/kernel/amd_iommu_init.c +8 -3
@@ -286,8 +286,12 @@ static u8 * __init iommu_map_mmio_space(
 {
 	u8 *ret;
 
-	if (!request_mem_region(address, MMIO_REGION_LENGTH, "amd_iommu"))
+	if (!request_mem_region(address, MMIO_REGION_LENGTH, "amd_iommu")) {
+		pr_err("AMD-Vi: Can not reserve memory region %llx for mmio\n",
+			address);
+		pr_err("AMD-Vi: This is a BIOS bug. Please contact your hardware vendor\n");
 		return NULL;
+	}
 
 	ret = ioremap_nocache(address, MMIO_REGION_LENGTH);
 	if (ret != NULL)
@@ -1313,7 +1317,7 @@ static int __init amd_iommu_init(void)
 		ret = amd_iommu_init_dma_ops();
 
 	if (ret)
-		goto free;
+		goto free_disable;
 
 	amd_iommu_init_api();
 
@@ -1331,9 +1335,10 @@ static int __init amd_iommu_init(void)
 out:
 	return ret;
 
-free:
+free_disable:
 	disable_iommus();
 
+free:
 	amd_iommu_uninit_devices();
 
 	free_pages((unsigned long)amd_iommu_pd_alloc_bitmap,
#539 lore raw

PATCH 91/200 x86/amd-iommu: Fall back to GART if initialization fails

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Joerg Roedel <[email protected]>

commit d7f0776975334070a93370ae048fda0c31a91c38 upstream.

This patch implements a fallback to the GART IOMMU if this is possible and the AMD IOMMU initialization failed. Otherwise the fallback would be nommu which is very problematic on machines with more than 4GB of memory or swiotlb which hurts io-performance.

---
 arch/x86/kernel/amd_iommu.c      |    4 ----
 arch/x86/kernel/amd_iommu_init.c |    9 +++++++++
 2 files changed, 9 insertions(+), 4 deletions(-)
arch/x86/kernel/amd_iommu.c +0 -4
@@ -2257,10 +2257,6 @@ int __init amd_iommu_init_dma_ops(void)
 
 	iommu_detected = 1;
 	swiotlb = 0;
-#ifdef CONFIG_GART_IOMMU
-	gart_iommu_aperture_disabled = 1;
-	gart_iommu_aperture = 0;
-#endif
 
 	/* Make the driver finally visible to the drivers */
 	dma_ops = &amd_iommu_dma_ops;
arch/x86/kernel/amd_iommu_init.c +9 -0
@@ -1357,6 +1357,15 @@ free:
 
 	free_unity_maps();
 
+#ifdef CONFIG_GART_IOMMU
+	/*
+	 * We failed to initialize the AMD IOMMU - try fallback to GART
+	 * if possible.
+	 */
+	gart_iommu_init();
+
+#endif
+
 	goto out;
 }
 
#540 lore raw

PATCH 92/200 eeepc-wmi: depends on BACKLIGHT_CLASS_DEVICE

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Randy Dunlap <[email protected]>

commit 89a7644be2c59eea443b0db2514fd42d5de909f8 upstream.

eeepc-wmi uses backlight*() interfaces so it should depend on BACKLIGHT_CLASS_DEVICE.

eeepc-wmi.c:(.text+0x2d7f54): undefined reference to backlight_force_update' eeepc-wmi.c:(.text+0x2d8012): undefined reference to backlight_device_register' eeepc-wmi.c:(.devinit.text+0x1c31c): undefined reference to backlight_device_unregister' eeepc-wmi.c:(.devexit.text+0x2f8b): undefined reference to backlight_device_unregister'

---
 drivers/platform/x86/Kconfig |    1 +
 1 file changed, 1 insertion(+)
drivers/platform/x86/Kconfig +1 -0
@@ -390,6 +390,7 @@ config EEEPC_WMI
 	depends on ACPI_WMI
 	depends on INPUT
 	depends on EXPERIMENTAL
+	depends on BACKLIGHT_CLASS_DEVICE
 	select INPUT_SPARSEKMAP
 	---help---
 	  Say Y here if you want to support WMI-based hotkeys on Eee PC laptops.
#541 lore raw

PATCH 93/200 clean DCACHE_CANT_MOUNT in d_delete()

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Al Viro <[email protected]>

commit 13e3c5e5b9c67e59074d24e29f3ff794bb4dfef0 upstream.

We set the "it's dead, don't mount on it" flag _and_ do not remove it if we turn the damn thing negative and leave it around. And if it goes positive afterwards, well...

Fortunately, there's only one place where that needs to be caught:
only d_delete() can turn the sucker negative without immediately freeing it; all other places that can lead to ->d_iput() call are followed by unconditionally freeing struct dentry in question. So the fix is obvious:

Addresses https://bugzilla.kernel.org/show_bug.cgi?id=16014

---
 fs/dcache.c |    1 +
 1 file changed, 1 insertion(+)
fs/dcache.c +1 -0
@@ -1529,6 +1529,7 @@ void d_delete(struct dentry * dentry)
 	spin_lock(&dentry->d_lock);
 	isdir = S_ISDIR(dentry->d_inode->i_mode);
 	if (atomic_read(&dentry->d_count) == 1) {
+		dentry->d_flags &= ~DCACHE_CANT_MOUNT;
 		dentry_iput(dentry);
 		fsnotify_nameremove(dentry, isdir);
 		return;
#542 lore raw

PATCH 94/200 exofs: confusion between kmap() and kmap_atomic() api

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Dan Carpenter <[email protected]>

commit ddf08f4b90a413892bbb9bb2e8a57aed991cd47d upstream.

For kmap_atomic() we call kunmap_atomic() on the returned pointer. That's different from kmap() and kunmap() and so it's easy to get them backwards.

---
 fs/exofs/dir.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
fs/exofs/dir.c +1 -1
@@ -608,7 +608,7 @@ int exofs_make_empty(struct inode *inode
 	de->inode_no = cpu_to_le64(parent->i_ino);
 	memcpy(de->name, PARENT_DIR, sizeof(PARENT_DIR));
 	exofs_set_de_type(de, inode);
-	kunmap_atomic(page, KM_USER0);
+	kunmap_atomic(kaddr, KM_USER0);
 	err = exofs_commit_chunk(page, 0, chunk_size);
 fail:
 	page_cache_release(page);
#543 lore raw

PATCH 95/200 mn10300: set ARCH_KMALLOC_MINALIGN

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: FUJITA Tomonori <[email protected]>

commit 6cdafaae41d52e6ef9a5c5be23602ef083e4d0f9 upstream.

Architectures that handle DMA-non-coherent memory need to set ARCH_KMALLOC_MINALIGN to make sure that kmalloc'ed buffer is DMA-safe: the buffer doesn't share a cache with the others.

---
 arch/mn10300/include/asm/cache.h |    2 ++
 1 file changed, 2 insertions(+)
arch/mn10300/include/asm/cache.h +2 -0
@@ -21,6 +21,8 @@
 #define L1_CACHE_DISPARITY	L1_CACHE_NENTRIES * L1_CACHE_BYTES
 #endif
 
+#define ARCH_KMALLOC_MINALIGN	L1_CACHE_BYTES
+
 /* data cache purge registers
  * - read from the register to unconditionally purge that cache line
  * - write address & 0xffffff00 to conditionally purge that cache line
#544 lore raw

PATCH 96/200 m68knommu: fix broken use of BUAD_TABLE_SIZE in 68328serial driver

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Greg Ungerer <[email protected]>

commit e9a137cb00d8b0f71c08a9e67d993f53e7713d21 upstream.

Commit 8b505ca8e2600eb9e7dd2d6b2682a81717671374 ("serial: 68328serial.c:
remove BAUD_TABLE_SIZE macro") misses one use of BAUD_TABLE_SIZE. So the resulting 68328serial.c does not compile:

drivers/serial/68328serial.c: In function `m68328_console_setup':
drivers/serial/68328serial.c:1439: error: `BAUD_TABLE_SIZE' undeclared (first use in this function) drivers/serial/68328serial.c:1439: error: (Each undeclared identifier is reported only once drivers/serial/68328serial.c:1439: error: for each function it appears in.)

Fix that last use of it.

---
 drivers/serial/68328serial.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/serial/68328serial.c +1 -1
@@ -1437,7 +1437,7 @@ int m68328_console_setup(struct console
 	for (i = 0; i < ARRAY_SIZE(baud_table); i++)
 		if (baud_table[i] == n)
 			break;
-	if (i < BAUD_TABLE_SIZE) {
+	if (i < ARRAY_SIZE(baud_table)) {
 		m68328_console_baud = n;
 		m68328_console_cbaud = 0;
 		if (i > 15) {
#545 lore raw

PATCH 97/200 m68k: set ARCH_KMALLOC_MINALIGN

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: FUJITA Tomonori <[email protected]>

commit dd6c26a66bdc629a500174ffe73b010b070b9f1b upstream.

Architectures that handle DMA-non-coherent memory need to set ARCH_KMALLOC_MINALIGN to make sure that kmalloc'ed buffer is DMA-safe: the buffer doesn't share a cache with the others.

---
 arch/m68k/include/asm/cache.h |    2 ++
 1 file changed, 2 insertions(+)
arch/m68k/include/asm/cache.h +2 -0
@@ -8,4 +8,6 @@
 #define        L1_CACHE_SHIFT  4
 #define        L1_CACHE_BYTES  (1<< L1_CACHE_SHIFT)
 
+#define ARCH_KMALLOC_MINALIGN	L1_CACHE_BYTES
+
 #endif
#546 lore raw

PATCH 98/200 rtc-cmos: do dev_set_drvdata() earlier in the initialization

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Dan Carpenter <[email protected]>

commit 6ba8bcd457d9fc793ac9435aa2e4138f571d4ec5 upstream.

The bug is an oops when dev_get_drvdata() returned null in cmos_update_irq_enable(). The call tree looks like this:
rtc_dev_ioctl()

    => rtc_update_irq_enable()
      => cmos_update_irq_enable()

It's caused by a race condition in the module initialization. It is rtc_device_register() which makes the ioctl operations live so I moved the call to dev_set_drvdata() before the call to rtc_device_register().

Addresses https://bugzilla.kernel.org/show_bug.cgi?id=15963

---
 drivers/rtc/rtc-cmos.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/rtc/rtc-cmos.c +3 -2
@@ -719,6 +719,9 @@ cmos_do_probe(struct device *dev, struct
 		}
 	}
 
+	cmos_rtc.dev = dev;
+	dev_set_drvdata(dev, &cmos_rtc);
+
 	cmos_rtc.rtc = rtc_device_register(driver_name, dev,
 				&cmos_rtc_ops, THIS_MODULE);
 	if (IS_ERR(cmos_rtc.rtc)) {
@@ -726,8 +729,6 @@ cmos_do_probe(struct device *dev, struct
 		goto cleanup0;
 	}
 
-	cmos_rtc.dev = dev;
-	dev_set_drvdata(dev, &cmos_rtc);
 	rename_region(ports, dev_name(&cmos_rtc.rtc->dev));
 
 	spin_lock_irq(&rtc_lock);
#547 lore raw

PATCH 99/200 rtc: s3c: initialize driver data before using it

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Maurus Cuelenaere <[email protected]>

commit e893de59a4982791368b3ce412bc67dd601a88a0 upstream.

s3c_rtc_setfreq() uses the platform driver data to derive struct rtc_device, so make sure drvdata is set _before_ s3c_rtc_setfreq() is called.

---
 drivers/rtc/rtc-s3c.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/rtc/rtc-s3c.c +3 -2
@@ -457,8 +457,6 @@ static int __devinit s3c_rtc_probe(struc
  	pr_debug("s3c2410_rtc: RTCCON=%02x\n",
 		 readb(s3c_rtc_base + S3C2410_RTCCON));
 
-	s3c_rtc_setfreq(&pdev->dev, 1);
-
 	device_init_wakeup(&pdev->dev, 1);
 
 	/* register RTC and exit */
@@ -475,6 +473,9 @@ static int __devinit s3c_rtc_probe(struc
 	rtc->max_user_freq = 128;
 
 	platform_set_drvdata(pdev, rtc);
+
+	s3c_rtc_setfreq(&pdev->dev, 1);
+
 	return 0;
 
  err_nortc:
#548 lore raw

PATCH 100/200 frv: set ARCH_KMALLOC_MINALIGN

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: FUJITA Tomonori <[email protected]>

commit 69dcf3db03626c4f18de624e8632454ea12ff260 upstream.

Architectures that handle DMA-non-coherent memory need to set ARCH_KMALLOC_MINALIGN to make sure that kmalloc'ed buffer is DMA-safe: the buffer doesn't share a cache with the others.

---
 arch/frv/include/asm/cache.h |    2 ++
 1 file changed, 2 insertions(+)
arch/frv/include/asm/cache.h +2 -0
@@ -17,6 +17,8 @@
 #define L1_CACHE_SHIFT		(CONFIG_FRV_L1_CACHE_SHIFT)
 #define L1_CACHE_BYTES		(1 << L1_CACHE_SHIFT)
 
+#define ARCH_KMALLOC_MINALIGN	L1_CACHE_BYTES
+
 #define __cacheline_aligned	__attribute__((aligned(L1_CACHE_BYTES)))
 #define ____cacheline_aligned	__attribute__((aligned(L1_CACHE_BYTES)))
 
#549 lore raw

PATCH 101/200 xtensa: set ARCH_KMALLOC_MINALIGN

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: FUJITA Tomonori <[email protected]>

commit 498900fc9cd1adbad1ba6b55ed9d8f2f5d655ca3 upstream.

Architectures that handle DMA-non-coherent memory need to set ARCH_KMALLOC_MINALIGN to make sure that kmalloc'ed buffer is DMA-safe: the buffer doesn't share a cache with the others.

---
 arch/xtensa/include/asm/cache.h |    1 +
 1 file changed, 1 insertion(+)
arch/xtensa/include/asm/cache.h +1 -0
@@ -29,5 +29,6 @@
 # define CACHE_WAY_SIZE ICACHE_WAY_SIZE
 #endif
 
+#define ARCH_KMALLOC_MINALIGN	L1_CACHE_BYTES
 
 #endif	/* _XTENSA_CACHE_H */
#550 lore raw

PATCH 102/200 Blackfin: set ARCH_KMALLOC_MINALIGN

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: FUJITA Tomonori <[email protected]>

commit 76b99699a2bbf9efdb578f9a38a202af2ecb354b upstream.

Architectures that handle DMA-non-coherent memory need to set ARCH_KMALLOC_MINALIGN to make sure that kmalloc'ed buffer is DMA-safe:
the buffer doesn't share a cache with the others.

---
 arch/blackfin/include/asm/cache.h |    2 ++
 1 file changed, 2 insertions(+)
arch/blackfin/include/asm/cache.h +2 -0
@@ -15,6 +15,8 @@
 #define L1_CACHE_BYTES	(1 << L1_CACHE_SHIFT)
 #define SMP_CACHE_BYTES	L1_CACHE_BYTES
 
+#define ARCH_KMALLOC_MINALIGN	L1_CACHE_BYTES
+
 #ifdef CONFIG_SMP
 #define __cacheline_aligned
 #else
#551 lore raw

PATCH 103/200 tmpfs: insert tmpfs cache pages to inactive list at first

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: KOSAKI Motohiro <[email protected]>

commit e9d6c157385e4efa61cb8293e425c9d8beba70d3 upstream.

Shaohua Li reported parallel file copy on tmpfs can lead to OOM killer. This is regression of caused by commit 9ff473b9a7 ("vmscan: evict streaming IO first"). Wow, It is 2 years old patch!

Currently, tmpfs file cache is inserted active list at first. This means that the insertion doesn't only increase numbers of pages in anon LRU, but it also reduces anon scanning ratio. Therefore, vmscan will get totally confused. It scans almost only file LRU even though the system has plenty unused tmpfs pages.

Historically, lru_cache_add_active_anon() was used for two reasons.
1) Intend to priotize shmem page rather than regular file cache.
2) Intend to avoid reclaim priority inversion of used once pages.

But we've lost both motivation because (1) Now we have separate anon and file LRU list. then, to insert active list doesn't help such priotize.
(2) In past, one pte access bit will cause page activation. then to insert inactive list with pte access bit mean higher priority than to insert active list. Its priority inversion may lead to uninteded lru chun. but it was already solved by commit 645747462 (vmscan: detect mapped file pages used only once). (Thanks Hannes, you are great!)

Thus, now we can use lru_cache_add_anon() instead.

---
 include/linux/swap.h |   10 ----------
 mm/filemap.c         |    4 ++--
 2 files changed, 2 insertions(+), 12 deletions(-)
include/linux/swap.h +0 -10
@@ -223,21 +223,11 @@ static inline void lru_cache_add_anon(st
 	__lru_cache_add(page, LRU_INACTIVE_ANON);
 }
 
-static inline void lru_cache_add_active_anon(struct page *page)
-{
-	__lru_cache_add(page, LRU_ACTIVE_ANON);
-}
-
 static inline void lru_cache_add_file(struct page *page)
 {
 	__lru_cache_add(page, LRU_INACTIVE_FILE);
 }
 
-static inline void lru_cache_add_active_file(struct page *page)
-{
-	__lru_cache_add(page, LRU_ACTIVE_FILE);
-}
-
 /* linux/mm/vmscan.c */
 extern unsigned long try_to_free_pages(struct zonelist *zonelist, int order,
 					gfp_t gfp_mask, nodemask_t *mask);
mm/filemap.c +2 -2
@@ -441,7 +441,7 @@ int add_to_page_cache_lru(struct page *p
 	/*
 	 * Splice_read and readahead add shmem/tmpfs pages into the page cache
 	 * before shmem_readpage has a chance to mark them as SwapBacked: they
-	 * need to go on the active_anon lru below, and mem_cgroup_cache_charge
+	 * need to go on the anon lru below, and mem_cgroup_cache_charge
 	 * (called in add_to_page_cache) needs to know where they're going too.
 	 */
 	if (mapping_cap_swap_backed(mapping))
@@ -452,7 +452,7 @@ int add_to_page_cache_lru(struct page *p
 		if (page_is_file_cache(page))
 			lru_cache_add_file(page);
 		else
-			lru_cache_add_active_anon(page);
+			lru_cache_add_anon(page);
 	}
 	return ret;
 }
#552 lore raw

PATCH 104/200 md: manage redundancy group in sysfs when changing level.

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: NeilBrown <[email protected]>

commit a64c876fd357906a1f7193723866562ad290654c upstream.

Some levels expect the 'redundancy group' to be present, others don't.
So when we change level of an array we might need to add or remove this group.

This requires fixing up the current practice of overloading ->private to indicate (when ->pers == NULL) that something needs to be removed. So create a new ->to_remove to fill that role.

When changing levels, we may need to add or remove attributes. When changing RAID5 -> RAID6, we both add and remove the same thing. It is important to catch this and optimise it out as the removal is delayed until a lock is released, so trying to add immediately would cause problems.

---
 drivers/md/md.c    |   43 ++++++++++++++++++++++++++++++++-----------
 drivers/md/md.h    |    1 +
 drivers/md/raid5.c |    7 +++++--
 3 files changed, 38 insertions(+), 13 deletions(-)
drivers/md/md.c +32 -11
@@ -510,9 +510,9 @@ static inline int mddev_trylock(mddev_t
 
 static struct attribute_group md_redundancy_group;
 
-static inline void mddev_unlock(mddev_t * mddev)
+static void mddev_unlock(mddev_t * mddev)
 {
-	if (mddev->pers == NULL && mddev->private) {
+	if (mddev->to_remove) {
 		/* These cannot be removed under reconfig_mutex as
 		 * an access to the files will try to take reconfig_mutex
 		 * while holding the file unremovable, which leads to
@@ -521,16 +521,20 @@ static inline void mddev_unlock(mddev_t
 		 * it while holding reconfig_mutex, and md_run can
 		 * use it to wait for the remove to complete.
 		 */
+		struct attribute_group *to_remove = mddev->to_remove;
+		mddev->to_remove = NULL;
 		mutex_lock(&mddev->open_mutex);
 		mutex_unlock(&mddev->reconfig_mutex);
 
-		sysfs_remove_group(&mddev->kobj, &md_redundancy_group);
-		if (mddev->private != (void*)1)
-			sysfs_remove_group(&mddev->kobj, mddev->private);
-		if (mddev->sysfs_action)
-			sysfs_put(mddev->sysfs_action);
-		mddev->sysfs_action = NULL;
-		mddev->private = NULL;
+		if (to_remove != &md_redundancy_group)
+			sysfs_remove_group(&mddev->kobj, to_remove);
+		if (mddev->pers == NULL ||
+		    mddev->pers->sync_request == NULL) {
+			sysfs_remove_group(&mddev->kobj, &md_redundancy_group);
+			if (mddev->sysfs_action)
+				sysfs_put(mddev->sysfs_action);
+			mddev->sysfs_action = NULL;
+		}
 		mutex_unlock(&mddev->open_mutex);
 	} else
 		mutex_unlock(&mddev->reconfig_mutex);
@@ -3003,6 +3007,23 @@ level_store(mddev_t *mddev, const char *
 	/* Looks like we have a winner */
 	mddev_suspend(mddev);
 	mddev->pers->stop(mddev);
+
+	if (mddev->pers->sync_request == NULL &&
+	    pers->sync_request != NULL) {
+		/* need to add the md_redundancy_group */
+		if (sysfs_create_group(&mddev->kobj, &md_redundancy_group))
+			printk(KERN_WARNING
+			       "md: cannot register extra attributes for %s\n",
+			       mdname(mddev));
+		mddev->sysfs_action = sysfs_get_dirent(mddev->kobj.sd, "sync_action");
+	}
+	if (mddev->pers->sync_request != NULL &&
+	    pers->sync_request == NULL) {
+		/* need to remove the md_redundancy_group */
+		if (mddev->to_remove == NULL)
+			mddev->to_remove = &md_redundancy_group;
+	}
+
 	module_put(mddev->pers->owner);
 	/* Invalidate devices that are now superfluous */
 	list_for_each_entry(rdev, &mddev->disks, same_set)
@@ -4557,8 +4578,8 @@ static int do_md_stop(mddev_t * mddev, i
 			mddev->queue->unplug_fn = NULL;
 			mddev->queue->backing_dev_info.congested_fn = NULL;
 			module_put(mddev->pers->owner);
-			if (mddev->pers->sync_request && mddev->private == NULL)
-				mddev->private = (void*)1;
+			if (mddev->pers->sync_request && mddev->to_remove == NULL)
+				mddev->to_remove = &md_redundancy_group;
 			mddev->pers = NULL;
 			/* tell userspace to handle 'inactive' */
 			sysfs_notify_dirent(mddev->sysfs_state);
drivers/md/md.h +1 -0
@@ -305,6 +305,7 @@ struct mddev_s
 	atomic_t 			max_corr_read_errors; /* max read retries */
 	struct list_head		all_mddevs;
 
+	struct attribute_group		*to_remove;
 	/* Generic barrier handling.
 	 * If there is a pending barrier request, all other
 	 * writes are blocked while the devices are flushed.
drivers/md/raid5.c +5 -2
@@ -5087,7 +5087,9 @@ static int run(mddev_t *mddev)
 	}
 
 	/* Ok, everything is just fine now */
-	if (sysfs_create_group(&mddev->kobj, &raid5_attrs_group))
+	if (mddev->to_remove == &raid5_attrs_group)
+		mddev->to_remove = NULL;
+	else if (sysfs_create_group(&mddev->kobj, &raid5_attrs_group))
 		printk(KERN_WARNING
 		       "raid5: failed to create sysfs attributes for %s\n",
 		       mdname(mddev));
@@ -5134,7 +5136,8 @@ static int stop(mddev_t *mddev)
 	mddev->queue->backing_dev_info.congested_fn = NULL;
 	blk_sync_queue(mddev->queue); /* the unplug fn references 'conf'*/
 	free_conf(conf);
-	mddev->private = &raid5_attrs_group;
+	mddev->private = NULL;
+	mddev->to_remove = &raid5_attrs_group;
 	return 0;
 }
 
#553 lore raw

PATCH 105/200 mlx4_core: Fix possible chunk sg list overflow in mlx4_alloc_icm()

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Sebastien Dugue <[email protected]>

commit c0dc72bad9cf21071f5e4005de46f7c8b67a138a upstream.

If the number of sg entries in the ICM chunk reaches MLX4_ICM_CHUNK_LEN, we must set chunk to NULL even for coherent mappings so that the next time through the loop will allocate another chunk. Otherwise we'll overflow the sg list the next time through the loop. This will lead to memory corruption if this case is hit.

mthca does not have this bug.

---
 drivers/net/mlx4/icm.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/net/mlx4/icm.c +2 -1
@@ -175,9 +175,10 @@ struct mlx4_icm *mlx4_alloc_icm(struct m
 
 				if (chunk->nsg <= 0)
 					goto fail;
+			}
 
+			if (chunk->npages == MLX4_ICM_CHUNK_LEN)
 				chunk = NULL;
-			}
 
 			npages -= 1 << cur_order;
 		} else {
#554 lore raw

PATCH 106/200 ARM: 6139/1: ARMv7: Use the Inner Shareable I-cache on MP

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Santosh Shilimkar <[email protected]>

commit a901ff715d53c109821cbbd9d7ea1f2a311646a9 upstream.

This patch fixes the flush_cache_all for ARMv7 SMP.It was missing from commit b8349b569aae661dea9d59d7d2ee587ccea3336c

arch/arm/mm/cache-v7.S +4 -0
index 06a90dc..37c8157 100644
@@ -91,7 +91,11 @@ ENTRY(v7_flush_kern_cache_all)
  THUMB(	stmfd	sp!, {r4-r7, r9-r11, lr}	)
 	bl	v7_flush_dcache_all
 	mov	r0, #0
+#ifdef CONFIG_SMP
+	mcr	p15, 0, r0, c7, c1, 0		@ invalidate I-cache inner shareable
+#else
 	mcr	p15, 0, r0, c7, c5, 0		@ I+BTB cache invalidate
+#endif
  ARM(	ldmfd	sp!, {r4-r5, r7, r9-r11, lr}	)
  THUMB(	ldmfd	sp!, {r4-r7, r9-r11, lr}	)
 	mov	pc, lr
#555 lore raw

PATCH 107/200 ARM: 6166/1: Proper prefetch abort handling on pre-ARMv6

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Anfei <[email protected]>

commit 5e27fb78df95e027723af2c90ecc9b4527ae59e9 upstream.

Instruction faults on pre-ARMv6 CPUs are interpreted as a 'translation fault', but do_translation_fault doesn't handle well if user mode trying to run instruction above TASK_SIZE, and result in the infinite retry of that instruction.

---
 arch/arm/mm/fault.c |    3 +++
 1 file changed, 3 insertions(+)
arch/arm/mm/fault.c +3 -0
@@ -393,6 +393,9 @@ do_translation_fault(unsigned long addr,
 	if (addr < TASK_SIZE)
 		return do_page_fault(addr, fsr, regs);
 
+	if (user_mode(regs))
+		goto bad_area;
+
 	index = pgd_index(addr);
 
 	/*
#556 lore raw

PATCH 108/200 ARM: 6164/1: Add kto and kfrom to input operands list.

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Khem Raj <[email protected]>

commit 9a40ac86152c9cffd3dca482a15ddf9a8c5716b3 upstream.

When functions incoming parameters are not in input operands list gcc 4.5 does not load the parameters into registers before calling this function but the inline assembly assumes valid addresses inside this function. This breaks the code because r0 and r1 are invalid when execution enters v4wb_copy_user_page ()

Also the constant needs to be used as third input operand so account for that as well.

Tested on qemu arm.

---
 arch/arm/mm/copypage-feroceon.c |    4 ++--
 arch/arm/mm/copypage-v4wb.c     |    4 ++--
 arch/arm/mm/copypage-v4wt.c     |    4 ++--
 arch/arm/mm/copypage-xsc3.c     |    4 ++--
 4 files changed, 8 insertions(+), 8 deletions(-)
arch/arm/mm/copypage-feroceon.c +2 -2
@@ -18,7 +18,7 @@ feroceon_copy_user_page(void *kto, const
 {
 	asm("\
 	stmfd	sp!, {r4-r9, lr}		\n\
-	mov	ip, %0				\n\
+	mov	ip, %2				\n\
 1:	mov	lr, r1				\n\
 	ldmia	r1!, {r2 - r9}			\n\
 	pld	[lr, #32]			\n\
@@ -64,7 +64,7 @@ feroceon_copy_user_page(void *kto, const
 	mcr	p15, 0, ip, c7, c10, 4		@ drain WB\n\
 	ldmfd	sp!, {r4-r9, pc}"
 	:
-	: "I" (PAGE_SIZE));
+	: "r" (kto), "r" (kfrom), "I" (PAGE_SIZE));
 }
 
 void feroceon_copy_user_highpage(struct page *to, struct page *from,
arch/arm/mm/copypage-v4wb.c +2 -2
@@ -27,7 +27,7 @@ v4wb_copy_user_page(void *kto, const voi
 {
 	asm("\
 	stmfd	sp!, {r4, lr}			@ 2\n\
-	mov	r2, %0				@ 1\n\
+	mov	r2, %2				@ 1\n\
 	ldmia	r1!, {r3, r4, ip, lr}		@ 4\n\
 1:	mcr	p15, 0, r0, c7, c6, 1		@ 1   invalidate D line\n\
 	stmia	r0!, {r3, r4, ip, lr}		@ 4\n\
@@ -44,7 +44,7 @@ v4wb_copy_user_page(void *kto, const voi
 	mcr	p15, 0, r1, c7, c10, 4		@ 1   drain WB\n\
 	ldmfd	 sp!, {r4, pc}			@ 3"
 	:
-	: "I" (PAGE_SIZE / 64));
+	: "r" (kto), "r" (kfrom), "I" (PAGE_SIZE / 64));
 }
 
 void v4wb_copy_user_highpage(struct page *to, struct page *from,
arch/arm/mm/copypage-v4wt.c +2 -2
@@ -25,7 +25,7 @@ v4wt_copy_user_page(void *kto, const voi
 {
 	asm("\
 	stmfd	sp!, {r4, lr}			@ 2\n\
-	mov	r2, %0				@ 1\n\
+	mov	r2, %2				@ 1\n\
 	ldmia	r1!, {r3, r4, ip, lr}		@ 4\n\
 1:	stmia	r0!, {r3, r4, ip, lr}		@ 4\n\
 	ldmia	r1!, {r3, r4, ip, lr}		@ 4+1\n\
@@ -40,7 +40,7 @@ v4wt_copy_user_page(void *kto, const voi
 	mcr	p15, 0, r2, c7, c7, 0		@ flush ID cache\n\
 	ldmfd	sp!, {r4, pc}			@ 3"
 	:
-	: "I" (PAGE_SIZE / 64));
+	: "r" (kto), "r" (kfrom), "I" (PAGE_SIZE / 64));
 }
 
 void v4wt_copy_user_highpage(struct page *to, struct page *from,
arch/arm/mm/copypage-xsc3.c +2 -2
@@ -34,7 +34,7 @@ xsc3_mc_copy_user_page(void *kto, const
 {
 	asm("\
 	stmfd	sp!, {r4, r5, lr}		\n\
-	mov	lr, %0				\n\
+	mov	lr, %2				\n\
 						\n\
 	pld	[r1, #0]			\n\
 	pld	[r1, #32]			\n\
@@ -67,7 +67,7 @@ xsc3_mc_copy_user_page(void *kto, const
 						\n\
 	ldmfd	sp!, {r4, r5, pc}"
 	:
-	: "I" (PAGE_SIZE / 64 - 1));
+	: "r" (kto), "r" (kfrom), "I" (PAGE_SIZE / 64 - 1));
 }
 
 void xsc3_mc_copy_user_highpage(struct page *to, struct page *from,
#557 lore raw

PATCH 109/200 ARM: 6146/1: sa1111: Prevent deadlock in resume path

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: =?UTF-8?q?Marek=20Va=C5=A1ut?= <[email protected]>

commit 3defb2476166445982a90c12d33f8947e75476c4 upstream.

This patch reorganises the sa1111_resume() function in a manner the spinlock happens after calling the sa1111_wake(). This fixes two bugs:

1) This function called sa1111_wake() which tried to claim the same spinlock the sa1111_resume() already claimed. This would result in certain deadlock.

Original idea for this part: Russell King <[email protected]>

2) The function didn't unlock the spinlock in case the chip didn't report correct ID.

Original idea for this part: Julia Lawall <[email protected]>

---
 arch/arm/common/sa1111.c |    9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)
arch/arm/common/sa1111.c +7 -2
@@ -951,8 +951,6 @@ static int sa1111_resume(struct platform
 	if (!save)
 		return 0;
 
-	spin_lock_irqsave(&sachip->lock, flags);
-
 	/*
 	 * Ensure that the SA1111 is still here.
 	 * FIXME: shouldn't do this here.
@@ -969,6 +967,13 @@ static int sa1111_resume(struct platform
 	 * First of all, wake up the chip.
 	 */
 	sa1111_wake(sachip);
+
+	/*
+	 * Only lock for write ops. Also, sa1111_wake must be called with
+	 * released spinlock!
+	 */
+	spin_lock_irqsave(&sachip->lock, flags);
+
 	sa1111_writel(0, sachip->base + SA1111_INTC + SA1111_INTEN0);
 	sa1111_writel(0, sachip->base + SA1111_INTC + SA1111_INTEN1);
 
#558 lore raw

PATCH 110/200 ARM: 6144/1: TCM memory bug freeing bug

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Linus Walleij <[email protected]>

commit ea208f646c8fb91c39c852e952fc911e1ad045ab upstream.

This fixes a bug in mm/init.c when freeing the TCM compile memory, this was being referred to as a char * which is incorrect: this will dereference the pointer and feed in the value at the location instead of the address to it. Change it to a plain char and use &(char) to reference it.

---
 arch/arm/mm/init.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
arch/arm/mm/init.c +3 -3
@@ -712,10 +712,10 @@ void __init mem_init(void)
 void free_initmem(void)
 {
 #ifdef CONFIG_HAVE_TCM
-	extern char *__tcm_start, *__tcm_end;
+	extern char __tcm_start, __tcm_end;
 
-	totalram_pages += free_area(__phys_to_pfn(__pa(__tcm_start)),
-				    __phys_to_pfn(__pa(__tcm_end)),
+	totalram_pages += free_area(__phys_to_pfn(__pa(&__tcm_start)),
+				    __phys_to_pfn(__pa(&__tcm_end)),
 				    "TCM link");
 #endif
 
#559 lore raw

PATCH 111/200 ARM: VFP: Fix vfp_put_double() for d16-d31

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Russell King <[email protected]>

commit 138de1c44a8e0606501cd8593407e9248e84f1b7 upstream.

vfp_put_double() takes the double value in r0,r1 not r1,r2.

---
 arch/arm/vfp/vfphw.S |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/vfp/vfphw.S +1 -1
@@ -277,7 +277,7 @@ ENTRY(vfp_put_double)
 #ifdef CONFIG_VFPv3
 	@ d16 - d31 registers
 	.irp	dr,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
-1:	mcrr	p11, 3, r1, r2, c\dr	@ fmdrr	r1, r2, d\dr
+1:	mcrr	p11, 3, r0, r1, c\dr	@ fmdrr	r0, r1, d\dr
 	mov	pc, lr
 	.org	1b + 8
 	.endr
#560 lore raw

PATCH 112/200 aio: fix the compat vectored operations

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jeff Moyer <[email protected]>

commit 9d85cba718efeef9ca00ce3f7f34f5880737aa9b upstream.

The aio compat code was not converting the struct iovecs from 32bit to 64bit pointers, causing either EINVAL to be returned from io_getevents, or EFAULT as the result of the I/O. This patch passes a compat flag to io_submit to signal that pointer conversion is necessary for a given iocb array.

A variant of this was tested by Michael Tokarev. I have also updated the libaio test harness to exercise this code path with good success. Further, I grabbed a copy of ltp and ran the testcases/kernel/syscall/readv and writev tests there (compiled with -m32 on my 64bit system). All seems happy, but extra eyes on this would be welcome.

---
 fs/aio.c            |   65 ++++++++++++++++++++++++++++++++--------------------
 fs/compat.c         |    2 -
 include/linux/aio.h |    5 ++++
 3 files changed, 47 insertions(+), 25 deletions(-)
fs/aio.c +41 -24
@@ -36,6 +36,7 @@
 #include <linux/blkdev.h>
 #include <linux/mempool.h>
 #include <linux/hash.h>
+#include <linux/compat.h>
 
 #include <asm/kmap_types.h>
 #include <asm/uaccess.h>
@@ -1384,13 +1385,22 @@ static ssize_t aio_fsync(struct kiocb *i
 	return ret;
 }
 
-static ssize_t aio_setup_vectored_rw(int type, struct kiocb *kiocb)
+static ssize_t aio_setup_vectored_rw(int type, struct kiocb *kiocb, bool compat)
 {
 	ssize_t ret;
 
-	ret = rw_copy_check_uvector(type, (struct iovec __user *)kiocb->ki_buf,
-				    kiocb->ki_nbytes, 1,
-				    &kiocb->ki_inline_vec, &kiocb->ki_iovec);
+#ifdef CONFIG_COMPAT
+	if (compat)
+		ret = compat_rw_copy_check_uvector(type,
+				(struct compat_iovec __user *)kiocb->ki_buf,
+				kiocb->ki_nbytes, 1, &kiocb->ki_inline_vec,
+				&kiocb->ki_iovec);
+	else
+#endif
+		ret = rw_copy_check_uvector(type,
+				(struct iovec __user *)kiocb->ki_buf,
+				kiocb->ki_nbytes, 1, &kiocb->ki_inline_vec,
+				&kiocb->ki_iovec);
 	if (ret < 0)
 		goto out;
 
@@ -1420,7 +1430,7 @@ static ssize_t aio_setup_single_vector(s
  *	Performs the initial checks and aio retry method
  *	setup for the kiocb at the time of io submission.
  */
-static ssize_t aio_setup_iocb(struct kiocb *kiocb)
+static ssize_t aio_setup_iocb(struct kiocb *kiocb, bool compat)
 {
 	struct file *file = kiocb->ki_filp;
 	ssize_t ret = 0;
@@ -1469,7 +1479,7 @@ static ssize_t aio_setup_iocb(struct kio
 		ret = security_file_permission(file, MAY_READ);
 		if (unlikely(ret))
 			break;
-		ret = aio_setup_vectored_rw(READ, kiocb);
+		ret = aio_setup_vectored_rw(READ, kiocb, compat);
 		if (ret)
 			break;
 		ret = -EINVAL;
@@ -1483,7 +1493,7 @@ static ssize_t aio_setup_iocb(struct kio
 		ret = security_file_permission(file, MAY_WRITE);
 		if (unlikely(ret))
 			break;
-		ret = aio_setup_vectored_rw(WRITE, kiocb);
+		ret = aio_setup_vectored_rw(WRITE, kiocb, compat);
 		if (ret)
 			break;
 		ret = -EINVAL;
@@ -1548,7 +1558,8 @@ static void aio_batch_free(struct hlist_
 }
 
 static int io_submit_one(struct kioctx *ctx, struct iocb __user *user_iocb,
-			 struct iocb *iocb, struct hlist_head *batch_hash)
+			 struct iocb *iocb, struct hlist_head *batch_hash,
+			 bool compat)
 {
 	struct kiocb *req;
 	struct file *file;
@@ -1609,7 +1620,7 @@ static int io_submit_one(struct kioctx *
 	req->ki_left = req->ki_nbytes = iocb->aio_nbytes;
 	req->ki_opcode = iocb->aio_lio_opcode;
 
-	ret = aio_setup_iocb(req);
+	ret = aio_setup_iocb(req, compat);
 
 	if (ret)
 		goto out_put_req;
@@ -1637,20 +1648,8 @@ out_put_req:
 	return ret;
 }
 
-/* sys_io_submit:
- *	Queue the nr iocbs pointed to by iocbpp for processing.  Returns
- *	the number of iocbs queued.  May return -EINVAL if the aio_context
- *	specified by ctx_id is invalid, if nr is < 0, if the iocb at
- *	*iocbpp[0] is not properly initialized, if the operation specified
- *	is invalid for the file descriptor in the iocb.  May fail with
- *	-EFAULT if any of the data structures point to invalid data.  May
- *	fail with -EBADF if the file descriptor specified in the first
- *	iocb is invalid.  May fail with -EAGAIN if insufficient resources
- *	are available to queue any iocbs.  Will return 0 if nr is 0.  Will
- *	fail with -ENOSYS if not implemented.
- */
-SYSCALL_DEFINE3(io_submit, aio_context_t, ctx_id, long, nr,
-		struct iocb __user * __user *, iocbpp)
+long do_io_submit(aio_context_t ctx_id, long nr,
+		  struct iocb __user *__user *iocbpp, bool compat)
 {
 	struct kioctx *ctx;
 	long ret = 0;
@@ -1687,7 +1686,7 @@ SYSCALL_DEFINE3(io_submit, aio_context_t
 			break;
 		}
 
-		ret = io_submit_one(ctx, user_iocb, &tmp, batch_hash);
+		ret = io_submit_one(ctx, user_iocb, &tmp, batch_hash, compat);
 		if (ret)
 			break;
 	}
@@ -1697,6 +1696,24 @@ SYSCALL_DEFINE3(io_submit, aio_context_t
 	return i ? i : ret;
 }
 
+/* sys_io_submit:
+ *	Queue the nr iocbs pointed to by iocbpp for processing.  Returns
+ *	the number of iocbs queued.  May return -EINVAL if the aio_context
+ *	specified by ctx_id is invalid, if nr is < 0, if the iocb at
+ *	*iocbpp[0] is not properly initialized, if the operation specified
+ *	is invalid for the file descriptor in the iocb.  May fail with
+ *	-EFAULT if any of the data structures point to invalid data.  May
+ *	fail with -EBADF if the file descriptor specified in the first
+ *	iocb is invalid.  May fail with -EAGAIN if insufficient resources
+ *	are available to queue any iocbs.  Will return 0 if nr is 0.  Will
+ *	fail with -ENOSYS if not implemented.
+ */
+SYSCALL_DEFINE3(io_submit, aio_context_t, ctx_id, long, nr,
+		struct iocb __user * __user *, iocbpp)
+{
+	return do_io_submit(ctx_id, nr, iocbpp, 0);
+}
+
 /* lookup_kiocb
  *	Finds a given iocb for cancellation.
  */
fs/compat.c +1 -1
@@ -600,7 +600,7 @@ compat_sys_io_submit(aio_context_t ctx_i
 	iocb64 = compat_alloc_user_space(nr * sizeof(*iocb64));
 	ret = copy_iocb(nr, iocb, iocb64);
 	if (!ret)
-		ret = sys_io_submit(ctx_id, nr, iocb64);
+		ret = do_io_submit(ctx_id, nr, iocb64, 1);
 	return ret;
 }
 
include/linux/aio.h +5 -0
@@ -212,6 +212,8 @@ extern void kick_iocb(struct kiocb *iocb
 extern int aio_complete(struct kiocb *iocb, long res, long res2);
 struct mm_struct;
 extern void exit_aio(struct mm_struct *mm);
+extern long do_io_submit(aio_context_t ctx_id, long nr,
+			 struct iocb __user *__user *iocbpp, bool compat);
 #else
 static inline ssize_t wait_on_sync_kiocb(struct kiocb *iocb) { return 0; }
 static inline int aio_put_req(struct kiocb *iocb) { return 0; }
@@ -219,6 +221,9 @@ static inline void kick_iocb(struct kioc
 static inline int aio_complete(struct kiocb *iocb, long res, long res2) { return 0; }
 struct mm_struct;
 static inline void exit_aio(struct mm_struct *mm) { }
+static inline long do_io_submit(aio_context_t ctx_id, long nr,
+				struct iocb __user * __user *iocbpp,
+				bool compat) { return 0; }
 #endif /* CONFIG_AIO */
 
 static inline struct kiocb *list_kiocb(struct list_head *h)
#561 lore raw

PATCH 113/200 idr: fix backtrack logic in idr_remove_all

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Imre Deak <[email protected]>

commit 2dcb22b346be7b7b7e630a8970d69cf3f1111ec1 upstream.

Currently idr_remove_all will fail with a use after free error if idr::layers is bigger than 2, which on 32 bit systems corresponds to items more than 1024. This is due to stepping back too many levels during backtracking. For simplicity let's assume that IDR_BITS=1 -> we have 2 nodes at each level below the root node and each leaf node stores two IDs.
(In reality for 32 bit systems IDR_BITS=5, with 32 nodes at each sub-root
level and 32 IDs in each leaf node). The sequence of freeing the nodes at the moment is as follows:

layer
1 -> a(7)
2 -> b(3) c(5)
3 -> d(1) e(2) f(4) g(6)

Until step 4 things go fine, but then node c is freed, whereas node g should be freed first. Since node c contains the pointer to node g we'll have a use after free error at step 6.

How many levels we step back after visiting the leaf nodes is currently determined by the msb of the id we are currently visiting:

Step
1. node d with IDs 0,1 is freed, current ID is advanced to 2.
msb of the current ID bit 1. This means we need to step back 1 level to node b and take the next sibling, node e.
2-3. node e with IDs 2,3 is freed, current ID is 4, msb is bit 2.
This means we need to step back 2 levels to node a, freeing node b on the way.
4-5. node f with IDs 4,5 is freed, current ID is 6, msb is still
bit 2. This means we again need to step back 2 levels to node a and free c on the way.
6. We should visit node g, but its pointer is not available as
node c was freed.

The fix changes how we determine the number of levels to step back. Instead of deducting this merely from the msb of the current ID, we should really check if advancing the ID causes an overflow to a bit position corresponding to a given layer. In the above example overflow from bit 0 to bit 1 should mean stepping back 1 level. Overflow from bit 1 to bit 2 should mean stepping back 2 levels and so on.

The fix was tested with IDs up to 1 << 20, which corresponds to 4 layers on 32 bit systems.

---
 lib/idr.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)
lib/idr.c +4 -1
@@ -445,6 +445,7 @@ EXPORT_SYMBOL(idr_remove);
 void idr_remove_all(struct idr *idp)
 {
 	int n, id, max;
+	int bt_mask;
 	struct idr_layer *p;
 	struct idr_layer *pa[MAX_LEVEL];
 	struct idr_layer **paa = &pa[0];
@@ -462,8 +463,10 @@ void idr_remove_all(struct idr *idp)
 			p = p->ary[(id >> n) & IDR_MASK];
 		}
 
+		bt_mask = id;
 		id += 1 << n;
-		while (n < fls(id)) {
+		/* Get the highest bit that the above add changed from 0->1. */
+		while (n < fls(id ^ bt_mask)) {
 			if (p)
 				free_layer(p);
 			n += IDR_BITS;
#562 lore raw

PATCH 114/200 ASoC: Update Freescale i.MX SSI driver DMA parameter handling

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Stuart Longland <[email protected]>

commit e2b3e622b259e62aa2450a25f1c20cca1bfdc81e upstream.

This updates the i.MX SSI driver to make it compatible with the ASoC tree following the move of DMA parameters from the DAI to the audio substream object.

---
 sound/soc/imx/imx-pcm-dma-mx2.c |    7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)
sound/soc/imx/imx-pcm-dma-mx2.c +4 -3
@@ -73,7 +73,8 @@ static void snd_imx_dma_err_callback(int
 {
 	struct snd_pcm_substream *substream = data;
 	struct snd_soc_pcm_runtime *rtd = substream->private_data;
-	struct imx_pcm_dma_params *dma_params = rtd->dai->cpu_dai->dma_data;
+	struct imx_pcm_dma_params *dma_params =
+		snd_soc_dai_get_dma_data(rtd->dai->cpu_dai, substream);
 	struct snd_pcm_runtime *runtime = substream->runtime;
 	struct imx_pcm_runtime_data *iprtd = runtime->private_data;
 	int ret;
@@ -102,7 +103,7 @@ static int imx_ssi_dma_alloc(struct snd_
 	struct imx_pcm_runtime_data *iprtd = runtime->private_data;
 	int ret;
 
-	dma_params = snd_soc_get_dma_data(rtd->dai->cpu_dai, substream);
+	dma_params = snd_soc_dai_get_dma_data(rtd->dai->cpu_dai, substream);
 
 	iprtd->dma = imx_dma_request_by_prio(DRV_NAME, DMA_PRIO_HIGH);
 	if (iprtd->dma < 0) {
@@ -212,7 +213,7 @@ static int snd_imx_pcm_prepare(struct sn
 	struct imx_pcm_runtime_data *iprtd = runtime->private_data;
 	int err;
 
-	dma_params = snd_soc_get_dma_data(rtd->dai->cpu_dai, substream);
+	dma_params = snd_soc_dai_get_dma_data(rtd->dai->cpu_dai, substream);
 
 	iprtd->substream = substream;
 	iprtd->buf = (unsigned int *)substream->dma_buffer.area;
#563 lore raw

PATCH 115/200 ASoC: Fix dB scales for WM835x

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Mark Brown <[email protected]>

commit e6a08c5a8990102bcd1f4bae84b668da6c23caa9 upstream.

These should be regular rather than linear scales.

sound/soc/codecs/wm8350.c +2 -2
index e5a48da..c342c2c 100644
@@ -425,8 +425,8 @@ static const struct soc_enum wm8350_enum[] = {
 	SOC_ENUM_SINGLE(WM8350_INPUT_MIXER_VOLUME, 15, 2, wm8350_lr),
 };
 
-static DECLARE_TLV_DB_LINEAR(pre_amp_tlv, -1200, 3525);
-static DECLARE_TLV_DB_LINEAR(out_pga_tlv, -5700, 600);
+static DECLARE_TLV_DB_SCALE(pre_amp_tlv, -1200, 3525, 0);
+static DECLARE_TLV_DB_SCALE(out_pga_tlv, -5700, 600, 0);
 static DECLARE_TLV_DB_SCALE(dac_pcm_tlv, -7163, 36, 1);
 static DECLARE_TLV_DB_SCALE(adc_pcm_tlv, -12700, 50, 1);
 static DECLARE_TLV_DB_SCALE(out_mix_tlv, -1500, 300, 1);
#564 lore raw

PATCH 116/200 ASoC: Fix dB scales for WM8400

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Mark Brown <[email protected]>

commit 3351e9fbb0fda6498ee149ee88c67f5849813c57 upstream.

These scales should be regular, not linear.

---
 sound/soc/codecs/wm8400.c |   18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)
sound/soc/codecs/wm8400.c +9 -9
@@ -107,21 +107,21 @@ static void wm8400_codec_reset(struct sn
 	wm8400_reset_codec_reg_cache(wm8400->wm8400);
 }
 
-static const DECLARE_TLV_DB_LINEAR(rec_mix_tlv, -1500, 600);
+static const DECLARE_TLV_DB_SCALE(rec_mix_tlv, -1500, 600, 0);
 
-static const DECLARE_TLV_DB_LINEAR(in_pga_tlv, -1650, 3000);
+static const DECLARE_TLV_DB_SCALE(in_pga_tlv, -1650, 3000, 0);
 
-static const DECLARE_TLV_DB_LINEAR(out_mix_tlv, -2100, 0);
+static const DECLARE_TLV_DB_SCALE(out_mix_tlv, -2100, 0, 0);
 
-static const DECLARE_TLV_DB_LINEAR(out_pga_tlv, -7300, 600);
+static const DECLARE_TLV_DB_SCALE(out_pga_tlv, -7300, 600, 0);
 
-static const DECLARE_TLV_DB_LINEAR(out_omix_tlv, -600, 0);
+static const DECLARE_TLV_DB_SCALE(out_omix_tlv, -600, 0, 0);
 
-static const DECLARE_TLV_DB_LINEAR(out_dac_tlv, -7163, 0);
+static const DECLARE_TLV_DB_SCALE(out_dac_tlv, -7163, 0, 0);
 
-static const DECLARE_TLV_DB_LINEAR(in_adc_tlv, -7163, 1763);
+static const DECLARE_TLV_DB_SCALE(in_adc_tlv, -7163, 1763, 0);
 
-static const DECLARE_TLV_DB_LINEAR(out_sidetone_tlv, -3600, 0);
+static const DECLARE_TLV_DB_SCALE(out_sidetone_tlv, -3600, 0, 0);
 
 static int wm8400_outpga_put_volsw_vu(struct snd_kcontrol *kcontrol,
         struct snd_ctl_elem_value *ucontrol)
@@ -440,7 +440,7 @@ static int outmixer_event (struct snd_so
 /* INMIX dB values */
 static const unsigned int in_mix_tlv[] = {
 	TLV_DB_RANGE_HEAD(1),
-	0,7, TLV_DB_LINEAR_ITEM(-1200, 600),
+	0,7, TLV_DB_SCALE_ITEM(-1200, 600, 0),
 };
 
 /* Left In PGA Connections */
#565 lore raw

PATCH 117/200 ASoC: Fix dB scales for WM8990

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Mark Brown <[email protected]>

commit f68596c6d8711650722b2a54328a088a2c21bc5b upstream.

These should be regular, not linear.

---
 sound/soc/codecs/wm8990.c |   18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)
sound/soc/codecs/wm8990.c +9 -9
@@ -111,21 +111,21 @@ static const u16 wm8990_reg[] = {
 
 #define wm8990_reset(c) snd_soc_write(c, WM8990_RESET, 0)
 
-static const DECLARE_TLV_DB_LINEAR(rec_mix_tlv, -1500, 600);
+static const DECLARE_TLV_DB_SCALE(rec_mix_tlv, -1500, 600, 0);
 
-static const DECLARE_TLV_DB_LINEAR(in_pga_tlv, -1650, 3000);
+static const DECLARE_TLV_DB_SCALE(in_pga_tlv, -1650, 3000, 0);
 
-static const DECLARE_TLV_DB_LINEAR(out_mix_tlv, 0, -2100);
+static const DECLARE_TLV_DB_SCALE(out_mix_tlv, 0, -2100, 0);
 
-static const DECLARE_TLV_DB_LINEAR(out_pga_tlv, -7300, 600);
+static const DECLARE_TLV_DB_SCALE(out_pga_tlv, -7300, 600, 0);
 
-static const DECLARE_TLV_DB_LINEAR(out_omix_tlv, -600, 0);
+static const DECLARE_TLV_DB_SCALE(out_omix_tlv, -600, 0, 0);
 
-static const DECLARE_TLV_DB_LINEAR(out_dac_tlv, -7163, 0);
+static const DECLARE_TLV_DB_SCALE(out_dac_tlv, -7163, 0, 0);
 
-static const DECLARE_TLV_DB_LINEAR(in_adc_tlv, -7163, 1763);
+static const DECLARE_TLV_DB_SCALE(in_adc_tlv, -7163, 1763, 0);
 
-static const DECLARE_TLV_DB_LINEAR(out_sidetone_tlv, -3600, 0);
+static const DECLARE_TLV_DB_SCALE(out_sidetone_tlv, -3600, 0, 0);
 
 static int wm899x_outpga_put_volsw_vu(struct snd_kcontrol *kcontrol,
 	struct snd_ctl_elem_value *ucontrol)
@@ -451,7 +451,7 @@ static int outmixer_event(struct snd_soc
 /* INMIX dB values */
 static const unsigned int in_mix_tlv[] = {
 	TLV_DB_RANGE_HEAD(1),
-	0, 7, TLV_DB_LINEAR_ITEM(-1200, 600),
+	0, 7, TLV_DB_SCALE_ITEM(-1200, 600, 0),
 };
 
 /* Left In PGA Connections */
#566 lore raw

PATCH 118/200 drm/radeon: fix the r100/r200 ums block 0 page fix

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Dave Airlie <[email protected]>

commit cf22f20ade30f8c03955324aaf27b1049e182600 upstream.

airlied -> brown paper bag.

I blame Hi-5 or the Wiggles for lowering my IQ, move the fix inside some brackets instead of breaking everything in site.

---
 drivers/gpu/drm/radeon/radeon_state.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/gpu/drm/radeon/radeon_state.c +3 -2
@@ -900,9 +900,10 @@ static void radeon_cp_dispatch_clear(str
 			flags |= RADEON_FRONT;
 	}
 	if (flags & (RADEON_DEPTH|RADEON_STENCIL)) {
-		if (!dev_priv->have_z_offset)
+		if (!dev_priv->have_z_offset) {
 			printk_once(KERN_ERR "radeon: illegal depth clear request. Buggy mesa detected - please update.\n");
-		flags &= ~(RADEON_DEPTH | RADEON_STENCIL);
+			flags &= ~(RADEON_DEPTH | RADEON_STENCIL);
+		}
 	}
 
 	if (flags & (RADEON_FRONT | RADEON_BACK)) {
#567 lore raw

PATCH 119/200 SLUB: Allow full duplication of kmalloc array for 390

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Christoph Lameter <[email protected]>

commit 0f1f694260e0d35b5ce7d471f6e679c3dd4d7d94 upstream.

Commit 756dee75872a2a764b478e18076360b8a4ec9045 ("SLUB: Get rid of dynamic DMA kmalloc cache allocation") makes S390 run out of kmalloc caches. Increase the number of kmalloc caches to a safe size.

---
 include/linux/slub_def.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
include/linux/slub_def.h +1 -1
@@ -132,7 +132,7 @@ struct kmem_cache {
 #ifdef CONFIG_ZONE_DMA
 #define SLUB_DMA __GFP_DMA
 /* Reserve extra caches for potential DMA use */
-#define KMALLOC_CACHES (2 * SLUB_PAGE_SHIFT - 6)
+#define KMALLOC_CACHES (2 * SLUB_PAGE_SHIFT)
 #else
 /* Disable DMA functionality */
 #define SLUB_DMA (__force gfp_t)0
#568 lore raw

PATCH 120/200 slub: move kmem_cache_node into its own cacheline

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Alexander Duyck <[email protected]>

commit 73367bd8eef4f4eb311005886aaa916013073265 upstream.

This patch is meant to improve the performance of SLUB by moving the local kmem_cache_node lock into it's own cacheline separate from kmem_cache. This is accomplished by simply removing the local_node when NUMA is enabled.

On my system with 2 nodes I saw around a 5% performance increase w/ hackbench times dropping from 6.2 seconds to 5.9 seconds on average. I suspect the performance gain would increase as the number of nodes increases, but I do not have the data to currently back that up.

Bugzilla-Reference: http://bugzilla.kernel.org/show_bug.cgi?id=15713

---
 include/linux/slub_def.h |    9 +++------
 mm/slub.c                |   33 +++++++++++----------------------
 2 files changed, 14 insertions(+), 28 deletions(-)
include/linux/slub_def.h +3 -6
@@ -75,12 +75,6 @@ struct kmem_cache {
 	int offset;		/* Free pointer offset. */
 	struct kmem_cache_order_objects oo;
 
-	/*
-	 * Avoid an extra cache line for UP, SMP and for the node local to
-	 * struct kmem_cache.
-	 */
-	struct kmem_cache_node local_node;
-
 	/* Allocation and freeing of slabs */
 	struct kmem_cache_order_objects max;
 	struct kmem_cache_order_objects min;
@@ -102,6 +96,9 @@ struct kmem_cache {
 	 */
 	int remote_node_defrag_ratio;
 	struct kmem_cache_node *node[MAX_NUMNODES];
+#else
+	/* Avoid an extra cache line for UP */
+	struct kmem_cache_node local_node;
 #endif
 };
 
mm/slub.c +11 -22
@@ -2141,7 +2141,7 @@ static void free_kmem_cache_nodes(struct
 
 	for_each_node_state(node, N_NORMAL_MEMORY) {
 		struct kmem_cache_node *n = s->node[node];
-		if (n && n != &s->local_node)
+		if (n)
 			kmem_cache_free(kmalloc_caches, n);
 		s->node[node] = NULL;
 	}
@@ -2150,33 +2150,22 @@ static void free_kmem_cache_nodes(struct
 static int init_kmem_cache_nodes(struct kmem_cache *s, gfp_t gfpflags)
 {
 	int node;
-	int local_node;
-
-	if (slab_state >= UP && (s < kmalloc_caches ||
-			s >= kmalloc_caches + KMALLOC_CACHES))
-		local_node = page_to_nid(virt_to_page(s));
-	else
-		local_node = 0;
 
 	for_each_node_state(node, N_NORMAL_MEMORY) {
 		struct kmem_cache_node *n;
 
-		if (local_node == node)
-			n = &s->local_node;
-		else {
-			if (slab_state == DOWN) {
-				early_kmem_cache_node_alloc(gfpflags, node);
-				continue;
-			}
-			n = kmem_cache_alloc_node(kmalloc_caches,
-							gfpflags, node);
-
-			if (!n) {
-				free_kmem_cache_nodes(s);
-				return 0;
-			}
+		if (slab_state == DOWN) {
+			early_kmem_cache_node_alloc(gfpflags, node);
+			continue;
+		}
+		n = kmem_cache_alloc_node(kmalloc_caches,
+						gfpflags, node);
 
+		if (!n) {
+			free_kmem_cache_nodes(s);
+			return 0;
 		}
+
 		s->node[node] = n;
 		init_kmem_cache_node(n, s);
 	}
#569 lore raw

Re: [000/200] 2.6.34.1 stable review

In reply to Greg KH
Quoted 8 lines · Greg KH

This is the start of the stable review cycle for the 2.6.34.1 release. There are 200 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. If anyone is a maintainer of the proper subsystem, and wants to add a Signed-off-by: line to the patch, please respond with it.

Responses should be made by Sat, July 3, 17:00:00 UTC UTC. Anything received after that time might be too late.

It looks like the requests I sent earlier this week have not been taken into account. Was it too late already or didn't you get them?

Rafael

#570 lore raw

Re: [000/200] 2.6.34.1 stable review

Quoted 7 lines · Rafael J. Wysocki
Quoted 6 lines · Greg KH

This is the start of the stable review cycle for the 2.6.34.1 release. There are 200 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. If anyone is a maintainer of the proper subsystem, and wants to add a Signed-off-by: line to the patch, please respond with it.

Quoted 5 lines
Quoted 2 lines

Responses should be made by Sat, July 3, 17:00:00 UTC UTC. Anything received after that time might be too late.

It looks like the requests I sent earlier this week have not been taken into account. Was it too late already or didn't you get them?

You missed the email above this where I explained why not everything people have sent in is in this release:

	http://thread.gmane.org/gmane.linux.kernel/1005055

Don't worry, it's in my to-apply queue and is not lost.

thanks,

greg k-h

#571 lore raw

Re: [000/200] 2.6.34.1 stable review

Quoted 11 lines · Greg KH
Quoted 10 lines · Rafael J. Wysocki
Quoted 8 lines · Greg KH

This is the start of the stable review cycle for the 2.6.34.1 release. There are 200 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. If anyone is a maintainer of the proper subsystem, and wants to add a Signed-off-by: line to the patch, please respond with it.

Responses should be made by Sat, July 3, 17:00:00 UTC UTC. Anything received after that time might be too late.

Quoted 6 lines
Quoted 2 lines

It looks like the requests I sent earlier this week have not been taken into account. Was it too late already or didn't you get them?

You missed the email above this where I explained why not everything people have sent in is in this release:

	http://thread.gmane.org/gmane.linux.kernel/1005055

Well, yes, I did.

Quoted 1 line

Don't worry, it's in my to-apply queue and is not lost.

OK, thanks!

Rafael

#572 lore raw

PATCH 121/200 hwmon: (ltc4245) Read only one GPIO pin

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Ira W. Snyder <[email protected]>

commit df16dd53c575d0cb9dbee20a3149927c862a9ff6 upstream.

Read only one of the GPIO pins as an analog voltage. The ADC can be switched to a different GPIO pin at runtime, but this is not supported.

Previously, this driver would report the analog voltage of the currently selected GPIO pin as all three GPIO voltages: in9_input, in10_input and in11_input.

---
 Documentation/hwmon/ltc4245 |    4 +---
 drivers/hwmon/ltc4245.c     |   18 +++++-------------
 2 files changed, 6 insertions(+), 16 deletions(-)
Documentation/hwmon/ltc4245 +1 -3
@@ -72,9 +72,7 @@ in6_min_alarm		5v  output undervoltage a
 in7_min_alarm		3v  output undervoltage alarm
 in8_min_alarm		Vee (-12v) output undervoltage alarm
 
-in9_input		GPIO #1 voltage data
-in10_input		GPIO #2 voltage data
-in11_input		GPIO #3 voltage data
+in9_input		GPIO voltage data
 
 power1_input		12v power usage (mW)
 power2_input		5v  power usage (mW)
drivers/hwmon/ltc4245.c +5 -13
@@ -45,9 +45,7 @@ enum ltc4245_cmd {
 	LTC4245_VEEIN			= 0x19,
 	LTC4245_VEESENSE		= 0x1a,
 	LTC4245_VEEOUT			= 0x1b,
-	LTC4245_GPIOADC1		= 0x1c,
-	LTC4245_GPIOADC2		= 0x1d,
-	LTC4245_GPIOADC3		= 0x1e,
+	LTC4245_GPIOADC			= 0x1c,
 };
 
 struct ltc4245_data {
@@ -61,7 +59,7 @@ struct ltc4245_data {
 	u8 cregs[0x08];
 
 	/* Voltage registers */
-	u8 vregs[0x0f];
+	u8 vregs[0x0d];
 };
 
 static struct ltc4245_data *ltc4245_update_device(struct device *dev)
@@ -86,7 +84,7 @@ static struct ltc4245_data *ltc4245_upda
 				data->cregs[i] = val;
 		}
 
-		/* Read voltage registers -- 0x10 to 0x1f */
+		/* Read voltage registers -- 0x10 to 0x1c */
 		for (i = 0; i < ARRAY_SIZE(data->vregs); i++) {
 			val = i2c_smbus_read_byte_data(client, i+0x10);
 			if (unlikely(val < 0))
@@ -128,9 +126,7 @@ static int ltc4245_get_voltage(struct de
 	case LTC4245_VEEOUT:
 		voltage = regval * -55;
 		break;
-	case LTC4245_GPIOADC1:
-	case LTC4245_GPIOADC2:
-	case LTC4245_GPIOADC3:
+	case LTC4245_GPIOADC:
 		voltage = regval * 10;
 		break;
 	default:
@@ -297,9 +293,7 @@ LTC4245_ALARM(in7_min_alarm,	(1 << 2),	L
 LTC4245_ALARM(in8_min_alarm,	(1 << 3),	LTC4245_FAULT2);
 
 /* GPIO voltages */
-LTC4245_VOLTAGE(in9_input,			LTC4245_GPIOADC1);
-LTC4245_VOLTAGE(in10_input,			LTC4245_GPIOADC2);
-LTC4245_VOLTAGE(in11_input,			LTC4245_GPIOADC3);
+LTC4245_VOLTAGE(in9_input,			LTC4245_GPIOADC);
 
 /* Power Consumption (virtual) */
 LTC4245_POWER(power1_input,			LTC4245_12VSENSE);
@@ -342,8 +336,6 @@ static struct attribute *ltc4245_attribu
 	&sensor_dev_attr_in8_min_alarm.dev_attr.attr,
 
 	&sensor_dev_attr_in9_input.dev_attr.attr,
-	&sensor_dev_attr_in10_input.dev_attr.attr,
-	&sensor_dev_attr_in11_input.dev_attr.attr,
 
 	&sensor_dev_attr_power1_input.dev_attr.attr,
 	&sensor_dev_attr_power2_input.dev_attr.attr,
#573 lore raw

PATCH 122/200 signals: check_kill_permission(): dont check creds if same_thread_group()

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Oleg Nesterov <[email protected]>

commit 065add3941bdca54fe04ed3471a96bce9af88793 upstream.

Andrew Tridgell reports that aio_read(SIGEV_SIGNAL) can fail if the notification from the helper thread races with setresuid(), see
http://samba.org/~tridge/junkcode/aio_uid.c

This happens because check_kill_permission() doesn't permit sending a signal to the task with the different cred->xids. But there is not any security reason to check ->cred's when the task sends a signal (private or group-wide) to its sub-thread. Whatever we do, any thread can bypass all security checks and send SIGKILL to all threads, or it can block a signal SIG and do kill(gettid(), SIG) to deliver this signal to another sub-thread. Not to mention that CLONE_THREAD implies CLONE_VM.

Change check_kill_permission() to avoid the credentials check when the sender and the target are from the same thread group.

Also, move "cred = current_cred()" down to avoid calling get_current() twice.

Note: David Howells pointed out we could relax this even more, the CLONE_SIGHAND (without CLONE_THREAD) case probably does not need these checks too.

Roland said:
: The glibc (libpthread) that does set*id across threads has
: been in use for a while (2.3.4?), probably in distro's using kernels as old : or older than any active -stable streams. In the race in question, this : kernel bug is breaking valid POSIX application expectations.

---
 kernel/signal.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)
kernel/signal.c +4 -2
@@ -642,7 +642,7 @@ static inline bool si_fromuser(const str
 static int check_kill_permission(int sig, struct siginfo *info,
 				 struct task_struct *t)
 {
-	const struct cred *cred = current_cred(), *tcred;
+	const struct cred *cred, *tcred;
 	struct pid *sid;
 	int error;
 
@@ -656,8 +656,10 @@ static int check_kill_permission(int sig
 	if (error)
 		return error;
 
+	cred = current_cred();
 	tcred = __task_cred(t);
-	if ((cred->euid ^ tcred->suid) &&
+	if (!same_thread_group(current, t) &&
+	    (cred->euid ^ tcred->suid) &&
 	    (cred->euid ^ tcred->uid) &&
 	    (cred->uid  ^ tcred->suid) &&
 	    (cred->uid  ^ tcred->uid) &&
#574 lore raw

PATCH 123/200 compat: factor out compat_rw_copy_check_uvector from compat_do_readv_writev

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jeff Moyer <[email protected]>

commit b83733639a494d5f42fa00a2506563fbd2d3015d upstream.

It was reported in http://lkml.org/lkml/2010/3/8/309 that 32 bit readv and writev AIO operations were not functioning properly. It turns out that the code to convert the 32bit io vectors to 64 bits was never written. The results of that can be pretty bad, but in my testing, it mostly ended up in generating EFAULT as we walked off the list of I/O vectors provided.

This patch set fixes the problem in my environment. are greatly appreciated.

This patch:

Factor out code that will be used by both compat_do_readv_writev and the compat aio submission code paths.

---
 fs/compat.c            |  130 +++++++++++++++++++++++++++++--------------------
 include/linux/compat.h |    4 +
 2 files changed, 81 insertions(+), 53 deletions(-)
fs/compat.c +77 -53
@@ -568,6 +568,79 @@ out:
 	return ret;
 }
 
+/* A write operation does a read from user space and vice versa */
+#define vrfy_dir(type) ((type) == READ ? VERIFY_WRITE : VERIFY_READ)
+
+ssize_t compat_rw_copy_check_uvector(int type,
+		const struct compat_iovec __user *uvector, unsigned long nr_segs,
+		unsigned long fast_segs, struct iovec *fast_pointer,
+		struct iovec **ret_pointer)
+{
+	compat_ssize_t tot_len;
+	struct iovec *iov = *ret_pointer = fast_pointer;
+	ssize_t ret = 0;
+	int seg;
+
+	/*
+	 * SuS says "The readv() function *may* fail if the iovcnt argument
+	 * was less than or equal to 0, or greater than {IOV_MAX}.  Linux has
+	 * traditionally returned zero for zero segments, so...
+	 */
+	if (nr_segs == 0)
+		goto out;
+
+	ret = -EINVAL;
+	if (nr_segs > UIO_MAXIOV || nr_segs < 0)
+		goto out;
+	if (nr_segs > fast_segs) {
+		ret = -ENOMEM;
+		iov = kmalloc(nr_segs*sizeof(struct iovec), GFP_KERNEL);
+		if (iov == NULL) {
+			*ret_pointer = fast_pointer;
+			goto out;
+		}
+	}
+	*ret_pointer = iov;
+
+	/*
+	 * Single unix specification:
+	 * We should -EINVAL if an element length is not >= 0 and fitting an
+	 * ssize_t.  The total length is fitting an ssize_t
+	 *
+	 * Be careful here because iov_len is a size_t not an ssize_t
+	 */
+	tot_len = 0;
+	ret = -EINVAL;
+	for (seg = 0; seg < nr_segs; seg++) {
+		compat_ssize_t tmp = tot_len;
+		compat_uptr_t buf;
+		compat_ssize_t len;
+
+		if (__get_user(len, &uvector->iov_len) ||
+		   __get_user(buf, &uvector->iov_base)) {
+			ret = -EFAULT;
+			goto out;
+		}
+		if (len < 0)	/* size_t not fitting in compat_ssize_t .. */
+			goto out;
+		tot_len += len;
+		if (tot_len < tmp) /* maths overflow on the compat_ssize_t */
+			goto out;
+		if (!access_ok(vrfy_dir(type), buf, len)) {
+			ret = -EFAULT;
+			goto out;
+		}
+		iov->iov_base = compat_ptr(buf);
+		iov->iov_len = (compat_size_t) len;
+		uvector++;
+		iov++;
+	}
+	ret = tot_len;
+
+out:
+	return ret;
+}
+
 static inline long
 copy_iocb(long nr, u32 __user *ptr32, struct iocb __user * __user *ptr64)
 {
@@ -1077,70 +1150,21 @@ static ssize_t compat_do_readv_writev(in
 {
 	compat_ssize_t tot_len;
 	struct iovec iovstack[UIO_FASTIOV];
-	struct iovec *iov=iovstack, *vector;
+	struct iovec *iov;
 	ssize_t ret;
-	int seg;
 	io_fn_t fn;
 	iov_fn_t fnv;
 
-	/*
-	 * SuS says "The readv() function *may* fail if the iovcnt argument
-	 * was less than or equal to 0, or greater than {IOV_MAX}.  Linux has
-	 * traditionally returned zero for zero segments, so...
-	 */
-	ret = 0;
-	if (nr_segs == 0)
-		goto out;
-
-	/*
-	 * First get the "struct iovec" from user memory and
-	 * verify all the pointers
-	 */
 	ret = -EINVAL;
-	if ((nr_segs > UIO_MAXIOV) || (nr_segs <= 0))
-		goto out;
 	if (!file->f_op)
 		goto out;
-	if (nr_segs > UIO_FASTIOV) {
-		ret = -ENOMEM;
-		iov = kmalloc(nr_segs*sizeof(struct iovec), GFP_KERNEL);
-		if (!iov)
-			goto out;
-	}
+
 	ret = -EFAULT;
 	if (!access_ok(VERIFY_READ, uvector, nr_segs*sizeof(*uvector)))
 		goto out;
 
-	/*
-	 * Single unix specification:
-	 * We should -EINVAL if an element length is not >= 0 and fitting an
-	 * ssize_t.  The total length is fitting an ssize_t
-	 *
-	 * Be careful here because iov_len is a size_t not an ssize_t
-	 */
-	tot_len = 0;
-	vector = iov;
-	ret = -EINVAL;
-	for (seg = 0 ; seg < nr_segs; seg++) {
-		compat_ssize_t tmp = tot_len;
-		compat_ssize_t len;
-		compat_uptr_t buf;
-
-		if (__get_user(len, &uvector->iov_len) ||
-		    __get_user(buf, &uvector->iov_base)) {
-			ret = -EFAULT;
-			goto out;
-		}
-		if (len < 0)	/* size_t not fitting an compat_ssize_t .. */
-			goto out;
-		tot_len += len;
-		if (tot_len < tmp) /* maths overflow on the compat_ssize_t */
-			goto out;
-		vector->iov_base = compat_ptr(buf);
-		vector->iov_len = (compat_size_t) len;
-		uvector++;
-		vector++;
-	}
+	tot_len = compat_rw_copy_check_uvector(type, uvector, nr_segs,
+					       UIO_FASTIOV, iovstack, &iov);
 	if (tot_len == 0) {
 		ret = 0;
 		goto out;
include/linux/compat.h +4 -0
@@ -356,5 +356,9 @@ asmlinkage long compat_sys_newfstatat(un
 asmlinkage long compat_sys_openat(unsigned int dfd, const char __user *filename,
 				  int flags, int mode);
 
+extern ssize_t compat_rw_copy_check_uvector(int type,
+		const struct compat_iovec __user *uvector, unsigned long nr_segs,
+		unsigned long fast_segs, struct iovec *fast_pointer,
+		struct iovec **ret_pointer);
 #endif /* CONFIG_COMPAT */
 #endif /* _LINUX_COMPAT_H */
#575 lore raw

PATCH 124/200 fs/compat_rw_copy_check_uvector: add missing compat_ptr call

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Heiko Carstens <[email protected]>

commit 7cbe17701a0379c7b05a79a6df4f24e41d2afde8 upstream.

A call to access_ok is missing a compat_ptr conversion. Introduced with b83733639a494d5f42fa00a2506563fbd2d3015d "compat: factor out compat_rw_copy_check_uvector from compat_do_readv_writev"

fs/compat.c: In function 'compat_rw_copy_check_uvector':
fs/compat.c:629: warning: passing argument 1 of '__access_ok' makes pointer from integer without a cast

---
 fs/compat.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
fs/compat.c +1 -1
@@ -626,7 +626,7 @@ ssize_t compat_rw_copy_check_uvector(int
 		tot_len += len;
 		if (tot_len < tmp) /* maths overflow on the compat_ssize_t */
 			goto out;
-		if (!access_ok(vrfy_dir(type), buf, len)) {
+		if (!access_ok(vrfy_dir(type), compat_ptr(buf), len)) {
 			ret = -EFAULT;
 			goto out;
 		}
#576 lore raw

PATCH 125/200 do_generic_file_read: clear page errors when issuing a fresh read of the page

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jeff Moyer <[email protected]>

commit 91803b499cca2fe558abad709ce83dc896b80950 upstream.

I/O errors can happen due to temporary failures, like multipath errors or losing network contact with the iSCSI server. Because of that, the VM will retry readpage on the page.

However, do_generic_file_read does not clear PG_error. This causes the system to be unable to actually use the data in the page cache page, even if the subsequent readpage completes successfully!

The function filemap_fault has had a ClearPageError before readpage forever. This patch simply adds the same to do_generic_file_read.

---
 mm/filemap.c |    6 ++++++
 1 file changed, 6 insertions(+)
mm/filemap.c +6 -0
@@ -1099,6 +1099,12 @@ page_not_up_to_date_locked:
 		}
 
 readpage:
+		/*
+		 * A previous I/O error may have been due to temporary
+		 * failures, eg. multipath errors.
+		 * PG_error will be set again if readpage fails.
+		 */
+		ClearPageError(page);
 		/* Start the actual read. The read will unlock the page. */
 		error = mapping->a_ops->readpage(filp, page);
 
#577 lore raw

PATCH 126/200 ipmi: handle run_to_completion properly in deliver_recv_msg()

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jiri Kosina <[email protected]>

commit a747c5abc329611220f16df0bb4cf0ca4a7fdf0c upstream.

If run_to_completion flag is set, it means that we are running in a single-threaded mode, and thus no locks are held.

This fixes a deadlock when IPMI notifier is being called during panic.

---
 drivers/char/ipmi/ipmi_si_intf.c |   11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)
drivers/char/ipmi/ipmi_si_intf.c +8 -3
@@ -314,9 +314,14 @@ static void deliver_recv_msg(struct smi_
 {
 	/* Deliver the message to the upper layer with the lock
 	   released. */
-	spin_unlock(&(smi_info->si_lock));
-	ipmi_smi_msg_received(smi_info->intf, msg);
-	spin_lock(&(smi_info->si_lock));
+
+	if (smi_info->run_to_completion) {
+		ipmi_smi_msg_received(smi_info->intf, msg);
+	} else {
+		spin_unlock(&(smi_info->si_lock));
+		ipmi_smi_msg_received(smi_info->intf, msg);
+		spin_lock(&(smi_info->si_lock));
+	}
 }
 
 static void return_hosed_msg(struct smi_info *smi_info, int cCode)
#578 lore raw

PATCH 127/200 x86, setup: Phoenix BIOS fixup is needed on Dell Inspiron Mini 1012

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Gabor Gombas <[email protected]>

commit 3d6e77a3ddb8e4156b89f4273ff8c7d37abaf781 upstream.

The low-memory corruption checker triggers during suspend/resume, so we need to reserve the low 64k. Don't be fooled that the BIOS identifies itself as "Dell Inc.", it's still Phoenix BIOS.

[ hpa: I think we blacklist almost every BIOS in existence. We should either change this to a whitelist or just make it unconditional. ]

LKML-Reference: <[email protected]>

---
 arch/x86/kernel/setup.c |   11 +++++++++++
 1 file changed, 11 insertions(+)
arch/x86/kernel/setup.c +11 -0
@@ -676,6 +676,17 @@ static struct dmi_system_id __initdata b
 			DMI_MATCH(DMI_BOARD_NAME, "DG45FC"),
 		},
 	},
+	/*
+	 * The Dell Inspiron Mini 1012 has DMI_BIOS_VENDOR = "Dell Inc.", so
+	 * match on the product name.
+	 */
+	{
+		.callback = dmi_low_memory_corruption,
+		.ident = "Phoenix BIOS",
+		.matches = {
+			DMI_MATCH(DMI_PRODUCT_NAME, "Inspiron 1012"),
+		},
+	},
 #endif
 	{}
 };
#579 lore raw

PATCH 128/200 xen: ensure timer tick is resumed even on CPU driving the resume

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Ian Campbell <[email protected]>

commit cd52e17ea8278f8449b6174a8e5ed439a2e44ffb upstream.

The core suspend/resume code is run from stop_machine on CPU0 but parts of the suspend/resume machinery (including xen_arch_resume) are run on whichever CPU happened to schedule the xenwatch kernel thread.

As part of the non-core resume code xen_arch_resume is called in order to restart the timer tick on non-boot processors. The boot processor itself is taken care of by core timekeeping code.

xen_arch_resume uses smp_call_function which does not call the given function on the current processor. This means that we can end up with one CPU not receiving timer ticks if the xenwatch thread happened to be scheduled on CPU > 0.

Use on_each_cpu instead of smp_call_function to ensure the timer tick is resumed everywhere.

---
 arch/x86/xen/suspend.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
arch/x86/xen/suspend.c +2 -2
@@ -60,6 +60,6 @@ static void xen_vcpu_notify_restore(void
 
 void xen_arch_resume(void)
 {
-	smp_call_function(xen_vcpu_notify_restore,
-			       (void *)CLOCK_EVT_NOTIFY_RESUME, 1);
+	on_each_cpu(xen_vcpu_notify_restore,
+		    (void *)CLOCK_EVT_NOTIFY_RESUME, 1);
 }
#580 lore raw

PATCH 129/200 xen: avoid allocation causing potential swap activity on the resume path

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Ian Campbell <[email protected]>

commit b3831cb55d383e8eb55d3b56c715fb48459b87c9 upstream.

Since the device we are resuming could be the device containing the swap device we should ensure that the allocation cannot cause IO.

On resume, this path is triggered when the running system tries to continue using its devices. If it cannot then the resume will fail; to try to avoid this we let it dip into the emergency pools.

The majority of these changes were made when linux-2.6.18-xen.hg changeset e8b49cfbdac0 was ported upstream in a144ff09bc52ef3f3684ed23eadc9c7c0e57b3aa but somehow this hunk was dropped.

---
 drivers/xen/xenbus/xenbus_xs.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/xen/xenbus/xenbus_xs.c +1 -1
@@ -499,7 +499,7 @@ int xenbus_printf(struct xenbus_transact
 #define PRINTF_BUFFER_SIZE 4096
 	char *printf_buffer;
 
-	printf_buffer = kmalloc(PRINTF_BUFFER_SIZE, GFP_KERNEL);
+	printf_buffer = kmalloc(PRINTF_BUFFER_SIZE, GFP_NOIO | __GFP_HIGH);
 	if (printf_buffer == NULL)
 		return -ENOMEM;
 
#581 lore raw

PATCH 130/200 ALSA: hda: Use LPIB for an ASUS device

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Daniel T Chen <[email protected]>

commit dd37f8e8659bc617c3f2a84e007a4824ccdac458 upstream.

Symptom: On the reporter's ASUS device, using PulseAudio in Ubuntu 10.04 LTS results in the PA daemon crashing shortly after attempting to select capture or to configure the audio hardware profile.

Test case: Using Ubuntu 10.04 LTS (Linux 2.6.32.12), Linux 2.6.33, or Linux 2.6.34, adjust the HDA device's capture volume with PulseAudio.

Resolution: add SSID for this machine to the position_fix quirk table, explicitly specifying the LPIB method.

Reported-and-Tested-By Irihapeti
---
 sound/pci/hda/hda_intel.c |    1 +
 1 file changed, 1 insertion(+)
sound/pci/hda/hda_intel.c +1 -0
@@ -2269,6 +2269,7 @@ static struct snd_pci_quirk position_fix
 	SND_PCI_QUIRK(0x1028, 0x01f6, "Dell Latitude 131L", POS_FIX_LPIB),
 	SND_PCI_QUIRK(0x103c, 0x306d, "HP dv3", POS_FIX_LPIB),
 	SND_PCI_QUIRK(0x1043, 0x813d, "ASUS P5AD2", POS_FIX_LPIB),
+	SND_PCI_QUIRK(0x1043, 0x81b3, "ASUS", POS_FIX_LPIB),
 	SND_PCI_QUIRK(0x104d, 0x9069, "Sony VPCS11V9E", POS_FIX_LPIB),
 	SND_PCI_QUIRK(0x1106, 0x3288, "ASUS M2V-MX SE", POS_FIX_LPIB),
 	SND_PCI_QUIRK(0x1179, 0xff10, "Toshiba A100-259", POS_FIX_LPIB),
#582 lore raw

PATCH 131/200 ALSA: hda: Use mb31 quirk for an iMac model

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Daniel T Chen <[email protected]>

commit 26fd74fc01991a18f0e3bd54f8b1b75945ee3dbb upstream.

Symptom: On the reporter's iMac, in Ubuntu 10.04 LTS neither playback nor capture appear audible out-of-the-box.

Test case: Boot from an Ubuntu 10.04 LTS live cd or from an installed configuration and attempt to play or capture audio.

Resolution: Specify the mb31 quirk for this machine in the codec SSID table.

---
 sound/pci/hda/patch_realtek.c |    1 +
 1 file changed, 1 insertion(+)
sound/pci/hda/patch_realtek.c +1 -0
@@ -9392,6 +9392,7 @@ static struct snd_pci_quirk alc882_ssid_
 	SND_PCI_QUIRK(0x106b, 0x1000, "iMac 24", ALC885_IMAC24),
 	SND_PCI_QUIRK(0x106b, 0x2800, "AppleTV", ALC885_IMAC24),
 	SND_PCI_QUIRK(0x106b, 0x2c00, "MacbookPro rev3", ALC885_MBP3),
+	SND_PCI_QUIRK(0x106b, 0x3000, "iMac", ALC889A_MB31),
 	SND_PCI_QUIRK(0x106b, 0x3600, "Macbook 3,1", ALC889A_MB31),
 	SND_PCI_QUIRK(0x106b, 0x3800, "MacbookPro 4,1", ALC885_MBP3),
 	SND_PCI_QUIRK(0x106b, 0x3e00, "iMac 24 Aluminum", ALC885_IMAC24),
#583 lore raw

PATCH 132/200 ALSA: hda: Use LPIB for another mainboard

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Daniel T Chen <[email protected]>

commit b90c076424da8166797bdc34187660fd0124f530 upstream.

Symptom: on the original reporter's VIA VT1708-based board, the PulseAudio daemon dies shortly after the user attempts to play an audio file.

Test case: boot from Ubuntu 10.04 LTS live cd; attempt to play an audio file.

Resolution: add SSID for the original reporter's hardware to the position_fix quirk table, explicitly specifying the LPIB method.

Reported-and-Tested-By Harald
---
 sound/pci/hda/hda_intel.c |    1 +
 1 file changed, 1 insertion(+)
sound/pci/hda/hda_intel.c +1 -0
@@ -2278,6 +2278,7 @@ static struct snd_pci_quirk position_fix
 	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(0x1849, 0x0888, "775Dual-VSTA", POS_FIX_LPIB),
 	SND_PCI_QUIRK(0x8086, 0x2503, "DG965OT AAD63733-203", POS_FIX_LPIB),
 	SND_PCI_QUIRK(0x8086, 0xd601, "eMachines T5212", POS_FIX_LPIB),
 	{}
#584 lore raw

PATCH 133/200 ALSA: hda: Use LPIB for ASUS M2V

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Daniel T Chen <[email protected]>

commit 9f75c1b12c5ef392ddcea575b13560842c28b1b3 upstream.

Symptom: On the reporter's ASUS M2V, using PulseAudio in Ubuntu 10.04 LTS results in the PA daemon crashing shortly after attempting playback of an audio file.

Test case: Using Ubuntu 10.04 LTS (Linux 2.6.32.12), Linux 2.6.33, or Linux 2.6.34, attempt playback of an audio file while PulseAudio is active.

Resolution: add SSID for this machine to the position_fix quirk table, explicitly specifying the LPIB method.

Reported-and-Tested-By D Tangman
---
 sound/pci/hda/hda_intel.c |    1 +
 1 file changed, 1 insertion(+)
sound/pci/hda/hda_intel.c +1 -0
@@ -2270,6 +2270,7 @@ static struct snd_pci_quirk position_fix
 	SND_PCI_QUIRK(0x103c, 0x306d, "HP dv3", POS_FIX_LPIB),
 	SND_PCI_QUIRK(0x1043, 0x813d, "ASUS P5AD2", POS_FIX_LPIB),
 	SND_PCI_QUIRK(0x1043, 0x81b3, "ASUS", POS_FIX_LPIB),
+	SND_PCI_QUIRK(0x1043, 0x81e7, "ASUS M2V", POS_FIX_LPIB),
 	SND_PCI_QUIRK(0x104d, 0x9069, "Sony VPCS11V9E", POS_FIX_LPIB),
 	SND_PCI_QUIRK(0x1106, 0x3288, "ASUS M2V-MX SE", POS_FIX_LPIB),
 	SND_PCI_QUIRK(0x1179, 0xff10, "Toshiba A100-259", POS_FIX_LPIB),
#585 lore raw

PATCH 134/200 vmware balloon: clamp number of collected non-balloonable pages

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Dmitry Torokhov <[email protected]>

commit 55adaa495edc429be84399f83df80dfb7f36598b upstream.

Limit number of accumulated non-balloonable pages during inflation cycle, otherwise there is a chance we will be spinning and growing the list forever. This happens during torture tests when balloon target changes while we are in the middle of inflation cycle and monitor starts refusing to lock pages (since they are not needed anymore).

---
 drivers/misc/vmware_balloon.c |   18 +++++++++++++++---
 1 file changed, 15 insertions(+), 3 deletions(-)
drivers/misc/vmware_balloon.c +15 -3
@@ -45,7 +45,7 @@
 
 MODULE_AUTHOR("VMware, Inc.");
 MODULE_DESCRIPTION("VMware Memory Control (Balloon) Driver");
-MODULE_VERSION("1.2.1.0-K");
+MODULE_VERSION("1.2.1.1-k");
 MODULE_ALIAS("dmi:*:svnVMware*:*");
 MODULE_ALIAS("vmware_vmmemctl");
 MODULE_LICENSE("GPL");
@@ -101,6 +101,8 @@ MODULE_LICENSE("GPL");
 /* Maximum number of page allocations without yielding processor */
 #define VMW_BALLOON_YIELD_THRESHOLD	1024
 
+/* Maximum number of refused pages we accumulate during inflation cycle */
+#define VMW_BALLOON_MAX_REFUSED		16
 
 /*
  * Hypervisor communication port definitions.
@@ -183,6 +185,7 @@ struct vmballoon {
 
 	/* transient list of non-balloonable pages */
 	struct list_head refused_pages;
+	unsigned int n_refused_pages;
 
 	/* balloon size in pages */
 	unsigned int size;
@@ -428,14 +431,21 @@ static int vmballoon_reserve_page(struct
 		/* inform monitor */
 		locked = vmballoon_send_lock_page(b, page_to_pfn(page));
 		if (!locked) {
+			STATS_INC(b->stats.refused_alloc);
+
 			if (b->reset_required) {
 				__free_page(page);
 				return -EIO;
 			}
 
-			/* place on list of non-balloonable pages, retry allocation */
+			/*
+			 * Place page on the list of non-balloonable pages
+			 * and retry allocation, unless we already accumulated
+			 * too many of them, in which case take a breather.
+			 */
 			list_add(&page->lru, &b->refused_pages);
-			STATS_INC(b->stats.refused_alloc);
+			if (++b->n_refused_pages >= VMW_BALLOON_MAX_REFUSED)
+				return -EIO;
 		}
 	} while (!locked);
 
@@ -483,6 +493,8 @@ static void vmballoon_release_refused_pa
 		__free_page(page);
 		STATS_INC(b->stats.refused_free);
 	}
+
+	b->n_refused_pages = 0;
 }
 
 /*
#586 lore raw

PATCH 135/200 Staging: comedi - correct parameter gainlkup for DAQCard-6024E in driver ni_mio_cs.c

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Martin Homuth-Rosemann <[email protected]>

commit ebe8622342f12bed387f7de4b5fb7c52005ccb29 upstream.

Correct at least one of the incorrect specs for a national instrument data acquisition card DAQCard-6024E. This card has only four different gain settings (+-10V, +-5V, +-0.5V, +-0.05V).

---
 drivers/staging/comedi/drivers/ni_mio_cs.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/staging/comedi/drivers/ni_mio_cs.c +1 -1
@@ -123,7 +123,7 @@ static const struct ni_board_struct ni_b
 	 .adbits = 12,
 	 .ai_fifo_depth = 1024,
 	 .alwaysdither = 0,
-	 .gainlkup = ai_gain_16,
+	 .gainlkup = ai_gain_4,
 	 .ai_speed = 5000,
 	 .n_aochan = 2,
 	 .aobits = 12,
#587 lore raw

PATCH 136/200 clocksource: sh_tmu: compute mult and shift before registration

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Aurelien Jarno <[email protected]>

commit 66f49121ffa41a19c59965b31b046d8368fec3c7 upstream.

Since commit 98962465ed9e6ea99c38e0af63fe1dcb5a79dc25 ("nohz: Prevent clocksource wrapping during idle"), the CPU of an R2D board never goes to idle. This commit assumes that mult and shift are assigned before the clocksource is registered. As a consequence the safe maximum sleep time is negative and the CPU never goes into idle.

This patch fixes the problem by moving mult and shift initialization from sh_tmu_clocksource_enable() to sh_tmu_register_clocksource().

---
 drivers/clocksource/sh_tmu.c |   20 +++++++++++---------
 1 file changed, 11 insertions(+), 9 deletions(-)
drivers/clocksource/sh_tmu.c +11 -9
@@ -200,16 +200,8 @@ static cycle_t sh_tmu_clocksource_read(s
 static int sh_tmu_clocksource_enable(struct clocksource *cs)
 {
 	struct sh_tmu_priv *p = cs_to_sh_tmu(cs);
-	int ret;
 
-	ret = sh_tmu_enable(p);
-	if (ret)
-		return ret;
-
-	/* TODO: calculate good shift from rate and counter bit width */
-	cs->shift = 10;
-	cs->mult = clocksource_hz2mult(p->rate, cs->shift);
-	return 0;
+	return sh_tmu_enable(p);
 }
 
 static void sh_tmu_clocksource_disable(struct clocksource *cs)
@@ -229,6 +221,16 @@ static int sh_tmu_register_clocksource(s
 	cs->disable = sh_tmu_clocksource_disable;
 	cs->mask = CLOCKSOURCE_MASK(32);
 	cs->flags = CLOCK_SOURCE_IS_CONTINUOUS;
+
+	/* clk_get_rate() needs an enabled clock */
+	clk_enable(p->clk);
+	/* channel will be configured at parent clock / 4 */
+	p->rate = clk_get_rate(p->clk) / 4;
+	clk_disable(p->clk);
+	/* TODO: calculate good shift from rate and counter bit width */
+	cs->shift = 10;
+	cs->mult = clocksource_hz2mult(p->rate, cs->shift);
+
 	pr_info("sh_tmu: %s used as clock source\n", cs->name);
 	clocksource_register(cs);
 	return 0;
#588 lore raw

PATCH 137/200 clocksource: sh_cmt: compute mult and shift before registration

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Paul Mundt <[email protected]>

commit f4d7c3565c1692c54d9152b52090fe73f0029e37 upstream.

Based on the sh_tmu change in 66f49121ffa41a19c59965b31b046d8368fec3c7 ("clocksource: sh_tmu: compute mult and shift before registration"). The same issues impact the sh_cmt driver, so we take the same approach here.

---
 drivers/clocksource/sh_cmt.c |   21 ++++++++++++---------
 1 file changed, 12 insertions(+), 9 deletions(-)
drivers/clocksource/sh_cmt.c +12 -9
@@ -413,18 +413,10 @@ static cycle_t sh_cmt_clocksource_read(s
 static int sh_cmt_clocksource_enable(struct clocksource *cs)
 {
 	struct sh_cmt_priv *p = cs_to_sh_cmt(cs);
-	int ret;
 
 	p->total_cycles = 0;
 
-	ret = sh_cmt_start(p, FLAG_CLOCKSOURCE);
-	if (ret)
-		return ret;
-
-	/* TODO: calculate good shift from rate and counter bit width */
-	cs->shift = 0;
-	cs->mult = clocksource_hz2mult(p->rate, cs->shift);
-	return 0;
+	return sh_cmt_start(p, FLAG_CLOCKSOURCE);
 }
 
 static void sh_cmt_clocksource_disable(struct clocksource *cs)
@@ -451,7 +443,18 @@ static int sh_cmt_register_clocksource(s
 	cs->resume = sh_cmt_clocksource_resume;
 	cs->mask = CLOCKSOURCE_MASK(sizeof(unsigned long) * 8);
 	cs->flags = CLOCK_SOURCE_IS_CONTINUOUS;
+
+	/* clk_get_rate() needs an enabled clock */
+	clk_enable(p->clk);
+	p->rate = clk_get_rate(p->clk) / (p->width == 16) ? 512 : 8;
+	clk_disable(p->clk);
+
+	/* TODO: calculate good shift from rate and counter bit width */
+	cs->shift = 10;
+	cs->mult = clocksource_hz2mult(p->rate, cs->shift);
+
 	pr_info("sh_cmt: %s used as clock source\n", cs->name);
+
 	clocksource_register(cs);
 	return 0;
 }
#589 lore raw

PATCH 138/200 gconfig: fix build failure on fedora 13

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Richard Kennedy <[email protected]>

commit cbab05f041a4cff6ca15856bdd35238b282b64eb upstream.

Making gconfig fails on fedora 13 as the linker cannot resolve dlsym.

Adding libdl to the link command fixes this.

make shows this error :-
/usr/bin/ld: scripts/kconfig/kconfig_load.o: undefined reference to symbol 'dlsym@@GLIBC_2.2.5' /usr/bin/ld: note: 'dlsym@@GLIBC_2.2.5' is defined in DSO /lib64/libdl.so.2 so try adding it to the linker command line /lib64/libdl.so.2: could not read symbols: Invalid operation

tested on x86_64 fedora 13.

---
 scripts/kconfig/Makefile |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
scripts/kconfig/Makefile +1 -1
@@ -208,7 +208,7 @@ HOSTCFLAGS_zconf.tab.o	:= -I$(src)
 HOSTLOADLIBES_qconf	= $(KC_QT_LIBS) -ldl
 HOSTCXXFLAGS_qconf.o	= $(KC_QT_CFLAGS) -D LKC_DIRECT_LINK
 
-HOSTLOADLIBES_gconf	= `pkg-config --libs gtk+-2.0 gmodule-2.0 libglade-2.0`
+HOSTLOADLIBES_gconf	= `pkg-config --libs gtk+-2.0 gmodule-2.0 libglade-2.0` -ldl
 HOSTCFLAGS_gconf.o	= `pkg-config --cflags gtk+-2.0 gmodule-2.0 libglade-2.0` \
                           -D LKC_DIRECT_LINK
 
#590 lore raw

PATCH 139/200 arch/x86/kernel: Add missing spin_unlock

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Julia Lawall <[email protected]>

commit 84fe6c19e4a598e8071e3bd1b2c923454eae1268 upstream.

Add a spin_unlock missing on the error path. The locks and unlocks are balanced in other functions, so it seems that the same should be the case here.

The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)

// <smpl>
@@
expression E1;
@@

* spin_lock(E1,...);
<+... when != E1

  if (...) {
    ... when != E1

* return ...;
}
...+>
* spin_unlock(E1,...);
// </smpl>

---
 arch/x86/kernel/amd_iommu.c |   12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)
arch/x86/kernel/amd_iommu.c +9 -3
@@ -1420,6 +1420,7 @@ static int __attach_device(struct device
 			   struct protection_domain *domain)
 {
 	struct iommu_dev_data *dev_data, *alias_data;
+	int ret;
 
 	dev_data   = get_dev_data(dev);
 	alias_data = get_dev_data(dev_data->alias);
@@ -1431,13 +1432,14 @@ static int __attach_device(struct device
 	spin_lock(&domain->lock);
 
 	/* Some sanity checks */
+	ret = -EBUSY;
 	if (alias_data->domain != NULL &&
 	    alias_data->domain != domain)
-		return -EBUSY;
+		goto out_unlock;
 
 	if (dev_data->domain != NULL &&
 	    dev_data->domain != domain)
-		return -EBUSY;
+		goto out_unlock;
 
 	/* Do real assignment */
 	if (dev_data->alias != dev) {
@@ -1453,10 +1455,14 @@ static int __attach_device(struct device
 
 	atomic_inc(&dev_data->bind);
 
+	ret = 0;
+
+out_unlock:
+
 	/* ready */
 	spin_unlock(&domain->lock);
 
-	return 0;
+	return ret;
 }
 
 /*
#591 lore raw

PATCH 140/200 pcmcia: only keep saved I365_CSCINT flag if there is no PCI irq

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Dominik Brodowski <[email protected]>

commit 02caa56e4b789b80ae7e0f0f0789f94b44ad32ef upstream.

Keeping the saved I365_CSCINT flag around breaks PCMCIA on some system, and is only needed on a few systems to get PCMCIA to work. This patch allows PCMCIA to work on both types, and it fixes
https://bugzilla.kernel.org/show_bug.cgi?id=16015

---
 drivers/pcmcia/yenta_socket.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/pcmcia/yenta_socket.c +3 -2
@@ -975,7 +975,7 @@ static irqreturn_t yenta_probe_handler(i
 /* probes the PCI interrupt, use only on override functions */
 static int yenta_probe_cb_irq(struct yenta_socket *socket)
 {
-	u8 reg;
+	u8 reg = 0;
 
 	if (!socket->cb_irq)
 		return -1;
@@ -989,7 +989,8 @@ static int yenta_probe_cb_irq(struct yen
 	}
 
 	/* generate interrupt, wait */
-	reg = exca_readb(socket, I365_CSCINT);
+	if (!socket->dev->irq)
+		reg = exca_readb(socket, I365_CSCINT);
 	exca_writeb(socket, I365_CSCINT, reg | I365_CSC_STSCHG);
 	cb_writel(socket, CB_SOCKET_EVENT, -1);
 	cb_writel(socket, CB_SOCKET_MASK, CB_CSTSMASK);
#592 lore raw

PATCH 141/200 pcmcia: avoid validate_cis failure on CIS override

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Dominik Brodowski <[email protected]>

commit b83156b52dd77979cc93bafc2283929532f6f7d0 upstream.

Commit a8408c17 introduced a new check to pccard_validate_cis(), which avoids any "late" calls to this function. This broke the insertion of cards which require a CIS override which changes the number of card functions. Fix this by asserting that this is _not_ a late call, but a proper call early during the card insertion process.

Fixes https://bugzilla.kernel.org/show_bug.cgi?id=16138

---
 drivers/pcmcia/ds.c |    1 +
 1 file changed, 1 insertion(+)
drivers/pcmcia/ds.c +1 -0
@@ -682,6 +682,7 @@ static void pcmcia_requery(struct pcmcia
 		if (old_funcs != new_funcs) {
 			/* we need to re-start */
 			pcmcia_card_remove(s, NULL);
+			s->functions = 0;
 			pcmcia_card_add(s);
 		}
 	}
#593 lore raw

PATCH 142/200 mac80211: fix deauth before assoc

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Johannes Berg <[email protected]>

commit b054b747a694927879c94dd11af54d04346aed7d upstream.

When we receive a deauthentication frame before having successfully associated, we neither print a message nor abort assocation. The former makes it hard to debug, while the latter later causes a warning in cfg80211 when, as will typically be the case, association timed out.

This warning was reported by many, e.g. in
https://bugzilla.kernel.org/show_bug.cgi?id=15981,
but I couldn't initially pinpoint it. I verified the fix by hacking hostapd to send a deauth frame instead of an association response.

---
 net/mac80211/mlme.c |   40 ++++++++++++++++++++++++++++++++++++++--
 1 file changed, 38 insertions(+), 2 deletions(-)
net/mac80211/mlme.c +38 -2
@@ -1530,9 +1530,45 @@ static void ieee80211_sta_rx_queued_mgmt
 	mutex_unlock(&ifmgd->mtx);
 
 	if (skb->len >= 24 + 2 /* mgmt + deauth reason */ &&
-	    (fc & IEEE80211_FCTL_STYPE) == IEEE80211_STYPE_DEAUTH)
-		cfg80211_send_deauth(sdata->dev, (u8 *)mgmt, skb->len);
+	    (fc & IEEE80211_FCTL_STYPE) == IEEE80211_STYPE_DEAUTH) {
+		struct ieee80211_local *local = sdata->local;
+		struct ieee80211_work *wk;
+
+		mutex_lock(&local->work_mtx);
+		list_for_each_entry(wk, &local->work_list, list) {
+			if (wk->sdata != sdata)
+				continue;
+
+			if (wk->type != IEEE80211_WORK_ASSOC)
+				continue;
+
+			if (memcmp(mgmt->bssid, wk->filter_ta, ETH_ALEN))
+				continue;
+			if (memcmp(mgmt->sa, wk->filter_ta, ETH_ALEN))
+				continue;
 
+			/*
+			 * Printing the message only here means we can't
+			 * spuriously print it, but it also means that it
+			 * won't be printed when the frame comes in before
+			 * we even tried to associate or in similar cases.
+			 *
+			 * Ultimately, I suspect cfg80211 should print the
+			 * messages instead.
+			 */
+			printk(KERN_DEBUG
+			       "%s: deauthenticated from %pM (Reason: %u)\n",
+			       sdata->name, mgmt->bssid,
+			       le16_to_cpu(mgmt->u.deauth.reason_code));
+
+			list_del_rcu(&wk->list);
+			free_work(wk);
+			break;
+		}
+		mutex_unlock(&local->work_mtx);
+
+		cfg80211_send_deauth(sdata->dev, (u8 *)mgmt, skb->len);
+	}
  out:
 	kfree_skb(skb);
 }
#594 lore raw

PATCH 143/200 ath5k: retain promiscuous setting

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Bob Copeland <[email protected]>

commit 6b5dcccb495b66b3b0b9581cdccfed038e5d68a2 upstream.

Commit 56d1de0a21db28e41741cfa0a66e18bc8d920554, "ath5k: clean up filter flags setting" introduced a regression in monitor mode such that the promisc filter flag would get lost.

Although we set the promisc flag when it changed, we did not preserve it across subsequent calls to configure_filter. This patch restores the original functionality.

---
 drivers/net/wireless/ath/ath5k/base.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/net/wireless/ath/ath5k/base.c +3 -1
@@ -2994,13 +2994,15 @@ static void ath5k_configure_filter(struc
 
 	if (changed_flags & (FIF_PROMISC_IN_BSS | FIF_OTHER_BSS)) {
 		if (*new_flags & FIF_PROMISC_IN_BSS) {
-			rfilt |= AR5K_RX_FILTER_PROM;
 			__set_bit(ATH_STAT_PROMISC, sc->status);
 		} else {
 			__clear_bit(ATH_STAT_PROMISC, sc->status);
 		}
 	}
 
+	if (test_bit(ATH_STAT_PROMISC, sc->status))
+		rfilt |= AR5K_RX_FILTER_PROM;
+
 	/* Note, AR5K_RX_FILTER_MCAST is already enabled */
 	if (*new_flags & FIF_ALLMULTI) {
 		mfilt[0] =  ~0;
#595 lore raw

PATCH 144/200 ahci: add pci quirk for JMB362

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Tejun Heo <[email protected]>

commit 4daedcfe8c6851aa01cc1997220f2577f4039c13 upstream.

JMB362 is a new variant of jmicron controller which is similar to JMB360 but has two SATA ports instead of one. As there is no PATA port, single function AHCI mode can be used as in JMB360. Add pci quirk for JMB362.

---
 drivers/pci/quirks.c    |    5 ++++-
 include/linux/pci_ids.h |    1 +
 2 files changed, 5 insertions(+), 1 deletion(-)
drivers/pci/quirks.c +4 -1
@@ -1457,7 +1457,8 @@ static void quirk_jmicron_ata(struct pci
 	conf5 &= ~(1 << 24);  /* Clear bit 24 */
 
 	switch (pdev->device) {
-	case PCI_DEVICE_ID_JMICRON_JMB360:
+	case PCI_DEVICE_ID_JMICRON_JMB360: /* SATA single port */
+	case PCI_DEVICE_ID_JMICRON_JMB362: /* SATA dual ports */
 		/* The controller should be in single function ahci mode */
 		conf1 |= 0x0002A100; /* Set 8, 13, 15, 17 */
 		break;
@@ -1493,12 +1494,14 @@ static void quirk_jmicron_ata(struct pci
 }
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_JMICRON, PCI_DEVICE_ID_JMICRON_JMB360, quirk_jmicron_ata);
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_JMICRON, PCI_DEVICE_ID_JMICRON_JMB361, quirk_jmicron_ata);
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_JMICRON, PCI_DEVICE_ID_JMICRON_JMB362, quirk_jmicron_ata);
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_JMICRON, PCI_DEVICE_ID_JMICRON_JMB363, quirk_jmicron_ata);
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_JMICRON, PCI_DEVICE_ID_JMICRON_JMB365, quirk_jmicron_ata);
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_JMICRON, PCI_DEVICE_ID_JMICRON_JMB366, quirk_jmicron_ata);
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_JMICRON, PCI_DEVICE_ID_JMICRON_JMB368, quirk_jmicron_ata);
 DECLARE_PCI_FIXUP_RESUME_EARLY(PCI_VENDOR_ID_JMICRON, PCI_DEVICE_ID_JMICRON_JMB360, quirk_jmicron_ata);
 DECLARE_PCI_FIXUP_RESUME_EARLY(PCI_VENDOR_ID_JMICRON, PCI_DEVICE_ID_JMICRON_JMB361, quirk_jmicron_ata);
+DECLARE_PCI_FIXUP_RESUME_EARLY(PCI_VENDOR_ID_JMICRON, PCI_DEVICE_ID_JMICRON_JMB362, quirk_jmicron_ata);
 DECLARE_PCI_FIXUP_RESUME_EARLY(PCI_VENDOR_ID_JMICRON, PCI_DEVICE_ID_JMICRON_JMB363, quirk_jmicron_ata);
 DECLARE_PCI_FIXUP_RESUME_EARLY(PCI_VENDOR_ID_JMICRON, PCI_DEVICE_ID_JMICRON_JMB365, quirk_jmicron_ata);
 DECLARE_PCI_FIXUP_RESUME_EARLY(PCI_VENDOR_ID_JMICRON, PCI_DEVICE_ID_JMICRON_JMB366, quirk_jmicron_ata);
include/linux/pci_ids.h +1 -0
@@ -2321,6 +2321,7 @@
 #define PCI_VENDOR_ID_JMICRON		0x197B
 #define PCI_DEVICE_ID_JMICRON_JMB360	0x2360
 #define PCI_DEVICE_ID_JMICRON_JMB361	0x2361
+#define PCI_DEVICE_ID_JMICRON_JMB362	0x2362
 #define PCI_DEVICE_ID_JMICRON_JMB363	0x2363
 #define PCI_DEVICE_ID_JMICRON_JMB365	0x2365
 #define PCI_DEVICE_ID_JMICRON_JMB366	0x2366
#596 lore raw

PATCH 145/200 firewire: core: check for 1394a compliant IRM, fix inaccessibility of Sony camcorder

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Stefan Richter <[email protected]>

commit 10389536742cefbedecb67a5b2906f155cf3a1c3 upstream.

Per IEEE 1394 clause 8.4.2.3, a contender for the IRM role shall check whether the current IRM complies to 1394a-2000 or later. If not force a compliant node (e.g. itself) to become IRM. This was implemented in the older ieee1394 driver but not yet in firewire-core.

An older Sony camcorder (Sony DCR-TRV25) which implements 1394-1995 IRM but neither 1394a-2000 IRM nor BM was now found to cause an interoperability bug:
- Camcorder becomes root node when plugged in, hence gets IRM role.
- firewire-core successfully contends for BM role, proceeds to perform gap count optimization and resets the bus.
- Sony camcorder ignores presence of a BM (against the spec, this is a firmware bug), performs its idea of gap count optimization and resets the bus.
- Preceding two steps are repeated endlessly, bus never settles, regular I/O is practically impossible.
http://thread.gmane.org/gmane.linux.kernel.firewire.user/3913

This is an interoperability regression from the old to the new drivers. Fix it indirectly by adding the 1394a IRM check. The spec suggests three and a half methods to determine 1394a compliance of a remote IRM; we choose the method of testing the Config_ROM.Bus_Info.generation field. This is data that firewire-core should have readily available at this point, i.e. does not require extra I/O.

---
 drivers/firewire/core-card.c |   24 +++++++++++++++++++-----
 1 file changed, 19 insertions(+), 5 deletions(-)
drivers/firewire/core-card.c +19 -5
@@ -231,7 +231,7 @@ void fw_schedule_bm_work(struct fw_card
 static void fw_card_bm_work(struct work_struct *work)
 {
 	struct fw_card *card = container_of(work, struct fw_card, work.work);
-	struct fw_device *root_device;
+	struct fw_device *root_device, *irm_device;
 	struct fw_node *root_node;
 	unsigned long flags;
 	int root_id, new_root_id, irm_id, local_id;
@@ -239,6 +239,7 @@ static void fw_card_bm_work(struct work_
 	bool do_reset = false;
 	bool root_device_is_running;
 	bool root_device_is_cmc;
+	bool irm_is_1394_1995_only;
 
 	spin_lock_irqsave(&card->lock, flags);
 
@@ -248,12 +249,18 @@ static void fw_card_bm_work(struct work_
 	}
 
 	generation = card->generation;
+
 	root_node = card->root_node;
 	fw_node_get(root_node);
 	root_device = root_node->data;
 	root_device_is_running = root_device &&
 			atomic_read(&root_device->state) == FW_DEVICE_RUNNING;
 	root_device_is_cmc = root_device && root_device->cmc;
+
+	irm_device = card->irm_node->data;
+	irm_is_1394_1995_only = irm_device && irm_device->config_rom &&
+			(irm_device->config_rom[2] & 0x000000f0) == 0;
+
 	root_id  = root_node->node_id;
 	irm_id   = card->irm_node->node_id;
 	local_id = card->local_node->node_id;
@@ -276,8 +283,15 @@ static void fw_card_bm_work(struct work_
 
 		if (!card->irm_node->link_on) {
 			new_root_id = local_id;
-			fw_notify("IRM has link off, making local node (%02x) root.\n",
-				  new_root_id);
+			fw_notify("%s, making local node (%02x) root.\n",
+				  "IRM has link off", new_root_id);
+			goto pick_me;
+		}
+
+		if (irm_is_1394_1995_only) {
+			new_root_id = local_id;
+			fw_notify("%s, making local node (%02x) root.\n",
+				  "IRM is not 1394a compliant", new_root_id);
 			goto pick_me;
 		}
 
@@ -316,8 +330,8 @@ static void fw_card_bm_work(struct work_
 			 * root, and thus, IRM.
 			 */
 			new_root_id = local_id;
-			fw_notify("BM lock failed, making local node (%02x) root.\n",
-				  new_root_id);
+			fw_notify("%s, making local node (%02x) root.\n",
+				  "BM lock failed", new_root_id);
 			goto pick_me;
 		}
 	} else if (card->bm_generation != generation) {
#597 lore raw

PATCH 146/200 misc: Fix allocation borrowed by vhost_net

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Alan Cox <[email protected]>

commit 79907d89c397b8bc2e05b347ec94e928ea919d33 upstream.

10, 233 is allocated officially to /dev/kmview which is shipping in Ubuntu and Debian distributions. vhost_net seem to have borrowed it without making a proper request and this causes regressions in the other distributions.

vhost_net can use a dynamic minor so use that instead. Also update the file with a comment to try and avoid future misunderstandings.

[ We should have caught this before 2.6.34 got released. - Linus ]
---
 drivers/vhost/net.c        |    2 +-
 include/linux/miscdevice.h |    7 ++++++-
 2 files changed, 7 insertions(+), 2 deletions(-)
drivers/vhost/net.c +1 -1
@@ -637,7 +637,7 @@ const static struct file_operations vhos
 };
 
 static struct miscdevice vhost_net_misc = {
-	VHOST_NET_MINOR,
+	MISC_DYNAMIC_MINOR,
 	"vhost-net",
 	&vhost_net_fops,
 };
include/linux/miscdevice.h +6 -1
@@ -3,6 +3,12 @@
 #include <linux/module.h>
 #include <linux/major.h>
 
+/*
+ *	These allocations are managed by [email protected]. If you use an
+ *	entry that is not in assigned your entry may well be moved and
+ *	reassigned, or set dynamic if a fixed value is not justified.
+ */
+
 #define PSMOUSE_MINOR		1
 #define MS_BUSMOUSE_MINOR	2
 #define ATIXL_BUSMOUSE_MINOR	3
@@ -30,7 +36,6 @@
 #define HPET_MINOR		228
 #define FUSE_MINOR		229
 #define KVM_MINOR		232
-#define VHOST_NET_MINOR		233
 #define MISC_DYNAMIC_MINOR	255
 
 struct device;
#598 lore raw

PATCH 147/200 cgroups: alloc_css_id() increments hierarchy depth

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Greg Thelen <[email protected]>

commit 94b3dd0f7bb393d93e84a173b1df9b8b64c83ac4 upstream.

Child groups should have a greater depth than their parents. Prior to this change, the parent would incorrectly report zero memory usage for child cgroups when use_hierarchy is enabled.

test script:
mount -t cgroup none /cgroups -o memory
cd /cgroups
mkdir cg1

echo 1 > cg1/memory.use_hierarchy
mkdir cg1/cg11

echo $$ > cg1/cg11/tasks
dd if=/dev/zero of=/tmp/foo bs=1M count=1

echo
echo CHILD
grep cache cg1/cg11/memory.stat

echo
echo PARENT
grep cache cg1/memory.stat

echo $$ > tasks
rmdir cg1/cg11 cg1
cd /
umount /cgroups

Using fae9c79, a recent patch that changed alloc_css_id() depth computation, the parent incorrectly reports zero usage:

  root@ubuntu:~# ./test
  1+0 records in
  1+0 records out
  1048576 bytes (1.0 MB) copied, 0.0151844 s, 69.1 MB/s

CHILD
cache 1048576
total_cache 1048576

PARENT
cache 0
total_cache 0

With this patch, the parent correctly includes child usage:

  root@ubuntu:~# ./test
  1+0 records in
  1+0 records out
  1048576 bytes (1.0 MB) copied, 0.0136827 s, 76.6 MB/s

CHILD
cache 1052672
total_cache 1052672

PARENT
cache 0
total_cache 1052672

---
 kernel/cgroup.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/cgroup.c +1 -1
@@ -4599,7 +4599,7 @@ static int alloc_css_id(struct cgroup_su
 	parent_css = parent->subsys[subsys_id];
 	child_css = child->subsys[subsys_id];
 	parent_id = parent_css->id;
-	depth = parent_id->depth;
+	depth = parent_id->depth + 1;
 
 	child_id = get_new_cssid(ss, depth);
 	if (IS_ERR(child_id))
#599 lore raw

PATCH 148/200 perf_events: Fix resource leak in x86 __hw_perf_event_init()

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Stephane Eranian <[email protected]>

commit 4b24a88b35e15e04bd8f2c5dda65b5dc8ebca05f upstream.

If reserve_pmc_hardware() succeeds but reserve_ds_buffers() fails, then we need to release_pmc_hardware. It won't be done by the destroy() callback because we return before setting it in case of error.

LKML-Reference: <[email protected]>

---
 arch/x86/kernel/cpu/perf_event.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)
arch/x86/kernel/cpu/perf_event.c +4 -1
@@ -460,8 +460,11 @@ static int __hw_perf_event_init(struct p
 		if (atomic_read(&active_events) == 0) {
 			if (!reserve_pmc_hardware())
 				err = -EBUSY;
-			else
+			else {
 				err = reserve_bts_hardware();
+				if (err)
+					release_pmc_hardware();
+			}
 		}
 		if (!err)
 			atomic_inc(&active_events);
#600 lore raw

PATCH 149/200 sata_nv: dont diddle with nIEN on mcp55

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Tejun Heo <[email protected]>

commit f3faf8fc3fab45c3526efe8c9e99bb23f8723350 upstream.

On mcp55, nIEN gets stuck once set and liteon blueray rom iHOS104-08 violates ATA specification and fails to set I on D2H Reg FIS if nIEN is set when the command was issued. When the other party is following the spec, both devices can work fine but when the two flaws are put together, they can't talk to each other.

mcp55 has its own IRQ masking mechanism and there's no reason to mess with nIEN in the first place. Fix it by dropping nIEN diddling from nv_mcp55_freeze/thaw().

This was originally reported by Cengiz. Although Cengiz hasn't verified the fix yet, I could reproduce this problem and verfiy the fix. Even if Cengiz is experiencing different or additional problems, this patch is needed.

---
 drivers/ata/sata_nv.c |    2 --
 1 file changed, 2 deletions(-)
drivers/ata/sata_nv.c +0 -2
@@ -1674,7 +1674,6 @@ static void nv_mcp55_freeze(struct ata_p
 	mask = readl(mmio_base + NV_INT_ENABLE_MCP55);
 	mask &= ~(NV_INT_ALL_MCP55 << shift);
 	writel(mask, mmio_base + NV_INT_ENABLE_MCP55);
-	ata_sff_freeze(ap);
 }
 
 static void nv_mcp55_thaw(struct ata_port *ap)
@@ -1688,7 +1687,6 @@ static void nv_mcp55_thaw(struct ata_por
 	mask = readl(mmio_base + NV_INT_ENABLE_MCP55);
 	mask |= (NV_INT_MASK_MCP55 << shift);
 	writel(mask, mmio_base + NV_INT_ENABLE_MCP55);
-	ata_sff_thaw(ap);
 }
 
 static void nv_adma_error_handler(struct ata_port *ap)
#601 lore raw

PATCH 150/200 sata_via: magic vt6421 fix for transmission problems w/ WD drives

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Tejun Heo <[email protected]>

commit 8b27ff4cf6d15964aa2987aeb58db4dfb1f87a19 upstream.

vt6421 has problems talking to recent WD drives. It causes a lot of transmission errors while high bandwidth transfer as reported in the following bugzilla entry.

https://bugzilla.kernel.org/show_bug.cgi?id=15173

Joseph Chan provided the following fix. I don't have any idea what it does but I can verify the issue is gone with the patch applied.

Originally-from: Joseph Chan <[email protected]>

---
 drivers/ata/sata_via.c |   13 +++++++++++++
 1 file changed, 13 insertions(+)
drivers/ata/sata_via.c +13 -0
@@ -575,6 +575,19 @@ static void svia_configure(struct pci_de
 		tmp8 |= NATIVE_MODE_ALL;
 		pci_write_config_byte(pdev, SATA_NATIVE_MODE, tmp8);
 	}
+
+	/*
+	 * vt6421 has problems talking to some drives.  The following
+	 * is the magic fix from Joseph Chan <[email protected]>.
+	 * Please add proper documentation if possible.
+	 *
+	 * https://bugzilla.kernel.org/show_bug.cgi?id=15173
+	 */
+	if (pdev->device == 0x3249) {
+		pci_read_config_byte(pdev, 0x52, &tmp8);
+		tmp8 |= 1 << 2;
+		pci_write_config_byte(pdev, 0x52, tmp8);
+	}
 }
 
 static int svia_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
#602 lore raw

PATCH 151/200 drm/i915: Rebind bo if currently bound with incorrect alignment.

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Chris Wilson <[email protected]>

commit ac0c6b5ad3b3b513e1057806d4b7627fcc0ecc27 upstream.

Whilst pinning the buffer, check that that its current alignment matches the requested alignment. If it does not, rebind.

This should clear up any final render errors whilst resuming, for reference:

Bug 27070 - [i915] Page table errors with empty ringbuffer
https://bugs.freedesktop.org/show_bug.cgi?id=27070

Bug 15502 - render error detected, EIR: 0x00000010
https://bugzilla.kernel.org/show_bug.cgi?id=15502

Bug 13844 - i915 error: "render error detected"
https://bugzilla.kernel.org/show_bug.cgi?id=13844

---
 drivers/gpu/drm/i915/i915_gem.c |   11 +++++++++++
 1 file changed, 11 insertions(+)
drivers/gpu/drm/i915/i915_gem.c +11 -0
@@ -4239,6 +4239,17 @@ i915_gem_object_pin(struct drm_gem_objec
 	int ret;
 
 	i915_verify_inactive(dev, __FILE__, __LINE__);
+
+	if (obj_priv->gtt_space != NULL) {
+		if (alignment == 0)
+			alignment = i915_gem_get_gtt_alignment(obj);
+		if (obj_priv->gtt_offset & (alignment - 1)) {
+			ret = i915_gem_object_unbind(obj);
+			if (ret)
+				return ret;
+		}
+	}
+
 	if (obj_priv->gtt_space == NULL) {
 		ret = i915_gem_object_bind_to_gtt(obj, alignment);
 		if (ret)
#603 lore raw

PATCH 152/200 drm/i915: Kill dangerous pending-flip debugging

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Chris Wilson <[email protected]>

commit 9908ff736adf261e749b4887486a32ffa209304c upstream.

We can, by virtue of a vblank interrupt firing in the middle of setting up the unpin work (i.e. after we set the unpin_work field and before we write to the ringbuffer) enter intel_finish_page_flip() prior to receiving the pending flip notification. Therefore we can expect to hit intel_finish_page_flip() under normal circumstances without a pending flip and even without installing the pending_flip_obj. This is exacerbated by aperture thrashing whilst binding the framebuffer

Bug 28079 - "glresize" causes kernel panic in intel_finish_page_flip.
https://bugs.freedesktop.org/show_bug.cgi?id=28079

---
 drivers/gpu/drm/i915/intel_display.c |    6 ------
 1 file changed, 6 deletions(-)
drivers/gpu/drm/i915/intel_display.c +0 -6
@@ -4155,12 +4155,6 @@ void intel_finish_page_flip(struct drm_d
 	spin_lock_irqsave(&dev->event_lock, flags);
 	work = intel_crtc->unpin_work;
 	if (work == NULL || !work->pending) {
-		if (work && !work->pending) {
-			obj_priv = to_intel_bo(work->pending_flip_obj);
-			DRM_DEBUG_DRIVER("flip finish: %p (%d) not pending?\n",
-					 obj_priv,
-					 atomic_read(&obj_priv->pending_flip));
-		}
 		spin_unlock_irqrestore(&dev->event_lock, flags);
 		return;
 	}
#604 lore raw

PATCH 153/200 USB: mos7840: fix null-pointer dereference

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Johan Hovold <[email protected]>

commit b41709f1263bb1ad37efc43fea0bb0b670c12e78 upstream.

Fix null-pointer dereference on error path.

---
 drivers/usb/serial/mos7840.c |    1 -
 1 file changed, 1 deletion(-)
drivers/usb/serial/mos7840.c +0 -1
@@ -731,7 +731,6 @@ static void mos7840_bulk_in_callback(str
 	mos7840_port = urb->context;
 	if (!mos7840_port) {
 		dbg("%s", "NULL mos7840_port pointer");
-		mos7840_port->read_urb_busy = false;
 		return;
 	}
 
#605 lore raw

PATCH 154/200 USB: xhci: Wait for host to start running.

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Sarah Sharp <[email protected]>

commit ed07453fd356025cc25272629e982f5e4607632c upstream.

When the run bit is set in the xHCI command register, it may take a few microseconds for the host to start running. We cannot ring any doorbells until the host is actually running, so wait until the status register says the host is running.

---
 drivers/usb/host/xhci.c |   39 ++++++++++++++++++++++++++++++++-------
 1 file changed, 32 insertions(+), 7 deletions(-)
drivers/usb/host/xhci.c +32 -7
@@ -105,6 +105,33 @@ int xhci_halt(struct xhci_hcd *xhci)
 }
 
 /*
+ * Set the run bit and wait for the host to be running.
+ */
+int xhci_start(struct xhci_hcd *xhci)
+{
+	u32 temp;
+	int ret;
+
+	temp = xhci_readl(xhci, &xhci->op_regs->command);
+	temp |= (CMD_RUN);
+	xhci_dbg(xhci, "// Turn on HC, cmd = 0x%x.\n",
+			temp);
+	xhci_writel(xhci, temp, &xhci->op_regs->command);
+
+	/*
+	 * Wait for the HCHalted Status bit to be 0 to indicate the host is
+	 * running.
+	 */
+	ret = handshake(xhci, &xhci->op_regs->status,
+			STS_HALT, 0, XHCI_MAX_HALT_USEC);
+	if (ret == -ETIMEDOUT)
+		xhci_err(xhci, "Host took too long to start, "
+				"waited %u microseconds.\n",
+				XHCI_MAX_HALT_USEC);
+	return ret;
+}
+
+/*
  * Reset a halted HC, and set the internal HC state to HC_STATE_HALT.
  *
  * This resets pipelines, timers, counters, state machines, etc.
@@ -452,13 +479,11 @@ int xhci_run(struct usb_hcd *hcd)
 	if (NUM_TEST_NOOPS > 0)
 		doorbell = xhci_setup_one_noop(xhci);
 
-	temp = xhci_readl(xhci, &xhci->op_regs->command);
-	temp |= (CMD_RUN);
-	xhci_dbg(xhci, "// Turn on HC, cmd = 0x%x.\n",
-			temp);
-	xhci_writel(xhci, temp, &xhci->op_regs->command);
-	/* Flush PCI posted writes */
-	temp = xhci_readl(xhci, &xhci->op_regs->command);
+	if (xhci_start(xhci)) {
+		xhci_halt(xhci);
+		return -ENODEV;
+	}
+
 	xhci_dbg(xhci, "// @%p = 0x%x\n", &xhci->op_regs->command, temp);
 	if (doorbell)
 		(*doorbell)(xhci);
#606 lore raw

PATCH 155/200 USB: xhci: Wait for controller to be ready after reset.

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Sarah Sharp <[email protected]>

commit 2d62f3eea98354d61f90d6b115eecf9be5f4bdfe upstream.

After software resets an xHCI host controller, it must wait for the "Controller Not Ready" (CNR) bit in the status register to be cleared. Software is not supposed to ring any doorbells or write to any registers except the status register until this bit is cleared.

---
 drivers/usb/host/xhci.c |   13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)
drivers/usb/host/xhci.c +12 -1
@@ -142,6 +142,7 @@ int xhci_reset(struct xhci_hcd *xhci)
 {
 	u32 command;
 	u32 state;
+	int ret;
 
 	state = xhci_readl(xhci, &xhci->op_regs->status);
 	if ((state & STS_HALT) == 0) {
@@ -156,7 +157,17 @@ int xhci_reset(struct xhci_hcd *xhci)
 	/* XXX: Why does EHCI set this here?  Shouldn't other code do this? */
 	xhci_to_hcd(xhci)->state = HC_STATE_HALT;
 
-	return handshake(xhci, &xhci->op_regs->command, CMD_RESET, 0, 250 * 1000);
+	ret = handshake(xhci, &xhci->op_regs->command,
+			CMD_RESET, 0, 250 * 1000);
+	if (ret)
+		return ret;
+
+	xhci_dbg(xhci, "Wait for controller to be ready for doorbell rings\n");
+	/*
+	 * xHCI cannot write to any doorbells or operational registers other
+	 * than status until the "Controller Not Ready" flag is cleared.
+	 */
+	return handshake(xhci, &xhci->op_regs->status, STS_CNR, 0, 250 * 1000);
 }
 
 
#607 lore raw

PATCH 156/200 USB: ftdi_sio: fix DTR/RTS line modes

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Daniel Mack <[email protected]>

commit 6a1a82df91fa0eb1cc76069a9efe5714d087eccd upstream.

Call set_mctrl() and clear_mctrl() according to the flow control mode selected. This makes serial communication for FT232 connected devices work when CRTSCTS is not set.

This fixes a regression introduced by 4175f3e31 ("tty_port: If we are opened non blocking we still need to raise the carrier"). This patch calls the low-level driver's dtr_rts() function which consequently sets TIOCM_DTR | TIOCM_RTS. A later call to set_termios() without CRTSCTS in cflags, however, does not reset these bits, and so data is not actually sent out on the serial wire.

---
 drivers/usb/serial/ftdi_sio.c |    4 ++++
 1 file changed, 4 insertions(+)
drivers/usb/serial/ftdi_sio.c +4 -0
@@ -2289,6 +2289,8 @@ static void ftdi_set_termios(struct tty_
 				"urb failed to set to rts/cts flow control\n");
 		}
 
+		/* raise DTR/RTS */
+		set_mctrl(port, TIOCM_DTR | TIOCM_RTS);
 	} else {
 		/*
 		 * Xon/Xoff code
@@ -2336,6 +2338,8 @@ static void ftdi_set_termios(struct tty_
 			}
 		}
 
+		/* lower DTR/RTS */
+		clear_mctrl(port, TIOCM_DTR | TIOCM_RTS);
 	}
 	return;
 }
#608 lore raw

PATCH 157/200 USB: cdc-acm: fix resource reclaim in error path of acm_probe

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Axel Lin <[email protected]>

commit c2572b78aa0447244a38e555ebb1b3b48a0088a5 upstream.

This patch fixes resource reclaim in error path of acm_probe:

1. In the case of "out of memory (read urbs usb_alloc_urb)\n")", there is no need to call acm_read_buffers_free(acm) here. Fix it by goto alloc_fail6 instead of alloc_fail7.
2. In the case of "out of memory (write urbs usb_alloc_urb)", usb_alloc_urb may fail in any iteration of the for loop. Current implementation does not properly free allocated snd->urb. Fix it by goto alloc_fail8 instead of alloc_fail7.
3. In the case of device_create_file(&intf->dev,&dev_attr_iCountryCodeRelDate) fail, acm->country_codes is kfreed. As a result, device_remove_file for dev_attr_wCountryCodes will not be executed in acm_disconnect. Fix it by calling device_remove_file for dev_attr_wCountryCodes before goto skip_countries.

---
 drivers/usb/class/cdc-acm.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/usb/class/cdc-acm.c +4 -2
@@ -1201,7 +1201,7 @@ made_compressed_probe:
 		if (rcv->urb == NULL) {
 			dev_dbg(&intf->dev,
 				"out of memory (read urbs usb_alloc_urb)\n");
-			goto alloc_fail7;
+			goto alloc_fail6;
 		}
 
 		rcv->urb->transfer_flags |= URB_NO_TRANSFER_DMA_MAP;
@@ -1225,7 +1225,7 @@ made_compressed_probe:
 		if (snd->urb == NULL) {
 			dev_dbg(&intf->dev,
 				"out of memory (write urbs usb_alloc_urb)");
-			goto alloc_fail7;
+			goto alloc_fail8;
 		}
 
 		if (usb_endpoint_xfer_int(epwrite))
@@ -1264,6 +1264,7 @@ made_compressed_probe:
 		i = device_create_file(&intf->dev,
 						&dev_attr_iCountryCodeRelDate);
 		if (i < 0) {
+			device_remove_file(&intf->dev, &dev_attr_wCountryCodes);
 			kfree(acm->country_codes);
 			goto skip_countries;
 		}
@@ -1300,6 +1301,7 @@ alloc_fail8:
 		usb_free_urb(acm->wb[i].urb);
 alloc_fail7:
 	acm_read_buffers_free(acm);
+alloc_fail6:
 	for (i = 0; i < num_rx_buf; i++)
 		usb_free_urb(acm->ru[i].urb);
 	usb_free_urb(acm->ctrlurb);
#609 lore raw

PATCH 158/200 USB: unbind all interfaces before rebinding them

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Alan Stern <[email protected]>

commit c043f1245654a726925529007210e9f786426448 upstream.

This patch (as1387) fixes a bug introduced during the changeover to the runtime PM framework. When a driver doesn't support resume or reset-resume, and consequently its interfaces need to be unbound and rebound, we have to unbind all the interfaces before trying to rebind any of them. Otherwise the driver's probe method for one interface could try to claim a different interface and fail, because that other interface hasn't been unbound yet.

This fixes Bugzilla #15788. The symptom is that some USB sound cards don't work after hibernation.

---
 drivers/usb/core/driver.c |    2 ++
 1 file changed, 2 insertions(+)
drivers/usb/core/driver.c +2 -0
@@ -1322,6 +1322,7 @@ int usb_resume(struct device *dev, pm_me
 
 	/* For all other calls, take the device back to full power and
 	 * tell the PM core in case it was autosuspended previously.
+	 * Unbind the interfaces that will need rebinding later.
 	 */
 	} else {
 		status = usb_resume_both(udev, msg);
@@ -1330,6 +1331,7 @@ int usb_resume(struct device *dev, pm_me
 			pm_runtime_set_active(dev);
 			pm_runtime_enable(dev);
 			udev->last_busy = jiffies;
+			do_unbind_rebind(udev, DO_REBIND);
 		}
 	}
 
#610 lore raw

PATCH 159/200 p54usb: Add device ID for Dell WLA3310 USB

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jason Dravet <[email protected]>

commit 0f666a08901f8b01f294ca0ad751019375240ae3 upstream.

Add Dell WLA3310 USB wireless card, which has a Z-Com XG-705A chipset, to the USB Ids in p54usb.

---
 drivers/net/wireless/p54/p54usb.c |    1 +
 1 file changed, 1 insertion(+)
drivers/net/wireless/p54/p54usb.c +1 -0
@@ -80,6 +80,7 @@ static struct usb_device_id p54u_table[]
 	{USB_DEVICE(0x1413, 0x5400)},   /* Telsey 802.11g USB2.0 Adapter */
 	{USB_DEVICE(0x1435, 0x0427)},	/* Inventel UR054G */
 	{USB_DEVICE(0x2001, 0x3704)},	/* DLink DWL-G122 rev A2 */
+	{USB_DEVICE(0x413c, 0x5513)},	/* Dell WLA3310 USB Wireless Adapter */
 	{USB_DEVICE(0x413c, 0x8102)},	/* Spinnaker DUT */
 	{USB_DEVICE(0x413c, 0x8104)},	/* Cohiba Proto board */
 	{}
#611 lore raw

PATCH 160/200 wrong type for magic argument in simple_fill_super()

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Roberto Sassu <[email protected]>

commit 7d683a09990ff095a91b6e724ecee0ff8733274a upstream.

It's used to superblock ->s_magic, which is unsigned long.

---
 fs/libfs.c         |    3 ++-
 include/linux/fs.h |    2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)
fs/libfs.c +2 -1
@@ -418,7 +418,8 @@ int simple_write_end(struct file *file,
  * unique inode values later for this filesystem, then you must take care
  * to pass it an appropriate max_reserved value to avoid collisions.
  */
-int simple_fill_super(struct super_block *s, int magic, struct tree_descr *files)
+int simple_fill_super(struct super_block *s, unsigned long magic,
+		      struct tree_descr *files)
 {
 	struct inode *inode;
 	struct dentry *root;
include/linux/fs.h +1 -1
@@ -2356,7 +2356,7 @@ extern const struct file_operations simp
 extern const struct inode_operations simple_dir_inode_operations;
 struct tree_descr { char *name; const struct file_operations *ops; int mode; };
 struct dentry *d_alloc_name(struct dentry *, const char *);
-extern int simple_fill_super(struct super_block *, int, struct tree_descr *);
+extern int simple_fill_super(struct super_block *, unsigned long, struct tree_descr *);
 extern int simple_pin_fs(struct file_system_type *, struct vfsmount **mount, int *count);
 extern void simple_release_fs(struct vfsmount **mount, int *count);
 
#612 lore raw

PATCH 161/200 cfq-iosched: fix an oops caused by slab leak

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Shaohua Li <[email protected]>

commit d02a2c077fb81f3224c770be62a318165b23b486 upstream.

I got below oops when unloading cfq-iosched. Considering scenario:
queue A merge to B, C merge to D and B will be merged to D. Before B is merged to D, we do split B. We should put B's reference for D.

[  807.768536] =============================================================================
[  807.768539] BUG cfq_queue: Objects remaining on kmem_cache_close()
[  807.768541] -----------------------------------------------------------------------------
[  807.768543]
[  807.768546] INFO: Slab 0xffffea0003e6b4e0 objects=26 used=1 fp=0xffff88011d584fd8 flags=0x200000000004082
[  807.768550] Pid: 5946, comm: rmmod Tainted: G        W   2.6.34-07097-gf4b87de-dirty #724
[  807.768552] Call Trace:
[  807.768560]  [<ffffffff81104e8d>] slab_err+0x8f/0x9d
[  807.768564]  [<ffffffff811059e1>] ? flush_cpu_slab+0x0/0x93
[  807.768569]  [<ffffffff8164be52>] ? add_preempt_count+0xe/0xca
[  807.768572]  [<ffffffff8164bd9c>] ? sub_preempt_count+0xe/0xb6
[  807.768577]  [<ffffffff81648871>] ? _raw_spin_unlock+0x15/0x30
[  807.768580]  [<ffffffff8164bd9c>] ? sub_preempt_count+0xe/0xb6
[  807.768584]  [<ffffffff811061bc>] list_slab_objects+0x9b/0x19f
[  807.768588]  [<ffffffff8164bf0a>] ? add_preempt_count+0xc6/0xca
[  807.768591]  [<ffffffff81109e27>] kmem_cache_destroy+0x13f/0x21d
[  807.768597]  [<ffffffffa000ff13>] cfq_slab_kill+0x1a/0x43 [cfq_iosched]
[  807.768601]  [<ffffffffa000ffcf>] cfq_exit+0x93/0x9e [cfq_iosched]
[  807.768606]  [<ffffffff810973a2>] sys_delete_module+0x1b1/0x219
[  807.768612]  [<ffffffff8102fb5b>] system_call_fastpath+0x16/0x1b
[  807.768618] INFO: Object 0xffff88011d584618 @offset=1560
[  807.768622] INFO: Allocated in cfq_get_queue+0x11e/0x274 [cfq_iosched] age=7173 cpu=1 pid=5496
[  807.768626] =============================================================================
---
 block/cfq-iosched.c |   20 ++++++++++++++------
 1 file changed, 14 insertions(+), 6 deletions(-)
block/cfq-iosched.c +14 -6
@@ -2503,15 +2503,10 @@ static void cfq_free_io_context(struct i
 	__call_for_each_cic(ioc, cic_free_func);
 }
 
-static void cfq_exit_cfqq(struct cfq_data *cfqd, struct cfq_queue *cfqq)
+static void cfq_put_cooperator(struct cfq_queue *cfqq)
 {
 	struct cfq_queue *__cfqq, *next;
 
-	if (unlikely(cfqq == cfqd->active_queue)) {
-		__cfq_slice_expired(cfqd, cfqq, 0);
-		cfq_schedule_dispatch(cfqd);
-	}
-
 	/*
 	 * If this queue was scheduled to merge with another queue, be
 	 * sure to drop the reference taken on that queue (and others in
@@ -2527,6 +2522,16 @@ static void cfq_exit_cfqq(struct cfq_dat
 		cfq_put_queue(__cfqq);
 		__cfqq = next;
 	}
+}
+
+static void cfq_exit_cfqq(struct cfq_data *cfqd, struct cfq_queue *cfqq)
+{
+	if (unlikely(cfqq == cfqd->active_queue)) {
+		__cfq_slice_expired(cfqd, cfqq, 0);
+		cfq_schedule_dispatch(cfqd);
+	}
+
+	cfq_put_cooperator(cfqq);
 
 	cfq_put_queue(cfqq);
 }
@@ -3470,6 +3475,9 @@ split_cfqq(struct cfq_io_context *cic, s
 	}
 
 	cic_set_cfqq(cic, NULL, 1);
+
+	cfq_put_cooperator(cfqq);
+
 	cfq_put_queue(cfqq);
 	return NULL;
 }
#613 lore raw

PATCH 162/200 iwlwifi: fix internal scan race

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Reinette Chatre <[email protected]>

commit 073d5eab6fc85b6c278d507a5633b759a85dc878 upstream.

It is possible for internal scan to race against itself if the device is not returning the scan results from first requests. What happens in this case is the cleanup done during the abort of the first internal scan also cleans up part of the new scan, causing it to access memory it shouldn't.

Here are details:
* First internal scan is triggered and scan command sent to device.
* After seven seconds there is no scan results so the watchdog timer triggers a scan abort.
* The scan abort succeeds and a SCAN_COMPLETE_NOTIFICATION is received for failed scan.
* During processing of SCAN_COMPLETE_NOTIFICATION we clear STATUS_SCANNING and queue the "scan_completed" work.
** At this time, since the problem that caused the internal scan in first
place is still present, a new internal scan is triggered.
The behavior at this point is a bit different between 2.6.34 and 2.6.35 since 2.6.35 has a lot of this synchronized. The rest of the race description will thus be generalized.
** As part of preparing for the scan "is_internal_short_scan" is set to true.
* At this point the completion work for fist scan is run. As part of this there is some locking missing around the "is_internal_short_scan" variable and it is set to "false".
** Now the second scan runs and it considers itself a real (not internal0
scan and thus causes problems with wrong memory being accessed.

The fix is twofold.
* Since "is_internal_short_scan" should be protected by mutex, fix this in scan completion work so that changes to it can be serialized.
* Do not queue a new internal scan if one is in progress.

This fixes https://bugzilla.kernel.org/show_bug.cgi?id=15824

---
 drivers/net/wireless/iwlwifi/iwl-scan.c |   21 ++++++++++++++++++---
 1 file changed, 18 insertions(+), 3 deletions(-)
drivers/net/wireless/iwlwifi/iwl-scan.c +18 -3
@@ -561,6 +561,11 @@ static void iwl_bg_start_internal_scan(s
 
 	mutex_lock(&priv->mutex);
 
+	if (priv->is_internal_short_scan == true) {
+		IWL_DEBUG_SCAN(priv, "Internal scan already in progress\n");
+		goto unlock;
+	}
+
 	if (!iwl_is_ready_rf(priv)) {
 		IWL_DEBUG_SCAN(priv, "not ready or exit pending\n");
 		goto unlock;
@@ -958,17 +963,27 @@ void iwl_bg_scan_completed(struct work_s
 {
 	struct iwl_priv *priv =
 	    container_of(work, struct iwl_priv, scan_completed);
+	bool internal = false;
 
 	IWL_DEBUG_SCAN(priv, "SCAN complete scan\n");
 
 	cancel_delayed_work(&priv->scan_check);
 
-	if (!priv->is_internal_short_scan)
-		ieee80211_scan_completed(priv->hw, false);
-	else {
+	mutex_lock(&priv->mutex);
+	if (priv->is_internal_short_scan) {
 		priv->is_internal_short_scan = false;
 		IWL_DEBUG_SCAN(priv, "internal short scan completed\n");
+		internal = true;
 	}
+	mutex_unlock(&priv->mutex);
+
+	/*
+	 * Do not hold mutex here since this will cause mac80211 to call
+	 * into driver again into functions that will attempt to take
+	 * mutex.
+	 */
+	if (!internal)
+		ieee80211_scan_completed(priv->hw, false);
 
 	if (test_bit(STATUS_EXIT_PENDING, &priv->status))
 		return;
#614 lore raw

PATCH 163/200 iwlwifi: recalculate average tpt if not current

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Reinette Chatre <[email protected]>

commit 3d79b2a9eeaa066b35c49fbb17e3156a3c482c3e upstream.

We currently have this check as a BUG_ON, which is being hit by people. Previously it was an error with a recalculation if not current, return that code.

The BUG_ON was introduced by:
commit 3110bef78cb4282c58245bc8fd6d95d9ccb19749

Author: Guy Cohen <[email protected]>
Date:   Tue Sep 9 10:54:54 2008 +0800

iwlwifi: Added support for 3 antennas

... the portion adding the BUG_ON is reverted since we are encountering the error and BUG_ON was created with assumption that error is not encountered.

---
 drivers/net/wireless/iwlwifi/iwl-agn-rs.c |   10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)
drivers/net/wireless/iwlwifi/iwl-agn-rs.c +6 -4
@@ -2077,10 +2077,12 @@ static void rs_rate_scale_perform(struct
 	}
 	/* Else we have enough samples; calculate estimate of
 	 * actual average throughput */
-
-	/* Sanity-check TPT calculations */
-	BUG_ON(window->average_tpt != ((window->success_ratio *
-			tbl->expected_tpt[index] + 64) / 128));
+	if (window->average_tpt != ((window->success_ratio *
+			tbl->expected_tpt[index] + 64) / 128)) {
+		IWL_ERR(priv, "expected_tpt should have been calculated by now\n");
+		window->average_tpt = ((window->success_ratio *
+					tbl->expected_tpt[index] + 64) / 128);
+	}
 
 	/* If we are searching for better modulation mode, check success. */
 	if (lq_sta->search_better_tbl &&
#615 lore raw

PATCH 164/200 perf: Fix signed comparison in perf_adjust_period()

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Peter Zijlstra <[email protected]>

commit f6ab91add6355e231e1c47897027b2a6ee4fa268 upstream.

Frederic reported that frequency driven swevents didn't work properly and even caused a division-by-zero error.

It turns out there are two bugs, the division-by-zero comes from a failure to deal with that in perf_calculate_period().

The other was more interesting and turned out to be a wrong comparison in perf_adjust_period(). The comparison was between an s64 and u64 and got implicitly converted to an unsigned comparison. The problem is that period_left is typically < 0, so it ended up being always true.

Cure this by making the local period variables s64.

LKML-Reference: <new-submission>

---
 kernel/perf_event.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)
kernel/perf_event.c +4 -1
@@ -1456,6 +1456,9 @@ do {					\
 		divisor = nsec * frequency;
 	}
 
+	if (!divisor)
+		return dividend;
+
 	return div64_u64(dividend, divisor);
 }
 
@@ -1478,7 +1481,7 @@ static int perf_event_start(struct perf_
 static void perf_adjust_period(struct perf_event *event, u64 nsec, u64 count)
 {
 	struct hw_perf_event *hwc = &event->hw;
-	u64 period, sample_period;
+	s64 period, sample_period;
 	s64 delta;
 
 	period = perf_calculate_period(event, nsec, count);
#616 lore raw

PATCH 165/200 tracing: Fix null pointer deref with SEND_SIG_FORCED

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Oleg Nesterov <[email protected]>

commit b9b76dfaac6fa2c289ee8a005be637afd2da7e2f upstream.

BUG: unable to handle kernel NULL pointer dereference at
	0000000000000006
IP: [<ffffffff8107bd37>] ftrace_raw_event_signal_generate+0x87/0x140

TP_STORE_SIGINFO() forgets about SEND_SIG_FORCED, fix.

We should probably export is_si_special() and change TP_STORE_SIGINFO() to use it in the longer term.

Cc Steven Rostedt <[email protected]>
Cc Andrew Morton <[email protected]>
Cc Jason Baron <[email protected]>
Cc Masami Hiramatsu <[email protected]>

LKML-Reference: <[email protected]>

---
 include/trace/events/signal.h |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
include/trace/events/signal.h +2 -1
@@ -10,7 +10,8 @@
 
 #define TP_STORE_SIGINFO(__entry, info)				\
 	do {							\
-		if (info == SEND_SIG_NOINFO) {			\
+		if (info == SEND_SIG_NOINFO ||			\
+		    info == SEND_SIG_FORCED) {			\
 			__entry->errno	= 0;			\
 			__entry->code	= SI_USER;		\
 		} else if (info == SEND_SIG_PRIV) {		\
#617 lore raw

PATCH 166/200 nfsd: nfsd_setattr needs to call commit_metadata

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Christoph Hellwig <[email protected]>

commit b160fdabe93a8a53094f90f02bf4dcb500782aab upstream.

The conversion of write_inode_now calls to commit_metadata in commit f501912a35c02eadc55ca9396ece55fe36f785d0 missed out the call in nfsd_setattr.

But without this conversion we can't guarantee that a SETATTR request has actually been commited to disk with XFS, which causes a regression from 2.6.32 (only for NFSv2, but anyway).

---
 fs/nfsd/vfs.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
fs/nfsd/vfs.c +1 -2
@@ -443,8 +443,7 @@ nfsd_setattr(struct svc_rqst *rqstp, str
 	if (size_change)
 		put_write_access(inode);
 	if (!err)
-		if (EX_ISSYNC(fhp->fh_export))
-			write_inode_now(inode, 1);
+		commit_metadata(fhp);
 out:
 	return err;
 
#618 lore raw

PATCH 167/200 wl1251: fix a memory leak in probe

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Grazvydas Ignotas <[email protected]>

commit aa679c36756003f1fabdb9fc6f00eb159559f7c3 upstream.

wl1251_sdio_probe() error path is missing wl1251_free_hw, add it.

---
 drivers/net/wireless/wl12xx/wl1251_sdio.c |    1 +
 1 file changed, 1 insertion(+)
drivers/net/wireless/wl12xx/wl1251_sdio.c +1 -0
@@ -160,6 +160,7 @@ disable:
 	sdio_disable_func(func);
 release:
 	sdio_release_host(func);
+	wl1251_free_hw(wl);
 	return ret;
 }
 
#619 lore raw

PATCH 168/200 iwlwifi: add missing rcu_read_lock

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Johannes Berg <[email protected]>

commit 6db6340c42d027b6364d49fa99d69019aca24de4 upstream.

Using ieee80211_find_sta() needs to be under RCU read lock, which iwlwifi currently misses, so fix it.

---
 drivers/net/wireless/iwlwifi/iwl-tx.c |    2 ++
 1 file changed, 2 insertions(+)
drivers/net/wireless/iwlwifi/iwl-tx.c +2 -0
@@ -1198,6 +1198,7 @@ static void iwl_tx_status(struct iwl_pri
 	struct ieee80211_sta *sta;
 	struct iwl_station_priv *sta_priv;
 
+	rcu_read_lock();
 	sta = ieee80211_find_sta(priv->vif, hdr->addr1);
 	if (sta) {
 		sta_priv = (void *)sta->drv_priv;
@@ -1206,6 +1207,7 @@ static void iwl_tx_status(struct iwl_pri
 		    atomic_dec_return(&sta_priv->pending_frames) == 0)
 			ieee80211_sta_block_awake(priv->hw, sta, false);
 	}
+	rcu_read_unlock();
 
 	ieee80211_tx_status_irqsafe(priv->hw, skb);
 }
#620 lore raw

PATCH 169/200 perf_events: Fix races and clean up perf_event and perf_mmap_data interaction

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Peter Zijlstra <[email protected]>

commit ac9721f3f54b27a16c7e1afb2481e7ee95a70318 upstream.

In order to move toward separate buffer objects, rework the whole perf_mmap_data construct to be a more self-sufficient entity, one with its own lifetime rules.

This greatly sanitizes the whole output redirection code, which was riddled with bugs and races.

LKML-Reference: <new-submission>

---
 include/linux/perf_event.h |    5 -
 kernel/perf_event.c        |  217 ++++++++++++++++++++++++++-------------------
 2 files changed, 129 insertions(+), 93 deletions(-)
include/linux/perf_event.h +3 -2
@@ -531,6 +531,7 @@ enum perf_event_active_state {
 struct file;
 
 struct perf_mmap_data {
+	atomic_t			refcount;
 	struct rcu_head			rcu_head;
 #ifdef CONFIG_PERF_USE_VMALLOC
 	struct work_struct		work;
@@ -538,7 +539,6 @@ struct perf_mmap_data {
 	int				data_order;
 	int				nr_pages;	/* nr of data pages  */
 	int				writable;	/* are we writable   */
-	int				nr_locked;	/* nr pages mlocked  */
 
 	atomic_t			poll;		/* POLL_ for wakeups */
 	atomic_t			events;		/* event_id limit       */
@@ -582,7 +582,6 @@ struct perf_event {
 	int				nr_siblings;
 	int				group_flags;
 	struct perf_event		*group_leader;
-	struct perf_event		*output;
 	const struct pmu		*pmu;
 
 	enum perf_event_active_state	state;
@@ -643,6 +642,8 @@ struct perf_event {
 	/* mmap bits */
 	struct mutex			mmap_mutex;
 	atomic_t			mmap_count;
+	int				mmap_locked;
+	struct user_struct		*mmap_user;
 	struct perf_mmap_data		*data;
 
 	/* poll related */
kernel/perf_event.c +126 -91

369 lines not on this page · raw message

#621 lore raw

PATCH 170/200 ext4: check s_log_groups_per_flex in online resize code

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Eric Sandeen <[email protected]>

commit 42007efd569f1cf3bfb9a61da60ef6c2179508ca upstream.

If groups_per_flex < 2, sbi->s_flex_groups[] doesn't get filled out, and every other access to this first tests s_log_groups_per_flex; same thing needs to happen in resize or we'll wander off into a null pointer when doing an online resize of the file system.

Thanks to Christoph Biedl, who came up with the trivial testcase:

# truncate --size 128M fsfile
# mkfs.ext3 -F fsfile
# tune2fs -O extents,uninit_bg,dir_index,flex_bg,huge_file,dir_nlink,extra_isize fsfile
# e2fsck -yDf -C0 fsfile
# truncate --size 132M fsfile
# losetup /dev/loop0 fsfile
# mount /dev/loop0 mnt
# resize2fs -p /dev/loop0
	https://bugzilla.kernel.org/show_bug.cgi?id=13549
---
 fs/ext4/resize.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
fs/ext4/resize.c +2 -1
@@ -911,7 +911,8 @@ int ext4_group_add(struct super_block *s
 	percpu_counter_add(&sbi->s_freeinodes_counter,
 			   EXT4_INODES_PER_GROUP(sb));
 
-	if (EXT4_HAS_INCOMPAT_FEATURE(sb, EXT4_FEATURE_INCOMPAT_FLEX_BG)) {
+	if (EXT4_HAS_INCOMPAT_FEATURE(sb, EXT4_FEATURE_INCOMPAT_FLEX_BG) &&
+	    sbi->s_log_groups_per_flex) {
 		ext4_group_t flex_group;
 		flex_group = ext4_flex_group(sbi, input->group);
 		atomic_add(input->free_blocks_count,
#622 lore raw

PATCH 171/200 ext4: Make sure the MOVE_EXT ioctl cant overwrite append-only files

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Theodore Ts'o <[email protected]>

commit 1f5a81e41f8b1a782c68d3843e9ec1bfaadf7d72 upstream.

Dan Roseberg has reported a problem with the MOVE_EXT ioctl. If the donor file is an append-only file, we should not allow the operation to proceed, lest we end up overwriting the contents of an append-only file.

---
 fs/ext4/move_extent.c |    3 +++
 1 file changed, 3 insertions(+)
fs/ext4/move_extent.c +3 -0
@@ -959,6 +959,9 @@ mext_check_arguments(struct inode *orig_
 		return -EINVAL;
 	}
 
+	if (IS_IMMUTABLE(donor_inode) || IS_APPEND(donor_inode))
+		return -EPERM;
+
 	/* Ext4 move extent does not support swapfile */
 	if (IS_SWAPFILE(orig_inode) || IS_SWAPFILE(donor_inode)) {
 		ext4_debug("ext4 move extent: The argument files should "
#623 lore raw

PATCH 172/200 GFS2: Fix permissions checking for setflags ioctl()

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Steven Whitehouse <[email protected]>

commit 7df0e0397b9a18358573274db9fdab991941062f upstream.

We should be checking for the ownership of the file for which flags are being set, rather than just for write access.

---
 fs/gfs2/file.c |    7 +++++++
 1 file changed, 7 insertions(+)
fs/gfs2/file.c +7 -0
@@ -218,6 +218,11 @@ static int do_gfs2_set_flags(struct file
 	if (error)
 		goto out_drop_write;
 
+	error = -EACCES;
+	if (!is_owner_or_cap(inode))
+		goto out;
+
+	error = 0;
 	flags = ip->i_diskflags;
 	new_flags = (flags & ~mask) | (reqflags & mask);
 	if ((new_flags ^ flags) == 0)
@@ -275,8 +280,10 @@ static int gfs2_set_flags(struct file *f
 {
 	struct inode *inode = filp->f_path.dentry->d_inode;
 	u32 fsflags, gfsflags;
+
 	if (get_user(fsflags, ptr))
 		return -EFAULT;
+
 	gfsflags = fsflags_cvt(fsflags_to_gfs2, fsflags);
 	if (!S_ISDIR(inode->i_mode)) {
 		if (gfsflags & GFS2_DIF_INHERIT_JDATA)
#624 lore raw

PATCH 173/200 CIFS: Allow null nd (as nfs server uses) on create

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Steve French <[email protected]>

commit fa588e0c57048b3d4bfcd772d80dc0615f83fd35 upstream.

While creating a file on a server which supports unix extensions such as Samba, if a file is being created which does not supply nameidata (i.e. nd is null), cifs client can oops when calling cifs_posix_open.

---
 fs/cifs/cifsproto.h |    6 ++++--
 fs/cifs/dir.c       |   20 ++++++++++++--------
 fs/cifs/file.c      |   11 +++++++----
 3 files changed, 23 insertions(+), 14 deletions(-)
fs/cifs/cifsproto.h +4 -2
@@ -95,8 +95,10 @@ extern struct cifsFileInfo *cifs_new_fil
 				__u16 fileHandle, struct file *file,
 				struct vfsmount *mnt, unsigned int oflags);
 extern int cifs_posix_open(char *full_path, struct inode **pinode,
-			   struct vfsmount *mnt, int mode, int oflags,
-			   __u32 *poplock, __u16 *pnetfid, int xid);
+				struct vfsmount *mnt,
+				struct super_block *sb,
+				int mode, int oflags,
+				__u32 *poplock, __u16 *pnetfid, int xid);
 extern void cifs_unix_basic_to_fattr(struct cifs_fattr *fattr,
 				     FILE_UNIX_BASIC_INFO *info,
 				     struct cifs_sb_info *cifs_sb);
fs/cifs/dir.c +12 -8
@@ -183,13 +183,14 @@ cifs_new_fileinfo(struct inode *newinode
 }
 
 int cifs_posix_open(char *full_path, struct inode **pinode,
-		    struct vfsmount *mnt, int mode, int oflags,
-		    __u32 *poplock, __u16 *pnetfid, int xid)
+			struct vfsmount *mnt, struct super_block *sb,
+			int mode, int oflags,
+			__u32 *poplock, __u16 *pnetfid, int xid)
 {
 	int rc;
 	FILE_UNIX_BASIC_INFO *presp_data;
 	__u32 posix_flags = 0;
-	struct cifs_sb_info *cifs_sb = CIFS_SB(mnt->mnt_sb);
+	struct cifs_sb_info *cifs_sb = CIFS_SB(sb);
 	struct cifs_fattr fattr;
 
 	cFYI(1, ("posix open %s", full_path));
@@ -242,7 +243,7 @@ int cifs_posix_open(char *full_path, str
 
 	/* get new inode and set it up */
 	if (*pinode == NULL) {
-		*pinode = cifs_iget(mnt->mnt_sb, &fattr);
+		*pinode = cifs_iget(sb, &fattr);
 		if (!*pinode) {
 			rc = -ENOMEM;
 			goto posix_open_ret;
@@ -251,7 +252,8 @@ int cifs_posix_open(char *full_path, str
 		cifs_fattr_to_inode(*pinode, &fattr);
 	}
 
-	cifs_new_fileinfo(*pinode, *pnetfid, NULL, mnt, oflags);
+	if (mnt)
+		cifs_new_fileinfo(*pinode, *pnetfid, NULL, mnt, oflags);
 
 posix_open_ret:
 	kfree(presp_data);
@@ -315,13 +317,14 @@ cifs_create(struct inode *inode, struct
 	if (nd && (nd->flags & LOOKUP_OPEN))
 		oflags = nd->intent.open.flags;
 	else
-		oflags = FMODE_READ;
+		oflags = FMODE_READ | SMB_O_CREAT;
 
 	if (tcon->unix_ext && (tcon->ses->capabilities & CAP_UNIX) &&
 	    (CIFS_UNIX_POSIX_PATH_OPS_CAP &
 			le64_to_cpu(tcon->fsUnixInfo.Capability))) {
-		rc = cifs_posix_open(full_path, &newinode, nd->path.mnt,
-				     mode, oflags, &oplock, &fileHandle, xid);
+		rc = cifs_posix_open(full_path, &newinode,
+			nd ? nd->path.mnt : NULL,
+			inode->i_sb, mode, oflags, &oplock, &fileHandle, xid);
 		/* EIO could indicate that (posix open) operation is not
 		   supported, despite what server claimed in capability
 		   negotation.  EREMOTE indicates DFS junction, which is not
@@ -678,6 +681,7 @@ cifs_lookup(struct inode *parent_dir_ino
 		     (nd->flags & LOOKUP_OPEN) && !pTcon->broken_posix_open &&
 		     (nd->intent.open.flags & O_CREAT)) {
 			rc = cifs_posix_open(full_path, &newInode, nd->path.mnt,
+					parent_dir_inode->i_sb,
 					nd->intent.open.create_mode,
 					nd->intent.open.flags, &oplock,
 					&fileHandle, xid);
fs/cifs/file.c +7 -4
@@ -298,10 +298,12 @@ int cifs_open(struct inode *inode, struc
 	    (CIFS_UNIX_POSIX_PATH_OPS_CAP &
 			le64_to_cpu(tcon->fsUnixInfo.Capability))) {
 		int oflags = (int) cifs_posix_convert_flags(file->f_flags);
+		oflags |= SMB_O_CREAT;
 		/* can not refresh inode info since size could be stale */
 		rc = cifs_posix_open(full_path, &inode, file->f_path.mnt,
-				     cifs_sb->mnt_file_mode /* ignored */,
-				     oflags, &oplock, &netfid, xid);
+				inode->i_sb,
+				cifs_sb->mnt_file_mode /* ignored */,
+				oflags, &oplock, &netfid, xid);
 		if (rc == 0) {
 			cFYI(1, ("posix open succeeded"));
 			/* no need for special case handling of setting mode
@@ -513,8 +515,9 @@ reopen_error_exit:
 		int oflags = (int) cifs_posix_convert_flags(file->f_flags);
 		/* can not refresh inode info since size could be stale */
 		rc = cifs_posix_open(full_path, NULL, file->f_path.mnt,
-				     cifs_sb->mnt_file_mode /* ignored */,
-				     oflags, &oplock, &netfid, xid);
+				inode->i_sb,
+				cifs_sb->mnt_file_mode /* ignored */,
+				oflags, &oplock, &netfid, xid);
 		if (rc == 0) {
 			cFYI(1, ("posix reopen succeeded"));
 			goto reopen_success;
#625 lore raw

PATCH 174/200 Btrfs: should add a permission check for setfacl

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Shi Weihua <[email protected]>

commit 2f26afba46f0ebf155cf9be746496a0304a5b7cf upstream.

On btrfs, do the following
------------------

# su user1
# cd btrfs-part/
# touch aaa
# getfacl aaa
  # file: aaa
  # owner: user1
  # group: user1
  user::rw-
  group::rw-
  other::r--
# su user2
# cd btrfs-part/
# setfacl -m u::rwx aaa
# getfacl aaa
  # file: aaa
  # owner: user1
  # group: user1
  user::rwx           <- successed to setfacl
  group::rw-
  other::r--
------------------
but we should prohibit it that user2 changing user1's acl.
In fact, on ext3 and other fs, a message occurs:
  setfacl: aaa: Operation not permitted

This patch fixed it.

---
 fs/btrfs/acl.c |    3 +++
 1 file changed, 3 insertions(+)
fs/btrfs/acl.c +3 -0
@@ -160,6 +160,9 @@ static int btrfs_xattr_acl_set(struct de
 	int ret;
 	struct posix_acl *acl = NULL;
 
+	if (!is_owner_or_cap(dentry->d_inode))
+		return -EPERM;
+
 	if (value) {
 		acl = posix_acl_from_xattr(value, size);
 		if (acl == NULL) {
#626 lore raw

PATCH 175/200 NFS: Ensure that we mark the inode as dirty if we exit early from commit

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Trond Myklebust <[email protected]>

commit c5efa5fc91f1f6d1d47e65f39e7ec6d1157c777d upstream.

If we exit from nfs_commit_inode() without ensuring that the COMMIT rpc call has been completed, we must re-mark the inode as dirty. Otherwise, future calls to sync_inode() with the WB_SYNC_ALL flag set will fail to ensure that the data is on the disk.

---
 fs/nfs/write.c |   13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)
fs/nfs/write.c +11 -2
@@ -1386,7 +1386,7 @@ static int nfs_commit_inode(struct inode
 	int res = 0;
 
 	if (!nfs_commit_set_lock(NFS_I(inode), may_wait))
-		goto out;
+		goto out_mark_dirty;
 	spin_lock(&inode->i_lock);
 	res = nfs_scan_commit(inode, &head, 0, 0);
 	spin_unlock(&inode->i_lock);
@@ -1398,9 +1398,18 @@ static int nfs_commit_inode(struct inode
 			wait_on_bit(&NFS_I(inode)->flags, NFS_INO_COMMIT,
 					nfs_wait_bit_killable,
 					TASK_KILLABLE);
+		else
+			goto out_mark_dirty;
 	} else
 		nfs_commit_clear_lock(NFS_I(inode));
-out:
+	return res;
+	/* Note: If we exit without ensuring that the commit is complete,
+	 * we must mark the inode as dirty. Otherwise, future calls to
+	 * sync_inode() with the WB_SYNC_ALL flag set will fail to ensure
+	 * that the data is on the disk.
+	 */
+out_mark_dirty:
+	__mark_inode_dirty(inode, I_DIRTY_DATASYNC);
 	return res;
 }
 
#627 lore raw

PATCH 176/200 NFS: Fix another nfs_wb_page() deadlock

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Trond Myklebust <[email protected]>

commit 0522f6adedd2736cbca3c0e16ca51df668993eee upstream.

J.R. Okajima reports that the call to sync_inode() in nfs_wb_page() can deadlock with other writeback flush calls. It boils down to the fact that we cannot ever call writeback_single_inode() while holding a page lock (even if we do set nr_to_write to zero) since another process may already be waiting in the call to do_writepages(), and so will deny us the I_SYNC lock.

---
 fs/nfs/write.c |    7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)
fs/nfs/write.c +5 -2
@@ -1518,14 +1518,17 @@ int nfs_wb_page(struct inode *inode, str
 	};
 	int ret;
 
-	while(PagePrivate(page)) {
+	for (;;) {
 		wait_on_page_writeback(page);
 		if (clear_page_dirty_for_io(page)) {
 			ret = nfs_writepage_locked(page, &wbc);
 			if (ret < 0)
 				goto out_error;
+			continue;
 		}
-		ret = sync_inode(inode, &wbc);
+		if (!PagePrivate(page))
+			break;
+		ret = nfs_commit_inode(inode, FLUSH_SYNC);
 		if (ret < 0)
 			goto out_error;
 	}
#628 lore raw

PATCH 177/200 V4L/DVB: uvcvideo: Prevent division by 0 when control step value is 0

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Laurent Pinchart <[email protected]>

commit cf7a50eeb6f462a0b7d1619fcb27a727a2981769 upstream.

The control step values reported by the device are used as a divisor unchecked, which can result in a division by zero.

Check the step value and make it 1 when null.

---
 drivers/media/video/uvc/uvc_ctrl.c |    2 ++
 1 file changed, 2 insertions(+)
drivers/media/video/uvc/uvc_ctrl.c +2 -0
@@ -1047,6 +1047,8 @@ int uvc_ctrl_set(struct uvc_video_chain
 				   uvc_ctrl_data(ctrl, UVC_CTRL_DATA_MAX));
 		step = mapping->get(mapping, UVC_GET_RES,
 				    uvc_ctrl_data(ctrl, UVC_CTRL_DATA_RES));
+		if (step == 0)
+			step = 1;
 
 		xctrl->value = min + (xctrl->value - min + step/2) / step * step;
 		xctrl->value = clamp(xctrl->value, min, max);
#629 lore raw

PATCH 178/200 KVM: SVM: Dont use kmap_atomic in nested_svm_map

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Joerg Roedel <[email protected]>

Use of kmap_atomic disables preemption but if we run in shadow-shadow mode the vmrun emulation executes kvm_set_cr3 which might sleep or fault. So use kmap instead for nested_svm_map.

(Cherry-picked from commit 7597f129d8b6799da7a264e6d6f7401668d3a36d)

---
 arch/x86/kvm/svm.c |   47 ++++++++++++++++++++++++-----------------------
 1 file changed, 24 insertions(+), 23 deletions(-)
arch/x86/kvm/svm.c +24 -23
@@ -1423,7 +1423,7 @@ static inline int nested_svm_intr(struct
 	return 0;
 }
 
-static void *nested_svm_map(struct vcpu_svm *svm, u64 gpa, enum km_type idx)
+static void *nested_svm_map(struct vcpu_svm *svm, u64 gpa, struct page **_page)
 {
 	struct page *page;
 
@@ -1431,7 +1431,9 @@ static void *nested_svm_map(struct vcpu_
 	if (is_error_page(page))
 		goto error;
 
-	return kmap_atomic(page, idx);
+	*_page = page;
+
+	return kmap(page);
 
 error:
 	kvm_release_page_clean(page);
@@ -1440,16 +1442,9 @@ error:
 	return NULL;
 }
 
-static void nested_svm_unmap(void *addr, enum km_type idx)
+static void nested_svm_unmap(struct page *page)
 {
-	struct page *page;
-
-	if (!addr)
-		return;
-
-	page = kmap_atomic_to_page(addr);
-
-	kunmap_atomic(addr, idx);
+	kunmap(page);
 	kvm_release_page_dirty(page);
 }
 
@@ -1457,6 +1452,7 @@ static bool nested_svm_exit_handled_msr(
 {
 	u32 param = svm->vmcb->control.exit_info_1 & 1;
 	u32 msr = svm->vcpu.arch.regs[VCPU_REGS_RCX];
+	struct page *page;
 	bool ret = false;
 	u32 t0, t1;
 	u8 *msrpm;
@@ -1464,7 +1460,7 @@ static bool nested_svm_exit_handled_msr(
 	if (!(svm->nested.intercept & (1ULL << INTERCEPT_MSR_PROT)))
 		return false;
 
-	msrpm = nested_svm_map(svm, svm->nested.vmcb_msrpm, KM_USER0);
+	msrpm = nested_svm_map(svm, svm->nested.vmcb_msrpm, &page);
 
 	if (!msrpm)
 		goto out;
@@ -1492,7 +1488,7 @@ static bool nested_svm_exit_handled_msr(
 	ret = msrpm[t1] & ((1 << param) << t0);
 
 out:
-	nested_svm_unmap(msrpm, KM_USER0);
+	nested_svm_unmap(page);
 
 	return ret;
 }
@@ -1615,6 +1611,7 @@ static int nested_svm_vmexit(struct vcpu
 	struct vmcb *nested_vmcb;
 	struct vmcb *hsave = svm->nested.hsave;
 	struct vmcb *vmcb = svm->vmcb;
+	struct page *page;
 
 	trace_kvm_nested_vmexit_inject(vmcb->control.exit_code,
 				       vmcb->control.exit_info_1,
@@ -1622,7 +1619,7 @@ static int nested_svm_vmexit(struct vcpu
 				       vmcb->control.exit_int_info,
 				       vmcb->control.exit_int_info_err);
 
-	nested_vmcb = nested_svm_map(svm, svm->nested.vmcb, KM_USER0);
+	nested_vmcb = nested_svm_map(svm, svm->nested.vmcb, &page);
 	if (!nested_vmcb)
 		return 1;
 
@@ -1712,7 +1709,7 @@ static int nested_svm_vmexit(struct vcpu
 	/* Exit nested SVM mode */
 	svm->nested.vmcb = 0;
 
-	nested_svm_unmap(nested_vmcb, KM_USER0);
+	nested_svm_unmap(page);
 
 	kvm_mmu_reset_context(&svm->vcpu);
 	kvm_mmu_load(&svm->vcpu);
@@ -1723,9 +1720,10 @@ static int nested_svm_vmexit(struct vcpu
 static bool nested_svm_vmrun_msrpm(struct vcpu_svm *svm)
 {
 	u32 *nested_msrpm;
+	struct page *page;
 	int i;
 
-	nested_msrpm = nested_svm_map(svm, svm->nested.vmcb_msrpm, KM_USER0);
+	nested_msrpm = nested_svm_map(svm, svm->nested.vmcb_msrpm, &page);
 	if (!nested_msrpm)
 		return false;
 
@@ -1734,7 +1732,7 @@ static bool nested_svm_vmrun_msrpm(struc
 
 	svm->vmcb->control.msrpm_base_pa = __pa(svm->nested.msrpm);
 
-	nested_svm_unmap(nested_msrpm, KM_USER0);
+	nested_svm_unmap(page);
 
 	return true;
 }
@@ -1744,8 +1742,9 @@ static bool nested_svm_vmrun(struct vcpu
 	struct vmcb *nested_vmcb;
 	struct vmcb *hsave = svm->nested.hsave;
 	struct vmcb *vmcb = svm->vmcb;
+	struct page *page;
 
-	nested_vmcb = nested_svm_map(svm, svm->vmcb->save.rax, KM_USER0);
+	nested_vmcb = nested_svm_map(svm, svm->vmcb->save.rax, &page);
 	if (!nested_vmcb)
 		return false;
 
@@ -1857,7 +1856,7 @@ static bool nested_svm_vmrun(struct vcpu
 	svm->vmcb->control.event_inj = nested_vmcb->control.event_inj;
 	svm->vmcb->control.event_inj_err = nested_vmcb->control.event_inj_err;
 
-	nested_svm_unmap(nested_vmcb, KM_USER0);
+	nested_svm_unmap(page);
 
 	enable_gif(svm);
 
@@ -1883,6 +1882,7 @@ static void nested_svm_vmloadsave(struct
 static int vmload_interception(struct vcpu_svm *svm)
 {
 	struct vmcb *nested_vmcb;
+	struct page *page;
 
 	if (nested_svm_check_permissions(svm))
 		return 1;
@@ -1890,12 +1890,12 @@ static int vmload_interception(struct vc
 	svm->next_rip = kvm_rip_read(&svm->vcpu) + 3;
 	skip_emulated_instruction(&svm->vcpu);
 
-	nested_vmcb = nested_svm_map(svm, svm->vmcb->save.rax, KM_USER0);
+	nested_vmcb = nested_svm_map(svm, svm->vmcb->save.rax, &page);
 	if (!nested_vmcb)
 		return 1;
 
 	nested_svm_vmloadsave(nested_vmcb, svm->vmcb);
-	nested_svm_unmap(nested_vmcb, KM_USER0);
+	nested_svm_unmap(page);
 
 	return 1;
 }
@@ -1903,6 +1903,7 @@ static int vmload_interception(struct vc
 static int vmsave_interception(struct vcpu_svm *svm)
 {
 	struct vmcb *nested_vmcb;
+	struct page *page;
 
 	if (nested_svm_check_permissions(svm))
 		return 1;
@@ -1910,12 +1911,12 @@ static int vmsave_interception(struct vc
 	svm->next_rip = kvm_rip_read(&svm->vcpu) + 3;
 	skip_emulated_instruction(&svm->vcpu);
 
-	nested_vmcb = nested_svm_map(svm, svm->vmcb->save.rax, KM_USER0);
+	nested_vmcb = nested_svm_map(svm, svm->vmcb->save.rax, &page);
 	if (!nested_vmcb)
 		return 1;
 
 	nested_svm_vmloadsave(svm->vmcb, nested_vmcb);
-	nested_svm_unmap(nested_vmcb, KM_USER0);
+	nested_svm_unmap(page);
 
 	return 1;
 }
#630 lore raw

PATCH 179/200 KVM: SVM: Fix schedule-while-atomic on nested exception handling

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Joerg Roedel <[email protected]>

Move the actual vmexit routine out of code that runs with irqs and preemption disabled.

(Cherry-picked from commit b8e88bc8ffba5fe53fb8d8a0a4be3bbcffeebe56)

---
 arch/x86/kvm/svm.c |   23 +++++++++++++++++++----
 1 file changed, 19 insertions(+), 4 deletions(-)
arch/x86/kvm/svm.c +19 -4
@@ -129,6 +129,7 @@ static void svm_flush_tlb(struct kvm_vcp
 static void svm_complete_interrupts(struct vcpu_svm *svm);
 
 static int nested_svm_exit_handled(struct vcpu_svm *svm);
+static int nested_svm_intercept(struct vcpu_svm *svm);
 static int nested_svm_vmexit(struct vcpu_svm *svm);
 static int nested_svm_check_exception(struct vcpu_svm *svm, unsigned nr,
 				      bool has_error_code, u32 error_code);
@@ -1384,6 +1385,8 @@ static int nested_svm_check_permissions(
 static int nested_svm_check_exception(struct vcpu_svm *svm, unsigned nr,
 				      bool has_error_code, u32 error_code)
 {
+	int vmexit;
+
 	if (!is_nested(svm))
 		return 0;
 
@@ -1392,7 +1395,11 @@ static int nested_svm_check_exception(st
 	svm->vmcb->control.exit_info_1 = error_code;
 	svm->vmcb->control.exit_info_2 = svm->vcpu.arch.cr2;
 
-	return nested_svm_exit_handled(svm);
+	vmexit = nested_svm_intercept(svm);
+	if (vmexit == NESTED_EXIT_DONE)
+		svm->nested.exit_required = true;
+
+	return vmexit;
 }
 
 static inline int nested_svm_intr(struct vcpu_svm *svm)
@@ -1521,7 +1528,7 @@ static int nested_svm_exit_special(struc
 /*
  * If this function returns true, this #vmexit was already handled
  */
-static int nested_svm_exit_handled(struct vcpu_svm *svm)
+static int nested_svm_intercept(struct vcpu_svm *svm)
 {
 	u32 exit_code = svm->vmcb->control.exit_code;
 	int vmexit = NESTED_EXIT_HOST;
@@ -1567,9 +1574,17 @@ static int nested_svm_exit_handled(struc
 	}
 	}
 
-	if (vmexit == NESTED_EXIT_DONE) {
+	return vmexit;
+}
+
+static int nested_svm_exit_handled(struct vcpu_svm *svm)
+{
+	int vmexit;
+
+	vmexit = nested_svm_intercept(svm);
+
+	if (vmexit == NESTED_EXIT_DONE)
 		nested_svm_vmexit(svm);
-	}
 
 	return vmexit;
 }
#631 lore raw

PATCH 180/200 KVM: SVM: Sync all control registers on nested vmexit

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Joerg Roedel <[email protected]>

Currently the vmexit emulation does not sync control registers were the access is typically intercepted by the nested hypervisor. But we can not count on that intercepts to sync these registers too and make the code architecturally more correct.

(Cherry-picked from commit cdbbdc1210223879450555fee04c29ebf116576b)

---
 arch/x86/kvm/svm.c |    4 ++++
 1 file changed, 4 insertions(+)
arch/x86/kvm/svm.c +4 -0
@@ -1647,9 +1647,13 @@ static int nested_svm_vmexit(struct vcpu
 	nested_vmcb->save.ds     = vmcb->save.ds;
 	nested_vmcb->save.gdtr   = vmcb->save.gdtr;
 	nested_vmcb->save.idtr   = vmcb->save.idtr;
+	nested_vmcb->save.cr0    = kvm_read_cr0(&svm->vcpu);
 	if (npt_enabled)
 		nested_vmcb->save.cr3    = vmcb->save.cr3;
+	else
+		nested_vmcb->save.cr3    = svm->vcpu.arch.cr3;
 	nested_vmcb->save.cr2    = vmcb->save.cr2;
+	nested_vmcb->save.cr4    = svm->vcpu.arch.cr4;
 	nested_vmcb->save.rflags = vmcb->save.rflags;
 	nested_vmcb->save.rip    = vmcb->save.rip;
 	nested_vmcb->save.rsp    = vmcb->save.rsp;
#632 lore raw

PATCH 181/200 KVM: SVM: Fix nested msr intercept handling

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Joerg Roedel <[email protected]>

The nested_svm_exit_handled_msr() function maps only one page of the guests msr permission bitmap. This patch changes the code to use kvm_read_guest to fix the bug.

(Cherry-picked from commit 4c7da8cb43c09e71a405b5aeaa58a1dbac3c39e9)

---
 arch/x86/kvm/svm.c |   13 +++----------
 1 file changed, 3 insertions(+), 10 deletions(-)
arch/x86/kvm/svm.c +3 -10
@@ -1459,19 +1459,13 @@ static bool nested_svm_exit_handled_msr(
 {
 	u32 param = svm->vmcb->control.exit_info_1 & 1;
 	u32 msr = svm->vcpu.arch.regs[VCPU_REGS_RCX];
-	struct page *page;
 	bool ret = false;
 	u32 t0, t1;
-	u8 *msrpm;
+	u8 val;
 
 	if (!(svm->nested.intercept & (1ULL << INTERCEPT_MSR_PROT)))
 		return false;
 
-	msrpm = nested_svm_map(svm, svm->nested.vmcb_msrpm, &page);
-
-	if (!msrpm)
-		goto out;
-
 	switch (msr) {
 	case 0 ... 0x1fff:
 		t0 = (msr * 2) % 8;
@@ -1492,11 +1486,10 @@ static bool nested_svm_exit_handled_msr(
 		goto out;
 	}
 
-	ret = msrpm[t1] & ((1 << param) << t0);
+	if (!kvm_read_guest(svm->vcpu.kvm, svm->nested.vmcb_msrpm + t1, &val, 1))
+		ret = val & ((1 << param) << t0);
 
 out:
-	nested_svm_unmap(page);
-
 	return ret;
 }
 
#633 lore raw

PATCH 182/200 KVM: SVM: Dont sync nested cr8 to lapic and back

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Joerg Roedel <[email protected]>

This patch makes syncing of the guest tpr to the lapic conditional on !nested. Otherwise a nested guest using the TPR could freeze the guest.
Another important change this patch introduces is that the cr8 intercept bits are no longer ORed at vmrun emulation if the guest sets VINTR_MASKING in its VMCB. The reason is that nested cr8 accesses need alway be handled by the nested hypervisor because they change the shadow version of the tpr.

(Cherry-picked from commit 88ab24adc7142506c8583ac36a34fa388300b750)

---
 arch/x86/kvm/svm.c |   46 +++++++++++++++++++++++++++++++---------------
 1 file changed, 31 insertions(+), 15 deletions(-)
arch/x86/kvm/svm.c +31 -15
@@ -1830,21 +1830,6 @@ static bool nested_svm_vmrun(struct vcpu
 	svm->vmcb->save.dr6 = nested_vmcb->save.dr6;
 	svm->vmcb->save.cpl = nested_vmcb->save.cpl;
 
-	/* We don't want a nested guest to be more powerful than the guest,
-	   so all intercepts are ORed */
-	svm->vmcb->control.intercept_cr_read |=
-		nested_vmcb->control.intercept_cr_read;
-	svm->vmcb->control.intercept_cr_write |=
-		nested_vmcb->control.intercept_cr_write;
-	svm->vmcb->control.intercept_dr_read |=
-		nested_vmcb->control.intercept_dr_read;
-	svm->vmcb->control.intercept_dr_write |=
-		nested_vmcb->control.intercept_dr_write;
-	svm->vmcb->control.intercept_exceptions |=
-		nested_vmcb->control.intercept_exceptions;
-
-	svm->vmcb->control.intercept |= nested_vmcb->control.intercept;
-
 	svm->nested.vmcb_msrpm = nested_vmcb->control.msrpm_base_pa;
 
 	/* cache intercepts */
@@ -1862,6 +1847,28 @@ static bool nested_svm_vmrun(struct vcpu
 	else
 		svm->vcpu.arch.hflags &= ~HF_VINTR_MASK;
 
+	if (svm->vcpu.arch.hflags & HF_VINTR_MASK) {
+		/* We only want the cr8 intercept bits of the guest */
+		svm->vmcb->control.intercept_cr_read &= ~INTERCEPT_CR8_MASK;
+		svm->vmcb->control.intercept_cr_write &= ~INTERCEPT_CR8_MASK;
+	}
+
+	/* We don't want a nested guest to be more powerful than the guest,
+	   so all intercepts are ORed */
+	svm->vmcb->control.intercept_cr_read |=
+		nested_vmcb->control.intercept_cr_read;
+	svm->vmcb->control.intercept_cr_write |=
+		nested_vmcb->control.intercept_cr_write;
+	svm->vmcb->control.intercept_dr_read |=
+		nested_vmcb->control.intercept_dr_read;
+	svm->vmcb->control.intercept_dr_write |=
+		nested_vmcb->control.intercept_dr_write;
+	svm->vmcb->control.intercept_exceptions |=
+		nested_vmcb->control.intercept_exceptions;
+
+	svm->vmcb->control.intercept |= nested_vmcb->control.intercept;
+
+	svm->vmcb->control.lbr_ctl = nested_vmcb->control.lbr_ctl;
 	svm->vmcb->control.int_vector = nested_vmcb->control.int_vector;
 	svm->vmcb->control.int_state = nested_vmcb->control.int_state;
 	svm->vmcb->control.tsc_offset += nested_vmcb->control.tsc_offset;
@@ -2524,6 +2531,9 @@ static void update_cr8_intercept(struct
 {
 	struct vcpu_svm *svm = to_svm(vcpu);
 
+	if (is_nested(svm) && (vcpu->arch.hflags & HF_VINTR_MASK))
+		return;
+
 	if (irr == -1)
 		return;
 
@@ -2627,6 +2637,9 @@ static inline void sync_cr8_to_lapic(str
 {
 	struct vcpu_svm *svm = to_svm(vcpu);
 
+	if (is_nested(svm) && (vcpu->arch.hflags & HF_VINTR_MASK))
+		return;
+
 	if (!(svm->vmcb->control.intercept_cr_write & INTERCEPT_CR8_MASK)) {
 		int cr8 = svm->vmcb->control.int_ctl & V_TPR_MASK;
 		kvm_set_cr8(vcpu, cr8);
@@ -2638,6 +2651,9 @@ static inline void sync_lapic_to_cr8(str
 	struct vcpu_svm *svm = to_svm(vcpu);
 	u64 cr8;
 
+	if (is_nested(svm) && (vcpu->arch.hflags & HF_VINTR_MASK))
+		return;
+
 	cr8 = kvm_get_cr8(vcpu);
 	svm->vmcb->control.int_ctl &= ~V_TPR_MASK;
 	svm->vmcb->control.int_ctl |= cr8 & V_TPR_MASK;
#634 lore raw

PATCH 183/200 KVM: SVM: Fix wrong interrupt injection in enable_irq_windows

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Joerg Roedel <[email protected]>

The nested_svm_intr() function does not execute the vmexit anymore. Therefore we may still be in the nested state after that function ran. This patch changes the nested_svm_intr() function to return wether the irq window could be enabled.

(Cherry-picked from commit 8fe546547cf6857a9d984bfe2f2194910f3fc5d0)

---
 arch/x86/kvm/svm.c |   17 ++++++++---------
 1 file changed, 8 insertions(+), 9 deletions(-)
arch/x86/kvm/svm.c +8 -9
@@ -1402,16 +1402,17 @@ static int nested_svm_check_exception(st
 	return vmexit;
 }
 
-static inline int nested_svm_intr(struct vcpu_svm *svm)
+/* This function returns true if it is save to enable the irq window */
+static inline bool nested_svm_intr(struct vcpu_svm *svm)
 {
 	if (!is_nested(svm))
-		return 0;
+		return true;
 
 	if (!(svm->vcpu.arch.hflags & HF_VINTR_MASK))
-		return 0;
+		return true;
 
 	if (!(svm->vcpu.arch.hflags & HF_HIF_MASK))
-		return 0;
+		return false;
 
 	svm->vmcb->control.exit_code = SVM_EXIT_INTR;
 
@@ -1424,10 +1425,10 @@ static inline int nested_svm_intr(struct
 		 */
 		svm->nested.exit_required = true;
 		trace_kvm_nested_intr_vmexit(svm->vmcb->save.rip);
-		return 1;
+		return false;
 	}
 
-	return 0;
+	return true;
 }
 
 static void *nested_svm_map(struct vcpu_svm *svm, u64 gpa, struct page **_page)
@@ -2591,13 +2592,11 @@ static void enable_irq_window(struct kvm
 {
 	struct vcpu_svm *svm = to_svm(vcpu);
 
-	nested_svm_intr(svm);
-
 	/* In case GIF=0 we can't rely on the CPU to tell us when
 	 * GIF becomes 1, because that's a separate STGI/VMRUN intercept.
 	 * The next time we get that intercept, this function will be
 	 * called again though and we'll get the vintr intercept. */
-	if (gif_set(svm)) {
+	if (gif_set(svm) && nested_svm_intr(svm)) {
 		svm_set_vintr(svm);
 		svm_inject_irq(svm, 0x0);
 	}
#635 lore raw

PATCH 184/200 KVM: s390: Fix possible memory leak of in kvm_arch_vcpu_create()

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Wei Yongjun <[email protected]>

This patch fixed possible memory leak in kvm_arch_vcpu_create() under s390, which would happen when kvm_arch_vcpu_create() fails.

(Cherry-picked from commit 7b06bf2ffa15e119c7439ed0b024d44f66d7b605)

---
 arch/s390/kvm/kvm-s390.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
arch/s390/kvm/kvm-s390.c +3 -1
@@ -341,11 +341,13 @@ struct kvm_vcpu *kvm_arch_vcpu_create(st
 
 	rc = kvm_vcpu_init(vcpu, kvm, id);
 	if (rc)
-		goto out_free_cpu;
+		goto out_free_sie_block;
 	VM_EVENT(kvm, 3, "create cpu %d at %p, sie block at %p", id, vcpu,
 		 vcpu->arch.sie_block);
 
 	return vcpu;
+out_free_sie_block:
+	free_page((unsigned long)(vcpu->arch.sie_block));
 out_free_cpu:
 	kfree(vcpu);
 out_nomem:
#636 lore raw

PATCH 185/200 KVM: PPC: Do not create debugfs if fail to create vcpu

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Wei Yongjun <[email protected]>

If fail to create the vcpu, we should not create the debugfs for it.

(Cherry-picked from commit 06056bfb944a0302a8f22eb45f09123de7fb417b)

---
 arch/powerpc/kvm/powerpc.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
arch/powerpc/kvm/powerpc.c +2 -1
@@ -193,7 +193,8 @@ struct kvm_vcpu *kvm_arch_vcpu_create(st
 {
 	struct kvm_vcpu *vcpu;
 	vcpu = kvmppc_core_vcpu_create(kvm, id);
-	kvmppc_create_vcpu_debugfs(vcpu, id);
+	if (!IS_ERR(vcpu))
+		kvmppc_create_vcpu_debugfs(vcpu, id);
 	return vcpu;
 }
 
#637 lore raw

PATCH 186/200 KVM: x86: Add callback to let modules decide over some supported cpuid bits

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Joerg Roedel <[email protected]>

This patch adds the get_supported_cpuid callback to kvm_x86_ops. It will be used in do_cpuid_ent to delegate the decission about some supported cpuid bits to the architecture modules.

(Cherry-picked from commit d4330ef2fb2236a1e3a176f0f68360f4c0a8661b)

---
 arch/x86/include/asm/kvm_host.h |    2 ++
 arch/x86/kvm/svm.c              |    6 ++++++
 arch/x86/kvm/vmx.c              |    6 ++++++
 arch/x86/kvm/x86.c              |    3 +++
 4 files changed, 17 insertions(+)
arch/x86/include/asm/kvm_host.h +2 -0
@@ -541,6 +541,8 @@ struct kvm_x86_ops {
 	int (*get_lpage_level)(void);
 	bool (*rdtscp_supported)(void);
 
+	void (*set_supported_cpuid)(u32 func, struct kvm_cpuid_entry2 *entry);
+
 	const struct trace_print_flags *exit_reasons_str;
 };
 
arch/x86/kvm/svm.c +6 -0
@@ -2907,6 +2907,10 @@ static void svm_cpuid_update(struct kvm_
 {
 }
 
+static void svm_set_supported_cpuid(u32 func, struct kvm_cpuid_entry2 *entry)
+{
+}
+
 static const struct trace_print_flags svm_exit_reasons_str[] = {
 	{ SVM_EXIT_READ_CR0,           		"read_cr0" },
 	{ SVM_EXIT_READ_CR3,	      		"read_cr3" },
@@ -3051,6 +3055,8 @@ static struct kvm_x86_ops svm_x86_ops =
 	.cpuid_update = svm_cpuid_update,
 
 	.rdtscp_supported = svm_rdtscp_supported,
+
+	.set_supported_cpuid = svm_set_supported_cpuid,
 };
 
 static int __init svm_init(void)
arch/x86/kvm/vmx.c +6 -0
@@ -4115,6 +4115,10 @@ static void vmx_cpuid_update(struct kvm_
 	}
 }
 
+static void vmx_set_supported_cpuid(u32 func, struct kvm_cpuid_entry2 *entry)
+{
+}
+
 static struct kvm_x86_ops vmx_x86_ops = {
 	.cpu_has_kvm_support = cpu_has_kvm_support,
 	.disabled_by_bios = vmx_disabled_by_bios,
@@ -4186,6 +4190,8 @@ static struct kvm_x86_ops vmx_x86_ops =
 	.cpuid_update = vmx_cpuid_update,
 
 	.rdtscp_supported = vmx_rdtscp_supported,
+
+	.set_supported_cpuid = vmx_set_supported_cpuid,
 };
 
 static int __init vmx_init(void)
arch/x86/kvm/x86.c +3 -0
@@ -1917,6 +1917,9 @@ static void do_cpuid_ent(struct kvm_cpui
 		entry->ecx &= kvm_supported_word6_x86_features;
 		break;
 	}
+
+	kvm_x86_ops->set_supported_cpuid(function, entry);
+
 	put_cpu();
 }
 
#638 lore raw

PATCH 187/200 KVM: SVM: Report emulated SVM features to userspace

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Joerg Roedel <[email protected]>

This patch implements the reporting of the emulated SVM features to userspace instead of the real hardware capabilities. Every real hardware capability needs emulation in nested svm so the old behavior was broken.

(Cherry-picked from commit c2c63a493924e09a1984d1374a0e60dfd54fc0b0)

---
 arch/x86/kvm/svm.c |   10 ++++++++++
 1 file changed, 10 insertions(+)
arch/x86/kvm/svm.c +10 -0
@@ -2909,6 +2909,16 @@ static void svm_cpuid_update(struct kvm_
 
 static void svm_set_supported_cpuid(u32 func, struct kvm_cpuid_entry2 *entry)
 {
+	switch (func) {
+	case 0x8000000A:
+		entry->eax = 1; /* SVM revision 1 */
+		entry->ebx = 8; /* Lets support 8 ASIDs in case we add proper
+				   ASID emulation to nested SVM */
+		entry->ecx = 0; /* Reserved */
+		entry->edx = 0; /* Do not support any additional features */
+
+		break;
+	}
 }
 
 static const struct trace_print_flags svm_exit_reasons_str[] = {
#639 lore raw

PATCH 188/200 x86, paravirt: Add a global synchronization point for pvclock

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Glauber Costa <[email protected]>

In recent stress tests, it was found that pvclock-based systems could seriously warp in smp systems. Using ingo's time-warp-test.c, I could trigger a scenario as bad as 1.5mi warps a minute in some systems. (to be fair, it wasn't that bad in most of them). Investigating further, I found out that such warps were caused by the very offset-based calculation pvclock is based on.

This happens even on some machines that report constant_tsc in its tsc flags, specially on multi-socket ones.

Two reads of the same kernel timestamp at approx the same time, will likely have tsc timestamped in different occasions too. This means the delta we calculate is unpredictable at best, and can probably be smaller in a cpu that is legitimately reading clock in a forward ocasion.

Some adjustments on the host could make this window less likely to happen, but still, it pretty much poses as an intrinsic problem of the mechanism.

A while ago, I though about using a shared variable anyway, to hold clock last state, but gave up due to the high contention locking was likely to introduce, possibly rendering the thing useless on big machines. I argue, however, that locking is not necessary.

We do a read-and-return sequence in pvclock, and between read and return, the global value can have changed. However, it can only have changed by means of an addition of a positive value. So if we detected that our clock timestamp is less than the current global, we know that we need to return a higher one, even though it is not exactly the one we compared to.

OTOH, if we detect we're greater than the current time source, we atomically replace the value with our new readings. This do causes contention on big boxes (but big here means *BIG*), but it seems like a good trade off, since it provide us with a time source guaranteed to be stable wrt time warps.

After this patch is applied, I don't see a single warp in time during 5 days of execution, in any of the machines I saw them before.

(Cherry-picked from commit 489fb490dbf8dab0249ad82b56688ae3842a79e8)

---
 arch/x86/kernel/pvclock.c |   24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)
arch/x86/kernel/pvclock.c +24 -0
@@ -109,11 +109,14 @@ unsigned long pvclock_tsc_khz(struct pvc
 	return pv_tsc_khz;
 }
 
+static atomic64_t last_value = ATOMIC64_INIT(0);
+
 cycle_t pvclock_clocksource_read(struct pvclock_vcpu_time_info *src)
 {
 	struct pvclock_shadow_time shadow;
 	unsigned version;
 	cycle_t ret, offset;
+	u64 last;
 
 	do {
 		version = pvclock_get_time_values(&shadow, src);
@@ -123,6 +126,27 @@ cycle_t pvclock_clocksource_read(struct
 		barrier();
 	} while (version != src->version);
 
+	/*
+	 * Assumption here is that last_value, a global accumulator, always goes
+	 * forward. If we are less than that, we should not be much smaller.
+	 * We assume there is an error marging we're inside, and then the correction
+	 * does not sacrifice accuracy.
+	 *
+	 * For reads: global may have changed between test and return,
+	 * but this means someone else updated poked the clock at a later time.
+	 * We just need to make sure we are not seeing a backwards event.
+	 *
+	 * For updates: last_value = ret is not enough, since two vcpus could be
+	 * updating at the same time, and one of them could be slightly behind,
+	 * making the assumption that last_value always go forward fail to hold.
+	 */
+	last = atomic64_read(&last_value);
+	do {
+		if (ret < last)
+			return last;
+		last = atomic64_cmpxchg(&last_value, last, ret);
+	} while (unlikely(last != ret));
+
 	return ret;
 }
 
#640 lore raw

PATCH 189/200 KVM: Dont allow lmsw to clear cr0.pe

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Avi Kivity <[email protected]>

The current lmsw implementation allows the guest to clear cr0.pe, contrary to the manual, which breaks EMM386.EXE.

Fix by ORing the old cr0.pe with lmsw's operand.

(Cherry-picked from commit f78e917688edbf1f14c318d2e50dc8e7dad20445)

---
 arch/x86/kvm/x86.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/x86/kvm/x86.c +1 -1
@@ -484,7 +484,7 @@ EXPORT_SYMBOL_GPL(kvm_set_cr0);
 
 void kvm_lmsw(struct kvm_vcpu *vcpu, unsigned long msw)
 {
-	kvm_set_cr0(vcpu, kvm_read_cr0_bits(vcpu, ~0x0ful) | (msw & 0x0f));
+	kvm_set_cr0(vcpu, kvm_read_cr0_bits(vcpu, ~0x0eul) | (msw & 0x0f));
 }
 EXPORT_SYMBOL_GPL(kvm_lmsw);
 
#641 lore raw

PATCH 190/200 KVM: x86: Check LMA bit before set_efer

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Sheng Yang <[email protected]>

kvm_x86_ops->set_efer() would execute vcpu->arch.efer = efer, so the checking of LMA bit didn't work.

(Cherry-picked from commit a3d204e28579427609c3d15d2310127ebaa47d94)

---
 arch/x86/kvm/x86.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
arch/x86/kvm/x86.c +2 -2
@@ -657,11 +657,11 @@ static void set_efer(struct kvm_vcpu *vc
 		}
 	}
 
-	kvm_x86_ops->set_efer(vcpu, efer);
-
 	efer &= ~EFER_LMA;
 	efer |= vcpu->arch.efer & EFER_LMA;
 
+	kvm_x86_ops->set_efer(vcpu, efer);
+
 	vcpu->arch.efer = efer;
 
 	vcpu->arch.mmu.base_role.nxe = (efer & EFER_NX) && !tdp_enabled;
#642 lore raw

PATCH 191/200 KVM: MMU: Segregate shadow pages with different cr0.wp

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Avi Kivity <[email protected]>

When cr0.wp=0, we may shadow a gpte having u/s=1 and r/w=0 with an spte having u/s=0 and r/w=1. This allows excessive access if the guest sets cr0.wp=1 and accesses through this spte.

Fix by making cr0.wp part of the base role; we'll have different sptes for the two cases and the problem disappears.

(Cherry-picked from commit 3dbe141595faa48a067add3e47bba3205b79d33c)

---
 arch/x86/include/asm/kvm_host.h |    1 +
 arch/x86/kvm/mmu.c              |    3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)
arch/x86/include/asm/kvm_host.h +1 -0
@@ -180,6 +180,7 @@ union kvm_mmu_page_role {
 		unsigned invalid:1;
 		unsigned cr4_pge:1;
 		unsigned nxe:1;
+		unsigned cr0_wp:1;
 	};
 };
 
arch/x86/kvm/mmu.c +2 -1
@@ -223,7 +223,7 @@ void kvm_mmu_set_mask_ptes(u64 user_mask
 }
 EXPORT_SYMBOL_GPL(kvm_mmu_set_mask_ptes);
 
-static int is_write_protection(struct kvm_vcpu *vcpu)
+static bool is_write_protection(struct kvm_vcpu *vcpu)
 {
 	return kvm_read_cr0_bits(vcpu, X86_CR0_WP);
 }
@@ -2439,6 +2439,7 @@ static int init_kvm_softmmu(struct kvm_v
 		r = paging32_init_context(vcpu);
 
 	vcpu->arch.mmu.base_role.glevels = vcpu->arch.mmu.root_level;
+	vcpu->arch.mmu.base_role.cr0_wp = is_write_protection(vcpu);
 
 	return r;
 }
#643 lore raw

PATCH 192/200 KVM: VMX: enable VMXON check with SMX enabled (Intel TXT)

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Shane Wang <[email protected]>

Per document, for feature control MSR:

Bit 1 enables VMXON in SMX operation. If the bit is clear, execution
of VMXON in SMX operation causes a general-protection exception.
Bit 2 enables VMXON outside SMX operation. If the bit is clear, execution
of VMXON outside SMX operation causes a general-protection exception.

This patch is to enable this kind of check with SMX for VMXON in KVM.

(Cherry-picked from commit cafd66595d92591e4bd25c3904e004fc6f897e2d)

---
 arch/x86/include/asm/msr-index.h |    5 +++--
 arch/x86/kernel/tboot.c          |    1 +
 arch/x86/kvm/vmx.c               |   32 +++++++++++++++++++++-----------
 include/linux/tboot.h            |    1 +
 4 files changed, 26 insertions(+), 13 deletions(-)
arch/x86/include/asm/msr-index.h +3 -2
@@ -199,8 +199,9 @@
 #define MSR_IA32_EBL_CR_POWERON		0x0000002a
 #define MSR_IA32_FEATURE_CONTROL        0x0000003a
 
-#define FEATURE_CONTROL_LOCKED		(1<<0)
-#define FEATURE_CONTROL_VMXON_ENABLED	(1<<2)
+#define FEATURE_CONTROL_LOCKED				(1<<0)
+#define FEATURE_CONTROL_VMXON_ENABLED_INSIDE_SMX	(1<<1)
+#define FEATURE_CONTROL_VMXON_ENABLED_OUTSIDE_SMX	(1<<2)
 
 #define MSR_IA32_APICBASE		0x0000001b
 #define MSR_IA32_APICBASE_BSP		(1<<8)
arch/x86/kernel/tboot.c +1 -0
@@ -46,6 +46,7 @@
 
 /* Global pointer to shared data; NULL means no measured launch. */
 struct tboot *tboot __read_mostly;
+EXPORT_SYMBOL(tboot);
 
 /* timeout for APs (in secs) to enter wait-for-SIPI state during shutdown */
 #define AP_WAIT_TIMEOUT		1
arch/x86/kvm/vmx.c +21 -11
@@ -27,6 +27,7 @@
 #include <linux/moduleparam.h>
 #include <linux/ftrace_event.h>
 #include <linux/slab.h>
+#include <linux/tboot.h>
 #include "kvm_cache_regs.h"
 #include "x86.h"
 
@@ -1176,9 +1177,16 @@ static __init int vmx_disabled_by_bios(v
 	u64 msr;
 
 	rdmsrl(MSR_IA32_FEATURE_CONTROL, msr);
-	return (msr & (FEATURE_CONTROL_LOCKED |
-		       FEATURE_CONTROL_VMXON_ENABLED))
-	    == FEATURE_CONTROL_LOCKED;
+	if (msr & FEATURE_CONTROL_LOCKED) {
+		if (!(msr & FEATURE_CONTROL_VMXON_ENABLED_INSIDE_SMX)
+			&& tboot_enabled())
+			return 1;
+		if (!(msr & FEATURE_CONTROL_VMXON_ENABLED_OUTSIDE_SMX)
+			&& !tboot_enabled())
+			return 1;
+	}
+
+	return 0;
 	/* locked but not enabled */
 }
 
@@ -1186,21 +1194,23 @@ static int hardware_enable(void *garbage
 {
 	int cpu = raw_smp_processor_id();
 	u64 phys_addr = __pa(per_cpu(vmxarea, cpu));
-	u64 old;
+	u64 old, test_bits;
 
 	if (read_cr4() & X86_CR4_VMXE)
 		return -EBUSY;
 
 	INIT_LIST_HEAD(&per_cpu(vcpus_on_cpu, cpu));
 	rdmsrl(MSR_IA32_FEATURE_CONTROL, old);
-	if ((old & (FEATURE_CONTROL_LOCKED |
-		    FEATURE_CONTROL_VMXON_ENABLED))
-	    != (FEATURE_CONTROL_LOCKED |
-		FEATURE_CONTROL_VMXON_ENABLED))
+
+	test_bits = FEATURE_CONTROL_LOCKED;
+	test_bits |= FEATURE_CONTROL_VMXON_ENABLED_OUTSIDE_SMX;
+	if (tboot_enabled())
+		test_bits |= FEATURE_CONTROL_VMXON_ENABLED_INSIDE_SMX;
+
+	if ((old & test_bits) != test_bits) {
 		/* enable and lock */
-		wrmsrl(MSR_IA32_FEATURE_CONTROL, old |
-		       FEATURE_CONTROL_LOCKED |
-		       FEATURE_CONTROL_VMXON_ENABLED);
+		wrmsrl(MSR_IA32_FEATURE_CONTROL, old | test_bits);
+	}
 	write_cr4(read_cr4() | X86_CR4_VMXE); /* FIXME: not cpu hotplug safe */
 	asm volatile (ASM_VMX_VMXON_RAX
 		      : : "a"(&phys_addr), "m"(phys_addr)
include/linux/tboot.h +1 -0
@@ -150,6 +150,7 @@ extern int tboot_force_iommu(void);
 
 #else
 
+#define tboot_enabled()			0
 #define tboot_probe()			do { } while (0)
 #define tboot_shutdown(shutdown_type)	do { } while (0)
 #define tboot_sleep(sleep_state, pm1a_control, pm1b_control)	\
#644 lore raw

PATCH 193/200 KVM: MMU: Dont read pdptrs with mmu spinlock held in mmu_alloc_roots

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Avi Kivity <[email protected]>

On svm, kvm_read_pdptr() may require reading guest memory, which can sleep.

Push the spinlock into mmu_alloc_roots(), and only take it after we've read the pdptr.

(Cherry-picked from commit 8facbbff071ff2b19268d3732e31badc60471e21)

---
 arch/x86/kvm/mmu.c |    7 +++++++
 1 file changed, 7 insertions(+)
arch/x86/kvm/mmu.c +7 -0
@@ -2085,11 +2085,13 @@ static int mmu_alloc_roots(struct kvm_vc
 			direct = 1;
 		if (mmu_check_root(vcpu, root_gfn))
 			return 1;
+		spin_lock(&vcpu->kvm->mmu_lock);
 		sp = kvm_mmu_get_page(vcpu, root_gfn, 0,
 				      PT64_ROOT_LEVEL, direct,
 				      ACC_ALL, NULL);
 		root = __pa(sp->spt);
 		++sp->root_count;
+		spin_unlock(&vcpu->kvm->mmu_lock);
 		vcpu->arch.mmu.root_hpa = root;
 		return 0;
 	}
@@ -2111,11 +2113,14 @@ static int mmu_alloc_roots(struct kvm_vc
 			root_gfn = 0;
 		if (mmu_check_root(vcpu, root_gfn))
 			return 1;
+		spin_lock(&vcpu->kvm->mmu_lock);
 		sp = kvm_mmu_get_page(vcpu, root_gfn, i << 30,
 				      PT32_ROOT_LEVEL, direct,
 				      ACC_ALL, NULL);
 		root = __pa(sp->spt);
 		++sp->root_count;
+		spin_unlock(&vcpu->kvm->mmu_lock);
+
 		vcpu->arch.mmu.pae_root[i] = root | PT_PRESENT_MASK;
 	}
 	vcpu->arch.mmu.root_hpa = __pa(vcpu->arch.mmu.pae_root);
@@ -2479,7 +2484,9 @@ int kvm_mmu_load(struct kvm_vcpu *vcpu)
 		goto out;
 	spin_lock(&vcpu->kvm->mmu_lock);
 	kvm_mmu_free_some_pages(vcpu);
+	spin_unlock(&vcpu->kvm->mmu_lock);
 	r = mmu_alloc_roots(vcpu);
+	spin_lock(&vcpu->kvm->mmu_lock);
 	mmu_sync_roots(vcpu);
 	spin_unlock(&vcpu->kvm->mmu_lock);
 	if (r)
#645 lore raw

PATCH 194/200 KVM: Fix wallclock version writing race

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Avi Kivity <[email protected]>

Wallclock writing uses an unprotected global variable to hold the version; this can cause one guest to interfere with another if both write their wallclock at the same time.

(Cherry-picked from commit 9ed3c444ab8987c7b219173a2f7807e3f71e234e)

---
 arch/x86/kvm/x86.c |   12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)
arch/x86/kvm/x86.c +10 -2
@@ -695,14 +695,22 @@ static int do_set_msr(struct kvm_vcpu *v
 
 static void kvm_write_wall_clock(struct kvm *kvm, gpa_t wall_clock)
 {
-	static int version;
+	int version;
+	int r;
 	struct pvclock_wall_clock wc;
 	struct timespec boot;
 
 	if (!wall_clock)
 		return;
 
-	version++;
+	r = kvm_read_guest(kvm, wall_clock, &version, sizeof(version));
+	if (r)
+		return;
+
+	if (version & 1)
+		++version;  /* first time write, random junk */
+
+	++version;
 
 	kvm_write_guest(kvm, wall_clock, &version, sizeof(version));
 
#646 lore raw

PATCH 195/200 KVM: PPC: Add missing vcpu_load()/vcpu_put() in vcpu ioctls

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Avi Kivity <[email protected]>

(Cherry-picked from commit 98001d8d017cea1ee0f9f35c6227bbd63ef5005b)

---
 arch/powerpc/kvm/book3s.c |   10 ++++++++++
 arch/powerpc/kvm/booke.c  |   15 ++++++++++++++-
 2 files changed, 24 insertions(+), 1 deletion(-)
arch/powerpc/kvm/book3s.c +10 -0
@@ -922,6 +922,8 @@ int kvm_arch_vcpu_ioctl_get_sregs(struct
 	struct kvmppc_vcpu_book3s *vcpu3s = to_book3s(vcpu);
 	int i;
 
+	vcpu_load(vcpu);
+
 	sregs->pvr = vcpu->arch.pvr;
 
 	sregs->u.s.sdr1 = to_book3s(vcpu)->sdr1;
@@ -940,6 +942,9 @@ int kvm_arch_vcpu_ioctl_get_sregs(struct
 			sregs->u.s.ppc32.dbat[i] = vcpu3s->dbat[i].raw;
 		}
 	}
+
+	vcpu_put(vcpu);
+
 	return 0;
 }
 
@@ -949,6 +954,8 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct
 	struct kvmppc_vcpu_book3s *vcpu3s = to_book3s(vcpu);
 	int i;
 
+	vcpu_load(vcpu);
+
 	kvmppc_set_pvr(vcpu, sregs->pvr);
 
 	vcpu3s->sdr1 = sregs->u.s.sdr1;
@@ -975,6 +982,9 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct
 
 	/* Flush the MMU after messing with the segments */
 	kvmppc_mmu_pte_flush(vcpu, 0, 0);
+
+	vcpu_put(vcpu);
+
 	return 0;
 }
 
arch/powerpc/kvm/booke.c +14 -1
@@ -479,6 +479,8 @@ int kvm_arch_vcpu_ioctl_get_regs(struct
 {
 	int i;
 
+	vcpu_load(vcpu);
+
 	regs->pc = vcpu->arch.pc;
 	regs->cr = kvmppc_get_cr(vcpu);
 	regs->ctr = vcpu->arch.ctr;
@@ -499,6 +501,8 @@ int kvm_arch_vcpu_ioctl_get_regs(struct
 	for (i = 0; i < ARRAY_SIZE(regs->gpr); i++)
 		regs->gpr[i] = kvmppc_get_gpr(vcpu, i);
 
+	vcpu_put(vcpu);
+
 	return 0;
 }
 
@@ -506,6 +510,8 @@ int kvm_arch_vcpu_ioctl_set_regs(struct
 {
 	int i;
 
+	vcpu_load(vcpu);
+
 	vcpu->arch.pc = regs->pc;
 	kvmppc_set_cr(vcpu, regs->cr);
 	vcpu->arch.ctr = regs->ctr;
@@ -525,6 +531,8 @@ int kvm_arch_vcpu_ioctl_set_regs(struct
 	for (i = 0; i < ARRAY_SIZE(regs->gpr); i++)
 		kvmppc_set_gpr(vcpu, i, regs->gpr[i]);
 
+	vcpu_put(vcpu);
+
 	return 0;
 }
 
@@ -553,7 +561,12 @@ int kvm_arch_vcpu_ioctl_set_fpu(struct k
 int kvm_arch_vcpu_ioctl_translate(struct kvm_vcpu *vcpu,
                                   struct kvm_translation *tr)
 {
-	return kvmppc_core_vcpu_translate(vcpu, tr);
+	int r;
+
+	vcpu_load(vcpu);
+	r = kvmppc_core_vcpu_translate(vcpu, tr);
+	vcpu_put(vcpu);
+	return r;
 }
 
 int kvm_vm_ioctl_get_dirty_log(struct kvm *kvm, struct kvm_dirty_log *log)
#647 lore raw

PATCH 196/200 KVM: x86: Add missing locking to arch specific vcpu ioctls

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Avi Kivity <[email protected]>

(Cherry-picked from commit 8fbf065d625617bbbf6b72d5f78f84ad13c8b547)

---
 arch/x86/kvm/x86.c |    6 ++++++
 1 file changed, 6 insertions(+)
arch/x86/kvm/x86.c +6 -0
@@ -1776,6 +1776,7 @@ static int kvm_vcpu_ioctl_get_cpuid2(str
 {
 	int r;
 
+	vcpu_load(vcpu);
 	r = -E2BIG;
 	if (cpuid->nent < vcpu->arch.cpuid_nent)
 		goto out;
@@ -1787,6 +1788,7 @@ static int kvm_vcpu_ioctl_get_cpuid2(str
 
 out:
 	cpuid->nent = vcpu->arch.cpuid_nent;
+	vcpu_put(vcpu);
 	return r;
 }
 
@@ -2042,6 +2044,7 @@ static int kvm_vcpu_ioctl_x86_setup_mce(
 	int r;
 	unsigned bank_num = mcg_cap & 0xff, bank;
 
+	vcpu_load(vcpu);
 	r = -EINVAL;
 	if (!bank_num || bank_num >= KVM_MAX_MCE_BANKS)
 		goto out;
@@ -2056,6 +2059,7 @@ static int kvm_vcpu_ioctl_x86_setup_mce(
 	for (bank = 0; bank < bank_num; bank++)
 		vcpu->arch.mce_banks[bank*4] = ~(u64)0;
 out:
+	vcpu_put(vcpu);
 	return r;
 }
 
@@ -2323,7 +2327,9 @@ long kvm_arch_vcpu_ioctl(struct file *fi
 		r = -EFAULT;
 		if (copy_from_user(&mce, argp, sizeof mce))
 			goto out;
+		vcpu_load(vcpu);
 		r = kvm_vcpu_ioctl_x86_set_mce(vcpu, &mce);
+		vcpu_put(vcpu);
 		break;
 	}
 	case KVM_GET_VCPU_EVENTS: {
#648 lore raw

PATCH 197/200 KVM: x86: Inject #GP with the right rip on efer writes

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Joerg Roedel <[email protected]>

This patch fixes a bug in the KVM efer-msr write path. If a guest writes to a reserved efer bit the set_efer function injects the #GP directly. The architecture dependent wrmsr function does not see this, assumes success and advances the rip. This results in a #GP in the guest with the wrong rip. This patch fixes this by reporting efer write errors back to the architectural wrmsr function.

(Cherry-picked from commit b69e8caef5b190af48c525f6d715e7b7728a77f6)

---
 arch/x86/kvm/x86.c |   31 ++++++++++++-------------------
 1 file changed, 12 insertions(+), 19 deletions(-)
arch/x86/kvm/x86.c +12 -19
@@ -624,37 +624,29 @@ static u32 emulated_msrs[] = {
 	MSR_IA32_MISC_ENABLE,
 };
 
-static void set_efer(struct kvm_vcpu *vcpu, u64 efer)
+static int set_efer(struct kvm_vcpu *vcpu, u64 efer)
 {
-	if (efer & efer_reserved_bits) {
-		kvm_inject_gp(vcpu, 0);
-		return;
-	}
+	if (efer & efer_reserved_bits)
+		return 1;
 
 	if (is_paging(vcpu)
-	    && (vcpu->arch.efer & EFER_LME) != (efer & EFER_LME)) {
-		kvm_inject_gp(vcpu, 0);
-		return;
-	}
+	    && (vcpu->arch.efer & EFER_LME) != (efer & EFER_LME))
+		return 1;
 
 	if (efer & EFER_FFXSR) {
 		struct kvm_cpuid_entry2 *feat;
 
 		feat = kvm_find_cpuid_entry(vcpu, 0x80000001, 0);
-		if (!feat || !(feat->edx & bit(X86_FEATURE_FXSR_OPT))) {
-			kvm_inject_gp(vcpu, 0);
-			return;
-		}
+		if (!feat || !(feat->edx & bit(X86_FEATURE_FXSR_OPT)))
+			return 1;
 	}
 
 	if (efer & EFER_SVME) {
 		struct kvm_cpuid_entry2 *feat;
 
 		feat = kvm_find_cpuid_entry(vcpu, 0x80000001, 0);
-		if (!feat || !(feat->ecx & bit(X86_FEATURE_SVM))) {
-			kvm_inject_gp(vcpu, 0);
-			return;
-		}
+		if (!feat || !(feat->ecx & bit(X86_FEATURE_SVM)))
+			return 1;
 	}
 
 	efer &= ~EFER_LMA;
@@ -666,6 +658,8 @@ static void set_efer(struct kvm_vcpu *vc
 
 	vcpu->arch.mmu.base_role.nxe = (efer & EFER_NX) && !tdp_enabled;
 	kvm_mmu_reset_context(vcpu);
+
+	return 0;
 }
 
 void kvm_enable_efer_bits(u64 mask)
@@ -1094,8 +1088,7 @@ int kvm_set_msr_common(struct kvm_vcpu *
 {
 	switch (msr) {
 	case MSR_EFER:
-		set_efer(vcpu, data);
-		break;
+		return set_efer(vcpu, data);
 	case MSR_K7_HWCR:
 		data &= ~(u64)0x40;	/* ignore flush filter disable */
 		if (data != 0) {
#649 lore raw

PATCH 198/200 KVM: SVM: Dont allow nested guest to VMMCALL into host

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Joerg Roedel <[email protected]>

This patch disables the possibility for a l2-guest to do a VMMCALL directly into the host. This would happen if the l1-hypervisor doesn't intercept VMMCALL and the l2-guest executes this instruction.

(Cherry-picked from commit 0d945bd9351199744c1e89d57a70615b6ee9f394)

---
 arch/x86/kvm/svm.c |    3 +++
 1 file changed, 3 insertions(+)
arch/x86/kvm/svm.c +3 -0
@@ -1854,6 +1854,9 @@ static bool nested_svm_vmrun(struct vcpu
 		svm->vmcb->control.intercept_cr_write &= ~INTERCEPT_CR8_MASK;
 	}
 
+	/* We don't want to see VMMCALLs from a nested guest */
+	svm->vmcb->control.intercept &= ~(1ULL << INTERCEPT_VMMCALL);
+
 	/* We don't want a nested guest to be more powerful than the guest,
 	   so all intercepts are ORed */
 	svm->vmcb->control.intercept_cr_read |=
#650 lore raw

PATCH 199/200 drm/i915: Dont touch PORT_HOTPLUG_EN in intel_dp_detect()

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Karsten Wiese <[email protected]>

commit 6e0032f0ae4440e75256bee11b163552cae21962 upstream.

PORT_HOTPLUG_EN has allready been setup in i915_driver_irq_postinstall(), when intel_dp_detect() runs.

Delete the DP[BCD]_HOTPLUG_INT_EN defines, they are not referenced anymore.

I found this while searching for a fix for

        https://bugzilla.redhat.com/show_bug.cgi?id=528312
---
 drivers/gpu/drm/i915/intel_dp.c |   10 ----------
 1 file changed, 10 deletions(-)
drivers/gpu/drm/i915/intel_dp.c +0 -10
@@ -1180,16 +1180,6 @@ intel_dp_detect(struct drm_connector *co
 	if (HAS_PCH_SPLIT(dev))
 		return ironlake_dp_detect(connector);
 
-	temp = I915_READ(PORT_HOTPLUG_EN);
-
-	I915_WRITE(PORT_HOTPLUG_EN,
-	       temp |
-	       DPB_HOTPLUG_INT_EN |
-	       DPC_HOTPLUG_INT_EN |
-	       DPD_HOTPLUG_INT_EN);
-
-	POSTING_READ(PORT_HOTPLUG_EN);
-
 	switch (dp_priv->output_reg) {
 	case DP_B:
 		bit = DPB_HOTPLUG_INT_STATUS;
#651 lore raw

PATCH 200/200 parisc: clear floating point exception flag on SIGFPE signal

In reply to Greg KH

2.6.34-stable review patch. If anyone has any objections, please let me know.

------------------

From: Helge Deller <[email protected]>

commit 550f0d922286556c7ea43974bb7921effb5a5278 upstream.

Clear the floating point exception flag before returning to user space. This is needed, else the libc trampoline handler may hit the same SIGFPE again while building up a trampoline to a signal handler.

Fixes debian bug #559406.

---
 arch/parisc/math-emu/decode_exc.c |    1 +
 1 file changed, 1 insertion(+)
arch/parisc/math-emu/decode_exc.c +1 -0
@@ -342,6 +342,7 @@ decode_fpu(unsigned int Fpu_register[],
 		return SIGNALCODE(SIGFPE, FPE_FLTINV);
 	  case DIVISIONBYZEROEXCEPTION:
 		update_trap_counts(Fpu_register, aflags, bflags, trap_counts);
+		Clear_excp_register(exception_index);
 	  	return SIGNALCODE(SIGFPE, FPE_FLTDIV);
 	  case INEXACTEXCEPTION:
 		update_trap_counts(Fpu_register, aflags, bflags, trap_counts);
#652 lore raw
In reply to Greg KH

Hi,

Quoted 4 lines · Greg KH

First off, sorry for the long delay in the -stable kernel releases, they got pushed to the back-burner for other things recently ("Hey look, is that the sun finally here in the Pacific Northwest?")

Quoted 8 lines

Please note that there are still a large number of patches that have been submitted to the -stable trees for inclusion, that I have not included yet. Do not worry, they are still in my queue, but due to the large number of patches that I already have queued up, I figured it was better to get what I have applied already out for a release and then work on catching up after this.

If anyone has any questions about this, please let me know.

Looks like this cpmac patch was not included in this -stable series:
http://www.spinics.net/lists/netdev/msg133317.html

Can you queue it for future -stable releases or this one?

Thank you.
--
Florian

author
#653 lore raw
Quoted 14 lines · Florian Fainelli

Hi,

Quoted 11 lines · Greg KH

First off, sorry for the long delay in the -stable kernel releases, they got pushed to the back-burner for other things recently ("Hey look, is that the sun finally here in the Pacific Northwest?")

Please note that there are still a large number of patches that have been submitted to the -stable trees for inclusion, that I have not included yet. Do not worry, they are still in my queue, but due to the large number of patches that I already have queued up, I figured it was better to get what I have applied already out for a release and then work on catching up after this.

Quoted 6 lines
Quoted 1 line

If anyone has any questions about this, please let me know.

Looks like this cpmac patch was not included in this -stable series:
http://www.spinics.net/lists/netdev/msg133317.html

Can you queue it for future -stable releases or this one?

{sigh}

Did you see the second paragraph above as to why it isn't in this release?

And yes, it will be in future ones.

thanks,

greg k-h

#654 lore raw
Quoted 20 lines · On Thu, 1 Jul 2010 15:10:59 -0700 Greg KH wrote:
Quoted 19 lines · Florian Fainelli

Hi,

Quoted 4 lines · Greg KH

First off, sorry for the long delay in the -stable kernel releases, they got pushed to the back-burner for other things recently ("Hey look, is that the sun finally here in the Pacific Northwest?")

Quoted 8 lines

Please note that there are still a large number of patches that have been submitted to the -stable trees for inclusion, that I have not included yet. Do not worry, they are still in my queue, but due to the large number of patches that I already have queued up, I figured it was better to get what I have applied already out for a release and then work on catching up after this.

If anyone has any questions about this, please let me know.

Looks like this cpmac patch was not included in this -stable series:
http://www.spinics.net/lists/netdev/msg133317.html

Quoted 6 lines
Quoted 1 line

Can you queue it for future -stable releases or this one?

{sigh}

Did you see the second paragraph above as to why it isn't in this release?

I did. :)
and I saw the third paragraph above.
["If anyone has any questions about this, please let me know."]

Quoted 1 line

And yes, it will be in future ones.

Unfortunately, I don't find it feasible to review several hundred patches in the next 3 days. I think that I understand how your stable & staging cycles (workloads) work, but I also think that it would help if you wouldn't batch all stable reviews together like this.

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

author
#655 lore raw
Quoted 24 lines · Randy Dunlap
Quoted 22 lines · On Thu, 1 Jul 2010 15:10:59 -0700 Greg KH wrote:
Quoted 20 lines · Florian Fainelli

Hi,

Quoted 4 lines · Greg KH

First off, sorry for the long delay in the -stable kernel releases, they got pushed to the back-burner for other things recently ("Hey look, is that the sun finally here in the Pacific Northwest?")

Quoted 8 lines

Please note that there are still a large number of patches that have been submitted to the -stable trees for inclusion, that I have not included yet. Do not worry, they are still in my queue, but due to the large number of patches that I already have queued up, I figured it was better to get what I have applied already out for a release and then work on catching up after this.

If anyone has any questions about this, please let me know.

Looks like this cpmac patch was not included in this -stable series:
http://www.spinics.net/lists/netdev/msg133317.html

Can you queue it for future -stable releases or this one?

Quoted 8 lines
Quoted 4 lines

{sigh}

Did you see the second paragraph above as to why it isn't in this release?

I did. :)
and I saw the third paragraph above.
["If anyone has any questions about this, please let me know."]

Well, if the question could be answered by reading the second paragraph... :)

Quoted 6 lines
Quoted 1 line

And yes, it will be in future ones.

Unfortunately, I don't find it feasible to review several hundred patches in the next 3 days. I think that I understand how your stable & staging cycles (workloads) work, but I also think that it would help if you wouldn't batch all stable reviews together like this.

If you look closely, almost all of the patches in all of the trees are in other trees, so the number of unique patches is much less than the whole total of all of the different patches in 4 trees.

If you don't like this type of review cycle, what would you prefer?

thanks,

greg k-h

#656 lore raw
Quoted 39 lines · On Thu, 1 Jul 2010 15:51:29 -0700 Greg KH wrote:
Quoted 24 lines · Randy Dunlap
Quoted 22 lines · On Thu, 1 Jul 2010 15:10:59 -0700 Greg KH wrote:
Quoted 20 lines · Florian Fainelli

Hi,

Quoted 4 lines · Greg KH

First off, sorry for the long delay in the -stable kernel releases, they got pushed to the back-burner for other things recently ("Hey look, is that the sun finally here in the Pacific Northwest?")

Quoted 8 lines

Please note that there are still a large number of patches that have been submitted to the -stable trees for inclusion, that I have not included yet. Do not worry, they are still in my queue, but due to the large number of patches that I already have queued up, I figured it was better to get what I have applied already out for a release and then work on catching up after this.

If anyone has any questions about this, please let me know.

Looks like this cpmac patch was not included in this -stable series:
http://www.spinics.net/lists/netdev/msg133317.html

Can you queue it for future -stable releases or this one?

Quoted 8 lines
Quoted 4 lines

{sigh}

Did you see the second paragraph above as to why it isn't in this release?

I did. :)
and I saw the third paragraph above.
["If anyone has any questions about this, please let me know."]

Well, if the question could be answered by reading the second paragraph... :)

Quoted 2 lines
Quoted 1 line

And yes, it will be in future ones.

Quoted 8 lines
Quoted 4 lines

Unfortunately, I don't find it feasible to review several hundred patches in the next 3 days. I think that I understand how your stable & staging cycles (workloads) work, but I also think that it would help if you wouldn't batch all stable reviews together like this.

If you look closely, almost all of the patches in all of the trees are in other trees, so the number of unique patches is much less than the whole total of all of the different patches in 4 trees.

Yes, that's a good point.

Quoted 1 line

If you don't like this type of review cycle, what would you prefer?

I don't see a magic bullet answer here. I think that it would help somewhat for the stable maintainer(s) to have only one -stable review cycle (new posting) per day, but someone may not like that either, since it would have the effect of delaying some stable kernel releases (not to mention muck up your workload).

thanks,
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

author
#657 lore raw
Quoted 8 lines · Randy Dunlap
Quoted 1 line · On Thu, 1 Jul 2010 15:51:29 -0700 Greg KH wrote:

If you don't like this type of review cycle, what would you prefer?

I don't see a magic bullet answer here. I think that it would help somewhat for the stable maintainer(s) to have only one -stable review cycle (new posting) per day, but someone may not like that either, since it would have the effect of delaying some stable kernel releases (not to mention muck up your workload).

Yeah, that would mess with the workload management a lot. And I don't see the benifit of doing a different release on different days. Just because they are different kernels, the same patches are usually being applied to all of them, so they are very much alike usually.

thanks,

greg k-h