- 09 Oct, 2014 16 commits
-
-
Steven Rostedt (Red Hat) authored
commit 24607f11 upstream. Commit 651e22f2 "ring-buffer: Always reset iterator to reader page" fixed one bug but in the process caused another one. The reset is to update the header page, but that fix also changed the way the cached reads were updated. The cache reads are used to test if an iterator needs to be updated or not. A ring buffer iterator, when created, disables writes to the ring buffer but does not stop other readers or consuming reads from happening. Although all readers are synchronized via a lock, they are only synchronized when in the ring buffer functions. Those functions may be called by any number of readers. The iterator continues down when its not interrupted by a consuming reader. If a consuming read occurs, the iterator starts from the beginning of the buffer. The way the iterator sees that a consuming read has happened since its last read is by checking the reader "cache". The cache holds the last counts of the read and the reader page itself. Commit 651e22f2 changed what was saved by the cache_read when the rb_iter_reset() occurred, making the iterator never match the cache. Then if the iterator calls rb_iter_reset(), it will go into an infinite loop by checking if the cache doesn't match, doing the reset and retrying, just to see that the cache still doesn't match! Which should never happen as the reset is suppose to set the cache to the current value and there's locks that keep a consuming reader from having access to the data. Fixes: 651e22f2 "ring-buffer: Always reset iterator to reader page" Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Josh Triplett authored
commit 62b4d204 upstream. commit 03b8c7b6 ("futex: Allow architectures to skip futex_atomic_cmpxchg_inatomic() test") added the HAVE_FUTEX_CMPXCHG symbol right below FUTEX. This placed it right in the middle of the options for the EXPERT menu. However, HAVE_FUTEX_CMPXCHG does not depend on EXPERT or FUTEX, so Kconfig stops placing items in the EXPERT menu, and displays the remaining several EXPERT items (starting with EPOLL) directly in the General Setup menu. Since both users of HAVE_FUTEX_CMPXCHG only select it "if FUTEX", make HAVE_FUTEX_CMPXCHG itself depend on FUTEX. With this change, the subsequent items display as part of the EXPERT menu again; the EMBEDDED menu now appears as the next top-level item in the General Setup menu, which makes General Setup much shorter and more usable. Signed-off-by:
Josh Triplett <josh@joshtriplett.org> Acked-by:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
-
Steve French authored
commit 19e81573 upstream. Changeset eb85d94b introduced a problem where if a cifs open fails during query info of a file we will still try to close the file (happens with certain types of reparse points) even though the file handle is not valid. In addition for SMB2/SMB3 we were not mapping the return code returned by Windows when trying to open a file (like a Windows NFS symlink) which is a reparse point. Signed-off-by:
Steve French <smfrench@gmail.com> Reviewed-by:
Pavel Shilovsky <pshilovsky@samba.org> Signed-off-by:
-
Chris Wilson authored
commit 91e56499 upstream. As we use WC updates of the PTE, we are responsible for notifying the hardware when to flush its TLBs. Do so after we zap all the PTEs before suspend (and the BIOS tries to read our GTT). Fixes a regression from commit 828c7908 Author: Ben Widawsky <benjamin.widawsky@intel.com> Date: Wed Oct 16 09:21:30 2013 -0700 drm/i915: Disable GGTT PTEs on GEN6+ suspend that survived and continue to cause harm even after commit e568af1c Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Mar 26 20:08:20 2014 +0100 drm/i915: Undo gtt scratch pte unmapping again v2: Trivial rebase. v3: Fixes requires pointer dances. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82340 Tested-by: ming.yao@intel.com Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Takashi Iwai <tiwai@suse.de> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Todd Previte <tprevite@gmail.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
NeilBrown authored
commit 8e0e99ba upstream. It has come to my attention (thanks Martin) that 'discard_zeroes_data' is only a hint. Some devices in some cases don't do what it says on the label. The use of DISCARD in RAID5 depends on reads from discarded regions being predictably zero. If a write to a previously discarded region performs a read-modify-write cycle it assumes that the parity block was consistent with the data blocks. If all were zero, this would be the case. If some are and some aren't this would not be the case. This could lead to data corruption after a device failure when data needs to be reconstructed from the parity. As we cannot trust 'discard_zeroes_data', ignore it by default and so disallow DISCARD on all raid4/5/6 arrays. As many devices are trustworthy, and as there are benefits to using DISCARD, add a module parameter to over-ride this caution and cause DISCARD to work if discard_zeroes_data is set. If a site want to enable DISCARD on some arrays but not on others they should select DISCARD support at the filesystem level, and set the raid456 module parameter. raid456.devices_handle_discard_safely=Y As this is a data-safety issue, I believe this patch is suitable for -stable. DISCARD support for RAID456 was added in 3.7 Cc: Shaohua Li <shli@kernel.org> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: Mike Snitzer <snitzer@redhat.com> Cc: Heinz Mauelshagen <heinzm@redhat.com> Acked-by:
Martin K. Petersen <martin.petersen@oracle.com> Acked-by:
Mike Snitzer <snitzer@redhat.com> Fixes: 620125f2Signed-off-by:
NeilBrown <neilb@suse.de> Signed-off-by:
-
Rafael J. Wysocki authored
commit e65b5ddb upstream. Fix the following bug introduced by commit 8fec051e (cpufreq: Convert existing drivers to use cpufreq_freq_transition_{begin|end}) that forgot to move the spin_lock() in pcc_cpufreq_target() past cpufreq_freq_transition_begin() which calls wait_event(): BUG: sleeping function called from invalid context at drivers/cpufreq/cpufreq.c:370 in_atomic(): 1, irqs_disabled(): 0, pid: 2636, name: modprobe Preemption disabled at:[<ffffffffa04d74d7>] pcc_cpufreq_target+0x27/0x200 [pcc_cpufreq] [ 51.025044] CPU: 57 PID: 2636 Comm: modprobe Tainted: G E 3.17.0-default #7 Hardware name: Hewlett-Packard ProLiant DL980 G7, BIOS P66 07/07/2010 00000000ffffffff ffff88026c46b828 ffffffff81589dbd 0000000000000000 ffff880037978090 ffff88026c46b848 ffffffff8108e1df ffff880037978090 0000000000000000 ffff88026c46b878 ffffffff8108e298 ffff88026d73ec00 Call Trace: [<ffffffff81589dbd>] dump_stack+0x4d/0x90 [<ffffffff8108e1df>] ___might_sleep+0x10f/0x180 [<ffffffff8108e298>] __might_sleep+0x48/0xd0 [<ffffffff8145b905>] cpufreq_freq_transition_begin+0x75/0x140 drivers/cpufreq/cpufreq.c:370 wait_event(policy->transition_wait, !policy->transition_ongoing); [<ffffffff8108fc99>] ? preempt_count_add+0xb9/0xc0 [<ffffffffa04d7513>] pcc_cpufreq_target+0x63/0x200 [pcc_cpufreq] drivers/cpufreq/pcc-cpufreq.c:207 spin_lock(&pcc_lock); [<ffffffff810e0d0f>] ? update_ts_time_stats+0x7f/0xb0 [<ffffffff8145be55>] __cpufreq_driver_target+0x85/0x170 [<ffffffff8145e4c8>] od_check_cpu+0xa8/0xb0 [<ffffffff8145ef10>] dbs_check_cpu+0x180/0x1d0 [<ffffffff8145f310>] cpufreq_governor_dbs+0x3b0/0x720 [<ffffffff8145ebe3>] od_cpufreq_governor_dbs+0x33/0xe0 [<ffffffff814593d9>] __cpufreq_governor+0xa9/0x210 [<ffffffff81459fb2>] cpufreq_set_policy+0x1e2/0x2e0 [<ffffffff8145a6cc>] cpufreq_init_policy+0x8c/0x110 [<ffffffff8145c9a0>] ? cpufreq_update_policy+0x1b0/0x1b0 [<ffffffff8108fb99>] ? preempt_count_sub+0xb9/0x100 [<ffffffff8145c6c6>] __cpufreq_add_dev+0x596/0x6b0 [<ffffffffa016c608>] ? pcc_cpufreq_probe+0x4b4/0x4b4 [pcc_cpufreq] [<ffffffff8145c7ee>] cpufreq_add_dev+0xe/0x10 [<ffffffff81408e81>] subsys_interface_register+0xc1/0xf0 [<ffffffff8108fb99>] ? preempt_count_sub+0xb9/0x100 [<ffffffff8145b3d7>] cpufreq_register_driver+0x117/0x2a0 [<ffffffffa016c65d>] pcc_cpufreq_init+0x55/0x9f8 [pcc_cpufreq] [<ffffffffa016c608>] ? pcc_cpufreq_probe+0x4b4/0x4b4 [pcc_cpufreq] [<ffffffff81000298>] do_one_initcall+0xc8/0x1f0 [<ffffffff811a731d>] ? __vunmap+0x9d/0x100 [<ffffffff810eb9a0>] do_init_module+0x30/0x1b0 [<ffffffff810edfa6>] load_module+0x686/0x710 [<ffffffff810ebb20>] ? do_init_module+0x1b0/0x1b0 [<ffffffff810ee1db>] SyS_init_module+0x9b/0xc0 [<ffffffff8158f7a9>] system_call_fastpath+0x16/0x1b Fixes: 8fec051e (cpufreq: Convert existing drivers to use cpufreq_freq_transition_{begin|end}) Reported-and-tested-by:
Mike Galbraith <umgwanakikbuti@gmail.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Arnd Bergmann authored
commit d62dbf77 upstream. When building this driver as a module, we get a helpful warning about the return type: drivers/cpufreq/integrator-cpufreq.c:232:2: warning: initialization from incompatible pointer type .remove = __exit_p(integrator_cpufreq_remove), If the remove callback returns void, the caller gets an undefined value as it expects an integer to be returned. This fixes the problem by passing down the value from cpufreq_unregister_driver. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Aaron Lu authored
commit 77076c7a upstream. Some of the Thinkpads' firmware will issue a backlight change request through i915 operation region unconditionally on AC plug/unplug, the backlight level used is arbitrary and thus should be ignored. This is handled by commit 0b9f7d93 (ACPI / i915: ignore firmware requests for backlight change). Then there is a Dell laptop whose vendor backlight interface also makes use of operation region to change backlight level and with the above commit, that interface no long works. The condition used to ignore the backlight change request from firmware is thus changed to: if the vendor backlight interface is not in use and the ACPI backlight interface is broken, we ignore the requests; oterwise, we keep processing them. Fixes: 0b9f7d93 (ACPI / i915: ignore firmware requests for backlight change) Link: https://lkml.org/lkml/2014/9/23/854Reported-and-tested-by:
Pali Rohár <pali.rohar@gmail.com> Signed-off-by:
Aaron Lu <aaron.lu@intel.com> Acked-by:
Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
-
Alexandru M Stan authored
commit cf27020d upstream. i2cdetect -q was broken (everything was a false positive, and no transfers were actually being sent over i2c). The way it works is by sending a 0 length write request and checking for NACK. This patch fixes the 0 length writes and actually sends them. Reported-by:
Doug Anderson <dianders@chromium.org> Signed-off-by:
Alexandru M Stan <amstan@chromium.org> Tested-by:
Max Schwarz <max.schwarz@online.de> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
-
Andy Gross authored
commit 86b59bbf upstream. The runtime pm calls need to be done before populating the children via the i2c_add_adapter call. If this is not done, a child can run into issues trying to do i2c read/writes due to the pm_runtime_sync failing. Signed-off-by:
Andy Gross <agross@codeaurora.org> Reviewed-by:
Felipe Balbi <balbi@ti.com> Acked-by:
Bjorn Andersson <bjorn.andersson@sonymobile.com> Signed-off-by:
-
Mel Gorman authored
commit d3cb8bf6 upstream. A migration entry is marked as write if pte_write was true at the time the entry was created. The VMA protections are not double checked when migration entries are being removed as mprotect marks write-migration-entries as read. It means that potentially we take a spurious fault to mark PTEs write again but it's straight-forward. However, there is a race between write migrations being marked read and migrations finishing. This potentially allows a PTE to be write that should have been read. Close this race by double checking the VMA permissions using maybe_mkwrite when migration completes. [torvalds@linux-foundation.org: use maybe_mkwrite] Signed-off-by:
Mel Gorman <mgorman@suse.de> Acked-by:
Rik van Riel <riel@redhat.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Johannes Weiner authored
commit 2f7dd7a4 upstream. The cgroup iterators yield css objects that have not yet gone through css_online(), but they are not complete memcgs at this point and so the memcg iterators should not return them. Commit d8ad3055 ("mm/memcg: iteration skip memcgs not yet fully initialized") set out to implement exactly this, but it uses CSS_ONLINE, a cgroup-internal flag that does not meet the ordering requirements for memcg, and so the iterator may skip over initialized groups, or return partially initialized memcgs. The cgroup core can not reasonably provide a clear answer on whether the object around the css has been fully initialized, as that depends on controller-specific locking and lifetime rules. Thus, introduce a memcg-specific flag that is set after the memcg has been initialized in css_online(), and read before mem_cgroup_iter() callers access the memcg members. Signed-off-by:
Johannes Weiner <hannes@cmpxchg.org> Cc: Tejun Heo <tj@kernel.org> Acked-by:
Michal Hocko <mhocko@suse.cz> Cc: Hugh Dickins <hughd@google.com> Cc: Peter Zijlstra <peterz@infradead.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Peter Zijlstra authored
commit 6c72e350 upstream. Oleg noticed that a cleanup by Sylvain actually uncovered a bug; by calling perf_event_free_task() when failing sched_fork() we will not yet have done the memset() on ->perf_event_ctxp[] and will therefore try and 'free' the inherited contexts, which are still in use by the parent process. This is bad.. Suggested-by:
Oleg Nesterov <oleg@redhat.com> Reported-by:
Sylvain 'ythier' Hitier <sylvain.hitier@gmail.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Xiubo Li authored
commit 6596aa04 upstream. Since we cannot make sure the 'params->num_regs' will always be none zero here, and then if it equals to zero, the kmemdup() will return ZERO_SIZE_PTR, which equals to ((void *)16). So this patch fix this with just doing the zero check before calling kmemdup(). Signed-off-by:
Xiubo Li <Li.Xiubo@freescale.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Stefan Kristiansson authored
commit fe2a08b3 upstream. The correct type (SSM2602/SSM2603/SSM2604) is passed down from the ssm2602_spi_probe()/ssm2602_spi_probe() functions, so use that instead of hardcoding it to SSM2602 in ssm2602_probe(). Fixes: c924dc68 ("ASoC: ssm2602: Split SPI and I2C code into different modules") Signed-off-by:
Stefan Kristiansson <stefan.kristiansson@saunalahti.fi> Signed-off-by:
Lars-Peter Clausen <lars@metafoo.de> Signed-off-by:
-
Jan Kara authored
commit c03aa9f6 upstream. We did not implement any bound on number of indirect ICBs we follow when loading inode. Thus corrupted medium could cause kernel to go into an infinite loop, possibly causing a stack overflow. Fix the possible stack overflow by removing recursion from __udf_read_inode() and limit number of indirect ICBs we follow to avoid infinite loops. Signed-off-by:
Jan Kara <jack@suse.cz> Cc: Chuck Ebbert <cebbert.lkml@gmail.com> Signed-off-by:
-
- 05 Oct, 2014 24 commits
-
-
Greg Kroah-Hartman authored
-
Rajendra Nayak authored
commit af438fec upstream. Use the corresponding compatibles to identify the devices. Signed-off-by:
Rajendra Nayak <rnayak@ti.com> Signed-off-by:
Lokesh Vutla <lokeshvutla@ti.com> Acked-by:
Nishanth Menon <nm@ti.com> Tested-by:
Paul Walmsley <paul@pwsan.com> Cc: Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Stephen Boyd authored
commit 5b6b7490 upstream. Sometimes we need to program PLLs with a fixed rate configuration during driver probe. Doing this after we register the PLLs with the clock framework causes the common clock framework to assume the rate of the PLLs are 0. This causes all sorts of problems for rate recalculations because the common clock framework caches the rate once at registration time unless a flag is set to always recalculate the rates. Split the qcom_cc_probe() function into two pieces, map and everything else, so that drivers which need to configure some PLL rates or otherwise twiddle bits in the clock controller can do so before registering clocks. This allows us to properly detect the rates of PLLs that are programmed at boot. Fixes: 49fc825f "clk: qcom: Consolidate common probe code" Signed-off-by:
Stephen Boyd <sboyd@codeaurora.org> Signed-off-by:
-
Stephen Boyd authored
commit f87dfcab upstream. The mdp_lut_clk isn't a child of the mdp_clk. Instead it's the child of the mdp_src clock. Fix it. Fixes: 6d00b56f "clk: qcom: Add support for MSM8960's multimedia clock controller (MMCC)" Signed-off-by:
-
Stephen Boyd authored
commit ff20783f upstream. Clocks that don't have a pre-divider don't list any pre-divider in their frequency tables, but their tables are initialized using aggregate initializers. Use tagged initializers so we properly assign the m and n values for each frequency. Furthermore, the mmcc_pxo_pll8_pll2_pll3 array improperly mapped the second element to pll2 instead of pll8, causing the clock driver to recalculate the wrong rate for any clocks using this array along with a rate that uses pll2. Plus the .num_parents field is 3 instead of 4 so you can't even switch the parent to pll3. Finally I noticed that the jpegd clock improperly indicates that the pre-divider width is only 2, when it's actually 4 bits wide. Fixes: 6d00b56f "clk: qcom: Add support for MSM8960's multimedia clock controller (MMCC)" Tested-by:
Rob Clark <robdclark@gmail.com> Signed-off-by:
-
Arnd Bergmann authored
commit 0bf22be0 upstream. The lustre virtual block device cannot handle 64K pages and fails at compile time. To avoid running into this error, let's disable the Kconfig option for this driver in cases it doesn't support. Reported-by:
Dann Frazier <dann.frazier@canonical.com> Signed-off-by:
-
Theodore Ts'o authored
commit a9cfcd63 upstream. Thanks to Dan Carpenter for extending smatch to find bugs like this. (This was found using a development version of smatch.) Fixes: 36de9286 Reported-by: Dan Carpenter <dan.carpenter@oracle.com Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Signed-off-by:
-
Theodore Ts'o authored
commit 36de9286 upstream. If we run into some kind of error, such as ENOMEM, while calling ext4_getblk() or ext4_dx_find_entry(), we need to make sure this error gets propagated up to ext4_find_entry() and then to its callers. This way, transient errors such as ENOMEM can get propagated to the VFS. This is important so that the system calls return the appropriate error, and also so that in the case of ext4_lookup(), we return an error instead of a NULL inode, since that will result in a negative dentry cache entry that will stick around long past the OOM condition which caused a transient ENOMEM error. Google-Bug-Id: #17142205 Signed-off-by:
-
Gu Zheng authored
commit 6098b45b upstream. It seems that exit_aio() also needs to wait for all iocbs to complete (like io_destroy), but we missed the wait step in current implemention, so fix it in the same way as we did in io_destroy. Signed-off-by:
Gu Zheng <guz.fnst@cn.fujitsu.com> Signed-off-by:
Benjamin LaHaise <bcrl@kvack.org> [bwh: Backported to 3.16: adjust context] Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
Suman Tripathi authored
commit 72f79f9e upstream. This patch removes the NCQ support from the APM X-Gene SoC AHCI Host Controller driver as it doesn't support it. Signed-off-by:
Loc Ho <lho@apm.com> Signed-off-by:
Suman Tripathi <stripathi@apm.com> Signed-off-by:
Tejun Heo <tj@kernel.org> [bwh: Backported to 3.16: host flags are passed to ahci_platform_init_host()] Signed-off-by:
-
Nishanth Menon authored
commit 2f103251 upstream. Check for valid parameters in check rate. Else, we end up getting errors like: [ 0.000000] Division by zero in kernel. [ 0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.17.0-rc1 #1 [ 0.000000] [<c0015160>] (unwind_backtrace) from [<c0011978>] (show_stack+0x10/0x14) [ 0.000000] [<c0011978>] (show_stack) from [<c055f5f4>] (dump_stack+0x78/0x94) [ 0.000000] [<c055f5f4>] (dump_stack) from [<c02e17cc>] (Ldiv0+0x8/0x10) [ 0.000000] [<c02e17cc>] (Ldiv0) from [<c047d228>] (ti_clk_divider_set_rate+0x14/0x14c) [ 0.000000] [<c047d228>] (ti_clk_divider_set_rate) from [<c047a938>] (clk_change_rate+0x138/0x180) [ 0.000000] [<c047a938>] (clk_change_rate) from [<c047a908>] (clk_change_rate+0x108/0x180) This occurs as part of the inital clock tree update of child clock nodes where new_rate could be 0 for non functional clocks. Fixes: b4761198 ("CLK: ti: add support for ti divider-clock") Signed-off-by:
Tero Kristo <t-kristo@ti.com> Signed-off-by:
-
Tero Kristo authored
commit 067bb174 upstream. In some cases, clocks can switch their parent with clk_set_rate, for example clk_mux can do this in some cases. Current implementation of clk_change_rate uses un-safe list iteration on the clock children, which will cause wrong clocks to be parsed in case any of the clock children change their parents during the change rate operation. Fixed by using the safe list iterator instead. The problem was detected due to some divide by zero errors generated by clock init on dra7-evm board, see discussion under http://article.gmane.org/gmane.linux.ports.arm.kernel/349180 for details. Fixes: 71472c0c ("clk: add support for clock reparent on set_rate") Signed-off-by:
Mike Turquette <mturquette@linaro.org> Signed-off-by:
-
Nishanth Menon authored
commit 20411dad upstream. Check for valid parameters in check rate. Else, we end up getting errors. This occurs as part of the inital clock tree update of child clock nodes where new_rate could be 0 for non functional clocks. Fixes: 9ac33b0c (" CLK: TI: Driver for DRA7 ATL (Audio Tracking Logic)") Signed-off-by:
-
Viresh Kumar authored
commit b1b12bab upstream. Commit 8e30444e ("cpufreq: fix cpufreq suspend/resume for intel_pstate") introduced a bug where the governors wouldn't be stopped anymore for ->target{_index}() drivers during suspend. This happens because 'cpufreq_suspended' is updated before stopping the governors during suspend and due to this __cpufreq_governor() would return early due to this check: /* Don't start any governor operations if we are entering suspend */ if (cpufreq_suspended) return 0; Fixes: 8e30444e ("cpufreq: fix cpufreq suspend/resume for intel_pstate") Signed-off-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
-
Dan Carpenter authored
commit d97a86c1 upstream. The lvip[] array has "state->limit" elements so the condition here should be >= instead of >. Fixes: 6ceea22b ('partitions: add aix lvm partition support files') Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
Philippe De Muyter <phdm@macqel.be> Signed-off-by:
Jens Axboe <axboe@fb.com> Signed-off-by:
-
Andy Shevchenko authored
commit dd8ecfca upstream. Accordingly to discussion [1] and followed up documentation the DMA controller driver shouldn't start any DMA operations when dmaengine_submit() is called. This patch fixes the workflow in dw_dmac driver to follow the documentation. [1] http://www.spinics.net/lists/arm-kernel/msg125987.htmlSigned-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Vinod Koul <vinod.koul@intel.com> Cc: "Petallo, MauriceX R" <mauricex.r.petallo@intel.com> Signed-off-by:
-
Andy Shevchenko authored
commit e7637c6c upstream. We have a duplicate code which starts first descriptor in the queue. Let's make this as a separate helper that can be used in future as well. Signed-off-by:
-
Ulf Hansson authored
commit 7878289b upstream. Commit "mmc: mmci: Handle CMD irq before DATA irq", caused an issue when using the ARM model of the PL181 and running QEMU. The bug was reported for the following QEMU version: $ qemu-system-arm -version QEMU emulator version 2.0.0 (Debian 2.0.0+dfsg-2ubuntu1.1), Copyright (c) 2003-2008 Fabrice Bellard To resolve the problem, let's restore the old behavior were the DATA irq is handled prior the CMD irq, but only for the arm_variant, which the problem was reported for. Reported-by:
John Stultz <john.stultz@linaro.org> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Russell King <linux@arm.linux.org.uk> Tested-by:
Kees Cook <keescook@chromium.org> Tested-by:
Ulf Hansson <ulf.hansson@linaro.org> [kees: backported to 3.16] Signed-off-by:
-
Pablo Neira Ayuso authored
commit b88825de upstream. Fix possible replacement of the per-cpu chain counters by null pointer when updating an existing chain in the commit path. Reported-by:
Matteo Croce <technoboy85@gmail.com> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
-
Julian Anastasov authored
commit eb90b0c7 upstream. commit fc604767 ("ipvs: changes for local real server") from 2.6.37 introduced DNAT support to local real server but the IPv6 LOCAL_OUT handler ip_vs_local_reply6() is registered incorrectly as IPv4 hook causing any outgoing IPv4 traffic to be dropped depending on the IP header values. Chris tracked down the problem to CONFIG_IP_VS_IPV6=y Bug report: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1349768Reported-by:
Chris J Arges <chris.j.arges@canonical.com> Tested-by:
Julian Anastasov <ja@ssi.bg> Signed-off-by:
Simon Horman <horms@verge.net.au> Signed-off-by:
-
Daniel Borkmann authored
commit caa8ad94 upstream. There's actually no good reason why we cannot use cgroup id 0, so lets just remove this artificial barrier. Reported-by:
Alexey Perevalov <a.perevalov@samsung.com> Signed-off-by:
Daniel Borkmann <dborkman@redhat.com> Tested-by:
-
Alex Gartrell authored
commit 76f084bc upstream. Previously, only the four high bits of the tclass were maintained in the ipv6 case. This matches the behavior of ipv4, though whether or not we should reflect ECN bits may be up for debate. Signed-off-by:
Alex Gartrell <agartrell@fb.com> Acked-by:
-
Eric Dumazet authored
commit 7bd8490e upstream. xt_hashlimit cannot be used with large hash tables, because garbage collector is run from a timer. If table is really big, its possible to hold cpu for more than 500 msec, which is unacceptable. Switch to a work queue, and use proper scheduling points to remove latencies spikes. Later, we also could switch to a smoother garbage collection done at lookup time, one bucket at a time... Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: Florian Westphal <fw@strlen.de> Cc: Patrick McHardy <kaber@trash.net> Reviewed-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
-
NeilBrown authored
commit f0cc9a05 upstream. r1_bio->start_next_window is not initialised in the READ case, so allow_barrier may incorrectly decrement conf->current_window_requests which can cause raise_barrier() to block forever. Fixes: 79ef3a8aReported-by:
Brassow Jonathan <jbrassow@redhat.com> Signed-off-by:
-
