Le 27/09/2022 à 04:57, Benjamin Gray a écrit :
> On Mon, 2022-09-26 at 14:33 +, Christophe Leroy wrote:
>>> +#define patch_memory(addr, val) \
>>> +({ \
>>> + BUILD_BUG_ON(!__native_word(val)); \
>>> + __patch_memory(addr, (unsigned long) val, sizeof(val)); \
>>> +})
>>
>> Can
On Mon, 2022-09-26 at 13:16 +, Christophe Leroy wrote:
> Build failure with GCC 5.5 (ppc64le_defconfig):
>
> CC arch/powerpc/kernel/ptrace/ptrace.o
> {standard input}: Assembler messages:
> {standard input}:10: Error: .localentry expression for
> `__SCT__tp_func_sys_enter' is not a
On Tue Sep 27, 2022 at 11:48 AM AEST, Zhouyi Zhou wrote:
> This is second version of my fix to PPC's "WARNING: suspicious RCU usage",
> I improved my fix under Paul E. McKenney's guidance:
> Link:
> https://lore.kernel.org/lkml/20220914021528.15946-1-zhouzho...@gmail.com/T/
>
> During the cpu
On Mon, 2022-09-26 at 14:55 +, Christophe Leroy wrote:
> > +config PPC_STATIC_CALL_KUNIT_TEST
> > + tristate "KUnit tests for PPC64 ELF ABI V2 static calls"
> > + default KUNIT_ALL_TESTS
> > + depends on HAVE_STATIC_CALL && PPC64_ELF_ABI_V2 && KUNIT &&
> > m
>
> Is there a
On Mon, 2022-09-26 at 14:54 +, Christophe Leroy wrote:
> > diff --git a/arch/powerpc/kernel/static_call.c
> > b/arch/powerpc/kernel/static_call.c
> > index 863a7aa24650..ecbb74e1b4d3 100644
> > --- a/arch/powerpc/kernel/static_call.c
> > +++ b/arch/powerpc/kernel/static_call.c
> > @@ -4,30
On Mon, 2022-09-26 at 14:33 +, Christophe Leroy wrote:
> > +#define patch_memory(addr, val) \
> > +({ \
> > + BUILD_BUG_ON(!__native_word(val)); \
> > + __patch_memory(addr, (unsigned long) val, sizeof(val)); \
> > +})
>
> Can you do a static __always_inline function instead of a
On Mon, 2022-09-26 at 14:49 +, Christophe Leroy wrote:
> > + /* Replace indirect branch sequence with direct branch
> > where possible */
> > + if (!create_branch(, jump_seq_addr, addr, 0))
> > + if (patch_instruction(jump_seq_addr, direct))
>
> Why not use
On Mon, Sep 26, 2022 at 09:40:25AM +0200, Michal Such??nek wrote:
> On Mon, Sep 26, 2022 at 08:47:32AM +0200, Greg Kroah-Hartman wrote:
> > On Sat, Sep 24, 2022 at 01:55:23PM +0200, Michal Suchánek wrote:
> > > On Sat, Sep 24, 2022 at 12:13:34PM +0200, Greg Kroah-Hartman wrote:
> > > > On Sat, Sep
Jason Gunthorpe writes:
> On Mon, Sep 26, 2022 at 04:03:06PM +1000, Alistair Popple wrote:
>> Since 27674ef6c73f ("mm: remove the extra ZONE_DEVICE struct page
>> refcount") device private pages have no longer had an extra reference
>> count when the page is in use. However before handing them
Felix Kuehling writes:
> On 2022-09-26 17:35, Lyude Paul wrote:
>> On Mon, 2022-09-26 at 16:03 +1000, Alistair Popple wrote:
>>> When the module is unloaded or a GPU is unbound from the module it is
>>> possible for device private pages to be left mapped in currently running
>>> processes.
This is second version of my fix to PPC's "WARNING: suspicious RCU usage",
I improved my fix under Paul E. McKenney's guidance:
Link:
https://lore.kernel.org/lkml/20220914021528.15946-1-zhouzho...@gmail.com/T/
During the cpu offlining, the sub functions of xive_teardown_cpu will
call
On Fri, Sep 23, 2022 at 04:58:41PM +1000,
Michael Ellerman wrote:
> isaku.yamah...@intel.com writes:
> > From: Isaku Yamahata
> >
> > Move processor compatibility check from kvm_arch_processor_compat() into
> ^
>
On Mon, 2022-09-26 at 07:57 +, Nicholas Miehlbradt wrote:
> KFENCE support was added for ppc32 in commit 90cbac0e995d
> ("powerpc: Enable KFENCE for PPC32").
> Enable KFENCE on ppc64 architecture with hash and radix MMUs.
> It uses the same mechanism as debug pagealloc to
> protect/unprotect
John Hubbard writes:
> On 9/26/22 14:35, Lyude Paul wrote:
>>> + for (i = 0; i < npages; i++) {
>>> + if (src_pfns[i] & MIGRATE_PFN_MIGRATE) {
>>> + struct page *dpage;
>>> +
>>> + /*
>>> +* _GFP_NOFAIL because the GPU is
On 2022-09-26 17:35, Lyude Paul wrote:
On Mon, 2022-09-26 at 16:03 +1000, Alistair Popple wrote:
When the module is unloaded or a GPU is unbound from the module it is
possible for device private pages to be left mapped in currently running
processes. This leads to a kernel crash when the
On Mon, Sep 26, 2022 at 05:52:18PM -0500, Rob Herring wrote:
> On Thu, Sep 22, 2022 at 4:15 PM Daniel Gimpelevich
> wrote:
> >
> > On Thu, 2022-09-22 at 14:10 -0700, Daniel Walker wrote:
> > > On Thu, Sep 22, 2022 at 05:03:46PM -0400, Sean Anderson wrote:
> > [snip]
> > > > As recently as last
On Thu, Sep 22, 2022 at 02:15:44PM -0700, Daniel Gimpelevich wrote:
> On Thu, 2022-09-22 at 14:10 -0700, Daniel Walker wrote:
> > On Thu, Sep 22, 2022 at 05:03:46PM -0400, Sean Anderson wrote:
> [snip]
> > > As recently as last month, someone's patch to add such support was
> > > rejected for this
On Thu, Sep 22, 2022 at 4:15 PM Daniel Gimpelevich
wrote:
>
> On Thu, 2022-09-22 at 14:10 -0700, Daniel Walker wrote:
> > On Thu, Sep 22, 2022 at 05:03:46PM -0400, Sean Anderson wrote:
> [snip]
> > > As recently as last month, someone's patch to add such support was
> > > rejected for this reason
On Mon, Sep 26, 2022 at 9:18 AM Nathan Lynch wrote:
>
> The error injection facility on pseries VMs allows corruption of
> arbitrary guest memory, potentially enabling a sufficiently privileged
> user to disable lockdown or perform other modifications of the running
> kernel via the rtas syscall.
On Mon, Sep 26, 2022 at 9:17 AM Nathan Lynch wrote:
>
> The /proc/powerpc/ofdt interface allows the root user to freely alter
> the in-kernel device tree, enabling arbitrary physical address writes
> via drivers that could bind to malicious device nodes, thus making it
> possible to disable
On 9/26/22 14:35, Lyude Paul wrote:
>> +for (i = 0; i < npages; i++) {
>> +if (src_pfns[i] & MIGRATE_PFN_MIGRATE) {
>> +struct page *dpage;
>> +
>> +/*
>> + * _GFP_NOFAIL because the GPU is going away and there
>> +
At boot time, it is not necessary to delay between polls of
cpu_callin_map when waiting for a kicked CPU to come up. Remove the
delay intervals, but preserve the overall deadline (five seconds).
At run time, the first poll result is usually negative and we incur a
sleeping wait. If we spin on the
On Mon, 2022-09-26 at 05:55 +, Christophe Leroy wrote:
>
> Le 25/09/2022 à 22:26, Haren Myneni a écrit :
> > DSI error will be generated when the paste operation is issued on
> > the suspended NX window due to NX state changes. The hypervisor
> > expects the partition to ignore this error
Em Fri, Sep 16, 2022 at 06:35:41PM +0530, kajoljain escreveu:
>
>
> On 9/16/22 16:19, Athira Rajeev wrote:
> > The perf probe related tests like probe_vfs_getname.sh which
> > is in "tools/perf/tests/shell" directory have dependency on
> > debuginfo information in the kernel. Currently debuginfo
This allows multiple phandles to be specified for pcs-handle, such as
when multiple PCSs are present for a single MAC. To differentiate
between them, also add a pcs-handle-names property.
Signed-off-by: Sean Anderson
---
This was previously submitted as [1]. I expect to update this series
more,
Now that we actually read registers from QSGMII PCSs, it's important
that we have the correct address (instead of hoping that we're the MAC
with all the QSGMII PCSs on its bus). This adds nodes for the QSGMII
PCSs. The exact mapping of QSGMII to MACs depends on the SoC.
Since the first QSGMII
Now that we actually read registers from QSGMII PCSs, it's important
that we have the correct address (instead of hoping that we're the MAC
with all the QSGMII PCSs on its bus). This adds nodes for the QSGMII
PCSs. They have the same addresses on all SoCs (e.g. if QSGMIIA is
present it's used for
On the T208X SoCs, MAC1 and MAC2 support XGMII. Add some new MAC dtsi
fragments, and mark the QMAN ports as 10G.
Fixes: da414bb923d9 ("powerpc/mpc85xx: Add FSL QorIQ DPAA FMan support to the
SoC device tree(s)")
Signed-off-by: Sean Anderson
---
(no changes since v4)
Changes in v4:
- New
This converts DPAA to phylink. All macs are converted. This should work
with no device tree modifications (including those made in this series),
except for QSGMII (as noted previously).
The mEMAC configuration is one of the tricker areas. I have tried to
capture all the restrictions across the
Although not stated in the datasheet, as far as I can tell PCS for mEMACs
is a "Lynx." By reusing the existing driver, we can remove the PCS
management code from the memac driver. This requires calling some PCS
functions manually which phylink would usually do for us, but we will let
it do that
This adds support for using a serdes which has to be configured. This is
primarly in preparation for the next commit, which will then change the
serdes mode dynamically.
Signed-off-by: Sean Anderson
---
(no changes since v4)
Changes in v4:
- Don't fail if phy support was not compiled in
At the moment, mEMACs are configured almost completely based on the
phy-connection-type. That is, if the phy interface is RGMII, it assumed
that RGMII is supported. For some interfaces, it is assumed that the
RCW/bootloader has set up the SerDes properly. This is generally OK, but
restricts
This binding is fairly bare-bones for now, since the Lynx driver doesn't
parse any properties (or match based on the compatible). We just need it
in order to prevent the PCS nodes from having phy devices attached to
them. This is not really a problem, but it is a bit inefficient.
This binding is
This series converts the DPAA driver to phylink.
I have tried to maintain backwards compatibility with existing device
trees whereever possible. However, one area where I was unable to
achieve this was with QSGMII. Please refer to patch 2 for details.
All mac drivers have now been converted. I
On Mon, Sep 26, 2022 at 10:01:55PM +0800, Zhuo Chen wrote:
> On 9/23/22 5:08 AM, Bjorn Helgaas wrote:
> > On Fri, Sep 02, 2022 at 02:16:33AM +0800, Zhuo Chen wrote:
> > > When state is pci_channel_io_frozen in pcie_do_recovery(),
> > > the severity is fatal and fatal status should be cleared.
> >
On Mon, Sep 26, 2022 at 10:16:23PM +0800, Zhuo Chen wrote:
> On 9/23/22 5:50 AM, Bjorn Helgaas wrote:
> > On Fri, Sep 02, 2022 at 02:16:34AM +0800, Zhuo Chen wrote:
> > > Statements clearing AER error status in aer_enable_rootport() has the
> > > same function as pci_aer_raw_clear_status(). So we
On Mon, Sep 26, 2022 at 09:30:48PM +0800, Zhuo Chen wrote:
> On 9/23/22 4:02 AM, Bjorn Helgaas wrote:
> > On Mon, Sep 12, 2022 at 01:09:05AM +0800, Zhuo Chen wrote:
> > > On 9/12/22 12:22 AM, Serge Semin wrote:
> > > > On Fri, Sep 02, 2022 at 02:16:32AM +0800, Zhuo Chen wrote:
> > >
On 9/24/22 2:54 AM, Vinod Koul wrote:
> On 20-09-22, 16:23, Sean Anderson wrote:
>> This adds support for the Lynx 10G "SerDes" devices found on various NXP
>> QorIQ SoCs. There may be up to four SerDes devices on each SoC, each
>> supporting up to eight lanes. Protocol support for each SerDes
NUMA hinting no longer uses savedwrite, let's rip it out.
... and while at it, drop __pte_write() and __pmd_write() on ppc64.
Signed-off-by: David Hildenbrand
---
arch/powerpc/include/asm/book3s/64/pgtable.h | 80 +---
arch/powerpc/kvm/book3s_hv_rm_mmu.c | 2 +-
commit b191f9b106ea ("mm: numa: preserve PTE write permissions across a
NUMA hinting fault") added remembering write permissions using ordinary
pte_write() for PROT_NONE mapped pages to avoid write faults when
remapping the page !PROT_NONE on NUMA hinting faults.
That commit noted:
The patch
Let's replicate what we have for PTEs in can_change_pte_writable() also
for PMDs.
While this might look like a pure performance improvement, we'll us this to
get rid of savedwrite handling in do_huge_pmd_numa_page() next. Place
do_huge_pmd_numa_page() stategicly good for that purpose.
Note that
We want to replicate this code for handling PMDs soon. No need to crash
the kernel, warning and rejecting is good enough. As this will no longer
get optimized out, drop the pte_write() check: no harm would be done.
While at it, add a comment why PROT_NONE mapped pages are excluded.
From: Nadav Amit
Anonymous pages might have the dirty bit clear, but this should not
prevent mprotect from making them writable if they are exclusive.
Therefore, skip the test whether the page is dirty in this case.
Note that there are already other ways to get a writable PTE mapping an
As discussed in my talk at LPC, we can reuse the same mechanism for
deciding whether to map a pte writable when upgrading permissions via
mprotect() -- e.g., PROT_READ -> PROT_READ|PROT_WRITE -- to replace the
savedwrite infrastructure used for NUMA hinting faults (e.g., PROT_NONE
->
Le 26/09/2022 à 08:43, Benjamin Gray a écrit :
> KUnit tests for the various combinations of caller/trampoline/target and
> kernel/module. They must be run from a module loaded at runtime to
> guarantee they have a different TOC to the kernel.
>
> The tests try to mitigate the chance of
Le 26/09/2022 à 08:43, Benjamin Gray a écrit :
> Implement static call support for 64 bit V2 ABI. This requires
> making sure the TOC is kept correct across kernel-module
> boundaries. As a secondary concern, it tries to use the local
> entry point of a target wherever possible. It does so by
>
Le 26/09/2022 à 08:43, Benjamin Gray a écrit :
> These tests are out-of-line only, so moving them to the
> their own file allows them to be run when an arch does
> not implement inline static calls.
>
> Signed-off-by: Benjamin Gray
I think you got a Reviewed-by from previous series.
> ---
>
Le 26/09/2022 à 08:43, Benjamin Gray a écrit :
> Inserts a direct branch to the stub target when possible, replacing the
> mtctr/btctr sequence.
>
> The load into r12 could potentially be skipped too, but that change
> would need to refactor the arguments to indicate that the address
> does not
On Mon, Sep 26, 2022 at 04:03:06PM +1000, Alistair Popple wrote:
> Since 27674ef6c73f ("mm: remove the extra ZONE_DEVICE struct page
> refcount") device private pages have no longer had an extra reference
> count when the page is in use. However before handing them back to the
> owning device
Hi,
By the way my email address is not anymore @c-s.fr but @csgroup.eu
allthough the former still works.
Le 26/09/2022 à 08:43, Benjamin Gray a écrit :
> Adds a generic text patching mechanism for patches of 1, 2, 4, or (64-bit) 8
> bytes. The patcher conditionally syncs the icache depending on
Le 26/09/2022 à 08:43, Benjamin Gray a écrit :
> Implementation of out-of-line static calls for PowerPC 64-bit ELF V2 ABI.
> Static calls patch an indirect branch into a direct branch at runtime.
> Out-of-line specifically has a caller directly call a trampoline, and
> the trampoline gets
On 9/23/22 5:50 AM, Bjorn Helgaas wrote:
On Fri, Sep 02, 2022 at 02:16:34AM +0800, Zhuo Chen wrote:
Statements clearing AER error status in aer_enable_rootport() has the
same function as pci_aer_raw_clear_status(). So we replace them, which
has no functional changes.
Signed-off-by: Zhuo
On 9/23/22 5:08 AM, Bjorn Helgaas wrote:
On Fri, Sep 02, 2022 at 02:16:33AM +0800, Zhuo Chen wrote:
When state is pci_channel_io_frozen in pcie_do_recovery(),
the severity is fatal and fatal status should be cleared.
So we add pci_aer_clear_fatal_status().
Seems sensible to me. Did you
On 9/23/22 4:02 AM, Bjorn Helgaas wrote:
On Mon, Sep 12, 2022 at 01:09:05AM +0800, Zhuo Chen wrote:
On 9/12/22 12:22 AM, Serge Semin wrote:
On Fri, Sep 02, 2022 at 02:16:32AM +0800, Zhuo Chen wrote:
Status bits for ERR_NONFATAL errors only are cleared in
pci_aer_clear_nonfatal_status(),
Hi Benjamin,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on 3d7a198cfdb47405cfb4a3ea523876569fe341e6]
url:
https://github.com/intel-lab-lkp/linux/commits/Benjamin-Gray/Out-of-line-static-calls-for-powerpc64-ELF-V2/20220926-145009
base
Haren Myneni writes:
> DSI error will be generated when the paste operation is issued on
> the suspended NX window due to NX state changes. The hypervisor
Please spell out DSI and NX on the first usage.
> expects the partition to ignore this error during page pault
> handling. To differentiate
The error injection facility on pseries VMs allows corruption of
arbitrary guest memory, potentially enabling a sufficiently privileged
user to disable lockdown or perform other modifications of the running
kernel via the rtas syscall.
Block the PAPR error injection facility from being opened or
Le 26/09/2022 à 08:43, Benjamin Gray a écrit :
> Implement static call support for 64 bit V2 ABI. This requires
> making sure the TOC is kept correct across kernel-module
> boundaries. As a secondary concern, it tries to use the local
> entry point of a target wherever possible. It does so by
>
Add two new lockdown reasons for use in powerpc's pseries platform
code.
The pseries platform allows hardware-level error injection via certain
calls to the RTAS (Run Time Abstraction Services) firmware. ACPI-based
error injection is already restricted in lockdown; this facility
should be
The /proc/powerpc/ofdt interface allows the root user to freely alter
the in-kernel device tree, enabling arbitrary physical address writes
via drivers that could bind to malicious device nodes, thus making it
possible to disable lockdown.
Historically this interface has been used on the pseries
Add missing __init/__exit annotations to module init/exit funcs
Signed-off-by: ruanjinjie
---
drivers/soc/fsl/dpio/dpio-driver.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/soc/fsl/dpio/dpio-driver.c
b/drivers/soc/fsl/dpio/dpio-driver.c
index
Add missing __init/__exit annotations to module init/exit funcs
Signed-off-by: ruanjinjie
---
drivers/soc/fsl/dpio/dpio-driver.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/soc/fsl/dpio/dpio-driver.c
b/drivers/soc/fsl/dpio/dpio-driver.c
index
Christophe Leroy writes:
> Hi Dmitry
>
> Le 25/09/2022 à 07:06, Dmitry Torokhov a écrit :
>> Hi Michael, Nick,
>>
>> I was wondering if PIKA Warp board still relevant. The reason for my
>> question is that I am interested in dropping legacy gpio APIs,
>> especially OF-specific ones, in favor of
On Monday 26 September 2022 10:17:26 Christophe Leroy wrote:
> Le 26/09/2022 à 11:53, Pali Rohár a écrit :
> > On Monday 26 September 2022 09:48:02 Christophe Leroy wrote:
> >> Le 19/08/2022 à 21:15, Pali Rohár a écrit :
> >>> This moves machine descriptions and all related code for all P2020
On Monday 26 September 2022 10:10:19 Christophe Leroy wrote:
> Le 19/08/2022 à 21:15, Pali Rohár a écrit :
> > "fsl,P2020RDB-PC" compatible string was present in Turris 1.x DTS file just
> > because Linux kernel required it for proper detection of P2020 processor
> > during boot.
> >
> > This was
On Monday 26 September 2022 10:08:19 Christophe Leroy wrote:
> Le 19/08/2022 à 21:15, Pali Rohár a écrit :
> > Generic unified P2020 machine description which supports all P2020-based
> > boards is now in separate file p2020.c. So create a separate config option
> > CONFIG_P2020 for it.
>
> Could
Le 26/09/2022 à 11:53, Pali Rohár a écrit :
> On Monday 26 September 2022 09:48:02 Christophe Leroy wrote:
>> Le 19/08/2022 à 21:15, Pali Rohár a écrit :
>>> This moves machine descriptions and all related code for all P2020 boards
>>> into new p2020.c source file. This is preparation for code
Le 19/08/2022 à 21:15, Pali Rohár a écrit :
> "fsl,P2020RDB-PC" compatible string was present in Turris 1.x DTS file just
> because Linux kernel required it for proper detection of P2020 processor
> during boot.
>
> This was quite a hack as CZ,NIC Turris 1.x is not compatible with
> Freescale
On Monday 26 September 2022 10:02:47 Christophe Leroy wrote:
> > +static int __init p2020_probe(void)
> > {
> > - if (of_machine_is_compatible("fsl,P2020RDB-PC"))
> > - return 1;
> > - return 0;
> > + struct device_node *p2020_cpu;
> > +
> > + /*
> > +* There is no common
Le 19/08/2022 à 21:15, Pali Rohár a écrit :
> Generic unified P2020 machine description which supports all P2020-based
> boards is now in separate file p2020.c. So create a separate config option
> CONFIG_P2020 for it.
Could it be CONFIG_PPC_P2020 instead ? Nowadays, drivers seems to spread
Le 19/08/2022 à 21:15, Pali Rohár a écrit :
> Combine machine descriptions and code of all P2020 boards into just one
> generic unified P2020 machine description. This allows kernel to boot on
> any P2020-based board with P2020 DTS file without need to patch kernel and
> define a new machine
Le 19/08/2022 à 21:15, Pali Rohár a écrit :
> Make just one .setup_arch and one .init_IRQ callback implementation for all
> P2020 board code. This deduplicate repeated and same code.
I think this patch should be split in two parts:
First patch : Create function mpc85xx_8259_init
Second patch :
On Monday 26 September 2022 09:48:02 Christophe Leroy wrote:
> Le 19/08/2022 à 21:15, Pali Rohár a écrit :
> > This moves machine descriptions and all related code for all P2020 boards
> > into new p2020.c source file. This is preparation for code deduplication
> > and providing one unified
Le 19/08/2022 à 21:15, Pali Rohár a écrit :
> This moves machine descriptions and all related code for all P2020 boards
> into new p2020.c source file. This is preparation for code deduplication
> and providing one unified machine description for all P2020 boards.
I'm having hard time to review
On Monday 26 September 2022 09:43:55 Christophe Leroy wrote:
> Le 19/08/2022 à 21:15, Pali Rohár a écrit :
> > Function mpc85xx_ds_pic_init() is not used out of the mpc85xx_ds.c file.
> >
> > Signed-off-by: Pali Rohár
>
> This patch should be squashed into patch 1.
No problem. Just to explain
Le 19/08/2022 à 21:15, Pali Rohár a écrit :
> Function mpc85xx_ds_pic_init() is not used out of the mpc85xx_ds.c file.
>
> Signed-off-by: Pali Rohár
This patch should be squashed into patch 1.
> ---
> arch/powerpc/platforms/85xx/mpc85xx_ds.c | 2 +-
> 1 file changed, 1 insertion(+), 1
On Mon Sep 26, 2022 at 4:18 PM AEST, Ganesh Goudar wrote:
> Part of machine check error handling is done in realmode,
> As of now instrumentation is not possible for any code that
> runs in realmode.
> When MCE is injected on KASAN enabled kernel, crash is
> observed, Hence force inline or mark no
kindly ping
在 2022/9/14 11:26, Lin Yujun 写道:
Use platform_device_put() to free the platform device and return
directly in the event platform_device_add() fails.
Fixes: a28d3af2a26c ("[PATCH] 2/5 powerpc: Rework PowerMac i2c part 2")
Signed-off-by: Lin Yujun
---
> On 26-Sep-2022, at 11:48 AM, Ganesh Goudar wrote:
>
> Part of machine check error handling is done in realmode,
> As of now instrumentation is not possible for any code that
> runs in realmode.
> When MCE is injected on KASAN enabled kernel, crash is
> observed, Hence force inline or mark
From: Nicholas Piggin
> Sent: 23 September 2022 16:42
>
> WARN_ONCE and similar are often used in frequently executed code, and
> should not crash the system. The program check interrupt caused by
> WARN_ON_ONCE can be a significant overhead even when nothing is being
> printed. This can cause
From: Christophe Leroy
debug_pagealloc_enabled() is always defined and constant folds to
'false' when CONFIG_DEBUG_PAGEALLOC is not enabled.
Remove the #ifdefs, the code and associated static variables will
be optimised out by the compiler when CONFIG_DEBUG_PAGEALLOC is
not defined.
KFENCE support was added for ppc32 in commit 90cbac0e995d
("powerpc: Enable KFENCE for PPC32").
Enable KFENCE on ppc64 architecture with hash and radix MMUs.
It uses the same mechanism as debug pagealloc to
protect/unprotect pages. All KFENCE kunit tests pass on both
MMUs.
KFENCE memory is
From: Christophe Leroy
If the page is already mapped resp. already unmapped, bail out.
Signed-off-by: Christophe Leroy
Signed-off-by: Nicholas Miehlbradt
---
arch/powerpc/mm/book3s64/hash_utils.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git
There is support for DEBUG_PAGEALLOC on hash but not on radix.
Add support on radix.
Signed-off-by: Nicholas Miehlbradt
---
v2: Revert change to radix_memory_block_size, instead set the size
in radix_init_pgtable and radix__create_section_mapping directly.
v3: Remove max_mapping_size argument of
David Hildenbrand writes:
>>> +Use WARN_ON_ONCE() rather than WARN() or WARN_ON()
>>> +**
>>> +
>>> +WARN_ON_ONCE() is generally preferred over WARN() or WARN_ON(), because it
>>> +is common for a given warning condition, if it occurs at all, to
On Mon, Sep 26, 2022 at 08:47:32AM +0200, Greg Kroah-Hartman wrote:
> On Sat, Sep 24, 2022 at 01:55:23PM +0200, Michal Suchánek wrote:
> > On Sat, Sep 24, 2022 at 12:13:34PM +0200, Greg Kroah-Hartman wrote:
> > > On Sat, Sep 24, 2022 at 11:45:21AM +0200, Michal Suchánek wrote:
> > > > On Sat, Sep
On Sat, Sep 24, 2022 at 01:55:23PM +0200, Michal Suchánek wrote:
> On Sat, Sep 24, 2022 at 12:13:34PM +0200, Greg Kroah-Hartman wrote:
> > On Sat, Sep 24, 2022 at 11:45:21AM +0200, Michal Suchánek wrote:
> > > On Sat, Sep 24, 2022 at 11:19:19AM +0200, Greg Kroah-Hartman wrote:
> > > > On Fri, Sep
Implement static call support for 64 bit V2 ABI. This requires
making sure the TOC is kept correct across kernel-module
boundaries. As a secondary concern, it tries to use the local
entry point of a target wherever possible. It does so by
checking if both tramp & target are kernel code, and falls
The callee may set a field in `st_other` to 1 to indicate r2 should be
treated as caller-saved. This means a trampoline must be used to save
the current TOC before calling it and restore it afterwards, much like
external calls.
This is necessary for supporting V2 ABI static calls that do not
These tests are out-of-line only, so moving them to the
their own file allows them to be run when an arch does
not implement inline static calls.
Signed-off-by: Benjamin Gray
---
kernel/Makefile | 1 +
kernel/static_call_inline.c | 43 ---
KUnit tests for the various combinations of caller/trampoline/target and
kernel/module. They must be run from a module loaded at runtime to
guarantee they have a different TOC to the kernel.
The tests try to mitigate the chance of panicing by restoring the
TOC after every static call. Not all
Inserts a direct branch to the stub target when possible, replacing the
mtctr/btctr sequence.
The load into r12 could potentially be skipped too, but that change
would need to refactor the arguments to indicate that the address
does not have a separate local entry point.
This helps the static
Adds a generic text patching mechanism for patches of 1, 2, 4, or (64-bit) 8
bytes. The patcher conditionally syncs the icache depending on if
the content will be executed (as opposed to, e.g., read-only data).
The `patch_instruction` function is reimplemented in terms of this
more generic
Implementation of out-of-line static calls for PowerPC 64-bit ELF V2 ABI.
Static calls patch an indirect branch into a direct branch at runtime.
Out-of-line specifically has a caller directly call a trampoline, and
the trampoline gets patched to directly call the target.
Previous version here:
Hi Dmitry
Le 25/09/2022 à 07:06, Dmitry Torokhov a écrit :
> Hi Michael, Nick,
>
> I was wondering if PIKA Warp board still relevant. The reason for my
> question is that I am interested in dropping legacy gpio APIs,
> especially OF-specific ones, in favor of newer gpiod APIs, and
>
Part of machine check error handling is done in realmode,
As of now instrumentation is not possible for any code that
runs in realmode.
When MCE is injected on KASAN enabled kernel, crash is
observed, Hence force inline or mark no instrumentation
for functions which can run in realmode, to avoid
On Mon, 19 Sept 2022 at 05:28, Michael Ellerman wrote:
>
> The original microwatt submission[1] included some early debug code for
> using the Microwatt "potato" UART.
The potato is indeed dead.
>
> The series that was eventually merged switched to using a standard UART,
> and so doesn't need
Signed-off-by: Alistair Popple
---
lib/test_hmm.c | 119 +-
lib/test_hmm_uapi.h| 1 +-
tools/testing/selftests/vm/hmm-tests.c | 49 +++-
3 files changed, 148 insertions(+), 21 deletions(-)
diff --git a/lib/test_hmm.c
When the module is unloaded or a GPU is unbound from the module it is
possible for device private pages to be left mapped in currently running
processes. This leads to a kernel crash when the pages are either freed
or accessed from the CPU because the GPU and associated data structures
and
nouveau_dmem_fault_copy_one() is used during handling of CPU faults via
the migrate_to_ram() callback and is used to copy data from GPU to CPU
memory. It is currently specific to fault handling, however a future
patch implementing eviction of data during teardown needs similar
functionality.
1 - 100 of 107 matches
Mail list logo
