linaro-kernel November 2014

linaro-kernel@lists.linaro.org

59 participants
128 discussions

[PATCH 3.17-rc4 0/3] kdb: Improve command output searching

by Daniel Thompson

This patchset improves kdb's capabilities to search the output of commands. Specifically it fixes a bug in the prompt management when '| grep' is used and adds a new feature to search command output interactively from the more prompt. Daniel Thompson (3): kdb: Fix a prompt management bug when using | grep kdb: Provide forward search at more prompt kdb: Const qualifier for kdb_getstr's prompt argument kernel/debug/kdb/kdb_io.c | 24 +++++++++++++++++++++--- kernel/debug/kdb/kdb_main.c | 11 ++++++----- kernel/debug/kdb/kdb_private.h | 4 +++- 3 files changed, 30 insertions(+), 9 deletions(-) -- 1.9.3

9 years, 3 months

[PATCH] kdb: Remove stack dump when entering kgdb due to NMI

by Daniel Thompson

Issuing a stack dump feels ergonomically wrong when entering due to NMI. Entering due to NMI is a normally reaction to a user request, either the NMI button on a server or a "magic knock" on a UART. Therefore the backtrace behaviour on entry due to NMI should be like SysRq-g (no stack dump) rather than like oops. Note also that the stack dump does not offer any information that cannot be trivial retrieved using the 'bt' command. Signed-off-by: Daniel Thompson <daniel.thompson(a)linaro.org> Cc: Jason Wessel <jason.wessel(a)windriver.com> Cc: Mike Travis <travis(a)sgi.com> Cc: Ingo Molnar <mingo(a)redhat.com> Cc: kgdb-bugreport(a)lists.sourceforge.net --- kernel/debug/kdb/kdb_main.c | 1 - 1 file changed, 1 deletion(-) diff --git a/kernel/debug/kdb/kdb_main.c b/kernel/debug/kdb/kdb_main.c index 49f2425..6d19905 100644 --- a/kernel/debug/kdb/kdb_main.c +++ b/kernel/debug/kdb/kdb_main.c @@ -1207,7 +1207,6 @@ static int kdb_local(kdb_reason_t reason, int error, struct pt_regs *regs, kdb_printf("due to NonMaskable Interrupt @ " kdb_machreg_fmt "\n", instruction_pointer(regs)); - kdb_dumpregs(regs); break; case KDB_REASON_SSTEP: case KDB_REASON_BREAK: -- 1.9.3

9 years, 3 months

[PATCH 3.17rc4] kdb: Avoid printing KERN_ levels to consoles

by Daniel Thompson

Currently when kdb traps printk messages then the log level prefix does not get stripped off before the message is issued to the various I/O handlers supported by kdb. This results in annoying visual noise and problems with grepping for ^. This patch addresses the problem by stripping log levels from messages before they are issued to the I/O handlers. printk(), which is used as an I/O handler for logging purposes, is handled as a special case; if the caller provided a log level then this will be preserved. Signed-off-by: Daniel Thompson <daniel.thompson(a)linaro.org> Cc: Jason Wessel <jason.wessel(a)windriver.com> Cc: Mike Travis <travis(a)sgi.com> Cc: Ingo Molnar <mingo(a)redhat.com> Cc: Andrew Morton <akpm(a)linux-foundation.org> --- kernel/debug/kdb/kdb_io.c | 20 +++++++++++++------- 1 file changed, 13 insertions(+), 7 deletions(-) diff --git a/kernel/debug/kdb/kdb_io.c b/kernel/debug/kdb/kdb_io.c index 7c70812..381f297 100644 --- a/kernel/debug/kdb/kdb_io.c +++ b/kernel/debug/kdb/kdb_io.c @@ -691,19 +691,22 @@ kdb_printit: * Write to all consoles. */ retlen = strlen(kdb_buffer); + cp = kdb_buffer; + if (cp[0] == KERN_SOH_ASCII && cp[1] != '\0') + cp += 2; if (!dbg_kdb_mode && kgdb_connected) { - gdbstub_msg_write(kdb_buffer, retlen); + gdbstub_msg_write(cp, retlen - (cp - kdb_buffer)); } else { if (dbg_io_ops && !dbg_io_ops->is_console) { - len = retlen; - cp = kdb_buffer; + len = retlen - (cp - kdb_buffer); + cp2 = cp; while (len--) { - dbg_io_ops->write_char(*cp); - cp++; + dbg_io_ops->write_char(*cp2); + cp2++; } } while (c) { - c->write(c, kdb_buffer, retlen); + c->write(c, cp, retlen - (cp - kdb_buffer)); touch_nmi_watchdog(); c = c->next; } @@ -711,7 +714,10 @@ kdb_printit: if (logging) { saved_loglevel = console_loglevel; console_loglevel = CONSOLE_LOGLEVEL_SILENT; - printk(KERN_INFO "%s", kdb_buffer); + if (cp == kdb_buffer) + printk(KERN_INFO "%s", kdb_buffer); + else + printk("%s", kdb_buffer); } if (KDB_STATE(PAGER)) { -- 1.9.3

9 years, 3 months

[PATCH] arm64: kgdb: fix single stepping

by AKASHI Takahiro

I tried to verify kgdb in vanilla kernel on fast model, but it seems that the single stepping with kgdb doesn't work correctly since its first appearance at v3.15. On v3.15, 'stepi' command after breaking the kernel at some breakpoint steps forward to the next instruction, but the succeeding 'stepi' never goes beyond that. On v3.16, 'stepi' moves forward and stops at the next instruction just after enable_dbg in el1_dbg, and never goes beyond that. This variance of behavior seems to come in with the following patch in v3.16: commit 2a2830703a23 ("arm64: debug: avoid accessing mdscr_el1 on fault paths where possible") This patch (1) moves kgdb_disable_single_step() from 'c' command handling to single step handler. This makes sure that single stepping gets effective at every 's' command. Please note that, under the current implementation, single step bit in spsr, which is cleared by the first single stepping, will not be set again for the consecutive 's' commands because single step bit in mdscr is still kept on (that is, kernel_active_single_step() in kgdb_arch_handle_exception() is true). (2) re-implements kgdb_roundup_cpus() because the current implementation enabled interrupts naively. See below. (3) removes 'enable_dbg' in el1_dbg. Single step bit in mdscr is turned on in do_handle_exception()-> kgdb_handle_expection() before returning to debugged context, and if debug exception is enabled in el1_dbg, we will see unexpected single- stepping in el1_dbg. Since v3.18, the following patch does the same: commit 1059c6bf8534 ("arm64: debug: don't re-enable debug exceptions on return from el1_dbg) (4) masks interrupts while single-stepping one instruction. If an interrupt is caught during processing a single-stepping, debug exception is unintentionally enabled by el1_irq's 'enable_dbg' before returning to debugged context. Thus, like in (2), we will see unexpected single-stepping in el1_irq. Basically (1) and (2) are for v3.15, (3) and (4) for v3.1[67]. * issue fixed by (2): Without (2), we would see another problem if a breakpoint is set at interrupt-sensible places, like gic_handle_irq(): KGDB: re-enter error: breakpoint removed ffffffc000081258 ------------[ cut here ]------------ WARNING: CPU: 0 PID: 650 at kernel/debug/debug_core.c:435 kgdb_handle_exception+0x1dc/0x1f4() Modules linked in: CPU: 0 PID: 650 Comm: sh Not tainted 3.17.0-rc2+ #177 Call trace: [<ffffffc000087fac>] dump_backtrace+0x0/0x130 [<ffffffc0000880ec>] show_stack+0x10/0x1c [<ffffffc0004d683c>] dump_stack+0x74/0xb8 [<ffffffc0000ab824>] warn_slowpath_common+0x8c/0xb4 [<ffffffc0000ab90c>] warn_slowpath_null+0x14/0x20 [<ffffffc000121bfc>] kgdb_handle_exception+0x1d8/0x1f4 [<ffffffc000092ffc>] kgdb_brk_fn+0x18/0x28 [<ffffffc0000821c8>] brk_handler+0x9c/0xe8 [<ffffffc0000811e8>] do_debug_exception+0x3c/0xac Exception stack(0xffffffc07e027650 to 0xffffffc07e027770) ... [<ffffffc000083cac>] el1_dbg+0x14/0x68 [<ffffffc00012178c>] kgdb_cpu_enter+0x464/0x5c0 [<ffffffc000121bb4>] kgdb_handle_exception+0x190/0x1f4 [<ffffffc000092ffc>] kgdb_brk_fn+0x18/0x28 [<ffffffc0000821c8>] brk_handler+0x9c/0xe8 [<ffffffc0000811e8>] do_debug_exception+0x3c/0xac Exception stack(0xffffffc07e027ac0 to 0xffffffc07e027be0) ... [<ffffffc000083cac>] el1_dbg+0x14/0x68 [<ffffffc00032e4b4>] __handle_sysrq+0x11c/0x190 [<ffffffc00032e93c>] write_sysrq_trigger+0x4c/0x60 [<ffffffc0001e7d58>] proc_reg_write+0x54/0x84 [<ffffffc000192fa4>] vfs_write+0x98/0x1c8 [<ffffffc0001939b0>] SyS_write+0x40/0xa0 Once some interrupt occurs, a breakpoint at gic_handle_irq() triggers kgdb. Kgdb then calls kgdb_roundup_cpus() to sync with other cpus. Current kgdb_roundup_cpus() unmasks interrupts temporarily to use smp_call_function(). This eventually allows another interrupt to occur and likely results in hitting a breakpoint at gic_handle_irq() again since debug exception is always enabled in el1_irq. We can avoid this issue by specifying "nokgdbroundup" in kernel parameter, but this will also leave other cpus be in unknown state in terms of kgdb, and may result in interfering with kgdb activity. Signed-off-by: AKASHI Takahiro <takahiro.akashi(a)linaro.org> --- arch/arm64/kernel/kgdb.c | 60 +++++++++++++++++++++++++++++++++++----------- 1 file changed, 46 insertions(+), 14 deletions(-) diff --git a/arch/arm64/kernel/kgdb.c b/arch/arm64/kernel/kgdb.c index a0d10c5..81b5910 100644 --- a/arch/arm64/kernel/kgdb.c +++ b/arch/arm64/kernel/kgdb.c @@ -19,9 +19,13 @@ * along with this program. If not, see <http://www.gnu.org/licenses/>. */ +#include <linux/cpumask.h> #include <linux/irq.h> +#include <linux/irq_work.h> #include <linux/kdebug.h> #include <linux/kgdb.h> +#include <linux/percpu.h> +#include <asm/ptrace.h> #include <asm/traps.h> struct dbg_reg_def_t dbg_reg_def[DBG_MAX_REG_NUM] = { @@ -95,6 +99,9 @@ struct dbg_reg_def_t dbg_reg_def[DBG_MAX_REG_NUM] = { { "fpcr", 4, -1 }, }; +static DEFINE_PER_CPU(unsigned int, kgdb_pstate); +static DEFINE_PER_CPU(struct irq_work, kgdb_irq_work); + char *dbg_get_reg(int regno, void *mem, struct pt_regs *regs) { if (regno >= DBG_MAX_REG_NUM || regno < 0) @@ -176,18 +183,14 @@ int kgdb_arch_handle_exception(int exception_vector, int signo, * over and over again. */ kgdb_arch_update_addr(linux_regs, remcom_in_buffer); - atomic_set(&kgdb_cpu_doing_single_step, -1); - kgdb_single_step = 0; - - /* - * Received continue command, disable single step - */ - if (kernel_active_single_step()) - kernel_disable_single_step(); err = 0; break; case 's': + /* mask interrupts while single stepping */ + __this_cpu_write(kgdb_pstate, linux_regs->pstate); + linux_regs->pstate |= PSR_I_BIT; + /* * Update step address value with address passed * with step packet. @@ -198,8 +201,6 @@ int kgdb_arch_handle_exception(int exception_vector, int signo, */ kgdb_arch_update_addr(linux_regs, remcom_in_buffer); atomic_set(&kgdb_cpu_doing_single_step, raw_smp_processor_id()); - kgdb_single_step = 1; - /* * Enable single step handling */ @@ -229,6 +230,18 @@ static int kgdb_compiled_brk_fn(struct pt_regs *regs, unsigned int esr) static int kgdb_step_brk_fn(struct pt_regs *regs, unsigned int esr) { + unsigned int pstate; + + kernel_disable_single_step(); + atomic_set(&kgdb_cpu_doing_single_step, -1); + + /* restore interrupt mask status */ + pstate = __this_cpu_read(kgdb_pstate); + if (pstate & PSR_I_BIT) + regs->pstate |= PSR_I_BIT; + else + regs->pstate &= ~PSR_I_BIT; + kgdb_handle_exception(1, SIGTRAP, 0, regs); return 0; } @@ -249,16 +262,27 @@ static struct step_hook kgdb_step_hook = { .fn = kgdb_step_brk_fn }; -static void kgdb_call_nmi_hook(void *ignored) +static void kgdb_roundup_hook(struct irq_work *work) { kgdb_nmicallback(raw_smp_processor_id(), get_irq_regs()); } void kgdb_roundup_cpus(unsigned long flags) { - local_irq_enable(); - smp_call_function(kgdb_call_nmi_hook, NULL, 0); - local_irq_disable(); + int cpu; + struct cpumask mask; + struct irq_work *work; + + mask = *cpu_online_mask; + cpumask_clear_cpu(smp_processor_id(), &mask); + cpu = cpumask_first(&mask); + if (cpu >= nr_cpu_ids) + return; + + for_each_cpu(cpu, &mask) { + work = per_cpu_ptr(&kgdb_irq_work, cpu); + irq_work_queue_on(work, cpu); + } } static int __kgdb_notify(struct die_args *args, unsigned long cmd) @@ -299,6 +323,8 @@ static struct notifier_block kgdb_notifier = { int kgdb_arch_init(void) { int ret = register_die_notifier(&kgdb_notifier); + int cpu; + struct irq_work *work; if (ret != 0) return ret; @@ -306,6 +332,12 @@ int kgdb_arch_init(void) register_break_hook(&kgdb_brkpt_hook); register_break_hook(&kgdb_compiled_brkpt_hook); register_step_hook(&kgdb_step_hook); + + for_each_possible_cpu(cpu) { + work = per_cpu_ptr(&kgdb_irq_work, cpu); + init_irq_work(work, kgdb_roundup_hook); + } + return 0; } -- 1.7.9.5

9 years, 3 months

[PATCH] arm: perf: Prevent wraparound during overflow

by Daniel Thompson

If the overflow threshold for a counter is set above or near the 0xffffffff boundary then the kernel may lose track of the overflow causing only events that occur *after* the overflow to be recorded. Specifically the problem occurs when the value of the performance counter overtakes its original programmed value due to wrap around. Typical solutions to this problem are either to avoid programming in values likely to be overtaken or to treat the overflow bit as the 33rd bit of the counter. Its somewhat fiddly to refactor the code to correctly handle the 33rd bit during irqsave sections (context switches for example) so instead we take the simpler approach of avoiding values likely to be overtaken. We set the limit to half of max_period because this matches the limit imposed in __hw_perf_event_init(). This causes a doubling of the interrupt rate for large threshold values, however even with a very fast counter ticking at 4GHz the interrupt rate would only be ~1Hz. Signed-off-by: Daniel Thompson <daniel.thompson(a)linaro.org> --- Notes: There is similar code in the arm64 tree which retains the assumptions of the original arm code regarding 32-bit wide performance counters. If this patch doesn't get beaten up during review I'll also share a similar patch for arm64. arch/arm/kernel/perf_event.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c index 266cba46db3e..b50a770f8c99 100644 --- a/arch/arm/kernel/perf_event.c +++ b/arch/arm/kernel/perf_event.c @@ -115,8 +115,14 @@ int armpmu_event_set_period(struct perf_event *event) ret = 1; } - if (left > (s64)armpmu->max_period) - left = armpmu->max_period; + /* + * Limit the maximum period to prevent the counter value + * from overtaking the one we are about to program. In + * effect we are reducing max_period to account for + * interrupt latency (and we are being very conservative). + */ + if (left > (s64)(armpmu->max_period >> 1)) + left = armpmu->max_period >> 1; local64_set(&hwc->prev_count, (u64)-left); -- 1.9.3

9 years, 3 months

[PATCH 1/2] cpuidle: acpi: Remove TIME_INVALID flag from acpi

by Daniel Lezcano

The commit 8e92b6605d introduced the TIME_VALID flag for the C1 state if this one is a mwait state assuming the interrupt will be enabled before reading the end time of the idle state. The changelog of this commit mention a potential problem with the menu governor but not a real observation and I assume it described an old code as the commit is from 2008. I have been digging through the code and I didn't find any place where the interrupts are enabled before reading the time. Moreover with the changes in the meantime, we moved the time measurements in the cpuidle core as well as the interrupts enabling making sure the time is measured before the interrupt are enabled again in a single place. Remove this test as the time measurement is always valid for this state. Signed-off-by: Daniel Lezcano <daniel.lezcano(a)linaro.org> --- drivers/acpi/processor_idle.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c index 380b4b4..7afba40 100644 --- a/drivers/acpi/processor_idle.c +++ b/drivers/acpi/processor_idle.c @@ -985,8 +985,6 @@ static int acpi_processor_setup_cpuidle_states(struct acpi_processor *pr) state->flags = 0; switch (cx->type) { case ACPI_STATE_C1: - if (cx->entry_method != ACPI_CSTATE_FFH) - state->flags |= CPUIDLE_FLAG_TIME_INVALID; state->enter = acpi_idle_enter_c1; state->enter_dead = acpi_idle_play_dead; -- 1.9.1

9 years, 4 months

[PATCH 00/26] thermal: cpu_cooling: Fixes and cleanups

by Viresh Kumar

Hi Eduardo, As you know I got into fixing cpu_cooling.c due to some cpufreq issues you and Lukasz were struggling with. I found some issues in cpu_cooling then and here are the fixes/cleanups. Sorry for the long list. Haven't broken them into smaller sets as most of the patches are very small, easy to review and inter-dependent. Only few of them should take more time to review. If this doesn't work out, let me know and I will try to send separate inter-dependent sets. Just apply whatever looks fine and I will update/resend the ones left in V2 if at required. First few are updates to platform drivers. Exynos fails to register after few patches in this series as it doesn't handle -EPROBE_DEFER properly (reported that in reply to your patch as well). Others weren't setting clip_cpus properly and are fixed. Next ones are cleanups of cpu_cooling.c to get things properly organized. Let me know if I screwed it up completely. Tested-on: Exynos5250 (Dual ARM Cortex A15). Rebased-over: v3.18-rc6 Pushed here: git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/linux.git thermal/cpu-cooling-fixes Cc: Amit Daniel Kachhap <amit.daniel(a)samsung.com> Cc: Chanwoo Choi <cw00.choi(a)samsung.com> Cc: Hongbo Zhang <hongbo.zhang(a)linaro.com> Cc: Kyungmin Park <kyungmin.park(a)samsung.com> Cc: Lukasz Majewski <l.majewski(a)samsung.com> Cc: Shawn Guo <shawn.guo(a)linaro.org> Viresh Kumar (26): thermal: db8500: pass cpu_present_mask to cpufreq_cooling_register() thermal: imx: pass cpu_present_mask to cpufreq_cooling_register() thermal: exynos: pass cpu_present_mask to cpufreq_cooling_register() thermal: exynos: Handle -EPROBE_DEFER properly cpu_cooling: random comment fixups cpu_cooling: fix doc comment over struct cpufreq_cooling_device cpu_cooling: Add comment to clarify relation between cooling state and frequency cpu_cooling: Pass variable instead of its type to sizeof() cpu_cooling: no need to set cpufreq_state to zero cpu_cooling: no need to set cpufreq_dev to NULL cpu_cooling: propagate error returned by idr_alloc() cpu_cooling: Don't match min/max frequencies for all CPUs on cooling register cpu_cooling: don't iterate over all allowed_cpus to update cpufreq policy cpu_cooling: Don't check is_cpufreq_valid() cpu_cooling: do error handling at the bottom in __cpufreq_cooling_register() cpu_cooling: Drop useless locking around idr_alloc/idr_remove cpu_cooling: Merge cpufreq_apply_cooling() into cpufreq_set_cur_state() cpu_cooling: Merge get_cpu_frequency() into cpufreq_set_cur_state() cpu_cooling: find max level during device registration cpu_cooling: get_property() doesn't need to support GET_MAXL anymore cpu_cooling: create list of cpufreq_cooling_devices cpu_cooling: use cpufreq_dev_list instead of cpufreq_dev_count cpu_cooling: Pass 'cpufreq_dev' to get_property() cpu_cooling: Store frequencies in descending order cpu_cooling: Use cpufreq_dev->freq_table for finding level/freq cpu_cooling: update copyright tags drivers/thermal/cpu_cooling.c | 405 +++++++++--------------- drivers/thermal/db8500_cpufreq_cooling.c | 5 +- drivers/thermal/imx_thermal.c | 4 +- drivers/thermal/samsung/exynos_thermal_common.c | 11 +- drivers/thermal/samsung/exynos_tmu.c | 4 +- 5 files changed, 153 insertions(+), 276 deletions(-) -- 2.0.3.693.g996b0fd

9 years, 4 months

[PATCH 0/8] OPP: Remove OPPs when not in use

by Viresh Kumar

Hi Rafael, This is what I came up with in reply to: http://www.spinics.net/lists/arm-kernel/msg380065.html The issue was first reported by Stefan Wahren, where he got warnings for duplicate OPP entries while he tried to insert/remove cpufreq-dt.ko multiple times. This set fixes it by first marking each OPP entry as static (created from DT) or dynamic. And then freeing only static ones from the ->exit() path of cpufreq drivers. An API is also provided to remove the dynamics ones, but no one is using it currently. This also modifies bunch of cpufreq drivers which were using OPPs created from DT. At last, thanks to Paul and You to clarify my doubts on RCU. Hope I understood them correctly :) Pushed here: git://git.linaro.org/people/viresh.kumar/linux.git cpufreq/opp-remove-v1 Rebased over: pm/linux-next Tested-on: Exynos 5250, dual cortex A15 with cpufreq-dt.c. Cc: Paul McKenney <paulmck(a)linux.vnet.ibm.com> Viresh Kumar (8): opp: rename 'head' as 'rcu_head' or 'srcu_head' based on its type opp: don't match for existing OPPs when list is empty opp: mark OPPs as 'static' or 'dynamic' opp: Introduce APIs to remove OPPs arm_big_little: free OPP table created during ->init() cpufreq-dt: free OPP table created during ->init() exynos5440: free OPP table created during ->init() imx6q: free OPP table created during ->init() drivers/base/power/opp.c | 196 +++++++++++++++++++++++++++-------- drivers/cpufreq/arm_big_little.c | 7 +- drivers/cpufreq/arm_big_little.h | 5 +- drivers/cpufreq/arm_big_little_dt.c | 1 + drivers/cpufreq/cpufreq-dt.c | 6 +- drivers/cpufreq/exynos5440-cpufreq.c | 5 +- drivers/cpufreq/imx6q-cpufreq.c | 11 +- include/linux/pm_opp.h | 12 ++- 8 files changed, 195 insertions(+), 48 deletions(-) -- 2.0.3.693.g996b0fd

9 years, 4 months

[PATCH v10 0/6] arm64: add seccomp support

by AKASHI Takahiro

This patch series enables secure computing (system call filtering) on arm64, and contains related enhancements and bug fixes. NOTE: This versions contain a workaround against possible BUG_ON() failure at audit_syscall_exit(), but doesn't contain an extra optimization, as I submitted for arm, of excluding syscall enter/exit tracing against invalid system calls due to an issue that I reported in: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-October/292170.h… The code was tested on ARMv8 fast model with 64-bit/32-bit userspace using: * libseccomp v2.1.1 with modifications for arm64, especially its "live" tests: No.20, 21 and 24. * modified version of Kees' seccomp test for 'changing/skipping a syscall' and seccomp() system call * in-house tests for 'changing/skipping a system call' by tracing with ptrace(SETREGSET, NT_SYSTEM_CALL) (that is, not via seccomp filter)' with and without audit tracing. Changes v9 -> v10: * modified system_call_get() for big-endian build [1/6] * modified the way to check for syscall(-1) on syscall entry [2/6] Changes v8 -> v9: * removed a restriction on syscall(-1) by setting a default errno [2/6] Changes v7 -> v8: * changed an interface of changing a syscall number from ptrace(SET_SYSCALL) to ptrace(SETREGSET, NT_ARM_SYSTEM_CALL) [1/6] * removed IS_SKILL_SYSCALL macro [2/6] * clarified comments in syscall_trace_enter() [2/6] * changed unsigned int to compat_uint_t in compat_siginfo._sigsys [5/6] * moved to a new calling interface of secure_computing(void) [6/6] Changes v6 -> v7: * simplified the condition of checking for user-issued syscall(-1) at syscall_trace_enter() [2/6] * defines __NR_seccomp_sigreturn only if arch-specific def doesn't exist. As Kees suggests, this is necessary for x86 and others. [3/6] * removed "#ifdef __ARCH_SIGSYS" which is always true on arm64. [5/6] * changed to call syscall_trace_exit() even if secure_computing fails. [6/6] In v6, syscall_trace_enter() returns RET_SYSCALL_SKIP_TRACE (== -2) and skips syscall_trace_exit() to minimize the overhead, but this case can be easily confused with user-issued (and invalid) syscall(-2). Anyway, this is now a consistent behavior with arm and other archs. Changes v5 -> v6: * rebased to v3.17-rc * changed the interface of changing/skipping a system call from re-writing x8 register [v5 1/3] to using dedicated PTRACE_SET_SYSCALL command [1/6, 2/6] Patch [1/6] contains a checkpatch error around a switch statement, but it won't be fixed as in compat_arch_ptrace(). * added a new system call, seccomp(), for compat task [4/6] * added SIGSYS siginfo for compat task [5/6] * changed to always execute audit exit tracing to avoid OOPs [2/6, 6/6] Changes v4 -> v5: * rebased to v3.16-rc * add patch [1/3] to allow ptrace to change a system call (please note that this patch should be applied even without seccomp.) Changes v3 -> v4: * removed the following patch and moved it to "arm64: prerequisites for audit and ftrace" patchset since it is required for audit and ftrace in case of !COMPAT, too. "arm64: is_compat_task is defined both in asm/compat.h and linux/compat.h" Changes v2 -> v3: * removed unnecessary 'type cast' operations [2/3] * check for a return value (-1) of secure_computing() explicitly [2/3] * aligned with the patch, "arm64: split syscall_trace() into separate functions for enter/exit" [2/3] * changed default of CONFIG_SECCOMP to n [2/3] Changes v1 -> v2: * added generic seccomp.h for arm64 to utilize it [1,2/3] * changed syscall_trace() to return more meaningful value (-EPERM) on seccomp failure case [2/3] * aligned with the change in "arm64: make a single hook to syscall_trace() for all syscall features" v2 [2/3] * removed is_compat_task() definition from compat.h [3/3] AKASHI Takahiro (6): arm64: ptrace: add NT_ARM_SYSTEM_CALL regset arm64: ptrace: allow tracer to skip a system call asm-generic: add generic seccomp.h for secure computing mode 1 arm64: add seccomp syscall for compat task arm64: add SIGSYS siginfo for compat task arm64: add seccomp support arch/arm64/Kconfig | 14 +++++++++++++ arch/arm64/include/asm/compat.h | 7 +++++++ arch/arm64/include/asm/seccomp.h | 25 +++++++++++++++++++++++ arch/arm64/include/asm/unistd.h | 3 +++ arch/arm64/include/asm/unistd32.h | 3 ++- arch/arm64/kernel/entry.S | 12 +++++++++-- arch/arm64/kernel/ptrace.c | 40 +++++++++++++++++++++++++++++++++++++ arch/arm64/kernel/signal32.c | 6 ++++++ include/asm-generic/seccomp.h | 30 ++++++++++++++++++++++++++++ include/uapi/linux/elf.h | 1 + 10 files changed, 138 insertions(+), 3 deletions(-) create mode 100644 arch/arm64/include/asm/seccomp.h create mode 100644 include/asm-generic/seccomp.h -- 1.7.9.5

9 years, 5 months

[RFC] cpufreq: Add "dvfs-method" binding to probe cpufreq drivers

by Viresh Kumar

DT based cpufreq drivers doesn't require much support from platform code now a days as most of the stuff is moved behind generic APIs. Like clk APIs for changing clock rates, regulator APIs for changing voltages, etc. One of the bottleneck still left was how to select which cpufreq driver to probe for a given platform as there might be multiple drivers available. Traditionally, we used to create platform devices from machine specific code which binds with a cpufreq driver. And while we moved towards DT based device creation, these devices stayed as is. The problem is getting worse now as we have architectures now with Zero platform specific code. Forcefully these platforms have to create a new file in drivers/cpufreq/ to just add these platform devices in order to use the generic drivers like cpufreq-dt.c. This has been discussed again and again, but with no solution yet. Last it was discussed here: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-May/256154.html This patch is an attempt towards getting the bindings. We only need to have one entry in cpus@cpu0 node which will match with drivers name. We can then add another file drivers/cpufreq/device_dt.c, which will add a platform device with the name it finds from cpus@cpu0 node and existing drivers will work without any change. Or something else if somebody have a better proposal. But lets fix the bindings first. Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> --- .../devicetree/bindings/cpufreq/drivers.txt | 53 ++++++++++++++++++++++ 1 file changed, 53 insertions(+) create mode 100644 Documentation/devicetree/bindings/cpufreq/drivers.txt diff --git a/Documentation/devicetree/bindings/cpufreq/drivers.txt b/Documentation/devicetree/bindings/cpufreq/drivers.txt new file mode 100644 index 0000000..bd14917 --- /dev/null +++ b/Documentation/devicetree/bindings/cpufreq/drivers.txt @@ -0,0 +1,53 @@ +Binding to select which cpufreq driver to register + +It is a generic DT binding for selecting which cpufreq-driver to register for +any platform. + +The property listed below must be defined under node /cpus/cpu@0 node. We don't +support multiple CPUFreq driver currently for different cluster and so this +information isn't required to be present in CPUs of all clusters. + +Required properties: +- None + +Optional properties: +- dvfs-method: CPUFreq driver to probe. For example: "arm-bL-cpufreq-dt", + "cpufreq-dt", etc + +Examples: + +cpus { + #address-cells = <1>; + #size-cells = <0>; + + cpu@0 { + compatible = "arm,cortex-a9"; + reg = <0>; + next-level-cache = <&L2>; + operating-points = < + /* kHz uV */ + 792000 1100000 + 396000 950000 + 198000 850000 + >; + dvfs-method = "cpufreq-dt"; + }; + + cpu@1 { + compatible = "arm,cortex-a9"; + reg = <1>; + next-level-cache = <&L2>; + }; + + cpu@2 { + compatible = "arm,cortex-a9"; + reg = <2>; + next-level-cache = <&L2>; + }; + + cpu@3 { + compatible = "arm,cortex-a9"; + reg = <3>; + next-level-cache = <&L2>; + }; +}; -- 2.0.3.693.g996b0fd

9 years, 5 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

linaro-kernel November 2014