From: Frank Rowand
Callers of of_irq_parse_one() blindly use the pointer args.np
without checking whether of_irq_parse_one() had an error and
thus did not set the value of args.np. Initialize args to
zero so that using the format "%pOF" to show the value of
args.np will show "(null)" when
From: Frank Rowand
One accessor of overlays[] was using a hard coded index value to
find the correct array entry instead of searching for the entry
containing the correct name.
Signed-off-by: Frank Rowand
---
drivers/of/unittest.c | 21 +
1 file changed, 17 insertions(+),
From: Frank Rowand
The overlay metadata nodes in the FDT created from testcases.dts
are not handled properly.
The __fixups__ and __local_fixups__ node were added to the live
devicetree, but should not be.
Only the first property in the /__symbols__ node was added to the
live devicetree if the
From: Frank Rowand
Overlay nodes added by add_changeset_node() do not have the node
fields name, phandle, and type set.
The node passed to __of_attach_node() when the add node changeset
entry is processed does not contain any properties. The node's
properties are located in add property
From: Frank Rowand
Argument unittest_nr is not used in of_unittest_apply_overlay(),
remove it.
Signed-off-by: Frank Rowand
---
drivers/of/unittest.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
index
From: Frank Rowand
Add test case of two fragments updating the same property. After
adding the test case, the system hangs at end of boot, after
after slub stack dumps from kfree() in crypto modprobe code.
Multiple overlay fragments adding, modifying, or deleting the same
property is not
From: Frank Rowand
Multiple overlay fragments adding or deleting the same node is not
supported. Replace code comment of such, with check to detect the
attempt and fail the overlay apply.
Devicetree unittest where multiple fragments added the same node was
added in the previous patch in the
From: Frank Rowand
Multiple overlay fragments adding or deleting the same node is not
supported. An attempt to do so results in an incorrect devicetree.
The node name will be munged for the second add.
After adding this patch, the unittest messages will show:
Duplicate name in motor-1,
From: Frank Rowand
Make overlay.c debug and error messages unique so that they can be
unambiguously found by grep.
Signed-off-by: Frank Rowand
---
drivers/of/overlay.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
From: Frank Rowand
If overlay properties #address-cells or #size-cells are already in
the live devicetree for any given node, then the values in the
overlay must match the values in the live tree.
If the properties are already in the live tree then there is no
need to create a changeset entry
From: Frank Rowand
Order the fields of struct fragment in the same order as
struct of_overlay_notify_data. The order in struct fragment is
not significant. If both structs are ordered the same then when
examining the data in a debugger or dump the human involved does
not have to remember which
From: Frank Rowand
of_attach_node() and of_detach_node() always return zero, so
their return value is meaningless. Change their type to void
and fix all callers to ignore return value.
Signed-off-by: Frank Rowand
---
arch/powerpc/platforms/pseries/dlpar.c| 13 ++---
From: Frank Rowand
When allocating a new node, add_changeset_node() was duplicating the
properties from the respective node in the overlay instead of
allocating a node with no properties.
When this patch is applied the errors reported by the devictree
unittest from patch "of: overlay: add tests
From: Frank Rowand
The changeset entry 'update property' was used for new properties in
an overlay instead of 'add property'.
The decision of whether to use 'update property' was based on whether
the property already exists in the subtree where the node is being
spliced into. At the top level
From: Frank Rowand
"of: overlay: add missing of_node_get() in __of_attach_node_sysfs"
added a missing of_node_get() to __of_attach_node_sysfs(). This
results in a refcount imbalance for nodes attached with
dlpar_attach_node(). The calling sequence from dlpar_attach_node()
to
From: Frank Rowand
There is a matching of_node_put() in __of_detach_node_sysfs()
Remove misleading comment from function header comment for
of_detach_node().
This patch may result in memory leaks from code that directly calls
the dynamic node add and delete functions directly instead of
using
From: Frank Rowand
The refcount of a newly added overlay node decrements to one
(instead of zero) when the overlay changeset is destroyed. This
change will cause the final decrement be to zero.
After applying this patch, new validation warnings will be
reported from the devicetree unittest
From: Frank Rowand
Add checks:
- attempted kfree due to refcount reaching zero before overlay
is removed
- properties linked to an overlay node when the node is removed
- node refcount > one during node removal in a changeset destroy,
if the node was created by the changeset
After
From: Frank Rowand
Add checks to (1) overlay apply process and (2) memory freeing
triggered by overlay release. The checks are intended to detect
possible memory leaks and invalid overlays.
The checks revealed bugs in existing code. Fixed the bugs.
While fixing bugs, noted other issues,
On Fri, Oct 12, 2018 at 7:10 PM, Joel Fernandes wrote:
> On Fri, Oct 12, 2018 at 06:54:33PM -0700, Daniel Colascione wrote:
>> I wonder whether it makes sense to expose to userspace somehow whether
>> mremap is "fast" for a particular architecture. If a feature relies on
>> fast mremap, it might
I wonder whether it makes sense to expose to userspace somehow whether
mremap is "fast" for a particular architecture. If a feature relies on
fast mremap, it might be better for some userland component to disable
that feature entirely rather than blindly use mremap and end up
performing very
Not 32-bit ARM?
On Fri, Oct 12, 2018 at 6:35 PM, Joel Fernandes wrote:
> On Fri, Oct 12, 2018 at 11:18:36AM -0700, David Miller wrote:
>> From: Joel Fernandes
> [...]
>> > Also, do we not flush the caches from any path when we munmap
>> > address space? We do call do_munmap on the old mapping
Moving page-tables at the PMD-level on x86 is known to be safe. Enable
this option so that we can do fast mremap when possible.
Signed-off-by: Joel Fernandes (Google)
---
arch/x86/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index
Moving page-tables at the PMD-level on arm64 is known to be safe. Enable
this option so that we can do fast mremap when possible.
Signed-off-by: Joel Fernandes (Google)
---
arch/arm64/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index
Android needs to mremap large regions of memory during memory management
related operations. The mremap system call can be really slow if THP is
not enabled. The bottleneck is move_page_tables, which is copying each
pte at a time, and can be really slow across a large map. Turning on THP
may not
This series speeds up mremap(2) syscall by copying page tables at the
PMD level even for non-THP systems. There is concern that the extra
'address' argument that mremap passes to pte_alloc may do something
subtle architecture related in the future that may make the scheme not
work. Also we find
Hi,
Here is the latest "fast mremap" series. The main change in this submission is
to enable the fast mremap optimization on a per-architecture basis to prevent
possible issues with architectures that may not behave well with such change.
x86: select HAVE_MOVE_PMD for faster mremap (v1)
arm64:
On Fri, Oct 12, 2018 at 06:54:33PM -0700, Daniel Colascione wrote:
> I wonder whether it makes sense to expose to userspace somehow whether
> mremap is "fast" for a particular architecture. If a feature relies on
> fast mremap, it might be better for some userland component to disable
> that
On Fri, Oct 12, 2018 at 06:39:45PM -0700, Daniel Colascione wrote:
> Not 32-bit ARM?
Well, I didn't want to enable every possible architecture we could in a
single go. Certainly arm32 can be a follow on enablement as can be other
architectures. The point of this series is to upstream this feature
On Fri, Oct 12, 2018 at 11:18:36AM -0700, David Miller wrote:
> From: Joel Fernandes
[...]
> > Also, do we not flush the caches from any path when we munmap
> > address space? We do call do_munmap on the old mapping from mremap
> > after moving to the new one.
>
> Sparc makes sure that shared
On Fri, Oct 12, 2018 at 2:59 AM, Gustavo A. R. Silva
wrote:
>
>
> On 10/12/18 11:32 AM, Michael Ellerman wrote:
>>
>> Sure. The kbuild report up thread has some or most of them.
>>
>> But here's a full list:
>>
>> Failed 279/290
>>
So,if we're talk about address...
EA0 is actually bit 63 for any kernel address. This means[1] the
effective address is
the real address ( the physical address), because MSR_HV=1.
1. What does it mean PA=EA ? How does the translation work now ?
2. in interrupts, the program counter is set to EA
If GCC is not built with glibc support then we must explicitly tell it
which register to use for TLS mode stack protector, otherwise it will
error out and the cc-option check will fail.
Signed-off-by: Michael Ellerman
---
arch/powerpc/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1
On Tue, Oct 9, 2018 at 11:21 PM Oliver O'Halloran wrote:
>
> Adds a driver that implements support for enabling and accessing PAPR
> SCM regions. Unfortunately due to how the PAPR interface works we can't
> use the existing of_pmem driver (yet) because:
>
> a) The guest is required to use the
On Fri, Oct 12, 2018 at 05:42:24PM +0100, Anton Ivanov wrote:
>
> On 10/12/18 3:48 PM, Anton Ivanov wrote:
> > On 12/10/2018 15:37, Kirill A. Shutemov wrote:
> > > On Fri, Oct 12, 2018 at 03:09:49PM +0100, Anton Ivanov wrote:
> > > > On 10/12/18 2:37 AM, Joel Fernandes (Google) wrote:
> > > > >
On Fri, Oct 12, 2018 at 09:57:19AM -0700, Joel Fernandes wrote:
> On Fri, Oct 12, 2018 at 04:19:46PM +0300, Kirill A. Shutemov wrote:
> > On Fri, Oct 12, 2018 at 05:50:46AM -0700, Joel Fernandes wrote:
> > > On Fri, Oct 12, 2018 at 02:30:56PM +0300, Kirill A. Shutemov wrote:
> > > > On Thu, Oct
On Fri, Oct 12, 2018 at 08:51:45PM +0200, SF Markus Elfring wrote:
> > The changes were obtained by applying the following Coccinelle script.
>
> A bit of clarification happened for its implementation details.
> https://systeme.lip6.fr/pipermail/cocci/2018-October/005374.html
>
> I have taken
> The changes were obtained by applying the following Coccinelle script.
A bit of clarification happened for its implementation details.
https://systeme.lip6.fr/pipermail/cocci/2018-October/005374.html
I have taken also another look at the following SmPL code.
> identifier fn =~
>
On 10/12/18 2:37 AM, Joel Fernandes (Google) wrote:
This series speeds up mremap(2) syscall by copying page tables at the
PMD level even for non-THP systems. There is concern that the extra
'address' argument that mremap passes to pte_alloc may do something
subtle architecture related in the
On 12/10/2018 15:37, Kirill A. Shutemov wrote:
On Fri, Oct 12, 2018 at 03:09:49PM +0100, Anton Ivanov wrote:
On 10/12/18 2:37 AM, Joel Fernandes (Google) wrote:
Android needs to mremap large regions of memory during memory management
related operations. The mremap system call can be really
On 10/12/18 2:37 AM, Joel Fernandes (Google) wrote:
Android needs to mremap large regions of memory during memory management
related operations. The mremap system call can be really slow if THP is
not enabled. The bottleneck is move_page_tables, which is copying each
pte at a time, and can be
On 10/12/18 3:48 PM, Anton Ivanov wrote:
On 12/10/2018 15:37, Kirill A. Shutemov wrote:
On Fri, Oct 12, 2018 at 03:09:49PM +0100, Anton Ivanov wrote:
On 10/12/18 2:37 AM, Joel Fernandes (Google) wrote:
Android needs to mremap large regions of memory during memory
management
related
On 10/12/18 5:50 PM, Joel Fernandes wrote:
On Fri, Oct 12, 2018 at 05:42:24PM +0100, Anton Ivanov wrote:
On 10/12/18 3:48 PM, Anton Ivanov wrote:
On 12/10/2018 15:37, Kirill A. Shutemov wrote:
On Fri, Oct 12, 2018 at 03:09:49PM +0100, Anton Ivanov wrote:
On 10/12/18 2:37 AM, Joel Fernandes
On Fri, Oct 12, 2018 at 05:58:40PM +0100, Anton Ivanov wrote:
[...]
> > > > > > If I read the code right, MIPS completely ignores the address
> > > > > > argument so
> > > > > > set_pmd_at there may not have the effect which this patch is trying
> > > > > > to
> > > > > > achieve.
> > > > >
On Fri, Oct 12, 2018 at 04:19:46PM +0300, Kirill A. Shutemov wrote:
> On Fri, Oct 12, 2018 at 05:50:46AM -0700, Joel Fernandes wrote:
> > On Fri, Oct 12, 2018 at 02:30:56PM +0300, Kirill A. Shutemov wrote:
> > > On Thu, Oct 11, 2018 at 06:37:56PM -0700, Joel Fernandes (Google) wrote:
> > > >
On Fri, Oct 12, 2018 at 05:42:24PM +0100, Anton Ivanov wrote:
>
> On 10/12/18 3:48 PM, Anton Ivanov wrote:
> > On 12/10/2018 15:37, Kirill A. Shutemov wrote:
> > > On Fri, Oct 12, 2018 at 03:09:49PM +0100, Anton Ivanov wrote:
> > > > On 10/12/18 2:37 AM, Joel Fernandes (Google) wrote:
> > > > >
On Fri, Oct 12, 2018 at 03:09:49PM +0100, Anton Ivanov wrote:
> On 10/12/18 2:37 AM, Joel Fernandes (Google) wrote:
> > Android needs to mremap large regions of memory during memory management
> > related operations. The mremap system call can be really slow if THP is
> > not enabled. The
On Fri, Oct 12, 2018 at 05:50:46AM -0700, Joel Fernandes wrote:
> On Fri, Oct 12, 2018 at 02:30:56PM +0300, Kirill A. Shutemov wrote:
> > On Thu, Oct 11, 2018 at 06:37:56PM -0700, Joel Fernandes (Google) wrote:
> > > Android needs to mremap large regions of memory during memory management
> > >
> I wrote something like this as below but it failed to compile, Julia any
> suggestions on how to express this?
>
> @pte_alloc_func_proto depends on patch exists@
> type T1, T2, T3, T4;
> identifier fn =~
> "^(__pte_alloc|pte_alloc_one|pte_alloc|__pte_alloc_kernel|pte_alloc_one_kernel)$";
> @@
>
On Fri, Oct 12, 2018 at 06:38:57PM +0200, Julia Lawall wrote:
> > I wrote something like this as below but it failed to compile, Julia any
> > suggestions on how to express this?
> >
> > @pte_alloc_func_proto depends on patch exists@
> > type T1, T2, T3, T4;
> > identifier fn =~
> >
On Fri, Oct 12, 2018 at 02:09:06PM +0300, Kirill A. Shutemov wrote:
> On Thu, Oct 11, 2018 at 06:37:55PM -0700, Joel Fernandes (Google) wrote:
> > diff --git a/arch/m68k/include/asm/mcf_pgalloc.h
> > b/arch/m68k/include/asm/mcf_pgalloc.h
> > index 12fe700632f4..4399d712f6db 100644
> > ---
On Fri, Oct 12, 2018 at 02:56:19PM +0100, Anton Ivanov wrote:
>
> On 10/12/18 2:37 AM, Joel Fernandes (Google) wrote:
> > This series speeds up mremap(2) syscall by copying page tables at the
> > PMD level even for non-THP systems. There is concern that the extra
> > 'address' argument that
On Fri, Oct 12, 2018 at 02:30:56PM +0300, Kirill A. Shutemov wrote:
> On Thu, Oct 11, 2018 at 06:37:56PM -0700, Joel Fernandes (Google) wrote:
> > Android needs to mremap large regions of memory during memory management
> > related operations. The mremap system call can be really slow if THP is
>
From: Joel Fernandes
Date: Fri, 12 Oct 2018 05:50:46 -0700
> If its an issue, then how do transparent huge pages work on Sparc? I don't
> see the huge page code (move_huge_pages) during mremap doing anything special
> for Sparc architecture when moving PMDs..
This is because all huge pages are
From: "Kirill A. Shutemov"
Date: Fri, 12 Oct 2018 14:30:56 +0300
> I looked into the code more and noticed move_pte() helper called from
> move_ptes(). It changes PTE entry to suite new address.
>
> It is only defined in non-trivial way on Sparc. I don't know much about
> Sparc and it's hard
Benjamin Herrenschmidt writes:
> It's not used anywhere else
>
> Signed-off-by: Benjamin Herrenschmidt
> ---
> arch/powerpc/kernel/prom_init.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
> index
On Fri, 2018-10-12 at 12:36 +0200, Christophe LEROY wrote:
>
> Le 12/10/2018 à 12:31, Abdul Haleem a écrit :
> > On Fri, 2018-10-12 at 10:08 +0200, Christophe LEROY wrote:
> >>
> >> Le 12/10/2018 à 09:48, Abdul Haleem a écrit :
> >>> On Fri, 2018-10-12 at 13:15 +0530, Abdul Haleem wrote:
>
Le 12/10/2018 à 11:02, Aneesh Kumar K.V a écrit :
On 10/12/18 1:38 PM, Christophe LEROY wrote:
Le 12/10/2018 à 09:48, Abdul Haleem a écrit :
On Fri, 2018-10-12 at 13:15 +0530, Abdul Haleem wrote:
Greeting's
Today's linux-next fails to boot on powerpc bare-metal with this error
POWER8
On Fri, Oct 12, 2018 at 02:30:56PM +0300, Kirill A. Shutemov wrote:
> On Thu, Oct 11, 2018 at 06:37:56PM -0700, Joel Fernandes (Google) wrote:
> > @@ -239,7 +287,21 @@ unsigned long move_page_tables(struct vm_area_struct
> > *vma,
> > split_huge_pmd(vma, old_pmd, old_addr);
>
On Thu, Oct 11, 2018 at 06:37:56PM -0700, Joel Fernandes (Google) wrote:
> Android needs to mremap large regions of memory during memory management
> related operations. The mremap system call can be really slow if THP is
> not enabled. The bottleneck is move_page_tables, which is copying each
>
On Fri, Oct 12, 2018 at 02:25:25AM +, Peng Ma wrote:
> Hi Rob,
>
> > -Original Message-
> > From: Rob Herring [mailto:r...@kernel.org]
> > Sent: 2018年10月12日 6:09
> > To: Peng Ma
> > Cc: vk...@kernel.org; Leo Li ; mark.rutl...@arm.com;
> > shawn...@kernel.org;
Reimplement Book3S idle code in C, moving POWER7/8/9 implementation
speific HV idle code to the powernv platform code.
Book3S assembly stubs are kept in common code and used only to save
the stack frame and non-volatile GPRs before executing architected
idle instructions, and restoring the stack
On Thu, Oct 11, 2018 at 06:37:55PM -0700, Joel Fernandes (Google) wrote:
> diff --git a/arch/m68k/include/asm/mcf_pgalloc.h
> b/arch/m68k/include/asm/mcf_pgalloc.h
> index 12fe700632f4..4399d712f6db 100644
> --- a/arch/m68k/include/asm/mcf_pgalloc.h
> +++ b/arch/m68k/include/asm/mcf_pgalloc.h
>
Le 12/10/2018 à 12:31, Abdul Haleem a écrit :
On Fri, 2018-10-12 at 10:08 +0200, Christophe LEROY wrote:
Le 12/10/2018 à 09:48, Abdul Haleem a écrit :
On Fri, 2018-10-12 at 13:15 +0530, Abdul Haleem wrote:
Greeting's
Today's linux-next fails to boot on powerpc bare-metal with this error
On Fri, 2018-10-12 at 10:08 +0200, Christophe LEROY wrote:
>
> Le 12/10/2018 à 09:48, Abdul Haleem a écrit :
> > On Fri, 2018-10-12 at 13:15 +0530, Abdul Haleem wrote:
> >> Greeting's
> >>
> >> Today's linux-next fails to boot on powerpc bare-metal with this error
> >>
> >> POWER8 performance
On 10/12/18 11:32 AM, Michael Ellerman wrote:
>
> Sure. The kbuild report up thread has some or most of them.
>
> But here's a full list:
>
> Failed 279/290
> http://kisskb.ellerman.id.au/kisskb/head/1d59e2c78793d8aea9949ca71323c4583c78f488/
> Failed:
"Gustavo A. R. Silva" writes:
> Hi Michael,
>
> On 10/11/18 2:32 AM, Michael Ellerman wrote:
>
>> It still pops a few errors, including in linux/signal.h & compat.h, so
>> it's somewhat aspirational until we can get those fixed up :)
>>
>
> I wonder if you have a log containing those warnings
Le 12/10/2018 à 11:02, Aneesh Kumar K.V a écrit :
On 10/12/18 1:38 PM, Christophe LEROY wrote:
Le 12/10/2018 à 09:48, Abdul Haleem a écrit :
On Fri, 2018-10-12 at 13:15 +0530, Abdul Haleem wrote:
Greeting's
Today's linux-next fails to boot on powerpc bare-metal with this error
POWER8
On 10/12/18 1:38 PM, Christophe LEROY wrote:
Le 12/10/2018 à 09:48, Abdul Haleem a écrit :
On Fri, 2018-10-12 at 13:15 +0530, Abdul Haleem wrote:
Greeting's
Today's linux-next fails to boot on powerpc bare-metal with this error
POWER8 performance monitor hardware support registered
rcu:
Le 12/10/2018 à 09:48, Abdul Haleem a écrit :
On Fri, 2018-10-12 at 13:15 +0530, Abdul Haleem wrote:
Greeting's
Today's linux-next fails to boot on powerpc bare-metal with this error
POWER8 performance monitor hardware support registered
rcu: Hierarchical SRCU implementation.
smp: Bringing
On Fri, 2018-10-12 at 13:15 +0530, Abdul Haleem wrote:
> Greeting's
>
> Today's linux-next fails to boot on powerpc bare-metal with this error
>
> POWER8 performance monitor hardware support registered
> rcu: Hierarchical SRCU implementation.
> smp: Bringing up secondary CPUs ...
> Kernel panic
Greeting's
Today's linux-next fails to boot on powerpc bare-metal with this error
POWER8 performance monitor hardware support registered
rcu: Hierarchical SRCU implementation.
smp: Bringing up secondary CPUs ...
Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in:
* Gautham R. Shenoy [2018-10-11 11:03:02]:
> From: "Gautham R. Shenoy"
>
>
> +#ifdef CONFIG_SCHED_SMT
> + if (has_big_cores) {
> + pr_info("Using small cores at SMT level\n");
> + power9_topology[0].mask = smallcore_smt_mask;
> +
> +DECLARE_PER_CPU(cpumask_var_t, cpu_smallcore_map);
>
> +/*
> + * On big-cores system, cpu_l1_cache_map for each CPU corresponds to
> + * the set its siblings that share the L1-cache.
> + */
> +DEFINE_PER_CPU(cpumask_var_t, cpu_l1_cache_map);
>
Nit:
Can you add a comment on how
74 matches
Mail list logo
