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

Hello! This series provides torture-test updates: 1. Replace multi-instance kzalloc() with kcalloc(). 2. Use __func__ instead of hard-coded function names. 3. Avoid fake-writer use of undefined primitives, which are represented with NULL in the structure referenced by

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

Hello! This series provides torture-test updates: 1. Replace multi-instance kzalloc() with kcalloc(). 2. Use __func__ instead of hard-coded function names. 3. Avoid fake-writer use of undefined primitives, which are represented with NULL in the structure referenced by

[PATCH tip/core/rcu 17/20] rcu: Add more tracing of expedited grace periods

This commit adds more tracing of expedited grace periods to enable improved debugging of slowdowns. Signed-off-by: Paul E. McKenney --- include/trace/events/rcu.h | 3 +++ kernel/rcu/rcu.h | 8 +++- kernel/rcu/tree_exp.h | 12 3

[PATCH tip/core/rcu 17/20] rcu: Add more tracing of expedited grace periods

This commit adds more tracing of expedited grace periods to enable improved debugging of slowdowns. Signed-off-by: Paul E. McKenney --- include/trace/events/rcu.h | 3 +++ kernel/rcu/rcu.h | 8 +++- kernel/rcu/tree_exp.h | 12 3 files changed, 22 insertions(+),

[PATCH tip/core/rcu 06/20] rcu: Call touch_nmi_watchdog() while printing stall warnings

From: Tejun Heo When RCU stall warning triggers, it can print out a lot of messages while holding spinlocks. If the console device is slow (e.g. an actual or IPMI serial console), it may end up triggering NMI hard lockup watchdog like the following. *** CPU printking while

[PATCH tip/core/rcu 06/20] rcu: Call touch_nmi_watchdog() while printing stall warnings

From: Tejun Heo When RCU stall warning triggers, it can print out a lot of messages while holding spinlocks. If the console device is slow (e.g. an actual or IPMI serial console), it may end up triggering NMI hard lockup watchdog like the following. *** CPU printking while holding RCU spinlock

[PATCH tip/core/rcu 03/20] rcu: Fix CPU offload boot message when no CPUs are offloaded

In CONFIG_RCU_NOCB_CPU=y kernels, if the boot parameters indicate that none of the CPUs should in fact be offloaded, the following somewhat obtuse message appears: Offload RCU callbacks from CPUs: . This commit therefore makes the message at least grammatically correct in this case:

[PATCH tip/core/rcu 03/20] rcu: Fix CPU offload boot message when no CPUs are offloaded

In CONFIG_RCU_NOCB_CPU=y kernels, if the boot parameters indicate that none of the CPUs should in fact be offloaded, the following somewhat obtuse message appears: Offload RCU callbacks from CPUs: . This commit therefore makes the message at least grammatically correct in this case:

Re: [PATCH 4.14 00/54] 4.14.23-stable review

Tony On 02/26/2018 03:45 PM, Tony Lindgren wrote: > * Guenter Roeck [180226 21:20]: >> On Mon, Feb 26, 2018 at 02:58:24PM -0600, Dan Murphy wrote: >>> Tony L/Greg >>> >>> On 02/26/2018 02:21 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for

Re: [PATCH 4.14 00/54] 4.14.23-stable review

Tony On 02/26/2018 03:45 PM, Tony Lindgren wrote: > * Guenter Roeck [180226 21:20]: >> On Mon, Feb 26, 2018 at 02:58:24PM -0600, Dan Murphy wrote: >>> Tony L/Greg >>> >>> On 02/26/2018 02:21 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.14.23 release.

[PATCH tip/core/rcu 16/20] rcu: Fix misprint in srcu_funnel_exp_start

From: Ildar Ismagilov The srcu_funnel_exp_start() function checks to see if the srcu_struct structure's expedited grace period counter needs updating to reflect a newly arrived request for an expedited SRCU grace period. Unfortunately, the check is backwards, so this commit

[PATCH tip/core/rcu 10/20] rcu: Remove obsolete force-quiescent-state statistics for debugfs

The debugfs interface displayed statistics on RCU-pending checks but this interface has since been removed. This commit therefore removes the no-longer-used rcu_state structure's ->n_force_qs_lh and ->n_force_qs_ngp fields along with their updates. (Though the ->n_force_qs_ngp field was actually

[PATCH tip/core/rcu 04/20] doc: Fix typo in rcutorture documentation

From: Lihao Liang Signed-off-by: Lihao Liang Signed-off-by: Paul E. McKenney --- tools/testing/selftests/rcutorture/doc/rcu-test-image.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH tip/core/rcu 16/20] rcu: Fix misprint in srcu_funnel_exp_start

From: Ildar Ismagilov The srcu_funnel_exp_start() function checks to see if the srcu_struct structure's expedited grace period counter needs updating to reflect a newly arrived request for an expedited SRCU grace period. Unfortunately, the check is backwards, so this commit reverses the sense

[PATCH tip/core/rcu 10/20] rcu: Remove obsolete force-quiescent-state statistics for debugfs

The debugfs interface displayed statistics on RCU-pending checks but this interface has since been removed. This commit therefore removes the no-longer-used rcu_state structure's ->n_force_qs_lh and ->n_force_qs_ngp fields along with their updates. (Though the ->n_force_qs_ngp field was actually

[PATCH tip/core/rcu 04/20] doc: Fix typo in rcutorture documentation

From: Lihao Liang Signed-off-by: Lihao Liang Signed-off-by: Paul E. McKenney --- tools/testing/selftests/rcutorture/doc/rcu-test-image.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/rcutorture/doc/rcu-test-image.txt

[PATCH tip/core/rcu 02/20] sched/isolation: Eliminate NO_HZ_FULL_ALL

Commit 6f1982fedd59 ("sched/isolation: Handle the nohz_full= parameter") broke CONFIG_NO_HZ_FULL_ALL=y kernels. This breakage is due to the code under CONFIG_NO_HZ_FULL_ALL failing to invoke the shiny new housekeeping functions. This means that rcutorture scenario TREE04 now emits RCU CPU stall

[PATCH tip/core/rcu 02/20] sched/isolation: Eliminate NO_HZ_FULL_ALL

Commit 6f1982fedd59 ("sched/isolation: Handle the nohz_full= parameter") broke CONFIG_NO_HZ_FULL_ALL=y kernels. This breakage is due to the code under CONFIG_NO_HZ_FULL_ALL failing to invoke the shiny new housekeeping functions. This means that rcutorture scenario TREE04 now emits RCU CPU stall

[PATCH tip/core/rcu 09/20] rcu: Remove obsolete __rcu_pending() statistics for debugfs

The debugfs interface displayed statistics on RCU-pending checks but this interface has since been removed. This commit therefore removes the no-longer-used rcu_data structure's ->n_rcu_pending, ->n_rp_core_needs_qs, ->n_rp_report_qs, ->n_rp_cb_ready, ->n_rp_cpu_needs_gp, ->n_rp_gp_completed,

[PATCH tip/core/rcu 09/20] rcu: Remove obsolete __rcu_pending() statistics for debugfs

The debugfs interface displayed statistics on RCU-pending checks but this interface has since been removed. This commit therefore removes the no-longer-used rcu_data structure's ->n_rcu_pending, ->n_rp_core_needs_qs, ->n_rp_report_qs, ->n_rp_cb_ready, ->n_rp_cpu_needs_gp, ->n_rp_gp_completed,

[PATCH tip/core/rcu 07/20] rcu: Remove obsolete boost statistics for debugfs

The debugfs interface displayed statistics on RCU priority boosting, but this interface has since been removed. This commit therefore removes the no-longer-used rcu_data structure's ->n_tasks_boosted, ->n_exp_boosts, and ->n_exp_boosts and their updates. If this information proves necessary in

[PATCH tip/core/rcu 07/20] rcu: Remove obsolete boost statistics for debugfs

The debugfs interface displayed statistics on RCU priority boosting, but this interface has since been removed. This commit therefore removes the no-longer-used rcu_data structure's ->n_tasks_boosted, ->n_exp_boosts, and ->n_exp_boosts and their updates. If this information proves necessary in

[PATCH tip/core/rcu 4/5] srcu: Remove dead code in srcu_gp_end()

From: Byungchul Park Of course, compilers will optimize out a dead code. Anyway, remove any dead code for better readibility. Signed-off-by: Byungchul Park Reviewed-by: Steven Rostedt (VMware) Signed-off-by: Paul E. McKenney

[PATCH tip/core/rcu 4/5] srcu: Remove dead code in srcu_gp_end()

From: Byungchul Park Of course, compilers will optimize out a dead code. Anyway, remove any dead code for better readibility. Signed-off-by: Byungchul Park Reviewed-by: Steven Rostedt (VMware) Signed-off-by: Paul E. McKenney --- kernel/rcu/srcutree.c | 2 -- 1 file changed, 2 deletions(-)

[PATCH tip/core/rcu 3/5] srcu: Reduce scans of srcu_data in counter wrap check

From: Ildar Ismagilov Currently, given a multi-level srcu_node tree, SRCU can scan the full set of srcu_data structures at each level when cleaning up after a grace period. This, though harmless otherwise, represents pointless overhead. This commit therefore eliminates this

[PATCH tip/core/rcu 3/5] srcu: Reduce scans of srcu_data in counter wrap check

From: Ildar Ismagilov Currently, given a multi-level srcu_node tree, SRCU can scan the full set of srcu_data structures at each level when cleaning up after a grace period. This, though harmless otherwise, represents pointless overhead. This commit therefore eliminates this overhead by scanning

[PATCH tip/core/rcu 1/5] srcu: Abstract function name

This commit moves to __func__ for function names in the name of better resilience to change. Signed-off-by: Paul E. McKenney --- kernel/rcu/srcutree.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c

[PATCH tip/core/rcu 1/5] srcu: Abstract function name

This commit moves to __func__ for function names in the name of better resilience to change. Signed-off-by: Paul E. McKenney --- kernel/rcu/srcutree.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c index

[PATCH tip/core/rcu 2/5] srcu: Prevent sdp->srcu_gp_seq_needed_exp counter wrap

From: Ildar Ismagilov SRCU checks each srcu_data structure's grace-period number for counter wrap four times per cycle by default. This frequency guarantees that normal comparisons will detect potential wrap. However, the expedited grace-period number is not checked. The

[PATCH tip/core/rcu 5/5] rcu: Remove SRCU throttling

The code in srcu_gp_end() inserts a delay every 0x3ff grace periods in order to prevent SRCU grace-period work from consuming an entire CPU when there is a long sequence of expedited SRCU grace-period requests. However, all of SRCU's grace-period work is carried out in workqueues, which are in

[PATCH tip/core/rcu 2/5] srcu: Prevent sdp->srcu_gp_seq_needed_exp counter wrap

From: Ildar Ismagilov SRCU checks each srcu_data structure's grace-period number for counter wrap four times per cycle by default. This frequency guarantees that normal comparisons will detect potential wrap. However, the expedited grace-period number is not checked. The consquences are not

[PATCH tip/core/rcu 5/5] rcu: Remove SRCU throttling

The code in srcu_gp_end() inserts a delay every 0x3ff grace periods in order to prevent SRCU grace-period work from consuming an entire CPU when there is a long sequence of expedited SRCU grace-period requests. However, all of SRCU's grace-period work is carried out in workqueues, which are in

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

Hello! This series provides minor SRCU updates: 1. Use __func__ instead of hard-coded function names. 2. Prevent sdp->srcu_gp_seq_needed_exp counter wrap, courtesy of Ildar Ismagilov. 3. Reduce scans of srcu_data in counter wrap check, courtesy of Ildar

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

Hello! This series provides minor SRCU updates: 1. Use __func__ instead of hard-coded function names. 2. Prevent sdp->srcu_gp_seq_needed_exp counter wrap, courtesy of Ildar Ismagilov. 3. Reduce scans of srcu_data in counter wrap check, courtesy of Ildar

[PATCH tip/core/rcu 19/20] rcu: Make expedited RCU CPU selection avoid unnecessary stores

This commit reworks the first loop in sync_rcu_exp_select_cpus() to avoid doing unnecssary stores to other CPUs' rcu_data structures. This speeds up that first loop by roughly a factor of two on an old x86 system. In the case where the system is mostly idle, this loop incurs a large fraction of

[PATCH tip/core/rcu 19/20] rcu: Make expedited RCU CPU selection avoid unnecessary stores

This commit reworks the first loop in sync_rcu_exp_select_cpus() to avoid doing unnecssary stores to other CPUs' rcu_data structures. This speeds up that first loop by roughly a factor of two on an old x86 system. In the case where the system is mostly idle, this loop incurs a large fraction of

Re: [PATCHv2] PM / wakeirq: Add wakeup name to dedicated wake irqs

On Mon, 2018-02-26 at 13:51 -0800, Tony Lindgren wrote: > * Andy Shevchenko [180225 13:37]: > > On Fri, 2018-02-23 at 14:06 -0800, Tony Lindgren wrote: > > > > + wirq->name = kasprintf(GFP_KERNEL, "%s:wakeup", > +

Re: [PATCHv2] PM / wakeirq: Add wakeup name to dedicated wake irqs

On Mon, 2018-02-26 at 13:51 -0800, Tony Lindgren wrote: > * Andy Shevchenko [180225 13:37]: > > On Fri, 2018-02-23 at 14:06 -0800, Tony Lindgren wrote: > > > > + wirq->name = kasprintf(GFP_KERNEL, "%s:wakeup", > +dev_name(dev)); Can it make one line? In any

Re: [PATCH v1] genirq: Add wakeup sysfs node to show IRQ wakeup state

* Andy Shevchenko [180226 15:51]: > Surprisingly there is no simple way to see if the IRQ line in question > is wakeup source or not. > > Note that wakeup might be an OOB (out-of-band) source like GPIO line > which makes things slightly more complicated. > >

Re: [PATCH v1] genirq: Add wakeup sysfs node to show IRQ wakeup state

* Andy Shevchenko [180226 15:51]: > Surprisingly there is no simple way to see if the IRQ line in question > is wakeup source or not. > > Note that wakeup might be an OOB (out-of-band) source like GPIO line > which makes things slightly more complicated. > > Add a sysfs node to cover this case.

[PATCH tip/core/rcu 14/20] rcu: Use wrapper for lockdep asserts

From: Matthew Wilcox Commits c0b334c5bfa9 and ea9b0c8a26a2 introduced new sparse warnings by accessing rcu_node->lock directly and ignoring the __private marker. Introduce a new wrapper and use it. Also fix a similar problem in srcutree.c introduced by a3883df3935e.

[PATCH tip/core/rcu 14/20] rcu: Use wrapper for lockdep asserts

From: Matthew Wilcox Commits c0b334c5bfa9 and ea9b0c8a26a2 introduced new sparse warnings by accessing rcu_node->lock directly and ignoring the __private marker. Introduce a new wrapper and use it. Also fix a similar problem in srcutree.c introduced by a3883df3935e. Signed-off-by: Matthew

[PATCH tip/core/rcu 15/20] rcu: Fix init_rcu_head() comment.

The current (and implicit) comment header for init_rcu_head() and destroy_rcu_head() incorrectly says that they are not needed for statically allocated rcu_head structures. This commit therefore fixes this comment. Reported-by: Bart Van Assche Signed-off-by: Paul E.

[PATCH tip/core/rcu 15/20] rcu: Fix init_rcu_head() comment.

The current (and implicit) comment header for init_rcu_head() and destroy_rcu_head() incorrectly says that they are not needed for statically allocated rcu_head structures. This commit therefore fixes this comment. Reported-by: Bart Van Assche Signed-off-by: Paul E. McKenney Reviewed-by: Bart

[PATCH tip/core/rcu 12/20] rcu: Consolidate rcu.h #ifdefs

The kernel/rcu/rcu.h file has a pair of consecutive #ifdefs on CONFIG_TINY_RCU, so this commit consolidates them, thus saving a few lines of code. Signed-off-by: Paul E. McKenney --- kernel/rcu/rcu.h | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff

[PATCH tip/core/rcu 12/20] rcu: Consolidate rcu.h #ifdefs

The kernel/rcu/rcu.h file has a pair of consecutive #ifdefs on CONFIG_TINY_RCU, so this commit consolidates them, thus saving a few lines of code. Signed-off-by: Paul E. McKenney --- kernel/rcu/rcu.h | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/kernel/rcu/rcu.h

[PATCH tip/core/rcu 18/20] rcu: Trace expedited GP delays due to transitioning CPUs

If a CPU is transitioning to or from offline state, an expedited grace period may undergo a timed wait. This timed wait can unduly delay grace periods, so this commit adds a trace statement to make it visible. Signed-off-by: Paul E. McKenney ---

[PATCH tip/core/rcu 18/20] rcu: Trace expedited GP delays due to transitioning CPUs

If a CPU is transitioning to or from offline state, an expedited grace period may undergo a timed wait. This timed wait can unduly delay grace periods, so this commit adds a trace statement to make it visible. Signed-off-by: Paul E. McKenney --- include/trace/events/rcu.h | 1 +

[PATCH tip/core/rcu 05/20] doc: Fix typo in rcu_head comments

From: Lihao Liang Signed-off-by: Lihao Liang Signed-off-by: Paul E. McKenney --- include/linux/types.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/types.h b/include/linux/types.h

[PATCH tip/core/rcu 05/20] doc: Fix typo in rcu_head comments

From: Lihao Liang Signed-off-by: Lihao Liang Signed-off-by: Paul E. McKenney --- include/linux/types.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/types.h b/include/linux/types.h index c94d59ef96cc..ec13d02b3481 100644 --- a/include/linux/types.h +++

[PATCH tip/core/rcu 20/20] rcu: Create RCU-specific workqueues with rescuers

RCU's expedited grace periods can participate in out-of-memory deadlocks due to all available system_wq kthreads being blocked and there not being memory available to create more. This commit prevents such deadlocks by allocating an RCU-specific workqueue_struct at early boot time, and providing

[PATCH tip/core/rcu 20/20] rcu: Create RCU-specific workqueues with rescuers

RCU's expedited grace periods can participate in out-of-memory deadlocks due to all available system_wq kthreads being blocked and there not being memory available to create more. This commit prevents such deadlocks by allocating an RCU-specific workqueue_struct at early boot time, and providing

[PATCH tip/core/rcu 01/20] rcu: Remove unnecessary spinlock in rcu_boot_init_percpu_data()

From: Lihao Liang Since rcu_boot_init_percpu_data() is only called at boot time, there is no data race and spinlock is not needed. Signed-off-by: Lihao Liang Signed-off-by: Paul E. McKenney --- kernel/rcu/tree.c | 4

[PATCH tip/core/rcu 01/20] rcu: Remove unnecessary spinlock in rcu_boot_init_percpu_data()

From: Lihao Liang Since rcu_boot_init_percpu_data() is only called at boot time, there is no data race and spinlock is not needed. Signed-off-by: Lihao Liang Signed-off-by: Paul E. McKenney --- kernel/rcu/tree.c | 4 1 file changed, 4 deletions(-) diff --git a/kernel/rcu/tree.c

[PATCH tip/core/rcu 11/20] rcu: More clearly identify grace-period kthread stack dump

It is not always obvious that the stack dump from a starved grace-period kthread isn't instead that of a CPU stalling the current grace period. This commit therefore adds a pr_err() flagging these dumps. Reported-by: Peter Zijlstra Signed-off-by: Paul E. McKenney

[PATCH tip/core/rcu 11/20] rcu: More clearly identify grace-period kthread stack dump

It is not always obvious that the stack dump from a starved grace-period kthread isn't instead that of a CPU stalling the current grace period. This commit therefore adds a pr_err() flagging these dumps. Reported-by: Peter Zijlstra Signed-off-by: Paul E. McKenney --- kernel/rcu/tree.c | 1 + 1

[PATCH tip/core/rcu 08/20] rcu: Remove obsolete callback-invocation statistics for debugfs

The debugfs interface displayed statistics on RCU callback invocation but this interface has since been removed. This commit therefore removes the no-longer-used rcu_data structure's ->n_cbs_invoked and ->n_nocbs_invoked fields along with their updates. If this information proves necessary in

Re: [PATCH v3 2/3] mm/free_pcppages_bulk: do not hold lock when picking pages to free

On Mon, 26 Feb 2018, Aaron Lu wrote: > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index 3154859cccd6..35576da0a6c9 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -1116,13 +1116,11 @@ static void free_pcppages_bulk(struct zone *zone, int > count, > int migratetype = 0; >

[PATCH tip/core/rcu 08/20] rcu: Remove obsolete callback-invocation statistics for debugfs

The debugfs interface displayed statistics on RCU callback invocation but this interface has since been removed. This commit therefore removes the no-longer-used rcu_data structure's ->n_cbs_invoked and ->n_nocbs_invoked fields along with their updates. If this information proves necessary in

Re: [PATCH v3 2/3] mm/free_pcppages_bulk: do not hold lock when picking pages to free

On Mon, 26 Feb 2018, Aaron Lu wrote: > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index 3154859cccd6..35576da0a6c9 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -1116,13 +1116,11 @@ static void free_pcppages_bulk(struct zone *zone, int > count, > int migratetype = 0; >

[PATCH tip/core/rcu 13/20] rcu: Remove redundant nxttail index macro define

From: "Liu, Changcheng" RCU's nxttail has been optimized to be a rcu_segcblist, which is a multi-tailed linked list with macros defined for the indexes for each tail. The indexes have been defined in linux/rcu_segcblist.h, so this commit removes the redundant

[PATCH tip/core/rcu 13/20] rcu: Remove redundant nxttail index macro define

From: "Liu, Changcheng" RCU's nxttail has been optimized to be a rcu_segcblist, which is a multi-tailed linked list with macros defined for the indexes for each tail. The indexes have been defined in linux/rcu_segcblist.h, so this commit removes the redundant definitions in kernel/rcu/tree.h.

[PATCH tip/core/rcu 0/20] Miscellaneous fixes

Hello! This series provides miscellaneous fixes: 1. Remove unnecessary spinlock in rcu_boot_init_percpu_data(), courtesy of Lihao Liang. 2. Eliminate NO_HZ_FULL_ALL, instead relying on the nohz_full kernel boot parameter. 3. Fix CPU offload boot message when no

[PATCH tip/core/rcu 0/20] Miscellaneous fixes

Hello! This series provides miscellaneous fixes: 1. Remove unnecessary spinlock in rcu_boot_init_percpu_data(), courtesy of Lihao Liang. 2. Eliminate NO_HZ_FULL_ALL, instead relying on the nohz_full kernel boot parameter. 3. Fix CPU offload boot message when no

Re: [PATCH v6 4/5] fuse: Ensure posix acls are translated outside of init_user_ns

ebied...@xmission.com (Eric W. Biederman) writes: > Miklos Szeredi writes: > >> On Thu, Feb 22, 2018 at 11:50 PM, Eric W. Biederman >> wrote: >> >>> So if we could figure out how to use the generic acl support for the old >>> brand of fuse filesystems

Re: [PATCH v6 4/5] fuse: Ensure posix acls are translated outside of init_user_ns

ebied...@xmission.com (Eric W. Biederman) writes: > Miklos Szeredi writes: > >> On Thu, Feb 22, 2018 at 11:50 PM, Eric W. Biederman >> wrote: >> >>> So if we could figure out how to use the generic acl support for the old >>> brand of fuse filesystems that don't set FUSE_POSIX_ACL it would be

Re: [PATCHv2] PM / wakeirq: Add wakeup name to dedicated wake irqs

* Andy Shevchenko [180225 13:37]: > On Fri, 2018-02-23 at 14:06 -0800, Tony Lindgren wrote: > > This makes it easy to grep :wakeup /proc/interrupts. > > > + char *name; > > Wouldn't be const? Yup it can be const. And the kasprintf() can be made simpler as

Re: [PATCHv2] PM / wakeirq: Add wakeup name to dedicated wake irqs

* Andy Shevchenko [180225 13:37]: > On Fri, 2018-02-23 at 14:06 -0800, Tony Lindgren wrote: > > This makes it easy to grep :wakeup /proc/interrupts. > > > + char *name; > > Wouldn't be const? Yup it can be const. And the kasprintf() can be made simpler as suggested earlier by Rafael. Here's

[PATCH net-next 0/4] stmmac barrier fixes and cleanup

stmmac barrier fixes and cleanup Niklas Cassel (4): net: stmmac: ensure that the MSS desc is the last desc to set the own bit net: stmmac: use correct barrier between coherent memory and MMIO net: stmmac: ensure that the device has released ownership before reading data net:

[PATCH net-next 0/4] stmmac barrier fixes and cleanup

stmmac barrier fixes and cleanup Niklas Cassel (4): net: stmmac: ensure that the MSS desc is the last desc to set the own bit net: stmmac: use correct barrier between coherent memory and MMIO net: stmmac: ensure that the device has released ownership before reading data net:

[PATCH net-next 2/4] net: stmmac: use correct barrier between coherent memory and MMIO

The last memory barrier in stmmac_xmit()/stmmac_tso_xmit() is placed between a coherent memory write and a MMIO write: The own bit is written in First Desc (TSO: MSS desc or First Desc). The DMA engine is started by a write to the tx desc tail pointer/ enable dma transmission register, i.e. a

Re: [PATCH v3 1/3] mm/free_pcppages_bulk: update pcp->count inside

On Mon, 26 Feb 2018, Aaron Lu wrote: > Matthew Wilcox found that all callers of free_pcppages_bulk() currently > update pcp->count immediately after so it's natural to do it inside > free_pcppages_bulk(). > > No functionality or performance change is expected from this patch. > > Suggested-by:

[PATCH net-next 2/4] net: stmmac: use correct barrier between coherent memory and MMIO

The last memory barrier in stmmac_xmit()/stmmac_tso_xmit() is placed between a coherent memory write and a MMIO write: The own bit is written in First Desc (TSO: MSS desc or First Desc). The DMA engine is started by a write to the tx desc tail pointer/ enable dma transmission register, i.e. a

Re: [PATCH v3 1/3] mm/free_pcppages_bulk: update pcp->count inside

On Mon, 26 Feb 2018, Aaron Lu wrote: > Matthew Wilcox found that all callers of free_pcppages_bulk() currently > update pcp->count immediately after so it's natural to do it inside > free_pcppages_bulk(). > > No functionality or performance change is expected from this patch. > > Suggested-by:

Re: [PATCH V15 06/22] mmc: block: Add blk-mq support

On 22.02.2018 20:54, Dmitry Osipenko wrote: > On 22.02.2018 10:42, Adrian Hunter wrote: >> On 21/02/18 22:50, Dmitry Osipenko wrote: >>> On 29.11.2017 16:41, Adrian Hunter wrote: Define and use a blk-mq queue. Discards and flushes are processed synchronously, but reads and writes

Re: [PATCH V15 06/22] mmc: block: Add blk-mq support

On 22.02.2018 20:54, Dmitry Osipenko wrote: > On 22.02.2018 10:42, Adrian Hunter wrote: >> On 21/02/18 22:50, Dmitry Osipenko wrote: >>> On 29.11.2017 16:41, Adrian Hunter wrote: Define and use a blk-mq queue. Discards and flushes are processed synchronously, but reads and writes

[PATCH net-next 4/4] net: stmmac: make dwmac4_release_tx_desc() clear all descriptor fields

Make dwmac4_release_tx_desc() clear all descriptor fields, not just TDES2 and TDES3. I'm suspecting that TDES0 and TDES1 wasn't cleared because the DMA engine uses them to store the tx hardware timestamp (if PTP is enabled). However, stmmac_tx_clean() calls stmmac_get_tx_hwtstamp(), which reads

[PATCH net-next 4/4] net: stmmac: make dwmac4_release_tx_desc() clear all descriptor fields

Make dwmac4_release_tx_desc() clear all descriptor fields, not just TDES2 and TDES3. I'm suspecting that TDES0 and TDES1 wasn't cleared because the DMA engine uses them to store the tx hardware timestamp (if PTP is enabled). However, stmmac_tx_clean() calls stmmac_get_tx_hwtstamp(), which reads

[PATCH net-next 1/4] net: stmmac: ensure that the MSS desc is the last desc to set the own bit

A dma_wmb() is used to guarantee the ordering, with respect to other writes, to cache coherent DMA memory. There is a dma_wmb() in prepare_tx_desc()/prepare_tso_tx_desc() which ensures that TDES0/1/2 is written before TDES3 (which contains the own bit), for First Desc. However, in the rare case

[PATCH net-next 3/4] net: stmmac: ensure that the device has released ownership before reading data

According to Documentation/memory-barriers.txt, we need to use a dma_rmb() after reading the status/own bit, to ensure that all descriptor fields are read after reading the own bit. This way, we ensure that the DMA engine is done with the DMA descriptor before we read the other descriptor fields,

[PATCH net-next 1/4] net: stmmac: ensure that the MSS desc is the last desc to set the own bit

A dma_wmb() is used to guarantee the ordering, with respect to other writes, to cache coherent DMA memory. There is a dma_wmb() in prepare_tx_desc()/prepare_tso_tx_desc() which ensures that TDES0/1/2 is written before TDES3 (which contains the own bit), for First Desc. However, in the rare case

[PATCH net-next 3/4] net: stmmac: ensure that the device has released ownership before reading data

According to Documentation/memory-barriers.txt, we need to use a dma_rmb() after reading the status/own bit, to ensure that all descriptor fields are read after reading the own bit. This way, we ensure that the DMA engine is done with the DMA descriptor before we read the other descriptor fields,

Re: [PATCH 4.14 00/54] 4.14.23-stable review

* Guenter Roeck [180226 21:20]: > On Mon, Feb 26, 2018 at 02:58:24PM -0600, Dan Murphy wrote: > > Tony L/Greg > > > > On 02/26/2018 02:21 PM, Greg Kroah-Hartman wrote: > > > This is the start of the stable review cycle for the 4.14.23 release. > > > There are 54 patches in

Re: [PATCH 4.14 00/54] 4.14.23-stable review

* Guenter Roeck [180226 21:20]: > On Mon, Feb 26, 2018 at 02:58:24PM -0600, Dan Murphy wrote: > > Tony L/Greg > > > > On 02/26/2018 02:21 PM, Greg Kroah-Hartman wrote: > > > This is the start of the stable review cycle for the 4.14.23 release. > > > There are 54 patches in this series, all will

Re: [PATCH v2 2/2] i2c: piix4: Use request_muxed_region

On Mon, Feb 26, 2018 at 10:43:07PM +0100, Wolfram Sang wrote: > > > It is an alternate and somewhat simpler solution which does not > > attempt to change the kernel API. My primary goal was to find > > a solution for the immediate problem between the watchdog and > > i2c drivers. My solution does

Re: [PATCH v2 2/2] i2c: piix4: Use request_muxed_region

On Mon, Feb 26, 2018 at 10:43:07PM +0100, Wolfram Sang wrote: > > > It is an alternate and somewhat simpler solution which does not > > attempt to change the kernel API. My primary goal was to find > > a solution for the immediate problem between the watchdog and > > i2c drivers. My solution does

Re: [PATCH v2 2/2] i2c: piix4: Use request_muxed_region

> It is an alternate and somewhat simpler solution which does not > attempt to change the kernel API. My primary goal was to find > a solution for the immediate problem between the watchdog and > i2c drivers. My solution does not attempt to fix the access problem > for (initialization) functions

Re: [PATCH v2 2/2] i2c: piix4: Use request_muxed_region

> It is an alternate and somewhat simpler solution which does not > attempt to change the kernel API. My primary goal was to find > a solution for the immediate problem between the watchdog and > i2c drivers. My solution does not attempt to fix the access problem > for (initialization) functions

Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure

On Mon, 26 Feb 2018 21:40:32 +0100 Boris Brezillon wrote: > On Mon, 26 Feb 2018 21:36:07 +0100 > Boris Brezillon wrote: > > > > >>> + > > > >>> +/** > > > >>> + * struct i3c_master_controller_ops - I3C master methods > > > >>> + *

Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure

On Mon, 26 Feb 2018 21:40:32 +0100 Boris Brezillon wrote: > On Mon, 26 Feb 2018 21:36:07 +0100 > Boris Brezillon wrote: > > > > >>> + > > > >>> +/** > > > >>> + * struct i3c_master_controller_ops - I3C master methods > > > >>> + * @bus_init: hook responsible for the I3C bus initialization.

Re: [PATCH 11/12] PM / AVS: SmartReflex: Prepare to use device tree based probing

* Rafael J. Wysocki [180226 10:38]: > On 2/23/2018 10:00 PM, Tony Lindgren wrote: > > We are currently probing smartreflex with omap_device while we are > > already probing smartreflex related interconnect target module with > > ti-sysc driver and dts data. ... > You

Re: [PATCH 11/12] PM / AVS: SmartReflex: Prepare to use device tree based probing

* Rafael J. Wysocki [180226 10:38]: > On 2/23/2018 10:00 PM, Tony Lindgren wrote: > > We are currently probing smartreflex with omap_device while we are > > already probing smartreflex related interconnect target module with > > ti-sysc driver and dts data. ... > You need an ACK from Kevin Hilman

Re: [PATCH v2 2/2] i2c: piix4: Use request_muxed_region

On Mon, Feb 26, 2018 at 09:52:04PM +0100, Wolfram Sang wrote: > On Mon, Feb 26, 2018 at 12:46:53PM -0800, Guenter Roeck wrote: > > Accesses to SB800_PIIX4_SMB_IDX can occur from multiple drivers. > > One example for another driver is the sp5100_tco driver. > > > > Use request_muxed_region() to

Re: [PATCH v2 2/2] i2c: piix4: Use request_muxed_region

On Mon, Feb 26, 2018 at 09:52:04PM +0100, Wolfram Sang wrote: > On Mon, Feb 26, 2018 at 12:46:53PM -0800, Guenter Roeck wrote: > > Accesses to SB800_PIIX4_SMB_IDX can occur from multiple drivers. > > One example for another driver is the sp5100_tco driver. > > > > Use request_muxed_region() to

Re: [PATCH] KVM: X86: Allow userspace to define the microcode version

On Mon, Feb 26, 2018 at 03:51:30PM -0500, Konrad Rzeszutek Wilk wrote: > On Mon, Feb 26, 2018 at 08:37:11PM +0100, Borislav Petkov wrote: > > On Mon, Feb 26, 2018 at 09:39:12AM -0500, Konrad Rzeszutek Wilk wrote: > > > diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c > > >

Re: [PATCH] KVM: X86: Allow userspace to define the microcode version

On Mon, Feb 26, 2018 at 03:51:30PM -0500, Konrad Rzeszutek Wilk wrote: > On Mon, Feb 26, 2018 at 08:37:11PM +0100, Borislav Petkov wrote: > > On Mon, Feb 26, 2018 at 09:39:12AM -0500, Konrad Rzeszutek Wilk wrote: > > > diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c > > >

Re: [RFC PATCH] ARM: configs: sunxi: Set ondemand govenor as default

On 19.02.2018 09:10, Maxime Ripard wrote: On Sat, Feb 17, 2018 at 03:22:35PM +0100, Philipp Rossak wrote: Right now the performance govenor is the default frequency govenor on sunxi devices. This causes some general problems. When the cpu is idle the cpu runs with its maximum frequency. This

Re: [RFC PATCH] ARM: configs: sunxi: Set ondemand govenor as default

On 19.02.2018 09:10, Maxime Ripard wrote: On Sat, Feb 17, 2018 at 03:22:35PM +0100, Philipp Rossak wrote: Right now the performance govenor is the default frequency govenor on sunxi devices. This causes some general problems. When the cpu is idle the cpu runs with its maximum frequency. This

Re: [PATCH v5 0/4] ARM: OMAP2+: AM33XX/AM43XX: Add suspend-resume support

* Santosh Shilimkar [180225 23:36]: > > Dave Gerlach (4): > >ARM: OMAP2+: Introduce low-level suspend code for AM33XX > >ARM: OMAP2+: Introduce low-level suspend code for AM43XX > >ARM: OMAP2+: pm33xx-core: Add platform code needed for PM > >soc: ti:

Re: [PATCH v5 0/4] ARM: OMAP2+: AM33XX/AM43XX: Add suspend-resume support

* Santosh Shilimkar [180225 23:36]: > > Dave Gerlach (4): > >ARM: OMAP2+: Introduce low-level suspend code for AM33XX > >ARM: OMAP2+: Introduce low-level suspend code for AM43XX > >ARM: OMAP2+: pm33xx-core: Add platform code needed for PM > >soc: ti: Add pm33xx driver for basic

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