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

[for-next][PATCH 33/34] uprobes: Use synchronize_rcu() not synchronize_sched()

by Steven Rostedt

From: "Steven Rostedt (VMware)" <rostedt(a)goodmis.org> While debugging another bug, I was looking at all the synchronize*() functions being used in kernel/trace, and noticed that trace_uprobes was using synchronize_sched(), with a comment to synchronize with {u,ret}_probe_trace_func(). When looking at those functions, the data is protected with "rcu_read_lock()" and not with "rcu_read_lock_sched()". This is using the wrong synchronize_*() function. Link: http://lkml.kernel.org/r/20180809160553.469e1e32@gandalf.local.home Cc: stable(a)vger.kernel.org Fixes: 70ed91c6ec7f8 ("tracing/uprobes: Support ftrace_event_file base multibuffer") Acked-by: Oleg Nesterov <oleg(a)redhat.com> Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org> --- kernel/trace/trace_uprobe.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c index bf89a51e740d..ac02fafc9f1b 100644 --- a/kernel/trace/trace_uprobe.c +++ b/kernel/trace/trace_uprobe.c @@ -952,7 +952,7 @@ probe_event_disable(struct trace_uprobe *tu, struct trace_event_file *file) list_del_rcu(&link->list); /* synchronize with u{,ret}probe_trace_func */ - synchronize_sched(); + synchronize_rcu(); kfree(link); if (!list_empty(&tu->tp.files)) -- 2.18.0

7 years, 4 months

1
0
0 0

[for-next][PATCH 18/34] tracing: Do not call start/stop() functions when tracing_on does not change

by Steven Rostedt

From: "Steven Rostedt (VMware)" <rostedt(a)goodmis.org> Currently, when one echo's in 1 into tracing_on, the current tracer's "start()" function is executed, even if tracing_on was already one. This can lead to strange side effects. One being that if the hwlat tracer is enabled, and someone does "echo 1 > tracing_on" into tracing_on, the hwlat tracer's start() function is called again which will recreate another kernel thread, and make it unable to remove the old one. Link: http://lkml.kernel.org/r/1533120354-22923-1-git-send-email-erica.bugden@lin… Cc: stable(a)vger.kernel.org Fixes: 2df8f8a6a897e ("tracing: Fix regression with irqsoff tracer and tracing_on file") Reported-by: Erica Bugden <erica.bugden(a)linutronix.de> Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org> --- kernel/trace/trace.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c index 823687997b01..2378bb4f1442 100644 --- a/kernel/trace/trace.c +++ b/kernel/trace/trace.c @@ -7628,7 +7628,9 @@ rb_simple_write(struct file *filp, const char __user *ubuf, if (buffer) { mutex_lock(&trace_types_lock); - if (val) { + if (!!val == tracer_tracing_is_on(tr)) { + val = 0; /* do nothing */ + } else if (val) { tracer_tracing_on(tr); if (tr->current_trace->start) tr->current_trace->start(tr); -- 2.18.0

7 years, 4 months

1
0
0 0

[PATCH] i2c: core: ACPI: Properly set status byte to 0 for multi-byte writes

by Hans de Goede

acpi_gsb_i2c_write_bytes() returns i2c_transfer()'s return value, which is the number of transfers executed on success, so 1. The ACPI code expects us to store 0 in gsb->status for success, not 1. Specifically this breaks the following code in the Thinkpad 8 DSDT: ECWR = I2CW = ECWR /* \_SB_.I2C1.BAT0.ECWR */ If ((ECST == Zero)) { ECRD = I2CR /* \_SB_.I2C1.I2CR */ } Before this commit we set ECST to 1, causing the read to never happen breaking battery monitoring on the Thinkpad 8. Note the Thinkpad 8 also has some unrelated issues where i2c transfers are unreliable. This commit sets status to 0 if it was bigger then 0 (so success), mirroring the multi-byte read path, fixing this. Cc: stable(a)vger.kernel.org Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> --- drivers/i2c/i2c-core-acpi.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/i2c/i2c-core-acpi.c b/drivers/i2c/i2c-core-acpi.c index 7c3b4740b94b..10ad851bd277 100644 --- a/drivers/i2c/i2c-core-acpi.c +++ b/drivers/i2c/i2c-core-acpi.c @@ -595,6 +595,8 @@ i2c_acpi_space_handler(u32 function, acpi_physical_address command, } else { status = acpi_gsb_i2c_write_bytes(client, command, gsb->data, info->access_length); + if (status > 0) + status = 0; } break; -- 2.18.0

7 years, 4 months

3
2
0 0

[PATCH] xtensa: increase ranges in ___invalidate_{i,d}cache_all

by Max Filippov

Cache invalidation macros use cache line size to iterate over invalidated cache lines, assuming that all cache ways are invalidated by single instruction, but xtensa ISA recommends to not assume that for future compatibility: In some implementations all ways at index Addry-1..z are invalidated regardless of the specified way, but for future compatibility this behavior should not be assumed. Iterate over all cache ways in ___invalidate_icache_all and ___invalidate_dcache_all. Cc: stable(a)vger.kernel.org Signed-off-by: Max Filippov <jcmvbkbc(a)gmail.com> --- arch/xtensa/include/asm/cacheasm.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/xtensa/include/asm/cacheasm.h b/arch/xtensa/include/asm/cacheasm.h index 5dd57c5db76c..e23069bcd8fb 100644 --- a/arch/xtensa/include/asm/cacheasm.h +++ b/arch/xtensa/include/asm/cacheasm.h @@ -123,7 +123,7 @@ .macro ___invalidate_dcache_all ar at #if XCHAL_DCACHE_SIZE - __loop_cache_all \ar \at dii __stringify(DCACHE_WAY_SIZE) \ + __loop_cache_all \ar \at dii XCHAL_DCACHE_SIZE \ XCHAL_DCACHE_LINEWIDTH 1020 #endif @@ -133,7 +133,7 @@ .macro ___invalidate_icache_all ar at #if XCHAL_ICACHE_SIZE - __loop_cache_all \ar \at iii __stringify(ICACHE_WAY_SIZE) \ + __loop_cache_all \ar \at iii XCHAL_ICACHE_SIZE \ XCHAL_ICACHE_LINEWIDTH 1020 #endif -- 2.11.0

7 years, 4 months

2
1
0 0

[PATCH] xtensa: limit offsets in __loop_cache_{all,page}

by Max Filippov

When building kernel for xtensa cores with big cache lines (e.g. 128 bytes or more) __loop_cache_all and __loop_cache_page may generate assembly instructions with immediate fields that are too big. This results in the following build errors: arch/xtensa/mm/misc.S: Assembler messages: arch/xtensa/mm/misc.S:464: Error: operand 2 of 'diwbi' has invalid value '256' arch/xtensa/mm/misc.S:464: Error: operand 2 of 'diwbi' has invalid value '384' arch/xtensa/kernel/head.S: Assembler messages: arch/xtensa/kernel/head.S:172: Error: operand 2 of 'diu' has invalid value '256' arch/xtensa/kernel/head.S:172: Error: operand 2 of 'diu' has invalid value '384' arch/xtensa/kernel/head.S:176: Error: operand 2 of 'iiu' has invalid value '256' arch/xtensa/kernel/head.S:176: Error: operand 2 of 'iiu' has invalid value '384' arch/xtensa/kernel/head.S:255: Error: operand 2 of 'diwb' has invalid value '256' arch/xtensa/kernel/head.S:255: Error: operand 2 of 'diwb' has invalid value '384' Add parameter max_immed to these macros and use it to limit values of immediate operands. Extract common code of these macros into the new macro __loop_cache_unroll. Cc: stable(a)vger.kernel.org Signed-off-by: Max Filippov <jcmvbkbc(a)gmail.com> --- arch/xtensa/include/asm/cacheasm.h | 65 +++++++++++++++++++++++--------------- 1 file changed, 40 insertions(+), 25 deletions(-) diff --git a/arch/xtensa/include/asm/cacheasm.h b/arch/xtensa/include/asm/cacheasm.h index 2041abb10a23..5dd57c5db76c 100644 --- a/arch/xtensa/include/asm/cacheasm.h +++ b/arch/xtensa/include/asm/cacheasm.h @@ -31,16 +31,32 @@ * */ - .macro __loop_cache_all ar at insn size line_width - movi \ar, 0 + .macro __loop_cache_unroll ar at insn size line_width max_immed + + .if (1 << (\line_width)) > (\max_immed) + reps = 1 + .elseif (2 << (\line_width)) > (\max_immed) + reps = 2 + .else + reps = 4 + .endif + + __loopi \ar, \at, \size, (reps << (\line_width)) + rep = 0 + .rep reps + \insn \ar, rep << (\line_width) + rep = rep + 1 + .endr + __endla \ar, \at, reps << (\line_width) + + .endm + - __loopi \ar, \at, \size, (4 << (\line_width)) - \insn \ar, 0 << (\line_width) - \insn \ar, 1 << (\line_width) - \insn \ar, 2 << (\line_width) - \insn \ar, 3 << (\line_width) - __endla \ar, \at, 4 << (\line_width) + .macro __loop_cache_all ar at insn size line_width max_immed + + movi \ar, 0 + __loop_cache_unroll \ar, \at, \insn, \size, \line_width, \max_immed .endm @@ -57,14 +73,9 @@ .endm - .macro __loop_cache_page ar at insn line_width + .macro __loop_cache_page ar at insn line_width max_immed - __loopi \ar, \at, PAGE_SIZE, 4 << (\line_width) - \insn \ar, 0 << (\line_width) - \insn \ar, 1 << (\line_width) - \insn \ar, 2 << (\line_width) - \insn \ar, 3 << (\line_width) - __endla \ar, \at, 4 << (\line_width) + __loop_cache_unroll \ar, \at, \insn, PAGE_SIZE, \line_width, \max_immed .endm @@ -72,7 +83,8 @@ .macro ___unlock_dcache_all ar at #if XCHAL_DCACHE_LINE_LOCKABLE && XCHAL_DCACHE_SIZE - __loop_cache_all \ar \at diu XCHAL_DCACHE_SIZE XCHAL_DCACHE_LINEWIDTH + __loop_cache_all \ar \at diu XCHAL_DCACHE_SIZE \ + XCHAL_DCACHE_LINEWIDTH 240 #endif .endm @@ -81,7 +93,8 @@ .macro ___unlock_icache_all ar at #if XCHAL_ICACHE_LINE_LOCKABLE && XCHAL_ICACHE_SIZE - __loop_cache_all \ar \at iiu XCHAL_ICACHE_SIZE XCHAL_ICACHE_LINEWIDTH + __loop_cache_all \ar \at iiu XCHAL_ICACHE_SIZE \ + XCHAL_ICACHE_LINEWIDTH 240 #endif .endm @@ -90,7 +103,8 @@ .macro ___flush_invalidate_dcache_all ar at #if XCHAL_DCACHE_SIZE - __loop_cache_all \ar \at diwbi XCHAL_DCACHE_SIZE XCHAL_DCACHE_LINEWIDTH + __loop_cache_all \ar \at diwbi XCHAL_DCACHE_SIZE \ + XCHAL_DCACHE_LINEWIDTH 240 #endif .endm @@ -99,7 +113,8 @@ .macro ___flush_dcache_all ar at #if XCHAL_DCACHE_SIZE - __loop_cache_all \ar \at diwb XCHAL_DCACHE_SIZE XCHAL_DCACHE_LINEWIDTH + __loop_cache_all \ar \at diwb XCHAL_DCACHE_SIZE \ + XCHAL_DCACHE_LINEWIDTH 240 #endif .endm @@ -109,7 +124,7 @@ #if XCHAL_DCACHE_SIZE __loop_cache_all \ar \at dii __stringify(DCACHE_WAY_SIZE) \ - XCHAL_DCACHE_LINEWIDTH + XCHAL_DCACHE_LINEWIDTH 1020 #endif .endm @@ -119,7 +134,7 @@ #if XCHAL_ICACHE_SIZE __loop_cache_all \ar \at iii __stringify(ICACHE_WAY_SIZE) \ - XCHAL_ICACHE_LINEWIDTH + XCHAL_ICACHE_LINEWIDTH 1020 #endif .endm @@ -166,7 +181,7 @@ .macro ___flush_invalidate_dcache_page ar as #if XCHAL_DCACHE_SIZE - __loop_cache_page \ar \as dhwbi XCHAL_DCACHE_LINEWIDTH + __loop_cache_page \ar \as dhwbi XCHAL_DCACHE_LINEWIDTH 1020 #endif .endm @@ -175,7 +190,7 @@ .macro ___flush_dcache_page ar as #if XCHAL_DCACHE_SIZE - __loop_cache_page \ar \as dhwb XCHAL_DCACHE_LINEWIDTH + __loop_cache_page \ar \as dhwb XCHAL_DCACHE_LINEWIDTH 1020 #endif .endm @@ -184,7 +199,7 @@ .macro ___invalidate_dcache_page ar as #if XCHAL_DCACHE_SIZE - __loop_cache_page \ar \as dhi XCHAL_DCACHE_LINEWIDTH + __loop_cache_page \ar \as dhi XCHAL_DCACHE_LINEWIDTH 1020 #endif .endm @@ -193,7 +208,7 @@ .macro ___invalidate_icache_page ar as #if XCHAL_ICACHE_SIZE - __loop_cache_page \ar \as ihi XCHAL_ICACHE_LINEWIDTH + __loop_cache_page \ar \as ihi XCHAL_ICACHE_LINEWIDTH 1020 #endif .endm -- 2.11.0

7 years, 4 months

2
1
0 0

[PATCH v5 13/13] drm/nouveau: Call pm_runtime_get_noresume() from hpd handlers

by Lyude Paul

We can't and don't need to try resuming the device from our hotplug handlers, but hotplug events are generally something we'd like to keep the device awake for whenever possible. So, grab a PM ref safely in our hotplug handlers using pm_runtime_get_noresume() and mark the device as busy once we're finished. Signed-off-by: Lyude Paul <lyude(a)redhat.com> Cc: stable(a)vger.kernel.org Cc: Lukas Wunner <lukas(a)wunner.de> Cc: Karol Herbst <karolherbst(a)gmail.com> --- drivers/gpu/drm/nouveau/nouveau_connector.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c b/drivers/gpu/drm/nouveau/nouveau_connector.c index 8409c3f2c3a1..5a8e8c1ad647 100644 --- a/drivers/gpu/drm/nouveau/nouveau_connector.c +++ b/drivers/gpu/drm/nouveau/nouveau_connector.c @@ -1152,6 +1152,11 @@ nouveau_connector_hotplug(struct nvif_notify *notify) const char *name = connector->name; struct nouveau_encoder *nv_encoder; + /* Resuming the device here isn't possible; but the suspend PM ops + * will wait for us to finish our work before disabling us so this + * should be enough + */ + pm_runtime_get_noresume(drm->dev->dev); nv_connector->hpd_task = current; if (rep->mask & NVIF_NOTIFY_CONN_V0_IRQ) { @@ -1171,6 +1176,9 @@ nouveau_connector_hotplug(struct nvif_notify *notify) } nv_connector->hpd_task = NULL; + + pm_runtime_mark_last_busy(drm->dev->dev); + pm_runtime_put_autosuspend(drm->dev->dev); return NVIF_NOTIFY_KEEP; } -- 2.17.1

7 years, 4 months

2
1
0 0

the editing is that you need

by Jeff

We would like to check if your photos need editing. We can do it for you. Our image editing is for web store photos, jewelries images and beauty and portrait photos etc. It is including cut out and clipping path , and also retouching if it is needed. We can do test on your photos. Just send us a photo we will start to work on it, Thanks, Jeff Allen

7 years, 4 months

1
0
0 0

the photos is what you need

by Jeff

We would like to check if your photos need editing. We can do it for you. Our image editing is for web store photos, jewelries images and beauty and portrait photos etc. It is including cut out and clipping path , and also retouching if it is needed. We can do test on your photos. Just send us a photo we will start to work on it, Thanks, Jeff Allen

7 years, 4 months

1
0
0 0

KASAN errors from unwind_frame

by Sodagudi Prasad

Hi All, I have observed following KASAN error with 4.14.56 kernel. Can you please copy change-[1](kasan: add no_sanitize attribute for clang builds) into stable kernels? [1] - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/i… ================================================================== BUG: KASAN: out-of-bounds in __read_once_size_nocheck include/linux/compiler.h:196 [inline] BUG: KASAN: out-of-bounds in unwind_frame+0xc4/0x324 arch/arm64/kernel/stacktrace.c:56 Read of size 8 at addr ffffffe3123ff4b0 by task poc/15233 CPU: 7 PID: 15233 Comm: poc Tainted: G S W O 4.14.56+ #3 Hardware name: Qualcomm Technologies, Inc. Call trace: dump_backtrace+0x0/0x388 show_stack+0x24/0x30 __dump_stack+0x24/0x2c dump_stack+0x8c/0xd0 print_address_description+0x74/0x234 kasan_report+0x240/0x264 __asan_report_load8_noabort+0x2c/0x38 unwind_frame+0xc4/0x324 walk_stackframe+0x44/0x6c __save_stack_trace+0x250/0x444 save_stack_trace_tsk+0x2c/0x38 proc_pid_stack+0x134/0x268 proc_single_show+0xdc/0x130 traverse+0x244/0x5b0 seq_lseek+0x10c/0x27c vfs_llseek+0xb4/0xe4 SyS_lseek+0x54/0xa0 el0_svc_naked+0x34/0x38 The buggy address belongs to the page: page:ffffffbf8c48ffc0 count:0 mapcount:0 mapping: (null) index:0x0 flags: 0x0() raw: 0000000000000000 0000000000000000 0000000000000000 00000000ffffffff raw: 0000000000000000 dead000000000200 0000000000000000 0000000000000000 page dumped because: kasan: bad access detected page_owner info is not active (free page?) Memory state around the buggy address: ffffffe3123ff380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffffffe3123ff400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > ffffffe3123ff480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ^ ffffffe3123ff500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffffffe3123ff580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ================================================================== -Thanks, Prasad -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, Linux Foundation Collaborative Project

7 years, 4 months

2
1
0 0

[PATCH] bcache: fix 0day error of setting writeback_rate by sysfs interface

by Coly Li

Commit ea8c5356d390 ("bcache: set max writeback rate when I/O request is idle") changes struct bch_ratelimit member rate from uint32_t to atomic_long_t and uses atomic_long_set() in drivers/md/bcache/sysfs.c to set new writeback rate, after the input is converted from memory buf to long int by sysfs_strtoul_clamp(). The above change has a problem because there is an implicit return inside sysfs_strtoul_clamp() so the following atomic_long_set() won't be called. This error is detected by 0day system with following snipped smatch warnings: drivers/md/bcache/sysfs.c:271 __cached_dev_store() error: uninitialized symbol 'v'. 270 sysfs_strtoul_clamp(writeback_rate, v, 1, INT_MAX); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @271 atomic_long_set(&dc->writeback_rate.rate, v); This patch fixes the above error by using strtoul_safe_clamp() to convert the input buffer into a long int type result. Fixes: Commit ea8c5356d390 ("bcache: set max writeback rate when I/O request is idle") Signed-off-by: Coly Li <colyli(a)suse.de> Cc: stable(a)vger.kernel.org #4.16+ Cc: Kai Krakow <kai(a)kaishome.de> Cc: Stefan Priebe <s.priebe(a)profihost.ag> --- drivers/md/bcache/sysfs.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/drivers/md/bcache/sysfs.c b/drivers/md/bcache/sysfs.c index 543b06408321..150cf4f4cf74 100644 --- a/drivers/md/bcache/sysfs.c +++ b/drivers/md/bcache/sysfs.c @@ -267,10 +267,17 @@ STORE(__cached_dev) sysfs_strtoul_clamp(writeback_percent, dc->writeback_percent, 0, 40); if (attr == &sysfs_writeback_rate) { - int v; + ssize_t ret; + long int v = atomic_long_read(&dc->writeback_rate.rate); + + ret = strtoul_safe_clamp(buf, v, 1, INT_MAX); - sysfs_strtoul_clamp(writeback_rate, v, 1, INT_MAX); - atomic_long_set(&dc->writeback_rate.rate, v); + if (!ret) { + atomic_long_set(&dc->writeback_rate.rate, v); + ret = size; + } + + return ret; } sysfs_strtoul_clamp(writeback_rate_update_seconds, -- 2.18.0

7 years, 4 months

2
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror