On 12/02/2020 15.24, Christophe Leroy wrote:
> Hi Rasmus,
>
> Kernel 5.6-rc1 silently fails on boot.
>
> I bisected the problem to commit b6231ea2b3c6 ("soc: fsl: qe: drop
> broken lazy call of cpm_muram_init()")
>
> I get a bad_page_fault() for an access at address 8 in
> cpm_muram_alloc_common
On 02/13/2020 14:17 PM, Christophe Leroy wrote:
> -Original Message-
> From: Christophe Leroy
> Sent: 2020年2月13日 14:17
> To: Qiang Zhao ; Rasmus Villemoes
> ; Leo Li ; Greg
> Kroah-Hartman
> Cc: Scott Wood ; linuxppc-dev@lists.ozlabs.org; LKML
> ; linux-arm-ker...@lists.infradead.org
> Su
Le 13/02/2020 à 06:23, Daniel Axtens a écrit :
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index e05e6dd67ae6..ef455da7efa3 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -285,18 +285,25 @@ void __init early_setup(unsigned l
Le 13/02/2020 à 04:35, Qiang Zhao a écrit :
On 02/12/2020 22:50 PM, Christophe Leroy wrote:
-Original Message-
From: Christophe Leroy
Sent: 2020年2月12日 22:50
To: Rasmus Villemoes ; Leo Li
; Qiang Zhao ; Greg
Kroah-Hartman
Cc: Scott Wood ; linuxppc-dev@lists.ozlabs.org; LKML
; linux-a
Le 13/02/2020 à 01:47, Daniel Axtens a écrit :
KASAN support on Book3S is a bit tricky to get right:
- It would be good to support inline instrumentation so as to be able to
catch stack issues that cannot be caught with outline mode.
- Inline instrumentation requires a fixed offset.
kcov instrumentation is collected the __sanitizer_cov_trace_pc hook in
kernel/kcov.c. The compiler inserts these hooks into every basic block
unless kcov is disabled for that file.
We then have a deep call-chain:
- __sanitizer_cov_trace_pc calls to check_kcov_mode()
- check_kcov_mode() (kernel/k
On 02/12/2020 22:50 PM, Christophe Leroy wrote:
> -Original Message-
> From: Christophe Leroy
> Sent: 2020年2月12日 22:50
> To: Rasmus Villemoes ; Leo Li
> ; Qiang Zhao ; Greg
> Kroah-Hartman
> Cc: Scott Wood ; linuxppc-dev@lists.ozlabs.org; LKML
> ; linux-arm-ker...@lists.infradead.org
> Su
Hi everyone, any comments or suggestions?
Thanks,
Jason
on 2020/2/6 10:58, Jason Yan wrote:
This is a try to implement KASLR for Freescale BookE64 which is based on
my earlier implementation for Freescale BookE32:
https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=131718
The implem
On 02/12/2020 11:25 PM, Gerald Schaefer wrote:
> On Wed, 12 Feb 2020 15:12:54 +0530
> Anshuman Khandual wrote:
>
+/*
+ * On s390 platform, the lower 12 bits are used to identify given page
table
+ * entry type and for other arch specific requirements. But these bits
Hi
On Thu, Feb 13, 2020 at 1:26 AM Fabio Estevam wrote:
>
> On Wed, Feb 12, 2020 at 1:35 AM Shengjiu Wang wrote:
> >
> > EASRC (Enhanced Asynchronous Sample Rate Converter) is a new
> > IP module found on i.MX815.
>
> i.MX815 in an internal terminology. Please avoid it on the commit log.
>
Ok, w
The align attribute applies an alignment constraint for namespace
creation in a region. Whereas the 'align' attribute of a namespace
applied alignment padding via an info block, the 'align' attribute
applies alignment constraints to the free space allocation.
The default for 'align' is the maximum
The NDD_ALIASING flag is used to indicate where pmem capacity might
alias with blk capacity and require labeling. It is also used to
indicate whether the DIMM supports labeling. Separate this latter
capability into its own flag so that the NDD_ALIASING flag is scoped to
true aliased configurations.
The pmem driver on PowerPC crashes with the following signature when
instantiating misaligned namespaces that map their capacity via
memremap_pages().
BUG: Unable to handle kernel data access at 0xc00100040600
Faulting instruction address: 0xc0090790
NIP [c0090790]
The "sub-section memory hotplug" facility allows memremap_pages() users
like libnvdimm to compensate for hardware platforms like x86 that have a
section size larger than their hardware memory mapping granularity. The
compensation that sub-section support affords is being tolerant of
physical memor
Changes since v1 [1]:
- Fix build errors with the PowerPC override for memremap_compat_align()
- Move the memremap_compat_align() override definition to
arch/powerpc/mm/ioremap.c (Aneesh)
[1]:
http://lore.kernel.org/r/158041475480.3889308.655103391935006598.st...@dwillia2-desk3.amr.corp.intel
KASAN support on Book3S is a bit tricky to get right:
- It would be good to support inline instrumentation so as to be able to
catch stack issues that cannot be caught with outline mode.
- Inline instrumentation requires a fixed offset.
- Book3S runs code in real mode after booting. Most n
kasan is already implied by the directory name, we don't need to
repeat it.
Suggested-by: Christophe Leroy
Signed-off-by: Daniel Axtens
---
arch/powerpc/mm/kasan/Makefile | 2 +-
arch/powerpc/mm/kasan/{kasan_init_32.c => init_32.c} | 0
2 files changed, 1 insertion(+), 1 d
KASAN is supported on 32-bit powerpc and the docs should reflect this.
Document s390 support while we're at it.
Suggested-by: Christophe Leroy
Reviewed-by: Christophe Leroy
Signed-off-by: Daniel Axtens
---
Changes since v5:
- rebase - riscv has now got support.
- document s390 support whil
powerpc has a variable number of PTRS_PER_*, set at runtime based
on the MMU that the kernel is booted under.
This means the PTRS_PER_* are no longer constants, and therefore
breaks the build.
Define default MAX_PTRS_PER_*s in the same style as MAX_PTRS_PER_P4D.
As KASAN is the only user at the m
Building on the work of Christophe, Aneesh and Balbir, I've ported
KASAN to 64-bit Book3S kernels running on the Radix MMU.
This provides full inline instrumentation on radix, but does require
that you be able to specify the amount of physically contiguous memory
on the system at compile time. Mor
https://bugzilla.kernel.org/show_bug.cgi?id=206501
--- Comment #6 from Christophe Leroy (christophe.le...@c-s.fr) ---
I found the reason I think. I just realised that the things saved to SPRN_SPRG
and in thread struct get overwriten by the DSI taken at stack write.
I'll prepare something to fix t
Hello,
> A big endian guest doing XIVE ?!? I'm pretty sure we didn't do much testing,
> if
> any, on such a setup... What distro is used in the VM ?
A live Void Linux ISO ;
https://repo.voidlinux-ppc.org/live/current/void-live-ppc64-20190901.iso
> This indicates that QEMU failed to configure the s
On Wed, 12 Feb 2020 15:12:54 +0530
Anshuman Khandual wrote:
> >> +/*
> >> + * On s390 platform, the lower 12 bits are used to identify given page
> >> table
> >> + * entry type and for other arch specific requirements. But these bits
> >> might
> >> + * affect the ability to clear entries with
https://bugzilla.kernel.org/show_bug.cgi?id=206501
--- Comment #5 from Christophe Leroy (christophe.le...@c-s.fr) ---
Interesting.
NIP: 0550
NIP: 045c
NIP: 0c38
NIP: 0370
The kernel seems to badly fault on the first write to the stack. This suggests
that there is no page allo
On Wed, Feb 12, 2020 at 1:35 AM Shengjiu Wang wrote:
>
> EASRC (Enhanced Asynchronous Sample Rate Converter) is a new
> IP module found on i.MX815.
i.MX815 in an internal terminology. Please avoid it on the commit log.
>
> Signed-off-by: Shengjiu Wang
> ---
> .../devicetree/bindings/sound/fsl,
On 2/12/20 11:56 AM, Alexey Budankov wrote:
On 12.02.2020 18:45, Stephen Smalley wrote:
On 2/12/20 10:21 AM, Stephen Smalley wrote:
On 2/12/20 8:53 AM, Alexey Budankov wrote:
On 12.02.2020 16:32, Stephen Smalley wrote:
On 2/12/20 3:53 AM, Alexey Budankov wrote:
Hi Stephen,
On 22.01.2020 1
Quoting Geert Uytterhoeven (2020-02-12 02:17:36)
> The PowerPC time code is not a clock provider, and just needs to call
> of_clk_init().
>
> Hence it can include instead of .
>
> Signed-off-by: Geert Uytterhoeven
> ---
Reviewed-by: Stephen Boyd
This has an ifdef around the of_clk_init() cal
On 12.02.2020 18:45, Stephen Smalley wrote:
> On 2/12/20 10:21 AM, Stephen Smalley wrote:
>> On 2/12/20 8:53 AM, Alexey Budankov wrote:
>>> On 12.02.2020 16:32, Stephen Smalley wrote:
On 2/12/20 3:53 AM, Alexey Budankov wrote:
> Hi Stephen,
>
> On 22.01.2020 17:07, Stephen Small
On 12.02.2020 18:21, Stephen Smalley wrote:
> On 2/12/20 8:53 AM, Alexey Budankov wrote:
>> On 12.02.2020 16:32, Stephen Smalley wrote:
>>> On 2/12/20 3:53 AM, Alexey Budankov wrote:
Hi Stephen,
On 22.01.2020 17:07, Stephen Smalley wrote:
> On 1/22/20 5:45 AM, Alexey Budankov wro
On 2/12/20 10:21 AM, Stephen Smalley wrote:
On 2/12/20 8:53 AM, Alexey Budankov wrote:
On 12.02.2020 16:32, Stephen Smalley wrote:
On 2/12/20 3:53 AM, Alexey Budankov wrote:
Hi Stephen,
On 22.01.2020 17:07, Stephen Smalley wrote:
On 1/22/20 5:45 AM, Alexey Budankov wrote:
On 21.01.2020 21:
On 2/12/20 8:53 AM, Alexey Budankov wrote:
On 12.02.2020 16:32, Stephen Smalley wrote:
On 2/12/20 3:53 AM, Alexey Budankov wrote:
Hi Stephen,
On 22.01.2020 17:07, Stephen Smalley wrote:
On 1/22/20 5:45 AM, Alexey Budankov wrote:
On 21.01.2020 21:27, Alexey Budankov wrote:
On 21.01.2020 20
https://bugzilla.kernel.org/show_bug.cgi?id=206501
--- Comment #4 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 287329
--> https://bugzilla.kernel.org/attachment.cgi?id=287329&action=edit
dmesg (5.6.0-rc1 + Fix DSI and ISI... patch , PowerMac G4 DP)
First patch was not successful
On 02/12/2020 02:24 PM, Christophe Leroy wrote:
Hi Rasmus,
Kernel 5.6-rc1 silently fails on boot.
I bisected the problem to commit b6231ea2b3c6 ("soc: fsl: qe: drop
broken lazy call of cpm_muram_init()")
I get a bad_page_fault() for an access at address 8 in
cpm_muram_alloc_common(), cal
Le 12/02/2020 à 15:24, Christophe Leroy a écrit :
Hi Rasmus,
[...]
NB: Next time, can you please copy powerpc mailing list when changing
such core parts of powerpc CPUs ?
Apologise for that comment, in fact I was part of the recipients so it
didn't land in my linuxppc mailbox.
Seem
Hi Rasmus,
Kernel 5.6-rc1 silently fails on boot.
I bisected the problem to commit b6231ea2b3c6 ("soc: fsl: qe: drop
broken lazy call of cpm_muram_init()")
I get a bad_page_fault() for an access at address 8 in
cpm_muram_alloc_common(), called from cpm_uart_console_setup() via
cpm_uart_allo
On 12.02.2020 16:32, Stephen Smalley wrote:
> On 2/12/20 3:53 AM, Alexey Budankov wrote:
>> Hi Stephen,
>>
>> On 22.01.2020 17:07, Stephen Smalley wrote:
>>> On 1/22/20 5:45 AM, Alexey Budankov wrote:
On 21.01.2020 21:27, Alexey Budankov wrote:
>
> On 21.01.2020 20:55, Alexei Star
On 2/12/20 3:53 AM, Alexey Budankov wrote:
Hi Stephen,
On 22.01.2020 17:07, Stephen Smalley wrote:
On 1/22/20 5:45 AM, Alexey Budankov wrote:
On 21.01.2020 21:27, Alexey Budankov wrote:
On 21.01.2020 20:55, Alexei Starovoitov wrote:
On Tue, Jan 21, 2020 at 9:31 AM Alexey Budankov
wrote:
On Tue, 11 Feb 2020 04:57:52 +0100
dftxbs3e wrote:
> Hello,
>
> I took a snapshot of a ppc64 (big endian) VM from a ppc64 (little endian)
> host using `virsh snapshot-create-as --domain --name `
>
A big endian guest doing XIVE ?!? I'm pretty sure we didn't do much testing, if
any, on such a
Christophe Leroy writes:
> Le 12/02/2020 à 11:12, Daniel Axtens a écrit :
>> Christophe Leroy writes:
>>
>>> Le 12/02/2020 à 06:47, Daniel Axtens a écrit :
diff --git a/arch/powerpc/include/asm/kasan.h
b/arch/powerpc/include/asm/kasan.h
index fbff9ff9032e..2911fdd3a6a0 100644
>>
https://bugzilla.kernel.org/show_bug.cgi?id=206501
--- Comment #3 from Christophe Leroy (christophe.le...@c-s.fr) ---
Could you also test the patch https://patchwork.ozlabs.org/patch/1236804/
instead of the above patch.
--
You are receiving this mail because:
You are watching the assignee of the
hash_page() needs to read page tables from kernel memory. When entire
kernel memory is mapped by BATs, which is normally the case when
CONFIG_STRICT_KERNEL_RWX is not set, it works even if the page hosting
the page table is not referenced in the MMU hash table.
However, if the page where the page
Define a bitmask interface to determine support for the Self Restore,
Self Save or both.
Also define an interface to determine the preference of that SPR to
be strictly saved or restored or encapsulated with an order of preference.
The preference bitmask is shown as below:
---
This commit introduces and leverages the Self save API which OPAL now
supports.
Add the new Self Save OPAL API call in the list of OPAL calls.
Implement the self saving of the SPRs based on the support populated
while respecting it's preferences.
This implementation allows mixing of support for t
Parse the device tree for nodes self-save, self-restore and populate
support for the preferred SPRs based what was advertised by the device
tree.
Signed-off-by: Pratik Rajesh Sampat
Reviewed-by: Ram Pai
---
arch/powerpc/platforms/powernv/idle.c | 82 +++
1 file changed,
Skiboot patches v4:
https://lists.ozlabs.org/pipermail/skiboot/2020-February/016404.html
v3 patches: https://lkml.org/lkml/2020/1/13/333
Changelog
v3 --> v4
Device tree interface change: Cease to use the active property for
self-save and self-restore and use only presence/absence of the node to
s
Generated files are also checked by sparse that's why add newline
to remove sparse (C=1) warning.
The issue was found on Microblaze and reported like this:
./arch/microblaze/include/generated/uapi/asm/unistd_32.h:438:45:
warning: no newline at end of file
Mips and PowerPC have it already but let'
Le 12/02/2020 à 11:12, Daniel Axtens a écrit :
Christophe Leroy writes:
Le 12/02/2020 à 06:47, Daniel Axtens a écrit :
diff --git a/arch/powerpc/include/asm/kasan.h b/arch/powerpc/include/asm/kasan.h
index fbff9ff9032e..2911fdd3a6a0 100644
--- a/arch/powerpc/include/asm/kasan.h
+++ b/arch/
The PowerPC time code is not a clock provider, and just needs to call
of_clk_init().
Hence it can include instead of .
Signed-off-by: Geert Uytterhoeven
---
arch/powerpc/kernel/time.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/
Christophe Leroy writes:
> Le 12/02/2020 à 06:47, Daniel Axtens a écrit :
>> diff --git a/arch/powerpc/include/asm/kasan.h
>> b/arch/powerpc/include/asm/kasan.h
>> index fbff9ff9032e..2911fdd3a6a0 100644
>> --- a/arch/powerpc/include/asm/kasan.h
>> +++ b/arch/powerpc/include/asm/kasan.h
>> @@ -2
request_irq() is preferred over setup_irq(). Existing callers of
setup_irq() reached mostly via 'init_IRQ()' & 'time_init()', while
memory allocators are ready by 'mm_init()'.
Per tglx[1], setup_irq() existed in olden days when allocators were not
ready by the time early interrupts were initialize
While trying to understand internals of irq handling, came across a
thread [1] in which tglx was referring to avoid usage of setup_irq().
Existing callers of setup_irq() reached mostly via 'init_IRQ()' &
'time_init()', while memory allocators are ready by 'mm_init()'.
Hence instances of setup_irq(
On 02/10/2020 09:07 PM, Catalin Marinas wrote:
> On Tue, Jan 28, 2020 at 06:57:53AM +0530, Anshuman Khandual wrote:
>> This gets build and run when CONFIG_DEBUG_VM_PGTABLE is selected along with
>> CONFIG_VM_DEBUG. Architectures willing to subscribe this test also need to
>> select CONFIG_ARCH_HAS_
Hi Stephen,
On 22.01.2020 17:07, Stephen Smalley wrote:
> On 1/22/20 5:45 AM, Alexey Budankov wrote:
>>
>> On 21.01.2020 21:27, Alexey Budankov wrote:
>>>
>>> On 21.01.2020 20:55, Alexei Starovoitov wrote:
On Tue, Jan 21, 2020 at 9:31 AM Alexey Budankov
wrote:
>
>
> On 21.01
https://bugzilla.kernel.org/show_bug.cgi?id=206501
Christophe Leroy (christophe.le...@c-s.fr) changed:
What|Removed |Added
CC||christophe.le
54 matches
Mail list logo
