PPC32 also have flush_dcache_range() so it can also support
ARCH_HAS_PMEM_API and ARCH_HAS_UACCESS_FLUSHCACHE without changes.
Signed-off-by: Christophe Leroy
---
v2: moved pmem.o from obj64-y to obj-y
arch/powerpc/Kconfig | 4 ++--
arch/powerpc/lib/Makefile | 4 ++--
2 files changed, 4 i
[ sorry for a late reply too, somehow I missed this thread before ]
On Tue, Jul 30, 2019 at 10:14:15AM +0200, Michal Hocko wrote:
> [Sorry for a late reply]
>
> On Mon 15-07-19 17:55:07, Hoan Tran OS wrote:
> > Hi,
> >
> > On 7/12/19 10:00 PM, Michal Hocko wrote:
> [...]
> > > Hmm, I thought thi
On Tue, Jul 30, 2019 at 02:37:16PM -0500, Reza Arbab wrote:
> On Fri, Jul 26, 2019 at 10:34:40AM +0530, Bharata B Rao wrote:
> > remove_pagetable() isn't freeing PUD table. This causes memory
> > leak during memory unplug. Fix this.
>
> On x86, this is intentional. See
>
> af2cf278ef4f ("x86/mm/h
From 31753a44c62c4fdf6e8a72994ae6861dbde49c11 Mon Sep 17 00:00:00 2001
From: Stephen Rothwell
Date: Wed, 31 Jul 2019 16:00:52 +1000
Subject: [PATCH] xilinx_uartps.c: suppress "may be used uninitialised" warning
A powerpc allyesconfig build produces this warning:
In file included from include/lin
https://bugzilla.kernel.org/show_bug.cgi?id=204375
--- Comment #4 from Christophe Leroy (christophe.le...@c-s.fr) ---
Proposed fix at https://patchwork.ozlabs.org/patch/1139515/
--
You are receiving this mail because:
You are watching the assignee of the bug.
Due to commit 4a6d8cf90017 ("powerpc/mm: don't use pte_alloc_kernel()
until slab is available on PPC32"), pte_alloc_kernel() cannot be used
during early KASAN init.
Fix it by using memblock_alloc() instead.
Reported-by: Erhard F.
Fixes: 2edb16efc899 ("powerpc/32: Add KASAN support")
Signed-off-b
Hi all,
I have been getting the following warnings from a couple of powerpc
builds for quite a while now. I was hoping someone might have time to
look at them and maybe even fix them up :-)
arch/powerpc/boot/dts/virtex440-ml510.dts:335.37-439.6: Warning (pci_bridge):
/plb@0/plbv46-pci@85e0:
https://bugzilla.kernel.org/show_bug.cgi?id=204375
--- Comment #3 from Christophe Leroy (christophe.le...@c-s.fr) ---
Looks like that's due to 4a6d8cf90017 ("powerpc/mm: don't use
pte_alloc_kernel() until slab is available on PPC32"), committed just before
the KASAN series
--
You are receiving t
https://bugzilla.kernel.org/show_bug.cgi?id=204375
Christophe Leroy (christophe.le...@c-s.fr) changed:
What|Removed |Added
CC||christophe.le
> On July 30, 2019 at 7:11 PM Thiago Jung Bauermann
> wrote:
>
>
>
> Christopher M Riedl writes:
>
> >> On July 30, 2019 at 4:31 PM Thiago Jung Bauermann
> >> wrote:
> >>
> >>
> >>
> >> Christopher M. Riedl writes:
> >>
> >> > Determining if a processor is in shared processor mode is no
On 2019/7/30 17:44, Christophe Leroy wrote:
Le 30/07/2019 à 09:42, Jason Yan a écrit :
After we have the basic support of relocate the kernel in some
appropriate place, we can start to randomize the offset now.
Entropy is derived from the banner and timer, which will change every
build and
On 2019/7/30 17:34, Christophe Leroy wrote:
Le 30/07/2019 à 09:42, Jason Yan a écrit :
This patch add support to boot kernel from places other than KERNELBASE.
Since CONFIG_RELOCATABLE has already supported, what we need to do is
map or copy kernel to a proper place and relocate. Freescale
On 9/5/19 3:54 pm, Andrew Donnellan wrote:
On 9/5/19 3:37 pm, Nicholas Piggin wrote:
Andrew Donnellan's on May 9, 2019 3:11 pm:
SCOM_DEBUGFS is really not needed for anything other than low-level
hardware debugging.
opal-prd uses its own interface (/dev/prd) for SCOM access, so it
doesn't
ne
On 3/5/19 5:52 pm, Andrew Donnellan wrote:
Currently the OPAL symbol map is globally readable, which seems bad as it
contains physical addresses.
Restrict it to root.
Suggested-by: Michael Ellerman
Cc: Jordan Niethe
Cc: Stewart Smith
Fixes: c8742f85125d ("powerpc/powernv: Expose OPAL firmwar
On 7/28/19 5:26 PM, Gustavo A. R. Silva wrote:
> Mark switch cases where we are expecting to fall through.
>
> This patch fixes the following warnings:
>
> drivers/scsi/ibmvscsi/ibmvfc.c: In function 'ibmvfc_npiv_login_done':
> drivers/scsi/ibmvscsi/ibmvfc.c:4022:3: warning: this statement may fa
Christopher M Riedl writes:
>> On July 30, 2019 at 4:31 PM Thiago Jung Bauermann
>> wrote:
>>
>>
>>
>> Christopher M. Riedl writes:
>>
>> > Determining if a processor is in shared processor mode is not a constant
>> > so don't hide it behind a #define.
>> >
>> > Signed-off-by: Christopher M.
> On July 30, 2019 at 4:31 PM Thiago Jung Bauermann
> wrote:
>
>
>
> Christopher M. Riedl writes:
>
> > Determining if a processor is in shared processor mode is not a constant
> > so don't hide it behind a #define.
> >
> > Signed-off-by: Christopher M. Riedl
> > ---
> > arch/powerpc/inclu
On Wed, 2019-07-24 at 14:02:59 UTC, Michael Ellerman wrote:
> Wire up the new clone3 syscall added in commit 7f192e3cd316 ("fork:
> add clone3").
>
> This requires a ppc_clone3 wrapper, in order to save the non-volatile
> GPRs before calling into the generic syscall code. Otherwise we hit
> the BU
On Mon, 2019-07-29 at 09:51:28 UTC, "Aneesh Kumar K.V" wrote:
> Currently, nvdimm subsystem expects the device numa node for SCM device to be
> an online node. It also doesn't try to bring the device numa node online.
> Hence
> if we use a non-online numa node as device node we hit crashes like be
On Mon, 2019-07-29 at 05:55:36 UTC, Santosh Sivaraj wrote:
> Implicit fallthrough warning was enabled globally which broke
> the build. Make it explicit with a `fall through` comment.
>
> Signed-off-by: Santosh Sivaraj
> Reviewed-by: Stephen Rothwell
> Reviewed-by: Gustavo A. R. Silva
Applied
Christopher M. Riedl writes:
> Determining if a processor is in shared processor mode is not a constant
> so don't hide it behind a #define.
>
> Signed-off-by: Christopher M. Riedl
> ---
> arch/powerpc/include/asm/spinlock.h | 21 +++--
> 1 file changed, 15 insertions(+), 6 de
Hi Christophe,
On Tue, 2019-07-30 at 09:02 +0200, Christophe Leroy wrote:
>
> Le 24/07/2019 à 07:33, Chris Packham a écrit :
> >
> > Device tree aware platforms can make use of CMDLINE_EXTEND to
> > extend the
> > kernel command line provided by the bootloader. This is
> > particularly
> > usefu
On Tue, 2019-07-30 at 10:07 -0700, Kees Cook wrote:
>
> > Why do we think it's an expected fall through? I can't really
> > convince
> > myself from the surrounding code that it's definitely intentional.
>
> Yeah, good question. Just now when I went looking for who
> used SMU_I2C_TRANSFER_COMBINE
A handful of drivers all have a trivial wrapper around their ioctl
handler, but don't call the compat_ptr() conversion function at the
moment. In practice this does not matter, since none of them are used
on the s390 architecture and for all other architectures, compat_ptr()
does not do anything, b
On Fri, Jul 26, 2019 at 10:34:40AM +0530, Bharata B Rao wrote:
remove_pagetable() isn't freeing PUD table. This causes memory
leak during memory unplug. Fix this.
On x86, this is intentional. See
af2cf278ef4f ("x86/mm/hotplug: Don't remove PGD entries in remove_pagetable()")
98fe3633c5a4 ("x86
On Tue, Jul 30, 2019 at 08:24:14PM +0200, Arnd Bergmann wrote:
> On Tue, Jul 30, 2019 at 6:16 PM Segher Boessenkool
> wrote:
> > in_le32 and friends? Yeah, huh. If LLVM copies that to the stack as
> > well, its (not byte reversing) read will be atomic just fine, so things
> > will still work cor
https://bugzilla.kernel.org/show_bug.cgi?id=204371
--- Comment #2 from Andrew Morton (a...@linux-foundation.org) ---
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Mon, 29 Jul 2019 22:35:48 + bugzilla-dae...@bugzilla.kernel.org wrote:
>
On Tue, Jul 30, 2019 at 7:07 PM Segher Boessenkool
wrote:
>
> On Tue, Jul 30, 2019 at 11:16:37AM -0500, Segher Boessenkool wrote:
> > in_le32 and friends? Yeah, huh. If LLVM copies that to the stack as
> > well, its (not byte reversing) read will be atomic just fine, so things
> > will still wor
On Mon, Jul 29, 2019 at 01:13:56PM +0300, Denis Efremov wrote:
> Architectures currently define HAVE_ARCH_PCI_RESOURCE_TO_USER if they want
> to provide their own pci_resource_to_user() implementation. This could be
> simplified if we make the generic version a weak function. Thus,
> architecture s
On Tue, Jul 30, 2019 at 6:16 PM Segher Boessenkool
wrote:
>
> On Tue, Jul 30, 2019 at 04:30:29PM +0200, Arnd Bergmann wrote:
> > On Tue, Jul 30, 2019 at 3:49 PM Segher Boessenkool
> > wrote:
> > >
> > > On Tue, Jul 30, 2019 at 09:34:28AM +0200, Arnd Bergmann wrote:
> > > > Upon a second look, I t
Hi,
On 7/30/19 1:14 AM, Michal Hocko wrote:
> [Sorry for a late reply]
>
> On Mon 15-07-19 17:55:07, Hoan Tran OS wrote:
>> Hi,
>>
>> On 7/12/19 10:00 PM, Michal Hocko wrote:
> [...]
>>> Hmm, I thought this was selectable. But I am obviously wrong here.
>>> Looking more closely, it seems that thi
On Wed, Jul 31, 2019 at 12:28:55AM +1000, Michael Ellerman wrote:
> Stephen Rothwell writes:
> > Mark switch cases where we are expecting to fall through.
> >
> > This patch fixes the following warning (Building: powerpc):
> >
> > drivers/macintosh/smu.c: In function 'smu_queue_i2c':
> > drivers/m
On Tue, Jul 30, 2019 at 11:16:37AM -0500, Segher Boessenkool wrote:
> in_le32 and friends? Yeah, huh. If LLVM copies that to the stack as
> well, its (not byte reversing) read will be atomic just fine, so things
> will still work correctly.
>
> The things defined with DEF_MMIO_IN_D (instead of D
On Tue, Jul 30, 2019 at 04:30:29PM +0200, Arnd Bergmann wrote:
> On Tue, Jul 30, 2019 at 3:49 PM Segher Boessenkool
> wrote:
> >
> > On Tue, Jul 30, 2019 at 09:34:28AM +0200, Arnd Bergmann wrote:
> > > Upon a second look, I think the issue is that the "Z" is an input argument
> > > when it should
Hi Michael,
On Wed, 31 Jul 2019 00:28:55 +1000 Michael Ellerman wrote:
>
> Why do we think it's an expected fall through? I can't really convince
> myself from the surrounding code that it's definitely intentional.
Its been that way since this code was introduced by commit
0365ba7fb1fa ("[PAT
On Tue, Jul 30, 2019 at 3:49 PM Segher Boessenkool
wrote:
>
> On Tue, Jul 30, 2019 at 09:34:28AM +0200, Arnd Bergmann wrote:
> > Upon a second look, I think the issue is that the "Z" is an input argument
> > when it should be an output. clang decides that it can make a copy of the
> > input and pa
Stephen Rothwell writes:
> Mark switch cases where we are expecting to fall through.
>
> This patch fixes the following warning (Building: powerpc):
>
> drivers/macintosh/smu.c: In function 'smu_queue_i2c':
> drivers/macintosh/smu.c:854:21: warning: this statement may fall through
> [-Wimplicit-f
Mark switch cases where we are expecting to fall through.
Fixes errors such as below, seen with mpc85xx_defconfig:
arch/powerpc/kernel/align.c: In function 'emulate_spe':
arch/powerpc/kernel/align.c:178:8: error: this statement may fall through
ret |= __get_user_inatomic(temp.v[3], p++);
On Tue, Jul 30, 2019 at 09:34:28AM +0200, Arnd Bergmann wrote:
> Upon a second look, I think the issue is that the "Z" is an input argument
> when it should be an output. clang decides that it can make a copy of the
> input and pass that into the inline asm. This is not the most efficient
> way, bu
Hi Vaibhav,
Thanks for writing this documentation.
Vaibhav Jain writes:
> This doc patch provides an initial description of the HCall op-codes
> that are used by Linux kernel running as a guest operating
> system (LPAR) on top of PowerVM or any other sPAPR compliant
> hyper-visor (e.g qemu).
>
>
David Gibson writes:
> On Tue, Jul 23, 2019 at 09:43:55PM +0530, Vaibhav Jain wrote:
>> Update the hvcalls.h to include op-codes for new hcalls introduce to
>> manage SCM memory. Also update existing hcall definitions to reflect
>> current papr specification for SCM.
>>
>> The removed hcall op-co
Arnd Bergmann writes:
> On Mon, Jul 29, 2019 at 11:52 PM Segher Boessenkool
> wrote:
>> On Mon, Jul 29, 2019 at 01:32:46PM -0700, Nathan Chancellor wrote:
>> > For the record:
>> >
>> > https://godbolt.org/z/z57VU7
>> >
>> > This seems consistent with what Michael found so I don't think a revert
Le 30/07/2019 à 09:42, Jason Yan a écrit :
When kaslr is enabled, the kernel offset is different for every boot.
This brings some difficult to debug the kernel. Dump out the kernel
offset when panic so that we can easily debug the kernel.
Signed-off-by: Jason Yan
Cc: Diana Craciun
Cc: Micha
Le 30/07/2019 à 09:42, Jason Yan a écrit :
The original kernel still exists in the memory, clear it now.
Signed-off-by: Jason Yan
Cc: Diana Craciun
Cc: Michael Ellerman
Cc: Christophe Leroy
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Nicholas Piggin
Cc: Kees Cook
Reviewed-by:
Le 30/07/2019 à 09:42, Jason Yan a écrit :
After we have the basic support of relocate the kernel in some
appropriate place, we can start to randomize the offset now.
Entropy is derived from the banner and timer, which will change every
build and boot. This not so much safe so additionally th
> -Original Message-
> From: Scott Wood
> Sent: Sunday, July 28, 2019 10:27 PM
> To: Valentin Longchamp ; linuxppc-
> d...@lists.ozlabs.org; ga...@kernel.crashing.org
> Cc: Madalin-cristian Bucur
> Subject: Re: [PATCH] powerpc/kmcent2: update the ethernet devices' phy
> properties
>
> On
Le 30/07/2019 à 09:42, Jason Yan a écrit :
This patch add support to boot kernel from places other than KERNELBASE.
Since CONFIG_RELOCATABLE has already supported, what we need to do is
map or copy kernel to a proper place and relocate. Freescale Book-E
parts expect lowmem to be mapped by fixe
Le 30/07/2019 à 09:42, Jason Yan a écrit :
Add a new helper reloc_kernel_entry() to jump back to the start of the
new kernel. After we put the new kernel in a randomized place we can use
this new helper to enter the kernel and begin to relocate again.
Signed-off-by: Jason Yan
Cc: Diana Craci
Le 30/07/2019 à 09:42, Jason Yan a écrit :
Add a new helper create_tlb_entry() to create a tlb entry by the virtual
and physical address. This is a preparation to support boot kernel at a
randomized address.
Signed-off-by: Jason Yan
Cc: Diana Craciun
Cc: Michael Ellerman
Cc: Christophe Ler
Le 30/07/2019 à 09:42, Jason Yan a écrit :
Now the kernel base is a fixed value - KERNELBASE. To support KASLR, we
need a variable to store the kernel base.
Signed-off-by: Jason Yan
Cc: Diana Craciun
Cc: Michael Ellerman
Cc: Christophe Leroy
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Le 30/07/2019 à 09:42, Jason Yan a écrit :
These two variables are both defined in init_32.c and init_64.c. Move
them to init-common.c.
Signed-off-by: Jason Yan
Cc: Diana Craciun
Cc: Michael Ellerman
Cc: Christophe Leroy
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Nicholas Piggin
[Sorry for a late reply]
On Mon 15-07-19 17:55:07, Hoan Tran OS wrote:
> Hi,
>
> On 7/12/19 10:00 PM, Michal Hocko wrote:
[...]
> > Hmm, I thought this was selectable. But I am obviously wrong here.
> > Looking more closely, it seems that this is indeed only about
> > __early_pfn_to_nid and as su
On Mon, Jul 29, 2019 at 11:52 PM Segher Boessenkool
wrote:
>
> On Mon, Jul 29, 2019 at 01:32:46PM -0700, Nathan Chancellor wrote:
> > For the record:
> >
> > https://godbolt.org/z/z57VU7
> >
> > This seems consistent with what Michael found so I don't think a revert
> > is entirely unreasonable.
>
When kaslr is enabled, the kernel offset is different for every boot.
This brings some difficult to debug the kernel. Dump out the kernel
offset when panic so that we can easily debug the kernel.
Signed-off-by: Jason Yan
Cc: Diana Craciun
Cc: Michael Ellerman
Cc: Christophe Leroy
Cc: Benjamin
The original kernel still exists in the memory, clear it now.
Signed-off-by: Jason Yan
Cc: Diana Craciun
Cc: Michael Ellerman
Cc: Christophe Leroy
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Nicholas Piggin
Cc: Kees Cook
---
arch/powerpc/kernel/kaslr_booke.c | 11 +++
arch/
One may want to disable kaslr when boot, so provide a cmdline parameter
'nokaslr' to support this.
Signed-off-by: Jason Yan
Cc: Diana Craciun
Cc: Michael Ellerman
Cc: Christophe Leroy
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Nicholas Piggin
Cc: Kees Cook
---
arch/powerpc/kernel/k
After we have the basic support of relocate the kernel in some
appropriate place, we can start to randomize the offset now.
Entropy is derived from the banner and timer, which will change every
build and boot. This not so much safe so additionally the bootloader may
pass entropy via the /chosen/ka
These two variables are both defined in init_32.c and init_64.c. Move
them to init-common.c.
Signed-off-by: Jason Yan
Cc: Diana Craciun
Cc: Michael Ellerman
Cc: Christophe Leroy
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Nicholas Piggin
Cc: Kees Cook
---
arch/powerpc/mm/init-common
Now the kernel base is a fixed value - KERNELBASE. To support KASLR, we
need a variable to store the kernel base.
Signed-off-by: Jason Yan
Cc: Diana Craciun
Cc: Michael Ellerman
Cc: Christophe Leroy
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Nicholas Piggin
Cc: Kees Cook
---
arch/p
Add a new helper reloc_kernel_entry() to jump back to the start of the
new kernel. After we put the new kernel in a randomized place we can use
this new helper to enter the kernel and begin to relocate again.
Signed-off-by: Jason Yan
Cc: Diana Craciun
Cc: Michael Ellerman
Cc: Christophe Leroy
Add a new helper create_tlb_entry() to create a tlb entry by the virtual
and physical address. This is a preparation to support boot kernel at a
randomized address.
Signed-off-by: Jason Yan
Cc: Diana Craciun
Cc: Michael Ellerman
Cc: Christophe Leroy
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerr
This patch add support to boot kernel from places other than KERNELBASE.
Since CONFIG_RELOCATABLE has already supported, what we need to do is
map or copy kernel to a proper place and relocate. Freescale Book-E
parts expect lowmem to be mapped by fixed TLB entries(TLB1). The TLB1
entries are not su
This series implements KASLR for powerpc/fsl_booke/32, as a security
feature that deters exploit attempts relying on knowledge of the location
of kernel internals.
Since CONFIG_RELOCATABLE has already supported, what we need to do is
map or copy kernel to a proper place and relocate. Freescale Boo
M_IF_NEEDED is defined too many times. Move it to a common place.
Signed-off-by: Jason Yan
Cc: Diana Craciun
Cc: Michael Ellerman
Cc: Christophe Leroy
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Nicholas Piggin
Cc: Kees Cook
Reviewed-by: Christophe Leroy
---
arch/powerpc/include/as
Le 24/07/2019 à 07:33, Chris Packham a écrit :
Device tree aware platforms can make use of CMDLINE_EXTEND to extend the
kernel command line provided by the bootloader. This is particularly
useful to set parameters for built-in modules that would otherwise be
done at module insertion. Add suppo
65 matches
Mail list logo