4 -stable kernel review cycles starting
Subsystems (87)
PATCH 89/200 md: set mddev readonly flag on blkdev BLKROSET ioctl
In reply to Greg KH2.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_deviceint 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; }/*
PATCH 90/200 x86/amd-iommu: Fix crash when request_mem_region fails
In reply to Greg KH2.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,
PATCH 91/200 x86/amd-iommu: Fall back to GART if initialization fails
In reply to Greg KH2.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; }
PATCH 92/200 eeepc-wmi: depends on BACKLIGHT_CLASS_DEVICE
In reply to Greg KH2.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.
PATCH 93/200 clean DCACHE_CANT_MOUNT in d_delete()
In reply to Greg KH2.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 ;
PATCH 94/200 exofs: confusion between kmap() and kmap_atomic() api
In reply to Greg KH2.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);
PATCH 95/200 mn10300: set ARCH_KMALLOC_MINALIGN
In reply to Greg KH2.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
PATCH 96/200 m68knommu: fix broken use of BUAD_TABLE_SIZE in 68328serial driver
In reply to Greg KH2.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 consolefor (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 ) {
PATCH 97/200 m68k: set ARCH_KMALLOC_MINALIGN
In reply to Greg KH2.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
PATCH 98/200 rtc-cmos: do dev_set_drvdata() earlier in the initialization
In reply to Greg KH2.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);
PATCH 99/200 rtc: s3c: initialize driver data before using it
In reply to Greg KH2.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(strucpr_debug ("s3c2410_rtc: RTCCON=%02x\n" ,readb (s3c_rtc_base +S3C2410_RTCCON )); -s3c_rtc_setfreq (&pdev->dev,1 ); -device_init_wakeup (&pdev->dev,1 );/* register RTC and exit */
@@ -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:
PATCH 100/200 frv: set ARCH_KMALLOC_MINALIGN
In reply to Greg KH2.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)))
PATCH 101/200 xtensa: set ARCH_KMALLOC_MINALIGN
In reply to Greg KH2.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 */
PATCH 102/200 Blackfin: set ARCH_KMALLOC_MINALIGN
In reply to Greg KH2.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
PATCH 103/200 tmpfs: insert tmpfs cache pages to inactive list at first
In reply to Greg KH2.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 *pif (page_is_file_cache (page))lru_cache_add_file (page);else -lru_cache_add_active_anon (page); +lru_cache_add_anon (page); }return ret; }
PATCH 104/200 md: manage redundancy group in sysfs when changing level.
In reply to Greg KH2.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_tstatic 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_satomic_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 ; }
PATCH 105/200 mlx4_core: Fix possible chunk sg list overflow in mlx4_alloc_icm()
In reply to Greg KH2.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 mif (chunk->nsg <=0 ) goto fail; + } +if (chunk->npages ==MLX4_ICM_CHUNK_LEN ) chunk =NULL ; - } npages -=1 << cur_order; }else {
PATCH 106/200 ARM: 6139/1: ARMv7: Use the Inner Shareable I-cache on MP
In reply to Greg KH2.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
@@ -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
PATCH 107/200 ARM: 6166/1: Proper prefetch abort handling on pre-ARMv6
In reply to Greg KH2.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);/*
PATCH 108/200 ARM: 6164/1: Add kto and kfrom to input operands list.
In reply to Greg KH2.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,
PATCH 109/200 ARM: 6146/1: sa1111: Prevent deadlock in resume path
In reply to Greg KH2.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 platformif (!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 );
PATCH 110/200 ARM: 6144/1: TCM memory bug freeing bug
In reply to Greg KH2.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
PATCH 111/200 ARM: VFP: Fix vfp_put_double() for d16-d31
In reply to Greg KH2.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
PATCH 112/200 aio: fix the compat vectored operations
In reply to Greg KH2.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 *ireturn 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_tbreak ; } - 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_treturn 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 *iocbextern 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 kiocstatic 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)
PATCH 113/200 idr: fix backtrack logic in idr_remove_all
In reply to Greg KH2.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 ;
PATCH 114/200 ASoC: Update Freescale i.MX SSI driver DMA parameter handling
In reply to Greg KH2.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 snstruct 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;
PATCH 115/200 ASoC: Fix dB scales for WM835x
In reply to Greg KH2.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
@@ -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);
PATCH 116/200 ASoC: Fix dB scales for WM8400
In reply to Greg KH2.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 snwm8400_reset_codec_reg_cache (wm8400->wm8400); } -static const DECLARE_TLV_DB_LINEAR(rec_mix_tlv, -1500, 600); +static const DECLARE_TLV_DB_SCALE(rec_mix_tlv, -1500, 600, 0); -static const DECLARE_TLV_DB_LINEAR(in_pga_tlv, -1650, 3000); +static const DECLARE_TLV_DB_SCALE(in_pga_tlv, -1650, 3000, 0); -static const DECLARE_TLV_DB_LINEAR(out_mix_tlv, -2100, 0); +static const DECLARE_TLV_DB_SCALE(out_mix_tlv, -2100, 0, 0); -static const DECLARE_TLV_DB_LINEAR(out_pga_tlv, -7300, 600); +static const DECLARE_TLV_DB_SCALE(out_pga_tlv, -7300, 600, 0); -static const DECLARE_TLV_DB_LINEAR(out_omix_tlv, -600, 0); +static const DECLARE_TLV_DB_SCALE(out_omix_tlv, -600, 0, 0); -static const DECLARE_TLV_DB_LINEAR(out_dac_tlv, -7163, 0); +static const DECLARE_TLV_DB_SCALE(out_dac_tlv, -7163, 0, 0); -static const DECLARE_TLV_DB_LINEAR(in_adc_tlv, -7163, 1763); +static const DECLARE_TLV_DB_SCALE(in_adc_tlv, -7163, 1763, 0); -static const DECLARE_TLV_DB_LINEAR(out_sidetone_tlv, -3600, 0); +static const DECLARE_TLV_DB_SCALE(out_sidetone_tlv, -3600, 0, 0);static int wm8400_outpga_put_volsw_vu (struct snd_kcontrol *kcontrol,struct snd_ctl_elem_value *ucontrol)
@@ -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 */
PATCH 117/200 ASoC: Fix dB scales for WM8990
In reply to Greg KH2.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 */
PATCH 118/200 drm/radeon: fix the r100/r200 ums block 0 page fix
In reply to Greg KH2.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 )) {
PATCH 119/200 SLUB: Allow full duplication of kmalloc array for 390
In reply to Greg KH2.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
PATCH 120/200 slub: move kmem_cache_node into its own cacheline
In reply to Greg KH2.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(structfor_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(structstatic 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); }
Re: [000/200] 2.6.34.1 stable review
In reply to Greg KHQuoted 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
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
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
PATCH 121/200 hwmon: (ltc4245) Read only one GPIO pin
In reply to Greg KH2.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 decase LTC4245_VEEOUT : voltage = regval *-55 ;break ; -case LTC4245_GPIOADC1 : -case LTC4245_GPIOADC2 : -case LTC4245_GPIOADC3 : +case LTC4245_GPIOADC : voltage = regval *10 ;break ;default :
@@ -297,9 +293,7 @@ LTC4245_ALARM(in7_min_alarm, (1 << 2), LLTC4245_ALARM (in8_min_alarm, (1 <<3 ),LTC4245_FAULT2 );/* GPIO voltages */ -LTC4245_VOLTAGE (in9_input,LTC4245_GPIOADC1 ); -LTC4245_VOLTAGE (in10_input,LTC4245_GPIOADC2 ); -LTC4245_VOLTAGE (in11_input,LTC4245_GPIOADC3 ); +LTC4245_VOLTAGE (in9_input,LTC4245_GPIOADC );/* Power Consumption (virtual) */ LTC4245_POWER (power1_input,LTC4245_12VSENSE );
@@ -342,8 +336,6 @@ static struct attribute *ltc4245_attribu &sensor_dev_attr_in8_min_alarm.dev_attr.attr, &sensor_dev_attr_in9_input.dev_attr.attr, - &sensor_dev_attr_in10_input.dev_attr.attr, - &sensor_dev_attr_in11_input.dev_attr.attr, &sensor_dev_attr_power1_input.dev_attr.attr, &sensor_dev_attr_power2_input.dev_attr.attr,
PATCH 122/200 signals: check_kill_permission(): dont check creds if same_thread_group()
In reply to Greg KH2.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 strstatic 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 sigif (error)return error; + cred =current_cred (); tcred =__task_cred (t); - if ((cred->euid ^ tcred->suid) && + if (!same_thread_group(current, t) && + (cred->euid ^ tcred->suid) && (cred->euid ^ tcred->uid) && (cred->uid ^ tcred->suid) && (cred->uid ^ tcred->uid) &&
PATCH 123/200 compat: factor out compat_rw_copy_check_uvector from compat_do_readv_writev
In reply to Greg KH2.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(unasmlinkage 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 */
PATCH 124/200 fs/compat_rw_copy_check_uvector: add missing compat_ptr call
In reply to Greg KH2.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; }
PATCH 125/200 do_generic_file_read: clear page errors when issuing a fresh read of the page
In reply to Greg KH2.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);
PATCH 126/200 ipmi: handle run_to_completion properly in deliver_recv_msg()
In reply to Greg KH2.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)
PATCH 127/200 x86, setup: Phoenix BIOS fixup is needed on Dell Inspiron Mini 1012
In reply to Greg KH2.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 {} };
PATCH 128/200 xen: ensure timer tick is resumed even on CPU driving the resume
In reply to Greg KH2.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(voidvoid xen_arch_resume (void ) { -smp_call_function (xen_vcpu_notify_restore, - (void *)CLOCK_EVT_NOTIFY_RESUME ,1 ); +on_each_cpu (xen_vcpu_notify_restore, + (void *)CLOCK_EVT_NOTIFY_RESUME ,1 ); }
PATCH 129/200 xen: avoid allocation causing potential swap activity on the resume path
In reply to Greg KH2.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 4096char *printf_buffer; - printf_buffer =kmalloc (PRINTF_BUFFER_SIZE ,GFP_KERNEL ); + printf_buffer =kmalloc (PRINTF_BUFFER_SIZE ,GFP_NOIO | __GFP_HIGH);if (printf_buffer ==NULL )return -ENOMEM ;
PATCH 130/200 ALSA: hda: Use LPIB for an ASUS device
In reply to Greg KH2.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.
--- 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_fixSND_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),
PATCH 131/200 ALSA: hda: Use mb31 quirk for an iMac model
In reply to Greg KH2.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),
PATCH 132/200 ALSA: hda: Use LPIB for another mainboard
In reply to Greg KH2.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.
--- 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_fixSND_PCI_QUIRK (0x1462 ,0x1002 ,"MSI Wind U115" ,POS_FIX_LPIB ),SND_PCI_QUIRK (0x1565 ,0x820f ,"Biostar Microtech" ,POS_FIX_LPIB ),SND_PCI_QUIRK (0x1565 ,0x8218 ,"Biostar Microtech" ,POS_FIX_LPIB ), +SND_PCI_QUIRK (0x1849 ,0x0888 ,"775Dual-VSTA" ,POS_FIX_LPIB ),SND_PCI_QUIRK (0x8086 ,0x2503 ,"DG965OT AAD63733-203" ,POS_FIX_LPIB ), SND_PCI_QUIRK(0x8086, 0xd601, "eMachines T5212", POS_FIX_LPIB), {}
PATCH 133/200 ALSA: hda: Use LPIB for ASUS M2V
In reply to Greg KH2.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.
--- 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_fixSND_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),
PATCH 134/200 vmware balloon: clamp number of collected non-balloonable pages
In reply to Greg KH2.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 ; }/*
PATCH 135/200 Staging: comedi - correct parameter gainlkup for DAQCard-6024E in driver ni_mio_cs.c
In reply to Greg KH2.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,
PATCH 136/200 clocksource: sh_tmu: compute mult and shift before registration
In reply to Greg KH2.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(sstatic 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 ;
PATCH 137/200 clocksource: sh_cmt: compute mult and shift before registration
In reply to Greg KH2.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(sstatic int sh_cmt_clocksource_enable (struct clocksource *cs) {struct sh_cmt_priv *p =cs_to_sh_cmt (cs); -int ret; p->total_cycles =0 ; - ret =sh_cmt_start (p,FLAG_CLOCKSOURCE ); -if (ret) -return ret; - -/* TODO: calculate good shift from rate and counter bit width */ - cs->shift =0 ; - cs->mult =clocksource_hz2mult (p->rate, cs->shift); -return 0 ; +return sh_cmt_start (p,FLAG_CLOCKSOURCE ); }static void sh_cmt_clocksource_disable (struct clocksource *cs)
@@ -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 ; }
PATCH 138/200 gconfig: fix build failure on fedora 13
In reply to Greg KH2.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
PATCH 139/200 arch/x86/kernel: Add missing spin_unlock
In reply to Greg KH2.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 devicespin_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 deviceatomic_inc (&dev_data->bind); + ret =0 ; + +out_unlock: +/* ready */ spin_unlock (&domain->lock); -return 0 ; +return ret; }/*
PATCH 140/200 pcmcia: only keep saved I365_CSCINT flag if there is no PCI irq
In reply to Greg KH2.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 );
PATCH 141/200 pcmcia: avoid validate_cis failure on CIS override
In reply to Greg KH2.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 pcmciaif (old_funcs != new_funcs) {/* we need to re-start */ pcmcia_card_remove (s,NULL ); + s->functions =0 ;pcmcia_card_add (s); } }
PATCH 142/200 mac80211: fix deauth before assoc
In reply to Greg KH2.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_mgmtmutex_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); }
PATCH 143/200 ath5k: retain promiscuous setting
In reply to Greg KH2.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(strucif (changed_flags & (FIF_PROMISC_IN_BSS |FIF_OTHER_BSS )) {if (*new_flags &FIF_PROMISC_IN_BSS ) { - rfilt |=AR5K_RX_FILTER_PROM ;__set_bit (ATH_STAT_PROMISC , sc->status); }else {__clear_bit (ATH_STAT_PROMISC , sc->status); } } +if (test_bit (ATH_STAT_PROMISC , sc->status)) + rfilt |=AR5K_RX_FILTER_PROM ; +/* Note, AR5K_RX_FILTER_MCAST is already enabled */ if (*new_flags &FIF_ALLMULTI ) { mfilt[0 ] = ~0 ;
PATCH 144/200 ahci: add pci quirk for JMB362
In reply to Greg KH2.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
PATCH 145/200 firewire: core: check for 1394a compliant IRM, fix inaccessibility of Sony camcorder
In reply to Greg KH2.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_cardstatic void fw_card_bm_work (struct work_struct *work) { struct fw_card *card = container_of(work, struct fw_card, work.work); -struct fw_device *root_device; +struct fw_device *root_device, *irm_device;struct fw_node *root_node;unsigned long flags;int root_id, new_root_id, irm_id, local_id;
@@ -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) {
PATCH 146/200 misc: Fix allocation borrowed by vhost_net
In reply to Greg KH2.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.
--- 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 255struct device ;
PATCH 147/200 cgroups: alloc_css_id() increments hierarchy depth
In reply to Greg KH2.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))
PATCH 148/200 perf_events: Fix resource leak in x86 __hw_perf_event_init()
In reply to Greg KH2.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 pif (atomic_read (&active_events) ==0 ) {if (!reserve_pmc_hardware ()) err = -EBUSY ; -else +else { err =reserve_bts_hardware (); +if (err) +release_pmc_hardware (); + } }if (!err)atomic_inc (&active_events);
PATCH 149/200 sata_nv: dont diddle with nIEN on mcp55
In reply to Greg KH2.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)
PATCH 150/200 sata_via: magic vt6421 fix for transmission problems w/ WD drives
In reply to Greg KH2.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)
PATCH 151/200 drm/i915: Rebind bo if currently bound with incorrect alignment.
In reply to Greg KH2.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_objecint ret;i915_verify_inactive (dev, __FILE__, __LINE__); + +if (obj_priv->gtt_space !=NULL ) { +if (alignment ==0 ) + alignment =i915_gem_get_gtt_alignment (obj); +if (obj_priv->gtt_offset & (alignment -1 )) { + ret =i915_gem_object_unbind (obj); +if (ret) +return ret; + } + } +if (obj_priv->gtt_space ==NULL ) { ret =i915_gem_object_bind_to_gtt (obj, alignment);if (ret)
PATCH 152/200 drm/i915: Kill dangerous pending-flip debugging
In reply to Greg KH2.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_dspin_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 ; }
PATCH 153/200 USB: mos7840: fix null-pointer dereference
In reply to Greg KH2.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 ; }
PATCH 154/200 USB: xhci: Wait for host to start running.
In reply to Greg KH2.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);
PATCH 155/200 USB: xhci: Wait for controller to be ready after reset.
In reply to Greg KH2.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 ); }
PATCH 156/200 USB: ftdi_sio: fix DTR/RTS line modes
In reply to Greg KH2.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 ; }
PATCH 157/200 USB: cdc-acm: fix resource reclaim in error path of acm_probe
In reply to Greg KH2.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);
PATCH 158/200 USB: unbind all interfaces before rebinding them
In reply to Greg KH2.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_mepm_runtime_set_active (dev);pm_runtime_enable (dev); udev->last_busy = jiffies; +do_unbind_rebind (udev,DO_REBIND ); } }
PATCH 159/200 p54usb: Add device ID for Dell WLA3310 USB
In reply to Greg KH2.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 */ {}
PATCH 160/200 wrong type for magic argument in simple_fill_super()
In reply to Greg KH2.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 simpextern const struct inode_operations simple_dir_inode_operations;struct tree_descr {char *name;const struct file_operations *ops;int mode; };struct dentry *d_alloc_name (struct dentry *,const char *); -extern int simple_fill_super (struct super_block *,int ,struct tree_descr *); +extern int simple_fill_super (struct super_block *,unsigned long ,struct tree_descr *);extern int simple_pin_fs (struct file_system_type *,struct vfsmount **mount,int *count);extern void simple_release_fs (struct vfsmount **mount,int *count);
PATCH 161/200 cfq-iosched: fix an oops caused by slab leak
In reply to Greg KH2.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_datcfq_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 ; }
PATCH 162/200 iwlwifi: fix internal scan race
In reply to Greg KH2.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(smutex_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 ;
PATCH 163/200 iwlwifi: recalculate average tpt if not current
In reply to Greg KH2.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 &&
PATCH 164/200 perf: Fix signed comparison in perf_adjust_period()
In reply to Greg KH2.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);
PATCH 165/200 tracing: Fix null pointer deref with SEND_SIG_FORCED
In reply to Greg KH2.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.
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) { \
PATCH 166/200 nfsd: nfsd_setattr needs to call commit_metadata
In reply to Greg KH2.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, strif (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;
PATCH 167/200 wl1251: fix a memory leak in probe
In reply to Greg KH2.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; }
PATCH 168/200 iwlwifi: add missing rcu_read_lock
In reply to Greg KH2.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_pristruct 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); }
PATCH 169/200 perf_events: Fix races and clean up perf_event and perf_mmap_data interaction
In reply to Greg KH2.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
PATCH 170/200 ext4: check s_log_groups_per_flex in online resize code
In reply to Greg KH2.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 *spercpu_counter_add (&sbi->s_freeinodes_counter,EXT4_INODES_PER_GROUP (sb)); -if (EXT4_HAS_INCOMPAT_FEATURE (sb,EXT4_FEATURE_INCOMPAT_FLEX_BG )) { +if (EXT4_HAS_INCOMPAT_FEATURE (sb,EXT4_FEATURE_INCOMPAT_FLEX_BG ) && + sbi->s_log_groups_per_flex) {ext4_group_t flex_group; flex_group =ext4_flex_group (sbi, input->group); atomic_add(input->free_blocks_count,
PATCH 171/200 ext4: Make sure the MOVE_EXT ioctl cant overwrite append-only files
In reply to Greg KH2.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 "
PATCH 172/200 GFS2: Fix permissions checking for setflags ioctl()
In reply to Greg KH2.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 fileif (error) goto out_drop_write; + error = -EACCES ; +if (!is_owner_or_cap (inode)) + goto out; + + error =0 ; flags = ip->i_diskflags; new_flags = (flags & ~mask) | (reqflags & mask);if ((new_flags ^ flags) ==0 )
@@ -275,8 +280,10 @@ static int gfs2_set_flags(struct file *f {struct inode *inode = filp->f_path.dentry->d_inode;u32 fsflags, gfsflags; +if (get_user (fsflags, ptr))return -EFAULT ; + gfsflags =fsflags_cvt (fsflags_to_gfs2, fsflags);if (!S_ISDIR (inode->i_mode)) {if (gfsflags &GFS2_DIF_INHERIT_JDATA )
PATCH 173/200 CIFS: Allow null nd (as nfs server uses) on create
In reply to Greg KH2.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, strcifs_fattr_to_inode (*pinode, &fattr); } -cifs_new_fileinfo (*pinode, *pnetfid,NULL , mnt, oflags); +if (mnt) +cifs_new_fileinfo (*pinode, *pnetfid,NULL , mnt, oflags); posix_open_ret:kfree (presp_data);
@@ -315,13 +317,14 @@ cifs_create(struct inode *inode, structif (nd && (nd->flags &LOOKUP_OPEN )) oflags = nd->intent.open.flags;else - oflags =FMODE_READ ; + oflags =FMODE_READ |SMB_O_CREAT ;if (tcon->unix_ext && (tcon->ses->capabilities &CAP_UNIX ) && (CIFS_UNIX_POSIX_PATH_OPS_CAP &le64_to_cpu (tcon->fsUnixInfo.Capability))) { - rc =cifs_posix_open (full_path, &newinode, nd->path.mnt, - mode, oflags, &oplock, &fileHandle, xid); + rc =cifs_posix_open (full_path, &newinode, + nd ? nd->path.mnt :NULL , + inode->i_sb, mode, oflags, &oplock, &fileHandle, xid);/* EIO could indicate that (posix open) operation is not supported, despite what server claimed in capability negotation. EREMOTE indicates DFS junction, which is not
@@ -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;
PATCH 174/200 Btrfs: should add a permission check for setfacl
In reply to Greg KH2.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 deint 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 ) {
PATCH 175/200 NFS: Ensure that we mark the inode as dirty if we exit early from commit
In reply to Greg KH2.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 inodeint 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 inodewait_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; }
PATCH 176/200 NFS: Fix another nfs_wb_page() deadlock
In reply to Greg KH2.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; }
PATCH 177/200 V4L/DVB: uvcvideo: Prevent division by 0 when control step value is 0
In reply to Greg KH2.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);
PATCH 178/200 KVM: SVM: Dont use kmap_atomic in nested_svm_map
In reply to Greg KH2.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(structreturn 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 vcpustruct 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 vcpustatic 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 vcpustruct 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(structstatic 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 vcstatic 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 ; }
PATCH 179/200 KVM: SVM: Fix schedule-while-atomic on nested exception handling
In reply to Greg KH2.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_vcpstatic 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; }
PATCH 180/200 KVM: SVM: Sync all control registers on nested vmexit
In reply to Greg KH2.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;
PATCH 181/200 KVM: SVM: Fix nested msr intercept handling
In reply to Greg KH2.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; }
PATCH 182/200 KVM: SVM: Dont sync nested cr8 to lapic and back
In reply to Greg KH2.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 vcpuelse 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(strstruct 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 ;
PATCH 183/200 KVM: SVM: Fix wrong interrupt injection in enable_irq_windows
In reply to Greg KH2.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(streturn vmexit; } -static inline int nested_svm_intr (struct vcpu_svm *svm) +/* This function returns true if it is save to enable the irq window */ +static inline bool nested_svm_intr (struct vcpu_svm *svm) {if (!is_nested (svm)) -return 0 ; +return true;if (!(svm->vcpu.arch.hflags &HF_VINTR_MASK )) -return 0 ; +return true;if (!(svm->vcpu.arch.hflags &HF_HIF_MASK )) -return 0 ; +return false; svm->vmcb->control.exit_code =SVM_EXIT_INTR ;
@@ -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 ); }
PATCH 184/200 KVM: s390: Fix possible memory leak of in kvm_arch_vcpu_create()
In reply to Greg KH2.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:
PATCH 185/200 KVM: PPC: Do not create debugfs if fail to create vcpu
In reply to Greg KH2.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; }
PATCH 186/200 KVM: x86: Add callback to let modules decide over some supported cpuid bits
In reply to Greg KH2.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 (); }
PATCH 187/200 KVM: SVM: Report emulated SVM features to userspace
In reply to Greg KH2.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[] = {
PATCH 188/200 x86, paravirt: Add a global synchronization point for pvclock
In reply to Greg KH2.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 pvcreturn pv_tsc_khz; } +static atomic64_t last_value =ATOMIC64_INIT (0 ); +cycle_t pvclock_clocksource_read (struct pvclock_vcpu_time_info *src) {struct pvclock_shadow_time shadow;unsigned version;cycle_t ret, offset; +u64 last; do { version = pvclock_get_time_values(&shadow, src);
@@ -123,6 +126,27 @@ cycle_t pvclock_clocksource_read(structbarrier (); }while (version != src->version); +/* +* Assumption here is that last_value, a global accumulator, always goes +* forward. If we are less than that, we should not be much smaller. +* We assume there is an error marging we're inside, and then the correction +* does not sacrifice accuracy. +* +* For reads: global may have changed between test and return, +* but this means someone else updated poked the clock at a later time. +* We just need to make sure we are not seeing a backwards event. +* +* For updates: last_value = ret is not enough, since two vcpus could be +* updating at the same time, and one of them could be slightly behind, +* making the assumption that last_value always go forward fail to hold. +*/ + last =atomic64_read (&last_value); +do { +if (ret < last) +return last; + last =atomic64_cmpxchg (&last_value, last, ret); + }while (unlikely (last != ret)); +return ret; }
PATCH 189/200 KVM: Dont allow lmsw to clear cr0.pe
In reply to Greg KH2.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);
PATCH 190/200 KVM: x86: Check LMA bit before set_efer
In reply to Greg KH2.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;
PATCH 191/200 KVM: MMU: Segregate shadow pages with different cr0.wp
In reply to Greg KH2.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; }
PATCH 192/200 KVM: VMX: enable VMXON check with SMX enabled (Intel TXT)
In reply to Greg KH2.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(vu64 msr;rdmsrl (MSR_IA32_FEATURE_CONTROL , msr); -return (msr & (FEATURE_CONTROL_LOCKED | -FEATURE_CONTROL_VMXON_ENABLED )) - ==FEATURE_CONTROL_LOCKED ; +if (msr &FEATURE_CONTROL_LOCKED ) { +if (!(msr &FEATURE_CONTROL_VMXON_ENABLED_INSIDE_SMX ) + &&tboot_enabled ()) +return 1 ; +if (!(msr &FEATURE_CONTROL_VMXON_ENABLED_OUTSIDE_SMX ) + && !tboot_enabled ()) +return 1 ; + } + +return 0 ;/* locked but not enabled */ }
@@ -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 */ asmvolatile (ASM_VMX_VMXON_RAX : : "a"(&phys_addr), "m"(phys_addr)
include/linux/tboot.h +1 -0
@@ -150,6 +150,7 @@ extern int tboot_force_iommu(void);#else +#define tboot_enabled () 0#define tboot_probe () do { } while (0)#define tboot_shutdown (shutdown_type) do { } while (0)#define tboot_sleep (sleep_state, pm1a_control, pm1b_control) \
PATCH 193/200 KVM: MMU: Dont read pdptrs with mmu spinlock held in mmu_alloc_roots
In reply to Greg KH2.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)
PATCH 194/200 KVM: Fix wallclock version writing race
In reply to Greg KH2.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 *vstatic void kvm_write_wall_clock (struct kvm *kvm,gpa_t wall_clock) { -static int version; +int version; +int r;struct pvclock_wall_clock wc;struct timespec boot;if (!wall_clock)return ; - version++; + r =kvm_read_guest (kvm, wall_clock, &version,sizeof (version)); +if (r) +return ; + +if (version &1 ) + ++version;/* first time write, random junk */ + + ++version;kvm_write_guest (kvm, wall_clock, &version,sizeof (version));
PATCH 195/200 KVM: PPC: Add missing vcpu_load()/vcpu_put() in vcpu ioctls
In reply to Greg KH2.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(structstruct kvmppc_vcpu_book3s *vcpu3s =to_book3s (vcpu);int i; +vcpu_load (vcpu); + sregs->pvr = vcpu->arch.pvr; sregs->u.s.sdr1 =to_book3s (vcpu)->sdr1;
@@ -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(structstruct kvmppc_vcpu_book3s *vcpu3s =to_book3s (vcpu);int i; +vcpu_load (vcpu); +kvmppc_set_pvr (vcpu, sregs->pvr); vcpu3s->sdr1 = sregs->u.s.sdr1;
@@ -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(structfor (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(structfor (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 kint kvm_arch_vcpu_ioctl_translate (struct kvm_vcpu *vcpu,struct kvm_translation *tr) { -return kvmppc_core_vcpu_translate (vcpu, tr); +int r; + +vcpu_load (vcpu); + r =kvmppc_core_vcpu_translate (vcpu, tr); +vcpu_put (vcpu); +return r; }int kvm_vm_ioctl_get_dirty_log (struct kvm *kvm,struct kvm_dirty_log *log)
PATCH 196/200 KVM: x86: Add missing locking to arch specific vcpu ioctls
In reply to Greg KH2.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 : {
PATCH 197/200 KVM: x86: Inject #GP with the right rip on efer writes
In reply to Greg KH2.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 ) {
PATCH 198/200 KVM: SVM: Dont allow nested guest to VMMCALL into host
In reply to Greg KH2.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 |=
PATCH 199/200 drm/i915: Dont touch PORT_HOTPLUG_EN in intel_dp_detect()
In reply to Greg KH2.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 *coif (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 ;
PATCH 200/200 parisc: clear floating point exception flag on SIGFPE signal
In reply to Greg KH2.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);
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
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.htmlCan 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
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 ***
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.htmlCan 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
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.htmlCan 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 ***
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