Re: [PATCH v1 13/13] xen: introduce a Kconfig option to enable the pvcalls frontend

On Mon, 24 Jul 2017, Juergen Gross wrote: > On 22/07/17 02:12, Stefano Stabellini wrote: > > Also add pvcalls-front to the Makefile. > > > > Signed-off-by: Stefano Stabellini > > CC: boris.ostrov...@oracle.com > > CC: jgr...@suse.com > > --- > > drivers/xen/Kconfig | 9

Re: [PATCH v1 13/13] xen: introduce a Kconfig option to enable the pvcalls frontend

On Mon, 24 Jul 2017, Juergen Gross wrote: > On 22/07/17 02:12, Stefano Stabellini wrote: > > Also add pvcalls-front to the Makefile. > > > > Signed-off-by: Stefano Stabellini > > CC: boris.ostrov...@oracle.com > > CC: jgr...@suse.com > > --- > > drivers/xen/Kconfig | 9 + > >

RCU stall warnings...

Paul and other RCU experts, Starting with 4.13-rc1 we're getting RCU stall dumps on sparc64, they definitely didn't happen in 4.12 I tried to look for low hanging fruit in the kernel/rcu/ changes this merge window, but nothing really stood out for me. This only seems to trigger when the system

RCU stall warnings...

Paul and other RCU experts, Starting with 4.13-rc1 we're getting RCU stall dumps on sparc64, they definitely didn't happen in 4.12 I tried to look for low hanging fruit in the kernel/rcu/ changes this merge window, but nothing really stood out for me. This only seems to trigger when the system

Re: [PATCH v1 01/13] xen/pvcalls: introduce the pvcalls xenbus frontend

On Mon, 24 Jul 2017, Juergen Gross wrote: > On 22/07/17 02:11, Stefano Stabellini wrote: > > Introduce a xenbus frontend for the pvcalls protocol, as defined by > > https://xenbits.xen.org/docs/unstable/misc/pvcalls.html. > > > > This patch only adds the stubs, the code will be added by the

Re: [PATCH v1 01/13] xen/pvcalls: introduce the pvcalls xenbus frontend

On Mon, 24 Jul 2017, Juergen Gross wrote: > On 22/07/17 02:11, Stefano Stabellini wrote: > > Introduce a xenbus frontend for the pvcalls protocol, as defined by > > https://xenbits.xen.org/docs/unstable/misc/pvcalls.html. > > > > This patch only adds the stubs, the code will be added by the

Re: [PATCH tip/core/rcu 5/5] EXP: sched/cputime: Fix using smp_processor_id() in preemptible

On Tue, Jul 25, 2017 at 06:01:55AM +0800, Wanpeng Li wrote: > 2017-07-25 5:58 GMT+08:00 Paul E. McKenney : > > From: Wanpeng Li > > > > BUG: using smp_processor_id() in preemptible [] code: > > 99-trinity/181 > > What's the meaning of

Re: [PATCH tip/core/rcu 5/5] EXP: sched/cputime: Fix using smp_processor_id() in preemptible

On Tue, Jul 25, 2017 at 06:01:55AM +0800, Wanpeng Li wrote: > 2017-07-25 5:58 GMT+08:00 Paul E. McKenney : > > From: Wanpeng Li > > > > BUG: using smp_processor_id() in preemptible [] code: > > 99-trinity/181 > > What's the meaning of EXP? Btw, the patch is in linus's tree currently.

Re: [PATCH 07/11] mfd: Drop unnecessary static

On Mon, Jul 24, 2017 at 12:20 PM, Pavel Machek wrote: > Hi! > >> > > Drop static on a local variable, when the variable is initialized before >> > > any possible use. Thus, the static has no benefit. > > Actually... it has possible other benefit -- saving stack space. I've > used

Re: [PATCH 07/11] mfd: Drop unnecessary static

On Mon, Jul 24, 2017 at 12:20 PM, Pavel Machek wrote: > Hi! > >> > > Drop static on a local variable, when the variable is initialized before >> > > any possible use. Thus, the static has no benefit. > > Actually... it has possible other benefit -- saving stack space. I've > used static for that

[PATCH tip/core/rcu 08/13] rcutorture: Place event-traced strings into trace buffer

Strings used in event tracing need to be specially handled, for example, being copied to the trace buffer instead of being pointed to by the trace buffer. Although the TPS() macro can be used to "launder" pointed-to strings, this might not be all that effective within a loadable module. This

[PATCH tip/core/rcu 08/13] rcutorture: Place event-traced strings into trace buffer

Strings used in event tracing need to be specially handled, for example, being copied to the trace buffer instead of being pointed to by the trace buffer. Although the TPS() macro can be used to "launder" pointed-to strings, this might not be all that effective within a loadable module. This

[PATCH] mwifiex: usb: fix spelling mistake: "aggreataon"-> "aggregation"

From: Colin Ian King Trivial fix to spelling mistake in aggr_ctrl module parameter message text. Signed-off-by: Colin Ian King --- drivers/net/wireless/marvell/mwifiex/main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH] mwifiex: usb: fix spelling mistake: "aggreataon"-> "aggregation"

From: Colin Ian King Trivial fix to spelling mistake in aggr_ctrl module parameter message text. Signed-off-by: Colin Ian King --- drivers/net/wireless/marvell/mwifiex/main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/marvell/mwifiex/main.c

[PATCH tip/core/rcu 03/13] rcu: Remove CONFIG_TASKS_RCU ifdef from rcuperf.c

The synchronize_rcu_tasks() and call_rcu_tasks() APIs are now available regardless of kernel configuration, so this commit removes the CONFIG_TASKS_RCU ifdef from rcuperf.c. Signed-off-by: Paul E. McKenney --- kernel/rcu/rcuperf.c | 17 + 1 file

[PATCH tip/core/rcu 03/13] rcu: Remove CONFIG_TASKS_RCU ifdef from rcuperf.c

The synchronize_rcu_tasks() and call_rcu_tasks() APIs are now available regardless of kernel configuration, so this commit removes the CONFIG_TASKS_RCU ifdef from rcuperf.c. Signed-off-by: Paul E. McKenney --- kernel/rcu/rcuperf.c | 17 + 1 file changed, 1 insertion(+), 16

[PATCH tip/core/rcu 11/13] rcutorture: Eliminate unused ts_rem local from rcu_trace_clock_local()

This commit removes an unused local variable named ts_rem that is marked __maybe_unused. Yes, the variable was assigned to, but it was never used beyond that point, hence not needed. Signed-off-by: Paul E. McKenney --- kernel/rcu/rcutorture.c | 3 ++- 1 file

[PATCH tip/core/rcu 11/13] rcutorture: Eliminate unused ts_rem local from rcu_trace_clock_local()

This commit removes an unused local variable named ts_rem that is marked __maybe_unused. Yes, the variable was assigned to, but it was never used beyond that point, hence not needed. Signed-off-by: Paul E. McKenney --- kernel/rcu/rcutorture.c | 3 ++- 1 file changed, 2 insertions(+), 1

[PATCH tip/core/rcu 10/13] rcutorture: Add task's CPU for rcutorture writer stalls

It appears that at least some of the rcutorture writer stall messages coincide with unusually long CPU-online operations, for example, no fewer than 205 seconds in a recent test. It is of course possible that the writer stall is not unrelated to this unusually long CPU-hotplug operation, and so

[PATCH tip/core/rcu 10/13] rcutorture: Add task's CPU for rcutorture writer stalls

It appears that at least some of the rcutorture writer stall messages coincide with unusually long CPU-online operations, for example, no fewer than 205 seconds in a recent test. It is of course possible that the writer stall is not unrelated to this unusually long CPU-hotplug operation, and so

[PATCH tip/core/rcu 09/13] rcutorture: Use nr_cpus rather than maxcpus to limit test size

The maxcpus= kernel boot parameter limits the number of CPUs brought online at boot time, but it does nothing to prevent additional CPUs from being brought up later. Placing a hard cap on the total number of CPUs is instead the job of the nr_cpus= boot parameter. This commit therefore switches

[PATCH tip/core/rcu 09/13] rcutorture: Use nr_cpus rather than maxcpus to limit test size

The maxcpus= kernel boot parameter limits the number of CPUs brought online at boot time, but it does nothing to prevent additional CPUs from being brought up later. Placing a hard cap on the total number of CPUs is instead the job of the nr_cpus= boot parameter. This commit therefore switches

[PATCH tip/core/rcu 04/13] rcutorture: Select CONFIG_PROVE_LOCKING for Tiny SRCU scenario

This commit selects CONFIG_PROVE_LOCKING for the SRCU-u scenario to get better test coverage. Signed-off-by: Paul E. McKenney --- tools/testing/selftests/rcutorture/configs/rcu/SRCU-u | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

[PATCH tip/core/rcu 01/13] rcutorture: Move SRCU status printing to SRCU implementations

This commit gets rid of some ugly #ifdefs in rcutorture.c by moving the SRCU status printing to the SRCU implementations. Signed-off-by: Paul E. McKenney --- include/linux/srcutiny.h | 13 + include/linux/srcutree.h | 1 + kernel/rcu/rcutorture.c | 39

[PATCH tip/core/rcu 01/13] rcutorture: Move SRCU status printing to SRCU implementations

This commit gets rid of some ugly #ifdefs in rcutorture.c by moving the SRCU status printing to the SRCU implementations. Signed-off-by: Paul E. McKenney --- include/linux/srcutiny.h | 13 + include/linux/srcutree.h | 1 + kernel/rcu/rcutorture.c | 39

[PATCH tip/core/rcu 04/13] rcutorture: Select CONFIG_PROVE_LOCKING for Tiny SRCU scenario

This commit selects CONFIG_PROVE_LOCKING for the SRCU-u scenario to get better test coverage. Signed-off-by: Paul E. McKenney --- tools/testing/selftests/rcutorture/configs/rcu/SRCU-u | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

[PATCH tip/core/rcu 07/13] rcutorture: Enable SRCU readers from timer handler

Now that it is legal to invoke srcu_read_lock() and srcu_read_unlock() for a given srcu_struct from both process context and {soft,}irq handlers, it is time to test it. This commit therefore enables testing of SRCU readers from rcutorture's timer handler, using in_task() to determine whether or

[PATCH tip/core/rcu 07/13] rcutorture: Enable SRCU readers from timer handler

Now that it is legal to invoke srcu_read_lock() and srcu_read_unlock() for a given srcu_struct from both process context and {soft,}irq handlers, it is time to test it. This commit therefore enables testing of SRCU readers from rcutorture's timer handler, using in_task() to determine whether or

[PATCH tip/core/rcu 13/13] rcutorture: Invoke call_rcu() from timer handler

The Linux kernel invokes call_rcu() from various interrupt/softirq handlers, but rcutorture does not. This commit therefore adds this behavior to rcutorture's repertoire. Signed-off-by: Paul E. McKenney --- kernel/rcu/rcutorture.c | 13 + 1 file changed,

[PATCH tip/core/rcu 13/13] rcutorture: Invoke call_rcu() from timer handler

The Linux kernel invokes call_rcu() from various interrupt/softirq handlers, but rcutorture does not. This commit therefore adds this behavior to rcutorture's repertoire. Signed-off-by: Paul E. McKenney --- kernel/rcu/rcutorture.c | 13 + 1 file changed, 13 insertions(+) diff

[PATCH tip/core/rcu 02/13] rcutorture: Print SRCU lock/unlock totals

This commit adds printing of SRCU lock/unlock totals, which are just the sums of the per-CPU counts. Saves a bit of mental arithmetic. Signed-off-by: Paul E. McKenney --- kernel/rcu/srcutree.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git

[PATCH tip/core/rcu 02/13] rcutorture: Print SRCU lock/unlock totals

This commit adds printing of SRCU lock/unlock totals, which are just the sums of the per-CPU counts. Saves a bit of mental arithmetic. Signed-off-by: Paul E. McKenney --- kernel/rcu/srcutree.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/kernel/rcu/srcutree.c

[PATCH tip/core/rcu 06/13] rcutorture: Don't wait for kernel when all builds fail

Currently, rcutorture groups runs in batches, building each scenario in a given batch, then invoking qemu to run all the kernels in the batch. Of course, if a given scenario's kernel fails to build, there is no qemu run for that scenario. And if all of the kernels in a given batch fail to build,

[PATCH tip/core/rcu 06/13] rcutorture: Don't wait for kernel when all builds fail

Currently, rcutorture groups runs in batches, building each scenario in a given batch, then invoking qemu to run all the kernels in the batch. Of course, if a given scenario's kernel fails to build, there is no qemu run for that scenario. And if all of the kernels in a given batch fail to build,

[PATCH tip/core/rcu 12/13] rcu: Add last-CPU to GP-kthread starvation messages

This commit augments the grace-period-kthread starvation debugging messages by adding the last CPU that ran the kthread. Signed-off-by: Paul E. McKenney --- kernel/rcu/tree.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/kernel/rcu/tree.c

[PATCH tip/core/rcu 12/13] rcu: Add last-CPU to GP-kthread starvation messages

This commit augments the grace-period-kthread starvation debugging messages by adding the last CPU that ran the kthread. Signed-off-by: Paul E. McKenney --- kernel/rcu/tree.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index

[PATCH tip/core/rcu 05/13] torture: Add --kconfig argument to kvm.sh

Currently, testing a variant of an existing scenario requires editing that scenario's file or creating a new scenario file. This is messy and error prone with respect to changes to scenarios. This commit therefore adds a --kconfig argument to kvm.sh, so that '--kconfig "CONFIG_RCU_TRACE=y

[PATCH tip/core/rcu 05/13] torture: Add --kconfig argument to kvm.sh

Currently, testing a variant of an existing scenario requires editing that scenario's file or creating a new scenario file. This is messy and error prone with respect to changes to scenarios. This commit therefore adds a --kconfig argument to kvm.sh, so that '--kconfig "CONFIG_RCU_TRACE=y

[PATCH tip/core/rcu 0/13] Torture-test updates

Hello! This series contains torture-test updates: 1. Move SRCU status printing to SRCU implementations. 2. Print SRCU lock/unlock totals because I am getting tired of doing the addition in my head. 3. Remove CONFIG_TASKS_RCU ifdef from rcuperf.c. 4. Select

[PATCH tip/core/rcu 0/13] Torture-test updates

Hello! This series contains torture-test updates: 1. Move SRCU status printing to SRCU implementations. 2. Print SRCU lock/unlock totals because I am getting tired of doing the addition in my head. 3. Remove CONFIG_TASKS_RCU ifdef from rcuperf.c. 4. Select

[PATCH 0/2] cpufreq: intel_pstate: Eliminate the PID controller

Hi, According to testing so far, the P-state selection based on the PID controller in intel_pstate can be replaced with the P-state selection based on CPU load with no considerable regressions *and* the PID-based P-state selection is generally flaky and hard to manage, make intel_pstate use the

[PATCH 0/2] cpufreq: intel_pstate: Eliminate the PID controller

Hi, According to testing so far, the P-state selection based on the PID controller in intel_pstate can be replaced with the P-state selection based on CPU load with no considerable regressions *and* the PID-based P-state selection is generally flaky and hard to manage, make intel_pstate use the

[PATCH 2/2] cpufreq: intel_pstate: Drop ->update_util from pstate_funcs

From: Rafael J. Wysocki All systems use the same P-state selection "powersave" algorithm in the active mode if HWP is not used, so there's no need to provide a pointer for it in struct pstate_funcs any more. Drop ->update_util from struct pstate_funcs and make

[PATCH 2/2] cpufreq: intel_pstate: Drop ->update_util from pstate_funcs

From: Rafael J. Wysocki All systems use the same P-state selection "powersave" algorithm in the active mode if HWP is not used, so there's no need to provide a pointer for it in struct pstate_funcs any more. Drop ->update_util from struct pstate_funcs and make

[PATCH 1/2] cpufreq: intel_pstate: Do not use PID-based P-state selection

From: Rafael J. Wysocki All systems with a defined ACPI preferred profile that are not "servers" have been using the load-based P-state selection algorithm in intel_pstate since 4.12-rc1 (mobile systems and laptops have been using it since 4.10-rc1) and no problems

[PATCH 1/2] cpufreq: intel_pstate: Do not use PID-based P-state selection

From: Rafael J. Wysocki All systems with a defined ACPI preferred profile that are not "servers" have been using the load-based P-state selection algorithm in intel_pstate since 4.12-rc1 (mobile systems and laptops have been using it since 4.10-rc1) and no problems with it have been reported to

Re: [PATCH] Input: rmi4 - remove the need for artificial IRQ in case of HID

Hi, could we get this thread going again? I've been hit by this problem on my new machine recently, Razer Blade Stealth, and it's been making the touchpad rather difficult to use (jumping cursors being seen, just like the ones mentioned in the thread). Additionally, I've been running this patch

Re: [PATCH] Input: rmi4 - remove the need for artificial IRQ in case of HID

Hi, could we get this thread going again? I've been hit by this problem on my new machine recently, Razer Blade Stealth, and it's been making the touchpad rather difficult to use (jumping cursors being seen, just like the ones mentioned in the thread). Additionally, I've been running this patch

Re: [PATCH] ARM: OMAP2+: omap_device: drop broken RPM status update from suspend_noirq

On 07/24/2017 04:52 AM, Johan Hovold wrote: > Since commit a8636c89648a ("PM / Runtime: Don't allow to suspend a > device with an active child"), which went into 4.10, it is no longer > permitted to set RPM_SUSPENDED state for a device with active children > (unless power.ignore_children is

Re: [PATCH] ARM: OMAP2+: omap_device: drop broken RPM status update from suspend_noirq

On 07/24/2017 04:52 AM, Johan Hovold wrote: > Since commit a8636c89648a ("PM / Runtime: Don't allow to suspend a > device with an active child"), which went into 4.10, it is no longer > permitted to set RPM_SUSPENDED state for a device with active children > (unless power.ignore_children is

[PATCH tip/core/rcu 3/4] srcu: Make process_srcu() be static

The function process_srcu() is not invoked outside of srcutree.c, so this commit makes it static and drops the EXPORT_SYMBOL_GPL(). Signed-off-by: Paul E. McKenney --- include/linux/srcutree.h | 2 -- kernel/rcu/srcutree.c| 4 ++-- 2 files changed, 2

[PATCH tip/core/rcu 3/4] srcu: Make process_srcu() be static

The function process_srcu() is not invoked outside of srcutree.c, so this commit makes it static and drops the EXPORT_SYMBOL_GPL(). Signed-off-by: Paul E. McKenney --- include/linux/srcutree.h | 2 -- kernel/rcu/srcutree.c| 4 ++-- 2 files changed, 2 insertions(+), 4 deletions(-) diff

[PATCH tip/core/rcu 4/4] srcu: Provide ordering for CPU not involved in grace period

Tree RCU guarantees that every online CPU has a memory barrier between any given grace period and any of that CPU's RCU read-side sections that must be ordered against that grace period. Since RCU doesn't always know where read-side critical sections are, the actual implementation guarantees

[PATCH tip/core/rcu 4/4] srcu: Provide ordering for CPU not involved in grace period

Tree RCU guarantees that every online CPU has a memory barrier between any given grace period and any of that CPU's RCU read-side sections that must be ordered against that grace period. Since RCU doesn't always know where read-side critical sections are, the actual implementation guarantees

[PATCH tip/core/rcu 2/4] rcutorture: Remove obsolete SRCU-C.boot

Classic SRCU is no more, so this commit removes the corresponding rcutorture boot-parameters file. Signed-off-by: Paul E. McKenney --- tools/testing/selftests/rcutorture/configs/rcu/SRCU-C.boot | 1 - 1 file changed, 1 deletion(-) delete mode 100644

[PATCH tip/core/rcu 2/4] rcutorture: Remove obsolete SRCU-C.boot

Classic SRCU is no more, so this commit removes the corresponding rcutorture boot-parameters file. Signed-off-by: Paul E. McKenney --- tools/testing/selftests/rcutorture/configs/rcu/SRCU-C.boot | 1 - 1 file changed, 1 deletion(-) delete mode 100644

[PATCH tip/core/rcu 1/4] srcu: Move rcu_scheduler_starting() from Tiny RCU to Tiny SRCU

Other than lockdep support, Tiny RCU has no need for the scheduler status. However, Tiny SRCU will need this to control boot-time behavior independent of lockdep. Therefore, this commit moves rcu_scheduler_starting() from kernel/rcu/tiny_plugin.h to kernel/rcu/srcutiny.c. This in turn allows

[PATCH tip/core/rcu 1/4] srcu: Move rcu_scheduler_starting() from Tiny RCU to Tiny SRCU

Other than lockdep support, Tiny RCU has no need for the scheduler status. However, Tiny SRCU will need this to control boot-time behavior independent of lockdep. Therefore, this commit moves rcu_scheduler_starting() from kernel/rcu/tiny_plugin.h to kernel/rcu/srcutiny.c. This in turn allows

Re: [PATCH v3 3/5] iio: adc: sun4i-gpadc-iio: add support for H3 thermal sensor

Hi Icenowy, [auto build test WARNING on robh/for-next] [also build test WARNING on v4.13-rc2 next-20170724] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Icenowy-Zheng/IIO-based-thermal-sensor

Re: [PATCH v3 3/5] iio: adc: sun4i-gpadc-iio: add support for H3 thermal sensor

Hi Icenowy, [auto build test WARNING on robh/for-next] [also build test WARNING on v4.13-rc2 next-20170724] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Icenowy-Zheng/IIO-based-thermal-sensor

[PATCH tip/core/rcu 0/4] SRCU updates

Hello! This series contains a few SRCU updates: 1. Move rcu_scheduler_starting() from Tiny RCU to Tiny SRCU. 2. Remove obsolete SRCU-C.boot kernel-parameter file 3. Make process_srcu() be static. 4. Provide ordering for CPU not involved in grace period.

[PATCH tip/core/rcu 0/4] SRCU updates

Hello! This series contains a few SRCU updates: 1. Move rcu_scheduler_starting() from Tiny RCU to Tiny SRCU. 2. Remove obsolete SRCU-C.boot kernel-parameter file 3. Make process_srcu() be static. 4. Provide ordering for CPU not involved in grace period.

Re: [PATCH v5 1/5] mm: add vm_insert_mixed_mkwrite()

On Mon, Jul 24, 2017 at 11:06:12AM -0600, Ross Zwisler wrote: > @@ -1658,14 +1658,35 @@ static int insert_pfn(struct vm_area_struct *vma, > unsigned long addr, > if (!pte) > goto out; > retval = -EBUSY; > - if (!pte_none(*pte)) > - goto out_unlock; > +

Re: [PATCH v5 1/5] mm: add vm_insert_mixed_mkwrite()

On Mon, Jul 24, 2017 at 11:06:12AM -0600, Ross Zwisler wrote: > @@ -1658,14 +1658,35 @@ static int insert_pfn(struct vm_area_struct *vma, > unsigned long addr, > if (!pte) > goto out; > retval = -EBUSY; > - if (!pte_none(*pte)) > - goto out_unlock; > +

[PATCH tip/core/rcu 7/9] drivers/ata: Replace spin_unlock_wait() with lock/unlock pair

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore eliminates the spin_unlock_wait() call and associated else-clause and hoists the then-clause's lock and unlock out of the "if"

[PATCH tip/core/rcu 7/9] drivers/ata: Replace spin_unlock_wait() with lock/unlock pair

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore eliminates the spin_unlock_wait() call and associated else-clause and hoists the then-clause's lock and unlock out of the "if"

[PATCH tip/core/rcu 1/9] net/netfilter/nf_conntrack_core: Fix net_conntrack_lock()

From: Manfred Spraul As we want to remove spin_unlock_wait() and replace it with explicit spin_lock()/spin_unlock() calls, we can use this to simplify the locking. In addition: - Reading nf_conntrack_locks_all needs ACQUIRE memory ordering. - The new code avoids the

[PATCH tip/core/rcu 1/9] net/netfilter/nf_conntrack_core: Fix net_conntrack_lock()

From: Manfred Spraul As we want to remove spin_unlock_wait() and replace it with explicit spin_lock()/spin_unlock() calls, we can use this to simplify the locking. In addition: - Reading nf_conntrack_locks_all needs ACQUIRE memory ordering. - The new code avoids the backwards loop. Only

[PATCH tip/core/rcu 5/9] exit: Replace spin_unlock_wait() with lock/unlock pair

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore replaces the spin_unlock_wait() call in do_exit() with spin_lock() followed immediately by spin_unlock(). This should be safe

[PATCH tip/core/rcu 5/9] exit: Replace spin_unlock_wait() with lock/unlock pair

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore replaces the spin_unlock_wait() call in do_exit() with spin_lock() followed immediately by spin_unlock(). This should be safe

[PATCH tip/core/rcu 9/9] arch: Remove spin_unlock_wait() arch-specific definitions

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore removes the underlying arch-specific arch_spin_unlock_wait() for all architectures providing them. Signed-off-by: Paul E.

[PATCH tip/core/rcu 8/9] locking: Remove spin_unlock_wait() generic definitions

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore removes spin_unlock_wait() and related definitions from core code. Signed-off-by: Paul E. McKenney

[PATCH tip/core/rcu 3/9] sched: Replace spin_unlock_wait() with lock/unlock pair

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore replaces the spin_unlock_wait() call in do_task_dead() with spin_lock() followed immediately by spin_unlock(). This should be

[PATCH tip/core/rcu 4/9] completion: Replace spin_unlock_wait() with lock/unlock pair

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore replaces the spin_unlock_wait() call in completion_done() with spin_lock() followed immediately by spin_unlock(). This should

[PATCH tip/core/rcu 6/9] ipc: Replace spin_unlock_wait() with lock/unlock pair

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore replaces the spin_unlock_wait() call in exit_sem() with spin_lock() followed immediately by spin_unlock(). This should be safe

[PATCH tip/core/rcu 9/9] arch: Remove spin_unlock_wait() arch-specific definitions

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore removes the underlying arch-specific arch_spin_unlock_wait() for all architectures providing them. Signed-off-by: Paul E.

[PATCH tip/core/rcu 8/9] locking: Remove spin_unlock_wait() generic definitions

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore removes spin_unlock_wait() and related definitions from core code. Signed-off-by: Paul E. McKenney Cc: Arnd Bergmann Cc:

[PATCH tip/core/rcu 3/9] sched: Replace spin_unlock_wait() with lock/unlock pair

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore replaces the spin_unlock_wait() call in do_task_dead() with spin_lock() followed immediately by spin_unlock(). This should be

[PATCH tip/core/rcu 4/9] completion: Replace spin_unlock_wait() with lock/unlock pair

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore replaces the spin_unlock_wait() call in completion_done() with spin_lock() followed immediately by spin_unlock(). This should

[PATCH tip/core/rcu 6/9] ipc: Replace spin_unlock_wait() with lock/unlock pair

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore replaces the spin_unlock_wait() call in exit_sem() with spin_lock() followed immediately by spin_unlock(). This should be safe

[PATCH tip/core/rcu 2/9] task_work: Replace spin_unlock_wait() with lock/unlock pair

From: Oleg Nesterov There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore replaces the spin_unlock_wait() call in task_work_run() with a spin_lock_irq() and a

[PATCH tip/core/rcu 2/9] task_work: Replace spin_unlock_wait() with lock/unlock pair

From: Oleg Nesterov There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore replaces the spin_unlock_wait() call in task_work_run() with a spin_lock_irq() and a spin_unlock_irq()

[PATCH tip/core/rcu 0/9] Remove spin_unlock_wait()

Hello! This series removes spin_unlock_wait(): 1. Remove spin_unlock_wait() from net/netfilter/nf_conntrack_core, courtesy of Manfred Spraul. 2. Replace task_work use of spin_unlock_wait() with lock/unlock pair, courtesy of Oleg Nesterov. 3. Replace scheduler use

[PATCH tip/core/rcu 0/9] Remove spin_unlock_wait()

Hello! This series removes spin_unlock_wait(): 1. Remove spin_unlock_wait() from net/netfilter/nf_conntrack_core, courtesy of Manfred Spraul. 2. Replace task_work use of spin_unlock_wait() with lock/unlock pair, courtesy of Oleg Nesterov. 3. Replace scheduler use

Re: [PATCH v3 3/5] iio: adc: sun4i-gpadc-iio: add support for H3 thermal sensor

Hi Icenowy, [auto build test WARNING on robh/for-next] [also build test WARNING on v4.13-rc2 next-20170724] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Icenowy-Zheng/IIO-based-thermal-sensor

Re: [PATCH v3 3/5] iio: adc: sun4i-gpadc-iio: add support for H3 thermal sensor

Hi Icenowy, [auto build test WARNING on robh/for-next] [also build test WARNING on v4.13-rc2 next-20170724] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Icenowy-Zheng/IIO-based-thermal-sensor

Re: [PATCH tip/core/rcu 5/5] EXP: sched/cputime: Fix using smp_processor_id() in preemptible

2017-07-25 5:58 GMT+08:00 Paul E. McKenney : > From: Wanpeng Li > > BUG: using smp_processor_id() in preemptible [] code: 99-trinity/181 What's the meaning of EXP? Btw, the patch is in linus's tree currently. Regards, Wanpeng Li

Re: [PATCH tip/core/rcu 5/5] EXP: sched/cputime: Fix using smp_processor_id() in preemptible

2017-07-25 5:58 GMT+08:00 Paul E. McKenney : > From: Wanpeng Li > > BUG: using smp_processor_id() in preemptible [] code: 99-trinity/181 What's the meaning of EXP? Btw, the patch is in linus's tree currently. Regards, Wanpeng Li

[PATCH tip/core/rcu 3/5] EXPERIMENTAL sched: Allow migrating kthreads into online but inactive CPUs

From: Tejun Heo Per-cpu workqueues have been tripping CPU affinity sanity checks while a CPU is being offlined. A per-cpu kworker ends up running on a CPU which isn't its target CPU while the CPU is online but inactive. While the scheduler allows kthreads to wake up on an

[PATCH tip/core/rcu 1/5] module: Fix pr_fmt() bug for header use of printk

From: Joe Perches This commit removes the pr_fmt() macro, replacing it with mod_err() and mod_debug() macros to avoid errors when using printk() from header files. Signed-off-by: Joe Perches Signed-off-by: Paul E. McKenney ---

[PATCH tip/core/rcu 3/5] EXPERIMENTAL sched: Allow migrating kthreads into online but inactive CPUs

From: Tejun Heo Per-cpu workqueues have been tripping CPU affinity sanity checks while a CPU is being offlined. A per-cpu kworker ends up running on a CPU which isn't its target CPU while the CPU is online but inactive. While the scheduler allows kthreads to wake up on an online but inactive

[PATCH tip/core/rcu 1/5] module: Fix pr_fmt() bug for header use of printk

From: Joe Perches This commit removes the pr_fmt() macro, replacing it with mod_err() and mod_debug() macros to avoid errors when using printk() from header files. Signed-off-by: Joe Perches Signed-off-by: Paul E. McKenney --- arch/blackfin/kernel/module.c | 39

[PATCH tip/core/rcu 4/5] sys_membarrier: Add expedited option

The sys_membarrier() system call has proven too slow for some use cases, which has prompted users to instead rely on TLB shootdown. Although TLB shootdown is much faster, it has the slight disadvantage of not working at all on arm and arm64. This commit therefore adds an expedited option to the

[PATCH tip/core/rcu 5/5] EXP: sched/cputime: Fix using smp_processor_id() in preemptible

From: Wanpeng Li BUG: using smp_processor_id() in preemptible [] code: 99-trinity/181 caller is debug_smp_processor_id+0x17/0x19 CPU: 0 PID: 181 Comm: 99-trinity Not tainted 4.12.0-01059-g2a42eb9 #1 Call Trace: dump_stack+0x82/0xb8

[PATCH tip/core/rcu 4/5] sys_membarrier: Add expedited option

The sys_membarrier() system call has proven too slow for some use cases, which has prompted users to instead rely on TLB shootdown. Although TLB shootdown is much faster, it has the slight disadvantage of not working at all on arm and arm64. This commit therefore adds an expedited option to the

[PATCH tip/core/rcu 5/5] EXP: sched/cputime: Fix using smp_processor_id() in preemptible

From: Wanpeng Li BUG: using smp_processor_id() in preemptible [] code: 99-trinity/181 caller is debug_smp_processor_id+0x17/0x19 CPU: 0 PID: 181 Comm: 99-trinity Not tainted 4.12.0-01059-g2a42eb9 #1 Call Trace: dump_stack+0x82/0xb8 check_preemption_disabled+0xd1/0xe3

[PATCH tip/core/rcu 2/5] init_task: Remove redundant INIT_TASK_RCU_TREE_PREEMPT() macro

Back in the dim distant past, the task_struct structure's RCU-related fields optionally included those needed for CONFIG_RCU_BOOST, even in CONFIG_PREEMPT_RCU builds. The INIT_TASK_RCU_TREE_PREEMPT() macro was used to provide initializers for those optional CONFIG_RCU_BOOST fields. However, the

[PATCH tip/core/rcu 2/5] init_task: Remove redundant INIT_TASK_RCU_TREE_PREEMPT() macro

Back in the dim distant past, the task_struct structure's RCU-related fields optionally included those needed for CONFIG_RCU_BOOST, even in CONFIG_PREEMPT_RCU builds. The INIT_TASK_RCU_TREE_PREEMPT() macro was used to provide initializers for those optional CONFIG_RCU_BOOST fields. However, the

[PATCH tip/core/rcu 0/5] Related non-RCU updates

Hello! This series is outside of RCU, including things like fixes for bug triggered by RCU commits. 1. Fix pr_fmt() bug for header use of printk, courtesy of Joe Perches. 2. Remove redundant INIT_TASK_RCU_TREE_PREEMPT() macro. 3. Allow migrating kthreads into online but inactive

[PATCH tip/core/rcu 0/5] Related non-RCU updates

Hello! This series is outside of RCU, including things like fixes for bug triggered by RCU commits. 1. Fix pr_fmt() bug for header use of printk, courtesy of Joe Perches. 2. Remove redundant INIT_TASK_RCU_TREE_PREEMPT() macro. 3. Allow migrating kthreads into online but inactive

<    1   2   3   4   5   6   7   8   9   10   >