Le 23/05/2019 à 08:49, Mathieu Malaterre a écrit :
In commit 2edb16efc899 ("powerpc/32: Add KASAN support") support for
KASAN has been added. However building it as module leads to (warning
treated as error with W=1):
arch/powerpc/mm/kasan/kasan_init_32.c:135:7: error: no previous prototyp
In commit 2edb16efc899 ("powerpc/32: Add KASAN support") support for
KASAN has been added. However building it as module leads to (warning
treated as error with W=1):
arch/powerpc/mm/kasan/kasan_init_32.c:135:7: error: no previous prototype for
'module_alloc' [-Werror=missing-prototypes]
Make
Salut Mathieu,
Le 23/05/2019 à 08:24, Mathieu Malaterre a écrit :
Salut Christophe,
On Wed, May 22, 2019 at 2:20 PM Christophe Leroy
wrote:
Le 22/05/2019 à 14:15, Mathieu Malaterre a écrit :
Hi all,
I have not boot my G4 in a while, today using master here is what I see:
done
Setting bt
Le 23/05/2019 à 07:21, Daniel Axtens a écrit :
Not all arches have a specific space carved out for modules -
some, such as powerpc, just use regular vmalloc space. Therefore,
globals in these modules cannot be backed by real shadow memory.
Can you explain in more details the reason why ?
PP
Salut Christophe,
On Wed, May 22, 2019 at 2:20 PM Christophe Leroy
wrote:
>
>
>
> Le 22/05/2019 à 14:15, Mathieu Malaterre a écrit :
> > Hi all,
> >
> > I have not boot my G4 in a while, today using master here is what I see:
> >
> > done
> > Setting btext !
> > W=640 H=488 LB=768 addr=0x9c008000
Christophe Leroy writes:
> Hi Daniel,
>
> Le 23/05/2019 à 07:21, Daniel Axtens a écrit :
>> Building on the work of Christophe, Aneesh and Balbir, I've ported
>> KASAN to Book3S radix.
>>
>> It builds on top Christophe's work on 32bit, and includes my work for
>> 64-bit Book3E (3S doesn't really
Le 23/05/2019 à 07:21, Daniel Axtens a écrit :
Wire up KASAN. Only outline instrumentation is supported.
The KASAN shadow area is mapped into vmemmap space:
0x8000 0400 to 0x8000 0600 .
To do this we require that vmemmap be disabled. (This is the default
in the kernel confi
On Tue, Apr 30, 2019 at 12:39:03PM +, Christophe Leroy wrote:
> This patch implements a fast entry for syscalls.
>
> Syscalls don't have to preserve non volatile registers except LR.
>
> This patch then implement a fast entry for syscalls, where
> volatile registers get clobbered.
>
> As thi
Le 23/05/2019 à 07:21, Daniel Axtens a écrit :
In powerpc (as I understand it), we spend a lot of time in boot
running in real mode before MMU paging is initialised. During
this time we call a lot of generic code, including printk(). If
we try to access the shadow region during this time, thin
Hi Daniel,
Le 23/05/2019 à 07:21, Daniel Axtens a écrit :
Building on the work of Christophe, Aneesh and Balbir, I've ported
KASAN to Book3S radix.
It builds on top Christophe's work on 32bit, and includes my work for
64-bit Book3E (3S doesn't really depend on 3E, but it was handy to
have aroun
Hi,
Le 22/05/2019 à 23:17, Aaro Koskinen a écrit :
Hi,
On Wed, May 22, 2019 at 10:33:35PM +0200, LEROY Christophe wrote:
Can you provide full details of the Oops you get ? And also your System.map ?
System.map is below. The oops log is attached as jpeg (crappy camera
shoot, apologies, I hope
Fixes: 63b2bc619565 ("powerpc/mm/32s: Use BATs for STRICT_KERNEL_RWX")
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/machine_kexec_32.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/kernel/machine_kexec_32.c
b/arch/powerpc/kernel/machine_kexec_32.c
index affe5dcce7
KASAN support on powerpc64 is interesting:
- We want to be able to support inline instrumentation so as to be
able to catch global and stack issues.
- We run a lot of code at boot in real mode. This includes stuff like
printk(), so it's not feasible to just disable instrumentation
arou
Not all arches have a specific space carved out for modules -
some, such as powerpc, just use regular vmalloc space. Therefore,
globals in these modules cannot be backed by real shadow memory.
In order to allow arches to perform this check, add a hook.
Signed-off-by: Daniel Axtens
---
include/l
powerpc supports several different MMUs. In particular, book3s
machines support both a hash-table based MMU and a radix MMU.
These MMUs support different numbers of entries per directory
level: PTES_PER_* reference variables. This leads to complier
errors as global variables must have constant size
Wire up KASAN. Only outline instrumentation is supported.
The KASAN shadow area is mapped into vmemmap space:
0x8000 0400 to 0x8000 0600 .
To do this we require that vmemmap be disabled. (This is the default
in the kernel config that QorIQ provides for the machine in their
SDK a
In powerpc (as I understand it), we spend a lot of time in boot
running in real mode before MMU paging is initialised. During
this time we call a lot of generic code, including printk(). If
we try to access the shadow region during this time, things fail.
My attempts to move early init before the
Currently, shadow addresses are always addr >> shift + offset.
However, for powerpc, the virtual address space is fragmented in
ways that make this simple scheme impractical.
Allow architectures to override:
- kasan_shadow_to_mem
- kasan_mem_to_shadow
- addr_has_shadow
Rename addr_has_shadow t
We have a couple of places checking for the existence of a shadow
mapping for an address by open-coding the inverse of the check in
addr_has_shadow.
Replace the open-coded versions with the helper. This will be
needed in future to allow architectures to override the layout
of the shadow mapping.
Building on the work of Christophe, Aneesh and Balbir, I've ported
KASAN to Book3S radix.
It builds on top Christophe's work on 32bit, and includes my work for
64-bit Book3E (3S doesn't really depend on 3E, but it was handy to
have around when developing and debugging).
This provides full inline
Hello Christoph,
Thanks for reviewing the patch!
Christoph Hellwig writes:
>> diff --git a/arch/powerpc/include/asm/mem_encrypt.h
>> b/arch/powerpc/include/asm/mem_encrypt.h
>> new file mode 100644
>> index ..45d5e4d0e6e0
>> --- /dev/null
>> +++ b/arch/powerpc/include/asm/mem_enc
Dave Young writes:
> On 05/22/19 at 07:01pm, Thiago Jung Bauermann wrote:
>> Commit b6664ba42f14 ("s390, kexec_file: drop arch_kexec_mem_walk()")
>> changed kexec_add_buffer() to skip searching for a memory location if
>> kexec_buf.mem is already set, and use the address that is there.
>>
>> I
On 05/22/19 at 07:01pm, Thiago Jung Bauermann wrote:
> Commit b6664ba42f14 ("s390, kexec_file: drop arch_kexec_mem_walk()")
> changed kexec_add_buffer() to skip searching for a memory location if
> kexec_buf.mem is already set, and use the address that is there.
>
> In powerpc code we reuse a kexe
The commit 58629c0dc349 ("powerpc/powernv/npu: Fault user page into the
hypervisor's pagetable") introduced a variable "c" to be used in
__get_user() and __get_user_nocheck() which need to stay as macros for
performance reasons, and "c" is not actually used in
pnv_npu2_handle_fault(),
arch/powerpc
While developing kasan for 64-bit book3s, I hit the following stack
over-read.
It occurs because the hypercall to put characters onto the terminal
takes 2 longs (128 bits/16 bytes) of characters at a time, and so
hvc_put_chars would unconditionally copy 16 bytes from the argument
buffer, regardles
Commit b6664ba42f14 ("s390, kexec_file: drop arch_kexec_mem_walk()")
changed kexec_add_buffer() to skip searching for a memory location if
kexec_buf.mem is already set, and use the address that is there.
In powerpc code we reuse a kexec_buf variable for loading both the kernel
and the initramfs by
On Mon, May 20, 2019 at 4:10 PM Bartlomiej Zolnierkiewicz
wrote:
>
> 'default n' is the default value for any bool or tristate Kconfig
> setting so there is no need to write it explicitly.
>
> Also since commit f467c5640c29 ("kconfig: only write '# CONFIG_FOO
> is not set' for visible symbols") th
Aaro Koskinen a écrit :
Hi,
On Wed, May 22, 2019 at 07:44:56AM +, Christophe Leroy wrote:
On 05/22/2019 06:14 AM, Christophe Leroy wrote:
>Le 22/05/2019 à 00:18, Aaro Koskinen a écrit :
>>I was trying to upgrade from v5.0 -> v5.1 on PowerBook G4, but when
>>trying
>>to kexec a kernel the
https://bugzilla.kernel.org/show_bug.cgi?id=203125
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Status|NEW |RESOLVED
Resol
Hi,
On Wed, May 22, 2019 at 07:44:56AM +, Christophe Leroy wrote:
> On 05/22/2019 06:14 AM, Christophe Leroy wrote:
> >Le 22/05/2019 à 00:18, Aaro Koskinen a écrit :
> >>I was trying to upgrade from v5.0 -> v5.1 on PowerBook G4, but when
> >>trying
> >>to kexec a kernel the system gets stuck (
Hi,
On Wed, May 22, 2019 at 08:14:23AM +0200, Christophe Leroy wrote:
> Le 22/05/2019 à 00:18, Aaro Koskinen a écrit :
> >I was trying to upgrade from v5.0 -> v5.1 on PowerBook G4, but when trying
> >to kexec a kernel the system gets stuck (no errors seen on the console).
>
> Do you mean you are
From: Daniel Baluta
[ Upstream commit ddb351145a967ee791a0fb0156852ec2fcb746ba ]
is_slave_mode defaults to false because sai structure
that contains it is kzalloc'ed.
Anyhow, if we decide to set the following configuration
SAI slave -> SAI master, is_slave_mode will remain set on true
although
From: Bo YU
[ Upstream commit 5d085ec04a000fefb5182d3b03ee46ca96d8389b ]
This is detected by Coverity scan: CID: 1440481
Signed-off-by: Bo YU
Signed-off-by: Michael Ellerman
Signed-off-by: Sasha Levin
---
arch/powerpc/boot/addnote.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
From: Daniel Baluta
[ Upstream commit ddb351145a967ee791a0fb0156852ec2fcb746ba ]
is_slave_mode defaults to false because sai structure
that contains it is kzalloc'ed.
Anyhow, if we decide to set the following configuration
SAI slave -> SAI master, is_slave_mode will remain set on true
although
From: Bo YU
[ Upstream commit 5d085ec04a000fefb5182d3b03ee46ca96d8389b ]
This is detected by Coverity scan: CID: 1440481
Signed-off-by: Bo YU
Signed-off-by: Michael Ellerman
Signed-off-by: Sasha Levin
---
arch/powerpc/boot/addnote.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
From: Daniel Baluta
[ Upstream commit ddb351145a967ee791a0fb0156852ec2fcb746ba ]
is_slave_mode defaults to false because sai structure
that contains it is kzalloc'ed.
Anyhow, if we decide to set the following configuration
SAI slave -> SAI master, is_slave_mode will remain set on true
although
From: Bo YU
[ Upstream commit 5d085ec04a000fefb5182d3b03ee46ca96d8389b ]
This is detected by Coverity scan: CID: 1440481
Signed-off-by: Bo YU
Signed-off-by: Michael Ellerman
Signed-off-by: Sasha Levin
---
arch/powerpc/boot/addnote.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
From: Anju T Sudhakar
[ Upstream commit a913e5e8b43be1d3897a141ce61c1ec071cad89c ]
Nest hardware counter memory resides in a per-chip reserve-memory.
During nest_imc_event_init(), chip-id of the event-cpu is considered to
calculate the base memory addresss for that cpu. Return, proper error
cond
From: Daniel Baluta
[ Upstream commit ddb351145a967ee791a0fb0156852ec2fcb746ba ]
is_slave_mode defaults to false because sai structure
that contains it is kzalloc'ed.
Anyhow, if we decide to set the following configuration
SAI slave -> SAI master, is_slave_mode will remain set on true
although
From: Nicholas Piggin
[ Upstream commit 7ae3f6e130e8dc6188b59e3b4ebc2f16e9c8d053 ]
Using a jiffies timer creates a dependency on the tick_do_timer_cpu
incrementing jiffies. If that CPU has locked up and jiffies is not
incrementing, the watchdog heartbeat timer for all CPUs stops and
creates fals
From: Anju T Sudhakar
[ Upstream commit 860b7d2286236170a36f94946d03ca9888d32571 ]
The data structure (i.e struct imc_mem_info) to hold the memory address
information for nest imc units is allocated based on the number of nodes
in the system.
nest_imc_event_init() traverse this struct array to
From: Bo YU
[ Upstream commit 5d085ec04a000fefb5182d3b03ee46ca96d8389b ]
This is detected by Coverity scan: CID: 1440481
Signed-off-by: Bo YU
Signed-off-by: Michael Ellerman
Signed-off-by: Sasha Levin
---
arch/powerpc/boot/addnote.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
From: Anju T Sudhakar
[ Upstream commit a913e5e8b43be1d3897a141ce61c1ec071cad89c ]
Nest hardware counter memory resides in a per-chip reserve-memory.
During nest_imc_event_init(), chip-id of the event-cpu is considered to
calculate the base memory addresss for that cpu. Return, proper error
cond
From: Daniel Baluta
[ Upstream commit ddb351145a967ee791a0fb0156852ec2fcb746ba ]
is_slave_mode defaults to false because sai structure
that contains it is kzalloc'ed.
Anyhow, if we decide to set the following configuration
SAI slave -> SAI master, is_slave_mode will remain set on true
although
From: Nicholas Piggin
[ Upstream commit 7ae3f6e130e8dc6188b59e3b4ebc2f16e9c8d053 ]
Using a jiffies timer creates a dependency on the tick_do_timer_cpu
incrementing jiffies. If that CPU has locked up and jiffies is not
incrementing, the watchdog heartbeat timer for all CPUs stops and
creates fals
From: Anju T Sudhakar
[ Upstream commit 860b7d2286236170a36f94946d03ca9888d32571 ]
The data structure (i.e struct imc_mem_info) to hold the memory address
information for nest imc units is allocated based on the number of nodes
in the system.
nest_imc_event_init() traverse this struct array to
From: Bo YU
[ Upstream commit 5d085ec04a000fefb5182d3b03ee46ca96d8389b ]
This is detected by Coverity scan: CID: 1440481
Signed-off-by: Bo YU
Signed-off-by: Michael Ellerman
Signed-off-by: Sasha Levin
---
arch/powerpc/boot/addnote.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
From: Anju T Sudhakar
[ Upstream commit a913e5e8b43be1d3897a141ce61c1ec071cad89c ]
Nest hardware counter memory resides in a per-chip reserve-memory.
During nest_imc_event_init(), chip-id of the event-cpu is considered to
calculate the base memory addresss for that cpu. Return, proper error
cond
From: Nicholas Piggin
[ Upstream commit 7ae3f6e130e8dc6188b59e3b4ebc2f16e9c8d053 ]
Using a jiffies timer creates a dependency on the tick_do_timer_cpu
incrementing jiffies. If that CPU has locked up and jiffies is not
incrementing, the watchdog heartbeat timer for all CPUs stops and
creates fals
From: Anju T Sudhakar
[ Upstream commit 860b7d2286236170a36f94946d03ca9888d32571 ]
The data structure (i.e struct imc_mem_info) to hold the memory address
information for nest imc units is allocated based on the number of nodes
in the system.
nest_imc_event_init() traverse this struct array to
From: Bo YU
[ Upstream commit 5d085ec04a000fefb5182d3b03ee46ca96d8389b ]
This is detected by Coverity scan: CID: 1440481
Signed-off-by: Bo YU
Signed-off-by: Michael Ellerman
Signed-off-by: Sasha Levin
---
arch/powerpc/boot/addnote.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
From: Anju T Sudhakar
[ Upstream commit a913e5e8b43be1d3897a141ce61c1ec071cad89c ]
Nest hardware counter memory resides in a per-chip reserve-memory.
During nest_imc_event_init(), chip-id of the event-cpu is considered to
calculate the base memory addresss for that cpu. Return, proper error
cond
On 05/22, Christian Brauner wrote:
>
> +static struct file *pick_file(struct files_struct *files, unsigned fd)
> {
> - struct file *file;
> + struct file *file = NULL;
> struct fdtable *fdt;
>
> spin_lock(&files->file_lock);
> @@ -632,15 +629,65 @@ int __close_fd(struct files
The commit b575c731fe58 ("powerpc/powernv/npu: Add set/unset window
helpers") called pnv_npu_set_window() in a void function
pnv_npu_dma_set_32(), but the return code from pnv_npu_set_window() has
no use there as all the error logging happen in pnv_npu_set_window(),
so just remove the unused variab
This adds basic tests for the new close_range() syscall.
- test that no invalid flags can be passed
- test that a range of file descriptors is correctly closed
- test that a range of file descriptors is correctly closed if there there
are already closed file descriptors in the range
- test that m
This adds the close_range() syscall. It allows to efficiently close a range
of file descriptors up to all file descriptors of a calling task.
The syscall came up in a recent discussion around the new mount API and
making new file descriptor types cloexec by default. During this
discussion, Al sugg
Hi Christophe,
thank you for your review.
On 22/05/2019 12:50, Christophe Leroy wrote:
>
>
> Le 22/05/2019 à 13:07, Vincenzo Frascino a écrit :
>> The current version of the multiarch vDSO selftest verifies only
>> gettimeofday.
>>
>> Extend the vDSO selftest to clock_getres, to verify that the
Hi Christophe,
thank you for your review.
On 22/05/2019 12:50, Christophe Leroy wrote:
>
>
> Le 22/05/2019 à 13:07, Vincenzo Frascino a écrit :
>> The current version of the multiarch vDSO selftest verifies only
>> gettimeofday.
>>
>> Extend the vDSO selftest to clock_getres, to verify that the
"Aneesh Kumar K.V" writes:
> On 5/14/19 9:45 AM, Dan Williams wrote:
>> [ add Keith who was looking at something similar ]
>>
...
>>
>> If it's reserved then we should not be accessing, even if the above
>> works in practice. Isn't the fix something more like this to fix up
>> the assumptions
Le 22/05/2019 à 14:15, Mathieu Malaterre a écrit :
Hi all,
I have not boot my G4 in a while, today using master here is what I see:
done
Setting btext !
W=640 H=488 LB=768 addr=0x9c008000
copying OF device tree...
starting device tree allocs at 01401000
otloc_up(0010, 0013d948)
trying
SMC relocation can also be activated earlier by the bootloader,
so the driver's behaviour cannot rely on selected kernel config.
When the SMC is relocated, CPM_CR_INIT_TRX cannot be used.
But the only thing CPM_CR_INIT_TRX does is to clear the
rstate and tstate registers, so this can be done manu
Hi all,
I have not boot my G4 in a while, today using master here is what I see:
done
Setting btext !
W=640 H=488 LB=768 addr=0x9c008000
copying OF device tree...
starting device tree allocs at 01401000
otloc_up(0010, 0013d948)
trying: 0x01401000
trying: 0x01501000
-› 01501000
alloc_bo
Le 22/05/2019 à 13:07, Vincenzo Frascino a écrit :
The current version of the multiarch vDSO selftest verifies only
gettimeofday.
Extend the vDSO selftest to clock_getres, to verify that the
syscall and the vDSO library function return the same information.
The extension has been used to ver
clock_getres in the vDSO library has to preserve the same behaviour
of posix_get_hrtimer_res().
In particular, posix_get_hrtimer_res() does:
sec = 0;
ns = hrtimer_resolution;
and hrtimer_resolution depends on the enablement of the high
resolution timers that can happen either at compile or
The current version of the multiarch vDSO selftest verifies only
gettimeofday.
Extend the vDSO selftest to clock_getres, to verify that the
syscall and the vDSO library function return the same information.
The extension has been used to verify the hrtimer_resoltion fix.
Cc: Shuah Khan
Signed-o
clock_getres in the vDSO library has to preserve the same behaviour
of posix_get_hrtimer_res().
In particular, posix_get_hrtimer_res() does:
sec = 0;
ns = hrtimer_resolution;
and hrtimer_resolution depends on the enablement of the high
resolution timers that can happen either at compile or
clock_getres in the vDSO library has to preserve the same behaviour
of posix_get_hrtimer_res().
In particular, posix_get_hrtimer_res() does:
sec = 0;
ns = hrtimer_resolution;
and hrtimer_resolution depends on the enablement of the high
resolution timers that can happen either at compile or
spi_finalize_current_message() shall be called once all
actions are finished, otherwise the last actions might
step over a newly started transfer.
Fixes: c592becbe704 ("spi: fsl-(e)spi: migrate to generic master queueing")
Signed-off-by: Christophe Leroy
---
drivers/spi/spi-fsl-spi.c | 2 +-
1 f
On Wed, May 22, 2019 at 01:57:01PM +0530, Aneesh Kumar K.V wrote:
> The nfpn related change is needed to fix the kernel message
>
> "number of pfns truncated from 2617344 to 163584"
>
> The change makes sure the nfpns stored in the superblock is right value.
>
> Signed-off-by: Aneesh Kumar K.V
This allows us to make changes in a backward incompatible way. I have
kept the PFN_MIN_VERSION in this patch '0' because we are not introducing
any incompatible changes in this patch. We also may want to backport this
to older kernels.
The error looks like
dax0.1: init failed, superblock min ve
The nfpn related change is needed to fix the kernel message
"number of pfns truncated from 2617344 to 163584"
The change makes sure the nfpns stored in the superblock is right value.
Signed-off-by: Aneesh Kumar K.V
---
drivers/nvdimm/label.c | 2 +-
drivers/nvdimm/pfn_devs.c| 6 +++--
This is needed so that we don't wrongly initialize a namespace
which doesn't have enough space reserved for holding struct pages
with the current kernel.
We also increment PFN_MIN_VERSION to make sure that older kernel
won't initialize namespace created with newer kernel.
Signed-off-by: Aneesh Ku
On Tue, May 21, 2019 at 10:23 PM Linus Torvalds
wrote:
>
> On Tue, May 21, 2019 at 9:41 AM Christian Brauner
> wrote:
> >
> > Yeah, you mentioned this before. I do like being able to specify an
> > upper bound to have the ability to place fds strategically after said
> > upper bound.
>
> I suspe
Hi Again,
On 05/22/2019 06:14 AM, Christophe Leroy wrote:
Hi Aero,
Le 22/05/2019 à 00:18, Aaro Koskinen a écrit :
Hi,
I was trying to upgrade from v5.0 -> v5.1 on PowerBook G4, but when
trying
to kexec a kernel the system gets stuck (no errors seen on the console).
Do you mean you are try
Hi,
On 5/21/19 5:18 PM, Michael Ellerman wrote:
Anju T Sudhakar writes:
Currently init_imc_pmu() can be failed either because
an IMC unit with invalid domain(i.e an IMC node not
supported by the kernel) is attempted a pmu-registration
or something went wrong while registering a valid IMC unit.
75 matches
Mail list logo
