Re: [PATCH V2] mm/madvise: Move up the behavior parameter validation

On 04/17/2017 10:57 AM, Naoya Horiguchi wrote: > On Fri, Apr 14, 2017 at 07:21:41PM +0530, Anshuman Khandual wrote: >> The madvise_behavior_valid() function should be called before >> acting upon the behavior parameter. Hence move up the function. >> This also includes MADV_SOFT_OFFLINE and

Re: [PATCH V2] mm/madvise: Move up the behavior parameter validation

On 04/17/2017 10:57 AM, Naoya Horiguchi wrote: > On Fri, Apr 14, 2017 at 07:21:41PM +0530, Anshuman Khandual wrote: >> The madvise_behavior_valid() function should be called before >> acting upon the behavior parameter. Hence move up the function. >> This also includes MADV_SOFT_OFFLINE and

[PATCH v2] mm: add VM_STATIC flag to vmalloc and prevent from removing the areas

vm_area_add_early/vm_area_register_early() are used to reserve vmalloc area during boot process and those virtually mapped areas are never unmapped. So `OR` VM_STATIC flag to the areas in vmalloc_init() when importing existing vmlist entries and prevent those areas from being removed from the

[PATCH v2] mm: add VM_STATIC flag to vmalloc and prevent from removing the areas

vm_area_add_early/vm_area_register_early() are used to reserve vmalloc area during boot process and those virtually mapped areas are never unmapped. So `OR` VM_STATIC flag to the areas in vmalloc_init() when importing existing vmlist entries and prevent those areas from being removed from the

Re: [PATCH 0/2] Free running cyclic transfer implementation for pl330

Hi Alexander, I have tested this series on rk3399 evb board and works well. Tested-by: Sugar Zhang 在 4/14/2017 22:35, Alexander Kochetkov 写道: Hello! This series contain free running cyclic transfer implementation for pl330. It affect ALL chips using pl330 (not

Re: [PATCH 0/2] Free running cyclic transfer implementation for pl330

Hi Alexander, I have tested this series on rk3399 evb board and works well. Tested-by: Sugar Zhang 在 4/14/2017 22:35, Alexander Kochetkov 写道: Hello! This series contain free running cyclic transfer implementation for pl330. It affect ALL chips using pl330 (not only rockchip) and allow to

[lkp-robot] [x86/mce] 5de97c9f6d: WARNING:at_arch/x86/kernel/cpu/mcheck/mce.c:#mce_register_decode_chain

FYI, we noticed the following commit: commit: 5de97c9f6d85fd83af76e09e338b18e7adb1ae60 ("x86/mce: Factor out and deprecate the /dev/mcelog driver") https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master in testcase: boot on test machine: qemu-system-i386 -enable-kvm -m 320M

[lkp-robot] [x86/mce] 5de97c9f6d: WARNING:at_arch/x86/kernel/cpu/mcheck/mce.c:#mce_register_decode_chain

FYI, we noticed the following commit: commit: 5de97c9f6d85fd83af76e09e338b18e7adb1ae60 ("x86/mce: Factor out and deprecate the /dev/mcelog driver") https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master in testcase: boot on test machine: qemu-system-i386 -enable-kvm -m 320M

Re: [PATCH v3 1/8] trace: ras: add ARM processor error information trace event

Hi Tyler, On 2017/4/18 1:18, Baicar, Tyler wrote: > On 4/16/2017 9:16 PM, Xie XiuQi wrote: >> On 2017/4/17 11:08, Xie XiuQi wrote: On 3/30/2017 4:31 AM, Xie XiuQi wrote: > Add a new trace event for ARM processor error information, so that > the user will know what error occurred.

Re: [PATCH v3 1/8] trace: ras: add ARM processor error information trace event

Hi Tyler, On 2017/4/18 1:18, Baicar, Tyler wrote: > On 4/16/2017 9:16 PM, Xie XiuQi wrote: >> On 2017/4/17 11:08, Xie XiuQi wrote: On 3/30/2017 4:31 AM, Xie XiuQi wrote: > Add a new trace event for ARM processor error information, so that > the user will know what error occurred.

[PATCH 3/3] clk: cs2000: select 12.20 High Accuracy on LFRatioCfg

From: Kuninori Morimoto cs2000 can select Static/Dynamic ratio based Frequency Synthesizer Mode, it can select 20.12 High Multiplier interpret for 32-bit User Defined Ratio if Dynamic ratio mode. Otherwise it should select 12.20 High Accuracy mode. Current

[PATCH 3/3] clk: cs2000: select 12.20 High Accuracy on LFRatioCfg

From: Kuninori Morimoto cs2000 can select Static/Dynamic ratio based Frequency Synthesizer Mode, it can select 20.12 High Multiplier interpret for 32-bit User Defined Ratio if Dynamic ratio mode. Otherwise it should select 12.20 High Accuracy mode. Current cs2000 is supporting Static ratio mode

[PATCH 2/3] clk: cs2000: tidyup DEVICE_CFG2 settings

From: Kuninori Morimoto DEVICE_CFG2 can select ratio from user defined ratio and LOCKCLK is for it. But current driver sets fixed 0 value. This patch fixes it. Note is that current cs2000 driver is using/supporting only ratio0 (= ch0) now. DEVICE_CFG2 can

[PATCH 2/3] clk: cs2000: tidyup DEVICE_CFG2 settings

From: Kuninori Morimoto DEVICE_CFG2 can select ratio from user defined ratio and LOCKCLK is for it. But current driver sets fixed 0 value. This patch fixes it. Note is that current cs2000 driver is using/supporting only ratio0 (= ch0) now. DEVICE_CFG2 can select STATIC/DYNAMIC ratio mode, and

Re: [PATCH 1/3] ptr_ring: batch ring zeroing

On 2017年04月15日 06:50, Michael S. Tsirkin wrote: On Fri, Apr 14, 2017 at 03:52:23PM +0800, Jason Wang wrote: On 2017年04月12日 16:03, Jason Wang wrote: On 2017年04月07日 13:49, Michael S. Tsirkin wrote: A known weakness in ptr_ring design is that it does not handle well the situation when ring

Re: [PATCH 1/3] ptr_ring: batch ring zeroing

On 2017年04月15日 06:50, Michael S. Tsirkin wrote: On Fri, Apr 14, 2017 at 03:52:23PM +0800, Jason Wang wrote: On 2017年04月12日 16:03, Jason Wang wrote: On 2017年04月07日 13:49, Michael S. Tsirkin wrote: A known weakness in ptr_ring design is that it does not handle well the situation when ring

[PATCH 1/3] clk: cs2000: enable clock skipping mode

From: Kuninori Morimoto CLK_IN skipping mode allows the PLL to maintain lock even when the CLK_IN signal has missing pulses for up to 20 ms (t CS) at a time. This patch enables it Signed-off-by: Kuninori Morimoto ---

[PATCH 1/3] clk: cs2000: enable clock skipping mode

From: Kuninori Morimoto CLK_IN skipping mode allows the PLL to maintain lock even when the CLK_IN signal has missing pulses for up to 20 ms (t CS) at a time. This patch enables it Signed-off-by: Kuninori Morimoto --- drivers/clk/clk-cs2000-cp.c | 6 ++ 1 file changed, 6 insertions(+)

[PATCH 0/3] clk: cs2000: tidyup missing settings

Hi Stephen These are missing settings for current cs2000. it is working without these settings, thus, not urgent. But, necessary for correct/safety operation. Kuninori Morimoto (3): clk: cs2000: enable clock skipping mode clk: cs2000: tidyup DEVICE_CFG2 settings clk: cs2000: select 12.20

[PATCH 0/3] clk: cs2000: tidyup missing settings

Hi Stephen These are missing settings for current cs2000. it is working without these settings, thus, not urgent. But, necessary for correct/safety operation. Kuninori Morimoto (3): clk: cs2000: enable clock skipping mode clk: cs2000: tidyup DEVICE_CFG2 settings clk: cs2000: select 12.20

Re: [PATCH 1/3] ptr_ring: batch ring zeroing

On 2017年04月15日 05:00, Michael S. Tsirkin wrote: On Fri, Apr 14, 2017 at 03:52:23PM +0800, Jason Wang wrote: On 2017年04月12日 16:03, Jason Wang wrote: On 2017年04月07日 13:49, Michael S. Tsirkin wrote: A known weakness in ptr_ring design is that it does not handle well the situation when ring

Re: [PATCH 1/3] ptr_ring: batch ring zeroing

On 2017年04月15日 05:00, Michael S. Tsirkin wrote: On Fri, Apr 14, 2017 at 03:52:23PM +0800, Jason Wang wrote: On 2017年04月12日 16:03, Jason Wang wrote: On 2017年04月07日 13:49, Michael S. Tsirkin wrote: A known weakness in ptr_ring design is that it does not handle well the situation when ring

[PATCH] tpm: Fix reference count to main device

The main device is currently not properly released due to one additional reference to the 'devs' device which is only released in case of a TPM 2. So, also get the additional reference only in case of a TPM2. Fixes: fdc915f7f719 ("tpm: expose spaces via a device link /dev/tpmrm") Signed-off-by:

[PATCH] tpm: Fix reference count to main device

The main device is currently not properly released due to one additional reference to the 'devs' device which is only released in case of a TPM 2. So, also get the additional reference only in case of a TPM2. Fixes: fdc915f7f719 ("tpm: expose spaces via a device link /dev/tpmrm") Signed-off-by:

Re: [PATCH 1/3] zram: fix operator precedence to get offset

Hello, On (04/18/17 08:53), Minchan Kim wrote: > On Mon, Apr 17, 2017 at 07:50:16PM +0900, Sergey Senozhatsky wrote: > > Hello Minchan, > > > > On (04/17/17 11:14), Minchan Kim wrote: > > > On Mon, Apr 17, 2017 at 10:54:29AM +0900, Sergey Senozhatsky wrote: > > > > On (04/17/17 10:21), Sergey

Re: [PATCH 1/3] zram: fix operator precedence to get offset

Hello, On (04/18/17 08:53), Minchan Kim wrote: > On Mon, Apr 17, 2017 at 07:50:16PM +0900, Sergey Senozhatsky wrote: > > Hello Minchan, > > > > On (04/17/17 11:14), Minchan Kim wrote: > > > On Mon, Apr 17, 2017 at 10:54:29AM +0900, Sergey Senozhatsky wrote: > > > > On (04/17/17 10:21), Sergey

Re: [patch] mm, vmscan: avoid thrashing anon lru when free + file is low

Hello David, On Mon, Apr 17, 2017 at 05:06:20PM -0700, David Rientjes wrote: > The purpose of the code that commit 623762517e23 ("revert 'mm: vmscan: do > not swap anon pages just because free+file is low'") reintroduces is to > prefer swapping anonymous memory rather than trashing the file lru.

Re: [patch] mm, vmscan: avoid thrashing anon lru when free + file is low

Hello David, On Mon, Apr 17, 2017 at 05:06:20PM -0700, David Rientjes wrote: > The purpose of the code that commit 623762517e23 ("revert 'mm: vmscan: do > not swap anon pages just because free+file is low'") reintroduces is to > prefer swapping anonymous memory rather than trashing the file lru.

Re: [PATCH v8 10/15] ACPI: platform-msi: retrieve dev id from IORT

On 2017/4/18 9:30, Sinan Kaya wrote: > On 4/17/2017 9:27 PM, Hanjun Guo wrote: >> Patches were merged via two trees: >> >> https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/log/?h=irq/core >> https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=for-next/core=50 >> >> So

Re: [PATCH v8 10/15] ACPI: platform-msi: retrieve dev id from IORT

On 2017/4/18 9:30, Sinan Kaya wrote: > On 4/17/2017 9:27 PM, Hanjun Guo wrote: >> Patches were merged via two trees: >> >> https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/log/?h=irq/core >> https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=for-next/core=50 >> >> So

Re: [PATCH v8 10/15] ACPI: platform-msi: retrieve dev id from IORT

On 4/17/2017 9:27 PM, Hanjun Guo wrote: > Patches were merged via two trees: > > https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/log/?h=irq/core > https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=for-next/core=50 > > So please try to merge those two trees and

Re: [PATCH v8 10/15] ACPI: platform-msi: retrieve dev id from IORT

On 4/17/2017 9:27 PM, Hanjun Guo wrote: > Patches were merged via two trees: > > https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/log/?h=irq/core > https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=for-next/core=50 > > So please try to merge those two trees and

Re: [PATCH v8 10/15] ACPI: platform-msi: retrieve dev id from IORT

Hi Sinan, On 2017/4/18 6:01, Sinan Kaya wrote: > On 4/17/2017 5:44 PM, Sinan Kaya wrote: >> Any idea what happened to the change in this function during merge? >> >> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=ae7c18380495ac5c14a614fdb6c452c3bf9148ac >> > I

Re: [PATCH v8 10/15] ACPI: platform-msi: retrieve dev id from IORT

Hi Sinan, On 2017/4/18 6:01, Sinan Kaya wrote: > On 4/17/2017 5:44 PM, Sinan Kaya wrote: >> Any idea what happened to the change in this function during merge? >> >> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=ae7c18380495ac5c14a614fdb6c452c3bf9148ac >> > I

Re: [PATCH v3 7/8] arm64: exception: handle asynchronous SError interrupt

Hi Mark, I have some confusion about the RAS feature when VHE is enabled. Does RAS spec support the situation when VHE is enabled. When VHE is disabled, the hyperviosr delegates the error exception to EL1 by setting HCR_EL2.VSE to 1, and this will inject a virtual SEI into OS. My understanding

Re: [PATCH v3 7/8] arm64: exception: handle asynchronous SError interrupt

Hi Mark, I have some confusion about the RAS feature when VHE is enabled. Does RAS spec support the situation when VHE is enabled. When VHE is disabled, the hyperviosr delegates the error exception to EL1 by setting HCR_EL2.VSE to 1, and this will inject a virtual SEI into OS. My understanding

Re: linux-next: manual merge of the net-next tree with the net tree

On 04/18/2017 02:18 AM, Stephen Rothwell wrote: Hi all, Today's linux-next merge of the net-next tree got a conflict in: kernel/bpf/syscall.c between commits: 6b1bb01bcc5b ("bpf: fix cb access in socket filter programs on tail calls") c2002f983767 ("bpf: fix checking xdp_adjust_head

Re: linux-next: manual merge of the net-next tree with the net tree

On 04/18/2017 02:18 AM, Stephen Rothwell wrote: Hi all, Today's linux-next merge of the net-next tree got a conflict in: kernel/bpf/syscall.c between commits: 6b1bb01bcc5b ("bpf: fix cb access in socket filter programs on tail calls") c2002f983767 ("bpf: fix checking xdp_adjust_head

Re: [PATCH] of: introduce event tracepoints for dynamic device_node lifecyle

FYI, this patch was meant to be sent as an RFC. Looks like the RFC tag got lost in my last spin. On 04/17/2017 05:32 PM, Tyrel Datwyler wrote: > This patch introduces event tracepoints for tracking a device_nodes > reference cycle as well as reconfig notifications generated in response > to

Re: [PATCH] of: introduce event tracepoints for dynamic device_node lifecyle

FYI, this patch was meant to be sent as an RFC. Looks like the RFC tag got lost in my last spin. On 04/17/2017 05:32 PM, Tyrel Datwyler wrote: > This patch introduces event tracepoints for tracking a device_nodes > reference cycle as well as reconfig notifications generated in response > to

Re: [PATCH v2 tip/core/rcu 04/39] srcu: Check for tardy grace-period activity in cleanup_srcu_struct()

On Mon, Apr 17, 2017 at 04:44:51PM -0700, Paul E. McKenney wrote: > Users of SRCU are obliged to complete all grace-period activity before > invoking cleanup_srcu_struct(). This means that all calls to either > synchronize_srcu() or synchronize_srcu_expedited() must have returned, > and all calls

Re: [PATCH v2 tip/core/rcu 04/39] srcu: Check for tardy grace-period activity in cleanup_srcu_struct()

On Mon, Apr 17, 2017 at 04:44:51PM -0700, Paul E. McKenney wrote: > Users of SRCU are obliged to complete all grace-period activity before > invoking cleanup_srcu_struct(). This means that all calls to either > synchronize_srcu() or synchronize_srcu_expedited() must have returned, > and all calls

Re: [PATCH v2 tip/core/rcu 04/39] srcu: Check for tardy grace-period activity in cleanup_srcu_struct()

On Mon, Apr 17, 2017 at 05:33:32PM -0700, Josh Triplett wrote: > On Mon, Apr 17, 2017 at 04:44:51PM -0700, Paul E. McKenney wrote: > > Users of SRCU are obliged to complete all grace-period activity before > > invoking cleanup_srcu_struct(). This means that all calls to either > >

Re: [PATCH v2 tip/core/rcu 04/39] srcu: Check for tardy grace-period activity in cleanup_srcu_struct()

On Mon, Apr 17, 2017 at 05:33:32PM -0700, Josh Triplett wrote: > On Mon, Apr 17, 2017 at 04:44:51PM -0700, Paul E. McKenney wrote: > > Users of SRCU are obliged to complete all grace-period activity before > > invoking cleanup_srcu_struct(). This means that all calls to either > >

Re: [PATCH -mm -v8 1/3] mm, THP, swap: Delay splitting THP during swap out

Johannes Weiner writes: > On Sat, Apr 15, 2017 at 09:17:04AM +0800, Huang, Ying wrote: >> Hi, Johannes, >> >> Johannes Weiner writes: >> >> > Hi Huang, >> > >> > I reviewed this patch based on the feedback I already provided, but >> > eventually gave up

Re: [PATCH -mm -v8 1/3] mm, THP, swap: Delay splitting THP during swap out

Johannes Weiner writes: > On Sat, Apr 15, 2017 at 09:17:04AM +0800, Huang, Ying wrote: >> Hi, Johannes, >> >> Johannes Weiner writes: >> >> > Hi Huang, >> > >> > I reviewed this patch based on the feedback I already provided, but >> > eventually gave up and rewrote it. Please take review

[PATCH] of: introduce event tracepoints for dynamic device_node lifecyle

This patch introduces event tracepoints for tracking a device_nodes reference cycle as well as reconfig notifications generated in response to node/property manipulations. With the recent upstreaming of the refcount API several device_node underflows and leaks have come to my attention in the

[PATCH] of: introduce event tracepoints for dynamic device_node lifecyle

This patch introduces event tracepoints for tracking a device_nodes reference cycle as well as reconfig notifications generated in response to node/property manipulations. With the recent upstreaming of the refcount API several device_node underflows and leaks have come to my attention in the

Re: [PATCH v2 tip/core/rcu 03/39] srcu: Consolidate batch checking into rcu_all_batches_empty()

On Mon, Apr 17, 2017 at 04:44:50PM -0700, Paul E. McKenney wrote: > The srcu_reschedule() function invokes rcu_batch_empty() on each of > the four rcu_batch structures in the srcu_struct in question twice. > Given that this check will also be needed in cleanup_srcu_struct(), this > commit

Re: [PATCH v2 tip/core/rcu 03/39] srcu: Consolidate batch checking into rcu_all_batches_empty()

On Mon, Apr 17, 2017 at 04:44:50PM -0700, Paul E. McKenney wrote: > The srcu_reschedule() function invokes rcu_batch_empty() on each of > the four rcu_batch structures in the srcu_struct in question twice. > Given that this check will also be needed in cleanup_srcu_struct(), this > commit

[PATCH] of: fix "/cpus" reference leak in of_numa_parse_cpu_nodes()

The call to of_find_node_by_path("/cpus") returns the cpus device_node with its reference count incremented. There is no matching of_node_put() call in of_numa_parse_cpu_nodes() which results in a leaked reference to the "/cpus" node. This patch adds an of_node_put() to release the reference.

[PATCH] of: fix "/cpus" reference leak in of_numa_parse_cpu_nodes()

The call to of_find_node_by_path("/cpus") returns the cpus device_node with its reference count incremented. There is no matching of_node_put() call in of_numa_parse_cpu_nodes() which results in a leaked reference to the "/cpus" node. This patch adds an of_node_put() to release the reference.

Re: [PATCH v2 tip/core/rcu 02/39] rcu: Make arch select smp_mb__after_unlock_lock() strength

On Mon, Apr 17, 2017 at 04:44:49PM -0700, Paul E. McKenney wrote: > The definition of smp_mb__after_unlock_lock() is currently smp_mb() > for CONFIG_PPC and a no-op otherwise. It would be better to instead > provide an architecture-selectable Kconfig option, and select the > strength of

Re: [PATCH v2 tip/core/rcu 02/39] rcu: Make arch select smp_mb__after_unlock_lock() strength

On Mon, Apr 17, 2017 at 04:44:49PM -0700, Paul E. McKenney wrote: > The definition of smp_mb__after_unlock_lock() is currently smp_mb() > for CONFIG_PPC and a no-op otherwise. It would be better to instead > provide an architecture-selectable Kconfig option, and select the > strength of

Re: [PATCH v2 tip/core/rcu 04/11] rcu: Make RCU_FANOUT_LEAF help text more explicit about skew_tick

On Mon, Apr 17, 2017 at 04:28:51PM -0700, Paul E. McKenney wrote: > If you set RCU_FANOUT_LEAF too high, you can get lock contention > on the leaf rcu_node, and you should boot with the skew_tick kernel > parameter set in order to avoid this lock contention. This commit > therefore upgrades the

linux-next: manual merge of the net-next tree with the net tree

Hi all, Today's linux-next merge of the net-next tree got a conflict in: kernel/bpf/syscall.c between commits: 6b1bb01bcc5b ("bpf: fix cb access in socket filter programs on tail calls") c2002f983767 ("bpf: fix checking xdp_adjust_head on tail calls") from the net tree and commit:

Re: [PATCH v2 tip/core/rcu 04/11] rcu: Make RCU_FANOUT_LEAF help text more explicit about skew_tick

On Mon, Apr 17, 2017 at 04:28:51PM -0700, Paul E. McKenney wrote: > If you set RCU_FANOUT_LEAF too high, you can get lock contention > on the leaf rcu_node, and you should boot with the skew_tick kernel > parameter set in order to avoid this lock contention. This commit > therefore upgrades the

linux-next: manual merge of the net-next tree with the net tree

Hi all, Today's linux-next merge of the net-next tree got a conflict in: kernel/bpf/syscall.c between commits: 6b1bb01bcc5b ("bpf: fix cb access in socket filter programs on tail calls") c2002f983767 ("bpf: fix checking xdp_adjust_head on tail calls") from the net tree and commit:

Re: [PATCH v2 tip/core/rcu 01/11] mm: Rename SLAB_DESTROY_BY_RCU to SLAB_TYPESAFE_BY_RCU

On Mon, 17 Apr 2017, Paul E. McKenney wrote: > A group of Linux kernel hackers reported chasing a bug that resulted > from their assumption that SLAB_DESTROY_BY_RCU provided an existence > guarantee, that is, that no block from such a slab would be reallocated > during an RCU read-side critical

Re: [PATCH v2 tip/core/rcu 01/11] mm: Rename SLAB_DESTROY_BY_RCU to SLAB_TYPESAFE_BY_RCU

On Mon, 17 Apr 2017, Paul E. McKenney wrote: > A group of Linux kernel hackers reported chasing a bug that resulted > from their assumption that SLAB_DESTROY_BY_RCU provided an existence > guarantee, that is, that no block from such a slab would be reallocated > during an RCU read-side critical

[PATCH v2] tools/power/x86/intel_pstate_tracer: Adjust directory ownership

The intel_pstate_tracer.py script only needs to be run as root when it is also used to actually acquire the trace data that it will post process. Otherwise it is generally preferable that it be run as a regular user. If run the first time as root the results directory will be incorrect for any

[PATCH v2] tools/power/x86/intel_pstate_tracer: Adjust directory ownership

The intel_pstate_tracer.py script only needs to be run as root when it is also used to actually acquire the trace data that it will post process. Otherwise it is generally preferable that it be run as a regular user. If run the first time as root the results directory will be incorrect for any

RE: [RESEND PATCH] tools/power/x86/intel_pstate_tracer: Adjust directory permissions

On 2107.04.16 15:57 Rafael J. Wysocki wrote: > On Sun, Apr 16, 2017 at 5:17 PM, Doug Smythies > wrote: >> Depending on what is being done, the intel_pstate_tracer.py script >> needs to be run as root, or can be run as a regular user. >> If run the first time as root the

RE: [RESEND PATCH] tools/power/x86/intel_pstate_tracer: Adjust directory permissions

On 2107.04.16 15:57 Rafael J. Wysocki wrote: > On Sun, Apr 16, 2017 at 5:17 PM, Doug Smythies > wrote: >> Depending on what is being done, the intel_pstate_tracer.py script >> needs to be run as root, or can be run as a regular user. >> If run the first time as root the results directory will be

Re: [PATCH v2 tip/core/rcu 01/39] rcu: Maintain special bits at bottom of ->dynticks counter

On Mon, Apr 17, 2017 at 04:44:48PM -0700, Paul E. McKenney wrote: > Currently, IPIs are used to force other CPUs to invalidate their TLBs > in response to a kernel virtual-memory mapping change. This works, but > degrades both battery lifetime (for idle CPUs) and real-time response > (for

Re: [PATCH v2 tip/core/rcu 01/39] rcu: Maintain special bits at bottom of ->dynticks counter

On Mon, Apr 17, 2017 at 04:44:48PM -0700, Paul E. McKenney wrote: > Currently, IPIs are used to force other CPUs to invalidate their TLBs > in response to a kernel virtual-memory mapping change. This works, but > degrades both battery lifetime (for idle CPUs) and real-time response > (for

Re: [PATCH] net/ncsi: fix checksum validation in response packet

On Mon, Apr 17, 2017 at 01:36:19PM -0400, David Miller wrote: >From: Cédric Le Goater >Date: Fri, 14 Apr 2017 10:56:37 +0200 > >> htonl was used instead of ntohl. Surely a typo. >> >> Signed-off-by: Cédric Le Goater > >I don't think so, "checksum" is of type "u32"

Re: [PATCH] net/ncsi: fix checksum validation in response packet

On Mon, Apr 17, 2017 at 01:36:19PM -0400, David Miller wrote: >From: Cédric Le Goater >Date: Fri, 14 Apr 2017 10:56:37 +0200 > >> htonl was used instead of ntohl. Surely a typo. >> >> Signed-off-by: Cédric Le Goater > >I don't think so, "checksum" is of type "u32" thus is in host byte >order.

[patch] mm, vmscan: avoid thrashing anon lru when free + file is low

The purpose of the code that commit 623762517e23 ("revert 'mm: vmscan: do not swap anon pages just because free+file is low'") reintroduces is to prefer swapping anonymous memory rather than trashing the file lru. If all anonymous memory is unevictable, however, this insistance on SCAN_ANON ends

[patch] mm, vmscan: avoid thrashing anon lru when free + file is low

The purpose of the code that commit 623762517e23 ("revert 'mm: vmscan: do not swap anon pages just because free+file is low'") reintroduces is to prefer swapping anonymous memory rather than trashing the file lru. If all anonymous memory is unevictable, however, this insistance on SCAN_ANON ends

Re: copy_page() on a kmalloc-ed page with DEBUG_SLAB enabled (was "zram: do not use copy_page with non-page alinged address")

On Mon, Apr 17, 2017 at 10:20:42AM -0500, Christoph Lameter wrote: > On Mon, 17 Apr 2017, Sergey Senozhatsky wrote: > > > Minchan reported that doing copy_page() on a kmalloc(PAGE_SIZE) page > > with DEBUG_SLAB enabled can cause a memory corruption (See below or > >

Re: copy_page() on a kmalloc-ed page with DEBUG_SLAB enabled (was "zram: do not use copy_page with non-page alinged address")

On Mon, Apr 17, 2017 at 10:20:42AM -0500, Christoph Lameter wrote: > On Mon, 17 Apr 2017, Sergey Senozhatsky wrote: > > > Minchan reported that doing copy_page() on a kmalloc(PAGE_SIZE) page > > with DEBUG_SLAB enabled can cause a memory corruption (See below or > >

linux-next: manual merge of the thermal-soc tree with the pm tree

Hi Eduardo, Today's linux-next merge of the thermal-soc tree got conflicts in: drivers/thermal/Kconfig drivers/thermal/Makefile between commit: 19678ffb9fd6 ("cpufreq: dbx500: Manage cooling device from cpufreq driver") from the pm tree and commit: 608567aac320 ("thermal: da9062/61:

linux-next: manual merge of the thermal-soc tree with the pm tree

Hi Eduardo, Today's linux-next merge of the thermal-soc tree got conflicts in: drivers/thermal/Kconfig drivers/thermal/Makefile between commit: 19678ffb9fd6 ("cpufreq: dbx500: Manage cooling device from cpufreq driver") from the pm tree and commit: 608567aac320 ("thermal: da9062/61:

[PATCH 0/1] drivers/staging/vt6656/main_usb.c: checkpatch warning

Hi All, I'm submitting this patch as part of Eudyptula challenge to fix a coding style problem. Thanks for taking time on this trivial patch. linsh Chewie Lin (1): drivers/staging/vt6656/main_usb.c: checkpatch warning drivers/staging/vt6656/main_usb.c | 2 +- 1 file changed, 1

[PATCH 0/1] drivers/staging/vt6656/main_usb.c: checkpatch warning

Hi All, I'm submitting this patch as part of Eudyptula challenge to fix a coding style problem. Thanks for taking time on this trivial patch. linsh Chewie Lin (1): drivers/staging/vt6656/main_usb.c: checkpatch warning drivers/staging/vt6656/main_usb.c | 2 +- 1 file changed, 1

[PATCH 1/1] drivers/staging/vt6656/main_usb.c: checkpatch warning

Swap string in the dev_warn() call with __func__ argument, instead of explicitly calling the function name in the string: WARNING: Prefer using "%s", __func__ to embedded function names #417: FILE: main_usb.c:417: +"usb_device_reset fail

[PATCH 1/1] drivers/staging/vt6656/main_usb.c: checkpatch warning

Swap string in the dev_warn() call with __func__ argument, instead of explicitly calling the function name in the string: WARNING: Prefer using "%s", __func__ to embedded function names #417: FILE: main_usb.c:417: +"usb_device_reset fail

[PATCH v2 tip/core/rcu 28/39] srcu: Make num_rcu_lvl[] array be external

This commit makes the num_rcu_lvl[] array external so that SRCU can make use of it for initializing its upcoming srcu_node tree. Signed-off-by: Paul E. McKenney --- kernel/rcu/rcu.h | 1 + kernel/rcu/tree.c | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-)

[PATCH v2 tip/core/rcu 28/39] srcu: Make num_rcu_lvl[] array be external

This commit makes the num_rcu_lvl[] array external so that SRCU can make use of it for initializing its upcoming srcu_node tree. Signed-off-by: Paul E. McKenney --- kernel/rcu/rcu.h | 1 + kernel/rcu/tree.c | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/rcu/rcu.h

RE: [PATCH] ACPICA: Export mutex functions

Hi, > From: Guenter Roeck [mailto:li...@roeck-us.net] > Subject: Re: [PATCH] ACPICA: Export mutex functions > > On Mon, Apr 17, 2017 at 11:29:38PM +0200, Rafael J. Wysocki wrote: > > On Mon, Apr 17, 2017 at 11:03 PM, Guenter Roeck wrote: > > > On Mon, Apr 17, 2017 at

RE: [PATCH] ACPICA: Export mutex functions

Hi, > From: Guenter Roeck [mailto:li...@roeck-us.net] > Subject: Re: [PATCH] ACPICA: Export mutex functions > > On Mon, Apr 17, 2017 at 11:29:38PM +0200, Rafael J. Wysocki wrote: > > On Mon, Apr 17, 2017 at 11:03 PM, Guenter Roeck wrote: > > > On Mon, Apr 17, 2017 at 08:40:38PM +, Moore,

[PATCH v2 tip/core/rcu 01/39] rcu: Maintain special bits at bottom of ->dynticks counter

Currently, IPIs are used to force other CPUs to invalidate their TLBs in response to a kernel virtual-memory mapping change. This works, but degrades both battery lifetime (for idle CPUs) and real-time response (for nohz_full CPUs), and in addition results in unnecessary IPIs due to the fact that

[PATCH v2 tip/core/rcu 13/39] srcu: Abstract multi-tail callback list handling

RCU has only one multi-tail callback list, which is implemented via the nxtlist, nxttail, nxtcompleted, qlen_lazy, and qlen fields in the rcu_data structure, and whose operations are open-code throughout the Tree RCU implementation. This has been more or less OK in the past, but upcoming

[PATCH v2 tip/core/rcu 01/39] rcu: Maintain special bits at bottom of ->dynticks counter

Currently, IPIs are used to force other CPUs to invalidate their TLBs in response to a kernel virtual-memory mapping change. This works, but degrades both battery lifetime (for idle CPUs) and real-time response (for nohz_full CPUs), and in addition results in unnecessary IPIs due to the fact that

[PATCH v2 tip/core/rcu 13/39] srcu: Abstract multi-tail callback list handling

RCU has only one multi-tail callback list, which is implemented via the nxtlist, nxttail, nxtcompleted, qlen_lazy, and qlen fields in the rcu_data structure, and whose operations are open-code throughout the Tree RCU implementation. This has been more or less OK in the past, but upcoming

[PATCH v2 tip/core/rcu 04/39] srcu: Check for tardy grace-period activity in cleanup_srcu_struct()

Users of SRCU are obliged to complete all grace-period activity before invoking cleanup_srcu_struct(). This means that all calls to either synchronize_srcu() or synchronize_srcu_expedited() must have returned, and all calls to call_srcu() must have returned, and the last call to call_srcu() must

[PATCH v2 tip/core/rcu 04/39] srcu: Check for tardy grace-period activity in cleanup_srcu_struct()

Users of SRCU are obliged to complete all grace-period activity before invoking cleanup_srcu_struct(). This means that all calls to either synchronize_srcu() or synchronize_srcu_expedited() must have returned, and all calls to call_srcu() must have returned, and the last call to call_srcu() must

[PATCH v2 tip/core/rcu 11/39] rcu: Place guard on rcu_all_qs() and rcu_note_context_switch() actions

The rcu_all_qs() and rcu_note_context_switch() do a series of checks, taking various actions to supply RCU with quiescent states, depending on the outcomes of the various checks. This is a bit much for scheduling fastpaths, so this commit creates a separate ->rcu_urgent_qs field in the

[PATCH v2 tip/core/rcu 09/39] rcu: Pull rcu_qs_ctr into rcu_dynticks structure

The rcu_qs_ctr variable is yet another isolated per-CPU variable, so this commit pulls it into the pre-existing rcu_dynticks per-CPU structure. Signed-off-by: Paul E. McKenney --- .../RCU/Design/Data-Structures/Data-Structures.html | 12 ++--

[PATCH v2 tip/core/rcu 09/39] rcu: Pull rcu_qs_ctr into rcu_dynticks structure

The rcu_qs_ctr variable is yet another isolated per-CPU variable, so this commit pulls it into the pre-existing rcu_dynticks per-CPU structure. Signed-off-by: Paul E. McKenney --- .../RCU/Design/Data-Structures/Data-Structures.html | 12 ++-- kernel/rcu/tree.c

[PATCH v2 tip/core/rcu 11/39] rcu: Place guard on rcu_all_qs() and rcu_note_context_switch() actions

The rcu_all_qs() and rcu_note_context_switch() do a series of checks, taking various actions to supply RCU with quiescent states, depending on the outcomes of the various checks. This is a bit much for scheduling fastpaths, so this commit creates a separate ->rcu_urgent_qs field in the

Re: [PATCH 1/3] zram: fix operator precedence to get offset

Hi Sergey, On Mon, Apr 17, 2017 at 07:50:16PM +0900, Sergey Senozhatsky wrote: > Hello Minchan, > > On (04/17/17 11:14), Minchan Kim wrote: > > On Mon, Apr 17, 2017 at 10:54:29AM +0900, Sergey Senozhatsky wrote: > > > On (04/17/17 10:21), Sergey Senozhatsky wrote: > > > > > However, it should be

Re: [PATCH 1/3] zram: fix operator precedence to get offset

Hi Sergey, On Mon, Apr 17, 2017 at 07:50:16PM +0900, Sergey Senozhatsky wrote: > Hello Minchan, > > On (04/17/17 11:14), Minchan Kim wrote: > > On Mon, Apr 17, 2017 at 10:54:29AM +0900, Sergey Senozhatsky wrote: > > > On (04/17/17 10:21), Sergey Senozhatsky wrote: > > > > > However, it should be

[PATCH v2 tip/core/rcu 17/39] srcu: Move rcu_seq_start() and friends to rcu.h

This commit moves rcu_seq_start(), rcu_seq_end(), rcu_seq_snap(), and rcu_seq_done() from kernel/rcu/tree.c to kernel/rcu/rcu.h. This will allow SRCU to use these functions, which in turn will allow SRCU to move from a single global callback queue to a per-CPU callback queue. Signed-off-by: Paul

[PATCH v2 tip/core/rcu 08/39] rcu: Pull rcu_sched_qs_mask into rcu_dynticks structure

The rcu_sched_qs_mask variable is yet another isolated per-CPU variable, so this commit pulls it into the pre-existing rcu_dynticks per-CPU structure. Signed-off-by: Paul E. McKenney --- .../RCU/Design/Data-Structures/Data-Structures.html | 9 -

[PATCH v2 tip/core/rcu 17/39] srcu: Move rcu_seq_start() and friends to rcu.h

This commit moves rcu_seq_start(), rcu_seq_end(), rcu_seq_snap(), and rcu_seq_done() from kernel/rcu/tree.c to kernel/rcu/rcu.h. This will allow SRCU to use these functions, which in turn will allow SRCU to move from a single global callback queue to a per-CPU callback queue. Signed-off-by: Paul

[PATCH v2 tip/core/rcu 08/39] rcu: Pull rcu_sched_qs_mask into rcu_dynticks structure

The rcu_sched_qs_mask variable is yet another isolated per-CPU variable, so this commit pulls it into the pre-existing rcu_dynticks per-CPU structure. Signed-off-by: Paul E. McKenney --- .../RCU/Design/Data-Structures/Data-Structures.html | 9 - kernel/rcu/tree.c

[PATCH v2 tip/core/rcu 03/39] srcu: Consolidate batch checking into rcu_all_batches_empty()

The srcu_reschedule() function invokes rcu_batch_empty() on each of the four rcu_batch structures in the srcu_struct in question twice. Given that this check will also be needed in cleanup_srcu_struct(), this commit consolidates these four checks into a new rcu_all_batches_empty() function.

[PATCH v2 tip/core/rcu 30/39] srcu: Improve rcu_seq grace-period-counter abstraction

The expedited grace-period code contains several open-coded shifts know the format of an rcu_seq grace-period counter, which is not particularly good style. This commit therefore creates a new rcu_seq_ctr() function that extracts the counter portion of the counter, and an rcu_seq_state() function

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