aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAge
...
* nfsd: nfsd_open: when dentry_open returns an error do not propagate as ↵Harshula Jayasuriya2013-08-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | struct file commit e4daf1ffbe6cc3b12aab4d604e627829e93e9914 upstream. The following call chain: ------------------------------------------------------------ nfs4_get_vfs_file - nfsd_open - dentry_open - do_dentry_open - __get_file_write_access - get_write_access - return atomic_inc_unless_negative(&inode->i_writecount) ? 0 : -ETXTBSY; ------------------------------------------------------------ can result in the following state: ------------------------------------------------------------ struct nfs4_file { ... fi_fds = {0xffff880c1fa65c80, 0xffffffffffffffe6, 0x0}, fi_access = {{ counter = 0x1 }, { counter = 0x0 }}, ... ------------------------------------------------------------ 1) First time around, in nfs4_get_vfs_file() fp->fi_fds[O_WRONLY] is NULL, hence nfsd_open() is called where we get status set to an error and fp->fi_fds[O_WRONLY] to -ETXTBSY. Thus we do not reach nfs4_file_get_access() and fi_access[O_WRONLY] is not incremented. 2) Second time around, in nfs4_get_vfs_file() fp->fi_fds[O_WRONLY] is NOT NULL (-ETXTBSY), so nfsd_open() is NOT called, but nfs4_file_get_access() IS called and fi_access[O_WRONLY] is incremented. Thus we leave a landmine in the form of the nfs4_file data structure in an incorrect state. 3) Eventually, when __nfs4_file_put_access() is called it finds fi_access[O_WRONLY] being non-zero, it decrements it and calls nfs4_file_put_fd() which tries to fput -ETXTBSY. ------------------------------------------------------------ ... [exception RIP: fput+0x9] RIP: ffffffff81177fa9 RSP: ffff88062e365c90 RFLAGS: 00010282 RAX: ffff880c2b3d99cc RBX: ffff880c2b3d9978 RCX: 0000000000000002 RDX: dead000000100101 RSI: 0000000000000001 RDI: ffffffffffffffe6 RBP: ffff88062e365c90 R8: ffff88041fe797d8 R9: ffff88062e365d58 R10: 0000000000000008 R11: 0000000000000000 R12: 0000000000000001 R13: 0000000000000007 R14: 0000000000000000 R15: 0000000000000000 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #9 [ffff88062e365c98] __nfs4_file_put_access at ffffffffa0562334 [nfsd] #10 [ffff88062e365cc8] nfs4_file_put_access at ffffffffa05623ab [nfsd] #11 [ffff88062e365ce8] free_generic_stateid at ffffffffa056634d [nfsd] #12 [ffff88062e365d18] release_open_stateid at ffffffffa0566e4b [nfsd] #13 [ffff88062e365d38] nfsd4_close at ffffffffa0567401 [nfsd] #14 [ffff88062e365d88] nfsd4_proc_compound at ffffffffa0557f28 [nfsd] #15 [ffff88062e365dd8] nfsd_dispatch at ffffffffa054543e [nfsd] #16 [ffff88062e365e18] svc_process_common at ffffffffa04ba5a4 [sunrpc] #17 [ffff88062e365e98] svc_process at ffffffffa04babe0 [sunrpc] #18 [ffff88062e365eb8] nfsd at ffffffffa0545b62 [nfsd] #19 [ffff88062e365ee8] kthread at ffffffff81090886 #20 [ffff88062e365f48] kernel_thread at ffffffff8100c14a ------------------------------------------------------------ Signed-off-by: Harshula Jayasuriya <harshula@redhat.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* powerpc/modules: Module CRC relocation fix causes perf issuesAnton Blanchard2013-08-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 0e0ed6406e61434d3f38fb58aa8464ec4722b77e upstream. Module CRCs are implemented as absolute symbols that get resolved by a linker script. We build an intermediate .o that contains an unresolved symbol for each CRC. genksysms parses this .o, calculates the CRCs and writes a linker script that "resolves" the symbols to the calculated CRC. Unfortunately the ppc64 relocatable kernel sees these CRCs as symbols that need relocating and relocates them at boot. Commit d4703aef (module: handle ppc64 relocating kcrctabs when CONFIG_RELOCATABLE=y) added a hook to reverse the bogus relocations. Part of this patch created a symbol at 0x0: # head -2 /proc/kallsyms 0000000000000000 T reloc_start c000000000000000 T .__start This reloc_start symbol is causing lots of confusion to perf. It thinks reloc_start is a massive function that stretches from 0x0 to 0xc000000000000000 and we get various cryptic errors out of perf, including: problem incrementing symbol count, skipping event This patch removes the reloc_start linker script label and instead defines it as PHYSICAL_START. We also need to wrap it with CONFIG_PPC64 because the ppc32 kernel can set a non zero PHYSICAL_START at compile time and we wouldn't want to subtract it from the CRCs in that case. Signed-off-by: Anton Blanchard <anton@samba.org> Acked-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* crypto: caam - Fixed the memory out of bound overwrite issueVakul Garg2013-08-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 9c23b7d3d6bda41e2a27375df705485523a96dc8 upstream. When kernel is compiled with CONFIG_SLUB_DEBUG=y and CRYPTO_MANAGER_DISABLE_TESTS=n, during kernel bootup, the kernel reports error given below. The root cause is that in function hash_digest_key(), for allocating descriptor, insufficient memory was being allocated. The required number of descriptor words apart from input and output pointers are 8 (instead of 6). ============================================================================= BUG dma-kmalloc-32 (Not tainted): Redzone overwritten ----------------------------------------------------------------------------- Disabling lock debugging due to kernel taint INFO: 0xdec5dec0-0xdec5dec3. First byte 0x0 instead of 0xcc INFO: Allocated in ahash_setkey+0x60/0x594 age=7 cpu=1 pid=1257 __kmalloc+0x154/0x1b4 ahash_setkey+0x60/0x594 test_hash+0x260/0x5a0 alg_test_hash+0x48/0xb0 alg_test+0x84/0x228 cryptomgr_test+0x4c/0x54 kthread+0x98/0x9c ret_from_kernel_thread+0x64/0x6c INFO: Slab 0xc0bd0ba0 objects=19 used=2 fp=0xdec5d0d0 flags=0x0081 INFO: Object 0xdec5dea0 @offset=3744 fp=0x5c200014 Bytes b4 dec5de90: 00 00 00 00 00 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a ........ZZZZZZZZ Object dec5dea0: b0 80 00 0a 84 41 00 0d f0 40 00 00 00 67 3f c0 .....A...@...g?. Object dec5deb0: 00 00 00 50 2c 14 00 50 f8 40 00 00 1e c5 d0 00 ...P,..P.@...... Redzone dec5dec0: 00 00 00 14 .... Padding dec5df68: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ Call Trace: [dec65b60] [c00071b4] show_stack+0x4c/0x168 (unreliable) [dec65ba0] [c00d4ec8] check_bytes_and_report+0xe4/0x11c [dec65bd0] [c00d507c] check_object+0x17c/0x23c [dec65bf0] [c0550a00] free_debug_processing+0xf4/0x294 [dec65c20] [c0550bdc] __slab_free+0x3c/0x294 [dec65c80] [c03f0744] ahash_setkey+0x4e0/0x594 [dec65cd0] [c01ef138] test_hash+0x260/0x5a0 [dec65e50] [c01ef4c0] alg_test_hash+0x48/0xb0 [dec65e70] [c01eecc4] alg_test+0x84/0x228 [dec65ee0] [c01ec640] cryptomgr_test+0x4c/0x54 [dec65ef0] [c005adc0] kthread+0x98/0x9c [dec65f40] [c000e1ac] ret_from_kernel_thread+0x64/0x6c FIX dma-kmalloc-32: Restoring 0xdec5dec0-0xdec5dec3=0xcc Change-Id: I0c7a1048053e811025d1c3b487940f87345c8f5d Signed-off-by: Vakul Garg <vakul@freescale.com> Reviewed-by: Geanta Neag Horia Ioan-B05471 <horia.geanta@freescale.com> Reviewed-by: Fleming Andrew-AFLEMING <AFLEMING@freescale.com> Tested-by: Fleming Andrew-AFLEMING <AFLEMING@freescale.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* svcrdma: underflow issue in decode_write_list()Dan Carpenter2013-08-04
| | | | | | | | | | | | | | | | commit b2781e1021525649c0b33fffd005ef219da33926 upstream. My static checker marks everything from ntohl() as untrusted and it complains we could have an underflow problem doing: return (u32 *)&ary->wc_array[nchunks]; Also on 32 bit systems the upper bound check could overflow. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* libata: make it clear that sata_inic162x is experimentalTejun Heo2013-08-04
| | | | | | | | | | | | | | | | | | | | commit bb9696192826a7d9279caf872e95b41bc26c7eff upstream. sata_inic162x never reached a state where it's reliable enough for production use and data corruption is a relatively common occurrence. Make the driver generate warning about the issues and mark the Kconfig option as experimental. If the situation doesn't improve, we'd be better off making it depend on CONFIG_BROKEN. Let's wait for several cycles and see if the kernel message draws any attention. Signed-off-by: Tejun Heo <tj@kernel.org> Reported-by: Martin Braure de Calignon <braurede@free.fr> Reported-by: Ben Hutchings <ben@decadent.org.uk> Reported-by: risc4all@yahoo.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ata: Fix DVD not dectected at some platform with Wellsburg PCHYouquan Song2013-08-04
| | | | | | | | | | | | | | | | commit eac27f04a71e1f39f196f7e520d16dcefc955d77 upstream. There is a patch b55f84e2d527182e7c611d466cd0bb6ddce201de "ata_piix: Fix DVD not dectected at some Haswell platforms" to fix an issue of DVD not recognized on Haswell Desktop platform with Lynx Point. Recently, it is also found the same issue at some platformas with Wellsburg PCH. So deliver a similar patch to fix it by disables 32bit PIO in IDE mode. Signed-off-by: Youquan Song <youquan.song@intel.com> Signed-off-by: Tejun Heo <tj@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* md/raid10: remove use-after-free bug.NeilBrown2013-08-04
| | | | | | | | | | | | | | | | | | | commit 0eb25bb027a100f5a9df8991f2f628e7d851bc1e upstream. We always need to be careful when calling generic_make_request, as it can start a chain of events which might free something that we are using. Here is one place I wasn't careful enough. If the wbio2 is not in use, then it might get freed at the first generic_make_request call. So perform all necessary tests first. This bug was introduced in 3.3-rc3 (24afd80d99) and can cause an oops, so fix is suitable for any -stable since then. Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* md/raid5: fix interaction of 'replace' and 'recovery'.NeilBrown2013-08-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit f94c0b6658c7edea8bc19d13be321e3860a3fa54 upstream. If a device in a RAID4/5/6 is being replaced while another is being recovered, then the writes to the replacement device currently don't happen, resulting in corruption when the replacement completes and the new drive takes over. This is because the replacement writes are only triggered when 's.replacing' is set and not when the similar 's.sync' is set (which is the case during resync and recovery - it means all devices need to be read). So schedule those writes when s.replacing is set as well. In this case we cannot use "STRIPE_INSYNC" to record that the replacement has happened as that is needed for recording that any parity calculation is complete. So introduce STRIPE_REPLACED to record if the replacement has happened. For safety we should also check that STRIPE_COMPUTE_RUN is not set. This has a similar effect to the "s.locked == 0" test. The latter ensure that now IO has been flagged but not started. The former checks if any parity calculation has been flagged by not started. We must wait for both of these to complete before triggering the 'replace'. Add a similar test to the subsequent check for "are we finished yet". This possibly isn't needed (is subsumed in the STRIPE_INSYNC test), but it makes it more obvious that the REPLACE will happen before we think we are finished. Finally if a NeedReplace device is not UPTODATE then that is an error. We really must trigger a warning. This bug was introduced in commit 9a3e1101b827a59ac9036a672f5fa8d5279d0fe2 (md/raid5: detect and handle replacements during recovery.) which introduced replacement for raid5. That was in 3.3-rc3, so any stable kernel since then would benefit from this fix. Reported-by: qindehua <13691222965@163.com> Tested-by: qindehua <qindehua@163.com> Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* md/raid1: fix bio handling problems in process_checks()NeilBrown2013-08-04
| | | | | | | | | | | | | | | | | | | | | | | | | commit 30bc9b53878a9921b02e3b5bc4283ac1c6de102a upstream. Recent change to use bio_copy_data() in raid1 when repairing an array is faulty. The underlying may have changed the bio in various ways using bio_advance and these need to be undone not just for the 'sbio' which is being copied to, but also the 'pbio' (primary) which is being copied from. So perform the reset on all bios that were read from and do it early. This also ensure that the sbio->bi_io_vec[j].bv_len passed to memcmp is correct. This fixes a crash during a 'check' of a RAID1 array. The crash was introduced in 3.10 so this is suitable for 3.10-stable. Reported-by: Joe Lawrence <joe.lawrence@stratus.com> Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* md: Remove recent change which allows devices to skip recovery.NeilBrown2013-08-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 5024c298311f3b97c85cb034f9edaa333fdb9338 upstream. commit 7ceb17e87bde79d285a8b988cfed9eaeebe60b86 md: Allow devices to be re-added to a read-only array. allowed a bit more than just that. It also allows devices to be added to a read-write array and to end up skipping recovery. This patch removes the offending piece of code pending a rewrite for a subsequent release. More specifically: If the array has a bitmap, then the device will still need a bitmap based resync ('saved_raid_disk' is set under different conditions is a bitmap is present). If the array doesn't have a bitmap, then this is correct as long as nothing has been written to the array since the metadata was checked by ->validate_super. However there is no locking to ensure that there was no write. Bug was introduced in 3.10 and causes data corruption so patch is suitable for 3.10-stable. Reported-by: Joe Lawrence <joe.lawrence@stratus.com> Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* x86: make sure IDT is page alignedKees Cook2013-08-04
| | | | | | | | | | | | | | | | | | | | | based on 4df05f361937ee86e5a8c9ead8aeb6a19ea9b7d7 upstream. Since the IDT is referenced from a fixmap, make sure it is page aligned. This avoids the risk of the IDT ever being moved in the bss and having the mapping be offset, resulting in calling incorrect handlers. In the current upstream kernel this is not a manifested bug, but heavily patched kernels (such as those using the PaX patch series) did encounter this bug. Signed-off-by: Kees Cook <keescook@chromium.org> Reported-by: PaX Team <pageexec@gmail.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Yinghai Lu <yinghai@kernel.org> Cc: Seiji Aguchi <seiji.aguchi@hds.com> Cc: Fenghua Yu <fenghua.yu@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* x86, suspend: Handle CPUs which fail to #GP on RDMSRH. Peter Anvin2013-08-04
| | | | | | | | | | | | | | | | | | | | | | | commit 5ff560fd48d5b3d82fa0c3aff625c9da1a301911 upstream. There are CPUs which have errata causing RDMSR of a nonexistent MSR to not fault. We would then try to WRMSR to restore the value of that MSR, causing a crash. Specifically, some Pentium M variants would have this problem trying to save and restore the non-existent EFER, causing a crash on resume. Work around this by making sure we can write back the result at suspend time. Huge thanks to Christian Sünkenberg for finding the offending erratum that finally deciphered the mystery. Reported-and-tested-by: Johan Heinrich <onny@project-insanity.org> Debugged-by: Christian Sünkenberg <christian.suenkenberg@student.kit.edu> Acked-by: Rafael J. Wysocki <rjw@sisk.pl> Link: http://lkml.kernel.org/r/51DDC972.3010005@student.kit.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* xen/blkback: Check device permissions before allowing OP_DISCARDKonrad Rzeszutek Wilk2013-08-04
| | | | | | | | | | | | | | | | | commit 604c499cbbcc3d5fe5fb8d53306aa0fae1990109 upstream. We need to make sure that the device is not RO or that the request is not past the number of sectors we want to issue the DISCARD operation for. This fixes CVE-2013-2140. Acked-by: Jan Beulich <JBeulich@suse.com> Acked-by: Ian Campbell <Ian.Campbell@citrix.com> [v1: Made it pr_warn instead of pr_debug] Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* xen-netfront: pull on receive skb may need to happen earlierJan Beulich2013-08-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 093b9c71b6e450e375f4646ba86faed0195ec7df upstream. Due to commit 3683243b ("xen-netfront: use __pskb_pull_tail to ensure linear area is big enough on RX") xennet_fill_frags() may end up filling MAX_SKB_FRAGS + 1 fragments in a receive skb, and only reduce the fragment count subsequently via __pskb_pull_tail(). That's a result of xennet_get_responses() allowing a maximum of one more slot to be consumed (and intermediately transformed into a fragment) if the head slot has a size less than or equal to RX_COPY_THRESHOLD. Hence we need to adjust xennet_fill_frags() to pull earlier if we reached the maximum fragment count - due to the described behavior of xennet_get_responses() this guarantees that at least the first fragment will get completely consumed, and hence the fragment count reduced. In order to not needlessly call __pskb_pull_tail() twice, make the original call conditional upon the pull target not having been reached yet, and defer the newly added one as much as possible (an alternative would have been to always call the function right before the call to xennet_fill_frags(), but that would imply more frequent cases of needing to call it twice). Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Wei Liu <wei.liu2@citrix.com> Cc: Ian Campbell <ian.campbell@citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Btrfs: re-add root to dead root list if we stop dropping itJosef Bacik2013-08-04
| | | | | | | | | | | | | | | | commit d29a9f629e009c9b90e5859bce581070fd6247fc upstream. If we stop dropping a root for whatever reason we need to add it back to the dead root list so that we will re-start the dropping next transaction commit. The other case this happens is if we recover a drop because we will add a root without adding it to the fs radix tree, so we can leak it's root and commit root extent buffer, adding this to the dead root list makes this cleanup happen. Thanks, Reported-by: Alex Lyakas <alex.btrfs@zadarastorage.com> Signed-off-by: Josef Bacik <jbacik@fusionio.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Btrfs: fix lock leak when resuming snapshot deletionJosef Bacik2013-08-04
| | | | | | | | | | | | | | commit fec386ac1428f9c0e672df952cbca5cebd4e4e2f upstream. We aren't setting path->locks[level] when we resume a snapshot deletion which means we won't unlock the buffer when we free the path. This causes deadlocks if we happen to re-allocate the block before we've evicted the extent buffer from cache. Thanks, Reported-by: Alex Lyakas <alex.btrfs@zadarastorage.com> Signed-off-by: Josef Bacik <jbacik@fusionio.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Btrfs: fix wrong write offset when replacing a deviceStefan Behrens2013-08-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 115930cb2d444a684975cf2325759cb48ebf80cc upstream. Miao Xie reported the following issue: The filesystem was corrupted after we did a device replace. Steps to reproduce: # mkfs.btrfs -f -m single -d raid10 <device0>..<device3> # mount <device0> <mnt> # btrfs replace start -rfB 1 <device4> <mnt> # umount <mnt> # btrfsck <device4> The reason for the issue is that we changed the write offset by mistake, introduced by commit 625f1c8dc. We read the data from the source device at first, and then write the data into the corresponding place of the new device. In order to implement the "-r" option, the source location is remapped using btrfs_map_block(). The read takes place on the mapped location, and the write needs to take place on the unmapped location. Currently the write is using the mapped location, and this commit changes it back by undoing the change to the write address that the aforementioned commit added by mistake. Reported-by: Miao Xie <miaox@cn.fujitsu.com> Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de> Signed-off-by: Josef Bacik <jbacik@fusionio.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* cpufreq / intel_pstate: Change to scale off of max P-stateDirk Brandewie2013-08-04
| | | | | | | | | | | | | | | | | | | | | | | commit 2134ed4d614349b2b4e8d7bb593baa9179b8dd1e upstream. Change to using max P-state instead of max turbo P-state. This change resolves two issues. On a quiet system intel_pstate can fail to respond to a load change. On CPU SKUs that have a limited number of P-states and no turbo range intel_pstate fails to select the highest available P-state. This change is suitable for stable v3.9+ References: https://bugzilla.kernel.org/show_bug.cgi?id=59481 Reported-and-tested-by: Arjan van de Ven <arjan@linux.intel.com> Reported-and-tested-by: dsmythies@telus.net Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* staging: android: logger: Correct write offset reset on errorKarlis Ogsts2013-08-04
| | | | | | | | | | | | | | | commit 72bb99cfe9c57d2044445fb34bbc95b4c0bae6f2 upstream. In the situation that a writer fails to copy data from userspace it will reset the write offset to the value it had before it went to sleep. This discarding any messages written while aquiring the mutex. Therefore the reset offset needs to be retrieved after acquiring the mutex. Cc: Android Kernel Team <kernel-team@android.com> Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* staging: comedi: COMEDI_CANCEL ioctl should wake up read/writeIan Abbott2013-08-04
| | | | | | | | | | | | | | | | | | | | | | | | | | commit 69acbaac303e8cb948801a9ddd0ac24e86cc4a1b upstream. Comedi devices can do blocking read() or write() (or poll()) if an asynchronous command has been set up, blocking for data (for read()) or buffer space (for write()). Various events associated with the asynchronous command will wake up the blocked reader or writer (or poller). It is also possible to force the asynchronous command to terminate by issuing a `COMEDI_CANCEL` ioctl. That shuts down the asynchronous command, but does not currently wake up the blocked reader or writer (or poller). If the blocked task could be woken up, it would see that the command is no longer active and return. The caller of the `COMEDI_CANCEL` ioctl could attempt to wake up the blocked task by sending a signal, but that's a nasty workaround. Change `do_cancel_ioctl()` to wake up the wait queue after it returns from `do_cancel()`. `do_cancel()` can propagate an error return value from the low-level comedi driver's cancel routine, but it always shuts the command down regardless, so `do_cancel_ioctl()` can wake up he wait queue regardless of the return value from `do_cancel()`. Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* staging: comedi: fix a race between do_cmd_ioctl() and read/writeIan Abbott2013-08-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 4b18f08be01a7b3c7b6df497137b6e3cb28adaa3 upstream. `do_cmd_ioctl()` is called with the comedi device's mutex locked to process the `COMEDI_CMD` ioctl to set up comedi's asynchronous command handling on a comedi subdevice. `comedi_read()` and `comedi_write()` are the `read` and `write` handlers for the comedi device, but do not lock the mutex (for performance reasons, as some things can hold the mutex for quite a long time). There is a race condition if `comedi_read()` or `comedi_write()` is running at the same time and for the same file object and comedi subdevice as `do_cmd_ioctl()`. `do_cmd_ioctl()` sets the subdevice's `busy` pointer to the file object way before it sets the `SRF_RUNNING` flag in the subdevice's `runflags` member. `comedi_read() and `comedi_write()` check the subdevice's `busy` pointer is pointing to the current file object, then if the `SRF_RUNNING` flag is not set, will call `do_become_nonbusy()` to shut down the asyncronous command. Bad things can happen if the asynchronous command is being shutdown and set up at the same time. To prevent the race, don't set the `busy` pointer until after the `SRF_RUNNING` flag has been set. Also, make sure the mutex is held in `comedi_read()` and `comedi_write()` while calling `do_become_nonbusy()` in order to avoid moving the race condition to a point within that function. Change some error handling `goto cleanup` statements in `do_cmd_ioctl()` to simple `return -ERRFOO` statements as a result of changing when the `busy` pointer is set. Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* USB: global suspend and remote wakeup don't mixAlan Stern2013-08-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit e583d9db9960cf40e0bc8afee4946baa9d71596e upstream. The hub driver was recently changed to use "global" suspend for system suspend transitions on non-SuperSpeed buses. This means that we don't suspend devices individually by setting the suspend feature on the upstream hub port; instead devices all go into suspend automatically when the root hub stops transmitting packets. The idea was to save time and to avoid certain kinds of wakeup races. Now it turns out that many hubs are buggy; they don't relay wakeup requests from a downstream port to their upstream port if the downstream port's suspend feature is not set (depending on the speed of the downstream port, whether or not the hub is enabled for remote wakeup, and possibly other factors). We can't have hubs dropping wakeup requests. Therefore this patch goes partway back to the old policy: It sets the suspend feature for a port if the device attached to that port or any of its descendants is enabled for wakeup. People will still be able to benefit from the time savings if they don't care about wakeup and leave it disabled on all their devices. In order to accomplish this, the patch adds a new field to the usb_hub structure: wakeup_enabled_descendants is a count of how many devices below a suspended hub are enabled for remote wakeup. A corresponding new subroutine determines the number of wakeup-enabled devices at or below an arbitrary suspended USB device. This should be applied to the 3.10 stable kernel. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-and-tested-by: Toralf Förster <toralf.foerster@gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: Clear both buffers when clearing a control transfer TT buffer.William Gulland2013-08-04
| | | | | | | | | | | | | commit 2c7b871b9102c497ba8f972aa5d38532f05b654d upstream. Control transfers have both IN and OUT (or SETUP) packets, so when clearing TT buffers for a control transfer it's necessary to send two HUB_CLEAR_TT_BUFFER requests to the hub. Signed-off-by: William Gulland <wgulland@google.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* USB: misc: Add Manhattan Hi-Speed USB DVI Converter to sisusbvgaJóhann B. Guðmundsson2013-08-04
| | | | | | | | commit 58fc90db8261b571c026bb8bf23aad48a7233118 upstream. Signed-off-by: Jóhann B. Guðmundsson <johannbg@fedoraproject.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* USB: ti_usb_3410_5052: fix dynamic-id matchingJohan Hovold2013-08-04
| | | | | | | | | | | | | | | | commit 1fad56424f5ad3ce4973505a357212b2e2282b3f upstream. The driver failed to take the dynamic ids into account when determining the device type and therefore all devices were detected as 2-port devices when using the dynamic-id interface. Match on the usb-serial-driver field instead of doing redundant id-table searches. Reported-by: Anders Hammarquist <iko@iko.pp.se> Signed-off-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: dwc3: gadget: don't prevent gadget from being probed if we failFelipe Balbi2013-08-04
| | | | | | | | | | | | | | | | commit cdcedd6981194e511cc206887db661d016069d68 upstream. In case we fail our ->udc_start() callback, we should be ready to accept another modprobe following the failed one. We had forgotten to clear dwc->gadget_driver back to NULL and, because of that, we were preventing gadget driver modprobe from being retried. Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: dwc3: fix wrong bit mask in dwc3_event_typeHuang Rui2013-08-04
| | | | | | | | | | | | | | | | | | | | | | | | | | commit 1974d494dea05ea227cb42f5e918828801e237aa upstream. Per dwc3 2.50a spec, the is_devspec bit is used to distinguish the Device Endpoint-Specific Event or Device-Specific Event (DEVT). If the bit is 1, the event is represented Device-Specific Event, then use [7:1] bits as Device Specific Event to marked the type. It has 7 bits, and we can see the reserved8_31 variable name which means from 8 to 31 bits marked reserved, actually there are 24 bits not 25 bits between that. And 1 + 7 + 24 = 32, the event size is 4 byes. So in dwc3_event_type, the bit mask should be: is_devspec [0] 1 bit type [7:1] 7 bits reserved8_31 [31:8] 24 bits This patch should be backported to kernels as old as 3.2, that contain the commit 72246da40f3719af3bfd104a2365b32537c27d83 "usb: Introduce DesignWare USB3 DRD Driver". Signed-off-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: dwc3: fix the error returned with usb3_phy failureRuchika Kharwar2013-08-04
| | | | | | | | | | | | commit 315955d707b50c8aad20a32ec0dd4c9fe243cabe upstream. When there is an error with the usb3_phy probe or absence, the error returned is erroneously for usb2_phy. Signed-off-by: Ruchika Kharwar <ruchika@ti.com> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* USB: mos7840: fix memory leak in openJohan Hovold2013-08-04
| | | | | | | | | | commit 5f8a2e68b679b41cc8e9b642f2f5aa45dd678641 upstream. Allocated urbs and buffers were never freed on errors in open. Signed-off-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* USB: EHCI: Fix resume signalling on remote wakeupRoger Quadros2013-08-04
| | | | | | | | | | | | | | | | | | | commit 47a64a13d54f6c669b00542848d5550be3d3310e upstream. Set the ehci->resuming flag for the port we receive a remote wakeup on so that resume signalling can be completed. Without this, the root hub timer will not fire again to check if the resume was completed and there will be a never-ending wait on on the port. This effect is only observed if the HUB IRQ IN does not come after we have initiated the port resume. Signed-off-by: Roger Quadros <rogerq@ti.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* xhci: Avoid NULL pointer deref when host dies.Sarah Sharp2013-08-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 203a86613fb3bf2767335659513fa98563a3eb71 upstream. When the host controller fails to respond to an Enable Slot command, and the host fails to respond to the register write to abort the command ring, the xHCI driver will assume the host is dead, and call usb_hc_died(). The USB device's slot_id is still set to zero, and the pointer stored at xhci->devs[0] will always be NULL. The call to xhci_check_args in xhci_free_dev should have caught the NULL virt_dev pointer. However, xhci_free_dev is designed to free the xhci_virt_device structures, even if the host is dead, so that we don't leak kernel memory. xhci_free_dev checks the return value from the generic xhci_check_args function. If the return value is -ENODEV, it carries on trying to free the virtual device. The issue is that xhci_check_args looks at the host controller state before it looks at the xhci_virt_device pointer. It will return -ENIVAL because the host is dead, and xhci_free_dev will ignore the return value, and happily dereference the NULL xhci_virt_device pointer. The fix is to make sure that xhci_check_args checks the xhci_virt_device pointer before it checks the host state. See https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1203453 for further details. This patch doesn't solve the underlying issue, but will ensure we don't see any more NULL pointer dereferences because of the issue. This patch should be backported to kernels as old as 3.1, that contain the commit 7bd89b4017f46a9b92853940fd9771319acb578a "xhci: Don't submit commands or URBs to halted hosts." Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Reported-by: Vincent Thiele <vincentthiele@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* xhci: fix null pointer dereference on ring_doorbell_for_active_ringsOleksij Rempel2013-08-04
| | | | | | | | | | | | | | | | | | commit d66eaf9f89502971fddcb0de550b01fa6f409d83 upstream. in some cases where device is attched to xhci port and do not responding, for example ath9k_htc with stalled firmware, kernel will crash on ring_doorbell_for_active_rings. This patch check if pointer exist before it is used. This patch should be backported to kernels as old as 2.6.35, that contain the commit e9df17eb1408cfafa3d1844bfc7f22c7237b31b8 "USB: xhci: Correct assumptions about number of rings per endpoint" Signed-off-by: Oleksij Rempel <linux@rempel-privat.de> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: host: xhci: Enable XHCI_SPURIOUS_SUCCESS for all controllers with xhci 1.0George Cherian2013-08-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 07f3cb7c28bf3f4dd80bfb136cf45810c46ac474 upstream. Xhci controllers with hci_version > 0.96 gives spurious success events on short packet completion. During webcam capture the "ERROR Transfer event TRB DMA ptr not part of current TD" was observed. The same application works fine with synopsis controllers hci_version 0.96. The same issue is seen with Intel Pantherpoint xhci controller. So enabling this quirk in xhci_gen_setup if controller verion is greater than 0.96. For xhci-pci move the quirk to much generic place xhci_gen_setup. Note from Sarah: The xHCI 1.0 spec changed how hardware handles short packets. The HW will notify SW of the TRB where the short packet occurred, and it will also give a successful status for the last TRB in a TD (the one with the IOC flag set). On the second successful status, that warning will be triggered in the driver. Software is now supposed to not assume the TD is not completed until it gets that last successful status. That means we have a slight race condition, although it should have little practical impact. This patch papers over that issue. It's on my long-term to-do list to fix this race condition, but it is a much more involved patch that will probably be too big for stable. This patch is needed for stable to avoid serious log spam. This patch should be backported to kernels as old as 3.0, that contain the commit ad808333d8201d53075a11bc8dd83b81f3d68f0b "Intel xhci: Ignore spurious successful event." The patch will have to be modified for kernels older than 3.2, since that kernel added the xhci_gen_setup function for xhci platform devices. The correct conflict resolution for kernels older than 3.2 is to set XHCI_SPURIOUS_SUCCESS in xhci_pci_quirks for all xHCI 1.0 hosts. Signed-off-by: George Cherian <george.cherian@ti.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* tracing: Remove locking trace_types_lock from tracing_reset_all_online_cpus()Steven Rostedt (Red Hat)2013-08-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 09d8091c024ec88d1541d93eb8ddb2bd5cf10c39 upstream. Commit a82274151af "tracing: Protect ftrace_trace_arrays list in trace_events.c" added taking the trace_types_lock mutex in trace_events.c as there were several locations that needed it for protection. Unfortunately, it also encapsulated a call to tracing_reset_all_online_cpus() which also takes the trace_types_lock, causing a deadlock. This happens when a module has tracepoints and has been traced. When the module is removed, the trace events module notifier will grab the trace_types_lock, do a bunch of clean ups, and also clears the buffer by calling tracing_reset_all_online_cpus. This doesn't happen often which explains why it wasn't caught right away. Commit a82274151af was marked for stable, which means this must be sent to stable too. Link: http://lkml.kernel.org/r/51EEC646.7070306@broadcom.com Reported-by: Arend van Spril <arend@broadcom.com> Tested-by: Arend van Spriel <arend@broadcom.com> Cc: Alexander Z Lam <azl@google.com> Cc: Vaibhav Nagarnaik <vnagarnaik@google.com> Cc: David Sharp <dhsharp@google.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* tracing: Kill the unbalanced tr->ref++ in tracing_buffers_open()Oleg Nesterov2013-08-04
| | | | | | | | | | | | | | | | | | | | | | | | commit e70e78e3c83b536730e31231dd9b979768d8df3c upstream. tracing_buffers_open() does trace_array_get() and then it wrongly inrcements tr->ref again under trace_types_lock. This means that every caller leaks trace_array: # cd /sys/kernel/debug/tracing/ # mkdir instances/X # true < instances/X/per_cpu/cpu0/trace_pipe_raw # rmdir instances/X rmdir: failed to remove `instances/X': Device or resource busy Link: http://lkml.kernel.org/r/20130719153644.GA18899@redhat.com Signed-off-by: Oleg Nesterov <oleg@redhat.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* tracing: Miscellaneous fixes for trace_array ref countingAlexander Z Lam2013-08-04
| | | | | | | | | | | | | | | | | commit f77d09a384676bde6445413949d9d2c508ff3e62 upstream. Some error paths did not handle ref counting properly, and some trace files need ref counting. Link: http://lkml.kernel.org/r/1374171524-11948-1-git-send-email-azl@google.com Signed-off-by: Alexander Z Lam <azl@google.com> Cc: Vaibhav Nagarnaik <vnagarnaik@google.com> Cc: David Sharp <dhsharp@google.com> Cc: Alexander Z Lam <lambchop468@gmail.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* tracing: Fix error handling to ensure instances can always be removedAlexander Z Lam2013-08-04
| | | | | | | | | | | | | | | | | | | | commit 609e85a70bcd0eedf4ec60639dbcfb1ab011e054 upstream. Remove debugfs directories for tracing instances during creation if an error occurs causing the trace_array for that instance to not be added to ftrace_trace_arrays. If the directory continues to exist after the error, it cannot be removed because the respective trace_array is not in ftrace_trace_arrays. Link: http://lkml.kernel.org/r/1373502874-1706-2-git-send-email-azl@google.com Signed-off-by: Alexander Z Lam <azl@google.com> Cc: Vaibhav Nagarnaik <vnagarnaik@google.com> Cc: David Sharp <dhsharp@google.com> Cc: Alexander Z Lam <lambchop468@gmail.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* SCSI: qla2xxx: Properly set the tagging for commands.Saurav Kashyap2013-08-04
| | | | | | | | | | | | | | | | commit c3ccb1d7cf4c4549151876dd37c0944a682fd9e1 upstream. This fixes a regression where Xyratex controllers and disks were lost by the driver: https://bugzilla.kernel.org/show_bug.cgi?id=59601 Reported-by: Jack Hill <jackhill@jackhill.us> Signed-off-by: Saurav Kashyap <saurav.kashyap@qlogic.com> Signed-off-by: Giridhar Malavali <giridhar.malavali@qlogic.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* SCSI: sd: fix crash when UA received on DIF enabled deviceEwan D. Milne2013-08-04
| | | | | | | | | | | | | | | | | | | | | | | | commit 085b513f97d8d799d28491239be4b451bcd8c2c5 upstream. sd_prep_fn will allocate a larger CDB for the command via mempool_alloc for devices using DIF type 2 protection. This CDB was being freed in sd_done, which results in a kernel crash if the command is retried due to a UNIT ATTENTION. This change moves the code to free the larger CDB into sd_unprep_fn instead, which is invoked after the request is complete. It is no longer necessary to call scsi_print_command separately for this case as the ->cmnd will no longer be NULL in the normal code path. Also removed conditional test for DIF type 2 when freeing the larger CDB because the protection_type could have been changed via sysfs while the command was executing. Signed-off-by: Ewan D. Milne <emilne@redhat.com> Acked-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* SCSI: isci: Fix a race condition in the SSP task management pathJeff Skirvin2013-08-04
| | | | | | | | | | | | | | | | | commit 96f15f29038e58e1b0a96483e2b369ff446becf1 upstream. This commit fixes a race condition in the isci driver abort task and SSP device task management path. The race is caused when an I/O termination in the SCU hardware is necessary because of an SSP target timeout condition, and the check of the I/O end state races against the HW-termination-driven end state. The failure of the race meant that no TMF was sent to the device to clean-up the pending I/O. Signed-off-by: Jeff Skirvin <jeffrey.d.skirvin@intel.com> Reviewed-by: Lukasz Dorau <lukasz.dorau@intel.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ARM: 7722/1: zImage: Convert 32bits memory size and address from ATAG to ↵Gregory CLEMENT2013-08-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 64bits DTB commit faefd550c45d8d314e8f260f21565320355c947f upstream. When CONFIG_ARM_APPENDED_DTB is selected, if the bootloader provides an ATAG_MEM it replaces the memory size and the memory address in the memory node of the device tree. In the case of a system which can handle more than 4GB, the memory node cell size is 4: each data (memory size and memory address) are 64 bits and then use 2 cells. The current code in atags_to_fdt.c made the assumption of a cell size of 2 (one cell for the memory size and one cell for the memory address), this leads to an improper write of the data and ends with a boot hang. This patch writes the memory size and the memory address on the memory node in the device tree depending of the size of the memory node (32 bits or 64 bits). It has been tested in the 2 cases: - with a dtb using skeleton.dtsi - and with a dtb using skeleton64.dtsi Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Acked-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Cc: Willy Tarreau <w@1wt.eu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ASoC: wm8962: Remove remaining direct register cache accessesNicolin Chen2013-08-04
| | | | | | | | | | | commit 2e7ee15ced914e109a1a5b6dfcd463d846a13bd5 upstream. Also fix return values for headphone switch updates. Signed-off-by: Nicolin Chen <b42378@freescale.com> Signed-off-by: Mark Brown <broonie@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ASoC: tegra: correct playback_dma_data setupRichard Zhao2013-08-04
| | | | | | | | | | | | | | | | | commit 647ab784c507763bfda79155f125b6edd1244806 upstream. The errors were caused by copy/paste mistake in below commit since v3.10: 3489d50 ASoC: tegra: Use common DAI DMA data struct It also corrects slave_id initialization in tegra20_ac97 driver. Signed-off-by: Richard Zhao <rizhao@nvidia.com> Acked-by: Stephen Warren <swarren@nvidia.com> Acked-by: Lucas Stach <dev@lynxeye.de> Signed-off-by: Mark Brown <broonie@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ASoC: max98088 - fix element type of the register cache.Chih-Chung Chang2013-08-04
| | | | | | | | | | | | | | commit cb6f66a2d278e57a6c9d8fb59bd9ebd8ab3965c2 upstream. The registers of max98088 are 8 bits, not 16 bits. This bug causes the contents of registers to be overwritten with bad values when the codec is suspended and then resumed. Signed-off-by: Chih-Chung Chang <chihchung@chromium.org> Signed-off-by: Dylan Reid <dgreid@chromium.org> Signed-off-by: Mark Brown <broonie@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ASoC: sglt5000: Fix the default value of CHIP_SSS_CTRLFabio Estevam2013-08-04
| | | | | | | | | | | | | commit 016fcab8ff46fca29375d484226ec91932aa4a07 upstream. According to the sgtl5000 reference manual, the default value of CHIP_SSS_CTRL is 0x10. Reported-by: Oskar Schirmer <oskar@scara.com> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Mark Brown <broonie@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* firewire: fix libdc1394/FlyCap2 iso event regressionClemens Ladisch2013-08-04
| | | | | | | | | | | | | | | | | | | | commit 0699a73af3811b66b1ab5650575acee5eea841ab upstream. Commit 18d627113b83 (firewire: prevent dropping of completed iso packet header data) was intended to be an obvious bug fix, but libdc1394 and FlyCap2 depend on the old behaviour by ignoring all returned information and thus not noticing that not all packets have been received yet. The result was that the video frame buffers would be saved before they contained the correct data. Reintroduce the old behaviour for old clients. Tested-by: Stepan Salenikovich <stepan.salenikovich@gmail.com> Tested-by: Josep Bosch <jep250@gmail.com> Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ALSA: hda - Guess what, it's two more Dell headset mic quirksDavid Henningsson2013-08-04
| | | | | | | | | | | | | commit cd6fb6793a33e2b02af6e05a8d3f735f7c88a943 upstream. Add two more machines that need quirks for headset mics to work. Tested-by: Shawn Wang <shawn.wang@canonical.com> BugLink: https://bugs.launchpad.net/bugs/1195636 Signed-off-by: David Henningsson <david.henningsson@canonical.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ALSA: hda - Yet another Dell headset mic quirkDavid Henningsson2013-08-04
| | | | | | | | | | | | | commit 6c29d68a82ec68db18241b818d03e7864c052be9 upstream. This quirk is needed for the headset mic to work on this Dell machine. BugLink: https://bugs.launchpad.net/bugs/1195597 Signed-off-by: David Henningsson <david.henningsson@canonical.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* USB: storage: Add MicroVault Flash Drive to unusual_devsRen Bigcren2013-08-04
| | | | | | | | | | | | | commit e7a6121f4929c17215f0cdca3726f4bf3e4e9529 upstream. The device report an error capacity when read_capacity_16(). Using read_capacity_10() can get the correct capacity. Signed-off-by: Ren Bigcren <bigcren.ren@sonymobile.com> Cc: Matthew Dharm <mdharm-usb@one-eyed-alien.net> Signed-off-by: Oskar Andero <oskar.andero@sonymobile.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* iscsi-target: Fix ISCSI_OP_SCSI_TMFUNC handling for iserNicholas Bellinger2013-08-04
| | | | | | | | | | | | | | | | commit 186a9647019587b3784694894c4d136fd00cfd7b upstream. This patch adds target_get_sess_cmd reference counting for iscsit_handle_task_mgt_cmd(), and adds a target_put_sess_cmd() for the failure case. It also fixes a bug where ISCSI_OP_SCSI_TMFUNC type commands where leaking iscsi_cmd->i_conn_node and eventually triggering an OOPs during struct isert_conn shutdown. Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.2 (git 2.25.0) at 2025-01-18 06:43:03 -0500