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):
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
https://bugzilla.kernel.org/show_bug.cgi?id=204375
Christophe Leroy (christophe.le...@c-s.fr) changed:
What|Removed |Added
CC|
> 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
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
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
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
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
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
> 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
> > ---
> >
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
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
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
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
> >
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
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,
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
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
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
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
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
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
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':
> >
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
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
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
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
>
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,
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
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:
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
> -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
>
>
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
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
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
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
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 +++
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
---
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
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
---
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
---
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
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
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
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
---
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
On Mon, Jul 29, 2019 at 11:57:19AM +0200, Geert Uytterhoeven wrote:
> Hi Christoph,
>
> On Thu, Jul 25, 2019 at 8:35 AM Christoph Hellwig wrote:
> > Most dma_map_ops instances are IOMMUs that work perfectly fine in 32-bits
> > of IOVA space, and the generic direct mapping code already provides
60 matches
Mail list logo
