- 17 Oct, 2018 1 commit
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/clk/linuxGreg Kroah-Hartman authored
Stephen writes: "clk fixes for v4.19-rc8 One fix for the Allwinner A10 SoC's audio PLL that wasn't properly set and generating noise." * tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux: clk: sunxi-ng: sun4i: Set VCO and PLL bias current to lowest setting
-
- 16 Oct, 2018 3 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparcGreg Kroah-Hartman authored
David writes: "Sparc fixes 1) Revert the %pOF change, it causes regressions. 2) Wire up io_pgetevents(). 3) Fix perf events on single-PCR sparc64 cpus. 4) Do proper perf event throttling like arm and x86." * git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc: Revert "sparc: Convert to using %pOFn instead of device_node.name" sparc64: Set %l4 properly on trap return after handling signals. sparc64: Make proc_id signed. sparc: Throttle perf events properly. sparc: Fix single-pcr perf event counter management. sparc: Wire up io_pgetevents system call. sunvdc: Remove VLA usage
-
git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinuxGreg Kroah-Hartman authored
Paul writes: "SELinux fixes for v4.19 We've got one SELinux "fix" that I'd like to get into v4.19 if possible. I'm using double quotes on "fix" as this is just an update to the MAINTAINERS file and not a code change. From my perspective, MAINTAINERS updates generally don't warrant inclusion during the -rcX phase, but this is a change to the mailing list location so it seemed prudent to get this in before v4.19 is released" * tag 'selinux-pr-20181015' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux: MAINTAINERS: update the SELinux mailing list location
-
David S. Miller authored
This reverts commit 0b9871a3. Causes crashes with qemu, interacts badly with commit commit 6d0a70a2 ("vsprintf: print OF node name using full_name") etc. Reported-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 15 Oct, 2018 4 commits
-
-
David Howells authored
The recent patch to fix the afs_server struct leak didn't actually fix the bug, but rather fixed some of the symptoms. The problem is that an asynchronous call that holds a resource pointed to by call->reply[0] will find the pointer cleared in the call destructor, thereby preventing the resource from being cleaned up. In the case of the server record leak, the afs_fs_get_capabilities() function in devel code sets up a call with reply[0] pointing at the server record that should be altered when the result is obtained, but this was being cleared before the destructor was called, so the put in the destructor does nothing and the record is leaked. Commit f014ffb0 removed the additional ref obtained by afs_install_server(), but the removal of this ref is actually used by the garbage collector to mark a server record as being defunct after the record has expired through lack of use. The offending clearance of call->reply[0] upon completion in afs_process_async_call() has been there from the origin of the code, but none of the asynchronous calls actually use that pointer currently, so it should be safe to remove (note that synchronous calls don't involve this function). Fix this by the following means: (1) Revert commit f014ffb0. (2) Remove the clearance of reply[0] from afs_process_async_call(). Without this, afs_manage_servers() will suffer an assertion failure if it sees a server record that didn't get used because the usage count is not 1. Fixes: f014ffb0 ("afs: Fix afs_server struct leak") Fixes: 08e0e7c8 ("[AF_RXRPC]: Make the in-kernel AFS filesystem use AF_RXRPC.") Signed-off-by: David Howells <dhowells@redhat.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
-
David S. Miller authored
If we did some signal processing, we have to reload the pt_regs tstate register because it's value may have changed. In doing so we also have to extract the %pil value contained in there anre load that into %l4. This value is at bit 20 and thus needs to be shifted down before we later write it into the %pil register. Most of the time this is harmless as we are returning to userspace and the %pil is zero for that case. Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
So that when it is unset, ie. '-1', userspace can see it properly. Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 14 Oct, 2018 2 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimmGreg Kroah-Hartman authored
Dan writes: "libnvdimm/dax 4.19-rc8 * Fix a livelock in dax_layout_busy_page() present since v4.18. The lockup triggers when truncating an actively mapped huge page out of a mapping pinned for direct-I/O. * Fix mprotect() clobbers of _PAGE_DEVMAP. Broken since v4.5 mprotect() clears this flag that is needed to communicate the liveness of device pages to the get_user_pages() path." * tag 'libnvdimm-fixes-4.19-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm: mm: Preserve _PAGE_DEVMAP across mprotect() calls filesystem-dax: Fix dax_layout_busy_page() livelock
-
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linuxGreg Kroah-Hartman authored
Wolfram writes: "i2c fix for 4.19: I2C has one documentation bugfix for something we changed during the v4.19 cycle" * 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: i2c: Fix kerneldoc for renamed i2c dma put function
-
- 13 Oct, 2018 11 commits
-
-
git://git.kernel.org/pub/scm/virt/kvm/kvmGreg Kroah-Hartman authored
Paolo writes: "KVM fixes for 4.19-rc8 Leftover bugfixes." * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: KVM: vmx: hyper-v: don't pass EPT configuration info to vmx_hv_remote_flush_tlb() KVM: x86: support CONFIG_KVM_AMD=y with CONFIG_CRYPTO_DEV_CCP_DD=m ARM: KVM: Correctly order SGI register entries in the cp15 array
-
Vitaly Kuznetsov authored
I'm observing random crashes in multi-vCPU L2 guests running on KVM on Hyper-V. I bisected the issue to the commit 877ad952 ("KVM: vmx: Add tlb_remote_flush callback support"). Hyper-V TLFS states: "AddressSpace specifies an address space ID (an EPT PML4 table pointer)" So apparently, Hyper-V doesn't expect us to pass naked EPTP, only PML4 pointer should be used. Strip off EPT configuration information before calling into vmx_hv_remote_flush_tlb(). Fixes: 877ad952 ("KVM: vmx: Add tlb_remote_flush callback support") Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
-
Richard Weinberger authored
ubifs_assert() is not WARN_ON(), so we have to invert the checks. Randy faced this warning with UBIFS being a module, since most users use UBIFS as builtin because UBIFS is the rootfs nobody noticed so far. :-( Including me. Reported-by: Randy Dunlap <rdunlap@infradead.org> Fixes: 54169ddd ("ubifs: Turn two ubifs_assert() into a WARN_ON()") Signed-off-by: Richard Weinberger <richard@nod.at> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
Fixes from Andrew: * akpm: fs/fat/fatent.c: add cond_resched() to fat_count_free_clusters() mm/thp: fix call to mmu_notifier in set_pmd_migration_entry() v2 mm/mmap.c: don't clobber partially overlapping VMA with MAP_FIXED_NOREPLACE ocfs2: fix a GCC warning
-
Khazhismel Kumykov authored
On non-preempt kernels this loop can take a long time (more than 50 ticks) processing through entries. Link: http://lkml.kernel.org/r/20181010172623.57033-1-khazhy@google.comSigned-off-by: Khazhismel Kumykov <khazhy@google.com> Acked-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Reviewed-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jérôme Glisse authored
Inside set_pmd_migration_entry() we are holding page table locks and thus we can not sleep so we can not call invalidate_range_start/end() So remove call to mmu_notifier_invalidate_range_start/end() because they are call inside the function calling set_pmd_migration_entry() (see try_to_unmap_one()). Link: http://lkml.kernel.org/r/20181012181056.7864-1-jglisse@redhat.comSigned-off-by: Jérôme Glisse <jglisse@redhat.com> Reported-by: Andrea Arcangeli <aarcange@redhat.com> Reviewed-by: Zi Yan <zi.yan@cs.rutgers.edu> Acked-by: Michal Hocko <mhocko@kernel.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Anshuman Khandual <khandual@linux.vnet.ibm.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: David Nellans <dnellans@nvidia.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Mel Gorman <mgorman@techsingularity.net> Cc: Minchan Kim <minchan@kernel.org> Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jann Horn authored
Daniel Micay reports that attempting to use MAP_FIXED_NOREPLACE in an application causes that application to randomly crash. The existing check for handling MAP_FIXED_NOREPLACE looks up the first VMA that either overlaps or follows the requested region, and then bails out if that VMA overlaps *the start* of the requested region. It does not bail out if the VMA only overlaps another part of the requested region. Fix it by checking that the found VMA only starts at or after the end of the requested region, in which case there is no overlap. Test case: user@debian:~$ cat mmap_fixed_simple.c #include <sys/mman.h> #include <errno.h> #include <stdio.h> #include <stdlib.h> #include <unistd.h> #ifndef MAP_FIXED_NOREPLACE #define MAP_FIXED_NOREPLACE 0x100000 #endif int main(void) { char *p; errno = 0; p = mmap((void*)0x10001000, 0x4000, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED_NOREPLACE, -1, 0); printf("p1=%p err=%m\n", p); errno = 0; p = mmap((void*)0x10000000, 0x2000, PROT_READ, MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED_NOREPLACE, -1, 0); printf("p2=%p err=%m\n", p); char cmd[100]; sprintf(cmd, "cat /proc/%d/maps", getpid()); system(cmd); return 0; } user@debian:~$ gcc -o mmap_fixed_simple mmap_fixed_simple.c user@debian:~$ ./mmap_fixed_simple p1=0x10001000 err=Success p2=0x10000000 err=Success 10000000-10002000 r--p 00000000 00:00 0 10002000-10005000 ---p 00000000 00:00 0 564a9a06f000-564a9a070000 r-xp 00000000 fe:01 264004 /home/user/mmap_fixed_simple 564a9a26f000-564a9a270000 r--p 00000000 fe:01 264004 /home/user/mmap_fixed_simple 564a9a270000-564a9a271000 rw-p 00001000 fe:01 264004 /home/user/mmap_fixed_simple 564a9a54a000-564a9a56b000 rw-p 00000000 00:00 0 [heap] 7f8eba447000-7f8eba5dc000 r-xp 00000000 fe:01 405885 /lib/x86_64-linux-gnu/libc-2.24.so 7f8eba5dc000-7f8eba7dc000 ---p 00195000 fe:01 405885 /lib/x86_64-linux-gnu/libc-2.24.so 7f8eba7dc000-7f8eba7e0000 r--p 00195000 fe:01 405885 /lib/x86_64-linux-gnu/libc-2.24.so 7f8eba7e0000-7f8eba7e2000 rw-p 00199000 fe:01 405885 /lib/x86_64-linux-gnu/libc-2.24.so 7f8eba7e2000-7f8eba7e6000 rw-p 00000000 00:00 0 7f8eba7e6000-7f8eba809000 r-xp 00000000 fe:01 405876 /lib/x86_64-linux-gnu/ld-2.24.so 7f8eba9e9000-7f8eba9eb000 rw-p 00000000 00:00 0 7f8ebaa06000-7f8ebaa09000 rw-p 00000000 00:00 0 7f8ebaa09000-7f8ebaa0a000 r--p 00023000 fe:01 405876 /lib/x86_64-linux-gnu/ld-2.24.so 7f8ebaa0a000-7f8ebaa0b000 rw-p 00024000 fe:01 405876 /lib/x86_64-linux-gnu/ld-2.24.so 7f8ebaa0b000-7f8ebaa0c000 rw-p 00000000 00:00 0 7ffcc99fa000-7ffcc9a1b000 rw-p 00000000 00:00 0 [stack] 7ffcc9b44000-7ffcc9b47000 r--p 00000000 00:00 0 [vvar] 7ffcc9b47000-7ffcc9b49000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] user@debian:~$ uname -a Linux debian 4.19.0-rc6+ #181 SMP Wed Oct 3 23:43:42 CEST 2018 x86_64 GNU/Linux user@debian:~$ As you can see, the first page of the mapping at 0x10001000 was clobbered. Link: http://lkml.kernel.org/r/20181010152736.99475-1-jannh@google.com Fixes: a4ff8e86 ("mm: introduce MAP_FIXED_NOREPLACE") Signed-off-by: Jann Horn <jannh@google.com> Reported-by: Daniel Micay <danielmicay@gmail.com> Acked-by: Michal Hocko <mhocko@suse.com> Acked-by: John Hubbard <jhubbard@nvidia.com> Acked-by: Kees Cook <keescook@chromium.org> Acked-by: Vlastimil Babka <vbabka@suse.cz> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
zhong jiang authored
Fix the following compile warning: fs/ocfs2/dlmglue.c:99:30: warning: lockdep_keys defined but not used [-Wunused-variable] static struct lock_class_key lockdep_keys[OCFS2_NUM_LOCK_TYPES]; Link: http://lkml.kernel.org/r/1536938148-32110-1-git-send-email-zhongjiang@huawei.comSigned-off-by: zhong jiang <zhongjiang@huawei.com> Reviewed-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
git://git.kernel.dk/linux-blockGreg Kroah-Hartman authored
Jens writes: "block fix for 4.19-rc Just a single fix that should go in, fixing a regression introduced in the blk-wbt code." * tag 'for-linus-20181012' of git://git.kernel.dk/linux-block: blk-wbt: wake up all when we scale up, not down
-
git://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2Greg Kroah-Hartman authored
Andreas writes: "gfs2 4.19 fixes Fix iomap buffered write support for journaled files" * tag 'gfs2-4.19.fixes3' of git://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2: gfs2: Fix iomap buffered write support for journaled files (2)
-
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linuxGreg Kroah-Hartman authored
Will writes: "More arm64 fixes - Reject CHAIN PMU events when they are not part of a 64-bit counter - Fix WARN_ON_ONCE() that triggers for reserved regions that don't correspond to mapped memory" * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64: perf: Reject stand-alone CHAIN events for PMUv3 arm64: Fix /proc/iomem for reserved but not memory regions
-
- 12 Oct, 2018 19 commits
-
-
David S. Miller authored
Like x86 and arm, call perf_sample_event_took() in perf event NMI interrupt handler. Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
It is important to clear the hw->state value for non-stopped events when they are added into the PMU. Otherwise when the event is scheduled out, we won't read the counter because HES_UPTODATE is still set. This breaks 'perf stat' and similar use cases, causing all the events to show zero. This worked for multi-pcr because we make explicit sparc_pmu_start() calls in calculate_multiple_pcrs(). calculate_single_pcr() doesn't do this because the idea there is to accumulate all of the counter settings into the single pcr value. So we have to add explicit hw->state handling there. Like x86, we use the PERF_HES_ARCH bit to track truly stopped events so that we don't accidently start them on a reload. Related to all of this, sparc_pmu_start() is missing a userpage update so add it. Signed-off-by: David S. Miller <davem@davemloft.net>
-
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-socGreg Kroah-Hartman authored
Arnd writes: "ARM: SoC fixes for 4.19 Two last minute bugfixes, both for NXP platforms: * The Layerscape 'qbman' infrastructure suffers from probe ordering bugs in some configurations, a two-patch series adds a hotfix for this. 4.20 will have a longer set of patches to rework it. * The old imx53-qsb board regressed in 4.19 after the addition of cpufreq support, adding a set of explicit operating points fixes this." * tag 'armsoc-fixes-4.19' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: soc: fsl: qman_portals: defer probe after qman's probe soc: fsl: qbman: add APIs to retrieve the probing status ARM: dts: imx53-qsb: disable 1.2GHz OPP
-
David Howells authored
Fix a leak of afs_server structs. The routine that installs them in the various lookup lists and trees gets a ref on leaving the function, whether it added the server or a server already exists. It shouldn't increment the refcount if it added the server. The effect of this that "rmmod kafs" will hang waiting for the leaked server to become unused. Fixes: d2ddc776 ("afs: Overhaul volume and server record caching and fileserver rotation") Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Peter Rosin authored
Just drop the "linux" part of the path, it was never correct. Reported-by: Joe Perches <joe@perches.com> Fixes: 256ac037 ("dt-bindings: document devicetree bindings for mux-controllers and gpio-mux") Signed-off-by: Peter Rosin <peda@axentia.se> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Peter Rosin authored
The file is GPL v2 or later. Acked-by: Mircea Caprioru <mircea.caprioru@analog.com> Signed-off-by: Peter Rosin <peda@axentia.se> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Andreas Gruenbacher authored
It turns out that the fix in commit 6636c3cc56 is bad; the assertion that the iomap code no longer creates buffer heads is incorrect for filesystems that set the IOMAP_F_BUFFER_HEAD flag. Instead, what's happening is that gfs2_iomap_begin_write treats all files that have the jdata flag set as journaled files, which is incorrect as long as those files are inline ("stuffed"). We're handling stuffed files directly via the page cache, which is why we ended up with pages without buffer heads in gfs2_page_add_databufs. Fix this by handling stuffed journaled files correctly in gfs2_iomap_begin_write. This reverts commit 6636c3cc5690c11631e6366cf9a28fb99c8b25bb. Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
-
Will Deacon authored
It doesn't make sense for a perf event to be configured as a CHAIN event in isolation, so extend the arm_pmu structure with a ->filter_match() function to allow the backend PMU implementation to reject CHAIN events early. Cc: <stable@vger.kernel.org> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
-
Will Deacon authored
We describe ranges of 'reserved' memory to userspace via /proc/iomem. Commit 50d7ba36 ("arm64: export memblock_reserve()d regions via /proc/iomem") updated the logic to export regions that were reserved because their contents should be preserved. This allowed kexec-tools to tell the difference between 'reserved' memory that must be preserved and not overwritten, (e.g. the ACPI tables), and 'nomap' memory that must not be touched without knowing the memory-attributes (e.g. RAS CPER regions). The above commit wrongly assumed that memblock_reserve() would not be used to reserve regions that aren't memory. It turns out this is exactly what early_init_dt_reserve_memory_arch() will do if it finds a DT reserved-memory that was also carved out of the memory node, which results in a WARN_ON_ONCE() and the region being reserved instead of ignored. The ramoops description on hikey and dragonboard-410c both do this, so we can't simply write this configuration off as "buggy firmware". Avoid this issue by rewriting reserve_memblock_reserved_regions() so that only the portions of reserved regions which overlap with mapped memory are actually reserved. Fixes: 50d7ba36 ("arm64: export memblock_reserve()d regions via /proc/iomem") Reported-by: John Stultz <john.stultz@linaro.org> Reported-by: Paolo Pisati <p.pisati@gmail.com> CC: Akashi Takahiro <takahiro.akashi@linaro.org> CC: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: James Morse <james.morse@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
-
David Howells authored
Access to the list of cells by /proc/net/afs/cells has a couple of problems: (1) It should be checking against SEQ_START_TOKEN for the keying the header line. (2) It's only holding the RCU read lock, so it can't just walk over the list without following the proper RCU methods. Fix these by using an hlist instead of an ordinary list and using the appropriate accessor functions to follow it with RCU. Since the code that adds a cell to the list must also necessarily change, sort the list on insertion whilst we're at it. Fixes: 989782dc ("afs: Overhaul cell database management") Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmcGreg Kroah-Hartman authored
Ulf writes: "MMC core: - Avoid fragile multiblock reads for the last sector in SPI mode WIFI/SDIO: - libertas: Fixup suspend sequence for the SDIO card" * tag 'mmc-v4.19-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc: libertas: call into generic suspend code before turning off power mmc: block: avoid multiblock reads for the last sector in SPI mode
-
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpioGreg Kroah-Hartman authored
Linus writes: "GPIO fix for the v4.19 series: - Fix up the interrupt parent for the irqdomains." * tag 'gpio-v4.19-4' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: gpio: Assign gpio_irq_chip::parents to non-stack pointer
-
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrlGreg Kroah-Hartman authored
Linus writes: "pin control fix for v4.19: A single pin control fix for v4.19: - Interrupt setup in the MCP23S08 driver." * tag 'pinctrl-v4.19-5' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: pinctrl: mcp23s08: fix irq and irqchip setup order
-
git://git.infradead.org/linux-mtdGreg Kroah-Hartman authored
Boris writes: "mdt: fix for 4.19-rc8 * Fix a stack overflow in lib/bch.c" * tag 'mtd/fixes-for-4.19-rc8' of git://git.infradead.org/linux-mtd: lib/bch: fix possible stack overrun
-
git://anongit.freedesktop.org/drm/drmGreg Kroah-Hartman authored
Dave writes: "drm fixes for 4.19-rc8 single nouveau runtime reference and mst change" * tag 'drm-fixes-2018-10-12-1' of git://anongit.freedesktop.org/drm/drm: drm/nouveau/drm/nouveau: Grab runtime PM ref in nv50_mstc_detect()
-
git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdmaGreg Kroah-Hartman authored
Doug writes: "RDMA fixes: Final for-rc pull request for 4.19 We only have one bug to submit this time around. It fixes a DMA unmap issue where we unmapped the DMA address from the IOMMU before we did from the card, resulting in a DMAR error with IOMMU enabled, or possible crash without." * tag 'for-gkh' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma: IB/mlx5: Unmap DMA addr from HCA before IOMMU
-
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/inputGreg Kroah-Hartman authored
Dmitry writes: "Input updates for v4.19-rc7 - we added a few scheduling points into various input interfaces to ensure that large writes will not cause RCU stalls - fixed configuring PS/2 keyboards as wakeup devices on newer platforms - added a new Xbox gamepad ID." * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: Input: uinput - add a schedule point in uinput_inject_events() Input: evdev - add a schedule point in evdev_write() Input: mousedev - add a schedule point in mousedev_write() Input: i8042 - enable keyboard wakeups by default when s2idle is used Input: xpad - add support for Xbox1 PDP Camo series gamepad
-
git://git.kernel.org/pub/scm/linux/kernel/git/sfr/next-fixesGreg Kroah-Hartman authored
Stephen writes: "A couple of warning fixes: Two fixes from Peter Oberparleiter <oberpar@linux.ibm.com>: Commit 6b7dca40 ("tracing: Allow gcov profiling on only ftrace subsystem") uncovered linker problems when using gcov kernel profiling on some architectures. These problems were likely introduced earlier, and are possibly related to compiler changes." * tag 'next-fixes-20181012' of git://git.kernel.org/pub/scm/linux/kernel/git/sfr/next-fixes: vmlinux.lds.h: Fix linker warnings about orphan .LPBX sections vmlinux.lds.h: Fix incomplete .text.exit discards
-
Arnd Bergmann authored
The previous patch introduced very large kernel stack usage and a Makefile change to hide the warning about it. From what I can tell, a number of things went wrong here: - The BCH_MAX_T constant was set to the maximum value for 'n', not the maximum for 't', which is much smaller. - The stack usage is actually larger than the entire kernel stack on some architectures that can use 4KB stacks (m68k, sh, c6x), which leads to an immediate overrun. - The justification in the patch description claimed that nothing changed, however that is not the case even without the two points above: the configuration is machine specific, and most boards never use the maximum BCH_ECC_WORDS() length but instead have something much smaller. That maximum would only apply to machines that use both the maximum block size and the maximum ECC strength. The largest value for 't' that I could find is '32', which in turn leads to a 60 byte array instead of 2048 bytes. Making it '64' for future extension seems also worthwhile, with 120 bytes for the array. Anything larger won't fit into the OOB area on NAND flash. With that changed, the warning can be enabled again. Only linux-4.19+ contains the breakage, so this is only needed as a stable backport if it does not make it into the release. Fixes: 02361bc7 ("lib/bch: Remove VLA usage") Reported-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: stable@vger.kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
-