- 01 Jul, 2014 34 commits
-
-
Thomas Gleixner authored
commit 1e77d0a1 upstream. Till reported that the spurious interrupt detection of threaded interrupts is broken in two ways: - note_interrupt() is called for each action thread of a shared interrupt line. That's wrong as we are only interested whether none of the device drivers felt responsible for the interrupt, but by calling multiple times for a single interrupt line we account IRQ_NONE even if one of the drivers felt responsible. - note_interrupt() when called from the thread handler is not serialized. That leaves the members of irq_desc which are used for the spurious detection unprotected. To solve this we need to defer the spurious detection of a threaded interrupt to the next hardware interrupt context where we have implicit serialization. If note_interrupt is called with action_ret == IRQ_WAKE_THREAD, we check whether the previous interrupt requested a deferred check. If not, we request a deferred check for the next hardware interrupt and return. If set, we check whether one of the interrupt threads signaled success. Depending on this information we feed the result into the spurious detector. If one primary handler of a shared interrupt returns IRQ_HANDLED we disable the deferred check of irq threads on the same line, as we have found at least one device driver who cared. Reported-by:
Till Straumann <strauman@slac.stanford.edu> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Tested-by:
Austin Schuh <austin@peloton-tech.com> Cc: Oliver Hartkopp <socketcan@hartkopp.net> Cc: Wolfgang Grandegger <wg@grandegger.com> Cc: Pavel Pisa <pisa@cmp.felk.cvut.cz> Cc: Marc Kleine-Budde <mkl@pengutronix.de> Cc: linux-can@vger.kernel.org Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1303071450130.22263@ionosSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Mike Frysinger authored
commit 7fd44dac upstream. The io_setup takes a pointer to a context id of type aio_context_t. This in turn is typed to a __kernel_ulong_t. We could tweak the exported headers to define this as a 64bit quantity for specific ABIs, but since we already have a 32bit compat shim for the x86 ABI, let's just re-use that logic. The libaio package is also written to expect this as a pointer type, so a compat shim would simplify that. The io_submit func operates on an array of pointers to iocb structs. Padding out the array to be 64bit aligned is a huge pain, so convert it over to the existing compat shim too. We don't convert io_getevents to the compat func as its only purpose is to handle the timespec struct, and the x32 ABI uses 64bit times. With this change, the libaio package can now pass its testsuite when built for the x32 ABI. Signed-off-by:
Mike Frysinger <vapier@gentoo.org> Link: http://lkml.kernel.org/r/1399250595-5005-1-git-send-email-vapier@gentoo.org Cc: H.J. Lu <hjl.tools@gmail.com> Signed-off-by:
H. Peter Anvin <hpa@zytor.com> Signed-off-by:
-
H. Peter Anvin authored
commit 246f2d2e upstream. It is not safe to use LAR to filter when to go down the espfix path, because the LDT is per-process (rather than per-thread) and another thread might change the descriptors behind our back. Fortunately it is always *safe* (if a bit slow) to go down the espfix path, and a 32-bit LDT stack segment is extremely rare. Signed-off-by:
H. Peter Anvin <hpa@linux.intel.com> Link: http://lkml.kernel.org/r/1398816946-3351-1-git-send-email-hpa@linux.intel.comSigned-off-by:
-
Nicholas A. Bellinger authored
[Note that a different patch to address the same issue went in during v3.15-rc1 (commit 4442dc8a), but includes a bunch of other changes that don't strictly apply to fixing the bug] This patch changes rd_allocate_sgl_table() to explicitly clear ramdisk_mcp backend memory pages by passing __GFP_ZERO into alloc_pages(). This addresses a potential security issue where reading from a ramdisk_mcp could return sensitive information, and follows what >= v3.15 does to explicitly clear ramdisk_mcp memory at backend device initialization time. Reported-by:
Jorge Daniel Sequeira Matias <jdsm@tecnico.ulisboa.pt> Cc: Jorge Daniel Sequeira Matias <jdsm@tecnico.ulisboa.pt> Signed-off-by:
Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by:
-
Russell King authored
commit 3683f44c upstream. While debugging the FEC ethernet driver using stacktrace, it was noticed that the stacktraces always begin as follows: [<c00117b4>] save_stack_trace_tsk+0x0/0x98 [<c0011870>] save_stack_trace+0x24/0x28 ... This is because the stack trace code includes the stack frames for itself. This is incorrect behaviour, and also leads to "skip" doing the wrong thing (which is the number of stack frames to avoid recording.) Perversely, it does the right thing when passed a non-current thread. Fix this by ensuring that we have a known constant number of frames above the main stack trace function, and always skip these. Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Lv Zheng authored
commit 73577d1d upstream. This patch fixes the following issue: If DSDT is customized, no local DSDT copy is needed. References: https://bugzilla.kernel.org/show_bug.cgi?id=69711Signed-off-by:
Enrico Etxe Arte <goitizena.generoa@gmail.com> Signed-off-by:
Lv Zheng <lv.zheng@intel.com> [rjw: Subject] Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Johan Hovold authored
commit 80cc0fcb upstream. Make sure that needs_remote_wake up is always set when there are open ports. Currently close() would unconditionally set needs_remote_wakeup to 0 even though there might still be open ports. This could lead to blocked input and possibly dropped data on devices that do not support remote wakeup (and which must therefore not be runtime suspended while open). Add an open_ports counter (protected by the susp_lock) and only clear needs_remote_wakeup when the last port is closed. Fixes: e6929a90 ("USB: support for autosuspend in sierra while online") Signed-off-by:
Johan Hovold <jhovold@gmail.com> Signed-off-by:
-
Johan Hovold authored
commit 014333f7 upstream. The delayed-write queue was never emptied on disconnect, something which would lead to leaked urbs and transfer buffers if the device is disconnected before being runtime resumed due to a write. Fixes: e6929a90 ("USB: support for autosuspend in sierra while online") Signed-off-by:
-
Johan Hovold authored
commit 7fdd26a0 upstream. Neither the transfer buffer or the urb itself were released in the resume error path for delayed writes. Also on errors, the remainder of the queue was not even processed, which leads to further urb and buffer leaks. The same error path also failed to balance the outstanding-urb counter, something which results in degraded throughput or completely blocked writes. Fix this by releasing urb and buffer and balancing counters on errors, and by always processing the whole queue even when submission of one urb fails. Fixes: e6929a90 ("USB: support for autosuspend in sierra while online") Signed-off-by:
-
Johan Hovold authored
commit 8452727d upstream. Fix use after free or NULL-pointer dereference during suspend and resume. The port data may never have been allocated (port probe failed) or may already have been released by port_remove (e.g. driver is unloaded) when suspend and resume are called. Fixes: e6929a90 ("USB: support for autosuspend in sierra while online") Signed-off-by:
-
Johan Hovold authored
commit 353fe198 upstream. Fix AA deadlock in open error path that would call close() and try to grab the already held disc_mutex. Fixes: b9a44bc1 ("sierra: driver urb handling improvements") Signed-off-by:
-
Johan Hovold authored
commit fb7ad4f9 upstream. Keep trying to submit urbs rather than bail out on first read-urb submission error, which would also prevent I/O for any further ports from being resumed. Instead keep an error count, for all types of failed submissions, and let USB core know that something went wrong. Also make sure to always clear the suspended flag. Currently a failed read-urb submission would prevent cached writes as well as any subsequent writes from being submitted until next suspend-resume cycle, something which may not even necessarily happen. Note that USB core currently only logs an error if an interface resume failed. Fixes: 383cedc3 ("USB: serial: full autosuspend support for the option driver") Signed-off-by:
-
Johan Hovold authored
commit 9096f1fb upstream. The interrupt urb was submitted unconditionally at resume, something which could lead to a NULL-pointer dereference in the urb completion handler as resume may be called after the port and port data is gone. Fix this by making sure the interrupt urb is only submitted and active when the port is open. Fixes: 383cedc3 ("USB: serial: full autosuspend support for the option driver") Signed-off-by:
-
Johan Hovold authored
commit 79eed03e upstream. The delayed-write queue was never emptied at shutdown (close), something which could lead to leaked urbs if the port is closed before being runtime resumed due to a write. When this happens the output buffer would not drain on close (closing_wait timeout), and after consecutive opens, writes could be corrupted with previously buffered data, transfered with reduced throughput or completely blocked. Note that unbusy_queued_urb() was simply moved out of CONFIG_PM. Fixes: 383cedc3 ("USB: serial: full autosuspend support for the option driver") Signed-off-by:
-
Johan Hovold authored
commit 170fad9e upstream. Fix race between write() and suspend() which could lead to writes being dropped (or I/O while suspended) if the device is runtime suspended while a write request is being processed. Specifically, suspend() releases the susp_lock after determining the device is idle but before setting the suspended flag, thus leaving a window where a concurrent write() can submit an urb. Fixes: 383cedc3 ("USB: serial: full autosuspend support for the option driver") Signed-off-by:
-
xiao jin authored
commit d9e93c08 upstream. We find a race between write and resume. usb_wwan_resume run play_delayed() and spin_unlock, but intfdata->suspended still is not set to zero. At this time usb_wwan_write is called and anchor the urb to delay list. Then resume keep running but the delayed urb have no chance to be commit until next resume. If the time of next resume is far away, tty will be blocked in tty_wait_until_sent during time. The race also can lead to writes being reordered. This patch put play_Delayed and intfdata->suspended together in the spinlock, it's to avoid the write race during resume. Fixes: 383cedc3 ("USB: serial: full autosuspend support for the option driver") Signed-off-by:
xiao jin <jin.xiao@intel.com> Signed-off-by:
Zhang, Qi1 <qi1.zhang@intel.com> Reviewed-by:
David Cohen <david.a.cohen@linux.intel.com> Signed-off-by:
-
xiao jin authored
commit db090473 upstream. When enable usb serial for modem data, sometimes the tty is blocked in tty_wait_until_sent because portdata->out_busy always is set and have no chance to be cleared. We find a bug in write error path. usb_wwan_write set portdata->out_busy firstly, then try autopm async with error. No out urb submit and no usb_wwan_outdat_callback to this write, portdata->out_busy can't be cleared. This patch clear portdata->out_busy if usb_wwan_write try autopm async with error. Fixes: 383cedc3 ("USB: serial: full autosuspend support for the option driver") Signed-off-by:
-
Mikulas Patocka authored
commit 972754cf upstream. I had occasional screen corruption with the matrox framebuffer driver and I found out that the reason for the corruption is that the hardware blitter accesses the videoram while it is being written to. The matrox driver has a macro WaitTillIdle() that should wait until the blitter is idle, but it sometimes doesn't work. I added a dummy read mga_inl(M_STATUS) to WaitTillIdle() to fix the problem. The dummy read will flush the write buffer in the PCI chipset, and the next read of M_STATUS will return the hardware status. Since applying this patch, I had no screen corruption at all. Signed-off-by:
Mikulas Patocka <mpatocka@redhat.com> Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by:
-
Maurizio Lombardi authored
commit b5b60778 upstream. The variable "size" is expressed as number of blocks and not as number of clusters, this could trigger a kernel panic when using ext4 with the size of a cluster different from the size of a block. Signed-off-by:
Maurizio Lombardi <mlombard@redhat.com> Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Signed-off-by:
-
Christian Borntraeger authored
commit 993072ee upstream. The IRB might be 96 bytes if the extended-I/O-measurement facility is used. This feature is currently not used by Linux, but struct irb already has the emw defined. So let's make the irb in lowcore match the size of the internal data structure to be future proof. We also have to add a pad, to correctly align the paste. The bigger irb field also circumvents a bug in some QEMU versions that always write the emw field on test subchannel and therefore destroy the paste definitions of this CPU. Running under these QEMU version broke some timing functions in the VDSO and all users of these functions, e.g. some JREs. Signed-off-by:
Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Sebastian Ott <sebott@linux.vnet.ibm.com> Cc: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by:
-
Johannes Weiner authored
commit 71abdc15 upstream. When kswapd exits, it can end up taking locks that were previously held by allocating tasks while they waited for reclaim. Lockdep currently warns about this: On Wed, May 28, 2014 at 06:06:34PM +0800, Gu Zheng wrote: > inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-R} usage. > kswapd2/1151 [HC0[0]:SC0[0]:HE1:SE1] takes: > (&sig->group_rwsem){+++++?}, at: exit_signals+0x24/0x130 > {RECLAIM_FS-ON-W} state was registered at: > mark_held_locks+0xb9/0x140 > lockdep_trace_alloc+0x7a/0xe0 > kmem_cache_alloc_trace+0x37/0x240 > flex_array_alloc+0x99/0x1a0 > cgroup_attach_task+0x63/0x430 > attach_task_by_pid+0x210/0x280 > cgroup_procs_write+0x16/0x20 > cgroup_file_write+0x120/0x2c0 > vfs_write+0xc0/0x1f0 > SyS_write+0x4c/0xa0 > tracesys+0xdd/0xe2 > irq event stamp: 49 > hardirqs last enabled at (49): _raw_spin_unlock_irqrestore+0x36/0x70 > hardirqs last disabled at (48): _raw_spin_lock_irqsave+0x2b/0xa0 > softirqs last enabled at (0): copy_process.part.24+0x627/0x15f0 > softirqs last disabled at (0): (null) > > other info that might help us debug this: > Possible unsafe locking scenario: > > CPU0 > ---- > lock(&sig->group_rwsem); > <Interrupt> > lock(&sig->group_rwsem); > > *** DEADLOCK *** > > no locks held by kswapd2/1151. > > stack backtrace: > CPU: 30 PID: 1151 Comm: kswapd2 Not tainted 3.10.39+ #4 > Call Trace: > dump_stack+0x19/0x1b > print_usage_bug+0x1f7/0x208 > mark_lock+0x21d/0x2a0 > __lock_acquire+0x52a/0xb60 > lock_acquire+0xa2/0x140 > down_read+0x51/0xa0 > exit_signals+0x24/0x130 > do_exit+0xb5/0xa50 > kthread+0xdb/0x100 > ret_from_fork+0x7c/0xb0 This is because the kswapd thread is still marked as a reclaimer at the time of exit. But because it is exiting, nobody is actually waiting on it to make reclaim progress anymore, and it's nothing but a regular thread at this point. Be tidy and strip it of all its powers (PF_MEMALLOC, PF_SWAPWRITE, PF_KSWAPD, and the lockdep reclaim state) before returning from the thread function. Signed-off-by:
Johannes Weiner <hannes@cmpxchg.org> Reported-by:
Gu Zheng <guz.fnst@cn.fujitsu.com> Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> Cc: Tang Chen <tangchen@cn.fujitsu.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Kees Cook authored
commit 1b15d2e5 upstream. Some drivers use the first HID report in the list instead of using an index. In these cases, validation uses ID 0, which was supposed to mean "first known report". This fixes the problem, which was causing at least the lgff family of devices to stop working since hid_validate_values was being called with ID 0, but the devices used single numbered IDs for their reports: 0x05, 0x01, /* Usage Page (Desktop), */ 0x09, 0x05, /* Usage (Gamepad), */ 0xA1, 0x01, /* Collection (Application), */ 0xA1, 0x02, /* Collection (Logical), */ 0x85, 0x01, /* Report ID (1), */ ... Reported-by:
Simon Wood <simon@mungewell.org> Signed-off-by:
Kees Cook <keescook@chromium.org> Reviewed-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Hugh Dickins authored
commit 7f39dda9 upstream. Trinity reports BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:47 in_atomic(): 0, irqs_disabled(): 0, pid: 5787, name: trinity-c27 __might_sleep < down_write < __put_anon_vma < page_get_anon_vma < migrate_pages < compact_zone < compact_zone_order < try_to_compact_pages .. Right, since conversion to mutex then rwsem, we should not put_anon_vma() from inside an rcu_read_lock()ed section: fix the two places that did so. And add might_sleep() to anon_vma_free(), as suggested by Peter Zijlstra. Fixes: 88c22088 ("mm: optimize page_lock_anon_vma() fast-path") Reported-by:
Dave Jones <davej@redhat.com> Signed-off-by:
Hugh Dickins <hughd@google.com> Cc: Peter Zijlstra <peterz@infradead.org> Signed-off-by:
-
Tony Luck authored
commit 74614de1 upstream. When Linux sees an "action optional" machine check (where h/w has reported an error that is not in the current execution path) we generally do not want to signal a process, since most processes do not have a SIGBUS handler - we'd just prematurely terminate the process for a problem that they might never actually see. task_early_kill() decides whether to consider a process - and it checks whether this specific process has been marked for early signals with "prctl", or if the system administrator has requested early signals for all processes using /proc/sys/vm/memory_failure_early_kill. But for MF_ACTION_REQUIRED case we must not defer. The error is in the execution path of the current thread so we must send the SIGBUS immediatley. Fix by passing a flag argument through collect_procs*() to task_early_kill() so it knows whether we can defer or must take action. Signed-off-by:
Tony Luck <tony.luck@intel.com> Signed-off-by:
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Cc: Andi Kleen <andi@firstfloor.org> Cc: Borislav Petkov <bp@suse.de> Cc: Chen Gong <gong.chen@linux.jf.intel.com> Signed-off-by:
-
Tony Luck authored
commit a70ffcac upstream. When a thread in a multi-threaded application hits a machine check because of an uncorrectable error in memory - we want to send the SIGBUS with si.si_code = BUS_MCEERR_AR to that thread. Currently we fail to do that if the active thread is not the primary thread in the process. collect_procs() just finds primary threads and this test: if ((flags & MF_ACTION_REQUIRED) && t == current) { will see that the thread we found isn't the current thread and so send a si.si_code = BUS_MCEERR_AO to the primary (and nothing to the active thread at this time). We can fix this by checking whether "current" shares the same mm with the process that collect_procs() said owned the page. If so, we send the SIGBUS to current (with code BUS_MCEERR_AR). Signed-off-by:
Otto Bruggeman <otto.g.bruggeman@intel.com> Cc: Andi Kleen <andi@firstfloor.org> Cc: Borislav Petkov <bp@suse.de> Cc: Chen Gong <gong.chen@linux.jf.intel.com> Signed-off-by:
-
Johan Hovold authored
commit acf47d4f upstream. Fix potential I/O while runtime suspended due to missing PM operations in send_setup. Fixes: 383cedc3 ("USB: serial: full autosuspend support for the option driver") Signed-off-by:
-
Alan Stern authored
commit b0a50e92 upstream. Leandro Liptak reports that his HASEE E200 computer hangs when we ask the BIOS to hand over control of the EHCI host controller. This definitely sounds like a bug in the BIOS, but at the moment there is no way to fix it. This patch works around the problem by avoiding the handoff whenever the motherboard and BIOS version match those of Leandro's computer. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Reported-by:
Leandro Liptak <leandroliptak@gmail.com> Tested-by:
-
Felipe Balbi authored
commit 687ef981 upstream. so it seems like DWC3 IP doesn't clear stalls automatically when we disable an endpoint, because of that, we _must_ make sure stalls are cleared before clearing the proper bit in DALEPENA register. Reported-by:
Johannes Stezenbach <js@sig21.net> Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Paul Bolle authored
commit d30f2065 upstream. Commit 193ab2a6 ("usb: gadget: allow multiple gadgets to be built") basically renamed the Kconfig symbol USB_GADGET_PXA25X to USB_PXA25X. It did not rename the related macros in use at that time. Commit c0a39151 ("ARM: pxa: fix inconsistent CONFIG_USB_PXA27X") did so for all but one macro. Rename that last macro too now. Fixes: 193ab2a6 ("usb: gadget: allow multiple gadgets to be built") Signed-off-by:
Paul Bolle <pebolle@tiscali.nl> Signed-off-by:
-
Alan Stern authored
commit 32b36eea upstream. In usbtest, tests 5 - 8 use the scatter-gather library in usbcore without any sort of timeout. If there's a problem in the gadget or host controller being tested, the test can hang. This patch adds a 10-second timeout to the tests, so that they will fail gracefully with an ETIMEDOUT error instead of hanging. Signed-off-by:
Huang Rui <ray.huang@amd.com> Tested-by:
-
Huang Rui authored
commit e4d58f5d upstream. TEST 12 and TEST 24 unlinks the URB write request for N times. When host and gadget both initialize pattern 1 (mod 63) data series to transfer, the gadget side will complain the wrong data which is not expected. Because in host side, usbtest doesn't fill the data buffer as mod 63 and this patch fixed it. [20285.488974] dwc3 dwc3.0.auto: ep1out-bulk: Transfer Not Ready [20285.489181] dwc3 dwc3.0.auto: ep1out-bulk: reason Transfer Not Active [20285.489423] dwc3 dwc3.0.auto: ep1out-bulk: req ffff8800aa6cb480 dma aeb50800 length 512 last [20285.489727] dwc3 dwc3.0.auto: ep1out-bulk: cmd 'Start Transfer' params 00000000 a9eaf000 00000000 [20285.490055] dwc3 dwc3.0.auto: Command Complete --> 0 [20285.490281] dwc3 dwc3.0.auto: ep1out-bulk: Transfer Not Ready [20285.490492] dwc3 dwc3.0.auto: ep1out-bulk: reason Transfer Active [20285.490713] dwc3 dwc3.0.auto: ep1out-bulk: endpoint busy [20285.490909] dwc3 dwc3.0.auto: ep1out-bulk: Transfer Complete [20285.491117] dwc3 dwc3.0.auto: request ffff8800aa6cb480 from ep1out-bulk completed 512/512 ===> 0 [20285.491431] zero gadget: bad OUT byte, buf[1] = 0 [20285.491605] dwc3 dwc3.0.auto: ep1out-bulk: cmd 'Set Stall' params 00000000 00000000 00000000 [20285.491915] dwc3 dwc3.0.auto: Command Complete --> 0 [20285.492099] dwc3 dwc3.0.auto: queing request ffff8800aa6cb480 to ep1out-bulk length 512 [20285.492387] dwc3 dwc3.0.auto: ep1out-bulk: Transfer Not Ready [20285.492595] dwc3 dwc3.0.auto: ep1out-bulk: reason Transfer Not Active [20285.492830] dwc3 dwc3.0.auto: ep1out-bulk: req ffff8800aa6cb480 dma aeb51000 length 512 last [20285.493135] dwc3 dwc3.0.auto: ep1out-bulk: cmd 'Start Transfer' params 00000000 a9eaf000 00000000 [20285.493465] dwc3 dwc3.0.auto: Command Complete --> 0 Signed-off-by:
-
Dan Carpenter authored
commit 8bab797c upstream. This is a static checker fix. The "dev" variable is always NULL after the while statement so we would be dereferencing a NULL pointer here. Fixes: 819a3eba ('[PATCH] applicom: fix error handling') Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Paul Bolle authored
commit d3921a03 upstream. Commit d0f47ff1 ("ASoC: OMAP: Build config cleanup for McBSP") removed the Kconfig symbol OMAP_MCBSP. It left two checks for CONFIG_OMAP_MCBSP untouched. Convert these to checks for CONFIG_SND_OMAP_SOC_MCBSP. That must be correct, since that re-enables calls to functions that are all found in sound/soc/omap/mcbsp.c. And that file is built only if CONFIG_SND_OMAP_SOC_MCBSP is defined. Fixes: d0f47ff1 ("ASoC: OMAP: Build config cleanup for McBSP") Signed-off-by:
-
Stephane Grosjean authored
commit 0b5a958c upstream. As remarked by Christopher R. Baker in his post at http://marc.info/?l=linux-can&m=139707295706465&w=2 there's a possibility for an use after free condition at device removal. This simplified patch introduces an additional variable to prevent the issue. Thanks for catching this. Reported-by:
Christopher R. Baker <cbaker@rec.ri.cmu.edu> Signed-off-by:
Stephane Grosjean <s.grosjean@peak-system.com> Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
-
- 26 Jun, 2014 6 commits
-
-
Greg Kroah-Hartman authored
-
Greg Kroah-Hartman authored
commit 206a81c1 upstream. The lzo decompressor can, if given some really crazy data, possibly overrun some variable types. Modify the checking logic to properly detect overruns before they happen. Reported-by:
"Don A. Bailey" <donb@securitymouse.com> Tested-by:
-
Markus F.X.J. Oberhumer authored
commit 8b975bd3 upstream. This commit updates the kernel LZO code to the current upsteam version which features a significant speed improvement - benchmarking the Calgary and Silesia test corpora typically shows a doubled performance in both compression and decompression on modern i386/x86_64/powerpc machines. Signed-off-by:
Markus F.X.J. Oberhumer <markus@oberhumer.com> Signed-off-by:
-
Markus F.X.J. Oberhumer authored
commit b6bec26c upstream. Rename the source file to match the function name and thereby also make room for a possible future even slightly faster "non-safe" decompressor version. Signed-off-by:
-
Lars-Peter Clausen authored
commit 883a1d49 upstream. The ALSA control code expects that the range of assigned indices to a control is continuous and does not overflow. Currently there are no checks to enforce this. If a control with a overflowing index range is created that control becomes effectively inaccessible and unremovable since snd_ctl_find_id() will not be able to find it. This patch adds a check that makes sure that controls with a overflowing index range can not be created. Signed-off-by:
Lars-Peter Clausen <lars@metafoo.de> Acked-by:
Jaroslav Kysela <perex@perex.cz> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Lars-Peter Clausen authored
commit ac902c11 upstream. Each control gets automatically assigned its numids when the control is created. The allocation is done by incrementing the numid by the amount of allocated numids per allocation. This means that excessive creation and destruction of controls (e.g. via SNDRV_CTL_IOCTL_ELEM_ADD/REMOVE) can cause the id to eventually overflow. Currently when this happens for the control that caused the overflow kctl->id.numid + kctl->count will also over flow causing it to be smaller than kctl->id.numid. Most of the code assumes that this is something that can not happen, so we need to make sure that it won't happen Signed-off-by:
-
