commit cb4115ad44ce05fa8d2eee30857dc10d3a854507 Author: Greg Kroah-Hartman Date: Sat Oct 13 05:50:59 2012 +0900 Linux 3.6.2 commit 049917d4843acf4b024f1721d83fbe2875cdd937 Author: Frediano Ziglio Date: Tue Aug 7 04:33:03 2012 -0500 Convert properly UTF-8 to UTF-16 commit fd3ba42c76d3d4b776120c2b24c1791e7bb3deb1 upstream. wchar_t is currently 16bit so converting a utf8 encoded characters not in plane 0 (>= 0x10000) to wchar_t (that is calling char2uni) lead to a -EINVAL return. This patch detect utf8 in cifs_strtoUTF16 and add special code calling utf8s_to_utf16s. Signed-off-by: Frediano Ziglio Acked-by: Jeff Layton Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit b034312000118d88ddb6027c262bf898440448ae Author: Jeff Layton Date: Wed Oct 3 16:02:36 2012 -0400 cifs: reinstate the forcegid option commit 72bd481f860f0125c810bb43d878ce5f9c060c58 upstream. Apparently this was lost when we converted to the standard option parser in 8830d7e07a5e38bc47650a7554b7c1cfd49902bf Reported-by: Gregory Lee Bartholomew Cc: Sachin Prabhu Signed-off-by: Jeff Layton Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 4f0f3fedbb68f71b9b3048d1b59b37aad41ad6a1 Author: Brian Norris Date: Fri Aug 31 15:01:19 2012 -0700 JFFS2: don't fail on bitflips in OOB commit 74d83beaa229aac7d126ac1ed9414658ff1a89d2 upstream. JFFS2 was designed without thought for OOB bitflips, it seems, but they can occur and will be reported to JFFS2 via mtd_read_oob()[1]. We don't want to fail on these transactions, since the data was corrected. [1] Few drivers report bitflips for OOB-only transactions. With such drivers, this patch should have no effect. Signed-off-by: Brian Norris Signed-off-by: Artem Bityutskiy Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman commit f6140a8820b12af81b7d346d0c75e4523d5338eb Author: Artem Bityutskiy Date: Thu Aug 23 10:10:07 2012 +0300 JFFS2: fix unmount regression commit a445f784ae5558a3da680aa6b39ed53c95a551c1 upstream. This patch fixes regression introduced by "8bdc81c jffs2: get rid of jffs2_sync_super". We submit a delayed work in order to make sure the write-buffer is synchronized at some point. But we do not flush it when we unmount, which causes an oops when we unmount the file-system and then the delayed work is executed. This patch fixes the issue by adding a "cancel_delayed_work_sync()" infocation in the '->sync_fs()' handler. This will make sure the delayed work is canceled on sync, unmount and re-mount. And because VFS always callse 'sync_fs()' before unmounting or remounting, this fixes the issue. Reported-by: Ludovic Desroches Signed-off-by: Artem Bityutskiy Tested-by: Ludovic Desroches Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman commit 8c63c3bf3e32a13c22edff2a9cc7310a46092e70 Author: Guennadi Liakhovetski Date: Tue Sep 18 06:42:42 2012 +0000 mmc: sh-mmcif: avoid oops on spurious interrupts commit 8464dd52d3198dd05cafb005371d76e5339eb842 upstream. On some systems, e.g., kzm9g, MMCIF interfaces can produce spurious interrupts without any active request. To prevent the Oops, that results in such cases, don't dereference the mmc request pointer until we make sure, that we are indeed processing such a request. Reported-by: Tetsuyuki Kobayashi Signed-off-by: Guennadi Liakhovetski Signed-off-by: Chris Ball Signed-off-by: Greg Kroah-Hartman commit 25356be596603e72329799728cbe494652ccdaab Author: Chris Ball Date: Sun Sep 9 22:56:48 2012 -0400 mmc: slot-gpio: Fix missing assignment to ctx->ro_gpio commit 15e8a8e42966162c207bb97ed55c803bc437eeae upstream. mmc_gpio_request_ro() doesn't store the requested gpio in ctx->ro_gpio. As a result, subsequent calls to mmc_gpio_get_ro() will always fail with -ENOSYS because the gpio number isn't available to that function. Acked-by: Guennadi Liakhovetski Signed-off-by: Chris Ball Signed-off-by: Greg Kroah-Hartman commit 07c0544659b0d75a7b649b37ab5641fa0a3eec2c Author: Vaibhav Bedia Date: Thu Sep 13 06:31:03 2012 +0000 mmc: omap_hsmmc: Pass on the suspend failure to the PM core commit c4c8eeb4df00aabb641553d6fbcd46f458e56cd9 upstream. In some cases mmc_suspend_host() is not able to claim the host and proceed with the suspend process. The core returns -EBUSY to the host controller driver. Unfortunately, the host controller driver does not pass on this information to the PM core and hence the system suspend process continues. ret = mmc_suspend_host(host->mmc); if (ret) { host->suspended = 0; if (host->pdata->resume) { ret = host->pdata->resume(dev, host->slot_id); The return status from mmc_suspend_host() is overwritten by return status from host->pdata->resume. So the original return status is lost. In these cases the MMC core gets to an unexpected state during resume and multiple issues related to MMC crop up. 1. Host controller driver starts accessing the device registers before the clocks are enabled which leads to a prefetch abort. 2. A file copy thread which was launched before suspend gets stuck due to the host not being reclaimed during resume. To avoid such problems pass on the -EBUSY status to the PM core from the host controller driver. With this change, MMC core suspend might still fail but it does not end up making the system unusable. Suspend gets aborted and the user can try suspending the system again. Signed-off-by: Vaibhav Bedia Signed-off-by: Hebbar, Gururaja Acked-by: Venkatraman S Signed-off-by: Chris Ball Signed-off-by: Greg Kroah-Hartman commit ccf5af221ef1f5d59f10f74ae1f08f9b289d0e6e Author: Andreas Bießmann Date: Fri Aug 31 13:35:42 2012 +0200 mtd: omap2: fix module loading commit 4d3d688da8e7016f15483e9319b41311e1db9515 upstream. Unloading the omap2 nand driver missed to release the memory region which will result in not being able to request it again if one want to load the driver later on. This patch fixes following error when loading omap2 module after unloading: ---8<--- ~ $ rmmod omap2 ~ $ modprobe omap2 [ 37.420928] omap2-nand: probe of omap2-nand.0 failed with error -16 ~ $ --->8--- This error was introduced in 67ce04bf2746f8a1f8c2a104b313d20c63f68378 which was the first commit of this driver. Signed-off-by: Andreas Bießmann Signed-off-by: Artem Bityutskiy Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman commit ee9be6a8ac6ca6b37f228cde4ee2b56b1090dd0b Author: Andreas Bießmann Date: Fri Aug 31 13:35:41 2012 +0200 mtd: omap2: fix omap_nand_remove segfault commit 7d9b110269253b1d5858cfa57d68dfc7bf50dd77 upstream. Do not kfree() the mtd_info; it is handled in the mtd subsystem and already freed by nand_release(). Instead kfree() the struct omap_nand_info allocated in omap_nand_probe which was not freed before. This patch fixes following error when unloading the omap2 module: ---8<--- ~ $ rmmod omap2 ------------[ cut here ]------------ kernel BUG at mm/slab.c:3126! Internal error: Oops - BUG: 0 [#1] PREEMPT ARM Modules linked in: omap2(-) CPU: 0 Not tainted (3.6.0-rc3-00230-g155e36d-dirty #3) PC is at cache_free_debugcheck+0x2d4/0x36c LR is at kfree+0xc8/0x2ac pc : [] lr : [] psr: 200d0193 sp : c521fe08 ip : c0e8ef90 fp : c521fe5c r10: bf0001fc r9 : c521e000 r8 : c0d99c8c r7 : c661ebc0 r6 : c065d5a4 r5 : c65c4060 r4 : c78005c0 r3 : 00000000 r2 : 00001000 r1 : c65c4000 r0 : 00000001 Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c5387d Table: 86694019 DAC: 00000015 Process rmmod (pid: 549, stack limit = 0xc521e2f0) Stack: (0xc521fe08 to 0xc5220000) fe00: c008a874 c00bf44c c515c6d0 200d0193 c65c4860 c515c240 fe20: c521fe3c c521fe30 c008a9c0 c008a854 c521fe5c c65c4860 c78005c0 bf0001fc fe40: c780ff40 a00d0113 c521e000 00000000 c521fe84 c521fe60 c0112efc c01122d8 fe60: c65c4860 c0673778 c06737ac 00000000 00070013 00000000 c521fe9c c521fe88 fe80: bf0001fc c0112e40 c0673778 bf001ca8 c521feac c521fea0 c02ca11c bf0001ac fea0: c521fec4 c521feb0 c02c82c4 c02ca100 c0673778 bf001ca8 c521fee4 c521fec8 fec0: c02c8dd8 c02c8250 00000000 bf001ca8 bf001ca8 c0804ee0 c521ff04 c521fee8 fee0: c02c804c c02c8d20 bf001924 00000000 bf001ca8 c521e000 c521ff1c c521ff08 ff00: c02c950c c02c7fbc bf001d48 00000000 c521ff2c c521ff20 c02ca3a4 c02c94b8 ff20: c521ff3c c521ff30 bf001938 c02ca394 c521ffa4 c521ff40 c009beb4 bf001930 ff40: c521ff6c 70616d6f b6fe0032 c0014f84 70616d6f b6fe0032 00000081 60070010 ff60: c521ff84 c521ff70 c008e1f4 c00bf328 0001a004 70616d6f c521ff94 0021ff88 ff80: c008e368 0001a004 70616d6f b6fe0032 00000081 c0015028 00000000 c521ffa8 ffa0: c0014dc0 c009bcd0 0001a004 70616d6f bec2ab38 00000880 bec2ab38 00000880 ffc0: 0001a004 70616d6f b6fe0032 00000081 00000319 00000000 b6fe1000 00000000 ffe0: bec2ab30 bec2ab20 00019f00 b6f539c0 60070010 bec2ab38 aaaaaaaa aaaaaaaa Backtrace: [] (cache_free_debugcheck+0x0/0x36c) from [] (kfree+0xc8/0x2ac) [] (kfree+0x0/0x2ac) from [] (omap_nand_remove+0x5c/0x64 [omap2]) [] (omap_nand_remove+0x0/0x64 [omap2]) from [] (platform_drv_remove+0x28/0x2c) r5:bf001ca8 r4:c0673778 [] (platform_drv_remove+0x0/0x2c) from [] (__device_release_driver+0x80/0xdc) [] (__device_release_driver+0x0/0xdc) from [] (driver_detach+0xc4/0xc8) r5:bf001ca8 r4:c0673778 [] (driver_detach+0x0/0xc8) from [] (bus_remove_driver+0x9c/0x104) r6:c0804ee0 r5:bf001ca8 r4:bf001ca8 r3:00000000 [] (bus_remove_driver+0x0/0x104) from [] (driver_unregister+0x60/0x80) r6:c521e000 r5:bf001ca8 r4:00000000 r3:bf001924 [] (driver_unregister+0x0/0x80) from [] (platform_driver_unregister+0x1c/0x20) r5:00000000 r4:bf001d48 [] (platform_driver_unregister+0x0/0x20) from [] (omap_nand_driver_exit+0x14/0x1c [omap2]) [] (omap_nand_driver_exit+0x0/0x1c [omap2]) from [] (sys_delete_module+0x1f0/0x2ec) [] (sys_delete_module+0x0/0x2ec) from [] (ret_fast_syscall+0x0/0x48) r8:c0015028 r7:00000081 r6:b6fe0032 r5:70616d6f r4:0001a004 Code: e1a00005 eb0d9172 e7f001f2 e7f001f2 (e7f001f2) ---[ end trace 6a30b24d8c0cc2ee ]--- Segmentation fault --->8--- This error was introduced in 67ce04bf2746f8a1f8c2a104b313d20c63f68378 which was the first commit of this driver. Signed-off-by: Andreas Bießmann Signed-off-by: Artem Bityutskiy Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman commit 9d674ea4d62df55d4f7f225143d27fa93e500b08 Author: Shmulik Ladkani Date: Sun Jun 10 13:58:12 2012 +0300 mtd: nand: Use the mirror BBT descriptor when reading its version commit 7bb9c75436212813b38700c34df4bbb6eb82debe upstream. The code responsible for reading the version of the mirror bbt was incorrectly using the descriptor of the main bbt. Pass the mirror bbt descriptor to 'scan_read_raw' when reading the version of the mirror bbt. Signed-off-by: Shmulik Ladkani Acked-by: Sebastian Andrzej Siewior Signed-off-by: Artem Bityutskiy Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman commit 4e180af39587eed3d2ec27afd6df8e45e1594495 Author: Richard Genoud Date: Wed Sep 12 14:26:26 2012 +0200 mtd: nandsim: bugfix: fail if overridesize is too big commit bb0a13a13411c4ce24c48c8ff3cdf7b48d237240 upstream. If override size is too big, the module was actually loaded instead of failing, because retval was not set. This lead to memory corruption with the use of the freed structs nandsim and nand_chip. Signed-off-by: Richard Genoud Signed-off-by: Artem Bityutskiy Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman commit d419593c0d5309892b3bcdac4ddac20c5d3f99e5 Author: Alexander Shiyan Date: Wed Aug 15 20:28:05 2012 +0400 mtd: autcpu12-nvram: Fix compile breakage commit d1f55c680e5d021e7066f4461dd678d42af18898 upstream. Update driver autcpu12-nvram.c so it compiles; map_read32/map_write32 no longer exist in the kernel so the driver is totally broken. Additionally, map_info name passed to simple_map_init is incorrect. Signed-off-by: Alexander Shiyan Acked-by: Arnd Bergmann Signed-off-by: Artem Bityutskiy Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman commit d7cced49961655a90d61148ce8fd4aaa8c44cd9f Author: Huang Shijie Date: Sat Aug 18 13:07:41 2012 -0400 mtd: mtdpart: break it as soon as we parse out the partitions commit c51803ddba10d80d9f246066802c6e359cf1d44c upstream. We may cause a memory leak when the @types has more then one parser. Take the `default_mtd_part_types` for example. The default_mtd_part_types has two parsers now: `cmdlinepart` and `ofpart`. Assume the following case: The kernel command line sets the partitions like: #gpmi-nand:20m(boot),20m(kernel),1g(rootfs),-(user) But the devicetree file(such as arch/arm/boot/dts/imx28-evk.dts) also sets the same partitions as the kernel command line does. In the current code, the partitions parsed out by the `ofpart` will overwrite the @pparts which has already set by the `cmdlinepart` parser, and the the partitions parsed out by the `cmdlinepart` is missed. A memory leak occurs. So we should break the code as soon as we parse out the partitions, In actually, this patch makes a priority order between the parsers. If one parser has already parsed out the partitions successfully, it's no need to use another parser anymore. Signed-off-by: Huang Shijie Signed-off-by: Artem Bityutskiy Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman commit 22e22876160b6b19e4aa52d8e562149840945e9b Author: Dylan Reid Date: Fri Sep 28 15:57:01 2012 -0700 ALSA: hda - Fix hang caused by race during suspend. commit d17344b3547669f5b6ee4fda993d03737a141bd6 upstream. There was a race condition when the system suspends while hda_power_work is running in the work queue. If system suspend (snd_hda_suspend) happens after the work queue releases power_lock but before it calls hda_call_codec_suspend, codec_suspend runs with power_on=0, causing the codec to power up for register reads, and hanging when it calls cancel_delayed_work_sync from the running work queue. The call chain from the work queue will look like this: hda_power_work <<- power_on = 1, unlock, then power_on cleard by suspend hda_call_codec_suspend hda_set_power_state snd_hda_codec_read codec_exec_verb snd_hda_power_up snd_hda_power_save __snd_hda_power_up cancel_delayed_work_sync <<-- cancelling executing wq Fix this by waiting for the work queue to finish before starting suspend if suspend is not happening on the work queue. Signed-off-by: Dylan Reid Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 93bfa6e4dade09e6b92a84990f479c3d59a69e14 Author: Quinlan Pfiffer Date: Fri Sep 28 19:58:44 2012 +0000 asix: Adds support for Lenovo 10/100 USB dongle. commit 66dc81ecd71332783c92fb170950d5ddb43da461 upstream. This dongle ships with the X1 Carbon, and has an AX88772B usb to ethernet chip in it. Signed-off-by: Quinlan Pfiffer Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit df953f991735380b44bdc995c6b4c7bef3618b66 Author: Peter Zijlstra Date: Thu Sep 6 00:03:50 2012 +0200 sched: Fix load avg vs. cpu-hotplug commit 08bedae1d0acd8c9baf514fb69fa199d0c8345f6 upstream. Commit f319da0c68 ("sched: Fix load avg vs cpu-hotplug") was an incomplete fix: In particular, the problem is that at the point it calls calc_load_migrate() nr_running := 1 (the stopper thread), so move the call to CPU_DEAD where we're sure that nr_running := 0. Also note that we can call calc_load_migrate() without serialization, we know the state of rq is stable since its cpu is dead, and we modify the global state using appropriate atomic ops. Suggested-by: Paul E. McKenney Signed-off-by: Peter Zijlstra Link: http://lkml.kernel.org/r/1346882630.2600.59.camel@twins Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 303990b92c02c16209f283b5fd8be431efcbb8b7 Author: Mauro Carvalho Chehab Date: Tue Oct 2 16:02:57 2012 -0300 em28xx: regression fix: use DRX-K sync firmware requests on em28xx commit 2425bb3d4016ed95ce83a90b53bd92c7f31091e4 upstream. As em28xx-dvb will always be initialized asynchronously, there's no need anymore for a separate thread to load the DRX-K firmware. Fixes a known regression with kernel 3.6 with tda18271 driver and asynchronous DRX-K firmware load. Antti tested it with the following hardware: Hauppauge WinTV HVR 930C MaxMedia UB425-TC PCTV QuatroStick nano (520e) Tested-by: Antti Palosaari Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit b3ab8b31e8b3c1ff4971bd52d0c8ebde5cfbdb97 Author: Seiji Aguchi Date: Tue Jul 24 13:27:23 2012 +0000 efi: initialize efi.runtime_version to make query_variable_info/update_capsule workable commit d6cf86d8f23253225fe2a763d627ecf7dfee9dae upstream. A value of efi.runtime_version is checked before calling update_capsule()/query_variable_info() as follows. But it isn't initialized anywhere. static efi_status_t virt_efi_query_variable_info(u32 attr, u64 *storage_space, u64 *remaining_space, u64 *max_variable_size) { if (efi.runtime_version < EFI_2_00_SYSTEM_TABLE_REVISION) return EFI_UNSUPPORTED; This patch initializes a value of efi.runtime_version at boot time. Signed-off-by: Seiji Aguchi Acked-by: Matthew Garrett Signed-off-by: Matt Fleming Signed-off-by: Ivan Hu Signed-off-by: Greg Kroah-Hartman commit 470b2dd6130f9fe44a7ac9554931bf217108d9a9 Author: Matthew Garrett Date: Thu Jul 26 18:00:00 2012 -0400 efi: Build EFI stub with EFI-appropriate options commit 9dead5bbb825d7c25c0400e61de83075046322d0 upstream. We can't assume the presence of the red zone while we're still in a boot services environment, so we should build with -fno-red-zone to avoid problems. Change the size of wchar at the same time to make string handling simpler. Signed-off-by: Matthew Garrett Signed-off-by: Matt Fleming Acked-by: Josh Boyer Signed-off-by: Greg Kroah-Hartman commit f66a52d6f1561fb601b0ad4e54ae3363b2af2486 Author: Mel Gorman Date: Mon Oct 8 16:29:20 2012 -0700 mempolicy: fix a memory corruption by refcount imbalance in alloc_pages_vma() commit 00442ad04a5eac08a98255697c510e708f6082e2 upstream. Commit cc9a6c877661 ("cpuset: mm: reduce large amounts of memory barrier related damage v3") introduced a potential memory corruption. shmem_alloc_page() uses a pseudo vma and it has one significant unique combination, vma->vm_ops=NULL and vma->policy->flags & MPOL_F_SHARED. get_vma_policy() does NOT increase a policy ref when vma->vm_ops=NULL and mpol_cond_put() DOES decrease a policy ref when a policy has MPOL_F_SHARED. Therefore, when a cpuset update race occurs, alloc_pages_vma() falls in 'goto retry_cpuset' path, decrements the reference count and frees the policy prematurely. Signed-off-by: KOSAKI Motohiro Signed-off-by: Mel Gorman Reviewed-by: Christoph Lameter Cc: Josh Boyer Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit ee561403e9fb860fc917b1804de1a56eaa3b0796 Author: KOSAKI Motohiro Date: Mon Oct 8 16:29:19 2012 -0700 mempolicy: fix refcount leak in mpol_set_shared_policy() commit 63f74ca21f1fad36d075e063f06dcc6d39fe86b2 upstream. When shared_policy_replace() fails to allocate new->policy is not freed correctly by mpol_set_shared_policy(). The problem is that shared mempolicy code directly call kmem_cache_free() in multiple places where it is easy to make a mistake. This patch creates an sp_free wrapper function and uses it. The bug was introduced pre-git age (IOW, before 2.6.12-rc2). [mgorman@suse.de: Editted changelog] Signed-off-by: KOSAKI Motohiro Signed-off-by: Mel Gorman Reviewed-by: Christoph Lameter Cc: Josh Boyer Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit ea4be282d1ec21cd7515e9b75c37ce77c7227d9d Author: Mel Gorman Date: Mon Oct 8 16:29:17 2012 -0700 mempolicy: fix a race in shared_policy_replace() commit b22d127a39ddd10d93deee3d96e643657ad53a49 upstream. shared_policy_replace() use of sp_alloc() is unsafe. 1) sp_node cannot be dereferenced if sp->lock is not held and 2) another thread can modify sp_node between spin_unlock for allocating a new sp node and next spin_lock. The bug was introduced before 2.6.12-rc2. Kosaki's original patch for this problem was to allocate an sp node and policy within shared_policy_replace and initialise it when the lock is reacquired. I was not keen on this approach because it partially duplicates sp_alloc(). As the paths were sp->lock is taken are not that performance critical this patch converts sp->lock to sp->mutex so it can sleep when calling sp_alloc(). [kosaki.motohiro@jp.fujitsu.com: Original patch] Signed-off-by: Mel Gorman Acked-by: KOSAKI Motohiro Reviewed-by: Christoph Lameter Cc: Josh Boyer Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 3540dbf4f2e5bd61d05d59a2d62a2640af036361 Author: KOSAKI Motohiro Date: Mon Oct 8 16:29:16 2012 -0700 mempolicy: remove mempolicy sharing commit 869833f2c5c6e4dd09a5378cfc665ffb4615e5d2 upstream. Dave Jones' system call fuzz testing tool "trinity" triggered the following bug error with slab debugging enabled ============================================================================= BUG numa_policy (Not tainted): Poison overwritten ----------------------------------------------------------------------------- INFO: 0xffff880146498250-0xffff880146498250. First byte 0x6a instead of 0x6b INFO: Allocated in mpol_new+0xa3/0x140 age=46310 cpu=6 pid=32154 __slab_alloc+0x3d3/0x445 kmem_cache_alloc+0x29d/0x2b0 mpol_new+0xa3/0x140 sys_mbind+0x142/0x620 system_call_fastpath+0x16/0x1b INFO: Freed in __mpol_put+0x27/0x30 age=46268 cpu=6 pid=32154 __slab_free+0x2e/0x1de kmem_cache_free+0x25a/0x260 __mpol_put+0x27/0x30 remove_vma+0x68/0x90 exit_mmap+0x118/0x140 mmput+0x73/0x110 exit_mm+0x108/0x130 do_exit+0x162/0xb90 do_group_exit+0x4f/0xc0 sys_exit_group+0x17/0x20 system_call_fastpath+0x16/0x1b INFO: Slab 0xffffea0005192600 objects=27 used=27 fp=0x (null) flags=0x20000000004080 INFO: Object 0xffff880146498250 @offset=592 fp=0xffff88014649b9d0 The problem is that the structure is being prematurely freed due to a reference count imbalance. In the following case mbind(addr, len) should replace the memory policies of both vma1 and vma2 and thus they will become to share the same mempolicy and the new mempolicy will have the MPOL_F_SHARED flag. +-------------------+-------------------+ | vma1 | vma2(shmem) | +-------------------+-------------------+ | | addr addr+len alloc_pages_vma() uses get_vma_policy() and mpol_cond_put() pair for maintaining the mempolicy reference count. The current rule is that get_vma_policy() only increments refcount for shmem VMA and mpol_conf_put() only decrements refcount if the policy has MPOL_F_SHARED. In above case, vma1 is not shmem vma and vma->policy has MPOL_F_SHARED! The reference count will be decreased even though was not increased whenever alloc_page_vma() is called. This has been broken since commit [52cd3b07: mempolicy: rework mempolicy Reference Counting] in 2008. There is another serious bug with the sharing of memory policies. Currently, mempolicy rebind logic (it is called from cpuset rebinding) ignores a refcount of mempolicy and override it forcibly. Thus, any mempolicy sharing may cause mempolicy corruption. The bug was introduced by commit [68860ec1: cpusets: automatic numa mempolicy rebinding]. Ideally, the shared policy handling would be rewritten to either properly handle COW of the policy structures or at least reference count MPOL_F_SHARED based exclusively on information within the policy. However, this patch takes the easier approach of disabling any policy sharing between VMAs. Each new range allocated with sp_alloc will allocate a new policy, set the reference count to 1 and drop the reference count of the old policy. This increases the memory footprint but is not expected to be a major problem as mbind() is unlikely to be used for fine-grained ranges. It is also inefficient because it means we allocate a new policy even in cases where mbind_range() could use the new_policy passed to it. However, it is more straight-forward and the change should be invisible to the user. [mgorman@suse.de: Edited changelog] Reported-by: Dave Jones , Cc: Christoph Lameter , Reviewed-by: Christoph Lameter Signed-off-by: KOSAKI Motohiro Signed-off-by: Mel Gorman Cc: Josh Boyer Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit bec0566d6d785490172cebd7180f2716c3483ad9 Author: KOSAKI Motohiro Date: Mon Oct 8 16:29:14 2012 -0700 revert "mm: mempolicy: Let vma_merge and vma_split handle vma->vm_policy linkages" commit 8d34694c1abf29df1f3c7317936b7e3e2e308d9b upstream. Commit 05f144a0d5c2 ("mm: mempolicy: Let vma_merge and vma_split handle vma->vm_policy linkages") removed vma->vm_policy updates code but it is the purpose of mbind_range(). Now, mbind_range() is virtually a no-op and while it does not allow memory corruption it is not the right fix. This patch is a revert. [mgorman@suse.de: Edited changelog] Signed-off-by: KOSAKI Motohiro Signed-off-by: Mel Gorman Cc: Christoph Lameter Cc: Josh Boyer Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 46482fa209172c262d3501146cb7c638a5ad359f Author: Paul E. McKenney Date: Sat Sep 22 13:55:30 2012 -0700 rcu: Fix day-one dyntick-idle stall-warning bug commit a10d206ef1a83121ab7430cb196e0376a7145b22 upstream. Each grace period is supposed to have at least one callback waiting for that grace period to complete. However, if CONFIG_NO_HZ=n, an extra callback-free grace period is no big problem -- it will chew up a tiny bit of CPU time, but it will complete normally. In contrast, CONFIG_NO_HZ=y kernels have the potential for all the CPUs to go to sleep indefinitely, in turn indefinitely delaying completion of the callback-free grace period. Given that nothing is waiting on this grace period, this is also not a problem. That is, unless RCU CPU stall warnings are also enabled, as they are in recent kernels. In this case, if a CPU wakes up after at least one minute of inactivity, an RCU CPU stall warning will result. The reason that no one noticed until quite recently is that most systems have enough OS noise that they will never remain absolutely idle for a full minute. But there are some embedded systems with cut-down userspace configurations that consistently get into this situation. All this begs the question of exactly how a callback-free grace period gets started in the first place. This can happen due to the fact that CPUs do not necessarily agree on which grace period is in progress. If a CPU still believes that the grace period that just completed is still ongoing, it will believe that it has callbacks that need to wait for another grace period, never mind the fact that the grace period that they were waiting for just completed. This CPU can therefore erroneously decide to start a new grace period. Note that this can happen in TREE_RCU and TREE_PREEMPT_RCU even on a single-CPU system: Deadlock considerations mean that the CPU that detected the end of the grace period is not necessarily officially informed of this fact for some time. Once this CPU notices that the earlier grace period completed, it will invoke its callbacks. It then won't have any callbacks left. If no other CPU has any callbacks, we now have a callback-free grace period. This commit therefore makes CPUs check more carefully before starting a new grace period. This new check relies on an array of tail pointers into each CPU's list of callbacks. If the CPU is up to date on which grace periods have completed, it checks to see if any callbacks follow the RCU_DONE_TAIL segment, otherwise it checks to see if any callbacks follow the RCU_WAIT_TAIL segment. The reason that this works is that the RCU_WAIT_TAIL segment will be promoted to the RCU_DONE_TAIL segment as soon as the CPU is officially notified that the old grace period has ended. This change is to cpu_needs_another_gp(), which is called in a number of places. The only one that really matters is in rcu_start_gp(), where the root rcu_node structure's ->lock is held, which prevents any other CPU from starting or completing a grace period, so that the comparison that determines whether the CPU is missing the completion of a grace period is stable. Reported-by: Becky Bruce Reported-by: Subodh Nijsure Reported-by: Paul Walmsley Signed-off-by: Paul E. McKenney Signed-off-by: Paul E. McKenney Tested-by: Paul Walmsley # OMAP3730, OMAP4430 Signed-off-by: Greg Kroah-Hartman commit 297981522d6a1db819a9a44ceecf147c04083143 Author: Frederic Weisbecker Date: Wed Aug 22 17:27:34 2012 +0200 score: Add missing RCU idle APIs on idle loop commit 0ee23fda59740767324b4340247ca41a2f498ca6 upstream. In the old times, the whole idle task was considered as an RCU quiescent state. But as RCU became more and more successful overtime, some RCU read side critical section have been added even in the code of some architectures idle tasks, for tracing for example. So nowadays, rcu_idle_enter() and rcu_idle_exit() must be called by the architecture to tell RCU about the part in the idle loop that doesn't make use of rcu read side critical sections, typically the part that puts the CPU in low power mode. This is necessary for RCU to find the quiescent states in idle in order to complete grace periods. Add this missing pair of calls in scores's idle loop. Reported-by: Paul E. McKenney Signed-off-by: Frederic Weisbecker Cc: Chen Liqin Cc: Lennox Wu Signed-off-by: Paul E. McKenney Reviewed-by: Josh Triplett Signed-off-by: Greg Kroah-Hartman commit ac1c02f167ece50c933392e6853f198003ddfd8a Author: Frederic Weisbecker Date: Wed Aug 22 17:27:34 2012 +0200 m32r: Add missing RCU idle APIs on idle loop commit 48ae077cfce72591b8fc80e1dcc87806f86fed7f upstream. In the old times, the whole idle task was considered as an RCU quiescent state. But as RCU became more and more successful overtime, some RCU read side critical section have been added even in the code of some architectures idle tasks, for tracing for example. So nowadays, rcu_idle_enter() and rcu_idle_exit() must be called by the architecture to tell RCU about the part in the idle loop that doesn't make use of rcu read side critical sections, typically the part that puts the CPU in low power mode. This is necessary for RCU to find the quiescent states in idle in order to complete grace periods. Add this missing pair of calls in the m32r's idle loop. Reported-by: Paul E. McKenney Signed-off-by: Frederic Weisbecker Cc: Hirokazu Takata Signed-off-by: Paul E. McKenney Reviewed-by: Josh Triplett Signed-off-by: Greg Kroah-Hartman commit ce47daf34ed6e95e6ae37ed20442e4c739af3edf Author: Frederic Weisbecker Date: Wed Aug 22 17:27:34 2012 +0200 cris: Add missing RCU idle APIs on idle loop commit c633f9e788928e91ad11f44df29b47bbbe9550b0 upstream. In the old times, the whole idle task was considered as an RCU quiescent state. But as RCU became more and more successful overtime, some RCU read side critical section have been added even in the code of some architectures idle tasks, for tracing for example. So nowadays, rcu_idle_enter() and rcu_idle_exit() must be called by the architecture to tell RCU about the part in the idle loop that doesn't make use of rcu read side critical sections, typically the part that puts the CPU in low power mode. This is necessary for RCU to find the quiescent states in idle in order to complete grace periods. Add this missing pair of calls in the Cris's idle loop. Reported-by: Paul E. McKenney Signed-off-by: Frederic Weisbecker Cc: Mikael Starvik Cc: Jesper Nilsson Cc: Cris Signed-off-by: Paul E. McKenney Reviewed-by: Josh Triplett Signed-off-by: Greg Kroah-Hartman commit 2b2e3e59d2482619b8b136a5053cb3842ae8d058 Author: Frederic Weisbecker Date: Wed Aug 22 17:27:34 2012 +0200 alpha: Add missing RCU idle APIs on idle loop commit 4c94cada48f7c660eca582be6032427a5e367117 upstream. In the old times, the whole idle task was considered as an RCU quiescent state. But as RCU became more and more successful overtime, some RCU read side critical section have been added even in the code of some architectures idle tasks, for tracing for example. So nowadays, rcu_idle_enter() and rcu_idle_exit() must be called by the architecture to tell RCU about the part in the idle loop that doesn't make use of rcu read side critical sections, typically the part that puts the CPU in low power mode. This is necessary for RCU to find the quiescent states in idle in order to complete grace periods. Add this missing pair of calls in the Alpha's idle loop. Reported-by: Paul E. McKenney Signed-off-by: Frederic Weisbecker Tested-by: Michael Cree Cc: Richard Henderson Cc: Ivan Kokshaysky Cc: Matt Turner Cc: alpha Cc: Paul E. McKenney Reviewed-by: Josh Triplett Signed-off-by: Greg Kroah-Hartman commit 879d66835e7bec7fd8885febe67f7eea4885b196 Author: Frederic Weisbecker Date: Wed Aug 22 17:27:34 2012 +0200 m68k: Add missing RCU idle APIs on idle loop commit 5b57ba37e82a15f345a6a2eb8c01a2b2d94c5eeb upstream. In the old times, the whole idle task was considered as an RCU quiescent state. But as RCU became more and more successful overtime, some RCU read side critical section have been added even in the code of some architectures idle tasks, for tracing for example. So nowadays, rcu_idle_enter() and rcu_idle_exit() must be called by the architecture to tell RCU about the part in the idle loop that doesn't make use of rcu read side critical sections, typically the part that puts the CPU in low power mode. This is necessary for RCU to find the quiescent states in idle in order to complete grace periods. Add this missing pair of calls in the m68k's idle loop. Reported-by: Paul E. McKenney Signed-off-by: Frederic Weisbecker Acked-by: Geert Uytterhoeven Cc: m68k Signed-off-by: Paul E. McKenney Reviewed-by: Josh Triplett Signed-off-by: Greg Kroah-Hartman commit 0faba81b8678ef19ef509da34ec2a64ee27dfcba Author: Frederic Weisbecker Date: Wed Aug 22 17:27:34 2012 +0200 mn10300: Add missing RCU idle APIs on idle loop commit 5b0753a90b7a98bc613c3767e9263a1a76d4f900 upstream. In the old times, the whole idle task was considered as an RCU quiescent state. But as RCU became more and more successful overtime, some RCU read side critical section have been added even in the code of some architectures idle tasks, for tracing for example. So nowadays, rcu_idle_enter() and rcu_idle_exit() must be called by the architecture to tell RCU about the part in the idle loop that doesn't make use of rcu read side critical sections, typically the part that puts the CPU in low power mode. This is necessary for RCU to find the quiescent states in idle in order to complete grace periods. Add this missing pair of calls in the mn10300's idle loop. Reported-by: Paul E. McKenney Signed-off-by: Frederic Weisbecker Cc: David Howells Cc: Koichi Yasutake Signed-off-by: Paul E. McKenney Acked-by: David Howells Reviewed-by: Josh Triplett Signed-off-by: Greg Kroah-Hartman commit d866531501b32ae2b3e4f69a31ef091774202e7e Author: Frederic Weisbecker Date: Wed Aug 22 17:27:34 2012 +0200 frv: Add missing RCU idle APIs on idle loop commit 41d8fe5bb3cf91ce2716ac8f43e4b40d802a99c8 upstream. In the old times, the whole idle task was considered as an RCU quiescent state. But as RCU became more and more successful overtime, some RCU read side critical section have been added even in the code of some architectures idle tasks, for tracing for example. So nowadays, rcu_idle_enter() and rcu_idle_exit() must be called by the architecture to tell RCU about the part in the idle loop that doesn't make use of rcu read side critical sections, typically the part that puts the CPU in low power mode. This is necessary for RCU to find the quiescent states in idle in order to complete grace periods. Add this missing pair of calls in the Frv's idle loop. Reported-by: Paul E. McKenney Signed-off-by: Frederic Weisbecker Cc: David Howells Acked-by: David Howells Reviewed-by: Josh Triplett Signed-off-by: Greg Kroah-Hartman commit d693bb06f86eb5f94ee9f42d91ce630f88a72445 Author: Frederic Weisbecker Date: Wed Aug 22 17:27:34 2012 +0200 xtensa: Add missing RCU idle APIs on idle loop commit 11ad47a0edbd62bfc0547cfcdf227a911433f207 upstream. In the old times, the whole idle task was considered as an RCU quiescent state. But as RCU became more and more successful overtime, some RCU read side critical section have been added even in the code of some architectures idle tasks, for tracing for example. So nowadays, rcu_idle_enter() and rcu_idle_exit() must be called by the architecture to tell RCU about the part in the idle loop that doesn't make use of rcu read side critical sections, typically the part that puts the CPU in low power mode. This is necessary for RCU to find the quiescent states in idle in order to complete grace periods. Add this missing pair of calls in the xtensa's idle loop. Reported-by: Paul E. McKenney Signed-off-by: Frederic Weisbecker Cc: Chris Zankel Signed-off-by: Paul E. McKenney Reviewed-by: Josh Triplett Signed-off-by: Greg Kroah-Hartman commit 88ea476abc56219b18bf096bdebfefc785b111ba Author: Frederic Weisbecker Date: Wed Aug 22 17:27:34 2012 +0200 parisc: Add missing RCU idle APIs on idle loop commit fbe752188d5589e7fcbb8e79824e560f77dccc92 upstream. In the old times, the whole idle task was considered as an RCU quiescent state. But as RCU became more and more successful overtime, some RCU read side critical section have been added even in the code of some architectures idle tasks, for tracing for example. So nowadays, rcu_idle_enter() and rcu_idle_exit() must be called by the architecture to tell RCU about the part in the idle loop that doesn't make use of rcu read side critical sections, typically the part that puts the CPU in low power mode. This is necessary for RCU to find the quiescent states in idle in order to complete grace periods. Add this missing pair of calls in the parisc's idle loop. Reported-by: Paul E. McKenney Signed-off-by: Frederic Weisbecker Cc: James E.J. Bottomley Cc: Helge Deller Cc: Parisc Signed-off-by: Paul E. McKenney Reviewed-by: Josh Triplett Signed-off-by: Greg Kroah-Hartman commit a9fd381af918001a9920a6ccc85b4775866c215e Author: Frederic Weisbecker Date: Wed Aug 22 17:27:34 2012 +0200 h8300: Add missing RCU idle APIs on idle loop commit b2fe1430d4115c74d007c825cb9dc3317f28bb16 upstream. In the old times, the whole idle task was considered as an RCU quiescent state. But as RCU became more and more successful overtime, some RCU read side critical section have been added even in the code of some architectures idle tasks, for tracing for example. So nowadays, rcu_idle_enter() and rcu_idle_exit() must be called by the architecture to tell RCU about the part in the idle loop that doesn't make use of rcu read side critical sections, typically the part that puts the CPU in low power mode. This is necessary for RCU to find the quiescent states in idle in order to complete grace periods. Add this missing pair of calls in the h8300's idle loop. Reported-by: Paul E. McKenney Signed-off-by: Frederic Weisbecker Cc: Yoshinori Sato Signed-off-by: Paul E. McKenney Reviewed-by: Josh Triplett Signed-off-by: Greg Kroah-Hartman commit eeb8209162b3d61b4e3cddb9935f5c8dfe097fb4 Author: Paul E. McKenney Date: Fri Aug 24 13:22:13 2012 -0700 ia64: Add missing RCU idle APIs on idle loop commit 93482f4ef1093f5961a63359a34612183d6beea0 upstream. Traditionally, the entire idle task served as an RCU quiescent state. But when RCU read side critical sections started appearing within the idle loop, this traditional strategy became untenable. The fix was to create new RCU APIs named rcu_idle_enter() and rcu_idle_exit(), which must be called by each architecture's idle loop so that RCU can tell when it is safe to ignore a given idle CPU. Unfortunately, this fix was never applied to ia64, a shortcoming remedied by this commit. Reported by: Tony Luck Signed-off-by: Paul E. McKenney Signed-off-by: Paul E. McKenney Tested by: Tony Luck Reviewed-by: Josh Triplett Signed-off-by: Greg Kroah-Hartman commit 2a853d7062c3598e2fa68a6614cd953164dcaf3e Author: Ben Widawsky Date: Wed Oct 3 19:34:24 2012 -0700 drm/i915: Fix GT_MODE default value commit f8f2ac9a76b0f80a6763ca316116a7bab8486997 upstream. I can't even find how I figured this might be needed anymore. But sure enough, the value I'm reading back on platforms doesn't match what the docs recommends. It seemed to fix Chris' GT1 in limited testing as well. Tested-by: Chris Wilson Signed-off-by: Ben Widawsky Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 2257e17ea4ff03c9d1d633a4cd1af4e2aa1f410e Author: Daniel Vetter Date: Tue Oct 2 17:54:35 2012 +0200 drm/i915: call drm_handle_vblank before finish_page_flip commit 74d44445afb9f50126eba052adeb89827cee88f3 upstream. ... since finish_page_flip needs the vblank timestamp generated in drm_handle_vblank. Somehow all the gmch platforms get it right, but all the pch platform irq handlers get is wrong. Hooray for copy& pasting! Currently this gets papered over by a gross hack in finish_page_flip. A second patch will remove that. Note that without this, the new timestamp sanity checks in flip_test occasionally get tripped up, hence the cc: stable tag. Reviewed-by: mario.kleiner@tuebingen.mpg.de Tested-by: Imre Deak Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 1a8f00d249b366be878ff40e2b520643a5637960 Author: Chris Wilson Date: Thu Sep 27 21:25:58 2012 +0100 drm/i915: Flush the pending flips on the CRTC before modification commit 5bb61643f6a70d48de9cfe91ad0fee0d618b6816 upstream. This was meant to be the purpose of the intel_crtc_wait_for_pending_flips() function which is called whilst preparing the CRTC for a modeset or before disabling. However, as Ville Syrjala pointed out, we set the pending flip notification on the old framebuffer that is no longer attached to the CRTC by the time we come to flush the pending operations. Instead, we can simply wait on the pending unpin work to be finished on this CRTC, knowning that the hardware has therefore finished modifying the registers, before proceeding with our direct access. Fixes i-g-t/flip_test on non-pch platforms. pch platforms simply schedule the flip immediately when the pipe is disabled, leading to other funny issues. Signed-off-by: Chris Wilson [danvet: Added i-g-t note and cc: stable] Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 57a38d925e665fcd729cd9ad4a75c84e11bd95c9 Author: Ratan Nalumasu Date: Sat Sep 22 11:46:30 2012 -0700 HID: hidraw: don't deallocate memory when it is in use commit 4fe9f8e203fdad1524c04beb390f3c6099781ed9 upstream. When a device is unplugged, wait for all processes that have opened the device to close before deallocating the device. Signed-off-by: Ratan Nalumasu Signed-off-by: Jiri Kosina Cc: Kees Cook Signed-off-by: Greg Kroah-Hartman commit 117262a8c47819ec502722159096b5dc90883a2b Author: Alex Deucher Date: Wed Sep 26 12:40:45 2012 -0400 drm/radeon: force MSIs on RS690 asics commit fb6ca6d154cdcd53e7f27f8dbba513830372699b upstream. There are so many quirks, lets just try and force this for all RS690s. See: https://bugs.freedesktop.org/show_bug.cgi?id=37679 Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit de6e1950e9455a350a174322137e55890ef2cf41 Author: Alex Deucher Date: Wed Sep 26 12:31:45 2012 -0400 drm/radeon: Add MSI quirk for gateway RS690 commit 3a6d59df80897cc87812b6826d70085905bed013 upstream. Fixes another system on: https://bugs.freedesktop.org/show_bug.cgi?id=37679 Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 4b9a37d406a64d169927c12aff51ba72c2b89311 Author: Marek Olšák Date: Tue Sep 25 03:34:01 2012 +0200 drm/radeon: allow MIP_ADDRESS=0 for MSAA textures on Evergreen commit 61051afd3540da71c1ac32f17ed663595a0f7ecb upstream. MIP_ADDRESS should point to the resolved FMASK for an MSAA texture. Setting MIP_ADDRESS to 0 means the FMASK pointer is invalid (the GPU won't read the memory then). The userspace has to set MIP_ADDRESS to 0 and *not* emit any relocation for it. Signed-off-by: Marek Olšák Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit bfe6102b77bd9a3925fa84517e047170befa75c5 Author: Marek Olšák Date: Tue Sep 25 01:45:33 2012 +0200 drm/radeon/kms: allow STRMOUT_BASE_UPDATE on RS780 and RS880 commit 46fc8781bf428ce1094a5980ca2b92a49d33a8ca upstream. This is required to make streamout work there. Signed-off-by: Marek Olšák Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit a364ac95d58cc2f64d596a298708a1429b60d5ac Author: Alex Deucher Date: Fri Sep 14 10:59:26 2012 -0400 drm/radeon: only adjust default clocks on NI GPUs commit 2e3b3b105ab3bb5b6a37198da4f193cd13781d13 upstream. SI asics store voltage information differently so we don't have a way to deal with it properly yet. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 1d43ed629768ed28d3ae3131b5c64b2c5b6fc565 Author: Chris Wilson Date: Mon Sep 17 09:38:03 2012 +0000 drm: Destroy the planes prior to destroying the associated CRTC commit 3184009c36da413724f283e3c7ac9cc60c623bc4 upstream. As during the plane cleanup, we wish to disable the hardware and so may modify state on the associated CRTC, that CRTC must continue to exist until we are finished. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54101 Signed-off-by: Chris Wilson Cc: Jesse Barnes Reviewed-by: Jesse Barnes Tested-by: lu hua Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 87b22644845862f54c657326d1da2484907db3b6 Author: Ben Skeggs Date: Fri Sep 28 11:50:29 2012 +1000 drm/nvc0/fence: restore pre-suspend fence buffer context on resume commit d6ba6d215a538a58f0f0026f0961b0b9125e8042 upstream. Fixes some unfortunate races on resume. The G84 version of the code doesn't need this as "gpuobj"s are automagically suspended/resumed by the core code whereas pinned buffer objects are not. Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit fbd15b54708f20d25e70d40c4035db37fa7c6c2a Author: Pierre-Louis Bossart Date: Fri Sep 21 18:39:06 2012 -0500 ALSA: hda - use LPIB for delay estimation commit 90accc58a6946e7245993da6079f88d8c29cb731 upstream. DMA Position in Buffer (DPIB) should be used for ring buffer management, while LPIB register provides information on the number of samples transfered on the link. The difference between the two pieces of information corresponds to hardware/DMA buffering. This patch reports this difference in runtime->delay, and removes the use of the COMBO mode on recent Intel hardware. Credits to Takashi Iwai for an initial patch. [rebased to for-next branch and replaced snd_printk() with snd_printdd() by tiwai] Signed-off-by: Pierre-Louis Bossart Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 7bf3c0a63f177629f36106050cfc58000f12a235 Author: Wang Xingchao Date: Mon Sep 17 13:10:23 2012 +0800 ALSA: hda - Add another pci id for Haswell board commit d279fae8a41690ec1b20c07be8c6f42f8af27a17 upstream. A new PCI id 0x0d0c for Haswell HDA Controller. [root@SKBM04SDP ~]# lspci |grep Audio 00:03.0 Audio device: Intel Corporation Device 0d0c (rev 02) 00:1b.0 Audio device: Intel Corporation Lynx Point HD Audio Controller Signed-off-by: Wang Xingchao Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 904e56af97e43c45068a4a801eaf03fb04d122df Author: Marko Friedemann Date: Mon Sep 3 10:12:40 2012 +0200 ALSA: USB: Support for (original) Xbox Communicator commit c05fce586d4da2dfe0309bef3795a8586e967bc3 upstream. Added support for Xbox Communicator to USB quirks. Signed-off-by: Marko Friedemann Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 90180feb0afe4be06678d9cd965dd730bd773a7e Author: Daniel Mack Date: Tue Sep 4 10:23:07 2012 +0200 ALSA: snd-usb: Add quirks for Playback Designs devices commit 2b58fd5b3193fd3af3d15114d95706087d25a7fe upstream. Playback Designs' USB devices have some hardware limitations on their USB interface. In particular: - They need a 20ms delay after each class compliant request as the hardware ACKs the USB packets before the device is actually ready for the next command. Sending data immediately will result in buffer overflows in the hardware. - The devices send bogus feedback data at the start of each stream which confuse the feedback format auto-detection. This patch introduces a new quirks hook that is called after each control packet and which adds a delay for all devices that match Playback Designs' USB VID for now. In addition, it adds a counter to snd_usb_endpoint to drop received packets on the floor. Another new quirks function that is called once an endpoint is started initializes that counter for these devices on their sync endpoint. Signed-off-by: Daniel Mack Reported-and-tested-by: Andreas Koch Supported-by: Demian Martin Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 3ebd9559e210f49fe89c6b81177bf05b5ab645e8 Author: David Henningsson Date: Thu Sep 20 10:20:41 2012 +0200 ALSA: usb - disable broken hw volume for Tenx TP6911 commit c10514394ef9e8de93a4ad8c8904d71dcd82c122 upstream. While going through Ubuntu bugs, I discovered this patch being posted and a confirmation that the patch works as expected. Finding out how the hw volume really works would be preferrable to just disabling the broken one, but this would be better than nothing. Credit: sndfnsdfin (qawsnews) BugLink: https://bugs.launchpad.net/bugs/559939 Signed-off-by: David Henningsson Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 23532ac1552087eb99cc06de4a6b49bfc7b447a5 Author: David Henningsson Date: Tue Sep 18 14:26:59 2012 +0200 ALSA: hda - limit internal mic boost for Asus X202E commit 4b527b6516ab1f0af8aaedd02dbf71ee2c1180f4 upstream. When the input gain for the internal mic is set to its maximum level, the background noise becomes so high - and any relevant signal clipped - that the setting becomes unusable. It is better to limit the amplification. BugLink: https://bugs.launchpad.net/bugs/1052460 Signed-off-by: David Henningsson Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit b1b0d462d583585d64dfa3efa1965709c2913011 Author: Herton Ronaldo Krzesinski Date: Thu Sep 27 10:38:14 2012 -0300 ALSA: hda/realtek - Fix detection of ALC271X codec commit 9f720bb9409ea5923361fbd3fdbc505ca36cf012 upstream. In commit af741c1 ("ALSA: hda/realtek - Call alc_auto_parse_customize_define() always after fixup"), alc_auto_parse_customize_define was moved after detection of ALC271X. The problem is that detection of ALC271X relies on spec->cdefine.platform_type, and it's set on alc_auto_parse_customize_define. Move the alc_auto_parse_customize_define and its required fixup setup before the block doing the ALC271X and other codec setup. BugLink: https://bugs.launchpad.net/bugs/1006690 Signed-off-by: Herton Ronaldo Krzesinski Reviewed-by: David Henningsson Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit e2e13279e29569c99fd45414abc827400459d817 Author: Herton Ronaldo Krzesinski Date: Fri Sep 21 20:45:19 2012 -0300 ALSA: hda/via - don't report presence on HPs with no presence support commit cf55e904516947597d75fd3844acc24891a95772 upstream. If headphone jack can't detect plug presence, and we have the jack in the jack table, snd_hda_jack_detect will return the plug as always present (as it'll be considered as a phantom jack). The problem is that when this happens, line out pins will always be disabled, resulting in no sound if there are no headphones connected. This was reported as a no sound problem after suspend on http://bugs.launchpad.net/bugs/1052499, since the bug doesn't manifests on first initialization before the phantom jack is added, but on resume we reexecute the initialization code, and via_hp_automute starts reporting HP always present with the jack now on the table. BugLink: https://bugs.launchpad.net/bugs/1052499 Signed-off-by: Herton Ronaldo Krzesinski Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit b719c952c5d6d24df15f8506f5b440a760b481a0 Author: Omair Mohammed Abdullah Date: Sat Sep 29 12:24:05 2012 +0530 ALSA: aloop - add locking to timer access commit d4f1e48bd11e3df6a26811f7a1f06c4225d92f7d upstream. When the loopback timer handler is running, calling del_timer() (for STOP trigger) will not wait for the handler to complete before deactivating the timer. The timer gets rescheduled in the handler as usual. Then a subsequent START trigger will try to start the timer using add_timer() with a timer pending leading to a kernel panic. Serialize the calls to add_timer() and del_timer() using a spin lock to avoid this. Signed-off-by: Omair Mohammed Abdullah Signed-off-by: Vinod Koul Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit a49679795f592ab764fab31bd94ce533a2e3395d Author: Felix Kaechele Date: Wed Sep 26 01:20:44 2012 +0200 ALSA: hda - Add inverted internal mic quirk for Lenovo IdeaPad U310 commit e4db0952e542090c605fd41d31d761f1b4624f4a upstream. The Lenovo IdeaPad U310 has an internal mic where the right channel is phase inverted. Signed-off-by: Felix Kaechele Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 3e595be0b92b3a9db691013b00847b5d269d92a7 Author: Paulo Zanoni Date: Tue Sep 25 13:23:34 2012 -0300 drm/i915: make sure we write all the DIP data bytes commit adf00b26d18e1b3570451296e03bcb20e4798cdd upstream. ... even if the actual infoframe is smaller than the maximum possible size. If we don't write all the 32 DIP data bytes the InfoFrame ECC may not be correctly calculated in some cases (e.g., when changing the port), and this will lead to black screens on HDMI monitors. The ECC value is generated by the hardware. I don't see how this should break anything since we're writing 0 and that should be the correct value, so this patch should be safe. Notice that on IVB and older we actually have 64 bytes available for VIDEO_DIP_DATA, but only bytes 0-31 actually store infoframe data: the others are either read-only ECC values or marked as "reserved". On HSW we only have 32 bytes, and the ECC value is stored on its own separate read-only register. See BSpec. This patch fixes bug #46761, which is marked as a regression introduced by commit 4e89ee174bb2da341bf90a84321c7008a3c9210d: drm/i915: set the DIP port on ibx_write_infoframe Before commit 4e89 we were just failing to send AVI infoframes when we needed to change the port, which can lead to black screens in some cases. After commit 4e89 we started sending infoframes, but with a possibly wrong ECC value. After this patch I hope we start sending correct infoframes. Version 2: - Improve commit message - Try to make the code more clear Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=46761 Signed-off-by: Paulo Zanoni Reviewed-by: Rodrigo Vivi Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit b80c1b7eabd8a93278c36d4692c6d83e74e4bf3e Author: Eugeni Dodonov Date: Mon Jun 18 19:03:38 2012 -0300 drm/i915: prevent possible pin leak on error path commit ab3951eb74e7c33a2f5b7b64d72e82f1eea61571 upstream. We should not hit this under any sane conditions, but still, this does not looks right. Reported-by: Herton Ronaldo Krzesinski CC: Chris Wilson CC: Daniel Vetter Reviewed-by: Chris Wlison Signed-off-by: Eugeni Dodonov Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit c2bb4485c33a281d9b58e20c811dfe5711ef9f62 Author: Gabor Juhos Date: Sat Sep 1 18:46:00 2012 +0200 MIPS: ath79: use correct fractional dividers for {CPU,DDR}_PLL on AR934x commit 65fc7f9957c52ad4fdf4ee5dfe3a75aa0a633d39 upstream. The current dividers in the code are wrong and this leads to broken CPU frequency calculation on boards where the fractional part is used. For example, if the SoC is running from a 40MHz reference clock, refdiv=1, nint=14, outdiv=0 and nfrac=31 the real frequency is 579.375MHz but the current code calculates 569.687MHz instead. Because the system time is indirectly related to the CPU frequency the broken computation causes drift in the system time. The correct divider is 2^6 for the CPU PLL and 2^10 for the DDR PLL. Use the correct values to fix the issue. Signed-off-by: Gabor Juhos Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/4305/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit a6d26c56e266a7b72dc48833f0429b4e0479f8cd Author: Andrea Arcangeli Date: Mon Oct 8 16:33:27 2012 -0700 mm: thp: fix pmd_present for split_huge_page and PROT_NONE with THP commit 027ef6c87853b0a9df53175063028edb4950d476 upstream. In many places !pmd_present has been converted to pmd_none. For pmds that's equivalent and pmd_none is quicker so using pmd_none is better. However (unless we delete pmd_present) we should provide an accurate pmd_present too. This will avoid the risk of code thinking the pmd is non present because it's under __split_huge_page_map, see the pmd_mknotpresent there and the comment above it. If the page has been mprotected as PROT_NONE, it would also lead to a pmd_present false negative in the same way as the race with split_huge_page. Because the PSE bit stays on at all times (both during split_huge_page and when the _PAGE_PROTNONE bit get set), we could only check for the PSE bit, but checking the PROTNONE bit too is still good to remember pmd_present must always keep PROT_NONE into account. This explains a not reproducible BUG_ON that was seldom reported on the lists. The same issue is in pmd_large, it would go wrong with both PROT_NONE and if it races with split_huge_page. Signed-off-by: Andrea Arcangeli Acked-by: Rik van Riel Cc: Johannes Weiner Cc: Hugh Dickins Cc: Mel Gorman Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 3445cb2e52e98dd2413bdc6bcccab475d3871dc1 Author: Hugh Dickins Date: Mon Oct 8 16:33:14 2012 -0700 mm: fix invalidate_complete_page2() lock ordering commit ec4d9f626d5908b6052c2973f37992f1db52e967 upstream. In fuzzing with trinity, lockdep protested "possible irq lock inversion dependency detected" when isolate_lru_page() reenabled interrupts while still holding the supposedly irq-safe tree_lock: invalidate_inode_pages2 invalidate_complete_page2 spin_lock_irq(&mapping->tree_lock) clear_page_mlock isolate_lru_page spin_unlock_irq(&zone->lru_lock) isolate_lru_page() is correct to enable interrupts unconditionally: invalidate_complete_page2() is incorrect to call clear_page_mlock() while holding tree_lock, which is supposed to nest inside lru_lock. Both truncate_complete_page() and invalidate_complete_page() call clear_page_mlock() before taking tree_lock to remove page from radix_tree. I guess invalidate_complete_page2() preferred to test PageDirty (again) under tree_lock before committing to the munlock; but since the page has already been unmapped, its state is already somewhat inconsistent, and no worse if clear_page_mlock() moved up. Reported-by: Sasha Levin Deciphered-by: Andrew Morton Signed-off-by: Hugh Dickins Acked-by: Mel Gorman Cc: Rik van Riel Cc: Johannes Weiner Cc: Michel Lespinasse Cc: Ying Han Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit f037cf000f6b77ceba478a7467d3f80d1f571ad8 Author: Michal Hocko Date: Mon Oct 8 16:33:31 2012 -0700 hugetlb: do not use vma_hugecache_offset() for vma_prio_tree_foreach commit 36e4f20af833d1ce196e6a4ade05dc26c44652d1 upstream. Commit 0c176d52b0b2 ("mm: hugetlb: fix pgoff computation when unmapping page from vma") fixed pgoff calculation but it has replaced it by vma_hugecache_offset() which is not approapriate for offsets used for vma_prio_tree_foreach() because that one expects index in page units rather than in huge_page_shift. Johannes said: : The resulting index may not be too big, but it can be too small: assume : hpage size of 2M and the address to unmap to be 0x200000. This is regular : page index 512 and hpage index 1. If you have a VMA that maps the file : only starting at the second huge page, that VMAs vm_pgoff will be 512 but : you ask for offset 1 and miss it even though it does map the page of : interest. hugetlb_cow() will try to unmap, miss the vma, and retry the : cow until the allocation succeeds or the skipped vma(s) go away. Signed-off-by: Michal Hocko Acked-by: Hillf Danton Cc: Mel Gorman Cc: KAMEZAWA Hiroyuki Cc: Andrea Arcangeli Cc: David Rientjes Acked-by: Johannes Weiner Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit ac8d33294e016f2003f8bf8caa848ba754a1d08c Author: Naoya Horiguchi Date: Mon Oct 8 16:33:47 2012 -0700 kpageflags: fix wrong KPF_THP on non-huge compound pages commit 7a71932d5676b7410ab64d149bad8bde6b0d8632 upstream. KPF_THP can be set on non-huge compound pages (like slab pages or pages allocated by drivers with __GFP_COMP) because PageTransCompound only checks PG_head and PG_tail. Obviously this is a bug and breaks user space applications which look for thp via /proc/kpageflags. This patch rules out setting KPF_THP wrongly by additionally checking PageLRU on the head pages. Signed-off-by: Naoya Horiguchi Acked-by: KOSAKI Motohiro Acked-by: David Rientjes Reviewed-by: Fengguang Wu Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 7c6e1b2ebc9ed6ec255fa06a1320e21fb0075bf6 Author: Mark Brown Date: Tue Jul 31 18:37:29 2012 +0100 ASoC: wm9712: Fix name of Capture Switch commit 689185b78ba6fbe0042f662a468b5565909dff7a upstream. Help UIs associate it with the matching gain control. Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit b84a59a1b43cce7d8efc3cbcdb4a21ac8b184536 Author: Charles Keepax Date: Thu Sep 27 13:21:48 2012 +0100 ASoC: wm5110: Adding missing volume update bits commit ae60503741991a36ed6b2a8f53b249b2a72af52b upstream. The volume update bits were being set on all but one input and one output. Signed-off-by: Charles Keepax Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit de153756f0f684a1f2dd660c58a873da2e6cfdd3 Author: Mark Brown Date: Thu Sep 27 18:35:24 2012 +0100 ASoC: wm_hubs: Ensure volume updates are handled during class W startup commit eb4d5fc1f0ce89e3d5b072c594a1e213a0e05881 upstream. In some circumstances we may need to flush volume updates to the device after switching to class W mode. Do this unconditionally to ensure that these situations are handled. Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 92b77229ee73413c1ebfe793ed0085eb1ff794f1 Author: Theodore Ts'o Date: Sun Sep 30 23:04:56 2012 -0400 ext4: fix mtime update in nodelalloc mode commit 041bbb6d369811e948ae01f3d00414264076be35 upstream. Commits 5e8830dc85d0 and 41c4d25f78c0 introduced a regression into v3.6-rc1 for ext4 in nodealloc mode, such that mtime updates would not take place for files modified via mmap if the page was already in the page cache. This would also affect ext3 file systems mounted using the ext4 file system driver. The problem was that ext4_page_mkwrite() had a shortcut which would avoid calling __block_page_mkwrite() under some circumstances, and the above two commit transferred the responsibility of calling file_update_time() to __block_page_mkwrite --- which woudln't get called in some circumstances. Since __block_page_mkwrite() only has three callers, block_page_mkwrite(), ext4_page_mkwrite, and nilfs_page_mkwrite(), the best way to solve this is to move the responsibility for calling file_update_time() to its caller. This problem was found via xfstests #215 with a file system mounted with -o nodelalloc. Signed-off-by: "Theodore Ts'o" Reviewed-by: Jan Kara Cc: KONISHI Ryusuke Signed-off-by: Greg Kroah-Hartman commit 34414b2bf58b95110bf8ccef77d66c05de9e923c Author: Jan Kara Date: Wed Sep 26 21:52:20 2012 -0400 ext4: fix fdatasync() for files with only i_size changes commit b71fc079b5d8f42b2a52743c8d2f1d35d655b1c5 upstream. Code tracking when transaction needs to be committed on fdatasync(2) forgets to handle a situation when only inode's i_size is changed. Thus in such situations fdatasync(2) doesn't force transaction with new i_size to disk and that can result in wrong i_size after a crash. Fix the issue by updating inode's i_datasync_tid whenever its size is updated. Reported-by: Kristian Nielsen Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit 12ebdf00d08f21da12c85e1800d5d91beaa4bfbe Author: Bernd Schubert Date: Wed Sep 26 21:24:57 2012 -0400 ext4: always set i_op in ext4_mknod() commit 6a08f447facb4f9e29fcc30fb68060bb5a0d21c2 upstream. ext4_special_inode_operations have their own ifdef CONFIG_EXT4_FS_XATTR to mask those methods. And ext4_iget also always sets it, so there is an inconsistency. Signed-off-by: Bernd Schubert Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit 22a5672604ff3eef101c83436ee15d8e2e148187 Author: Dmitry Monakhov Date: Wed Sep 26 12:32:54 2012 -0400 ext4: online defrag is not supported for journaled files commit f066055a3449f0e5b0ae4f3ceab4445bead47638 upstream. Proper block swap for inodes with full journaling enabled is truly non obvious task. In order to be on a safe side let's explicitly disable it for now. Signed-off-by: Dmitry Monakhov Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit ba57d9ef068e6f55226bfedf0e7cd6adab37a316 Author: Dmitry Monakhov Date: Wed Sep 26 12:32:19 2012 -0400 ext4: move_extent code cleanup commit 03bd8b9b896c8e940f282f540e6b4de90d666b7c upstream. - Remove usless checks, because it is too late to check that inode != NULL at the moment it was referenced several times. - Double lock routines looks very ugly and locking ordering relays on order of i_ino, but other kernel code rely on order of pointers. Let's make them simple and clean. - check that inodes belongs to the same SB as soon as possible. Signed-off-by: Dmitry Monakhov Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit 2fdb1128f404ab026d2794de3bd604500edd444b Author: Herton Ronaldo Krzesinski Date: Sun Sep 23 22:49:12 2012 -0400 ext4: fix crash when accessing /proc/mounts concurrently commit 50df9fd55e4271e89a7adf3b1172083dd0ca199d upstream. The crash was caused by a variable being erronously declared static in token2str(). In addition to /proc/mounts, the problem can also be easily replicated by accessing /proc/fs/ext4//options in parallel: $ cat /proc/fs/ext4//options > options.txt ... and then running the following command in two different terminals: $ while diff /proc/fs/ext4//options options.txt; do true; done This is also the cause of the following a crash while running xfstests #234, as reported in the following bug reports: https://bugs.launchpad.net/bugs/1053019 https://bugzilla.kernel.org/show_bug.cgi?id=47731 Signed-off-by: Herton Ronaldo Krzesinski Signed-off-by: "Theodore Ts'o" Cc: Brad Figg Signed-off-by: Greg Kroah-Hartman commit 1638f1fb5b54c51f09769cb8938798d4122225d4 Author: Theodore Ts'o Date: Wed Sep 19 22:42:36 2012 -0400 ext4: fix potential deadlock in ext4_nonda_switch() commit 00d4e7362ed01987183e9528295de3213031309c upstream. In ext4_nonda_switch(), if the file system is getting full we used to call writeback_inodes_sb_if_idle(). The problem is that we can be holding i_mutex already, and this causes a potential deadlock when writeback_inodes_sb_if_idle() when it tries to take s_umount. (See lockdep output below). As it turns out we don't need need to hold s_umount; the fact that we are in the middle of the write(2) system call will keep the superblock pinned. Unfortunately writeback_inodes_sb() checks to make sure s_umount is taken, and the VFS uses a different mechanism for making sure the file system doesn't get unmounted out from under us. The simplest way of dealing with this is to just simply grab s_umount using a trylock, and skip kicking the writeback flusher thread in the very unlikely case that we can't take a read lock on s_umount without blocking. Also, we now check the cirteria for kicking the writeback thread before we decide to whether to fall back to non-delayed writeback, so if there are any outstanding delayed allocation writes, we try to get them resolved as soon as possible. [ INFO: possible circular locking dependency detected ] 3.6.0-rc1-00042-gce894ca #367 Not tainted ------------------------------------------------------- dd/8298 is trying to acquire lock: (&type->s_umount_key#18){++++..}, at: [] writeback_inodes_sb_if_idle+0x28/0x46 but task is already holding lock: (&sb->s_type->i_mutex_key#8){+.+...}, at: [] generic_file_aio_write+0x5f/0xd3 which lock already depends on the new lock. 2 locks held by dd/8298: #0: (sb_writers#2){.+.+.+}, at: [] generic_file_aio_write+0x56/0xd3 #1: (&sb->s_type->i_mutex_key#8){+.+...}, at: [] generic_file_aio_write+0x5f/0xd3 stack backtrace: Pid: 8298, comm: dd Not tainted 3.6.0-rc1-00042-gce894ca #367 Call Trace: [] ? console_unlock+0x345/0x372 [] print_circular_bug+0x190/0x19d [] __lock_acquire+0x86d/0xb6c [] ? mark_held_locks+0x5c/0x7b [] lock_acquire+0x66/0xb9 [] ? writeback_inodes_sb_if_idle+0x28/0x46 [] down_read+0x28/0x58 [] ? writeback_inodes_sb_if_idle+0x28/0x46 [] writeback_inodes_sb_if_idle+0x28/0x46 [] ext4_nonda_switch+0xe1/0xf4 [] ext4_da_write_begin+0x27/0x193 [] generic_file_buffered_write+0xc8/0x1bb [] __generic_file_aio_write+0x1dd/0x205 [] generic_file_aio_write+0x78/0xd3 [] ext4_file_write+0x480/0x4a6 [] ? __lock_acquire+0x41e/0xb6c [] ? sched_clock_cpu+0x11a/0x13e [] ? trace_hardirqs_off+0xb/0xd [] ? local_clock+0x37/0x4e [] do_sync_write+0x67/0x9d [] ? wait_on_retry_sync_kiocb+0x44/0x44 [] vfs_write+0x7b/0xe6 [] sys_write+0x3b/0x64 [] syscall_call+0x7/0xb Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit 5018ddd6809e3ca755087da51c9808f9535d46f0 Author: Yongqiang Yang Date: Wed Sep 5 01:27:50 2012 -0400 ext4: avoid duplicate writes of the backup bg descriptor blocks commit 2ebd1704ded88a8ae29b5f3998b13959c715c4be upstream. The resize code was needlessly writing the backup block group descriptor blocks multiple times (once per block group) during an online resize. Signed-off-by: Yongqiang Yang Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit 256ae46c73e0e989c390eaa31833881dd55d6b0c Author: Yongqiang Yang Date: Wed Sep 5 01:25:50 2012 -0400 ext4: don't copy non-existent gdt blocks when resizing commit 6df935ad2fced9033ab52078825fcaf6365f34b7 upstream. The resize code was copying blocks at the beginning of each block group in order to copy the superblock and block group descriptor table (gdt) blocks. This was, unfortunately, being done even for block groups that did not have super blocks or gdt blocks. This is a complete waste of perfectly good I/O bandwidth, to skip writing those blocks for sparse bg's. Signed-off-by: Yongqiang Yang Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit 416a6881ec91623137652ab40e95870ee591e608 Author: Yongqiang Yang Date: Wed Sep 5 01:21:50 2012 -0400 ext4: ignore last group w/o enough space when resizing instead of BUG'ing commit 03c1c29053f678234dbd51bf3d65f3b7529021de upstream. If the last group does not have enough space for group tables, ignore it instead of calling BUG_ON(). Reported-by: Daniel Drake Signed-off-by: Yongqiang Yang Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit 69c212a724fd353e05aeb8dff788a71f68a6b1d8 Author: Yinghai Lu Date: Mon Sep 10 17:19:33 2012 -0700 PCI: Check P2P bridge for invalid secondary/subordinate range commit 1965f66e7db08d1ebccd24a59043eba826cc1ce8 upstream. For bridges with "secondary > subordinate", i.e., invalid bus number apertures, we don't enumerate anything behind the bridge unless the user specified "pci=assign-busses". This patch makes us automatically try to reassign the downstream bus numbers in this case (just for that bridge, not for all bridges as "pci=assign-busses" does). We don't discover all the devices on the Intel DP43BF motherboard without this change (or "pci=assign-busses") because its BIOS configures a bridge as: pci 0000:00:1e.0: PCI bridge to [bus 20-08] (subtractive decode) [bhelgaas: changelog, change message to dev_info] Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=18412 Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=625754 Reported-by: Brian C. Huffman Reported-by: VL Tested-by: VL Signed-off-by: Yinghai Lu Signed-off-by: Bjorn Helgaas commit 5cc78bc58829a3cb08404821484744846cf06e66 Author: Martin Peschke Date: Tue Sep 4 15:23:36 2012 +0200 SCSI: zfcp: only access zfcp_scsi_dev for valid scsi_device commit d436de8ce25f53a8a880a931886821f632247943 upstream. __scsi_remove_device (e.g. due to dev_loss_tmo) calls zfcp_scsi_slave_destroy which in turn sends a close LUN FSF request to the adapter. After 30 seconds without response, zfcp_erp_timeout_handler kicks the ERP thread failing the close LUN ERP action. zfcp_erp_wait in zfcp_erp_lun_shutdown_wait and thus zfcp_scsi_slave_destroy returns and then scsi_device is no longer valid. Sometime later the response to the close LUN FSF request may finally come in. However, commit b62a8d9b45b971a67a0f8413338c230e3117dff5 "[SCSI] zfcp: Use SCSI device data zfcp_scsi_dev instead of zfcp_unit" introduced a number of attempts to unconditionally access struct zfcp_scsi_dev through struct scsi_device causing a use-after-free. This leads to an Oops due to kernel page fault in one of: zfcp_fsf_abort_fcp_command_handler, zfcp_fsf_open_lun_handler, zfcp_fsf_close_lun_handler, zfcp_fsf_req_trace, zfcp_fsf_fcp_handler_common. Move dereferencing of zfcp private data zfcp_scsi_dev allocated in scsi_device via scsi_transport_reserve_device after the check for potentially aborted FSF request and thus no longer valid scsi_device. Only then assign sdev_to_zfcp(sdev) to the local auto variable struct zfcp_scsi_dev *zfcp_sdev. Signed-off-by: Martin Peschke Signed-off-by: Steffen Maier Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit ce6673c6e35541a45622fcd53573c27994f406a3 Author: Steffen Maier Date: Tue Sep 4 15:23:34 2012 +0200 SCSI: zfcp: restore refcount check on port_remove commit d99b601b63386f3395dc26a699ae703a273d9982 upstream. Upstream commit f3450c7b917201bb49d67032e9f60d5125675d6a "[SCSI] zfcp: Replace local reference counting with common kref" accidentally dropped a reference count check before tearing down zfcp_ports that are potentially in use by zfcp_units. Even remote ports in use can be removed causing unreachable garbage objects zfcp_ports with zfcp_units. Thus units won't come back even after a manual port_rescan. The kref of zfcp_port->dev.kobj is already used by the driver core. We cannot re-use it to track the number of zfcp_units. Re-introduce our own counter for units per port and check on port_remove. Signed-off-by: Steffen Maier Reviewed-by: Heiko Carstens Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit d27f15561fe521b44c0f784514cbd3e6c717bf36 Author: Julia Lawall Date: Tue Sep 4 15:23:33 2012 +0200 SCSI: zfcp: remove invalid reference to list iterator variable commit ca579c9f136af4274ccfd1bcaee7f38a29a0e2e9 upstream. If list_for_each_entry, etc complete a traversal of the list, the iterator variable ends up pointing to an address at an offset from the list head, and not a meaningful structure. Thus this value should not be used after the end of the iterator. Replace port->adapter->scsi_host by adapter->scsi_host. This problem was found using Coccinelle (http://coccinelle.lip6.fr/). Oversight in upsteam commit of v2.6.37 a1ca48319a9aa1c5b57ce142f538e76050bb8972 "[SCSI] zfcp: Move ACL/CFDC code to zfcp_cfdc.c" which merged the content of zfcp_erp_port_access_changed(). Signed-off-by: Julia Lawall Signed-off-by: Steffen Maier Reviewed-by: Martin Peschke Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit dd9ec1c64725b0b4deef5fd1bc1af11d624501d4 Author: Steffen Maier Date: Tue Sep 4 15:23:32 2012 +0200 SCSI: zfcp: Do not wakeup while suspended commit cb45214960bc989af8b911ebd77da541c797717d upstream. If the mapping of FCP device bus ID and corresponding subchannel is modified while the Linux image is suspended, the resume of FCP devices can fail. During resume, zfcp gets callbacks from cio regarding the modified subchannels but they can be arbitrarily mixed with the restore/resume callback. Since the cio callbacks would trigger adapter recovery, zfcp could wakeup before the resume callback. Therefore, ignore the cio callbacks regarding subchannels while being suspended. We can safely do so, since zfcp does not deal itself with subchannels. For problem determination purposes, we still trace the ignored callback events. The following kernel messages could be seen on resume: kernel: : parent should not be sleeping As part of adapter reopen recovery, zfcp performs auto port scanning which can erroneously try to register new remote ports with scsi_transport_fc and the device core code complains about the parent (adapter) still sleeping. kernel: zfcp.3dff9c: :\ Setting up the QDIO connection to the FCP adapter failed kernel: zfcp.574d43: :\ ERP cannot recover an error on the FCP device In such cases, the adapter gave up recovery and remained blocked along with its child objects: remote ports and LUNs/scsi devices. Even the adapter shutdown as part of giving up recovery failed because the ccw device state remained disconnected. Later, the corresponding remote ports ran into dev_loss_tmo. As a result, the LUNs were erroneously not available again after resume. Even a manually triggered adapter recovery (e.g. sysfs attribute failed, or device offline/online via sysfs) could not recover the adapter due to the remaining disconnected state of the corresponding ccw device. Signed-off-by: Steffen Maier Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 6698ed992a57761a1d3583e11e492da6ac3bbdc7 Author: Steffen Maier Date: Tue Sep 4 15:23:31 2012 +0200 SCSI: zfcp: Bounds checking for deferred error trace commit 01e60527f0a49b3d7df603010bd6079bb4b6cf07 upstream. The pl vector has scount elements, i.e. pl[scount-1] is the last valid element. For maximum sized requests, payload->counter == scount after the last loop iteration. Therefore, do bounds checking first (with boolean shortcut) to not access the invalid element pl[scount]. Do not trust the maximum sbale->scount value from the HBA but ensure we won't access the pl vector out of our allocated bounds. While at it, clean up scoping and prevent unnecessary memset. Minor fix for 86a9668a8d29ea711613e1cb37efa68e7c4db564 "[SCSI] zfcp: support for hardware data router" Signed-off-by: Steffen Maier Reviewed-by: Martin Peschke Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit f2e388ca8361ca66ed4090e54e287000f9c6e3b4 Author: Steffen Maier Date: Tue Sep 4 15:23:30 2012 +0200 SCSI: zfcp: Make trace record tags unique commit 0100998dbfe6dfcd90a6e912ca7ed6f255d48f25 upstream. Duplicate fssrh_2 from a54ca0f62f953898b05549391ac2a8a4dad6482b "[SCSI] zfcp: Redesign of the debug tracing for HBA records." complicates distinction of generic status read response from local link up. Duplicate fsscth1 from 2c55b750a884b86dea8b4cc5f15e1484cc47a25c "[SCSI] zfcp: Redesign of the debug tracing for SAN records." complicates distinction of good common transport response from invalid port handle. Signed-off-by: Steffen Maier Reviewed-by: Martin Peschke Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 6b00187c43c099c6648a6e9fd0f36b0663aca5d6 Author: Steffen Maier Date: Tue Sep 4 15:23:29 2012 +0200 SCSI: zfcp: Adapt to new FC_PORTSPEED semantics commit d22019778cd9ea04c1dadf7bf453920d5288f8d9 upstream. Commit a9277e7783651d4e0a849f7988340b1c1cf748a4 "[SCSI] scsi_transport_fc: Getting FC Port Speed in sync with FC-GS" changed the semantics of FC_PORTSPEED defines to FDMI port attributes of FC-HBA/SM-HBA which is different from the previous bit reversed Report Port Speed Capabilities (RPSC) ELS of FC-GS/FC-LS. Zfcp showed "10 Gbit" instead of "4 Gbit" for supported_speeds. It now uses explicit bit conversion as the other LLDs already do, in order to be independent of the kernel bit semantics. See also http://marc.info/?l=linux-scsi&m=134452926830730&w=2 Signed-off-by: Steffen Maier Reviewed-by: Martin Peschke Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit d70fd1a97eddef329ae3c63e72d38529862bded2 Author: Florian Zumbiehl Date: Tue Oct 2 12:20:37 2012 +0000 drm/savage: re-add busmaster enable, regression fix commit df86b5765a48d5f557489577652bd6df145b0e1b upstream. 466e69b8b03b8c1987367912782bc12988ad8794 dropped busmaster enable from the global drm code and moved it to the individual drivers, but missed the savage driver. So, this re-adds busmaster enable to the savage driver, fixing the regression. Signed-off-by: Florian Zumbiehl Reviewed-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 13d536a0bb25c10e183bc022a1b88dc097aad15d Author: Nicolas Dichtel Date: Wed Sep 26 00:04:55 2012 +0000 ipv6: del unreachable route when an addr is deleted on lo [ Upstream commit 64c6d08e6490fb18cea09bb03686c149946bd818 ] When an address is added on loopback (ip -6 a a 2002::1/128 dev lo), two routes are added: - one in the local table: local 2002::1 via :: dev lo proto none metric 0 - one the in main table (for the prefix): unreachable 2002::1 dev lo proto kernel metric 256 error -101 When the address is deleted, the route inserted in the main table remains because we use rt6_lookup(), which returns NULL when dst->error is set, which is the case here! Thus, it is better to use ip6_route_lookup() to avoid this kind of filter. Signed-off-by: Nicolas Dichtel Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 15fb2c5df65705de850c003eb23dadebc4042af6 Author: Tao Hou Date: Mon Oct 1 16:42:43 2012 +0000 net: ethernet: davinci_cpdma: decrease the desc count when cleaning up the remaining packets [ Upstream commit ffb5ba90017505a19e238e986e6d33f09e4df765 ] chan->count is used by rx channel. If the desc count is not updated by the clean up loop in cpdma_chan_stop, the value written to the rxfree register in cpdma_chan_start will be incorrect. Signed-off-by: Tao Hou Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 0f1bf6e2dc225d9bfce3be0be0b2f22956bcb313 Author: Gao feng Date: Wed Sep 19 19:25:34 2012 +0000 ipv6: release reference of ip6_null_entry's dst entry in __ip6_del_rt [ Upstream commit 6825a26c2dc21eb4f8df9c06d3786ddec97cf53b ] as we hold dst_entry before we call __ip6_del_rt, so we should alse call dst_release not only return -ENOENT when the rt6_info is ip6_null_entry. and we already hold the dst entry, so I think it's safe to call dst_release out of the write-read lock. Signed-off-by: Gao feng Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 57d8849c5fa2aa2e0b91aa2f822c6a41b2d879d4 Author: Antonio Quartulli Date: Tue Oct 2 06:14:17 2012 +0000 8021q: fix mac_len recomputation in vlan_untag() [ Upstream commit 5316cf9a5197eb80b2800e1acadde287924ca975 ] skb_reset_mac_len() relies on the value of the skb->network_header pointer, therefore we must wait for such pointer to be recalculated before computing the new mac_len value. Signed-off-by: Antonio Quartulli Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 52fc5048534e9d4127622fa5a269a92f3bb5218b Author: Eric Dumazet Date: Thu Oct 4 01:25:26 2012 +0000 ipv4: add a fib_type to fib_info [ Upstream commit f4ef85bbda96324785097356336bc79cdd37db0a ] commit d2d68ba9fe8 (ipv4: Cache input routes in fib_info nexthops.) introduced a regression for forwarding. This was hard to reproduce but the symptom was that packets were delivered to local host instead of being forwarded. David suggested to add fib_type to fib_info so that we dont inadvertently share same fib_info for different purposes. With help from Julian Anastasov who provided very helpful hints, reproduced here : Can it be a problem related to fib_info reuse from different routes. For example, when local IP address is created for subnet we have: broadcast 192.168.0.255 dev DEV proto kernel scope link src 192.168.0.1 192.168.0.0/24 dev DEV proto kernel scope link src 192.168.0.1 local 192.168.0.1 dev DEV proto kernel scope host src 192.168.0.1 The "dev DEV proto kernel scope link src 192.168.0.1" is a reused fib_info structure where we put cached routes. The result can be same fib_info for 192.168.0.255 and 192.168.0.0/24. RTN_BROADCAST is cached only for input routes. Incoming broadcast to 192.168.0.255 can be cached and can cause problems for traffic forwarded to 192.168.0.0/24. So, this patch should solve the problem because it separates the broadcast from unicast traffic. And the ip_route_input_slow caching will work for local and broadcast input routes (above routes 1 and 3) just because they differ in scope and use different fib_info. Many thanks to Chris Clayton for his patience and help. Reported-by: Chris Clayton Bisected-by: Chris Clayton Reported-by: Dave Jones Signed-off-by: Eric Dumazet Cc: Julian Anastasov Tested-by: Chris Clayton Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit c1d5777da53b53e02b38845ef9e80ac542f6a08a Author: Yuta Ando Date: Mon Oct 1 23:24:30 2012 +0900 localmodconfig: Fix localyesconfig to set to 'y' not 'm' commit 4eae518d4b01b0cbf2f0d8edb5a6f3d6245ee8fb upstream. The kbuild target 'localyesconfig' has been same as 'localmodconfig' since the commit 50bce3e "kconfig/streamline_config.pl: merge local{mod,yes}config". The commit expects this script generates different configure depending on target, but it was not yet implemented. So I added code that sets to 'yes' when target is 'localyesconfig'. Link: http://lkml.kernel.org/r/1349101470-12243-1-git-send-email-yuta.and@gmail.com Signed-off-by: Yuta Ando Cc: linux-kbuild@vger.kernel.org Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 14b4ed22a6b5fc1549504336131be4f5f6ba1bf4 Author: Eric Sandeen Date: Sat Aug 18 22:29:40 2012 -0400 jbd2: don't write superblock when if its empty commit eeecef0af5ea4efd763c9554cf2bd80fc4a0efd3 upstream. This sequence: # truncate --size=1g fsfile # mkfs.ext4 -F fsfile # mount -o loop,ro fsfile /mnt # umount /mnt # dmesg | tail results in an IO error when unmounting the RO filesystem: [ 318.020828] Buffer I/O error on device loop1, logical block 196608 [ 318.027024] lost page write due to I/O error on loop1 [ 318.032088] JBD2: Error -5 detected when updating journal superblock for loop1-8. This was a regression introduced by commit 24bcc89c7e7c: "jbd2: split updating of journal superblock and marking journal empty". Signed-off-by: Eric Sandeen Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit d024fea7032bc7c333c967db530b44d59a180d14 Author: Lai Jiangshan Date: Tue Sep 18 10:40:00 2012 -0700 workqueue: fix possible stall on try_to_grab_pending() of a delayed work item commit 3aa62497594430ea522050b75c033f71f2c60ee6 upstream. Currently, when try_to_grab_pending() grabs a delayed work item, it leaves its linked work items alone on the delayed_works. The linked work items are always NO_COLOR and will cause future cwq_activate_first_delayed() increase cwq->nr_active incorrectly, and may cause the whole cwq to stall. For example, state: cwq->max_active = 1, cwq->nr_active = 1 one work in cwq->pool, many in cwq->delayed_works. step1: try_to_grab_pending() removes a work item from delayed_works but leaves its NO_COLOR linked work items on it. step2: Later on, cwq_activate_first_delayed() activates the linked work item increasing ->nr_active. step3: cwq->nr_active = 1, but all activated work items of the cwq are NO_COLOR. When they finish, cwq->nr_active will not be decreased due to NO_COLOR, and no further work items will be activated from cwq->delayed_works. the cwq stalls. Fix it by ensuring the target work item is activated before stealing PENDING in try_to_grab_pending(). This ensures that all the linked work items are activated without incorrectly bumping cwq->nr_active. tj: Updated comment and description. Signed-off-by: Lai Jiangshan Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit d878ce75405d3fc90b0253d44ce603e5948584fb Author: Tejun Heo Date: Fri Aug 3 10:30:45 2012 -0700 workqueue: add missing smp_wmb() in process_one_work() commit 959d1af8cffc8fd38ed53e8be1cf4ab8782f9c00 upstream. WORK_STRUCT_PENDING is used to claim ownership of a work item and process_one_work() releases it before starting execution. When someone else grabs PENDING, all pre-release updates to the work item should be visible and all updates made by the new owner should happen afterwards. Grabbing PENDING uses test_and_set_bit() and thus has a full barrier; however, clearing doesn't have a matching wmb. Given the preceding spin_unlock and use of clear_bit, I don't believe this can be a problem on an actual machine and there hasn't been any related report but it still is theretically possible for clear_pending to permeate upwards and happen before work->entry update. Add an explicit smp_wmb() before work_clear_pending(). Signed-off-by: Tejun Heo Cc: Oleg Nesterov Signed-off-by: Greg Kroah-Hartman commit 05a65b235fb23759f3d0912f2967f6f2cd1a5c1d Author: Feng Hong Date: Wed Sep 19 14:16:00 2012 +0200 PM / Sleep: use resume event when call dpm_resume_early commit 997a031107ec962967ce36db9bc500f1fad491c1 upstream. When dpm_suspend_noirq fail, state is PMSG_SUSPEND, should change to PMSG_RESUME when dpm_resume_early is called Signed-off-by: Feng Hong Signed-off-by: Raul Xiong Signed-off-by: Neil Zhang Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 40c975a26226ae76d5d0809dc383544cdf3a11d7 Author: Alexandre Bounine Date: Thu Oct 4 17:15:48 2012 -0700 rapidio/rionet: fix multicast packet transmit logic commit 7c4a6106d6451fc03c491e61df37c044505d843a upstream. Fix multicast packet transmit logic to account for repetitive transmission of single skb: - correct check for available buffers (this bug may produce NULL pointer crash dump in case of heavy traffic); - update skb user count (incorrect user counter causes a warning dump from net_tx_action routine during multicast transfers in systems with three or more rionet participants). Signed-off-by: Alexandre Bounine Cc: Matt Porter Cc: David S. Miller Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit e23dfd7c2925856d19b875b1fbb2a0cd5c67180b Author: Mauro Carvalho Chehab Date: Tue Oct 2 16:01:15 2012 -0300 drxk: allow loading firmware synchrousnously commit 8e30783b0b3270736b2cff6415c68b894bc411df upstream. Due to udev-182, the firmware load was changed to be async, as otherwise udev would give up of loading a firmware. Add an option to return to the previous behaviour, async firmware loads cause failures with the tda18271 driver. Antti tested it with the following hardware: Hauppauge WinTV HVR 930C MaxMedia UB425-TC PCTV QuatroStick nano (520e) Tested-by: Antti Palosaari Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit f1cebb761c0cb4a550f2e8567fdb0a12f27b3878 Author: Jacob Keller Date: Fri Sep 21 07:23:20 2012 +0000 ixgbe: fix PTP ethtool timestamping function commit 1cc92eb871d6cbb1da038b4bcd89eec3c73b9781 upstream. This patch fixes a development issue that occurred due to invalid modes reported in the ethtool get_ts_info function. The issue is resolved by removing unsupported modes from the Rx supported list. Signed-off-by: Jacob Keller Tested-by: Phil Schmitt Signed-off-by: Jeff Kirsher Signed-off-by: Greg Kroah-Hartman commit edfd73d1bff85b117ee3c5d10da6c9645fe60d45 Author: Gavin Shan Date: Mon Sep 17 04:34:28 2012 +0000 powerpc/eeh: Fix crash on converting OF node to edev commit 1e38b7140185e384da216aff66a711df09b5afc9 upstream. The kernel crash was reported by Alexy. He was testing some feature with private kernel, in which Alexy added some code in pci_pm_reset() to read the CSR after writting it. The bug could be reproduced on Fiber Channel card (Fibre Channel: Emulex Corporation Saturn-X: LightPulse Fibre Channel Host Adapter (rev 03)) by the following commands. # echo 1 > /sys/devices/pci0004:01/0004:01:00.0/reset # rmmod lpfc # modprobe lpfc The history behind the test case is that those additional config space reading operations in pci_pm_reset() would cause EEH error, but we didn't detect EEH error until "modprobe lpfc". For the case, all the PCI devices on PCI bus (0004:01) were removed and added after PE reset. Then the EEH devices would be figured out again based on the OF nodes. Unfortunately, there were some child OF nodes under PCI device (0004:01:00.0), but they didn't have attached PCI_DN since they're invisible from PCI domain. However, we were still trying to convert OF node to EEH device without checking on the attached PCI_DN. Eventually, it caused the kernel crash as follows: Unable to handle kernel paging request for data at address 0x00000030 Faulting instruction address: 0xc00000000004d888 cpu 0x0: Vector: 300 (Data Access) at [c000000fc797b950] pc: c00000000004d888: .eeh_add_device_tree_early+0x78/0x140 lr: c00000000004d880: .eeh_add_device_tree_early+0x70/0x140 sp: c000000fc797bbd0 msr: 8000000000009032 dar: 30 dsisr: 40000000 current = 0xc000000fc78d9f70 paca = 0xc00000000edb0000 softe: 0 irq_happened: 0x00 pid = 2951, comm = eehd enter ? for help [c000000fc797bc50] c00000000004d848 .eeh_add_device_tree_early+0x38/0x140 [c000000fc797bcd0] c00000000004d848 .eeh_add_device_tree_early+0x38/0x140 [c000000fc797bd50] c000000000051b54 .pcibios_add_pci_devices+0x34/0x190 [c000000fc797bde0] c00000000004fb10 .eeh_reset_device+0x100/0x160 [c000000fc797be70] c0000000000502dc .eeh_handle_event+0x19c/0x300 [c000000fc797bf00] c000000000050570 .eeh_event_handler+0x130/0x1a0 [c000000fc797bf90] c000000000020138 .kernel_thread+0x54/0x70 The patch changes of_node_to_eeh_dev() and just returns NULL if the passed OF node doesn't have attached PCI_DN. Reported-by: Alexey Kardashevskiy Signed-off-by: Gavin Shan Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit dede562fbfe509c3e84d8259822f8612416316cf Author: Nishanth Aravamudan Date: Mon Oct 1 14:59:13 2012 +0000 powerpc: Fix VMX fix for memcpy case commit c8adfeccee01ce3de6a7d14fcd4e3be02e27f03c upstream. In 2fae7cdb60240e2e2d9b378afbf6d9fcce8a3890 ("powerpc: Fix VMX in interrupt check in POWER7 copy loops"), Anton inadvertently introduced a regression for memcpy on POWER7 machines. copyuser and memcpy diverge slightly in their use of cr1 (copyuser doesn't use it, but memcpy does) and you end up clobbering that register with your fix. That results in (taken from an FC18 kernel): [ 18.824604] Unrecoverable VMX/Altivec Unavailable Exception f20 at c000000000052f40 [ 18.824618] Oops: Unrecoverable VMX/Altivec Unavailable Exception, sig: 6 [#1] [ 18.824623] SMP NR_CPUS=1024 NUMA pSeries [ 18.824633] Modules linked in: tg3(+) be2net(+) cxgb4(+) ipr(+) sunrpc xts lrw gf128mul dm_crypt dm_round_robin dm_multipath linear raid10 raid456 async_raid6_recov async_memcpy async_pq raid6_pq async_xor xor async_tx raid1 raid0 scsi_dh_rdac scsi_dh_hp_sw scsi_dh_emc scsi_dh_alua squashfs cramfs [ 18.824705] NIP: c000000000052f40 LR: c00000000020b874 CTR: 0000000000000512 [ 18.824709] REGS: c000001f1fef7790 TRAP: 0f20 Not tainted (3.6.0-0.rc6.git0.2.fc18.ppc64) [ 18.824713] MSR: 8000000000009032 CR: 4802802e XER: 20000010 [ 18.824726] SOFTE: 0 [ 18.824728] CFAR: 0000000000000f20 [ 18.824731] TASK = c000000fa7128400[0] 'swapper/24' THREAD: c000000fa7480000 CPU: 24 GPR00: 00000000ffffffc0 c000001f1fef7a10 c00000000164edc0 c000000f9b9a8120 GPR04: c000000f9b9a8124 0000000000001438 0000000000000060 03ffffff064657ee GPR08: 0000000080000000 0000000000000010 0000000000000020 0000000000000030 GPR12: 0000000028028022 c00000000ff25400 0000000000000001 0000000000000000 GPR16: 0000000000000000 7fffffffffffffff c0000000016b2180 c00000000156a500 GPR20: c000000f968c7a90 c0000000131c31d8 c000001f1fef4000 c000000001561d00 GPR24: 000000000000000a 0000000000000000 0000000000000001 0000000000000012 GPR28: c000000fa5c04f80 00000000000008bc c0000000015c0a28 000000000000022e [ 18.824792] NIP [c000000000052f40] .memcpy_power7+0x5a0/0x7c4 [ 18.824797] LR [c00000000020b874] .pcpu_free_area+0x174/0x2d0 [ 18.824800] Call Trace: [ 18.824803] [c000001f1fef7a10] [c000000000052c14] .memcpy_power7+0x274/0x7c4 (unreliable) [ 18.824809] [c000001f1fef7b10] [c00000000020b874] .pcpu_free_area+0x174/0x2d0 [ 18.824813] [c000001f1fef7bb0] [c00000000020ba88] .free_percpu+0xb8/0x1b0 [ 18.824819] [c000001f1fef7c50] [c00000000043d144] .throtl_pd_exit+0x94/0xd0 [ 18.824824] [c000001f1fef7cf0] [c00000000043acf8] .blkg_free+0x88/0xe0 [ 18.824829] [c000001f1fef7d90] [c00000000018c048] .rcu_process_callbacks+0x2e8/0x8a0 [ 18.824835] [c000001f1fef7e90] [c0000000000a8ce8] .__do_softirq+0x158/0x4d0 [ 18.824840] [c000001f1fef7f90] [c000000000025ecc] .call_do_softirq+0x14/0x24 [ 18.824845] [c000000fa7483650] [c000000000010e80] .do_softirq+0x160/0x1a0 [ 18.824850] [c000000fa74836f0] [c0000000000a94a4] .irq_exit+0xf4/0x120 [ 18.824854] [c000000fa7483780] [c000000000020c44] .timer_interrupt+0x154/0x4d0 [ 18.824859] [c000000fa7483830] [c000000000003be0] decrementer_common+0x160/0x180 [ 18.824866] --- Exception: 901 at .plpar_hcall_norets+0x84/0xd4 [ 18.824866] LR = .check_and_cede_processor+0x48/0x80 [ 18.824871] [c000000fa7483b20] [c00000000007f018] .check_and_cede_processor+0x18/0x80 (unreliable) [ 18.824877] [c000000fa7483b90] [c00000000007f104] .dedicated_cede_loop+0x84/0x150 [ 18.824883] [c000000fa7483c50] [c0000000006bc030] .cpuidle_enter+0x30/0x50 [ 18.824887] [c000000fa7483cc0] [c0000000006bc9f4] .cpuidle_idle_call+0x104/0x720 [ 18.824892] [c000000fa7483d80] [c000000000070af8] .pSeries_idle+0x18/0x40 [ 18.824897] [c000000fa7483df0] [c000000000019084] .cpu_idle+0x1a4/0x380 [ 18.824902] [c000000fa7483ec0] [c0000000008a4c18] .start_secondary+0x520/0x528 [ 18.824907] [c000000fa7483f90] [c0000000000093f0] .start_secondary_prolog+0x10/0x14 [ 18.824911] Instruction dump: [ 18.824914] 38840008 90030000 90e30004 38630008 7ca62850 7cc300d0 78c7e102 7cf01120 [ 18.824923] 78c60660 39200010 39400020 39600030 <7e00200c> 7c0020ce 38840010 409f001c [ 18.824935] ---[ end trace 0bb95124affaaa45 ]--- [ 18.825046] Unrecoverable VMX/Altivec Unavailable Exception f20 at c000000000052d08 I believe the right fix is to make memcpy match usercopy and not use cr1. Signed-off-by: Nishanth Aravamudan Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 60b3e539bffddda2f1dd41d77e7353e864cca210 Author: Rusty Russell Date: Thu Oct 4 12:03:25 2012 +0930 lguest: fix occasional crash in example launcher. commit ca16f580a5db7e60bfafe59a50bb133bd3347491 upstream. We usually got away with ->next on the final entry being NULL, but it finally bit me. Signed-off-by: Rusty Russell Signed-off-by: Greg Kroah-Hartman commit 0c9f520eff046d5dea7ab8ac20f5835288300625 Author: Fabio Estevam Date: Thu Oct 4 17:11:16 2012 -0700 drivers/dma/dmaengine.c: lower the priority of 'failed to get' dma channel message commit 0eb5a35801df3c438ce3fc91310a415ea4452c00 upstream. Do the same as commit a03a202e95fd ("dmaengine: failure to get a specific DMA channel is not critical") to get rid of the following messages during kernel boot: dmaengine_get: failed to get dma1chan0: (-22) dmaengine_get: failed to get dma1chan1: (-22) dmaengine_get: failed to get dma1chan2: (-22) dmaengine_get: failed to get dma1chan3: (-22) .. Signed-off-by: Fabio Estevam Cc: Vinod Koul Cc: Dan Williams Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 4b45def3ed7625fa553eb8ae42624dd7dd3239e7 Author: Martin Michlmayr Date: Thu Oct 4 17:11:25 2012 -0700 drivers/scsi/atp870u.c: fix bad use of udelay commit 0f6d93aa9d96cc9022b51bd10d462b03296be146 upstream. The ACARD driver calls udelay() with a value > 2000, which leads to to the following compilation error on ARM: ERROR: "__bad_udelay" [drivers/scsi/atp870u.ko] undefined! make[1]: *** [__modpost] Error 1 This is because udelay is defined on ARM, roughly speaking, as #define udelay(n) ((n) > 2000 ? __bad_udelay() : \ __const_udelay((n) * ((2199023U*HZ)>>11))) The argument to __const_udelay is the number of jiffies to wait divided by 4, but this does not work unless the multiplication does not overflow, and that is what the build error is designed to prevent. The intended behavior can be achieved by using mdelay to call udelay multiple times in a loop. [jrnieder@gmail.com: adding context] Signed-off-by: Martin Michlmayr Signed-off-by: Jonathan Nieder Cc: James Bottomley Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 842f9ae997e6f29c768fde68ba22be81ab4891ab Author: Shawn Guo Date: Thu Oct 4 17:12:23 2012 -0700 kernel/sys.c: call disable_nonboot_cpus() in kernel_restart() commit f96972f2dc6365421cf2366ebd61ee4cf060c8d5 upstream. As kernel_power_off() calls disable_nonboot_cpus(), we may also want to have kernel_restart() call disable_nonboot_cpus(). Doing so can help machines that require boot cpu be the last alive cpu during reboot to survive with kernel restart. This fixes one reboot issue seen on imx6q (Cortex-A9 Quad). The machine requires that the restart routine be run on the primary cpu rather than secondary ones. Otherwise, the secondary core running the restart routine will fail to come to online after reboot. Signed-off-by: Shawn Guo Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 5761d00bf5760f044224fd7a7500942ff7ba973c Author: Davidlohr Bueso Date: Thu Oct 4 17:13:18 2012 -0700 lib/gcd.c: prevent possible div by 0 commit e96875677fb2b7cb739c5d7769824dff7260d31d upstream. Account for all properties when a and/or b are 0: gcd(0, 0) = 0 gcd(a, 0) = a gcd(0, b) = b Fixes no known problems in current kernels. Signed-off-by: Davidlohr Bueso Cc: Eric Dumazet Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit fdb540f319a7a93ada40636c6313bb8e10438ca7 Author: Mark Brown Date: Tue Aug 7 19:42:44 2012 +0100 mfd: 88pm860x: Move _IO resources out of ioport_ioresource commit c10c2aab634a3c61c46b98875988b2f53040bc9c upstream. The removal of mach/io.h from most ARM platforms also set the range of valid IO ports to be empty for most platforms when previously any 32 bit integer had been valid. This makes it impossible to add IO resources as the added range is smaller than that of the root resource for IO ports. Since we're not really using IO memory at all fix this by defining our own root resource outside the normal tree and make that the parent of all IO resources. This also ensures we won't conflict with read IO ports if we ever run on a platform which happens to use them. Signed-off-by: Mark Brown Acked-by: Arnd Bergmann Acked-by: Haojian Zhuang Tested-by: Haojian Zhuang Signed-off-by: Samuel Ortiz Signed-off-by: Greg Kroah-Hartman commit 196d29c060a92d5a2221dd043b8d6903ec211341 Author: Mark Brown Date: Tue Aug 7 19:42:43 2012 +0100 mfd: max8925: Move _IO resources out of ioport_ioresource commit bee6e1fa617b1fb7f6f91033428410e05f5ab0ed upstream. The removal of mach/io.h from most ARM platforms also set the range of valid IO ports to be empty for most platforms when previously any 32 bit integer had been valid. This makes it impossible to add IO resources as the added range is smaller than that of the root resource for IO ports. Since we're not really using IO memory at all fix this by defining our own root resource outside the normal tree and make that the parent of all IO resources. This also ensures we won't conflict with read IO ports if we ever run on a platform which happens to use them. Signed-off-by: Mark Brown Acked-by: Arnd Bergmann Acked-by: Haojian Zhuang Tested-by: Haojian Zhuang Signed-off-by: Samuel Ortiz Signed-off-by: Greg Kroah-Hartman commit 7b9d29463b35f8eafa43b42a40bb10435d258945 Author: Lin Ming Date: Mon Jul 16 16:30:21 2012 +0800 ACPI: run _OSC after ACPI_FULL_INITIALIZATION commit fc54ab72959edbf229b65ac74b2f122d799ca002 upstream. The _OSC method may exist in module level code, so it must be called after ACPI_FULL_INITIALIZATION On some new platforms with Zero-Power-Optical-Disk-Drive (ZPODD) support, this fix is necessary to save power. Signed-off-by: Lin Ming Tested-by: Aaron Lu Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman commit a84766cd7b1949ececf525dc93de015110fb5625 Author: Frank Schäfer Date: Sun Sep 9 15:02:20 2012 -0300 media: gspca_pac7302: make red balance and blue balance controls work again commit db43b9ca2f101d0945d043fa7d5ecd8f2da17fef upstream. Fix a regression from kernel 3.4 which has been introduced with the conversion of the gspca driver to the v4l2 control framework. Signed-off-by: Frank Schäfer Signed-off-by: Hans de Goede Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit f0510e6733a31862830ae47703cddb84885e070f Author: Frank Schäfer Date: Sun Sep 9 15:02:19 2012 -0300 media: gspca_pac7302: add support for device 1ae7:2001 Speedlink Snappy Microphone SL-6825-SBK commit 97d2fbf501e3cf105ac957086c7e40e62e15cdf8 upstream. Signed-off-by: Frank Schäfer Signed-off-by: Hans de Goede Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 434f4d3f1209d4e4c8b0d577d1c809f349c4f0da Author: Ben Hutchings Date: Sun Aug 19 19:32:27 2012 -0300 media: rc: ite-cir: Initialise ite_dev::rdev earlier commit 4b961180ef275035b1538317ffd0e21e80e63e77 upstream. ite_dev::rdev is currently initialised in ite_probe() after rc_register_device() returns. If a newly registered device is opened quickly enough, we may enable interrupts and try to use ite_dev::rdev before it has been initialised. Move it up to the earliest point we can, right after calling rc_allocate_device(). Reported-and-tested-by: YunQiang Su Signed-off-by: Ben Hutchings Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 3de9e9624b36263618470c6e134f22eabf8f2551 Author: Mauro Carvalho Chehab Date: Tue Oct 2 15:35:27 2012 -0300 em28xx: Make all em28xx extensions to be initialized asynchronously commit 6ae5e060840589f567c1837613e8a9d34fc9188a upstream. em28xx-dvb, em28xx-alsa and em28xx-ir are typically initialized asyncrhronously. The exception for it is when those modules are loaded before em28xx (or before an em28xx card insertion) or when they're built in. Make the extentions to always load asynchronously. That allows having all DVB firmwares loaded synchronously with udev-182. Antti tested it with the following hardware: Hauppauge WinTV HVR 930C MaxMedia UB425-TC PCTV QuatroStick nano (520e) Tested-by: Antti Palosaari Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit d4f7487aa0588291ad992d2921f02f543e25445b Author: Wade Farnsworth Date: Tue Oct 2 17:08:30 2012 +0100 ARM: 7548/1: include linux/sched.h in syscall.h commit 8ef102c6b4bc996ff96ca52b34775fe931ec90c9 upstream. The syscall tracing patch introduces a compile bug in lttng-modules when the latter calls syscall_get_nr(), similar to the following: /arch/arm/include/asm/syscall.h:21:2: error: implicit declaration of function 'task_thread_info' [-Werror=implicit-function-declaration] The issue is that we are using task_thread_info() in the syscall_get_nr() function in asm/syscall.h, but not explicitly including sched.h from this file, so we can expect this bug might surface any time that syscall_get_nr() is called. Explicitly including sched.h solves the problem. Signed-off-by: Wade Farnsworth Acked-by: Will Deacon Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit ad02e7b197e85889bd2df38bffa3e41c695c35f3 Author: Alex Williamson Date: Fri Nov 11 17:26:44 2011 -0700 intel-iommu: Default to non-coherent for domains unattached to iommus commit 2e12bc29fc5a12242d68e11875db3dd58efad9ff upstream. domain_update_iommu_coherency() currently defaults to setting domains as coherent when the domain is not attached to any iommus. This allows for a window in domain_context_mapping_one() where such a domain can update context entries non-coherently, and only after update the domain capability to clear iommu_coherency. This can be seen using KVM device assignment on VT-d systems that do not support coherency in the ecap register. When a device is added to a guest, a domain is created (iommu_coherency = 0), the device is attached, and ranges are mapped. If we then hot unplug the device, the coherency is updated and set to the default (1) since no iommus are attached to the domain. A subsequent attach of a device makes use of the same dmar domain (now marked coherent) updates context entries with coherency enabled, and only disables coherency as the last step in the process. To fix this, switch domain_update_iommu_coherency() to use the safer, non-coherent default for domains not attached to iommus. Signed-off-by: Alex Williamson Tested-by: Donald Dutile Acked-by: Donald Dutile Acked-by: Chris Wright Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 11464f790b08f7a8b0e5a98b994f53bd33ecb9e4 Author: Anton Blanchard Date: Wed Oct 3 18:57:10 2012 +0000 powerpc/iommu: Fix multiple issues with IOMMU pools code commit d900bd7366463fd96a907b2c212242e2b68b27d8 upstream. There are a number of issues in the recent IOMMU pools code: - On a preempt kernel we might switch CPUs in the middle of building a scatter gather list. When this happens the handle hint passed in no longer falls within the local CPU's pool. Check for this and fall back to the pool hint. - We were missing a spin_unlock/spin_lock in one spot where we switch pools. - We need to provide locking around dart_tlb_invalidate_all and dart_tlb_invalidate_one now that the global lock is gone. Reported-by: Alexander Graf Signed-off-by: Anton Blanchard Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 987bb385ef97fba0dcaf531e63a9bc5ca2e2f9f1 Author: Michael Wang Date: Wed Sep 5 10:33:18 2012 +0800 slab: fix the DEADLOCK issue on l3 alien lock commit 947ca1856a7e60aa6d20536785e6a42dff25aa6e upstream. DEADLOCK will be report while running a kernel with NUMA and LOCKDEP enabled, the process of this fake report is: kmem_cache_free() //free obj in cachep -> cache_free_alien() //acquire cachep's l3 alien lock -> __drain_alien_cache() -> free_block() -> slab_destroy() -> kmem_cache_free() //free slab in cachep->slabp_cache -> cache_free_alien() //acquire cachep->slabp_cache's l3 alien lock Since the cachep and cachep->slabp_cache's l3 alien are in the same lock class, fake report generated. This should not happen since we already have init_lock_keys() which will reassign the lock class for both l3 list and l3 alien. However, init_lock_keys() was invoked at a wrong position which is before we invoke enable_cpucache() on each cache. Since until set slab_state to be FULL, we won't invoke enable_cpucache() on caches to build their l3 alien while creating them, so although we invoked init_lock_keys(), the l3 alien lock class won't change since we don't have them until invoked enable_cpucache() later. This patch will invoke init_lock_keys() after we done enable_cpucache() instead of before to avoid the fake DEADLOCK report. Michael traced the problem back to a commit in release 3.0.0: commit 30765b92ada267c5395fc788623cb15233276f5c Author: Peter Zijlstra Date: Thu Jul 28 23:22:56 2011 +0200 slab, lockdep: Annotate the locks before using them Fernando found we hit the regular OFF_SLAB 'recursion' before we annotate the locks, cure this. The relevant portion of the stack-trace: > [ 0.000000] [] rt_spin_lock+0x50/0x56 > [ 0.000000] [] __cache_free+0x43/0xc3 > [ 0.000000] [] kmem_cache_free+0x6c/0xdc > [ 0.000000] [] slab_destroy+0x4f/0x53 > [ 0.000000] [] free_block+0x94/0xc1 > [ 0.000000] [] do_tune_cpucache+0x10b/0x2bb > [ 0.000000] [] enable_cpucache+0x7b/0xa7 > [ 0.000000] [] kmem_cache_init_late+0x1f/0x61 > [ 0.000000] [] start_kernel+0x24c/0x363 > [ 0.000000] [] i386_start_kernel+0xa9/0xaf Reported-by: Fernando Lopez-Lezcano Acked-by: Pekka Enberg Signed-off-by: Peter Zijlstra Link: http://lkml.kernel.org/r/1311888176.2617.379.camel@laptop Signed-off-by: Ingo Molnar The commit moved init_lock_keys() before we build up the alien, so we failed to reclass it. Acked-by: Christoph Lameter Tested-by: Paul E. McKenney Signed-off-by: Michael Wang Signed-off-by: Pekka Enberg Signed-off-by: Greg Kroah-Hartman commit caeb8b844999f194c3f76a9a3b0a8b94e17eadca Author: Daniel J Blueman Date: Fri Oct 5 22:23:55 2012 +0200 i2c-piix4: Fix build failure commit c415b303a704e5c5f766fc0404093910c36cc4ab upstream. Fix build failure in Intel PIIX4 I2C driver. Signed-off-by: Daniel J Blueman Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman commit 29f7d41bd8864713f28a63c7706afa7816b8e6e2 Author: Jean Delvare Date: Tue Oct 2 16:42:36 2012 +0200 kbuild: Fix gcc -x syntax commit b1e0d8b70fa31821ebca3965f2ef8619d7c5e316 upstream. The correct syntax for gcc -x is "gcc -x assembler", not "gcc -xassembler". Even though the latter happens to work, the former is what is documented in the manual page and thus what gcc wrappers such as icecream do expect. This isn't a cosmetic change. The missing space prevents icecream from recognizing compilation tasks it can't handle, leading to silent kernel miscompilations. Besides me, credits go to Michael Matz and Dirk Mueller for investigating the miscompilation issue and tracking it down to this incorrect -x parameter syntax. Signed-off-by: Jean Delvare Acked-by: Ingo Molnar Cc: Bernhard Walle Cc: Michal Marek Cc: Ralf Baechle Signed-off-by: Michal Marek Signed-off-by: Greg Kroah-Hartman commit 4bb50fa92f02d4b05067501919b280b44c6f4659 Author: Michal Marek Date: Tue Sep 25 16:03:03 2012 +0200 kbuild: Do not package /boot and /lib in make tar-pkg commit fe04ddf7c2910362f3817c8156e41cbd6c0ee35d upstream. There were reports of users destroying their Fedora installs by a kernel tarball that replaces the /lib -> /usr/lib symlink. Let's remove the toplevel directories from the tarball to prevent this from happening. Reported-by: Andi Kleen Suggested-by: Ben Hutchings Signed-off-by: Michal Marek Signed-off-by: Greg Kroah-Hartman commit 1d9465b68211c801acadde7dc3520eaba5e176c5 Author: Sascha Hauer Date: Thu Oct 4 17:11:17 2012 -0700 kbuild: make: fix if_changed when command contains backslashes commit c353acba28fb3fa1fd05fd6b85a9fc7938330f9c upstream. The call if_changed mechanism does not work when the command contains backslashes. This basically is an issue with lzo and bzip2 compressed kernels. The compressed binaries do not contain the uncompressed image size, so these use size_append to append the size. This results in backslashes in the executed command. With this if_changed always detects a change in the command and rebuilds the compressed image even if nothing has changed. Fix this by escaping backslashes in make-cmd Signed-off-by: Sascha Hauer Signed-off-by: Jan Luebbe Cc: Sam Ravnborg Cc: Bernhard Walle Cc: Michal Marek Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 562cc37c095ddc6873a1541d36250ad59ce59549 Author: Geert Uytterhoeven Date: Thu Oct 4 17:11:13 2012 -0700 mn10300: only add -mmem-funcs to KBUILD_CFLAGS if gcc supports it commit 9957423f035c2071f6d1c5d2f095cdafbeb25ad7 upstream. It seems the current (gcc 4.6.3) no longer provides this so make it conditional. As reported by Tony before, the mn10300 architecture cross-compiles with gcc-4.6.3 if -mmem-funcs is not added to KBUILD_CFLAGS. Reported-by: Tony Breeds Signed-off-by: Geert Uytterhoeven Cc: David Howells Cc: Koichi Yasutake Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman