| 03cdadb | Dan Williams | 26 February 2016, 23:19:43 UTC | block: disable block device DAX by default The recent *sync enabling discovered that we are inserting into the block_device pagecache counter to the expectations of the dirty data tracking for dax mappings. This can lead to data corruption. We want to support DAX for block devices eventually, but it requires wider changes to properly manage the pagecache. dump_stack+0x85/0xc2 dax_writeback_mapping_range+0x60/0xe0 blkdev_writepages+0x3f/0x50 do_writepages+0x21/0x30 __filemap_fdatawrite_range+0xc6/0x100 filemap_write_and_wait+0x4a/0xa0 set_blocksize+0x70/0xd0 sb_set_blocksize+0x1d/0x50 ext4_fill_super+0x75b/0x3360 mount_bdev+0x180/0x1b0 ext4_mount+0x15/0x20 mount_fs+0x38/0x170 Mark the support broken so its disabled by default, but otherwise still available for testing. Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com> Reported-by: Ross Zwisler <ross.zwisler@linux.intel.com> Suggested-by: Dave Chinner <david@fromorbit.com> Reviewed-by: Jan Kara <jack@suse.cz> Cc: Jens Axboe <axboe@fb.com> Cc: Matthew Wilcox <matthew.r.wilcox@intel.com> Cc: Al Viro <viro@ftp.linux.org.uk> Cc: Theodore Ts'o <tytso@mit.edu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | 27 February 2016, 18:28:52 UTC |
| a4a8481 | Guozhonghua | 26 February 2016, 23:19:40 UTC | ocfs2: unlock inode if deleting inode from orphan fails When doing append direct io cleanup, if deleting inode fails, it goes out without unlocking inode, which will cause the inode deadlock. This issue was introduced by commit cf1776a9e834 ("ocfs2: fix a tiny race when truncate dio orohaned entry"). Signed-off-by: Guozhonghua <guozhonghua@h3c.com> Signed-off-by: Joseph Qi <joseph.qi@huawei.com> Reviewed-by: Gang He <ghe@suse.com> Cc: Mark Fasheh <mfasheh@suse.de> Cc: Joel Becker <jlbec@evilplan.org> Cc: Junxiao Bi <junxiao.bi@oracle.com> Cc: <stable@vger.kernel.org> [4.2+] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | 27 February 2016, 18:28:52 UTC |
| 5ef11c3 | Daniel Cashman | 26 February 2016, 23:19:37 UTC | mm: ASLR: use get_random_long() Replace calls to get_random_int() followed by a cast to (unsigned long) with calls to get_random_long(). Also address shifting bug which, in case of x86 removed entropy mask for mmap_rnd_bits values > 31 bits. Signed-off-by: Daniel Cashman <dcashman@android.com> Acked-by: Kees Cook <keescook@chromium.org> Cc: "Theodore Ts'o" <tytso@mit.edu> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: David S. Miller <davem@davemloft.net> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Nick Kralevich <nnk@google.com> Cc: Jeff Vander Stoep <jeffv@google.com> Cc: Mark Salyzyn <salyzyn@android.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | 27 February 2016, 18:28:52 UTC |
| ec9ee4a | Daniel Cashman | 26 February 2016, 23:19:34 UTC | drivers: char: random: add get_random_long() Commit d07e22597d1d ("mm: mmap: add new /proc tunable for mmap_base ASLR") added the ability to choose from a range of values to use for entropy count in generating the random offset to the mmap_base address. The maximum value on this range was set to 32 bits for 64-bit x86 systems, but this value could be increased further, requiring more than the 32 bits of randomness provided by get_random_int(), as is already possible for arm64. Add a new function: get_random_long() which more naturally fits with the mmap usage of get_random_int() but operates exactly the same as get_random_int(). Also, fix the shifting constant in mmap_rnd() to be an unsigned long so that values greater than 31 bits generate an appropriate mask without overflow. This is especially important on x86, as its shift instruction uses a 5-bit mask for the shift operand, which meant that any value for mmap_rnd_bits over 31 acts as a no-op and effectively disables mmap_base randomization. Finally, replace calls to get_random_int() with get_random_long() where appropriate. This patch (of 2): Add get_random_long(). Signed-off-by: Daniel Cashman <dcashman@android.com> Acked-by: Kees Cook <keescook@chromium.org> Cc: "Theodore Ts'o" <tytso@mit.edu> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: David S. Miller <davem@davemloft.net> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Nick Kralevich <nnk@google.com> Cc: Jeff Vander Stoep <jeffv@google.com> Cc: Mark Salyzyn <salyzyn@android.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | 27 February 2016, 18:28:52 UTC |
| 8479eba | Mel Gorman | 26 February 2016, 23:19:31 UTC | mm: numa: quickly fail allocations for NUMA balancing on full nodes Commit 4167e9b2cf10 ("mm: remove GFP_THISNODE") removed the GFP_THISNODE flag combination due to confusing semantics. It noted that alloc_misplaced_dst_page() was one such user after changes made by commit e97ca8e5b864 ("mm: fix GFP_THISNODE callers and clarify"). Unfortunately when GFP_THISNODE was removed, users of alloc_misplaced_dst_page() started waking kswapd and entering direct reclaim because the wrong GFP flags are cleared. The consequence is that workloads that used to fit into memory now get reclaimed which is addressed by this patch. The problem can be demonstrated with "mutilate" that exercises memcached which is software dedicated to memory object caching. The configuration uses 80% of memory and is run 3 times for varying numbers of clients. The results on a 4-socket NUMA box are mutilate 4.4.0 4.4.0 vanilla numaswap-v1 Hmean 1 8394.71 ( 0.00%) 8395.32 ( 0.01%) Hmean 4 30024.62 ( 0.00%) 34513.54 ( 14.95%) Hmean 7 32821.08 ( 0.00%) 70542.96 (114.93%) Hmean 12 55229.67 ( 0.00%) 93866.34 ( 69.96%) Hmean 21 39438.96 ( 0.00%) 85749.21 (117.42%) Hmean 30 37796.10 ( 0.00%) 50231.49 ( 32.90%) Hmean 47 18070.91 ( 0.00%) 38530.13 (113.22%) The metric is queries/second with the more the better. The results are way outside of the noise and the reason for the improvement is obvious from some of the vmstats 4.4.0 4.4.0 vanillanumaswap-v1r1 Minor Faults 1929399272 2146148218 Major Faults 19746529 3567 Swap Ins 57307366 9913 Swap Outs 50623229 17094 Allocation stalls 35909 443 DMA allocs 0 0 DMA32 allocs 72976349 170567396 Normal allocs 5306640898 5310651252 Movable allocs 0 0 Direct pages scanned 404130893 799577 Kswapd pages scanned 160230174 0 Kswapd pages reclaimed 55928786 0 Direct pages reclaimed 1843936 41921 Page writes file 2391 0 Page writes anon 50623229 17094 The vanilla kernel is swapping like crazy with large amounts of direct reclaim and kswapd activity. The figures are aggregate but it's known that the bad activity is throughout the entire test. Note that simple streaming anon/file memory consumers also see this problem but it's not as obvious. In those cases, kswapd is awake when it should not be. As there are at least two reclaim-related bugs out there, it's worth spelling out the user-visible impact. This patch only addresses bugs related to excessive reclaim on NUMA hardware when the working set is larger than a NUMA node. There is a bug related to high kswapd CPU usage but the reports are against laptops and other UMA hardware and is not addressed by this patch. Signed-off-by: Mel Gorman <mgorman@techsingularity.net> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: David Rientjes <rientjes@google.com> Cc: <stable@vger.kernel.org> [4.1+] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | 27 February 2016, 18:28:52 UTC |
| ad33bb0 | Andrea Arcangeli | 26 February 2016, 23:19:28 UTC | mm: thp: fix SMP race condition between THP page fault and MADV_DONTNEED pmd_trans_unstable()/pmd_none_or_trans_huge_or_clear_bad() were introduced to locklessy (but atomically) detect when a pmd is a regular (stable) pmd or when the pmd is unstable and can infinitely transition from pmd_none() and pmd_trans_huge() from under us, while only holding the mmap_sem for reading (for writing not). While holding the mmap_sem only for reading, MADV_DONTNEED can run from under us and so before we can assume the pmd to be a regular stable pmd we need to compare it against pmd_none() and pmd_trans_huge() in an atomic way, with pmd_trans_unstable(). The old pmd_trans_huge() left a tiny window for a race. Useful applications are unlikely to notice the difference as doing MADV_DONTNEED concurrently with a page fault would lead to undefined behavior. [akpm@linux-foundation.org: tidy up comment grammar/layout] Signed-off-by: Andrea Arcangeli <aarcange@redhat.com> Reported-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | 27 February 2016, 18:28:52 UTC |
| 29a9faa | Linus Torvalds | 26 February 2016, 17:35:03 UTC | Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client Pull Ceph fixes from Sage Weil: "There are two small messenger bug fixes and a log spam regression fix" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client: libceph: don't spam dmesg with stray reply warnings libceph: use the right footer size when skipping a message libceph: don't bail early from try_read() when skipping a message | 26 February 2016, 17:35:03 UTC |
| c213341 | Linus Torvalds | 26 February 2016, 17:27:21 UTC | Merge tag 'sound-4.5-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound Pull sound fixes from Takashi Iwai: "Things got calmed down for rc6, as it seems, and we have only a few HD-audio fixes at this time: a fix for Skylake codec probe errors, a fix for missing interrupt handling, and a few Dell and HP quirks" * tag 'sound-4.5-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: ALSA: hda - Loop interrupt handling until really cleared ALSA: hda - Fix headset support and noise on HP EliteBook 755 G2 ALSA: hda - Fixup speaker pass-through control for nid 0x14 on ALC225 ALSA: hda - Fixing background noise on Dell Inspiron 3162 ALSA: hda - Apply clock gate workaround to Skylake, too | 26 February 2016, 17:27:21 UTC |
| bb134ff | Linus Torvalds | 26 February 2016, 17:21:48 UTC | Merge tag 'pm+acpi-4.5-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull power management and ACPI fixes from Rafael Wysocki: "These are two reverts of recent PCI-related ACPI core changes (one of which caused some systems to crash on boot and the other was a cleanup on top of it) and a devfreq fix for Tegra. Specifics: - Revert an ACPI core change related to IRQ management in PCI that introduced code relying on the use of kmalloc() which turned out to also run during early init when that's not available yet and caused some systems to crash on boot for this reason along with a cleanup on top of it (Rafael Wysocki). - Prevent devfreq from flooding the kernel log with useless messages on Tegra (which started to happen after some recent changes in the devfreq core) by fixing the driver to follow the documentation and the core's expectations in its ->target callback (Tomeu Vizoso)" * tag 'pm+acpi-4.5-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: Revert "ACPI, PCI, irq: remove interrupt count restriction" Revert "ACPI / PCI: Simplify acpi_penalize_isa_irq()" PM / devfreq: tegra: Set freq in rate callback | 26 February 2016, 17:21:48 UTC |
| 1711fd9 | Rafael J. Wysocki | 26 February 2016, 12:50:55 UTC | Merge branches 'pm-devfreq' and 'acpi-pci' * pm-devfreq: PM / devfreq: tegra: Set freq in rate callback * acpi-pci: Revert "ACPI, PCI, irq: remove interrupt count restriction" Revert "ACPI / PCI: Simplify acpi_penalize_isa_irq()" | 26 February 2016, 12:50:55 UTC |
| 34d47a7 | James Morris | 26 February 2016, 08:32:16 UTC | Merge branch 'stable-4.5' of git://git.infradead.org/users/pcmoore/selinux into for-linus | 26 February 2016, 08:32:16 UTC |
| 473f414 | Takashi Iwai | 23 February 2016, 14:54:47 UTC | ALSA: hda - Loop interrupt handling until really cleared Currently the interrupt handler of HD-audio driver assumes that no irq update is needed while processing the irq. But in reality, it has been confirmed that the HW irq is issued even during the irq handling. Since we clear the irq status at the beginning, process the interrupt, then exits from the handler, the lately issued interrupt is left untouched without being properly processed. This patch changes the interrupt handler code to loop over the check-and-process. The handler tries repeatedly as long as the IRQ status are turned on, and either stream or CORB/RIRB is handled. For checking the stream handling, snd_hdac_bus_handle_stream_irq() returns a value indicating the stream indices bits. Other than that, the change is only in the irq handler itself. Reported-by: Libin Yang <libin.yang@linux.intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> | 26 February 2016, 07:50:31 UTC |
| 5bb9871 | Linus Torvalds | 26 February 2016, 04:12:09 UTC | Merge tag 'trace-fixes-v4.5-rc5-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace Pull tracing fix from Steven Rostedt: "Another small bug reported to me by Chunyu Hu. When perf added a "reg" function to the function tracing event (not a tracepoint), it caused that event to be displayed as a tracepoint and could cause errors in tracepoint handling. That was solved by adding a flag to ignore ftrace non-tracepoint events. But that flag was missed when displaying events in available_events, which should only contain tracepoint events. This broke a documented way to enable all events with: cat available_events > set_event As the function non-tracepoint event would cause that to error out. The commit here fixes that by having the available_events file not list events that have the ignore flag set" * tag 'trace-fixes-v4.5-rc5-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace: tracing: Fix showing function event in available_events | 26 February 2016, 04:12:09 UTC |
| 73056bb | Linus Torvalds | 26 February 2016, 03:53:54 UTC | Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm Pull KVM fixes from Paolo Bonzini: "KVM/ARM fixes: - Fix per-vcpu vgic bitmap allocation - Do not give copy random memory on MMIO read - Fix GICv3 APR register restore order KVM/x86 fixes: - Fix ubsan warning - Fix hardware breakpoints in a guest vs. preempt notifiers - Fix Hurd Generic: - use __GFP_NOWARN together with GFP_NOWAIT" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: KVM: x86: MMU: fix ubsan index-out-of-range warning arm64: KVM: vgic-v3: Restore ICH_APR0Rn_EL2 before ICH_APR1Rn_EL2 KVM: async_pf: do not warn on page allocation failures KVM: x86: fix conversion of addresses to linear in 32-bit protected mode KVM: x86: fix missed hardware breakpoints arm/arm64: KVM: Feed initialized memory to MMIO accesses KVM: arm/arm64: vgic: Ensure bitmaps are long enough | 26 February 2016, 03:53:54 UTC |
| 5882c16 | Linus Torvalds | 26 February 2016, 03:47:01 UTC | Merge tag 'renesas-sh-drivers-fixes-for-v4.5' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas Pull SuperH driver fix from Simon Horman: "Restore legacy clock domain on SuperH platforms" * tag 'renesas-sh-drivers-fixes-for-v4.5' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas: drivers: sh: Restore legacy clock domain on SuperH platforms | 26 February 2016, 03:47:01 UTC |
| 9aca90a | Linus Torvalds | 26 February 2016, 03:41:53 UTC | Merge tag 'powerpc-4.5-4' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux Pull powerpc fixes from Michael Ellerman: - eeh: Fix partial hotplug criterion from Gavin Shan - mm: Clear the invalid slot information correctly from Aneesh Kumar K.V * tag 'powerpc-4.5-4' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: powerpc/mm/hash: Clear the invalid slot information correctly powerpc/eeh: Fix partial hotplug criterion | 26 February 2016, 03:41:53 UTC |
| 70d070f | Linus Torvalds | 26 February 2016, 03:36:33 UTC | Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux Pull s390 bugfixes from Martin Schwidefsky: "Two critical bug fixes for the signal handling" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390/fpu: signals vs. floating point control register s390/compat: correct restore of high gprs on signal return | 26 February 2016, 03:36:33 UTC |
| 81904db | Linus Torvalds | 26 February 2016, 03:31:01 UTC | Merge tag 'nfsd-4.5-1' of git://linux-nfs.org/~bfields/linux Pull nfsd bugfix from Bruce Fields: "One fix for a bug that could cause a NULL write past the end of a buffer in case of unusually long writes to some system interfaces used by mountd and other nfs support utilities" * tag 'nfsd-4.5-1' of git://linux-nfs.org/~bfields/linux: sunrpc/cache: fix off-by-one in qword_get() | 26 February 2016, 03:31:01 UTC |
| 3acdb84 | Linus Torvalds | 26 February 2016, 03:01:42 UTC | Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux Pull drm fixes from Dave Airlie: "This is a bit larger than Id like, but I asked the Intel guys to pull in some Skylake fixes in the possibly vain hope that Skylake might be more functional now that I'm seeing production hardware shipping. For i915, it's mostly the same patch in a few places, making sure the hw doesn't turn off when we are programming it. Apart from that are two nouveau fixes, one for a module defer bug, and one for using nouveau on new Lenovo P50 models. Then there are a bunch of AMDGPU fixes, one is a fix for v4.4 vblank regressions, and some PM fixes" * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: (26 commits) drm/nouveau/disp/dp: ensure sink is powered up before attempting link training drm/nouveau: platform: Fix deferred probe drm/amdgpu: disable direct VM updates when vm_debug is set amdgpu: fix NULL pointer dereference at tonga_check_states_equal drm/i915/gen9: Verify and enforce dc6 state writes drm/i915/gen9: Check for DC state mismatch drm/radeon/pm: adjust display configuration after powerstate drm/amdgpu/pm: adjust display configuration after powerstate drm/amdgpu/pm: add some checks for PX drm/amdgpu: fix locking in force performance level drm/amdgpu/gfx8: fix priv reg interrupt enable drm/i915/skl: Ensure HW is powered during DDB HW state readout drm/i915/lvds: Ensure the HW is powered during HW state readout drm/i915/hdmi: Ensure the HW is powered during HW state readout drm/i915/dsi: Ensure the HW is powered during HW state readout drm/i915/dp: Ensure the HW is powered during HW state readout drm/i915: Ensure the HW is powered when accessing the CRC HW block drm/i915/ddi: Ensure the HW is powered during HW state readout drm/i915/crt: Ensure the HW is powered during HW state readout drm/i915: Ensure the HW is powered during HW access in assert_pipe ... | 26 February 2016, 03:01:42 UTC |
| 3d7b365 | Linus Torvalds | 26 February 2016, 02:54:53 UTC | Merge branch 'libnvdimm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm Pull libnvdimm fixes from Dan Williams: - Two fixes for compatibility with the ACPI 6.1 specification. Without these fixes multi-interface DIMMs will fail to be probed, and address range scrub commands to find memory errors will give results that the kernel will mis-interpret. For multi-interface DIMMs Linux will accept either the original 6.0 implementation or 6.1. For address range scrub we'll only support 6.1 since ACPI formalized this DSM differently than the original example [1] implemented in v4.2. The expectation is that production systems will only ever ship the ACPI 6.1 address range scrub command definition. - The wider async address range scrub work targeting 4.6 discovered that the original synchronous implementation in 4.5 is not sizing its return buffer correctly. - Arnd caught that my recent fix to the size of the pfn_t flags missed updating the flags variable used in the pmem driver. - Toshi found that we mishandle the memremap() return value in devm_memremap(). * 'libnvdimm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm: nvdimm: use 'u64' for pfn flags devm_memremap: Fix error value when memremap failed nfit: update address range scrub commands to the acpi 6.1 format libnvdimm, tools/testing/nvdimm: fix 'ars_status' output buffer sizing nfit: fix multi-interface dimm handling, acpi6.1 compatibility | 26 February 2016, 02:54:53 UTC |
| 1ebe383 | Linus Torvalds | 26 February 2016, 02:42:08 UTC | Merge tag 'for-v4.5-rc' of git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply Pull power supply fixes from Sebastian Reichel: "Add a regression fix for changed sysfs path of bq27xxx_battery and update MAINTAINERS file" * tag 'for-v4.5-rc' of git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply: power: bq27xxx_battery: Restore device name MAINTAINERS: update bq27xxx driver | 26 February 2016, 02:42:08 UTC |
| f883982 | Takashi Iwai | 25 February 2016, 13:31:59 UTC | ALSA: hda - Fix headset support and noise on HP EliteBook 755 G2 HP EliteBook 755 G2 with ALC3228 (ALC280) codec [103c:221c] requires the known fixup (ALC269_FIXUP_HEADSET_MIC) for making the headset mic working. Also, it suffers from the loopback noise problem, so we should disable aamix path as well. Reported-by: Derick Eddington <derick.eddington@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> | 25 February 2016, 13:36:08 UTC |
| 2ae9557 | David Henningsson | 25 February 2016, 08:37:05 UTC | ALSA: hda - Fixup speaker pass-through control for nid 0x14 on ALC225 On one of the machines we enable, we found that the actual speaker volume did not always correspond to the volume set in alsamixer. This patch fixes that problem. This patch was orginally written by Kailang @ Realtek, I've rebased it to fit sound git master. Cc: stable@vger.kernel.org BugLink: https://bugs.launchpad.net/bugs/1549660 Co-Authored-By: Kailang <kailang@realtek.com> Signed-off-by: David Henningsson <david.henningsson@canonical.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> | 25 February 2016, 09:24:29 UTC |
| 0fb00d3 | Paolo Bonzini | 25 February 2016, 08:53:55 UTC | Merge tag 'kvm-arm-for-4.5-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into kvm-master KVM/ARM fixes for 4.5-rc6 - Fix per-vcpu vgic bitmap allocation - Do not give copy random memory on MMIO read - Fix GICv3 APR register restore order | 25 February 2016, 08:53:55 UTC |
| 17e4bce | Mike Krinkin | 24 February 2016, 18:02:31 UTC | KVM: x86: MMU: fix ubsan index-out-of-range warning Ubsan reports the following warning due to a typo in update_accessed_dirty_bits template, the patch fixes the typo: [ 168.791851] ================================================================================ [ 168.791862] UBSAN: Undefined behaviour in arch/x86/kvm/paging_tmpl.h:252:15 [ 168.791866] index 4 is out of range for type 'u64 [4]' [ 168.791871] CPU: 0 PID: 2950 Comm: qemu-system-x86 Tainted: G O L 4.5.0-rc5-next-20160222 #7 [ 168.791873] Hardware name: LENOVO 23205NG/23205NG, BIOS G2ET95WW (2.55 ) 07/09/2013 [ 168.791876] 0000000000000000 ffff8801cfcaf208 ffffffff81c9f780 0000000041b58ab3 [ 168.791882] ffffffff82eb2cc1 ffffffff81c9f6b4 ffff8801cfcaf230 ffff8801cfcaf1e0 [ 168.791886] 0000000000000004 0000000000000001 0000000000000000 ffffffffa1981600 [ 168.791891] Call Trace: [ 168.791899] [<ffffffff81c9f780>] dump_stack+0xcc/0x12c [ 168.791904] [<ffffffff81c9f6b4>] ? _atomic_dec_and_lock+0xc4/0xc4 [ 168.791910] [<ffffffff81da9e81>] ubsan_epilogue+0xd/0x8a [ 168.791914] [<ffffffff81daafa2>] __ubsan_handle_out_of_bounds+0x15c/0x1a3 [ 168.791918] [<ffffffff81daae46>] ? __ubsan_handle_shift_out_of_bounds+0x2bd/0x2bd [ 168.791922] [<ffffffff811287ef>] ? get_user_pages_fast+0x2bf/0x360 [ 168.791954] [<ffffffffa1794050>] ? kvm_largepages_enabled+0x30/0x30 [kvm] [ 168.791958] [<ffffffff81128530>] ? __get_user_pages_fast+0x360/0x360 [ 168.791987] [<ffffffffa181b818>] paging64_walk_addr_generic+0x1b28/0x2600 [kvm] [ 168.792014] [<ffffffffa1819cf0>] ? init_kvm_mmu+0x1100/0x1100 [kvm] [ 168.792019] [<ffffffff8129e350>] ? debug_check_no_locks_freed+0x350/0x350 [ 168.792044] [<ffffffffa1819cf0>] ? init_kvm_mmu+0x1100/0x1100 [kvm] [ 168.792076] [<ffffffffa181c36d>] paging64_gva_to_gpa+0x7d/0x110 [kvm] [ 168.792121] [<ffffffffa181c2f0>] ? paging64_walk_addr_generic+0x2600/0x2600 [kvm] [ 168.792130] [<ffffffff812e848b>] ? debug_lockdep_rcu_enabled+0x7b/0x90 [ 168.792178] [<ffffffffa17d9a4a>] emulator_read_write_onepage+0x27a/0x1150 [kvm] [ 168.792208] [<ffffffffa1794d44>] ? __kvm_read_guest_page+0x54/0x70 [kvm] [ 168.792234] [<ffffffffa17d97d0>] ? kvm_task_switch+0x160/0x160 [kvm] [ 168.792238] [<ffffffff812e848b>] ? debug_lockdep_rcu_enabled+0x7b/0x90 [ 168.792263] [<ffffffffa17daa07>] emulator_read_write+0xe7/0x6d0 [kvm] [ 168.792290] [<ffffffffa183b620>] ? em_cr_write+0x230/0x230 [kvm] [ 168.792314] [<ffffffffa17db005>] emulator_write_emulated+0x15/0x20 [kvm] [ 168.792340] [<ffffffffa18465f8>] segmented_write+0xf8/0x130 [kvm] [ 168.792367] [<ffffffffa1846500>] ? em_lgdt+0x20/0x20 [kvm] [ 168.792374] [<ffffffffa14db512>] ? vmx_read_guest_seg_ar+0x42/0x1e0 [kvm_intel] [ 168.792400] [<ffffffffa1846d82>] writeback+0x3f2/0x700 [kvm] [ 168.792424] [<ffffffffa1846990>] ? em_sidt+0xa0/0xa0 [kvm] [ 168.792449] [<ffffffffa185554d>] ? x86_decode_insn+0x1b3d/0x4f70 [kvm] [ 168.792474] [<ffffffffa1859032>] x86_emulate_insn+0x572/0x3010 [kvm] [ 168.792499] [<ffffffffa17e71dd>] x86_emulate_instruction+0x3bd/0x2110 [kvm] [ 168.792524] [<ffffffffa17e6e20>] ? reexecute_instruction.part.110+0x2e0/0x2e0 [kvm] [ 168.792532] [<ffffffffa14e9a81>] handle_ept_misconfig+0x61/0x460 [kvm_intel] [ 168.792539] [<ffffffffa14e9a20>] ? handle_pause+0x450/0x450 [kvm_intel] [ 168.792546] [<ffffffffa15130ea>] vmx_handle_exit+0xd6a/0x1ad0 [kvm_intel] [ 168.792572] [<ffffffffa17f6a6c>] ? kvm_arch_vcpu_ioctl_run+0xbdc/0x6090 [kvm] [ 168.792597] [<ffffffffa17f6bcd>] kvm_arch_vcpu_ioctl_run+0xd3d/0x6090 [kvm] [ 168.792621] [<ffffffffa17f6a6c>] ? kvm_arch_vcpu_ioctl_run+0xbdc/0x6090 [kvm] [ 168.792627] [<ffffffff8293b530>] ? __ww_mutex_lock_interruptible+0x1630/0x1630 [ 168.792651] [<ffffffffa17f5e90>] ? kvm_arch_vcpu_runnable+0x4f0/0x4f0 [kvm] [ 168.792656] [<ffffffff811eeb30>] ? preempt_notifier_unregister+0x190/0x190 [ 168.792681] [<ffffffffa17e0447>] ? kvm_arch_vcpu_load+0x127/0x650 [kvm] [ 168.792704] [<ffffffffa178e9a3>] kvm_vcpu_ioctl+0x553/0xda0 [kvm] [ 168.792727] [<ffffffffa178e450>] ? vcpu_put+0x40/0x40 [kvm] [ 168.792732] [<ffffffff8129e350>] ? debug_check_no_locks_freed+0x350/0x350 [ 168.792735] [<ffffffff82946087>] ? _raw_spin_unlock+0x27/0x40 [ 168.792740] [<ffffffff8163a943>] ? handle_mm_fault+0x1673/0x2e40 [ 168.792744] [<ffffffff8129daa8>] ? trace_hardirqs_on_caller+0x478/0x6c0 [ 168.792747] [<ffffffff8129dcfd>] ? trace_hardirqs_on+0xd/0x10 [ 168.792751] [<ffffffff812e848b>] ? debug_lockdep_rcu_enabled+0x7b/0x90 [ 168.792756] [<ffffffff81725a80>] do_vfs_ioctl+0x1b0/0x12b0 [ 168.792759] [<ffffffff817258d0>] ? ioctl_preallocate+0x210/0x210 [ 168.792763] [<ffffffff8174aef3>] ? __fget+0x273/0x4a0 [ 168.792766] [<ffffffff8174acd0>] ? __fget+0x50/0x4a0 [ 168.792770] [<ffffffff8174b1f6>] ? __fget_light+0x96/0x2b0 [ 168.792773] [<ffffffff81726bf9>] SyS_ioctl+0x79/0x90 [ 168.792777] [<ffffffff82946880>] entry_SYSCALL_64_fastpath+0x23/0xc1 [ 168.792780] ================================================================================ Signed-off-by: Mike Krinkin <krinkin.m.u@gmail.com> Reviewed-by: Xiao Guangrong <guangrong.xiao@linux.intel.com> Cc: stable@vger.kernel.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> | 25 February 2016, 08:50:35 UTC |
| 3b43b71 | Kai-Heng Feng | 25 February 2016, 07:19:38 UTC | ALSA: hda - Fixing background noise on Dell Inspiron 3162 After login to the desktop on Dell Inspiron 3162, there's a very loud background noise comes from the builtin speaker. The noise does not go away even if the speaker is muted. The noise disappears after using the aamix fixup. Codec: Realtek ALC3234 Address: 0 AFG Function Id: 0x1 (unsol 1) Vendor Id: 0x10ec0255 Subsystem Id: 0x10280725 Revision Id: 0x100002 No Modem Function Group found BugLink: http://bugs.launchpad.net/bugs/1549620 Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> | 25 February 2016, 08:10:13 UTC |
| 3772e72 | Dave Airlie | 25 February 2016, 03:17:50 UTC | Merge branch 'linux-4.5' of git://github.com/skeggsb/linux into drm-fixes single for for eDP panel issues on Lenovo P50 * 'linux-4.5' of git://github.com/skeggsb/linux: drm/nouveau/disp/dp: ensure sink is powered up before attempting link training | 25 February 2016, 03:17:50 UTC |
| 95664e6 | Ben Skeggs | 17 February 2016, 22:14:19 UTC | drm/nouveau/disp/dp: ensure sink is powered up before attempting link training This can happen under some annoying circumstances, and is a quick fix until more substantial changes can be made. Fixed eDP mode changes on (at least) the Lenovo P50. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org | 25 February 2016, 03:15:43 UTC |
| 870571a | Thierry Reding | 24 February 2016, 17:34:43 UTC | drm/nouveau: platform: Fix deferred probe The error cleanup paths aren't quite correct and will crash upon deferred probe. Cc: stable@vger.kernel.org # v4.3+ Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com> | 25 February 2016, 02:20:59 UTC |
| 0378ba4 | Geert Uytterhoeven | 24 February 2016, 08:43:23 UTC | drivers: sh: Restore legacy clock domain on SuperH platforms CONFIG_ARCH_SHMOBILE is not only enabled for Renesas ARM platforms (which are DT based and multi-platform), but also on a select set of Renesas SuperH platforms (SH7722/SH7723/SH7724/SH7343/SH7366). Hence since commit 0ba58de231066e47 ("drivers: sh: Get rid of CONFIG_ARCH_SHMOBILE_MULTI"), the legacy clock domain is no longer installed on these SuperH platforms, and module clocks may not be enabled when needed, leading to driver failures. To fix this, add an additional check for CONFIG_OF. Fixes: 0ba58de231066e47 ("drivers: sh: Get rid of CONFIG_ARCH_SHMOBILE_MULTI"). Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Simon Horman <horms+renesas@verge.net.au> | 25 February 2016, 00:05:19 UTC |
| 398cb0c | Dave Airlie | 24 February 2016, 22:22:43 UTC | Merge tag 'drm-intel-fixes-2016-02-22' of git://anongit.freedesktop.org/drm-intel into drm-fixes This is a bit large, but it really helps Skylake bugs we are seeing on a number of laptops. Most of the commits are quite similar, ensuring the display power doesn't vanish under us during hardware access. Also do note that it's not just Skylake that's affected. * tag 'drm-intel-fixes-2016-02-22' of git://anongit.freedesktop.org/drm-intel: drm/i915/gen9: Verify and enforce dc6 state writes drm/i915/gen9: Check for DC state mismatch drm/i915/skl: Ensure HW is powered during DDB HW state readout drm/i915/lvds: Ensure the HW is powered during HW state readout drm/i915/hdmi: Ensure the HW is powered during HW state readout drm/i915/dsi: Ensure the HW is powered during HW state readout drm/i915/dp: Ensure the HW is powered during HW state readout drm/i915: Ensure the HW is powered when accessing the CRC HW block drm/i915/ddi: Ensure the HW is powered during HW state readout drm/i915/crt: Ensure the HW is powered during HW state readout drm/i915: Ensure the HW is powered during HW access in assert_pipe drm/i915: Ensure the HW is powered when disabling VGA drm/i915/ibx: Ensure the HW is powered during PLL HW readout drm/i915: Ensure the HW is powered during display pipe HW readout drm/i915: Add helper to get a display power ref if it was already enabled | 24 February 2016, 22:22:43 UTC |
| ad00a57 | Dave Airlie | 24 February 2016, 22:21:33 UTC | Merge branch 'drm-fixes-4.5' of git://people.freedesktop.org/~agd5f/linux into drm-fixes A few radeon and amdgpu fixes for 4.5. A few further fixes for the vblank regressions in 4.4 and a couple of other minor fixes. * 'drm-fixes-4.5' of git://people.freedesktop.org/~agd5f/linux: drm/amdgpu: disable direct VM updates when vm_debug is set amdgpu: fix NULL pointer dereference at tonga_check_states_equal drm/radeon/pm: adjust display configuration after powerstate drm/amdgpu/pm: adjust display configuration after powerstate drm/amdgpu/pm: add some checks for PX drm/amdgpu: fix locking in force performance level drm/amdgpu/gfx8: fix priv reg interrupt enable drm/amdgpu: Don't hang in amdgpu_flip_work_func on disabled crtc. drm/radeon: Don't hang in radeon_flip_work_func on disabled crtc. (v2) | 24 February 2016, 22:21:33 UTC |
| 6dc390a | Linus Torvalds | 24 February 2016, 22:06:17 UTC | Merge tag 'arc-4.5-rc6-fixes-upd' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc Pull ARC fixes from Vineet Gupta: - Fix for csd deadlock due to missing self IPI - Accompanying IPI cleanups / optimization - Brown paper bag bug in one of the cleanups above - Boot reporting updates for new hardware features - Don't force DEVTMPFS if INITRAMFS * tag 'arc-4.5-rc6-fixes-upd' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc: arc: SMP: CONFIG_ARC_IPI_DBG cleanup ARC: SMP: No need for CONFIG_ARC_IPI_DBG ARCv2: Elide sending new cross core intr if receiver didn't ack prev ARCv2: SMP: Push IPI_IRQ into IPI provider ARC: [intc-compact] Remove IPI setup from ARCompact port ARCv2: SMP: Emulate IPI to self using software triggered interrupt arc: get rid of DEVTMPFS dependency on INITRAMFS_SOURCE ARCv2: boot report CCMs (Closely Coupled Memories) ARCv2: boot print Low Latency Memory ARC: Assume multiplier is always present | 24 February 2016, 22:06:17 UTC |
| aa263c4 | Linus Torvalds | 24 February 2016, 22:00:26 UTC | Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs Pull vfs fixes from Al Viro: "Assorted fixes - xattr one from this cycle, the rest - stable fodder" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: fs/pnode.c: treat zero mnt_group_id-s as unequal affs_do_readpage_ofs(): just use kmap_atomic() around memcpy() xattr handlers: plug a lock leak in simple_xattr_list fs: allow no_seek_end_llseek to actually seek | 24 February 2016, 22:00:26 UTC |
| cd8140c | Ilya Dryomov | 19 February 2016, 10:38:57 UTC | libceph: don't spam dmesg with stray reply warnings Commit d15f9d694b77 ("libceph: check data_len in ->alloc_msg()") mistakenly bumped the log level on the "tid %llu unknown, skipping" message. Turn it back into a dout() - stray replies are perfectly normal when OSDs flap, crash, get killed for testing purposes, etc. Cc: stable@vger.kernel.org # 4.3+ Signed-off-by: Ilya Dryomov <idryomov@gmail.com> Reviewed-by: Alex Elder <elder@linaro.org> | 24 February 2016, 19:28:51 UTC |
| dbc0d3c | Ilya Dryomov | 19 February 2016, 10:38:57 UTC | libceph: use the right footer size when skipping a message ceph_msg_footer is 21 bytes long, while ceph_msg_footer_old is only 13. Don't skip too much when CEPH_FEATURE_MSG_AUTH isn't negotiated. Cc: stable@vger.kernel.org # 3.19+ Signed-off-by: Ilya Dryomov <idryomov@gmail.com> Reviewed-by: Alex Elder <elder@linaro.org> | 24 February 2016, 19:28:40 UTC |
| e7a88e8 | Ilya Dryomov | 17 February 2016, 19:04:08 UTC | libceph: don't bail early from try_read() when skipping a message The contract between try_read() and try_write() is that when called each processes as much data as possible. When instructed by osd_client to skip a message, try_read() is violating this contract by returning after receiving and discarding a single message instead of checking for more. try_write() then gets a chance to write out more requests, generating more replies/skips for try_read() to handle, forcing the messenger into a starvation loop. Cc: stable@vger.kernel.org # 3.10+ Reported-by: Varada Kari <Varada.Kari@sandisk.com> Signed-off-by: Ilya Dryomov <idryomov@gmail.com> Tested-by: Varada Kari <Varada.Kari@sandisk.com> Reviewed-by: Alex Elder <elder@linaro.org> | 24 February 2016, 19:28:31 UTC |
| 2ac015e | Kirill A. Shutemov | 24 February 2016, 15:58:03 UTC | thp: call pmdp_invalidate() with correct virtual address Sebastian Ott and Gerald Schaefer reported random crashes on s390. It was bisected to my THP refcounting patchset. The problem is that pmdp_invalidated() called with wrong virtual address. It got offset up by HPAGE_PMD_SIZE by loop over ptes. The solution is to introduce new variable to be used in loop and don't touch 'haddr'. Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Reported-and-tested-by: Gerald Schaefer <gerald.schaefer@de.ibm.com> Reported-and-tested-by Sebastian Ott <sebott@linux.vnet.ibm.com> Reviewed-by: Will Deacon <will.deacon@arm.com> Cc: Christian Borntraeger <borntraeger@de.ibm.com> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Sasha Levin <sasha.levin@oracle.com> Cc: Jerome Marchand <jmarchan@redhat.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | 24 February 2016, 18:46:30 UTC |
| 6378076 | Christian König | 19 February 2016, 09:03:03 UTC | drm/amdgpu: disable direct VM updates when vm_debug is set That should make user space bugs more obvious. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> | 24 February 2016, 17:46:06 UTC |
| 827108d | Bradley Pankow | 23 February 2016, 01:11:47 UTC | amdgpu: fix NULL pointer dereference at tonga_check_states_equal The event_data passed from pem_fini was not cleared upon initialization. This caused NULL checks to pass and cast_const_phw_tonga_power_state to attempt to dereference an invalid pointer. Clear the event_data in pem_init and pem_fini before calling pem_handle_event. Reviewed-by: Rex Zhu <Rex.Zhu@amd.com> Signed-off-by: Bradley Pankow <btpankow@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> | 24 February 2016, 17:46:05 UTC |
| fd451b9 | Marc Zyngier | 17 February 2016, 10:25:05 UTC | arm64: KVM: vgic-v3: Restore ICH_APR0Rn_EL2 before ICH_APR1Rn_EL2 The GICv3 architecture spec says: Writing to the active priority registers in any order other than the following order will result in UNPREDICTABLE behavior: - ICH_AP0R<n>_EL2. - ICH_AP1R<n>_EL2. So let's not pointlessly go against the rule... Acked-by: Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> | 24 February 2016, 17:25:58 UTC |
| d045437 | Steven Rostedt (Red Hat) | 24 February 2016, 14:04:24 UTC | tracing: Fix showing function event in available_events The ftrace:function event is only displayed for parsing the function tracer data. It is not used to enable function tracing, and does not include an "enable" file in its event directory. Originally, this event was kept separate from other events because it did not have a ->reg parameter. But perf added a "reg" parameter for its use which caused issues, because it made the event available to functions where it was not compatible for. Commit 9b63776fa3ca9 "tracing: Do not enable function event with enable" added a TRACE_EVENT_FL_IGNORE_ENABLE flag that prevented the function event from being enabled by normal trace events. But this commit missed keeping the function event from being displayed by the "available_events" directory, which is used to show what events can be enabled by set_event. One documented way to enable all events is to: cat available_events > set_event But because the function event is displayed in the available_events, this now causes an INVALID error: cat: write error: Invalid argument Reported-by: Chunyu Hu <chuhu@redhat.com> Fixes: 9b63776fa3ca9 "tracing: Do not enable function event with enable" Cc: stable@vger.kernel.org # 3.4+ Signed-off-by: Steven Rostedt <rostedt@goodmis.org> | 24 February 2016, 14:17:11 UTC |
| d744479 | Christian Borntraeger | 19 February 2016, 12:11:46 UTC | KVM: async_pf: do not warn on page allocation failures In async_pf we try to allocate with NOWAIT to get an element quickly or fail. This code also handle failures gracefully. Lets silence potential page allocation failures under load. qemu-system-s39: page allocation failure: order:0,mode:0x2200000 [...] Call Trace: ([<00000000001146b8>] show_trace+0xf8/0x148) [<000000000011476a>] show_stack+0x62/0xe8 [<00000000004a36b8>] dump_stack+0x70/0x98 [<0000000000272c3a>] warn_alloc_failed+0xd2/0x148 [<000000000027709e>] __alloc_pages_nodemask+0x94e/0xb38 [<00000000002cd36a>] new_slab+0x382/0x400 [<00000000002cf7ac>] ___slab_alloc.constprop.30+0x2dc/0x378 [<00000000002d03d0>] kmem_cache_alloc+0x160/0x1d0 [<0000000000133db4>] kvm_setup_async_pf+0x6c/0x198 [<000000000013dee8>] kvm_arch_vcpu_ioctl_run+0xd48/0xd58 [<000000000012fcaa>] kvm_vcpu_ioctl+0x372/0x690 [<00000000002f66f6>] do_vfs_ioctl+0x3be/0x510 [<00000000002f68ec>] SyS_ioctl+0xa4/0xb8 [<0000000000781c5e>] system_call+0xd6/0x264 [<000003ffa24fa06a>] 0x3ffa24fa06a Cc: stable@vger.kernel.org Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: Dominik Dingel <dingel@linux.vnet.ibm.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> | 24 February 2016, 13:47:46 UTC |
| 0c1d77f | Paolo Bonzini | 19 February 2016, 17:07:21 UTC | KVM: x86: fix conversion of addresses to linear in 32-bit protected mode Commit e8dd2d2d641c ("Silence compiler warning in arch/x86/kvm/emulate.c", 2015-09-06) broke boot of the Hurd. The bug is that the "default:" case actually could modify "la", but after the patch this change is not reflected in *linear. The bug is visible whenever a non-zero segment base causes the linear address to wrap around the 4GB mark. Fixes: e8dd2d2d641cb2724ee10e76c0ad02e04289c017 Cc: stable@vger.kernel.org Reported-by: Aurelien Jarno <aurelien@aurel32.net> Tested-by: Aurelien Jarno <aurelien@aurel32.net> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> | 24 February 2016, 13:47:45 UTC |
| 172b238 | Paolo Bonzini | 10 February 2016, 16:50:23 UTC | KVM: x86: fix missed hardware breakpoints Sometimes when setting a breakpoint a process doesn't stop on it. This is because the debug registers are not loaded correctly on VCPU load. The following simple reproducer from Oleg Nesterov tries using debug registers in two threads. To see the bug, run a 2-VCPU guest with "taskset -c 0" and run "./bp 0 1" inside the guest. #include <unistd.h> #include <signal.h> #include <stdlib.h> #include <stdio.h> #include <sys/wait.h> #include <sys/ptrace.h> #include <sys/user.h> #include <asm/debugreg.h> #include <assert.h> #define offsetof(TYPE, MEMBER) ((size_t) &((TYPE *)0)->MEMBER) unsigned long encode_dr7(int drnum, int enable, unsigned int type, unsigned int len) { unsigned long dr7; dr7 = ((len | type) & 0xf) << (DR_CONTROL_SHIFT + drnum * DR_CONTROL_SIZE); if (enable) dr7 |= (DR_GLOBAL_ENABLE << (drnum * DR_ENABLE_SIZE)); return dr7; } int write_dr(int pid, int dr, unsigned long val) { return ptrace(PTRACE_POKEUSER, pid, offsetof (struct user, u_debugreg[dr]), val); } void set_bp(pid_t pid, void *addr) { unsigned long dr7; assert(write_dr(pid, 0, (long)addr) == 0); dr7 = encode_dr7(0, 1, DR_RW_EXECUTE, DR_LEN_1); assert(write_dr(pid, 7, dr7) == 0); } void *get_rip(int pid) { return (void*)ptrace(PTRACE_PEEKUSER, pid, offsetof(struct user, regs.rip), 0); } void test(int nr) { void *bp_addr = &&label + nr, *bp_hit; int pid; printf("test bp %d\n", nr); assert(nr < 16); // see 16 asm nops below pid = fork(); if (!pid) { assert(ptrace(PTRACE_TRACEME, 0,0,0) == 0); kill(getpid(), SIGSTOP); for (;;) { label: asm ( "nop; nop; nop; nop;" "nop; nop; nop; nop;" "nop; nop; nop; nop;" "nop; nop; nop; nop;" ); } } assert(pid == wait(NULL)); set_bp(pid, bp_addr); for (;;) { assert(ptrace(PTRACE_CONT, pid, 0, 0) == 0); assert(pid == wait(NULL)); bp_hit = get_rip(pid); if (bp_hit != bp_addr) fprintf(stderr, "ERR!! hit wrong bp %ld != %d\n", bp_hit - &&label, nr); } } int main(int argc, const char *argv[]) { while (--argc) { int nr = atoi(*++argv); if (!fork()) test(nr); } while (wait(NULL) > 0) ; return 0; } Cc: stable@vger.kernel.org Suggested-by: Nadav Amit <namit@cs.technion.ac.il> Reported-by: Andrey Wagin <avagin@gmail.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> | 24 February 2016, 13:47:39 UTC |
| e249714 | Rafael J. Wysocki | 24 February 2016, 12:55:38 UTC | Revert "ACPI, PCI, irq: remove interrupt count restriction" Revert commit b5bd02695471 (ACPI, PCI, irq: remove interrupt count restriction) that introduced a boot regression on some systems where it caused kmalloc() to be used too early. Link: http://marc.info/?l=linux-acpi&m=145580159209240&w=2 Reported-by: Nalla, Ravikanth <ravikanth.nalla@hpe.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> | 24 February 2016, 12:55:38 UTC |
| 5ec5d10 | Rafael J. Wysocki | 24 February 2016, 12:53:46 UTC | Revert "ACPI / PCI: Simplify acpi_penalize_isa_irq()" Revert commit 0971686954f9 "ACPI / PCI: Simplify acpi_penalize_isa_irq()" that depends on commit b5bd02695471 (ACPI, PCI, irq: remove interrupt count restriction) which introduced a regression and needs to be reverted for this reason. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> | 24 February 2016, 12:53:46 UTC |
| 1d6a821 | Marc Zyngier | 15 February 2016, 17:04:04 UTC | arm/arm64: KVM: Feed initialized memory to MMIO accesses On an MMIO access, we always copy the on-stack buffer info the shared "run" structure, even if this is a read access. This ends up leaking up to 8 bytes of uninitialized memory into userspace, depending on the size of the access. An obvious fix for this one is to only perform the copy if this is an actual write. Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> | 24 February 2016, 11:53:09 UTC |
| 9ef2d8b | Valentin Rothberg | 24 February 2016, 08:40:22 UTC | arc: SMP: CONFIG_ARC_IPI_DBG cleanup Previous Commit ("ARC: SMP: No need for CONFIG_ARC_IPI_DBG") removed the Kconfig option ARC_IPI_DBG. Remove the last reference on this option. Signed-off-by: Valentin Rothberg <valentinrothberg@gmail.com> Signed-off-by: Vineet Gupta <vgupta@synopsys.com> | 24 February 2016, 08:45:39 UTC |
| d73b73f | Vineet Gupta | 19 February 2016, 02:48:11 UTC | ARC: SMP: No need for CONFIG_ARC_IPI_DBG This was more relevant during SMP bringup. The warning for bogus msg better be visible always. Signed-off-by: Vineet Gupta <vgupta@synopsys.com> | 24 February 2016, 05:37:32 UTC |
| 3dea30c | Vineet Gupta | 19 February 2016, 02:27:41 UTC | ARCv2: Elide sending new cross core intr if receiver didn't ack prev ARConnect/MCIP IPI sending has a retry-wait loop in case caller had not seen a previous such interrupt. Turns out that it is not needed at all. Linux cross core calling allows coalescing multiple IPIs to same receiver - it is fine as long as there is one. This logic is built into upper layer already, at a higher level of abstraction. ipi_send_msg_one() sets the actual msg payload, but it only calls MCIP IPI sending if msg holder was empty (using atomic-set-new-and-get-old construct). Thus it is unlikely that the retry-wait looping was ever getting exercised at all. Cc: Chuck Jordan <cjordan@synopsys.com> Cc: Peter Zijlstra <peterz@infradead.org> Signed-off-by: Vineet Gupta <vgupta@synopsys.com> | 24 February 2016, 05:37:31 UTC |
| 9681787 | Vineet Gupta | 23 February 2016, 08:05:12 UTC | ARCv2: SMP: Push IPI_IRQ into IPI provider Signed-off-by: Vineet Gupta <vgupta@synopsys.com> | 24 February 2016, 05:37:31 UTC |
| dbcbc7e | Vineet Gupta | 28 January 2016, 07:18:05 UTC | ARC: [intc-compact] Remove IPI setup from ARCompact port There is no real ARC700 based SMP SoC so remove IPI definition. EZChip's SMP ARC700 is going to use a different intc and IPI provider anyways. Signed-off-by: Vineet Gupta <vgupta@synopsys.com> | 24 February 2016, 05:37:31 UTC |
| bb143f8 | Vineet Gupta | 23 February 2016, 06:25:16 UTC | ARCv2: SMP: Emulate IPI to self using software triggered interrupt ARConnect/MCIP Inter-Core-Interrupt module can't send interrupt to local core. So use core intc capability to trigger software interrupt to self, using an unsued IRQ #21. This showed up as csd deadlock with LTP trace_sched on a dual core system. This test acts as scheduler fuzzer, triggering all sorts of schedulting activity. Trouble starts with IPI to self, which doesn't get delivered (effectively lost due to H/w capability), but the msg intended to be sent remain enqueued in per-cpu @ipi_data. All subsequent IPIs to this core from other cores get elided due to the IPI coalescing optimization in ipi_send_msg_one() where a pending msg implies an IPI already sent and assumes other core is yet to ack it. After the elided IPI, other core simply goes into csd_lock_wait() but never comes out as this core never sees the interrupt. Fixes STAR 9001008624 Cc: Peter Zijlstra <peterz@infradead.org> Cc: <stable@vger.kernel.org> [4.2] Signed-off-by: Vineet Gupta <vgupta@synopsys.com> | 24 February 2016, 05:37:28 UTC |
| 84e54c4 | Linus Torvalds | 24 February 2016, 03:03:43 UTC | Merge tag 'dm-4.5-fix' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm Pull device mapper fix from Mike Snitzer: "Fix a 112 byte leak for each IO request that is requeued while DM multipath is handling faults due to path failures. This leak does not happen if blk-mq DM multipath is used. It only occurs if .request_fn DM multipath is stacked ontop of blk-mq paths (e.g. scsi-mq devices)" * tag 'dm-4.5-fix' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm: dm: fix dm_rq_target_io leak on faults with .request_fn DM w/ blk-mq paths | 24 February 2016, 03:03:43 UTC |
| 0ecdcd3 | Linus Torvalds | 24 February 2016, 02:54:58 UTC | Merge tag 'mmc-v4.5-rc4' of git://git.linaro.org/people/ulf.hansson/mmc Pull MMC fix from Ulf Hansson: "Here's an mmc fix intended for v4.5 rc6. MMC host: - omap_hsmmc: Fix PM regression for deferred probe" * tag 'mmc-v4.5-rc4' of git://git.linaro.org/people/ulf.hansson/mmc: mmc: omap_hsmmc: Fix PM regression with deferred probe for pm_runtime_reinit | 24 February 2016, 02:54:58 UTC |
| c454420 | Arnd Bergmann | 22 February 2016, 21:58:34 UTC | nvdimm: use 'u64' for pfn flags A recent bugfix changed pfn_t to always be 64-bit wide, but did not change the code in pmem.c, which is now broken on 32-bit architectures as reported by gcc: In file included from ../drivers/nvdimm/pmem.c:28:0: drivers/nvdimm/pmem.c: In function 'pmem_alloc': include/linux/pfn_t.h:15:17: error: large integer implicitly truncated to unsigned type [-Werror=overflow] #define PFN_DEV (1ULL << (BITS_PER_LONG_LONG - 3)) This changes the intermediate pfn_flags in struct pmem_device to be 64 bit wide as well, so they can store the flags correctly. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: db78c22230d0 ("mm: fix pfn_t vs highmem") Signed-off-by: Dan Williams <dan.j.williams@intel.com> | 24 February 2016, 01:17:20 UTC |
| 93f834d | Toshi Kani | 20 February 2016, 22:32:24 UTC | devm_memremap: Fix error value when memremap failed devm_memremap() returns an ERR_PTR() value in case of error. However, it returns NULL when memremap() failed. This causes the caller, such as the pmem driver, to proceed and oops later. Change devm_memremap() to return ERR_PTR(-ENXIO) when memremap() failed. Signed-off-by: Toshi Kani <toshi.kani@hpe.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: <stable@vger.kernel.org> Reviewed-by: Ross Zwisler <ross.zwisler@linux.intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> | 24 February 2016, 01:17:20 UTC |
| 4577b06 | Dan Williams | 17 February 2016, 21:08:58 UTC | nfit: update address range scrub commands to the acpi 6.1 format The original format of these commands from the "NVDIMM DSM Interface Example" [1] are superseded by the ACPI 6.1 definition of the "NVDIMM Root Device _DSMs" [2]. [1]: http://pmem.io/documents/NVDIMM_DSM_Interface_Example.pdf [2]: http://www.uefi.org/sites/default/files/resources/ACPI_6_1.pdf "9.20.7 NVDIMM Root Device _DSMs" Changes include: 1/ New 'restart' fields in ars_status, unfortunately these are implemented in the middle of the existing definition so this change is not backwards compatible. The expectation is that shipping platforms will only ever support the ACPI 6.1 definition. 2/ New status values for ars_start ('busy') and ars_status ('overflow'). Cc: Vishal Verma <vishal.l.verma@intel.com> Cc: Linda Knippers <linda.knippers@hpe.com> Cc: <stable@vger.kernel.org> Signed-off-by: Dan Williams <dan.j.williams@intel.com> | 24 February 2016, 01:17:20 UTC |
| 351228e | Rafael J. Wysocki | 24 February 2016, 01:13:43 UTC | Merge branch 'for-rafael' of https://git.kernel.org/pub/scm/linux/kernel/git/mzx/devfreq into pm-devfreq Pull a devfreq fix for v4.5 from MyungJoo Ham. * 'for-rafael' of https://git.kernel.org/pub/scm/linux/kernel/git/mzx/devfreq: PM / devfreq: tegra: Set freq in rate callback | 24 February 2016, 01:13:43 UTC |
| 420eb6d | Linus Torvalds | 24 February 2016, 00:39:21 UTC | Merge tag 'nfs-for-4.5-4' of git://git.linux-nfs.org/projects/trondmy/linux-nfs Pull NFS client bugfixes from Trond Myklebust: "Stable bugfixes: - Fix nfs_size_to_loff_t - NFSv4: Fix a dentry leak on alias use Other bugfixes: - Don't schedule a layoutreturn if the layout segment can be freed immediately. - Always set NFS_LAYOUT_RETURN_REQUESTED with lo->plh_return_iomode - rpcrdma_bc_receive_call() should init rq_private_buf.len - fix stateid handling for the NFS v4.2 operations - pnfs/blocklayout: fix a memeory leak when using,vmalloc_to_page - fix panic in gss_pipe_downcall() in fips mode - Fix a race between layoutget and pnfs_destroy_layout - Fix a race between layoutget and bulk recalls" * tag 'nfs-for-4.5-4' of git://git.linux-nfs.org/projects/trondmy/linux-nfs: NFSv4.x/pnfs: Fix a race between layoutget and bulk recalls NFSv4.x/pnfs: Fix a race between layoutget and pnfs_destroy_layout auth_gss: fix panic in gss_pipe_downcall() in fips mode pnfs/blocklayout: fix a memeory leak when using,vmalloc_to_page nfs4: fix stateid handling for the NFS v4.2 operations NFSv4: Fix a dentry leak on alias use xprtrdma: rpcrdma_bc_receive_call() should init rq_private_buf.len pNFS: Always set NFS_LAYOUT_RETURN_REQUESTED with lo->plh_return_iomode pNFS: Fix pnfs_mark_matching_lsegs_return() nfs: fix nfs_size_to_loff_t | 24 February 2016, 00:39:21 UTC |
| de9e478 | Linus Torvalds | 23 February 2016, 22:58:52 UTC | x86: fix SMAP in 32-bit environments In commit 11f1a4b9755f ("x86: reorganize SMAP handling in user space accesses") I changed how the stac/clac instructions were generated around the user space accesses, which then made it possible to do batched accesses efficiently for user string copies etc. However, in doing so, I completely spaced out, and didn't even think about the 32-bit case. And nobody really even seemed to notice, because SMAP doesn't even exist until modern Skylake processors, and you'd have to be crazy to run 32-bit kernels on a modern CPU. Which brings us to Andy Lutomirski. He actually tested the 32-bit kernel on new hardware, and noticed that it doesn't work. My bad. The trivial fix is to add the required uaccess begin/end markers around the raw accesses in <asm/uaccess_32.h>. I feel a bit bad about this patch, just because that header file really should be cleaned up to avoid all the duplicated code in it, and this commit just expands on the problem. But this just fixes the bug without any bigger cleanup surgery. Reported-and-tested-by: Andy Lutomirski <luto@kernel.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | 24 February 2016, 00:25:20 UTC |
| 236cf17 | Mark Rutland | 16 February 2016, 14:47:31 UTC | KVM: arm/arm64: vgic: Ensure bitmaps are long enough When we allocate bitmaps in vgic_vcpu_init_maps, we divide the number of bits we need by 8 to figure out how many bytes to allocate. However, bitmap elements are always accessed as unsigned longs, and if we didn't happen to allocate a size such that size % sizeof(unsigned long) == 0, bitmap accesses may go past the end of the allocation. When using KASAN (which does byte-granular access checks), this results in a continuous stream of BUGs whenever these bitmaps are accessed: ============================================================================= BUG kmalloc-128 (Tainted: G B ): kasan: bad access detected ----------------------------------------------------------------------------- INFO: Allocated in vgic_init.part.25+0x55c/0x990 age=7493 cpu=3 pid=1730 INFO: Slab 0xffffffbde6d5da40 objects=16 used=15 fp=0xffffffc935769700 flags=0x4000000000000080 INFO: Object 0xffffffc935769500 @offset=1280 fp=0x (null) Bytes b4 ffffffc9357694f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffffffc935769500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffffffc935769510: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffffffc935769520: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffffffc935769530: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffffffc935769540: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffffffc935769550: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffffffc935769560: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffffffc935769570: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Padding ffffffc9357695b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Padding ffffffc9357695c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Padding ffffffc9357695d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Padding ffffffc9357695e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Padding ffffffc9357695f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ CPU: 3 PID: 1740 Comm: kvm-vcpu-0 Tainted: G B 4.4.0+ #17 Hardware name: ARM Juno development board (r1) (DT) Call trace: [<ffffffc00008e770>] dump_backtrace+0x0/0x280 [<ffffffc00008ea04>] show_stack+0x14/0x20 [<ffffffc000726360>] dump_stack+0x100/0x188 [<ffffffc00030d324>] print_trailer+0xfc/0x168 [<ffffffc000312294>] object_err+0x3c/0x50 [<ffffffc0003140fc>] kasan_report_error+0x244/0x558 [<ffffffc000314548>] __asan_report_load8_noabort+0x48/0x50 [<ffffffc000745688>] __bitmap_or+0xc0/0xc8 [<ffffffc0000d9e44>] kvm_vgic_flush_hwstate+0x1bc/0x650 [<ffffffc0000c514c>] kvm_arch_vcpu_ioctl_run+0x2ec/0xa60 [<ffffffc0000b9a6c>] kvm_vcpu_ioctl+0x474/0xa68 [<ffffffc00036b7b0>] do_vfs_ioctl+0x5b8/0xcb0 [<ffffffc00036bf34>] SyS_ioctl+0x8c/0xa0 [<ffffffc000086cb0>] el0_svc_naked+0x24/0x28 Memory state around the buggy address: ffffffc935769400: 00 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffffffc935769480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffffffc935769500: 04 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffffffc935769580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffffffc935769600: 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc fc ================================================================== Fix the issue by always allocating a multiple of sizeof(unsigned long), as we do elsewhere in the vgic code. Fixes: c1bfb577a ("arm/arm64: KVM: vgic: switch to dynamic allocation") Cc: stable@vger.kernel.org Acked-by: Marc Zyngier <marc.zyngier@arm.com> Acked-by: Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> | 23 February 2016, 19:02:48 UTC |
| b7052cd | Stefan Hajnoczi | 18 February 2016, 18:55:54 UTC | sunrpc/cache: fix off-by-one in qword_get() The qword_get() function NUL-terminates its output buffer. If the input string is in hex format \xXXXX... and the same length as the output buffer, there is an off-by-one: int qword_get(char **bpp, char *dest, int bufsize) { ... while (len < bufsize) { ... *dest++ = (h << 4) | l; len++; } ... *dest = '\0'; return len; } This patch ensures the NUL terminator doesn't fall outside the output buffer. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: J. Bruce Fields <bfields@redhat.com> | 23 February 2016, 18:20:16 UTC |
| 3e5177c | Alexey Brodkin | 20 February 2016, 13:04:26 UTC | arc: get rid of DEVTMPFS dependency on INITRAMFS_SOURCE Even though DEVTMPFS is required when our pre-built initramfs is used it is not the case in general. It is perfectly possible to use initramfs with device nodes already populated or there could be other usages, see discussion below for more detials: http://thread.gmane.org/gmane.comp.embedded.openwrt.devel/37819/focus=37821 This change removes mentioned dependency from arch/arc/Kconfig updating instead those defconfigs that are usually used with this kind of pre-build initramfs. And while at it all touched defconfigs were regenerated via savedefconfig and some options were removed: * USB is selected by other options implicitly * VGA_CONSOLE is disableb for ARC since 031e29b5877f31676739dc2f847d04c2c0732034 * EXT3_FS automatically selects EXT4_FS * MTDxxx and JFFS2_FS make no sense for AXS because AXS NAND controller is not upstreamed * NET_OSCI_LAN is not in upstream as well * ARCPGU_xxx options make no sense because ARC PGU is not yet in upstream and when it gets there all config options would be taken from devicetree Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Signed-off-by: Vineet Gupta <vgupta@synopsys.com> | 23 February 2016, 07:01:04 UTC |
| dbb0c7c | Tomeu Vizoso | 21 January 2016, 07:52:26 UTC | PM / devfreq: tegra: Set freq in rate callback As per the documentation of the devfreq_dev_profile.target callback, set the freq argument to the new frequency before returning. This caused endless messages like this after recent changes in the core: devfreq 6000c800.actmon: Couldn't update frequency transition information. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Reported-by: Tyler Baker <tyler.baker@linaro.org> Tested-by: Thierry Reding <treding@nvidia.com> Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com> | 23 February 2016, 05:27:42 UTC |
| 9fd4b9f | Trond Myklebust | 22 February 2016, 22:46:34 UTC | NFSv4.x/pnfs: Fix a race between layoutget and bulk recalls Replace another case where the layout 'plh_block_lgets' can trigger infinite loops in send_layoutget(). Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com> | 22 February 2016, 22:46:34 UTC |
| 2454dfe | Trond Myklebust | 22 February 2016, 22:34:59 UTC | NFSv4.x/pnfs: Fix a race between layoutget and pnfs_destroy_layout If the server reboots while there is a layoutget outstanding, then the call to pnfs_choose_layoutget_stateid() will fail with an EAGAIN error, which causes an infinite loop in send_layoutget(). The reason why we never break out of the loop is that the layout 'plh_block_lgets' field is never cleared. Fix is to replace plh_block_lgets with NFS_LAYOUT_INVALID_STID, which can be reset after a new layoutget. Fixes: ab7d763e477c5 ("pNFS: Ensure nfs4_layoutget_prepare returns...") Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com> | 22 February 2016, 22:34:59 UTC |
| 4de8ebe | Linus Torvalds | 22 February 2016, 22:09:18 UTC | Merge tag 'trace-fixes-v4.5-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace Pull tracing fixes from Steven Rostedt: "Two more small fixes. One is by Yang Shi who added a READ_ONCE_NOCHECK() to the scan of the stack made by the stack tracer. As the stack tracer scans the entire kernel stack, KASAN triggers seeing it as a "stack out of bounds" error. As the scan is looking at the contents of the stack from parent functions. The NOCHECK() tells KASAN that this is done on purpose, and is not some kind of stack overflow. The second fix is to the ftrace selftests, to retrieve the PID of executed commands from the shell with '$!' and not by parsing 'jobs'" * tag 'trace-fixes-v4.5-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace: tracing, kasan: Silence Kasan warning in check_stack of stack_tracer ftracetest: Fix instance test to use proper shell command for pids | 22 February 2016, 22:09:18 UTC |
| 692b8c6 | Linus Torvalds | 22 February 2016, 21:57:01 UTC | Merge tag 'for-linus-4.5-rc5-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip Pull xen bug fixes from David Vrabel: - Two scsiback fixes (resource leak and spurious warning). - Fix DMA mapping of compound pages on arm/arm64. - Fix some pciback regressions in MSI-X handling. - Fix a pcifront crash due to some uninitialize state. * tag 'for-linus-4.5-rc5-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip: xen/pcifront: Fix mysterious crashes when NUMA locality information was extracted. xen/pcifront: Report the errors better. xen/pciback: Save the number of MSI-X entries to be copied later. xen/pciback: Check PF instead of VF for PCI_COMMAND_MEMORY xen: fix potential integer overflow in queue_reply xen/arm: correctly handle DMA mapping of compound pages xen/scsiback: avoid warnings when adding multiple LUNs to a domain xen/scsiback: correct frontend counting | 22 February 2016, 21:57:01 UTC |
| dea08e6 | Linus Torvalds | 22 February 2016, 20:18:07 UTC | Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net Pull networking fixes from David Miller: "Looks like a lot, but mostly driver fixes scattered all over as usual. Of note: 1) Add conditional sched in nf conntrack in cleanup to avoid NMI watchdogs. From Florian Westphal. 2) Fix deadlock in nfnetlink cttimeout, also from Floarian. 3) Fix handling of slaves in bonding ARP monitor validation, from Jay Vosburgh. 4) Callers of ip_cmsg_send() are responsible for freeing IP options, some were not doing so. Fix from Eric Dumazet. 5) Fix per-cpu bugs in mvneta driver, from Gregory CLEMENT. 6) Fix vlan handling in mv88e6xxx DSA driver, from Vivien Didelot. 7) bcm7xxx PHY driver bug fixes from Florian Fainelli. 8) Avoid unaligned accesses to protocol headers wrt. GRE, from Alexander Duyck. 9) SKB leaks and other problems in arc_emac driver, from Alexander Kochetkov. 10) tcp_v4_inbound_md5_hash() releases listener socket instead of request socket on error path, oops. Fix from Eric Dumazet. 11) Missing socket release in pppoe_rcv_core() that seems to have existed basically forever. From Guillaume Nault. 12) Missing slave_dev unregister in dsa_slave_create() error path, from Florian Fainelli. 13) crypto_alloc_hash() never returns NULL, fix return value check in __tcp_alloc_md5sig_pool. From Insu Yun. 14) Properly expire exception route entries in ipv4, from Xin Long. 15) Fix races in tcp/dccp listener socket dismantle, from Eric Dumazet. 16) Don't set IFF_TX_SKB_SHARING in vxlan, geneve, or GRE, it's not legal. These drivers modify the SKB on transmit. From Jiri Benc. 17) Fix regression in the initialziation of netdev->tx_queue_len. From Phil Sutter. 18) Missing unlock in tipc_nl_add_bc_link() error path, from Insu Yun. 19) SCTP port hash sizing does not properly ensure that table is a power of two in size. From Neil Horman. 20) Fix initializing of software copy of MAC address in fmvj18x_cs driver, from Ken Kawasaki" * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (129 commits) bnx2x: Fix 84833 phy command handler bnx2x: Fix led setting for 84858 phy. bnx2x: Correct 84858 PHY fw version bnx2x: Fix 84833 RX CRC bnx2x: Fix link-forcing for KR2 net: ethernet: davicom: fix devicetree irq resource fmvj18x_cs: fix incorrect indexing of dev->dev_addr[] when copying the MAC address Driver: Vmxnet3: Update Rx ring 2 max size net: netcp: rework the code for get/set sw_data in dma desc soc: ti: knav_dma: rename pad in struct knav_dma_desc to sw_data net: ti: netcp: restore get/set_pad_info() functionality MAINTAINERS: Drop myself as xen netback maintainer sctp: Fix port hash table size computation can: ems_usb: Fix possible tx overflow Bluetooth: hci_core: Avoid mixing up req_complete and req_complete_skb net: bcmgenet: Fix internal PHY link state af_unix: Don't use continue to re-execute unix_stream_read_generic loop unix_diag: fix incorrect sign extension in unix_lookup_by_ino bnxt_en: Failure to update PHY is not fatal condition. bnxt_en: Remove unnecessary call to update PHY settings. ... | 22 February 2016, 20:18:07 UTC |
| 5c102d0 | Linus Torvalds | 22 February 2016, 20:12:46 UTC | Merge tag 'hwmon-for-linus-v4.5-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging Pull hwmon fixes from Guenter Roeck: "Two fixes headed for stable: - Remove an unnecessary speed_index lookup for thermal hook in the gpio-fan driver. The unnecessary speed lookup can hog the system. - Handle negative conversion values correctly in the ads1015 driver" * tag 'hwmon-for-linus-v4.5-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging: hwmon: (gpio-fan) Remove un-necessary speed_index lookup for thermal hook hwmon: (ads1015) Handle negative conversion values correctly | 22 February 2016, 20:12:46 UTC |
| a16152c | Linus Torvalds | 22 February 2016, 20:04:11 UTC | Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma Pull rdma fixes from Doug Ledford: "One ocrdma fix: - The new CQ API support was added to ocrdma, but they got the arming logic wrong, so without this, transfers eventually fail when they fail to arm the interrupt properly under load Two related fixes for mlx4: - When we added the 64bit extended counters support to the core IB code, they forgot to update the RoCE side of the mlx4 driver (the IB side they properly updated). I debated whether or not to include these patches as they could be considered feature enablement patches, but the existing code will blindy copy the 32bit counters, whether any counters were requested at all (a bug). These two patches make it (a) check to see that counters were requested and (b) copy the right counters (the 64bit support is new, the 32bit is not). For that reason I went ahead and took them" * tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma: IB/mlx4: Add support for the port info class for RoCE ports IB/mlx4: Add support for extended counters over RoCE ports RDMA/ocrdma: Fix arm logic to align with new cq API | 22 February 2016, 20:04:11 UTC |
| 7ee302f | Linus Torvalds | 22 February 2016, 19:55:18 UTC | Merge branch 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux Pull i2c fixes from Wolfram Sang: "Some bugfixes from I2C for you: A fix for a RuntimePM regression with OMAP, a fix to enable TCO for Lewisburg platforms, and a typo fix while we are here" * 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: i2c: i801: Adding Intel Lewisburg support for iTCO i2c: uniphier: fix typos in error messages i2c: omap: Fix PM regression with deferred probe for pm_runtime_reinit | 22 February 2016, 19:55:18 UTC |
| 9b18572 | Mika Kuoppala | 18 February 2016, 15:58:09 UTC | drm/i915/gen9: Verify and enforce dc6 state writes It has been observed that sometimes disabling the dc6 fails and dc6 state pops back up, brief moment after disabling. This has to be dmc save/restore timing issue or other bug in the way dc states are handled. Try to work around this issue as we don't have firmware fix yet available. Verify that the value we wrote for the dmc sticks, and also enforce it by rewriting it, if it didn't. v2: Zero rereads on rewrite for extra paranoia (Imre) Testcase: kms_flip/basic-flip-vs-dpms References: https://bugs.freedesktop.org/show_bug.cgi?id=93768 Cc: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455811089-27884-1-git-send-email-mika.kuoppala@intel.com (cherry picked from commit 779cb5d3ddd72950ec726f86e38f7575c7fbdd4c) Signed-off-by: Jani Nikula <jani.nikula@intel.com> | 22 February 2016, 16:37:43 UTC |
| 9b6f209 | Patrik Jakobsson | 18 February 2016, 15:21:11 UTC | drm/i915/gen9: Check for DC state mismatch The DMC can incorrectly run off and allow DC states on it's own. We don't know the root-cause for this yet but this patch makes it more visible. Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455808874-22089-2-git-send-email-mika.kuoppala@intel.com (cherry picked from commit 832dba889e27487c3087149f1039acc3feb89003) Signed-off-by: Jani Nikula <jani.nikula@intel.com> | 22 February 2016, 16:37:25 UTC |
| 39d4275 | Alex Deucher | 19 February 2016, 23:05:10 UTC | drm/radeon/pm: adjust display configuration after powerstate set_power_state defaults to no displays, so we need to update the display configuration after setting up the powerstate on the first call. In most cases this is not an issue since ends up getting called multiple times at any given modeset and the proper order is achieved in the display changed handling at the top of the function. Reviewed-by: Christian König <christian.koenig@amd.com> Acked-by: Jordan Lazare <Jordan.Lazare@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org | 22 February 2016, 16:31:09 UTC |
| 8e7cedc | Alex Deucher | 19 February 2016, 22:55:31 UTC | drm/amdgpu/pm: adjust display configuration after powerstate set_power_state defaults to no displays, so we need to update the display configuration after setting up the powerstate on the first call. In most cases this is not an issue since ends up getting called multiple times at any given modeset and the proper order is achieved in the display changed handling at the top of the function. Reviewed-by: Christian König <christian.koenig@amd.com> Acked-by: Jordan Lazare <Jordan.Lazare@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org | 22 February 2016, 16:31:02 UTC |
| 0c67df4 | Alex Deucher | 19 February 2016, 20:30:15 UTC | drm/amdgpu/pm: add some checks for PX I.e., doesn't make sense to change power states or check the temperature when the asic is powered off. Reviewed-by: Christian König <christian.koenig@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> | 22 February 2016, 16:30:56 UTC |
| 10f950f | Alex Deucher | 19 February 2016, 20:18:45 UTC | drm/amdgpu: fix locking in force performance level Looks like a copy paste typo when we added powerplay support. Reviewed-by: Christian König <christian.koenig@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> | 22 February 2016, 16:30:50 UTC |
| 04ab3b7 | Alex Deucher | 18 February 2016, 16:10:09 UTC | drm/amdgpu/gfx8: fix priv reg interrupt enable Looks like a copy/paste typo. Reviewed-by: Christian König <christian.koenig@amd.com> Noticed-by: David Panariti <David.Panariti@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> | 22 February 2016, 16:30:35 UTC |
| 7e31a01 | Takashi Iwai | 22 February 2016, 14:18:13 UTC | ALSA: hda - Apply clock gate workaround to Skylake, too Some Skylake machines show the codec probe errors in certain situations, e.g. HP Z240 desktop fails to probe the onboard Realtek codec at reloading the snd-hda-intel module like: snd_hda_intel 0000:00:1f.3: spurious response 0x200:0x2, last cmd=0x000000 snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to polling mode: lastcmd=0x000f0000 snd_hda_intel 0000:00:1f.3: No response from codec, disabling MSI: last cmd=0x000f0000 snd_hda_intel 0000:00:1f.3: Codec #0 probe error; disabling it... hdaudio hdaudioC0D2: no AFG or MFG node found snd_hda_intel 0000:00:1f.3: no codecs initialized Also, HP G470 G3 suffers from the similar problem, as reported in bugzilla below. On this machine, the codec probe error appears even at a fresh boot. As Libin suggested, the same workaround used for Broxton in the commit [6639484ddaf6: ALSA: hda - disable dynamic clock gating on Broxton before reset] can be applied for Skylake in order to fix this problem. The Intel HW team also confirmed that this is needed for SKL. This patch makes the workaround applied to both SKL and BXT platforms. The referred macros are moved and one superfluous macro (IS_BROXTON()) is another one (IS_BXT()) as well. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=112731 Suggested-by: Libin Yang <libin.yang@linux.intel.com> Cc: <stable@vger.kernel.org> # v4.4+ Signed-off-by: Takashi Iwai <tiwai@suse.de> | 22 February 2016, 16:13:48 UTC |
| 53188eb | Imre Deak | 16 February 2016, 16:56:46 UTC | drm/i915/skl: Ensure HW is powered during DDB HW state readout The assumption when adding the intel_display_power_is_enabled() checks was that if it returns success the power can't be turned off afterwards during the HW access, which is guaranteed by modeset locks. This isn't always true, so make sure we hold a dedicated reference for the time of the access. Spotted-by: Mika Kuoppala <mika.kuoppala@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93441 CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455719489-3008-1-git-send-email-imre.deak@intel.com (cherry picked from commit 4d800030238878c1a98d1d3a37a3d673eea661ce) Signed-off-by: Jani Nikula <jani.nikula@intel.com> | 22 February 2016, 15:44:40 UTC |
| 380bdff | Imre Deak | 12 February 2016, 16:55:21 UTC | drm/i915/lvds: Ensure the HW is powered during HW state readout The assumption when adding the intel_display_power_is_enabled() checks was that if it returns success the power can't be turned off afterwards during the HW access, which is guaranteed by modeset locks. This isn't always true, so make sure we hold a dedicated reference for the time of the access. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-13-git-send-email-imre.deak@intel.com (cherry picked from commit ecb2448218acf23c401434c26be256147833b221) Signed-off-by: Jani Nikula <jani.nikula@intel.com> | 22 February 2016, 15:44:40 UTC |
| 31feb61 | Imre Deak | 12 February 2016, 16:55:20 UTC | drm/i915/hdmi: Ensure the HW is powered during HW state readout The assumption when adding the intel_display_power_is_enabled() checks was that if it returns success the power can't be turned off afterwards during the HW access, which is guaranteed by modeset locks. This isn't always true, so make sure we hold a dedicated reference for the time of the access. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-12-git-send-email-imre.deak@intel.com (cherry picked from commit 5b0921748c0b1d0362bbfa802dc25a5c23de7e76) Signed-off-by: Jani Nikula <jani.nikula@intel.com> | 22 February 2016, 15:44:39 UTC |
| fe97fd7 | Imre Deak | 12 February 2016, 16:55:19 UTC | drm/i915/dsi: Ensure the HW is powered during HW state readout The assumption when adding the intel_display_power_is_enabled() checks was that if it returns success the power can't be turned off afterwards during the HW access, which is guaranteed by modeset locks. This isn't always true, so make sure we hold a dedicated reference for the time of the access. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-11-git-send-email-imre.deak@intel.com (cherry picked from commit 3f3f42b887fbffc3353e44ef9f32456c19ae4280) Signed-off-by: Jani Nikula <jani.nikula@intel.com> | 22 February 2016, 15:44:39 UTC |
| b81b801 | Imre Deak | 12 February 2016, 16:55:18 UTC | drm/i915/dp: Ensure the HW is powered during HW state readout The assumption when adding the intel_display_power_is_enabled() checks was that if it returns success the power can't be turned off afterwards during the HW access, which is guaranteed by modeset locks. This isn't always true, so make sure we hold a dedicated reference for the time of the access. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-10-git-send-email-imre.deak@intel.com (cherry picked from commit 6fa9a5ecf7a54450b255229ac1fc6df276cf0653) Signed-off-by: Jani Nikula <jani.nikula@intel.com> | 22 February 2016, 15:44:38 UTC |
| 02f9f5e | Imre Deak | 12 February 2016, 16:55:17 UTC | drm/i915: Ensure the HW is powered when accessing the CRC HW block The assumption when adding the intel_display_power_is_enabled() checks was that if it returns success the power can't be turned off afterwards during the HW access, which is guaranteed by modeset locks. This isn't always true, so make sure we hold a dedicated reference for the time of the access. While at it also add the missing reference around the HW access in i915_interrupt_info(). v2: - update the commit message mentioning that this also fixes the HW access in the interrupt info debugfs entry (Daniel) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-9-git-send-email-imre.deak@intel.com (cherry picked from commit e129649b7a3e1d50d196e159492496777769437e) Signed-off-by: Jani Nikula <jani.nikula@intel.com> | 22 February 2016, 15:44:38 UTC |
| d594102 | Imre Deak | 12 February 2016, 16:55:16 UTC | drm/i915/ddi: Ensure the HW is powered during HW state readout The assumption when adding the intel_display_power_is_enabled() checks was that if it returns success the power can't be turned off afterwards during the HW access, which is guaranteed by modeset locks. This isn't always true, so make sure we hold a dedicated reference for the time of the access. CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-8-git-send-email-imre.deak@intel.com (cherry picked from commit e27daab49718e3232318d8b539cb302521b4b724) Signed-off-by: Jani Nikula <jani.nikula@intel.com> | 22 February 2016, 15:44:37 UTC |
| 7a6252c | Imre Deak | 12 February 2016, 16:55:15 UTC | drm/i915/crt: Ensure the HW is powered during HW state readout The assumption when adding the intel_display_power_is_enabled() checks was that if it returns success the power can't be turned off afterwards during the HW access, which is guaranteed by modeset locks. This isn't always true, so make sure we hold a dedicated reference for the time of the access. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93439 CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-7-git-send-email-imre.deak@intel.com (cherry picked from commit 1c8fdda1ea947ae8cf994969a1c285acc7089cb9) Signed-off-by: Jani Nikula <jani.nikula@intel.com> | 22 February 2016, 15:44:37 UTC |
| 5a24fab | Imre Deak | 12 February 2016, 16:55:14 UTC | drm/i915: Ensure the HW is powered during HW access in assert_pipe The assumption when adding the intel_display_power_is_enabled() checks was that if it returns success the power can't be turned off afterwards during the HW access, which is guaranteed by modeset locks. This isn't always true, so make sure we hold a dedicated reference for the time of the access. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-6-git-send-email-imre.deak@intel.com (cherry picked from commit 4feed0ebfa45879bc422c9a0bfa3cffec82ea60a) Signed-off-by: Jani Nikula <jani.nikula@intel.com> | 22 February 2016, 15:44:37 UTC |
| bacd67d | Imre Deak | 12 February 2016, 16:55:13 UTC | drm/i915: Ensure the HW is powered when disabling VGA The assumption when adding the intel_display_power_is_enabled() checks was that if it returns success the power can't be turned off afterwards during the HW access, which is guaranteed by modeset locks. This isn't always true, so make sure we hold a dedicated reference for the time of the access. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-5-git-send-email-imre.deak@intel.com (cherry picked from commit 6392f8478e6f119467b1ad06e30e1f078e62efc1) Signed-off-by: Jani Nikula <jani.nikula@intel.com> | 22 February 2016, 15:44:36 UTC |
| 013ef6c | Imre Deak | 12 February 2016, 16:55:12 UTC | drm/i915/ibx: Ensure the HW is powered during PLL HW readout The assumption when adding the intel_display_power_is_enabled() checks was that if it returns success the power can't be turned off afterwards during the HW access, which is guaranteed by modeset locks. This isn't always true, so make sure we hold a dedicated reference for the time of the access. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-4-git-send-email-imre.deak@intel.com (cherry picked from commit 12fda3876d08519bdf6f0acc70dd35754b422ed5) Signed-off-by: Jani Nikula <jani.nikula@intel.com> | 22 February 2016, 15:44:36 UTC |
| 9fb84d5 | Imre Deak | 12 February 2016, 16:55:11 UTC | drm/i915: Ensure the HW is powered during display pipe HW readout The assumption when adding the intel_display_power_is_enabled() checks was that if it returns success the power can't be turned off afterwards during the HW access, which is guaranteed by modeset locks. This isn't always true, so make sure we hold a dedicated reference for the time of the access. Signed-off-by: Imre Deak <imre.deak@intel.com> Revieved-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-3-git-send-email-imre.deak@intel.com (cherry picked from commit 1729050eb4bbc192e54069e82069f2811313c1dd) Signed-off-by: Jani Nikula <jani.nikula@intel.com> | 22 February 2016, 15:44:35 UTC |
| 5af9a45 | Imre Deak | 17 February 2016, 12:17:42 UTC | drm/i915: Add helper to get a display power ref if it was already enabled We have many places in the code where we check if a given display power domain is enabled and if so access registers backed by this power domain. We assumed that some modeset lock will prevent the power reference from vanishing in the middle of the HW access, but this assumption doesn't always hold. In such cases we get either the wakeref not held, or an unclaimed register access error message. To fix this in a future-proof way that's independent of other locks wrap any such access with a get_ref_if_enabled()/put_ref() pair. Kudos to Ville and Joonas for the ideas of this new interface. v2: - init the power_domains ptr when declaring it everywhere (Joonas) v3: - don't report the device to be powered if runtime PM is disabled CC: Mika Kuoppala <mika.kuoppala@intel.com> CC: Chris Wilson <chris@chris-wilson.co.uk> CC: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> CC: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455711462-7442-1-git-send-email-imre.deak@intel.com (cherry picked from commit 09731280028ce03e6a27e1998137f1775a2839f3) Signed-off-by: Jani Nikula <jani.nikula@intel.com> | 22 February 2016, 15:44:35 UTC |
| 1b17cb7 | Martin Schwidefsky | 19 February 2016, 14:29:05 UTC | s390/fpu: signals vs. floating point control register git commit 904818e2f229f3d94ec95f6932a6358c81e73d78 "s390/kernel: introduce fpu-internal.h with fpu helper functions" introduced the fpregs_store / fp_regs_load helper. These function fail to save and restore the floating pointer control registers. The effect is that the FPC is not correctly handled on signal delivery and signal return. Cc: stable@vger.kernel.org # 4.4 Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> | 22 February 2016, 08:29:35 UTC |
| 342300c | Martin Schwidefsky | 19 February 2016, 13:44:14 UTC | s390/compat: correct restore of high gprs on signal return git commit 8070361799ae1e3f4ef347bd10f0a508ac10acfb "s390: add support for vector extension" broke 31-bit compat processes in regard to signal handling. The restore_sigregs_ext32() function is used to restore the additional elements from the user space signal frame. Among the additional elements are the upper registers halves for 64-bit register support for 31-bit processes. The copy_from_user that is used to retrieve the high-gprs array from the user stack uses an incorrect length, 8 bytes instead of 64 bytes. This causes incorrect upper register halves to get loaded. Cc: stable@vger.kernel.org # 3.8+ Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> | 22 February 2016, 08:29:35 UTC |
| 9ab3ac2 | Aneesh Kumar K.V | 20 February 2016, 15:11:54 UTC | powerpc/mm/hash: Clear the invalid slot information correctly We can get a hash pte fault with 4k base page size and find the pte already inserted with 64K base page size. In that case we need to clear the existing slot information from the old pte. Fix this correctly With THP, we also clear the slot information with respect to all the 64K hash pte mapping that 16MB page. They are all invalid now. This make sure we don't find the slot valid when we fault with 4k base page size. Finding the slot valid should not result in any wrong behavior because we do check again in hash page table for the validity. But we can avoid that check completely. Fixes: a43c0eb8364c022 ("powerpc/mm: Convert 4k hash insert to C") Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> | 22 February 2016, 08:27:39 UTC |
| f6bf0fa | Gavin Shan | 12 February 2016, 05:03:05 UTC | powerpc/eeh: Fix partial hotplug criterion During error recovery, the device could be removed as part of the partial hotplug. The criterion used to come with partial hotplug is: if the device driver provides error_detected(), slot_reset() and resume() callbacks, it's immune from hotplug. Otherwise, it's going to experience partial hotplug during EEH recovery. But the criterion isn't correct enough: mlx4_core driver for Mellanox adapters provides error_detected(), slot_reset() callbacks, but resume() isn't there. Those Mellanox adapters won't be to involved in the partial hotplug. This fixes the criterion to a practical one: adpater with driver that provides error_detected(), slot_reset() will be immune from partial hotplug. resume() isn't mandatory. Fixes: f2da4ccf ("powerpc/eeh: More relaxed hotplug criterion") Cc: stable@vger.kernel.org #v4.4+ Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> | 22 February 2016, 08:25:55 UTC |
| d856626 | David S. Miller | 22 February 2016, 03:51:55 UTC | Merge tag 'linux-can-fixes-for-4.5-20160221' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can Marc Kleine-Budde says: ==================== pull-request: can 2016-02-21 this is a pull reqeust of one patch for net/master. The patch is by Gerhard Uttenthaler and fixes a potential tx overflow in the ems_usb driver. ==================== Signed-off-by: David S. Miller <davem@davemloft.net> | 22 February 2016, 03:51:55 UTC |
