* [patch V3 05/20] acpi: Remove header dependency
From: Thomas Gleixner @ 2020-03-21 11:25 UTC (permalink / raw)
To: LKML
Cc: Randy Dunlap, linux-ia64, Peter Zijlstra, linux-pci,
Sebastian Siewior, platform-driver-x86, Guo Ren, Linus Torvalds,
Joel Fernandes, Vincent Chen, Ingo Molnar, Davidlohr Bueso,
kbuild test robot, Brian Cain, Jonathan Corbet, Paul E . McKenney,
linux-hexagon, Rafael J. Wysocki, linux-csky, linux-acpi,
Darren Hart, Zhang Rui, Len Brown, Fenghua Yu, Arnd Bergmann,
linux-pm, linuxppc-dev, Greentime Hu, Bjorn Helgaas,
Kurt Schwemmer, Kalle Valo, Felipe Balbi, Michal Simek, Tony Luck,
Nick Hu, Geoff Levand, Greg Kroah-Hartman, linux-usb,
linux-wireless, Oleg Nesterov, Davidlohr Bueso, netdev,
Logan Gunthorpe, David S. Miller, Andy Shevchenko
In-Reply-To: <20200321112544.878032781@linutronix.de>
From: Peter Zijlstra <peterz@infradead.org>
In order to avoid future header hell, remove the inclusion of
proc_fs.h from acpi_bus.h. All it needs is a forward declaration of a
struct.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Darren Hart <dvhart@infradead.org>
Cc: Andy Shevchenko <andy@infradead.org>
Cc: platform-driver-x86@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
Cc: linux-pm@vger.kernel.org
Cc: Len Brown <lenb@kernel.org>
Cc: linux-acpi@vger.kernel.org
---
drivers/platform/x86/dell-smo8800.c | 1 +
drivers/platform/x86/wmi.c | 1 +
drivers/thermal/intel/int340x_thermal/acpi_thermal_rel.c | 1 +
include/acpi/acpi_bus.h | 2 +-
4 files changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/platform/x86/dell-smo8800.c
+++ b/drivers/platform/x86/dell-smo8800.c
@@ -16,6 +16,7 @@
#include <linux/interrupt.h>
#include <linux/miscdevice.h>
#include <linux/uaccess.h>
+#include <linux/fs.h>
struct smo8800_device {
u32 irq; /* acpi device irq */
--- a/drivers/platform/x86/wmi.c
+++ b/drivers/platform/x86/wmi.c
@@ -29,6 +29,7 @@
#include <linux/uaccess.h>
#include <linux/uuid.h>
#include <linux/wmi.h>
+#include <linux/fs.h>
#include <uapi/linux/wmi.h>
ACPI_MODULE_NAME("wmi");
--- a/drivers/thermal/intel/int340x_thermal/acpi_thermal_rel.c
+++ b/drivers/thermal/intel/int340x_thermal/acpi_thermal_rel.c
@@ -19,6 +19,7 @@
#include <linux/acpi.h>
#include <linux/uaccess.h>
#include <linux/miscdevice.h>
+#include <linux/fs.h>
#include "acpi_thermal_rel.h"
static acpi_handle acpi_thermal_rel_handle;
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -80,7 +80,7 @@ bool acpi_dev_present(const char *hid, c
#ifdef CONFIG_ACPI
-#include <linux/proc_fs.h>
+struct proc_dir_entry;
#define ACPI_BUS_FILE_ROOT "acpi"
extern struct proc_dir_entry *acpi_root_dir;
^ permalink raw reply
* [patch V3 13/20] Documentation: Add lock ordering and nesting documentation
From: Thomas Gleixner @ 2020-03-21 11:25 UTC (permalink / raw)
To: LKML
Cc: linux-usb, linux-ia64, Peter Zijlstra, linux-pci,
Sebastian Siewior, platform-driver-x86, Guo Ren, Joel Fernandes,
Vincent Chen, Ingo Molnar, Davidlohr Bueso, linux-acpi,
Brian Cain, Jonathan Corbet, linux-hexagon, Rafael J. Wysocki,
linux-csky, Linus Torvalds, Darren Hart, Zhang Rui, Len Brown,
Fenghua Yu, Paul E . McKenney, linux-pm, linuxppc-dev,
Greentime Hu, Bjorn Helgaas, Kurt Schwemmer, Kalle Valo,
kbuild test robot, Felipe Balbi, Michal Simek, Tony Luck, Nick Hu,
Geoff Levand, Greg Kroah-Hartman, Randy Dunlap, linux-wireless,
Oleg Nesterov, Davidlohr Bueso, Arnd Bergmann, netdev,
Logan Gunthorpe, David S. Miller, Andy Shevchenko
In-Reply-To: <20200321112544.878032781@linutronix.de>
From: Thomas Gleixner <tglx@linutronix.de>
The kernel provides a variety of locking primitives. The nesting of these
lock types and the implications of them on RT enabled kernels is nowhere
documented.
Add initial documentation.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: "Paul E . McKenney" <paulmck@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Randy Dunlap <rdunlap@infradead.org>
---
V3: Addressed review comments from Paul, Jonathan, Davidlohr
V2: Addressed review comments from Randy
---
Documentation/locking/index.rst | 1
Documentation/locking/locktypes.rst | 299 ++++++++++++++++++++++++++++++++++++
2 files changed, 300 insertions(+)
create mode 100644 Documentation/locking/locktypes.rst
--- a/Documentation/locking/index.rst
+++ b/Documentation/locking/index.rst
@@ -7,6 +7,7 @@ locking
.. toctree::
:maxdepth: 1
+ locktypes
lockdep-design
lockstat
locktorture
--- /dev/null
+++ b/Documentation/locking/locktypes.rst
@@ -0,0 +1,299 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. _kernel_hacking_locktypes:
+
+==========================
+Lock types and their rules
+==========================
+
+Introduction
+============
+
+The kernel provides a variety of locking primitives which can be divided
+into two categories:
+
+ - Sleeping locks
+ - Spinning locks
+
+This document conceptually describes these lock types and provides rules
+for their nesting, including the rules for use under PREEMPT_RT.
+
+
+Lock categories
+===============
+
+Sleeping locks
+--------------
+
+Sleeping locks can only be acquired in preemptible task context.
+
+Although implementations allow try_lock() from other contexts, it is
+necessary to carefully evaluate the safety of unlock() as well as of
+try_lock(). Furthermore, it is also necessary to evaluate the debugging
+versions of these primitives. In short, don't acquire sleeping locks from
+other contexts unless there is no other option.
+
+Sleeping lock types:
+
+ - mutex
+ - rt_mutex
+ - semaphore
+ - rw_semaphore
+ - ww_mutex
+ - percpu_rw_semaphore
+
+On PREEMPT_RT kernels, these lock types are converted to sleeping locks:
+
+ - spinlock_t
+ - rwlock_t
+
+Spinning locks
+--------------
+
+ - raw_spinlock_t
+ - bit spinlocks
+
+On non-PREEMPT_RT kernels, these lock types are also spinning locks:
+
+ - spinlock_t
+ - rwlock_t
+
+Spinning locks implicitly disable preemption and the lock / unlock functions
+can have suffixes which apply further protections:
+
+ =================== ====================================================
+ _bh() Disable / enable bottom halves (soft interrupts)
+ _irq() Disable / enable interrupts
+ _irqsave/restore() Save and disable / restore interrupt disabled state
+ =================== ====================================================
+
+
+rtmutex
+=======
+
+RT-mutexes are mutexes with support for priority inheritance (PI).
+
+PI has limitations on non PREEMPT_RT enabled kernels due to preemption and
+interrupt disabled sections.
+
+PI clearly cannot preempt preemption-disabled or interrupt-disabled
+regions of code, even on PREEMPT_RT kernels. Instead, PREEMPT_RT kernels
+execute most such regions of code in preemptible task context, especially
+interrupt handlers and soft interrupts. This conversion allows spinlock_t
+and rwlock_t to be implemented via RT-mutexes.
+
+
+raw_spinlock_t and spinlock_t
+=============================
+
+raw_spinlock_t
+--------------
+
+raw_spinlock_t is a strict spinning lock implementation regardless of the
+kernel configuration including PREEMPT_RT enabled kernels.
+
+raw_spinlock_t is a strict spinning lock implementation in all kernels,
+including PREEMPT_RT kernels. Use raw_spinlock_t only in real critical
+core code, low level interrupt handling and places where disabling
+preemption or interrupts is required, for example, to safely access
+hardware state. raw_spinlock_t can sometimes also be used when the
+critical section is tiny, thus avoiding RT-mutex overhead.
+
+spinlock_t
+----------
+
+The semantics of spinlock_t change with the state of CONFIG_PREEMPT_RT.
+
+On a non PREEMPT_RT enabled kernel spinlock_t is mapped to raw_spinlock_t
+and has exactly the same semantics.
+
+spinlock_t and PREEMPT_RT
+-------------------------
+
+On a PREEMPT_RT enabled kernel spinlock_t is mapped to a separate
+implementation based on rt_mutex which changes the semantics:
+
+ - Preemption is not disabled
+
+ - The hard interrupt related suffixes for spin_lock / spin_unlock
+ operations (_irq, _irqsave / _irqrestore) do not affect the CPUs
+ interrupt disabled state
+
+ - The soft interrupt related suffix (_bh()) still disables softirq
+ handlers.
+
+ Non-PREEMPT_RT kernels disable preemption to get this effect.
+
+ PREEMPT_RT kernels use a per-CPU lock for serialization which keeps
+ preemption disabled. The lock disables softirq handlers and also
+ prevents reentrancy due to task preemption.
+
+PREEMPT_RT kernels preserve all other spinlock_t semantics:
+
+ - Tasks holding a spinlock_t do not migrate. Non-PREEMPT_RT kernels
+ avoid migration by disabling preemption. PREEMPT_RT kernels instead
+ disable migration, which ensures that pointers to per-CPU variables
+ remain valid even if the task is preempted.
+
+ - Task state is preserved across spinlock acquisition, ensuring that the
+ task-state rules apply to all kernel configurations. Non-PREEMPT_RT
+ kernels leave task state untouched. However, PREEMPT_RT must change
+ task state if the task blocks during acquisition. Therefore, it saves
+ the current task state before blocking and the corresponding lock wakeup
+ restores it.
+
+ Other types of wakeups would normally unconditionally set the task state
+ to RUNNING, but that does not work here because the task must remain
+ blocked until the lock becomes available. Therefore, when a non-lock
+ wakeup attempts to awaken a task blocked waiting for a spinlock, it
+ instead sets the saved state to RUNNING. Then, when the lock
+ acquisition completes, the lock wakeup sets the task state to the saved
+ state, in this case setting it to RUNNING.
+
+rwlock_t
+========
+
+rwlock_t is a multiple readers and single writer lock mechanism.
+
+Non-PREEMPT_RT kernels implement rwlock_t as a spinning lock and the
+suffix rules of spinlock_t apply accordingly. The implementation is fair,
+thus preventing writer starvation.
+
+rwlock_t and PREEMPT_RT
+-----------------------
+
+PREEMPT_RT kernels map rwlock_t to a separate rt_mutex-based
+implementation, thus changing semantics:
+
+ - All the spinlock_t changes also apply to rwlock_t.
+
+ - Because an rwlock_t writer cannot grant its priority to multiple
+ readers, a preempted low-priority reader will continue holding its lock,
+ thus starving even high-priority writers. In contrast, because readers
+ can grant their priority to a writer, a preempted low-priority writer
+ will have its priority boosted until it releases the lock, thus
+ preventing that writer from starving readers.
+
+
+PREEMPT_RT caveats
+==================
+
+spinlock_t and rwlock_t
+-----------------------
+
+These changes in spinlock_t and rwlock_t semantics on PREEMPT_RT kernels
+have a few implications. For example, on a non-PREEMPT_RT kernel the
+following code sequence works as expected::
+
+ local_irq_disable();
+ spin_lock(&lock);
+
+and is fully equivalent to::
+
+ spin_lock_irq(&lock);
+
+Same applies to rwlock_t and the _irqsave() suffix variants.
+
+On PREEMPT_RT kernel this code sequence breaks because RT-mutex requires a
+fully preemptible context. Instead, use spin_lock_irq() or
+spin_lock_irqsave() and their unlock counterparts. In cases where the
+interrupt disabling and locking must remain separate, PREEMPT_RT offers a
+local_lock mechanism. Acquiring the local_lock pins the task to a CPU,
+allowing things like per-CPU irq-disabled locks to be acquired. However,
+this approach should be used only where absolutely necessary.
+
+
+raw_spinlock_t
+--------------
+
+Acquiring a raw_spinlock_t disables preemption and possibly also
+interrupts, so the critical section must avoid acquiring a regular
+spinlock_t or rwlock_t, for example, the critical section must avoid
+allocating memory. Thus, on a non-PREEMPT_RT kernel the following code
+works perfectly::
+
+ raw_spin_lock(&lock);
+ p = kmalloc(sizeof(*p), GFP_ATOMIC);
+
+But this code fails on PREEMPT_RT kernels because the memory allocator is
+fully preemptible and therefore cannot be invoked from truly atomic
+contexts. However, it is perfectly fine to invoke the memory allocator
+while holding normal non-raw spinlocks because they do not disable
+preemption on PREEMPT_RT kernels::
+
+ spin_lock(&lock);
+ p = kmalloc(sizeof(*p), GFP_ATOMIC);
+
+
+bit spinlocks
+-------------
+
+Bit spinlocks are problematic for PREEMPT_RT as they cannot be easily
+substituted by an RT-mutex based implementation for obvious reasons.
+
+The semantics of bit spinlocks are preserved on PREEMPT_RT kernels and the
+caveats vs. raw_spinlock_t apply.
+
+Some bit spinlocks are substituted by regular spinlock_t for PREEMPT_RT but
+this requires conditional (#ifdef'ed) code changes at the usage site while
+the spinlock_t substitution is simply done by the compiler and the
+conditionals are restricted to header files and core implementation of the
+locking primitives and the usage sites do not require any changes.
+
+
+Lock type nesting rules
+=======================
+
+The most basic rules are:
+
+ - Lock types of the same lock category (sleeping, spinning) can nest
+ arbitrarily as long as they respect the general lock ordering rules to
+ prevent deadlocks.
+
+ - Sleeping lock types cannot nest inside spinning lock types.
+
+ - Spinning lock types can nest inside sleeping lock types.
+
+These rules apply in general independent of CONFIG_PREEMPT_RT.
+
+As PREEMPT_RT changes the lock category of spinlock_t and rwlock_t from
+spinning to sleeping this has obviously restrictions how they can nest with
+raw_spinlock_t.
+
+This results in the following nest ordering:
+
+ 1) Sleeping locks
+ 2) spinlock_t and rwlock_t
+ 3) raw_spinlock_t and bit spinlocks
+
+Lockdep is aware of these constraints to ensure that they are respected.
+
+
+Owner semantics
+===============
+
+Most lock types in the Linux kernel have strict owner semantics, i.e. the
+context (task) which acquires a lock has to release it.
+
+There are two exceptions:
+
+ - semaphores
+ - rwsems
+
+semaphores have no owner semantics for historical reason, and as such
+trylock and release operations can be called from any context. They are
+often used for both serialization and waiting purposes. That's generally
+discouraged and should be replaced by separate serialization and wait
+mechanisms, such as mutexes and completions.
+
+rwsems have grown interfaces which allow non owner release for special
+purposes. This usage is problematic on PREEMPT_RT because PREEMPT_RT
+substitutes all locking primitives except semaphores with RT-mutex based
+implementations to provide priority inheritance for all lock types except
+the truly spinning ones. Priority inheritance on ownerless locks is
+obviously impossible.
+
+For now the rwsem non-owner release excludes code which utilizes it from
+being used on PREEMPT_RT enabled kernels. In same cases this can be
+mitigated by disabling portions of the code, in other cases the complete
+functionality has to be disabled until a workable solution has been found.
^ permalink raw reply
* [patch V3 14/20] timekeeping: Split jiffies seqlock
From: Thomas Gleixner @ 2020-03-21 11:25 UTC (permalink / raw)
To: LKML
Cc: Randy Dunlap, linux-ia64, Peter Zijlstra, linux-pci,
Sebastian Siewior, platform-driver-x86, Guo Ren, Joel Fernandes,
Vincent Chen, Ingo Molnar, Jonathan Corbet, Davidlohr Bueso,
kbuild test robot, Brian Cain, linux-acpi, Paul E . McKenney,
linux-hexagon, Rafael J. Wysocki, linux-csky, Linus Torvalds,
Darren Hart, Zhang Rui, Len Brown, Fenghua Yu, Arnd Bergmann,
linux-pm, linuxppc-dev, Greentime Hu, Bjorn Helgaas,
Kurt Schwemmer, Kalle Valo, Felipe Balbi, Michal Simek, Tony Luck,
Nick Hu, Geoff Levand, Greg Kroah-Hartman, linux-usb,
linux-wireless, Oleg Nesterov, Davidlohr Bueso, netdev,
Logan Gunthorpe, David S. Miller, Andy Shevchenko
In-Reply-To: <20200321112544.878032781@linutronix.de>
From: Thomas Gleixner <tglx@linutronix.de>
seqlock consists of a sequence counter and a spinlock_t which is used to
serialize the writers. spinlock_t is substituted by a "sleeping" spinlock
on PREEMPT_RT enabled kernels which breaks the usage in the timekeeping
code as the writers are executed in hard interrupt and therefore
non-preemptible context even on PREEMPT_RT.
The spinlock in seqlock cannot be unconditionally replaced by a
raw_spinlock_t as many seqlock users have nesting spinlock sections or
other code which is not suitable to run in truly atomic context on RT.
Instead of providing a raw_seqlock API for a single use case, open code the
seqlock for the jiffies use case and implement it with a raw_spinlock_t and
a sequence counter.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
kernel/time/jiffies.c | 7 ++++---
kernel/time/tick-common.c | 10 ++++++----
kernel/time/tick-sched.c | 19 ++++++++++++-------
kernel/time/timekeeping.c | 6 ++++--
kernel/time/timekeeping.h | 3 ++-
5 files changed, 28 insertions(+), 17 deletions(-)
--- a/kernel/time/jiffies.c
+++ b/kernel/time/jiffies.c
@@ -58,7 +58,8 @@ static struct clocksource clocksource_ji
.max_cycles = 10,
};
-__cacheline_aligned_in_smp DEFINE_SEQLOCK(jiffies_lock);
+__cacheline_aligned_in_smp DEFINE_RAW_SPINLOCK(jiffies_lock);
+__cacheline_aligned_in_smp seqcount_t jiffies_seq;
#if (BITS_PER_LONG < 64)
u64 get_jiffies_64(void)
@@ -67,9 +68,9 @@ u64 get_jiffies_64(void)
u64 ret;
do {
- seq = read_seqbegin(&jiffies_lock);
+ seq = read_seqcount_begin(&jiffies_seq);
ret = jiffies_64;
- } while (read_seqretry(&jiffies_lock, seq));
+ } while (read_seqcount_retry(&jiffies_seq, seq));
return ret;
}
EXPORT_SYMBOL(get_jiffies_64);
--- a/kernel/time/tick-common.c
+++ b/kernel/time/tick-common.c
@@ -84,13 +84,15 @@ int tick_is_oneshot_available(void)
static void tick_periodic(int cpu)
{
if (tick_do_timer_cpu == cpu) {
- write_seqlock(&jiffies_lock);
+ raw_spin_lock(&jiffies_lock);
+ write_seqcount_begin(&jiffies_seq);
/* Keep track of the next tick event */
tick_next_period = ktime_add(tick_next_period, tick_period);
do_timer(1);
- write_sequnlock(&jiffies_lock);
+ write_seqcount_end(&jiffies_seq);
+ raw_spin_unlock(&jiffies_lock);
update_wall_time();
}
@@ -162,9 +164,9 @@ void tick_setup_periodic(struct clock_ev
ktime_t next;
do {
- seq = read_seqbegin(&jiffies_lock);
+ seq = read_seqcount_begin(&jiffies_seq);
next = tick_next_period;
- } while (read_seqretry(&jiffies_lock, seq));
+ } while (read_seqcount_retry(&jiffies_seq, seq));
clockevents_switch_state(dev, CLOCK_EVT_STATE_ONESHOT);
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -65,7 +65,8 @@ static void tick_do_update_jiffies64(kti
return;
/* Reevaluate with jiffies_lock held */
- write_seqlock(&jiffies_lock);
+ raw_spin_lock(&jiffies_lock);
+ write_seqcount_begin(&jiffies_seq);
delta = ktime_sub(now, last_jiffies_update);
if (delta >= tick_period) {
@@ -91,10 +92,12 @@ static void tick_do_update_jiffies64(kti
/* Keep the tick_next_period variable up to date */
tick_next_period = ktime_add(last_jiffies_update, tick_period);
} else {
- write_sequnlock(&jiffies_lock);
+ write_seqcount_end(&jiffies_seq);
+ raw_spin_unlock(&jiffies_lock);
return;
}
- write_sequnlock(&jiffies_lock);
+ write_seqcount_end(&jiffies_seq);
+ raw_spin_unlock(&jiffies_lock);
update_wall_time();
}
@@ -105,12 +108,14 @@ static ktime_t tick_init_jiffy_update(vo
{
ktime_t period;
- write_seqlock(&jiffies_lock);
+ raw_spin_lock(&jiffies_lock);
+ write_seqcount_begin(&jiffies_seq);
/* Did we start the jiffies update yet ? */
if (last_jiffies_update == 0)
last_jiffies_update = tick_next_period;
period = last_jiffies_update;
- write_sequnlock(&jiffies_lock);
+ write_seqcount_end(&jiffies_seq);
+ raw_spin_unlock(&jiffies_lock);
return period;
}
@@ -676,10 +681,10 @@ static ktime_t tick_nohz_next_event(stru
/* Read jiffies and the time when jiffies were updated last */
do {
- seq = read_seqbegin(&jiffies_lock);
+ seq = read_seqcount_begin(&jiffies_seq);
basemono = last_jiffies_update;
basejiff = jiffies;
- } while (read_seqretry(&jiffies_lock, seq));
+ } while (read_seqcount_retry(&jiffies_seq, seq));
ts->last_jiffies = basejiff;
ts->timer_expires_base = basemono;
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -2397,8 +2397,10 @@ EXPORT_SYMBOL(hardpps);
*/
void xtime_update(unsigned long ticks)
{
- write_seqlock(&jiffies_lock);
+ raw_spin_lock(&jiffies_lock);
+ write_seqcount_begin(&jiffies_seq);
do_timer(ticks);
- write_sequnlock(&jiffies_lock);
+ write_seqcount_end(&jiffies_seq);
+ raw_spin_unlock(&jiffies_lock);
update_wall_time();
}
--- a/kernel/time/timekeeping.h
+++ b/kernel/time/timekeeping.h
@@ -25,7 +25,8 @@ static inline void sched_clock_resume(vo
extern void do_timer(unsigned long ticks);
extern void update_wall_time(void);
-extern seqlock_t jiffies_lock;
+extern raw_spinlock_t jiffies_lock;
+extern seqcount_t jiffies_seq;
#define CS_NAME_LEN 32
^ permalink raw reply
* [patch V3 04/20] orinoco_usb: Use the regular completion interfaces
From: Thomas Gleixner @ 2020-03-21 11:25 UTC (permalink / raw)
To: LKML
Cc: Randy Dunlap, linux-ia64, Peter Zijlstra, linux-pci,
Sebastian Siewior, platform-driver-x86, Guo Ren, Joel Fernandes,
Vincent Chen, Ingo Molnar, Jonathan Corbet, Davidlohr Bueso,
kbuild test robot, Brian Cain, linux-acpi, Paul E . McKenney,
linux-hexagon, Rafael J. Wysocki, linux-csky, Linus Torvalds,
Darren Hart, Zhang Rui, Len Brown, Fenghua Yu, Arnd Bergmann,
linux-pm, linuxppc-dev, Greentime Hu, Bjorn Helgaas,
Kurt Schwemmer, Kalle Valo, Felipe Balbi, Michal Simek, Tony Luck,
Nick Hu, Geoff Levand, Greg Kroah-Hartman, linux-usb,
linux-wireless, Oleg Nesterov, Davidlohr Bueso, netdev,
Logan Gunthorpe, David S. Miller, Andy Shevchenko
In-Reply-To: <20200321112544.878032781@linutronix.de>
From: Thomas Gleixner <tglx@linutronix.de>
The completion usage in this driver is interesting:
- it uses a magic complete function which according to the comment was
implemented by invoking complete() four times in a row because
complete_all() was not exported at that time.
- it uses an open coded wait/poll which checks completion:done. Only one wait
side (device removal) uses the regular wait_for_completion() interface.
The rationale behind this is to prevent that wait_for_completion() consumes
completion::done which would prevent that all waiters are woken. This is not
necessary with complete_all() as that sets completion::done to UINT_MAX which
is left unmodified by the woken waiters.
Replace the magic complete function with complete_all() and convert the
open coded wait/poll to regular completion interfaces.
This changes the wait to exclusive wait mode. But that does not make any
difference because the wakers use complete_all() which ignores the
exclusive mode.
Reported-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: linux-usb@vger.kernel.org
---
V2: New patch to avoid conversion to swait functions later.
---
drivers/net/wireless/intersil/orinoco/orinoco_usb.c | 21 ++++----------------
1 file changed, 5 insertions(+), 16 deletions(-)
--- a/drivers/net/wireless/intersil/orinoco/orinoco_usb.c
+++ b/drivers/net/wireless/intersil/orinoco/orinoco_usb.c
@@ -365,17 +365,6 @@ static struct request_context *ezusb_all
return ctx;
}
-
-/* Hopefully the real complete_all will soon be exported, in the mean
- * while this should work. */
-static inline void ezusb_complete_all(struct completion *comp)
-{
- complete(comp);
- complete(comp);
- complete(comp);
- complete(comp);
-}
-
static void ezusb_ctx_complete(struct request_context *ctx)
{
struct ezusb_priv *upriv = ctx->upriv;
@@ -409,7 +398,7 @@ static void ezusb_ctx_complete(struct re
netif_wake_queue(dev);
}
- ezusb_complete_all(&ctx->done);
+ complete_all(&ctx->done);
ezusb_request_context_put(ctx);
break;
@@ -419,7 +408,7 @@ static void ezusb_ctx_complete(struct re
/* This is normal, as all request contexts get flushed
* when the device is disconnected */
err("Called, CTX not terminating, but device gone");
- ezusb_complete_all(&ctx->done);
+ complete_all(&ctx->done);
ezusb_request_context_put(ctx);
break;
}
@@ -690,11 +679,11 @@ static void ezusb_req_ctx_wait(struct ez
* get the chance to run themselves. So we make sure
* that we don't sleep for ever */
int msecs = DEF_TIMEOUT * (1000 / HZ);
- while (!ctx->done.done && msecs--)
+
+ while (!try_wait_for_completion(&ctx->done) && msecs--)
udelay(1000);
} else {
- wait_event_interruptible(ctx->done.wait,
- ctx->done.done);
+ wait_for_completion(&ctx->done);
}
break;
default:
^ permalink raw reply
* [patch V3 15/20] sched/swait: Prepare usage in completions
From: Thomas Gleixner @ 2020-03-21 11:25 UTC (permalink / raw)
To: LKML
Cc: Randy Dunlap, linux-ia64, Peter Zijlstra, linux-pci,
Sebastian Siewior, platform-driver-x86, Guo Ren, Joel Fernandes,
Vincent Chen, Ingo Molnar, Jonathan Corbet, Davidlohr Bueso,
kbuild test robot, Brian Cain, linux-acpi, Paul E . McKenney,
linux-hexagon, Rafael J. Wysocki, linux-csky, Linus Torvalds,
Darren Hart, Zhang Rui, Len Brown, Fenghua Yu, Arnd Bergmann,
linux-pm, linuxppc-dev, Greentime Hu, Bjorn Helgaas,
Kurt Schwemmer, Kalle Valo, Felipe Balbi, Michal Simek, Tony Luck,
Nick Hu, Geoff Levand, Greg Kroah-Hartman, linux-usb,
linux-wireless, Oleg Nesterov, Davidlohr Bueso, netdev,
Logan Gunthorpe, David S. Miller, Andy Shevchenko
In-Reply-To: <20200321112544.878032781@linutronix.de>
From: Thomas Gleixner <tglx@linutronix.de>
As a preparation to use simple wait queues for completions:
- Provide swake_up_all_locked() to support complete_all()
- Make __prepare_to_swait() public available
This is done to enable the usage of complete() within truly atomic contexts
on a PREEMPT_RT enabled kernel.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
---
V2: Add comment to swake_up_all_locked()
---
kernel/sched/sched.h | 3 +++
kernel/sched/swait.c | 15 ++++++++++++++-
2 files changed, 17 insertions(+), 1 deletion(-)
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -2492,3 +2492,6 @@ static inline bool is_per_cpu_kthread(st
return true;
}
#endif
+
+void swake_up_all_locked(struct swait_queue_head *q);
+void __prepare_to_swait(struct swait_queue_head *q, struct swait_queue *wait);
--- a/kernel/sched/swait.c
+++ b/kernel/sched/swait.c
@@ -32,6 +32,19 @@ void swake_up_locked(struct swait_queue_
}
EXPORT_SYMBOL(swake_up_locked);
+/*
+ * Wake up all waiters. This is an interface which is solely exposed for
+ * completions and not for general usage.
+ *
+ * It is intentionally different from swake_up_all() to allow usage from
+ * hard interrupt context and interrupt disabled regions.
+ */
+void swake_up_all_locked(struct swait_queue_head *q)
+{
+ while (!list_empty(&q->task_list))
+ swake_up_locked(q);
+}
+
void swake_up_one(struct swait_queue_head *q)
{
unsigned long flags;
@@ -69,7 +82,7 @@ void swake_up_all(struct swait_queue_hea
}
EXPORT_SYMBOL(swake_up_all);
-static void __prepare_to_swait(struct swait_queue_head *q, struct swait_queue *wait)
+void __prepare_to_swait(struct swait_queue_head *q, struct swait_queue *wait)
{
wait->task = current;
if (list_empty(&wait->task_list))
^ permalink raw reply
* [patch V3 08/20] hexagon: Remove mm.h from asm/uaccess.h
From: Thomas Gleixner @ 2020-03-21 11:25 UTC (permalink / raw)
To: LKML
Cc: Randy Dunlap, linux-ia64, Peter Zijlstra, linux-pci,
Sebastian Siewior, platform-driver-x86, Guo Ren, Joel Fernandes,
Vincent Chen, Ingo Molnar, Jonathan Corbet, Davidlohr Bueso,
kbuild test robot, Brian Cain, linux-acpi, Paul E . McKenney,
linux-hexagon, Rafael J. Wysocki, linux-csky, Linus Torvalds,
Darren Hart, Zhang Rui, Len Brown, Fenghua Yu, Arnd Bergmann,
linux-pm, linuxppc-dev, Greentime Hu, Bjorn Helgaas,
Kurt Schwemmer, Kalle Valo, Felipe Balbi, Michal Simek, Tony Luck,
Nick Hu, Geoff Levand, Greg Kroah-Hartman, linux-usb,
linux-wireless, Oleg Nesterov, Davidlohr Bueso, netdev,
Logan Gunthorpe, David S. Miller, Andy Shevchenko
In-Reply-To: <20200321112544.878032781@linutronix.de>
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
The defconfig compiles without linux/mm.h. With mm.h included the
include chain leands to:
| CC kernel/locking/percpu-rwsem.o
| In file included from include/linux/huge_mm.h:8,
| from include/linux/mm.h:567,
| from arch/hexagon/include/asm/uaccess.h:,
| from include/linux/uaccess.h:11,
| from include/linux/sched/task.h:11,
| from include/linux/sched/signal.h:9,
| from include/linux/rcuwait.h:6,
| from include/linux/percpu-rwsem.h:8,
| from kernel/locking/percpu-rwsem.c:6:
| include/linux/fs.h:1422:29: error: array type has incomplete element type 'struct percpu_rw_semaphore'
| 1422 | struct percpu_rw_semaphore rw_sem[SB_FREEZE_LEVELS];
once rcuwait.h includes linux/sched/signal.h.
Remove the linux/mm.h include.
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Brian Cain <bcain@codeaurora.org>
Cc: linux-hexagon@vger.kernel.org
---
V3: New patch
---
arch/hexagon/include/asm/uaccess.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/hexagon/include/asm/uaccess.h b/arch/hexagon/include/asm/uaccess.h
index 00cb38faad0c4..c1019a736ff13 100644
--- a/arch/hexagon/include/asm/uaccess.h
+++ b/arch/hexagon/include/asm/uaccess.h
@@ -10,7 +10,6 @@
/*
* User space memory access functions
*/
-#include <linux/mm.h>
#include <asm/sections.h>
/*
--
2.26.0.rc2
^ permalink raw reply related
* [patch V3 02/20] pci/switchtec: Replace completion wait queue usage for poll
From: Thomas Gleixner @ 2020-03-21 11:25 UTC (permalink / raw)
To: LKML
Cc: Randy Dunlap, linux-ia64, Peter Zijlstra, linux-pci,
Sebastian Siewior, platform-driver-x86, Guo Ren, Joel Fernandes,
Vincent Chen, Ingo Molnar, Jonathan Corbet, Davidlohr Bueso,
kbuild test robot, Brian Cain, linux-acpi, Paul E . McKenney,
linux-hexagon, Rafael J. Wysocki, linux-csky, Linus Torvalds,
Darren Hart, Zhang Rui, Len Brown, Fenghua Yu, Arnd Bergmann,
linux-pm, linuxppc-dev, Greentime Hu, Bjorn Helgaas,
Kurt Schwemmer, Kalle Valo, Felipe Balbi, Michal Simek, Tony Luck,
Nick Hu, Geoff Levand, Greg Kroah-Hartman, linux-usb,
linux-wireless, Oleg Nesterov, Davidlohr Bueso, netdev,
Logan Gunthorpe, David S. Miller, Andy Shevchenko
In-Reply-To: <20200321112544.878032781@linutronix.de>
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
The poll callback is using the completion wait queue and sticks it into
poll_wait() to wake up pollers after a command has completed.
This works to some extent, but cannot provide EPOLLEXCLUSIVE support
because the waker side uses complete_all() which unconditionally wakes up
all waiters. complete_all() is required because completions internally use
exclusive wait and complete() only wakes up one waiter by default.
This mixes conceptually different mechanisms and relies on internal
implementation details of completions, which in turn puts contraints on
changing the internal implementation of completions.
Replace it with a regular wait queue and store the state in struct
switchtec_user.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: Kurt Schwemmer <kurt.schwemmer@microsemi.com>
Cc: linux-pci@vger.kernel.org
---
V2: Reworded changelog.
---
drivers/pci/switch/switchtec.c | 22 +++++++++++++---------
1 file changed, 13 insertions(+), 9 deletions(-)
--- a/drivers/pci/switch/switchtec.c
+++ b/drivers/pci/switch/switchtec.c
@@ -52,10 +52,11 @@ struct switchtec_user {
enum mrpc_state state;
- struct completion comp;
+ wait_queue_head_t cmd_comp;
struct kref kref;
struct list_head list;
+ bool cmd_done;
u32 cmd;
u32 status;
u32 return_code;
@@ -77,7 +78,7 @@ static struct switchtec_user *stuser_cre
stuser->stdev = stdev;
kref_init(&stuser->kref);
INIT_LIST_HEAD(&stuser->list);
- init_completion(&stuser->comp);
+ init_waitqueue_head(&stuser->cmd_comp);
stuser->event_cnt = atomic_read(&stdev->event_cnt);
dev_dbg(&stdev->dev, "%s: %p\n", __func__, stuser);
@@ -175,7 +176,7 @@ static int mrpc_queue_cmd(struct switcht
kref_get(&stuser->kref);
stuser->read_len = sizeof(stuser->data);
stuser_set_state(stuser, MRPC_QUEUED);
- reinit_completion(&stuser->comp);
+ stuser->cmd_done = false;
list_add_tail(&stuser->list, &stdev->mrpc_queue);
mrpc_cmd_submit(stdev);
@@ -222,7 +223,8 @@ static void mrpc_complete_cmd(struct swi
memcpy_fromio(stuser->data, &stdev->mmio_mrpc->output_data,
stuser->read_len);
out:
- complete_all(&stuser->comp);
+ stuser->cmd_done = true;
+ wake_up_interruptible(&stuser->cmd_comp);
list_del_init(&stuser->list);
stuser_put(stuser);
stdev->mrpc_busy = 0;
@@ -529,10 +531,11 @@ static ssize_t switchtec_dev_read(struct
mutex_unlock(&stdev->mrpc_mutex);
if (filp->f_flags & O_NONBLOCK) {
- if (!try_wait_for_completion(&stuser->comp))
+ if (!stuser->cmd_done)
return -EAGAIN;
} else {
- rc = wait_for_completion_interruptible(&stuser->comp);
+ rc = wait_event_interruptible(stuser->cmd_comp,
+ stuser->cmd_done);
if (rc < 0)
return rc;
}
@@ -580,7 +583,7 @@ static __poll_t switchtec_dev_poll(struc
struct switchtec_dev *stdev = stuser->stdev;
__poll_t ret = 0;
- poll_wait(filp, &stuser->comp.wait, wait);
+ poll_wait(filp, &stuser->cmd_comp, wait);
poll_wait(filp, &stdev->event_wq, wait);
if (lock_mutex_and_test_alive(stdev))
@@ -588,7 +591,7 @@ static __poll_t switchtec_dev_poll(struc
mutex_unlock(&stdev->mrpc_mutex);
- if (try_wait_for_completion(&stuser->comp))
+ if (stuser->cmd_done)
ret |= EPOLLIN | EPOLLRDNORM;
if (stuser->event_cnt != atomic_read(&stdev->event_cnt))
@@ -1272,7 +1275,8 @@ static void stdev_kill(struct switchtec_
/* Wake up and kill any users waiting on an MRPC request */
list_for_each_entry_safe(stuser, tmpuser, &stdev->mrpc_queue, list) {
- complete_all(&stuser->comp);
+ stuser->cmd_done = true;
+ wake_up_interruptible(&stuser->cmd_comp);
list_del_init(&stuser->list);
stuser_put(stuser);
}
^ permalink raw reply
* [patch V3 06/20] nds32: Remove mm.h from asm/uaccess.h
From: Thomas Gleixner @ 2020-03-21 11:25 UTC (permalink / raw)
To: LKML
Cc: Randy Dunlap, linux-ia64, Peter Zijlstra, linux-pci,
Sebastian Siewior, platform-driver-x86, Guo Ren, Joel Fernandes,
Vincent Chen, Ingo Molnar, Jonathan Corbet, Davidlohr Bueso,
kbuild test robot, Brian Cain, linux-acpi, Paul E . McKenney,
linux-hexagon, Rafael J. Wysocki, linux-csky, Linus Torvalds,
Darren Hart, Zhang Rui, Len Brown, Fenghua Yu, Arnd Bergmann,
linux-pm, linuxppc-dev, Greentime Hu, Bjorn Helgaas,
Kurt Schwemmer, Kalle Valo, Felipe Balbi, Michal Simek, Tony Luck,
Nick Hu, Geoff Levand, Greg Kroah-Hartman, linux-usb,
linux-wireless, Oleg Nesterov, Davidlohr Bueso, netdev,
Logan Gunthorpe, David S. Miller, Andy Shevchenko
In-Reply-To: <20200321112544.878032781@linutronix.de>
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
The defconfig compiles without linux/mm.h. With mm.h included the
include chain leands to:
| CC kernel/locking/percpu-rwsem.o
| In file included from include/linux/huge_mm.h:8,
| from include/linux/mm.h:567,
| from arch/nds32/include/asm/uaccess.h:,
| from include/linux/uaccess.h:11,
| from include/linux/sched/task.h:11,
| from include/linux/sched/signal.h:9,
| from include/linux/rcuwait.h:6,
| from include/linux/percpu-rwsem.h:8,
| from kernel/locking/percpu-rwsem.c:6:
| include/linux/fs.h:1422:29: error: array type has incomplete element type 'struct percpu_rw_semaphore'
| 1422 | struct percpu_rw_semaphore rw_sem[SB_FREEZE_LEVELS];
once rcuwait.h includes linux/sched/signal.h.
Remove the linux/mm.h include.
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Nick Hu <nickhu@andestech.com>
Cc: Greentime Hu <green.hu@gmail.com>
Cc: Vincent Chen <deanbo422@gmail.com>
---
V3: New patch
---
arch/nds32/include/asm/uaccess.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/nds32/include/asm/uaccess.h b/arch/nds32/include/asm/uaccess.h
index 8916ad9f9f139..3a9219f53ee0d 100644
--- a/arch/nds32/include/asm/uaccess.h
+++ b/arch/nds32/include/asm/uaccess.h
@@ -11,7 +11,6 @@
#include <asm/errno.h>
#include <asm/memory.h>
#include <asm/types.h>
-#include <linux/mm.h>
#define __asmeq(x, y) ".ifnc " x "," y " ; .err ; .endif\n\t"
--
2.26.0.rc2
^ permalink raw reply related
* [patch V3 07/20] csky: Remove mm.h from asm/uaccess.h
From: Thomas Gleixner @ 2020-03-21 11:25 UTC (permalink / raw)
To: LKML
Cc: Randy Dunlap, linux-ia64, Peter Zijlstra, linux-pci,
Sebastian Siewior, platform-driver-x86, Guo Ren, Joel Fernandes,
Vincent Chen, Ingo Molnar, Jonathan Corbet, Davidlohr Bueso,
kbuild test robot, Brian Cain, linux-acpi, Paul E . McKenney,
linux-hexagon, Rafael J. Wysocki, linux-csky, Linus Torvalds,
Darren Hart, Zhang Rui, Len Brown, Fenghua Yu, Arnd Bergmann,
linux-pm, linuxppc-dev, Greentime Hu, Bjorn Helgaas,
Kurt Schwemmer, Kalle Valo, Felipe Balbi, Michal Simek, Tony Luck,
Nick Hu, Geoff Levand, Greg Kroah-Hartman, linux-usb,
linux-wireless, Oleg Nesterov, Davidlohr Bueso, netdev,
Logan Gunthorpe, David S. Miller, Andy Shevchenko
In-Reply-To: <20200321112544.878032781@linutronix.de>
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
The defconfig compiles without linux/mm.h. With mm.h included the
include chain leands to:
| CC kernel/locking/percpu-rwsem.o
| In file included from include/linux/huge_mm.h:8,
| from include/linux/mm.h:567,
| from arch/csky/include/asm/uaccess.h:,
| from include/linux/uaccess.h:11,
| from include/linux/sched/task.h:11,
| from include/linux/sched/signal.h:9,
| from include/linux/rcuwait.h:6,
| from include/linux/percpu-rwsem.h:8,
| from kernel/locking/percpu-rwsem.c:6:
| include/linux/fs.h:1422:29: error: array type has incomplete element type 'struct percpu_rw_semaphore'
| 1422 | struct percpu_rw_semaphore rw_sem[SB_FREEZE_LEVELS];
once rcuwait.h includes linux/sched/signal.h.
Remove the linux/mm.h include.
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Guo Ren <guoren@kernel.org>
Cc: linux-csky@vger.kernel.org
---
V3: New patch
---
arch/csky/include/asm/uaccess.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/csky/include/asm/uaccess.h b/arch/csky/include/asm/uaccess.h
index eaa1c3403a424..abefa125b93cf 100644
--- a/arch/csky/include/asm/uaccess.h
+++ b/arch/csky/include/asm/uaccess.h
@@ -11,7 +11,6 @@
#include <linux/errno.h>
#include <linux/types.h>
#include <linux/sched.h>
-#include <linux/mm.h>
#include <linux/string.h>
#include <linux/version.h>
#include <asm/segment.h>
--
2.26.0.rc2
^ permalink raw reply related
* [patch V3 12/20] powerpc/ps3: Convert half completion to rcuwait
From: Thomas Gleixner @ 2020-03-21 11:25 UTC (permalink / raw)
To: LKML
Cc: Randy Dunlap, linux-ia64, Peter Zijlstra, linux-pci,
Sebastian Siewior, platform-driver-x86, Guo Ren, Joel Fernandes,
linux-hexagon, Vincent Chen, Ingo Molnar, Jonathan Corbet,
Davidlohr Bueso, kbuild test robot, Brian Cain, linux-acpi,
Paul E . McKenney, Rafael J. Wysocki, linux-csky, Linus Torvalds,
Darren Hart, Zhang Rui, Len Brown, Fenghua Yu, Arnd Bergmann,
linux-pm, Greentime Hu, Bjorn Helgaas, Kurt Schwemmer, Kalle Valo,
Felipe Balbi, Michal Simek, Tony Luck, Nick Hu, Geoff Levand,
Greg Kroah-Hartman, linux-usb, linux-wireless, Oleg Nesterov,
Davidlohr Bueso, Logan Gunthorpe, netdev, linuxppc-dev,
David S. Miller, Andy Shevchenko
In-Reply-To: <20200321112544.878032781@linutronix.de>
From: Thomas Gleixner <tglx@linutronix.de>
The PS3 notification interrupt and kthread use a hacked up completion to
communicate. Since we're wanting to change the completion implementation and
this is abuse anyway, replace it with a simple rcuwait since there is only ever
the one waiter.
AFAICT the kthread uses TASK_INTERRUPTIBLE to not increase loadavg, kthreads
cannot receive signals by default and this one doesn't look different. Use
TASK_IDLE instead.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Geoff Levand <geoff@infradead.org>
Cc: linuxppc-dev@lists.ozlabs.org
---
V3: Folded the init fix from bigeasy
V2: New patch to avoid the magic completion wait variant
---
arch/powerpc/platforms/ps3/device-init.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
--- a/arch/powerpc/platforms/ps3/device-init.c
+++ b/arch/powerpc/platforms/ps3/device-init.c
@@ -13,6 +13,7 @@
#include <linux/init.h>
#include <linux/slab.h>
#include <linux/reboot.h>
+#include <linux/rcuwait.h>
#include <asm/firmware.h>
#include <asm/lv1call.h>
@@ -670,7 +671,8 @@ struct ps3_notification_device {
spinlock_t lock;
u64 tag;
u64 lv1_status;
- struct completion done;
+ struct rcuwait wait;
+ bool done;
};
enum ps3_notify_type {
@@ -712,7 +714,8 @@ static irqreturn_t ps3_notification_inte
pr_debug("%s:%u: completed, status 0x%llx\n", __func__,
__LINE__, status);
dev->lv1_status = status;
- complete(&dev->done);
+ dev->done = true;
+ rcuwait_wake_up(&dev->wait);
}
spin_unlock(&dev->lock);
return IRQ_HANDLED;
@@ -725,12 +728,12 @@ static int ps3_notification_read_write(s
unsigned long flags;
int res;
- init_completion(&dev->done);
spin_lock_irqsave(&dev->lock, flags);
res = write ? lv1_storage_write(dev->sbd.dev_id, 0, 0, 1, 0, lpar,
&dev->tag)
: lv1_storage_read(dev->sbd.dev_id, 0, 0, 1, 0, lpar,
&dev->tag);
+ dev->done = false;
spin_unlock_irqrestore(&dev->lock, flags);
if (res) {
pr_err("%s:%u: %s failed %d\n", __func__, __LINE__, op, res);
@@ -738,14 +741,10 @@ static int ps3_notification_read_write(s
}
pr_debug("%s:%u: notification %s issued\n", __func__, __LINE__, op);
- res = wait_event_interruptible(dev->done.wait,
- dev->done.done || kthread_should_stop());
+ rcuwait_wait_event(&dev->wait, dev->done || kthread_should_stop(), TASK_IDLE);
+
if (kthread_should_stop())
res = -EINTR;
- if (res) {
- pr_debug("%s:%u: interrupted %s\n", __func__, __LINE__, op);
- return res;
- }
if (dev->lv1_status) {
pr_err("%s:%u: %s not completed, status 0x%llx\n", __func__,
@@ -810,6 +809,7 @@ static int ps3_probe_thread(void *data)
}
spin_lock_init(&dev.lock);
+ rcuwait_init(&dev.wait);
res = request_irq(irq, ps3_notification_interrupt, 0,
"ps3_notification", &dev);
^ permalink raw reply
* [patch V3 00/20] Lock ordering documentation and annotation for lockdep
From: Thomas Gleixner @ 2020-03-21 11:25 UTC (permalink / raw)
To: LKML
Cc: Randy Dunlap, linux-ia64, Peter Zijlstra, linux-pci,
Sebastian Siewior, platform-driver-x86, Guo Ren, Joel Fernandes,
Vincent Chen, Ingo Molnar, Jonathan Corbet, Davidlohr Bueso,
kbuild test robot, Brian Cain, linux-acpi, Paul E . McKenney,
linux-hexagon, Rafael J. Wysocki, linux-csky, Linus Torvalds,
Darren Hart, Zhang Rui, Len Brown, Fenghua Yu, Arnd Bergmann,
linux-pm, linuxppc-dev, Greentime Hu, Bjorn Helgaas,
Kurt Schwemmer, Kalle Valo, Felipe Balbi, Michal Simek, Tony Luck,
Nick Hu, Geoff Levand, Greg Kroah-Hartman, linux-usb,
linux-wireless, Oleg Nesterov, Davidlohr Bueso, netdev,
Logan Gunthorpe, David S. Miller, Andy Shevchenko
This is the third and hopefully final version of this work. The second one
can be found here:
https://lore.kernel.org/r/20200318204302.693307984@linutronix.de
Changes since V2:
- Included the arch/XXX fixups for the rcuwait changes (Sebastian)
- Folded the init fix for the PS3 change (Sebastian)
- Addressed feedback on documentation (Paul, Davidlohr, Jonathan)
- Picked up acks and reviewed tags
Thanks,
tglx
^ permalink raw reply
* [patch V3 20/20] lockdep: Add posixtimer context tracing bits
From: Thomas Gleixner @ 2020-03-21 11:26 UTC (permalink / raw)
To: LKML
Cc: Randy Dunlap, linux-ia64, Peter Zijlstra, linux-pci,
Sebastian Siewior, platform-driver-x86, Guo Ren, Joel Fernandes,
Vincent Chen, Ingo Molnar, Jonathan Corbet, Davidlohr Bueso,
kbuild test robot, Brian Cain, linux-acpi, Paul E . McKenney,
linux-hexagon, Rafael J. Wysocki, linux-csky, Linus Torvalds,
Darren Hart, Zhang Rui, Len Brown, Fenghua Yu, Arnd Bergmann,
linux-pm, linuxppc-dev, Greentime Hu, Bjorn Helgaas,
Kurt Schwemmer, Kalle Valo, Felipe Balbi, Michal Simek, Tony Luck,
Nick Hu, Geoff Levand, Greg Kroah-Hartman, linux-usb,
linux-wireless, Oleg Nesterov, Davidlohr Bueso, netdev,
Logan Gunthorpe, David S. Miller, Andy Shevchenko
In-Reply-To: <20200321112544.878032781@linutronix.de>
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Splitting run_posix_cpu_timers() into two parts is work in progress which
is stuck on other entry code related problems. The heavy lifting which
involves locking of sighand lock will be moved into task context so the
necessary execution time is burdened on the task and not on interrupt
context.
Until this work completes lockdep with the spinlock nesting rules enabled
would emit warnings for this known context.
Prevent it by setting "->irq_config = 1" for the invocation of
run_posix_cpu_timers() so lockdep does not complain when sighand lock is
acquried. This will be removed once the split is completed.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
include/linux/irqflags.h | 12 ++++++++++++
kernel/time/posix-cpu-timers.c | 6 +++++-
2 files changed, 17 insertions(+), 1 deletion(-)
--- a/include/linux/irqflags.h
+++ b/include/linux/irqflags.h
@@ -69,6 +69,16 @@ do { \
current->irq_config = 0; \
} while (0)
+# define lockdep_posixtimer_enter() \
+ do { \
+ current->irq_config = 1; \
+ } while (0)
+
+# define lockdep_posixtimer_exit() \
+ do { \
+ current->irq_config = 0; \
+ } while (0)
+
# define lockdep_irq_work_enter(__work) \
do { \
if (!(atomic_read(&__work->flags) & IRQ_WORK_HARD_IRQ))\
@@ -94,6 +104,8 @@ do { \
# define lockdep_softirq_exit() do { } while (0)
# define lockdep_hrtimer_enter(__hrtimer) do { } while (0)
# define lockdep_hrtimer_exit(__hrtimer) do { } while (0)
+# define lockdep_posixtimer_enter() do { } while (0)
+# define lockdep_posixtimer_exit() do { } while (0)
# define lockdep_irq_work_enter(__work) do { } while (0)
# define lockdep_irq_work_exit(__work) do { } while (0)
#endif
--- a/kernel/time/posix-cpu-timers.c
+++ b/kernel/time/posix-cpu-timers.c
@@ -1126,8 +1126,11 @@ void run_posix_cpu_timers(void)
if (!fastpath_timer_check(tsk))
return;
- if (!lock_task_sighand(tsk, &flags))
+ lockdep_posixtimer_enter();
+ if (!lock_task_sighand(tsk, &flags)) {
+ lockdep_posixtimer_exit();
return;
+ }
/*
* Here we take off tsk->signal->cpu_timers[N] and
* tsk->cpu_timers[N] all the timers that are firing, and
@@ -1169,6 +1172,7 @@ void run_posix_cpu_timers(void)
cpu_timer_fire(timer);
spin_unlock(&timer->it_lock);
}
+ lockdep_posixtimer_exit();
}
/*
^ permalink raw reply
* Re: [PATCH 2/5] csky: Remove mm.h from asm/uaccess.h
From: Guo Ren @ 2020-03-21 11:24 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: Randy Dunlap, Peter Zijlstra, linux-pci,
Linux Kernel Mailing List, joel, Will Deacon, mingo, dave,
Arnd Bergmann, linux-csky, torvalds, paulmck, linuxppc-dev,
Steven Rostedt, bhelgaas, kurt.schwemmer, kvalo,
kbuild test robot, balbi, gregkh, linux-usb, linux-wireless, oleg,
Thomas Gleixner, netdev, logang, David Miller
In-Reply-To: <20200320094856.3453859-3-bigeasy@linutronix.de>
Tested and Acked by me.
Queued for next pull request, thx
On Fri, Mar 20, 2020 at 5:49 PM Sebastian Andrzej Siewior
<bigeasy@linutronix.de> wrote:
>
> The defconfig compiles without linux/mm.h. With mm.h included the
> include chain leands to:
> | CC kernel/locking/percpu-rwsem.o
> | In file included from include/linux/huge_mm.h:8,
> | from include/linux/mm.h:567,
> | from arch/csky/include/asm/uaccess.h:,
> | from include/linux/uaccess.h:11,
> | from include/linux/sched/task.h:11,
> | from include/linux/sched/signal.h:9,
> | from include/linux/rcuwait.h:6,
> | from include/linux/percpu-rwsem.h:8,
> | from kernel/locking/percpu-rwsem.c:6:
> | include/linux/fs.h:1422:29: error: array type has incomplete element type 'struct percpu_rw_semaphore'
> | 1422 | struct percpu_rw_semaphore rw_sem[SB_FREEZE_LEVELS];
>
> once rcuwait.h includes linux/sched/signal.h.
>
> Remove the linux/mm.h include.
>
> Cc: Guo Ren <guoren@kernel.org>
> Cc: linux-csky@vger.kernel.org
> Reported-by: kbuild test robot <lkp@intel.com>
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> ---
> arch/csky/include/asm/uaccess.h | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/csky/include/asm/uaccess.h b/arch/csky/include/asm/uaccess.h
> index eaa1c3403a424..abefa125b93cf 100644
> --- a/arch/csky/include/asm/uaccess.h
> +++ b/arch/csky/include/asm/uaccess.h
> @@ -11,7 +11,6 @@
> #include <linux/errno.h>
> #include <linux/types.h>
> #include <linux/sched.h>
> -#include <linux/mm.h>
> #include <linux/string.h>
> #include <linux/version.h>
> #include <asm/segment.h>
> --
> 2.26.0.rc2
>
--
Best Regards
Guo Ren
ML: https://lore.kernel.org/linux-csky/
^ permalink raw reply
* Re: [PATCH 07/10] ARM: dts: tango4: Make /serial compatible with ns16550a
From: Måns Rullgård @ 2020-03-21 11:11 UTC (permalink / raw)
To: Lubomir Rintel
Cc: Mark Rutland, devicetree, Marc Gonzalez, Greg Kroah-Hartman,
linuxppc-dev, Haojian Zhuang, linux-kernel, Rob Herring,
Paul Mackerras, linux-serial, Robert Jarzmik, Daniel Mack
In-Reply-To: <20200320174107.29406-8-lkundrak@v3.sk>
Lubomir Rintel <lkundrak@v3.sk> writes:
> ralink,rt2880-uart is compatible with ns16550a and all other
> instances of RT2880 UART nodes include it in the compatible property.
> Add it also here, to make the binding schema simpler.
>
> Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Acked-by: Mans Rullgard <mans@mansr.com>
> ---
> arch/arm/boot/dts/tango4-common.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/tango4-common.dtsi b/arch/arm/boot/dts/tango4-common.dtsi
> index ff72a8efb73d0..54fd522badfc9 100644
> --- a/arch/arm/boot/dts/tango4-common.dtsi
> +++ b/arch/arm/boot/dts/tango4-common.dtsi
> @@ -85,7 +85,7 @@ tick-counter@10048 {
> };
>
> uart: serial@10700 {
> - compatible = "ralink,rt2880-uart";
> + compatible = "ralink,rt2880-uart", "ns16550a";
> reg = <0x10700 0x30>;
> interrupts = <1 IRQ_TYPE_LEVEL_HIGH>;
> clock-frequency = <7372800>;
> --
> 2.25.1
>
--
Måns Rullgård
^ permalink raw reply
* Re: [patch V2 07/15] powerpc/ps3: Convert half completion to rcuwait
From: Thomas Gleixner @ 2020-03-21 10:41 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-usb, Peter Zijlstra, linux-pci, Sebastian Andrzej Siewior,
Oleg Nesterov, Joel Fernandes, Will Deacon, Ingo Molnar,
Davidlohr Bueso, Paul E . McKenney, Logan Gunthorpe,
Linus Torvalds, Arnd Bergmann, Steven Rostedt, Bjorn Helgaas,
Kurt Schwemmer, Kalle Valo, Felipe Balbi, Greg Kroah-Hartman,
Randy Dunlap, linux-wireless, LKML, netdev, linuxppc-dev,
David S. Miller
In-Reply-To: <20200319100459.GA18506@infradead.org>
Christoph Hellwig <hch@infradead.org> writes:
> On Wed, Mar 18, 2020 at 09:43:09PM +0100, Thomas Gleixner wrote:
>> The PS3 notification interrupt and kthread use a hacked up completion to
>> communicate. Since we're wanting to change the completion implementation and
>> this is abuse anyway, replace it with a simple rcuwait since there is only ever
>> the one waiter.
>>
>> AFAICT the kthread uses TASK_INTERRUPTIBLE to not increase loadavg, kthreads
>> cannot receive signals by default and this one doesn't look different. Use
>> TASK_IDLE instead.
>
> I think the right fix here is to jut convert the thing to a threaded
> interrupt handler and kill off the stupid kthread.
That'd be a major surgery.
> But I wonder how alive the whole PS3 support is to start with..
There seem to be a few enthusiast left which have a Other-OS capable PS3
Thanks,
tglx
^ permalink raw reply
* [PATCH] powerpc/ptrace: Fix ptrace-hwbreak selftest failure
From: Christophe Leroy @ 2020-03-21 10:37 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
Pieces of commit c3f68b0478e7 ("powerpc/watchpoint: Fix ptrace
code that muck around with address/len") disappeared with
commit 53387e67d003 ("powerpc/ptrace: split out ADV_DEBUG_REGS
related functions.").
Restore them.
Fixes: 53387e67d003 ("powerpc/ptrace: split out ADV_DEBUG_REGS related functions.")
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
arch/powerpc/kernel/ptrace/ptrace-noadv.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/kernel/ptrace/ptrace-noadv.c b/arch/powerpc/kernel/ptrace/ptrace-noadv.c
index cf05fadba0d5..d4170932acb4 100644
--- a/arch/powerpc/kernel/ptrace/ptrace-noadv.c
+++ b/arch/powerpc/kernel/ptrace/ptrace-noadv.c
@@ -153,7 +153,7 @@ long ppc_set_hwdebug(struct task_struct *child, struct ppc_hw_breakpoint *bp_inf
if ((unsigned long)bp_info->addr >= TASK_SIZE)
return -EIO;
- brk.address = bp_info->addr & ~7UL;
+ brk.address = bp_info->addr & ~HW_BREAKPOINT_ALIGN;
brk.type = HW_BRK_TYPE_TRANSLATE;
brk.len = DABR_MAX_LEN;
if (bp_info->trigger_type & PPC_BREAKPOINT_TRIGGER_READ)
@@ -161,10 +161,6 @@ long ppc_set_hwdebug(struct task_struct *child, struct ppc_hw_breakpoint *bp_inf
if (bp_info->trigger_type & PPC_BREAKPOINT_TRIGGER_WRITE)
brk.type |= HW_BRK_TYPE_WRITE;
#ifdef CONFIG_HAVE_HW_BREAKPOINT
- /*
- * Check if the request is for 'range' breakpoints. We can
- * support it if range < 8 bytes.
- */
if (bp_info->addr_mode == PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE)
len = bp_info->addr2 - bp_info->addr;
else if (bp_info->addr_mode == PPC_BREAKPOINT_MODE_EXACT)
@@ -177,7 +173,7 @@ long ppc_set_hwdebug(struct task_struct *child, struct ppc_hw_breakpoint *bp_inf
/* Create a new breakpoint request if one doesn't exist already */
hw_breakpoint_init(&attr);
- attr.bp_addr = (unsigned long)bp_info->addr & ~HW_BREAKPOINT_ALIGN;
+ attr.bp_addr = (unsigned long)bp_info->addr;
attr.bp_len = len;
arch_bp_generic_fields(brk.type, &attr.bp_type);
--
2.25.0
^ permalink raw reply related
* Re: [PATCH v5 10/13] powerpc/ptrace: split out ADV_DEBUG_REGS related functions.
From: Christophe Leroy @ 2020-03-21 10:27 UTC (permalink / raw)
To: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras, mikey
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <87imizdbaz.fsf@mpe.ellerman.id.au>
On 03/20/2020 02:12 AM, Michael Ellerman wrote:
> Christophe Leroy <christophe.leroy@c-s.fr> writes:
>> Move ADV_DEBUG_REGS functions out of ptrace.c, into
>> ptrace-adv.c and ptrace-noadv.c
>>
>> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
>> ---
>> v4: Leave hw_breakpoint.h for ptrace.c
>> ---
>> arch/powerpc/kernel/ptrace/Makefile | 4 +
>> arch/powerpc/kernel/ptrace/ptrace-adv.c | 468 ++++++++++++++++
>> arch/powerpc/kernel/ptrace/ptrace-decl.h | 5 +
>> arch/powerpc/kernel/ptrace/ptrace-noadv.c | 236 ++++++++
>> arch/powerpc/kernel/ptrace/ptrace.c | 650 ----------------------
>> 5 files changed, 713 insertions(+), 650 deletions(-)
>> create mode 100644 arch/powerpc/kernel/ptrace/ptrace-adv.c
>> create mode 100644 arch/powerpc/kernel/ptrace/ptrace-noadv.c
>
> This is somehow breaking the ptrace-hwbreak selftest on Power8:
>
> test: ptrace-hwbreak
> tags: git_version:v5.6-rc6-892-g7a285a6067d6
> PTRACE_SET_DEBUGREG, WO, len: 1: Ok
> PTRACE_SET_DEBUGREG, WO, len: 2: Ok
> PTRACE_SET_DEBUGREG, WO, len: 4: Ok
> PTRACE_SET_DEBUGREG, WO, len: 8: Ok
> PTRACE_SET_DEBUGREG, RO, len: 1: Ok
> PTRACE_SET_DEBUGREG, RO, len: 2: Ok
> PTRACE_SET_DEBUGREG, RO, len: 4: Ok
> PTRACE_SET_DEBUGREG, RO, len: 8: Ok
> PTRACE_SET_DEBUGREG, RW, len: 1: Ok
> PTRACE_SET_DEBUGREG, RW, len: 2: Ok
> PTRACE_SET_DEBUGREG, RW, len: 4: Ok
> PTRACE_SET_DEBUGREG, RW, len: 8: Ok
> PPC_PTRACE_SETHWDEBUG, MODE_EXACT, WO, len: 1: Ok
> PPC_PTRACE_SETHWDEBUG, MODE_EXACT, RO, len: 1: Ok
> PPC_PTRACE_SETHWDEBUG, MODE_EXACT, RW, len: 1: Ok
> PPC_PTRACE_SETHWDEBUG, MODE_RANGE, DW ALIGNED, WO, len: 6: Ok
> PPC_PTRACE_SETHWDEBUG, MODE_RANGE, DW ALIGNED, RO, len: 6: Ok
> PPC_PTRACE_SETHWDEBUG, MODE_RANGE, DW ALIGNED, RW, len: 6: Ok
> PPC_PTRACE_SETHWDEBUG, MODE_RANGE, DW UNALIGNED, WO, len: 6: Ok
> PPC_PTRACE_SETHWDEBUG, MODE_RANGE, DW UNALIGNED, RO, len: 6: Fail
> failure: ptrace-hwbreak
>
> I haven't had time to work out why yet.
>
A (big) part of commit c3f68b0478e7 ("powerpc/watchpoint: Fix ptrace
code that muck around with address/len") was lost during rebase.
I'll send a fix, up to you to squash it in or commit it as is.
Christophe
^ permalink raw reply
* Re: [patch V2 08/15] Documentation: Add lock ordering and nesting documentation
From: Thomas Gleixner @ 2020-03-21 10:26 UTC (permalink / raw)
To: paulmck
Cc: Randy Dunlap, Peter Zijlstra, linux-pci,
Sebastian Andrzej Siewior, Oleg Nesterov, Joel Fernandes,
Will Deacon, Ingo Molnar, Davidlohr Bueso, Logan Gunthorpe,
Arnd Bergmann, linuxppc-dev, Steven Rostedt, Bjorn Helgaas,
Kurt Schwemmer, Kalle Valo, Felipe Balbi, Greg Kroah-Hartman,
linux-usb, linux-wireless, LKML, netdev, Linus Torvalds,
David S. Miller
In-Reply-To: <20200321022930.GU3199@paulmck-ThinkPad-P72>
"Paul E. McKenney" <paulmck@kernel.org> writes:
> On Fri, Mar 20, 2020 at 11:36:03PM +0100, Thomas Gleixner wrote:
>> I agree that what I tried to express is hard to parse, but it's at least
>> halfways correct :)
>
> Apologies! That is what I get for not looking it up in the source. :-/
>
> OK, so I am stupid enough not only to get it wrong, but also to try again:
>
> ... Other types of wakeups would normally unconditionally set the
> task state to RUNNING, but that does not work here because the task
> must remain blocked until the lock becomes available. Therefore,
> when a non-lock wakeup attempts to awaken a task blocked waiting
> for a spinlock, it instead sets the saved state to RUNNING. Then,
> when the lock acquisition completes, the lock wakeup sets the task
> state to the saved state, in this case setting it to RUNNING.
>
> Is that better?
Definitely!
Thanks for all the editorial work!
tglx
^ permalink raw reply
* [powerpc:fixes-test] BUILD SUCCESS 1d0c32ec3b860a32df593a22bad0d1dbc5546a59
From: kbuild test robot @ 2020-03-21 8:49 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git fixes-test
branch HEAD: 1d0c32ec3b860a32df593a22bad0d1dbc5546a59 KVM: PPC: Fix kernel crash with PR KVM
elapsed time: 1740m
configs tested: 226
configs skipped: 154
The following configs have been built successfully.
More configs may be tested in the coming days.
arm allmodconfig
arm allnoconfig
arm allyesconfig
arm64 allmodconfig
arm64 allnoconfig
arm64 allyesconfig
arm at91_dt_defconfig
arm efm32_defconfig
arm exynos_defconfig
arm multi_v5_defconfig
arm multi_v7_defconfig
arm shmobile_defconfig
arm sunxi_defconfig
arm64 defconfig
sparc allyesconfig
nds32 defconfig
powerpc allnoconfig
sh allnoconfig
riscv defconfig
ia64 allyesconfig
nds32 allnoconfig
sh rsk7269_defconfig
nios2 3c120_defconfig
parisc generic-32bit_defconfig
riscv rv32_defconfig
microblaze nommu_defconfig
sparc defconfig
m68k allmodconfig
s390 allmodconfig
i386 alldefconfig
i386 allnoconfig
i386 allyesconfig
i386 defconfig
ia64 alldefconfig
ia64 allmodconfig
ia64 allnoconfig
ia64 defconfig
c6x allyesconfig
c6x evmc6678_defconfig
nios2 10m50_defconfig
openrisc or1ksim_defconfig
openrisc simple_smp_defconfig
xtensa common_defconfig
xtensa iss_defconfig
h8300 edosk2674_defconfig
h8300 h8300h-sim_defconfig
h8300 h8s-sim_defconfig
m68k m5475evb_defconfig
m68k sun3_defconfig
m68k multi_defconfig
arc allyesconfig
arc defconfig
microblaze mmu_defconfig
powerpc defconfig
powerpc ppc64_defconfig
powerpc rhel-kconfig
mips 32r2_defconfig
mips 64r6el_defconfig
mips allmodconfig
mips allnoconfig
mips allyesconfig
mips fuloong2e_defconfig
mips malta_kvm_defconfig
parisc allnoconfig
parisc allyesconfig
parisc generic-64bit_defconfig
x86_64 randconfig-a001-20200320
x86_64 randconfig-a002-20200320
x86_64 randconfig-a003-20200320
i386 randconfig-a001-20200320
i386 randconfig-a002-20200320
i386 randconfig-a003-20200320
x86_64 randconfig-a001-20200321
x86_64 randconfig-a002-20200321
x86_64 randconfig-a003-20200321
i386 randconfig-a001-20200321
i386 randconfig-a002-20200321
i386 randconfig-a003-20200321
alpha randconfig-a001-20200320
m68k randconfig-a001-20200320
mips randconfig-a001-20200320
nds32 randconfig-a001-20200320
parisc randconfig-a001-20200320
alpha randconfig-a001-20200321
m68k randconfig-a001-20200321
mips randconfig-a001-20200321
nds32 randconfig-a001-20200321
parisc randconfig-a001-20200321
riscv randconfig-a001-20200321
c6x randconfig-a001-20200321
h8300 randconfig-a001-20200321
microblaze randconfig-a001-20200321
nios2 randconfig-a001-20200321
sparc64 randconfig-a001-20200321
c6x randconfig-a001-20200320
h8300 randconfig-a001-20200320
microblaze randconfig-a001-20200320
nios2 randconfig-a001-20200320
sparc64 randconfig-a001-20200320
csky randconfig-a001-20200320
openrisc randconfig-a001-20200320
s390 randconfig-a001-20200320
sh randconfig-a001-20200320
xtensa randconfig-a001-20200320
csky randconfig-a001-20200321
openrisc randconfig-a001-20200321
s390 randconfig-a001-20200321
sh randconfig-a001-20200321
xtensa randconfig-a001-20200321
x86_64 randconfig-b001-20200320
x86_64 randconfig-b002-20200320
x86_64 randconfig-b003-20200320
i386 randconfig-b001-20200320
i386 randconfig-b002-20200320
i386 randconfig-b003-20200320
x86_64 randconfig-b001-20200321
x86_64 randconfig-b002-20200321
x86_64 randconfig-b003-20200321
i386 randconfig-b001-20200321
i386 randconfig-b002-20200321
i386 randconfig-b003-20200321
x86_64 randconfig-c001-20200320
x86_64 randconfig-c002-20200320
x86_64 randconfig-c003-20200320
i386 randconfig-c001-20200320
i386 randconfig-c002-20200320
i386 randconfig-c003-20200320
x86_64 randconfig-c001-20200321
x86_64 randconfig-c002-20200321
x86_64 randconfig-c003-20200321
i386 randconfig-c001-20200321
i386 randconfig-c002-20200321
i386 randconfig-c003-20200321
x86_64 randconfig-d001-20200320
x86_64 randconfig-d002-20200320
x86_64 randconfig-d003-20200320
i386 randconfig-d001-20200320
i386 randconfig-d002-20200320
i386 randconfig-d003-20200320
x86_64 randconfig-d001-20200321
x86_64 randconfig-d002-20200321
x86_64 randconfig-d003-20200321
i386 randconfig-d001-20200321
i386 randconfig-d002-20200321
i386 randconfig-d003-20200321
x86_64 randconfig-e001-20200321
x86_64 randconfig-e002-20200321
x86_64 randconfig-e003-20200321
i386 randconfig-e001-20200321
i386 randconfig-e002-20200321
i386 randconfig-e003-20200321
x86_64 randconfig-e001-20200320
x86_64 randconfig-e002-20200320
x86_64 randconfig-e003-20200320
i386 randconfig-e001-20200320
i386 randconfig-e002-20200320
i386 randconfig-e003-20200320
x86_64 randconfig-f001-20200320
x86_64 randconfig-f002-20200320
x86_64 randconfig-f003-20200320
i386 randconfig-f001-20200320
i386 randconfig-f002-20200320
i386 randconfig-f003-20200320
x86_64 randconfig-f001-20200321
x86_64 randconfig-f002-20200321
x86_64 randconfig-f003-20200321
i386 randconfig-f001-20200321
i386 randconfig-f002-20200321
i386 randconfig-f003-20200321
x86_64 randconfig-g001-20200320
x86_64 randconfig-g002-20200320
x86_64 randconfig-g003-20200320
i386 randconfig-g001-20200320
i386 randconfig-g002-20200320
i386 randconfig-g003-20200320
x86_64 randconfig-g001-20200321
x86_64 randconfig-g002-20200321
x86_64 randconfig-g003-20200321
i386 randconfig-g001-20200321
i386 randconfig-g002-20200321
i386 randconfig-g003-20200321
x86_64 randconfig-h001-20200320
x86_64 randconfig-h002-20200320
x86_64 randconfig-h003-20200320
i386 randconfig-h001-20200320
i386 randconfig-h002-20200320
i386 randconfig-h003-20200320
x86_64 randconfig-h001-20200321
x86_64 randconfig-h002-20200321
x86_64 randconfig-h003-20200321
i386 randconfig-h001-20200321
i386 randconfig-h002-20200321
i386 randconfig-h003-20200321
arc randconfig-a001-20200320
arm randconfig-a001-20200320
arm64 randconfig-a001-20200320
ia64 randconfig-a001-20200320
powerpc randconfig-a001-20200320
sparc randconfig-a001-20200320
arm randconfig-a001-20200321
arm64 randconfig-a001-20200321
ia64 randconfig-a001-20200321
powerpc randconfig-a001-20200321
riscv allmodconfig
riscv allnoconfig
riscv allyesconfig
riscv nommu_virt_defconfig
s390 alldefconfig
s390 allnoconfig
s390 allyesconfig
s390 debug_defconfig
s390 defconfig
s390 zfcpdump_defconfig
sh allmodconfig
sh sh7785lcr_32bit_defconfig
sh titan_defconfig
sparc64 allmodconfig
sparc64 allnoconfig
sparc64 allyesconfig
sparc64 defconfig
x86_64 fedora-25
x86_64 kexec
x86_64 lkp
x86_64 rhel
x86_64 rhel-7.2-clear
x86_64 rhel-7.6
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: [PATCH] powerpc/pseries: avoid harmless preempt warning
From: Nicholas Piggin @ 2020-03-21 6:34 UTC (permalink / raw)
To: Christophe Leroy, linuxppc-dev
In-Reply-To: <6b34ba18-de6b-15c5-1611-fb5c92e065f9@c-s.fr>
Christophe Leroy's on March 21, 2020 1:33 am:
>
>
> Le 20/03/2020 à 16:24, Nicholas Piggin a écrit :
>> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
>> ---
>> arch/powerpc/platforms/pseries/lpar.c | 10 +++++++++-
>> 1 file changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/platforms/pseries/lpar.c b/arch/powerpc/platforms/pseries/lpar.c
>> index 3c3da25b445c..e4ed5317f117 100644
>> --- a/arch/powerpc/platforms/pseries/lpar.c
>> +++ b/arch/powerpc/platforms/pseries/lpar.c
>> @@ -636,8 +636,16 @@ static const struct proc_ops vcpudispatch_stats_freq_proc_ops = {
>>
>> static int __init vcpudispatch_stats_procfs_init(void)
>> {
>> - if (!lppaca_shared_proc(get_lppaca()))
>> + /*
>> + * Avoid smp_processor_id while preemptible. All CPUs should have
>> + * the same value for lppaca_shared_proc.
>> + */
>> + preempt_disable();
>> + if (!lppaca_shared_proc(get_lppaca())) {
>> + preempt_enable();
>> return 0;
>> + }
>> + preempt_enable();
>
> Can we avoid the double preempt_enable() with something like:
>
> preempt_disable();
> is_shared = lppaca_shared_proc(get_lppaca());
> preempt_enable();
> if (!is_shared)
> return 0;
I don't mind too much. Same number of lines.
Thanks,
Nick
^ permalink raw reply
* Re: [PATCH] powerpc/64: ftrace don't trace real mode
From: Nicholas Piggin @ 2020-03-21 6:32 UTC (permalink / raw)
To: linuxppc-dev, Naveen N. Rao
In-Reply-To: <1584728788.91gvyrzbi3.naveen@linux.ibm.com>
Naveen N. Rao's on March 21, 2020 4:39 am:
> Hi Nick,
>
> Nicholas Piggin wrote:
>> This warns and prevents tracing attempted in a real-mode context.
>
> Is this something you're seeing often? Last time we looked at this, KVM
> was the biggest offender and we introduced paca->ftrace_enabled as a way
> to disable ftrace while in KVM code.
Not often but it has a tendancy to blow up the least tested code at the
worst times :)
Machine check is bad, I'm sure HMI too but I haven't tested that yet.
I've fixed up most of it with annotations, this is obviously an extra
safety not something to rely on like ftrace_enabled. Probably even the
WARN_ON here is dangerous here, but I don't want to leave these bugs
in there.
Although the machine check and hmi code touch a fair bit of stuff and
annotating is a bit fragile. It might actually be better if the
paca->ftrace_enabled could be a nesting counter, then we could use it
in machine checks too and avoid a lot of annotations.
> While this is cheap when handling ftrace_regs_caller() as done in this
> patch, for simple function tracing (see below), we will have to grab the
> MSR which will slow things down slightly.
mfmsr is not too bad these days.
>
>>
>> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
>> ---
>> arch/powerpc/kernel/trace/ftrace.c | 3 +++
>> .../powerpc/kernel/trace/ftrace_64_mprofile.S | 19 +++++++++++++++----
>> 2 files changed, 18 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/powerpc/kernel/trace/ftrace.c b/arch/powerpc/kernel/trace/ftrace.c
>> index 7ea0ca044b65..ef965815fcb9 100644
>> --- a/arch/powerpc/kernel/trace/ftrace.c
>> +++ b/arch/powerpc/kernel/trace/ftrace.c
>> @@ -949,6 +949,9 @@ unsigned long prepare_ftrace_return(unsigned long parent, unsigned long ip,
>> {
>> unsigned long return_hooker;
>>
>> + if (WARN_ON_ONCE((mfmsr() & (MSR_IR|MSR_DR)) != (MSR_IR|MSR_DR)))
>> + goto out;
>> +
>
> This is called on function entry to redirect function return to a
> trampoline if needed. I am not sure if we have (or will have) too many C
> functions that disable MSR_IR|MSR_DR. Unless the number of such
> functions is large, it might be preferable to mark specific functions as
> notrace.
>
>> if (unlikely(ftrace_graph_is_dead()))
>> goto out;
>>
>> diff --git a/arch/powerpc/kernel/trace/ftrace_64_mprofile.S b/arch/powerpc/kernel/trace/ftrace_64_mprofile.S
>> index f9fd5f743eba..6205f15cb603 100644
>> --- a/arch/powerpc/kernel/trace/ftrace_64_mprofile.S
>> +++ b/arch/powerpc/kernel/trace/ftrace_64_mprofile.S
>> @@ -51,16 +51,21 @@ _GLOBAL(ftrace_regs_caller)
>> SAVE_10GPRS(12, r1)
>> SAVE_10GPRS(22, r1)
>>
>> - /* Save previous stack pointer (r1) */
>> - addi r8, r1, SWITCH_FRAME_SIZE
>> - std r8, GPR1(r1)
>> -
>> /* Load special regs for save below */
>> mfmsr r8
>> mfctr r9
>> mfxer r10
>> mfcr r11
>>
>> + /* Shouldn't be called in real mode */
>> + andi. r3,r8,(MSR_IR|MSR_DR)
>> + cmpdi r3,(MSR_IR|MSR_DR)
>> + bne ftrace_bad_realmode
>> +
>> + /* Save previous stack pointer (r1) */
>> + addi r8, r1, SWITCH_FRAME_SIZE
>> + std r8, GPR1(r1)
>> +
>
> This stomps on the MSR value in r8, which is saved into pt_regs further
> below.
>
> You'll also have to handle ftrace_caller() which is used for simple
> function tracing. We don't read the MSR there today, but that will be
> needed if we want to suppress tracing.
Oops, thanks good catch.
Thanks,
Nick
^ permalink raw reply
* Re: [patch V2 08/15] Documentation: Add lock ordering and nesting documentation
From: Paul E. McKenney @ 2020-03-21 2:29 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Randy Dunlap, Peter Zijlstra, linux-pci,
Sebastian Andrzej Siewior, Oleg Nesterov, Joel Fernandes,
Will Deacon, Ingo Molnar, Davidlohr Bueso, Logan Gunthorpe,
Arnd Bergmann, linuxppc-dev, Steven Rostedt, Bjorn Helgaas,
Kurt Schwemmer, Kalle Valo, Felipe Balbi, Greg Kroah-Hartman,
linux-usb, linux-wireless, LKML, netdev, Linus Torvalds,
David S. Miller
In-Reply-To: <874kuipsbw.fsf@nanos.tec.linutronix.de>
On Fri, Mar 20, 2020 at 11:36:03PM +0100, Thomas Gleixner wrote:
> "Paul E. McKenney" <paulmck@kernel.org> writes:
> > On Fri, Mar 20, 2020 at 08:51:44PM +0100, Thomas Gleixner wrote:
> >> "Paul E. McKenney" <paulmck@kernel.org> writes:
> >> >
> >> > - The soft interrupt related suffix (_bh()) still disables softirq
> >> > handlers. However, unlike non-PREEMPT_RT kernels (which disable
> >> > preemption to get this effect), PREEMPT_RT kernels use a per-CPU
> >> > lock to exclude softirq handlers.
> >>
> >> I've made that:
> >>
> >> - The soft interrupt related suffix (_bh()) still disables softirq
> >> handlers.
> >>
> >> Non-PREEMPT_RT kernels disable preemption to get this effect.
> >>
> >> PREEMPT_RT kernels use a per-CPU lock for serialization. The lock
> >> disables softirq handlers and prevents reentrancy by a preempting
> >> task.
> >
> > That works! At the end, I would instead say "prevents reentrancy
> > due to task preemption", but what you have works.
>
> Yours is better.
>
> >> - Task state is preserved across spinlock acquisition, ensuring that the
> >> task-state rules apply to all kernel configurations. Non-PREEMPT_RT
> >> kernels leave task state untouched. However, PREEMPT_RT must change
> >> task state if the task blocks during acquisition. Therefore, it
> >> saves the current task state before blocking and the corresponding
> >> lock wakeup restores it. A regular not lock related wakeup sets the
> >> task state to RUNNING. If this happens while the task is blocked on
> >> a spinlock then the saved task state is changed so that correct
> >> state is restored on lock wakeup.
> >>
> >> Hmm?
> >
> > I of course cannot resist editing the last two sentences:
> >
> > ... Other types of wakeups unconditionally set task state to RUNNING.
> > If this happens while a task is blocked while acquiring a spinlock,
> > then the task state is restored to its pre-acquisition value at
> > lock-wakeup time.
>
> Errm no. That would mean
>
> state = UNINTERRUPTIBLE
> lock()
> block()
> real_state = state
> state = SLEEPONLOCK
>
> non lock wakeup
> state = RUNNING <--- FAIL #1
>
> lock wakeup
> state = real_state <--- FAIL #2
>
> How it works is:
>
> state = UNINTERRUPTIBLE
> lock()
> block()
> real_state = state
> state = SLEEPONLOCK
>
> non lock wakeup
> real_state = RUNNING
>
> lock wakeup
> state = real_state == RUNNING
>
> If there is no 'non lock wakeup' before the lock wakeup:
>
> state = UNINTERRUPTIBLE
> lock()
> block()
> real_state = state
> state = SLEEPONLOCK
>
> lock wakeup
> state = real_state == UNINTERRUPTIBLE
>
> I agree that what I tried to express is hard to parse, but it's at least
> halfways correct :)
Apologies! That is what I get for not looking it up in the source. :-/
OK, so I am stupid enough not only to get it wrong, but also to try again:
... Other types of wakeups would normally unconditionally set the
task state to RUNNING, but that does not work here because the task
must remain blocked until the lock becomes available. Therefore,
when a non-lock wakeup attempts to awaken a task blocked waiting
for a spinlock, it instead sets the saved state to RUNNING. Then,
when the lock acquisition completes, the lock wakeup sets the task
state to the saved state, in this case setting it to RUNNING.
Is that better?
Thanx, Paul
^ permalink raw reply
* Re: [PATCH 2/2] KVM: PPC: Book3S HV: H_SVM_INIT_START must call UV_RETURN
From: Ram Pai @ 2020-03-21 0:47 UTC (permalink / raw)
To: Laurent Dufour; +Cc: linuxppc-dev, linux-kernel, kvm-ppc, Bharata B Rao
In-Reply-To: <20200320102643.15516-3-ldufour@linux.ibm.com>
On Fri, Mar 20, 2020 at 11:26:43AM +0100, Laurent Dufour wrote:
> When the call to UV_REGISTER_MEM_SLOT is failing, for instance because
> there is not enough free secured memory, the Hypervisor (HV) has to call
secure memory,
> UV_RETURN to report the error to the Ultravisor (UV). Then the UV will call
> H_SVM_INIT_ABORT to abort the securing phase and go back to the calling VM.
>
> If the kvm->arch.secure_guest is not set, in the return path rfid is called
> but there is no valid context to get back to the SVM since the Hcall has
> been routed by the Ultravisor.
>
> Move the setting of kvm->arch.secure_guest earlier in
> kvmppc_h_svm_init_start() so in the return path, UV_RETURN will be called
> instead of rfid.
>
> Cc: Bharata B Rao <bharata@linux.ibm.com>
> Cc: Paul Mackerras <paulus@ozlabs.org>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com>
Reviewed-by: Ram Pai <linuxram@us.ibm.com>
^ permalink raw reply
* Re: [PATCH 1/2] KVM: PPC: Book3S HV: check caller of H_SVM_* Hcalls
From: Ram Pai @ 2020-03-21 0:40 UTC (permalink / raw)
To: Laurent Dufour; +Cc: linuxppc-dev, linux-kernel, kvm-ppc, Bharata B Rao
In-Reply-To: <20200320102643.15516-2-ldufour@linux.ibm.com>
On Fri, Mar 20, 2020 at 11:26:42AM +0100, Laurent Dufour wrote:
> The Hcall named H_SVM_* are reserved to the Ultravisor. However, nothing
> prevent a malicious VM or SVM to call them. This could lead to weird result
> and should be filtered out.
>
> Checking the Secure bit of the calling MSR ensure that the call is coming
> from either the Ultravisor or a SVM. But any system call made from a SVM
> are going through the Ultravisor, and the Ultravisor should filter out
> these malicious call. This way, only the Ultravisor is able to make such a
> Hcall.
>
> Cc: Bharata B Rao <bharata@linux.ibm.com>
> Cc: Paul Mackerras <paulus@ozlabs.org>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com>
Reviewed-by: Ram Pai <linuxram@us.ibnm.com>
> ---
> arch/powerpc/kvm/book3s_hv.c | 32 +++++++++++++++++++++-----------
> 1 file changed, 21 insertions(+), 11 deletions(-)
>
^ permalink raw reply
* Re: [PATCH v2 0/2] Don't generate thousands of new warnings when building docs
From: Jonathan Corbet @ 2020-03-20 23:10 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Ricardo Ribalda Delgado, Linux Doc Mailing List, target-devel,
Paul Mackerras, H. Peter Anvin, Alex Shi, linux-scsi, x86,
Tyler Hicks, Ingo Molnar, Jakub Kicinski, Jacopo Mondi,
Luca Ceresoli, Johannes Berg, ecryptfs, Matthias Maennich,
dmaengine, Borislav Petkov, Thomas Gleixner, Martin K. Petersen,
netdev, linux-kernel, Vinod Koul, Harry Wei, Greg Kroah-Hartman,
Hans Verkuil, linuxppc-dev, David S. Miller, Madhuparna Bhowmik
In-Reply-To: <cover.1584716446.git.mchehab+huawei@kernel.org>
On Fri, 20 Mar 2020 16:11:01 +0100
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:
> This small series address a regression caused by a new patch at
> docs-next (and at linux-next).
I don't know how I missed that mess, sorry. I plead distracting times or
something like that. Heck, I think I'll blame everything on the plague
for at least the next few weeks.
Anyway, I've applied this, thanks for cleaning it up.
jon
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox