commit 89b2a066a5c4a14e9bee3e16054c06a8400415e6 Author: Greg Kroah-Hartman Date: Sun Jul 6 18:59:25 2014 -0700 Linux 3.15.4 commit 6d4f6fb5a4f210a67b5d79b8b5bfd82d6918ab7e Author: Mengdong Lin Date: Thu Jun 26 18:45:16 2014 +0800 ALSA: hda - restore BCLK M/N values when resuming HSW/BDW display controller commit a07187c992be945ab561b370cbb49cfd72064c3c upstream. For Intel Haswell/Broadwell display HD-A controller, the 24MHz HD-A link BCLK is converted from Core Display Clock (CDCLK): BCLK = CDCLK * M / N And there are two registers EM4 and EM5 to program M, N value respectively. The EM4/EM5 values will be lost and when the display power well is disabled. BIOS programs CDCLK selected by OEM and EM4/EM5, but BIOS has no idea about display power well on/off at runtime. So the M/N can be wrong if non-default CDCLK is used when the audio controller resumes, which results in an invalid BCLK and abnormal audio playback rate. So this patch saves and restores valid M/N values on controller suspend/resume. And 'struct hda_intel' is defined to contain standard HD-A 'struct azx' and Intel specific fields, as Takashi suggested. Signed-off-by: Mengdong Lin Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 9931e761bc58ed208f51b047d958a12f0db89bda Author: Takashi Iwai Date: Tue Jun 24 13:55:25 2014 +0200 ALSA: hda - Adjust speaker HPF and add LED support for HP Spectre 13 commit 8b3dfdaf0c25a584cb31d04d2574115cf2d422ab upstream. HP Spectre 13 has the IDT 92HD95 codec, and BIOS seems to set the default high-pass filter in some "safer" range, which results in the very soft tone from the built-in speakers in contrast to Windows. Also, the mute LED control is missing, since 92HD95 codec still has no HP-specific fixups for GPIO setups. This patch adds these missing features: the HPF is adjusted by the vendor-specific verb, and the LED is set up from a DMI string (but with the default polarity = 0 assumption due to the incomplete BIOS on the given machine). Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=74841 Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 9d62370910e8cfbeecec7e20f81b097460796558 Author: Pierre Ossman Date: Wed Jun 18 21:48:09 2014 +0200 ALSA: hda - hdmi: call overridden init on resume commit a283368382c50345dff61525f493ea307f21ec9b upstream. We need to call the proper init function in case it has been overridden, as it might restore things that the generic routing doesn't know anything about. E.g. AMD cards have special verbs that need resetting. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=77901 Fixes: 5a61358433b1 ('ALSA: hda - hdmi: Add ATI/AMD multi-channel audio support') Signed-off-by: Pierre Ossman Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 760da6c274078dd66ad432f9599d5389822e1090 Author: Takashi Iwai Date: Wed Jun 25 14:24:47 2014 +0200 ALSA: usb-audio: Fix races at disconnection and PCM closing commit 92a586bdc06de6629dae1b357dac221253f55ff8 upstream. When a USB-audio device is disconnected while PCM is still running, we still see some race: the disconnect callback calls snd_usb_endpoint_free() that calls release_urbs() and then kfree() while a PCM stream would be closed at the same time and calls stop_endpoints() that leads to wait_clear_urbs(). That is, the EP object might be deallocated while a PCM stream is syncing with wait_clear_urbs() with the same EP. Basically calling multiple wait_clear_urbs() would work fine, also calling wait_clear_urbs() and release_urbs() would work, too, as wait_clear_urbs() just reads some fields in ep. The problem is the succeeding kfree() in snd_pcm_endpoint_free(). This patch moves out the EP deallocation into the later point, the destructor callback. At this stage, all PCMs must have been already closed, so it's safe to free the objects. Reported-by: Alan Stern Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 22e7649524323c35d868c639f349164fb8ef8455 Author: Oleg Nesterov Date: Sun Apr 13 20:58:54 2014 +0200 tracing: Fix syscall_*regfunc() vs copy_process() race commit 4af4206be2bd1933cae20c2b6fb2058dbc887f7c upstream. syscall_regfunc() and syscall_unregfunc() should set/clear TIF_SYSCALL_TRACEPOINT system-wide, but do_each_thread() can race with copy_process() and miss the new child which was not added to the process/thread lists yet. Change copy_process() to update the child's TIF_SYSCALL_TRACEPOINT under tasklist. Link: http://lkml.kernel.org/p/20140413185854.GB20668@redhat.com Fixes: a871bd33a6c0 "tracing: Add syscall tracepoints" Acked-by: Frederic Weisbecker Acked-by: Paul E. McKenney Signed-off-by: Oleg Nesterov Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit bdd1a65b62995eb29f93b2b0d54ef1f9b9a8ece3 Author: Steven Rostedt (Red Hat) Date: Fri May 30 09:42:39 2014 -0400 tracing: Try again for saved cmdline if failed due to locking commit 379cfdac37923653c9d4242d10052378b7563005 upstream. In order to prevent the saved cmdline cache from being filled when tracing is not active, the comms are only recorded after a trace event is recorded. The problem is, a comm can fail to be recorded if the trace_cmdline_lock is held. That lock is taken via a trylock to allow it to happen from any context (including NMI). If the lock fails to be taken, the comm is skipped. No big deal, as we will try again later. But! Because of the code that was added to only record after an event, we may not try again later as the recording is made as a oneshot per event per CPU. Only disable the recording of the comm if the comm is actually recorded. Fixes: 7ffbd48d5cab "tracing: Cache comms only after an event occurred" Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 866da94194a9f73095f0c6dd3e45425573b0da4d Author: Jacob Keller Date: Fri Jun 6 14:36:39 2014 -0700 Documentation/SubmittingPatches: describe the Fixes: tag commit 8401aa1f59975c03eeebd3ac6d264cbdfe9af5de upstream. Update the SubmittingPatches process to include howto about the new 'Fixes:' tag to be used when a patch fixes an issue in a previous commit (found by git-bisect for example). Signed-off-by: Jacob Keller Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Cc: Randy Dunlap Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit bbd637d4b8700d4eedbd2cb34cdea8b6b69a27f0 Author: Greg Kroah-Hartman Date: Thu Jul 3 16:06:57 2014 -0700 lz4: add overrun checks to lz4_uncompress_unknownoutputsize() commit 4a3a99045177369700c60d074c0e525e8093b0fc upstream. Jan points out that I forgot to make the needed fixes to the lz4_uncompress_unknownoutputsize() function to mirror the changes done in lz4_decompress() with regards to potential pointer overflows. The only in-kernel user of this function is the zram code, which only takes data from a valid compressed buffer that it made itself, so it's not a big issue. But due to external kernel modules using this function, it's better to be safe here. Reported-by: Jan Beulich Cc: "Don A. Bailey" Signed-off-by: Greg Kroah-Hartman commit ac79fd540a0282460a22955753056c4a636b620b Author: Tejun Heo Date: Thu Jul 3 15:43:15 2014 -0400 ptrace,x86: force IRET path after a ptrace_stop() commit b9cd18de4db3c9ffa7e17b0dc0ca99ed5aa4d43a upstream. The 'sysret' fastpath does not correctly restore even all regular registers, much less any segment registers or reflags values. That is very much part of why it's faster than 'iret'. Normally that isn't a problem, because the normal ptrace() interface catches the process using the signal handler infrastructure, which always returns with an iret. However, some paths can get caught using ptrace_event() instead of the signal path, and for those we need to make sure that we aren't going to return to user space using 'sysret'. Otherwise the modifications that may have been done to the register set by the tracer wouldn't necessarily take effect. Fix it by forcing IRET path by setting TIF_NOTIFY_RESUME from arch_ptrace_stop_needed() which is invoked from ptrace_stop(). Signed-off-by: Tejun Heo Reported-by: Andy Lutomirski Acked-by: Oleg Nesterov Suggested-by: Linus Torvalds Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit d737e6aba63044d9d77ee127beefc2b549abce03 Author: Deng-Cheng Zhu Date: Tue Jun 24 10:31:08 2014 -0700 MIPS: KVM: Fix memory leak on VCPU commit 8c9eb041cf76038eb3b62ee259607eec9b89f48d upstream. kvm_arch_vcpu_free() is called in 2 code paths: 1) kvm_vm_ioctl() kvm_vm_ioctl_create_vcpu() kvm_arch_vcpu_destroy() kvm_arch_vcpu_free() 2) kvm_put_kvm() kvm_destroy_vm() kvm_arch_destroy_vm() kvm_mips_free_vcpus() kvm_arch_vcpu_free() Neither of the paths handles VCPU free. We need to do it in kvm_arch_vcpu_free() corresponding to the memory allocation in kvm_arch_vcpu_create(). Signed-off-by: Deng-Cheng Zhu Reviewed-by: James Hogan Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 458f9d65705447e9e4340f13ecd304a3899d0108 Author: James Hogan Date: Thu May 29 10:16:44 2014 +0100 MIPS: KVM: Remove redundant NULL checks before kfree() commit c6c0a6637f9da54f9472144d44f71cf847f92e20 upstream. The kfree() function already NULL checks the parameter so remove the redundant NULL checks before kfree() calls in arch/mips/kvm/. Signed-off-by: James Hogan Cc: Paolo Bonzini Cc: Gleb Natapov Cc: kvm@vger.kernel.org Cc: Ralf Baechle Cc: linux-mips@linux-mips.org Cc: Sanjay Lal Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit dd0bcbeae6ddc9658b1738ab5499cf379d5d418e Author: Aaron Plattner Date: Wed Jun 18 11:27:32 2014 -0700 cpufreq: unlock when failing cpufreq_update_policy() commit fefa8ff810c5ab4c4206aed9d159c4d6fe8d4f1c upstream. Commit bd0fa9bb455d introduced a failure path to cpufreq_update_policy() if cpufreq_driver->get(cpu) returns NULL. However, it jumps to the 'no_policy' label, which exits without unlocking any of the locks the function acquired earlier. This causes later calls into cpufreq to hang. Fix this by creating a new 'unlock' label and jumping to that instead. Fixes: bd0fa9bb455d ("cpufreq: Return error if ->get() failed in cpufreq_update_policy()") Link: https://devtalk.nvidia.com/default/topic/751903/kernel-3-15-and-nv-drivers-337-340-failed-to-initialize-the-nvidia-kernel-module-gtx-550-ti-/ Signed-off-by: Aaron Plattner Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 328484c47819ed474534e56deee41c5c6c76ad19 Author: Ed Swarthout Date: Thu Jun 5 18:56:17 2014 -0500 cpufreq: ppc-corenet-cpu-freq: do_div use quotient commit 906fe033145aab7d65a428bfda2cf19c75720894 upstream. Commit 6712d2931933 (cpufreq: ppc-corenet-cpufreq: Fix __udivdi3 modpost error) used the remainder from do_div instead of the quotient. Fix that and add one to ensure minimum is met. Fixes: 6712d2931933 (cpufreq: ppc-corenet-cpufreq: Fix __udivdi3 modpost error) Signed-off-by: Ed Swarthout Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 3d8e24ef90f331379ab066b7f9d0889be5e3e8d1 Author: Jeff Mahoney Date: Wed May 21 13:28:07 2014 -0400 reiserfs: call truncate_setsize under tailpack mutex commit 22e7478ddbcb670e33fab72d0bbe7c394c3a2c84 upstream. Prior to commit 0e4f6a791b1e (Fix reiserfs_file_release()), reiserfs truncates serialized on i_mutex. They mostly still do, with the exception of reiserfs_file_release. That blocks out other writers via the tailpack mutex and the inode openers counter adjusted in reiserfs_file_open. However, NFS will call reiserfs_setattr without having called ->open, so we end up with a race when nfs is calling ->setattr while another process is releasing the file. Ultimately, it triggers the BUG_ON(inode->i_size != new_file_size) check in maybe_indirect_to_direct. The solution is to pull the lock into reiserfs_setattr to encompass the truncate_setsize call as well. Signed-off-by: Jeff Mahoney Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit 008643fecc2f65accbaccc2f1b97cc56cb5bd42a Author: Dave Chinner Date: Fri Jun 6 16:00:43 2014 +1000 xfs: xfs_readsb needs to check for magic numbers commit 556b8883cfac3d3203557e161ea8005f8b5479b2 upstream. Commit daba542 ("xfs: skip verification on initial "guess" superblock read") dropped the use of a verifier for the initial superblock read so we can probe the sector size of the filesystem stored in the superblock. It, however, now fails to validate that what was read initially is actually an XFS superblock and hence will fail the sector size check and return ENOSYS. This causes probe-based mounts to fail because it expects XFS to return EINVAL when it doesn't recognise the superblock format. Reported-by: Plamen Petrov Tested-by: Plamen Petrov Signed-off-by: Dave Chinner Reviewed-by: Christoph Hellwig Signed-off-by: Dave Chinner Signed-off-by: Greg Kroah-Hartman commit f1ee6ff83edd96a756b6c986d50a92e772bc5ed4 Author: Scott Wood Date: Tue Jun 24 20:15:51 2014 -0500 powerpc: Don't skip ePAPR spin-table CPUs commit 6663a4fa6711050036562ddfd2086edf735fae21 upstream. Commit 59a53afe70fd530040bdc69581f03d880157f15a "powerpc: Don't setup CPUs with bad status" broke ePAPR SMP booting. ePAPR says that CPUs that aren't presently running shall have status of disabled, with enable-method being used to determine whether the CPU can be enabled. Fix by checking for spin-table, which is currently the only supported enable-method. Signed-off-by: Scott Wood Cc: Michael Neuling Cc: Emil Medve Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 99860b1d9cc9f6900af7e1b2a33441dea900c2be Author: Benjamin Herrenschmidt Date: Tue Jun 10 15:04:40 2014 +1000 powerpc: Add AT_HWCAP2 to indicate V.CRYPTO category support commit dd58a092c4202f2bd490adab7285b3ff77f8e467 upstream. The Vector Crypto category instructions are supported by current POWER8 chips, advertise them to userspace using a specific bit to properly differentiate with chips of the same architecture level that might not have them. Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 9cd68f06722d52ea568ab1bc408487909a319389 Author: Michael Neuling Date: Fri Jun 6 14:28:51 2014 +1000 powerpc: Don't setup CPUs with bad status commit 59a53afe70fd530040bdc69581f03d880157f15a upstream. OPAL will mark a CPU that is guarded as "bad" in the status property of the CPU node. Unfortunatley Linux doesn't check this property and will put the bad CPU in the present map. This has caused hangs on booting when we try to unsplit the core. This patch checks the CPU is avaliable via this status property before putting it in the present map. Signed-off-by: Michael Neuling Tested-by: Anton Blanchard Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit f45e075fcbc5a2ce9c60f34e9fe78a86cb780bad Author: Paul Bolle Date: Tue May 20 21:59:42 2014 +0200 powerpc: fix typo 'CONFIG_PPC_CPU' commit b69a1da94f3d1589d1942b5d1b384d8cfaac4500 upstream. Commit cd64d1697cf0 ("powerpc: mtmsrd not defined") added a check for CONFIG_PPC_CPU were a check for CONFIG_PPC_FPU was clearly intended. Fixes: cd64d1697cf0 ("powerpc: mtmsrd not defined") Signed-off-by: Paul Bolle Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit feb6334d1c3b1678a6eaa5a6f93ba0cc6bd8d953 Author: Michael Ellerman Date: Tue Jun 10 16:46:21 2014 +1000 powerpc/perf: Ensure all EBB register state is cleared on fork() commit 3df48c981d5a9610e02e9270b1bc4274fb536710 upstream. In commit 330a1eb "Core EBB support for 64-bit book3s" I messed up clear_task_ebb(). It clears some but not all of the task's Event Based Branch (EBB) registers when we duplicate a task struct. That allows a child task to observe the EBBHR & EBBRR of its parent, which it should not be able to do. Fix it by clearing EBBHR & EBBRR. Signed-off-by: Michael Ellerman Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 8ae1bea30532b765c1fb340d6531bf1772de5ee2 Author: Paul Bolle Date: Tue May 20 22:24:58 2014 +0200 powerpc: fix typo 'CONFIG_PMAC' commit 6e0fdf9af216887e0032c19d276889aad41cad00 upstream. Commit b0d278b7d3ae ("powerpc/perf_event: Reduce latency of calling perf_event_do_pending") added a check for CONFIG_PMAC were a check for CONFIG_PPC_PMAC was clearly intended. Fixes: b0d278b7d3ae ("powerpc/perf_event: Reduce latency of calling perf_event_do_pending") Signed-off-by: Paul Bolle Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 3c777e6b95964f5a170f4d49b99dbbf3badf4433 Author: Anton Blanchard Date: Wed Jun 4 10:48:48 2014 +1000 powerpc: 64bit sendfile is capped at 2GB commit 5d73320a96fcce80286f1447864c481b5f0b96fa upstream. commit 8f9c0119d7ba (compat: fs: Generic compat_sys_sendfile implementation) changed the PowerPC 64bit sendfile call from sys_sendile64 to sys_sendfile. Unfortunately this broke sendfile of lengths greater than 2G because sys_sendfile caps at MAX_NON_LFS. Restore what we had previously which fixes the bug. Signed-off-by: Anton Blanchard Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 9553083aa0a8d12b41b340057de726005d9a54c7 Author: Benjamin Herrenschmidt Date: Tue Jun 3 17:33:41 2014 +1000 powerpc/serial: Use saner flags when creating legacy ports commit c4cad90f9e9dcb85afc5e75a02ae3522ed077296 upstream. We had a mix & match of flags used when creating legacy ports depending on where we found them in the device-tree. Among others we were missing UPF_SKIP_TEST for some kind of ISA ports which is a problem as quite a few UARTs out there don't support the loopback test (such as a lot of BMCs). Let's pick the set of flags used by the SoC code and generalize it which means autoconf, no loopback test, irq maybe shared and fixed port. Sending to stable as the lack of UPF_SKIP_TEST is breaking serial on some machines so I want this back into distros Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit d1c8b9f6dcaff940d41bf00245bd05af3fd72bf9 Author: Michael Ellerman Date: Wed May 28 18:21:17 2014 +1000 powerpc/mm: Check paca psize is up to date for huge mappings commit 09567e7fd44291bfc08accfdd67ad8f467842332 upstream. We have a bug in our hugepage handling which exhibits as an infinite loop of hash faults. If the fault is being taken in the kernel it will typically trigger the softlockup detector, or the RCU stall detector. The bug is as follows: 1. mmap(0xa0000000, ..., MAP_FIXED | MAP_HUGE_TLB | MAP_ANONYMOUS ..) 2. Slice code converts the slice psize to 16M. 3. The code on lines 539-540 of slice.c in slice_get_unmapped_area() synchronises the mm->context with the paca->context. So the paca slice mask is updated to include the 16M slice. 3. Either: * mmap() fails because there are no huge pages available. * mmap() succeeds and the mapping is then munmapped. In both cases the slice psize remains at 16M in both the paca & mm. 4. mmap(0xa0000000, ..., MAP_FIXED | MAP_ANONYMOUS ..) 5. The slice psize is converted back to 64K. Because of the check on line 539 of slice.c we DO NOT update the paca->context. The paca slice mask is now out of sync with the mm slice mask. 6. User/kernel accesses 0xa0000000. 7. The SLB miss handler slb_allocate_realmode() **uses the paca slice mask** to create an SLB entry and inserts it in the SLB. 18. With the 16M SLB entry in place the hardware does a hash lookup, no entry is found so a data access exception is generated. 19. The data access handler calls do_page_fault() -> handle_mm_fault(). 10. __handle_mm_fault() creates a THP mapping with do_huge_pmd_anonymous_page(). 11. The hardware retries the access, there is still nothing in the hash table so once again a data access exception is generated. 12. hash_page() calls into __hash_page_thp() and inserts a mapping in the hash. Although the THP mapping maps 16M the hashing is done using 64K as the segment page size. 13. hash_page() returns immediately after calling __hash_page_thp(), skipping over the code at line 1125. Resulting in the mismatch between the paca->context and mm->context not being detected. 14. The hardware retries the access, the hash it generates using the 16M SLB entry does NOT match the hash we inserted. 15. We take another data access and go into __hash_page_thp(). 16. We see a valid entry in the hpte_slot_array and so we call updatepp() which succeeds. 17. Goto 14. We could fix this in two ways. The first would be to remove or modify the check on line 539 of slice.c. The second option is to cause the check of paca psize in hash_page() on line 1125 to also be done for THP pages. We prefer the latter, because the check & update of the paca psize is not done until we know it's necessary. It's also done only on the current cpu, so we don't need to IPI all other cpus. Without further rearranging the code, the simplest fix is to pull out the code that checks paca psize and call it in two places. Firstly for THP/hugetlb, and secondly for other mappings as before. Thanks to Dave Jones for trinity, which originally found this bug. Signed-off-by: Michael Ellerman Reviewed-by: Aneesh Kumar K.V Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 948eccfe9a3f7253f5ea268ff9db2ebdb67005c1 Author: Anton Blanchard Date: Sat Jun 7 11:29:01 2014 +1000 powernv: Fix permissions on sysparam sysfs entries commit 1bd098903fda069cb96fe8b5cb4595b46c683385 upstream. Everyone can write to these files, which is not what we want. Signed-off-by: Anton Blanchard Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit b180a6567ac315d7f244e7f52cb46774f9967e66 Author: Gavin Shan Date: Thu Apr 24 18:00:21 2014 +1000 powerpc/pseries: Fix overwritten PE state commit 54f112a3837d4e7532bbedbbbf27c0de277be510 upstream. In pseries_eeh_get_state(), EEH_STATE_UNAVAILABLE is always overwritten by EEH_STATE_NOT_SUPPORT because of the missed "break" there. The patch fixes the issue. Reported-by: Joe Perches Signed-off-by: Gavin Shan Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 716f02ac00a77c14cdf18de2e75e49e68e46e1e8 Author: Scott Mayhew Date: Fri Jun 20 08:44:42 2014 -0400 nfs: Fix cache_validity check in nfs_write_pageuptodate() commit 18dd78c427513fb0f89365138be66e6ee8700d1b upstream. NFS_INO_INVALID_DATA cannot be ignored, even if we have a delegation. We're still having some problems with data corruption when multiple clients are appending to a file and those clients are being granted write delegations on open. To reproduce: Client A: vi /mnt/`hostname -s` while :; do echo "XXXXXXXXXXXXXXX" >>/mnt/file; sleep $(( $RANDOM % 5 )); done Client B: vi /mnt/`hostname -s` while :; do echo "YYYYYYYYYYYYYYY" >>/mnt/file; sleep $(( $RANDOM % 5 )); done What's happening is that in nfs_update_inode() we're recognizing that the file size has changed and we're setting NFS_INO_INVALID_DATA accordingly, but then we ignore the cache_validity flags in nfs_write_pageuptodate() because we have a delegation. As a result, in nfs_updatepage() we're extending the write to cover the full page even though we've not read in the data to begin with. Signed-off-by: Scott Mayhew Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit ff177fb44d47f46567543127e3ad42936b31c71f Author: Mateusz Guzik Date: Tue Jun 10 12:44:12 2014 +0200 NFS: populate ->net in mount data when remounting commit a914722f333b3359d2f4f12919380a334176bb89 upstream. Otherwise the kernel oopses when remounting with IPv6 server because net is dereferenced in dev_get_by_name. Use net ns of current thread so that dev_get_by_name does not operate on foreign ns. Changing the address is prohibited anyway so this should not affect anything. Signed-off-by: Mateusz Guzik Cc: linux-nfs@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit ca3fd5c679515e152f2e7feb980ebe8c444d5b18 Author: Trond Myklebust Date: Thu Jun 5 10:42:37 2014 -0400 NFS: Use raw_write_seqcount_begin/end int nfs4_reclaim_open_state commit abbec2da13f0e4c5d9b78b7e2c025a3e617228ba upstream. The addition of lockdep code to write_seqcount_begin/end has lead to a bunch of false positive claims of ABBA deadlocks with the so_lock spinlock. Audits show that this simply cannot happen because the read side code does not spin while holding so_lock. Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 7b2ffd05bdc009f6671a638138348c82fdc0267a Author: Trond Myklebust Date: Tue Apr 15 10:07:57 2014 -0400 NFS: Don't declare inode uptodate unless all attributes were checked commit 43b6535e717d2f656f71d9bd16022136b781c934 upstream. Fix a bug, whereby nfs_update_inode() was declaring the inode to be up to date despite not having checked all the attributes. The bug occurs because the temporary variable in which we cache the validity information is 'sanitised' before reapplying to nfsi->cache_validity. Reported-by: Kinglong Mee Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 9024c373998c6742a2fec0889d791fccc3e5efa0 Author: Christoph Hellwig Date: Wed May 28 10:46:13 2014 +0200 nfsd: getattr for FATTR4_WORD0_FILES_AVAIL needs the statfs buffer commit 12337901d654415d9f764b5f5ba50052e9700f37 upstream. Note nobody's ever noticed because the typical client probably never requests FILES_AVAIL without also requesting something else on the list. Signed-off-by: Christoph Hellwig Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 7e2f54792d45ff623ddaf424fbaf17d20e3e4246 Author: J. Bruce Fields Date: Tue May 27 11:14:26 2014 -0400 nfsd4: fix FREE_STATEID lockowner leak commit 48385408b45523d9a432c66292d47ef43efcbb94 upstream. 27b11428b7de ("nfsd4: remove lockowner when removing lock stateid") introduced a memory leak. Reported-by: Jeff Layton Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit a01b18de19cdb51dc0389ccc54120735c3a46d1b Author: Trond Myklebust Date: Thu May 29 20:06:55 2014 -0400 pNFS: Handle allocation errors correctly in filelayout_alloc_layout_hdr() commit 6df200f5d5191bdde4d2e408215383890f956781 upstream. Return the NULL pointer when the allocation fails. Reported-by: Fengguang Wu Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit fe5320465fe885510598a9e4be72189d5a82f605 Author: Trond Myklebust Date: Sun May 18 14:05:22 2014 -0400 SUNRPC: Fix a module reference leak in svc_handle_xprt commit c789102c20bbbdda6831a273e046715be9d6af79 upstream. If the accept() call fails, we need to put the module reference. Signed-off-by: Trond Myklebust Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 7022c10a56e5a2f094aec8ee364ece22773746e3 Author: Bart Van Assche Date: Fri Jun 6 18:25:04 2014 +0200 IB/umad: Fix use-after-free on close commit 60e1751cb52cc6d1ae04b6bd3c2b96e770b5823f upstream. Avoid that closing /dev/infiniband/umad or /dev/infiniband/issm triggers a use-after-free. __fput() invokes f_op->release() before it invokes cdev_put(). Make sure that the ib_umad_device structure is freed by the cdev_put() call instead of f_op->release(). This avoids that changing the port mode from IB into Ethernet and back to IB followed by restarting opensmd triggers the following kernel oops: general protection fault: 0000 [#1] PREEMPT SMP RIP: 0010:[] [] module_put+0x2c/0x170 Call Trace: [] cdev_put+0x20/0x30 [] __fput+0x1ae/0x1f0 [] ____fput+0xe/0x10 [] task_work_run+0xac/0xe0 [] do_notify_resume+0x9f/0xc0 [] int_signal+0x12/0x17 Reference: https://bugzilla.kernel.org/show_bug.cgi?id=75051 Signed-off-by: Bart Van Assche Reviewed-by: Yann Droneaud Signed-off-by: Roland Dreier Signed-off-by: Greg Kroah-Hartman commit ca467005c452ed79b90f92419a6c77c3c515de2a Author: Bart Van Assche Date: Tue May 20 10:33:41 2014 +0200 IB/umad: Fix error handling commit 8ec0a0e6b58218bdc1db91dd70ebfcd6ad8dd6cd upstream. Avoid leaking a kref count in ib_umad_open() if port->ib_dev == NULL or if nonseekable_open() fails. Avoid leaking a kref count, that sm_sem is kept down and also that the IB_PORT_SM capability mask is not cleared in ib_umad_sm_open() if nonseekable_open() fails. Since container_of() never returns NULL, remove the code that tests whether container_of() returns NULL. Moving the kref_get() call from the start of ib_umad_*open() to the end is safe since it is the responsibility of the caller of these functions to ensure that the cdev pointer remains valid until at least when these functions return. Signed-off-by: Bart Van Assche [ydroneaud@opteya.com: rework a bit to reduce the amount of code changed] Signed-off-by: Yann Droneaud [ nonseekable_open() can't actually fail, but.... - Roland ] Signed-off-by: Roland Dreier Signed-off-by: Greg Kroah-Hartman commit 91439e675cb101d19d349465d3329e3a7db46793 Author: Bart Van Assche Date: Tue May 20 15:03:49 2014 +0200 IB/srp: Fix a sporadic crash triggered by cable pulling commit 024ca90151f5e4296d30f72c13ff9a075e23c9ec upstream. Avoid that the loops that iterate over the request ring can encounter a pointer to a SCSI command in req->scmnd that is no longer associated with that request. If the function srp_unmap_data() is invoked twice for a SCSI command that is not in flight then that would cause ib_fmr_pool_unmap() to be invoked with an invalid pointer as argument, resulting in a kernel oops. Reported-by: Sagi Grimberg Reference: http://thread.gmane.org/gmane.linux.drivers.rdma/19068/focus=19069 Signed-off-by: Bart Van Assche Reviewed-by: Sagi Grimberg Signed-off-by: Roland Dreier Signed-off-by: Greg Kroah-Hartman commit 464fbb1f0dd3b9d4e53bdae2d61d2f338d96a494 Author: Dennis Dalessandro Date: Fri May 2 11:40:17 2014 -0400 IB/ipath: Translate legacy diagpkt into newer extended diagpkt commit 7e6d3e5c70f13874fb06e6b67696ed90ce79bd48 upstream. This patch addresses an issue where the legacy diagpacket is sent in from the user, but the driver operates on only the extended diagpkt. This patch specifically initializes the extended diagpkt based on the legacy packet. Reported-by: Rickard Strandqvist Reviewed-by: Mike Marciniszyn Signed-off-by: Dennis Dalessandro Signed-off-by: Roland Dreier Signed-off-by: Greg Kroah-Hartman commit cbb9d902bb0216079cf6f29fab9851eb48307409 Author: Mike Marciniszyn Date: Fri May 2 11:28:04 2014 -0400 IB/qib: Fix port in pkey change event commit 911eccd284d13d78c92ec4f1f1092c03457d732a upstream. The code used a literal 1 in dispatching an IB_EVENT_PKEY_CHANGE. As of the dual port qib QDR card, this is not necessarily correct. Change to use the port as specified in the call. Reported-by: Alex Estrin Reviewed-by: Dennis Dalessandro Signed-off-by: Mike Marciniszyn Signed-off-by: Roland Dreier Signed-off-by: Greg Kroah-Hartman commit 0151759dd37044fd2cb44d6eef8d63bb16b0b47e Author: Yann Droneaud Date: Mon May 5 19:33:22 2014 +0200 IB/mlx5: add missing padding at end of struct mlx5_ib_create_srq commit 43bc889380c2ad9aa230eccc03a15cc52cf710d4 upstream. The i386 ABI disagrees with most other ABIs regarding alignment of data type larger than 4 bytes: on most ABIs a padding must be added at end of the structures, while it is not required on i386. So for most ABIs struct mlx5_ib_create_srq gets implicitly padded to be aligned on a 8 bytes multiple, while for i386, such padding is not added. Tool pahole could be used to find such implicit padding: $ pahole --anon_include \ --nested_anon_include \ --recursive \ --class_name mlx5_ib_create_srq \ drivers/infiniband/hw/mlx5/mlx5_ib.o Then, structure layout can be compared between i386 and x86_64: # +++ obj-i386/drivers/infiniband/hw/mlx5/mlx5_ib.o.pahole.txt 2014-03-28 11:43:07.386413682 +0100 # --- obj-x86_64/drivers/infiniband/hw/mlx5/mlx5_ib.o.pahole.txt 2014-03-27 13:06:17.788472721 +0100 # @@ -69,7 +68,6 @@ struct mlx5_ib_create_srq { # __u64 db_addr; /* 8 8 */ # __u32 flags; /* 16 4 */ # # - /* size: 20, cachelines: 1, members: 3 */ # - /* last cacheline: 20 bytes */ # + /* size: 24, cachelines: 1, members: 3 */ # + /* padding: 4 */ # + /* last cacheline: 24 bytes */ # }; ABI disagreement will make an x86_64 kernel try to read past the buffer provided by an i386 binary. When boundary check will be implemented, the x86_64 kernel will refuse to read past the i386 userspace provided buffer and the uverb will fail. Anyway, if the structure lay in memory on a page boundary and next page is not mapped, ib_copy_from_udata() will fail and the uverb will fail. This patch makes create_srq_user() takes care of the input data size to handle the case where no padding was provided. This way, x86_64 kernel will be able to handle struct mlx5_ib_create_srq as sent by unpatched and patched i386 libmlx5. Link: http://marc.info/?i=cover.1399309513.git.ydroneaud@opteya.com Fixes: e126ba97dba9e ("mlx5: Add driver for Mellanox Connect-IB adapter") Signed-off-by: Yann Droneaud Signed-off-by: Roland Dreier Signed-off-by: Greg Kroah-Hartman commit bcdd10a31eae267c10fd4c73fa834e74defc936b Author: Yann Droneaud Date: Mon May 5 19:33:21 2014 +0200 IB/mlx5: add missing padding at end of struct mlx5_ib_create_cq commit a8237b32a3faab155a5dc8f886452147ce73da3e upstream. The i386 ABI disagrees with most other ABIs regarding alignment of data type larger than 4 bytes: on most ABIs a padding must be added at end of the structures, while it is not required on i386. So for most ABI struct mlx5_ib_create_cq get padded to be aligned on a 8 bytes multiple, while for i386, such padding is not added. The tool pahole can be used to find such implicit padding: $ pahole --anon_include \ --nested_anon_include \ --recursive \ --class_name mlx5_ib_create_cq \ drivers/infiniband/hw/mlx5/mlx5_ib.o Then, structure layout can be compared between i386 and x86_64: # +++ obj-i386/drivers/infiniband/hw/mlx5/mlx5_ib.o.pahole.txt 2014-03-28 11:43:07.386413682 +0100 # --- obj-x86_64/drivers/infiniband/hw/mlx5/mlx5_ib.o.pahole.txt 2014-03-27 13:06:17.788472721 +0100 # @@ -34,9 +34,8 @@ struct mlx5_ib_create_cq { # __u64 db_addr; /* 8 8 */ # __u32 cqe_size; /* 16 4 */ # # - /* size: 20, cachelines: 1, members: 3 */ # - /* last cacheline: 20 bytes */ # + /* size: 24, cachelines: 1, members: 3 */ # + /* padding: 4 */ # + /* last cacheline: 24 bytes */ # }; This ABI disagreement will make an x86_64 kernel try to read past the buffer provided by an i386 binary. When boundary check will be implemented, a x86_64 kernel will refuse to read past the i386 userspace provided buffer and the uverb will fail. Anyway, if the structure lies in memory on a page boundary and next page is not mapped, ib_copy_from_udata() will fail when trying to read the 4 bytes of padding and the uverb will fail. This patch makes create_cq_user() takes care of the input data size to handle the case where no padding is provided. This way, x86_64 kernel will be able to handle struct mlx5_ib_create_cq as sent by unpatched and patched i386 libmlx5. Link: http://marc.info/?i=cover.1399309513.git.ydroneaud@opteya.com Fixes: e126ba97dba9e ("mlx5: Add driver for Mellanox Connect-IB adapter") Signed-off-by: Yann Droneaud Signed-off-by: Roland Dreier Signed-off-by: Greg Kroah-Hartman commit bf63ac69a549156f5a75763ff27de9d5499d11b0 Author: Don Zickus Date: Mon Jun 23 13:22:03 2014 -0700 kernel/watchdog.c: remove preemption restrictions when restarting lockup detector commit bde92cf455a03a91badb7046855592d8c008e929 upstream. Peter Wu noticed the following splat on his machine when updating /proc/sys/kernel/watchdog_thresh: BUG: sleeping function called from invalid context at mm/slub.c:965 in_atomic(): 1, irqs_disabled(): 0, pid: 1, name: init 3 locks held by init/1: #0: (sb_writers#3){.+.+.+}, at: [] vfs_write+0x143/0x180 #1: (watchdog_proc_mutex){+.+.+.}, at: [] proc_dowatchdog+0x33/0x110 #2: (cpu_hotplug.lock){.+.+.+}, at: [] get_online_cpus+0x32/0x80 Preemption disabled at:[] proc_dowatchdog+0xe4/0x110 CPU: 0 PID: 1 Comm: init Not tainted 3.16.0-rc1-testing #34 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Call Trace: dump_stack+0x4e/0x7a __might_sleep+0x11d/0x190 kmem_cache_alloc_trace+0x4e/0x1e0 perf_event_alloc+0x55/0x440 perf_event_create_kernel_counter+0x26/0xe0 watchdog_nmi_enable+0x75/0x140 update_timers_all_cpus+0x53/0xa0 proc_dowatchdog+0xe4/0x110 proc_sys_call_handler+0xb3/0xc0 proc_sys_write+0x14/0x20 vfs_write+0xad/0x180 SyS_write+0x49/0xb0 system_call_fastpath+0x16/0x1b NMI watchdog: disabled (cpu0): hardware events not enabled What happened is after updating the watchdog_thresh, the lockup detector is restarted to utilize the new value. Part of this process involved disabling preemption. Once preemption was disabled, perf tried to allocate a new event (as part of the restart). This caused the above BUG_ON as you can't sleep with preemption disabled. The preemption restriction seemed agressive as we are not doing anything on that particular cpu, but with all the online cpus (which are protected by the get_online_cpus lock). Remove the restriction and the BUG_ON goes away. Signed-off-by: Don Zickus Acked-by: Michal Hocko Reported-by: Peter Wu Tested-by: Peter Wu Acked-by: David Rientjes Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 7d1cd9c360d66e8b3815b6d8bba31e50776d1bfd Author: gundberg Date: Thu Apr 24 15:49:19 2014 +0200 watchdog: kempld-wdt: Use the correct value when configuring the prescaler with the watchdog commit a9e0436b303e94ba57d3bd4b1fcbeaa744b7ebeb upstream. Use the prescaler index, rather than its value, to configure the watchdog. This will prevent a mismatch with the prescaler used to calculate the cycles. Signed-off-by: Per Gundberg Reviewed-by: Guenter Roeck Reviewed-by: Michael Brunner Tested-by: Michael Brunner Signed-off-by: Wim Van Sebroeck Signed-off-by: Greg Kroah-Hartman commit 7eeb3fde74c84e6ba779f68195c546014e2b2aa7 Author: Gabor Juhos Date: Wed Apr 16 11:34:41 2014 +0200 watchdog: ath79_wdt: avoid spurious restarts on AR934x commit 23afeb613ec0e10aecfae7838a14d485db62ac52 upstream. On some AR934x based systems, where the frequency of the AHB bus is relatively high, the built-in watchdog causes a spurious restart when it gets enabled. The possible cause of these restarts is that the timeout value written into the TIMER register does not reaches the hardware in time. Add an explicit delay into the ath79_wdt_enable function to avoid the spurious restarts. Signed-off-by: Gabor Juhos Reviewed-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Greg Kroah-Hartman commit be346e1643e1e59493b761ccad74b906caa02129 Author: Viresh Kumar Date: Thu May 15 10:01:59 2014 +0530 watchdog: sp805: Set watchdog_device->timeout from ->set_timeout() commit 938626d96a3ffb9eb54552bb0d3a4f2b30ffdeb0 upstream. Implementation of ->set_timeout() is supposed to set 'timeout' field of 'struct watchdog_device' passed to it. sp805 was rather setting this in a local variable. Fix it. Reported-by: Arun Ramamurthy Signed-off-by: Viresh Kumar Reviewed-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Greg Kroah-Hartman commit 9c5e4ce346fe16af2bf7a2345a6515182ba0e2ba Author: Yann Droneaud Date: Mon May 5 19:35:26 2014 +0200 RDMA/cxgb4: add missing padding at end of struct c4iw_alloc_ucontext_resp commit b7dfa8895f64ffa371d0ed09c1d1ba8c6e19b956 upstream. The i386 ABI disagrees with most other ABIs regarding alignment of data types larger than 4 bytes: on most ABIs a padding must be added at end of the structures, while it is not required on i386. So for most ABI struct c4iw_alloc_ucontext_resp gets implicitly padded to be aligned on a 8 bytes multiple, while for i386, such padding is not added. The tool pahole can be used to find such implicit padding: $ pahole --anon_include \ --nested_anon_include \ --recursive \ --class_name c4iw_alloc_ucontext_resp \ drivers/infiniband/hw/cxgb4/iw_cxgb4.o Then, structure layout can be compared between i386 and x86_64: # +++ obj-i386/drivers/infiniband/hw/cxgb4/iw_cxgb4.o.pahole.txt 2014-03-28 11:43:05.547432195 +0100 # --- obj-x86_64/drivers/infiniband/hw/cxgb4/iw_cxgb4.o.pahole.txt 2014-03-28 10:55:10.990133017 +0100 # @@ -2,9 +2,8 @@ struct c4iw_alloc_ucontext_resp { # __u64 status_page_key; /* 0 8 */ # __u32 status_page_size; /* 8 4 */ # # - /* size: 12, cachelines: 1, members: 2 */ # - /* last cacheline: 12 bytes */ # + /* size: 16, cachelines: 1, members: 2 */ # + /* padding: 4 */ # + /* last cacheline: 16 bytes */ # }; This ABI disagreement will make an x86_64 kernel try to write past the buffer provided by an i386 binary. When boundary check will be implemented, the x86_64 kernel will refuse to write past the i386 userspace provided buffer and the uverbs will fail. If the structure is on a page boundary and the next page is not mapped, ib_copy_to_udata() will fail and the uverb will fail. Additionally, as reported by Dan Carpenter, without the implicit padding being properly cleared, an information leak would take place in most architectures. This patch adds an explicit padding to struct c4iw_alloc_ucontext_resp, and, like 92b0ca7cb149 ("IB/mlx5: Fix stack info leak in mlx5_ib_alloc_ucontext()"), makes function c4iw_alloc_ucontext() not writting this padding field to userspace. This way, x86_64 kernel will be able to write struct c4iw_alloc_ucontext_resp as expected by unpatched and patched i386 libcxgb4. Link: http://marc.info/?i=cover.1399309513.git.ydroneaud@opteya.com Link: http://marc.info/?i=1395848977.3297.15.camel@localhost.localdomain Link: http://marc.info/?i=20140328082428.GH25192@mwanda Cc: Fixes: 05eb23893c2c ("cxgb4/iw_cxgb4: Doorbell Drop Avoidance Bug Fixes") Reported-by: Yann Droneaud Reported-by: Dan Carpenter Signed-off-by: Yann Droneaud Acked-by: Steve Wise Signed-off-by: Roland Dreier Signed-off-by: Greg Kroah-Hartman commit 5402b8c918087c87a6d89832dd4a54bac08bb9ce Author: Yann Droneaud Date: Mon May 5 19:33:23 2014 +0200 RDMA/cxgb4: Add missing padding at end of struct c4iw_create_cq_resp commit b6f04d3d21458818073a2f5af5339f958864bf71 upstream. The i386 ABI disagrees with most other ABIs regarding alignment of data types larger than 4 bytes: on most ABIs a padding must be added at end of the structures, while it is not required on i386. So for most ABI struct c4iw_create_cq_resp gets implicitly padded to be aligned on a 8 bytes multiple, while for i386, such padding is not added. The tool pahole can be used to find such implicit padding: $ pahole --anon_include \ --nested_anon_include \ --recursive \ --class_name c4iw_create_cq_resp \ drivers/infiniband/hw/cxgb4/iw_cxgb4.o Then, structure layout can be compared between i386 and x86_64: # +++ obj-i386/drivers/infiniband/hw/cxgb4/iw_cxgb4.o.pahole.txt 2014-03-28 11:43:05.547432195 +0100 # --- obj-x86_64/drivers/infiniband/hw/cxgb4/iw_cxgb4.o.pahole.txt 2014-03-28 10:55:10.990133017 +0100 # @@ -14,9 +13,8 @@ struct c4iw_create_cq_resp { # __u32 size; /* 28 4 */ # __u32 qid_mask; /* 32 4 */ # # - /* size: 36, cachelines: 1, members: 6 */ # - /* last cacheline: 36 bytes */ # + /* size: 40, cachelines: 1, members: 6 */ # + /* padding: 4 */ # + /* last cacheline: 40 bytes */ # }; This ABI disagreement will make an x86_64 kernel try to write past the buffer provided by an i386 binary. When boundary check will be implemented, the x86_64 kernel will refuse to write past the i386 userspace provided buffer and the uverbs will fail. If the structure is on a page boundary and the next page is not mapped, ib_copy_to_udata() will fail and the uverb will fail. This patch adds an explicit padding at end of structure c4iw_create_cq_resp, and, like 92b0ca7cb149 ("IB/mlx5: Fix stack info leak in mlx5_ib_alloc_ucontext()"), makes function c4iw_create_cq() not writting this padding field to userspace. This way, x86_64 kernel will be able to write struct c4iw_create_cq_resp as expected by unpatched and patched i386 libcxgb4. Link: http://marc.info/?i=cover.1399309513.git.ydroneaud@opteya.com Fixes: cfdda9d764362 ("RDMA/cxgb4: Add driver for Chelsio T4 RNIC") Fixes: e24a72a3302a6 ("RDMA/cxgb4: Fix four byte info leak in c4iw_create_cq()") Cc: Dan Carpenter Signed-off-by: Yann Droneaud Acked-by: Steve Wise Signed-off-by: Roland Dreier Signed-off-by: Greg Kroah-Hartman commit bbac87fb33da122c392e911706c6503c208e8eec Author: Christoph Jaeger Date: Mon Apr 21 17:02:42 2014 +0200 RDMA/cxgb4: Fix memory leaks in c4iw_alloc() error paths commit 65b302ad31b02b0790417f4e65833af494cb35ce upstream. c4iw_alloc() bails out without freeing the storage that 'devp' points to. Picked up by Coverity - CID 1204241. Fixes: fa658a98a2 ("RDMA/cxgb4: Use the BAR2/WC path for kernel QPs and T5 devices") Signed-off-by: Christoph Jaeger Acked-by: Steve Wise Signed-off-by: Roland Dreier Signed-off-by: Greg Kroah-Hartman commit b03a0751eb1039340c843411cd2f09859531a385 Author: hujianyang Date: Sat May 31 11:39:32 2014 +0800 UBIFS: Remove incorrect assertion in shrink_tnc() commit 72abc8f4b4e8574318189886de627a2bfe6cd0da upstream. I hit the same assert failed as Dolev Raviv reported in Kernel v3.10 shows like this: [ 9641.164028] UBIFS assert failed in shrink_tnc at 131 (pid 13297) [ 9641.234078] CPU: 1 PID: 13297 Comm: mmap.test Tainted: G O 3.10.40 #1 [ 9641.234116] [] (unwind_backtrace+0x0/0x12c) from [] (show_stack+0x20/0x24) [ 9641.234137] [] (show_stack+0x20/0x24) from [] (dump_stack+0x20/0x28) [ 9641.234188] [] (dump_stack+0x20/0x28) from [] (shrink_tnc_trees+0x25c/0x350 [ubifs]) [ 9641.234265] [] (shrink_tnc_trees+0x25c/0x350 [ubifs]) from [] (ubifs_shrinker+0x25c/0x310 [ubifs]) [ 9641.234307] [] (ubifs_shrinker+0x25c/0x310 [ubifs]) from [] (shrink_slab+0x1d4/0x2f8) [ 9641.234327] [] (shrink_slab+0x1d4/0x2f8) from [] (do_try_to_free_pages+0x300/0x544) [ 9641.234344] [] (do_try_to_free_pages+0x300/0x544) from [] (try_to_free_pages+0x2d0/0x398) [ 9641.234363] [] (try_to_free_pages+0x2d0/0x398) from [] (__alloc_pages_nodemask+0x494/0x7e8) [ 9641.234382] [] (__alloc_pages_nodemask+0x494/0x7e8) from [] (new_slab+0x78/0x238) [ 9641.234400] [] (new_slab+0x78/0x238) from [] (__slab_alloc.constprop.42+0x1a4/0x50c) [ 9641.234419] [] (__slab_alloc.constprop.42+0x1a4/0x50c) from [] (kmem_cache_alloc_trace+0x54/0x188) [ 9641.234459] [] (kmem_cache_alloc_trace+0x54/0x188) from [] (do_readpage+0x168/0x468 [ubifs]) [ 9641.234553] [] (do_readpage+0x168/0x468 [ubifs]) from [] (ubifs_readpage+0x424/0x464 [ubifs]) [ 9641.234606] [] (ubifs_readpage+0x424/0x464 [ubifs]) from [] (filemap_fault+0x304/0x418) [ 9641.234638] [] (filemap_fault+0x304/0x418) from [] (__do_fault+0xd4/0x530) [ 9641.234665] [] (__do_fault+0xd4/0x530) from [] (handle_pte_fault+0x480/0xf54) [ 9641.234690] [] (handle_pte_fault+0x480/0xf54) from [] (handle_mm_fault+0x140/0x184) [ 9641.234716] [] (handle_mm_fault+0x140/0x184) from [] (do_page_fault+0x150/0x3ac) [ 9641.234737] [] (do_page_fault+0x150/0x3ac) from [] (do_DataAbort+0x3c/0xa0) [ 9641.234759] [] (do_DataAbort+0x3c/0xa0) from [] (__dabt_usr+0x38/0x40) After analyzing the code, I found a condition that may cause this failed in correct operations. Thus, I think this assertion is wrong and should be removed. Suppose there are two clean znodes and one dirty znode in TNC. So the per-filesystem atomic_t @clean_zn_cnt is (2). If commit start, dirty_znode is set to COW_ZNODE in get_znodes_to_commit() in case of potentially ops on this znode. We clear COW bit and DIRTY bit in write_index() without @tnc_mutex locked. We don't increase @clean_zn_cnt in this place. As the comments in write_index() shows, if another process hold @tnc_mutex and dirty this znode after we clean it, @clean_zn_cnt would be decreased to (1). We will increase @clean_zn_cnt to (2) with @tnc_mutex locked in free_obsolete_znodes() to keep it right. If shrink_tnc() performs between decrease and increase, it will release other 2 clean znodes it holds and found @clean_zn_cnt is less than zero (1 - 2 = -1), then hit the assertion. Because free_obsolete_znodes() will soon correct @clean_zn_cnt and no harm to fs in this case, I think this assertion could be removed. 2 clean zondes and 1 dirty znode, @clean_zn_cnt == 2 Thread A (commit) Thread B (write or others) Thread C (shrinker) ->write_index ->clear_bit(DIRTY_NODE) ->clear_bit(COW_ZNODE) @clean_zn_cnt == 2 ->mutex_locked(&tnc_mutex) ->dirty_cow_znode ->!ubifs_zn_cow(znode) ->!test_and_set_bit(DIRTY_NODE) ->atomic_dec(&clean_zn_cnt) ->mutex_unlocked(&tnc_mutex) @clean_zn_cnt == 1 ->mutex_locked(&tnc_mutex) ->shrink_tnc ->destroy_tnc_subtree ->atomic_sub(&clean_zn_cnt, 2) ->ubifs_assert <- hit ->mutex_unlocked(&tnc_mutex) @clean_zn_cnt == -1 ->mutex_lock(&tnc_mutex) ->free_obsolete_znodes ->atomic_inc(&clean_zn_cnt) ->mutux_unlock(&tnc_mutex) @clean_zn_cnt == 0 (correct after shrink) Signed-off-by: hujianyang Signed-off-by: Artem Bityutskiy Signed-off-by: Greg Kroah-Hartman commit becae3b2c884916505d89b6b6d468113047ee8a3 Author: hujianyang Date: Wed Apr 30 14:06:06 2014 +0800 UBIFS: fix an mmap and fsync race condition commit 691a7c6f28ac90cccd0dbcf81348ea90b211bdd0 upstream. There is a race condition in UBIFS: Thread A (mmap) Thread B (fsync) ->__do_fault ->write_cache_pages -> ubifs_vm_page_mkwrite -> budget_space -> lock_page -> release/convert_page_budget -> SetPagePrivate -> TestSetPageDirty -> unlock_page -> lock_page -> TestClearPageDirty -> ubifs_writepage -> do_writepage -> release_budget -> ClearPagePrivate -> unlock_page -> !(ret & VM_FAULT_LOCKED) -> lock_page -> set_page_dirty -> ubifs_set_page_dirty -> TestSetPageDirty (set page dirty without budgeting) -> unlock_page This leads to situation where we have a diry page but no budget allocated for this page, so further write-back may fail with -ENOSPC. In this fix we return from page_mkwrite without performing unlock_page. We return VM_FAULT_LOCKED instead. After doing this, the race above will not happen. Signed-off-by: hujianyang Tested-by: Laurence Withers Signed-off-by: Artem Bityutskiy Signed-off-by: Greg Kroah-Hartman commit 7b758a0a8a3e20de46294a283463d1fb4d0a58f0 Author: Joe Handzik Date: Thu May 8 14:27:24 2014 -0500 hpsa: add new Smart Array PCI IDs (May 2014) commit 3b7a45e5ba85dc79c7714edd9eee9aaed730cd6b upstream. Signed-off-by: Scott Teel Signed-off-by: Joe Handzik Signed-off-by: Stephen M. Cameron Signed-off-by: Christoph Hellwig Signed-off-by: Greg Kroah-Hartman commit 746242a44f036d1f4ea43a8defb75ae5c76d220e Author: Markos Chandras Date: Mon Jun 23 09:48:51 2014 +0100 MIPS: MSC: Prevent out-of-bounds writes to MIPS SC ioremap'd region commit ab6c15bc6620ebe220970cc040b29bcb2757f373 upstream. Previously, the lower limit for the MIPS SC initialization loop was set incorrectly allowing one extra loop leading to writes beyond the MSC ioremap'd space. More precisely, the value of the 'imp' in the last loop increased beyond the msc_irqmap_t boundaries and as a result of which, the 'n' variable was loaded with an incorrect value. This value was used later on to calculate the offset in the MSC01_IC_SUP which led to random crashes like the following one: CPU 0 Unable to handle kernel paging request at virtual address e75c0200, epc == 8058dba4, ra == 8058db90 [...] Call Trace: [<8058dba4>] init_msc_irqs+0x104/0x154 [<8058b5bc>] arch_init_irq+0xd8/0x154 [<805897b0>] start_kernel+0x220/0x36c Kernel panic - not syncing: Attempted to kill the idle task! This patch fixes the problem Signed-off-by: Markos Chandras Reviewed-by: James Hogan Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/7118/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 567ceb4199c368fc0a1c944b5632c934aa2a05b4 Author: Paul Burton Date: Wed Jun 18 15:00:46 2014 +0100 Revert "MIPS: Save/restore MSA context around signals" commit 16f77de82f2d2f628306dab9bc4799df0d28a199 upstream. This reverts commit eec43a224cf1 "MIPS: Save/restore MSA context around signals" and the MSA parts of ca750649e08c "MIPS: kernel: signal: Prevent save/restore FPU context in user memory" (the restore path of which appears incorrect anyway...). The reverted patch took care not to break compatibility with userland users of struct sigcontext, but inadvertantly changed the offset of the uc_sigmask field of struct ucontext. Thus Linux v3.15 breaks the userland ABI. The MSA context will need to be saved via some other opt-in mechanism, but for now revert the change to reduce the fallout. This will have minimal impact upon use of MSA since the only supported CPU which includes it (the P5600) is 32-bit and therefore requires that the experimental CONFIG_MIPS_O32_FP64_SUPPORT Kconfig option be selected before the kernel will set FR=1 for a task, a requirement for MSA use. Thus the users of MSA are limited to known small groups of people & this patch won't be breaking any previously working MSA-using userland outside of experimental settings. [ralf@linux-mips.org: Fixed rejects.] Reported-by: Joseph S. Myers Signed-off-by: Paul Burton Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/7107/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 6651239ed8cfdd0059aa796054c91f2ab1252a48 Author: Alex Smith Date: Tue Jun 17 10:39:53 2014 +0100 recordmcount/MIPS: Fix possible incorrect mcount_loc table entries in modules commit 91ad11d7cc6f4472ebf177a6252fbf0fd100d798 upstream. On MIPS calls to _mcount in modules generate 2 instructions to load the _mcount address (and therefore 2 relocations). The mcount_loc table should only reference the first of these, so the second is filtered out by checking the relocation offset and ignoring ones that immediately follow the previous one seen. However if a module has an _mcount call at offset 0, the second relocation would not be filtered out due to old_r_offset == 0 being taken to mean that the current relocation is the first one seen, and both would end up in the mcount_loc table. This results in ftrace_make_nop() patching both (adjacent) instructions to branches over the _mcount call sequence like so: 0xffffffffc08a8000: 04 00 00 10 b 0xffffffffc08a8014 0xffffffffc08a8004: 04 00 00 10 b 0xffffffffc08a8018 0xffffffffc08a8008: 2d 08 e0 03 move at,ra ... The second branch is in the delay slot of the first, which is defined to be unpredictable - on the platform on which this bug was encountered, it triggers a reserved instruction exception. Fix by initializing old_r_offset to ~0 and using that instead of 0 to determine whether the current relocation is the first seen. Signed-off-by: Alex Smith Cc: linux-kernel@vger.kernel.org Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/7098/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 438b20e970ccf13d8eedd70031e1fedc957c1ccb Author: Asai Thambi S P Date: Wed Apr 16 20:30:16 2014 -0700 mtip32xx: Remove dfs_parent after pci unregister commit af5ded8ccf21627f9614afc03b356712666ed225 upstream. In module exit, dfs_parent and it's subtree were removed before unregistering with pci. When debugfs entry for each device is attempted to remove in pci_remove() context, they don't exist, as dfs_parent and its children were already ripped apart. Modified to first unregister with pci and then remove dfs_parent. Signed-off-by: Asai Thambi S P Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 8e5d7e9d97682c239627e1c55b3ffa8cc09f187a Author: Asai Thambi S P Date: Wed Apr 16 20:27:54 2014 -0700 mtip32xx: Increase timeout for STANDBY IMMEDIATE command commit 670a641420a3d9586eebe7429dfeec4e7ed447aa upstream. Increased timeout for STANDBY IMMEDIATE command to 2 minutes. Signed-off-by: Selvan Mani Signed-off-by: Asai Thambi S P Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 55e416900e309572eb497da2ddb43ce45f80690b Author: Asai Thambi S P Date: Thu Mar 13 18:45:15 2014 -0700 mtip32xx: Fix ERO and NoSnoop values in PCIe upstream on AMD systems commit d1e714db8129a1d3670e449b87719c78e2c76f9f upstream. A hardware quirk in P320h/P420m interfere with PCIe transactions on some AMD chipsets, making P320h/P420m unusable. This workaround is to disable ERO and NoSnoop bits in the parent and root complex for normal functioning of these devices NOTE: This workaround is specific to AMD chipset with a PCIe upstream device with device id 0x5aXX Signed-off-by: Asai Thambi S P Signed-off-by: Sam Bradshaw Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 7886e1875b9a2b04e47c9055cceb4c2127e12ed7 Author: Bjorn Helgaas Date: Sat Apr 5 15:14:22 2014 -0600 PCI: Fix incorrect vgaarb conditional in WARN_ON() commit 67ebd8140dc8923c65451fa0f6a8eee003c4dcd3 upstream. 3448a19da479 "vgaarb: use bridges to control VGA routing where possible" added the "flags & PCI_VGA_STATE_CHANGE_DECODES" condition to an existing WARN_ON(), but used bitwise AND (&) instead of logical AND (&&), so the condition is never true. Replace with logical AND. Found by Coverity (CID 142811). Fixes: 3448a19da479 "vgaarb: use bridges to control VGA routing where possible" Signed-off-by: Bjorn Helgaas Acked-by: Yinghai Lu Acked-by: David Airlie Signed-off-by: Greg Kroah-Hartman commit 70e5f0286c1bb0f6957b8e54c620ec845378bb69 Author: Thomas Jarosch Date: Mon Apr 7 15:10:32 2014 +0200 PCI: Add new ID for Intel GPU "spurious interrupt" quirk commit 7c82126a94e69bbbac586f0249e7ef11e681246c upstream. After a CPU upgrade while keeping the same mainboard, we faced "spurious interrupt" problems again. It turned out that the new CPU also featured a new GPU with a different PCI ID. Add this PCI ID to the quirk table. Probably all other Intel GPU PCI IDs are affected, too, but I don't want to add them without a test system. See f67fd55fa96f ("PCI: Add quirk for still enabled interrupts on Intel Sandy Bridge GPUs") for some history. [bhelgaas: add f67fd55fa96f reference, stable tag] Signed-off-by: Thomas Jarosch Signed-off-by: Bjorn Helgaas Signed-off-by: Greg Kroah-Hartman commit 14d5017514154c8d0deb801e3dd74a810e7d8a55 Author: Hans de Goede Date: Sat Jun 7 23:07:13 2014 -0700 Input: elantech - don't set bit 1 of reg_10 when the no_hw_res quirk is set commit fb4f8f568a9def02240ef9bf7aabd246dc63a081 upstream. The touchpad on the GIGABYTE U2442 not only stops communicating when we try to set bit 3 (enable real hardware resolution) of reg_10, but on some BIOS versions also when we set bit 1 (enable two finger mode auto correct). I've asked the original reporter of: https://bugzilla.kernel.org/show_bug.cgi?id=61151 To check that not setting bit 1 does not lead to any adverse effects on his model / BIOS revision, and it does not, so this commit fixes the touchpad not working on these versions by simply never setting bit 1 for laptop models with the no_hw_res quirk. Reported-and-tested-by: James Lademann Tested-by: Philipp Wolfer Signed-off-by: Hans de Goede Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 32f38de5cd99ae05751f04ef654d7749f3907ee8 Author: Hans de Goede Date: Sat Jun 7 22:35:07 2014 -0700 Input: elantech - deal with clickpads reporting right button events commit cd9e83e2754465856097f31c7ab933ce74c473f8 upstream. At least the Dell Vostro 5470 elantech *clickpad* reports right button clicks when clicked in the right bottom area: https://bugzilla.redhat.com/show_bug.cgi?id=1103528 This is different from how (elantech) clickpads normally operate, normally no matter where the user clicks on the pad the pad always reports a left button event, since there is only 1 hardware button beneath the path. It looks like Dell has put 2 buttons under the pad, one under each bottom corner, causing this. Since this however still clearly is a real clickpad hardware-wise, we still want to report it as such to userspace, so that things like finger movement in the bottom area can be properly ignored as it should be on clickpads. So deal with this weirdness by simply mapping a right click to a left click on elantech clickpads. As an added advantage this is something which we can simply do on all elantech clickpads, so no need to add special quirks for this weird model. Reported-and-tested-by: Elder Marco Signed-off-by: Hans de Goede Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 4470cf9ba206c6a7e72bff8804132381166379ce Author: Benjamin Tissoires Date: Sat Jun 7 22:37:47 2014 -0700 Input: synaptics - fix resolution for manually provided min/max commit d49cb7aeebb974713f9f7ab2991352d3050b095b upstream. commit 421e08c41fda fixed the reported min/max for the X and Y axis, but unfortunately, it broke the resolution of those same axis. On the t540p, the resolution is the same regarding X and Y. It is not a problem for xf86-input-synaptics because this driver is only interested in the ratio between X and Y. Unfortunately, xf86-input-cmt uses directly the resolution, and having a null resolution leads to some divide by 0 errors, which are translated by -infinity in the resulting coordinates. Reported-by: Peter Hutterer Signed-off-by: Benjamin Tissoires Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit abd948c8bf6066d18a8a4a9c82fc7997a818134e Author: Mikulas Patocka Date: Mon Jun 23 13:42:37 2014 -0400 iscsi-target: fix iscsit_del_np deadlock on unload commit 81a9c5e72bdf7109a65102ca61d8cbd722cf4021 upstream. On uniprocessor preemptible kernel, target core deadlocks on unload. The following events happen: * iscsit_del_np is called * it calls send_sig(SIGINT, np->np_thread, 1); * the scheduler switches to the np_thread * the np_thread is woken up, it sees that kthread_should_stop() returns false, so it doesn't terminate * the np_thread clears signals with flush_signals(current); and goes back to sleep in iscsit_accept_np * the scheduler switches back to iscsit_del_np * iscsit_del_np calls kthread_stop(np->np_thread); * the np_thread is waiting in iscsit_accept_np and it doesn't respond to kthread_stop The deadlock could be resolved if the administrator sends SIGINT signal to the np_thread with killall -INT iscsi_np The reproducible deadlock was introduced in commit db6077fd0b7dd41dc6ff18329cec979379071f87, but the thread-stopping code was racy even before. This patch fixes the problem. Using kthread_should_stop to stop the np_thread is unreliable, so we test np_thread_state instead. If np_thread_state equals ISCSI_NP_THREAD_SHUTDOWN, the thread exits. Signed-off-by: Mikulas Patocka Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit b874e798cca577f4bc5a544f3b72939e12e3af86 Author: Nicholas Bellinger Date: Tue Jun 17 21:54:38 2014 +0000 iscsi-target: Explicily clear login response PDU in exception path commit 683497566d48f86e04d026de1ee658dd74fc1077 upstream. This patch adds a explicit memset to the login response PDU exception path in iscsit_tx_login_rsp(). This addresses a regression bug introduced in commit baa4d64b where the initiator would end up not receiving the login response and associated status class + detail, before closing the login connection. Reported-by: Christophe Vu-Brugier Tested-by: Christophe Vu-Brugier Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 99e5722b8c83006a9dcbc67a6d34ab130672d41a Author: Nicholas Bellinger Date: Fri Jun 20 10:59:57 2014 -0700 iscsi-target: Avoid rejecting incorrect ITT for Data-Out commit 97c99b47ac58bacb7c09e1f47d5d184434f6b06a upstream. This patch changes iscsit_check_dataout_hdr() to dump the incoming Data-Out payload when the received ITT is not associated with a WRITE, instead of calling iscsit_reject_cmd() for the non WRITE ITT descriptor. This addresses a bug where an initiator sending an Data-Out for an ITT associated with a READ would end up generating a reject for the READ, eventually resulting in list corruption. Reported-by: Santosh Kulkarni Reported-by: Arshad Hussain Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 2c6b54c2261f24b75605b48525b753ac4fdd917e Author: Nicholas Bellinger Date: Mon Jun 16 20:25:54 2014 +0000 target: Fix left-over se_lun->lun_sep pointer OOPs commit 83ff42fcce070801a3aa1cd6a3269d7426271a8d upstream. This patch fixes a left-over se_lun->lun_sep pointer OOPs when one of the /sys/kernel/config/target/$FABRIC/$WWPN/$TPGT/lun/$LUN/alua* attributes is accessed after the $DEVICE symlink has been removed. To address this bug, go ahead and clear se_lun->lun_sep memory in core_dev_unexport(), so that the existing checks for show/store ALUA attributes in target_core_fabric_configfs.c work as expected. Reported-by: Sebastian Herbszt Tested-by: Sebastian Herbszt Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman