- 13 Sep, 2015 40 commits
-
-
Thulasimani,Sivakumar authored
commit 5e86dfe3 upstream. This patch removes 5.4Gbps from supported link rate for CHV since it is not supported in it. v2: change the ordering for better readability (Ville) Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Chris Wilson authored
commit 903ecd0b upstream. Everytime we use the logical context with execlists it becomes dirty (as the hardware will write the new register values afterwards, as well as the GPU state that will be used). We need to then flag the context as dirty everytime since after a swap-out/swap-in cycle the dirty flag will be cleared, and a further swap-out cycle will then loose the most recent GPU state. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Thierry Reding authored
commit dbb3df2d upstream. If PM is enabled but PM_SLEEP is disabled, the suspend/resume functions are still unused and produce a compiler warning. Signed-off-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by:
-
Vincent Pelletier authored
commit 1ae5ddb6 upstream. GPIOF_IN flag was lost in: Commit 633a21d8("input: gpio_keys_polled: Add support for GPIO descriptors"). Without this flag, legacy code path (for non-descriptor GPIO declarations) would configure GPIO as output (0 meaning GPIOF_DIR_OUT | GPIOF_INIT_LOW). Signed-off-by:
Vincent Pelletier <plr.vincent@gmail.com> Reviewed-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Bjorn Helgaas authored
commit 45ea2a5f upstream. Meelis and Helge reported that 3a9ad0b4 ("PCI: Add pci_bus_addr_t") caused HPMCs on A500 and hangs on rp5470. PA-RISC does not set ARCH_DMA_ADDR_T_64BIT, even for 64-bit kernels, so prior to 3a9ad0b4, we always used 32-bit PCI addresses. After 3a9ad0b4, we do use 64-bit PCI addresses in 64-bit kernels, and apparently there's some PA-RISC problem related to them. Fixes: 3a9ad0b4 ("PCI: Add pci_bus_addr_t") Link: http://lkml.kernel.org/r/alpine.LRH.2.11.1507260929000.30065@math.ut.eeReported-by:
Meelis Roos <mroos@linux.ee> Reported-by:
Helge Deller <deller@gmx.de> Tested-by:
Yinghai Lu <yinghai@kernel.org> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Acked-by:
-
Alexei Potashnik authored
commit 9547308b upstream. Make sure all non-READ SCSI commands get targ_xfer_tag initialized to 0xffffffff, not just WRITEs. Double-free of a TUR cmd object occurs under the following scenario: 1. TUR received (targ_xfer_tag is uninitialized and left at 0) 2. TUR status sent 3. First unsolicited NOPIN is sent to initiator (gets targ_xfer_tag of 0) 4. NOPOUT for NOPIN (with TTT=0) arrives - its ExpStatSN acks TUR status, TUR is queued for removal - LIO tries to find NOPIN with TTT=0, but finds the same TUR instead, TUR is queued for removal for the 2nd time (Drop unbalanced conditional bracket usage - nab) Signed-off-by:
Alexei Potashnik <alexei@purestorage.com> Signed-off-by:
Spencer Baugh <sbaugh@catern.com> Signed-off-by:
Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by:
-
Adrien Schildknecht authored
commit f5eeb5fa upstream. At the last iteration of the loop, j may equal zero and thus tp_list[j - 1] causes an invalid read. Change the logic of the loop so that j - 1 is always >= 0. Signed-off-by:
Adrien Schildknecht <adrien+dev@schischi.me> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Markus Osterhoff authored
commit c7e69ae6 upstream. After a for-loop was replaced by list_for_each_entry, see Commit bbbc7e85 ("ALSA: hda - Allocate hda_pcm objects dynamically"), Commit 751e2216 ("ALSA: hda: fix possible null dereference"), a possible NULL pointer dereference has been introduced; this patch adds the NULL check on pcm->pcm, while leaving a potentially superfluous check on pcm itself untouched. Signed-off-by:
Markus Osterhoff <linux-kernel@k-raum.org> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Takashi Iwai authored
commit c7cd0ef6 upstream. The widget power-saving code tries to turn up/down the power of each widget in the I/O paths that are modified at each jack plug/unplug. The recent report revealed that the power activation leaves some widgets unpowered after plugging. This is because snd_hda_activate_path() turns on path->active flag at the end of the function while the path power management is done before that. Then it's regarded as if nothing is active, and the driver turns off the power. The fix is simply to set the flag at the beginning of the function, before trying to power up. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=102521Signed-off-by:
-
Takashi Iwai authored
commit 9d2b48f7 upstream. The is_active_nid_for_any() function in the generic parser is supposed to check all connections from/to the given widget, but the current code checks only the first input connection (index = 0). This patch corrects the code to check all inputs by passing -1 to index argument. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=102521Signed-off-by:
-
David Henningsson authored
commit f6b28e4d upstream. On shutdown/reboot of CX20722, first shut down all EAPDs, then shut down the afg node to D3. Failure to do so can lead to spurious noises from the internal speaker directly after reboot (and before the codec is reinitialized again, i e in BIOS setup or GRUB menus). BugLink: https://bugs.launchpad.net/bugs/1487345Signed-off-by:
David Henningsson <david.henningsson@canonical.com> Signed-off-by:
-
Jurgen Kramer authored
commit 9544f8b6 upstream. This patch adds native DSD support for the Gustard DAC-X20U. Signed-off-by:
Jurgen Kramer <gtmkramer@xs4all.nl> Signed-off-by:
-
Woodrow Shen authored
commit 7ccb0a99 upstream. Dell laptop causes the white noise by login screen and headphone, and the fixup function ALC292_FIXUP_DISABLE_AAMIX can eliminate this noise. Codec: Realtek ALC3235 Vendor Id: 0x10ec0293 Subsystem Id: 0x102806db BugLink: https://bugs.launchpad.net/bugs/1484334Signed-off-by:
Woodrow Shen <woodrow.shen@canonical.com> Signed-off-by:
-
Takashi Iwai authored
commit 9003ebb1 upstream. The fix for deadlock in PM in commit [1ee23fe0: ALSA: usb-audio: Fix deadlocks at resuming] introduced a new check of in_pm flag. However, the brainless patch author evaluated it in a wrong way (logical AND instead of logical OR), thus usb_autopm_get_interface() is wrongly called at probing, leading to unbalance of runtime PM refcount. This patch fixes it by correcting the logic. Reported-by:
Hans Yang <hansy@nvidia.com> Fixes: 1ee23fe0 ('ALSA: usb-audio: Fix deadlocks at resuming') Signed-off-by:
-
Alban Crequy authored
commit 24ee3cf8 upstream. The comment says it's using trialcs->mems_allowed as a temp variable but it didn't match the code. Change the code to match the comment. This fixes an issue when writing in cpuset.mems when a sub-directory exists: we need to write several times for the information to persist: | root@alban:/sys/fs/cgroup/cpuset# mkdir footest9 | root@alban:/sys/fs/cgroup/cpuset# cd footest9 | root@alban:/sys/fs/cgroup/cpuset/footest9# mkdir aa | root@alban:/sys/fs/cgroup/cpuset/footest9# cat cpuset.mems | | root@alban:/sys/fs/cgroup/cpuset/footest9# echo 0 > cpuset.mems | root@alban:/sys/fs/cgroup/cpuset/footest9# cat cpuset.mems | | root@alban:/sys/fs/cgroup/cpuset/footest9# echo 0 > cpuset.mems | root@alban:/sys/fs/cgroup/cpuset/footest9# cat cpuset.mems | 0 | root@alban:/sys/fs/cgroup/cpuset/footest9# cat aa/cpuset.mems | | root@alban:/sys/fs/cgroup/cpuset/footest9# echo 0 > aa/cpuset.mems | root@alban:/sys/fs/cgroup/cpuset/footest9# cat aa/cpuset.mems | 0 | root@alban:/sys/fs/cgroup/cpuset/footest9# This should help to fix the following issue in Docker: https://github.com/opencontainers/runc/issues/133 In some conditions, a Docker container needs to be started twice in order to work. Signed-off-by:
Alban Crequy <alban@endocode.com> Tested-by:
Iago López Galeiras <iago@endocode.com> Acked-by:
Li Zefan <lizefan@huawei.com> Signed-off-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
-
Tejun Heo authored
commit 74a80d67 upstream. This reverts commit 42b966fb. As implemented, ACS-4 sense reporting for ATA devices bypasses error diagnosis and handling in libata degrading EH behavior significantly. Revert the related changes for now. Signed-off-by:
-
Tejun Heo authored
commit 84ded2f8 upstream. This reverts commit fe7173c2. As implemented, ACS-4 sense reporting for ATA devices bypasses error diagnosis and handling in libata degrading EH behavior significantly. Revert the related changes for now. ATA_ID_COMMAND_SET_3/4 constants are not reverted as they're used by later changes. Signed-off-by:
-
Tejun Heo authored
commit fe16d4f2 upstream. This reverts commit a1524f22. As implemented, ACS-4 sense reporting for ATA devices bypasses error diagnosis and handling in libata degrading EH behavior significantly. Revert the related changes for now. Signed-off-by:
-
Horia Geant? authored
commit b310c178 upstream. When doing pointer operation for accessing the HW S/G table, a value representing number of entries (and not number of bytes) must be used. Fixes: 045e3678 ("crypto: caam - ahash hmac support") Signed-off-by:
Horia Geant? <horia.geanta@freescale.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Jan Stancek authored
commit d3392f41 upstream. Commit 00085111 changed sha256/512 update functions to pass more data to nx_build_sg_list(), which ends with sg list overflows and usually with update functions failing for data larger than max_sg_len * NX_PAGE_SIZE. This happens because: - both "total" and "to_process" are updated, which leads to "to_process" getting overflowed for some data lengths For example: In first iteration "total" is 50, and let's assume "to_process" is 30 due to sg limits. At the end of first iteration "total" is set to 20. At start of 2nd iteration "to_process" overflows on: to_process = total - to_process; - "in_sg" is not reset to nx_ctx->in_sg after each iteration - nx_build_sg_list() is hitting overflow because the amount of data passed to it would require more than sgmax elements - as consequence of previous item, data stored in overflowed sg list may no longer be aligned to SHA*_BLOCK_SIZE This patch changes sha256/512 update functions so that "to_process" respects sg limits and never tries to pass more data to nx_build_sg_list() to avoid overflows. "to_process" is calculated as minimum of "total" and sg limits at start of every iteration. Fixes: 00085111 ("crypto: nx - Fix SHA concurrence issue and sg limit bounds") Signed-off-by:
Jan Stancek <jstancek@redhat.com> Cc: Leonidas Da Silva Barbosa <leosilva@linux.vnet.ibm.com> Cc: Marcelo Henrique Cerri <mhcerri@linux.vnet.ibm.com> Cc: Fionnuala Gunter <fin@linux.vnet.ibm.com> Cc: "David S. Miller" <davem@davemloft.net> Signed-off-by:
-
Martin K. Petersen authored
commit 4f258a46 upstream. Commit bcdb247c ("sd: Limit transfer length") clamped the maximum size of an I/O request to the MAXIMUM TRANSFER LENGTH field in the BLOCK LIMITS VPD. This had the unfortunate effect of also limiting the maximum size of non-filesystem requests sent to the device through sg/bsg. Avoid using blk_queue_max_hw_sectors() and set the max_sectors queue limit directly. Also update the comment in blk_limits_max_hw_sectors() to clarify that max_hw_sectors defines the limit for the I/O controller only. Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Reported-by:
Brian King <brking@linux.vnet.ibm.com> Tested-by:
James Bottomley <JBottomley@Odin.com> Signed-off-by:
-
John Soni Jose authored
commit 660d0831 upstream. In case of hw iscsi offload, an host can have N-number of active connections. There can be IO's running on some connections which make host->host_busy always TRUE. Now if logout from a connection is tried then the code gets into an infinite loop as host->host_busy is always TRUE. iscsi_conn_teardown(....) { ......... /* * Block until all in-progress commands for this connection * time out or fail. */ for (;;) { spin_lock_irqsave(session->host->host_lock, flags); if (!atomic_read(&session->host->host_busy)) { /* OK for ERL == 0 */ spin_unlock_irqrestore(session->host->host_lock, flags); break; } spin_unlock_irqrestore(session->host->host_lock, flags); msleep_interruptible(500); iscsi_conn_printk(KERN_INFO, conn, "iscsi conn_destroy(): " "host_busy %d host_failed %d\n", atomic_read(&session->host->host_busy), session->host->host_failed); ................ ............... } } This is not an issue with software-iscsi/iser as each cxn is a separate host. Fix: Acquiring eh_mutex in iscsi_conn_teardown() before setting session->state = ISCSI_STATE_TERMINATE. Signed-off-by:
John Soni Jose <sony.john@avagotech.com> Reviewed-by:
Mike Christie <michaelc@cs.wisc.edu> Reviewed-by:
Chris Leech <cleech@redhat.com> Signed-off-by:
-
Markos Chandras authored
commit 9f161439 upstream. Commit 4c21b8fd ("MIPS: seccomp: Handle indirect system calls (o32)") fixed indirect system calls on O32 but it also introduced a bug for MIPS64 where it erroneously modified the v0 (syscall) register with the assumption that the sycall offset hasn't been taken into consideration. This breaks seccomp on MIPS64 n64 and n32 ABIs. We fix this by replacing the addition with a move instruction. Fixes: 4c21b8fd ("MIPS: seccomp: Handle indirect system calls (o32)") Reviewed-by:
James Hogan <james.hogan@imgtec.com> Signed-off-by:
Markos Chandras <markos.chandras@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/10951/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
-
Guenter Roeck authored
commit 8ef9724b upstream. When inserting a new register into a block, the present bit map size is increased using krealloc. krealloc does not clear the additionally allocated memory, leaving it filled with random values. Result is that some registers are considered cached even though this is not the case. Fix the problem by clearing the additionally allocated memory. Also, if the bitmap size does not increase, do not reallocate the bitmap at all to reduce overhead. Fixes: 3f4ff561 ("regmap: rbtree: Make cache_present bitmap per node") Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Linus Torvalds authored
commit ed596cde upstream. This reverts commits 9a036b93 ("x86/signal/64: Remove 'fs' and 'gs' from sigcontext") and c6f20629 ("x86/signal/64: Fix SS handling for signals delivered to 64-bit programs"). They were cleanups, but they break dosemu by changing the signal return behavior (and removing 'fs' and 'gs' from the sigcontext struct - while not actually changing any behavior - causes build problems). Reported-and-tested-by:
Stas Sergeev <stsp@list.ru> Acked-by:
Andy Lutomirski <luto@amacapital.net> Cc: Ingo Molnar <mingo@kernel.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Charles Keepax authored
commit 72e43164 upstream. The PM runtime core by default assumes a chip is suspended when runtime PM is enabled. Currently the arizona driver enables runtime PM when the chip is fully active and then disables the DCVDD regulator at the end of arizona_dev_init. This however has several problems, firstly the if we reach the end of arizona_dev_init, we did not properly follow all the proceedures for shutting down the chip, and most notably we never marked the chip as cache only so any writes occurring between then and the next PM runtime resume will be lost. Secondly, if we are already resumed when we reach the end of dev_init, then at best we get unbalanced regulator enable/disables at work we lose DCVDD whilst we need it. Additionally, since the commit 4f0216409f7c ("mfd: arizona: Add better support for system suspend"), the PM runtime operations may disable/enable the IRQ, so the IRQs must now be enabled before we call any PM operations. This patch adds a call to pm_runtime_set_active to inform the PM core that the device is starting up active and moves the PM enabling to around the IRQ initialisation to avoid any PM callbacks happening until the IRQs are initialised. Signed-off-by:
Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
-
Russell King authored
commit bac51ad9 upstream. We must invalidate the L1 cache before enabling coherency, otherwise secondary CPUs can inject invalid cache lines into the coherent CPU cluster, which could then be migrated to other CPUs. This fixes a recent regression with SoCFPGA randomly failing to boot. Fixes: 02b4e275 ("ARM: v7 setup function should invalidate L1 cache") Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Cc: Alexander Kochetkov <al.kochet@gmail.com> Signed-off-by:
-
Russell King authored
commit 02b4e275 upstream. All ARMv5 and older CPUs invalidate their caches in the early assembly setup function, prior to enabling the MMU. This is because the L1 cache should not contain any data relevant to the execution of the kernel at this point; all data should have been flushed out to memory. This requirement should also be true for ARMv6 and ARMv7 CPUs - indeed, these typically do not search their caches when caching is disabled (as it needs to be when the MMU is disabled) so this change should be safe. ARMv7 allows there to be CPUs which search their caches while caching is disabled, and it's permitted that the cache is uninitialised at boot; for these, the architecture reference manual requires that an implementation specific code sequence is used immediately after reset to ensure that the cache is placed into a sane state. Such functionality is definitely outside the remit of the Linux kernel, and must be done by the SoC's firmware before _any_ CPU gets to the Linux kernel. Changing the data cache clean+invalidate to a mere invalidate allows us to get rid of a lot of platform specific hacks around this issue for their secondary CPU bringup paths - some of which were buggy. Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Tested-by:
Heiko Stuebner <heiko@sntech.de> Tested-by:
Dinh Nguyen <dinguyen@opensource.altera.com> Acked-by:
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Tested-by:
Shawn Guo <shawn.guo@linaro.org> Tested-by:
Geert Uytterhoeven <geert+renesas@glider.be> Tested-by:
Michal Simek <michal.simek@xilinx.com> Tested-by:
Wei Xu <xuwei5@hisilicon.com> Signed-off-by:
-
Nathan Lynch authored
commit d2b30cd4 upstream. When using a toolchain with gold as the default linker, the VDSO build fails: VDSO arch/arm/vdso/vdso.so.raw HOSTCC arch/arm/vdso/vdsomunge MUNGE arch/arm/vdso/vdso.so.dbg OBJCOPY arch/arm/vdso/vdso.so BFD: arch/arm/vdso/vdso.so: Not enough room for program headers, try linking with -N For whatever reason, ld.gold is omitting an exidx program header that ld.bfd emits, and even when I work around that, I don't get a working VDSO. For now, instead of supporting gold (which will fail to link the kernel anyway since it does not implement --pic-veneer), direct the compiler to use the traditional bfd linker. This is accomplished by using -fuse-ld, which is implemented in GCC 4.8 and later. Note: one limitation of this is that if the toolchain is configured to use gold by default, and the bfd linker is not in $PATH, the VDSO build will fail: VDSO arch/arm/vdso/vdso.so.raw collect2: fatal error: cannot find 'ld' This will happen if CROSS_COMPILE begins with a path such as /opt/bin/arm-linux-gnu- but /opt/bin is not in $PATH. This is considered an acceptable corner-case limitation and is easily worked around. Additonal note: we use cc-option instead of cc-ldoption so that -fuse-ld=bfd is placed in the command line if the compiler recognizes the option. Using cc-ldoption results in an attempt to link, which fails in the situation just described, causing -fuse-ld=bfd to be omitted and gold to be used for the VDSO link, which is what we're trying to prevent. Reported-by:
Stefan Agner <stefan@agner.ch> Signed-off-by:
Nathan Lynch <nathan_lynch@mentor.com> Signed-off-by:
-
Nathan Lynch authored
commit d33ce23b upstream. Currently the VDSO's link options are kind of a mess spread between ccflags-y and cmd_vdsold. Collect linker directives into one variable, VDSO_LDFLAGS, and use that in cmd_vdsold. Signed-off-by:
-
Kishon Vijay Abraham I authored
commit 70caac3f upstream. commit <ed8509ed> ("ARM: dts: omap5: add minimal l4 bus layout with control module support") moved pbias_regulator dt node from being a child node of ocp to be the child node of omap5_padconf_global. After this device for pbias_regulator is not created. Fix it by adding "simple-bus" compatible property to omap5_padconf_global dt node. Fixes: ed8509ed ("ARM: dts: omap5: add minimal l4 bus layout with control module support") Signed-off-by:
Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Kishon Vijay Abraham I authored
commit 89a898df upstream. commit <7415b0b4> ("ARM: dts: omap4: add minimal l4 bus layout with control module support") moved pbias_regulator dt node from being a child node of ocp to be the child node of omap4_padconf_global. After this device for pbias_regulator is not created. Fix it by adding "simple-bus" compatible property to omap4_padconf_global dt node. Fixes: 7415b0b4 ("ARM: dts: omap4: add minimal l4 bus layout with control module support") Signed-off-by:
-
Kishon Vijay Abraham I authored
commit cd455673 upstream. commit <d919501f> ("ARM: dts: dra7: add minimal l4 bus layout with control module support") moved pbias_regulator dt node from being a child node of ocp to be the child node of scm_conf. After this device for pbias_regulator is not created. Fix it by adding "simple-bus" compatible property to scm_conf dt node. Fixes: d919501f ("ARM: dts: dra7: add minimal l4 bus layout with control module support") Suggested-by:
Tero Kristo <t-kristo@ti.com> Signed-off-by:
Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by:
-
Kishon Vijay Abraham I authored
commit 4317c8c9 upstream. commit <72b10ac0> ("ARM: dts: omap24xx: add minimal l4 bus layout with control module support") moved pbias_regulator dt node from being a child node of ocp to be the child node of scm_conf. After this device for pbias_regulator is not created. Fix it by adding "simple-bus" compatible property to scm_conf dt node. Fixes: 72b10ac0 ("ARM: dts: omap24xx: add minimal l4 bus layout with control module support") Signed-off-by:
-
Lucas Stach authored
commit 1a9fa190 upstream. The PCIe interrupts are also routed through the GPC. This has been missed from the conversion to stacked IRQ domains as the PCIe controller uses an explicit interrupt map and thus doesn't inherit the SoC global interrupt parent. Signed-off-by:
Lucas Stach <l.stach@pengutronix.de> Signed-off-by:
Shawn Guo <shawnguo@kernel.org> Signed-off-by:
-
Bart Van Assche authored
commit 8f2777f5 upstream. Since fc_fcp_cleanup_cmd() can sleep this function must not be called while holding a spinlock. This patch avoids that fc_fcp_cleanup_each_cmd() triggers the following bug: BUG: scheduling while atomic: sg_reset/1512/0x00000202 1 lock held by sg_reset/1512: #0: (&(&fsp->scsi_pkt_lock)->rlock){+.-...}, at: [<ffffffffc0225cd5>] fc_fcp_cleanup_each_cmd.isra.21+0xa5/0x150 [libfc] Preemption disabled at:[<ffffffffc0225cd5>] fc_fcp_cleanup_each_cmd.isra.21+0xa5/0x150 [libfc] Call Trace: [<ffffffff816c612c>] dump_stack+0x4f/0x7b [<ffffffff810828bc>] __schedule_bug+0x6c/0xd0 [<ffffffff816c87aa>] __schedule+0x71a/0xa10 [<ffffffff816c8ad2>] schedule+0x32/0x80 [<ffffffffc0217eac>] fc_seq_set_resp+0xac/0x100 [libfc] [<ffffffffc0218b11>] fc_exch_done+0x41/0x60 [libfc] [<ffffffffc0225cff>] fc_fcp_cleanup_each_cmd.isra.21+0xcf/0x150 [libfc] [<ffffffffc0225f43>] fc_eh_device_reset+0x1c3/0x270 [libfc] [<ffffffff814a2cc9>] scsi_try_bus_device_reset+0x29/0x60 [<ffffffff814a3908>] scsi_ioctl_reset+0x258/0x2d0 [<ffffffff814a2650>] scsi_ioctl+0x150/0x440 [<ffffffff814b3a9d>] sd_ioctl+0xad/0x120 [<ffffffff8132f266>] blkdev_ioctl+0x1b6/0x810 [<ffffffff811da608>] block_ioctl+0x38/0x40 [<ffffffff811b4e08>] do_vfs_ioctl+0x2f8/0x530 [<ffffffff811b50c1>] SyS_ioctl+0x81/0xa0 [<ffffffff816cf8b2>] system_call_fastpath+0x16/0x7a Signed-off-by:
Bart Van Assche <bart.vanassche@sandisk.com> Signed-off-by:
Vasu Dev <vasu.dev@intel.com> Signed-off-by:
-
Bart Van Assche authored
commit f6979ade upstream. Due to patch "libfc: Do not invoke the response handler after fc_exch_done()" (commit ID 7030fd62) the lport_recv() call in fc_exch_recv_req() is passed a dangling pointer. Avoid this by moving the fc_frame_free() call from fc_invoke_resp() to its callers. This patch fixes the following crash: general protection fault: 0000 [#3] PREEMPT SMP RIP: fc_lport_recv_req+0x72/0x280 [libfc] Call Trace: fc_exch_recv+0x642/0xde0 [libfc] fcoe_percpu_receive_thread+0x46a/0x5ed [fcoe] kthread+0x10a/0x120 ret_from_fork+0x42/0x70 Signed-off-by:
-
Thomas Hellstrom authored
commit 3e04e2fe upstream. This addresses two issues that cause problems with viewperf maya-03 in situation with memory pressure. The first issue causes attempts to unreserve buffers if batched reservation fails due to, for example, a signal pending. While previously the ttm_eu api was resistant against this type of error, it is no longer and the lockdep code will complain about attempting to unreserve buffers that are not reserved. The issue is resolved by avoid calling ttm_eu_backoff_reservation in the buffer reserve error path. The second issue is that the binding_mutex may be held when user-space fence objects are created and hence during memory reclaims. This may cause recursive attempts to grab the binding mutex. The issue is resolved by not holding the binding mutex across fence creation and submission. Signed-off-by:
Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by:
Sinclair Yeh <syeh@vmware.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Alex Deucher authored
commit e037239e upstream. Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Dan Carpenter authored
commit 4a8e70f5 upstream. The limit should be ARRAY_SIZE(params) (5 elements) here instead of sizeof(params) (20 bytes). Fixes: 08177f40 ('HID: uclogic: merge hid-huion driver in hid-uclogic') Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Nikolai Kondrashov <spbnick@gmail.com> Signed-off-by:
Jiri Kosina <jkosina@suse.com> Signed-off-by:
-
