Le 10/05/2021 à 03:18, Jordan Niethe a écrit :
From: Russell Currey
To enable strict module RWX on powerpc, set:
CONFIG_STRICT_MODULE_RWX=y
You should also have CONFIG_STRICT_KERNEL_RWX=y set to have any real
security benefit.
ARCH_HAS_STRICT_MODULE_RWX is set to require
Le 10/05/2021 à 03:18, Jordan Niethe a écrit :
From: Russell Currey
Add the arch specific insn page allocator for powerpc. This allocates
ROX pages if STRICT_KERNEL_RWX is enabled. These pages are only written
to with patch_instruction() which is able to write RO pages.
Reviewed-by: Daniel
The cmd_cpp_lds_S rule already has -P and -U$(ARCH) so there is no need
in duplicating these, clean that up. Since only -C is left and
scripts/Makefile.build have -C removed since
commit 5cb0512c02ec ("Kbuild: don't pass "-C" to preprocessor when processing
linker scripts")
this follows the lead
Some interrupt handlers have an "extra" that saves 1 or 2 registers
(r14, r15) in the paca save area and makes them available to use by the
handler.
The change to always save nvgprs in exception handlers lead to some
interrupt handlers saving those scratch r14 / r15 registers into the
interrupt
On 14/05/2021 12:42, Masahiro Yamada wrote:
On Fri, May 14, 2021 at 3:59 AM Nathan Chancellor wrote:
On 5/13/2021 4:59 AM, Alexey Kardashevskiy wrote:
The $(CPP) (do only preprocessing) macro is already defined in Makefile.
However POWERPC redefines it and adds $(KBUILD_CFLAGS) which
On Wed, May 12, 2021 at 7:29 PM Segher Boessenkool
wrote:
>
> On Wed, May 12, 2021 at 01:48:53PM +1000, Alexey Kardashevskiy wrote:
> > >Oh! I completely missed those few lines. Sorry for that :-(
> >
> > Well, I probably should have made it a separate patch anyway, I'll
> > repost separately.
On Fri, May 14, 2021 at 3:59 AM Nathan Chancellor wrote:
>
> On 5/13/2021 4:59 AM, Alexey Kardashevskiy wrote:
> > The $(CPP) (do only preprocessing) macro is already defined in Makefile.
> > However POWERPC redefines it and adds $(KBUILD_CFLAGS) which results
> > in flags duplication. Which is
On 14/05/2021 04:59, Nathan Chancellor wrote:
On 5/13/2021 4:59 AM, Alexey Kardashevskiy wrote:
The $(CPP) (do only preprocessing) macro is already defined in Makefile.
However POWERPC redefines it and adds $(KBUILD_CFLAGS) which results
in flags duplication. Which is not a big deal by
On 14 May 2021 at 00:58am, Nicholas Piggin wrote:
Excerpts from Christian Zigotzky's message of May 14, 2021 6:20 am:
On 13 May 2021 at 07:00pm, Christophe Leroy wrote:
Ah yes, I remember this problem.
Can you select CONFIG_VIRT_CPU_ACCOUNTING_GEN in your configuration ?
Otherwise, I can try
Excerpts from Christian Zigotzky's message of May 14, 2021 6:20 am:
> On 13 May 2021 at 07:00pm, Christophe Leroy wrote:
>>
>> Ah yes, I remember this problem.
>>
>> Can you select CONFIG_VIRT_CPU_ACCOUNTING_GEN in your configuration ?
>>
>> Otherwise, I can try to fix the branch.
>>
>> Christophe
On 13 May 2021 at 07:00pm, Christophe Leroy wrote:
Le 13/05/2021 à 18:35, Christian Zigotzky a écrit :
On 13 May 2021 at 5:51pm, Christophe Leroy wrote:
Le 13/05/2021 à 17:19, Christian Zigotzky a écrit :
On 13 May 2021 at 12:01 pm, Christophe Leroy wrote:
Le 13/05/2021 à 08:47,
On 5/13/21 11:27 AM, Christophe Leroy wrote:
> When PUD and/or PMD are folded, those functions are useless
> and we have a stub in linux/pgtable.h
>
> Reported-by: Randy Dunlap
> Signed-off-by: Christophe Leroy
> ---
> arch/x86/mm/pgtable.c | 34 +++---
> 1 file
On 5/13/2021 4:59 AM, Alexey Kardashevskiy wrote:
The $(CPP) (do only preprocessing) macro is already defined in Makefile.
However POWERPC redefines it and adds $(KBUILD_CFLAGS) which results
in flags duplication. Which is not a big deal by itself except for
the flags which depend on other flags
When PUD and/or PMD are folded, those functions are useless
and we have a stub in linux/pgtable.h
Reported-by: Randy Dunlap
Signed-off-by: Christophe Leroy
---
arch/x86/mm/pgtable.c | 34 +++---
1 file changed, 19 insertions(+), 15 deletions(-)
diff --git
Le 13/05/2021 à 18:35, Christian Zigotzky a écrit :
On 13 May 2021 at 5:51pm, Christophe Leroy wrote:
Le 13/05/2021 à 17:19, Christian Zigotzky a écrit :
On 13 May 2021 at 12:01 pm, Christophe Leroy wrote:
Le 13/05/2021 à 08:47, Christian Zigotzky a écrit :
Hi Christophe,
On 9. May
On 13 May 2021 at 5:51pm, Christophe Leroy wrote:
Le 13/05/2021 à 17:19, Christian Zigotzky a écrit :
On 13 May 2021 at 12:01 pm, Christophe Leroy wrote:
Le 13/05/2021 à 08:47, Christian Zigotzky a écrit :
Hi Christophe,
On 9. May 2021, at 19:37, Christophe Leroy
wrote:
Did I do an
Le 13/05/2021 à 17:19, Christian Zigotzky a écrit :
On 13 May 2021 at 12:01 pm, Christophe Leroy wrote:
Le 13/05/2021 à 08:47, Christian Zigotzky a écrit :
Hi Christophe,
On 9. May 2021, at 19:37, Christophe Leroy wrote:
Did I do an error in my analysis ?
No, you didn’t. On the
On 13 May 2021 at 12:01 pm, Christophe Leroy wrote:
Le 13/05/2021 à 08:47, Christian Zigotzky a écrit :
Hi Christophe,
On 9. May 2021, at 19:37, Christophe Leroy
wrote:
Did I do an error in my analysis ?
No, you didn’t. On the contrary you have found the issue. ;-) The
issue is
The entry flush mitigation can be enabled/disabled at runtime. When this
happens it results in the kernel patching its own instructions to
enable/disable the mitigation sequence.
With strict kernel RWX enabled instruction patching happens via a
secondary mapping of the kernel text, so that we
The stf entry barrier fallback is unsafe to execute in a semi-patched
state, which can happen when enabling/disabling the mitigation with
strict kernel RWX enabled and using the hash MMU.
See the previous commit for more details.
Fix it by changing the order in which we patch the instructions.
Xen backends of para-virtualized devices can live in dom0 kernel, dom0
user land, or in a driver domain. This means that a backend might
reside in a less trusted environment than the Xen core components, so
a backend should not be able to do harm to a Xen guest (it can still
mess up I/O data, but
Hi Logan,
[...]
> Thanks, this is a great cleanup. I've reviewed the entire series.
>
> Reviewed-by: Logan Gunthorpe
Thank you! Appreciate it!
> I agree that the new lines that are missing should be added.
While working on the simple change to add the missing new lines, I've
found that we
On 5/12/21 10:57 PM, Peter Zijlstra wrote:
> On Wed, May 12, 2021 at 10:08:21PM +0530, Kajol Jain wrote:
>> +static void nvdimm_pmu_read(struct perf_event *event)
>> +{
>> +struct nvdimm_pmu *nd_pmu = to_nvdimm_pmu(event->pmu);
>> +
>> +/* jump to arch/platform specific callbacks if any
Almost all logic is moved to C, by introducing a new in_guest mode for
the P9 path that branches very early in the KVM interrupt handler to P9
exit code.
The main P9 entry and exit assembly is now only about 160 lines of low
level stack setup and register save/restore, plus a bad-interrupt
In the interest of minimising the amount of code that is run in
"real-mode", don't handle hcalls in real mode in the P9 path. This
requires some new handlers for H_CEDE and xics-on-xive to be added
before xive is pulled or cede logic is checked.
This introduces a change in radix guest behaviour
Switching the MMU from radix<->radix mode is tricky particularly as the
MMU can remain enabled and requires a certain sequence of SPR updates.
Move these together into their own functions.
This also includes the radix TLB check / flush because it's tied in to
MMU switching due to tlbiel getting
Move the xive management up so the low level register switching can be
pushed further down in a later patch. XIVE MMIO CI operations can run in
higher level code with machine checks, tracing, etc., available.
Reviewed-by: Alexey Kardashevskiy
Signed-off-by: Nicholas Piggin
---
This applies on top of these series:
https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=238649
https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=238941
https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=238946
This was broken out from the large Cify series.
The $(CPP) (do only preprocessing) macro is already defined in Makefile.
However POWERPC redefines it and adds $(KBUILD_CFLAGS) which results
in flags duplication. Which is not a big deal by itself except for
the flags which depend on other flags and the compiler checks them
as it parses the
Clean up the following includecheck warning:
./tools/testing/selftests/powerpc/tm/tm-vmx-unavail.c: pthread.h is
included more than once.
No functional change.
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
tools/testing/selftests/powerpc/tm/tm-vmx-unavail.c | 1 -
1 file changed,
On 13.05.21 12:25, Greg Kroah-Hartman wrote:
On Thu, May 13, 2021 at 12:03:02PM +0200, Juergen Gross wrote:
Xen frontends shouldn't BUG() in case of illegal data received from
their backends. So replace the BUG_ON()s when reading illegal data from
the ring page with negative return values.
On Thu, May 13, 2021 at 12:03:02PM +0200, Juergen Gross wrote:
> Xen frontends shouldn't BUG() in case of illegal data received from
> their backends. So replace the BUG_ON()s when reading illegal data from
> the ring page with negative return values.
>
> Signed-off-by: Juergen Gross
> ---
>
On 13.05.21 12:16, Christophe Leroy wrote:
Le 13/05/2021 à 12:03, Juergen Gross a écrit :
Xen frontends shouldn't BUG() in case of illegal data received from
their backends. So replace the BUG_ON()s when reading illegal data from
the ring page with negative return values.
Signed-off-by:
Le 13/05/2021 à 12:03, Juergen Gross a écrit :
Xen frontends shouldn't BUG() in case of illegal data received from
their backends. So replace the BUG_ON()s when reading illegal data from
the ring page with negative return values.
Signed-off-by: Juergen Gross
---
drivers/tty/hvc/hvc_xen.c
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
fixes-test
branch HEAD: da3bb206c9ceb0736d9e2897ea697acabad35833 KVM: PPC: Book3S HV: Fix
kvm_unmap_gfn_range_hv() for Hash MMU
elapsed time: 1183m
configs tested: 9
configs skipped: 83
The following configs have
Xen frontends shouldn't BUG() in case of illegal data received from
their backends. So replace the BUG_ON()s when reading illegal data from
the ring page with negative return values.
Signed-off-by: Juergen Gross
---
drivers/tty/hvc/hvc_xen.c | 15 +--
1 file changed, 13
Le 13/05/2021 à 08:47, Christian Zigotzky a écrit :
Hi Christophe,
On 9. May 2021, at 19:37, Christophe Leroy wrote:
Did I do an error in my analysis ?
No, you didn’t. On the contrary you have found the issue. ;-) The issue is
somewhere in the new interrupt code.
I'm not convinced,
On 04/05/2021 13:03, Nathan Lynch wrote:
Add new APIs for handling busy (-2) and extended delay
hint (9900...9905) statuses from RTAS. These are intended to be
drop-in replacements for existing uses of rtas_busy_delay().
A problem with rtas_busy_delay() and rtas_busy_delay_time() is that
iomap_max_page_shift is expected to contain a page shift,
so it can't be a 'bool', has to be an 'unsigned int'
And fix the default values: P4D_SHIFT is when huge iomap is allowed.
However, on some architectures (eg: powerpc book3s/64), P4D_SHIFT is
not a constant so it can't be used to
Thanks for looking into this patch Dan,
Dan Williams writes:
> On Fri, May 7, 2021 at 4:40 AM Vaibhav Jain wrote:
>>
>> In case performance stats for an nvdimm are not available, reading the
>> 'perf_stats' sysfs file returns an -ENOENT error. A better approach is
>> to make the 'perf_stats'
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
next-test
branch HEAD: d64ef8451fbc85489928bea033a63d9c09fca786 powerpc/32s: Remove
asm/book3s/32/hash.h
elapsed time: 1129m
configs tested: 9
configs skipped: 83
The following configs have been built
In case performance stats for an nvdimm are not available, reading the
'perf_stats' sysfs file returns an -ENOENT error. A better approach is
to make the 'perf_stats' file entirely invisible to indicate that
performance stats for an nvdimm are unavailable.
So this patch updates
Commit 51c9c0843993 ("powerpc/kprobes: Implement Optprobes")
implemented a powerpc specific version of optinsn in order
to workaround the 32Mb limitation for direct branches.
Instead of implementing a dedicated powerpc version, use the
common optinsn and override the allocation and freeing
Some architectures like powerpc require a non standard
allocation of optinsn page, because module pages are
too far from the kernel for direct branches.
Define weak alloc_optinsn_page() and free_optinsn_page(), that
fall back on alloc_insn_page() and free_insn_page() when not
overriden by the
Hi Christophe,
> On 9. May 2021, at 19:37, Christophe Leroy
> wrote:
>
> Did I do an error in my analysis ?
No, you didn’t. On the contrary you have found the issue. ;-) The issue is
somewhere in the new interrupt code.
> ZZ | * | ceff77efa4f8 powerpc/64e/interrupt: Use new interrupt
45 matches
Mail list logo
