Le 02/07/2021 à 03:25, Nicholas Piggin a écrit :
Excerpts from Christophe Leroy's message of July 1, 2021 9:17 pm:
The powerpc kernel is not prepared to handle exec faults from kernel.
Especially, the function is_exec_fault() will return 'false' when an
exec fault is taken by kernel, because
Reset_link() callback function (named with reset_subordinates()
in pcie_do_recovery() function) was called before mmio_enabled(),
so exchange the sequence between step 2 MMIO Enabled and step 3
Link Reset accordingly.
Signed-off-by: Wesley Sheng
---
Documentation/PCI/pci-error-recovery.rst | 25
pecific files
for 20210701
# good: [62fb9874f5da54fdb243003b386128037319b219] Linux 5.13
git bisect start 'HEAD' 'v5.13'
# bad: [f63c4fda987a19b1194cc45cb72fd5bf968d9d90] Merge remote-tracking branch
'rdma/for-next'
git bisect bad f63c4fda987a19b1194cc45cb72fd5bf968d9d90
#
On Thu, Jul 01, 2021 at 05:22:31PM -0500, Bjorn Helgaas wrote:
> Please make the subject a little more specific. "rearrange the
> general sequence" doesn't say anything about what was affected.
>
> On Fri, Jun 18, 2021 at 02:04:46PM +0800, Wesley Sheng wrote:
> > Reset_link() callback function wa
10630
i386 randconfig-a016-20210630
i386 randconfig-a012-20210630
i386 randconfig-a013-20210630
i386 randconfig-a015-20210630
i386 randconfig-a015-20210701
i386 randconfig-a016-20210701
i386 randconfig-a01
10630
i386 randconfig-a015-20210701
i386 randconfig-a016-20210701
i386 randconfig-a011-20210701
i386 randconfig-a012-20210701
i386 randconfig-a013-20210701
i386 randconfig-a014-20210701
i386 randc
Excerpts from Christophe Leroy's message of July 1, 2021 9:17 pm:
> The powerpc kernel is not prepared to handle exec faults from kernel.
> Especially, the function is_exec_fault() will return 'false' when an
> exec fault is taken by kernel, because the check is based on reading
> current->thread.r
Hi Jason,
> The BUG_ON macro simplifies the if condition followed by BUG, so that
> we can use BUG_ON instead of if condition followed by BUG.
[...]
> - if (spu_acquire(ctx))
> - BUG(); /* a kernel thread never has signals pending */
> + /* a kernel thread never has si
Excerpts from Madhavan Srinivasan's message of July 1, 2021 11:17 pm:
>
> On 6/22/21 4:27 PM, Nicholas Piggin wrote:
>> KVM PMU management code looks for particular frozen/disabled bits in
>> the PMU registers so it knows whether it must clear them when coming
>> out of a guest or not. Setting thi
This can be used by the newly-added nintendo-otp nvmem module.
Signed-off-by: Emmanuel Gil Peyrot
---
arch/powerpc/boot/dts/wii.dts | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/boot/dts/wii.dts b/arch/powerpc/boot/dts/wii.dts
index c5fb54f8cc02..e9c94
This selects the nintendo-otp module when building for this platform.
Signed-off-by: Emmanuel Gil Peyrot
---
arch/powerpc/configs/wii_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/configs/wii_defconfig
b/arch/powerpc/configs/wii_defconfig
index 379c171f3ddd..a0c45bf
This is wrong, but needed in order to avoid overlapping ranges with the
OTP area added in the next commit. A refactor of this part of the
device tree is needed: according to Wiibrew[1], this area starts at
0x0d80 and spans 0x400 bytes (that is, 0x100 32-bit registers),
encompassing PIC and GPI
Both of these consoles use the exact same two registers, even at the
same address, but the Wii U has eight banks of 128 bytes memory while
the Wii only has one, hence the two compatible strings.
Signed-off-by: Emmanuel Gil Peyrot
---
.../bindings/nvmem/nintendo-otp.yaml | 44 +++
This OTP is read-only and contains various keys used by the console to
decrypt, encrypt or verify various pieces of storage.
Its size depends on the console, it is 128 bytes on the Wii and
1024 bytes on the Wii U (split into eight 128 bytes banks).
It can be used directly by writing into one regi
The OTP is a read-only memory area which contains various keys and
signatures used to decrypt, encrypt or verify various pieces of storage.
Its size depends on the console, it is 128 bytes on the Wii and
1024 bytes on the Wii U (split into eight 128 bytes banks).
It can be used directly by writin
Please make the subject a little more specific. "rearrange the
general sequence" doesn't say anything about what was affected.
On Fri, Jun 18, 2021 at 02:04:46PM +0800, Wesley Sheng wrote:
> Reset_link() callback function was called before mmio_enabled() in
> pcie_do_recovery() function actually,
On Sat, Jun 26, 2021 at 11:34:01PM +, Jonathan Neuschäfer wrote:
> On Wed, May 19, 2021 at 11:50:43AM +0200, Emmanuel Gil Peyrot wrote:
> > This can be used by the newly-added nintendo-otp nvmem module.
> >
> > Signed-off-by: Emmanuel Gil Peyrot
> > ---
> > arch/powerpc/boot/dts/wii.dts | 5
Christophe Leroy wrote:
Le 01/07/2021 à 17:08, Naveen N. Rao a écrit :
Commit 91c960b0056672 ("bpf: Rename BPF_XADD and prepare to encode other
atomics in .imm") converted BPF_XADD to BPF_ATOMIC and updated all JIT
implementations to reject JIT'ing instructions with an immediate value
differen
On Thu, Jul 1, 2021 at 12:32 PM Naveen N. Rao
wrote:
>
> Alexei Starovoitov wrote:
> > On Thu, Jul 1, 2021 at 8:09 AM Naveen N. Rao
> > wrote:
> >>
> >> Commit 91c960b0056672 ("bpf: Rename BPF_XADD and prepare to encode other
> >> atomics in .imm") converted BPF_XADD to BPF_ATOMIC and added a way
Alexei Starovoitov wrote:
On Thu, Jul 1, 2021 at 8:09 AM Naveen N. Rao
wrote:
Commit 91c960b0056672 ("bpf: Rename BPF_XADD and prepare to encode other
atomics in .imm") converted BPF_XADD to BPF_ATOMIC and added a way to
distinguish instructions based on the immediate field. Existing JIT
imple
Le 01/07/2021 à 17:08, Naveen N. Rao a écrit :
Commit 91c960b0056672 ("bpf: Rename BPF_XADD and prepare to encode other
atomics in .imm") converted BPF_XADD to BPF_ATOMIC and updated all JIT
implementations to reject JIT'ing instructions with an immediate value
different from BPF_ADD. However,
On Thu, Jul 1, 2021 at 8:09 AM Naveen N. Rao
wrote:
>
> Commit 91c960b0056672 ("bpf: Rename BPF_XADD and prepare to encode other
> atomics in .imm") converted BPF_XADD to BPF_ATOMIC and added a way to
> distinguish instructions based on the immediate field. Existing JIT
> implementations were upda
This is a smatch warning:
arch/powerpc/sysdev/xive/common.c:1161 xive_request_ipi() warn: unsigned
'xid->irq' is never less than zero.
Fixes: fd6db2892eba ("powerpc/xive: Modernize XIVE-IPI domain with an 'alloc'
handler")
Cc: sta...@vger.kernel.org # v5.13
Reported-by: kernel test robot
Sig
Commit 91c960b0056672 ("bpf: Rename BPF_XADD and prepare to encode other
atomics in .imm") converted BPF_XADD to BPF_ATOMIC and updated all JIT
implementations to reject JIT'ing instructions with an immediate value
different from BPF_ADD. However, ppc32 BPF JIT was implemented around
the same time
Commit 91c960b0056672 ("bpf: Rename BPF_XADD and prepare to encode other
atomics in .imm") converted BPF_XADD to BPF_ATOMIC and added a way to
distinguish instructions based on the immediate field. Existing JIT
implementations were updated to check for the immediate field and to
reject programs uti
The first patch fixes an issue that causes a soft lockup on ppc64 with
the BPF_ATOMIC bounds propagation verifier test. The second one updates
ppc32 JIT to reject atomic operations properly.
- Naveen
Naveen N. Rao (2):
powerpc/bpf: Fix detecting BPF atomic instructions
powerpc/bpf: Reject a
On 01/07/21 09:45, Srikar Dronamraju wrote:
> @@ -1891,12 +1894,30 @@ void sched_init_numa(void)
> void sched_domains_numa_masks_set(unsigned int cpu)
> {
> int node = cpu_to_node(cpu);
> - int i, j;
> + int i, j, empty;
>
> + empty = cpumask_empty(sched_domains_numa_masks[0][no
The BUG_ON macro simplifies the if condition followed by BUG, so that
we can use BUG_ON instead of if condition followed by BUG.
Signed-off-by: Jason Wang
---
arch/powerpc/platforms/cell/spufs/sched.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/
On Thu, Jul 1, 2021 at 2:57 PM Christophe Leroy
wrote:
> Le 01/07/2021 à 14:50, Jason Wang a écrit :
> > The BUG_ON macro simplifies the if condition followed by BUG, but it
> > will lead to the kernel crashing. Therefore, we can try using WARN_ON
> > instead of if condition followed by BUG.
>
> B
The PowerNV and pSeries platforms now have support for both the XICS
and XIVE IRQ domains.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/platforms/powernv/pci-ioda.c | 4 +---
arch/powerpc/platforms/pseries/msi.c | 4
2 files changed, 1 insertion(+), 7 deletions(-)
diff --git a/arc
PCI MSIs now live in an MSI domain but the underlying calls, which
will EOI the interrupt in real mode, need an HW IRQ number mapped in
the XICS IRQ domain. Grab it there.
Cc: Alexey Kardashevskiy
Signed-off-by: Cédric Le Goater
---
arch/powerpc/kvm/book3s_hv.c | 12 ++--
1 file changed
The default domain of the PCI/MSIs is not the XIVE domain anymore. To
list the IRQ mappings under XMON and debugfs, query the IRQ data from
the low level XIVE domain.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/sysdev/xive/common.c | 11 +--
1 file changed, 5 insertions(+), 6 deleti
Before MSI domains, the default IRQ chip of PHB3 MSIs was patched by
pnv_set_msi_irq_chip() with the custom EOI handler pnv_ioda2_msi_eoi()
and the owning PHB was deduced from the 'ioda.irq_chip' field. This
path has been deprecated by the MSI domains but it is still in use by
the P8 CAPI 'cxl' dri
The HW IRQ numbers generated by the PCI MSI layer can be quite large
on a pSeries machine when running under the IBM Hypervisor and they
appear as negative. Use '%lu' instead to show them correctly.
Cc: Thomas Gleixner
Signed-off-by: Cédric Le Goater
---
kernel/irq/irqdesc.c | 2 +-
kernel/irq/
PCI MSI interrupt numbers are now mapped in a PCI-MSI domain but the
underlying calls handling the passthrough of the interrupt in the
guest need a number in the XIVE IRQ domain.
Use the IRQ data mapped in the XIVE IRQ domain and not the one in the
PCI-MSI domain.
Cc: Thomas Gleixner
Signed-off-
This moves the IRQ initialization done under the different ICS backends
in the common part of XICS. The 'map' handler becomes a simple 'check'
on the HW IRQ at the FW level.
As we don't need an ICS anymore in xics_migrate_irqs_away(), the XICS
domain does not set a chip data for the IRQ.
Signed-o
XICS doesn't have any state associated with the IRQ. The support is
straightforward and simpler than for XIVE.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/sysdev/xics/xics-common.c | 41 ++
1 file changed, 41 insertions(+)
diff --git a/arch/powerpc/sysdev/xics/xics-
It really helps to know how the HW is configured when tweaking the IRQ
subsystem.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/sysdev/xics/ics-opal.c | 2 +-
arch/powerpc/sysdev/xics/ics-rtas.c | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/sysdev/xics/ic
pnv_opal_pci_msi_eoi() is called from KVM to EOI passthrough interrupts
when in real mode. Adding MSI domain broke the hack using the
'ioda.irq_chip' field to deduce the owning PHB. Fix that by using the
IRQ chip data in the MSI domain.
The 'ioda.irq_chip' field is now unused and could be removed
MSIs should be fully managed by the PCI and IRQ subsystems now.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/platforms/powernv/pci.h | 6 --
arch/powerpc/platforms/powernv/pci-ioda.c | 27 -
arch/powerpc/platforms/powernv/pci.c | 67 ---
3 files changed
The MSI domain clears the IRQ with msi_domain_free(), which calls
irq_domain_free_irqs_top(), which clears the handler data. This is a
problem for the XIVE controller since we need to unmap MMIO pages and
free a specific XIVE structure.
The 'msi_free()' handler is called before irq_domain_free_irq
desc->irq_data points to the top level IRQ data descriptor which is
not necessarily in the XICS IRQ domain. MSIs are in another domain for
instance. Fix that by looking for a mapping on the low level XICS IRQ
domain.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/sysdev/xics/xics-common.c | 9
The routine kvmppc_set_passthru_irq() calls kvmppc_xive_set_mapped()
and kvmppc_xive_clr_mapped() with an IRQ descriptor. Use directly the
host IRQ number to remove a useless conversion.
Add some debug.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/include/asm/kvm_ppc.h | 4 ++--
arch/power
The pnv_ioda2_msi_eoi() chip handler is not used anymore for MSIs.
Simply use the check on the PSI-MSI chip.
Cc: Alexey Kardashevskiy
Signed-off-by: Cédric Le Goater
---
arch/powerpc/platforms/powernv/pci-ioda.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/pl
That was a workaround in the XICS domain because of the lack of MSI
domain. This is now handled.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/sysdev/xics/ics-opal.c | 11 ---
arch/powerpc/sysdev/xics/ics-rtas.c | 9 -
2 files changed, 20 deletions(-)
diff --git a/arch/power
This adds handlers to allocate/free IRQs in a domain hierarchy. We
could try to use xive_irq_domain_map() in xive_irq_domain_alloc() but
we rely on xive_irq_alloc_data() to set the IRQ handler data and
duplicating the code is simpler.
xive_irq_free_data() needs to be called when IRQ are freed to c
MSIs should be fully managed by the PCI and IRQ subsystems now.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/platforms/pseries/msi.c | 87
1 file changed, 87 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/msi.c
b/arch/powerpc/platforms/pseries/msi.c
i
Simply allocate or release the MSI domains when a PHB is inserted in
or removed from the machine.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/platforms/pseries/pseries.h | 1 +
arch/powerpc/platforms/pseries/msi.c | 10 ++
arch/powerpc/platforms/pseries/pci_dlpar.c | 4 +++
That was a workaround in the XIVE domain because of the lack of MSI
domain. This is now handled.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/sysdev/xive/common.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/arch/powerpc/sysdev/xive/common.c
b/arch/powerpc/sysdev/xive/comm
PHB3s need an extra OPAL call to EOI the interrupt. The call takes an
OPAL HW IRQ number but it is translated into a vector number in OPAL.
Here, we directly use the vector number of the in-the-middle "PNV-MSI"
domain instead of grabbing the OPAL HW IRQ number in the XICS parent
domain.
Signed-off
and clean up the error path.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/sysdev/xics/xics-common.c | 21 +
1 file changed, 17 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/sysdev/xics/xics-common.c
b/arch/powerpc/sysdev/xics/xics-common.c
index 399dd5becf65..
We always had only one ICS per machine. Simplify the XICS driver by
removing the ICS list.
The ICS stored in the chip data of the XICS domain becomes useless and
we don't need it anymore to migrate away IRQs from a CPU. This will be
removed in a subsequent patch.
Signed-off-by: Cédric Le Goater
This splits the routine setting the MSIs in two parts: allocation of
MSIs for the PCI device at the FW level (RTAS) and the actual mapping
and activation of the IRQs.
rtas_prepare_msi_irqs() will serve as a handler for the PCI MSI domain.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/platfor
Passthrough PCI MSI interrupts are detected in KVM with a check on a
specific EOI handler (P8) or on XIVE (P9). We can now check the
PCI-MSI IRQ chip which is cleaner.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/kvm/book3s_hv.c | 2 +-
arch/powerpc/platforms/powernv/pci-ioda.c
This is very similar to the MSI domains of the pSeries platform. The
MSI allocator is directly handled under the Linux PHB in the
in-the-middle "PNV-MSI" domain.
Only the XIVE (P9/P10) parent domain is supported for now. Support for
XICS will come later.
Signed-off-by: Cédric Le Goater
---
arch
It will be used as a 'compose_msg' handler of the MSI domain introduced
later.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/platforms/powernv/pci-ioda.c | 28 +++
1 file changed, 23 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/a
It will help to size the PCI MSI domain.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/platforms/pseries/msi.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/msi.c
b/arch/powerpc/platforms/pseries/msi.c
index 637300330507..d2d090e0
The RTAS firmware can not disable one MSI at a time. It's all or
nothing. We need a custom free IRQ handler for that.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/platforms/pseries/msi.c | 16
1 file changed, 16 insertions(+)
diff --git a/arch/powerpc/platforms/pseries/msi.
Hello,
This series adds support for MSI IRQ domains on top of the XICS (P8)
and XIVE (P9/P10) IRQ domains for the PowerNV (baremetal) and pSeries
(VM) platforms. It should simplify and improve IRQ affinity of PCI
MSIs under these PowerPC platforms, specially for drivers distributing
multiple RX/TX
Two IRQ domains are added on top of default machine IRQ domain.
First, the top level "pSeries-PCI-MSI" domain deals with the MSI
specificities. In this domain, the HW IRQ numbers are generated by the
PCI MSI layer, they compose a unique ID for an MSI source with the PCI
device identifier and the M
pr_debug() is easier to activate and it helps to know how the kernel
configures the HW when tweaking the IRQ subsystem.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/sysdev/xive/common.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/sysdev/xive/common.c
In the early days of XIVE support, commit cffb717ceb8e ("powerpc/xive:
Ensure active irqd when setting affinity") tried to fix an issue
related to interrupt migration. If the root cause was related to CPU
unplug, it should have been fixed and there is no reason to keep the
irqd_is_started() check.
On 6/22/21 4:27 PM, Nicholas Piggin wrote:
KVM PMU management code looks for particular frozen/disabled bits in
the PMU registers so it knows whether it must clear them when coming
out of a guest or not. Setting this up helps KVM make these optimisations
without getting confused. Longer term th
Le 01/07/2021 à 14:50, Jason Wang a écrit :
The BUG_ON macro simplifies the if condition followed by BUG, but it
will lead to the kernel crashing. Therefore, we can try using WARN_ON
instead of if condition followed by BUG.
But are you sure it is ok to continue if spu_acquire(ctx) returned f
The BUG_ON macro simplifies the if condition followed by BUG, but it
will lead to the kernel crashing. Therefore, we can try using WARN_ON
instead of if condition followed by BUG.
Signed-off-by: Jason Wang
---
arch/powerpc/platforms/cell/spufs/sched.c | 4 ++--
1 file changed, 2 insertions(+), 2
Commit 9b69d48c7516 ("powerpc/64e: remove implicit soft-masking and
interrupt exit restart logic") limited the implicit soft masking and
restart logic to 64-bit Book3S only. However we are still building
restart_table.c for all 64-bit, ie. Book3E also.
There's no need to build it for 64e, and it a
The ARRAY_SIZE macro is more compact and formal to get array size in
linux kernel source. In addition, it is more readable for kernel
developpers. Thus, we can replace all sizeof(arr)/sizeof(arr[0]) with
ARRAY_SIZE.
Signed-off-by: Jason Wang
---
arch/powerpc/xmon/ppc-opc.c | 16 ++--
Excerpts from Nicholas Piggin's message of July 1, 2021 5:37 pm:
> Excerpts from Christopher M. Riedl's message of July 1, 2021 4:53 pm:
>> On Thu Jul 1, 2021 at 1:04 AM CDT, Nicholas Piggin wrote:
>>> Excerpts from Christopher M. Riedl's message of July 1, 2021 3:28 pm:
>>> > On Wed Jun 30, 2021 a
The powerpc kernel is not prepared to handle exec faults from kernel.
Especially, the function is_exec_fault() will return 'false' when an
exec fault is taken by kernel, because the check is based on reading
current->thread.regs->trap which contains the trap from user.
For instance, when provoking
cpu_cpu_map holds all the CPUs in the DIE. However in PowerPC, when
onlining/offlining of CPUs, this mask doesn't get updated. This mask
is however updated when CPUs are added/removed. So when both
operations like online/offline of CPUs and adding/removing of CPUs are
done simultaneously, then cpu
Currently, a debug message gets printed every time an attempt to
add(remove) a CPU. However this is redundant if the CPU is already added
(removed) from the node.
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Nathan Lynch
Cc: Michael Ellerman
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Valentin Schneider
When simultaneously running CPU online/offline with CPU add/remove in a
loop, we see a WARNING messages.
WARNING: CPU: 13 PID: 1142 at kernel/sched/topology.c:898
build_sched_domains+0xd48/0x1720
Modules linked in: rpadlpar_io rpaphp mptcp_diag xsk_diag tcp_diag udp_diag
raw_diag inet_diag unix_d
Hi Michael,
Do you mind taking this patch of 5.14?
Thanks,
Laurent.
Le 17/05/2021 à 11:06, Laurent Dufour a écrit :
After a LPM, the device tree node ibm,dynamic-reconfiguration-memory may be
updated by the hypervisor in the case the NUMA topology of the LPAR's
memory is updated.
This is hand
Hi Michael,
Do you mind taking this patch of 5.14?
Thanks,
Laurent.
Le 11/05/2021 à 09:31, Laurent Dufour a écrit :
When a LPAR is migratable, we should consider the maximum possible NUMA
node instead the number of NUMA node from the actual system.
The DT property 'ibm,current-associativity-d
Hi Michael,
Do you mind taking this patch of 5.14?
Thanks,
Laurent.
Le 29/04/2021 à 19:49, Laurent Dufour a écrit :
When a CPU is hot added, the CPU ids are taken from the available mask from
the lower possible set. If that set of values was previously used for CPU
attached to a different node
Excerpts from Fabiano Rosas's message of July 1, 2021 3:51 am:
> Nicholas Piggin writes:
>
>> Some of the DAWR SPR access is already predicated on dawr_enabled(),
>> apply this to the remainder of the accesses.
>>
>> Signed-off-by: Nicholas Piggin
>> ---
>> arch/powerpc/kvm/book3s_hv_p9_entry.c
Excerpts from Christopher M. Riedl's message of July 1, 2021 5:02 pm:
> On Thu Jul 1, 2021 at 1:12 AM CDT, Nicholas Piggin wrote:
>> Excerpts from Christopher M. Riedl's message of May 6, 2021 2:34 pm:
>> > When code patching a STRICT_KERNEL_RWX kernel the page containing the
>> > address to be pat
On Wed, Jun 30, 2021 at 08:56:51AM -0700, Nathan Chancellor wrote:
> On Wed, Jun 30, 2021 at 12:43:48PM +0100, Will Deacon wrote:
> > On Wed, Jun 30, 2021 at 05:17:27PM +0800, Claire Chang wrote:
> > > `BUG: unable to handle page fault for address: 003a8290` and
> > > the fact it crashed at
Excerpts from Christopher M. Riedl's message of July 1, 2021 4:53 pm:
> On Thu Jul 1, 2021 at 1:04 AM CDT, Nicholas Piggin wrote:
>> Excerpts from Christopher M. Riedl's message of July 1, 2021 3:28 pm:
>> > On Wed Jun 30, 2021 at 11:15 PM CDT, Nicholas Piggin wrote:
>> >> Excerpts from Christopher
On Thu Jul 1, 2021 at 1:12 AM CDT, Nicholas Piggin wrote:
> Excerpts from Christopher M. Riedl's message of May 6, 2021 2:34 pm:
> > When code patching a STRICT_KERNEL_RWX kernel the page containing the
> > address to be patched is temporarily mapped as writeable. Currently, a
> > per-cpu vmalloc p
80 matches
Mail list logo
