From e2b8ddcc6b3fbb860e15c5d52455735e128326aa Mon Sep 17 00:00:00 2001 From: Lv Zheng Date: Mon, 24 Mar 2014 14:48:45 +0800 Subject: ACPICA: Remove global option to serialize all control methods. According to the reports, the "acpi_serialize" mechanism is broken as: A. The parallel method calls can still happen when the interpreter lock is released under the following conditions: 1. External callbacks are invoked, for example, by the region handlers, the exception handlers, etc.; 2. Module level execution is performed when Load/LoadTable opcodes are executed, and 3. The _REG control methods are invoked to complete the region registrations. B. For the following situations, the interpreter lock need to be released even for a serialized method while currently, the lock-releasing operation is marked as a no-op by acpi_ex_relinquish/reacquire_interpreter() when this mechanism is enabled: 1. Wait opcode is executed, 2. Acquire opcode is executed, and 3. Sleep opcode is executed. This patch removes this mechanism and the internal acpi_ex_relinquish/reacquire_interpreter() APIs. Lv Zheng. References: https://bugzilla.kernel.org/show_bug.cgi?id=52191 Signed-off-by: Lv Zheng Signed-off-by: Bob Moore Signed-off-by: Rafael J. Wysocki --- include/acpi/acpixf.h | 1 - 1 file changed, 1 deletion(-) (limited to 'include') diff --git a/include/acpi/acpixf.h b/include/acpi/acpixf.h index e04f0114283f..a3a8dae1cd61 100644 --- a/include/acpi/acpixf.h +++ b/include/acpi/acpixf.h @@ -71,7 +71,6 @@ extern u32 acpi_dbg_layer; /* ACPICA runtime options */ -extern u8 acpi_gbl_all_methods_serialized; extern u8 acpi_gbl_copy_dsdt_locally; extern u8 acpi_gbl_create_osi_method; extern u8 acpi_gbl_disable_auto_repair; -- cgit v1.2.3 From 22b5afce6a0f29f995b0cce83a5033892dd306d8 Mon Sep 17 00:00:00 2001 From: Bob Moore Date: Mon, 24 Mar 2014 14:49:00 +0800 Subject: ACPICA: Add auto-serialization support for ill-behaved control methods. This change adds support to automatically mark a control method as "serialized" if the method creates any named objects. This will positively prevent the method from being entered by more than one thread and thus preventing a possible abort when an attempt is made to create an object twice. Implemented by parsing all non-serialize control methods at table load time. This feature is disabled by default and this patch also adds a new Linux kernel parameter "acpi_auto_serialize" to allow this feature to be turned on for a specific boot. References: https://bugzilla.kernel.org/show_bug.cgi?id=52191 Signed-off-by: Bob Moore Signed-off-by: Lv Zheng Signed-off-by: Rafael J. Wysocki --- include/acpi/acpixf.h | 1 + 1 file changed, 1 insertion(+) (limited to 'include') diff --git a/include/acpi/acpixf.h b/include/acpi/acpixf.h index a3a8dae1cd61..fc017dff1ba0 100644 --- a/include/acpi/acpixf.h +++ b/include/acpi/acpixf.h @@ -71,6 +71,7 @@ extern u32 acpi_dbg_layer; /* ACPICA runtime options */ +extern u8 acpi_gbl_auto_serialize_methods; extern u8 acpi_gbl_copy_dsdt_locally; extern u8 acpi_gbl_create_osi_method; extern u8 acpi_gbl_disable_auto_repair; -- cgit v1.2.3 From 12478cf0c55e5969f740bb38a24b1a0104ae18d8 Mon Sep 17 00:00:00 2001 From: "Srivatsa S. Bhat" Date: Mon, 24 Mar 2014 13:35:44 +0530 Subject: cpufreq: Make sure frequency transitions are serialized Whenever we change the frequency of a CPU, we call the PRECHANGE and POSTCHANGE notifiers. They must be serialized, i.e. PRECHANGE and POSTCHANGE notifiers should strictly alternate, thereby preventing two different sets of PRECHANGE or POSTCHANGE notifiers from interleaving arbitrarily. The following examples illustrate why this is important: Scenario 1: ----------- A thread reading the value of cpuinfo_cur_freq, will call __cpufreq_cpu_get()->cpufreq_out_of_sync()->cpufreq_notify_transition() The ondemand governor can decide to change the frequency of the CPU at the same time and hence it can end up sending the notifications via ->target(). If the notifiers are not serialized, the following sequence can occur: - PRECHANGE Notification for freq A (from cpuinfo_cur_freq) - PRECHANGE Notification for freq B (from target()) - Freq changed by target() to B - POSTCHANGE Notification for freq B - POSTCHANGE Notification for freq A We can see from the above that the last POSTCHANGE Notification happens for freq A but the hardware is set to run at freq B. Where would we break then?: adjust_jiffies() in cpufreq.c & cpufreq_callback() in arch/arm/kernel/smp.c (which also adjusts the jiffies). All the loops_per_jiffy calculations will get messed up. Scenario 2: ----------- The governor calls __cpufreq_driver_target() to change the frequency. At the same time, if we change scaling_{min|max}_freq from sysfs, it will end up calling the governor's CPUFREQ_GOV_LIMITS notification, which will also call __cpufreq_driver_target(). And hence we end up issuing concurrent calls to ->target(). Typically, platforms have the following logic in their ->target() routines: (Eg: cpufreq-cpu0, omap, exynos, etc) A. If new freq is more than old: Increase voltage B. Change freq C. If new freq is less than old: decrease voltage Now, if the two concurrent calls to ->target() are X and Y, where X is trying to increase the freq and Y is trying to decrease it, we get the following race condition: X.A: voltage gets increased for larger freq Y.A: nothing happens Y.B: freq gets decreased Y.C: voltage gets decreased X.B: freq gets increased X.C: nothing happens Thus we can end up setting a freq which is not supported by the voltage we have set. That will probably make the clock to the CPU unstable and the system might not work properly anymore. This patch introduces a set of synchronization primitives to serialize frequency transitions, which are to be used as shown below: cpufreq_freq_transition_begin(); //Perform the frequency change cpufreq_freq_transition_end(); The _begin() call sends the PRECHANGE notification whereas the _end() call sends the POSTCHANGE notification. Also, all the necessary synchronization is handled within these calls. In particular, even drivers which set the ASYNC_NOTIFICATION flag can also use these APIs for performing frequency transitions (ie., you can call _begin() from one task, and call the corresponding _end() from a different task). The actual synchronization underneath is not that complicated: The key challenge is to allow drivers to begin the transition from one thread and end it in a completely different thread (this is to enable drivers that do asynchronous POSTCHANGE notification from bottom-halves, to also use the same interface). To achieve this, a 'transition_ongoing' flag, a 'transition_lock' spinlock and a wait-queue are added per-policy. The flag and the wait-queue are used in conjunction to create an "uninterrupted flow" from _begin() to _end(). The spinlock is used to ensure that only one such "flow" is in flight at any given time. Put together, this provides us all the necessary synchronization. Signed-off-by: Srivatsa S. Bhat Signed-off-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki --- include/linux/cpufreq.h | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'include') diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h index 2d2e62c8666a..e33760268a86 100644 --- a/include/linux/cpufreq.h +++ b/include/linux/cpufreq.h @@ -16,6 +16,7 @@ #include #include #include +#include #include /********************************************************************* @@ -104,6 +105,11 @@ struct cpufreq_policy { * __cpufreq_governor(data, CPUFREQ_GOV_POLICY_EXIT); */ struct rw_semaphore rwsem; + + /* Synchronization for frequency transitions */ + bool transition_ongoing; /* Tracks transition status */ + spinlock_t transition_lock; + wait_queue_head_t transition_wait; }; /* Only for ACPI */ @@ -337,6 +343,10 @@ void cpufreq_notify_transition(struct cpufreq_policy *policy, struct cpufreq_freqs *freqs, unsigned int state); void cpufreq_notify_post_transition(struct cpufreq_policy *policy, struct cpufreq_freqs *freqs, int transition_failed); +void cpufreq_freq_transition_begin(struct cpufreq_policy *policy, + struct cpufreq_freqs *freqs); +void cpufreq_freq_transition_end(struct cpufreq_policy *policy, + struct cpufreq_freqs *freqs, int transition_failed); #else /* CONFIG_CPU_FREQ */ static inline int cpufreq_register_notifier(struct notifier_block *nb, -- cgit v1.2.3 From 236a98005274d8011136aee4aef52241588a9712 Mon Sep 17 00:00:00 2001 From: Viresh Kumar Date: Mon, 24 Mar 2014 13:35:46 +0530 Subject: cpufreq: Make cpufreq_notify_transition & cpufreq_notify_post_transition static cpufreq_notify_transition() and cpufreq_notify_post_transition() shouldn't be called directly by cpufreq drivers anymore and so these should be marked static. Reviewed-by: Srivatsa S. Bhat Signed-off-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki --- include/linux/cpufreq.h | 4 ---- 1 file changed, 4 deletions(-) (limited to 'include') diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h index e33760268a86..c48e595f623e 100644 --- a/include/linux/cpufreq.h +++ b/include/linux/cpufreq.h @@ -339,10 +339,6 @@ static inline void cpufreq_resume(void) {} int cpufreq_register_notifier(struct notifier_block *nb, unsigned int list); int cpufreq_unregister_notifier(struct notifier_block *nb, unsigned int list); -void cpufreq_notify_transition(struct cpufreq_policy *policy, - struct cpufreq_freqs *freqs, unsigned int state); -void cpufreq_notify_post_transition(struct cpufreq_policy *policy, - struct cpufreq_freqs *freqs, int transition_failed); void cpufreq_freq_transition_begin(struct cpufreq_policy *policy, struct cpufreq_freqs *freqs); void cpufreq_freq_transition_end(struct cpufreq_policy *policy, -- cgit v1.2.3