- Linux-stable-mirror - lists.linaro.org

[PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake

by ianwmorrison＠gmail.com

From: Ian W MORRISON <ianwmorrison(a)gmail.com> As the Geminilake firmware is now merged to linux-firmware.git use MODUE_FIRMWARE to load the firmware. This removes the error message in the dmesg log: i915 0000:00:02.0: Direct firmware load for i915/glk_dmc_ver1_04.bin failed with error -2 i915 0000:00:02.0: Failed to load DMC firmware i915/glk_dmc_ver1_04.bin. Disabling runtime power management. i915 0000:00:02.0: DMC firmware homepage: https://01.org/linuxgraphics/downloads/firmware and now shows that the firmware has correctly loaded: [drm] Finished loading DMC firmware i915/glk_dmc_ver1_04.bin (v1.4) Cc: stable(a)vger.kernel.org Signed-off-by: Ian W MORRISON <ianwmorrison(a)gmail.com> --- drivers/gpu/drm/i915/intel_csr.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c index 41e6c75a7f3c..f9550ea46c26 100644 --- a/drivers/gpu/drm/i915/intel_csr.c +++ b/drivers/gpu/drm/i915/intel_csr.c @@ -35,6 +35,7 @@ */ #define I915_CSR_GLK "i915/glk_dmc_ver1_04.bin" +MODULE_FIRMWARE(I915_CSR_GLK); #define GLK_CSR_VERSION_REQUIRED CSR_VERSION(1, 4) #define I915_CSR_CNL "i915/cnl_dmc_ver1_07.bin" -- 2.11.0

7 years, 7 months

1
0
0 0

Fwd: [tip:x86/urgent] x86/platform/UV: Fix critical UV MMR address error

by Mike Travis

This was sent to stable(a)vger.kernel.org almost 2 weeks ago and I haven't heard anything back yet. Is there any update on the status? (sorry for the bad formatting, this is the only way I can forward the email. I can only resend the original email before the commit email from Thomas.) Thanks. -------- Forwarded Message -------- Subject: [tip:x86/urgent] x86/platform/UV: Fix critical UV MMR address error Date: Wed, 28 Mar 2018 11:25:04 -0700 From: tip-bot for mike.travis(a)hpe.com <tipbot(a)zytor.com> Reply-To: andrew.banman(a)hpe.com, hpa(a)zytor.com, tglx(a)linutronix.de, mingo(a)kernel.org, russ.anderson(a)hpe.com, travis(a)sgi.com, linux-kernel(a)vger.kernel.org, mike.travis(a)hpe.com, dimitri.sivanich(a)hpe.com To: linux-tip-commits(a)vger.kernel.org CC: dimitri.sivanich(a)hpe.com, mike.travis(a)hpe.com, linux-kernel(a)vger.kernel.org, mingo(a)kernel.org, hpa(a)zytor.com, tglx(a)linutronix.de, andrew.banman(a)hpe.com, russ.anderson(a)hpe.com, travis(a)sgi.com Commit-ID: bd47a85acd727e27b7283daff557865ad04c59f6 Gitweb: https://git.kernel.org/tip/bd47a85acd727e27b7283daff557865ad04c59f6 Author: mike.travis(a)hpe.com <mike.travis(a)hpe.com> AuthorDate: Wed, 28 Mar 2018 12:40:11 -0500 Committer: Thomas Gleixner <tglx(a)linutronix.de> CommitDate: Wed, 28 Mar 2018 20:19:45 +0200 x86/platform/UV: Fix critical UV MMR address error A critical error was found testing the fixed UV4 HUB in that an MMR address was found to be incorrect. This causes the virtual address space for accessing the MMIOH1 region to be allocated with the incorrect size. Fixes: 673aa20c55a1 ("x86/platform/UV: Update uv_mmrs.h to prepare for UV4A fixes") Signed-off-by: Mike Travis <travis(a)sgi.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: Dimitri Sivanich <dimitri.sivanich(a)hpe.com> Cc: Russ Anderson <russ.anderson(a)hpe.com> Cc: Andrew Banman <andrew.banman(a)hpe.com> Link: https://lkml.kernel.org/r/20180328174011.041801248@stormcage.americas.sgi.c… --- arch/x86/include/asm/uv/uv_mmrs.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/include/asm/uv/uv_mmrs.h b/arch/x86/include/asm/uv/uv_mmrs.h index ecb9ddef128f..62c79e26a59a 100644 --- a/arch/x86/include/asm/uv/uv_mmrs.h +++ b/arch/x86/include/asm/uv/uv_mmrs.h @@ -3833,7 +3833,7 @@ union uvh_rh_gam_mmioh_overlay_config0_mmr_u { #define UV1H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR uv_undefined("UV1H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR") #define UV2H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR uv_undefined("UV2H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR") #define UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR 0x1603000UL -#define UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR 0x483000UL +#define UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR 0x484000UL #define UVH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR ( \ is_uv1_hub() ? UV1H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR : \ is_uv2_hub() ? UV2H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR : \

7 years, 7 months

2
3
0 0

+ ipc-shm-fix-use-after-free-of-shm-file-via-remap_file_pages.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: ipc/shm: fix use-after-free of shm file via remap_file_pages() has been added to the -mm tree. Its filename is ipc-shm-fix-use-after-free-of-shm-file-via-remap_file_pages.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/ipc-shm-fix-use-after-free-of-shm-… and later at http://ozlabs.org/~akpm/mmotm/broken-out/ipc-shm-fix-use-after-free-of-shm-… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Eric Biggers <ebiggers(a)google.com> Subject: ipc/shm: fix use-after-free of shm file via remap_file_pages() syzbot reported a use-after-free of shm_file_data(file)->file->f_op in shm_get_unmapped_area(), called via sys_remap_file_pages(). Unfortunately it couldn't generate a reproducer, but I found a bug which I think caused it. When remap_file_pages() is passed a full System V shared memory segment, the memory is first unmapped, then a new map is created using the ->vm_file. Between these steps, the shm ID can be removed and reused for a new shm segment. But, shm_mmap() only checks whether the ID is currently valid before calling the underlying file's ->mmap(); it doesn't check whether it was reused. Thus it can use the wrong underlying file, one that was already freed. Fix this by making the "outer" shm file (the one that gets put in ->vm_file) hold a reference to the real shm file, and by making __shm_open() require that the file associated with the shm ID matches the one associated with the "outer" file. Commit 1ac0b6dec656 ("ipc/shm: handle removed segments gracefully in shm_mmap()") almost fixed this bug, but it didn't go far enough because it didn't consider the case where the shm ID is reused. The following program usually reproduces this bug: #include <stdlib.h> #include <sys/shm.h> #include <sys/syscall.h> #include <unistd.h> int main() { int is_parent = (fork() != 0); srand(getpid()); for (;;) { int id = shmget(0xF00F, 4096, IPC_CREAT|0700); if (is_parent) { void *addr = shmat(id, NULL, 0); usleep(rand() % 50); while (!syscall(__NR_remap_file_pages, addr, 4096, 0, 0, 0)); } else { usleep(rand() % 50); shmctl(id, IPC_RMID, NULL); } } } It causes the following NULL pointer dereference due to a 'struct file' being used while it's being freed. (I couldn't actually get a KASAN use-after-free splat like in the syzbot report. But I think it's possible with this bug; it would just take a more extraordinary race...) BUG: unable to handle kernel NULL pointer dereference at 0000000000000058 PGD 0 P4D 0 Oops: 0000 [#1] SMP NOPTI CPU: 9 PID: 258 Comm: syz_ipc Not tainted 4.16.0-05140-gf8cf2f16a7c95 #189 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-20171110_100015-anatol 04/01/2014 RIP: 0010:d_inode include/linux/dcache.h:519 [inline] RIP: 0010:touch_atime+0x25/0xd0 fs/inode.c:1724 [...] Call Trace: file_accessed include/linux/fs.h:2063 [inline] shmem_mmap+0x25/0x40 mm/shmem.c:2149 call_mmap include/linux/fs.h:1789 [inline] shm_mmap+0x34/0x80 ipc/shm.c:465 call_mmap include/linux/fs.h:1789 [inline] mmap_region+0x309/0x5b0 mm/mmap.c:1712 do_mmap+0x294/0x4a0 mm/mmap.c:1483 do_mmap_pgoff include/linux/mm.h:2235 [inline] SYSC_remap_file_pages mm/mmap.c:2853 [inline] SyS_remap_file_pages+0x232/0x310 mm/mmap.c:2769 do_syscall_64+0x64/0x1a0 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x42/0xb7 Link: http://lkml.kernel.org/r/20180409043039.28915-1-ebiggers3@gmail.com Reported-by: syzbot+d11f321e7f1923157eac80aa990b446596f46439(a)syzkaller.appspotmail.com Fixes: c8d78c1823f4 ("mm: replace remap_file_pages() syscall with emulation") Signed-off-by: Eric Biggers <ebiggers(a)google.com> Cc: Davidlohr Bueso <dave(a)stgolabs.net> Cc: Manfred Spraul <manfred(a)colorfullife.com> Cc: "Eric W . Biederman" <ebiederm(a)xmission.com> Cc: "Kirill A. Shutemov" <kirill.shutemov(a)linux.intel.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- diff -puN ipc/shm.c~ipc-shm-fix-use-after-free-of-shm-file-via-remap_file_pages ipc/shm.c --- a/ipc/shm.c~ipc-shm-fix-use-after-free-of-shm-file-via-remap_file_pages +++ a/ipc/shm.c @@ -225,6 +225,12 @@ static int __shm_open(struct vm_area_str if (IS_ERR(shp)) return PTR_ERR(shp); + if (shp->shm_file != sfd->file) { + /* ID was reused */ + shm_unlock(shp); + return -EINVAL; + } + shp->shm_atim = ktime_get_real_seconds(); ipc_update_pid(&shp->shm_lprid, task_tgid(current)); shp->shm_nattch++; @@ -455,8 +461,9 @@ static int shm_mmap(struct file *file, s int ret; /* - * In case of remap_file_pages() emulation, the file can represent - * removed IPC ID: propogate shm_lock() error to caller. + * In case of remap_file_pages() emulation, the file can represent an + * IPC ID that was removed, and possibly even reused by another shm + * segment already. Propagate this case as an error to caller. */ ret = __shm_open(vma); if (ret) @@ -480,6 +487,7 @@ static int shm_release(struct inode *ino struct shm_file_data *sfd = shm_file_data(file); put_ipc_ns(sfd->ns); + fput(sfd->file); shm_file_data(file) = NULL; kfree(sfd); return 0; @@ -1432,7 +1440,7 @@ long do_shmat(int shmid, char __user *sh file->f_mapping = shp->shm_file->f_mapping; sfd->id = shp->shm_perm.id; sfd->ns = get_ipc_ns(ns); - sfd->file = shp->shm_file; + sfd->file = get_file(shp->shm_file); sfd->vm_ops = NULL; err = security_mmap_file(file, prot, flags); _ Patches currently in -mm which might be from ebiggers(a)google.com are ipc-shm-fix-use-after-free-of-shm-file-via-remap_file_pages.patch

7 years, 7 months

1
0
0 0

+ gup-return-efault-on-access_ok-failure.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: get_user_pages_fast(): return -EFAULT on access_ok failure has been added to the -mm tree. Its filename is gup-return-efault-on-access_ok-failure.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/gup-return-efault-on-access_ok-fai… and later at http://ozlabs.org/~akpm/mmotm/broken-out/gup-return-efault-on-access_ok-fai… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: "Michael S. Tsirkin" <mst(a)redhat.com> Subject: get_user_pages_fast(): return -EFAULT on access_ok failure get_user_pages_fast is supposed to be a faster drop-in equivalent of get_user_pages. As such, callers expect it to return a negative return code when passed an invalid address, and never expect it to return 0 when passed a positive number of pages, since its documentation says: * Returns number of pages pinned. This may be fewer than the number * requested. If nr_pages is 0 or negative, returns 0. If no pages * were pinned, returns -errno. When get_user_pages_fast fall back on get_user_pages this is exactly what happens. Unfortunately the implementation is inconsistent: it returns 0 if passed a kernel address, confusing callers: for example, the following is pretty common but does not appear to do the right thing with a kernel address: ret = get_user_pages_fast(addr, 1, writeable, &page); if (ret < 0) return ret; Change get_user_pages_fast to return -EFAULT when supplied a kernel address to make it match expectations. All callers have been audited for consistency with the documented semantics. Link: http://lkml.kernel.org/r/1522962072-182137-4-git-send-email-mst@redhat.com Fixes: 5b65c4677a57 ("mm, x86/mm: Fix performance regression in get_user_pages_fast()") Signed-off-by: Michael S. Tsirkin <mst(a)redhat.com> Reported-by: syzbot+6304bf97ef436580fede(a)syzkaller.appspotmail.com Reviewed-by: Andrew Morton <akpm(a)linux-foundation.org> Cc: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Cc: Huang Ying <ying.huang(a)intel.com> Cc: Jonathan Corbet <corbet(a)lwn.net> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Thorsten Leemhuis <regressions(a)leemhuis.info> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- diff -puN mm/gup.c~gup-return-efault-on-access_ok-failure mm/gup.c --- a/mm/gup.c~gup-return-efault-on-access_ok-failure +++ a/mm/gup.c @@ -1806,9 +1806,12 @@ int get_user_pages_fast(unsigned long st len = (unsigned long) nr_pages << PAGE_SHIFT; end = start + len; + if (nr_pages <= 0) + return 0; + if (unlikely(!access_ok(write ? VERIFY_WRITE : VERIFY_READ, (void __user *)start, len))) - return 0; + return -EFAULT; if (gup_fast_permitted(start, nr_pages, write)) { local_irq_disable(); _ Patches currently in -mm which might be from mst(a)redhat.com are mm-gup_benchmark-handle-gup-failures.patch gup-return-efault-on-access_ok-failure.patch mm-gup-document-return-value.patch

7 years, 7 months

1
0
0 0

+ mm-gup_benchmark-handle-gup-failures-fix.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm-gup_benchmark-handle-gup-failures-fix has been added to the -mm tree. Its filename is mm-gup_benchmark-handle-gup-failures-fix.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/mm-gup_benchmark-handle-gup-failur… and later at http://ozlabs.org/~akpm/mmotm/broken-out/mm-gup_benchmark-handle-gup-failur… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Andrew Morton <akpm(a)linux-foundation.org> Subject: mm-gup_benchmark-handle-gup-failures-fix Cc: Huang Ying <ying.huang(a)intel.com> Cc: Jonathan Corbet <corbet(a)lwn.net> Cc: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: "Michael S. Tsirkin" <mst(a)redhat.com> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: <stable(a)vger.kernel.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Thorsten Leemhuis <regressions(a)leemhuis.info> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- diff -puN mm/gup_benchmark.c~mm-gup_benchmark-handle-gup-failures-fix mm/gup_benchmark.c --- a/mm/gup_benchmark.c~mm-gup_benchmark-handle-gup-failures-fix +++ a/mm/gup_benchmark.c @@ -41,8 +41,9 @@ static int __gup_benchmark_ioctl(unsigne } nr = get_user_pages_fast(addr, nr, gup->flags & 1, pages + i); - if (nr > 0) - i += nr; + if (nr <= 0) + break; + i += nr; } end_time = ktime_get(); _ Patches currently in -mm which might be from akpm(a)linux-foundation.org are i-need-old-gcc.patch mm-gup_benchmark-handle-gup-failures-fix.patch arm-arch-arm-include-asm-pageh-needs-personalityh.patch ocfs2-without-quota-support-try-to-avoid-calling-quota-recovery-checkpatch-fixes.patch mm.patch z3fold-fix-memory-leak-fix.patch list_lru-prefetch-neighboring-list-entries-before-acquiring-lock-fix.patch mm-oom-cgroup-aware-oom-killer-fix.patch mm-oom-docs-describe-the-cgroup-aware-oom-killer-fix-2-fix.patch proc-add-seq_put_decimal_ull_width-to-speed-up-proc-pid-smaps-fix.patch fs-reiserfs-journalc-add-missing-resierfs_warning-arg.patch ipc-shmc-shm_split-remove-unneeded-test-for-null-shm_file_datavm_ops.patch linux-next-rejects.patch linux-next-git-rejects.patch linux-next-fixup.patch fs-fsnotify-account-fsnotify-metadata-to-kmemcg-fix.patch kernel-forkc-export-kernel_thread-to-modules.patch slab-leaks3-default-y.patch

7 years, 7 months

1
0
0 0

+ mm-gup_benchmark-handle-gup-failures.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm/gup_benchmark: handle gup failures has been added to the -mm tree. Its filename is mm-gup_benchmark-handle-gup-failures.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/mm-gup_benchmark-handle-gup-failur… and later at http://ozlabs.org/~akpm/mmotm/broken-out/mm-gup_benchmark-handle-gup-failur… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: "Michael S. Tsirkin" <mst(a)redhat.com> Subject: mm/gup_benchmark: handle gup failures Patch series "mm/get_user_pages_fast fixes, cleanups", v2. Turns out get_user_pages_fast and __get_user_pages_fast return different values on error when given a single page: __get_user_pages_fast returns 0. get_user_pages_fast returns either 0 or an error. Callers of get_user_pages_fast expect an error so fix it up to return an error consistently. Stress the difference between get_user_pages_fast and __get_user_pages_fast to make sure callers aren't confused. This patch (of 3): __gup_benchmark_ioctl does not handle the case where get_user_pages_fast fails: - a negative return code will cause a buffer overrun - returning with partial success will cause use of uninitialized memory. Link: http://lkml.kernel.org/r/1522962072-182137-3-git-send-email-mst@redhat.com Signed-off-by: Michael S. Tsirkin <mst(a)redhat.com> Reviewed-by: Andrew Morton <akpm(a)linux-foundation.org> Cc: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Cc: Huang Ying <ying.huang(a)intel.com> Cc: Jonathan Corbet <corbet(a)lwn.net> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Thorsten Leemhuis <regressions(a)leemhuis.info> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- diff -puN mm/gup_benchmark.c~mm-gup_benchmark-handle-gup-failures mm/gup_benchmark.c --- a/mm/gup_benchmark.c~mm-gup_benchmark-handle-gup-failures +++ a/mm/gup_benchmark.c @@ -23,7 +23,7 @@ static int __gup_benchmark_ioctl(unsigne struct page **pages; nr_pages = gup->size / PAGE_SIZE; - pages = kvmalloc(sizeof(void *) * nr_pages, GFP_KERNEL); + pages = kvzalloc(sizeof(void *) * nr_pages, GFP_KERNEL); if (!pages) return -ENOMEM; @@ -41,7 +41,8 @@ static int __gup_benchmark_ioctl(unsigne } nr = get_user_pages_fast(addr, nr, gup->flags & 1, pages + i); - i += nr; + if (nr > 0) + i += nr; } end_time = ktime_get(); _ Patches currently in -mm which might be from mst(a)redhat.com are mm-gup_benchmark-handle-gup-failures.patch gup-return-efault-on-access_ok-failure.patch mm-gup-document-return-value.patch

7 years, 7 months

1
0
0 0

[PATCH v2 1/3] mm/gup_benchmark: handle gup failures

by Michael S. Tsirkin

__gup_benchmark_ioctl does not handle the case where get_user_pages_fast fails: - a negative return code will cause a buffer overrun - returning with partial success will cause use of uninitialized memory. Cc: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Huang Ying <ying.huang(a)intel.com> Cc: Jonathan Corbet <corbet(a)lwn.net> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Thorsten Leemhuis <regressions(a)leemhuis.info> Cc: stable(a)vger.kernel.org Signed-off-by: Michael S. Tsirkin <mst(a)redhat.com> --- mm/gup_benchmark.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/mm/gup_benchmark.c b/mm/gup_benchmark.c index 5c8e2ab..d743035 100644 --- a/mm/gup_benchmark.c +++ b/mm/gup_benchmark.c @@ -23,7 +23,7 @@ static int __gup_benchmark_ioctl(unsigned int cmd, struct page **pages; nr_pages = gup->size / PAGE_SIZE; - pages = kvmalloc(sizeof(void *) * nr_pages, GFP_KERNEL); + pages = kvzalloc(sizeof(void *) * nr_pages, GFP_KERNEL); if (!pages) return -ENOMEM; @@ -41,7 +41,8 @@ static int __gup_benchmark_ioctl(unsigned int cmd, } nr = get_user_pages_fast(addr, nr, gup->flags & 1, pages + i); - i += nr; + if (nr > 0) + i += nr; } end_time = ktime_get(); -- MST

7 years, 7 months

3
3
0 0

+ resource-fix-integer-overflow-at-reallocation.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: resource: fix integer overflow at reallocation has been added to the -mm tree. Its filename is resource-fix-integer-overflow-at-reallocation.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/resource-fix-integer-overflow-at-r… and later at http://ozlabs.org/~akpm/mmotm/broken-out/resource-fix-integer-overflow-at-r… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Takashi Iwai <tiwai(a)suse.de> Subject: resource: fix integer overflow at reallocation We've got a bug report indicating a kernel panic at booting on an x86-32 system, and it turned out to be the invalid resource assigned after PCI resource reallocation. __find_resource() first aligns the resource start address and resets the end address with start+size-1 accordingly, then checks whether it's contained. Here the end address may overflow the integer, although resource_contains() still returns true because the function validates only start and end address. So this ends up with returning an invalid resource (start > end). There was already an attempt to cover such a problem in the commit 47ea91b4052d ("Resource: fix wrong resource window calculation"), but this case is an overseen one. This patch adds the validity check in resource_contains() to see whether the given resource has a valid range for avoiding the integer overflow problem. Bugzilla: http://bugzilla.opensuse.org/show_bug.cgi?id=1086739 Link: http://lkml.kernel.org/r/20180408072026.27365-1-tiwai@suse.de Fixes: 23c570a67448 ("resource: ability to resize an allocated resource") Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Reported-by: Michael Henders <hendersm(a)shaw.ca> Tested-by: Michael Henders <hendersm(a)shaw.ca> Reviewed-by: Ram Pai <linuxram(a)us.ibm.com> Cc: Bjorn Helgaas <bhelgaas(a)google.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- diff -puN include/linux/ioport.h~resource-fix-integer-overflow-at-reallocation include/linux/ioport.h --- a/include/linux/ioport.h~resource-fix-integer-overflow-at-reallocation +++ a/include/linux/ioport.h @@ -212,6 +212,9 @@ static inline bool resource_contains(str return false; if (r1->flags & IORESOURCE_UNSET || r2->flags & IORESOURCE_UNSET) return false; + /* sanity check whether it's a valid resource range */ + if (r2->end < r2->start) + return false; return r1->start <= r2->start && r1->end >= r2->end; } _ Patches currently in -mm which might be from tiwai(a)suse.de are resource-fix-integer-overflow-at-reallocation.patch

7 years, 7 months

1
0
0 0

[merged] mm-hwpoison-disable-memory-error-handling-on-1gb-hugepage.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm: hwpoison: disable memory error handling on 1GB hugepage has been removed from the -mm tree. Its filename was mm-hwpoison-disable-memory-error-handling-on-1gb-hugepage.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Naoya Horiguchi <n-horiguchi(a)ah.jp.nec.com> Subject: mm: hwpoison: disable memory error handling on 1GB hugepage Recently the following BUG was reported: Injecting memory failure for pfn 0x3c0000 at process virtual address 0x7fe300000000 Memory failure: 0x3c0000: recovery action for huge page: Recovered BUG: unable to handle kernel paging request at ffff8dfcc0003000 IP: gup_pgd_range+0x1f0/0xc20 PGD 17ae72067 P4D 17ae72067 PUD 0 Oops: 0000 [#1] SMP PTI ... CPU: 3 PID: 5467 Comm: hugetlb_1gb Not tainted 4.15.0-rc8-mm1-abc+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.3-1.fc25 04/01/2014 You can easily reproduce this by calling madvise(MADV_HWPOISON) twice on a 1GB hugepage. This happens because get_user_pages_fast() is not aware of a migration entry on pud that was created in the 1st madvise() event. I think that conversion to pud-aligned migration entry is working, but other MM code walking over page table isn't prepared for it. We need some time and effort to make all this work properly, so this patch avoids the reported bug by just disabling error handling for 1GB hugepage. [n-horiguchi(a)ah.jp.nec.com: v2] Link: http://lkml.kernel.org/r/1517284444-18149-1-git-send-email-n-horiguchi@ah.j… Link: http://lkml.kernel.org/r/1517207283-15769-1-git-send-email-n-horiguchi@ah.j… Signed-off-by: Naoya Horiguchi <n-horiguchi(a)ah.jp.nec.com> Acked-by: Michal Hocko <mhocko(a)suse.com> Reviewed-by: Andrew Morton <akpm(a)linux-foundation.org> Reviewed-by: Mike Kravetz <mike.kravetz(a)oracle.com> Acked-by: Punit Agrawal <punit.agrawal(a)arm.com> Tested-by: Michael Ellerman <mpe(a)ellerman.id.au> Cc: Anshuman Khandual <khandual(a)linux.vnet.ibm.com> Cc: "Aneesh Kumar K.V" <aneesh.kumar(a)linux.vnet.ibm.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- include/linux/mm.h | 1 + mm/memory-failure.c | 16 ++++++++++++++++ 2 files changed, 17 insertions(+) diff -puN include/linux/mm.h~mm-hwpoison-disable-memory-error-handling-on-1gb-hugepage include/linux/mm.h --- a/include/linux/mm.h~mm-hwpoison-disable-memory-error-handling-on-1gb-hugepage +++ a/include/linux/mm.h @@ -2613,6 +2613,7 @@ enum mf_action_page_type { MF_MSG_POISONED_HUGE, MF_MSG_HUGE, MF_MSG_FREE_HUGE, + MF_MSG_NON_PMD_HUGE, MF_MSG_UNMAP_FAILED, MF_MSG_DIRTY_SWAPCACHE, MF_MSG_CLEAN_SWAPCACHE, diff -puN mm/memory-failure.c~mm-hwpoison-disable-memory-error-handling-on-1gb-hugepage mm/memory-failure.c --- a/mm/memory-failure.c~mm-hwpoison-disable-memory-error-handling-on-1gb-hugepage +++ a/mm/memory-failure.c @@ -502,6 +502,7 @@ static const char * const action_page_ty [MF_MSG_POISONED_HUGE] = "huge page already hardware poisoned", [MF_MSG_HUGE] = "huge page", [MF_MSG_FREE_HUGE] = "free huge page", + [MF_MSG_NON_PMD_HUGE] = "non-pmd-sized huge page", [MF_MSG_UNMAP_FAILED] = "unmapping failed page", [MF_MSG_DIRTY_SWAPCACHE] = "dirty swapcache page", [MF_MSG_CLEAN_SWAPCACHE] = "clean swapcache page", @@ -1084,6 +1085,21 @@ static int memory_failure_hugetlb(unsign return 0; } + /* + * TODO: hwpoison for pud-sized hugetlb doesn't work right now, so + * simply disable it. In order to make it work properly, we need + * make sure that: + * - conversion of a pud that maps an error hugetlb into hwpoison + * entry properly works, and + * - other mm code walking over page table is aware of pud-aligned + * hwpoison entries. + */ + if (huge_page_size(page_hstate(head)) > PMD_SIZE) { + action_result(pfn, MF_MSG_NON_PMD_HUGE, MF_IGNORED); + res = -EBUSY; + goto out; + } + if (!hwpoison_user_mappings(p, pfn, flags, &head)) { action_result(pfn, MF_MSG_UNMAP_FAILED, MF_IGNORED); res = -EBUSY; _ Patches currently in -mm which might be from n-horiguchi(a)ah.jp.nec.com are

7 years, 7 months

1
0
0 0

[merged] lib-fix-stall-in-__bitmap_parselist.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: lib: fix stall in __bitmap_parselist() has been removed from the -mm tree. Its filename was lib-fix-stall-in-__bitmap_parselist.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Yury Norov <ynorov(a)caviumnetworks.com> Subject: lib: fix stall in __bitmap_parselist() syzbot is catching stalls at __bitmap_parselist() (https://syzkaller.appspot.com/bug?id=ad7e0351fbc90535558514a71cd3edc1168199…). The trigger is unsigned long v = 0; bitmap_parselist("7:,", &v, BITS_PER_LONG); which results in hitting infinite loop at while (a <= b) { off = min(b - a + 1, used_size); bitmap_set(maskp, a, off); a += group_size; } due to used_size == group_size == 0. Link: http://lkml.kernel.org/r/20180404162647.15763-1-ynorov@caviumnetworks.com Fixes: 0a5ce0831d04382a ("lib/bitmap.c: make bitmap_parselist() thread-safe and much faster") Signed-off-by: Yury Norov <ynorov(a)caviumnetworks.com> Reported-by: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp> Reported-by: syzbot <syzbot+6887cbb011c8054e8a3d(a)syzkaller.appspotmail.com> Cc: Noam Camus <noamca(a)mellanox.com> Cc: Rasmus Villemoes <linux(a)rasmusvillemoes.dk> Cc: Matthew Wilcox <mawilcox(a)microsoft.com> Cc: Mauro Carvalho Chehab <mchehab(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- lib/bitmap.c | 2 +- lib/test_bitmap.c | 4 ++++ 2 files changed, 5 insertions(+), 1 deletion(-) diff -puN lib/bitmap.c~lib-fix-stall-in-__bitmap_parselist lib/bitmap.c --- a/lib/bitmap.c~lib-fix-stall-in-__bitmap_parselist +++ a/lib/bitmap.c @@ -607,7 +607,7 @@ static int __bitmap_parselist(const char /* if no digit is after '-', it's wrong*/ if (at_start && in_range) return -EINVAL; - if (!(a <= b) || !(used_size <= group_size)) + if (!(a <= b) || group_size == 0 || !(used_size <= group_size)) return -EINVAL; if (b >= nmaskbits) return -ERANGE; diff -puN lib/test_bitmap.c~lib-fix-stall-in-__bitmap_parselist lib/test_bitmap.c --- a/lib/test_bitmap.c~lib-fix-stall-in-__bitmap_parselist +++ a/lib/test_bitmap.c @@ -255,6 +255,10 @@ static const struct test_bitmap_parselis {-EINVAL, "-1", NULL, 8, 0}, {-EINVAL, "-0", NULL, 8, 0}, {-EINVAL, "10-1", NULL, 8, 0}, + {-EINVAL, "0-31:", NULL, 8, 0}, + {-EINVAL, "0-31:0", NULL, 8, 0}, + {-EINVAL, "0-31:0/0", NULL, 8, 0}, + {-EINVAL, "0-31:1/0", NULL, 8, 0}, {-EINVAL, "0-31:10/1", NULL, 8, 0}, }; _ Patches currently in -mm which might be from ynorov(a)caviumnetworks.com are

7 years, 7 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror