April 2018 - Linux-stable-mirror

[merged] mm-slab-reschedule-cache_reap-on-the-same-cpu.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm, slab: reschedule cache_reap() on the same CPU has been removed from the -mm tree. Its filename was mm-slab-reschedule-cache_reap-on-the-same-cpu.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Vlastimil Babka <vbabka(a)suse.cz> Subject: mm, slab: reschedule cache_reap() on the same CPU cache_reap() is initially scheduled in start_cpu_timer() via schedule_delayed_work_on(). But then the next iterations are scheduled via schedule_delayed_work(), i.e. using WORK_CPU_UNBOUND. Thus since commit ef557180447f ("workqueue: schedule WORK_CPU_UNBOUND work on wq_unbound_cpumask CPUs") there is no guarantee the future iterations will run on the originally intended cpu, although it's still preferred. I was able to demonstrate this with /sys/module/workqueue/parameters/debug_force_rr_cpu. IIUC, it may also happen due to migrating timers in nohz context. As a result, some cpu's would be calling cache_reap() more frequently and others never. This patch uses schedule_delayed_work_on() with the current cpu when scheduling the next iteration. Link: http://lkml.kernel.org/r/20180411070007.32225-1-vbabka@suse.cz Fixes: ef557180447f ("workqueue: schedule WORK_CPU_UNBOUND work on wq_unbound_cpumask CPUs") Signed-off-by: Vlastimil Babka <vbabka(a)suse.cz> Acked-by: Pekka Enberg <penberg(a)kernel.org> Acked-by: Christoph Lameter <cl(a)linux.com> Cc: Joonsoo Kim <iamjoonsoo.kim(a)lge.com> Cc: David Rientjes <rientjes(a)google.com> Cc: Tejun Heo <tj(a)kernel.org> Cc: Lai Jiangshan <jiangshanlai(a)gmail.com> Cc: John Stultz <john.stultz(a)linaro.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Stephen Boyd <sboyd(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/slab.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff -puN mm/slab.c~mm-slab-reschedule-cache_reap-on-the-same-cpu mm/slab.c --- a/mm/slab.c~mm-slab-reschedule-cache_reap-on-the-same-cpu +++ a/mm/slab.c @@ -4086,7 +4086,8 @@ next: next_reap_node(); out: /* Set up the next iteration */ - schedule_delayed_work(work, round_jiffies_relative(REAPTIMEOUT_AC)); + schedule_delayed_work_on(smp_processor_id(), work, + round_jiffies_relative(REAPTIMEOUT_AC)); } void get_slabinfo(struct kmem_cache *cachep, struct slabinfo *sinfo) _ Patches currently in -mm which might be from vbabka(a)suse.cz are

6 years, 9 months

1
0
0 0

[merged] ipc-shm-fix-use-after-free-of-shm-file-via-remap_file_pages.patch removed from -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 removed from the -mm tree. Its filename was ipc-shm-fix-use-after-free-of-shm-file-via-remap_file_pages.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ 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. Taking the reference to the real shm file is needed to fully solve the problem, since otherwise sfd->file could point to a freed file, which then could be reallocated for the reused shm ID, causing the wrong shm segment to be mapped (and without the required permission checks). 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 [ebiggers(a)google.com: add comment] Link: http://lkml.kernel.org/r/20180410192850.235835-1-ebiggers3@gmail.com 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> Acked-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Acked-by: Davidlohr Bueso <dbueso(a)suse.de> Cc: Manfred Spraul <manfred(a)colorfullife.com> Cc: "Eric W . Biederman" <ebiederm(a)xmission.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- ipc/shm.c | 23 ++++++++++++++++++++--- 1 file changed, 20 insertions(+), 3 deletions(-) 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; @@ -1445,7 +1453,16 @@ 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; + /* + * We need to take a reference to the real shm file to prevent the + * pointer from becoming stale in cases where the lifetime of the outer + * file extends beyond that of the shm segment. It's not usually + * possible, but it can happen during remap_file_pages() emulation as + * that unmaps the memory, then does ->mmap() via file reference only. + * We'll deny the ->mmap() if the shm segment was since removed, but to + * detect shm ID reuse we need to compare the file pointers. + */ + 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

6 years, 9 months

1
0
0 0

[merged] gup-return-efault-on-access_ok-failure.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: get_user_pages_fast(): return -EFAULT on access_ok failure has been removed from the -mm tree. Its filename was gup-return-efault-on-access_ok-failure.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ 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> --- mm/gup.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) 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

6 years, 9 months

1
0
0 0

[merged] mm-gup_benchmark-handle-gup-failures.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm/gup_benchmark: handle gup failures has been removed from the -mm tree. Its filename was mm-gup_benchmark-handle-gup-failures.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ 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. [akpm(a)linux-foundation.org: simplification] 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> --- mm/gup_benchmark.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) 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,6 +41,8 @@ static int __gup_benchmark_ioctl(unsigne } nr = get_user_pages_fast(addr, nr, gup->flags & 1, pages + i); + if (nr <= 0) + break; i += nr; } end_time = ktime_get(); _ Patches currently in -mm which might be from mst(a)redhat.com are

6 years, 9 months

1
0
0 0

[merged] resource-fix-integer-overflow-at-reallocation-v1.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: resource: fix integer overflow at reallocation has been removed from the -mm tree. Its filename was resource-fix-integer-overflow-at-reallocation-v1.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ 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 PCI resource assigned after 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 of the newly calculated resource for avoiding the integer overflow problem. Bugzilla: http://bugzilla.opensuse.org/show_bug.cgi?id=1086739 Link: http://lkml.kernel.org/r/s5hpo37d5l8.wl-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: Andrew Morton <akpm(a)linux-foundation.org> Cc: 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> --- kernel/resource.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff -puN kernel/resource.c~resource-fix-integer-overflow-at-reallocation-v1 kernel/resource.c --- a/kernel/resource.c~resource-fix-integer-overflow-at-reallocation-v1 +++ a/kernel/resource.c @@ -651,7 +651,8 @@ static int __find_resource(struct resour alloc.start = constraint->alignf(constraint->alignf_data, &avail, size, constraint->align); alloc.end = alloc.start + size - 1; - if (resource_contains(&avail, &alloc)) { + if (alloc.start <= alloc.end && + resource_contains(&avail, &alloc)) { new->start = alloc.start; new->end = alloc.end; return 0; _ Patches currently in -mm which might be from tiwai(a)suse.de are

6 years, 9 months

1
0
0 0

[PATCH] drm/amd/display: Disable CRTC if primary plane has no FB

by Harry Wentland

This commit teaches DM to deal with a change of behavior with drm_atomic_remove_fb. It no longer disable CRTC with NULL FB on their primary plane: (846c7dfc1193 drm/atomic: Try to preserve the crtc enabled state in drm_atomic_remove_fb, v2.) DC/DM is currently not fully setup to simply stop scanout from the primary plane (and blank the crtc), so we'll disable the CRTC in this case. Signed-off-by: Harry Wentland <harry.wentland(a)amd.com> Cc: stable(a)vger.kernel.org --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index 6f92a19bebd6..c1b1c5931a01 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -4683,6 +4683,7 @@ static int dm_update_crtcs_state(struct amdgpu_display_manager *dm, struct amdgpu_dm_connector *aconnector = NULL; struct drm_connector_state *new_con_state = NULL; struct dm_connector_state *dm_conn_state = NULL; + struct drm_plane_state *new_plane_state = NULL; new_stream = NULL; @@ -4736,6 +4737,11 @@ static int dm_update_crtcs_state(struct amdgpu_display_manager *dm, if (dm_old_crtc_state->freesync_enabled != dm_new_crtc_state->freesync_enabled) new_crtc_state->mode_changed = true; + new_plane_state = drm_atomic_get_new_plane_state(state, new_crtc_state->crtc->primary); + + if (new_plane_state && !new_plane_state->fb) + new_crtc_state->mode_changed = true; + if (!drm_atomic_crtc_needs_modeset(new_crtc_state)) goto next_crtc; @@ -4783,6 +4789,9 @@ static int dm_update_crtcs_state(struct amdgpu_display_manager *dm, if (!aconnector || (!aconnector->dc_sink && aconnector->mst_port)) goto next_crtc; + if (new_plane_state && !new_plane_state->fb) + goto next_crtc; + if (modereset_required(new_crtc_state)) goto next_crtc; @@ -4894,7 +4903,7 @@ static int dm_update_planes_state(struct dc *dc, if (!dm_old_crtc_state->stream) continue; - DRM_DEBUG_DRIVER("Disabling DRM plane: %d on DRM crtc %d\n", + DRM_DEBUG_ATOMIC("Disabling DRM plane: %d on DRM crtc %d\n", plane->base.id, old_plane_crtc->base.id); if (!dc_remove_plane_from_context( -- 2.17.0

6 years, 9 months

1
0
0 0

kernel 4.14.x crash around fsnotify_mark_connector

by Pavlos Parissis

Hi, In one of our production servers where we run kernel version 4.14.32, I noticed the following: ---- [138630.417246] cache_from_obj: Wrong slab cache. fsnotify_mark_connector but object is from kmalloc-2048(361:anycast-healthchecker.service) [138630.477075] ------------[ cut here ]------------ [138630.500028] WARNING: CPU: 14 PID: 26002 at mm/slab.h:377 kmem_cache_free+0x133/0x1c0 [138630.538130] Modules linked in: netconsole binfmt_misc sctp_diag sctp dccp_diag dccp tcp_diag udp_diag inet_diag unix_diag cfg80211 rfkill 8021q garp mrp xfs loop x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel crypto_simd glue_helper cryptd iTCO_wdt intel_cstate hpwdt hpilo iTCO_vendor_support sg intel_rapl_perf ipmi_si pcspkr ioatdma shpchp lpc_ich i2c_i801 ipmi_devintf dca mfd_core wmi ipmi_msghandler nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables ext4 mbcache jbd2 i2c_algo_bit sd_mod drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm bnx2x serio_raw mdio libcrc32c crc32c_intel hpsa ptp drm scsi_transport_sas pps_core dm_mirror dm_region_hash dm_log dm_mod dax [138630.871763] CPU: 14 PID: 26002 Comm: kworker/u66:3 Not tainted 4.14.32-1.el7.x86_64 #1 [138630.910864] Hardware name: HP ProLiant BL460c Gen9, BIOS I36 10/25/2017 [138630.943498] Workqueue: events_unbound fsnotify_connector_destroy_workfn [138630.976569] task: ffff88203b62ae80 task.stack: ffffc90008a20000 [138631.005895] RIP: 0010:kmem_cache_free+0x133/0x1c0 [138631.029230] RSP: 0018:ffffc90008a23e20 EFLAGS: 00010246 [138631.055217] RAX: 000000000000007c RBX: ffff882000000000 RCX: 0000000000000000 [138631.091346] RDX: 0000000000000000 RSI: ffff88203f3969d8 RDI: ffff88203f3969d8 [138631.127139] RBP: ffffc90008a23e38 R08: 0000000000000001 R09: 000000000000057d [138631.162575] R10: ffff88102b906cf0 R11: ffff88102b913ea0 R12: ffff88103f579980 [138631.198018] R13: ffff88203bd57c00 R14: ffff88203bd63f00 R15: ffffffff82128388 [138631.233371] FS: 0000000000000000(0000) GS:ffff88203f380000(0000) knlGS:0000000000000000 [138631.273426] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [138631.301980] CR2: 0000000003600fd8 CR3: 000000000200a006 CR4: 00000000003606e0 [138631.338783] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [138631.374525] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [138631.409797] Call Trace: [138631.422387] fsnotify_connector_destroy_workfn+0x68/0x80 [138631.448516] process_one_work+0x15c/0x380 [138631.468352] worker_thread+0x4d/0x3e0 [138631.486705] kthread+0x10c/0x140 [138631.503091] ? max_active_store+0x80/0x80 [138631.523217] ? __kthread_parkme+0x70/0x70 [138631.543338] ? do_syscall_64+0x79/0x1b0 [138631.562518] ret_from_fork+0x35/0x40 [138631.580199] Code: 4c 3b a7 d8 00 00 00 0f 84 11 ff ff ff 48 8b 4f 60 49 8b 54 24 60 48 c7 c6 c0 19 c3 81 48 c7 c7 c0 9c e7 81 31 c0 e8 90 a5 eb ff <0f> 0b4c 89 e7 e9 e9 fe ff ff 65 8b 05 2c 3c de 7e 89 c0 48 0f [138631.672489] ---[ end trace 6748d86d682915c2 ]--- [138631.695691] cache_from_obj: Wrong slab cache. fsnotify_mark_connector but object is from kmalloc-2048(361:anycast-healthchecker.service) --- The kernel was fine and server was responsive. A coworker mentioned that it may come from https://github.com/torvalds/linux/blob/master/fs/notify/mark.c#L160 and commit 08991e83b728 ("fsnotify: Free fsnotify_mark_connector when there is no mark attached") arrived with 4.12-rc1 may be the cause of it. I am wondering if it is related to the issue I reported https://lkml.org/lkml/2018/4/16/506. But, that issue causes the whole server to crash, which is not the case for above kernel dump. Cheers, Pavlos

6 years, 9 months

2
4
0 0

[PATCH 2/2] MIPS: memset.S: Fix return of __clear_user from Lpartial_fixup

by Matt Redfearn

The __clear_user function is defined to return the number of bytes that could not be cleared. From the underlying memset / bzero implementation this means setting register a2 to that number on return. Currently if a page fault is triggered within the memset_partial block, the value loaded into a2 on return is meaningless. The label .Lpartial_fixup\@ is jumped to on page fault. Currently it masks the remaining count of bytes (a2) with STORMASK, meaning that the least significant 2 (32bit) or 3 (64bit) bits of the remaining count are always clear. Secondly, .Lpartial_fixup\@ expects t1 to contain the end address of the copy. This is set up by the initial block: PTR_ADDU t1, a0 /* end address */ However, the .Lmemset_partial\@ block then reuses register t1 to calculate a jump through a block of word copies. This leaves it no longer containing the end address of the copy operation if a page fault occurs, and the remaining bytes calculation is incorrect. Fix these issues by removing the and of a2 with STORMASK, and replace t1 with register t2 in the .Lmemset_partial\@ block. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable(a)vger.kernel.org Signed-off-by: Matt Redfearn <matt.redfearn(a)mips.com> --- arch/mips/lib/memset.S | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/arch/mips/lib/memset.S b/arch/mips/lib/memset.S index 90bcdf1224ee..3257dca58cad 100644 --- a/arch/mips/lib/memset.S +++ b/arch/mips/lib/memset.S @@ -161,19 +161,19 @@ .Lmemset_partial\@: R10KCBARRIER(0(ra)) - PTR_LA t1, 2f /* where to start */ + PTR_LA t2, 2f /* where to start */ #ifdef CONFIG_CPU_MICROMIPS LONG_SRL t7, t0, 1 #endif #if LONGSIZE == 4 - PTR_SUBU t1, FILLPTRG + PTR_SUBU t2, FILLPTRG #else .set noat LONG_SRL AT, FILLPTRG, 1 - PTR_SUBU t1, AT + PTR_SUBU t2, AT .set at #endif - jr t1 + jr t2 PTR_ADDU a0, t0 /* dest ptr */ .set push @@ -250,7 +250,6 @@ .Lpartial_fixup\@: PTR_L t0, TI_TASK($28) - andi a2, STORMASK LONG_L t0, THREAD_BUADDR(t0) LONG_ADDU a2, t1 jr ra -- 2.7.4

6 years, 9 months

2
5
0 0

[REGRESSION] [v2] ACPI / video: Default lcd_only to true on Win8 ready and newer machines

by James Hogan

On Sat, Dec 23, 2017 at 07:41:47PM +0100, Hans de Goede wrote: > We're seeing a lot of bogus backlight interfaces on newer machines without > a LCD such as desktops, servers and HDMI sticks. This causes userspace to > show a non-functional brightness slider in e.g. the GNOME3 system menu, > which is undesirable. More in general we should simply just not register > a non functional backlight interface. > > Checking the lcd flag causes the bogus acpi_video backlight interfaces to > go away (on the machines this was tested on). > > This commit enables the lcd_only option by default on any machines which > are win8 ready, fixing this. > > This is not entirely without risk of regressions, but video_detect.c > already prefers native-backlight interfaces over the acpi_video one > on win8 ready machines, calling acpi_video_unregister_backlight() as soon > as a native interface shows up. This is done because the acpi backlight > interface often is broken on win8 ready machines, because win8 does not > seem to actually use it. This patch (in the form of commit 965736ee654d ("ACPI / video: Default lcd_only to true on Win8-ready and newer machines") in stable v4.15.17), breaks backlight control on my 2013 XPS13 laptop. It normally uses the acpi backlight device, but after this patch that device no longer shows up in sysfs. This isn't the first time the backlight has gotton broken on this system, though I think last time it was because the intel backlight driver got used instead of the ACPI one and that didn't work properly with it, so it needed a quirk to make it use ACPI instead. Is some other quirk needed around here too? Cheers James

6 years, 9 months

2
5
0 0

[PATCH] target: Fix Fortify_panic kernel exception

by Bryant G. Ly

[ 496.212783] ------------[ cut here ]------------ [ 496.212784] kernel BUG at /build/linux-hwe-edge-ojNirv/linux-hwe-edge-4.15.0/lib/string.c:1052! [ 496.212789] Oops: Exception in kernel mode, sig: 5 [#1] [ 496.212791] LE SMP NR_CPUS=2048 NUMA pSeries [ 496.212795] Modules linked in: hvcs(OE) hvcserver dm_snapshot dm_bufio rpadlpar_io rpaphp ip6table_raw xt_CT xt_mac xt_tcpudp xt_comment xt_physdev xt_set ip_set_hash_net ip_set iptable_raw dccp_diag dccp tcp_diag udp_diag inet_diag unix_diag af_packet_diag netlink_diag target_core_pscsi(OE) target_core_file(OE) target_core_iblock(OE) iscsi_target_mod(OE) vxlan ip6_udp_tunnel udp_tunnel openvswitch nsh nf_nat_ipv6 target_core_user(OE) uio binfmt_misc xt_conntrack nf_conntrack_netlink nfnetlink nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_ipv6 nf_defrag_ipv6 nbd ipt_REJECT nf_reject_ipv4 ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 pseries_rng nf_nat ibmvmc(OE) nf_conntrack libcrc32c vmx_crypto crct10dif_vpmsum iptable_mangle iptable_filter [ 496.212854] ip_tables ip6table_filter ip6_tables ebtables x_tables br_netfilter bridge stp llc ib_iser rdma_cm iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi autofs4 mlx4_en ses enclosure scsi_transport_sas uas usb_storage ibmvscsis(OE) target_core_mod(OE) ibmveth(OE) mlx5_core mlx4_core mlxfw crc32c_vpmsum be2net tg3 ipr devlink [ 496.212888] CPU: 1 PID: 2587 Comm: kworker/1:2 Tainted: G OE 4.15.0-15-generic #16~16.04.1-Ubuntu [ 496.212897] Workqueue: ibmvscsis3000000f ibmvscsis_scheduler [ibmvscsis] [ 496.212900] NIP: c000000000cbbf00 LR: c000000000cbbefc CTR: 0000000000655170 [ 496.212903] REGS: c0000007e58e3580 TRAP: 0700 Tainted: G OE (4.15.0-15-generic) [ 496.212906] MSR: 800000000282b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 286c2222 XER: 20000003 [ 496.212915] CFAR: c00000000018d634 SOFTE: 1 GPR00: c000000000cbbefc c0000007e58e3800 c0000000016bae00 0000000000000022 GPR04: c0000007fe94ce18 c0000007fe964368 0000000000000003 ffffffffffffffff GPR08: 0000000000000007 c000000001193a74 00000007fd7c0000 0000000000003986 GPR12: 0000000000002200 c00000000fa80b00 c00000000013a308 c0000007f48adb00 GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR20: 0000000000000000 0000000000000000 fffffffffffffef7 0000000000000402 GPR24: 0000000000000000 f000000001a8cb40 00000000000003f0 0000000000648010 GPR28: c0000005a360a570 c0000007f4095880 c0000000fc9e7e00 c0000007f1f56000 [ 496.212952] NIP [c000000000cbbf00] fortify_panic+0x28/0x38 [ 496.212956] LR [c000000000cbbefc] fortify_panic+0x24/0x38 [ 496.212958] Call Trace: [ 496.212960] [c0000007e58e3800] [c000000000cbbefc] fortify_panic+0x24/0x38 (unreliable) [ 496.212965] [c0000007e58e3860] [d00000000f150c28] iblock_execute_write_same+0x3b8/0x3c0 [target_core_iblock] [ 496.212976] [c0000007e58e3910] [d000000006c737d4] __target_execute_cmd+0x54/0x150 [target_core_mod] [ 496.212982] [c0000007e58e3940] [d000000006d32ce4] ibmvscsis_write_pending+0x74/0xe0 [ibmvscsis] [ 496.212991] [c0000007e58e39b0] [d000000006c74fc8] transport_generic_new_cmd+0x318/0x370 [target_core_mod] [ 496.213001] [c0000007e58e3a30] [d000000006c75084] transport_handle_cdb_direct+0x64/0xd0 [target_core_mod] [ 496.213011] [c0000007e58e3aa0] [d000000006c75298] target_submit_cmd_map_sgls+0x1a8/0x320 [target_core_mod] [ 496.213021] [c0000007e58e3b30] [d000000006c75458] target_submit_cmd+0x48/0x60 [target_core_mod] [ 496.213026] [c0000007e58e3bd0] [d000000006d34c20] ibmvscsis_scheduler+0x370/0x600 [ibmvscsis] [ 496.213031] [c0000007e58e3c90] [c00000000013135c] process_one_work+0x1ec/0x580 [ 496.213035] [c0000007e58e3d20] [c000000000131798] worker_thread+0xa8/0x600 [ 496.213039] [c0000007e58e3dc0] [c00000000013a468] kthread+0x168/0x1b0 [ 496.213044] [c0000007e58e3e30] [c00000000000b528] ret_from_kernel_thread+0x5c/0xb4 [ 496.213047] Instruction dump: [ 496.213049] 7c0803a6 4e800020 3c4c00a0 3842ef28 7c0802a6 f8010010 f821ffa1 7c641b78 [ 496.213055] 3c62ff94 3863dc00 4b4d16f1 60000000 <0fe00000> 00000000 00000000 00000000 [ 496.213062] ---[ end trace 4c7e8c92043f3868 ]--- [ 654.577815] ibmvscsis 3000000f: connection lost with outstanding work The patch fixes the above trace where the size passed into memcmp is greater than the size of the data passed in from ptr1 or ptr2 then a fortify_panic is posted. Fixes: 2237498f0b5c ("target/iblock: Convert WRITE_SAME to blkdev_issue_zeroout") Signed-off-by: Bryant G. Ly <bryantly(a)linux.vnet.ibm.com> Reviewed-by: Steven Royer <seroyer(a)linux.vnet.ibm.com> Tested-by: Taylor Jakobson <tjakobs(a)us.ibm.com> Cc: Christoph Hellwig <hch(a)lst.de> Cc: Nicholas Bellinger <nab(a)linux-iscsi.org> Cc: <stable(a)vger.kernel.org> --- drivers/target/target_core_iblock.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/target/target_core_iblock.c b/drivers/target/target_core_iblock.c index 07c814c..6042901 100644 --- a/drivers/target/target_core_iblock.c +++ b/drivers/target/target_core_iblock.c @@ -427,8 +427,8 @@ iblock_execute_zero_out(struct block_device *bdev, struct se_cmd *cmd) { struct se_device *dev = cmd->se_dev; struct scatterlist *sg = &cmd->t_data_sg[0]; - unsigned char *buf, zero = 0x00, *p = &zero; - int rc, ret; + unsigned char *buf, *not_zero; + int ret; buf = kmap(sg_page(sg)) + sg->offset; if (!buf) @@ -437,10 +437,10 @@ iblock_execute_zero_out(struct block_device *bdev, struct se_cmd *cmd) * Fall back to block_execute_write_same() slow-path if * incoming WRITE_SAME payload does not contain zeros. */ - rc = memcmp(buf, p, cmd->data_length); + not_zero = memchr_inv(buf, 0x00, cmd->data_length); kunmap(sg_page(sg)); - if (rc) + if (not_zero) return TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE; ret = blkdev_issue_zeroout(bdev, -- 2.7.2

6 years, 9 months

2
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror April 2018