* Re: [1/4] powerpc: define __ARCH_IRQ_EXIT_IRQS_DISABLED
From: Michael Ellerman @ 2018-01-22 3:34 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Nicholas Piggin
In-Reply-To: <20171116160052.18672-2-npiggin@gmail.com>
On Thu, 2017-11-16 at 16:00:49 UTC, Nicholas Piggin wrote:
> powerpc calls irq_exit() with local irqs disabled, therefore it
> can define __ARCH_IRQ_EXIT_IRQS_DISABLED.
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/c16bee4bded5449ec3b3ec73579ba2
cheers
^ permalink raw reply
* Re: powerpc/mm: Remove unused flag arg in global_invalidates
From: Michael Ellerman @ 2018-01-22 3:34 UTC (permalink / raw)
To: Aneesh Kumar K.V, benh, paulus; +Cc: linuxppc-dev, Aneesh Kumar K.V
In-Reply-To: <20171106122744.4321-1-aneesh.kumar@linux.vnet.ibm.com>
On Mon, 2017-11-06 at 12:27:44 UTC, "Aneesh Kumar K.V" wrote:
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/76b03dc07eebe9c8829bc4c40ae357
cheers
^ permalink raw reply
* Re: powerpc/watchdog: improve watchdog comments
From: Michael Ellerman @ 2018-01-22 3:34 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Nicholas Piggin
In-Reply-To: <20171101002733.7213-1-npiggin@gmail.com>
On Wed, 2017-11-01 at 00:27:33 UTC, Nicholas Piggin wrote:
> The overview comments in the powerpc watchdog are out of date after
> several iterations and changes of the code. Bring them up to date.
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/723b113319baa8d8b5f619a94348fa
cheers
^ permalink raw reply
* Re: powerpc/perf: Change the data type for the variable 'ncpu' in IMC code
From: Michael Ellerman @ 2018-01-22 3:34 UTC (permalink / raw)
To: Anju T Sudhakar; +Cc: maddy, linuxppc-dev, linux-kernel, anju
In-Reply-To: <1509443520-27106-1-git-send-email-anju@linux.vnet.ibm.com>
On Tue, 2017-10-31 at 09:52:00 UTC, Anju T Sudhakar wrote:
> Change the data type for the variable 'ncpu' in ppc_core_imc_cpu_offline(),
> since cpumask_any_but() returns an 'int' value.
>
> Signed-off-by: Anju T Sudhakar <anju@linux.vnet.ibm.com>
> Reported-by: David Binderman <dcb314@hotmail.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/074db39e00bb0d35cda7de9a4bae3a
cheers
^ permalink raw reply
* Re: selftests/powerpc: Add alignment handler selftest
From: Michael Ellerman @ 2018-01-22 3:34 UTC (permalink / raw)
To: Andrew Donnellan, linuxppc-dev; +Cc: mikey
In-Reply-To: <20171016050402.9455-1-andrew.donnellan@au1.ibm.com>
On Mon, 2017-10-16 at 05:04:02 UTC, Andrew Donnellan wrote:
> Add a selftest to exercise the powerpc alignment fault handler.
>
> Signed-off-by: Michael Neuling <mikey@neuling.org>
> Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/8d1915873d492b8e1f03bbcab527db
cheers
^ permalink raw reply
* Re: powerpc: Expose TSCR via sysfs
From: Michael Ellerman @ 2018-01-22 3:34 UTC (permalink / raw)
To: Anton Blanchard, benh, paulus, npiggin; +Cc: linuxppc-dev
In-Reply-To: <20170907171112.29579-1-anton@ozlabs.org>
On Thu, 2017-09-07 at 17:11:12 UTC, Anton Blanchard wrote:
> From: Anton Blanchard <anton@samba.org>
>
> The thread switch control register (TSCR) is a per core register
> that configures how the CPU shares resources between SMT threads.
>
> Exposing it via sysfs allows us to tune it at run time.
>
> Signed-off-by: Anton Blanchard <anton@samba.org>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/b6d34eb4d280c893d0f442f4b9e039
cheers
^ permalink raw reply
* Re: [v3, 3/6] dt: booting-without-of: DT fix s/#interrupt-cell/#interrupt-cells/
From: Michael Ellerman @ 2018-01-22 3:34 UTC (permalink / raw)
To: Geert Uytterhoeven, David Airlie, Rob Herring, Mark Rutland,
Carlo Caione, Kevin Hilman, Chanho Min, Catalin Marinas,
Will Deacon
Cc: devicetree, Geert Uytterhoeven, Neil Armstrong, linux-kernel,
dri-devel, netdev, Paul Mackerras, linux-amlogic, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <1496407129-13527-4-git-send-email-geert+renesas@glider.be>
On Fri, 2017-06-02 at 12:38:46 UTC, Geert Uytterhoeven wrote:
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Acked-by: Rob Herring <robh@kernel.org>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/4be4119d1fbd93c44d5c639735c312
cheers
^ permalink raw reply
* Re: powerpc/pseries: Don't give a warning when HPT resizing isn't available
From: Michael Ellerman @ 2018-01-22 3:34 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, paulus, linux-kernel, David Gibson
In-Reply-To: <20170317011119.31091-1-david@gibson.dropbear.id.au>
On Fri, 2017-03-17 at 01:11:19 UTC, David Gibson wrote:
> As of 438cc81a41 "powerpc/pseries: Automatically resize HPT for memory hot
> add/remove" when running on the pseries platform, we always attempt to
> use the PAPR extension to resize the hashed page table (HPT) when we add
> or remove memory.
>
> This is fine, but when the extension is available we'll give a harmless,
> but scary warning. This patch suppresses the warning in this case. It
> will still warn if the feature is supposed to be available, but didn't
> work.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/7339390d772ddee0447886d72c3aeb
cheers
^ permalink raw reply
* Re: powerpc: Use octal numbers for file permissions
From: Michael Ellerman @ 2018-01-22 3:34 UTC (permalink / raw)
To: Russell Currey, linuxppc-dev
In-Reply-To: <20170112035413.26544-1-ruscur@russell.cc>
On Thu, 2017-01-12 at 03:54:13 UTC, Russell Currey wrote:
> Symbolic macros are unintuitive and hard to read, whereas octal constants
> are much easier to interpret. Replace macros for the basic permission
> flags (user/group/other read/write/execute) with numeric constants
> instead, across the whole powerpc tree.
>
> Introducing a significant number of changes across the tree for no runtime
> benefit isn't exactly desirable, but so long as these macros are still
> used in the tree people will keep sending patches that add them. Not only
> are they hard to parse at a glance, there are multiple ways of coming to
> the same value (as you can see with 0444 and 0644 in this patch) which
> hurts readability.
>
> Signed-off-by: Russell Currey <ruscur@russell.cc>
> Reviewed-by: Cyril Bur <cyrilbur@gmail.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/57ad583f2086d55ada284c54bfc440
cheers
^ permalink raw reply
* Re: [RFC PATCH v2 1/1] of: introduce event tracepoints for dynamic device_node lifecyle
From: Steven Rostedt @ 2018-01-21 22:01 UTC (permalink / raw)
To: Wolfram Sang
Cc: devicetree, Tyrel Datwyler, Geert Uytterhoeven, linux-renesas-soc,
linuxppc-dev, Rob Herring, Frank Rowand, linux-kernel
In-Reply-To: <20180121143117.19805-2-wsa+renesas@sang-engineering.com>
On Sun, 21 Jan 2018 15:31:17 +0100
Wolfram Sang <wsa+renesas@sang-engineering.com> wrote:
> From: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
>=20
> This patch introduces event tracepoints for tracking a device_nodes
> reference cycle as well as reconfig notifications generated in response
> to node/property manipulations.
>=20
> With the recent upstreaming of the refcount API several device_node
> underflows and leaks have come to my attention in the pseries (DLPAR)
> dynamic logical partitioning code (ie. POWER speak for hotplugging
> virtual and physcial resources at runtime such as cpus or IOAs). These
> tracepoints provide a easy and quick mechanism for validating the
> reference counting of device_nodes during their lifetime.
>=20
> Further, when pseries lpars are migrated to a different machine we
> perform a live update of our device tree to bring it into alignment with
> the configuration of the new machine. The of_reconfig_notify trace point
> provides a mechanism that can be turned for debuging the device tree
> modifications with out having to build a custom kernel to get at the
> DEBUG code introduced by commit 00aa37206e1a54 ("of/reconfig: Add debug
> output for OF_RECONFIG notifiers").
>=20
> The following trace events are provided: of_node_get, of_node_put,
> of_node_release, and of_reconfig_notify. These trace points require a
> kernel built with ftrace support to be enabled. In a typical environment
> where debugfs is mounted at /sys/kernel/debug the entire set of
> tracepoints can be set with the following:
>=20
> echo "of:*" > /sys/kernel/debug/tracing/set_event
>=20
> or
>=20
> echo 1 > /sys/kernel/debug/tracing/events/of/enable
>=20
> The following shows the trace point data from a DLPAR remove of a cpu
> from a pseries lpar:
>=20
> cat /sys/kernel/debug/tracing/trace | grep "POWER8@10"
>=20
> cpuhp/23-147 [023] .... 128.324827:
> of_node_put: refcount=3D5, dn->full_name=3D/cpus/PowerPC,POWER8@10
> cpuhp/23-147 [023] .... 128.324829:
> of_node_put: refcount=3D4, dn->full_name=3D/cpus/PowerPC,POWER8@10
> cpuhp/23-147 [023] .... 128.324829:
> of_node_put: refcount=3D3, dn->full_name=3D/cpus/PowerPC,POWER8@10
> cpuhp/23-147 [023] .... 128.324831:
> of_node_put: refcount=3D2, dn->full_name=3D/cpus/PowerPC,POWER8@10
> drmgr-7284 [009] .... 128.439000:
> of_node_put: refcount=3D1, dn->full_name=3D/cpus/PowerPC,POWER8@10
> drmgr-7284 [009] .... 128.439002:
> of_reconfig_notify: action=3DDETACH_NODE, dn->full_name=3D/cpus/P=
owerPC,POWER8@10,
> prop->name=3Dnull, old_prop->name=3Dnull
> drmgr-7284 [009] .... 128.439015:
> of_node_put: refcount=3D0, dn->full_name=3D/cpus/PowerPC,POWER8@10
> drmgr-7284 [009] .... 128.439016:
> of_node_release: dn->full_name=3D/cpus/PowerPC,POWER8@10, dn->_fl=
ags=3D4
>=20
> Signed-off-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
> [wsa: fixed commit abbrev and one of the sysfs paths in commit desc,
> removed trailing space and fixed pointer declaration in code]
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
=46rom the tracing perspective:
Reviewed-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
-- Steve
> ---
^ permalink raw reply
* Re: [PATCH v10 01/27] mm, powerpc, x86: define VM_PKEY_BITx bits if CONFIG_ARCH_HAS_PKEYS is enabled
From: Aneesh Kumar K.V @ 2018-01-21 15:34 UTC (permalink / raw)
To: Ram Pai, mpe, mingo, akpm, corbet, arnd
Cc: linuxppc-dev, linux-mm, x86, linux-arch, linux-doc,
linux-kselftest, linux-kernel, dave.hansen, benh, paulus,
khandual, bsingharora, hbabu, mhocko, bauerman, ebiederm,
linuxram
In-Reply-To: <1516326648-22775-2-git-send-email-linuxram@us.ibm.com>
Ram Pai <linuxram@us.ibm.com> writes:
> VM_PKEY_BITx are defined only if CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS
> is enabled. Powerpc also needs these bits. Hence lets define the
> VM_PKEY_BITx bits for any architecture that enables
> CONFIG_ARCH_HAS_PKEYS.
>
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
> Signed-off-by: Ram Pai <linuxram@us.ibm.com>
> ---
> fs/proc/task_mmu.c | 4 ++--
> include/linux/mm.h | 9 +++++----
> 2 files changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> index 339e4c1..b139617 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -674,13 +674,13 @@ static void show_smap_vma_flags(struct seq_file *m, struct vm_area_struct *vma)
> [ilog2(VM_MERGEABLE)] = "mg",
> [ilog2(VM_UFFD_MISSING)]= "um",
> [ilog2(VM_UFFD_WP)] = "uw",
> -#ifdef CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS
> +#ifdef CONFIG_ARCH_HAS_PKEYS
> /* These come out via ProtectionKey: */
> [ilog2(VM_PKEY_BIT0)] = "",
> [ilog2(VM_PKEY_BIT1)] = "",
> [ilog2(VM_PKEY_BIT2)] = "",
> [ilog2(VM_PKEY_BIT3)] = "",
> -#endif
> +#endif /* CONFIG_ARCH_HAS_PKEYS */
> };
> size_t i;
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index ea818ff..01381d3 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -228,15 +228,16 @@ extern int overcommit_kbytes_handler(struct ctl_table *, int, void __user *,
> #define VM_HIGH_ARCH_4 BIT(VM_HIGH_ARCH_BIT_4)
> #endif /* CONFIG_ARCH_USES_HIGH_VMA_FLAGS */
>
> -#if defined(CONFIG_X86)
> -# define VM_PAT VM_ARCH_1 /* PAT reserves whole VMA at once (x86) */
> -#if defined (CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS)
> +#ifdef CONFIG_ARCH_HAS_PKEYS
> # define VM_PKEY_SHIFT VM_HIGH_ARCH_BIT_0
> # define VM_PKEY_BIT0 VM_HIGH_ARCH_0 /* A protection key is a 4-bit value */
> # define VM_PKEY_BIT1 VM_HIGH_ARCH_1
> # define VM_PKEY_BIT2 VM_HIGH_ARCH_2
> # define VM_PKEY_BIT3 VM_HIGH_ARCH_3
> -#endif
> +#endif /* CONFIG_ARCH_HAS_PKEYS */
> +
> +#if defined(CONFIG_X86)
> +# define VM_PAT VM_ARCH_1 /* PAT reserves whole VMA at once (x86) */
> #elif defined(CONFIG_PPC)
> # define VM_SAO VM_ARCH_1 /* Strong Access Ordering (powerpc) */
> #elif defined(CONFIG_PARISC)
> --
> 1.7.1
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [RFC PATCH v2 1/1] of: introduce event tracepoints for dynamic device_node lifecyle
From: Wolfram Sang @ 2018-01-21 14:31 UTC (permalink / raw)
To: devicetree
Cc: Tyrel Datwyler, Geert Uytterhoeven, linux-renesas-soc,
linuxppc-dev, Rob Herring, Frank Rowand, Steven Rostedt,
linux-kernel, Wolfram Sang
In-Reply-To: <20180121143117.19805-1-wsa+renesas@sang-engineering.com>
From: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
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 pseries (DLPAR)
dynamic logical partitioning code (ie. POWER speak for hotplugging
virtual and physcial resources at runtime such as cpus or IOAs). These
tracepoints provide a easy and quick mechanism for validating the
reference counting of device_nodes during their lifetime.
Further, when pseries lpars are migrated to a different machine we
perform a live update of our device tree to bring it into alignment with
the configuration of the new machine. The of_reconfig_notify trace point
provides a mechanism that can be turned for debuging the device tree
modifications with out having to build a custom kernel to get at the
DEBUG code introduced by commit 00aa37206e1a54 ("of/reconfig: Add debug
output for OF_RECONFIG notifiers").
The following trace events are provided: of_node_get, of_node_put,
of_node_release, and of_reconfig_notify. These trace points require a
kernel built with ftrace support to be enabled. In a typical environment
where debugfs is mounted at /sys/kernel/debug the entire set of
tracepoints can be set with the following:
echo "of:*" > /sys/kernel/debug/tracing/set_event
or
echo 1 > /sys/kernel/debug/tracing/events/of/enable
The following shows the trace point data from a DLPAR remove of a cpu
from a pseries lpar:
cat /sys/kernel/debug/tracing/trace | grep "POWER8@10"
cpuhp/23-147 [023] .... 128.324827:
of_node_put: refcount=5, dn->full_name=/cpus/PowerPC,POWER8@10
cpuhp/23-147 [023] .... 128.324829:
of_node_put: refcount=4, dn->full_name=/cpus/PowerPC,POWER8@10
cpuhp/23-147 [023] .... 128.324829:
of_node_put: refcount=3, dn->full_name=/cpus/PowerPC,POWER8@10
cpuhp/23-147 [023] .... 128.324831:
of_node_put: refcount=2, dn->full_name=/cpus/PowerPC,POWER8@10
drmgr-7284 [009] .... 128.439000:
of_node_put: refcount=1, dn->full_name=/cpus/PowerPC,POWER8@10
drmgr-7284 [009] .... 128.439002:
of_reconfig_notify: action=DETACH_NODE, dn->full_name=/cpus/PowerPC,POWER8@10,
prop->name=null, old_prop->name=null
drmgr-7284 [009] .... 128.439015:
of_node_put: refcount=0, dn->full_name=/cpus/PowerPC,POWER8@10
drmgr-7284 [009] .... 128.439016:
of_node_release: dn->full_name=/cpus/PowerPC,POWER8@10, dn->_flags=4
Signed-off-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
[wsa: fixed commit abbrev and one of the sysfs paths in commit desc,
removed trailing space and fixed pointer declaration in code]
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
drivers/of/dynamic.c | 32 ++++++----------
include/trace/events/of.h | 93 +++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 105 insertions(+), 20 deletions(-)
create mode 100644 include/trace/events/of.h
diff --git a/drivers/of/dynamic.c b/drivers/of/dynamic.c
index ab988d88704da0..b0d6ab5a35b8c6 100644
--- a/drivers/of/dynamic.c
+++ b/drivers/of/dynamic.c
@@ -21,6 +21,9 @@ static struct device_node *kobj_to_device_node(struct kobject *kobj)
return container_of(kobj, struct device_node, kobj);
}
+#define CREATE_TRACE_POINTS
+#include <trace/events/of.h>
+
/**
* of_node_get() - Increment refcount of a node
* @node: Node to inc refcount, NULL is supported to simplify writing of
@@ -30,8 +33,10 @@ static struct device_node *kobj_to_device_node(struct kobject *kobj)
*/
struct device_node *of_node_get(struct device_node *node)
{
- if (node)
+ if (node) {
kobject_get(&node->kobj);
+ trace_of_node_get(refcount_read(&node->kobj.kref.refcount), node->full_name);
+ }
return node;
}
EXPORT_SYMBOL(of_node_get);
@@ -43,8 +48,10 @@ EXPORT_SYMBOL(of_node_get);
*/
void of_node_put(struct device_node *node)
{
- if (node)
+ if (node) {
+ trace_of_node_put(refcount_read(&node->kobj.kref.refcount) - 1, node->full_name);
kobject_put(&node->kobj);
+ }
}
EXPORT_SYMBOL(of_node_put);
@@ -75,24 +82,7 @@ const char *action_names[] = {
int of_reconfig_notify(unsigned long action, struct of_reconfig_data *p)
{
int rc;
-#ifdef DEBUG
- struct of_reconfig_data *pr = p;
-
- switch (action) {
- case OF_RECONFIG_ATTACH_NODE:
- case OF_RECONFIG_DETACH_NODE:
- pr_debug("notify %-15s %pOF\n", action_names[action],
- pr->dn);
- break;
- case OF_RECONFIG_ADD_PROPERTY:
- case OF_RECONFIG_REMOVE_PROPERTY:
- case OF_RECONFIG_UPDATE_PROPERTY:
- pr_debug("notify %-15s %pOF:%s\n", action_names[action],
- pr->dn, pr->prop->name);
- break;
-
- }
-#endif
+ trace_of_reconfig_notify(action, p);
rc = blocking_notifier_call_chain(&of_reconfig_chain, action, p);
return notifier_to_errno(rc);
}
@@ -320,6 +310,8 @@ void of_node_release(struct kobject *kobj)
{
struct device_node *node = kobj_to_device_node(kobj);
+ trace_of_node_release(node);
+
/* We should never be releasing nodes that haven't been detached. */
if (!of_node_check_flag(node, OF_DETACHED)) {
pr_err("ERROR: Bad of_node_put() on %pOF\n", node);
diff --git a/include/trace/events/of.h b/include/trace/events/of.h
new file mode 100644
index 00000000000000..e8b1302a6f0129
--- /dev/null
+++ b/include/trace/events/of.h
@@ -0,0 +1,93 @@
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM of
+
+#if !defined(_TRACE_OF_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_OF_H
+
+#include <linux/of.h>
+#include <linux/tracepoint.h>
+
+DECLARE_EVENT_CLASS(of_node_ref_template,
+
+ TP_PROTO(int refcount, const char *dn_name),
+
+ TP_ARGS(refcount, dn_name),
+
+ TP_STRUCT__entry(
+ __string(dn_name, dn_name)
+ __field(int, refcount)
+ ),
+
+ TP_fast_assign(
+ __assign_str(dn_name, dn_name);
+ __entry->refcount = refcount;
+ ),
+
+ TP_printk("refcount=%d, dn->full_name=%s",
+ __entry->refcount, __get_str(dn_name))
+);
+
+DEFINE_EVENT(of_node_ref_template, of_node_get,
+ TP_PROTO(int refcount, const char *dn_name),
+ TP_ARGS(refcount, dn_name));
+
+DEFINE_EVENT(of_node_ref_template, of_node_put,
+ TP_PROTO(int refcount, const char *dn_name),
+ TP_ARGS(refcount, dn_name));
+
+TRACE_EVENT(of_node_release,
+
+ TP_PROTO(struct device_node *dn),
+
+ TP_ARGS(dn),
+
+ TP_STRUCT__entry(
+ __string(dn_name, dn->full_name)
+ __field(unsigned long, flags)
+ ),
+
+ TP_fast_assign(
+ __assign_str(dn_name, dn->full_name);
+ __entry->flags = dn->_flags;
+ ),
+
+ TP_printk("dn->full_name=%s, dn->_flags=%lu",
+ __get_str(dn_name), __entry->flags)
+);
+
+#define of_reconfig_action_names \
+ {OF_RECONFIG_ATTACH_NODE, "ATTACH_NODE"}, \
+ {OF_RECONFIG_DETACH_NODE, "DETACH_NODE"}, \
+ {OF_RECONFIG_ADD_PROPERTY, "ADD_PROPERTY"}, \
+ {OF_RECONFIG_REMOVE_PROPERTY, "REMOVE_PROPERTY"}, \
+ {OF_RECONFIG_UPDATE_PROPERTY, "UPDATE_PROPERTY"}
+
+TRACE_EVENT(of_reconfig_notify,
+
+ TP_PROTO(unsigned long action, struct of_reconfig_data *ord),
+
+ TP_ARGS(action, ord),
+
+ TP_STRUCT__entry(
+ __field(unsigned long, action)
+ __string(dn_name, ord->dn->full_name)
+ __string(prop_name, ord->prop ? ord->prop->name : "null")
+ __string(oldprop_name, ord->old_prop ? ord->old_prop->name : "null")
+ ),
+
+ TP_fast_assign(
+ __entry->action = action;
+ __assign_str(dn_name, ord->dn->full_name);
+ __assign_str(prop_name, ord->prop ? ord->prop->name : "null");
+ __assign_str(oldprop_name, ord->old_prop ? ord->old_prop->name : "null");
+ ),
+
+ TP_printk("action=%s, dn->full_name=%s, prop->name=%s, old_prop->name=%s",
+ __print_symbolic(__entry->action, of_reconfig_action_names),
+ __get_str(dn_name), __get_str(prop_name), __get_str(oldprop_name))
+);
+
+#endif /* _TRACE_OF_H */
+
+/* This part must be outside protection */
+#include <trace/define_trace.h>
--
2.11.0
^ permalink raw reply related
* [RFC PATCH v2 0/1] of: easier debugging for node life cycle issues
From: Wolfram Sang @ 2018-01-21 14:31 UTC (permalink / raw)
To: devicetree
Cc: Tyrel Datwyler, Geert Uytterhoeven, linux-renesas-soc,
linuxppc-dev, Rob Herring, Frank Rowand, Steven Rostedt,
linux-kernel, Wolfram Sang
I got a bug report for a DT node refcounting problem in the I2C subsystem. This
patch was a huge help in validating the bug report and the proposed solution.
So, I thought I bring it to attention again. Thanks Tyrel, for the initial
work!
Note that I did not test the dynamic updates, only of_node_{get|put} so far. I
read that Tyrel checked dynamic updates extensively with this patch. And since
DT overlays are also used within our Renesas dev team, this will help there, as
well.
Tested on a Renesas Salvator-XS board (R-Car H3).
Changes since RFC v1:
* rebased to v4.15-rc8
* fixed commit abbrev and one of the sysfs paths in commit desc
* removed trailing space and fixed pointer declaration in code
I consider all the remaining checkpatch issues irrelevant for this patch.
So what about applying it?
Kind regards,
Wolfram
Tyrel Datwyler (1):
of: introduce event tracepoints for dynamic device_node lifecyle
drivers/of/dynamic.c | 32 ++++++----------
include/trace/events/of.h | 93 +++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 105 insertions(+), 20 deletions(-)
create mode 100644 include/trace/events/of.h
--
2.11.0
^ permalink raw reply
* Pull request: scottwood/linux.git next
From: Scott Wood @ 2018-01-21 7:55 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, galak
Contains fixes for CPM GPIO and an FSL PCI erratum workaround,
plus a minor cleanup patch.
The following changes since commit f2ac428e0edabbca41b9dfe9473a90147962e4e9:
powerpc/pseries/cpuidle: add polling idle for shared processor guests (2018-01-18 15:43:44 +1100)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git next
for you to fetch changes up to c095ff93f901c1620b28dce4d813dd548bc5236b:
powerpc/sysdev: change CPM GPIO to platform_device (2018-01-20 23:29:02 -0600)
----------------------------------------------------------------
Christophe Leroy (1):
powerpc/sysdev: change CPM GPIO to platform_device
Joakim Tjernlund (1):
powerpc/fsl_pci: Correct fsl_pci_mcheck_exception
Vasyl Gomonovych (1):
powerpc/fsl_pci: Fix ptr_ret.cocci warnings
arch/powerpc/include/asm/cpm.h | 2 +-
arch/powerpc/include/asm/cpm1.h | 2 +
arch/powerpc/sysdev/Makefile | 3 +-
arch/powerpc/sysdev/cpm1.c | 33 ++++-------------
arch/powerpc/sysdev/cpm2.c | 11 ------
arch/powerpc/sysdev/cpm_common.c | 5 ++-
arch/powerpc/sysdev/cpm_gpio.c | 80 ++++++++++++++++++++++++++++++++++++++++
arch/powerpc/sysdev/fsl_pci.c | 6 +--
8 files changed, 99 insertions(+), 43 deletions(-)
create mode 100644 arch/powerpc/sysdev/cpm_gpio.c
^ permalink raw reply
* Re: [PATCH v2 1/5] powerpc/mm: Enhance 'slice' for supporting PPC32
From: Segher Boessenkool @ 2018-01-20 17:56 UTC (permalink / raw)
To: christophe leroy
Cc: Aneesh Kumar K.V, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, Scott Wood, linuxppc-dev, linux-kernel
In-Reply-To: <36e8d873-4021-4266-bf5f-287f396ba9e1@c-s.fr>
Hi!
On Sat, Jan 20, 2018 at 09:22:50AM +0100, christophe leroy wrote:
> >>>>>>>On PPC32, the address space is limited to 4Gbytes, hence only the
> >>>>>>>low
> >>>>>>>slices will be used. As of today, the code uses
> >>>>>>>SLICE_LOW_TOP (0x100000000ul) and compares it with addr to determine
> >>>>>>>if addr refers to low or high space.
> >>>>>>>On PPC32, such a (addr < SLICE_LOW_TOP) test is always false because
> >>>>>>>0x100000000ul degrades to 0. Therefore, the patch modifies
> >>>>>>>SLICE_LOW_TOP to (0xfffffffful) and modifies the tests to
> >>>>>>>(addr <= SLICE_LOW_TOP) which will then always be true on PPC32
> >>>>>>>as addr has type 'unsigned long' while not modifying the PPC64
> >>>>>>>behaviour.
It should work to define SLICE_LOW_TOP as 0x100000000ull and keep
everything else the same, no?
> >I don't think so. When I had the missing prototype, the compilation goes
> >ok, including the final link. Which means at the end the code is not
> >included since radix_enabled() evaluates to 0.
> >
> >Many many parts of the kernel are based on this assumption.
>
> Segher, what is your opinion on the above ? Can we consider that a ' if
> (nbits)' will always be compiled out when nbits is a #define constant,
> or should we duplicate the macros as suggested in order to avoid
> unneccessary 'if' test on platforms where 'nbits' is always not null by
> definition ?
Doing things like
if (nbits)
some_undeclared_function();
will likely work in practice if the condition evaluates to false at
compile time, but a) it will warn; b) it is just yuck; and c) it will
not always work (for example, you get the wrong prototype in this case,
not lethal here with most ABIs, but ugh).
Just make sure to declare all functions, or define it to some empty
thing, or #ifdeffery if you have to. There are many options, it is
not hard, and if it means you have to pull code further apart that is
not so bad: you get cleaner, clearer code.
Segher
^ permalink raw reply
* Re: [PATCH 02/13] powerpc/powernv: Set correct configuration space size for opencapi devices
From: Michael Ellerman @ 2018-01-20 9:52 UTC (permalink / raw)
To: Frederic Barrat, linuxppc-dev, linux-kernel
Cc: arnd, gregkh, andrew.donnellan, alastair
In-Reply-To: <386af9b4afde2a0f9cd699d79b0fdf3e4fc0e2d7.1513608243.git.fbarrat@linux.vnet.ibm.com>
Frederic Barrat <fbarrat@linux.vnet.ibm.com> writes:
> From Andrew Donnellan <andrew.donnellan@au1.ibm.com>
>
> The configuration space for opencapi devices doesn't have a PCI
> Express capability, therefore confusing linux in thinking it's of an
> old PCI type with a 256-byte configuration space size, instead of the
> desired 4k. So add a PCI fixup to declare the correct size.
>
>
> Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
> Signed-off-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
> ---
> arch/powerpc/platforms/powernv/pci-ioda.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
> index c37b5d288f9c..b8ec76aa266f 100644
> --- a/arch/powerpc/platforms/powernv/pci-ioda.c
> +++ b/arch/powerpc/platforms/powernv/pci-ioda.c
> @@ -4079,6 +4079,16 @@ void __init pnv_pci_init_npu2_opencapi_phb(struct device_node *np)
> pnv_pci_init_ioda_phb(np, 0, PNV_PHB_NPU_OCAPI);
> }
>
> +static void pnv_npu2_opencapi_cfg_size_fixup(struct pci_dev *dev)
> +{
> + struct pci_controller *hose = pci_bus_to_host(dev->bus);
> + struct pnv_phb *phb = hose->private_data;
> +
> + if (phb->type == PNV_PHB_NPU_OCAPI)
> + dev->cfg_size = PCI_CFG_SPACE_EXP_SIZE;
> +}
> +DECLARE_PCI_FIXUP_EARLY(PCI_ANY_ID, PCI_ANY_ID, pnv_npu2_opencapi_cfg_size_fixup);
On my Power8 PowerVM LPAR:
[ 0.096846] PCI: Probing PCI hardware
[ 0.096878] PCI host bridge to bus 0015:70
[ 0.096883] pci_bus 0015:70: root bus resource [mem 0x3fc0c0000000-0x3fc0cfffffff] (bus address [0xc0000000-0xcfffffff])
[ 0.096888] pci_bus 0015:70: root bus resource [mem 0x301800000000-0x301bffffffff] (bus address [0x3d01800000000-0x3d01bffffffff])
[ 0.096892] pci_bus 0015:70: root bus resource [bus 70-ff]
[ 0.097523] Unable to handle kernel paging request for data at address 0x00000008
[ 0.097526] Faulting instruction address: 0xc0000000000b3330
[ 0.097530] Oops: Kernel access of bad area, sig: 11 [#1]
[ 0.097532] LE SMP NR_CPUS=2048 NUMA pSeries
[ 0.097536] Modules linked in:
[ 0.097539] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.15.0-rc2-gcc7x-gf93b9d8 #1
[ 0.097543] task: 000000007ef679b5 task.stack: 00000000c7c0b3f9
[ 0.097546] NIP: c0000000000b3330 LR: c00000000067ee78 CTR: c0000000000b3300
[ 0.097549] REGS: 0000000012013889 TRAP: 0380 Not tainted (4.15.0-rc2-gcc7x-gf93b9d8)
[ 0.097552] MSR: 8000000002009033 <SF,VEC,EE,ME,IR,DR,RI,LE> CR: 88000842 XER: 2000000f
[ 0.097559] CFAR: c00000000067ee74 SOFTE: 0
[ 0.097559] GPR00: c00000000067ee78 c0000003f7583980 c00000000103f000 c0000003fd619800
[ 0.097559] GPR04: c000000000d9c0e0 c000000000d9c7a0 ffff0a01ffffff10 0000000000000030
[ 0.097559] GPR08: 0000000000000000 0000000000000000 000000000000ffff c000000000ba3428
[ 0.097559] GPR12: c0000000000b3300 c00000000fd40000 c00000000000d938 0000000000000000
[ 0.097559] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 0.097559] GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 0.097559] GPR24: c000000000e7b380 0000000000000000 0000000000000000 c0000000010d0088
[ 0.097559] GPR28: 000000000000ffff c000000000d9c7a0 c0000003fd619800 c0000003fd619800
[ 0.097595] NIP [c0000000000b3330] pnv_npu2_opencapi_cfg_size_fixup+0x30/0x60
[ 0.097599] LR [c00000000067ee78] pci_do_fixups+0xd8/0x140
[ 0.097602] Call Trace:
[ 0.097605] [c0000003f7583980] [c0000000000607a8] pci_dev_pdn_setup+0x58/0x70 (unreliable)
[ 0.097609] [c0000003f75839b0] [c00000000067ee78] pci_do_fixups+0xd8/0x140
[ 0.097613] [c0000003f7583a00] [c000000000064334] of_create_pci_dev+0x1d4/0x910
[ 0.097617] [c0000003f7583ab0] [c000000000064b98] __of_scan_bus+0x128/0x1e0
[ 0.097621] [c0000003f7583b20] [c00000000006225c] pcibios_scan_phb+0x22c/0x260
[ 0.097625] [c0000003f7583bc0] [c000000000e11648] pcibios_init+0x8c/0xe4
[ 0.097629] [c0000003f7583c40] [c00000000000d6b8] do_one_initcall+0x68/0x1e0
[ 0.097633] [c0000003f7583d00] [c000000000e04534] kernel_init_freeable+0x280/0x36c
[ 0.097636] [c0000003f7583dc0] [c00000000000d95c] kernel_init+0x2c/0x160
[ 0.097640] [c0000003f7583e30] [c00000000000bae8] ret_from_kernel_thread+0x5c/0x74
[ 0.097643] Instruction dump:
[ 0.097646] 3c4c00f9 3842bd00 7c0802a6 fbe1fff8 f8010010 f821ffd1 7c7f1b78 60000000
[ 0.097652] 60000000 e93f0010 e92900d0 e9290280 <81290008> 2f890003 409e000c 39201000
[ 0.097659] ---[ end trace 57e6a876df59eda0 ]---
And Power8 KVM guest:
[ 0.271653] PCI: Probing PCI hardware
[ 0.272640] PCI host bridge to bus 0000:00
[ 0.272897] pci_bus 0000:00: root bus resource [io 0x10000-0x1ffff] (bus address [0x0000-0xffff])
[ 0.273127] pci_bus 0000:00: root bus resource [mem 0x100a0000000-0x1101fffffff] (bus address [0x80000000-0xfffffffff])
[ 0.273346] pci_bus 0000:00: root bus resource [bus 00-ff]
[ 0.273610] Unable to handle kernel paging request for data at address 0x00000008
[ 0.273752] Faulting instruction address: 0xc0000000000b0030
[ 0.273878] Oops: Kernel access of bad area, sig: 11 [#1]
[ 0.273972] LE SMP NR_CPUS=2048 NUMA pSeries
[ 0.274068] Modules linked in:
[ 0.274140] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.15.0-rc2-gcc5x-gf93b9d8 #1
[ 0.274283] task: 000000001f3d5330 task.stack: 00000000f3462ef5
[ 0.274405] NIP: c0000000000b0030 LR: c00000000064aed8 CTR: c0000000000b0000
[ 0.274549] REGS: 000000000ef1a4d9 TRAP: 0380 Not tainted (4.15.0-rc2-gcc5x-gf93b9d8)
[ 0.274692] MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 28000222 XER: 20000000
[ 0.274838] CFAR: c00000000064aed4 SOFTE: 0
[ 0.274838] GPR00: c00000000064aed8 c0000000fea87970 c000000000feec00 c0000000fe184108
[ 0.274838] GPR04: c000000000d4bbf8 00000000ffffffff 0000000000000008 0000000098968000
[ 0.274838] GPR08: 0000000000000038 0000000000000000 0000000000000000 0000000000000001
[ 0.274838] GPR12: c0000000000b0000 c00000000fd40000 c00000000000d798 0000000000000000
[ 0.274838] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 0.274838] GPR20: 0000000000000000 0000000000000000 0000000000000000 c000000000d987b8
[ 0.274838] GPR24: c000000000db3894 0000000000000000 c000000000ca7d28 c000000001080088
[ 0.274838] GPR28: 000000000000ffff c000000000d4c2b8 c0000000fe184108 c0000000fe184108
[ 0.276032] NIP [c0000000000b0030] pnv_npu2_opencapi_cfg_size_fixup+0x30/0x60
[ 0.276178] LR [c00000000064aed8] pci_do_fixups+0xd8/0x130
[ 0.276269] Call Trace:
[ 0.276317] [c0000000fea87970] [c00000000005eb78] pci_dev_pdn_setup+0x58/0x70 (unreliable)
[ 0.276458] [c0000000fea879a0] [c00000000064aed8] pci_do_fixups+0xd8/0x130
[ 0.276575] [c0000000fea879f0] [c000000000062608] of_create_pci_dev+0x1d8/0x420
[ 0.276715] [c0000000fea87aa0] [c000000000062974] __of_scan_bus+0x124/0x1f0
[ 0.276831] [c0000000fea87b10] [c0000000000604dc] pcibios_scan_phb+0x24c/0x280
[ 0.276967] [c0000000fea87bb0] [c000000000dc16c4] pcibios_init+0x90/0xe8
[ 0.277078] [c0000000fea87c30] [c00000000000d5f8] do_one_initcall+0x138/0x1d0
[ 0.277208] [c0000000fea87cf0] [c000000000db45e8] kernel_init_freeable+0x298/0x378
[ 0.277341] [c0000000fea87dc0] [c00000000000d7bc] kernel_init+0x2c/0x160
[ 0.277454] [c0000000fea87e30] [c00000000000bae8] ret_from_kernel_thread+0x5c/0x74
[ 0.277591] Instruction dump:
[ 0.277662] 3c4c00f4 3842ec00 7c0802a6 fbe1fff8 f8010010 f821ffd1 7c7f1b78 60000000
[ 0.277804] 60000000 e93f0010 e92900d0 e9290280 <81290008> 2f890003 409e000c 39201000
[ 0.277950] ---[ end trace df10e6159ca0c179 ]---
cheers
^ permalink raw reply
* Re: [PATCH v2 1/5] powerpc/mm: Enhance 'slice' for supporting PPC32
From: christophe leroy @ 2018-01-20 8:22 UTC (permalink / raw)
To: Aneesh Kumar K.V, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, Scott Wood, Segher Boessenkool
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <e2f36c99-1b5d-acf5-12c8-b2b48701011a@c-s.fr>
Hi Segher,
Le 19/01/2018 à 10:45, Christophe LEROY a écrit :
>
>
> Le 19/01/2018 à 10:13, Aneesh Kumar K.V a écrit :
>>
>>
>> On 01/19/2018 02:37 PM, Christophe LEROY wrote:
>>>
>>>
>>> Le 19/01/2018 à 10:02, Aneesh Kumar K.V a écrit :
>>>>
>>>>
>>>> On 01/19/2018 02:14 PM, Christophe LEROY wrote:
>>>>>
>>>>>
>>>>> Le 19/01/2018 à 09:24, Aneesh Kumar K.V a écrit :
>>>>>> Christophe Leroy <christophe.leroy@c-s.fr> writes:
>>>>>>
>>>>>>> In preparation for the following patch which will fix an issue on
>>>>>>> the 8xx by re-using the 'slices', this patch enhances the
>>>>>>> 'slices' implementation to support 32 bits CPUs.
>>>>>>>
>>>>>>> On PPC32, the address space is limited to 4Gbytes, hence only the
>>>>>>> low
>>>>>>> slices will be used. As of today, the code uses
>>>>>>> SLICE_LOW_TOP (0x100000000ul) and compares it with addr to determine
>>>>>>> if addr refers to low or high space.
>>>>>>> On PPC32, such a (addr < SLICE_LOW_TOP) test is always false because
>>>>>>> 0x100000000ul degrades to 0. Therefore, the patch modifies
>>>>>>> SLICE_LOW_TOP to (0xfffffffful) and modifies the tests to
>>>>>>> (addr <= SLICE_LOW_TOP) which will then always be true on PPC32
>>>>>>> as addr has type 'unsigned long' while not modifying the PPC64
>>>>>>> behaviour.
>>>>>>>
>>>>>>> This patch moves "slices" functions prototypes from page64.h to
>>>>>>> page.h
>>>>>>>
>>>>>>> The high slices use bitmaps. As bitmap functions are not prepared to
>>>>>>> handling bitmaps of size 0, the bitmap_xxx() calls are wrapped into
>>>>>>> slice_bitmap_xxx() macros which will take care of the 0 nbits case.
>>>>>>>
>>>>>>> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
>>>>>>> ---
>>>>>>> v2: First patch of v1 serie split in two parts ; added
>>>>>>> slice_bitmap_xxx() macros.
>>>>>>>
>>>>>>> arch/powerpc/include/asm/page.h | 14 +++++++++
>>>>>>> arch/powerpc/include/asm/page_32.h | 19 ++++++++++++
>>>>>>> arch/powerpc/include/asm/page_64.h | 21 ++-----------
>>>>>>> arch/powerpc/mm/hash_utils_64.c | 2 +-
>>>>>>> arch/powerpc/mm/mmu_context_nohash.c | 7 +++++
>>>>>>> arch/powerpc/mm/slice.c | 60
>>>>>>> ++++++++++++++++++++++++------------
>>>>>>> 6 files changed, 83 insertions(+), 40 deletions(-)
>>>>>>>
>>>>>>> diff --git a/arch/powerpc/include/asm/page.h
>>>>>>> b/arch/powerpc/include/asm/page.h
>>>>>>> index 8da5d4c1cab2..d0384f9db9eb 100644
>>>>>>> --- a/arch/powerpc/include/asm/page.h
>>>>>>> +++ b/arch/powerpc/include/asm/page.h
>>>>>>> @@ -342,6 +342,20 @@ typedef struct page *pgtable_t;
>>>>>>> #endif
>>>>>>> #endif
>>>>>>> +#ifdef CONFIG_PPC_MM_SLICES
>>>>>>> +struct mm_struct;
>>>>>>> +
>>>>>>> +unsigned long slice_get_unmapped_area(unsigned long addr,
>>>>>>> unsigned long len,
>>>>>>> + unsigned long flags, unsigned int psize,
>>>>>>> + int topdown);
>>>>>>> +
>>>>>>> +unsigned int get_slice_psize(struct mm_struct *mm, unsigned long
>>>>>>> addr);
>>>>>>> +
>>>>>>> +void slice_set_user_psize(struct mm_struct *mm, unsigned int
>>>>>>> psize);
>>>>>>> +void slice_set_range_psize(struct mm_struct *mm, unsigned long
>>>>>>> start,
>>>>>>> + unsigned long len, unsigned int psize);
>>>>>>> +#endif
>>>>>>> +
>>>>>>
>>>>>> Should we do a slice.h ? the way we have other files? and then do
>>>>>
>>>>> Yes we could add a slice.h instead of using page.h for that, good
>>>>> idea.
>>>>>
>>>>>>
>>>>>> arch/powerpc/include/asm/book3s/64/slice.h that will carry
>>>>>> #define slice_bitmap_zero(dst, nbits) \
>>>>>> do { if (nbits) bitmap_zero(dst, nbits); } while (0)
>>>>>> #define slice_bitmap_set(dst, pos, nbits) \
>>>>>> do { if (nbits) bitmap_set(dst, pos, nbits); } while (0)
>>>>>> #define slice_bitmap_copy(dst, src, nbits) \
>>>>>> do { if (nbits) bitmap_copy(dst, src, nbits); } while (0)
>>>>>> #define slice_bitmap_and(dst, src1, src2, nbits) \
>>>>>> ({ (nbits) ? bitmap_and(dst, src1, src2, nbits) : 0; })
>>>>>> #define slice_bitmap_or(dst, src1, src2, nbits) \
>>>>>> do { if (nbits) bitmap_or(dst, src1, src2, nbits); } while (0)
>>>>>> #define slice_bitmap_andnot(dst, src1, src2, nbits) \
>>>>>> ({ (nbits) ? bitmap_andnot(dst, src1, src2, nbits) : 0; })
>>>>>> #define slice_bitmap_equal(src1, src2, nbits) \
>>>>>> ({ (nbits) ? bitmap_equal(src1, src2, nbits) : 1; })
>>>>>> #define slice_bitmap_empty(src, nbits) \
>>>>>> ({ (nbits) ? bitmap_empty(src, nbits) : 1; })
>>>>>>
>>>>>> This without that if(nbits) check and a proper static inline so
>>>>>> that we
>>>>>> can do type checking.
>>>>>
>>>>> Is it really worth duplicating that just for eliminating the 'if
>>>>> (nbits)' in one case ?
>>>>>
>>>>> Only in book3s/64 we will be able to eliminate that, for nohash/32
>>>>> we need to keep the test due to the difference between low and high
>>>>> slices.
>>>>
>>>> the other advantage is we move the SLICE_LOW_SHIFT to the right
>>>> location. IMHO mm subystem is really complex with these really
>>>> overloaded headers. If we can keep it seperate we should with
>>>> minimal code duplication?
>>>
>>> For the constants I fully agree with your proposal and I will do it.
>>> I was only questionning the benefit of moving the slice_bitmap_xxxx()
>>> stuff, taking into account that the 'if (nbits)' test is already
>>> eliminated by the compiler.
>>>
>>
>> That is compiler dependent as you are finding with the other patch
>> where if (0) didn't get compiled out
>
> I don't think so. When I had the missing prototype, the compilation goes
> ok, including the final link. Which means at the end the code is not
> included since radix_enabled() evaluates to 0.
>
> Many many parts of the kernel are based on this assumption.
>
Segher, what is your opinion on the above ? Can we consider that a ' if
(nbits)' will always be compiled out when nbits is a #define constant,
or should we duplicate the macros as suggested in order to avoid
unneccessary 'if' test on platforms where 'nbits' is always not null by
definition ?
Patch is at https://patchwork.ozlabs.org/patch/862117/
Christophe
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
^ permalink raw reply
* Re: [PATCH] watchdog: core: make sure the watchdog_worker is not deferred
From: Guenter Roeck @ 2018-01-20 2:58 UTC (permalink / raw)
To: Christophe Leroy, Wim Van Sebroeck
Cc: linux-kernel, linuxppc-dev, linux-watchdog
In-Reply-To: <20180118111121.4542E65A3A@localhost.localdomain>
On 01/18/2018 03:11 AM, Christophe Leroy wrote:
> commit 4cd13c21b207e ("softirq: Let ksoftirqd do its job") has the
> effect of deferring timer handling in case of high CPU load, hence
> delaying the delayed work allthought the worker is running which
> high realtime priority.
>
> As hrtimers are not managed by softirqs, this patch replaces the
> delayed work by a plain work and uses an hrtimer to schedule that work.
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
> ---
> drivers/watchdog/watchdog_dev.c | 86 +++++++++++++++++++++++++----------------
> 1 file changed, 52 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/watchdog/watchdog_dev.c b/drivers/watchdog/watchdog_dev.c
> index 68bc29e6e79e..ffbdc4642ea5 100644
> --- a/drivers/watchdog/watchdog_dev.c
> +++ b/drivers/watchdog/watchdog_dev.c
> @@ -36,10 +36,10 @@
> #include <linux/errno.h> /* For the -ENODEV/... values */
> #include <linux/fs.h> /* For file operations */
> #include <linux/init.h> /* For __init/__exit/... */
> -#include <linux/jiffies.h> /* For timeout functions */
> +#include <linux/hrtimer.h> /* For hrtimers */
> #include <linux/kernel.h> /* For printk/panic/... */
> #include <linux/kref.h> /* For data references */
> -#include <linux/kthread.h> /* For kthread_delayed_work */
> +#include <linux/kthread.h> /* For kthread_work */
> #include <linux/miscdevice.h> /* For handling misc devices */
> #include <linux/module.h> /* For module stuff/... */
> #include <linux/mutex.h> /* For mutexes */
> @@ -67,9 +67,10 @@ struct watchdog_core_data {
> struct cdev cdev;
> struct watchdog_device *wdd;
> struct mutex lock;
> - unsigned long last_keepalive;
> - unsigned long last_hw_keepalive;
> - struct kthread_delayed_work work;
> + ktime_t last_keepalive;
> + ktime_t last_hw_keepalive;
> + struct hrtimer timer;
> + struct kthread_work work;
> unsigned long status; /* Internal status bits */
> #define _WDOG_DEV_OPEN 0 /* Opened ? */
> #define _WDOG_ALLOW_RELEASE 1 /* Did we receive the magic char ? */
> @@ -109,18 +110,19 @@ static inline bool watchdog_need_worker(struct watchdog_device *wdd)
> (t && !watchdog_active(wdd) && watchdog_hw_running(wdd));
> }
>
> -static long watchdog_next_keepalive(struct watchdog_device *wdd)
> +static ktime_t watchdog_next_keepalive(struct watchdog_device *wdd)
> {
> struct watchdog_core_data *wd_data = wdd->wd_data;
> unsigned int timeout_ms = wdd->timeout * 1000;
> - unsigned long keepalive_interval;
> - unsigned long last_heartbeat;
> - unsigned long virt_timeout;
> + ktime_t keepalive_interval;
> + ktime_t last_heartbeat, latest_heartbeat;
> + ktime_t virt_timeout;
> unsigned int hw_heartbeat_ms;
>
> - virt_timeout = wd_data->last_keepalive + msecs_to_jiffies(timeout_ms);
> + virt_timeout = ktime_add(wd_data->last_keepalive,
> + ms_to_ktime(timeout_ms));
> hw_heartbeat_ms = min_not_zero(timeout_ms, wdd->max_hw_heartbeat_ms);
> - keepalive_interval = msecs_to_jiffies(hw_heartbeat_ms / 2);
> + keepalive_interval = ms_to_ktime(hw_heartbeat_ms / 2);
>
> if (!watchdog_active(wdd))
> return keepalive_interval;
> @@ -130,8 +132,11 @@ static long watchdog_next_keepalive(struct watchdog_device *wdd)
> * after the most recent ping from userspace, the last
> * worker ping has to come in hw_heartbeat_ms before this timeout.
> */
> - last_heartbeat = virt_timeout - msecs_to_jiffies(hw_heartbeat_ms);
> - return min_t(long, last_heartbeat - jiffies, keepalive_interval);
> + last_heartbeat = ktime_sub(virt_timeout, ms_to_ktime(hw_heartbeat_ms));
> + latest_heartbeat = ktime_sub(last_heartbeat, ktime_get());
> + if (ktime_before(latest_heartbeat, keepalive_interval))
> + return latest_heartbeat;
> + return keepalive_interval;
> }
>
> static inline void watchdog_update_worker(struct watchdog_device *wdd)
> @@ -139,30 +144,33 @@ static inline void watchdog_update_worker(struct watchdog_device *wdd)
> struct watchdog_core_data *wd_data = wdd->wd_data;
>
> if (watchdog_need_worker(wdd)) {
> - long t = watchdog_next_keepalive(wdd);
> + ktime_t t = watchdog_next_keepalive(wdd);
>
> if (t > 0)
> - kthread_mod_delayed_work(watchdog_kworker,
> - &wd_data->work, t);
> + hrtimer_start(&wd_data->timer, t, HRTIMER_MODE_REL);
> } else {
> - kthread_cancel_delayed_work_sync(&wd_data->work);
> + hrtimer_cancel(&wd_data->timer);
> }
> }
>
> static int __watchdog_ping(struct watchdog_device *wdd)
> {
> struct watchdog_core_data *wd_data = wdd->wd_data;
> - unsigned long earliest_keepalive = wd_data->last_hw_keepalive +
> - msecs_to_jiffies(wdd->min_hw_heartbeat_ms);
> + ktime_t earliest_keepalive, now;
> int err;
>
> - if (time_is_after_jiffies(earliest_keepalive)) {
> - kthread_mod_delayed_work(watchdog_kworker, &wd_data->work,
> - earliest_keepalive - jiffies);
> + earliest_keepalive = ktime_add(wd_data->last_hw_keepalive,
> + ms_to_ktime(wdd->min_hw_heartbeat_ms));
> + now = ktime_get();
> +
> + if (ktime_after(earliest_keepalive, now)) {
> + hrtimer_start(&wd_data->timer,
> + ktime_sub(earliest_keepalive, now),
> + HRTIMER_MODE_REL);
> return 0;
> }
>
> - wd_data->last_hw_keepalive = jiffies;
> + wd_data->last_hw_keepalive = now;
>
> if (wdd->ops->ping)
> err = wdd->ops->ping(wdd); /* ping the watchdog */
> @@ -195,7 +203,7 @@ static int watchdog_ping(struct watchdog_device *wdd)
>
> set_bit(_WDOG_KEEPALIVE, &wd_data->status);
>
> - wd_data->last_keepalive = jiffies;
> + wd_data->last_keepalive = ktime_get();
> return __watchdog_ping(wdd);
> }
>
> @@ -210,9 +218,7 @@ static void watchdog_ping_work(struct kthread_work *work)
> {
> struct watchdog_core_data *wd_data;
>
> - wd_data = container_of(container_of(work, struct kthread_delayed_work,
> - work),
> - struct watchdog_core_data, work);
> + wd_data = container_of(work, struct watchdog_core_data, work);
>
> mutex_lock(&wd_data->lock);
> if (watchdog_worker_should_ping(wd_data))
> @@ -220,6 +226,16 @@ static void watchdog_ping_work(struct kthread_work *work)
> mutex_unlock(&wd_data->lock);
> }
>
> +static enum hrtimer_restart watchdog_timer_expired(struct hrtimer *timer)
> +{
> + struct watchdog_core_data *wd_data;
> +
> + wd_data = container_of(timer, struct watchdog_core_data, timer);
> +
> + kthread_queue_work(watchdog_kworker, &wd_data->work);
> + return HRTIMER_NORESTART;
> +}
> +
> /*
> * watchdog_start: wrapper to start the watchdog.
> * @wdd: the watchdog device to start
> @@ -234,7 +250,7 @@ static void watchdog_ping_work(struct kthread_work *work)
> static int watchdog_start(struct watchdog_device *wdd)
> {
> struct watchdog_core_data *wd_data = wdd->wd_data;
> - unsigned long started_at;
> + ktime_t started_at;
> int err;
>
> if (watchdog_active(wdd))
> @@ -242,7 +258,7 @@ static int watchdog_start(struct watchdog_device *wdd)
>
> set_bit(_WDOG_KEEPALIVE, &wd_data->status);
>
> - started_at = jiffies;
> + started_at = ktime_get();
> if (watchdog_hw_running(wdd) && wdd->ops->ping)
> err = wdd->ops->ping(wdd);
> else
> @@ -928,7 +944,9 @@ static int watchdog_cdev_register(struct watchdog_device *wdd, dev_t devno)
> if (IS_ERR_OR_NULL(watchdog_kworker))
> return -ENODEV;
>
> - kthread_init_delayed_work(&wd_data->work, watchdog_ping_work);
> + kthread_init_work(&wd_data->work, watchdog_ping_work);
> + hrtimer_init(&wd_data->timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
> + wd_data->timer.function = watchdog_timer_expired;
>
> if (wdd->id == 0) {
> old_wd_data = wd_data;
> @@ -964,7 +982,7 @@ static int watchdog_cdev_register(struct watchdog_device *wdd, dev_t devno)
> }
>
> /* Record time of most recent heartbeat as 'just before now'. */
> - wd_data->last_hw_keepalive = jiffies - 1;
> + wd_data->last_hw_keepalive = ktime_sub(ktime_get(), 1);
>
> /*
> * If the watchdog is running, prevent its driver from being unloaded,
> @@ -974,8 +992,7 @@ static int watchdog_cdev_register(struct watchdog_device *wdd, dev_t devno)
> __module_get(wdd->ops->owner);
> kref_get(&wd_data->kref);
> if (handle_boot_enabled)
> - kthread_queue_delayed_work(watchdog_kworker,
> - &wd_data->work, 0);
> + hrtimer_start(&wd_data->timer, 0, HRTIMER_MODE_REL);
> else
> pr_info("watchdog%d running and kernel based pre-userspace handler disabled\n",
> wdd->id);
> @@ -1012,7 +1029,8 @@ static void watchdog_cdev_unregister(struct watchdog_device *wdd)
> watchdog_stop(wdd);
> }
>
> - kthread_cancel_delayed_work_sync(&wd_data->work);
> + hrtimer_cancel(&wd_data->timer);
> + kthread_cancel_work_sync(&wd_data->work);
>
> kref_put(&wd_data->kref, watchdog_core_data_release);
> }
>
^ permalink raw reply
* Re: [PATCH 4/6] dt-bindings: gpio: Add binding for Wii GPIO controller
From: Jonathan Neuschäfer @ 2018-01-20 1:47 UTC (permalink / raw)
To: Rob Herring
Cc: Jonathan Neuschäfer, linux-kernel, linuxppc-dev, linux-gpio,
devicetree, Linus Walleij, Mark Rutland, Benjamin Herrenschmidt,
Paul Mackerras, Michael Ellerman
In-Reply-To: <20180119230521.st5uon74fpi4jghc@rob-hp-laptop>
[-- Attachment #1: Type: text/plain, Size: 717 bytes --]
On Fri, Jan 19, 2018 at 05:05:21PM -0600, Rob Herring wrote:
> On Mon, Jan 15, 2018 at 04:13:59AM +0100, Jonathan Neuschäfer wrote:
> > Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
> > ---
> > .../bindings/gpio/nintendo,hollywood-gpio.txt | 27 ++++++++++++++++++++++
> > .../devicetree/bindings/powerpc/nintendo/wii.txt | 9 +-------
> > 2 files changed, 28 insertions(+), 8 deletions(-)
> > create mode 100644 Documentation/devicetree/bindings/gpio/nintendo,hollywood-gpio.txt
[...]
> > +Example:
> > +
> > + GPIO: gpio@0d8000c0 {
>
> Drop the leading 0.
Ok, will do.
> With that,
>
> Reviewed-by: Rob Herring <robh@kernel.org>
Thanks.
Jonathan Neuschäfer
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 4/6] dt-bindings: gpio: Add binding for Wii GPIO controller
From: Rob Herring @ 2018-01-19 23:05 UTC (permalink / raw)
To: Jonathan Neuschäfer
Cc: linux-kernel, linuxppc-dev, linux-gpio, devicetree, Linus Walleij,
Mark Rutland, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman
In-Reply-To: <20180115031401.19577-5-j.neuschaefer@gmx.net>
On Mon, Jan 15, 2018 at 04:13:59AM +0100, Jonathan Neuschäfer wrote:
> Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
> ---
> .../bindings/gpio/nintendo,hollywood-gpio.txt | 27 ++++++++++++++++++++++
> .../devicetree/bindings/powerpc/nintendo/wii.txt | 9 +-------
> 2 files changed, 28 insertions(+), 8 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/gpio/nintendo,hollywood-gpio.txt
>
> diff --git a/Documentation/devicetree/bindings/gpio/nintendo,hollywood-gpio.txt b/Documentation/devicetree/bindings/gpio/nintendo,hollywood-gpio.txt
> new file mode 100644
> index 000000000000..a97ce6b5b724
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/nintendo,hollywood-gpio.txt
> @@ -0,0 +1,27 @@
> +Nintendo Wii (Hollywood) GPIO controller
> +
> +Required properties:
> +- compatible: "nintendo,hollywood-gpio
> +- reg: Physical base address and length of the controller's registers.
> +- gpio-controller: Marks the device node as a GPIO controller.
> +- #gpio-cells: Should be <2>. The first cell is the pin number and the
> + second cell is used to specify optional parameters:
> + - bit 0 specifies polarity (0 for normal, 1 for inverted).
> +
> +Optional properties:
> +- ngpios: see Documentation/devicetree/bindings/gpio/gpio.txt
> +- interrupt-controller: Marks the device node as an interrupt controller.
> +- #interrupt-cells: Should be two.
> +- interrupts: Interrupt specifier for the controller's Broadway (PowerPC)
> + interrupt.
> +- interrupt-parent: phandle of the parent interrupt controller.
> +
> +Example:
> +
> + GPIO: gpio@0d8000c0 {
Drop the leading 0.
With that,
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v10 27/27] mm: display pkey in smaps if arch_pkeys_enabled() is true
From: Eric W. Biederman @ 2018-01-19 17:04 UTC (permalink / raw)
To: Ram Pai
Cc: mpe, mingo, akpm, corbet, arnd, linuxppc-dev, linux-mm, x86,
linux-arch, linux-doc, linux-kselftest, linux-kernel, dave.hansen,
benh, paulus, khandual, aneesh.kumar, bsingharora, hbabu, mhocko,
bauerman
In-Reply-To: <20180119165050.GK5612@ram.oc3035372033.ibm.com>
Ram Pai <linuxram@us.ibm.com> writes:
> On Fri, Jan 19, 2018 at 10:09:41AM -0600, Eric W. Biederman wrote:
>> Ram Pai <linuxram@us.ibm.com> writes:
>>
>> > Currently the architecture specific code is expected to
>> > display the protection keys in smap for a given vma.
>> > This can lead to redundant code and possibly to divergent
>> > formats in which the key gets displayed.
>> >
>> > This patch changes the implementation. It displays the
>> > pkey only if the architecture support pkeys.
>> >
>> > x86 arch_show_smap() function is not needed anymore.
>> > Delete it.
>> >
>> > Signed-off-by: Ram Pai <linuxram@us.ibm.com>
>> > ---
>> > arch/x86/kernel/setup.c | 8 --------
>> > fs/proc/task_mmu.c | 11 ++++++-----
>> > 2 files changed, 6 insertions(+), 13 deletions(-)
>> >
>> > diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
>> > index 8af2e8d..ddf945a 100644
>> > --- a/arch/x86/kernel/setup.c
>> > +++ b/arch/x86/kernel/setup.c
>> > @@ -1326,11 +1326,3 @@ static int __init register_kernel_offset_dumper(void)
>> > return 0;
>> > }
>> > __initcall(register_kernel_offset_dumper);
>> > -
>> > -void arch_show_smap(struct seq_file *m, struct vm_area_struct *vma)
>> > -{
>> > - if (!boot_cpu_has(X86_FEATURE_OSPKE))
>> > - return;
>> > -
>> > - seq_printf(m, "ProtectionKey: %8u\n", vma_pkey(vma));
>> > -}
>> > diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
>> > index 0edd4da..4b39a94 100644
>> > --- a/fs/proc/task_mmu.c
>> > +++ b/fs/proc/task_mmu.c
>> > @@ -18,6 +18,7 @@
>> > #include <linux/page_idle.h>
>> > #include <linux/shmem_fs.h>
>> > #include <linux/uaccess.h>
>> > +#include <linux/pkeys.h>
>> >
>> > #include <asm/elf.h>
>> > #include <asm/tlb.h>
>> > @@ -728,10 +729,6 @@ static int smaps_hugetlb_range(pte_t *pte, unsigned long hmask,
>> > }
>> > #endif /* HUGETLB_PAGE */
>> >
>> > -void __weak arch_show_smap(struct seq_file *m, struct vm_area_struct *vma)
>> > -{
>> > -}
>> > -
>> > static int show_smap(struct seq_file *m, void *v, int is_pid)
>> > {
>> > struct proc_maps_private *priv = m->private;
>> > @@ -851,9 +848,13 @@ static int show_smap(struct seq_file *m, void *v, int is_pid)
>> > (unsigned long)(mss->pss >> (10 + PSS_SHIFT)));
>> >
>> > if (!rollup_mode) {
>> > - arch_show_smap(m, vma);
>> > +#ifdef CONFIG_ARCH_HAS_PKEYS
>> > + if (arch_pkeys_enabled())
>> > + seq_printf(m, "ProtectionKey: %8u\n", vma_pkey(vma));
>> > +#endif
>>
>> Would it be worth it making vma_pkey a noop on architectures that don't
>> support protection keys so that we don't need the #ifdef here?
>
> You mean something like this?
> #define vma_pkey(vma)
> It will lead to compilation error.
>
>
> I can make it
> #define vma_pkey(vma) 0
>
> and that will work and get rid of the #ifdef
Yes the second is what I was thinking.
I don't know if it is worth it but #ifdefs can be problematic as the
result in code not being compile tested.
Eric
^ permalink raw reply
* Re: [PATCH v10 27/27] mm: display pkey in smaps if arch_pkeys_enabled() is true
From: Ram Pai @ 2018-01-19 16:50 UTC (permalink / raw)
To: Eric W. Biederman
Cc: mpe, mingo, akpm, corbet, arnd, linuxppc-dev, linux-mm, x86,
linux-arch, linux-doc, linux-kselftest, linux-kernel, dave.hansen,
benh, paulus, khandual, aneesh.kumar, bsingharora, hbabu, mhocko,
bauerman
In-Reply-To: <87shb1de4a.fsf@xmission.com>
On Fri, Jan 19, 2018 at 10:09:41AM -0600, Eric W. Biederman wrote:
> Ram Pai <linuxram@us.ibm.com> writes:
>
> > Currently the architecture specific code is expected to
> > display the protection keys in smap for a given vma.
> > This can lead to redundant code and possibly to divergent
> > formats in which the key gets displayed.
> >
> > This patch changes the implementation. It displays the
> > pkey only if the architecture support pkeys.
> >
> > x86 arch_show_smap() function is not needed anymore.
> > Delete it.
> >
> > Signed-off-by: Ram Pai <linuxram@us.ibm.com>
> > ---
> > arch/x86/kernel/setup.c | 8 --------
> > fs/proc/task_mmu.c | 11 ++++++-----
> > 2 files changed, 6 insertions(+), 13 deletions(-)
> >
> > diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> > index 8af2e8d..ddf945a 100644
> > --- a/arch/x86/kernel/setup.c
> > +++ b/arch/x86/kernel/setup.c
> > @@ -1326,11 +1326,3 @@ static int __init register_kernel_offset_dumper(void)
> > return 0;
> > }
> > __initcall(register_kernel_offset_dumper);
> > -
> > -void arch_show_smap(struct seq_file *m, struct vm_area_struct *vma)
> > -{
> > - if (!boot_cpu_has(X86_FEATURE_OSPKE))
> > - return;
> > -
> > - seq_printf(m, "ProtectionKey: %8u\n", vma_pkey(vma));
> > -}
> > diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> > index 0edd4da..4b39a94 100644
> > --- a/fs/proc/task_mmu.c
> > +++ b/fs/proc/task_mmu.c
> > @@ -18,6 +18,7 @@
> > #include <linux/page_idle.h>
> > #include <linux/shmem_fs.h>
> > #include <linux/uaccess.h>
> > +#include <linux/pkeys.h>
> >
> > #include <asm/elf.h>
> > #include <asm/tlb.h>
> > @@ -728,10 +729,6 @@ static int smaps_hugetlb_range(pte_t *pte, unsigned long hmask,
> > }
> > #endif /* HUGETLB_PAGE */
> >
> > -void __weak arch_show_smap(struct seq_file *m, struct vm_area_struct *vma)
> > -{
> > -}
> > -
> > static int show_smap(struct seq_file *m, void *v, int is_pid)
> > {
> > struct proc_maps_private *priv = m->private;
> > @@ -851,9 +848,13 @@ static int show_smap(struct seq_file *m, void *v, int is_pid)
> > (unsigned long)(mss->pss >> (10 + PSS_SHIFT)));
> >
> > if (!rollup_mode) {
> > - arch_show_smap(m, vma);
> > +#ifdef CONFIG_ARCH_HAS_PKEYS
> > + if (arch_pkeys_enabled())
> > + seq_printf(m, "ProtectionKey: %8u\n", vma_pkey(vma));
> > +#endif
>
> Would it be worth it making vma_pkey a noop on architectures that don't
> support protection keys so that we don't need the #ifdef here?
You mean something like this?
#define vma_pkey(vma)
It will lead to compilation error.
I can make it
#define vma_pkey(vma) 0
and that will work and get rid of the #ifdef
RP
^ permalink raw reply
* Re: [PATCH v10 27/27] mm: display pkey in smaps if arch_pkeys_enabled() is true
From: Eric W. Biederman @ 2018-01-19 16:09 UTC (permalink / raw)
To: Ram Pai
Cc: mpe, mingo, akpm, corbet, arnd, linuxppc-dev, linux-mm, x86,
linux-arch, linux-doc, linux-kselftest, linux-kernel, dave.hansen,
benh, paulus, khandual, aneesh.kumar, bsingharora, hbabu, mhocko,
bauerman
In-Reply-To: <1516326648-22775-28-git-send-email-linuxram@us.ibm.com>
Ram Pai <linuxram@us.ibm.com> writes:
> Currently the architecture specific code is expected to
> display the protection keys in smap for a given vma.
> This can lead to redundant code and possibly to divergent
> formats in which the key gets displayed.
>
> This patch changes the implementation. It displays the
> pkey only if the architecture support pkeys.
>
> x86 arch_show_smap() function is not needed anymore.
> Delete it.
>
> Signed-off-by: Ram Pai <linuxram@us.ibm.com>
> ---
> arch/x86/kernel/setup.c | 8 --------
> fs/proc/task_mmu.c | 11 ++++++-----
> 2 files changed, 6 insertions(+), 13 deletions(-)
>
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index 8af2e8d..ddf945a 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -1326,11 +1326,3 @@ static int __init register_kernel_offset_dumper(void)
> return 0;
> }
> __initcall(register_kernel_offset_dumper);
> -
> -void arch_show_smap(struct seq_file *m, struct vm_area_struct *vma)
> -{
> - if (!boot_cpu_has(X86_FEATURE_OSPKE))
> - return;
> -
> - seq_printf(m, "ProtectionKey: %8u\n", vma_pkey(vma));
> -}
> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> index 0edd4da..4b39a94 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -18,6 +18,7 @@
> #include <linux/page_idle.h>
> #include <linux/shmem_fs.h>
> #include <linux/uaccess.h>
> +#include <linux/pkeys.h>
>
> #include <asm/elf.h>
> #include <asm/tlb.h>
> @@ -728,10 +729,6 @@ static int smaps_hugetlb_range(pte_t *pte, unsigned long hmask,
> }
> #endif /* HUGETLB_PAGE */
>
> -void __weak arch_show_smap(struct seq_file *m, struct vm_area_struct *vma)
> -{
> -}
> -
> static int show_smap(struct seq_file *m, void *v, int is_pid)
> {
> struct proc_maps_private *priv = m->private;
> @@ -851,9 +848,13 @@ static int show_smap(struct seq_file *m, void *v, int is_pid)
> (unsigned long)(mss->pss >> (10 + PSS_SHIFT)));
>
> if (!rollup_mode) {
> - arch_show_smap(m, vma);
> +#ifdef CONFIG_ARCH_HAS_PKEYS
> + if (arch_pkeys_enabled())
> + seq_printf(m, "ProtectionKey: %8u\n", vma_pkey(vma));
> +#endif
Would it be worth it making vma_pkey a noop on architectures that don't
support protection keys so that we don't need the #ifdef here?
Eric
> show_smap_vma_flags(m, vma);
> }
> +
> m_cache_vma(m, vma);
> return ret;
> }
^ permalink raw reply
* Re: DPAA Ethernet traffice troubles with Linux kernel
From: Joakim Tjernlund @ 2018-01-19 13:42 UTC (permalink / raw)
To: andrew@lunn.ch
Cc: linuxppc-dev@lists.ozlabs.org, netdev@vger.kernel.org,
madalin.bucur@nxp.com, madskateman@gmail.com
In-Reply-To: <20180119132251.GJ32299@lunn.ch>
T24gVGh1LCAxOTcwLTAxLTAxIGF0IDAwOjAwICswMDAwLCBBbmRyZXcgTHVubiB3cm90ZToNCj4g
Q0FVVElPTjogVGhpcyBlbWFpbCBvcmlnaW5hdGVkIGZyb20gb3V0c2lkZSBvZiB0aGUgb3JnYW5p
emF0aW9uLiBEbyBub3QgY2xpY2sgbGlua3Mgb3Igb3BlbiBhdHRhY2htZW50cyB1bmxlc3MgeW91
IHJlY29nbml6ZSB0aGUgc2VuZGVyIGFuZCBrbm93IHRoZSBjb250ZW50IGlzIHNhZmUuDQo+IA0K
PiANCj4gPiA+IGNvbW1pdCA0ZDhlZTE5MzViY2Q2NjYzNjAzMTFkZmRhZGVlZTIzNWQ2ODJkNjlh
DQo+ID4gPiBBdXRob3I6IEZsb3JpYW4gRmFpbmVsbGkgPGYuZmFpbmVsbGlAZ21haWwuY29tPg0K
PiA+ID4gRGF0ZTogVHVlIEF1ZyAyMiAxNToyNDo0NyAyMDE3IC0wNzAwDQo+ID4gPiBmc2wvbWFu
OiBJbmhlcml0IHBhcmVudCBkZXZpY2UgYW5kIG9mX25vZGUNCj4gPiA+IA0KPiA+ID4gYW5kIHdh
cyBsYXRlciBhZGRyZXNzZWQgYnkgdGhpcyBwYXRjaCBzZXQ6DQo+ID4gPiANCj4gPiA+IGh0dHA6
Ly9wYXRjaHdvcmsub3psYWJzLm9yZy9wcm9qZWN0L25ldGRldi9saXN0Lz9zZXJpZXM9ODQ2MiZz
dGF0ZT0qDQo+ID4gPiANCj4gPiA+IEV2ZW4gd2l0aCB0aGVzZSBlcnJvcnMgcHJpbnRlZCwgYWxs
IGlzIHdvcmtpbmcgZmluZSwgaXQncyBqdXN0IHRoZQ0KPiA+ID4gc2Vjb25kIHByb2JpbmcgdGhh
dCBmYWlscy4gQWRkaW5nIHRoZSBsYXR0ZXIgcGF0Y2hlcyBvciByZXZlcnRpbmcNCj4gPiA+IHRo
ZSBvbmUgYWJvdmUgbWFrZXMgdGhlIGVycm9ycyBwcmludHMgZGlzc2FwZWFyLg0KPiA+IA0KPiA+
IExvb2tpbmcgYXQgdGhlIGFib3ZlIHBhdGNoIHNlcmllcnMgSSBzZWUgaXQgaXMgaW4gc3RhdGUg
QWNjZXB0ZWQgYW5kIGhhcyBiZWVuIHRoZXJlDQo+ID4gc2luY2UgMjAxNy0xMC0xNg0KPiA+IFRo
YXQgc2VlbXMgbGlrZSBhIGF3ZnVsIGxvbmcgdG8gd2FpdCBpbiBiZWZvcmUgZ2V0dGluZyBpbnRv
IExpbnV4LCBpcyB0aGVyZSBzb21ldGhpbmcNCj4gPiBob2xkaW5nIHRoZXNlIHBhdGNoZXMgYmFj
ayA/DQo+IA0KPiBUaGV5IGFyZSBpbiBMaW51eCwgaGF2ZSBiZWVuIHNpbmNlIE9jdG9iZXIgMTZ0
aC4gQnV0IGF0IHRoZSBtb21lbnQsDQo+IHRoZXkgYXJlIG9ubHkgaW4gdjQuMTUsIG5vdCB2NC4x
NC4NCg0KTm93IEkgc2VlIHRoZW0gaW4gNC4xNSwgbXVzdCBoYXZlIGxvb2tlZCBpbiB0aGUgd3Jv
bmcgYnJhbmNoLg0KDQo+IA0KPiBUaGVzZSBwYXRjaGVzIHByb2JhYmx5IGRvbid0IGZpdCB0aGUg
c3RhYmxlIHJ1bGVzLCBmb3IgZ2V0dGluZyB0aGVtDQo+IGFkZGVkIHRvIHY0LjE0Lg0KPiANCj4g
aHR0cHM6Ly9naXRodWIuY29tL3RvcnZhbGRzL2xpbnV4L2Jsb2IvbWFzdGVyL0RvY3VtZW50YXRp
b24vcHJvY2Vzcy9zdGFibGUta2VybmVsLXJ1bGVzLnJzdA0KDQpTdHVmZiBuZWVkcyB0byB3b3Jr
LCB3aGF0ZXZlciBuZWVkZWQgdG8gbWFrZSB0aGF0IGhhcHBlbiBpcyBhbGxvd2VkLiBFdmVuIGJh
Y2twb3J0aW5nDQpzb21lIG5ldyBpbmZyYSBzdHJ1Y3R1cmUgaWYgbmVlZCBiZSB0byBzaW1wbGlm
eSBmaXhpbmcgYnVncy4NCg0KPiANCj4gV2hhdCBpcyBuZWVkZWQgaXMgYSBtaW5pbWFsIGZpeC4g
T3IganVzdCB3YWl0IHVudGlsIFN1bmRheSwgd2hlbiB0aGVyZQ0KPiBpcyBhIGdvb2QgY2hhbmNl
IHY0LjE1IHdpbGwgYmUgcmVsZWFzZWQuDQoNCllvdSBzZWVtIHRvIHRoaW5rIGV2ZXJ5b25lIGFs
d2F5cyB1cGdyYWRlIHRvIGxpbnV4IGxhdGVzdCBidXQgdGhpcyBpcyBub3Qgc28uDQpXZSBkbyBw
cm9kdWN0IGRldmVsb3BtZW50IGhlcmUgYW5kIGFwcHJlY2lhdGUgdGhlIHN0YWJsZSBrZXJuZWxz
IHNvIHdlIGNhbiB3b3JrIGluDQpwZWFjZSBhbmQgbm90IGNoYXNpbmcgdGhlIGxhdGVzdCBrZXJu
ZWwuDQoNCiBKb2NrZQ==
^ permalink raw reply
* Re: DPAA Ethernet traffice troubles with Linux kernel
From: Andrew Lunn @ 2018-01-19 13:22 UTC (permalink / raw)
To: Joakim Tjernlund
Cc: madalin.bucur@nxp.com, linuxppc-dev@lists.ozlabs.org,
netdev@vger.kernel.org, madskateman@gmail.com
In-Reply-To: <1516348851.4730.15.camel@infinera.com>
> > commit 4d8ee1935bcd666360311dfdadeee235d682d69a
> > Author: Florian Fainelli <f.fainelli@gmail.com>
> > Date: Tue Aug 22 15:24:47 2017 -0700
> > fsl/man: Inherit parent device and of_node
> >
> > and was later addressed by this patch set:
> >
> > http://patchwork.ozlabs.org/project/netdev/list/?series=8462&state=*
> >
> > Even with these errors printed, all is working fine, it's just the
> > second probing that fails. Adding the latter patches or reverting
> > the one above makes the errors prints dissapear.
>
> Looking at the above patch seriers I see it is in state Accepted and has been there
> since 2017-10-16
> That seems like a awful long to wait in before getting into Linux, is there something
> holding these patches back ?
They are in Linux, have been since October 16th. But at the moment,
they are only in v4.15, not v4.14.
These patches probably don't fit the stable rules, for getting them
added to v4.14.
https://github.com/torvalds/linux/blob/master/Documentation/process/stable-kernel-rules.rst
What is needed is a minimal fix. Or just wait until Sunday, when there
is a good chance v4.15 will be released.
Andrew
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox