commit 9c9ab76c48ffc48648c8e5da40d57965fc65c030 Author: Greg Kroah-Hartman Date: Tue May 7 20:33:25 2013 -0700 Linux 3.8.12 commit 05610af3c7228f509be69a96ec425b1836360615 Author: Lars-Peter Clausen Date: Tue Feb 19 11:51:22 2013 +0100 mfd: adp5520: Restore mode bits on resume commit c6cc25fda58da8685ecef3f179adc7b99c8253b2 upstream. The adp5520 unfortunately also clears the BL_EN bit when the nSTNDBY bit is cleared. So we need to make sure to restore it during resume if it was set before suspend. Signed-off-by: Lars-Peter Clausen Acked-by: Michael Hennerich Signed-off-by: Samuel Ortiz Signed-off-by: Greg Kroah-Hartman commit 55b8e63ea5ce5ffa45205a9e15cdd740aa8a69b4 Author: Al Viro Date: Sun May 5 00:16:35 2013 -0400 rcutrace: single_open() leaks commit 7ee2b9e56495c56dcaffa2bab19b39451d9fdc8a upstream. Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 51b0bfff72d38c16dc81a06244cf14dc10605ed0 Author: Terry Barnaby Date: Mon Apr 8 12:05:47 2013 -0400 mmc: atmel-mci: pio hang on block errors commit bdbc5d0c60f3e9de3eeccf1c1a18bdc11dca62cc upstream. The driver is doing, by default, multi-block reads. When a block error occurs, card/block.c instigates a single block read: "mmcblk0: retrying using single block read". It leaves the sg chain intact and just changes the length attribute for the first sg entry and the overall sg_len parameter. When atmci_read_data_pio is called to read the single block of data it ignores the sg_len and expects to read more than 512 bytes as it sees there are multiple items in the sg list. No more data comes as the controller has only been commanded to get one block. Signed-off-by: Terry Barnaby Acked-by: Ludovic Desroches Signed-off-by: Chris Ball Signed-off-by: Greg Kroah-Hartman commit da52815aeca48bfc954672fc66e5bcad2fbc99bd Author: Philip Rakity Date: Thu Apr 4 20:18:11 2013 +0100 mmc: core: Fix bit width test failing on old eMMC cards commit 836dc2fe89c968c10cada87e0dfae6626f8f9da3 upstream. PARTITION_SUPPORT needs to be set before doing the compare on version number so the bit width test does not get invalid data. Before this patch, a Sandisk iNAND eMMC card would detect 1-bit width although the hardware supports 4-bit. Only affects old emmc devices - pre 4.4 devices. Reported-by: Elad Yi Signed-off-by: Philip Rakity Signed-off-by: Chris Ball Signed-off-by: Greg Kroah-Hartman commit 13dd76b5d440ea98cffca49b530a94034ade9254 Author: Li Fei Date: Fri Apr 26 20:50:11 2013 +0800 x86: Eliminate irq_mis_count counted in arch_irq_stat commit f7b0e1055574ce06ab53391263b4e205bf38daf3 upstream. With the current implementation, kstat_cpu(cpu).irqs_sum is also increased in case of irq_mis_count increment. So there is no need to count irq_mis_count in arch_irq_stat, otherwise irq_mis_count will be counted twice in the sum of /proc/stat. Reported-by: Liu Chuansheng Signed-off-by: Li Fei Acked-by: Liu Chuansheng Cc: tomoki.sekiyama.qu@hitachi.com Cc: joe@perches.com Link: http://lkml.kernel.org/r/1366980611.32469.7.camel@fli24-HP-Compaq-8100-Elite-CMT-PC Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit b63018273bb6c505777a7ddccb8120f08111a6c0 Author: Gleb Natapov Date: Wed Apr 24 13:38:36 2013 +0300 KVM: X86 emulator: fix source operand decoding for 8bit mov[zs]x instructions commit 660696d1d16a71e15549ce1bf74953be1592bcd3 upstream. Source operand for one byte mov[zs]x is decoded incorrectly if it is in high byte register. Fix that. Signed-off-by: Gleb Natapov Signed-off-by: Greg Kroah-Hartman commit 3b9e9dd0f30c73bb90175124ed33b52d59d79c16 Author: David Howells Date: Sat May 4 08:48:27 2013 +0100 Give the OID registry file module info to avoid kernel tainting commit 9e6879460c8edb0cd3c24c09b83d06541b5af0dc upstream. Give the OID registry file module information so that it doesn't taint the kernel when compiled as a module and loaded. Reported-by: Dros Adamson Signed-off-by: David Howells cc: Trond Myklebust Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit f9581149b12db1f0896158669447f368557ee25a Author: Johan Hovold Date: Wed Mar 13 17:11:59 2013 +0100 mmc: at91/avr32/atmel-mci: fix DMA-channel leak on module unload commit 91cf54feecf815bec0b6a8d6d9dbd0e219f2f2cc upstream. Fix regression introduced by commit 796211b7953 ("mmc: atmel-mci: add pdc support and runtime capabilities detection") which removed the need for CONFIG_MMC_ATMELMCI_DMA but kept the Kconfig-entry as well as the compile guards around dma_release_channel() in remove(). Consequently, DMA is always enabled (if supported), but the DMA-channel is not released on module unload unless the DMA-config option is selected. Remove the no longer used CONFIG_MMC_ATMELMCI_DMA option completely. Signed-off-by: Johan Hovold Acked-by: Ludovic Desroches Signed-off-by: Chris Ball Signed-off-by: Greg Kroah-Hartman commit 836f410351d004d6a793e3bffe8f11667a932f4f Author: Theodore Ts'o Date: Sun Apr 21 20:32:03 2013 -0400 ext4: fix Kconfig documentation for CONFIG_EXT4_DEBUG commit 7f3e3c7cfcec148ccca9c0dd2dbfd7b00b7ac10f upstream. Fox the Kconfig documentation for CONFIG_EXT4_DEBUG to match the change made by commit a0b30c1229: ext4: use module parameters instead of debugfs for mballoc_debug Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit eb6903e96bdc8192483867048e04407799d85943 Author: Theodore Ts'o Date: Sun Apr 21 20:19:43 2013 -0400 ext4: fix online resizing for ext3-compat file systems commit c5c72d814cf0f650010337c73638b25e6d14d2d4 upstream. Commit fb0a387dcdc restricts block allocations for indirect-mapped files to block groups less than s_blockfile_groups. However, the online resizing code wasn't setting s_blockfile_groups, so the newly added block groups were not available for non-extent mapped files. Reported-by: Eric Sandeen Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit 2ed87d87342a7de090409bf02b2a86ac32191d4f Author: Dmitry Monakhov Date: Tue Apr 9 23:56:48 2013 -0400 ext4: fix big-endian bug in metadata checksum calculations commit 171a7f21a76a0958c225b97c00a97a10390d40ee upstream. Signed-off-by: Dmitry Monakhov Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit 5c5c79d431221917eef944c4c026b3044a5acc2a Author: Dmitry Monakhov Date: Wed Apr 3 22:08:52 2013 -0400 ext4: fix journal callback list traversal commit 5d3ee20855e28169d711b394857ee608a5023094 upstream. It is incorrect to use list_for_each_entry_safe() for journal callback traversial because ->next may be removed by other task: ->ext4_mb_free_metadata() ->ext4_mb_free_metadata() ->ext4_journal_callback_del() This results in the following issue: WARNING: at lib/list_debug.c:62 __list_del_entry+0x1c0/0x250() Hardware name: list_del corruption. prev->next should be ffff88019a4ec198, but was 6b6b6b6b6b6b6b6b Modules linked in: cpufreq_ondemand acpi_cpufreq freq_table mperf coretemp kvm_intel kvm crc32c_intel ghash_clmulni_intel microcode sg xhci_hcd button sd_mod crc_t10dif aesni_intel ablk_helper cryptd lrw aes_x86_64 xts gf128mul ahci libahci pata_acpi ata_generic dm_mirror dm_region_hash dm_log dm_mod Pid: 16400, comm: jbd2/dm-1-8 Tainted: G W 3.8.0-rc3+ #107 Call Trace: [] warn_slowpath_common+0xad/0xf0 [] warn_slowpath_fmt+0x46/0x50 [] ? ext4_journal_commit_callback+0x99/0xc0 [] __list_del_entry+0x1c0/0x250 [] ext4_journal_commit_callback+0x6f/0xc0 [] jbd2_journal_commit_transaction+0x23a6/0x2570 [] ? try_to_del_timer_sync+0x82/0xa0 [] ? del_timer_sync+0x91/0x1e0 [] kjournald2+0x19f/0x6a0 [] ? wake_up_bit+0x40/0x40 [] ? bit_spin_lock+0x80/0x80 [] kthread+0x10e/0x120 [] ? __init_kthread_worker+0x70/0x70 [] ret_from_fork+0x7c/0xb0 [] ? __init_kthread_worker+0x70/0x70 This patch fix the issue as follows: - ext4_journal_commit_callback() make list truly traversial safe simply by always starting from list_head - fix race between two ext4_journal_callback_del() and ext4_journal_callback_try_del() Signed-off-by: Dmitry Monakhov Signed-off-by: "Theodore Ts'o" Reviewed-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit 45932b3fd127c47269e3ba43d771033f30d25f78 Author: Dmitry Monakhov Date: Wed Apr 3 22:06:52 2013 -0400 jbd2: fix race between jbd2_journal_remove_checkpoint and ->j_commit_callback commit 794446c6946513c684d448205fbd76fa35f38b72 upstream. The following race is possible: [kjournald2] other_task jbd2_journal_commit_transaction() j_state = T_FINISHED; spin_unlock(&journal->j_list_lock); ->jbd2_journal_remove_checkpoint() ->jbd2_journal_free_transaction(); ->kmem_cache_free(transaction) ->j_commit_callback(journal, transaction); -> USE_AFTER_FREE WARNING: at lib/list_debug.c:62 __list_del_entry+0x1c0/0x250() Hardware name: list_del corruption. prev->next should be ffff88019a4ec198, but was 6b6b6b6b6b6b6b6b Modules linked in: cpufreq_ondemand acpi_cpufreq freq_table mperf coretemp kvm_intel kvm crc32c_intel ghash_clmulni_intel microcode sg xhci_hcd button sd_mod crc_t10dif aesni_intel ablk_helper cryptd lrw aes_x86_64 xts gf128mul ahci libahci pata_acpi ata_generic dm_mirror dm_region_hash dm_log dm_mod Pid: 16400, comm: jbd2/dm-1-8 Tainted: G W 3.8.0-rc3+ #107 Call Trace: [] warn_slowpath_common+0xad/0xf0 [] warn_slowpath_fmt+0x46/0x50 [] ? ext4_journal_commit_callback+0x99/0xc0 [] __list_del_entry+0x1c0/0x250 [] ext4_journal_commit_callback+0x6f/0xc0 [] jbd2_journal_commit_transaction+0x23a6/0x2570 [] ? try_to_del_timer_sync+0x82/0xa0 [] ? del_timer_sync+0x91/0x1e0 [] kjournald2+0x19f/0x6a0 [] ? wake_up_bit+0x40/0x40 [] ? bit_spin_lock+0x80/0x80 [] kthread+0x10e/0x120 [] ? __init_kthread_worker+0x70/0x70 [] ret_from_fork+0x7c/0xb0 [] ? __init_kthread_worker+0x70/0x70 In order to demonstrace this issue one should mount ext4 with mount -o discard option on SSD disk. This makes callback longer and race window becomes wider. In order to fix this we should mark transaction as finished only after callbacks have completed Signed-off-by: Dmitry Monakhov Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit aab8960fc9c05f82842586235fae4de1082708e1 Author: Theodore Ts'o Date: Wed Apr 3 22:02:52 2013 -0400 ext4/jbd2: don't wait (forever) for stale tid caused by wraparound commit d76a3a77113db020d9bb1e894822869410450bd9 upstream. In the case where an inode has a very stale transaction id (tid) in i_datasync_tid or i_sync_tid, it's possible that after a very large (2**31) number of transactions, that the tid number space might wrap, causing tid_geq()'s calculations to fail. Commit deeeaf13 "jbd2: fix fsync() tid wraparound bug", later modified by commit e7b04ac0 "jbd2: don't wake kjournald unnecessarily", attempted to fix this problem, but it only avoided kjournald spinning forever by fixing the logic in jbd2_log_start_commit(). Unfortunately, in the codepaths in fs/ext4/fsync.c and fs/ext4/inode.c that might call jbd2_log_start_commit() with a stale tid, those functions will subsequently call jbd2_log_wait_commit() with the same stale tid, and then wait for a very long time. To fix this, we replace the calls to jbd2_log_start_commit() and jbd2_log_wait_commit() with a call to a new function, jbd2_complete_transaction(), which will correctly handle stale tid's. As a bonus, jbd2_complete_transaction() will avoid locking j_state_lock for writing unless a commit needs to be started. This should have a small (but probably not measurable) improvement for ext4's scalability. Signed-off-by: "Theodore Ts'o" Reported-by: Ben Hutchings Reported-by: George Barnett Signed-off-by: Greg Kroah-Hartman commit c7e1e426d0b6bc1ab07779615c81faf6176901e5 Author: Jacob Keller Date: Sat Mar 2 07:51:42 2013 +0000 ixgbe: fix EICR write in ixgbe_msix_other commit d87d830720a1446403ed38bfc2da268be0d356d1 upstream. Previously, the ixgbe_msix_other was writing the full 32bits of the set interrupts, instead of only the ones which the ixgbe_msix_other is handling. This resulted in a loss of performance when the X540's PPS feature is enabled due to sometimes clearing queue interrupts which resulted in the driver not getting the interrupt for cleaning the q_vector rings often enough. The fix is to simply mask the lower 16bits off so that this handler does not write them in the EICR, which causes them to remain high and be properly handled by the clean_rings interrupt routine as normal. Signed-off-by: Jacob Keller Tested-by: Phil Schmitt Signed-off-by: Jeff Kirsher Signed-off-by: Greg Kroah-Hartman commit 870ef91261887958df8b91a14386bd9fc4485325 Author: Robin Holt Date: Tue Apr 30 19:15:54 2013 -0700 ipc: sysv shared memory limited to 8TiB commit d69f3bad4675ac519d41ca2b11e1c00ca115cecd upstream. Trying to run an application which was trying to put data into half of memory using shmget(), we found that having a shmall value below 8EiB-8TiB would prevent us from using anything more than 8TiB. By setting kernel.shmall greater than 8EiB-8TiB would make the job work. In the newseg() function, ns->shm_tot which, at 8TiB is INT_MAX. ipc/shm.c: 458 static int newseg(struct ipc_namespace *ns, struct ipc_params *params) 459 { ... 465 int numpages = (size + PAGE_SIZE -1) >> PAGE_SHIFT; ... 474 if (ns->shm_tot + numpages > ns->shm_ctlall) 475 return -ENOSPC; [akpm@linux-foundation.org: make ipc/shm.c:newseg()'s numpages size_t, not int] Signed-off-by: Robin Holt Reported-by: Alex Thorlton Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 8aba4976abb99ae093cc8d74976164be487a93a5 Author: Johannes Berg Date: Tue Apr 16 14:32:26 2013 +0200 wireless: regulatory: fix channel disabling race condition commit 990de49f74e772b6db5208457b7aa712a5f4db86 upstream. When a full scan 2.4 and 5 GHz scan is scheduled, but then the 2.4 GHz part of the scan disables a 5.2 GHz channel due to, e.g. receiving country or frequency information, that 5.2 GHz channel might already be in the list of channels to scan next. Then, when the driver checks if it should do a passive scan, that will return false and attempt an active scan. This is not only wrong but can also lead to the iwlwifi device firmware crashing since it checks regulatory as well. Fix this by not setting the channel flags to just disabled but rather OR'ing in the disabled flag. That way, even if the race happens, the channel will be scanned passively which is still (mostly) correct. Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit a63d0364cc416e40a3a4f8d67d73354c91152a7d Author: Bryan Schumaker Date: Fri Apr 19 16:09:38 2013 -0400 nfsd: Decode and send 64bit time values commit bf8d909705e9d9bac31d9b8eac6734d2b51332a7 upstream. The seconds field of an nfstime4 structure is 64bit, but we are assuming that the first 32bits are zero-filled. So if the client tries to set atime to a value before the epoch (touch -t 196001010101), then the server will save the wrong value on disk. Signed-off-by: Bryan Schumaker Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit f1b384b6f67be458dabb31ed1e5938e1b125f5f5 Author: fanchaoting Date: Mon Apr 1 21:07:22 2013 +0800 nfsd: don't run get_file if nfs4_preprocess_stateid_op return error commit b022032e195ffca83d7002d6b84297d796ed443b upstream. we should return error status directly when nfs4_preprocess_stateid_op return error. Signed-off-by: fanchaoting Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 73b12d302d65782ea3f072a230c939233f2ab4ec Author: J. Bruce Fields Date: Thu Mar 28 20:37:14 2013 -0400 nfsd4: don't close read-write opens too soon commit 0c7c3e67ab91ec6caa44bdf1fc89a48012ceb0c5 upstream. Don't actually close any opens until we don't need them at all. This means being left with write access when it's not really necessary, but that's better than putting a file that might still have posix locks held on it, as we have been. Reported-by: Toralf Förster Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 082265bbb37927de80da50c22bf24993c0b9ca75 Author: Trond Myklebust Date: Mon Apr 1 15:34:05 2013 -0400 NFSv4: Handle NFS4ERR_DELAY and NFS4ERR_GRACE in nfs4_open_delegation_recall commit 8b6cc4d6f841d31f72fe7478453759166d366274 upstream. A server shouldn't normally return NFS4ERR_GRACE if the client holds a delegation, since no conflicting lock reclaims can be granted, however the spec does not require the server to grant the open in this instance Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 70167a15d829277ed1373973b9535c20025c772a Author: Shaohua Li Date: Sun Apr 28 18:26:38 2013 +0800 MD: ignore discard request for hard disks of hybid raid1/raid10 array commit 32f9f570d04461a41bdcd5c1d93b41ebc5ce182a upstream. In SSD/hard disk hybid storage, discard request should be ignored for hard disk. We used to be doing this way, but the unplug path forgets it. This is suitable for stable tree since v3.6. Reported-and-tested-by: Markus Signed-off-by: Shaohua Li Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit 9088a4100a97838270b44a7980ccbc822b17a85b Author: NeilBrown Date: Wed Apr 24 11:42:44 2013 +1000 md: bad block list should default to disabled. commit 486adf72ccc0c235754923d47a2270c5dcb0c98b upstream. Maintenance of a bad-block-list currently defaults to 'enabled' and is then disabled when it cannot be supported. This is backwards and causes problem for dm-raid which didn't know to disable it. So fix the defaults, and only enabled for v1.x metadata which explicitly has bad blocks enabled. The problem with dm-raid has been present since badblock support was added in v3.1, so this patch is suitable for any -stable from 3.1 onwards. Reported-by: Jonathan Brassow Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit 97a12ae90a305b643a42fafe191d092f796d6179 Author: Trond Myklebust Date: Sun Apr 21 18:01:06 2013 -0400 LOCKD: Ensure that nlmclnt_block resets block->b_status after a server reboot commit 1dfd89af8697a299e7982ae740d4695ecd917eef upstream. After a server reboot, the reclaimer thread will recover all the existing locks. For locks that are blocked, however, it will change the value of block->b_status to nlm_lck_denied_grace_period in order to signal that they need to wake up and resend the original blocking lock request. Due to a bug, however, the block->b_status never gets reset after the blocked locks have been woken up, and so the process goes into an infinite loop of resends until the blocked lock is satisfied. Reported-by: Marc Eshel Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit d76dc4af6d15b4f47dc2d01fd40938ce7675b568 Author: Oleg Nesterov Date: Tue Apr 30 15:28:20 2013 -0700 exec: do not abuse ->cred_guard_mutex in threadgroup_lock() commit e56fb2874015370e3b7f8d85051f6dce26051df9 upstream. threadgroup_lock() takes signal->cred_guard_mutex to ensure that thread_group_leader() is stable. This doesn't look nice, the scope of this lock in do_execve() is huge. And as Dave pointed out this can lead to deadlock, we have the following dependencies: do_execve: cred_guard_mutex -> i_mutex cgroup_mount: i_mutex -> cgroup_mutex attach_task_by_pid: cgroup_mutex -> cred_guard_mutex Change de_thread() to take threadgroup_change_begin() around the switch-the-leader code and change threadgroup_lock() to avoid ->cred_guard_mutex. Note that de_thread() can't sleep with ->group_rwsem held, this can obviously deadlock with the exiting leader if the writer is active, so it does threadgroup_change_end() before schedule(). Reported-by: Dave Jones Acked-by: Tejun Heo Acked-by: Li Zefan Signed-off-by: Oleg Nesterov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 88d9e88d1b44a0b3947bce5d973c3ce0865ec868 Author: Greg Thelen Date: Tue Apr 30 15:26:48 2013 -0700 fs/dcache.c: add cond_resched() to shrink_dcache_parent() commit 421348f1ca0bf17769dee0aed4d991845ae0536d upstream. Call cond_resched() in shrink_dcache_parent() to maintain interactivity. Before this patch: void shrink_dcache_parent(struct dentry * parent) { while ((found = select_parent(parent, &dispose)) != 0) shrink_dentry_list(&dispose); } select_parent() populates the dispose list with dentries which shrink_dentry_list() then deletes. select_parent() carefully uses need_resched() to avoid doing too much work at once. But neither shrink_dcache_parent() nor its called functions call cond_resched(). So once need_resched() is set select_parent() will return single dentry dispose list which is then deleted by shrink_dentry_list(). This is inefficient when there are a lot of dentry to process. This can cause softlockup and hurts interactivity on non preemptable kernels. This change adds cond_resched() in shrink_dcache_parent(). The benefit of this is that need_resched() is quickly cleared so that future calls to select_parent() are able to efficiently return a big batch of dentry. These additional cond_resched() do not seem to impact performance, at least for the workload below. Here is a program which can cause soft lockup if other system activity sets need_resched(). int main() { struct rlimit rlim; int i; int f[100000]; char buf[20]; struct timeval t1, t2; double diff; /* cleanup past run */ system("rm -rf x"); /* boost nfile rlimit */ rlim.rlim_cur = 200000; rlim.rlim_max = 200000; if (setrlimit(RLIMIT_NOFILE, &rlim)) err(1, "setrlimit"); /* make directory for files */ if (mkdir("x", 0700)) err(1, "mkdir"); if (gettimeofday(&t1, NULL)) err(1, "gettimeofday"); /* populate directory with open files */ for (i = 0; i < 100000; i++) { snprintf(buf, sizeof(buf), "x/%d", i); f[i] = open(buf, O_CREAT); if (f[i] == -1) err(1, "open"); } /* close some of the files */ for (i = 0; i < 85000; i++) close(f[i]); /* unlink all files, even open ones */ system("rm -rf x"); if (gettimeofday(&t2, NULL)) err(1, "gettimeofday"); diff = (((double)t2.tv_sec * 1000000 + t2.tv_usec) - ((double)t1.tv_sec * 1000000 + t1.tv_usec)); printf("done: %g elapsed\n", diff/1e6); return 0; } Signed-off-by: Greg Thelen Signed-off-by: Dave Chinner Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit dd644cc9dae03d05c128ee3aba39d18b97ebdc22 Author: Zhao Hongjiang Date: Tue Apr 30 15:26:46 2013 -0700 inotify: invalid mask should return a error number but not set it commit 04df32fa10ab9a6f0643db2949d42efc966bc844 upstream. When we run the crackerjack testsuite, the inotify_add_watch test is stalled. This is caused by the invalid mask 0 - the task is waiting for the event but it never comes. inotify_add_watch() should return -EINVAL as it did before commit 676a0675cf92 ("inotify: remove broken mask checks causing unmount to be EINVAL"). That commit removes the invalid mask check, but that check is needed. Check the mask's ALL_INOTIFY_BITS before the inotify_arg_to_mask() call. If none are set, just return -EINVAL. Because IN_UNMOUNT is in ALL_INOTIFY_BITS, this change will not trigger the problem that above commit fixed. [akpm@linux-foundation.org: fix build] Signed-off-by: Zhao Hongjiang Acked-by: Jim Somerville Cc: Paul Gortmaker Cc: Jerome Marchand Cc: Eric Paris Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 4f452a14022af59bdc1b28732b3680731ec481c8 Author: Robert Richter Date: Tue Apr 30 18:57:18 2013 +0200 sata_highbank: Rename proc_name to the module name commit 2cc1144a31f76d4a9fb48bec5d6ba1359f980813 upstream. mkinitrd looks at /sys/class/scsi_host/host$hostnum/proc_name to find the module name of a disk driver. Current name is "highbank-ahci" but the module is "sata_highbank". Rename it to match the module name. Signed-off-by: Robert Richter Cc: Rob Herring Cc: Alexander Graf Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman commit fc8bc6906f47766f9bdcb296f4b176984889249e Author: Thomas Gleixner Date: Thu Apr 25 11:45:53 2013 +0200 clockevents: Set dummy handler on CPU_DEAD shutdown commit 6f7a05d7018de222e40ca003721037a530979974 upstream. Vitaliy reported that a per cpu HPET timer interrupt crashes the system during hibernation. What happens is that the per cpu HPET timer gets shut down when the nonboot cpus are stopped. When the nonboot cpus are onlined again the HPET code sets up the MSI interrupt which fires before the clock event device is registered. The event handler is still set to hrtimer_interrupt, which then crashes the machine due to highres mode not being active. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700333 There is no real good way to avoid that in the HPET code. The HPET code alrady has a mechanism to detect spurious interrupts when event handler == NULL for a similar reason. We can handle that in the clockevent/tick layer and replace the previous functional handler with a dummy handler like we do in tick_setup_new_device(). The original clockevents code did this in clockevents_exchange_device(), but that got removed by commit 7c1e76897 (clockevents: prevent clockevent event_handler ending up handler_noop) which forgot to fix it up in tick_shutdown(). Same issue with the broadcast device. Reported-by: Vitaliy Fillipov Cc: Ben Hutchings Cc: 700333@bugs.debian.org Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit ede709157120c653f1cef5d0da1656ef141e4750 Author: Steven Rostedt Date: Mon Apr 29 15:18:38 2013 -0400 localmodconfig: Process source kconfig files as they are found commit ced9cb1af1e3486cc14dca755a1b3fbadf06e90b upstream. A bug was reported that caused localmodconfig to not keep all the dependencies of ATH9K. This was caused by the kconfig file: In drivers/net/wireless/ath/Kconfig: commit fdb2b6f6dfc7b5a1c741a677eb990070690958f7 Author: Li Zefan Date: Thu Apr 18 23:09:52 2013 -0700 cgroup: fix broken file xattrs commit 712317ad97f41e738e1a19aa0a6392a78a84094e upstream. We should store file xattrs in struct cfent instead of struct cftype, because cftype is a type while cfent is object instance of cftype. For example each cgroup has a tasks file, and each tasks file is associated with a uniq cfent, but all those files share the same struct cftype. Alexey Kodanev reported a crash, which can be reproduced: # mount -t cgroup -o xattr /sys/fs/cgroup # mkdir /sys/fs/cgroup/test # setfattr -n trusted.value -v test_value /sys/fs/cgroup/tasks # rmdir /sys/fs/cgroup/test # umount /sys/fs/cgroup oops! In this case, simple_xattrs_free() will free the same struct simple_xattrs twice. tj: Dropped unused local variable @cft from cgroup_diput(). Reported-by: Alexey Kodanev Signed-off-by: Li Zefan Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 1ef527a1111b2a206d39d2e23cf13819e329f8b4 Author: Li Zefan Date: Tue Mar 12 15:36:00 2013 -0700 cgroup: fix an off-by-one bug which may trigger BUG_ON() commit 3ac1707a13a3da9cfc8f242a15b2fae6df2c5f88 upstream. The 3rd parameter of flex_array_prealloc() is the number of elements, not the index of the last element. The effect of the bug is, when opening cgroup.procs, a flex array will be allocated and all elements of the array is allocated with GFP_KERNEL flag, but the last one is GFP_ATOMIC, and if we fail to allocate memory for it, it'll trigger a BUG_ON(). Signed-off-by: Li Zefan Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 928c5edbe6f7cb0d1c71bc2353d091bc5b114fe3 Author: Zhang Rui Date: Fri Apr 26 09:19:53 2013 +0000 ACPI / thermal: do not always return THERMAL_TREND_RAISING for active trip points commit 94a409319561ec1847fd9bf996a2d5843ad00932 upstream. Commit 4ae46be "Thermal: Introduce thermal_zone_trip_update()" introduced a regression causing the fan to be always on even when the system is idle. My original idea in that commit is that: - when the current temperature is above the trip point, keep the fan on, even if the temperature is dropping. - when the current temperature is below the trip point, turn on the fan when the temperature is raising, turn off the fan when the temperature is dropping. But this is what the code actually does: - when the current temperature is above the trip point, the fan keeps on. - when the current temperature is below the trip point, the fan is always on because thermal_get_trend() in driver/acpi/thermal.c returns THERMAL_TREND_RAISING. Thus the fan keeps running even if the system is idle. Fix this in drivers/acpi/thermal.c. [rjw: Changelog] References: https://bugzilla.kernel.org/show_bug.cgi?id=56591 References: https://bugzilla.kernel.org/show_bug.cgi?id=56601 References: https://bugzilla.kernel.org/show_bug.cgi?id=50041#c45 Signed-off-by: Zhang Rui Tested-by: Matthias Tested-by: Ville Syrjälä Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit c80044245f076dfef574cbb11b47f2ce611291e2 Author: Wang YanQing Date: Tue Apr 23 01:19:19 2013 +0200 ACPI: Fix wrong parameter passed to memblock_reserve commit a6432ded299726f123b93d0132fead200551535c upstream. Commit 53aac44 (ACPI: Store valid ACPI tables passed via early initrd in reserved memblock areas) introduced acpi_initrd_override() that passes a wrong value as the second argument to memblock_reserve(). Namely, the second argument of memblock_reserve() is the size of the region, not the address of the top of it, so make acpi_initrd_override() pass the size in there as appropriate. [rjw: Changelog] Signed-off-by: Wang YanQing Acked-by: Yinghai Lu Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 8ee9b0d0b4cd61a9179f07dca81bf996c45543e5 Author: Aaron Lu Date: Sat Apr 27 09:33:07 2013 +0800 libata: acpi: make ata_ap_acpi_handle not block commit d66af4df0837f21bf267305dc5ccab2d29e24d86 upstream. Since commit 30dcf76acc, ata_ap_acpi_handle will always do a namespace walk, which requires acquiring an acpi namespace mutex. This made it impossible to be used when calling path has held a spinlock. For example, it can occur in the following code path for pata_acpi: ata_scsi_queuecmd (ap->lock is acquired) __ata_scsi_queuecmd ata_scsi_translate ata_qc_issue pacpi_qc_issue ata_acpi_stm ata_ap_acpi_handle acpi_get_child acpi_walk_namespace acpi_ut_acquire_mutex (acquire mutex while holding lock) This caused scheduling while atomic bug, as reported in bug #56781. Actually, ata_ap_acpi_handle doesn't have to walk the namespace every time it is called, it can simply return the bound acpi handle on the corresponding SCSI host. The reason previously it is not done this way is, ata_ap_acpi_handle is used in the binding function ata_acpi_bind_host by ata_acpi_gtm when the handle is not bound to the SCSI host yet. Since we already have the ATA port's handle in its binding function, we can simply use it instead of calling ata_ap_acpi_handle there. So introduce a new function __ata_acpi_gtm, where it will receive an acpi handle param in addition to the ATA port which is solely used for debug statement. With this change, we can make ata_ap_acpi_handle simply return the bound handle for SCSI host instead of walking the acpi namespace now. Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=56781 Reported-and-tested-by: Signed-off-by: Aaron Lu Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman commit 06455f09fe33497ea1b49580dececfaa0dc10a83 Author: Derek Basehore Date: Mon Apr 29 16:20:23 2013 -0700 drivers/rtc/rtc-cmos.c: don't disable hpet emulation on suspend commit e005715efaf674660ae59af83b13822567e3a758 upstream. There's a bug where rtc alarms are ignored after the rtc cmos suspends but before the system finishes suspend. Since hpet emulation is disabled and it still handles the interrupts, a wake event is never registered which is done from the rtc layer. This patch reverts commit d1b2efa83fbf ("rtc: disable hpet emulation on suspend") which disabled hpet emulation. To fix the problem mentioned in that commit, hpet_rtc_timer_init() is called directly on resume. Signed-off-by: Derek Basehore Cc: Maxim Levitsky Cc: "H. Peter Anvin" Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "Rafael J. Wysocki" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit df8a9d8e7d3dc1de16899ac67c8e6c08d4655595 Author: Mel Gorman Date: Mon Apr 29 15:08:48 2013 -0700 mm: swap: mark swap pages writeback before queueing for direct IO commit 0cdc444a67ccdbd58bfbcba865cb17a9f17a7691 upstream. As pointed out by Andrew Morton, the swap-over-NFS writeback is not setting PageWriteback before it is queued for direct IO. While swap pages do not participate in BDI or process dirty accounting and the IO is synchronous, the writeback bit is still required and not setting it in this case was an oversight. swapoff depends on the page writeback to synchronoise all pending writes on a swap page before it is reused. Swapcache freeing and reuse depend on checking the PageWriteback under lock to ensure the page is safe to reuse. Direct IO handlers and the direct IO handler for NFS do not deal with PageWriteback as they are synchronous writes. In the case of NFS, it schedules pages (or a page in the case of swap) for IO and then waits synchronously for IO to complete in nfs_direct_write(). It is recognised that this is a slowdown from normal swap handling which is asynchronous and uses a completion handler. Shoving PageWriteback handling down into direct IO handlers looks like a bad fit to handle the swap case although it may have to be dealt with some day if swap is converted to use direct IO in general and bmap is finally done away with. At that point it will be necessary to refit asynchronous direct IO with completion handlers onto the swap subsystem. As swapcache currently depends on PageWriteback to protect against races, this patch sets PageWriteback under the page lock before queueing it for direct IO. It is cleared when the direct IO handler returns. IO errors are treated similarly to the direct-to-bio case except PageError is not set as in the case of swap-over-NFS, it is likely to be a transient error. It was asked what prevents such a page being reclaimed in parallel. With this patch applied, such a page will now be skipped (most of the time) or blocked until the writeback completes. Reclaim checks PageWriteback under the page lock before calling try_to_free_swap and the page lock should prevent the page being requeued for IO before it is freed. This and Jerome's related patch should considered for -stable as far back as 3.6 when swap-over-NFS was introduced. [akpm@linux-foundation.org: use pr_err_ratelimited()] [akpm@linux-foundation.org: remove hopefully-unneeded cast in printk] Signed-off-by: Mel Gorman Cc: Jerome Marchand Cc: Hugh Dickins Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit ab1a3c6d9410ea4eef37be8cb804785b07113adb Author: Jerome Marchand Date: Mon Apr 29 15:08:47 2013 -0700 swap: redirty page if page write fails on swap file commit 2d30d31ea3c5be426ce25607b9bd1835acb85e0a upstream. Since commit 62c230bc1790 ("mm: add support for a filesystem to activate swap files and use direct_IO for writing swap pages"), swap_writepage() calls direct_IO on swap files. However, in that case the page isn't redirtied if I/O fails, and is therefore handled afterwards as if it has been successfully written to the swap file, leading to memory corruption when the page is eventually swapped back in. This patch sets the page dirty when direct_IO() fails. It fixes a memory corruption that happened while using swap-over-NFS. Signed-off-by: Jerome Marchand Acked-by: Johannes Weiner Acked-by: Mel Gorman Cc: Hugh Dickins Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 551c15a593c8c8636d609508f6a3d957bdec10ea Author: Prarit Bhargava Date: Mon Apr 8 08:47:15 2013 -0400 hrtimer: Add expiry time overflow check in hrtimer_interrupt commit 8f294b5a139ee4b75e890ad5b443c93d1e558a8b upstream. The settimeofday01 test in the LTP testsuite effectively does gettimeofday(current time); settimeofday(Jan 1, 1970 + 100 seconds); settimeofday(current time); This test causes a stack trace to be displayed on the console during the setting of timeofday to Jan 1, 1970 + 100 seconds: [ 131.066751] ------------[ cut here ]------------ [ 131.096448] WARNING: at kernel/time/clockevents.c:209 clockevents_program_event+0x135/0x140() [ 131.104935] Hardware name: Dinar [ 131.108150] Modules linked in: sg nfsv3 nfs_acl nfsv4 auth_rpcgss nfs dns_resolver fscache lockd sunrpc nf_conntrack_netbios_ns nf_conntrack_broadcast ipt_MASQUERADE ip6table_mangle ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 iptable_nat nf_nat_ipv4 nf_nat iptable_mangle ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter ip_tables kvm_amd kvm sp5100_tco bnx2 i2c_piix4 crc32c_intel k10temp fam15h_power ghash_clmulni_intel amd64_edac_mod pcspkr serio_raw edac_mce_amd edac_core microcode xfs libcrc32c sr_mod sd_mod cdrom ata_generic crc_t10dif pata_acpi radeon i2c_algo_bit drm_kms_helper ttm drm ahci pata_atiixp libahci libata usb_storage i2c_core dm_mirror dm_region_hash dm_log dm_mod [ 131.176784] Pid: 0, comm: swapper/28 Not tainted 3.8.0+ #6 [ 131.182248] Call Trace: [ 131.184684] [] warn_slowpath_common+0x7f/0xc0 [ 131.191312] [] warn_slowpath_null+0x1a/0x20 [ 131.197131] [] clockevents_program_event+0x135/0x140 [ 131.203721] [] tick_program_event+0x24/0x30 [ 131.209534] [] hrtimer_interrupt+0x131/0x230 [ 131.215437] [] ? cpufreq_p4_target+0x130/0x130 [ 131.221509] [] smp_apic_timer_interrupt+0x69/0x99 [ 131.227839] [] apic_timer_interrupt+0x6d/0x80 [ 131.233816] [] ? sched_clock_cpu+0xc5/0x120 [ 131.240267] [] ? cpuidle_wrap_enter+0x50/0xa0 [ 131.246252] [] ? cpuidle_wrap_enter+0x49/0xa0 [ 131.252238] [] cpuidle_enter_tk+0x10/0x20 [ 131.257877] [] cpuidle_idle_call+0xa9/0x260 [ 131.263692] [] cpu_idle+0xaf/0x120 [ 131.268727] [] start_secondary+0x255/0x257 [ 131.274449] ---[ end trace 1151a50552231615 ]--- When we change the system time to a low value like this, the value of timekeeper->offs_real will be a negative value. It seems that the WARN occurs because an hrtimer has been started in the time between the releasing of the timekeeper lock and the IPI call (via a call to on_each_cpu) in clock_was_set() in the do_settimeofday() code. The end result is that a REALTIME_CLOCK timer has been added with softexpires = expires = KTIME_MAX. The hrtimer_interrupt() fires/is called and the loop at kernel/hrtimer.c:1289 is executed. In this loop the code subtracts the clock base's offset (which was set to timekeeper->offs_real in do_settimeofday()) from the current hrtimer_cpu_base->expiry value (which was KTIME_MAX): KTIME_MAX - (a negative value) = overflow A simple check for an overflow can resolve this problem. Using KTIME_MAX instead of the overflow value will result in the hrtimer function being run, and the reprogramming of the timer after that. Reviewed-by: Rik van Riel Cc: Thomas Gleixner Signed-off-by: Prarit Bhargava [jstultz: Tweaked commit subject] Signed-off-by: John Stultz Signed-off-by: Greg Kroah-Hartman commit afb6f738ccaee780d65c1a787666812b0df5719d Author: David Engraf Date: Tue Mar 19 13:29:55 2013 +0100 hrtimer: Fix ktime_add_ns() overflow on 32bit architectures commit 51fd36f3fad8447c487137ae26b9d0b3ce77bb25 upstream. One can trigger an overflow when using ktime_add_ns() on a 32bit architecture not supporting CONFIG_KTIME_SCALAR. When passing a very high value for u64 nsec, e.g. 7881299347898368000 the do_div() function converts this value to seconds (7881299347) which is still to high to pass to the ktime_set() function as long. The result in is a negative value. The problem on my system occurs in the tick-sched.c, tick_nohz_stop_sched_tick() when time_delta is set to timekeeping_max_deferment(). The check for time_delta < KTIME_MAX is valid, thus ktime_add_ns() is called with a too large value resulting in a negative expire value. This leads to an endless loop in the ticker code: time_delta: 7881299347898368000 expires = ktime_add_ns(last_update, time_delta) expires: negative value This fix caps the value to KTIME_MAX. This error doesn't occurs on 64bit or architectures supporting CONFIG_KTIME_SCALAR (e.g. ARM, x86-32). Signed-off-by: David Engraf [jstultz: Minor tweaks to commit message & header] Signed-off-by: John Stultz Signed-off-by: Greg Kroah-Hartman commit 58404c0c7a4a36e18f4b8be9fed611d0d314932b Author: Dylan Reid Date: Tue Apr 16 20:02:34 2013 -0700 ASoC: max98088: Fix logging of hardware revision. commit 98682063549bedd6e2d2b6b7222f150c6fbce68c upstream. The hardware revision of the codec is based at 0x40. Subtract that before convering to ASCII. The same as it is done for 98095. Signed-off-by: Dylan Reid Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit c535d30755d309222d199952e7f45f31364d16db Author: Kailang Yang Date: Thu Apr 25 11:04:43 2013 +0200 ALSA: hda - Add the support for ALC286 codec commit 7fc7d047216aa4923d401c637be2ebc6e3d5bd9b upstream. It's yet another ALC269-variant. Signed-off-by: Kailang Yang Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit cc05a275dbbeca406b44e02eabb8d67bcb362482 Author: Clemens Ladisch Date: Sat Apr 27 12:10:32 2013 +0200 ALSA: USB: adjust for changed 3.8 USB API commit c75c5ab575af7db707689cdbb5a5c458e9a034bb upstream. The recent changes in the USB API ("implement new semantics for URB_ISO_ASAP") made the former meaning of the URB_ISO_ASAP flag the default, and changed this flag to mean that URBs can be delayed. This is not the behaviour wanted by any of the audio drivers because it leads to discontinuous playback with very small period sizes. Therefore, our URBs need to be submitted without this flag. Reported-by: Joe Rayhawk Signed-off-by: Clemens Ladisch Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 416277fa40c0a0e9f4823d98a6ec8c0993a99a07 Author: Takashi Iwai Date: Thu Apr 25 07:38:15 2013 +0200 ALSA: usb-audio: Fix autopm error during probing commit 60af3d037eb8c670dcce31401501d1271e7c5d95 upstream. We've got strange errors in get_ctl_value() in mixer.c during probing, e.g. on Hercules RMX2 DJ Controller: ALSA mixer.c:352 cannot get ctl value: req = 0x83, wValue = 0x201, wIndex = 0xa00, type = 4 ALSA mixer.c:352 cannot get ctl value: req = 0x83, wValue = 0x200, wIndex = 0xa00, type = 4 .... It turned out that the culprit is autopm: snd_usb_autoresume() returns -ENODEV when called during card->probing = 1. Since the call itself during card->probing = 1 is valid, let's fix the return value of snd_usb_autoresume() as success. Reported-and-tested-by: Daniel Schürmann Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 25273c9c50b8517400ec849e803a6c339655fb52 Author: Clemens Ladisch Date: Mon Apr 15 15:59:51 2013 +0200 ALSA: usb-audio: disable autopm for MIDI devices commit cbc200bca4b51a8e2406d4b654d978f8503d430b upstream. Commit 88a8516a2128 (ALSA: usbaudio: implement USB autosuspend) introduced autopm for all USB audio/MIDI devices. However, many MIDI devices, such as synthesizers, do not merely transmit MIDI messages but use their MIDI inputs to control other functions. With autopm, these devices would get powered down as soon as the last MIDI port device is closed on the host. Even some plain MIDI interfaces could get broken: they automatically send Active Sensing messages while powered up, but as soon as these messages cease, the receiving device would interpret this as an accidental disconnection. Commit f5f165418cab (ALSA: usb-audio: Fix missing autopm for MIDI input) introduced another regression: some devices (e.g. the Roland GAIA SH-01) are self-powered but do a reset whenever the USB interface's power state changes. To work around all this, just disable autopm for all USB MIDI devices. Reported-by: Laurens Holst Signed-off-by: Clemens Ladisch Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit a0dd5139a83d53d239eb896e159058ff859c1c8c Author: Calvin Owens Date: Fri Apr 12 22:33:59 2013 -0500 ALSA: usb: Add quirk for 192KHz recording on E-Mu devices commit 1539d4f82ad534431cc67935e8e442ccf107d17d upstream. When recording at 176.2KHz or 192Khz, the device adds a 32-bit length header to the capture packets, which obviously needs to be ignored for recording to work properly. Userspace expected: L0 L1 L2 R0 R1 R2 ...but actually got: R2 L0 L1 L2 R0 R1 Also, the last byte of the length header being interpreted as L0 of the first sample caused spikes every 0.5ms, resulting in a loud 16KHz tone (about the highest 'B' on a piano) being present throughout captures. Tested at all sample rates on an E-Mu 0404USB, and tested for regressions on a generic USB headset. Signed-off-by: Calvin Owens Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 269f78b5ebfce19ff5f084061fe4883dea40d200 Author: Daniel Mack Date: Wed Apr 24 19:38:42 2013 +0200 ALSA: snd-usb: try harder to find USB_DT_CS_ENDPOINT commit ebfc594c02148b6a85c2f178cf167a44a3c3ce10 upstream. The USB_DT_CS_ENDPOINT class-specific endpoint descriptor is usually stuffed directly after the standard USB endpoint descriptor, and this is where the driver currently expects it to be. There are, however, devices in the wild that have it the other way around in their descriptor sets, so the USB_DT_CS_ENDPOINT comes *before* the standard enpoint. Devices known to implement it that way are "Sennheiser BTD-500" and Plantronics USB headsets. When the driver can't find the USB_DT_CS_ENDPOINT, it won't be able to change sample rates, as the bitmask for the validity of this command is storen in bmAttributes of that descriptor. Fix this by searching the entire interface instead of just the extra bytes of the first endpoint, in case the latter fails. Signed-off-by: Daniel Mack Reported-and-tested-by: Torstein Hegge Reported-and-tested-by: Yves G Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit ae6f3c644ca300425e79b0d32d3dad214004255f Author: Takashi Iwai Date: Wed Apr 24 07:55:20 2013 +0200 ALSA: emu10k1: Fix dock firmware loading commit e08b34e86dfdb72a62196ce0f03d33f48958d8b9 upstream. The commit [b209c4df: ALSA: emu10k1: cache emu1010 firmware] broke the firmware loading of the dock, just (mistakenly) ignoring a different firmware for docks on some models. This patch revives them again. Bugzilla: https://bugs.archlinux.org/task/34865 Reported-and-tested-by: Tobias Powalowski Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 991b9fcab994af5270eab96160617005f9167179 Author: Duncan Laurie Date: Sun Mar 17 14:56:39 2013 -0700 TPM: Retry SaveState command in suspend path commit 32d33b29ba077d6b45de35f2181e0a7411b162f4 upstream. If the TPM has already been sent a SaveState command before the driver is loaded it may have problems sending that same command again later. This issue is seen with the Chromebook Pixel due to a firmware bug in the legacy mode boot path which is sending the SaveState command before booting the kernel. More information is available at http://crbug.com/203524 This change introduces a retry of the SaveState command in the suspend path in order to work around this issue. A future firmware update should fix this but this is also a trivial workaround in the driver that has no effect on systems that do not show this problem. When this does happen the TPM responds with a non-fatal TPM_RETRY code that is defined in the specification: The TPM is too busy to respond to the command immediately, but the command could be resubmitted at a later time. The TPM MAY return TPM_RETRY for any command at any time. It can take several seconds before the TPM will respond again. I measured a typical time between 3 and 4 seconds and the timeout is set at a safe 5 seconds. It is also possible to reproduce this with commands via /dev/tpm0. The bug linked above has a python script attached which can be used to test for this problem. I tested a variety of TPMs from Infineon, Nuvoton, Atmel, and STMicro but was only able to reproduce this with LPC and I2C TPMs from Infineon. The TPM specification only loosely defines this behavior: TPM Main Level 2 Part 3 v1.2 r116, section 3.3. TPM_SaveState: The TPM MAY declare all preserved values invalid in response to any command other than TPM_Init. TCG PC Client BIOS Spec 1.21 section 8.3.1. After issuing a TPM_SaveState command, the OS SHOULD NOT issue TPM commands before transitioning to S3 without issuing another TPM_SaveState command. TCG PC Client TIS 1.21, section 4. Power Management: The TPM_SaveState command allows a Static OS to indicate to the TPM that the platform may enter a low power state where the TPM will be required to enter into the D3 power state. The use of the term "may" is significant in that there is no requirement for the platform to actually enter the low power state after sending the TPM_SaveState command. The software may, in fact, send subsequent commands after sending the TPM_SaveState command. Change-Id: I52b41e826412688e5b6c8ddd3bb16409939704e9 Signed-off-by: Duncan Laurie Signed-off-by: Kent Yoder Cc: Dirk Hohndel Signed-off-by: Greg Kroah-Hartman commit 5d3fcda885ad9344278101d9a584aae74f7b351e Author: Hugh Dickins Date: Mon Apr 29 15:07:44 2013 -0700 mm: allow arch code to control the user page table ceiling commit 6ee8630e02be6dd89926ca0fbc21af68b23dc087 upstream. On architectures where a pgd entry may be shared between user and kernel (e.g. ARM+LPAE), freeing page tables needs a ceiling other than 0. This patch introduces a generic USER_PGTABLES_CEILING that arch code can override. It is the responsibility of the arch code setting the ceiling to ensure the complete freeing of the page tables (usually in pgd_free()). [catalin.marinas@arm.com: commit log; shift_arg_pages(), asm-generic/pgtables.h changes] Signed-off-by: Hugh Dickins Signed-off-by: Catalin Marinas Cc: Russell King Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit f7a07f4a01c40b9e47a3c9afc285092bf7b52913 Author: Anurup m Date: Mon Apr 29 15:05:52 2013 -0700 fs/fscache/stats.c: fix memory leak commit ec686c9239b4d472052a271c505d04dae84214cc upstream. There is a kernel memory leak observed when the proc file /proc/fs/fscache/stats is read. The reason is that in fscache_stats_open, single_open is called and the respective release function is not called during release. Hence fix with correct release function - single_release(). Addresses https://bugzilla.kernel.org/show_bug.cgi?id=57101 Signed-off-by: Anurup m Cc: shyju pv Cc: Sanil kumar Cc: Nataraj m Cc: Li Zefan Cc: David Howells Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 092d8ddf4125492f86e9b99b03bd1816bfd94f97 Author: Stephan Schreiber Date: Tue Mar 19 15:27:12 2013 -0700 Wrong asm register contraints in the kvm implementation commit de53e9caa4c6149ef4a78c2f83d7f5b655848767 upstream. The Linux Kernel contains some inline assembly source code which has wrong asm register constraints in arch/ia64/kvm/vtlb.c. I observed this on Kernel 3.2.35 but it is also true on the most recent Kernel 3.9-rc1. File arch/ia64/kvm/vtlb.c: u64 guest_vhpt_lookup(u64 iha, u64 *pte) { u64 ret; struct thash_data *data; data = __vtr_lookup(current_vcpu, iha, D_TLB); if (data != NULL) thash_vhpt_insert(current_vcpu, data->page_flags, data->itir, iha, D_TLB); asm volatile ( "rsm psr.ic|psr.i;;" "srlz.d;;" "ld8.s r9=[%1];;" "tnat.nz p6,p7=r9;;" "(p6) mov %0=1;" "(p6) mov r9=r0;" "(p7) extr.u r9=r9,0,53;;" "(p7) mov %0=r0;" "(p7) st8 [%2]=r9;;" "ssm psr.ic;;" "srlz.d;;" "ssm psr.i;;" "srlz.d;;" : "=r"(ret) : "r"(iha), "r"(pte):"memory"); return ret; } The list of output registers is : "=r"(ret) : "r"(iha), "r"(pte):"memory"); The constraint "=r" means that the GCC has to maintain that these vars are in registers and contain valid info when the program flow leaves the assembly block (output registers). But "=r" also means that GCC can put them in registers that are used as input registers. Input registers are iha, pte on the example. If the predicate p7 is true, the 8th assembly instruction "(p7) mov %0=r0;" is the first one which writes to a register which is maintained by the register constraints; it sets %0. %0 means the first register operand; it is ret here. This instruction might overwrite the %2 register (pte) which is needed by the next instruction: "(p7) st8 [%2]=r9;;" Whether it really happens depends on how GCC decides what registers it uses and how it optimizes the code. The attached patch fixes the register operand constraints in arch/ia64/kvm/vtlb.c. The register constraints should be : "=&r"(ret) : "r"(iha), "r"(pte):"memory"); The & means that GCC must not use any of the input registers to place this output register in. This is Debian bug#702639 (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702639). The patch is applicable on Kernel 3.9-rc1, 3.2.35 and many other versions. Signed-off-by: Stephan Schreiber Signed-off-by: Tony Luck Signed-off-by: Greg Kroah-Hartman commit 3ce5b781239c2593e251f824f56a586a3254fb14 Author: Stephan Schreiber Date: Tue Mar 19 15:22:27 2013 -0700 Wrong asm register contraints in the futex implementation commit 136f39ddc53db3bcee2befbe323a56d4fbf06da8 upstream. The Linux Kernel contains some inline assembly source code which has wrong asm register constraints in arch/ia64/include/asm/futex.h. I observed this on Kernel 3.2.23 but it is also true on the most recent Kernel 3.9-rc1. File arch/ia64/include/asm/futex.h: static inline int futex_atomic_cmpxchg_inatomic(u32 *uval, u32 __user *uaddr, u32 oldval, u32 newval) { if (!access_ok(VERIFY_WRITE, uaddr, sizeof(u32))) return -EFAULT; { register unsigned long r8 __asm ("r8"); unsigned long prev; __asm__ __volatile__( " mf;; \n" " mov %0=r0 \n" " mov ar.ccv=%4;; \n" "[1:] cmpxchg4.acq %1=[%2],%3,ar.ccv \n" " .xdata4 \"__ex_table\", 1b-., 2f-. \n" "[2:]" : "=r" (r8), "=r" (prev) : "r" (uaddr), "r" (newval), "rO" ((long) (unsigned) oldval) : "memory"); *uval = prev; return r8; } } The list of output registers is : "=r" (r8), "=r" (prev) The constraint "=r" means that the GCC has to maintain that these vars are in registers and contain valid info when the program flow leaves the assembly block (output registers). But "=r" also means that GCC can put them in registers that are used as input registers. Input registers are uaddr, newval, oldval on the example. The second assembly instruction " mov %0=r0 \n" is the first one which writes to a register; it sets %0 to 0. %0 means the first register operand; it is r8 here. (The r0 is read-only and always 0 on the Itanium; it can be used if an immediate zero value is needed.) This instruction might overwrite one of the other registers which are still needed. Whether it really happens depends on how GCC decides what registers it uses and how it optimizes the code. The objdump utility can give us disassembly. The futex_atomic_cmpxchg_inatomic() function is inline, so we have to look for a module that uses the funtion. This is the cmpxchg_futex_value_locked() function in kernel/futex.c: static int cmpxchg_futex_value_locked(u32 *curval, u32 __user *uaddr, u32 uval, u32 newval) { int ret; pagefault_disable(); ret = futex_atomic_cmpxchg_inatomic(curval, uaddr, uval, newval); pagefault_enable(); return ret; } Now the disassembly. At first from the Kernel package 3.2.23 which has been compiled with GCC 4.4, remeber this Kernel seemed to work: objdump -d linux-3.2.23/debian/build/build_ia64_none_mckinley/kernel/futex.o 0000000000000230 : 230: 0b 18 80 1b 18 21 [MMI] adds r3=3168,r13;; 236: 80 40 0d 00 42 00 adds r8=40,r3 23c: 00 00 04 00 nop.i 0x0;; 240: 0b 50 00 10 10 10 [MMI] ld4 r10=[r8];; 246: 90 08 28 00 42 00 adds r9=1,r10 24c: 00 00 04 00 nop.i 0x0;; 250: 09 00 00 00 01 00 [MMI] nop.m 0x0 256: 00 48 20 20 23 00 st4 [r8]=r9 25c: 00 00 04 00 nop.i 0x0;; 260: 08 10 80 06 00 21 [MMI] adds r2=32,r3 266: 00 00 00 02 00 00 nop.m 0x0 26c: 02 08 f1 52 extr.u r16=r33,0,61 270: 05 40 88 00 08 e0 [MLX] addp4 r8=r34,r0 276: ff ff 0f 00 00 e0 movl r15=0xfffffffbfff;; 27c: f1 f7 ff 65 280: 09 70 00 04 18 10 [MMI] ld8 r14=[r2] 286: 00 00 00 02 00 c0 nop.m 0x0 28c: f0 80 1c d0 cmp.ltu p6,p7=r15,r16;; 290: 08 40 fc 1d 09 3b [MMI] cmp.eq p8,p9=-1,r14 296: 00 00 00 02 00 40 nop.m 0x0 29c: e1 08 2d d0 cmp.ltu p10,p11=r14,r33 2a0: 56 01 10 00 40 10 [BBB] (p10) br.cond.spnt.few 2e0 2a6: 02 08 00 80 21 03 (p08) br.cond.dpnt.few 2b0 2ac: 40 00 00 41 (p06) br.cond.spnt.few 2e0 2b0: 0a 00 00 00 22 00 [MMI] mf;; 2b6: 80 00 00 00 42 00 mov r8=r0 2bc: 00 00 04 00 nop.i 0x0 2c0: 0b 00 20 40 2a 04 [MMI] mov.m ar.ccv=r8;; 2c6: 10 1a 85 22 20 00 cmpxchg4.acq r33=[r33],r35,ar.ccv 2cc: 00 00 04 00 nop.i 0x0;; 2d0: 10 00 84 40 90 11 [MIB] st4 [r32]=r33 2d6: 00 00 00 02 00 00 nop.i 0x0 2dc: 20 00 00 40 br.few 2f0 2e0: 09 40 c8 f9 ff 27 [MMI] mov r8=-14 2e6: 00 00 00 02 00 00 nop.m 0x0 2ec: 00 00 04 00 nop.i 0x0;; 2f0: 0b 58 20 1a 19 21 [MMI] adds r11=3208,r13;; 2f6: 20 01 2c 20 20 00 ld4 r18=[r11] 2fc: 00 00 04 00 nop.i 0x0;; 300: 0b 88 fc 25 3f 23 [MMI] adds r17=-1,r18;; 306: 00 88 2c 20 23 00 st4 [r11]=r17 30c: 00 00 04 00 nop.i 0x0;; 310: 11 00 00 00 01 00 [MIB] nop.m 0x0 316: 00 00 00 02 00 80 nop.i 0x0 31c: 08 00 84 00 br.ret.sptk.many b0;; The lines 2b0: 0a 00 00 00 22 00 [MMI] mf;; 2b6: 80 00 00 00 42 00 mov r8=r0 2bc: 00 00 04 00 nop.i 0x0 2c0: 0b 00 20 40 2a 04 [MMI] mov.m ar.ccv=r8;; 2c6: 10 1a 85 22 20 00 cmpxchg4.acq r33=[r33],r35,ar.ccv 2cc: 00 00 04 00 nop.i 0x0;; are the instructions of the assembly block. The line 2b6: 80 00 00 00 42 00 mov r8=r0 sets the r8 register to 0 and after that 2c0: 0b 00 20 40 2a 04 [MMI] mov.m ar.ccv=r8;; prepares the 'oldvalue' for the cmpxchg but it takes it from r8. This is wrong. What happened here is what I explained above: An input register is overwritten which is still needed. The register operand constraints in futex.h are wrong. (The problem doesn't occur when the Kernel is compiled with GCC 4.6.) The attached patch fixes the register operand constraints in futex.h. The code after patching of it: static inline int futex_atomic_cmpxchg_inatomic(u32 *uval, u32 __user *uaddr, u32 oldval, u32 newval) { if (!access_ok(VERIFY_WRITE, uaddr, sizeof(u32))) return -EFAULT; { register unsigned long r8 __asm ("r8") = 0; unsigned long prev; __asm__ __volatile__( " mf;; \n" " mov ar.ccv=%4;; \n" "[1:] cmpxchg4.acq %1=[%2],%3,ar.ccv \n" " .xdata4 \"__ex_table\", 1b-., 2f-. \n" "[2:]" : "+r" (r8), "=&r" (prev) : "r" (uaddr), "r" (newval), "rO" ((long) (unsigned) oldval) : "memory"); *uval = prev; return r8; } } I also initialized the 'r8' var with the C programming language. The _asm qualifier on the definition of the 'r8' var forces GCC to use the r8 processor register for it. I don't believe that we should use inline assembly for zeroing out a local variable. The constraint is "+r" (r8) what means that it is both an input register and an output register. Note that the page fault handler will modify the r8 register which will be the return value of the function. The real fix is "=&r" (prev) The & means that GCC must not use any of the input registers to place this output register in. Patched the Kernel 3.2.23 and compiled it with GCC4.4: 0000000000000230 : 230: 0b 18 80 1b 18 21 [MMI] adds r3=3168,r13;; 236: 80 40 0d 00 42 00 adds r8=40,r3 23c: 00 00 04 00 nop.i 0x0;; 240: 0b 50 00 10 10 10 [MMI] ld4 r10=[r8];; 246: 90 08 28 00 42 00 adds r9=1,r10 24c: 00 00 04 00 nop.i 0x0;; 250: 09 00 00 00 01 00 [MMI] nop.m 0x0 256: 00 48 20 20 23 00 st4 [r8]=r9 25c: 00 00 04 00 nop.i 0x0;; 260: 08 10 80 06 00 21 [MMI] adds r2=32,r3 266: 20 12 01 10 40 00 addp4 r34=r34,r0 26c: 02 08 f1 52 extr.u r16=r33,0,61 270: 05 40 00 00 00 e1 [MLX] mov r8=r0 276: ff ff 0f 00 00 e0 movl r15=0xfffffffbfff;; 27c: f1 f7 ff 65 280: 09 70 00 04 18 10 [MMI] ld8 r14=[r2] 286: 00 00 00 02 00 c0 nop.m 0x0 28c: f0 80 1c d0 cmp.ltu p6,p7=r15,r16;; 290: 08 40 fc 1d 09 3b [MMI] cmp.eq p8,p9=-1,r14 296: 00 00 00 02 00 40 nop.m 0x0 29c: e1 08 2d d0 cmp.ltu p10,p11=r14,r33 2a0: 56 01 10 00 40 10 [BBB] (p10) br.cond.spnt.few 2e0 2a6: 02 08 00 80 21 03 (p08) br.cond.dpnt.few 2b0 2ac: 40 00 00 41 (p06) br.cond.spnt.few 2e0 2b0: 0b 00 00 00 22 00 [MMI] mf;; 2b6: 00 10 81 54 08 00 mov.m ar.ccv=r34 2bc: 00 00 04 00 nop.i 0x0;; 2c0: 09 58 8c 42 11 10 [MMI] cmpxchg4.acq r11=[r33],r35,ar.ccv 2c6: 00 00 00 02 00 00 nop.m 0x0 2cc: 00 00 04 00 nop.i 0x0;; 2d0: 10 00 2c 40 90 11 [MIB] st4 [r32]=r11 2d6: 00 00 00 02 00 00 nop.i 0x0 2dc: 20 00 00 40 br.few 2f0 2e0: 09 40 c8 f9 ff 27 [MMI] mov r8=-14 2e6: 00 00 00 02 00 00 nop.m 0x0 2ec: 00 00 04 00 nop.i 0x0;; 2f0: 0b 88 20 1a 19 21 [MMI] adds r17=3208,r13;; 2f6: 30 01 44 20 20 00 ld4 r19=[r17] 2fc: 00 00 04 00 nop.i 0x0;; 300: 0b 90 fc 27 3f 23 [MMI] adds r18=-1,r19;; 306: 00 90 44 20 23 00 st4 [r17]=r18 30c: 00 00 04 00 nop.i 0x0;; 310: 11 00 00 00 01 00 [MIB] nop.m 0x0 316: 00 00 00 02 00 80 nop.i 0x0 31c: 08 00 84 00 br.ret.sptk.many b0;; Much better. There is a 270: 05 40 00 00 00 e1 [MLX] mov r8=r0 which was generated by C code r8 = 0. Below 2b6: 00 10 81 54 08 00 mov.m ar.ccv=r34 what means that oldval is no longer overwritten. This is Debian bug#702641 (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702641). The patch is applicable on Kernel 3.9-rc1, 3.2.23 and many other versions. Signed-off-by: Stephan Schreiber Signed-off-by: Tony Luck Signed-off-by: Greg Kroah-Hartman commit 3fc6be3dd634f426922da16bc1966f9d4227a9dc Author: Alex A. Mihaylov Date: Mon Apr 15 07:29:35 2013 +0400 rt2x00: Fix transmit power troubles on some Ralink RT30xx cards commit 7e9dafd873034dd64ababcb858be424c4780ae13 upstream. Some cards on Ralink RT30xx chipset not have correctly TX_MIXER_GAIN value in them EEPROM/EFUSE. In this case, we must use default value, but always used EEPROM/EFUSE value. As result we have tranmitt power range from -10dBm to +6dBm instead 0dBm to +16dBm. Correctly value in EEPROM/EFUSE is one or more for RT3070 and two or more for other RT30xx chips. Tested on Canyon CNP-WF518N1 usb Wi-Fi dongle and Jorjin WN8020 usb embedded Wi-Fi module. Signed-off-by: Alex A. Mihaylov Acked-by: Gertjan van Wingerde Acked-by: Stanislaw Gruszka Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 7ca9cb29b8f07a070671a5bd626fa78402dfb3ca Author: Rafael J. Wysocki Date: Fri Apr 12 13:58:17 2013 +0000 PCI/PM: Fix fallback to PCI_D0 in pci_platform_power_transition() commit 769ba7212f2059ca9fe0c73371e3d415c8c1c529 upstream. Commit b51306c (PCI: Set device power state to PCI_D0 for device without native PM support) modified pci_platform_power_transition() by adding code causing dev->current_state for devices that don't support native PCI PM but are power-manageable by the platform to be changed to PCI_D0 regardless of the value returned by the preceding platform_pci_set_power_state(). In particular, that also is done if the platform_pci_set_power_state() has been successful, which causes the correct power state of the device set by pci_update_current_state() in that case to be overwritten by PCI_D0. Fix that mistake by making the fallback to PCI_D0 only happen if the platform_pci_set_power_state() has returned an error. [bhelgaas: folded in Yinghai's simplification, added URL & stable info] Reference: http://lkml.kernel.org/r/27806FC4E5928A408B78E88BBC67A2306F466BBA@ORSMSX101.amr.corp.intel.com Reported-by: Chris J. Benenati Signed-off-by: Rafael J. Wysocki Signed-off-by: Bjorn Helgaas Acked-by: Yinghai Lu Signed-off-by: Greg Kroah-Hartman commit 540ffb908bec0c152b02559279b20d7cfcad110d Author: Yinghai Lu Date: Thu Mar 28 04:28:58 2013 +0000 PCI / ACPI: Don't query OSC support with all possible controls commit 545d6e189a41c94c11f55045a771118eccc9d9eb upstream. Found problem on system that firmware that could handle pci aer. Firmware get error reporting after pci injecting error, before os boots. But after os boots, firmware can not get report anymore, even pci=noaer is passed. Root cause: BIOS _OSC has problem with query bit checking. It turns out that BIOS vendor is copying example code from ACPI Spec. In ACPI Spec 5.0, page 290: If (Not(And(CDW1,1))) // Query flag clear? { // Disable GPEs for features granted native control. If (And(CTRL,0x01)) // Hot plug control granted? { Store(0,HPCE) // clear the hot plug SCI enable bit Store(1,HPCS) // clear the hot plug SCI status bit } ... } When Query flag is set, And(CDW1,1) will be 1, Not(1) will return 0xfffffffe. So it will get into code path that should be for control set only. BIOS acpi code should be changed to "If (LEqual(And(CDW1,1), 0)))" Current kernel code is using _OSC query to notify firmware about support from OS and then use _OSC to set control bits. During query support, current code is using all possible controls. So will execute code that should be only for control set stage. That will have problem when pci=noaer or aer firmware_first is used. As firmware have that control set for os aer already in query support stage, but later will not os aer handling. We should avoid passing all possible controls, just use osc_control_set instead. That should workaround BIOS bugs with affected systems on the field as more bios vendors are copying sample code from ACPI spec. Signed-off-by: Yinghai Lu Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit bea361dba23fff2b229f111c72df51bd0b12be29 Author: Tony Luck Date: Wed Mar 20 10:30:15 2013 -0700 Fix initialization of CMCI/CMCP interrupts commit d303e9e98fce56cdb3c6f2ac92f626fc2bd51c77 upstream. Back 2010 during a revamp of the irq code some initializations were moved from ia64_mca_init() to ia64_mca_late_init() in commit c75f2aa13f5b268aba369b5dc566088b5194377c Cannot use register_percpu_irq() from ia64_mca_init() But this was hideously wrong. First of all these initializations are now down far too late. Specifically after all the other cpus have been brought up and initialized their own CMC vectors from smp_callin(). Also ia64_mca_late_init() may be called from any cpu so the line: ia64_mca_cmc_vector_setup(); /* Setup vector on BSP */ is generally not executed on the BSP, and so the CMC vector isn't setup at all on that processor. Make use of the arch_early_irq_init() hook to get this code executed at just the right moment: not too early, not too late. Reported-by: Fred Hartnett Tested-by: Fred Hartnett Signed-off-by: Tony Luck Signed-off-by: Greg Kroah-Hartman commit dda34083d85638e18a3d61701500c52405183e0c Author: Ming Lei Date: Tue Apr 2 10:12:26 2013 +0800 sysfs: fix use after free in case of concurrent read/write and readdir commit f7db5e7660b122142410dcf36ba903c73d473250 upstream. The inode->i_mutex isn't hold when updating filp->f_pos in read()/write(), so the filp->f_pos might be read as 0 or 1 in readdir() when there is concurrent read()/write() on this same file, then may cause use after free in readdir(). The bug can be reproduced with Li Zefan's test code on the link: https://patchwork.kernel.org/patch/2160771/ This patch fixes the use after free under this situation. Reported-by: Li Zefan Signed-off-by: Ming Lei Signed-off-by: Greg Kroah-Hartman commit 5d35a536a241865aeaf5f960783ce2c023fed2c3 Author: Sandy Wu Date: Thu Mar 28 17:05:44 2013 -0700 crypto: crc32-pclmul - Use gas macro for pclmulqdq commit 57ae1b0532977b30184aaba04b6cafe0a284c21f upstream. Occurs when CONFIG_CRYPTO_CRC32C_INTEL=y and CONFIG_CRYPTO_CRC32C_INTEL=y. Older versions of bintuils do not support the pclmulqdq instruction. The PCLMULQDQ gas macro is used instead. Signed-off-by: Sandy Wu Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 35d20c1b1a355f53e5b9f403ad57c26cd3b5d676 Author: Steven A. Falco Date: Mon Apr 22 09:34:39 2013 +0000 i2c: xiic: must always write 16-bit words to TX_FIFO commit c39e8e4354ce4daf23336de5daa28a3b01f00aa6 upstream. The TX_FIFO register is 10 bits wide. The lower 8 bits are the data to be written, while the upper two bits are flags to indicate stop/start. The driver apparently attempted to optimize write access, by only writing a byte in those cases where the stop/start bits are zero. However, we have seen cases where the lower byte is duplicated onto the upper byte by the hardware, which causes inadvertent stop/starts. This patch changes the write access to the transmit FIFO to always be 16 bits wide. Signed off by: Steven A. Falco Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 228a8f062631a04bf383a80f30f4c9787c706ecd Author: Namhyung Kim Date: Thu Apr 11 16:01:38 2013 +0900 tracing: Reset ftrace_graph_filter_enabled if count is zero commit 9f50afccfdc15d95d7331acddcb0f7703df089ae upstream. The ftrace_graph_count can be decreased with a "!" pattern, so that the enabled flag should be updated too. Link: http://lkml.kernel.org/r/1365663698-2413-1-git-send-email-namhyung@kernel.org Signed-off-by: Namhyung Kim Cc: Frederic Weisbecker Cc: Ingo Molnar Cc: Namhyung Kim Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit fbf7a3f498a9aecd68b3bd6047435d5d859e6868 Author: Namhyung Kim Date: Wed Apr 10 09:18:12 2013 +0900 tracing: Check return value of tracing_init_dentry() commit ed6f1c996bfe4b6e520cf7a74b51cd6988d84420 upstream. Check return value and bail out if it's NULL. Link: http://lkml.kernel.org/r/1365553093-10180-2-git-send-email-namhyung@kernel.org Signed-off-by: Namhyung Kim Cc: Frederic Weisbecker Cc: Namhyung Kim Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 3c90dc77f2bcf0ce2ac6cd31522b3833713112bc Author: Namhyung Kim Date: Mon Apr 1 21:46:24 2013 +0900 tracing: Fix off-by-one on allocating stat->pages commit 39e30cd1537937d3c00ef87e865324e981434e5b upstream. The first page was allocated separately, so no need to start from 0. Link: http://lkml.kernel.org/r/1364820385-32027-2-git-send-email-namhyung@kernel.org Signed-off-by: Namhyung Kim Cc: Frederic Weisbecker Cc: Namhyung Kim Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 5d937312da32c4ab78280d0999036ed4ea872ecb Author: Steven Rostedt (Red Hat) Date: Wed Mar 13 23:34:22 2013 -0400 tracing: Remove most or all of stack tracer stack size from stack_max_size commit 4df297129f622bdc18935c856f42b9ddd18f9f28 upstream. Currently, the depth reported in the stack tracer stack_trace file does not match the stack_max_size file. This is because the stack_max_size includes the overhead of stack tracer itself while the depth does not. The first time a max is triggered, a calculation is not performed that figures out the overhead of the stack tracer and subtracts it from the stack_max_size variable. The overhead is stored and is subtracted from the reported stack size for comparing for a new max. Now the stack_max_size corresponds to the reported depth: # cat stack_max_size 4640 # cat stack_trace Depth Size Location (48 entries) ----- ---- -------- 0) 4640 32 _raw_spin_lock+0x18/0x24 1) 4608 112 ____cache_alloc+0xb7/0x22d 2) 4496 80 kmem_cache_alloc+0x63/0x12f 3) 4416 16 mempool_alloc_slab+0x15/0x17 [...] While testing against and older gcc on x86 that uses mcount instead of fentry, I found that pasing in ip + MCOUNT_INSN_SIZE let the stack trace show one more function deep which was missing before. Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 0b2efcddd7459f87f4b6dd69fba814fadd630f0e Author: Steven Rostedt (Red Hat) Date: Wed Mar 13 21:25:35 2013 -0400 tracing: Fix stack tracer with fentry use commit d4ecbfc49b4b1d4b597fb5ba9e4fa25d62f105c5 upstream. When gcc 4.6 on x86 is used, the function tracer will use the new option -mfentry which does a call to "fentry" at every function instead of "mcount". The significance of this is that fentry is called as the first operation of the function instead of the mcount usage of being called after the stack. This causes the stack tracer to show some bogus results for the size of the last function traced, as well as showing "ftrace_call" instead of the function. This is due to the stack frame not being set up by the function that is about to be traced. # cat stack_trace Depth Size Location (48 entries) ----- ---- -------- 0) 4824 216 ftrace_call+0x5/0x2f 1) 4608 112 ____cache_alloc+0xb7/0x22d 2) 4496 80 kmem_cache_alloc+0x63/0x12f The 216 size for ftrace_call includes both the ftrace_call stack (which includes the saving of registers it does), as well as the stack size of the parent. To fix this, if CC_USING_FENTRY is defined, then the stack_tracer will reserve the first item in stack_dump_trace[] array when calling save_stack_trace(), and it will fill it in with the parent ip. Then the code will look for the parent pointer on the stack and give the real size of the parent's stack pointer: # cat stack_trace Depth Size Location (14 entries) ----- ---- -------- 0) 2640 48 update_group_power+0x26/0x187 1) 2592 224 update_sd_lb_stats+0x2a5/0x4ac 2) 2368 160 find_busiest_group+0x31/0x1f1 3) 2208 256 load_balance+0xd9/0x662 I'm Cc'ing stable, although it's not urgent, as it only shows bogus size for item #0, the rest of the trace is legit. It should still be corrected in previous stable releases. Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 4a13a00a69fe14edc29fc8eaf11e4ffb5d1b1200 Author: Steven Rostedt (Red Hat) Date: Wed Mar 13 20:43:57 2013 -0400 tracing: Use stack of calling function for stack tracer commit 87889501d0adfae10e3b0f0e6f2d7536eed9ae84 upstream. Use the stack of stack_trace_call() instead of check_stack() as the test pointer for max stack size. It makes it a bit cleaner and a little more accurate. Adding stable, as a later fix depends on this patch. Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 0e16fac6740ff559a9fb61d26c8f89e263dbe126 Author: Mika Kuoppala Date: Mon Apr 22 14:19:26 2013 +0300 fbcon: when font is freed, clear also vc_font.data commit e6637d5427d2af9f3f33b95447bfc5347e5ccd85 upstream. commit ae1287865f5361fa138d4d3b1b6277908b54eac9 Author: Dave Airlie Date: Thu Jan 24 16:12:41 2013 +1000 fbcon: don't lose the console font across generic->chip driver switch uses a pointer in vc->vc_font.data to load font into the new driver. However if the font is actually freed, we need to clear the data so that we don't reload font from dangling pointer. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=892340 Signed-off-by: Mika Kuoppala Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 4299d4656505a6a3e6e49ab9f3a4f21485b8ea87 Author: Linus Torvalds Date: Wed May 1 07:32:21 2013 -0700 tty: fix up atime/mtime mess, take three commit b0b885657b6c8ef63a46bc9299b2a7715d19acde upstream. We first tried to avoid updating atime/mtime entirely (commit b0de59b5733d: "TTY: do not update atime/mtime on read/write"), and then limited it to only update it occasionally (commit 37b7f3c76595: "TTY: fix atime/mtime regression"), but it turns out that this was both insufficient and overkill. It was insufficient because we let people attach to the shared ptmx node to see activity without even reading atime/mtime, and it was overkill because the "only once a minute" means that you can't really tell an idle person from an active one with 'w'. So this tries to fix the problem properly. It marks the shared ptmx node as un-notifiable, and it lowers the "only once a minute" to a few seconds instead - still long enough that you can't time individual keystrokes, but short enough that you can tell whether somebody is active or not. Reported-by: Simon Kirby Acked-by: Jiri Slaby Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit b35abd4e63783b8b8a13866dcc5d2fd65dc3cee6 Author: Richard Cochran Date: Mon Apr 22 19:42:16 2013 +0000 gianfar: do not advertise any alarm capability. commit cd4baaaa04b4aaa3b0ec4d13a6f3d203b92eadbd upstream. An early draft of the PHC patch series included an alarm in the gianfar driver. During the review process, the alarm code was dropped, but the capability removal was overlooked. This patch fixes the issue by advertising zero alarms. This patch should be applied to every 3.x stable kernel. Signed-off-by: Richard Cochran Reported-by: Chris LaRocque Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 6b7ac849c11afb0a36f14e8515b07270a2c90e35 Author: Catalin Marinas Date: Mon Apr 29 15:07:45 2013 -0700 arm: set the page table freeing ceiling to TASK_SIZE commit 104ad3b32d7a71941c8ab2dee78eea38e8a23309 upstream. ARM processors with LPAE enabled use 3 levels of page tables, with an entry in the top level (pgd) covering 1GB of virtual space. Because of the branch relocation limitations on ARM, the loadable modules are mapped 16MB below PAGE_OFFSET, making the corresponding 1GB pgd shared between kernel modules and user space. If free_pgtables() is called with the default ceiling 0, free_pgd_range() (and subsequently called functions) also frees the page table shared between user space and kernel modules (which is normally handled by the ARM-specific pgd_free() function). This patch changes defines the ARM USER_PGTABLES_CEILING to TASK_SIZE when CONFIG_ARM_LPAE is enabled. Note that the pgd_free() function already checks the presence of the shared pmd page allocated by pgd_alloc() and frees it, though with ceiling 0 this wasn't necessary. Signed-off-by: Catalin Marinas Cc: Russell King Cc: Hugh Dickins Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 377dcc3af695bc2bd7e571f62d8accfb8e0733f1 Author: Federico Vaga Date: Mon Apr 15 16:01:07 2013 +0200 serial_core.c: add put_device() after device_find_child() commit 5a65dcc04cda41f4122aacc37a5a348454645399 upstream. The serial core uses device_find_child() but does not drop the reference to the retrieved child after using it. This patch add the missing put_device(). What I have done to test this issue. I used a machine with an AMBA PL011 serial driver. I tested the patch on next-20120408 because the last branch [next-20120415] does not boot on this board. For test purpose, I added some pr_info() messages to print the refcount after device_find_child() (lines: 1937,2009), and after put_device() (lines: 1947, 2021). Boot the machine *without* put_device(). Then: echo reboot > /sys/power/disk echo disk > /sys/power/state [ 87.058575] uart_suspend_port:1937 refcount 4 [ 87.058582] uart_suspend_port:1947 refcount 4 [ 87.098083] uart_resume_port:2009refcount 5 [ 87.098088] uart_resume_port:2021 refcount 5 echo disk > /sys/power/state [ 103.055574] uart_suspend_port:1937 refcount 6 [ 103.055580] uart_suspend_port:1947 refcount 6 [ 103.095322] uart_resume_port:2009 refcount 7 [ 103.095327] uart_resume_port:2021 refcount 7 echo disk > /sys/power/state [ 252.459580] uart_suspend_port:1937 refcount 8 [ 252.459586] uart_suspend_port:1947 refcount 8 [ 252.499611] uart_resume_port:2009 refcount 9 [ 252.499616] uart_resume_port:2021 refcount 9 The refcount continuously increased. Boot the machine *with* this patch. Then: echo reboot > /sys/power/disk echo disk > /sys/power/state [ 159.333559] uart_suspend_port:1937 refcount 4 [ 159.333566] uart_suspend_port:1947 refcount 3 [ 159.372751] uart_resume_port:2009 refcount 4 [ 159.372755] uart_resume_port:2021 refcount 3 echo disk > /sys/power/state [ 185.713614] uart_suspend_port:1937 refcount 4 [ 185.713621] uart_suspend_port:1947 refcount 3 [ 185.752935] uart_resume_port:2009 refcount 4 [ 185.752940] uart_resume_port:2021 refcount 3 echo disk > /sys/power/state [ 207.458584] uart_suspend_port:1937 refcount 4 [ 207.458591] uart_suspend_port:1947 refcount 3 [ 207.498598] uart_resume_port:2009 refcount 4 [ 207.498605] uart_resume_port:2021 refcount 3 The refcount correctly handled. Signed-off-by: Federico Vaga Signed-off-by: Greg Kroah-Hartman commit 7ede7ac52827b403b4a878011f71a354eb7e8de2 Author: Konrad Rzeszutek Wilk Date: Tue Apr 16 14:08:50 2013 -0400 xen/smp/spinlock: Fix leakage of the spinlock interrupt line for every CPU online/offline commit 66ff0fe9e7bda8aec99985b24daad03652f7304e upstream. While we don't use the spinlock interrupt line (see for details commit f10cd522c5fbfec9ae3cc01967868c9c2401ed23 - xen: disable PV spinlocks on HVM) - we should still do the proper init / deinit sequence. We did not do that correctly and for the CPU init for PVHVM guest we would allocate an interrupt line - but failed to deallocate the old interrupt line. This resulted in leakage of an irq_desc but more importantly this splat as we online an offlined CPU: genirq: Flags mismatch irq 71. 0002cc20 (spinlock1) vs. 0002cc20 (spinlock1) Pid: 2542, comm: init.late Not tainted 3.9.0-rc6upstream #1 Call Trace: [] __setup_irq+0x23e/0x4a0 [] ? kmem_cache_alloc_trace+0x221/0x250 [] request_threaded_irq+0xfb/0x160 [] ? xen_spin_trylock+0x20/0x20 [] bind_ipi_to_irqhandler+0xa3/0x160 [] ? kasprintf+0x38/0x40 [] ? xen_spin_trylock+0x20/0x20 [] ? update_max_interval+0x15/0x40 [] xen_init_lock_cpu+0x3c/0x78 [] xen_hvm_cpu_notify+0x29/0x33 [] notifier_call_chain+0x4d/0x70 [] __raw_notifier_call_chain+0x9/0x10 [] __cpu_notify+0x1b/0x30 [] _cpu_up+0xa0/0x14b [] cpu_up+0xd9/0xec [] store_online+0x94/0xd0 [] dev_attr_store+0x1b/0x20 [] sysfs_write_file+0xf4/0x170 [] vfs_write+0xb4/0x130 [] sys_write+0x5a/0xa0 [] system_call_fastpath+0x16/0x1b cpu 1 spinlock event irq -16 smpboot: Booting Node 0 Processor 1 APIC 0x2 And if one looks at the /proc/interrupts right after offlining (CPU1): 70: 0 0 xen-percpu-ipi spinlock0 71: 0 0 xen-percpu-ipi spinlock1 77: 0 0 xen-percpu-ipi spinlock2 There is the oddity of the 'spinlock1' still being present. Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman commit d9cdb8cadde392413f01d8182863d1727a43a60b Author: Konrad Rzeszutek Wilk Date: Tue Apr 16 13:49:26 2013 -0400 xen/smp: Fix leakage of timer interrupt line for every CPU online/offline. commit 888b65b4bc5e7fcbbb967023300cd5d44dba1950 upstream. In the PVHVM path when we do CPU online/offline path we would leak the timer%d IRQ line everytime we do a offline event. The online path (xen_hvm_setup_cpu_clockevents via x86_cpuinit.setup_percpu_clockev) would allocate a new interrupt line for the timer%d. But we would still use the old interrupt line leading to: kernel BUG at /home/konrad/ssd/konrad/linux/kernel/hrtimer.c:1261! invalid opcode: 0000 [#1] SMP RIP: 0010:[] [] hrtimer_interrupt+0x261/0x270 .. snip.. [] xen_timer_interrupt+0x2f/0x1b0 [] ? stop_machine_cpu_stop+0xb5/0xf0 [] handle_irq_event_percpu+0x7c/0x240 [] handle_percpu_irq+0x49/0x70 [] __xen_evtchn_do_upcall+0x1c3/0x2f0 [] xen_evtchn_do_upcall+0x2a/0x40 [] xen_hvm_callback_vector+0x6d/0x80 [] ? start_secondary+0x193/0x1a8 [] ? start_secondary+0x18f/0x1a8 There is also the oddity (timer1) in the /proc/interrupts after offlining CPU1: 64: 1121 0 xen-percpu-virq timer0 78: 0 0 xen-percpu-virq timer1 84: 0 2483 xen-percpu-virq timer2 This patch fixes it. Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman commit 037f6cd3f80e2777b758839055faaba00aab6e3d Author: Konrad Rzeszutek Wilk Date: Tue Apr 16 15:18:00 2013 -0400 xen/time: Fix kasprintf splat when allocating timer%d IRQ line. commit 7918c92ae9638eb8a6ec18e2b4a0de84557cccc8 upstream. When we online the CPU, we get this splat: smpboot: Booting Node 0 Processor 1 APIC 0x2 installing Xen timer for CPU 1 BUG: sleeping function called from invalid context at /home/konrad/ssd/konrad/linux/mm/slab.c:3179 in_atomic(): 1, irqs_disabled(): 0, pid: 0, name: swapper/1 Pid: 0, comm: swapper/1 Not tainted 3.9.0-rc6upstream-00001-g3884fad #1 Call Trace: [] __might_sleep+0xda/0x100 [] __kmalloc_track_caller+0x1e7/0x2c0 [] ? kasprintf+0x38/0x40 [] kvasprintf+0x5b/0x90 [] kasprintf+0x38/0x40 [] xen_setup_timer+0x30/0xb0 [] xen_hvm_setup_cpu_clockevents+0x1f/0x30 [] start_secondary+0x19c/0x1a8 The solution to that is use kasprintf in the CPU hotplug path that 'online's the CPU. That is, do it in in xen_hvm_cpu_notify, and remove the call to in xen_hvm_setup_cpu_clockevents. Unfortunatly the later is not a good idea as the bootup path does not use xen_hvm_cpu_notify so we would end up never allocating timer%d interrupt lines when booting. As such add the check for atomic() to continue. Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman commit d6ea7f37051e33e97ee34b17267b294ffa1e40c3 Author: Heiko Carstens Date: Thu Apr 25 10:03:15 2013 +0200 s390/memory hotplug: prevent offline of active memory increments commit 94c163663fc1dcfc067a5fb3cc1446b9469975ce upstream. In case a machine supports memory hotplug all active memory increments present at IPL time have been initialized with a "usecount" of 1. This is wrong if the memory increment size is larger than the memory section size of the memory hotplug code. If that is the case the usecount must be initialized with the number of memory sections that fit into one memory increment. Otherwise it is possible to put a memory increment into standby state even if there are still active sections. Afterwards addressing exceptions might happen which cause the kernel to panic. However even worse, if a memory increment was put into standby state and afterwards into active state again, it's contents would have been zeroed, leading to memory corruption. This was only an issue for machines that support standby memory and have at least 256GB memory. This is broken since commit fdb1bb15 "[S390] sclp/memory hotplug: fix initial usecount of increments". Signed-off-by: Heiko Carstens Reviewed-by: Gerald Schaefer Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit 107283031bae85952d53d7adc161d0880f5007ed Author: Tormod Volden Date: Sat Apr 20 14:24:04 2013 +0200 usb-storage: CY7C68300A chips do not support Cypress ATACB commit 671b4b2ba9266cbcfe7210a704e9ea487dcaa988 upstream. Many cards based on CY7C68300A/B/C use the USB ID 04b4:6830 but only the B and C variants (EZ-USB AT2LP) support the ATA Command Block functionality, according to the data sheets. The A variant (EZ-USB AT2) locks up if ATACB is attempted, until a typical 30 seconds timeout runs out and a USB reset is performed. https://bugs.launchpad.net/bugs/428469 It seems that one way to spot a CY7C68300A (at least where the card manufacturer left Cypress' EEPROM default vaules, against Cypress' recommendations) is to look at the USB string descriptor indices. A http://media.digikey.com/pdf/Data%20Sheets/Cypress%20PDFs/CY7C68300A.pdf B http://www.farnell.com/datasheets/43456.pdf C http://www.cypress.com/?rID=14189 Note that a CY7C68300B/C chip appears as CY7C68300A if it is running in Backward Compatibility Mode, and if ATACB would be supported in this case there is anyway no way to tell which chip it really is. For 5 years my external USB drive has been locking up for half a minute when plugged in and ata_id is run by udev, or anytime hdparm or similar is run on it. Finally looking at the /correct/ datasheet I think I found the reason. I am aware the quirk in this patch is a bit hacky, but the hardware manufacturers haven't made it easy for us. Signed-off-by: Tormod Volden Signed-off-by: Greg Kroah-Hartman commit 67dedab551ec62b7796039c74f15b9c720218aab Author: Shengzhou Liu Date: Wed Apr 17 18:03:46 2013 +0800 usb: remove redundant tdi_reset commit 61ac6ac8d662ac7ac67c864954d39d1b19948354 upstream. We remove the redundant tdi_reset in ehci_setup since there is already it in ehci_reset. It was observed that the duplicated tdi_reset was causing the PHY_CLK_VALID bit unstable. Reported-by: Michael Braun Signed-off-by: Shengzhou Liu Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman commit 515b5832d64840f842782fd077b4150f7baafbd1 Author: Michael Grzeschik Date: Thu Apr 4 13:13:47 2013 +0300 usb: chipidea: udc: fix memory leak in _ep_nuke commit 7ca2cd291fd84ae499390f227a255ccba2780a81 upstream. In hardware_enqueue code adds one extra td with dma_pool_alloc if mReq->req.zero is true. When _ep_nuke will be called for that endpoint, dma_pool_free will not be called to free that memory again. That patch fixes this. Signed-off-by: Michael Grzeschik Signed-off-by: Alexander Shishkin Signed-off-by: Greg Kroah-Hartman commit b52693dafea15c2f4b0feec336678395b5dfed8e Author: Michael Grzeschik Date: Thu Apr 4 13:13:46 2013 +0300 usb: chipidea: udc: fix memory access of shared memory on armv5 machines commit a9c174302b1590ef3ead485d804a303c5f89174b upstream. The udc uses an shared dma memory space between hard and software. This memory layout is described in ci13xxx_qh and ci13xxx_td which are marked with the attribute ((packed)). The compiler currently does not know about the alignment of the memory layout, and will create strb and ldrb operations. The Datasheet of the synopsys core describes, that some operations on the mapped memory need to be atomic double word operations. I.e. the next pointer addressing in the qhead, as otherwise the hardware will read wrong data and totally stuck. This is also possible while working with the current active td queue, and preparing the td->ptr.next in software while the hardware is still working with the current active td which is supposed to be changed: writeb(0xde, &td->ptr.next + 0x0); /* strb */ writeb(0xad, &td->ptr.next + 0x1); /* strb */ <----- hardware reads value of td->ptr.next and get stuck! writeb(0xbe, &td->ptr.next + 0x2); /* strb */ writeb(0xef, &td->ptr.next + 0x3); /* strb */ This appeares on armv5 machines where the hardware does not support unaligned 32bit operations. This patch adds the attribute ((aligned(4))) to the structures to tell the compiler to use 32bit operations. It also adds an wmb() for the prepared TD data before it gets enqueued into the qhead. Signed-off-by: Michael Grzeschik Reviewed-by: Felipe Balbi Signed-off-by: Alexander Shishkin Signed-off-by: Greg Kroah-Hartman commit 5578ba6bd451f8f7dc89019c9b197ea3ef6db6be Author: Hans de Goede Date: Tue Apr 16 11:08:33 2013 +0200 usbfs: Always allow ctrl requests with USB_RECIP_ENDPOINT on the ctrl ep commit 1361bf4b9f9ef45e628a5b89e0fd9bedfdcb7104 upstream. When usbfs receives a ctrl-request from userspace it calls check_ctrlrecip, which for a request with USB_RECIP_ENDPOINT tries to map this to an interface to see if this interface is claimed, except for ctrl-requests with a type of USB_TYPE_VENDOR. When trying to use this device: http://www.akaipro.com/eiepro redirected to a Windows vm running on qemu on top of Linux. The windows driver makes a ctrl-req with USB_TYPE_CLASS and USB_RECIP_ENDPOINT with index 0, and the mapping of the endpoint (0) to the interface fails since ep 0 is the ctrl endpoint and thus never is part of an interface. This patch fixes this ctrl-req failing by skipping the checkintf call for USB_RECIP_ENDPOINT ctrl-reqs on the ctrl endpoint. Reported-by: Dave Stikkolorum Tested-by: Dave Stikkolorum Signed-off-by: Hans de Goede Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman commit 73f78129b8c9b8213dd83232c64e85120c8ee9e2 Author: Adrian Thomasset Date: Wed Apr 24 11:37:35 2013 +0100 USB: ftdi_sio: enable two UART ports on ST Microconnect Lite commit 71d9a2b95fc9c9474d46d764336efd7a5a805555 upstream. The FT4232H used in the ST Micro Connect Lite has four hi-speed UART ports. The first two ports are reserved for the JTAG interface. We enable by default ports 2 and 3 as UARTs (where port 2 is a conventional RS-232 UART) Signed-off-by: Adrian Thomasset Signed-off-by: Greg Kroah-Hartman commit 072dbd59aa8e3aaeb6f39144b81e8a90f683e2f2 Author: Adrian Thomasset Date: Tue Apr 23 12:46:29 2013 +0100 USB: ftdi_sio: correct ST Micro Connect Lite PIDs commit 9f06d15f8db6946e41f73196a122b84a37938878 upstream. The current ST Micro Connect Lite uses the FT4232H hi-speed quad USB UART FTDI chip. It is also possible to drive STM reference targets populated with an on-board JTAG debugger based on the FT2232H chip with the same STMicroelectronics tools. For this reason, the ST Micro Connect Lite PIDs should be ST_STMCLT_2232_PID: 0x3746 ST_STMCLT_4232_PID: 0x3747 Signed-off-by: Adrian Thomasset Signed-off-by: Greg Kroah-Hartman commit 775994902ebd8c1d8a30e703e6c3de9f332eff22 Author: Stefani Seibold Date: Sun Apr 7 12:08:55 2013 +0200 USB: add ftdi_sio USB ID for GDM Boost V1.x commit 58f8b6c4fa5a13cb2ddb400e26e9e65766d71e38 upstream. This patch add a missing usb device id for the GDMBoost V1.x device The patch is against 3.9-rc5 Signed-off-by: Stefani Seibold Signed-off-by: Greg Kroah-Hartman commit b5bfe20124f1a2a6ff8acf5d8f16805906462772 Author: Ben Jencks Date: Tue Apr 2 00:35:08 2013 -0400 usb/misc/appledisplay: Add 24" LED Cinema display commit e7d3b6e22c871ba36d052ca99bc8ceca4d546a60 upstream. Add the Apple 24" LED Cinema display to the supported devices. Signed-off-by: Ben Jencks Signed-off-by: Greg Kroah-Hartman commit f3603003d7e5c71195606281a0bba4d2c087e9db Author: Johannes Berg Date: Wed Apr 17 11:26:40 2013 +0200 mac80211: fix station entry leak/warning while suspending commit b20d34c458bc2bbd0a4624f2933581e01e72d875 upstream. Since Stanislaw's patches, when suspending while connected, cfg80211 will disconnect. This causes the AP station to be removed, which uses call_rcu() to clean up. Due to needing process context, this queues a work struct on the mac80211 workqueue. This will warn and fail when already suspended, which can happen if the rcu call doesn't happen quickly. To fix this, replace the synchronize_net() which is really just synchronize_rcu_expedited() with rcu_barrier(), which unlike synchronize_rcu() waits until RCU callback have run and thus avoids this issue. In theory, this can even happen without Stanislaw's change to disconnect on suspend since userspace might disconnect just before suspending, though then it's unlikely that the call_rcu() will be delayed long enough. Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit e03eb5f7fe183ba234e9b096a08ff2cb1d27e50b Author: Yogesh Ashok Powar Date: Tue Apr 23 16:49:48 2013 -0700 mwifiex: Call pci_release_region after calling pci_disable_device commit 5b0d9b218b74042ff72bf4bfda6eeb2e4bf98397 upstream. "drivers should call pci_release_region() AFTER calling pci_disable_device()" Please refer section 3.2 Request MMIO/IOP resources in Documentation/PCI/pci.txt Signed-off-by: Avinash Patil Signed-off-by: Amitkumar Karwar Signed-off-by: Yogesh Ashok Powar Signed-off-by: Bing Zhao Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 1ded766000402267865ec2c96ef4759fe3402ff9 Author: Yogesh Ashok Powar Date: Tue Apr 23 16:49:47 2013 -0700 mwifiex: Use pci_release_region() instead of a pci_release_regions() commit c380aafb77b7435d010698fe3ca6d3e1cd745fde upstream. PCI regions are associated with the device using pci_request_region() call. Hence use pci_release_region() instead of pci_release_regions(). Signed-off-by: Yogesh Ashok Powar Signed-off-by: Amitkumar Karwar Signed-off-by: Avinash Patil Signed-off-by: Bing Zhao Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 6a30b99e412dbbaaca684efb88d4142d1b2309fa Author: Emmanuel Grumbach Date: Wed Apr 17 09:47:00 2013 +0300 iwlwifi: dvm: don't send zeroed LQ cmd commit 63b77bf489881747c5118476918cc8c29378ee63 upstream. When the stations are being restored because of unassoc RXON, the LQ cmd may not have been initialized because it is initialized only after association. Sending zeroed LQ_CMD makes the fw unhappy: it raises SYSASSERT_2078. Signed-off-by: Emmanuel Grumbach Reviewed-by: Johannes Berg [move zero_lq and make static const] Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 3b878e81dd0be24d6b0851266920c03519ad728b Author: Stanislaw Gruszka Date: Tue Apr 16 15:38:29 2013 +0200 iwlwifi: fix freeing uninitialized pointer commit 3309ccf7fcebceef540ebe90c65d2f94d745a45b upstream. If on iwl_dump_nic_event_log() error occurs before that function initialize buf, we process uninitiated pointer in iwl_dbgfs_log_event_read() and can hit "BUG at mm/slub.c:3409" Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=951241 Reported-by: ian.odette@eprize.com Signed-off-by: Stanislaw Gruszka Reviewed-by: Emmanuel Grumbach Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 0787640bbe69c1920ce70aecbb14b8a84cc42570 Author: Michael Ellerman Date: Tue Apr 23 15:13:14 2013 +0000 powerpc/spufs: Initialise inode->i_ino in spufs_new_inode() commit 6747e83235caecd30b186d1282e4eba7679f81b7 upstream. In commit 85fe402 (fs: do not assign default i_ino in new_inode), the initialisation of i_ino was removed from new_inode() and pushed down into the callers. However spufs_new_inode() was not updated. This exhibits as no files appearing in /spu, because all our dirents have a zero inode, which readdir() seems to dislike. Signed-off-by: Michael Ellerman Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 6c90fd94192868a473c7fdc064c93a865617cbae Author: Michael Neuling Date: Wed Apr 24 21:00:37 2013 +0000 powerpc/power8: Fix secondary CPUs hanging on boot for HV=0 commit 8c2a381734fc9718f127f4aba958e8a7958d4028 upstream. In __restore_cpu_power8 we determine if we are HV and if not, we return before setting HV only resources. Unfortunately we forgot to restore the link register from r11 before returning. This will happen on boot and with secondary CPUs not coming online. This adds the missing link register restore. Signed-off-by: Michael Neuling Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 1248f642860f89ae24eac527c0cc8a26b4fb6660 Author: Michael Neuling Date: Thu Apr 25 15:30:57 2013 +0000 powerpc: Fix hardware IRQs with MMU on exceptions when HV=0 commit 3e96ca7f007ddb06b82a74a68585d1dbafa85ff1 upstream. POWER8 allows us to take interrupts with the MMU on. This gives us a second set of vectors offset at 0x4000. Unfortunately when coping these vectors we missed checking for MSR HV for hardware interrupts (0x500). This results in us trying to use HSRR0/1 when HV=0, rather than SRR0/1 on HW IRQs The below fixes this to check CPU_FTR_HVMODE when patching the code at 0x4500. Also we remove the check for CPU_FTR_ARCH_206 since relocation on IRQs are only available in arch 2.07 and beyond. Thanks to benh for helping find this. Signed-off-by: Michael Neuling Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit a334da9ebc3115b0de621fbdf7e380407877af67 Author: Michael Neuling Date: Wed Apr 24 00:30:09 2013 +0000 powerpc: Add isync to copy_and_flush commit 29ce3c5073057991217916abc25628e906911757 upstream. In __after_prom_start we copy the kernel down to zero in two calls to copy_and_flush. After the first call (copy from 0 to copy_to_here:) we jump to the newly copied code soon after. Unfortunately there's no isync between the copy of this code and the jump to it. Hence it's possible that stale instructions could still be in the icache or pipeline before we branch to it. We've seen this on real machines and it's results in no console output after: calling quiesce... returning from prom_init The below adds an isync to ensure that the copy and flushing has completed before any branching to the new instructions occurs. Signed-off-by: Michael Neuling Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 79a18cca2a4a060c29fb8ed589556ac0f587cf42 Author: Nicolas Ferre Date: Thu Mar 21 18:01:42 2013 +0100 ARM: at91/trivial: typos in compatible property commit 2a5a461f179509142c661d79f878855798b85201 upstream. - unneeded whitespace - missing double quote Acked-by: Jean-Christophe PLAGNIOL-VILLARD Signed-off-by: Nicolas Ferre Signed-off-by: Greg Kroah-Hartman commit a8ad97411a406d6cdd0c9fb7e04865863cf3b43c Author: Nicolas Ferre Date: Wed Feb 20 17:32:20 2013 +0100 ARM: at91/trivial: fix model name for SAM9G15-EK commit 88fcb59a06556bf10eac97d7abb913cccea2c830 upstream. Acked-by: Jean-Christophe PLAGNIOL-VILLARD Signed-off-by: Nicolas Ferre Signed-off-by: Greg Kroah-Hartman commit 2910c9029d93688e66fcb645c3b2ea044a9286b1 Author: Maxime Ripard Date: Sat Mar 23 10:58:57 2013 +0100 ARM: at91: Fix typo in restart code panic message commit e7619459d47a673af3433208a42f583af920e9db upstream. Signed-off-by: Maxime Ripard Acked-by: Jean-Christophe PLAGNIOL-VILLARD Signed-off-by: Nicolas Ferre Signed-off-by: Greg Kroah-Hartman commit a7e8082538ab097012c8d46df9ddef643166c560 Author: Nicolas Ferre Date: Fri Mar 22 12:32:09 2013 +0100 ARM: at91: remove partial parameter in bootargs for at91sam9x5ek.dtsi commit b090e5f68c0353534880b95ea0df56b8c0230b8c upstream. Remove the malformed "mem=" bootargs parameter in at91sam9x5ek.dtsi Acked-by: Jean-Christophe PLAGNIOL-VILLARD Signed-off-by: Nicolas Ferre Signed-off-by: Greg Kroah-Hartman commit c3b519dd6c58ab536484c22bdcc5771517f16f10 Author: Douglas Gilbert Date: Thu Apr 4 18:19:55 2013 +0200 ARM: at91/at91sam9260.dtsi: fix u(s)art pinctrl encoding commit f10491fff07dcced77f8ab1b3bc1f8e18715bfb9 upstream. Signed-off-by: Douglas Gilbert [nicolas.ferre@atmel.com: fix rts/cts for usart3] Signed-off-by: Nicolas Ferre Signed-off-by: Greg Kroah-Hartman commit b82569c8f4c8c232c876c0c9bf6220d2839112f2 Author: Linus Walleij Date: Fri Apr 26 15:29:55 2013 +0200 ARM: u300: fix ages old copy/paste bug commit 0259d9eb30d003af305626db2d8332805696e60d upstream. The UART1 is on the fast AHB bridge, not on the slow bus. Acked-by: Arnd Bergmann Signed-off-by: Linus Walleij Signed-off-by: Olof Johansson Signed-off-by: Greg Kroah-Hartman commit 9d3629f8f6f74766ce9845214223cfb01c2b94d0 Author: Daniel Lezcano Date: Fri Mar 29 11:31:35 2013 +0100 ARM: omap3: cpuidle: enable time keeping commit 0d97558901c446a989de202a5d9ae94ec53644e5 upstream. The TIME_VALID flag is specified for the different states but the time residency computation is not done, no tk flag, no time computation in the idle function. Set the en_core_tk_irqen flag to activate it. Signed-off-by: Daniel Lezcano Acked-by: Santosh Shilimkar Signed-off-by: Kevin Hilman Signed-off-by: Greg Kroah-Hartman commit 3d9dbbde6c43d3e7f9d3047032113c3a75663e70 Author: Joerg Roedel Date: Wed Mar 27 01:43:14 2013 +0100 staging: zsmalloc: Fix link error on ARM commit d95abbbb291bf5bce078148f53603ce9c0aa1d44 upstream. Testing the arm chromebook config against the upstream kernel produces a linker error for the zsmalloc module from staging. The symbol flush_tlb_kernel_range is not available there. Fix this by removing the reimplementation of unmap_kernel_range in the zsmalloc module and using the function directly. The unmap_kernel_range function is not usable by modules, so also disallow building the driver as a module for now. Signed-off-by: Joerg Roedel Acked-by: Minchan Kim Signed-off-by: Greg Kroah-Hartman commit f1af230b00cafcee75328a631cbca0f656d95442 Author: Bjørn Mork Date: Tue Apr 9 11:26:02 2013 +0200 USB: option: add a D-Link DWM-156 variant commit a2a2d6c7f93e160b52a4ad0164db1f43f743ae0f upstream. Adding support for a Mediatek based device labelled as D-Link Model: DWM-156, H/W Ver: A7 Also adding two other device IDs found in the Debian(!) packages included on the embedded device driver CD. This is a composite MBIM + serial ports + card reader device: T: Bus=04 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 14 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=2001 ProdID=7d01 Rev= 3.00 S: Manufacturer=D-Link,Inc S: Product=D-Link DWM-156 C:* #Ifs= 7 Cfg#= 1 Atr=a0 MxPwr=500mA A: FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=0e Prot=00 I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=cdc_mbim E: Ad=88(I) Atr=03(Int.) MxPS= 64 Ivl=125us I: If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=02 Prot=01 Driver=option E: Ad=87(I) Atr=03(Int.) MxPS= 64 Ivl=500us E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 6 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms Signed-off-by: Bjørn Mork Signed-off-by: Greg Kroah-Hartman commit ebdb6d413bf0f1d1e1ae28e2d8b5bfa032aa28a8 Author: Filippo Turato Date: Sat Apr 20 15:04:08 2013 +0200 USB: serial: option: Added support Olivetti Olicard 145 commit d19bf5cedfd7d53854a3bd699c98b467b139833b upstream. This adds PID for Olivetti Olicard 145 in option.c Signed-off-by: Filippo Turato Signed-off-by: Greg Kroah-Hartman