- 18 Mar, 2017 1 commit
-
-
William Breathitt Gray authored
commit ca8d8e03 upstream. The flag register is offset by 1 from the respective channel data register. This patch fixes an off-by-one error when attempting to read a channel flag register where the base address was not properly offset. Fixes: 28e5d3bb ("iio: 104-quad-8: Add IIO support for the ACCES 104-QUAD-8") Signed-off-by:
William Breathitt Gray <vilhelm.gray@gmail.com> Signed-off-by:
Jonathan Cameron <jic23@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 15 Mar, 2017 39 commits
-
-
Greg Kroah-Hartman authored
-
K. Y. Srinivasan authored
commit 372b1e91 upstream. The hypercall page only needs to be executable but currently it is setup to be writable as well. Fix the issue. Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Acked-by:
Kees Cook <keescook@chromium.org> Reported-by:
Stephen Hemminger <stephen@networkplumber.org> Tested-by:
-
OGAWA Hirofumi authored
commit c0d0e351 upstream. Recently fallocate patch was merged and it uses MSDOS_I(inode)->mmu_private at fat_evict_inode(). However, fat_inode/fsinfo_inode that was introduced in past didn't initialize MSDOS_I(inode) properly. With those combinations, it became the cause of accessing random entry in FAT area. Link: http://lkml.kernel.org/r/87pohrj4i8.fsf@mail.parknet.co.jpSigned-off-by:
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Reported-by:
Moreno Bartalucci <moreno.bartalucci@tecnorama.it> Tested-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Dmitry Vyukov authored
commit 68fd814a upstream. We see reported stalls/lockups in quarantine_remove_cache() on machines with large amounts of RAM. quarantine_remove_cache() needs to scan whole quarantine in order to take out all objects belonging to the cache. Quarantine is currently 1/32-th of RAM, e.g. on a machine with 256GB of memory that will be 8GB. Moreover quarantine scanning is a walk over uncached linked list, which is slow. Add cond_resched() after scanning of each non-empty batch of objects. Batches are specifically kept of reasonable size for quarantine_put(). On a machine with 256GB of RAM we should have ~512 non-empty batches, each with 16MB of objects. Link: http://lkml.kernel.org/r/20170308154239.25440-1-dvyukov@google.comSigned-off-by:
Dmitry Vyukov <dvyukov@google.com> Acked-by:
Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: Greg Thelen <gthelen@google.com> Signed-off-by:
-
Tahsin Erdogan authored
commit 40e952f9 upstream. mem_cgroup_free() indirectly calls wb_domain_exit() which is not prepared to deal with a struct wb_domain object that hasn't executed wb_domain_init(). For instance, the following warning message is printed by lockdep if alloc_percpu() fails in mem_cgroup_alloc(): INFO: trying to register non-static key. the code is fine but needs lockdep annotation. turning off the locking correctness validator. CPU: 1 PID: 1950 Comm: mkdir Not tainted 4.10.0+ #151 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Call Trace: dump_stack+0x67/0x99 register_lock_class+0x36d/0x540 __lock_acquire+0x7f/0x1a30 lock_acquire+0xcc/0x200 del_timer_sync+0x3c/0xc0 wb_domain_exit+0x14/0x20 mem_cgroup_free+0x14/0x40 mem_cgroup_css_alloc+0x3f9/0x620 cgroup_apply_control_enable+0x190/0x390 cgroup_mkdir+0x290/0x3d0 kernfs_iop_mkdir+0x58/0x80 vfs_mkdir+0x10e/0x1a0 SyS_mkdirat+0xa8/0xd0 SyS_mkdir+0x14/0x20 entry_SYSCALL_64_fastpath+0x18/0xad Add __mem_cgroup_free() which skips wb_domain_exit(). This is used by both mem_cgroup_free() and mem_cgroup_alloc() clean up. Fixes: 0b8f73e1 ("mm: memcontrol: clean up alloc, online, offline, free functions") Link: http://lkml.kernel.org/r/20170306192122.24262-1-tahsin@google.comSigned-off-by:
Tahsin Erdogan <tahsin@google.com> Acked-by:
Michal Hocko <mhocko@suse.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Signed-off-by:
-
Kirill A. Shutemov authored
commit 6ebb4a1b upstream. The following test case triggers BUG() in munlock_vma_pages_range(): int main(int argc, char *argv[]) { int fd; system("mount -t tmpfs -o huge=always none /mnt"); fd = open("/mnt/test", O_CREAT | O_RDWR); ftruncate(fd, 4UL << 20); mmap(NULL, 4UL << 20, PROT_READ | PROT_WRITE, MAP_SHARED | MAP_FIXED | MAP_LOCKED, fd, 0); mmap(NULL, 4096, PROT_READ | PROT_WRITE, MAP_SHARED | MAP_LOCKED, fd, 0); munlockall(); return 0; } The second mmap() create PTE-mapping of the first huge page in file. It makes kernel munlock the page as we never keep PTE-mapped page mlocked. On munlockall() when we handle vma created by the first mmap(), munlock_vma_page() returns page_mask == 0, as the page is not mlocked anymore. On next iteration follow_page_mask() return tail page, but page_mask is HPAGE_NR_PAGES - 1. It makes us skip to the first tail page of the next huge page and step on VM_BUG_ON_PAGE(PageMlocked(page)). The fix is not use the page_mask from follow_page_mask() at all. It has no use for us. Link: http://lkml.kernel.org/r/20170302150252.34120-1-kirill.shutemov@linux.intel.comSigned-off-by:
Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Signed-off-by:
-
Daniel Borkmann authored
commit 2c4ea6e2 upstream. Fengguang reported random corruptions from various locations on x86-32 after commits d2852a22 ("arch: add ARCH_HAS_SET_MEMORY config") and 9d876e79 ("bpf: fix unlocking of jited image when module ronx not set") that uses the former. While x86-32 doesn't have a JIT like x86_64, the bpf_prog_lock_ro() and bpf_prog_unlock_ro() got enabled due to ARCH_HAS_SET_MEMORY, whereas Fengguang's test kernel doesn't have module support built in and therefore never had the DEBUG_SET_MODULE_RONX setting enabled. After investigating the crashes further, it turned out that using set_memory_ro() and set_memory_rw() didn't have the desired effect, for example, setting the pages as read-only on x86-32 would still let probe_kernel_write() succeed without error. This behavior would manifest itself in situations where the vmalloc'ed buffer was accessed prior to set_memory_*() such as in case of bpf_prog_alloc(). In cases where it wasn't, the page attribute changes seemed to have taken effect, leading to the conclusion that a TLB invalidate didn't happen. Moreover, it turned out that this issue reproduced with qemu in "-cpu kvm64" mode, but not for "-cpu host". When the issue occurs, change_page_attr_set_clr() did trigger a TLB flush as expected via __flush_tlb_all() through cpa_flush_range(), though. There are 3 variants for issuing a TLB flush: invpcid_flush_all() (depends on CPU feature bits X86_FEATURE_INVPCID, X86_FEATURE_PGE), cr4 based flush (depends on X86_FEATURE_PGE), and cr3 based flush. For "-cpu host" case in my setup, the flush used invpcid_flush_all() variant, whereas for "-cpu kvm64", the flush was cr4 based. Switching the kvm64 case to cr3 manually worked fine, and further investigating the cr4 one turned out that X86_CR4_PGE bit was not set in cr4 register, meaning the __native_flush_tlb_global_irq_disabled() wrote cr4 twice with the same value instead of clearing X86_CR4_PGE in the first write to trigger the flush. It turned out that X86_CR4_PGE was cleared from cr4 during init from lguest_arch_host_init() via adjust_pge(). The X86_FEATURE_PGE bit is also cleared from there due to concerns of using PGE in guest kernel that can lead to hard to trace bugs (see bff672e6 ("lguest: documentation V: Host") in init()). The CPU feature bits are cleared in dynamic boot_cpu_data, but they never propagated to __flush_tlb_all() as it uses static_cpu_has() instead of boot_cpu_has() for testing which variant of TLB flushing to use, meaning they still used the old setting of the host kernel. Clearing via setup_clear_cpu_cap(X86_FEATURE_PGE) so this would propagate to static_cpu_has() checks is too late at this point as sections have been patched already, so for now, it seems reasonable to switch back to boot_cpu_has(X86_FEATURE_PGE) as it was prior to commit c109bf95 ("x86/cpufeature: Remove cpu_has_pge"). This lets the TLB flush trigger via cr3 as originally intended, properly makes the new page attributes visible and thus fixes the crashes seen by Fengguang. Fixes: c109bf95 ("x86/cpufeature: Remove cpu_has_pge") Reported-by:
Fengguang Wu <fengguang.wu@intel.com> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Cc: bp@suse.de Cc: Kees Cook <keescook@chromium.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: netdev@vger.kernel.org Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Alexei Starovoitov <ast@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: lkp@01.org Cc: Laura Abbott <labbott@redhat.com> Link: http://lkml.kernrl.org/r/20170301125426.l4nf65rx4wahohyl@wfg-t540p.sh.intel.com Link: http://lkml.kernel.org/r/25c41ad9eca164be4db9ad84f768965b7eb19d9e.1489191673.git.daniel@iogearbox.netSigned-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Dan Williams authored
commit ef947b25 upstream. gup_pte_range() fails to check pte_allows_gup() before translating a DAX pte entry, pte_devmap(), to a page. This allows writes to read-only mappings, and bypasses the DAX cacheline dirty tracking due to missed 'mkwrite' faults. The gup_huge_pmd() path and the gup_huge_pud() path correctly check pte_allows_gup() before checking for _devmap() entries. Fixes: 3565fce3 ("mm, x86: get_user_pages() for dax mappings") Link: http://lkml.kernel.org/r/148804251312.36605.12665024794196605053.stgit@dwillia2-desk3.amr.corp.intel.comSigned-off-by:
Ross Zwisler <ross.zwisler@linux.intel.com> Signed-off-by:
Dan Williams <dan.j.williams@intel.com> Reported-by:
Dave Hansen <dave.hansen@linux.intel.com> Reported-by:
-
Arnd Bergmann authored
commit d24cdcd3 upstream. I ran into this compile warning, which is the result of BUG_ON(1) not always leading to the compiler treating the code path as unreachable: include/linux/ceph/osdmap.h: In function 'ceph_can_shift_osds': include/linux/ceph/osdmap.h:62:1: error: control reaches end of non-void function [-Werror=return-type] Using BUG() here avoids the warning. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Ilya Dryomov <idryomov@gmail.com> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by:
-
Hans de Goede authored
commit 998d7573 upstream. If there is no OPREGION_ASLE_EXT then a VBT stored in mailbox #4 may use the ASLE_EXT parts of the opregion. Adjust the vbt_size calculation for a vbt in mailbox #4 for this. This fixes the driver not finding the VBT on a jumper ezpad mini3 cherrytrail tablet and on a ACER SW5_017 machine. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1487088758-30050-1-git-send-email-jani.nikula@intel.com (cherry picked from commit dfb65e71) Signed-off-by:
-
Chris Wilson authored
commit 636deb5b upstream. The i915_gem_object_wait_fence() uses an incoming timeout=0 to query whether the current fence is busy or idle, without waiting. This can be used by the wait-ioctl to implement a busy query. Fixes: e95433c7 ("drm/i915: Rearrange i915_wait_request() accounting with callers") Testcase: igt/gem_wait/basic-busy-write-all Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.william.auld@gmail.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: <drm-intel-fixes@lists.freedesktop.org> # v4.10-rc1+ Link: http://patchwork.freedesktop.org/patch/msgid/20170212215344.16600-1-chris@chris-wilson.co.ukReviewed-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> (cherry picked from commit d892e939) Signed-off-by:
-
Chris Wilson authored
commit 44a02705 upstream. We first wait for a request to be submitted to hw and assigned a seqno, before we can wait for the hw to signal completion (otherwise we don't know the hw id we need to wait upon). Whilst waiting for the request to be submitted, we may exceed the user's timeout and need to propagate the error back. v2: Make ETIME into an error from wait_for_execute for consistent exit handling. Reported-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Fixes: 4680816b ("drm/i915: Wait first for submission, before waiting for request completion") Testcase: igt/gem_wait/basic-await Signed-off-by:
-
Ville Syrjälä authored
commit aa9323dd upstream. Until recently vlv_steal_power_sequencer() wasn't being called for normal DP ports, and hence it could assert that it should only be called for pipe A and B (since pipe C doesn't support eDP). However that changed when we started to consider normal DP ports as well when choosing a PPS. So we will now get spurious warnings when vlv_steal_power_sequencer() does get called for pipe C. Avoid this by moving the WARN down into vlv_detach_power_sequencer() where this assertion should still hold. Cc: Imre Deak <imre.deak@intel.com> Fixes: 9f2bdb00 ("drm/i915: Prevent PPS stealing from a normal DP port on VLV/CHV") References: https://bugs.freedesktop.org/show_bug.cgi?id=95287Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170208175254.10958-1-ville.syrjala@linux.intel.comReviewed-by:
Imre Deak <imre.deak@intel.com> (cherry picked from commit d158694f) Signed-off-by:
-
Chris Wilson authored
commit 2d2cfc12 upstream. If we fail to dma-map the object, the most common cause is lack of space inside the SW-IOTLB due to fragmentation. If we recreate the_sg_table using segments of PAGE_SIZE (and single page allocations), we may succeed in remapping the scatterlist. First became a significant problem for the mock selftests after commit 5584f1b1 ("drm/i915: fix i915 running as dom0 under Xen") increased the max_order. Fixes: 920cf419 ("drm/i915: Introduce an internal allocator for disposable private objects") Fixes: 5584f1b1 ("drm/i915: fix i915 running as dom0 under Xen") Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> (cherry picked from commit bb96dcf5) Signed-off-by:
-
Chris Wilson authored
commit 24f76b2c upstream. We can not allow the worker to run after its fbdev, or even the module, has been removed. Fixes: cfe63423 ("drm/fb-helper: Add drm_fb_helper_set_suspend_unlocked()") Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170207124956.14954-2-chris@chris-wilson.co.ukSigned-off-by:
-
Chris Wilson authored
commit f21b9a92 upstream. We can not allow the worker to run after its fbdev, or even the module, has been removed. Fixes: eaa434de ("drm/fb-helper: Add fb_deferred_io support") Signed-off-by:
-
Chris Wilson authored
commit ddd09373 upstream. Explicitly disable stolen memory when running as a guest in a virtual machine, since the memory is not mediated between clients and reserved entirely for the host. The actual size should be reported as zero, but like every other quirk we want to tell the user what is happening. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99028Signed-off-by:
Zhenyu Wang <zhenyuw@linux.intel.com> (cherry picked from commit 04a68a35) Signed-off-by:
-
Dan Carpenter authored
commit f9ad86e4 upstream. Having "ret" be a bool type works for everything except ret = funcs->atomic_check(). The other functions all return zero on error but ->atomic_check() returns negative error codes. We want to propagate the error code but instead we return 1. I found this bug with static analysis and I don't know if it affects run time. Fixes: 4cd4df80 ("drm/atomic: Add ->atomic_check() to encoder helpers") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Fabio Estevam authored
commit fc12bccd upstream. Commit deb65870 ("drm/imx: imx-tve: check the value returned by regulator_set_voltage()") exposes the following probe issue: 63ff0000.tve supply dac not found, using dummy regulator imx-drm display-subsystem: failed to bind 63ff0000.tve (ops imx_tve_ops): -22 When the 'dac-supply' is not passed in the device tree a dummy regulator is used and setting its voltage is not allowed. To fix this issue, do not set the dac-supply voltage inside the driver and let its voltage be specified in the device tree. Print a warning if the the 'dac-supply' voltage has a value different from 2.75V. Fixes: deb65870 ("drm/imx: imx-tve: check the value returned by regulator_set_voltage()") Suggested-by:
Lucas Stach <l.stach@pengutronix.de> Signed-off-by:
Fabio Estevam <fabio.estevam@nxp.com> Signed-off-by:
Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
-
Thomas Hellstrom authored
commit 31788ca8 upstream. vmware tools has a daemon that gets layout information from the GUI and forwards it to DRM so that the modesetting code can set preferred connector locations and modes. This daemon was using control nodes but since control nodes were just removed, make it possible for the daemon to use render- or primary nodes instead. This is a bit ugly but will allow drm to proceed with removal of the mostly unused control-node code and allow vmware to proceed with fixing up automatic layout settings for gnome-shell/wayland. We bump minor to inform user-space about the api change. Signed-off-by:
Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by:
Sinclair Yeh <syeh@vmware.com> Signed-off-by:
-
Michel Dänzer authored
commit 239ac65f upstream. The current caching state may not be tt_cached, even though the placement contains TTM_PL_FLAG_CACHED, because placement can contain multiple caching flags. Trying to swap out such a BO would trip up the BUG_ON(ttm->caching_state != tt_cached); in ttm_tt_swapout. Signed-off-by:
Michel Dänzer <michel.daenzer@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Tomeu Vizoso authored
commit 36fc5797 upstream. Rotel RSX-1058 is a receiver with 4 HDMI inputs and a HDMI output, all 1.1. When a sink that supports deep color is connected to the output, the receiver will send EDIDs that advertise this capability, even if it isn't possible with HDMI versions earlier than 1.3. Currently the kernel is assuming that deep color is possible and the sink displays an error. This quirk will make sure that deep color isn't used with this particular receiver. Fixes: 7a0baa62 ("Revert "drm/i915: Disable 12bpc hdmi for now"") Signed-off-by:
Tomeu Vizoso <tomeu.vizoso@collabora.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170220152545.13153-1-tomeu.vizoso@collabora.com Cc: Matt Horan <matt@matthoran.com> Tested-by:
Matt Horan <matt@matthoran.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99869Reviewed-by:
-
Alex Deucher authored
commit a882f5de upstream. The vfct table can contain multiple vbios images if the platform contains multiple GPUs. Noticed by netkas on phoronix forums. This patch fixes those platforms. Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Y.C. Chen authored
commit 3856081e upstream. The current POST code for the AST2300/2400 family doesn't work properly if the chip hasn't been initialized previously by either the BMC own FW or the VBIOS. This fixes it. Signed-off-by:
Y.C. Chen <yc_chen@aspeedtech.com> Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Tested-by:
Joel Stanley <joel@jms.id.au> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Y.C. Chen authored
commit 9bb92f51 upstream. open_key enables access the registers used by enable_mmio Signed-off-by:
-
Y.C. Chen authored
commit 905f21a4 upstream. The test to see if VGA was already enabled is doing an unnecessary second test from a register that may or may not have been initialized to a valid value. Remove it. Signed-off-by:
-
Russell Currey authored
commit 71f677a9 upstream. The ast driver configures a window to enable access into BMC memory space in order to read some configuration registers. If this window is disabled, which it can be from the BMC side, the ast driver can't function. Closing this window is a necessity for security if a machine's host side and BMC side are controlled by different parties; i.e. a cloud provider offering machines "bare metal". A recent patch went in to try to check if that window is open but it does so by trying to access the registers in question and testing if the result is 0xffffffff. This method will trigger a PCIe error when the window is closed which on some systems will be fatal (it will trigger an EEH for example on POWER which will take out the device). This patch improves this in two ways: - First, if the firmware has put properties in the device-tree containing the relevant configuration information, we use these. - Otherwise, a bit in one of the SCU scratch registers (which are readable via the VGA register space and writeable by the BMC) will indicate if the BMC has closed the window. This bit has been defined by Y.C Chen from Aspeed. If the window is closed and the configuration isn't available from the device-tree, some sane defaults are used. Those defaults are hopefully sufficient for standard video modes used on a server. Signed-off-by:
Russell Currey <ruscur@russell.cc> Acked-by:
-
Jean Delvare authored
Revert commit f8d9422e ("drm/amdgpu: update tile table for oland/hainan") as it is causing ugly visual artifacts on at least Oland. This is only an optimization so we can live without it. This fixes kernel bug #194761: amdgpu driver breaks on Oland (SI) https://bugzilla.kernel.org/show_bug.cgi?id=194761Signed-off-by:
Jean Delvare <jdelvare@suse.de> Fixes: f8d9422e ("drm/amdgpu: update tile table for oland/hainan") Cc: Flora Cui <Flora.Cui@amd.com> Cc: Junwei Zhang <Jerry.Zhang@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Acked-by:
-
Alex Deucher authored
commit c10c8f7c upstream. Don't update display bandwidth on headless asics. bug: https://bugs.freedesktop.org/show_bug.cgi?id=99387Signed-off-by:
-
Alex Deucher authored
commit 4ce3bd45 upstream. Add cases for asics with 3 and 5 crtcs. Fixes an artificial limitation on asics with 3 or 5 crtcs. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=99744Reviewed-by:
-
Johannes Berg authored
commit 19d19e96 upstream. When I originally introduced using the driver-indicated station as an optimisation to avoid the hashtable lookup/iteration, of course it wasn't intended to really functionally change anything. I neglected, however, to take into account VLAN interfaces, which have the property that management and data frames are handled differently: data frames go directly to the station and the VLAN while management frames continue to be processed over the underlying/associated AP-type interface. As a consequence, when a driver used this optimisation for management frames and the user enabled VLANs, my change broke things since any management frames, particularly disassoc/deauth, were missed by hostapd. Fix this by restoring the original code path for non-data frames, they aren't critical for performance to begin with. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=194713. Big thanks goes to Jarek who bisected the issue and provided a very detailed bug report, including the crucial information that he was using VLANs in his configuration. Fixes: 771e846bea9e ("mac80211: allow passing transmitter station on RX") Reported-and-tested-by:
Jarek Kamiński <jarek@freeside.be> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Felix Fietkau authored
commit 890030d3 upstream. When running a BA session, the driver (or the hardware) already takes care of retransmitting failed frames, since it has to keep the receiver reorder window in sync. Adding another layer of retransmit around that does not improve anything. In fact, it can only lead to some strong reordering with huge latency. Signed-off-by:
Felix Fietkau <nbd@nbd.name> Signed-off-by:
-
Sara Sharon authored
commit b7540d8f upstream. When RX aggregation starts, transmitter may continue send frames with SN smaller than SSN until the AddBA response is received. However, the reorder buffer is already initialized at this point, which will cause the drop of such frames as duplicates since the head SN of the reorder buffer is set to the SSN, which is bigger. Signed-off-by:
Sara Sharon <sara.sharon@intel.com> Signed-off-by:
-
Matt Chen authored
commit a9e9200d upstream. The issue was found when entering suspend and resume. It triggers a warning in: mac80211/key.c: ieee80211_enable_keys() ... WARN_ON_ONCE(sdata->crypto_tx_tailroom_needed_cnt || sdata->crypto_tx_tailroom_pending_dec); ... It points out sdata->crypto_tx_tailroom_pending_dec isn't cleaned up successfully in a delayed_work during suspend. Add a flush_delayed_work to fix it. Signed-off-by:
Matt Chen <matt.chen@intel.com> Signed-off-by:
-
Dan Williams authored
commit 86ef58a4 upstream. The interleave-set cookie is a sum that sanity checks the composition of an interleave set has not changed from when the namespace was initially created. The checksum is calculated by sorting the DIMMs by their location in the interleave-set. The comparison for the sort must be 64-bit wide, not byte-by-byte as performed by memcmp() in the broken case. Fix the implementation to accept correct cookie values in addition to the Linux "memcmp" order cookies, but only allow correct cookies to be generated going forward. It does mean that namespaces created by third-party-tooling, or created by newer kernels with this fix, will not validate on older kernels. However, there are a couple mitigating conditions: 1/ platforms with namespace-label capable NVDIMMs are not widely available. 2/ interleave-sets with a single-dimm are by definition not affected (nothing to sort). This covers the QEMU-KVM NVDIMM emulation case. The cookie stored in the namespace label will be fixed by any write the namespace label, the most straightforward way to achieve this is to write to the "alt_name" attribute of a namespace in sysfs. Fixes: eaf96153 ("libnvdimm, nfit: add interleave-set state-tracking infrastructure") Reported-by:
Nicholas Moulin <nicholas.w.moulin@linux.intel.com> Tested-by:
-
Max Filippov authored
commit 4ab18701 upstream. FDT tag parsing is not related to whether BLK_DEV_INITRD is configured or not, move it out of the corresponding #ifdef/#endif block. This fixes passing external FDT to the kernel configured w/o BLK_DEV_INITRD support. Signed-off-by:
Max Filippov <jcmvbkbc@gmail.com> Signed-off-by:
-
Clemens Gruber authored
commit 8d254a34 upstream. When first implementing support for changing the output frequency, an optimization was added to continue the PWM after changing the prescaler without having to reprogram the ON and OFF registers for the duty cycle, in case the duty cycle stayed the same. This was flawed, because we compared the absolute value of the duty cycle in nanoseconds instead of the ratio to the period. Fix the problem by removing the shortcut. Fixes: 01ec8472 ("pwm-pca9685: Support changing the output frequency") Signed-off-by:
Clemens Gruber <clemens.gruber@pqgruber.com> Reviewed-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
Thierry Reding <thierry.reding@gmail.com> Signed-off-by:
-
Trond Myklebust authored
commit 251af29c upstream. It is not sufficient to just check that the lock pids match when granting a callback, we also need to ensure that we're granting the callback on the right file. Reported-by:
Pankaj Singh <psingh.ait@gmail.com> Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
Trond Myklebust <trond.myklebust@primarydata.com> Signed-off-by:
Anna Schumaker <Anna.Schumaker@Netapp.com> Signed-off-by:
-
Gavin Shan authored
commit d0c42497 upstream. In PowerNV PCI hotplug driver, the initial PCI slot's state is set to PNV_PHP_STATE_POPULATED if no PCI devices are connected to the slot. The PCI devices that are hot added to the slot won't be probed and populated because of the check in pnv_php_enable(): /* Check if the slot has been configured */ if (php_slot->state != PNV_PHP_STATE_REGISTERED) return 0; This fixes the issue by leaving the slot in PNV_PHP_STATE_REGISTERED state initially if nothing is connected to the slot. Fixes: 360aebd8 ("drivers/pci/hotplug: Support surprise hotplug in powernv driver") Reported-by:
Hank Chang <hankmax0000@gmail.com> Signed-off-by:
Gavin Shan <gwshan@linux.vnet.ibm.com> Tested-by:
Willie Liauw <williel@supermicro.com.tw> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
