Re: [PATCH v2 6/6] selftests: exec: simpification the Makefile
On Mon, 2015-09-07 at 22:04 +0800, Bamvor Jian Zhang wrote:
> selftests: exec: simpification the Makefile
Please give us a better subject, ie something like:
selftests/exec: Revert to default emit rule
> With the previous patch, the installation method change from install
> to rsync. There is not no need to create subdir during test, the
^
one too many "not"
> default RUN_TESTS is enough.
^
EMIT_TESTS
>
> This patch implicitly revert commit 84cbd9e4 ("selftests/exec: do not
^
"essentially" would be more accurate I think
> install subdir as it is already created").
cheers
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Use (two) different compilers at build-time?
On Tue, Sep 8, 2015 at 7:45 AM, Sedat Dilek wrote: > On Tue, Sep 8, 2015 at 12:30 AM, Sedat Dilek wrote: >> On Mon, Sep 7, 2015 at 11:20 PM, Sedat Dilek wrote: >>> On Mon, Sep 7, 2015 at 10:59 PM, Linus Torvalds >>> wrote: On Mon, Sep 7, 2015 at 1:53 PM, Sedat Dilek wrote: > > That does not work. .. because you didn't do what I told you to do. > I copied a gcc-compiled percpu.o OR deleted/renamed percpu.o and > re-invoked make - this starts a complete new build from scratch. Right. Because you changed the compiler name, so now the build system realizes that the old build instructions are stale. Which is why you have to: >> Use a wrapper around the compiler (and point to that wrapper with the >> "to switch compilers from under the make, without the build paths >> changing (because otherwise our makefile auto-machinery notices that >> flags and command changed). >> >> Use CC (or CROSS_COMPILE) to point at your wrapper. > > No idea how to realize that, sorry. Literally just do something like this: - have a shell script call "mycompiler" and make it do gcc/llvm "$@". - or even just use a symlink (the script has the advantage that you can play with the options etc too) - change the shell script (or symlink) itself, and make sure to use the same CC for "make" at all times, so that the build script never sees that the underlying command is now different. It should work fine, I've done it a couple of times (although admittedly not recently) >>> >>> OK, I have created a mycompiler shell-script and use that for CC and >>> HOSTCC in my own build-script. >>> >>> Using CLANG... >>> >>> [ /usr/bin/mycompiler ] >>> >>> #!/bin/bash >>> >>> clang "$@" >>> - EOF - >>> >>> $ mycompiler --version >>> clang version 3.7.0 (tags/RELEASE_370/final) >>> Target: x86_64-unknown-linux-gnu >>> Thread model: posix >>> >>> Switching to GCC... >>> >>> [ /usr/bin/mycompiler ] >>> >>> #!/bin/bash >>> >>> gcc-4.9 "$@" >>> - EOF - >>> >>> $ mycompiler --version >>> gcc-4.9 (Ubuntu 4.9.2-0ubuntu1~12.04) 4.9.2 >>> Copyright (C) 2014 Free Software Foundation, Inc. >>> This is free software; see the source for copying conditions. There is NO >>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. >>> >>> Thanks, that helped me a lot. >>> >> >> Sadly, this trick does not work here with Linux v4.2. >> > > So, the problem is any change to your make-lines. > Means $COMPILER and/or compiler flags! > > I simplified in Makefile... > > COMPILER := clang > export COMPILER > > and then did a symlink gcc-4.9 -> clang. > > This did NOT work because clang uses a compiler-flag > '-no-integrated-as' which does not exist for gcc! > > So, switching from gcc -> clang or vice-versa is not possible with > your compiler-wrapper-script trick :-(. > > Anyway, I need a different solution. > > One of my ideas was to hack the mm/Makefile. > > --- a/mm/Makefile > +++ b/mm/Makefile > @@ -2,6 +2,9 @@ > # Makefile for the linux memory manager. > # > > +COMPILER := gcc > +export COMPILER > + > KASAN_SANITIZE_slab_common.o := n > KASAN_SANITIZE_slub.o := n > > @@ -78,3 +81,6 @@ obj-$(CONFIG_CMA) += cma.o > obj-$(CONFIG_MEMORY_BALLOON) += balloon_compaction.o > obj-$(CONFIG_PAGE_EXTENSION) += page_ext.o > obj-$(CONFIG_CMA_DEBUGFS) += cma_debug.o > + > +COMPILER := clang > +export COMPILER > > Not sure if this works. > This does not work. And if it had worked - it cannot due to passing invalid compiler-flags to gcc. Empty head. - Sedat - -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 5/6] selftests: change install command to rsync
On Mon, 2015-09-07 at 22:04 +0800, Bamvor Jian Zhang wrote:
> The command of install could not handle the special files in exec
> testcases, change the default rule to rsync to fix this.
> The result of installation is unchanged after this commit.
>
> Suggested-by: Michael Ellerman
> Signed-off-by: Bamvor Jian Zhang
Ah OK, I did suggest it. You never replied to my mail suggesting it though.
I assume you tested it and it worked for all cases?
> diff --git a/tools/testing/selftests/ftrace/Makefile
> b/tools/testing/selftests/ftrace/Makefile
> index 0acbeca..4e6ed13 100644
> --- a/tools/testing/selftests/ftrace/Makefile
> +++ b/tools/testing/selftests/ftrace/Makefile
> @@ -1,7 +1,7 @@
> all:
>
> TEST_PROGS := ftracetest
> -TEST_DIRS := test.d/
> +TEST_DIRS := test.d
>
> include ../lib.mk
>
> diff --git a/tools/testing/selftests/lib.mk b/tools/testing/selftests/lib.mk
> index 97f1c67..50a93f5 100644
> --- a/tools/testing/selftests/lib.mk
> +++ b/tools/testing/selftests/lib.mk
> @@ -12,13 +12,10 @@ run_tests: all
> $(RUN_TESTS)
>
> define INSTALL_RULE
> - @if [ "X$(TEST_PROGS)$(TEST_PROGS_EXTENDED)$(TEST_FILES)" != "X" ];
> then\
> - mkdir -p $(INSTALL_PATH);
> \
> - for TEST_DIR in $(TEST_DIRS); do
> \
> - cp -r $$TEST_DIR $(INSTALL_PATH);
> \
> - done;
> \
> - echo "install -t $(INSTALL_PATH) $(TEST_PROGS)
> $(TEST_PROGS_EXTENDED) $(TEST_FILES)"; \
> - install -t $(INSTALL_PATH) $(TEST_PROGS) $(TEST_PROGS_EXTENDED)
> $(TEST_FILES); \
> + @if [ "X$(TEST_PROGS)$(TEST_PROGS_EXTENDED)$(TEST_FILES)" != "X" ];
> then\
> + mkdir -p ${INSTALL_PATH};
> \
> + echo "rsync -a $(TEST_DIRS) $(TEST_PROGS)
> $(TEST_PROGS_EXTENDED) $(TEST_FILES) $(INSTALL_PATH)/"; \
What is the echo for?
> + rsync -a $(TEST_DIRS) $(TEST_PROGS) $(TEST_PROGS_EXTENDED)
> $(TEST_FILES) $(INSTALL_PATH)/; \
> fi
> endef
>
cheers
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/4] perf: Add function to enable perf events in kernel with ring buffer
perf_event_create_kernel_counter is used to enable perf events in kernel
without buffer for logging its events. This patch add new fucntion which
enable perf events with ring buffer. Intel PT logger uses this to enable
Intel PT and some associated events with its log buffer.
Signed-off-by: Takao Indoh
---
include/linux/perf_event.h | 10 ++
kernel/events/core.c | 70 ---
2 files changed, 75 insertions(+), 5 deletions(-)
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 2027809..34ada8c 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -657,6 +657,16 @@ perf_event_create_kernel_counter(struct perf_event_attr
*attr,
struct task_struct *task,
perf_overflow_handler_t callback,
void *context);
+extern struct perf_event *
+perf_event_create_kernel_counter_with_buffer(struct perf_event_attr *attr,
+ int cpu,
+ struct task_struct *task,
+ perf_overflow_handler_t callback,
+ void *context,
+ int flags,
+ int nr_pages,
+ int nr_pages_aux,
+ struct perf_event *output_event);
extern void perf_pmu_migrate_context(struct pmu *pmu,
int src_cpu, int dst_cpu);
extern u64 perf_event_read_value(struct perf_event *event,
diff --git a/kernel/events/core.c b/kernel/events/core.c
index ae16867..c9d8a59 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -8356,21 +8356,33 @@ err_fd:
}
/**
- * perf_event_create_kernel_counter
+ * perf_event_create_kernel_counter_with_buffer
*
* @attr: attributes of the counter to create
* @cpu: cpu in which the counter is bound
* @task: task to profile (NULL for percpu)
+ * @overflow_handler: handler for overflow event
+ * @context: target context
+ * @flags: flags of ring buffer
+ * @nr_pages: size (number of pages) of buffer
+ * @nr_pages_aux: size (number of pages) of aux buffer
+ * @output_event: event to be attached
*/
struct perf_event *
-perf_event_create_kernel_counter(struct perf_event_attr *attr, int cpu,
-struct task_struct *task,
-perf_overflow_handler_t overflow_handler,
-void *context)
+perf_event_create_kernel_counter_with_buffer(struct perf_event_attr *attr,
+ int cpu,
+ struct task_struct *task,
+ perf_overflow_handler_t overflow_handler,
+ void *context,
+ int flags,
+ int nr_pages,
+ int nr_pages_aux,
+ struct perf_event *output_event)
{
struct perf_event_context *ctx;
struct perf_event *event;
int err;
+ struct ring_buffer *rb = NULL;
/*
* Get the target context (task or percpu):
@@ -8383,6 +8395,31 @@ perf_event_create_kernel_counter(struct perf_event_attr
*attr, int cpu,
goto err;
}
+ if (output_event) {
+ err = perf_event_set_output(event, output_event);
+ if (err)
+ goto err_free;
+ } else if (nr_pages) {
+ rb = rb_alloc(nr_pages,
+ event->attr.watermark ? event->attr.wakeup_watermark : 0,
+ event->cpu, flags);
+
+ if (!rb) {
+ err = -ENOMEM;
+ goto err_free;
+ }
+
+ ring_buffer_attach(event, rb);
+
+ if (nr_pages_aux) {
+ err = rb_alloc_aux(rb, event, 0, nr_pages_aux,
+ event->attr.aux_watermark, flags);
+
+ if (err)
+ goto err_free;
+ }
+ }
+
/* Mark owner so we could distinguish it from user events. */
event->owner = EVENT_OWNER_KERNEL;
@@ -8411,10 +8448,33 @@ perf_event_create_kernel_counter(struct perf_event_attr
*attr, int cpu,
return event;
err_free:
+ if (rb && rb->aux_pages)
+ rb_free_aux(rb);
+ if (rb)
+ rb_free(rb);
free_event(event);
err:
return ERR_PTR(err);
}
+EXPORT_SYMBOL_GPL(perf_event_create_kernel_counter_with_buffer);
+
+/**
+ * perf_event_create_kernel_counter
+ *
+ * @attr: attributes of the counter to create
+ * @cpu: cpu in which the counter is bound
+ * @task: task to profile (NULL for percpu)
+ */
+struct perf_event *
[PATCH v2 4/4] x86: Stop Intel PT and save its registers when panic occurs
When panic occurs, Intel PT logging is stopped to prevent it from overwrite its log buffer. The registers of Intel PT are saved in the memory on panic, they are needed for debugger to find the last position where Intel PT wrote data. Signed-off-by: Takao Indoh --- arch/x86/kernel/crash.c |9 + 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c index e068d66..78deceb 100644 --- a/arch/x86/kernel/crash.c +++ b/arch/x86/kernel/crash.c @@ -35,6 +35,7 @@ #include #include #include +#include /* Alignment required for elf header segment */ #define ELF_CORE_HEADER_ALIGN 4096 @@ -127,6 +128,10 @@ static void kdump_nmi_callback(int cpu, struct pt_regs *regs) cpu_emergency_vmxoff(); cpu_emergency_svm_disable(); +#ifdef CONFIG_X86_INTEL_PT_LOG + save_intel_pt_registers(); +#endif + disable_local_APIC(); } @@ -172,6 +177,10 @@ void native_machine_crash_shutdown(struct pt_regs *regs) cpu_emergency_vmxoff(); cpu_emergency_svm_disable(); +#ifdef CONFIG_X86_INTEL_PT_LOG + save_intel_pt_registers(); +#endif + #ifdef CONFIG_X86_IO_APIC /* Prevent crash_kexec() from deadlocking on ioapic_lock. */ ioapic_zap_locks(); -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/4] x86: Intel Processor Trace Logger
Hi all, These patch series provide logging feature for Intel Processor Trace (Intel PT). Intel PT is a new feature of Intel CPU "Broadwell", it captures information about program execution flow. Here is a article about Intel PT. https://software.intel.com/en-us/blogs/2013/09/18/processor-tracing Once Intel PT is enabled, the events which change program flow, like branch instructions, exceptions, interruptions, traps and so on are logged in the memory. This is very useful for debugging because we can know the detailed behavior of software. This patch creates log buffer for Intel PT and enable logging at boot time. When kernel panic occurs, we can get this log buffer from crashdump file by kdump, and reconstruct the flow that led to the panic. changelog: v2: - Reimplement using perf_event_create_kernel_counter v1: https://lkml.org/lkml/2015/7/29/6 Takao Indoh (4): perf/trace: Add function to find event type by name perf: Add function to enable perf events in kernel with ring buffer perf/x86/intel/pt: Add Intel PT logger x86: Stop Intel PT and save its registers when panic occurs arch/x86/Kconfig | 16 +++ arch/x86/include/asm/intel_pt_log.h | 13 ++ arch/x86/kernel/cpu/Makefile |2 + arch/x86/kernel/cpu/intel_pt_log.c| 178 + arch/x86/kernel/cpu/perf_event_intel_pt.c |6 + arch/x86/kernel/crash.c |9 ++ include/linux/perf_event.h| 10 ++ include/linux/trace_events.h |2 + kernel/events/core.c | 70 +++- kernel/trace/trace_event_perf.c | 22 10 files changed, 323 insertions(+), 5 deletions(-) create mode 100644 arch/x86/include/asm/intel_pt_log.h create mode 100644 arch/x86/kernel/cpu/intel_pt_log.c -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/4] perf/x86/intel/pt: Add Intel PT logger
This patch provides Intel PT logging feature. When system boots with a
parameter "intel_pt_log", log buffers for Intel PT are allocated and
logging starts, then processor flow information is written in the log
buffer by hardware like flight recorder. This is very helpful to
investigate a cause of kernel panic.
The log buffer size is specified by the parameter
"intel_pt_log_buf_len=". This buffer is used as circular buffer,
therefore old events are overwritten by new events.
Signed-off-by: Takao Indoh
---
arch/x86/Kconfig | 16 +++
arch/x86/include/asm/intel_pt_log.h | 13 ++
arch/x86/kernel/cpu/Makefile |2 +
arch/x86/kernel/cpu/intel_pt_log.c| 178 +
arch/x86/kernel/cpu/perf_event_intel_pt.c |6 +
5 files changed, 215 insertions(+), 0 deletions(-)
create mode 100644 arch/x86/include/asm/intel_pt_log.h
create mode 100644 arch/x86/kernel/cpu/intel_pt_log.c
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index f37010f..2b99ba2 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1722,6 +1722,22 @@ config X86_INTEL_MPX
If unsure, say N.
+config X86_INTEL_PT_LOG
+ prompt "Intel PT logger"
+ def_bool n
+ depends on PERF_EVENTS && CPU_SUP_INTEL
+ ---help---
+ Intel PT is a hardware features that can capture information
+ about program execution flow. Once Intel PT is enabled, the
+ events which change program flow, like branch instructions,
+ exceptions, interruptions, traps and so on are logged in
+ the memory.
+
+ This option enables starting Intel PT logging feature at boot
+ time. When kernel panic occurs, Intel PT log buffer can be
+ retrieved from crash dump file and enables to reconstruct the
+ detailed flow that led to the panic.
+
config EFI
bool "EFI runtime service support"
depends on ACPI
diff --git a/arch/x86/include/asm/intel_pt_log.h
b/arch/x86/include/asm/intel_pt_log.h
new file mode 100644
index 000..cef63f7
--- /dev/null
+++ b/arch/x86/include/asm/intel_pt_log.h
@@ -0,0 +1,13 @@
+#ifndef __INTEL_PT_LOG_H__
+#define __INTEL_PT_LOG_H__
+
+#if defined(CONFIG_X86_INTEL_PT_LOG)
+
+#include
+
+void pt_log_start(struct pmu *pmu);
+void save_intel_pt_registers(void);
+
+#endif
+
+#endif /* __INTEL_PT_LOG_H__ */
diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
index 4eb065c..67c17f0 100644
--- a/arch/x86/kernel/cpu/Makefile
+++ b/arch/x86/kernel/cpu/Makefile
@@ -48,6 +48,8 @@ obj-$(CONFIG_PERF_EVENTS_INTEL_UNCORE)+=
perf_event_intel_uncore.o \
perf_event_intel_uncore_nhmex.o
obj-$(CONFIG_CPU_SUP_INTEL)+= perf_event_msr.o
obj-$(CONFIG_CPU_SUP_AMD) += perf_event_msr.o
+
+obj-$(CONFIG_X86_INTEL_PT_LOG) += intel_pt_log.o
endif
diff --git a/arch/x86/kernel/cpu/intel_pt_log.c
b/arch/x86/kernel/cpu/intel_pt_log.c
new file mode 100644
index 000..eb345fd
--- /dev/null
+++ b/arch/x86/kernel/cpu/intel_pt_log.c
@@ -0,0 +1,178 @@
+/*
+ * Intel Processor Trace Logger
+ *
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include
+#include
+
+#define SAMPLE_TYPE_BASE \
+ (PERF_SAMPLE_IP|PERF_SAMPLE_TID|PERF_SAMPLE_TIME|PERF_SAMPLE_IDENTIFIER)
+#define SAMPLE_TYPE_PT \
+ (SAMPLE_TYPE_BASE|PERF_SAMPLE_CPU|PERF_SAMPLE_RAW)
+#define SAMPLE_TYPE_SCHED \
+ (SAMPLE_TYPE_BASE|PERF_SAMPLE_CPU|PERF_SAMPLE_PERIOD|PERF_SAMPLE_RAW)
+#define SAMPLE_TYPE_DUMMY \
+ (SAMPLE_TYPE_BASE)
+
+/* intel_pt */
+static struct perf_event_attr pt_attr_pt = {
+ .config = 0x400, /* bit10: TSCEn */
+ .size = sizeof(struct perf_event_attr),
+ .sample_type= SAMPLE_TYPE_PT,
+ .read_format= PERF_FORMAT_ID,
+ .inherit= 1,
+ .pinned = 1,
+ .sample_id_all = 1,
+ .exclude_guest = 1
+};
+
+/* sched:sched_switch */
+static struct perf_event_attr pt_attr_sched = {
+ .type = PERF_TYPE_TRACEPOINT,
+ .size = sizeof(struct perf_event_attr),
+ .sample_type= SAMPLE_TYPE_SCHED,
+ .read_format= PERF_FORMAT_ID,
+ .inherit= 1,
+ .sample_id_all = 1,
+ .exclude_guest = 1
+};
+
+/* dummy:u */
+static struct perf_event_attr pt_attr_dummy = {
+ .type = PERF_TYPE_SOFTWARE,
+ .config = PERF_COUNT_SW_DUMMY,
+ .size = sizeof(struct perf_event_attr),
+ .sample_type= SAMPLE_TYPE_DUMMY,
+ .read_format= PERF_FORMAT_ID,
+ .inherit= 1,
+ .exclude_kernel = 1,
+ .exclude_hv = 1,
+ .comm = 1,
+ .task = 1,
+ .sample_id_all = 1,
+ .comm_exec = 1
+};
+
+static int pt_log_enabled;
+static int pt_log_buf_nr_pages = 128; /* number of pages for log buffer */
+static struct cpumask pt_log_cpu_mask;
[PATCH v2 1/4] perf/trace: Add function to find event type by name
This patch adds function to find struct trace_event by event name like
"sched_switch" , and return its type so that Intel PT logger can enable
the trace event in kernel. Intel PT logger needs this because it needs
sched_switch tracing to collect side-band data.
Signed-off-by: Takao Indoh
---
include/linux/trace_events.h|2 ++
kernel/trace/trace_event_perf.c | 22 ++
2 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/include/linux/trace_events.h b/include/linux/trace_events.h
index ed27917..d3cae4b 100644
--- a/include/linux/trace_events.h
+++ b/include/linux/trace_events.h
@@ -616,6 +616,8 @@ perf_trace_buf_submit(void *raw_data, int size, int rctx,
u64 addr,
{
perf_tp_event(addr, count, raw_data, size, regs, head, rctx, task);
}
+
+int perf_trace_event_get_type_by_name(char *system, char *name);
#endif
#endif /* _LINUX_TRACE_EVENT_H */
diff --git a/kernel/trace/trace_event_perf.c b/kernel/trace/trace_event_perf.c
index abfc903..1a851d5 100644
--- a/kernel/trace/trace_event_perf.c
+++ b/kernel/trace/trace_event_perf.c
@@ -21,6 +21,28 @@ typedef typeof(unsigned long [PERF_MAX_TRACE_SIZE /
sizeof(unsigned long)])
/* Count the events in use (per event id, not per instance) */
static int total_ref_count;
+int perf_trace_event_get_type_by_name(char *system, char *name)
+{
+ struct trace_event_call *tp_event;
+ int ret = 0;
+ /*
+* All type is larger than __TRACE_LAST_TYPE + 1. Therefore return zero
+* as a invalid type if not found.
+*/
+
+ mutex_lock(_mutex);
+ list_for_each_entry(tp_event, _events, list) {
+ if (!strcmp(tp_event->class->system, system) &&
+ !strcmp(trace_event_name(tp_event), name)) {
+ ret = tp_event->event.type;
+ break;
+ }
+ }
+ mutex_unlock(_mutex);
+
+ return ret;
+}
+
static int perf_trace_event_perm(struct trace_event_call *tp_event,
struct perf_event *p_event)
{
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 4/6] selftests: mqueue: simpification the Makefile
On Mon, 2015-09-07 at 22:04 +0800, Bamvor Jian Zhang wrote: > selftests: mqueue: simpification the Makefile This should be: selftests/mqueue: Simplify the Makefile And please write a change log, even for simple commits like this. You can say something like: Use make's implict rule for building simple C programs. > Suggested-by: Michael Ellermani > Signed-off-by: Bamvor Jian Zhang > --- > tools/testing/selftests/mqueue/Makefile | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/tools/testing/selftests/mqueue/Makefile > b/tools/testing/selftests/mqueue/Makefile > index ca8327f..9f51aaa 100644 > --- a/tools/testing/selftests/mqueue/Makefile > +++ b/tools/testing/selftests/mqueue/Makefile > @@ -1,8 +1,7 @@ > CFLAGS += -O2 > +LDLIBS = -lrt -lpthread -lpopt Please move the TEST_PROGS line here: TEST_PROGS := mq_open_tests mq_perf_tests > -all: > - $(CC) $(CFLAGS) mq_open_tests.c -o mq_open_tests -lrt > - $(CC) $(CFLAGS) -o mq_perf_tests mq_perf_tests.c -lrt -lpthread -lpopt > +all: mq_open_tests mq_perf_tests So this can become: all: $(TEST_PROGS) > > include ../lib.mk cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Use (two) different compilers at build-time?
On Tue, Sep 8, 2015 at 12:30 AM, Sedat Dilek wrote: > On Mon, Sep 7, 2015 at 11:20 PM, Sedat Dilek wrote: >> On Mon, Sep 7, 2015 at 10:59 PM, Linus Torvalds >> wrote: >>> On Mon, Sep 7, 2015 at 1:53 PM, Sedat Dilek wrote: That does not work. >>> >>> .. because you didn't do what I told you to do. >>> I copied a gcc-compiled percpu.o OR deleted/renamed percpu.o and re-invoked make - this starts a complete new build from scratch. >>> >>> Right. Because you changed the compiler name, so now the build system >>> realizes that the old build instructions are stale. >>> >>> Which is why you have to: >>> > Use a wrapper around the compiler (and point to that wrapper with the > "to switch compilers from under the make, without the build paths > changing (because otherwise our makefile auto-machinery notices that > flags and command changed). > > Use CC (or CROSS_COMPILE) to point at your wrapper. No idea how to realize that, sorry. >>> >>> Literally just do something like this: >>> >>> - have a shell script call "mycompiler" and make it do gcc/llvm "$@". >>> >>> - or even just use a symlink (the script has the advantage that you >>> can play with the options etc too) >>> >>> - change the shell script (or symlink) itself, and make sure to use >>> the same CC for "make" at all times, so that the build script never >>> sees that the underlying command is now different. >>> >>> It should work fine, I've done it a couple of times (although >>> admittedly not recently) >>> >> >> OK, I have created a mycompiler shell-script and use that for CC and >> HOSTCC in my own build-script. >> >> Using CLANG... >> >> [ /usr/bin/mycompiler ] >> >> #!/bin/bash >> >> clang "$@" >> - EOF - >> >> $ mycompiler --version >> clang version 3.7.0 (tags/RELEASE_370/final) >> Target: x86_64-unknown-linux-gnu >> Thread model: posix >> >> Switching to GCC... >> >> [ /usr/bin/mycompiler ] >> >> #!/bin/bash >> >> gcc-4.9 "$@" >> - EOF - >> >> $ mycompiler --version >> gcc-4.9 (Ubuntu 4.9.2-0ubuntu1~12.04) 4.9.2 >> Copyright (C) 2014 Free Software Foundation, Inc. >> This is free software; see the source for copying conditions. There is NO >> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. >> >> Thanks, that helped me a lot. >> > > Sadly, this trick does not work here with Linux v4.2. > So, the problem is any change to your make-lines. Means $COMPILER and/or compiler flags! I simplified in Makefile... COMPILER := clang export COMPILER and then did a symlink gcc-4.9 -> clang. This did NOT work because clang uses a compiler-flag '-no-integrated-as' which does not exist for gcc! So, switching from gcc -> clang or vice-versa is not possible with your compiler-wrapper-script trick :-(. Anyway, I need a different solution. One of my ideas was to hack the mm/Makefile. --- a/mm/Makefile +++ b/mm/Makefile @@ -2,6 +2,9 @@ # Makefile for the linux memory manager. # +COMPILER := gcc +export COMPILER + KASAN_SANITIZE_slab_common.o := n KASAN_SANITIZE_slub.o := n @@ -78,3 +81,6 @@ obj-$(CONFIG_CMA) += cma.o obj-$(CONFIG_MEMORY_BALLOON) += balloon_compaction.o obj-$(CONFIG_PAGE_EXTENSION) += page_ext.o obj-$(CONFIG_CMA_DEBUGFS) += cma_debug.o + +COMPILER := clang +export COMPILER Not sure if this works. - Sedat - -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/6] selftests: mqueue: allow extra cflags
On Mon, 2015-09-07 at 22:04 +0800, Bamvor Jian Zhang wrote: > change from = to += in order to pass the proper headers and librareis Please start your changelogs with a Capital letter, they are supposed to be proper English sentences. > (popt.h and libpopt.so) in order to build successful in cross > compiling. Yeah. More generally it allows the user to pass whatever CFLAGS they wish, which is a good feature. Acked-by: Michael Ellerman cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/6] selftests: only compile userfaultfd for x86 and powperpc
On Mon, 2015-09-07 at 22:04 +0800, Bamvor Jian Zhang wrote: > Check it before compiling to avoid the failure of building and > installation. I asked you not to do this. http://lkml.kernel.org/r/1440991580.5735.4.ca...@ellerman.id.au Can you tell me why you ignored my comments? cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/6] selftests: rename jump label to static_keys
On Mon, 2015-09-07 at 22:04 +0800, Bamvor Jian Zhang wrote:
> commit "2bf9e0a locking/static_keys: Provide a selftest" rename
^
d
> jump_label directory to static_keys.
... "and failed to update the Makefile, causing the selftests build to fail.
This commit fixes it by updating the Makefile with the new name and also moves
the entry into the correct position to keep the list alphabetically sorted."
Also the proper syntax for quoting a commit is:
Commit 2bf9e0ab08c6 ("locking/static_keys: Provide a selftest")
And ideally you also include a line saying:
Fixes: 2bf9e0ab08c6 ("locking/static_keys: Provide a selftest")
> Signed-off-by: Bamvor Jian Zhang
> ---
> tools/testing/selftests/Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/testing/selftests/Makefile
> b/tools/testing/selftests/Makefile
> index ac40ec9..8922c21 100644
> --- a/tools/testing/selftests/Makefile
> +++ b/tools/testing/selftests/Makefile
> @@ -17,12 +17,12 @@ TARGETS += powerpc
> TARGETS += ptrace
> TARGETS += seccomp
> TARGETS += size
> +TARGETS += static_keys
> TARGETS += sysctl
> ifneq (1, $(quicktest))
> TARGETS += timers
> endif
> TARGETS += user
> -TARGETS += jumplabel
> TARGETS += vm
> TARGETS += x86
> TARGETS += zram
Otherwise:
Acked-by: Michael Ellerman
cheers
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sched: fix lose fair sleeper bonus in switch_to_fair()
On 9/8/15 1:28 PM, Byungchul Park wrote:
On Tue, Sep 08, 2015 at 11:46:01AM +0800, Wanpeng Li wrote:
On 9/7/15 10:02 PM, Peter Zijlstra wrote:
Please always Cc at least the person who wrote the lines you modify.
On Mon, Sep 07, 2015 at 05:45:20PM +0800, Wanpeng Li wrote:
The sleeper task will be normalized when moved from fair_sched_class, in
order that vruntime will be adjusted either the task is running or sleeping
when moved back. The nomalization in switch_to_fair for sleep task will
result in lose fair sleeper bonus in place_entity() once the vruntime -
cfs_rq->min_vruntime is big when moved from fair_sched_class.
This patch fix it by adjusting vruntime just during migrating as original
codes since the vruntime of the task has usually NOT been normalized in
this case.
Sorry, I cannot follow that at all. Maybe its me being sleep deprived,
but could you try that again?
When changing away from the fair class while sleeping, relative
vruntime is calculated to handle the case sleep when moved from
fair_sched_class and running when moved to fair_sched_class. The
i don't think relative vruntime is calculated to handle the special case
you mentioned. i think the calculation is necessary for all cases detaching
Please refer why the relative vruntime caculation is introduced to
switched_from_fair(): https://lkml.org/lkml/2011/1/17/129
a task from a cfs_rq.
absolute vruntime will be calculated in enqueue_entity() either the
task is running or sleeping when moved back. The fair sleeper bonus
i think absolute vruntime is calculated in enqueue_entuty() only when the
task is on rq. therefore in the case that the task is not on rq,
switched_to_fair() has to calculate the absolute vruntime instread.
Absolute vruntime is caculated in place_entity() which is called by
enqueue_entity() for DEQUEUE_SLEEP task.
Regards,
Wanpeng Li
should be gained in place_entity() if the task is still sleeping.
However, after recent commit ( 23ec30ddd7c1306: 'sched: add two
functions for att(det)aching a task to(from) a cfs_rq'), the
absolute vruntime will be calculated in switched_to_fair(), so the
max_vruntime() which is called in place_entity() will select the
absolute vruntime which is calculated in switched_to_fair() as the
se->vruntime and lose the fair sleeper bonus.
please refer my another reply, and let me know if i missed something.
thanks,
byungchul
Regards,
Wanpeng Li
Signed-off-by: Wanpeng Li
---
kernel/sched/fair.c | 11 +++
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index d26d3b7..eb9aa35 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -8005,9 +8005,6 @@ static void attach_task_cfs_rq(struct task_struct *p)
/* Synchronize task with its cfs_rq */
attach_entity_load_avg(cfs_rq, se);
-
- if (!vruntime_normalized(p))
- se->vruntime += cfs_rq->min_vruntime;
}
static void switched_from_fair(struct rq *rq, struct task_struct *p)
@@ -8066,14 +8063,20 @@ void init_cfs_rq(struct cfs_rq *cfs_rq)
#ifdef CONFIG_FAIR_GROUP_SCHED
static void task_move_group_fair(struct task_struct *p)
{
+ struct sched_entity *se = >se;
+ struct cfs_rq *cfs_rq = cfs_rq_of(se);
+
detach_task_cfs_rq(p);
set_task_rq(p, task_cpu(p));
#ifdef CONFIG_SMP
/* Tell se's cfs_rq has been changed -- migrated */
- p->se.avg.last_update_time = 0;
+ se->avg.last_update_time = 0;
#endif
attach_task_cfs_rq(p);
+
+ if (!vruntime_normalized(p))
+ se->vruntime += cfs_rq->min_vruntime;
}
void free_fair_sched_group(struct task_group *tg)
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] crypto: testmgr: test IV value after a cipher operation
On Tue, Sep 08, 2015 at 05:23:59AM +0200, Stephan Mueller wrote: > Am Dienstag, 16. Juni 2015, 11:46:46 schrieb Boris Brezillon: > > Hi Herbert, > > >The crypto drivers are supposed to update the IV passed to the crypto > >request before calling the completion callback. > >Test for the IV value before considering the test as successful. > > May I ask whether there is anything wrong with this patch? > > I am asking because the keywrapping template I would like to release would > need the test manager to check the generated IV. There is nothing wrong with the patch. I just wanted to finish the skcipher conversion before adding this patch. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sched: fix lose fair sleeper bonus in switch_to_fair()
On Tue, Sep 08, 2015 at 11:46:01AM +0800, Wanpeng Li wrote:
> On 9/7/15 10:02 PM, Peter Zijlstra wrote:
> >Please always Cc at least the person who wrote the lines you modify.
> >
> >On Mon, Sep 07, 2015 at 05:45:20PM +0800, Wanpeng Li wrote:
> >>The sleeper task will be normalized when moved from fair_sched_class, in
> >>order that vruntime will be adjusted either the task is running or sleeping
> >>when moved back. The nomalization in switch_to_fair for sleep task will
> >>result in lose fair sleeper bonus in place_entity() once the vruntime -
> >>cfs_rq->min_vruntime is big when moved from fair_sched_class.
> >>
> >>This patch fix it by adjusting vruntime just during migrating as original
> >>codes since the vruntime of the task has usually NOT been normalized in
> >>this case.
> >Sorry, I cannot follow that at all. Maybe its me being sleep deprived,
> >but could you try that again?
>
> When changing away from the fair class while sleeping, relative
> vruntime is calculated to handle the case sleep when moved from
> fair_sched_class and running when moved to fair_sched_class. The
i don't think relative vruntime is calculated to handle the special case
you mentioned. i think the calculation is necessary for all cases detaching
a task from a cfs_rq.
> absolute vruntime will be calculated in enqueue_entity() either the
> task is running or sleeping when moved back. The fair sleeper bonus
i think absolute vruntime is calculated in enqueue_entuty() only when the
task is on rq. therefore in the case that the task is not on rq,
switched_to_fair() has to calculate the absolute vruntime instread.
> should be gained in place_entity() if the task is still sleeping.
> However, after recent commit ( 23ec30ddd7c1306: 'sched: add two
> functions for att(det)aching a task to(from) a cfs_rq'), the
> absolute vruntime will be calculated in switched_to_fair(), so the
> max_vruntime() which is called in place_entity() will select the
> absolute vruntime which is calculated in switched_to_fair() as the
> se->vruntime and lose the fair sleeper bonus.
please refer my another reply, and let me know if i missed something.
thanks,
byungchul
>
> Regards,
> Wanpeng Li
>
> >
> >>Signed-off-by: Wanpeng Li
> >>---
> >> kernel/sched/fair.c | 11 +++
> >> 1 files changed, 7 insertions(+), 4 deletions(-)
> >>
> >>diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> >>index d26d3b7..eb9aa35 100644
> >>--- a/kernel/sched/fair.c
> >>+++ b/kernel/sched/fair.c
> >>@@ -8005,9 +8005,6 @@ static void attach_task_cfs_rq(struct task_struct *p)
> >>/* Synchronize task with its cfs_rq */
> >>attach_entity_load_avg(cfs_rq, se);
> >>-
> >>- if (!vruntime_normalized(p))
> >>- se->vruntime += cfs_rq->min_vruntime;
> >> }
> >> static void switched_from_fair(struct rq *rq, struct task_struct *p)
> >>@@ -8066,14 +8063,20 @@ void init_cfs_rq(struct cfs_rq *cfs_rq)
> >> #ifdef CONFIG_FAIR_GROUP_SCHED
> >> static void task_move_group_fair(struct task_struct *p)
> >> {
> >>+ struct sched_entity *se = >se;
> >>+ struct cfs_rq *cfs_rq = cfs_rq_of(se);
> >>+
> >>detach_task_cfs_rq(p);
> >>set_task_rq(p, task_cpu(p));
> >> #ifdef CONFIG_SMP
> >>/* Tell se's cfs_rq has been changed -- migrated */
> >>- p->se.avg.last_update_time = 0;
> >>+ se->avg.last_update_time = 0;
> >> #endif
> >>attach_task_cfs_rq(p);
> >>+
> >>+ if (!vruntime_normalized(p))
> >>+ se->vruntime += cfs_rq->min_vruntime;
> >> }
> >> void free_fair_sched_group(struct task_group *tg)
> >>--
> >>1.7.1
> >>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Sep 8
Hi all, Please do not add material for v4.4 until after v4.3-rc1 is out. Changes since 20150903: I used the h8300 tree from next-20150828 since the current tree has been rebased onto something very old :-( The parisc-hd tree gained a conflict against Linus' tree. The v4l-dvb tree gained a conflict against Linus' tree. The drm-misc tree gained a build failure so I used the version from next-20150902. The kvm tree gained a build failure for which I reverted a commit. The akpm tree gained a build failure for which I added a merge fix patch. Non-merge commits (relative to Linus' tree): 1906 1645 files changed, 93741 insertions(+), 24534 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm defconfig. Below is a summary of the state of the merge. I am currently merging 225 trees (counting Linus' and 33 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (4e4adb2f4628 Merge tag 'nfs-for-4.3-1' of git://git.linux-nfs.org/projects/trondmy/linux-nfs) Merging fixes/master (c7e9ad7da219 Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip) Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on module install) Merging arc-current/for-curr (e4140819dadc ARC: signal handling robustify) Merging arm-current/fixes (3939f3345050 ARM: 8418/1: add boot image dependencies to not generate invalid images) Merging m68k-current/for-linus (1ecb40643a9a m68k/bootinfo: Use kmemdup rather than duplicating its implementation) Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached build errors) Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5) Merging powerpc-fixes/fixes (64291f7db5bd Linux 4.2) Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2) Merging sparc/master (73958c651fbf sparc64: use ENTRY/ENDPROC in VISsave) Merging net/master (46cdc9be0841 cxgb4: fix usage of uninitialized variable) Merging ipsec/master (93efac3f2e03 ipv6: Fix IPsec pre-encap fragmentation check) Merging sound-current/for-linus (5ee20bc79246 ALSA: usb-audio: Change internal PCM order) Merging pci-current/for-linus (45ea2a5fed6d PCI: Don't use 64-bit bus addresses on PA-RISC) Merging wireless-drivers/master (741e3b9902d1 rtlwifi: rtl8723be: Add module parameter for MSI interrupts) Merging driver-core.current/driver-core-linus (cbfe8fa6cd67 Linux 4.2-rc4) Merging tty.current/tty-linus (0de6cfb9f314 Revert "uart: pl011: Rename regs with enumeration") Merging usb.current/usb-linus (f7644cbfcdf0 Linux 4.2-rc6) Merging usb-gadget-fixes/fixes (c93e64e91248 usb: udc: core: add device_del() call to error pathway) Merging usb-serial-fixes/usb-linus (d071a3cdd2e1 USB: qcserial: add HP lt4111 LTE/EV-DO/HSPA+ Gobi 4G Module) Merging staging.current/staging-linus (7d9071a09502 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs) Merging char-misc.current/char-misc-linus (f7644cbfcdf0 Linux 4.2-rc6) Merging input-current/for-linus (01b944fe1cd4 Merge branch 'next' into for-linus) Merging crypto-current/master (71c6da846be4 crypto: ghash-clmulni: specify context size for ghash async algorithm) Merging ide/master (d681f1166919 ide: remove deprecated use of pci api) Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test for PPC_PSERIES) Merging rr-fixes/fixes (275d7d44d802 module: Fix locking in symbol_put_addr()) Merging vfio-fixes/for-linus (4bc94d5dc95d vfio: Fix lockdep issue) Merging kselftest-fixes/fixes
Re: eata fails to load on post 4.2 kernels
Hi Auhur,
Could you please help to apply the test patch
against the latest mainstream linux kernel?
Thanks!
Gerry
On 2015/9/7 14:26, Arthur Marsh wrote:
>
>
> Jiang Liu wrote on 07/09/15 12:36:
>> On 2015/9/7 4:31, Arthur Marsh wrote:
>>> Arthur Marsh wrote on 06/09/15 21:07:
Arthur Marsh wrote on 06/09/15 18:34:
> Arthur Marsh wrote on 06/09/15 15:58:
>> Hi, I'm seeing the following on post 4.2 kernels, am currently
>> bisecting
>> to find where it started:
First kernel in the bisection that worked without needing irqpoll:
[ 73.751482] EATA0: IRQ 10 mapped to IO-APIC IRQ 17.
[ 73.776711] EATA/DMA 2.0x: Copyright (C) 1994-2003 Dario Ballabio.
[ 73.802005] EATA config options -> tm:1, lc:y, mq:16, rs:y, et:n,
ip:n, ep:n, pp:y.
[ 73.829175] EATA0: 2.0C, PCI 0xd890, IRQ 17, BMST, SG 122, MB 64.
[ 73.82] EATA0: wide SCSI support enabled, max_id 16, max_lun 8.
[ 73.881125] EATA0: SCSI channel 0 enabled, host target ID 7.
>>>
>>> After a git bisect, I get:
>>>
>>> git bisect good
>>> 991de2e59090e55c65a7f59a049142e3c480f7bd is the first bad commit
>>> commit 991de2e59090e55c65a7f59a049142e3c480f7bd
>>> Author: Jiang Liu
>>> Date: Wed Jun 10 16:54:59 2015 +0800
>>>
>>> PCI, x86: Implement pcibios_alloc_irq() and pcibios_free_irq()
>>>
>>> To support IOAPIC hotplug, we need to allocate PCI IRQ resources on
>>> demand
>>> and free them when not used anymore.
>>>
>>> Implement pcibios_alloc_irq() and pcibios_free_irq() to dynamically
>>> allocate and free PCI IRQs.
>>>
>>> Remove mp_should_keep_irq(), which is no longer used.
>>>
>>> [bhelgaas: changelog]
>>> Signed-off-by: Jiang Liu
>>> Signed-off-by: Bjorn Helgaas
>>> Acked-by: Thomas Gleixner
>>>
>>> :04 04 765e2d5232d53247ec260b34b51589c3bccb36ae
>>> f680234a27685e94b1a35ae2a7218f8eafa9071a M arch
>>> :04 04 d55a682bcde72682e883365e88ad1df6186fd54d
>>> f82c470a04a6845fcf5e0aa934512c75628f798d M drivers
>>>
>>> I'm happy to supply more details if needed.
>> Hi Arthur,
>> Thanks for reporting this. It seems to be an irq misrouting
>> issue. Could you please help to provide:
>> 1) full dmesg with the latest code
>> 2) full dmesg and /proc/interrupts with the latest code and
>> kernel parameter "irqpoll" specified
>> Thanks!
>> Gerry
>
> The pc locks up when loading the eata module so I've attached a photo of
> the monitor screen.
>
> Arthur.
>
>
>From 3085626fb2e677c1d88f158397948935b73f5239 Mon Sep 17 00:00:00 2001
From: Jiang Liu
Date: Tue, 8 Sep 2015 10:41:19 +0800
Subject: [PATCH]
Signed-off-by: Jiang Liu
---
drivers/pci/pci-driver.c |1 +
drivers/scsi/eata.c |2 ++
2 files changed, 3 insertions(+)
diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
index 52a880ca1768..17d2a0b1de18 100644
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -392,6 +392,7 @@ int __weak pcibios_alloc_irq(struct pci_dev *dev)
{
return 0;
}
+EXPORT_SYMBOL_GPL(pcibios_alloc_irq);
void __weak pcibios_free_irq(struct pci_dev *dev)
{
diff --git a/drivers/scsi/eata.c b/drivers/scsi/eata.c
index 227dd2c2ec2f..7e6eaf867987 100644
--- a/drivers/scsi/eata.c
+++ b/drivers/scsi/eata.c
@@ -1061,6 +1061,7 @@ static void enable_pci_ports(void)
driver_name, dev->bus->number, dev->devfn);
#endif
+ pcibios_alloc_irq(dev);
if (pci_enable_device(dev))
printk
("%s: warning, pci_enable_device failed, bus %d devfn 0x%x.\n",
@@ -1520,6 +1521,7 @@ static void add_pci_ports(void)
if (!(dev = pci_get_class(PCI_CLASS_STORAGE_SCSI << 8, dev)))
break;
+ pcibios_alloc_irq(dev);
if (pci_enable_device(dev)) {
#if defined(DEBUG_PCI_DETECT)
printk
--
1.7.10.4
Re: [PATCH] zram: don't copy invalid compression algorithms
On (09/08/15 13:50), Minchan Kim wrote: > For exmaple, disksize, max_comp_streams are changed only if > it is successful. > If your logic were right approach, we should change > max_comp_streams for *stupid* script although it doesn't check define stupid. is echo 210 > /sys/block/zram0/max_comp_streams clever or stupid? do we control mem_limit_store()? no. do we contol mem_used_max_store()? no. if user asks to redefine a "default" value we just let him do so. -ss -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/4] cpufreq-dt: add suspend frequency support
On 08-09-15, 13:48, Krzysztof Kozlowski wrote: > Somehow my mind stuck on solving Exynos4x12 cpufreq issues. > > Right, it should go through Rafael's, probably except DTS patch (4/4) > because it depends on previous DTS changes. These changes are still in > arm-soc, not in Linus' tree [0]. That's bad :( Anyway, 4/4 is kind of independent to this series, in the sense that it wouldn't harm even if it gets applied separately. So, go ahead and apply 4/4 to Samsung's tree and rest of this can be picked by Rafael. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] leds:lp55xx: Correct Kconfig dependency for f/w user helper
On Tue, 08 Sep 2015 02:30:07 +0200,
Kim, Milo wrote:
>
> Hi Takashi,
>
> On 9/7/2015 11:19 PM, Jacek Anaszewski wrote:
> > Hi Takashi,
> >
> > Thanks for chasing this.
> > Milo, could you express your opinion?
> >
> > On 09/07/2015 02:25 PM, Takashi Iwai wrote:
> >> The commit [b67893206fc0: leds:lp55xx: fix firmware loading error]
> >> tries to address the firmware file handling with user helper, but it
> >> sets a wrong Kconfig CONFIG_FW_LOADER_USER_HELPER_FALLBACK. Since the
> >> wrong option was enabled, the system got a regression -- it suffers
> >> from the unexpected long delays for non-present firmware files.
> >>
> >> This patch corrects the Kconfig dependency to the right one,
> >> CONFIG_FW_LOADER_USER_HELPER. This doesn't change the fallback
> >> behavior but only enables UMH when needed.
> >>
> >> Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=944661
> >> Fixes: b67893206fc0 ('leds:lp55xx: fix firmware loading error')
> >> Cc: # v4.2+
> >> Signed-off-by: Takashi Iwai
> >> ---
> >>drivers/leds/Kconfig | 2 +-
> >>1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> >> index 70f4255ff291..2ba52bc2e174 100644
> >> --- a/drivers/leds/Kconfig
> >> +++ b/drivers/leds/Kconfig
> >> @@ -229,7 +229,7 @@ config LEDS_LP55XX_COMMON
> >>tristate "Common Driver for TI/National
> >> LP5521/5523/55231/5562/8501"
> >>depends on LEDS_LP5521 || LEDS_LP5523 || LEDS_LP5562 ||
> >> LEDS_LP8501
> >>select FW_LOADER
> >> - select FW_LOADER_USER_HELPER_FALLBACK
> >> + select FW_LOADER_USER_HELPER
> >>help
> >> This option supports common operations for
> >> LP5521/5523/55231/5562/8501
> >> devices.
>
> Thank for catching this. It seems I misunderstood firmware helper
> configuration. LP55xx driver uses firmware interface to activate LED
> visual effect. So this driver enables FW_LOADER_USER_HELPER_FALLBACK and
> calls request_firmware_nowait() without uevent. Then, it will try to
> load raw data manually when binary(firmware) file doesn't exist.
>
> I'm still not clear what the difference is between FW_LOADER_USER_HELPER
> and FW_LOADER_USER_HELPER_FALLBACK. Kconfig description makes me confused.
> Could you explain it in more details?
FW_LOADER_USER_HELPER_FALLBACK globally enables the fallback to user
helper mode when no file is loaded by the direct f/w loader. It
automatically sets FW_LOADER_USER_HELPER.
OTOH, when FW_LOADER_USER_HELPER is set, requeset_firmware_nowait()
does user mode fallback only when uevent (the second) argument is
false. Note that this is a special case. In the usual cases --
uevent = true or request_firmware() -- its doesn't enable the
fallback.
The fallback to user helper mode is bad for the recent udev, since
udev already dropped the f/w support code completely. Thus every
non-existing f/w load will result in 60 seconds stall.
In short, FW_LOAD_USER_HELPER_FALLBACK is present mostly only for
older systems, just for compatibility. For drivers that need the no
direct f/w load and no udev interaction, set FW_LOAD_USER_HELPER
instead.
Takashi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] zram: don't copy invalid compression algorithms
On (09/08/15 13:50), Minchan Kim wrote: [..] > And it's straightforward/consistent to change the thing's state > only if is successful. > what for? I provided several good reasons not to do this, because it makes life easier for users. we added this check in Jun 25, 2015 while this functionality and scripts have been around for years, and apparently now it's users' problem and they must go and do something. seriously, what improvement this change brings in the first place? what does it make better and for whom? -ss -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 1/2] perf,kvm/powerpc: Add kvm_perf.h for powerpc
On 09/07/2015 10:40 AM, Michael Ellerman wrote:
On Fri, 2015-09-04 at 17:51 -0300, Arnaldo Carvalho de Melo wrote:
Em Tue, Sep 01, 2015 at 12:18:47PM +0530, Hemant Kumar escreveu:
Should I try to process the 5 together, applying thest two first?
Yes, this patchset needs to be applied before applying the other patchset,
since there is a direct dependency on these two for the tooling part to
work.
I see there are no acks from powerpc arch maintainers, how should we
proceed here? If there are no problems with the arch bits, and if it is
just to enable the tooling part, again, should I process the 5 as just
one series?
The reason to split the earlier patchset into two was to separate the
tooling/perf/ and arch/powerpc/ side patches, as asked by Michael..
Here is the link to that discussion :
http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg86916.html
If Michael is ok with the patches, you can process all the 5 patches
together. Michael?
Michael?
I'm not particularly happy with it.
Can we at least remove this hunk from the uapi header:
+/* This is to shut the compiler up */
+#define KVM_ENTRY_TRACE ""
+#define KVM_EXIT_TRACE ""
+#define KVM_EXIT_REASON ""
Agreed, I didn't like this too, but I kept this because of the generic
perf userspace code that looks for KVM_{ENTRY,EXIT}_TRACE and
KVM_EXIT_REASON. We can remove this and put this hunk in the
userspace side.
Arnaldo,
Can we remove the dependency on uapi altogether (also suggested
by Scott) because it doesn't seem to fulfill much purpose? Rather,
hardcode the events in the userspace completely (since, tracepoint
event names are unlikely to change) ? Some of what is being done
by x86 already in kvm-stat.c where its defining kvm_events_tp[] and
its not using the macros, rather, the tracepoints directly. Macros are
only being used in builtin-kvm.c where the tracepoint names are
matched with KVM_{ENTRY,EXIT}_TRACE and when we are looking
for the key KVM_EXIT_REASON.
--
Thanks,
Hemant Kumar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [git pull] drm for 4.3
On 8 September 2015 at 14:04, Stephen Rothwell wrote: > Hi Dave, > > On Tue, 8 Sep 2015 13:01:21 +1000 Dave Airlie wrote: >> >> Is this to be a regular thing? because I know I'd prefer to merge >> fixes than wait for -rc1 to be an accurate copy of linux-next. > > It happens when I can (almost) keep up with Linus' merge rate (often I > can't). It is not an issue and I agree that fixes should just be done > as/when needed. That is why I say "not judging, just noting" - I > generally don't have the time to figure out if each and every unseen > commit is a fix or new feature and/or if it has some possibility of > interacting with some other tree in a way that a few days in linux-next > may have flushed out. > > So, if you are happy with what you are doing (and you don't irritate > Linus), then I am happy (as long as you don't cause unnecessary extra > conflicts in linux-next :-)). > Maybe you could heuristic it by ratio new commits or new lines vs the total size of the -next tree. i.e. 59 commits in a 5000 commit tree is likely not that bad, 59 commits in a 20 commit tree would be bad. Though not sure how you'd tune it! Dave. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the akpm tree
Hi Andrew,
After merging the akpm tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/net/ieee802154/at86rf230.c: In function 'at86rf230_stats_show':
drivers/net/ieee802154/at86rf230.c:1650:6: error: void value not ignored as it
ought to be
ret = seq_printf(file, "SUCCESS:\t\t%8llu\n", lp->trac.success);
^
drivers/net/ieee802154/at86rf230.c:1654:6: error: void value not ignored as it
ought to be
ret = seq_printf(file, "SUCCESS_DATA_PENDING:\t%8llu\n",
^
drivers/net/ieee802154/at86rf230.c:1659:6: error: void value not ignored as it
ought to be
ret = seq_printf(file, "SUCCESS_WAIT_FOR_ACK:\t%8llu\n",
^
drivers/net/ieee802154/at86rf230.c:1664:6: error: void value not ignored as it
ought to be
ret = seq_printf(file, "CHANNEL_ACCESS_FAILURE:\t%8llu\n",
^
drivers/net/ieee802154/at86rf230.c:1669:6: error: void value not ignored as it
ought to be
ret = seq_printf(file, "NO_ACK:\t\t\t%8llu\n", lp->trac.no_ack);
^
drivers/net/ieee802154/at86rf230.c:1673:2: error: void value not ignored as it
ought to be
return seq_printf(file, "INVALID:\t\t%8llu\n", lp->trac.invalid);
^
drivers/net/ieee802154/at86rf230.c:1674:1: warning: control reaches end of
non-void function [-Wreturn-type]
}
^
Caused by commit
890acf8330ca ("at86rf230: add debugfs support")
from the bluetooth tree interacting with commit
0287f0d7576f ("fs/seq_file: convert int seq_vprint/seq_printf/etc... returns
to void")
from the akpm tree.
I have added the following fix patch for today:
From: Stephen Rothwell
Date: Tue, 8 Sep 2015 14:48:11 +1000
Subject: [PATCH]
fs-seq_file-convert-int-seq_vprint-seq_printf-etc-returns-to-void-fix-fix-fix
Signed-off-by: Stephen Rothwell
---
drivers/net/ieee802154/at86rf230.c | 28 +++-
1 file changed, 7 insertions(+), 21 deletions(-)
diff --git a/drivers/net/ieee802154/at86rf230.c
b/drivers/net/ieee802154/at86rf230.c
index b8b0628dc2f3..a9f3af63e590 100644
--- a/drivers/net/ieee802154/at86rf230.c
+++ b/drivers/net/ieee802154/at86rf230.c
@@ -1647,30 +1647,16 @@ static int at86rf230_stats_show(struct seq_file *file,
void *offset)
struct at86rf230_local *lp = file->private;
int ret;
- ret = seq_printf(file, "SUCCESS:\t\t%8llu\n", lp->trac.success);
- if (ret < 0)
- return ret;
-
- ret = seq_printf(file, "SUCCESS_DATA_PENDING:\t%8llu\n",
+ seq_printf(file, "SUCCESS:\t\t%8llu\n", lp->trac.success);
+ seq_printf(file, "SUCCESS_DATA_PENDING:\t%8llu\n",
lp->trac.success_data_pending);
- if (ret < 0)
- return ret;
-
- ret = seq_printf(file, "SUCCESS_WAIT_FOR_ACK:\t%8llu\n",
+ seq_printf(file, "SUCCESS_WAIT_FOR_ACK:\t%8llu\n",
lp->trac.success_wait_for_ack);
- if (ret < 0)
- return ret;
-
- ret = seq_printf(file, "CHANNEL_ACCESS_FAILURE:\t%8llu\n",
+ seq_printf(file, "CHANNEL_ACCESS_FAILURE:\t%8llu\n",
lp->trac.channel_access_failure);
- if (ret < 0)
- return ret;
-
- ret = seq_printf(file, "NO_ACK:\t\t\t%8llu\n", lp->trac.no_ack);
- if (ret < 0)
- return ret;
-
- return seq_printf(file, "INVALID:\t\t%8llu\n", lp->trac.invalid);
+ seq_printf(file, "NO_ACK:\t\t\t%8llu\n", lp->trac.no_ack);
+ seq_printf(file, "INVALID:\t\t%8llu\n", lp->trac.invalid);
+ return 0;
}
static int at86rf230_stats_open(struct inode *inode, struct file *file)
--
2.5.1
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] zram: don't copy invalid compression algorithms
On Tue, Sep 08, 2015 at 10:58:31AM +0900, Sergey Senozhatsky wrote: > On (09/08/15 10:33), Sergey Senozhatsky wrote: > > > I don't understand your concern. To me, this patch makes sense to me. > > > Could you explain your point clearly, again? > > > > OK. suppose someone landed a typo in a 'zram device management' script > > > > echo llzo > /sys/block/zram0/comp_algorithm > > -bash: echo: write error: Invalid argument > > > > > > but the script ignores 'echo: write error'. > > Because we added compression algorithm name check recently. > > > > then the script does > > > > echo 200M > /sys/block/zram0/disksize > > -bash: echo: write error: Invalid argument > > > > > > doing a simple dmesg reveals the problem > > > > [ 7076.657184] zram: Cannot initialise llzo compressing backend > > > > note that zram provides 'llzo' here, which is convenient. > > ah, forgot to mention. there is another misleading thing. > > suppose the script checks the comp_algorithm() error code. > and it attempts to do somthing like > echo llzo > /sys/block/zram0/comp_algorithm > -bash: echo: write error: Device or resource busy > > > so user knows that comp_algorithm failed. so now > he/she goes and checks zram > > cat /sys/block/zram0/comp_algorithm > [lzo] lz4 > > > and finds out... that [lzo] is supported and selected for usage. > > so what't the problem then? so user wrongly assumes now that the > script has provided 'lzo' as input to zram... false! > > > > the existing scheme of things will provide additional hint. > > #current implementation > cat /sys/block/zram0/comp_algorithm > lzo lz4 > > so, none of the supported compression algorithms is selected. > aha, that is obviously lead us to a conclusion that something > wrong was with the input that script provided to zram. correct! The problem is caused by that user skipped check of whether his action was successful or not. IOW, script should have chekcked status of "echo llzo > ". User shouldn't rely on dmesg. So, I don't think it's good idea to paper over user's mistake. And it's straightforward/consistent to change the thing's state only if is successful. For exmaple, disksize, max_comp_streams are changed only if it is successful. If your logic were right approach, we should change max_comp_streams for *stupid* script although it doesn't check return value of doing. It doesn't sound to make sense to me. > > -ss -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/4] cpufreq-dt: add suspend frequency support
On 08.09.2015 13:20, Viresh Kumar wrote: > On 08-09-15, 12:56, Krzysztof Kozlowski wrote: >> There were no comments from your side for this patchset nor for previous >> Marek's fix. After mentioned change and Bart's re-spin, do you plan to >> grab this patchset and send it for current v4.3 cycle? > > Why do you think it should go via Kukjin's tree and not Rafael's? Somehow my mind stuck on solving Exynos4x12 cpufreq issues. Right, it should go through Rafael's, probably except DTS patch (4/4) because it depends on previous DTS changes. These changes are still in arm-soc, not in Linus' tree [0]. Best regards, Krzysztof [0] https://git.kernel.org/cgit/linux/kernel/git/arm/arm-soc.git/commit/?h=next/late=f44997412e5b39b6a1231f16555120c5b2aae0ed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the drm-misc tree
Op 08-09-15 om 01:42 schreef Stephen Rothwell:
> Hi all,
>
> On Thu, 3 Sep 2015 10:49:19 +1000 Stephen Rothwell
> wrote:
>> After merging the drm-misc tree, today's linux-next build (arm
>> multi_v7_defconfig) failed like this:
>>
>> drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c: In function
>> 'mdp5_plane_cleanup_fb':
>> drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c:272:26: error: 'fb' redeclared as
>> different kind of symbol
>> struct drm_framebuffer *fb = old_state->fb;
>> ^
>> drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c:267:27: note: previous definition
>> of 'fb' was here
>>struct drm_framebuffer *fb,
>>^
>> drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c: At top level:
>> drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c:383:3: warning: initialization
>> from incompatible pointer type
>>.cleanup_fb = mdp5_plane_cleanup_fb,
>>^
>> drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c:383:3: warning: (near
>> initialization for 'mdp5_plane_helper_funcs.cleanup_fb')
>>
>> Caused by commit
>>
>> a317290af0db ("drm/atomic: Make prepare_fb/cleanup_fb only take state, v3")
>>
>> Well, that was clearly never build tested :-(
>>
>> I have used the drm-misc tree from next-20150902 for today.
> This is still in today's linux-next :-(
>
I just got around to making an amend fix patch for it yesterday. Can you fold
it into v3 daniel?
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
index 4d390b699e9a..a0f5ff0ce8dc 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
@@ -264,7 +264,6 @@ static int mdp5_plane_prepare_fb(struct drm_plane *plane,
}
static void mdp5_plane_cleanup_fb(struct drm_plane *plane,
- struct drm_framebuffer *fb,
const struct drm_plane_state *old_state)
{
struct mdp5_plane *mdp5_plane = to_mdp5_plane(plane);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/4] cpufreq-dt: add suspend frequency support
On 08-09-15, 12:56, Krzysztof Kozlowski wrote: > There were no comments from your side for this patchset nor for previous > Marek's fix. After mentioned change and Bart's re-spin, do you plan to > grab this patchset and send it for current v4.3 cycle? Why do you think it should go via Kukjin's tree and not Rafael's? -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] selftests: add membarrier syscall test
On Mon, 2015-09-07 at 16:01 +, Mathieu Desnoyers wrote: > - On Sep 3, 2015, at 11:36 PM, Michael Ellerman m...@ellerman.id.au wrote: > > On Thu, 2015-09-03 at 15:47 +, Mathieu Desnoyers wrote: > >> > >> My personal experience is that make headers_install does not necessarily > >> play > >> well with the distribution header file hierarchy, which requires some > >> tweaks > >> to be done by the users (e.g. asm vs x86_64-linux-gnu). > > > > OK, I've never had issues. What exactly are you doing and how is it going > > wrong? > > After some investigation, I noticed the following: > > 1) I first ran make headers_install as root, which installed the > headers within my build tree. I later tried it again as user, and > it failed due to permission issues (my bad). This is where I tried > to install it into my system rather than under my build directory, > which caused a mess. Yeah OK that's a good point about root. I tend to build as a regular user and then copy the installed tests to another machine where I run them as root. > 2) Since make kselftest should be run as root (according to make > help), Well some of the tests only work when run as root. IMHO we should support running as many tests as possible as non-root, but some of them obviously require root. So you can run them as non-root, but to get maximum coverage you need to run them as root. > this means that all the output files generated by the build > are owned by root. It leads to permissions issues when trying to > rebuild the tests as user afterward. Perhaps we could introduce a > distinction between make kselftest_build and make kselftest_run ? > The former could be executed as user, and the latter as root. Right. Personally I don't use the kselftest target at all, I just cd down to tools/testing/selftests and run make there. If it was up to me the kselftest target would go away, because it's only caused us trouble so far. But given it's there we should try to make it work as well as possible. So yeah splitting it into build and run would make sense, that way you could do: $ make headers_install $ make kselftest_build $ sudo make kselftest_run And that would hopefully do the right thing. Would that improve the workflow for you? > > So that seems to be working for me. Are you doing some different work flow, > > or > > am I just missing something? > > When doing make headers_install, it indeed installs > membarrier.h where we expect it under the build output > dir: > > $ ls usr/include/linux/membarrier.h > usr/include/linux/membarrier.h > > However, if I issue > > $ make -C tools/testing/selftests TARGETS=membarrier > make: Entering directory > `/home/efficios/git/linux-next/tools/testing/selftests' > for TARGET in membarrier; do \ > make -C $TARGET; \ > done; > make[1]: Entering directory > `/home/efficios/git/linux-next/tools/testing/selftests/membarrier' > gcc membarrier_test.c -o membarrier_test > membarrier_test.c:2:30: fatal error: linux/membarrier.h: No such file or > directory > #include > > This is after applying the modifications you requested > (see patch attached). Perhaps I did something wrong ? Yeah sorry, you still need the -I line: CFLAGS += -I../../../../usr/include/ We /should/ add that to lib.mk so it's inherited by everyone, but we haven't yet. So I think if you put that back the instructions I gave you will work? cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git pull] drm for 4.3
Hi Dave, On Tue, 8 Sep 2015 13:01:21 +1000 Dave Airlie wrote: > > Is this to be a regular thing? because I know I'd prefer to merge > fixes than wait for -rc1 to be an accurate copy of linux-next. It happens when I can (almost) keep up with Linus' merge rate (often I can't). It is not an issue and I agree that fixes should just be done as/when needed. That is why I say "not judging, just noting" - I generally don't have the time to figure out if each and every unseen commit is a fix or new feature and/or if it has some possibility of interacting with some other tree in a way that a few days in linux-next may have flushed out. So, if you are happy with what you are doing (and you don't irritate Linus), then I am happy (as long as you don't cause unnecessary extra conflicts in linux-next :-)). -- Cheers, Stephen Rothwells...@canb.auug.org.au -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] powerpc32: memcpy: only use dcbz once cache is enabled
On Mon, 2015-09-07 at 16:24 +0200, Christophe Leroy wrote: > memcpy() uses instruction dcbz to speed up copy by not wasting time > loading cache line with data that will be overwritten. > Some platform like mpc52xx do no have cache active at startup and > can therefore not use memcpy(). Allthough no part of the code > explicitly uses memcpy(), GCC makes calls to it. > > This patch modifies memcpy() such that at startup, the 'dcbz' > instruction is replaced by 'dcbt' which is harmless if cache is not > enabled, and which helps a bit (allthough not as much as dcbz) if > cache is already enabled. > > Once the initial MMU is setup, in machine_init() we patch memcpy() > by replacing the temporary 'dcbt' by 'dcbz' > > Reported-by: Michal Sojka > Signed-off-by: Christophe Leroy Is there some reason you can't use the normal cpu feature sections? See arch/powerpc/lib/memcpy_64.S for an example of what I mean. cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/4] cpufreq-dt: add suspend frequency support
On 08.09.2015 11:46, Viresh Kumar wrote: > On 07-09-15, 17:41, Bartlomiej Zolnierkiewicz wrote: >> Hi, >> >> This patch series adds suspend frequency support (using opp-v2 >> bindings and suspend-opp functionality) to cpufreq-dt driver and >> then adds suspend opp for Exynos4412 based boards. >> >> This patch series fixes suspend/resume support on Exynos4412 >> based Trats2 board and reboot hang on Exynos4412 based Odroid >> U3 board. >> >> Changes since v3: >> - fixed dev_pm_opp_get_suspend_opp() locking >> - shortened variable name in dev_pm_opp_get_suspend_opp() >> - adjusted cpufreq_generic_suspend() to work with cpufreq-dt >> - removed no longer needed cpufreq_dt_suspend() >> - added Acked-by tag from Viresh to patch #4 > > Just a minor comment on 3/4 and after fixing that: > > Acked-by: Viresh Kumar Dear Kukjin, There were no comments from your side for this patchset nor for previous Marek's fix. After mentioned change and Bart's re-spin, do you plan to grab this patchset and send it for current v4.3 cycle? Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sched: fix lose fair sleeper bonus in switch_to_fair()
On 9/7/15 10:02 PM, Peter Zijlstra wrote:
Please always Cc at least the person who wrote the lines you modify.
On Mon, Sep 07, 2015 at 05:45:20PM +0800, Wanpeng Li wrote:
The sleeper task will be normalized when moved from fair_sched_class, in
order that vruntime will be adjusted either the task is running or sleeping
when moved back. The nomalization in switch_to_fair for sleep task will
result in lose fair sleeper bonus in place_entity() once the vruntime -
cfs_rq->min_vruntime is big when moved from fair_sched_class.
This patch fix it by adjusting vruntime just during migrating as original
codes since the vruntime of the task has usually NOT been normalized in
this case.
Sorry, I cannot follow that at all. Maybe its me being sleep deprived,
but could you try that again?
When changing away from the fair class while sleeping, relative vruntime
is calculated to handle the case sleep when moved from fair_sched_class
and running when moved to fair_sched_class. The absolute vruntime will
be calculated in enqueue_entity() either the task is running or sleeping
when moved back. The fair sleeper bonus should be gained in
place_entity() if the task is still sleeping. However, after recent
commit ( 23ec30ddd7c1306: 'sched: add two functions for att(det)aching a
task to(from) a cfs_rq'), the absolute vruntime will be calculated in
switched_to_fair(), so the max_vruntime() which is called in
place_entity() will select the absolute vruntime which is calculated in
switched_to_fair() as the se->vruntime and lose the fair sleeper bonus.
Regards,
Wanpeng Li
Signed-off-by: Wanpeng Li
---
kernel/sched/fair.c | 11 +++
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index d26d3b7..eb9aa35 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -8005,9 +8005,6 @@ static void attach_task_cfs_rq(struct task_struct *p)
/* Synchronize task with its cfs_rq */
attach_entity_load_avg(cfs_rq, se);
-
- if (!vruntime_normalized(p))
- se->vruntime += cfs_rq->min_vruntime;
}
static void switched_from_fair(struct rq *rq, struct task_struct *p)
@@ -8066,14 +8063,20 @@ void init_cfs_rq(struct cfs_rq *cfs_rq)
#ifdef CONFIG_FAIR_GROUP_SCHED
static void task_move_group_fair(struct task_struct *p)
{
+ struct sched_entity *se = >se;
+ struct cfs_rq *cfs_rq = cfs_rq_of(se);
+
detach_task_cfs_rq(p);
set_task_rq(p, task_cpu(p));
#ifdef CONFIG_SMP
/* Tell se's cfs_rq has been changed -- migrated */
- p->se.avg.last_update_time = 0;
+ se->avg.last_update_time = 0;
#endif
attach_task_cfs_rq(p);
+
+ if (!vruntime_normalized(p))
+ se->vruntime += cfs_rq->min_vruntime;
}
void free_fair_sched_group(struct task_group *tg)
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] crypto: testmgr: test IV value after a cipher operation
Am Dienstag, 16. Juni 2015, 11:46:46 schrieb Boris Brezillon:
Hi Herbert,
>The crypto drivers are supposed to update the IV passed to the crypto
>request before calling the completion callback.
>Test for the IV value before considering the test as successful.
May I ask whether there is anything wrong with this patch?
I am asking because the keywrapping template I would like to release would
need the test manager to check the generated IV.
Thanks a lot.
>
>Signed-off-by: Boris Brezillon
>---
> crypto/testmgr.c | 12 +++-
> crypto/testmgr.h | 1 +
> 2 files changed, 12 insertions(+), 1 deletion(-)
>
>diff --git a/crypto/testmgr.c b/crypto/testmgr.c
>index f9bce3d..e6b5f24 100644
>--- a/crypto/testmgr.c
>+++ b/crypto/testmgr.c
>@@ -1013,12 +1013,22 @@ static int __test_skcipher(struct crypto_ablkcipher
>*tfm, int enc,
>
> q = data;
> if (memcmp(q, template[i].result, template[i].rlen)) {
>- pr_err("alg: skcipher%s: Test %d failed on %s for
%s\n",
>+ pr_err("alg: skcipher%s: Test %d failed (invalid
result) on %s for %s\n",
>d, j, e, algo);
> hexdump(q, template[i].rlen);
> ret = -EINVAL;
> goto out;
> }
>+
>+ if (template[i].iv_out &&
>+ memcmp(iv, template[i].iv_out,
>+ crypto_ablkcipher_ivsize(tfm))) {
>+ pr_err("alg: skcipher%s: Test %d failed (invalid
output IV) on %s for
>%s\n", + d, j, e, algo);
>+ hexdump(iv, crypto_ablkcipher_ivsize(tfm));
>+ ret = -EINVAL;
>+ goto out;
>+ }
> }
>
> j = 0;
>diff --git a/crypto/testmgr.h b/crypto/testmgr.h
>index 62e2485..03320f9 100644
>--- a/crypto/testmgr.h
>+++ b/crypto/testmgr.h
>@@ -49,6 +49,7 @@ struct hash_testvec {
> struct cipher_testvec {
> char *key;
> char *iv;
>+ char *iv_out;
> char *input;
> char *result;
> unsigned short tap[MAX_TAP];
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kernel/sysctl.c: If "count" including the terminating byte '\0' the write system call should retrun success.
On Fri, Aug 28, 2015 at 11:31 AM, Sean Fu wrote: > On Thu, Aug 27, 2015 at 4:32 PM, Sean Fu wrote: >> On Thu, Aug 27, 2015 at 10:32 AM, Steven Rostedt wrote: >>> On Thu, 27 Aug 2015 08:17:29 +0800 >>> Sean Fu wrote: strace execute result: write(3, "1\2\0", 3)= -1 EINVAL (Invalid argument) > If vleft > 1, "1\0 2" is treated as invalid paraments and all string > include '\0' will be invalid. Hi All experts, Could you please signed off this patch? > > > -- Steve >>> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git pull] drm for 4.3
On 8 September 2015 at 12:03, Stephen Rothwell wrote: > Hi Linus, > > On Fri, 4 Sep 2015 23:40:53 +0100 (IST) Dave Airlie wrote: >> >> This is the main pull request for the drm for 4.3. Nouveau is probably the >> biggest >> amount of changes in here, since it missed 4.2. Highlights below, along with >> the usual >> bunch of fixes. There are a few minor conflicts with your tree but nothing >> you can't handle. All stuff outside drm should have applicable acks. >> >> The following changes since commit c13dcf9f2d6f5f06ef1bf79ec456df614c5e058b: >> >> Linux 4.2-rc8 (2015-08-23 20:52:59 -0700) >> >> are available in the git repository at: >> >> git://people.freedesktop.org/~airlied/linux drm-next >> >> for you to fetch changes up to 73bf1b7be7aab60d7c651402441dd0b0b4991098: >> >> Merge branch 'drm-next-4.3' of git://people.freedesktop.org/~agd5f/linux >> into drm-next (2015-09-05 07:46:09 +1000) > > This contains 59 commits added since Sept 1 and 56 of those are only > appearing in today's linux-next. Not judging, just noting. Is this to be a regular thing? because I know I'd prefer to merge fixes than wait for -rc1 to be an accurate copy of linux-next. Dave. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [v2,3/6] powerpc: kill mfvtb()
On Mon, Sep 07, 2015 at 07:29:42PM +1000, Michael Ellerman wrote: > On Mon, 2015-24-08 at 11:20:25 UTC, Kevin Hao wrote: > > This function is only used by get_vtb(). They are almost the same > > except the reading from the real register. Move the mfspr() to > > get_vtb() and kill the function mfvtb(). With this, we can eliminate > > the use of cpu_has_feature() in very core header file like reg.h. > > This is a preparation for the use of jump label for cpu_has_feature(). > > I don't mind this change. But can you elaborate a bit on the issue with using > cpu_has_feature() in reg.h? Just so I can understand the problem. > > I assume you ended up in a big mess of includes when you tried to include > jump_label.h from reg.h? Yes, the "jump_leabel.h" already include "reg.h" implicitly. from arch/powerpc/include/asm/cache.h:6:0, from include/linux/cache.h:5, from include/linux/printk.h:8, from include/linux/kernel.h:14, from include/asm-generic/bug.h:13, from arch/powerpc/include/asm/bug.h:127, from include/linux/bug.h:4, from include/linux/jump_label.h:81, So including "jump_label.h" from "reg.h" will cause a recursive header inclusion problem. Thanks, Kevin pgpE7V7gUSsew.pgp Description: PGP signature
[PATCH 0/2] perf: we can now read separate debug-info files based on a build ID
Date: Mon, 7 Sep 2015 19:27:01 -0700
(Please Cc me when replying; I'm not subscribed)
Hi. Perf currently has trouble reading separate debug-info files when trying to
look up symbols in a 'perf report'. According to the gdb documentation:
https://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html
separate debug-info files can live in any of
/usr/lib/debug/.build-id/ab/cdef1234.debug
/usr/bin/debuglink
/usr/bin/.debug/debuglink
/usr/lib/debug/usr/bin/debuglink
Prior to this patch series, perf reads the value of the debuglink from the
.gnu_debuglink section, and tries to read a file of that name in the same
directory as the stripped ELF file. For an executable, this would be
"/usr/bin/debuglink" above. And that's it; the other paths are not checked.
The "normal" thing to do on Debian boxes these days is
/usr/lib/debug/.build-id/ab/cdef1234.debug
This patch series makes this work. The remaining two paths are still unchecked,
but I don't know if they're "standard" anywhere
Dima Kogan (2):
perf: fixed type error when reading a build-id
perf: we can now read separate debug-info files based on a build ID
tools/perf/util/symbol-minimal.c | 2 +-
tools/perf/util/symbol.c | 9 +
2 files changed, 10 insertions(+), 1 deletion(-)
--
2.1.4
>From b095f63f4bcfeb9c00f62a7627243c5231e4d666 Mon Sep 17 00:00:00 2001
From: Dima Kogan
Date: Mon, 7 Sep 2015 17:30:28 -0700
Subject: [PATCH 1/2] perf: fixed type error when reading a build-id
This was benign, but wrong. The build-id should live in a char[], not a char*[]
Signed-off-by: Dima Kogan
---
tools/perf/util/symbol-minimal.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/util/symbol-minimal.c b/tools/perf/util/symbol-minimal.c
index fd8477c..4890633 100644
--- a/tools/perf/util/symbol-minimal.c
+++ b/tools/perf/util/symbol-minimal.c
@@ -337,7 +337,7 @@ int dso__load_sym(struct dso *dso, struct map *map __maybe_unused,
symbol_filter_t filter __maybe_unused,
int kmodule __maybe_unused)
{
- unsigned char *build_id[BUILD_ID_SIZE];
+ unsigned char build_id[BUILD_ID_SIZE];
int ret;
ret = fd__is_64_bit(ss->fd);
--
2.1.4
>From 956877b14b0243868cbf381f0fc5607eb973f268 Mon Sep 17 00:00:00 2001
From: Dima Kogan
Date: Mon, 7 Sep 2015 17:34:19 -0700
Subject: [PATCH 2/2] perf: we can now read separate debug-info files based on
a build ID
Recent GDB (at least on a vanilla Debian box) looks for debug information in
/usr/lib/debug/.build-id/nn/nnn
where nn/nn is the build-id of the stripped ELF binary. This is documented
here:
https://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html
This was not working in perf because we didn't read the build id until AFTER we
searched for the separate debug information file. This patch reads the build ID
and THEN does the search.
Signed-off-by: Dima Kogan
---
tools/perf/util/symbol.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index 1f97ffb..05c656b 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -1406,6 +1406,7 @@ int dso__load(struct dso *dso, struct map *map, symbol_filter_t filter)
struct symsrc ss_[2];
struct symsrc *syms_ss = NULL, *runtime_ss = NULL;
bool kmod;
+ unsigned char build_id[BUILD_ID_SIZE];
pthread_mutex_lock(>lock);
@@ -1461,6 +1462,14 @@ int dso__load(struct dso *dso, struct map *map, symbol_filter_t filter)
dso->symtab_type == DSO_BINARY_TYPE__GUEST_KMODULE ||
dso->symtab_type == DSO_BINARY_TYPE__GUEST_KMODULE_COMP;
+
+ /*
+ * Read the build id if possible. This is required for
+ * DSO_BINARY_TYPE__BUILDID_DEBUGINFO to work
+ */
+ if (filename__read_build_id(dso->name, build_id, BUILD_ID_SIZE) > 0)
+ dso__set_build_id(dso, build_id);
+
/*
* Iterate over candidate debug images.
* Keep track of "interesting" ones (those which have a symtab, dynsym,
--
2.1.4
[PATCH] ARM:mm: define arch-specific IOREMAP_MAX_ORDER only in !SMP && !LPAE case
The arch-specific IOREMAP_MAX_ORDER is introduced in commit: ff0daca([ARM] Add section support to ioremap) and commit: a069c89 ([ARM] 3705/1: add supersection support to ioremap()). But supersections and sections mappings are only used in !SMP && !LPAE case. Otherwise, mapping is created using the usual 4K pages. In most cases without !SMP && !LPAE, the big alignment cause high fragmentation issue in vmalloc area. Here we use arch-specific IOREMAP_MAX_ORDER only in !SMP && !LPAE case, otherwise use generic IOREMAP_MAX_ORDER in include/linux/vmalloc.h. Signed-off-by: Zhang Zhen --- arch/arm/include/asm/memory.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h index b7f6fb4..3209012 100644 --- a/arch/arm/include/asm/memory.h +++ b/arch/arm/include/asm/memory.h @@ -76,10 +76,12 @@ */ #define XIP_VIRT_ADDR(physaddr) (MODULES_VADDR + ((physaddr) & 0x000f)) +#if !defined(CONFIG_SMP) && !defined(CONFIG_ARM_LPAE) /* * Allow 16MB-aligned ioremap pages */ #define IOREMAP_MAX_ORDER 24 +#endif #else /* CONFIG_MMU */ -- 1.9.1 . -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/4] cpufreq-dt: add suspend frequency support
On 07-09-15, 17:41, Bartlomiej Zolnierkiewicz wrote: > Hi, > > This patch series adds suspend frequency support (using opp-v2 > bindings and suspend-opp functionality) to cpufreq-dt driver and > then adds suspend opp for Exynos4412 based boards. > > This patch series fixes suspend/resume support on Exynos4412 > based Trats2 board and reboot hang on Exynos4412 based Odroid > U3 board. > > Changes since v3: > - fixed dev_pm_opp_get_suspend_opp() locking > - shortened variable name in dev_pm_opp_get_suspend_opp() > - adjusted cpufreq_generic_suspend() to work with cpufreq-dt > - removed no longer needed cpufreq_dt_suspend() > - added Acked-by tag from Viresh to patch #4 Just a minor comment on 3/4 and after fixing that: Acked-by: Viresh Kumar -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 3/4] cpufreq-dt: add suspend frequency support
On 07-09-15, 17:41, Bartlomiej Zolnierkiewicz wrote: > +#ifdef CONFIG_PM > + .suspend = cpufreq_generic_suspend, > +#endif I don't think there is any need of the #ifdef here. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 6/9] cpufreq: ondemand: queue work for policy->cpus together
On 08-09-15, 07:41, Viresh Kumar wrote: > > > next_sampling = jiffies + usecs_to_jiffies(new_rate); > > > appointed_at = dbs_info->cdbs.dwork.timer.expires; > > > > For that to work we always need to do stuff for policy->cpus in sync. > > Do we? > > Hmm, we are not in 100% sync for sure. Will check that again. On the other hand, if we decide to apply 7/9 as well, then this is anyway going to get removed :) -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sched: fix lose fair sleeper bonus in switch_to_fair()
hello wanpeng,
On Mon, Sep 07, 2015 at 05:45:20PM +0800, Wanpeng Li wrote:
> The sleeper task will be normalized when moved from fair_sched_class, in
> order that vruntime will be adjusted either the task is running or sleeping
> when moved back. The nomalization in switch_to_fair for sleep task will
> result in lose fair sleeper bonus in place_entity() once the vruntime -
> cfs_rq->min_vruntime is big when moved from fair_sched_class.
it is nothing to do with normalization.
if vruntime - cfs_rq->min_vruntime is big even though place_entity() was
called when moved from fair class, then we actually expect that it still has
a big vruntime when moved back to fair class.
if we don't expect that it still has a big vruntime when moved back to fair
class, we need to consider other approaches e.g. to move a position calling
place_entity() or to add place_entity() call properly ..
however we should not touch normalization logic. in other words, if we
normalized the vruntime when leaved, then we should necessarily restore the
vruntime to a non-normalized value when moved back.
>
> This patch fix it by adjusting vruntime just during migrating as original
> codes since the vruntime of the task has usually NOT been normalized in
> this case.
could you explain this in detail? when is a vruntime not normalized?
thanks,
byungchul
>
> Signed-off-by: Wanpeng Li
> ---
> kernel/sched/fair.c | 11 +++
> 1 files changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index d26d3b7..eb9aa35 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -8005,9 +8005,6 @@ static void attach_task_cfs_rq(struct task_struct *p)
>
> /* Synchronize task with its cfs_rq */
> attach_entity_load_avg(cfs_rq, se);
> -
> - if (!vruntime_normalized(p))
> - se->vruntime += cfs_rq->min_vruntime;
> }
>
> static void switched_from_fair(struct rq *rq, struct task_struct *p)
> @@ -8066,14 +8063,20 @@ void init_cfs_rq(struct cfs_rq *cfs_rq)
> #ifdef CONFIG_FAIR_GROUP_SCHED
> static void task_move_group_fair(struct task_struct *p)
> {
> + struct sched_entity *se = >se;
> + struct cfs_rq *cfs_rq = cfs_rq_of(se);
> +
> detach_task_cfs_rq(p);
> set_task_rq(p, task_cpu(p));
>
> #ifdef CONFIG_SMP
> /* Tell se's cfs_rq has been changed -- migrated */
> - p->se.avg.last_update_time = 0;
> + se->avg.last_update_time = 0;
> #endif
> attach_task_cfs_rq(p);
> +
> + if (!vruntime_normalized(p))
> + se->vruntime += cfs_rq->min_vruntime;
> }
>
> void free_fair_sched_group(struct task_group *tg)
> --
> 1.7.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 6/9] cpufreq: ondemand: queue work for policy->cpus together
On 08-09-15, 03:33, Rafael J. Wysocki wrote: > > + /* Make sure the work is not canceled on policy->cpus */ > > I'm not sure what scenario can lead to that. Care to explain? CPUFREQ_GOV_STOP event called for the policy and so all its works are in canceled state. > > + if (!dbs_info->cdbs.shared->policy) > > continue; > > > > next_sampling = jiffies + usecs_to_jiffies(new_rate); > > appointed_at = dbs_info->cdbs.dwork.timer.expires; > > For that to work we always need to do stuff for policy->cpus in sync. > Do we? Hmm, we are not in 100% sync for sure. Will check that again. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the kvm tree
Hi Paolo, Stephen,
On 9/8/15 9:35 AM, Stephen Rothwell wrote:
Hi all,
After merging the kvm tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
arch/powerpc/kvm/../../../virt/kvm/kvm_main.c: In function 'grow_halt_poll_ns':
arch/powerpc/kvm/../../../virt/kvm/kvm_main.c:1931:2: error: implicit
declaration of function 'trace_kvm_halt_poll_ns_grow'
[-Werror=implicit-function-declaration]
trace_kvm_halt_poll_ns_grow(vcpu->vcpu_id, val, old);
^
arch/powerpc/kvm/../../../virt/kvm/kvm_main.c: In function
'shrink_halt_poll_ns':
arch/powerpc/kvm/../../../virt/kvm/kvm_main.c:1945:2: error: implicit
declaration of function 'trace_kvm_halt_poll_ns_shrink'
[-Werror=implicit-function-declaration]
trace_kvm_halt_poll_ns_shrink(vcpu->vcpu_id, val, old);
^
Caused by commit
2cbd78244fb2 ("KVM: trace kvm_halt_poll_ns grow/shrink")
I have reverted that commit for today.
I miss place the trace codes under CONFIG_KVM_ASYNC_PF, the patch in the
attachment rewrite the commit and fix it. Sorry for that.
Regards,
Wanpeng Li
>From c06ca8fec43a7ccc1fe265afe8b2fd3b84085368 Mon Sep 17 00:00:00 2001
From: Wanpeng Li
Date: Tue, 8 Sep 2015 10:03:38 +0800
Subject: [PATCH] KVM: trace kvm_halt_poll_ns grow/shrink
Tracepoint for dynamic halt_pool_ns, fired on every potential change.
Signed-off-by: Wanpeng Li
---
include/trace/events/kvm.h | 30 ++
virt/kvm/kvm_main.c| 8 ++--
2 files changed, 36 insertions(+), 2 deletions(-)
diff --git a/include/trace/events/kvm.h b/include/trace/events/kvm.h
index a44062d..d6f8322 100644
--- a/include/trace/events/kvm.h
+++ b/include/trace/events/kvm.h
@@ -358,6 +358,36 @@ TRACE_EVENT(
#endif
+TRACE_EVENT(kvm_halt_poll_ns,
+ TP_PROTO(bool grow, unsigned int vcpu_id, int new, int old),
+ TP_ARGS(grow, vcpu_id, new, old),
+
+ TP_STRUCT__entry(
+ __field(bool, grow)
+ __field(unsigned int, vcpu_id)
+ __field(int, new)
+ __field(int, old)
+ ),
+
+ TP_fast_assign(
+ __entry->grow = grow;
+ __entry->vcpu_id= vcpu_id;
+ __entry->new= new;
+ __entry->old= old;
+ ),
+
+ TP_printk("vcpu %u: halt_poll_ns %d (%s %d)",
+ __entry->vcpu_id,
+ __entry->new,
+ __entry->grow ? "grow" : "shrink",
+ __entry->old)
+);
+
+#define trace_kvm_halt_poll_ns_grow(vcpu_id, new, old) \
+ trace_kvm_halt_poll_ns(true, vcpu_id, new, old)
+#define trace_kvm_halt_poll_ns_shrink(vcpu_id, new, old) \
+ trace_kvm_halt_poll_ns(false, vcpu_id, new, old)
+
#endif /* _TRACE_KVM_MAIN_H */
/* This part must be outside protection */
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 8ab49cf..4662a88 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -1918,8 +1918,9 @@ EXPORT_SYMBOL_GPL(kvm_vcpu_mark_page_dirty);
static void grow_halt_poll_ns(struct kvm_vcpu *vcpu)
{
- int val = vcpu->halt_poll_ns;
+ int old, val;
+ old = val = vcpu->halt_poll_ns;
/* 10us base */
if (val == 0 && halt_poll_ns_grow)
val = 1;
@@ -1927,18 +1928,21 @@ static void grow_halt_poll_ns(struct kvm_vcpu *vcpu)
val *= halt_poll_ns_grow;
vcpu->halt_poll_ns = val;
+ trace_kvm_halt_poll_ns_grow(vcpu->vcpu_id, val, old);
}
static void shrink_halt_poll_ns(struct kvm_vcpu *vcpu)
{
- int val = vcpu->halt_poll_ns;
+ int old, val;
+ old = val = vcpu->halt_poll_ns;
if (halt_poll_ns_shrink == 0)
val = 0;
else
val /= halt_poll_ns_shrink;
vcpu->halt_poll_ns = val;
+ trace_kvm_halt_poll_ns_shrink(vcpu->vcpu_id, val, old);
}
static int kvm_vcpu_check_block(struct kvm_vcpu *vcpu)
--
1.9.1
Re: [git pull] drm for 4.3
Hi Linus, On Fri, 4 Sep 2015 23:40:53 +0100 (IST) Dave Airlie wrote: > > This is the main pull request for the drm for 4.3. Nouveau is probably the > biggest > amount of changes in here, since it missed 4.2. Highlights below, along with > the usual > bunch of fixes. There are a few minor conflicts with your tree but nothing > you can't handle. All stuff outside drm should have applicable acks. > > The following changes since commit c13dcf9f2d6f5f06ef1bf79ec456df614c5e058b: > > Linux 4.2-rc8 (2015-08-23 20:52:59 -0700) > > are available in the git repository at: > > git://people.freedesktop.org/~airlied/linux drm-next > > for you to fetch changes up to 73bf1b7be7aab60d7c651402441dd0b0b4991098: > > Merge branch 'drm-next-4.3' of git://people.freedesktop.org/~agd5f/linux > into drm-next (2015-09-05 07:46:09 +1000) This contains 59 commits added since Sept 1 and 56 of those are only appearing in today's linux-next. Not judging, just noting. -- Cheers, Stephen Rothwells...@canb.auug.org.au -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: fix bug which lowmem size is limited to 760MB
On Tue, 8 Sep 2015, Russell King - ARM Linux wrote:
> On Mon, Sep 07, 2015 at 03:40:36PM -0400, Nicolas Pitre wrote:
> > On Mon, 7 Sep 2015, Arnd Bergmann wrote:
> >
> > > On Thursday 03 September 2015 21:24:00 Nicolas Pitre wrote:
> > > > If 768MB targets were common place then it could be worth changing the
> > > > default vmalloc size to accommodate this memory size and testing all
> > > > the
> > > > other targets to make sure no regressions are introduced. But given it
> > > > is easy to change the default via the kernel cmdline, and that you lose
> > > > only 8 MB otherwise, I don't think it is worth the trouble and/or the
> > > > risk.
> > >
> > > Agreed.
> >
> > Well... I think there is a better solution.
>
> Doesn't this clash with things like:
>
> #define UNCACHEABLE_ADDR0xff00 /* IRQ_STAT */
>
> ?
It looks like the move might actually "fix" it. That UNCACHEABLE_ADDR
is mapped with:
static struct map_desc ebsa110_io_desc[] __initdata = {
/*
* sparse external-decode ISAIO space
*/
{ /* IRQ_STAT/IRQ_MCLR */
.virtual= (unsigned long)IRQ_STAT,
.pfn= __phys_to_pfn(TRICK4_PHYS),
.length = TRICK4_SIZE,
.type = MT_DEVICE
},
[...]
};
This is passed to iotable_init(), then to create_mapping(). There you
have:
if ((md->type == MT_DEVICE || md->type == MT_ROM) &&
md->virtual >= PAGE_OFFSET &&
(md->virtual < VMALLOC_START || md->virtual >= VMALLOC_END)) {
pr_warn("BUG: mapping for 0x%08llx at 0x%08lx out of vmalloc
space\n",
(long long)__pfn_to_phys((u64)md->pfn), md->virtual);
}
So you must have hit the above warning somehow. Incidentally, this
IRQ_STAT entry is the only one that happened to be outside the vmalloc
area. By moving VMALLOC_END from 0xff00 to 0xff80 the warning
will be gone.
Nicolas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 4/9] cpufreq: governor: Drop __gov_queue_work()
On 08-09-15, 03:15, Rafael J. Wysocki wrote: > On Monday, July 27, 2015 05:58:09 PM Viresh Kumar wrote: > > __gov_queue_work() isn't required anymore and can be merged with > > gov_queue_work(). Do it. > > > > Signed-off-by: Viresh Kumar > > Quite frankly I don't see the point. But isn't that just an unnecessary wrapper ? > I'd even remove the inline from its definition and let the compiler decide > what to do with it. What if the compiler decides to link it? Why add a function call for (almost) no use? -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 3/9] cpufreq: ondemand: only queue canceled works from update_sampling_rate()
On 08-09-15, 03:11, Rafael J. Wysocki wrote:
> There really are two cases, either you pass a CPU or gov_queue_work() has to
> walk policy->cpus.
Right (At least for now, we are doing just that.)
> Doing it the way you did hides that IMO.
Maybe. But I see it otherwise. Adding special meaning to a variable
(like int cpu == -1 being the special case to specify policy->cpus)
hides things morei, as we need to look at how it is decoded finally in
the routine gov_queue_work().
But if we send a mask instead, it is very clear by reading the callers
site, what we are trying to do.
> I'd simply pass an int and use a special value to indicate that policy->cpus
> is to be walked.
Like cpu == -1 thing? Or something else?
> > - if (!all_cpus) {
> > - /*
> > -* Use raw_smp_processor_id() to avoid preemptible warnings.
> > -* We know that this is only called with all_cpus == false from
> > -* works that have been queued with *_work_on() functions and
> > -* those works are canceled during CPU_DOWN_PREPARE so they
> > -* can't possibly run on any other CPU.
> > -*/
>
> This was a useful comment and it should be moved along the logic it was
> supposed
> to explain and not just dropped.
Sigh
> > - __gov_queue_work(raw_smp_processor_id(), dbs_data, delay);
> > - } else {
> > - for_each_cpu(i, policy->cpus)
> > - __gov_queue_work(i, dbs_data, delay);
> > - }
> > + for_each_cpu(i, cpus)
> > + __gov_queue_work(i, dbs_data, delay);
> >
> > out_unlock:
> > mutex_unlock(_governor_lock);
> > @@ -232,7 +221,8 @@ static void dbs_timer(struct work_struct *work)
> > struct cpufreq_policy *policy = shared->policy;
> > struct dbs_data *dbs_data = policy->governor_data;
> > unsigned int sampling_rate, delay;
> > - bool modify_all = true;
> > + const struct cpumask *cpus;
>
> I don't think this local variable is necessary.
>
> > + bool load_eval;
> >
> > mutex_lock(>timer_mutex);
> >
> > @@ -246,11 +236,11 @@ static void dbs_timer(struct work_struct *work)
> > sampling_rate = od_tuners->sampling_rate;
> > }
> >
> > - if (!need_load_eval(cdbs->shared, sampling_rate))
> > - modify_all = false;
> > + load_eval = need_load_eval(cdbs->shared, sampling_rate);
> > + cpus = load_eval ? policy->cpus : cpumask_of(raw_smp_processor_id());
> >
> > - delay = dbs_data->cdata->gov_dbs_timer(cdbs, dbs_data, modify_all);
> > - gov_queue_work(dbs_data, policy, delay, modify_all);
> > + delay = dbs_data->cdata->gov_dbs_timer(cdbs, dbs_data, load_eval);
> > + gov_queue_work(dbs_data, policy, delay, cpus);
Avoiding that local variable would have made this a little longer, but
I can surely drop it :)
gov_queue_work(dbs_data, policy, delay,
load_eval ? policy->cpus :
cpumask_of(raw_smp_processor_id());
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] Please pull NFS client changes
Hi Linus, On Mon, 07 Sep 2015 16:59:04 -0400 Trond Myklebust wrote: > > The following changes since commit 74d33293e467df61de1b1d8b2fbe29e550dec33b: > > Linux 4.2-rc5 (2015-08-02 18:34:55 -0700) > > are available in the git repository at: > > git://git.linux-nfs.org/projects/trondmy/linux-nfs.git tags/nfs-for-4.3-1 > > for you to fetch changes up to 5445b1fbd123420bffed5e629a420aa2a16bf849: > > NFSv4: Respect the server imposed limit on how many changes we may cache > (2015-09-07 12:36:17 -0400) This contains about 12 commits new since Sept 1 and the last 6 are only appearing in linux-next today (though I did not do Friday and Monday's linux-next). Not judging, just noting. -- Cheers, Stephen Rothwells...@canb.auug.org.au -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] zram: don't copy invalid compression algorithms
On (09/08/15 10:33), Sergey Senozhatsky wrote: > > I don't understand your concern. To me, this patch makes sense to me. > > Could you explain your point clearly, again? > > OK. suppose someone landed a typo in a 'zram device management' script > > echo llzo > /sys/block/zram0/comp_algorithm > -bash: echo: write error: Invalid argument > > > but the script ignores 'echo: write error'. > Because we added compression algorithm name check recently. > > then the script does > > echo 200M > /sys/block/zram0/disksize > -bash: echo: write error: Invalid argument > > > doing a simple dmesg reveals the problem > > [ 7076.657184] zram: Cannot initialise llzo compressing backend > > note that zram provides 'llzo' here, which is convenient. ah, forgot to mention. there is another misleading thing. suppose the script checks the comp_algorithm() error code. and it attempts to do somthing like echo llzo > /sys/block/zram0/comp_algorithm -bash: echo: write error: Device or resource busy so user knows that comp_algorithm failed. so now he/she goes and checks zram cat /sys/block/zram0/comp_algorithm [lzo] lz4 and finds out... that [lzo] is supported and selected for usage. so what't the problem then? so user wrongly assumes now that the script has provided 'lzo' as input to zram... false! the existing scheme of things will provide additional hint. #current implementation cat /sys/block/zram0/comp_algorithm lzo lz4 so, none of the supported compression algorithms is selected. aha, that is obviously lead us to a conclusion that something wrong was with the input that script provided to zram. correct! -ss -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/5] perf probe: Split add_perf_probe_events()
On Sun, Sep 06, 2015 at 03:47:37PM +0800, Wangnan (F) wrote:
> Hi Namhyung,
Hi,
I'm off until Wednesday. I'll be able to take a look at it on
Thursday.
Thanks,
Namhyung
>
> Thanks for this patchset.
>
> Could you plase have a look at patch 5/27 and 6/27 in my newest pull
> request?
> These 2 patches utilize new probing API to create probe point and collect
> probe_trace_events. I'm not very sure I fully understand your design
> principle,
> especially the cleanup part, because I can see different functions dealing
> with
> cleanup:
>
> cleanup_perf_probe_events
> del_perf_probe_events
> clear_perf_probe_event
> clear_probe_trace_event
>
> But non of them works perfectly for me.
>
> In bpf_prog_priv__clear() function of 6/27, I copied some code from
> cleanup_perf_probe_events(), because I think when destroying bpf programs,
> the probe_trace_events should also be cleanuped, but we don't need call
> exit_symbol_maps() many times, because we are in 'perf record', and not
> sure whether other parts of perf need symbol maps. Otherwise I think
> directly
> calling cleanup_perf_probe_events() sould be better.
>
> You can find patch from:
>
> http://lkml.kernel.org/n/1441523623-152703-6-git-send-email-wangn...@huawei.com
>
> http://lkml.kernel.org/n/1441523623-152703-7-git-send-email-wangn...@huawei.com
>
> Thank you.
>
> On 2015/9/4 20:15, Namhyung Kim wrote:
> >The add_perf_probe_events() does 3 things:
> >
> > 1. convert all perf events to trace events
> > 2. add all trace events to kernel
> > 3. cleanup all trace events
> >
> >But sometimes we need to do something with the trace events. So split
> >the funtion into three, so that it can access intermediate trace events
> >via struct __event_package if needed.
> >
> >Acked-by: Masami Hiramatsu
> >Signed-off-by: Namhyung Kim
> >---
> > tools/perf/util/probe-event.c | 39 +++
> > 1 file changed, 35 insertions(+), 4 deletions(-)
> >
> >diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
> >index eb5f18b75402..2c762f41e7a5 100644
> >--- a/tools/perf/util/probe-event.c
> >+++ b/tools/perf/util/probe-event.c
> >@@ -2765,9 +2765,10 @@ struct __event_package {
> > int ntevs;
> > };
> >-int add_perf_probe_events(struct perf_probe_event *pevs, int npevs)
> >+static int convert_perf_probe_events(struct perf_probe_event *pevs, int
> >npevs,
> >+ struct __event_package **ppkgs)
> > {
> >-int i, j, ret;
> >+int i, ret;
> > struct __event_package *pkgs;
> > ret = 0;
> >@@ -2792,12 +2793,21 @@ int add_perf_probe_events(struct perf_probe_event
> >*pevs, int npevs)
> > ret = convert_to_probe_trace_events(pkgs[i].pev,
> > [i].tevs);
> > if (ret < 0)
> >-goto end;
> >+return ret;
> > pkgs[i].ntevs = ret;
> > }
> > /* This just release blacklist only if allocated */
> > kprobe_blacklist__release();
> >+*ppkgs = pkgs;
> >+
> >+return 0;
> >+}
> >+
> >+static int apply_perf_probe_events(struct __event_package *pkgs, int npevs)
> >+{
> >+int i, ret = 0;
> >+
> > /* Loop 2: add all events */
> > for (i = 0; i < npevs; i++) {
> > ret = __add_probe_trace_events(pkgs[i].pev, pkgs[i].tevs,
> >@@ -2806,7 +2816,16 @@ int add_perf_probe_events(struct perf_probe_event
> >*pevs, int npevs)
> > if (ret < 0)
> > break;
> > }
> >-end:
> >+return ret;
> >+}
> >+
> >+static void cleanup_perf_probe_events(struct __event_package *pkgs, int
> >npevs)
> >+{
> >+int i, j;
> >+
> >+if (pkgs == NULL)
> >+return;
> >+
> > /* Loop 3: cleanup and free trace events */
> > for (i = 0; i < npevs; i++) {
> > for (j = 0; j < pkgs[i].ntevs; j++)
> >@@ -2815,6 +2834,18 @@ end:
> > }
> > free(pkgs);
> > exit_symbol_maps();
> >+}
> >+
> >+int add_perf_probe_events(struct perf_probe_event *pevs, int npevs)
> >+{
> >+int ret;
> >+struct __event_package *pkgs = NULL;
> >+
> >+ret = convert_perf_probe_events(pevs, npevs, );
> >+if (ret == 0)
> >+ret = apply_perf_probe_events(pkgs, npevs);
> >+
> >+cleanup_perf_probe_events(pkgs, npevs);
> > return ret;
> > }
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 0/5] Let the power allocator thermal governor run on any thermal zone
Hi Javi, On Mon, Sep 7, 2015 at 9:19 PM, Javi Merino wrote: > Relax the thermal governor requirements of sustainable_power and at > least two trip points so that it can be bound to any thermal zone. > Its behavior won't be optimal, it would be the best possible with the > data provided. I tested this whole series on my MT8173 board with a battery thermal zone with no trip points, so, for this whole series (not sure if both are needed, so take your pick): Reviewed-by: Daniel Kurtz Tested-by: Daniel Kurtz I am a bit confused by MAINTAINERS for drivers/thermal. Will these patches be picked up by Eduardo or Zhang? Thanks! -Dan > Changes since v4: >- Fix crash when a thermal zone with no trip points has no > get_trip_point_temp(). Reported by Daniel Kurtz. >- s/estimate_controller_constants()/estimate_pid_constants()/g > > Changes since v3: >- Don't hardcode a value for sustainable power and re-estimate > the PID controllers every time if no sustainable power is given > as suggested by Eduardo Valentin. >- power_actor_get_min_power() moved to a patch of its own. > > Changes since v2: > - Typos suggested by Daniel Kurtz > > Changes since v1: > - Let the power allocator governor operate if the thermal zone > doesn't have tzp as suggested by Chung-yih Wang > > Javi Merino (5): > thermal: Add a function to get the minimum power > thermal: power_allocator: relax the requirement of a sustainable_power > in tzp > thermal: power_allocator: relax the requirement of two passive trip > points > thermal: power_allocator: don't require tzp to be present for the > thermal zone > thermal: power_allocator: exit early if there are no cooling devices > > Documentation/thermal/power_allocator.txt | 2 +- > drivers/thermal/power_allocator.c | 243 > ++ > drivers/thermal/thermal_core.c| 28 > include/linux/thermal.h | 6 + > 4 files changed, 214 insertions(+), 65 deletions(-) > > -- > 1.9.1 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arm64: kernel: Use a separate stack for irq interrupts.
Jungseok, On 09/08/2015 01:34 AM, Jungseok Lee wrote: On Sep 8, 2015, at 1:06 AM, James Morse wrote: On 07/09/15 16:48, Jungseok Lee wrote: On Sep 7, 2015, at 11:36 PM, James Morse wrote: Hi James, Having to handle interrupts on top of an existing kernel stack means the kernel stack must be large enough to accomodate both the maximum kernel usage, and the maximum irq handler usage. Switching to a different stack when processing irqs allows us to make the stack size smaller. Maximum kernel stack usage (running ltp and generating usb+ethernet interrupts) was 7256 bytes. With this patch, the same workload gives a maximum stack usage of 5816 bytes. I'd like to know how to measure the max stack depth. AFAIK, a stack tracer on ftrace does not work well. Did you dump a stack region and find or track down an untouched region? I enabled the 'Trace max stack' option under menuconfig 'Kernel Hacking' -> 'Tracers', then looked in debugfs:/tracing/stack_max_size. What problems did you encounter? (I may be missing something…) When I enabled the feature, all entries had *0* size except the last entry. It can be reproduced easily as looking in debugs:/tracing/stack_trace. I'm afraid that you have not applied one of patches in my RFC: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/355919.html I have not looked into James' patch in details, but hope that it will help fix one of issues that are annoying me: Stack tracer (actually save_stack_trace()) will miss a function (and its parent function in some case) that is being executed when an interrupt is taken. -Takahiro AKASHI You can track down my report and Akashi's changes with the following links: - http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/354126.html - https://lkml.org/lkml/2015/7/13/29 Although it is impossible to measure an exact depth at this moment, the feature could be utilized to check improvement. Cc'ing Akashi for additional comments if needed. Best Regards Jungseok Lee -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] kasan: fix last shadow judgement in memory_is_poisoned_16()
The shadow which correspond 16 bytes may span 2 or 3 bytes. If shadow
only take 2 bytes, we can return in "if (likely(!last_byte)) ...", but
it calculates wrong, so fix it.
Signed-off-by: Xishi Qiu
---
mm/kasan/kasan.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/mm/kasan/kasan.c b/mm/kasan/kasan.c
index 7b28e9c..8da2114 100644
--- a/mm/kasan/kasan.c
+++ b/mm/kasan/kasan.c
@@ -135,12 +135,11 @@ static __always_inline bool
memory_is_poisoned_16(unsigned long addr)
if (unlikely(*shadow_addr)) {
u16 shadow_first_bytes = *(u16 *)shadow_addr;
- s8 last_byte = (addr + 15) & KASAN_SHADOW_MASK;
if (unlikely(shadow_first_bytes))
return true;
- if (likely(!last_byte))
+ if (likely(IS_ALIGNED(addr, 8)))
return false;
return memory_is_poisoned_1(addr + 15);
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V3 2/9] cpufreq: conservative: remove 'enable' field
Conservative governor has its own 'enable' field to check if
conservative governor is used for a CPU or not
This can be checked by policy->governor with 'cpufreq_gov_conservative'
and so this field can be dropped.
Because its not guaranteed that dbs_info->cdbs.shared will a valid
pointer for all CPUs (will be NULL for CPUs that don't use
ondemand/conservative governors), we can't use it anymore. Lets get
policy with cpufreq_cpu_get_raw() instead.
Signed-off-by: Viresh Kumar
---
Updates: use cpufreq_cpu_get_raw() instead of cpufreq_cpu_get().
drivers/cpufreq/cpufreq.c | 3 ++-
drivers/cpufreq/cpufreq_conservative.c | 31 ++-
drivers/cpufreq/cpufreq_governor.c | 12 +---
drivers/cpufreq/cpufreq_governor.h | 2 +-
4 files changed, 22 insertions(+), 26 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 82428099c569..2a0c2a26df11 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -239,12 +239,13 @@ int cpufreq_generic_init(struct cpufreq_policy *policy,
EXPORT_SYMBOL_GPL(cpufreq_generic_init);
/* Only for cpufreq core internal use */
-static struct cpufreq_policy *cpufreq_cpu_get_raw(unsigned int cpu)
+struct cpufreq_policy *cpufreq_cpu_get_raw(unsigned int cpu)
{
struct cpufreq_policy *policy = per_cpu(cpufreq_cpu_data, cpu);
return policy && cpumask_test_cpu(cpu, policy->cpus) ? policy : NULL;
}
+EXPORT_SYMBOL_GPL(cpufreq_cpu_get_raw);
unsigned int cpufreq_generic_get(unsigned int cpu)
{
diff --git a/drivers/cpufreq/cpufreq_conservative.c
b/drivers/cpufreq/cpufreq_conservative.c
index 84a1506950a7..1fa1deb6e91f 100644
--- a/drivers/cpufreq/cpufreq_conservative.c
+++ b/drivers/cpufreq/cpufreq_conservative.c
@@ -23,6 +23,19 @@
static DEFINE_PER_CPU(struct cs_cpu_dbs_info_s, cs_cpu_dbs_info);
+static int cs_cpufreq_governor_dbs(struct cpufreq_policy *policy,
+ unsigned int event);
+
+#ifndef CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE
+static
+#endif
+struct cpufreq_governor cpufreq_gov_conservative = {
+ .name = "conservative",
+ .governor = cs_cpufreq_governor_dbs,
+ .max_transition_latency = TRANSITION_LATENCY_LIMIT,
+ .owner = THIS_MODULE,
+};
+
static inline unsigned int get_freq_target(struct cs_dbs_tuners *cs_tuners,
struct cpufreq_policy *policy)
{
@@ -119,12 +132,14 @@ static int dbs_cpufreq_notifier(struct notifier_block
*nb, unsigned long val,
struct cpufreq_freqs *freq = data;
struct cs_cpu_dbs_info_s *dbs_info =
_cpu(cs_cpu_dbs_info, freq->cpu);
- struct cpufreq_policy *policy;
+ struct cpufreq_policy *policy = cpufreq_cpu_get_raw(freq->cpu);
- if (!dbs_info->enable)
+ if (!policy)
return 0;
- policy = dbs_info->cdbs.shared->policy;
+ /* policy isn't governed by conservative governor */
+ if (policy->governor != _gov_conservative)
+ return 0;
/*
* we only care if our internally tracked freq moves outside the 'valid'
@@ -367,16 +382,6 @@ static int cs_cpufreq_governor_dbs(struct cpufreq_policy
*policy,
return cpufreq_governor_dbs(policy, _dbs_cdata, event);
}
-#ifndef CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE
-static
-#endif
-struct cpufreq_governor cpufreq_gov_conservative = {
- .name = "conservative",
- .governor = cs_cpufreq_governor_dbs,
- .max_transition_latency = TRANSITION_LATENCY_LIMIT,
- .owner = THIS_MODULE,
-};
-
static int __init cpufreq_gov_dbs_init(void)
{
return cpufreq_register_governor(_gov_conservative);
diff --git a/drivers/cpufreq/cpufreq_governor.c
b/drivers/cpufreq/cpufreq_governor.c
index 939197ffa4ac..750626d8fb03 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -463,7 +463,6 @@ static int cpufreq_governor_start(struct cpufreq_policy
*policy,
cdata->get_cpu_dbs_info_s(cpu);
cs_dbs_info->down_skip = 0;
- cs_dbs_info->enable = 1;
cs_dbs_info->requested_freq = policy->cur;
} else {
struct od_ops *od_ops = cdata->gov_ops;
@@ -482,9 +481,7 @@ static int cpufreq_governor_start(struct cpufreq_policy
*policy,
static int cpufreq_governor_stop(struct cpufreq_policy *policy,
struct dbs_data *dbs_data)
{
- struct common_dbs_data *cdata = dbs_data->cdata;
- unsigned int cpu = policy->cpu;
- struct cpu_dbs_info *cdbs = cdata->get_cpu_cdbs(cpu);
+ struct cpu_dbs_info *cdbs = dbs_data->cdata->get_cpu_cdbs(policy->cpu);
struct cpu_common_dbs_info *shared = cdbs->shared;
/* State should be equivalent to START */
@@ -493,13 +490,6 @@
linux-next: build failure after merge of the kvm tree
Hi all,
After merging the kvm tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
arch/powerpc/kvm/../../../virt/kvm/kvm_main.c: In function 'grow_halt_poll_ns':
arch/powerpc/kvm/../../../virt/kvm/kvm_main.c:1931:2: error: implicit
declaration of function 'trace_kvm_halt_poll_ns_grow'
[-Werror=implicit-function-declaration]
trace_kvm_halt_poll_ns_grow(vcpu->vcpu_id, val, old);
^
arch/powerpc/kvm/../../../virt/kvm/kvm_main.c: In function
'shrink_halt_poll_ns':
arch/powerpc/kvm/../../../virt/kvm/kvm_main.c:1945:2: error: implicit
declaration of function 'trace_kvm_halt_poll_ns_shrink'
[-Werror=implicit-function-declaration]
trace_kvm_halt_poll_ns_shrink(vcpu->vcpu_id, val, old);
^
Caused by commit
2cbd78244fb2 ("KVM: trace kvm_halt_poll_ns grow/shrink")
I have reverted that commit for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 2/9] cpufreq: conservative: remove 'enable' field
On 08-09-15, 02:17, Rafael J. Wysocki wrote:
> > static inline unsigned int get_freq_target(struct cs_dbs_tuners *cs_tuners,
> >struct cpufreq_policy *policy)
> > {
> > @@ -119,12 +132,14 @@ static int dbs_cpufreq_notifier(struct notifier_block
> > *nb, unsigned long val,
> > struct cpufreq_freqs *freq = data;
> > struct cs_cpu_dbs_info_s *dbs_info =
> > _cpu(cs_cpu_dbs_info, freq->cpu);
> > - struct cpufreq_policy *policy;
> > + struct cpufreq_policy *policy = cpufreq_cpu_get(freq->cpu);
> >
> > - if (!dbs_info->enable)
> > + if (!policy)
> > return 0;
> >
> > - policy = dbs_info->cdbs.shared->policy;
>
> So here we could get to the policy directly. After the change we have to:
>
> - acquire cpufreq_rwsem
> - acquire cpufreq_driver_lock
> - go the kobject_get on policy->kobj
Hmm, actually we can do cpufreq_cpu_get_raw() here as this is getting
called from notifier and policy isn't going to get freed for sure.
And then it wouldn't be that bad.
> and then finally drop the reference to the kobject when we're done.
>
> So may I ask where exactly is the improvement?
Agree. Let me resend it quickly.
> > + /* policy isn't governed by conservative governor */
> > + if (policy->governor != _gov_conservative)
> > + goto policy_put;
> >
> > /*
> > * we only care if our internally tracked freq moves outside the 'valid'
>
> Thanks,
> Rafael
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] zram: fix possible use after free in zcomp_create()
On Tue, Sep 08, 2015 at 10:20:38AM +0900, Sergey Senozhatsky wrote:
> On (09/08/15 10:07), Minchan Kim wrote:
> [..]
> > > + int ret;
> >
> > For the clarification, I want to call it as 'error' instead of ret.
> >
> > >
> > > backend = find_backend(compress);
> > > if (!backend)
> > > @@ -347,10 +348,10 @@ struct zcomp *zcomp_create(const char *compress,
> > > int max_strm)
> > >
> > > comp->backend = backend;
> > > if (max_strm > 1)
> > > - zcomp_strm_multi_create(comp, max_strm);
> > > + ret = zcomp_strm_multi_create(comp, max_strm);
> > > else
> > > - zcomp_strm_single_create(comp);
> > > - if (!comp->stream) {
> > > + ret = zcomp_strm_single_create(comp);
> > > + if (ret) {
> > > kfree(comp);
> > > return ERR_PTR(-ENOMEM);
> > > }
> >
> > And we could return ERR_PTR(error) rather than fixed -ENOMEM to propagate
>
> yep, I thought about that; looks to be minor so I didn't insist
> on changing that. don't mind to change it to ERR_PTR(error).
Thanks.
>
> > other errors potentially could be happen in future(ex, crypto support).
> > Of course, we should change description of the function about error return.
>
> on the other hand, this is zcomp_strm_FOO_create(), which is mostly
> about memory allocation. but yeah, who knows. We can change this as
> a part of crypto api rework; ERR_PTR(error) does not fix anything
> per se, so may be we can avoid pushing this change into stable.
Strictly speaking, you're right. I asked two things bug fixing and
refactoring. But I thought it is really trivial enough to push
-stable.
With bonus, it's more readable(ie, error naming) and makes sense(
ie, not assume under layer function always fails with no memory).
So, hope to fix it altogether if anyone isn't strong against that.
Thank you.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] zram: don't copy invalid compression algorithms
On (09/08/15 10:14), Minchan Kim wrote: [..] > > NACK. > > > > This is intentional. We haven't returned 'invalid compression algorithm' > > error from comp_algorithm_store() historically, so someone's script can > > simply ignore it. However, the script will fail to init the device and > > user will be able to figure out the root cause, because zram will report > > to syslog an actually requested alg name. > > > > Example > > > > [ 1669.473296] zram: Cannot initialise llzo compressing backend > > I don't understand your concern. To me, this patch makes sense to me. > Could you explain your point clearly, again? OK. suppose someone landed a typo in a 'zram device management' script echo llzo > /sys/block/zram0/comp_algorithm -bash: echo: write error: Invalid argument but the script ignores 'echo: write error'. Because we added compression algorithm name check recently. then the script does echo 200M > /sys/block/zram0/disksize -bash: echo: write error: Invalid argument doing a simple dmesg reveals the problem [ 7076.657184] zram: Cannot initialise llzo compressing backend note that zram provides 'llzo' here, which is convenient. With this change the semantics is changing and zram now swallows (hides) the user space error. echo llzo > /sys/block/zram0/comp_algorithm -bash: echo: write error: Invalid argument echo 200M > /sys/block/zram0/disksize instead of using a requested 'llzo' zram for some reason switched to 'lzo'. I don't like this behaviour change. User requested to change the 'default' value, and that new value didn't work out. No reason to hide it. -ss -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] zram: fix possible use after free in zcomp_create()
On (09/08/15 10:07), Minchan Kim wrote:
[..]
> > + int ret;
>
> For the clarification, I want to call it as 'error' instead of ret.
>
> >
> > backend = find_backend(compress);
> > if (!backend)
> > @@ -347,10 +348,10 @@ struct zcomp *zcomp_create(const char *compress, int
> > max_strm)
> >
> > comp->backend = backend;
> > if (max_strm > 1)
> > - zcomp_strm_multi_create(comp, max_strm);
> > + ret = zcomp_strm_multi_create(comp, max_strm);
> > else
> > - zcomp_strm_single_create(comp);
> > - if (!comp->stream) {
> > + ret = zcomp_strm_single_create(comp);
> > + if (ret) {
> > kfree(comp);
> > return ERR_PTR(-ENOMEM);
> > }
>
> And we could return ERR_PTR(error) rather than fixed -ENOMEM to propagate
yep, I thought about that; looks to be minor so I didn't insist
on changing that. don't mind to change it to ERR_PTR(error).
> other errors potentially could be happen in future(ex, crypto support).
> Of course, we should change description of the function about error return.
on the other hand, this is zcomp_strm_FOO_create(), which is mostly
about memory allocation. but yeah, who knows. We can change this as
a part of crypto api rework; ERR_PTR(error) does not fix anything
per se, so may be we can avoid pushing this change into stable.
-ss
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Documentation: Remove misleading examples of the barriers in wake_*()
Two examples for barriers in wake_up() and co. in memory-barriers.txt
are misleading, along with their explanations:
1. The example which wanted to explain the write barrier in
wake_up() and co. [spotted by Oleg Nesterov ]
2. The example which wanted to explain that the write barriers in
wake_up() and co. only exist iff a wakeup actually occurs.
For example #1, according to Oleg Nesterov:
>
> The barrier occurs before the task state is cleared
>
> is not actually right. This is misleading. What is really important is that
> we have a barrier before we _read_ the task state. And again, again, the
> fact that we actually have the write barrier is just the implementation
> detail.
>
And the example #2 is actually an example which could explain that the
barriers in wait_event() and co. only exist iff a sleep actually occurs.
Further more, these barriers are only used for the correctness of
sleeping and waking up, i.e. they exist only to guarantee the ordering
of memory accesses to the task states and the global variables
indicating an event. Users can't rely on them for other things, so
memory-barriers.txt had better to call this out and remove the
misleading examples.
This patch removes the misleading examples along with their
explanations, calls it out that those implied barriers are only for
sleep and wakeup related variables and adds a new example to explain the
implied barrier in wake_up() and co.
Signed-off-by: Boqun Feng
---
Documentation/memory-barriers.txt | 42 +--
1 file changed, 18 insertions(+), 24 deletions(-)
diff --git a/Documentation/memory-barriers.txt
b/Documentation/memory-barriers.txt
index eafa6a5..07de72f 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -1948,6 +1948,10 @@ these appear to happen in the right order, the
primitives to begin the process
of going to sleep, and the primitives to initiate a wake up imply certain
barriers.
+[!] Note that these implied barriers are only for the correctness of sleep and
+wake-up. So don't rely on these barriers for things that are neither the task
+states nor the global variables indicating the events.
+
Firstly, the sleeper normally follows something like this sequence of events:
for (;;) {
@@ -1997,32 +2001,22 @@ or:
event_indicated = 1;
wake_up_process(event_daemon);
-A write memory barrier is implied by wake_up() and co. if and only if they wake
-something up. The barrier occurs before the task state is cleared, and so sits
-between the STORE to indicate the event and the STORE to set TASK_RUNNING:
-
- CPU 1 CPU 2
- === ===
- set_current_state();STORE event_indicated
- smp_store_mb(); wake_up();
- STORE current->state
-STORE current->state
- LOAD event_indicated
+A memory barrier is implied by wake_up() and co. if and only if they wake
+something up. The memory barrier here is not necessary to be a general barrier,
+it only needs to guarantee a STORE preceding this barrier can never be
+reordered after a LOAD following this barrier(i.e. a STORE-LOAD barrier). This
+barrier guarantees that the event has been indicated before the waker read the
+wakee's task state:
-To repeat, this write memory barrier is present if and only if something
-is actually awakened. To see this, consider the following sequence of
-events, where X and Y are both initially zero:
+ CPU 1
+ ===
+ STORE event_indicated;
+ wake_up_process(wakee);
+
+ LOAD wakee->state;
- CPU 1 CPU 2
- === ===
- X = 1; STORE event_indicated
- smp_mb(); wake_up();
- Y = 1; wait_event(wq, Y == 1);
- wake_up();load from Y sees 1, no memory barrier
- load from X might see 0
-
-In contrast, if a wakeup does occur, CPU 2's load from X would be guaranteed
-to see 1.
+This barrier pairs with the general barrier implied by set_current_state() on
+the sleeper side.
The available waker functions include:
--
2.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] zram: don't copy invalid compression algorithms
Hey Sergey,
On Tue, Sep 08, 2015 at 08:56:35AM +0900, Sergey Senozhatsky wrote:
> On (09/07/15 21:48), Luis Henriques wrote:
> > Validate the new compression algorithm before copying it into the zram
> > 'compressor' field, keeping the old one if it's invalid.
> >
>
> NACK.
>
> This is intentional. We haven't returned 'invalid compression algorithm'
> error from comp_algorithm_store() historically, so someone's script can
> simply ignore it. However, the script will fail to init the device and
> user will be able to figure out the root cause, because zram will report
> to syslog an actually requested alg name.
>
> Example
>
> [ 1669.473296] zram: Cannot initialise llzo compressing backend
I don't understand your concern. To me, this patch makes sense to me.
Could you explain your point clearly, again?
Thanks.
>
>
> -ss
>
> > The error path code is also slightly refactored.
> >
> > Signed-off-by: Luis Henriques
> > ---
> > drivers/block/zram/zram_drv.c | 13 -
> > 1 file changed, 8 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> > index 9c01f5bfa33f..33551ec9e7f5 100644
> > --- a/drivers/block/zram/zram_drv.c
> > +++ b/drivers/block/zram/zram_drv.c
> > @@ -367,10 +367,15 @@ static ssize_t comp_algorithm_store(struct device
> > *dev,
> >
> > down_write(>init_lock);
> > if (init_done(zram)) {
> > - up_write(>init_lock);
> > pr_info("Can't change algorithm for initialized device\n");
> > - return -EBUSY;
> > + len = -EBUSY;
> > + goto out;
> > + }
> > + if (!zcomp_available_algorithm(buf)) {
> > + len = -EINVAL;
> > + goto out;
> > }
> > +
> > strlcpy(zram->compressor, buf, sizeof(zram->compressor));
> >
> > /* ignore trailing newline */
> > @@ -378,9 +383,7 @@ static ssize_t comp_algorithm_store(struct device *dev,
> > if (sz > 0 && zram->compressor[sz - 1] == '\n')
> > zram->compressor[sz - 1] = 0x00;
> >
> > - if (!zcomp_available_algorithm(zram->compressor))
> > - len = -EINVAL;
> > -
> > +out:
> > up_write(>init_lock);
> > return len;
> > }
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend
> -Original Message- > From: linux-input-ow...@vger.kernel.org > [mailto:linux-input-ow...@vger.kernel.org] On Behalf Of Rafael J. Wysocki > Sent: 08 September, 2015 0:20 > To: Tirdea, Irina > Cc: Alan Stern; linux...@vger.kernel.org; linux-in...@vger.kernel.org; > linux-kernel@vger.kernel.org; Brown, Len; Pavel Machek; > Purdila, Octavian; Dmitry Torokhov > Subject: Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing > runtime suspend > > On Monday, September 07, 2015 11:42:41 PM Irina Tirdea wrote: > > Add new option to sysfs control interface, allowing the user to force > > suspend the device. > > Had we thought this had been a good idea, we'd have added that thing to > the interface from the start. > > The problem with it is that user space generally doesn't know when it is > safe to suspend a device, so it cannot force anything into runtime suspend. > Yes, this is generally true. However, in the scenario I mentioned this is exactly what is happening. When turning off the screen of a mobile device, the user space is the one that suspends the devices that are not needed in order to save power (like touchscreens). Each such driver export an enable/disable attribute that calls the same code as resume/suspend (e.g. touchscreen drivers ads7846, ad7877 and most Android drivers not merged upstream). This adds more complexity to every driver by adding one more logical power state. It would be good to have a common interface instead of doing this in every driver. I might have not used "forced" in the proper way here. What I mean by it is that the device can be runtime suspended while ignoring the runtime usage count. > > This is useful for devices that need to be > > suspended when closing the lid of a laptop or the screen of a mobile > > device, while user space still holds open handles to it and the > > system does not enter system suspend. > > > > Add the "off" option to the sysfs control power interface, along with > > the already present "on" and "auto". When this attribute is set to > > "off", the device will be force suspended by calling its runtime > > suspend callback and disabling runtime power management so that > > further accesses to the device will not change the actual state. > > And how is user space supposed to know that it doesn't break things > this way? > In this implementation, user space is only allowed to change the states bottom-up in the sysfs hierarchy (it cannot force suspend a device if it has children that have not been suspended by user space). Another way to do this is to keep runtime power management enabled but to force the usage count to 0 while the device is set to runtime mode "off". > > The device can be resumed by setting the attribute to "on" or "auto". > > The behavior of the interface when switching only between "on" > > and "auto" states remains unchanged. > > > > Signed-off-by: Irina Tirdea > > --- > > > > Hi, > > > > This is a proposal for suspending devices when the closing the lid of > > a laptop or the screen of a mobile device. > > > > I am testing this with a Goodix touchscreen [1] for an Android mobile > > device. Android has an user space layer (power HAL) that would normally > > close the touchscreen when the screen is closed. Android touchscreen > > drivers usually provide a custom sysfs interface to allow this. > > This would be better implemented in a common place, to avoid code > > duplication and to simplify the driver code (as previously discussed > > in [1]). > > > > I know there are more ways to implement this, so I would appreciate > > your feedback. > > So the feedback is that this is not going to work in general. Please > use a different approach. > Would it work if this would be a capability that individual drivers need to declare? In the previous discussion thread , there were a couple of options mentioned, but none seemed to reach a consensus. You mentioned adding a "more aggressive runtime PM mode" [1]. I'm not sure how this would work except for adding a sysfs attribute that would trigger a runtime suspend while ignoring usage count. Would that be a better direction? Thank you, Irina [1] http://marc.info/?l=linux-input=140564626306396=2 > Thanks, > Rafael > > -- > To unsubscribe from this list: send the line "unsubscribe linux-input" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 1/4] iio: bmc150: Use i2c regmap
> -Original Message-
> From: Srinivas Pandruvada [mailto:srinivas.pandruv...@linux.intel.com]
> Sent: 31 August, 2015 22:39
> To: Jonathan Cameron; Markus Pargmann; Tirdea, Irina
> Cc: Lars-Peter Clausen; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org; ker...@pengutronix.de
> Subject: Re: [PATCH v2 1/4] iio: bmc150: Use i2c regmap
>
> Hi Irina,
>
Hi Srinivas,
> Is it possible for you to test this patchset? I don't have platform to
> test with me now (working remotely for couple of weeks).
>
Sure, I'll test this patch set today.
Sorry for the late response, seems I somehow missed your e-mail.
Regards,
Irina
> Thanks,
> Srinivas
>
> On Mon, 2015-08-31 at 17:11 +0100, Jonathan Cameron wrote:
> > On 20/08/15 13:49, Markus Pargmann wrote:
> > > This replaces all usage of direct i2c accesses with regmap
> > > accesses.
> > >
> > > Signed-off-by: Markus Pargmann
> > Looks fine to me, but I will be wanting an Ack / reviewed-by
> > and preferably a tested by from Srinivas.
> >
> > Thanks,
> >
> > Jonathan
> > > ---
> > > drivers/iio/accel/Kconfig| 2 +
> > > drivers/iio/accel/bmc150-accel.c | 219 +--
> > >
> > > 2 files changed, 95 insertions(+), 126 deletions(-)
> > >
> > > diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
> > > index 00e7bcbdbe24..01dd03d194d1 100644
> > > --- a/drivers/iio/accel/Kconfig
> > > +++ b/drivers/iio/accel/Kconfig
> > > @@ -22,6 +22,8 @@ config BMC150_ACCEL
> > > depends on I2C
> > > select IIO_BUFFER
> > > select IIO_TRIGGERED_BUFFER
> > > + select REGMAP
> > > + select REGMAP_I2C
> > > help
> > > Say yes here to build support for the following Bosch
> > > accelerometers:
> > > BMC150, BMI055, BMA250E, BMA222E, BMA255, BMA280.
> > > diff --git a/drivers/iio/accel/bmc150-accel.c
> > > b/drivers/iio/accel/bmc150-accel.c
> > > index 55751d9e1ade..c5c773e75173 100644
> > > --- a/drivers/iio/accel/bmc150-accel.c
> > > +++ b/drivers/iio/accel/bmc150-accel.c
> > > @@ -35,6 +35,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > >
> > > #define BMC150_ACCEL_DRV_NAME"bmc150_accel
> > > "
> > > #define BMC150_ACCEL_IRQ_NAME"bmc150_accel
> > > _event"
> > > @@ -185,6 +186,8 @@ enum bmc150_accel_trigger_id {
> > >
> > > struct bmc150_accel_data {
> > > struct i2c_client *client;
> > > + struct regmap *regmap;
> > > + struct device *dev;
> > > struct bmc150_accel_interrupt
> > > interrupts[BMC150_ACCEL_INTERRUPTS];
> > > atomic_t active_intr;
> > > struct bmc150_accel_trigger
> > > triggers[BMC150_ACCEL_TRIGGERS];
> > > @@ -241,6 +244,11 @@ static const struct {
> > > {50,
> > > BMC150_ACCEL_SLEEP_500_MS},
> > > {100,
> > > BMC150_ACCEL_SLEEP_1_SEC} };
> > >
> > > +static const struct regmap_config bmc150_i2c_regmap_conf = {
> > > + .reg_bits = 8,
> > > + .val_bits = 8,
> > > + .max_register = 0x3f,
> > > +};
> > >
> > > static int bmc150_accel_set_mode(struct bmc150_accel_data *data,
> > >enum bmc150_power_modes mode,
> > > @@ -270,8 +278,7 @@ static int bmc150_accel_set_mode(struct
> > > bmc150_accel_data *data,
> > >
> > > dev_dbg(>client->dev, "Set Mode bits %x\n",
> > > lpw_bits);
> > >
> > > - ret = i2c_smbus_write_byte_data(data->client,
> > > - BMC150_ACCEL_REG_PMU_LPW,
> > > lpw_bits);
> > > + ret = regmap_write(data->regmap, BMC150_ACCEL_REG_PMU_LPW,
> > > lpw_bits);
> > > if (ret < 0) {
> > > dev_err(>client->dev, "Error writing
> > > reg_pmu_lpw\n");
> > > return ret;
> > > @@ -289,8 +296,7 @@ static int bmc150_accel_set_bw(struct
> > > bmc150_accel_data *data, int val,
> > > for (i = 0; i < ARRAY_SIZE(bmc150_accel_samp_freq_table);
> > > ++i) {
> > > if (bmc150_accel_samp_freq_table[i].val == val &&
> > > bmc150_accel_samp_freq_table[i].va
> > > l2 == val2) {
> > > - ret = i2c_smbus_write_byte_data(
> > > - data->client,
> > > + ret = regmap_write(data->regmap,
> > > BMC150_ACCEL_REG_PMU_BW,
> > > bmc150_accel_samp_freq_table[i].bw
> > > _bits);
> > > if (ret < 0)
> > > @@ -307,26 +313,19 @@ static int bmc150_accel_set_bw(struct
> > > bmc150_accel_data *data, int val,
> > >
> > > static int bmc150_accel_update_slope(struct bmc150_accel_data
> > > *data)
> > > {
> > > - int ret, val;
> > > + int ret;
> > >
> > > - ret = i2c_smbus_write_byte_data(data->client,
> > > BMC150_ACCEL_REG_INT_6,
> > > + ret = regmap_write(data->regmap, BMC150_ACCEL_REG_INT_6,
> > > data->slope_thres);
> > > if (ret < 0) {
> > > dev_err(>client->dev, "Error writing
> > > reg_int_6\n");
> > > return ret;
> > > }
> > >
> > > - ret =
Re: [PATCH V2 6/9] cpufreq: ondemand: queue work for policy->cpus together
On Monday, July 27, 2015 05:58:11 PM Viresh Kumar wrote:
> Currently update_sampling_rate() runs over each online CPU and
> cancels/queues work on it. Its very inefficient for the case where a
> single policy manages multiple CPUs, as they can be processed together.
>
> Also drop the unnecessary cancel_delayed_work_sync() as we are doing a
> mod_delayed_work_on() in gov_queue_work(), which will take care of
> pending works for us.
>
> Signed-off-by: Viresh Kumar
> ---
> drivers/cpufreq/cpufreq_ondemand.c | 31 ++-
> 1 file changed, 18 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq_ondemand.c
> b/drivers/cpufreq/cpufreq_ondemand.c
> index f1551fc7b4fd..a6f579e40ce2 100644
> --- a/drivers/cpufreq/cpufreq_ondemand.c
> +++ b/drivers/cpufreq/cpufreq_ondemand.c
> @@ -247,40 +247,45 @@ static void update_sampling_rate(struct dbs_data
> *dbs_data,
> unsigned int new_rate)
> {
> struct od_dbs_tuners *od_tuners = dbs_data->tuners;
> + struct cpufreq_policy *policy;
> + struct od_cpu_dbs_info_s *dbs_info;
> + unsigned long next_sampling, appointed_at;
> + struct cpumask cpumask;
> int cpu;
>
> + cpumask_copy(, cpu_online_mask);
> +
> od_tuners->sampling_rate = new_rate = max(new_rate,
> dbs_data->min_sampling_rate);
>
> - for_each_online_cpu(cpu) {
> - struct cpufreq_policy *policy;
> - struct od_cpu_dbs_info_s *dbs_info;
> - unsigned long next_sampling, appointed_at;
> -
> + for_each_cpu(cpu, ) {
> policy = cpufreq_cpu_get(cpu);
> if (!policy)
> continue;
> +
> + /* clear all CPUs of this policy */
> + cpumask_andnot(, , policy->cpus);
Well, this is not exactly straightforward, but should work.
> +
> if (policy->governor != _gov_ondemand) {
> cpufreq_cpu_put(policy);
> continue;
> }
> +
> dbs_info = _cpu(od_cpu_dbs_info, cpu);
> cpufreq_cpu_put(policy);
>
> - if (!delayed_work_pending(_info->cdbs.dwork))
> + /* Make sure the work is not canceled on policy->cpus */
I'm not sure what scenario can lead to that. Care to explain?
> + if (!dbs_info->cdbs.shared->policy)
> continue;
>
> next_sampling = jiffies + usecs_to_jiffies(new_rate);
> appointed_at = dbs_info->cdbs.dwork.timer.expires;
For that to work we always need to do stuff for policy->cpus in sync.
Do we?
> - if (time_before(next_sampling, appointed_at)) {
> - cancel_delayed_work_sync(_info->cdbs.dwork);
> -
> - gov_queue_work(dbs_data, policy,
> -usecs_to_jiffies(new_rate),
> -cpumask_of(cpu));
> + if (!time_before(next_sampling, appointed_at))
> + continue;
>
> - }
> + gov_queue_work(dbs_data, policy, usecs_to_jiffies(new_rate),
> +policy->cpus);
> }
> }
>
>
Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] zram: fix possible use after free in zcomp_create()
Hello,
First of all, Thanks for catching a bug and review, Guys.
Below there are just some cleanup.
If you guys think it's better, please respin.
On Mon, Sep 07, 2015 at 03:13:10PM +0100, Luis Henriques wrote:
> zcomp_create() verifies the success of zcomp_strm_{multi,siggle}_create()
> through comp->stream, which can potentially be pointing to memory that was
> freed if these functions returned an error.
>
> Fixes: beca3ec71fe5 ("zram: add multi stream functionality")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Luis Henriques
> ---
> Changes since v1:
> * Check zcomp_strm_{multi,siggle}_create() return code instead
>comp->stream (suggested by Sergey)
>
> drivers/block/zram/zcomp.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/block/zram/zcomp.c b/drivers/block/zram/zcomp.c
> index 965d1afb0eaa..8d2cdfd307db 100644
> --- a/drivers/block/zram/zcomp.c
> +++ b/drivers/block/zram/zcomp.c
> @@ -336,6 +336,7 @@ struct zcomp *zcomp_create(const char *compress, int
> max_strm)
> {
> struct zcomp *comp;
> struct zcomp_backend *backend;
> + int ret;
For the clarification, I want to call it as 'error' instead of ret.
>
> backend = find_backend(compress);
> if (!backend)
> @@ -347,10 +348,10 @@ struct zcomp *zcomp_create(const char *compress, int
> max_strm)
>
> comp->backend = backend;
> if (max_strm > 1)
> - zcomp_strm_multi_create(comp, max_strm);
> + ret = zcomp_strm_multi_create(comp, max_strm);
> else
> - zcomp_strm_single_create(comp);
> - if (!comp->stream) {
> + ret = zcomp_strm_single_create(comp);
> + if (ret) {
> kfree(comp);
> return ERR_PTR(-ENOMEM);
> }
And we could return ERR_PTR(error) rather than fixed -ENOMEM to propagate
other errors potentially could be happen in future(ex, crypto support).
Of course, we should change description of the function about error return.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 4/9] cpufreq: governor: Drop __gov_queue_work()
On Monday, July 27, 2015 05:58:09 PM Viresh Kumar wrote:
> __gov_queue_work() isn't required anymore and can be merged with
> gov_queue_work(). Do it.
>
> Signed-off-by: Viresh Kumar
Quite frankly I don't see the point.
I'd even remove the inline from its definition and let the compiler decide
what to do with it.
> ---
> drivers/cpufreq/cpufreq_governor.c | 17 ++---
> 1 file changed, 6 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq_governor.c
> b/drivers/cpufreq/cpufreq_governor.c
> index a890450711bb..3ddc27764e10 100644
> --- a/drivers/cpufreq/cpufreq_governor.c
> +++ b/drivers/cpufreq/cpufreq_governor.c
> @@ -158,25 +158,20 @@ void dbs_check_cpu(struct dbs_data *dbs_data, int cpu)
> }
> EXPORT_SYMBOL_GPL(dbs_check_cpu);
>
> -static inline void __gov_queue_work(int cpu, struct dbs_data *dbs_data,
> - unsigned int delay)
> -{
> - struct cpu_dbs_info *cdbs = dbs_data->cdata->get_cpu_cdbs(cpu);
> -
> - mod_delayed_work_on(cpu, system_wq, >dwork, delay);
> -}
> -
> void gov_queue_work(struct dbs_data *dbs_data, struct cpufreq_policy *policy,
> unsigned int delay, const struct cpumask *cpus)
> {
> - int i;
> + struct cpu_dbs_info *cdbs;
> + int cpu;
>
> mutex_lock(_governor_lock);
> if (!policy->governor_enabled)
> goto out_unlock;
>
> - for_each_cpu(i, cpus)
> - __gov_queue_work(i, dbs_data, delay);
> + for_each_cpu(cpu, cpus) {
> + cdbs = dbs_data->cdata->get_cpu_cdbs(cpu);
> + mod_delayed_work_on(cpu, system_wq, >dwork, delay);
> + }
>
> out_unlock:
> mutex_unlock(_governor_lock);
>
Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 3/9] cpufreq: ondemand: only queue canceled works from update_sampling_rate()
On Monday, July 27, 2015 05:58:08 PM Viresh Kumar wrote:
> The sampling rate is updated with a call to update_sampling_rate(), and
> we process CPUs one by one here. While the work is canceled on per-cpu
> basis, it is getting queued (by mistake) for all policy->cpus.
>
> This would result in wasting cpu cycles for queuing works which are
> already queued and never canceled.
>
> This patch changes this behavior to queue work only on the cpu, for
> which it was canceled earlier.
>
> To do that, replace 'modify_all' parameter to gov_queue_work() with a
> mask of CPUs.
There really are two cases, either you pass a CPU or gov_queue_work() has to
walk policy->cpus. Doing it the way you did hides that IMO.
I'd simply pass an int and use a special value to indicate that policy->cpus
is to be walked.
> Also the last parameter to ->gov_dbs_timer() was named
> 'modify_all' earlier, but its purpose was to decide if load has to be
> evaluated again or not. Lets rename that to load_eval.
>
> Fixes: 031299b3be30 ("cpufreq: governors: Avoid unnecessary per cpu timer
> interrupts")
> Signed-off-by: Viresh Kumar
> ---
> drivers/cpufreq/cpufreq_conservative.c | 4 ++--
> drivers/cpufreq/cpufreq_governor.c | 30 ++
> drivers/cpufreq/cpufreq_governor.h | 4 ++--
> drivers/cpufreq/cpufreq_ondemand.c | 7 ---
> 4 files changed, 18 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq_conservative.c
> b/drivers/cpufreq/cpufreq_conservative.c
> index 18bfbc313e48..1aa3bd46cea3 100644
> --- a/drivers/cpufreq/cpufreq_conservative.c
> +++ b/drivers/cpufreq/cpufreq_conservative.c
> @@ -116,11 +116,11 @@ static void cs_check_cpu(int cpu, unsigned int load)
> }
>
> static unsigned int cs_dbs_timer(struct cpu_dbs_info *cdbs,
> - struct dbs_data *dbs_data, bool modify_all)
> + struct dbs_data *dbs_data, bool load_eval)
> {
> struct cs_dbs_tuners *cs_tuners = dbs_data->tuners;
>
> - if (modify_all)
> + if (load_eval)
> dbs_check_cpu(dbs_data, cdbs->shared->policy->cpu);
>
> return delay_for_sampling_rate(cs_tuners->sampling_rate);
> diff --git a/drivers/cpufreq/cpufreq_governor.c
> b/drivers/cpufreq/cpufreq_governor.c
> index 750626d8fb03..a890450711bb 100644
> --- a/drivers/cpufreq/cpufreq_governor.c
> +++ b/drivers/cpufreq/cpufreq_governor.c
> @@ -167,7 +167,7 @@ static inline void __gov_queue_work(int cpu, struct
> dbs_data *dbs_data,
> }
>
> void gov_queue_work(struct dbs_data *dbs_data, struct cpufreq_policy *policy,
> - unsigned int delay, bool all_cpus)
> + unsigned int delay, const struct cpumask *cpus)
> {
> int i;
>
> @@ -175,19 +175,8 @@ void gov_queue_work(struct dbs_data *dbs_data, struct
> cpufreq_policy *policy,
> if (!policy->governor_enabled)
> goto out_unlock;
>
> - if (!all_cpus) {
> - /*
> - * Use raw_smp_processor_id() to avoid preemptible warnings.
> - * We know that this is only called with all_cpus == false from
> - * works that have been queued with *_work_on() functions and
> - * those works are canceled during CPU_DOWN_PREPARE so they
> - * can't possibly run on any other CPU.
> - */
This was a useful comment and it should be moved along the logic it was supposed
to explain and not just dropped.
> - __gov_queue_work(raw_smp_processor_id(), dbs_data, delay);
> - } else {
> - for_each_cpu(i, policy->cpus)
> - __gov_queue_work(i, dbs_data, delay);
> - }
> + for_each_cpu(i, cpus)
> + __gov_queue_work(i, dbs_data, delay);
>
> out_unlock:
> mutex_unlock(_governor_lock);
> @@ -232,7 +221,8 @@ static void dbs_timer(struct work_struct *work)
> struct cpufreq_policy *policy = shared->policy;
> struct dbs_data *dbs_data = policy->governor_data;
> unsigned int sampling_rate, delay;
> - bool modify_all = true;
> + const struct cpumask *cpus;
I don't think this local variable is necessary.
> + bool load_eval;
>
> mutex_lock(>timer_mutex);
>
> @@ -246,11 +236,11 @@ static void dbs_timer(struct work_struct *work)
> sampling_rate = od_tuners->sampling_rate;
> }
>
> - if (!need_load_eval(cdbs->shared, sampling_rate))
> - modify_all = false;
> + load_eval = need_load_eval(cdbs->shared, sampling_rate);
> + cpus = load_eval ? policy->cpus : cpumask_of(raw_smp_processor_id());
>
> - delay = dbs_data->cdata->gov_dbs_timer(cdbs, dbs_data, modify_all);
> - gov_queue_work(dbs_data, policy, delay, modify_all);
> + delay = dbs_data->cdata->gov_dbs_timer(cdbs, dbs_data, load_eval);
> + gov_queue_work(dbs_data, policy, delay, cpus);
>
> mutex_unlock(>timer_mutex);
> }
> @@ -474,7 +464,7 @@ static int
Re: [PATCH v4 4/4] ARM: dts: add suspend opp to exynos4412
On 08.09.2015 00:41, Bartlomiej Zolnierkiewicz wrote: > Mark 800MHz OPP as a suspend opp for Exynos4412 based > boards so effectively cpufreq-dt driver behavior w.r.t. > suspend frequency matches what the old exynos-cpufreq > driver has been doing. > > This patch fixes suspend/resume support on Exynos4412 based > Trats2 board and reboot hang on Exynos4412 based Odroid U3 > board. > > Cc: Thomas Abraham > Cc: Javier Martinez Canillas > Cc: Krzysztof Kozlowski > Cc: Marek Szyprowski > Cc: Tobias Jakobi > Acked-by: Viresh Kumar > Signed-off-by: Bartlomiej Zolnierkiewicz > --- > arch/arm/boot/dts/exynos4412.dtsi | 1 + > 1 file changed, 1 insertion(+) Acked-by: Krzysztof Kozlowski Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] leds:lp55xx: Correct Kconfig dependency for f/w user helper
Hi Takashi,
On 9/7/2015 11:19 PM, Jacek Anaszewski wrote:
Hi Takashi,
Thanks for chasing this.
Milo, could you express your opinion?
On 09/07/2015 02:25 PM, Takashi Iwai wrote:
The commit [b67893206fc0: leds:lp55xx: fix firmware loading error]
tries to address the firmware file handling with user helper, but it
sets a wrong Kconfig CONFIG_FW_LOADER_USER_HELPER_FALLBACK. Since the
wrong option was enabled, the system got a regression -- it suffers
from the unexpected long delays for non-present firmware files.
This patch corrects the Kconfig dependency to the right one,
CONFIG_FW_LOADER_USER_HELPER. This doesn't change the fallback
behavior but only enables UMH when needed.
Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=944661
Fixes: b67893206fc0 ('leds:lp55xx: fix firmware loading error')
Cc: # v4.2+
Signed-off-by: Takashi Iwai
---
drivers/leds/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 70f4255ff291..2ba52bc2e174 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -229,7 +229,7 @@ config LEDS_LP55XX_COMMON
tristate "Common Driver for TI/National LP5521/5523/55231/5562/8501"
depends on LEDS_LP5521 || LEDS_LP5523 || LEDS_LP5562 || LEDS_LP8501
select FW_LOADER
- select FW_LOADER_USER_HELPER_FALLBACK
+ select FW_LOADER_USER_HELPER
help
This option supports common operations for LP5521/5523/55231/5562/8501
devices.
Thank for catching this. It seems I misunderstood firmware helper
configuration. LP55xx driver uses firmware interface to activate LED
visual effect. So this driver enables FW_LOADER_USER_HELPER_FALLBACK and
calls request_firmware_nowait() without uevent. Then, it will try to
load raw data manually when binary(firmware) file doesn't exist.
I'm still not clear what the difference is between FW_LOADER_USER_HELPER
and FW_LOADER_USER_HELPER_FALLBACK. Kconfig description makes me confused.
Could you explain it in more details?
Best regards,
Milo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: wake_up_process implied memory barrier clarification
Hi Oleg,
On Mon, Sep 07, 2015 at 07:06:52PM +0200, Oleg Nesterov wrote:
> Sorry for delay,
>
> On 09/02, Boqun Feng wrote:
> >
> > On Tue, Sep 01, 2015 at 06:39:23PM +0200, Oleg Nesterov wrote:
> > > On 09/01, Boqun Feng wrote:
> > > >
> > > > On Tue, Sep 01, 2015 at 11:59:23AM +0200, Oleg Nesterov wrote:
> > > > >
> > > > > And just in case, wake_up() differs in a sense that it doesn't even
> > > > > need
> > > > > that STORE-LOAD barrier in try_to_wake_up(), we can rely on
> > > > > wait_queue_head_t->lock. Assuming that wake_up() pairs with the
> > > > > "normal"
> > > > > wait_event()-like code.
> > >
> > > Looks like, you have missed this part of my previous email. See below.
> >
> > I guess I need to think through this, though I haven't found any problem
> > in wake_up() if we remove the STORE-LOAD barrier in try_to_wake_up().
> > And I know that in wake_up(), try_to_wake_up() will be called with
> > holding wait_queue_head_t->lock, however, only part of wait_event()
> > holds the same lock, I can't figure out why the barrier is not needed
> > because of the lock..
>
> This is very simple. __wait_event() does
>
> for (;;) {
> prepare_to_wait_event(WQ, ...); // takes WQ->lock
>
> if (CONDITION)
> break;
>
> schedule();
> }
>
> and we have
>
> CONDITION = 1;
> wake_up(WQ);// takes WQ->lock
>
> on another side.
>
> Suppose that __wait_event() wins and takes WQ->lock first. It can block
> then. In this case wake_up() must see the result of set_current_state()
> and list_add() when it takes the same lock, otherwise spin_lock() would
> be simply buggy. So it will wake the waiter up.
>
> At the same time, if __wait_event() takes this lock after wake_up(), it
> can not miss CONDITION = 1. It must see it after it takes the lock, and
> of course after it drops the lock too.
>
Yes, you're right! I wasn't aware that in prepare_to_wait_event(),
set_current_state() is called with the WQ->lock.
> So I am not sure I understand your concerns in this case...
>
It's my mistake. Thank you for your explanation ;-)
Regards,
Boqun
signature.asc
Description: PGP signature
Re: [PATCH] ARM: fix bug which lowmem size is limited to 760MB
On Mon, Sep 07, 2015 at 03:40:36PM -0400, Nicolas Pitre wrote: > On Mon, 7 Sep 2015, Arnd Bergmann wrote: > > > On Thursday 03 September 2015 21:24:00 Nicolas Pitre wrote: > > > If 768MB targets were common place then it could be worth changing the > > > default vmalloc size to accommodate this memory size and testing all the > > > other targets to make sure no regressions are introduced. But given it > > > is easy to change the default via the kernel cmdline, and that you lose > > > only 8 MB otherwise, I don't think it is worth the trouble and/or the > > > risk. > > > > Agreed. > > Well... I think there is a better solution. Doesn't this clash with things like: #define UNCACHEABLE_ADDR0xff00 /* IRQ_STAT */ ? -- FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] zram: fix possible use after free in zcomp_create()
On (09/07/15 15:13), Luis Henriques wrote:
> zcomp_create() verifies the success of zcomp_strm_{multi,siggle}_create()
> through comp->stream, which can potentially be pointing to memory that was
> freed if these functions returned an error.
>
> Fixes: beca3ec71fe5 ("zram: add multi stream functionality")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Luis Henriques
Cc Andrew
Acked-by: Sergey Senozhatsky
-ss
> ---
> Changes since v1:
> * Check zcomp_strm_{multi,siggle}_create() return code instead
>comp->stream (suggested by Sergey)
>
> drivers/block/zram/zcomp.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/block/zram/zcomp.c b/drivers/block/zram/zcomp.c
> index 965d1afb0eaa..8d2cdfd307db 100644
> --- a/drivers/block/zram/zcomp.c
> +++ b/drivers/block/zram/zcomp.c
> @@ -336,6 +336,7 @@ struct zcomp *zcomp_create(const char *compress, int
> max_strm)
> {
> struct zcomp *comp;
> struct zcomp_backend *backend;
> + int ret;
>
> backend = find_backend(compress);
> if (!backend)
> @@ -347,10 +348,10 @@ struct zcomp *zcomp_create(const char *compress, int
> max_strm)
>
> comp->backend = backend;
> if (max_strm > 1)
> - zcomp_strm_multi_create(comp, max_strm);
> + ret = zcomp_strm_multi_create(comp, max_strm);
> else
> - zcomp_strm_single_create(comp);
> - if (!comp->stream) {
> + ret = zcomp_strm_single_create(comp);
> + if (ret) {
> kfree(comp);
> return ERR_PTR(-ENOMEM);
> }
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] zram: don't copy invalid compression algorithms
On (09/07/15 21:48), Luis Henriques wrote:
> Validate the new compression algorithm before copying it into the zram
> 'compressor' field, keeping the old one if it's invalid.
>
NACK.
This is intentional. We haven't returned 'invalid compression algorithm'
error from comp_algorithm_store() historically, so someone's script can
simply ignore it. However, the script will fail to init the device and
user will be able to figure out the root cause, because zram will report
to syslog an actually requested alg name.
Example
[ 1669.473296] zram: Cannot initialise llzo compressing backend
-ss
> The error path code is also slightly refactored.
>
> Signed-off-by: Luis Henriques
> ---
> drivers/block/zram/zram_drv.c | 13 -
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> index 9c01f5bfa33f..33551ec9e7f5 100644
> --- a/drivers/block/zram/zram_drv.c
> +++ b/drivers/block/zram/zram_drv.c
> @@ -367,10 +367,15 @@ static ssize_t comp_algorithm_store(struct device *dev,
>
> down_write(>init_lock);
> if (init_done(zram)) {
> - up_write(>init_lock);
> pr_info("Can't change algorithm for initialized device\n");
> - return -EBUSY;
> + len = -EBUSY;
> + goto out;
> + }
> + if (!zcomp_available_algorithm(buf)) {
> + len = -EINVAL;
> + goto out;
> }
> +
> strlcpy(zram->compressor, buf, sizeof(zram->compressor));
>
> /* ignore trailing newline */
> @@ -378,9 +383,7 @@ static ssize_t comp_algorithm_store(struct device *dev,
> if (sz > 0 && zram->compressor[sz - 1] == '\n')
> zram->compressor[sz - 1] = 0x00;
>
> - if (!zcomp_available_algorithm(zram->compressor))
> - len = -EINVAL;
> -
> +out:
> up_write(>init_lock);
> return len;
> }
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 2/9] cpufreq: conservative: remove 'enable' field
On Monday, July 27, 2015 05:58:07 PM Viresh Kumar wrote:
> Conservative governor has its own 'enable' field to check if
> conservative governor is used for a CPU or not
>
> This can be checked by policy->governor with 'cpufreq_gov_conservative'
> and so this field can be dropped.
>
> Because its not guaranteed that dbs_info->cdbs.shared will a valid
> pointer for all CPUs (will be NULL for CPUs that don't use
> ondemand/conservative governors), we can't use it anymore. Lets get
> policy with cpufreq_cpu_get() instead.
But previously, if the enable bit was set, we actually new that the
pointer was valid, right?
> Signed-off-by: Viresh Kumar
> ---
> drivers/cpufreq/cpufreq_conservative.c | 34
> +-
> drivers/cpufreq/cpufreq_governor.c | 12 +---
> drivers/cpufreq/cpufreq_governor.h | 1 -
> 3 files changed, 22 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq_conservative.c
> b/drivers/cpufreq/cpufreq_conservative.c
> index 84a1506950a7..18bfbc313e48 100644
> --- a/drivers/cpufreq/cpufreq_conservative.c
> +++ b/drivers/cpufreq/cpufreq_conservative.c
> @@ -23,6 +23,19 @@
>
> static DEFINE_PER_CPU(struct cs_cpu_dbs_info_s, cs_cpu_dbs_info);
>
> +static int cs_cpufreq_governor_dbs(struct cpufreq_policy *policy,
> +unsigned int event);
> +
> +#ifndef CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE
> +static
> +#endif
> +struct cpufreq_governor cpufreq_gov_conservative = {
> + .name = "conservative",
> + .governor = cs_cpufreq_governor_dbs,
> + .max_transition_latency = TRANSITION_LATENCY_LIMIT,
> + .owner = THIS_MODULE,
> +};
> +
> static inline unsigned int get_freq_target(struct cs_dbs_tuners *cs_tuners,
> struct cpufreq_policy *policy)
> {
> @@ -119,12 +132,14 @@ static int dbs_cpufreq_notifier(struct notifier_block
> *nb, unsigned long val,
> struct cpufreq_freqs *freq = data;
> struct cs_cpu_dbs_info_s *dbs_info =
> _cpu(cs_cpu_dbs_info, freq->cpu);
> - struct cpufreq_policy *policy;
> + struct cpufreq_policy *policy = cpufreq_cpu_get(freq->cpu);
>
> - if (!dbs_info->enable)
> + if (!policy)
> return 0;
>
> - policy = dbs_info->cdbs.shared->policy;
So here we could get to the policy directly. After the change we have to:
- acquire cpufreq_rwsem
- acquire cpufreq_driver_lock
- go the kobject_get on policy->kobj
and then finally drop the reference to the kobject when we're done.
So may I ask where exactly is the improvement?
> + /* policy isn't governed by conservative governor */
> + if (policy->governor != _gov_conservative)
> + goto policy_put;
>
> /*
>* we only care if our internally tracked freq moves outside the 'valid'
Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] of_pci_irq: Silence bogus "of_irq_parse_pci() failed ..." messages.
On 9/6/2015 8:50 PM, Frank Rowand wrote:
> On 9/6/2015 7:16 PM, Frank Rowand wrote:
>> On 9/6/2015 1:46 PM, Rob Herring wrote:
>>> On Fri, Sep 4, 2015 at 8:14 PM, Frank Rowand wrote:
On 9/4/2015 12:12 PM, David Daney wrote:
> From: David Daney
>
> It is perfectly legitimate for a PCI device to have an
> PCI_INTERRUPT_PIN value of zero. This happens if the device doesn't
> use interrupts, or on PCIe devices, where only MSI/MSI-X are
> supported.
>
> Silence the annoying "of_irq_parse_pci() failed with rc=-19" error
> messages by making them conditional on !-ENODEV (which can only be
> produced in the PCI_INTERRUPT_PIN == 0 case).
>
> Signed-off-by: David Daney
> ---
> drivers/of/of_pci_irq.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/of/of_pci_irq.c b/drivers/of/of_pci_irq.c
> index 1710d9d..33d242a 100644
> --- a/drivers/of/of_pci_irq.c
> +++ b/drivers/of/of_pci_irq.c
> @@ -106,7 +106,9 @@ int of_irq_parse_and_map_pci(const struct pci_dev
> *dev, u8 slot, u8 pin)
>
> ret = of_irq_parse_pci(dev, );
> if (ret) {
> - dev_err(>dev, "of_irq_parse_pci() failed with
> rc=%d\n", ret);
> + if (ret != -ENODEV)
> + dev_err(>dev,
> + "of_irq_parse_pci() failed with rc=%d\n",
> ret);
> return 0; /* Proper return code 0 == NO_IRQ */
> }
>
>
It is not safe to assume that the functions that of_irq_parse_pci() calls
will never be modified to return -ENODEV, thus resulting in
of_irq_parse_pci()
returning -ENODEV for a reason other than PCI_INTERRUPT_PIN == 0.
>>>
>>> Yes, but we're talking about a print statement.
>>>
A more robust solution would be something like:
>>
>> < snip my bad solution >
>>
I'm not sure I like my solution, there might be a better way.
>>>
>>> I don't like it. That's way too complex for just silencing an
>>> erroneous error message.
>>>
>>> Perhaps just move the error message into of_irq_parse_pci and then you
>>> can control the print more easily. Or just change to dev_dbg would be
>>> okay by me.
>>
>> I knew I was making it way too hard. Yes, just move the error message
>> to of_irq_parse_pci(), where the "/* No pin, exit */" test occurs.
>
> And this time I replied too quickly, not really thinking through my comment.
> There are several error return points in of_irq_parse_pci(), so moving the
> error message into of_irq_parse_pci() is not the answer.
is not the answer unless
of_irq_parse_pci()
is changed over to the single point of return style.
I realized I should have typed the whole thought...
-Frank
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the drm-misc tree
Hi all,
On Thu, 3 Sep 2015 10:49:19 +1000 Stephen Rothwell
wrote:
>
> After merging the drm-misc tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c: In function
> 'mdp5_plane_cleanup_fb':
> drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c:272:26: error: 'fb' redeclared as
> different kind of symbol
> struct drm_framebuffer *fb = old_state->fb;
> ^
> drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c:267:27: note: previous definition
> of 'fb' was here
>struct drm_framebuffer *fb,
>^
> drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c: At top level:
> drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c:383:3: warning: initialization from
> incompatible pointer type
>.cleanup_fb = mdp5_plane_cleanup_fb,
>^
> drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c:383:3: warning: (near
> initialization for 'mdp5_plane_helper_funcs.cleanup_fb')
>
> Caused by commit
>
> a317290af0db ("drm/atomic: Make prepare_fb/cleanup_fb only take state, v3")
>
> Well, that was clearly never build tested :-(
>
> I have used the drm-misc tree from next-20150902 for today.
This is still in today's linux-next :-(
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the akpm-current tree with the tip tree
Hi Linus, On Wed, 29 Jul 2015 19:12:56 +0200 Andrea Arcangeli wrote: > > On Tue, Jul 28, 2015 at 04:00:15PM +1000, Stephen Rothwell wrote: > > -359 i386userfaultfd sys_userfaultfd > > ++374 i386userfaultfd sys_userfaultfd > > Do I understand correctly the syscall number of userfaultfd for x86 > 32bit has just changed from 359 to 374? Appreciated that you CCed me > on such a relevant change to be sure I didn't miss it. > > Then the below is needed as well. The below patch was missed when the userfaultfd stuff and the x86 changes were merged. I have repeated the patch in the clear below. From: Andrea Arcangeli Date: Wed, 29 Jul 2015 18:53:17 +0200 Subject: [PATCH] userfaultfd: selftest: update userfaultfd x86 32bit syscall number It changed as result of linux-next merge of other syscalls. Signed-off-by: Andrea Arcangeli --- tools/testing/selftests/vm/userfaultfd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/vm/userfaultfd.c b/tools/testing/selftests/vm/userfaultfd.c index 0c0b839..76071b1 100644 --- a/tools/testing/selftests/vm/userfaultfd.c +++ b/tools/testing/selftests/vm/userfaultfd.c @@ -69,7 +69,7 @@ #ifdef __x86_64__ #define __NR_userfaultfd 323 #elif defined(__i386__) -#define __NR_userfaultfd 359 +#define __NR_userfaultfd 374 #elif defined(__powewrpc__) #define __NR_userfaultfd 364 #else -- Cheers, Stephen Rothwells...@canb.auug.org.au -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the v4l-dvb tree with Linus' tree
Hi Mauro,
Today's linux-next merge of the v4l-dvb tree got a conflict in:
mm/Makefile
between commit:
c1a4de99fada ("userfaultfd: mcopy_atomic|mfill_zeropage:
UFFDIO_COPY|UFFDIO_ZEROPAGE preparation")
from Linus' tree and commit:
8025e5ddf9c1 ("[media] mm: Provide new get_vaddr_frames() helper")
from the v4l-dvb tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc mm/Makefile
index b424d5e5b6ff,be5d5c866305..
--- a/mm/Makefile
+++ b/mm/Makefile
@@@ -78,4 -78,4 +78,5 @@@ obj-$(CONFIG_CMA) += cma.
obj-$(CONFIG_MEMORY_BALLOON) += balloon_compaction.o
obj-$(CONFIG_PAGE_EXTENSION) += page_ext.o
obj-$(CONFIG_CMA_DEBUGFS) += cma_debug.o
+obj-$(CONFIG_USERFAULTFD) += userfaultfd.o
+ obj-$(CONFIG_FRAME_VECTOR) += frame_vector.o
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 1/9] cpufreq: Use __func__ to print function's name
On Monday, July 27, 2015 05:58:06 PM Viresh Kumar wrote:
> Its better to use __func__ to print functions name instead of writing
> the name in the print statement. This also has the advantage that a
> change in function's name doesn't force us to change the print message
> as well.
>
> Reviewed-by: Preeti U Murthy
> Signed-off-by: Viresh Kumar
OK, this is simple enough. Applied, thanks!
> ---
> drivers/cpufreq/cpufreq.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 46251e8d30f2..f620055279f3 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -2074,8 +2074,7 @@ static int __cpufreq_governor(struct cpufreq_policy
> *policy,
> if (!try_module_get(policy->governor->owner))
> return -EINVAL;
>
> - pr_debug("__cpufreq_governor for CPU %u, event %u\n",
> - policy->cpu, event);
> + pr_debug("%s: for CPU %u, event %u\n", __func__, policy->cpu, event);
>
> mutex_lock(_governor_lock);
> if ((policy->governor_enabled && event == CPUFREQ_GOV_START)
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the parisc-hd tree with Linus' tree
Hi all,
Today's linux-next merge of the parisc-hd tree got a conflict in:
arch/parisc/kernel/irq.c
between commit:
d2109a12198e ("parisc/irq: Use access helper irq_data_get_affinity_mask()")
from Linus' tree and commit:
b15e2f939727 ("parisc: Filter out spurious interrupts in PA-RISC irq handler")
from the parisc-hd tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/parisc/kernel/irq.c
index 413ec3c3f9cc,c0eab24f6a9e..
--- a/arch/parisc/kernel/irq.c
+++ b/arch/parisc/kernel/irq.c
@@@ -507,8 -507,8 +507,8 @@@ void do_cpu_irq_mask(struct pt_regs *re
struct pt_regs *old_regs;
unsigned long eirr_val;
int irq, cpu = smp_processor_id();
- #ifdef CONFIG_SMP
- struct irq_desc *desc;
+ struct irq_data *irq_data;
+ #ifdef CONFIG_SMP
cpumask_t dest;
#endif
@@@ -521,10 -521,14 +521,14 @@@
goto set_out;
irq = eirr_to_irq(eirr_val);
- #ifdef CONFIG_SMP
+ irq_data = irq_get_irq_data(irq);
+ /* Filter out spurious interrupts, mostly from serial port at bootup */
- desc = irq_to_desc(irq);
- if (unlikely(!desc->action))
++ if (unlikely(!irq_data))
+ goto set_out;
+
+ #ifdef CONFIG_SMP
- cpumask_copy(, desc->irq_data.affinity);
- if (irqd_is_per_cpu(>irq_data) &&
+ cpumask_copy(, irq_data_get_affinity_mask(irq_data));
+ if (irqd_is_per_cpu(irq_data) &&
!cpumask_test_cpu(smp_processor_id(), )) {
int cpu = cpumask_first();
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH v2] Fix: clocksource watchdog marks TSC unstable on guest VM
I have been getting those warnings across a range of guest
kernels in my development virtual machines. The host is a
3.13 Ubuntu kernel. The latest guest on which I reproduced
this is a 4.2 kernel (akpm's tree).
[ 126.902240] clocksource: timekeeping watchdog: Marking clocksource 'tsc' as
unstable because the skew is too large:
[ 126.902240] clocksource: 'hpet' wd_now: f948c267
wd_last: f5edb97c mask:
[ 126.967563] clocksource: 'tsc' cs_now: 48f04ee060
cs_last: 48a8c73ed0 mask:
Relevant info from the guest kernel dmesg:
[2.197070] HPET: 3 timers in total, 0 timers will be used for per-cpu timer
[2.198021] hpet0: at MMIO 0xfed0, IRQs 2, 8, 0
[2.199557] hpet0: 3 comparators, 64-bit 100.00 MHz counter
[3.393185] tsc: Refined TSC clocksource calibration: 2400.037 MHz
[3.396552] clocksource: tsc: mask: 0x max_cycles:
0x22985a87e67, max_idle_ns: 440795315743 ns
It appears that the clocksource watchdog does:
local_irq_disable();
csnow = cs->read(cs);
wdnow = watchdog->read(watchdog);
local_irq_enable();
If the host kernel preempts the guest between reading the
TSC and the watchdog, the resulting delta may go well over
the watchdog threshold, which is currently 62ms.
Correct this issue by reading "wdnow" before and after reading
TSC, and retry if the delta between the two reads exceeds
WATCHDOG_THRESHOLD.
Introduce WATCHDOG_RETRY to bound the number of retry (in the
unlikely event of a bogus clock source for wdnow). If the
number of retry has been reached, bail out.
Signed-off-by: Mathieu Desnoyers
CC: Daniel Lezcano
CC: Thomas Gleixner
--
Changes since v1:
- Add missing \n at the end of pr_warn().
---
kernel/time/clocksource.c | 190 +++---
1 file changed, 111 insertions(+), 79 deletions(-)
diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c
index 174c594..224d7a8 100644
--- a/kernel/time/clocksource.c
+++ b/kernel/time/clocksource.c
@@ -126,6 +126,11 @@ static void __clocksource_change_rating(struct clocksource
*cs, int rating);
*/
#define WATCHDOG_INTERVAL (HZ >> 1)
#define WATCHDOG_THRESHOLD (NSEC_PER_SEC >> 4)
+/*
+ * When two back-to-back reads of the watchdog clock are too far
+ * apart, limit the number of retry allowed before we bail out.
+ */
+#define WATCHDOG_RETRY 20
static void clocksource_watchdog_work(struct work_struct *work)
{
@@ -166,97 +171,124 @@ void clocksource_mark_unstable(struct clocksource *cs)
spin_unlock_irqrestore(_lock, flags);
}
-static void clocksource_watchdog(unsigned long data)
+static void check_cs_wd(struct clocksource *cs)
{
- struct clocksource *cs;
- cycle_t csnow, wdnow, cslast, wdlast, delta;
- int64_t wd_nsec, cs_nsec;
- int next_cpu, reset_pending;
-
- spin_lock(_lock);
- if (!watchdog_running)
- goto out;
-
- reset_pending = atomic_read(_reset_pending);
+ cycle_t csnow, wdnow[2], cslast, wdlast, delta;
+ int64_t wd_nsec[2], cs_nsec;
+ int retry_count = WATCHDOG_RETRY;
+
+restart:
+ /* Clocksource already marked unstable? */
+ if (cs->flags & CLOCK_SOURCE_UNSTABLE) {
+ if (finished_booting)
+ schedule_work(_work);
+ return;
+ }
- list_for_each_entry(cs, _list, wd_list) {
+ local_irq_disable();
+ wdnow[0] = watchdog->read(watchdog);
+ csnow = cs->read(cs);
+ wdnow[1] = watchdog->read(watchdog);
+ local_irq_enable();
+
+ /* Clocksource initialized ? */
+ if (!(cs->flags & CLOCK_SOURCE_WATCHDOG) ||
+ atomic_read(_reset_pending)) {
+ cs->flags |= CLOCK_SOURCE_WATCHDOG;
+ cs->wd_last = wdnow[1];
+ cs->cs_last = csnow;
+ return;
+ }
- /* Clocksource already marked unstable? */
- if (cs->flags & CLOCK_SOURCE_UNSTABLE) {
- if (finished_booting)
- schedule_work(_work);
- continue;
- }
+ delta = clocksource_delta(wdnow[0], cs->wd_last, watchdog->mask);
+ wd_nsec[0] = clocksource_cyc2ns(delta, watchdog->mult,
+watchdog->shift);
+ delta = clocksource_delta(wdnow[1], cs->wd_last, watchdog->mask);
+ wd_nsec[1] = clocksource_cyc2ns(delta, watchdog->mult,
+watchdog->shift);
- local_irq_disable();
- csnow = cs->read(cs);
- wdnow = watchdog->read(watchdog);
- local_irq_enable();
-
- /* Clocksource initialized ? */
- if (!(cs->flags & CLOCK_SOURCE_WATCHDOG) ||
- atomic_read(_reset_pending)) {
- cs->flags |= CLOCK_SOURCE_WATCHDOG;
-
[PATCH] staging: lustre: ptlrpc: include ptlrpc_internal.h
Remove sparse warning "symbol 'sptlrpc_plain_init' was not declared"
by including ptlrpc_internal.h, which includes sptlrpc_plain_init.
Signed-off-by: Anders Fridlund
---
drivers/staging/lustre/lustre/ptlrpc/sec_plain.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/lustre/lustre/ptlrpc/sec_plain.c
b/drivers/staging/lustre/lustre/ptlrpc/sec_plain.c
index a243db6..d905b77 100644
--- a/drivers/staging/lustre/lustre/ptlrpc/sec_plain.c
+++ b/drivers/staging/lustre/lustre/ptlrpc/sec_plain.c
@@ -46,6 +46,7 @@
#include "../include/obd_class.h"
#include "../include/lustre_net.h"
#include "../include/lustre_sec.h"
+#include "ptlrpc_internal.h"
struct plain_sec {
struct ptlrpc_sec pls_base;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3] Documentation: add Device tree bindings for hwmon/nct7802
Add add Device tree bindings for registers
which are not covered by hwmon ABI and are required to
configure specific HW.
---
Changed in v3:
- Fixed vendor prefix
- Added short registers description,
full registers description is available at
https://www.nuvoton.com/hq/products/cloud-computing/hardware-monitors/desktop-server-series/nct7802y/
Changed in v2:
- Removed nct7802,reg-init
- Added registers initialization by names
Introduced in v1:
- nct7802,reg-init
Signed-off-by: Constantine Shulyupin
---
.../devicetree/bindings/hwmon/nct7802.txt | 28 ++
1 file changed, 28 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/nct7802.txt
diff --git a/Documentation/devicetree/bindings/hwmon/nct7802.txt
b/Documentation/devicetree/bindings/hwmon/nct7802.txt
new file mode 100644
index 000..5b4c3fe
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/nct7802.txt
@@ -0,0 +1,28 @@
+Nuvoton NCT7802Y Hardware Monitoring IC
+
+Required node properties:
+
+ - "compatible": must be "nuvoton,nct7802"
+ - "reg": I2C bus address of the device
+
+Optional properties:
+
+One byte registers:
+ - nuvoton,start - Start register at index 0x21
+ - nuvoton,mode - Mode register at index 0x22
+ - nuvoton,en_peci - PECI enable register at index 0x23
+ - nuvoton,en_fan - Fan Enable Register at index 0x24
+ - nuvoton,en_v - voltage monitor enable register
+ at index 0x25
+
+A detailed datasheet for registers and the device is
+available at Nuvoton web site.
+
+Example nct7802 node:
+
+nct7802 {
+ compatible = "nuvoton,nct7802";
+ reg = <0x2a>;
+ nuvoton,start = <0x01>;
+ nuvoton,mode = <0x7E>; // RTD1_MD = 2
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Use (two) different compilers at build-time?
On Mon, Sep 7, 2015 at 11:20 PM, Sedat Dilek wrote: > On Mon, Sep 7, 2015 at 10:59 PM, Linus Torvalds > wrote: >> On Mon, Sep 7, 2015 at 1:53 PM, Sedat Dilek wrote: >>> >>> That does not work. >> >> .. because you didn't do what I told you to do. >> >>> I copied a gcc-compiled percpu.o OR deleted/renamed percpu.o and >>> re-invoked make - this starts a complete new build from scratch. >> >> Right. Because you changed the compiler name, so now the build system >> realizes that the old build instructions are stale. >> >> Which is why you have to: >> Use a wrapper around the compiler (and point to that wrapper with the "to switch compilers from under the make, without the build paths changing (because otherwise our makefile auto-machinery notices that flags and command changed). Use CC (or CROSS_COMPILE) to point at your wrapper. >>> >>> No idea how to realize that, sorry. >> >> Literally just do something like this: >> >> - have a shell script call "mycompiler" and make it do gcc/llvm "$@". >> >> - or even just use a symlink (the script has the advantage that you >> can play with the options etc too) >> >> - change the shell script (or symlink) itself, and make sure to use >> the same CC for "make" at all times, so that the build script never >> sees that the underlying command is now different. >> >> It should work fine, I've done it a couple of times (although >> admittedly not recently) >> > > OK, I have created a mycompiler shell-script and use that for CC and > HOSTCC in my own build-script. > > Using CLANG... > > [ /usr/bin/mycompiler ] > > #!/bin/bash > > clang "$@" > - EOF - > > $ mycompiler --version > clang version 3.7.0 (tags/RELEASE_370/final) > Target: x86_64-unknown-linux-gnu > Thread model: posix > > Switching to GCC... > > [ /usr/bin/mycompiler ] > > #!/bin/bash > > gcc-4.9 "$@" > - EOF - > > $ mycompiler --version > gcc-4.9 (Ubuntu 4.9.2-0ubuntu1~12.04) 4.9.2 > Copyright (C) 2014 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > Thanks, that helped me a lot. > Sadly, this trick does not work here with Linux v4.2. - Sedat - -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH] Fix: clocksource watchdog marks TSC unstable on guest VM
I have been getting those warnings across a range of guest
kernels in my development virtual machines. The host is a
3.13 Ubuntu kernel. The latest guest on which I reproduced
this is a 4.2 kernel (akpm's tree).
[ 126.902240] clocksource: timekeeping watchdog: Marking clocksource 'tsc' as
unstable because the skew is too large:
[ 126.902240] clocksource: 'hpet' wd_now: f948c267
wd_last: f5edb97c mask:
[ 126.967563] clocksource: 'tsc' cs_now: 48f04ee060
cs_last: 48a8c73ed0 mask:
Relevant info from the guest kernel dmesg:
[2.197070] HPET: 3 timers in total, 0 timers will be used for per-cpu timer
[2.198021] hpet0: at MMIO 0xfed0, IRQs 2, 8, 0
[2.199557] hpet0: 3 comparators, 64-bit 100.00 MHz counter
[3.393185] tsc: Refined TSC clocksource calibration: 2400.037 MHz
[3.396552] clocksource: tsc: mask: 0x max_cycles:
0x22985a87e67, max_idle_ns: 440795315743 ns
It appears that the clocksource watchdog does:
local_irq_disable();
csnow = cs->read(cs);
wdnow = watchdog->read(watchdog);
local_irq_enable();
If the host kernel preempts the guest between reading the
TSC and the watchdog, the resulting delta may go well over
the watchdog threshold, which is currently 62ms.
Correct this issue by reading "wdnow" before and after reading
TSC, and retry if the delta between the two reads exceeds
WATCHDOG_THRESHOLD.
Introduce WATCHDOG_RETRY to bound the number of retry (in the
unlikely event of a bogus clock source for wdnow). If the
number of retry has been reached, bail out.
Signed-off-by: Mathieu Desnoyers
CC: Daniel Lezcano
CC: Thomas Gleixner
---
kernel/time/clocksource.c | 190 +++---
1 file changed, 111 insertions(+), 79 deletions(-)
diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c
index 174c594..caca552 100644
--- a/kernel/time/clocksource.c
+++ b/kernel/time/clocksource.c
@@ -126,6 +126,11 @@ static void __clocksource_change_rating(struct clocksource
*cs, int rating);
*/
#define WATCHDOG_INTERVAL (HZ >> 1)
#define WATCHDOG_THRESHOLD (NSEC_PER_SEC >> 4)
+/*
+ * When two back-to-back reads of the watchdog clock are too far
+ * apart, limit the number of retry allowed before we bail out.
+ */
+#define WATCHDOG_RETRY 20
static void clocksource_watchdog_work(struct work_struct *work)
{
@@ -166,97 +171,124 @@ void clocksource_mark_unstable(struct clocksource *cs)
spin_unlock_irqrestore(_lock, flags);
}
-static void clocksource_watchdog(unsigned long data)
+static void check_cs_wd(struct clocksource *cs)
{
- struct clocksource *cs;
- cycle_t csnow, wdnow, cslast, wdlast, delta;
- int64_t wd_nsec, cs_nsec;
- int next_cpu, reset_pending;
-
- spin_lock(_lock);
- if (!watchdog_running)
- goto out;
-
- reset_pending = atomic_read(_reset_pending);
+ cycle_t csnow, wdnow[2], cslast, wdlast, delta;
+ int64_t wd_nsec[2], cs_nsec;
+ int retry_count = WATCHDOG_RETRY;
+
+restart:
+ /* Clocksource already marked unstable? */
+ if (cs->flags & CLOCK_SOURCE_UNSTABLE) {
+ if (finished_booting)
+ schedule_work(_work);
+ return;
+ }
- list_for_each_entry(cs, _list, wd_list) {
+ local_irq_disable();
+ wdnow[0] = watchdog->read(watchdog);
+ csnow = cs->read(cs);
+ wdnow[1] = watchdog->read(watchdog);
+ local_irq_enable();
+
+ /* Clocksource initialized ? */
+ if (!(cs->flags & CLOCK_SOURCE_WATCHDOG) ||
+ atomic_read(_reset_pending)) {
+ cs->flags |= CLOCK_SOURCE_WATCHDOG;
+ cs->wd_last = wdnow[1];
+ cs->cs_last = csnow;
+ return;
+ }
- /* Clocksource already marked unstable? */
- if (cs->flags & CLOCK_SOURCE_UNSTABLE) {
- if (finished_booting)
- schedule_work(_work);
- continue;
- }
+ delta = clocksource_delta(wdnow[0], cs->wd_last, watchdog->mask);
+ wd_nsec[0] = clocksource_cyc2ns(delta, watchdog->mult,
+watchdog->shift);
+ delta = clocksource_delta(wdnow[1], cs->wd_last, watchdog->mask);
+ wd_nsec[1] = clocksource_cyc2ns(delta, watchdog->mult,
+watchdog->shift);
- local_irq_disable();
- csnow = cs->read(cs);
- wdnow = watchdog->read(watchdog);
- local_irq_enable();
-
- /* Clocksource initialized ? */
- if (!(cs->flags & CLOCK_SOURCE_WATCHDOG) ||
- atomic_read(_reset_pending)) {
- cs->flags |= CLOCK_SOURCE_WATCHDOG;
- cs->wd_last = wdnow;
- cs->cs_last = csnow;
Re: Dealing with the NMI mess
On Mon, Sep 7, 2015 at 12:30 PM, Maciej W. Rozycki wrote: > On Mon, 7 Sep 2015, Andy Lutomirski wrote: > >> > These are all implementation-specific details, including the INT1 >> > instruction, which is why I am not at all surprised that they are omitted >> > from architecture manuals. >> >> That bit is BS, though. The INT1 instruction, executed in user mode >> (CPL3) with no hardware debugger attached, will enter the kernel >> through a gate at vector 1, *even if that gate has DPL == 0*. >> >> If there's an instruction that bypasses hardware protection >> mechanisms, then Intel should document it rather than relying on OS >> writers to know enough folklore to get it right. >> >> Heck, SDM Volume 3 6.12.1.1 says "The processor checks the DPL of the >> interrupt or trap gate only if an exception or interrupt is generated >> with an INT n, INT 3, or INTO instruction." It does not say "the >> processor does not check the DPL of the interrupt or trap gate if the >> exception or interrupt is generated with the undocumented ICEBP >> instruction." > > It does not have to be mentioned, because it's implied by how the #DB > exception is propagated: regardless of its origin it never checks the DPL. > And user-mode software may well use POPF at any time to set the TF bit in > the flags register to the same effect, so the OS needs to be prepared for > a #DB exception it hasn't scheduled itself anyway. Not really. int $1 checks DPL. Setting TF results in saved TF set and the corresponding bit in DR6 set as well. Triggering a #DB using the debug registers requires active OS help. So operating systems need to handle a #DB without no indicated cause without spewing warnings or crashing, and there is no indication whatsoever in the SDM or APM that this is the case. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: exynos_defconfig: Enable USB Video Class support
The Exynos5420 Peach Pit and Exynos5800 Peach Pi boards have a built-in Silicon Motion USB UVC WebCam. Enable support for the USB Video Class driver and its needed media Kconfig symbols so the camera is supported. Signed-off-by: Javier Martinez Canillas --- arch/arm/configs/exynos_defconfig | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig index 1ff2bfa2e183..62f677f76a0b 100644 --- a/arch/arm/configs/exynos_defconfig +++ b/arch/arm/configs/exynos_defconfig @@ -126,6 +126,10 @@ CONFIG_REGULATOR_S2MPA01=y CONFIG_REGULATOR_S2MPS11=y CONFIG_REGULATOR_S5M8767=y CONFIG_REGULATOR_TPS65090=y +CONFIG_MEDIA_SUPPORT=y +CONFIG_MEDIA_CAMERA_SUPPORT=y +CONFIG_MEDIA_USB_SUPPORT=y +CONFIG_USB_VIDEO_CLASS=y CONFIG_DRM=y CONFIG_DRM_NXP_PTN3460=y CONFIG_DRM_PARADE_PS8622=y -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Energy Aware Scheduling and Power Management LPC microconference summary
Hi All, After the Energy Aware Scheduling and Power Management microconference at the LPC I and Morten prepared a summary of it for the LPC readout session. There was not enough time to present the whole of it, though, so I promised to send it out, but then got distracted by urgent stuff and only got back to it today. It still is relevant in my view, so here it goes. In addition to the below, the most important takeaway from the EAS+PM microconference for both me and Morten was likely that more meetings like that would be good to have, so we're considering organizing a PM Summit next year. One of the candidate time frames is along with the ELC in April. The other is at the Kernel Summit in October/November. Please let me know what you think. Thanks, Rafael --- Thursday Modern systems tend to be more and more hierarchical in nature (power domains etc.), but the existing CPU PM frameworks have problems with taking that into account. There are attempts to address this issue. For example, the new version 6 of ACPI provides a way to describe hierarchies of CPU idle states that in principle can be used for this purpose, but how to use that information in the kernel is under discussion. More discussion to happen. There is a proposal from Linaro to extend the existing device PM framework to cover CPU hierarchies that has been presented during the session. Everybody acknowledged the problem and that it should be addressed and the proposed approach does not appear to be objectionable (at the high level). Patches are in the works at an RFC stage, to be worked on going forward. The requisite topology information need to come from somewhere like ACPI or a Device Tree. A proposal of new DT bindings for this purpose has been presented and discussed. There were no major objections against it, but more discussion is needed. Also discussed was the problem of identifying possible wakeup sources for system sleep states (suspend-to-RAM). The kernel needs to know which devices can wake up the system from sleep so as to allow user space to configure them accordingly. That information has to be provided in some way and if it cannot be retrieved from devices themselves, the firmware has to provide it. There is no good way to do it in DT, more discussion is needed. Platforms handle wakeup interrupts inconsistently and that needs to be carified and unified. Work in progress. Firday The energy aware scheduling is a way to combine the decisions made by the CPU scheduler and CPU PM governors (cpufreq, cpuidle) to achieve consistency and ultimately to bring it an energy model to guide those decisions. There is a patchset implementing the idea in the works for some time, a few bits from it have already been merged (per-task utilization tracking and frequency invariant utilization tracking). The energy aware scheduling patchset was discussed. There is general agreement on the approach. The patchset needs to be split into smaller bits easier to handle. Those will be merged when they mature. Related to that is a scheduler-driven frequency scaling propsal. The idea is for the scheduler to play the role of a CPU frequency governor, possibly taking the EAS bits into account. Gaps have been indentified in the cpufreq framework that need to be closed to make it play nicer with the scheduler (locking, cpufreq-provided topology information needs to agree with scheduling groups, an iterface to change frequency asynchronously). Those gaps will be worked on going forward. There was a discussion about possibly synchronizing the management of performance states accross different system components (eg. GPUs and CPUs). More discussion is needed. Some system use hardware-based peformance control. The way it works on recent Intel systems has been presented and discussed. It is not really clear how much those systems can benefit from the EAS-based approach and in what way. More discussion to happen. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] stmmac: fix check for phydev being open
Hi Sergei, On Tue, 2015-09-08 at 00:24 +0300, Sergei Shtylyov wrote: > On 09/07/2015 11:50 PM, Alexey Brodkin wrote: > > > Current implementation via IS_ERR(phydev) may make no sense because > > of_phy_attach() returns NULL on failure instead of error value. > > Not of_phy_connect()? I already noticed this misspelling - it came from my exploration of what happens inside of_phy_connect(). So sort of braindump. I will fix in v3 re-spin. -Alexey-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] stmmac: fix check for phydev being open
On 09/07/2015 11:50 PM, Alexey Brodkin wrote: Current implementation via IS_ERR(phydev) may make no sense because of_phy_attach() returns NULL on failure instead of error value. Not of_phy_connect()? Still for checking result of phy_connect() IS_ERR() is useful. To address both situations we use combined IS_ERR_OR_NULL() check. Cc: Giuseppe Cavallaro Cc: linux-kernel@vger.kernel.org Cc: sta...@vger.kernel.org Cc: David Miller Cc: Sergei Shtylyov Signed-off-by: Alexey Brodkin MBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Use (two) different compilers at build-time?
On Mon, Sep 7, 2015 at 10:59 PM, Linus Torvalds wrote: > On Mon, Sep 7, 2015 at 1:53 PM, Sedat Dilek wrote: >> >> That does not work. > > .. because you didn't do what I told you to do. > >> I copied a gcc-compiled percpu.o OR deleted/renamed percpu.o and >> re-invoked make - this starts a complete new build from scratch. > > Right. Because you changed the compiler name, so now the build system > realizes that the old build instructions are stale. > > Which is why you have to: > >>> Use a wrapper around the compiler (and point to that wrapper with the >>> "to switch compilers from under the make, without the build paths >>> changing (because otherwise our makefile auto-machinery notices that >>> flags and command changed). >>> >>> Use CC (or CROSS_COMPILE) to point at your wrapper. >> >> No idea how to realize that, sorry. > > Literally just do something like this: > > - have a shell script call "mycompiler" and make it do gcc/llvm "$@". > > - or even just use a symlink (the script has the advantage that you > can play with the options etc too) > > - change the shell script (or symlink) itself, and make sure to use > the same CC for "make" at all times, so that the build script never > sees that the underlying command is now different. > > It should work fine, I've done it a couple of times (although > admittedly not recently) > OK, I have created a mycompiler shell-script and use that for CC and HOSTCC in my own build-script. Using CLANG... [ /usr/bin/mycompiler ] #!/bin/bash clang "$@" - EOF - $ mycompiler --version clang version 3.7.0 (tags/RELEASE_370/final) Target: x86_64-unknown-linux-gnu Thread model: posix Switching to GCC... [ /usr/bin/mycompiler ] #!/bin/bash gcc-4.9 "$@" - EOF - $ mycompiler --version gcc-4.9 (Ubuntu 4.9.2-0ubuntu1~12.04) 4.9.2 Copyright (C) 2014 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Thanks, that helped me a lot. - Sedat - -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][rfc] intel_pstate: Fix user input of min/max to legal policy region
On Wednesday, August 12, 2015 11:49:19 AM Chen Yu wrote: > In current code, if system is using performance policy, user can > modify the max_perf_pct to any values lower than 100: > > $ grep . /sys/devices/system/cpu/intel_pstate/m*_perf_pct > /sys/devices/system/cpu/intel_pstate/max_perf_pct:100 > /sys/devices/system/cpu/intel_pstate/min_perf_pct:100 > > $ echo 80 > /sys/devices/system/cpu/intel_pstate/max_perf_pct > > $ grep . /sys/devices/system/cpu/intel_pstate/m*_perf_pct > /sys/devices/system/cpu/intel_pstate/max_perf_pct:80 > /sys/devices/system/cpu/intel_pstate/min_perf_pct:100 > > the max_perf_pct above is lower than min_perf_pct, which > is not reasonable. > > This patch solves this problem by clamping min_perf_pct and max_perf_pct > to be strictly inside [min_policy_pct,max_policy_pct]. > > Signed-off-by: Chen Yu Looks reasonable to me. Kristen, any objections? > --- > drivers/cpufreq/intel_pstate.c | 10 +++--- > 1 file changed, 7 insertions(+), 3 deletions(-) > > diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c > index fcb929e..3702c5a 100644 > --- a/drivers/cpufreq/intel_pstate.c > +++ b/drivers/cpufreq/intel_pstate.c > @@ -423,6 +423,7 @@ static ssize_t store_max_perf_pct(struct kobject *a, > struct attribute *b, > > limits.max_sysfs_pct = clamp_t(int, input, 0 , 100); > limits.max_perf_pct = min(limits.max_policy_pct, limits.max_sysfs_pct); > + limits.max_perf_pct = max(limits.min_policy_pct, limits.max_perf_pct); > limits.max_perf = div_fp(int_tofp(limits.max_perf_pct), int_tofp(100)); > > if (hwp_active) > @@ -442,6 +443,7 @@ static ssize_t store_min_perf_pct(struct kobject *a, > struct attribute *b, > > limits.min_sysfs_pct = clamp_t(int, input, 0 , 100); > limits.min_perf_pct = max(limits.min_policy_pct, limits.min_sysfs_pct); > + limits.min_perf_pct = min(limits.max_policy_pct, limits.min_perf_pct); > limits.min_perf = div_fp(int_tofp(limits.min_perf_pct), int_tofp(100)); > > if (hwp_active) > @@ -985,12 +987,14 @@ static int intel_pstate_set_policy(struct > cpufreq_policy *policy) > > limits.min_policy_pct = (policy->min * 100) / policy->cpuinfo.max_freq; > limits.min_policy_pct = clamp_t(int, limits.min_policy_pct, 0 , 100); > - limits.min_perf_pct = max(limits.min_policy_pct, limits.min_sysfs_pct); > - limits.min_perf = div_fp(int_tofp(limits.min_perf_pct), int_tofp(100)); > - > limits.max_policy_pct = (policy->max * 100) / policy->cpuinfo.max_freq; > limits.max_policy_pct = clamp_t(int, limits.max_policy_pct, 0 , 100); > + > + limits.min_perf_pct = max(limits.min_policy_pct, limits.min_sysfs_pct); > + limits.min_perf_pct = min(limits.max_policy_pct, limits.min_perf_pct); > + limits.min_perf = div_fp(int_tofp(limits.min_perf_pct), int_tofp(100)); > limits.max_perf_pct = min(limits.max_policy_pct, limits.max_sysfs_pct); > + limits.max_perf_pct = max(limits.min_policy_pct, limits.max_perf_pct); > limits.max_perf = div_fp(int_tofp(limits.max_perf_pct), int_tofp(100)); > > if (hwp_active) > -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v0 2/9] suspend: Add getter function to report if freezing is active
On Monday, September 07, 2015 10:55:43 AM Daniel Wagner wrote:
> On 09/05/2015 04:11 AM, Rafael J. Wysocki wrote:
> > On Friday, September 04, 2015 03:34:55 PM Daniel Wagner wrote:
> >> Instead encode the FREEZE state via the CPU state we allow the
> >> interesting subsystems (MCE, microcode) to query the power
> >> subsystem directly.
> >
> > A use case, please.
>
> The motivation for this change is to reduce the complexity in the
> hotplug code. As tried to point out in the cover letter, the FROZEN
> bits have only a bunch of users after all those years (2007). So it is
> worth to have all the notifier users to handle the FROZEN state?
>
> Don't know if that counts as use case.
Well, the code you're changing has nothing to do with CPU hotplug and
CPU_TASKS_FROZEN. It is about suspend-to-idle.
Please grep for suspend_freeze_state and see what it is used for.
There is some confusion in the naming, but that is about the freezing of
the whole system, while CPU_TASKS_FROZEN is about the freezing of user space.
> >> Most notifiers are not interested at all
> >> in this information so rather have explicit calls to freeze_active()
> >> instead adding complexity to the rest of the users of the CPU
> >> notifiers.
> >
> > Why does it has anything to do with CPU notifiers?
>
> cpu_{down|up} will call the notifiers with the CPU_TASK_FROZEN bit set
> and so most notifiers are doing
>
> switch (actcion ~CPU_TASK_FROZEN)
>
> to filter it out because they don't need to handle the system wide
> ongoing freeze operations.
>
> > We don't offline CPUs for suspend-to-idle.
>
> Sure. As I said the motivation is to reduce the complexity in the
> hotplug code.
You need to fine a different way to do that.
Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] stmmac: fix check for phydev being open
Hi Sergei,
On Mon, 2015-09-07 at 23:53 +0300, Sergei Shtylyov wrote:
> On 09/07/2015 11:50 PM, Alexey Brodkin wrote:
>
> > Current implementation via IS_ERR(phydev) may make no sense because
> > of_phy_attach() returns NULL on failure instead of error value.
> >
> > Still for checking result of phy_connect() IS_ERR() is useful.
> >
> > To address both situations we use combined IS_ERR_OR_NULL() check.
> >
> > Cc: Giuseppe Cavallaro
> > Cc: linux-kernel@vger.kernel.org
> > Cc: sta...@vger.kernel.org
> > Cc: David Miller
> > Cc: Sergei Shtylyov
> > Signed-off-by: Alexey Brodkin
> > ---
> >
> > Changes compared to v1:
> > * Use IS_ERR_OR_NULL() instead of discrete checks for null and err
> >
> > drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> > b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> > index 864b476..7985d8a 100644
> > --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> > @@ -837,7 +837,7 @@ static int stmmac_init_phy(struct net_device *dev)
> > interface);
> > }
> >
> > - if (IS_ERR(phydev)) {
> > + if (IS_ERR_OR_NULL(phydev)) {
> > pr_err("%s: Could not attach to PHY\n", dev->name);
> > return PTR_ERR(phydev);
>
> Hm, in case of phydev == NULL, you're going to return 0 here... is that
> what you want?
Ah, right.
So then the question would be what's a proper error code for !phydev:
-ENOENT or -ENODEV?
-Alexey--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Possible deadlock related to CPU hotplug and kernfs
On Monday, September 07, 2015 11:11:19 AM Jiang Liu wrote: > On 2015/9/4 22:16, Rafael J. Wysocki wrote: > > Hi, > > > > On Fri, Sep 4, 2015 at 9:20 AM, Jiang Liu wrote: > >> On 2015/9/4 4:08, Rafael J. Wysocki wrote: > >>> Hi Tejun, > >>> > >>> On Thu, Sep 3, 2015 at 6:19 PM, Tejun Heo wrote: > Hello, Rafael. > > On Thu, Sep 03, 2015 at 02:58:16AM +0200, Rafael J. Wysocki wrote: > > So acpi_device_hotplug() calls lock_device_hotplug() which simply > > acquires device_hotplug_lock. It is held throughout the entire > > hot-add/hot-remove code path. > > > > Witing anything to /sys/devices/system/cpu/cpux/online goes through > > online_store() in drivers/base/core.c and that does > > lock_device_hotplug_sysfs() which then attempts to acquire > > device_hotplug_lock using mutex_trylock(). And it only calls > > either device_online() or device_offline() if it ends up with the > > lock held. > > > > Quite frankly, I don't see how these particular two code paths can > > deadlock in any way. > > > > So either a third code path is involved which is not executed > > under device_hotplug_lock, or lockdep needs to be told to actually > > take device_hotplug_lock into account in this case IMO. > > Hmm... all sysfs rw functions are protected from removal. ie. by > default, removal of a sysfs file drains in-flight rw operations, so > the hot plug path grabs a lock and then tries to remove a file and > writing to the online file makes the file's write method to try to > grab the same lock. It deadlocks if the hotunplug path already has > the lock and trying to drain the online file for removal. > >>> > >>> My point is that you cannot get into that situation. If hotplug > >>> already holds device_hotplug_lock, the write to "online" will end up > >>> doing restart_syscall(). > >>> > >>> If the "online" code path is holding the lock, hotplug cannot acquire > >>> it and cannot proceed. > >>> > >>> Am I missing anything? > >> Hi Rafael, > >> I think your are right. The lock_device_hotplug_sysfs() has > >> already provided a solution for such a deadlock scenario. And there's > >> another related code path at boot as: > >> smp_init() > >> ->cpu_up() > >> ->cpu_hotplug_begin() > >> So it seems to be a false alarm. Any way to teach lockdep > >> about this to get rid of the false alarm? > > > > Well, maybe we could call lock_device_hotplug() from that code path too? > Hi Rafael, > Adding lock_device_hotplug() to smp_init() doesn't solve the > issue. So it seems to be an false alarm of lockdep, and I don't know > how to get rid of such an lockdep false alarm:( Peter, Ingo, some help from lockdep expert is needed. We have a splat that almost certainly is a false positive (the original report is here http://marc.info/?l=linux-kernel=144109156901959=4) and no ideas how to make it go away. Can you please have a look and advise? Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] acpi: Add basic device probing infrastructure
On Friday, September 04, 2015 06:06:48 PM Marc Zyngier wrote: > IRQ controllers and timers are the two types of device the kernel > requires before being able to use the device driver model. > > ACPI so far lacks a proper probing infrastructure similar to the one > we have with DT, where we're able to declare IRQ chips and > clocksources inside the driver code, and let the core code pick it up > and call us back on a match. This leads to all kind of really ugly > hacks all over the arm64 code and even in the ACPI layer. > > In order to allow some basic probing based on the ACPI tables, > introduce "struct acpi_probe_entry" which contains just enough > data and callbacks to match a table, an optional subtable, and > call a probe function. A driver can, at build time, register itself > and expect being called if the right entry exists in the ACPI > table. > > A acpi_probe_device_init() is provided, taking an ACPI table > identifier, and iterating over the registered entries. What about things that are provided by the ACPI namespace (eg. via _MAT) rather than in static tables? Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Use (two) different compilers at build-time?
On Mon, Sep 7, 2015 at 1:53 PM, Sedat Dilek wrote: > > That does not work. .. because you didn't do what I told you to do. > I copied a gcc-compiled percpu.o OR deleted/renamed percpu.o and > re-invoked make - this starts a complete new build from scratch. Right. Because you changed the compiler name, so now the build system realizes that the old build instructions are stale. Which is why you have to: >> Use a wrapper around the compiler (and point to that wrapper with the >> "to switch compilers from under the make, without the build paths >> changing (because otherwise our makefile auto-machinery notices that >> flags and command changed). >> >> Use CC (or CROSS_COMPILE) to point at your wrapper. > > No idea how to realize that, sorry. Literally just do something like this: - have a shell script call "mycompiler" and make it do gcc/llvm "$@". - or even just use a symlink (the script has the advantage that you can play with the options etc too) - change the shell script (or symlink) itself, and make sure to use the same CC for "make" at all times, so that the build script never sees that the underlying command is now different. It should work fine, I've done it a couple of times (although admittedly not recently) Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
