- 20 Jun, 2014 1 commit
-
-
Justin Maggard authored
commit c41570c9 upstream. When defragging a very large file, the cluster variable can wrap its 32-bit signed int type and become negative, which eventually gets passed to btrfs_force_ra() as a very large unsigned long value. On 32-bit platforms, this eventually results in an Oops from the SLAB allocator. Change the cluster and max_cluster signed int variables to unsigned long to match the readahead functions. This also allows the min() comparison in btrfs_defrag_file() to work as intended. Signed-off-by:
Josef Bacik <jbacik@fb.com> Signed-off-by:
Chris Mason <clm@fb.com> Signed-off-by:
Jiri Slaby <jslaby@suse.cz>
-
- 18 Jun, 2014 7 commits
-
-
Markos Chandras authored
commit 137f7df8 upstream. Add _TIF_SECCOMP flag to _TIF_WORK_SYSCALL_ENTRY to indicate that the system call needs to be checked against a seccomp filter. Signed-off-by:
Markos Chandras <markos.chandras@imgtec.com> Reviewed-by:
Paul Burton <paul.burton@imgtec.com> Reviewed-by:
James Hogan <james.hogan@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/6405/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
-
Denis Turischev authored
commit 0a939993 upstream. Patch "xhci: Switch Intel Lynx Point ports to EHCI on shutdown." commit c09ec25d is not fully correct It switches both Lynx Point and Lynx Point-LP ports to EHCI on shutdown. On some Lynx Point machines it causes spurious interrupt, which wake the system: bugzilla.kernel.org/show_bug.cgi?id=76291 On Lynx Point-LP on the contrary switching ports to EHCI seems to be necessary to fix these spurious interrupts. Signed-off-by:
Denis Turischev <denis@compulab.co.il> Reported-by:
Wulf Richartz <wulf.richartz@gmail.com> Cc: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Jiri Kosina authored
commit 6314a108 upstream. Commit 41a55b4d ("floppy: silence warning during disk test") caused bio.bi_flags being overwritten, and its initialization to BIO_UPTODATE in bio_init() to be lost. This was unnoticed until 7b7b68bb ("floppy: bail out in open() if drive is not responding to block0 read"), because the error value wasn't checked for in the bio completion callback. Now we are actually looking at the error, and the loss of BIO_UPTODATE causes EIO to be wrongly passed to the callback, which confuses the FD_OPEN_SHOULD_FAIL_BIT logic. Fix this by not destroying previous value of bi_flags when setting BIO_QUIET. Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Daniel Vetter authored
commit fcc9fe1a upstream. We want future generations to at least attempt to use all features, so restrict the stolen memory disabling when vt-d is enabled to the latest generation we have reports for. Which is a HSW per the original report. Also once we get a bit a hold of some of the mysterious framebuffer in stolen memory issues that still haunt bugzilla, we should probably drop this hack again and see what happens. This was introduced in commit 0f4706d2 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Mar 18 14:50:50 2014 +0200 drm/i915: Disable stolen memory when DMAR is active Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@intel.com> Cc: David Woodhouse <dwmw2@infradead.org> References: https://bugs.freedesktop.org/show_bug.cgi?id=68535Acked-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Igor Gnatenko authored
commit 6db249eb upstream. After suspend another Renesas PCI-X USB 3.0 card doesn't work. [root@fedora-20 ~]# lspci -vmnnd 1912: Device: 03:00.0 Class: USB controller [0c03] Vendor: Renesas Technology Corp. [1912] Device: uPD720202 USB 3.0 Host Controller [0015] SVendor: Renesas Technology Corp. [1912] SDevice: uPD720202 USB 3.0 Host Controller [0015] Rev: 02 ProgIf: 30 This patch should be applied to stable kernel 3.14 that contain the commit 1aa9578c "xhci: Fix resume issues on Renesas chips in Samsung laptops" Reported-and-tested-by:
Anatoly Kharchenko <rfr-bugs@yandex.ru> Reference: http://redmine.russianfedora.pro/issues/1315Signed-off-by:
Igor Gnatenko <i.gnatenko.brain@gmail.com> Cc: stable@vger.kernel.org # 3.14 Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
-
Larry Finger authored
commit 5f918699 upstream. Beginning with kernel 3.13, this driver fails on some systems. The problem was bisected to: Commit 1bf4bbb4 Author: Felix Fietkau <nbd@openwrt.org> Title: mac80211: send control port protocol frames to the VO queue There is noting wrong with the above commit. The regression occurs because V0 queue on RTL8192SE cards uses priority 6, not the usual 7. The fix is to modify the rtl8192se routine that sets the correct transmit queue. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=74541Reported-by:
Alex Miller <almiller_1@yahoo.co.uk> Tested-by:
Larry Finger <Larry.Finger@lwfinger.net> Cc: Stable <stable@vger.kernel.org> [3.13+] Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Helmut Schaa authored
commit 5998be87 upstream. Since commit 558ff225 (ath9k: fix ps-poll responses under a-mpdu sessions) non-data frames would have gotten a sequence number from a TIDs sequence counter instead of using the global sequence counter. This can lead to instable connections. To fix this only select the correct TID if we are processing a data frame. Furthermore, prevent non-data frames to get a sequence number from a TID sequence counter by adding a check to ath_tx_setup_buffer. Cc: Felix Fietkau <nbd@openwrt.org> Signed-off-by:
Helmut Schaa <helmut.schaa@googlemail.com> Acked-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
-
- 11 Jun, 2014 2 commits
-
-
Jiri Slaby authored
-
Florian Westphal authored
commit 895162b1 upstream. else we may fail to forward skb even if original fragments do fit outgoing link mtu: 1. remote sends 2k packets in two 1000 byte frags, DF set 2. we want to forward but only see '2k > mtu and DF set' 3. we then send icmp error saying that outgoing link is 1500 But original sender never sent a packet that would not fit the outgoing link. Setting local_df makes outgoing path test size vs. IPCB(skb)->frag_max_size, so we will still send the correct error in case the largest original size did not fit outgoing link mtu. Reported-by:
Maxime Bizon <mbizon@freebox.fr> Suggested-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
-
- 09 Jun, 2014 30 commits
-
-
Thomas Gleixner authored
commit 54a21788 upstream. The current implementation of lookup_pi_state has ambigous handling of the TID value 0 in the user space futex. We can get into the kernel even if the TID value is 0, because either there is a stale waiters bit or the owner died bit is set or we are called from the requeue_pi path or from user space just for fun. The current code avoids an explicit sanity check for pid = 0 in case that kernel internal state (waiters) are found for the user space address. This can lead to state leakage and worse under some circumstances. Handle the cases explicit: Waiter | pi_state | pi->owner | uTID | uODIED | ? [1] NULL | --- | --- | 0 | 0/1 | Valid [2] NULL | --- | --- | >0 | 0/1 | Valid [3] Found | NULL | -- | Any | 0/1 | Invalid [4] Found | Found | NULL | 0 | 1 | Valid [5] Found | Found | NULL | >0 | 1 | Invalid [6] Found | Found | task | 0 | 1 | Valid [7] Found | Found | NULL | Any | 0 | Invalid [8] Found | Found | task | ==taskTID | 0/1 | Valid [9] Found | Found | task | 0 | 0 | Invalid [10] Found | Found | task | !=taskTID | 0/1 | Invalid [1] Indicates that the kernel can acquire the futex atomically. We came came here due to a stale FUTEX_WAITERS/FUTEX_OWNER_DIED bit. [2] Valid, if TID does not belong to a kernel thread. If no matching thread is found then it indicates that the owner TID has died. [3] Invalid. The waiter is queued on a non PI futex [4] Valid state after exit_robust_list(), which sets the user space value to FUTEX_WAITERS | FUTEX_OWNER_DIED. [5] The user space value got manipulated between exit_robust_list() and exit_pi_state_list() [6] Valid state after exit_pi_state_list() which sets the new owner in the pi_state but cannot access the user space value. [7] pi_state->owner can only be NULL when the OWNER_DIED bit is set. [8] Owner and user space value match [9] There is no transient state which sets the user space TID to 0 except exit_robust_list(), but this is indicated by the FUTEX_OWNER_DIED bit. See [4] [10] There is no transient state which leaves owner and user space TID out of sync. Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Kees Cook <keescook@chromium.org> Cc: Will Drewry <wad@chromium.org> Cc: Darren Hart <dvhart@linux.intel.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Thomas Gleixner authored
commit 13fbca4c upstream. If the owner died bit is set at futex_unlock_pi, we currently do not cleanup the user space futex. So the owner TID of the current owner (the unlocker) persists. That's observable inconsistant state, especially when the ownership of the pi state got transferred. Clean it up unconditionally. Signed-off-by:
-
Thomas Gleixner authored
commit b3eaa9fc upstream. We need to protect the atomic acquisition in the kernel against rogue user space which sets the user space futex to 0, so the kernel side acquisition succeeds while there is existing state in the kernel associated to the real owner. Verify whether the futex has waiters associated with kernel state. If it has, return -EINVAL. The state is corrupted already, so no point in cleaning it up. Subsequent calls will fail as well. Not our problem. [ tglx: Use futex_top_waiter() and explain why we do not need to try restoring the already corrupted user space state. ] Signed-off-by:
Darren Hart <dvhart@linux.intel.com> Cc: Kees Cook <keescook@chromium.org> Cc: Will Drewry <wad@chromium.org> Signed-off-by:
-
Thomas Gleixner authored
futex-prevent-requeue-pi-on-same-futex.patch futex: Forbid uaddr == uaddr2 in futex_requeue(..., requeue_pi=1) commit e9c243a5 upstream. If uaddr == uaddr2, then we have broken the rule of only requeueing from a non-pi futex to a pi futex with this call. If we attempt this, then dangling pointers may be left for rt_waiter resulting in an exploitable condition. This change brings futex_requeue() in line with futex_wait_requeue_pi() which performs the same check as per commit 6f7b0a2a ("futex: Forbid uaddr == uaddr2 in futex_wait_requeue_pi()") [ tglx: Compare the resulting keys as well, as uaddrs might be different depending on the mapping ] Fixes CVE-2014-3153. Reported-by: Pinkie Pie Signed-off-by:
Will Drewry <wad@chromium.org> Signed-off-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
-
Guennadi Liakhovetski authored
commit 97d9d23d upstream. If a struct contains 64-bit fields, it is aligned on 64-bit boundaries within containing structs in 64-bit compilations. This is the case with struct v4l2_window, which contains pointers and is embedded into struct v4l2_format, and that one is embedded into struct v4l2_create_buffers. Unlike some other structs, used as a part of the kernel ABI as ioctl() arguments, that are packed, these structs aren't packed. This isn't a problem per se, but the ioctl-compat code for VIDIOC_CREATE_BUFS contains a bug, that triggers in such 64-bit builds. That code wrongly assumes, that in struct v4l2_create_buffers, struct v4l2_format immediately follows the __u32 memory field, which in fact isn't the case. This bug wasn't visible until now, because until recently hardly any applications used this ioctl() and mostly embedded 32-bit only drivers implemented it. This is changing now with addition of this ioctl() to some USB drivers, e.g. UVC. This patch fixes the bug by copying parts of struct v4l2_create_buffers separately. Signed-off-by:
Guennadi Liakhovetski <g.liakhovetski@gmx.de> Acked-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Mauro Carvalho Chehab <m.chehab@samsung.com> Signed-off-by:
-
Guennadi Liakhovetski authored
commit cfece585 upstream. Commit 75e2bdad "ov7670: allow configuration of image size, clock speed, and I/O method" uses a wrong index to iterate an array. Apart from being wrong, it also uses an unchecked value from user-space, which can cause access to unmapped memory in the kernel, triggered by a normal desktop user with rights to use V4L2 devices. Signed-off-by:
Jonathan Corbet <corbet@lwn.net> Signed-off-by:
-
Antti Palosaari authored
commit 8845cc64 upstream. There was some frequency calculation overflows which caused tuning failure on 32-bit architecture. Use 64-bit numbers where needed in order to avoid calculation overflows. Thanks for the Finnish person, who asked remain anonymous, reporting, testing and suggesting the fix. Signed-off-by:
Antti Palosaari <crope@iki.fi> Signed-off-by:
-
Alex Williamson authored
commit e028a9e6 upstream. An apparent cut and paste error prevents the correct flags from being set on the alias device resulting in MSI on conventional PCI devices failing to work. This also produces error events from the IOMMU like: AMD-Vi: Event logged [INVALID_DEVICE_REQUEST device=00:14.4 address=0x000000fdf8000000 flags=0x0a00] Where 14.4 is a PCIe-to-PCI bridge with a device behind it trying to use MSI interrupts. Signed-off-by:
Alex Williamson <alex.williamson@redhat.com> Signed-off-by:
Joerg Roedel <joro@8bytes.org> Signed-off-by:
-
Chunwei Chen authored
commit 178eda29 upstream. It has been reported that using ZFSonLinux on rbd will result in memory corruption. The bug report can be found here: https://github.com/zfsonlinux/spl/issues/241 http://tracker.ceph.com/issues/7790 The reason is that ZFS will send pages with page_count 0 into rbd, which in turns send them to tcp_sendpage. However, tcp_sendpage cannot deal with page_count 0, as it will do get_page and put_page, and erroneously free the page. This type of issue has been noted before, and handled in iscsi, drbd, etc. So, rbd should also handle this. This fix address this issue by fall back to slower sendmsg when page_count 0 detected. Cc: Sage Weil <sage@inktank.com> Cc: Yehuda Sadeh <yehuda@inktank.com> Signed-off-by:
Chunwei Chen <tuxoko@gmail.com> Reviewed-by:
Ilya Dryomov <ilya.dryomov@inktank.com> Signed-off-by:
-
Geert Uytterhoeven authored
commit 83596fbe upstream. The availability of SPI Dual or Quad Transfer Mode as indicated by the "spi-tx-bus-width" and "spi-rx-bus-width" properties in the device tree is a hardware property of the SPI master, SPI slave, and board wiring. Hence the SPI core should not reject an SPI slave because an SPI master driver doesn't (yet) support Dual or Quad Transfer Mode. Change the lack of Dual or Quad Transfer Mode support in the SPI master driver from an error condition to a warning condition, and ignore the unsupported mode bits, falling back to Single Transfer Mode, to avoid breakages when running old kernels with new device trees. Fixes: f477b7fb (spi: DUAL and QUAD support) Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
Mark Brown <broonie@linaro.org> Signed-off-by:
-
Srivatsa S. Bhat authored
commit 011e4b02 upstream. If we try to perform a kexec when the machine is in ST (Single-Threaded) mode (ppc64_cpu --smt=off), the kexec operation doesn't succeed properly, and we get the following messages during boot: [ 0.089866] POWER8 performance monitor hardware support registered [ 0.089985] power8-pmu: PMAO restore workaround active. [ 5.095419] Processor 1 is stuck. [ 10.097933] Processor 2 is stuck. [ 15.100480] Processor 3 is stuck. [ 20.102982] Processor 4 is stuck. [ 25.105489] Processor 5 is stuck. [ 30.108005] Processor 6 is stuck. [ 35.110518] Processor 7 is stuck. [ 40.113369] Processor 9 is stuck. [ 45.115879] Processor 10 is stuck. [ 50.118389] Processor 11 is stuck. [ 55.120904] Processor 12 is stuck. [ 60.123425] Processor 13 is stuck. [ 65.125970] Processor 14 is stuck. [ 70.128495] Processor 15 is stuck. [ 75.131316] Processor 17 is stuck. Note that only the sibling threads are stuck, while the primary threads (0, 8, 16 etc) boot just fine. Looking closer at the previous step of kexec, we observe that kexec tries to wakeup (bring online) the sibling threads of all the cores, before performing kexec: [ 9464.131231] Starting new kernel [ 9464.148507] kexec: Waking offline cpu 1. [ 9464.148552] kexec: Waking offline cpu 2. [ 9464.148600] kexec: Waking offline cpu 3. [ 9464.148636] kexec: Waking offline cpu 4. [ 9464.148671] kexec: Waking offline cpu 5. [ 9464.148708] kexec: Waking offline cpu 6. [ 9464.148743] kexec: Waking offline cpu 7. [ 9464.148779] kexec: Waking offline cpu 9. [ 9464.148815] kexec: Waking offline cpu 10. [ 9464.148851] kexec: Waking offline cpu 11. [ 9464.148887] kexec: Waking offline cpu 12. [ 9464.148922] kexec: Waking offline cpu 13. [ 9464.148958] kexec: Waking offline cpu 14. [ 9464.148994] kexec: Waking offline cpu 15. [ 9464.149030] kexec: Waking offline cpu 17. Instrumenting this piece of code revealed that the cpu_up() operation actually fails with -EBUSY. Thus, only the primary threads of all the cores are online during kexec, and hence this is a sure-shot receipe for disaster, as explained in commit e8e5c215 (powerpc/kexec: Fix orphaned offline CPUs across kexec), as well as in the comment above wake_offline_cpus(). It turns out that cpu_up() was returning -EBUSY because the variable 'cpu_hotplug_disabled' was set to 1; and this disabling of CPU hotplug was done by migrate_to_reboot_cpu() inside kernel_kexec(). Now, migrate_to_reboot_cpu() was originally written with the assumption that any further code will not need to perform CPU hotplug, since we are anyway in the reboot path. However, kexec is clearly not such a case, since we depend on onlining CPUs, atleast on powerpc. So re-enable cpu-hotplug after returning from migrate_to_reboot_cpu() in the kexec path, to fix this regression in kexec on powerpc. Also, wrap the cpu_up() in powerpc kexec code within a WARN_ON(), so that we can catch such issues more easily in the future. Fixes: c97102ba (kexec: migrate to reboot cpu) Signed-off-by:
Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Guenter Roeck authored
commit 7998eb3d upstream. With binutils 2.24, various 64 bit builds fail with relocation errors such as arch/powerpc/kernel/built-in.o: In function `exc_debug_crit_book3e': (.text+0x165ee): relocation truncated to fit: R_PPC64_ADDR16_HI against symbol `interrupt_base_book3e' defined in .text section in arch/powerpc/kernel/built-in.o arch/powerpc/kernel/built-in.o: In function `exc_debug_crit_book3e': (.text+0x16602): relocation truncated to fit: R_PPC64_ADDR16_HI against symbol `interrupt_end_book3e' defined in .text section in arch/powerpc/kernel/built-in.o The assembler maintainer says: I changed the ABI, something that had to be done but unfortunately happens to break the booke kernel code. When building up a 64-bit value with lis, ori, shl, oris, ori or similar sequences, you now should use @high and @higha in place of @h and @ha. @h and @ha (and their associated relocs R_PPC64_ADDR16_HI and R_PPC64_ADDR16_HA) now report overflow if the value is out of 32-bit signed range. ie. @h and @ha assume you're building a 32-bit value. This is needed to report out-of-range -mcmodel=medium toc pointer offsets in @toc@h and @toc@ha expressions, and for consistency I did the same for all other @h and @ha relocs. Replacing @h with @high in one strategic location fixes the relocation errors. This has to be done conditionally since the assembler either supports @h or @high but not both. Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Gavin Shan authored
commit 372cf124 upstream. Resetting root port has more stuff to do than that for PCIe switch ports and we should have resetting root port done in firmware instead of the kernel itself. The problem was introduced by commit 5b2e198e ("powerpc/powernv: Rework EEH reset"). Signed-off-by:
Gavin Shan <gwshan@linux.vnet.ibm.com> Signed-off-by:
-
Horia Geanta authored
commit 27c5fb7a upstream. GFP_ATOMIC memory allocation could fail. In this case, avoid NULL pointer dereference and notify user. Cc: Kim Phillips <kim.phillips@freescale.com> Signed-off-by:
Horia Geanta <horia.geanta@freescale.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Olof Johansson authored
commit ce78cc07 upstream. Don't unmark the device as suspended until after it's been re-setup. The main race would be w.r.t. an i2c driver that gets resumed at the same time (asyncronously), that is allowed to do a transfer since suspended is set to 0 before reinit, but really should have seen the -EIO return instead. Signed-off-by:
Olof Johansson <olof@lixom.net> Signed-off-by:
Doug Anderson <dianders@chromium.org> Acked-by:
Kukjin Kim <kgene.kim@samsung.com> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
-
Du, Wenkai authored
commit 47bb27e7 upstream. There have been "i2c_designware 80860F41:00: controller timed out" errors on a number of Baytrail platforms. The issue is caused by incorrect value in Interrupt Mask Register (DW_IC_INTR_MASK) when i2c core is being enabled. This causes call to __i2c_dw_enable() to immediately start the transfer which leads to timeout. There are 3 failure modes observed: 1. Failure in S0 to S3 resume path The default value after reset for DW_IC_INTR_MASK is 0x8ff. When we start the first transaction after resuming from system sleep, TX_EMPTY interrupt is already unmasked because of the hardware default. 2. Failure in normal operational path This failure happens rarely and is hard to reproduce. Debug trace showed that DW_IC_INTR_MASK had value of 0x254 when failure occurred, which meant TX_EMPTY was unmasked. 3. Failure in S3 to S0 suspend path This failure also happens rarely and is hard to reproduce. Adding debug trace that read DW_IC_INTR_MASK made this failure not reproducible. But from ISR call trace we could conclude TX_EMPTY was unmasked when problem occurred. The patch masks all interrupts before the controller is enabled to resolve the faulty DW_IC_INTR_MASK conditions. Signed-off-by:
Wenkai Du <wenkai.du@intel.com> Acked-by:
Mika Westerberg <mika.westerberg@linux.intel.com> [wsa: improved the comment and removed typo in commit msg] Signed-off-by:
-
Wolfram Sang authored
commit d7653964 upstream. This hardware does not support zero length transfers. Instead, the driver does one (random) byte transfers currently with undefined results for the slaves. We now bail out. Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by:
-
Edward Lin authored
commit b753631b upstream. With win8 capabiltiy, the machine will boot itself immediately after shutdown command has executed. Work around this issue by disabling win8 capcability. This workaround also makes wireless hotkey work. Signed-off-by:
Edward Lin <yidi.lin@canonical.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Igor Mammedov authored
commit 0b9d46dd upstream. acpi_processor_add() assumes that present at boot CPUs are always onlined, it is not so if a CPU failed to become onlined. As result acpi_processor_add() will mark such CPU device as onlined in sysfs and following attempts to online/offline it using /sys/device/system/cpu/cpuX/online attribute will fail. Do not poke into device internals in acpi_processor_add() and touch "struct device { .offline }" attribute, since for CPUs onlined at boot it's set by: topology_init() -> arch_register_cpu() -> register_cpu() before ACPI device tree is parsed, and for hotplugged CPUs it's set when userspace onlines CPU via sysfs. Signed-off-by:
Igor Mammedov <imammedo@redhat.com> Acked-by:
Toshi Kani <toshi.kani@hp.com> Signed-off-by:
-
Hans de Goede authored
commit f6e6e1b9 upstream. Without this this EEE PC exports a non working WMI interface, with this it exports a working "good old" eeepc_laptop interface, fixing brightness control not working as well as rfkill being stuck in a permanent wireless blocked state. This is not an ideal way to fix this, but various attempts to fix this otherwise have failed, see: References: https://bugzilla.redhat.com/show_bug.cgi?id=1067181 Reported-and-tested-by: lou.cardone@gmail.com Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Levente Kurusa authored
commit a6f9bf4d upstream. When a ZPODD device is unbound via sysfs, the ACPI notify handler is not removed. This causes panics as observed in Bug #74601. The panic only happens when the wake happens from outside the kernel (i.e. inserting a media or pressing a button). Add a loop to ata_port_detach which loops through the port's devices and checks if zpodd is enabled, if so call zpodd_exit. Reviewed-by:
Aaron Lu <aaron.lu@intel.com> Signed-off-by:
Levente Kurusa <levex@linux.com> Signed-off-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
-
Andy Shevchenko authored
commit 97977f75 upstream. The commit dbde5c29 "dw_dmac: use devm_* functions to simplify code" turns probe function to use devm_* helpers and simultaneously brings a regression. We need to ensure irq is disabled, followed by ensuring that don't schedule any more tasklets and then its safe to use tasklet_kill(). The free_irq() will ensure that the irq is disabled and also wait till all scheduled interrupts are executed by invoking synchronize_irq(). So we need to only do tasklet_kill() after invoking free_irq(). Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Vinod Koul <vinod.koul@intel.com> Signed-off-by:
-
Ezequiel Garcia authored
commit 5a9a55bf upstream. We need to use writel() instead of writel_relaxed() when starting a channel, to ensure all the descriptors have been flushed before the activation. While at it, remove the unneeded read-modify-write and make the code simpler. Signed-off-by:
Lior Amsalem <alior@marvell.com> Signed-off-by:
Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by:
Dan Williams <dan.j.williams@intel.com> Signed-off-by:
-
Mikulas Patocka authored
commit 610f2de3 upstream. The DM crypt target used per-cpu structures to hold pointers to a ablkcipher_request structure. The code assumed that the work item keeps executing on a single CPU, so it didn't use synchronization when accessing this structure. If a CPU is disabled by writing 0 to /sys/devices/system/cpu/cpu*/online, the work item could be moved to another CPU. This causes dm-crypt crashes, like the following, because the code starts using an incorrect ablkcipher_request: smpboot: CPU 7 is now offline BUG: unable to handle kernel NULL pointer dereference at 0000000000000130 IP: [<ffffffffa1862b3d>] crypt_convert+0x12d/0x3c0 [dm_crypt] ... Call Trace: [<ffffffffa1864415>] ? kcryptd_crypt+0x305/0x470 [dm_crypt] [<ffffffff81062060>] ? finish_task_switch+0x40/0xc0 [<ffffffff81052a28>] ? process_one_work+0x168/0x470 [<ffffffff8105366b>] ? worker_thread+0x10b/0x390 [<ffffffff81053560>] ? manage_workers.isra.26+0x290/0x290 [<ffffffff81058d9f>] ? kthread+0xaf/0xc0 [<ffffffff81058cf0>] ? kthread_create_on_node+0x120/0x120 [<ffffffff813464ac>] ? ret_from_fork+0x7c/0xb0 [<ffffffff81058cf0>] ? kthread_create_on_node+0x120/0x120 Fix this bug by removing the per-cpu definition. The structure ablkcipher_request is accessed via a pointer from convert_context. Consequently, if the work item is rescheduled to a different CPU, the thread still uses the same ablkcipher_request. This change may undermine performance improvements intended by commit c0297721 ("dm crypt: scale to multiple cpus") on select hardware. In practice no performance difference was observed on recent hardware. But regardless, correctness is more important than performance. Signed-off-by:
Mikulas Patocka <mpatocka@redhat.com> Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Signed-off-by:
-
Jani Nikula authored
This is commit 0f540c3a upstream. Since commit ee1452d7 Author: Jani Nikula <jani.nikula@intel.com> Date: Fri Sep 20 15:05:30 2013 +0300 drm/i915: assume all GM45 Acer laptops use inverted backlight PWM failed and was later reverted in commit be505f64 Author: Alexander van Heukelum <heukelum@fastmail.fm> Date: Sat Dec 28 21:00:39 2013 +0100 Revert "drm/i915: assume all GM45 Acer laptops use inverted backlight PWM" fix the individual broken machine instead. Note to backporters: http://patchwork.freedesktop.org/patch/17837/ is the patch you want for 3.13 and older. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=54171 Reference: http://mid.gmane.org/DUB115-W7628C7C710EA51AA110CD4A5000@phx.gblSigned-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> [danvet: Patch mangling for 3.14 plus adding the link to the original for 3.13.] Signed-off-by:
-
Chris Wilson authored
This is commit df6f783a upstream. On non-LLC platforms, when changing the cache level of an object, we may need to unbind it so that prefetching across page boundaries does not cross into a different memory domain. This requires us to unbind conflicting vma, but we did so iterating over the objects vma in an unsafe manner (as the list was being modified as we iterated). The regression was introduced in commit 3089c6f2 Author: Ben Widawsky <ben@bwidawsk.net> Date: Wed Jul 31 17:00:03 2013 -0700 drm/i915: make caching operate on all address spaces apparently as far back as v3.12-rc1, but it has only just begun to trigger real world bug reports. Reported-and-tested-by:
Nikolay Martynov <mar.kolya@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76384Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
-
Daniel Vetter authored
This is commit 2ab1bc9d upstream. Apparently it doesn't work. X-tiled self-refresh works flawlessly otoh. Apparently X still works correctly with linear framebuffers, so might just be an issue with the initial modeset. It's unclear whether this just borked wm setup from our side or a hw restriction, but just disabling gets things going. Note that this regression was only brought to light with commit 3f2dc5ac Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Fri Jan 10 14:06:47 2014 +0200 drm/i915: Fix 915GM self-refresh enable/disable before that self-refresh for i915GM didn't work at all. Kudos to Ville for spotting a little bug in the original patch I've attached to the bug. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76103Tested-by:
Krzysztof Mazur <krzysiek@podlesie.net> Cc: Krzysztof Mazur <krzysiek@podlesie.net> Reviewed-by:
-
Mikulas Patocka authored
commit 1e1110c4 upstream. On each processed XCOPY command, two "kmalloc-512" memory objects are leaked. These represent two allocations of struct xcopy_pt_cmd in target_core_xcopy.c. The reason for the memory leak is that the cmd_kref field is not initialized (thus, it is zero because the allocations were done with kzalloc). When we decrement zero kref in target_put_sess_cmd, the result is not zero, thus target_release_cmd_kref is not called. This patch fixes the bug by moving kref initialization from target_get_sess_cmd to transport_init_se_cmd (this function is called from target_core_xcopy.c, so it will correctly initialize cmd_kref). It can be easily verified that all code that calls target_get_sess_cmd also calls transport_init_se_cmd earlier, thus moving kref_init shouldn't introduce any new problems. Signed-off-by:
Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by:
-
Andy Grover authored
commit 07b8dae3 upstream. Just like for pSCSI, if the transport sets get_write_cache, then it is not valid to enable write cache emulation for it. Return an error. see https://bugzilla.redhat.com/show_bug.cgi?id=1082675Reviewed-by:
Chris Leech <cleech@redhat.com> Signed-off-by:
Andy Grover <agrover@redhat.com> Signed-off-by:
-
Nicholas Bellinger authored
commit 7cbfcc95 upstream. This patch changes an incorrect use of BUG_ON to instead generate a REJECT + PROTOCOL_ERROR in iscsit_process_nop_out() code. This case can occur with traditional TCP where a flood of zeros in the data stream can reach this block for what is presumed to be a NOP-OUT with a solicited reply, but without a valid iscsi_cmd pointer. This incorrect BUG_ON was introduced during the v3.11-rc timeframe with the following commit: commit 778de368 Author: Nicholas Bellinger <nab@linux-iscsi.org> Date: Fri Jun 14 16:07:47 2013 -0700 iscsi/isert-target: Refactor ISCSI_OP_NOOP RX handling Reported-by:
Arshad Hussain <arshad.hussain@calsoftinc.com> Signed-off-by:
-
