* Re: [patch V3 34/35] soc: ti: ti_sci_inta_msi: Get rid of ti_sci_inta_msi_get_virq()
From: Nishanth Menon @ 2021-12-13 17:57 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Mark Rutland, Stuart Yoder, Will Deacon, Peter Ujfalusi,
Ashok Raj, Joerg Roedel, Jassi Brar, Sinan Kaya, iommu,
Bjorn Helgaas, linux-arm-kernel, Jason Gunthorpe, linux-pci,
xen-devel, Kevin Tian, Arnd Bergmann, Robin Murphy,
Alex Williamson, Cedric Le Goater, Santosh Shilimkar,
Bjorn Helgaas, Megha Dey, Laurentiu Tudor, Juergen Gross,
Tero Kristo, Greg Kroah-Hartman, LKML, Vinod Koul, Marc Zygnier,
dmaengine, linuxppc-dev
In-Reply-To: <20211210221815.269468319@linutronix.de>
On 23:19-20211210, Thomas Gleixner wrote:
> From: Thomas Gleixner <tglx@linutronix.de>
>
> Just use the core function msi_get_virq().
>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
> Cc: Peter Ujfalusi <peter.ujfalusi@gmail.com>
> Cc: Vinod Koul <vkoul@kernel.org>
> Cc: dmaengine@vger.kernel.org
Acked-by: Nishanth Menon <nm@ti.com>
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D)/Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
^ permalink raw reply
* Re: [PATCH v1 0/5] Implement livepatch on PPC32
From: Steven Rostedt @ 2021-12-13 18:54 UTC (permalink / raw)
To: Christophe Leroy
Cc: Petr Mladek, Joe Lawrence, linux-s390@vger.kernel.org,
Jiri Kosina, linux-kernel@vger.kernel.org, Ingo Molnar,
Josh Poimboeuf, live-patching@vger.kernel.org, Naveen N . Rao,
Miroslav Benes, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <fc3099b8-9f12-3e47-08a0-05abc37a0482@csgroup.eu>
On Mon, 13 Dec 2021 17:50:52 +0000
Christophe Leroy <christophe.leroy@csgroup.eu> wrote:
> @@ -958,6 +942,12 @@ unsigned long prepare_ftrace_return(unsigned long
> parent, unsigned long ip,
> out:
> return parent;
> }
> +
> +void ftrace_graph_func(unsigned long ip, unsigned long parent_ip,
> + struct ftrace_ops *op, struct ftrace_regs *fregs)
> +{
> + prepare_ftrace_return(ip, kernel_stack_pointer(&fregs->regs), 0);
> +}
I have for powerpc prepare_ftrace_return as:
unsigned long prepare_ftrace_return(unsigned long parent, unsigned long ip,
unsigned long sp)
{
unsigned long return_hooker;
if (unlikely(ftrace_graph_is_dead()))
goto out;
if (unlikely(atomic_read(¤t->tracing_graph_pause)))
goto out;
return_hooker = ppc_function_entry(return_to_handler);
if (!function_graph_enter(parent, ip, 0, (unsigned long *)sp))
parent = return_hooker;
out:
return parent;
}
Which means you'll need different parameters to it than what x86 has, which
has the prototype of:
void prepare_ftrace_return(unsigned long ip, unsigned long *parent,
unsigned long frame_pointer)
and it does not use the frame_pointer for this case, which is why it is
zero.
For powerpc though, it uses the stack pointer, so you parameters are
incorrect. Looks like it should be:
prepare_ftrace_return(parent_ip, ip, kernel_stack_pointer(&fregs->regs));
And that will likely not be enough. I'll need to update the ctr register,
as that is where the return address is saved. So you'll probably need it to be:
void ftrace_graph_func(unsigned long ip, unsigned long parent_ip,
struct ftrace_ops *op, struct ftrace_regs *fregs)
{
unsigned long parent;
parent = prepare_ftrace_return(parent_ip, ip, kernel_stack_pointer(&fregs->regs));
fregs->regs.ctr = parent;
}
-- Steve
^ permalink raw reply
* Re: [patch V3 12/35] soc: ti: ti_sci_inta_msi: Allocate MSI device data on first use
From: Nishanth Menon @ 2021-12-13 17:56 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Mark Rutland, Stuart Yoder, Will Deacon, Ashok Raj, Joerg Roedel,
Jassi Brar, Sinan Kaya, iommu, Peter Ujfalusi, Bjorn Helgaas,
Megha Dey, Jason Gunthorpe, linux-pci, xen-devel, Kevin Tian,
Arnd Bergmann, Robin Murphy, Alex Williamson, Cedric Le Goater,
Santosh Shilimkar, Bjorn Helgaas, linux-arm-kernel,
Laurentiu Tudor, Juergen Gross, Tero Kristo, Greg Kroah-Hartman,
LKML, Vinod Koul, Marc Zygnier, dmaengine, linuxppc-dev
In-Reply-To: <20211210221813.928842960@linutronix.de>
On 23:19-20211210, Thomas Gleixner wrote:
> From: Thomas Gleixner <tglx@linutronix.de>
>
> Allocate the MSI device data on first invocation of the allocation function.
>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
> Cc: Nishanth Menon <nm@ti.com>
> Cc: Tero Kristo <kristo@kernel.org>
> Cc: Santosh Shilimkar <ssantosh@kernel.org>
> Cc: linux-arm-kernel@lists.infradead.org
Acked-by: Nishanth Menon <nm@ti.com>
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D)/Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
^ permalink raw reply
* Re: [patch V3 00/35] genirq/msi, PCI/MSI: Spring cleaning - Part 2
From: Nishanth Menon @ 2021-12-13 18:29 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Mark Rutland, Stuart Yoder, Will Deacon, Ashok Raj, Joerg Roedel,
Jassi Brar, Sinan Kaya, iommu, Peter Ujfalusi, Bjorn Helgaas,
linux-arm-kernel, Jason Gunthorpe, linux-pci, xen-devel,
Kevin Tian, Arnd Bergmann, Robin Murphy, Alex Williamson,
Cedric Le Goater, Santosh Shilimkar, Bjorn Helgaas, Megha Dey,
Laurentiu Tudor, Juergen Gross, Tero Kristo, Greg Kroah-Hartman,
LKML, Vinod Koul, Marc Zygnier, dmaengine, linuxppc-dev
In-Reply-To: <20211210221642.869015045@linutronix.de>
On 23:18-20211210, Thomas Gleixner wrote:
[...]
>
> It's also available from git:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git msi-v3-part-2
[...]
> ---
> drivers/dma/ti/k3-udma-private.c | 6
> drivers/dma/ti/k3-udma.c | 14 -
> drivers/irqchip/irq-ti-sci-inta.c | 2
> drivers/soc/ti/k3-ringacc.c | 6
> drivers/soc/ti/ti_sci_inta_msi.c | 22 --
> include/linux/soc/ti/ti_sci_inta_msi.h | 1
Also while testing on TI K3 platforms, I noticed:
msi_device_data_release/msi_device_destroy_sysfs in am64xx-evm / j7200
[1] https://gist.github.com/nmenon/36899c7819681026cfe1ef185fb95f33#file-am64xx-evm-txt-L1018
[2] https://gist.github.com/nmenon/36899c7819681026cfe1ef185fb95f33#file-j7200-evm-txt-L1076
Which is not present in vanilla v5.16-rc4
v5.16-rc4:
https://gist.github.com/nmenon/1aee3f0a7da47d5e9dcb7336b32a70cb
msi-v3-part-2:
https://gist.github.com/nmenon/36899c7819681026cfe1ef185fb95f33
(.config https://gist.github.com/nmenon/ec6f95303828abf16a64022d8e3a269f)
Vs:
next-20211208:
https://gist.github.com/nmenon/f5ca3558bd5c1fbe62dc5ceb420b536e
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D)/Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
^ permalink raw reply
* Re: [PATCH v2] of/fdt: Rework early_init_dt_scan_memory() to call directly
From: Rob Herring @ 2021-12-13 18:18 UTC (permalink / raw)
To: Michael Ellerman
Cc: devicetree, Thomas Bogendoerfer, linuxppc-dev, open list:MIPS,
linux-kernel@vger.kernel.org, Paul Mackerras, John Crispin,
Frank Rowand
In-Reply-To: <87fsqwn03o.fsf@mpe.ellerman.id.au>
On Mon, Dec 13, 2021 at 6:47 AM Michael Ellerman <mpe@ellerman.id.au> wrote:
>
> Rob Herring <robh@kernel.org> writes:
> > Use of the of_scan_flat_dt() function predates libfdt and is discouraged
> > as libfdt provides a nicer set of APIs. Rework
> > early_init_dt_scan_memory() to be called directly and use libfdt.
> ...
> > diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
> > index 6e1a106f02eb..63762a3b75e8 100644
> > --- a/arch/powerpc/kernel/prom.c
> > +++ b/arch/powerpc/kernel/prom.c
> > @@ -532,19 +532,19 @@ static int __init early_init_drmem_lmb(struct drmem_lmb *lmb,
> > }
> > #endif /* CONFIG_PPC_PSERIES */
> >
> > -static int __init early_init_dt_scan_memory_ppc(unsigned long node,
> > - const char *uname,
> > - int depth, void *data)
> > +static int __init early_init_dt_scan_memory_ppc(void)
> > {
> > #ifdef CONFIG_PPC_PSERIES
> > - if (depth == 1 &&
> > - strcmp(uname, "ibm,dynamic-reconfiguration-memory") == 0) {
> > + const void *fdt = initial_boot_params;
> > + int node = fdt_path_offset(fdt, "/ibm,dynamic-reconfiguration-memory");
> > +
> > + if (node > 0) {
> > walk_drmem_lmbs_early(node, NULL, early_init_drmem_lmb);
> > return 0;
> > }
> > #endif
> >
> > - return early_init_dt_scan_memory(node, uname, depth, data);
> > + return early_init_dt_scan_memory();
> > }
> >
> > /*
> > @@ -749,7 +749,7 @@ void __init early_init_devtree(void *params)
> >
> > /* Scan memory nodes and rebuild MEMBLOCKs */
> > early_init_dt_scan_root();
> > - of_scan_flat_dt(early_init_dt_scan_memory_ppc, NULL);
> > + early_init_dt_scan_memory_ppc();
> >
> > parse_early_param();
> >
> > @@ -858,7 +858,7 @@ void __init early_get_first_memblock_info(void *params, phys_addr_t *size)
> > */
> > add_mem_to_memblock = 0;
> > early_init_dt_scan_root();
> > - of_scan_flat_dt(early_init_dt_scan_memory_ppc, NULL);
> > + early_init_dt_scan_memory_ppc();
> > add_mem_to_memblock = 1;
> >
> > if (size)
>
>
> This blows up one of my machines with:
>
> [ 0.000000][ T0] printk: bootconsole [udbg0] enabled
> -> early_setup(), dt_ptr: 0x1ec90000
> [ 0.000000][ T0] ------------[ cut here ]------------
> [ 0.000000][ T0] kernel BUG at arch/powerpc/mm/book3s64/hash_utils.c:2117!
> [ 0.000000][ T0] Oops: Exception in kernel mode, sig: 5 [#1]
> [ 0.000000][ T0] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA
> [ 0.000000][ T0] Modules linked in:
> [ 0.000000][ T0] CPU: 0 PID: 0 Comm: swapper Not tainted 5.16.0-rc4-00073-g81291383ffde-dirty #69
> [ 0.000000][ T0] NIP: c0000000000924d8 LR: c000000002009764 CTR: c0000000000924d0
> [ 0.000000][ T0] REGS: c000000002833bc0 TRAP: 0700 Not tainted (5.16.0-rc4-00073-g81291383ffde-dirty)
> [ 0.000000][ T0] MSR: 8000000000021003 <SF,ME,RI,LE> CR: 24000244 XER: 20000001
> [ 0.000000][ T0] CFAR: 0000000000000730 IRQMASK: 1
> [ 0.000000][ T0] GPR00: c000000002009764 c000000002833e60 c000000002834100 ffffffffffffffff
> [ 0.000000][ T0] GPR04: 0000000000000000 c000000002080866 0000000000000000 0000000000000000
> [ 0.000000][ T0] GPR08: c000000002080864 0000000000000001 c0000000028d4100 c000000000ffe598
> [ 0.000000][ T0] GPR12: c0000000000924d0 c000000002082200 0000000000000000 0000000000000000
> [ 0.000000][ T0] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> [ 0.000000][ T0] GPR20: 0000000000000001 0000000010004604 0000000000000000 0000000010004bfc
> [ 0.000000][ T0] GPR24: 0000000000000000 c000000000000000 0000000002970000 c00000000008a480
> [ 0.000000][ T0] GPR28: c0000000028e19f8 c00000001ec90000 c000000002865af8 000000001ec90000
> [ 0.000000][ T0] NIP [c0000000000924d8] hash__setup_initial_memory_limit+0x18/0x110
> [ 0.000000][ T0] LR [c000000002009764] early_init_devtree+0x13c/0x4ec
> [ 0.000000][ T0] Call Trace:
> [ 0.000000][ T0] [c000000002833e60] [c0000000020096fc] early_init_devtree+0xd4/0x4ec (unreliable)
> [ 0.000000][ T0] [c000000002833f10] [c00000000200b008] early_setup+0xc8/0x22c
> [ 0.000000][ T0] [c000000002833f90] [000000000000d368] 0xd368
> [ 0.000000][ T0] Instruction dump:
> [ 0.000000][ T0] 4bffff0c eaa10028 4bffff44 60000000 60000000 60420000 3c4c027a 38421c40
> [ 0.000000][ T0] 7c0802a6 4bfe2e5d 3123ffff 7d291910 <0b090000> 3d220003 392919f8 e9290000
> [ 0.000000][ T0] random: get_random_bytes called from oops_exit+0x54/0xa0 with crng_init=0
> [ 0.000000][ T0] ---[ end trace 0000000000000000 ]---
>
>
> It's complaining about memstart_addr being 0, which implies
> early_init_dt_add_memory_arch() was never called.
The only thing I see is now there is an assumption that 'memory' nodes
are off the root node only. Before they could be anywhere. If that's
the issue, then we need something like this (untested and WS
corrupted):
index a835c458f50a..97d7607625ec 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -1083,16 +1083,13 @@ int __init early_init_dt_scan_memory(void)
int node;
const void *fdt = initial_boot_params;
- fdt_for_each_subnode(node, fdt, 0) {
- const char *type = of_get_flat_dt_prop(node,
"device_type", NULL);
+ for (node = fdt_node_offset_by_prop_value(fdt, -1,
"device_type", "memory", 6);
+ node != -FDT_ERR_NOTFOUND;
+ node = fdt_node_offset_by_prop_value(fdt, node,
"device_type", "memory", 6)) {
const __be32 *reg, *endp;
int l;
bool hotpluggable;
- /* We are scanning "memory" nodes only */
- if (type == NULL || strcmp(type, "memory") != 0)
- continue;
-
reg = of_get_flat_dt_prop(node, "linux,usable-memory", &l);
if (reg == NULL)
reg = of_get_flat_dt_prop(node, "reg", &l);
Rob
^ permalink raw reply related
* Re: [PATCH v2 2/6] powerpc/kexec_file: Add KEXEC_SIG support.
From: Michal Suchánek @ 2021-12-13 18:18 UTC (permalink / raw)
To: Nayna
Cc: Mimi Zohar, David Howells, keyrings, Paul Mackerras,
Alexander Gordeev, linux-s390, Herbert Xu, Baoquan He,
Christian Borntraeger, James Morris, Lakshmi Ramasubramanian,
Christian Borntraeger, Serge E. Hallyn, Vasily Gorbik,
Rob Herring, Heiko Carstens, linux-crypto, Dmitry Kasatkin,
Hari Bathini, Daniel Axtens, Philipp Rudo, Frank van der Linden,
kexec, linux-kernel, Luis Chamberlain, Sven Schnelle,
linux-security-module, Jessica Yu, linux-integrity, linuxppc-dev,
David S. Miller, Thiago Jung Bauermann, buendgen
In-Reply-To: <17153a1c-86c6-6ffd-35d6-5329829661df@linux.vnet.ibm.com>
Hello,
On Sun, Dec 12, 2021 at 07:46:53PM -0500, Nayna wrote:
>
> On 11/25/21 13:02, Michal Suchanek wrote:
> > Copy the code from s390x
> >
> > Signed-off-by: Michal Suchanek <msuchanek@suse.de>
> > ---
> > arch/powerpc/Kconfig | 11 +++++++++++
> > arch/powerpc/kexec/elf_64.c | 36 ++++++++++++++++++++++++++++++++++++
> > 2 files changed, 47 insertions(+)
> >
> > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> > index ac0c515552fd..ecc1227a77f1 100644
> > --- a/arch/powerpc/Kconfig
> > +++ b/arch/powerpc/Kconfig
> > @@ -561,6 +561,17 @@ config KEXEC_FILE
> > config ARCH_HAS_KEXEC_PURGATORY
> > def_bool KEXEC_FILE
> >
> > +config KEXEC_SIG
> > + bool "Verify kernel signature during kexec_file_load() syscall"
> > + depends on KEXEC_FILE && MODULE_SIG_FORMAT
> > + help
> > + This option makes kernel signature verification mandatory for
> > + the kexec_file_load() syscall.
> > +
>
> Resending my last response as looks like it didn't go through mailing list
> because of some wrong formatting. My apologies to those who are receiving it
> twice.
>
> Since powerpc also supports IMA_ARCH_POLICY for kernel image signature
> verification, please include the following:
>
> "An alternative implementation for the powerpc arch is IMA_ARCH_POLICY. It
> verifies the appended kernel image signature and additionally includes both
> the signed and unsigned file hashes in the IMA measurement list, extends the
> IMA PCR in the TPM, and prevents blacklisted binary kernel images from being
> kexec'd."
It also does blacklist based on the file hash?
There is a downstream patch that adds the support for the module
signatures, and when the code is reused for KEXEC_SIG the blacklist
also applies to it.
Which kind of shows that people really want to use the IMA features but
with no support on some major architectures it's not going to work.
Thanks
Michal
^ permalink raw reply
* Re: [patch V3 22/35] soc: ti: ti_sci_inta_msi: Use msi_desc::msi_index
From: Nishanth Menon @ 2021-12-13 17:57 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Mark Rutland, Stuart Yoder, Will Deacon, Ashok Raj, Joerg Roedel,
Jassi Brar, Sinan Kaya, iommu, Peter Ujfalusi, Bjorn Helgaas,
Megha Dey, Jason Gunthorpe, linux-pci, xen-devel, Kevin Tian,
Arnd Bergmann, Robin Murphy, Alex Williamson, Cedric Le Goater,
Santosh Shilimkar, Bjorn Helgaas, linux-arm-kernel,
Laurentiu Tudor, Juergen Gross, Tero Kristo, Greg Kroah-Hartman,
LKML, Vinod Koul, Marc Zygnier, dmaengine, linuxppc-dev
In-Reply-To: <20211210221814.540704224@linutronix.de>
On 23:19-20211210, Thomas Gleixner wrote:
> From: Thomas Gleixner <tglx@linutronix.de>
>
> Use the common msi_index member and get rid of the pointless wrapper struct.
>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
> Cc: Nishanth Menon <nm@ti.com>
> Cc: Tero Kristo <kristo@kernel.org>
> Cc: Santosh Shilimkar <ssantosh@kernel.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: linux-arm-kernel@lists.infradead.org
Acked-by: Nishanth Menon <nm@ti.com>
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D)/Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
^ permalink raw reply
* Re: [PATCH v2 6/6] module: Move duplicate mod_check_sig users code to mod_parse_sig
From: Michal Suchánek @ 2021-12-13 18:06 UTC (permalink / raw)
To: Philipp Rudo
Cc: Nayna, Mimi Zohar, David Howells, keyrings, Paul Mackerras,
Alexander Gordeev, Rob Herring, Herbert Xu, Baoquan He,
Christian Borntraeger, James Morris, Lakshmi Ramasubramanian,
Christian Borntraeger, Serge E. Hallyn, Vasily Gorbik, linux-s390,
Heiko Carstens, linux-crypto, Hari Bathini, Daniel Axtens,
Dmitry Kasatkin, Frank van der Linden, kexec, linux-kernel,
Luis Chamberlain, Sven Schnelle, linux-security-module,
Jessica Yu, linux-integrity, linuxppc-dev, David S. Miller,
Thiago Jung Bauermann, buendgen
In-Reply-To: <20211207171034.0b782d82@rhtmp>
Hello,
On Tue, Dec 07, 2021 at 05:10:34PM +0100, Philipp Rudo wrote:
> Hi Michal,
>
> On Thu, 25 Nov 2021 19:02:44 +0100
> Michal Suchanek <msuchanek@suse.de> wrote:
>
> > Multiple users of mod_check_sig check for the marker, then call
> > mod_check_sig, extract signature length, and remove the signature.
> >
> > Put this code in one place together with mod_check_sig.
> >
> > Signed-off-by: Michal Suchanek <msuchanek@suse.de>
> > ---
> > include/linux/module_signature.h | 1 +
> > kernel/module_signature.c | 56 ++++++++++++++++++++++++++++-
> > kernel/module_signing.c | 26 +++-----------
> > security/integrity/ima/ima_modsig.c | 22 ++----------
> > 4 files changed, 63 insertions(+), 42 deletions(-)
> >
> > diff --git a/include/linux/module_signature.h b/include/linux/module_signature.h
> > index 7eb4b00381ac..1343879b72b3 100644
> > --- a/include/linux/module_signature.h
> > +++ b/include/linux/module_signature.h
> > @@ -42,5 +42,6 @@ struct module_signature {
> >
> > int mod_check_sig(const struct module_signature *ms, size_t file_len,
> > const char *name);
> > +int mod_parse_sig(const void *data, size_t *len, size_t *sig_len, const char *name);
> >
> > #endif /* _LINUX_MODULE_SIGNATURE_H */
> > diff --git a/kernel/module_signature.c b/kernel/module_signature.c
> > index 00132d12487c..784b40575ee4 100644
> > --- a/kernel/module_signature.c
> > +++ b/kernel/module_signature.c
> > @@ -8,14 +8,36 @@
> >
> > #include <linux/errno.h>
> > #include <linux/printk.h>
> > +#include <linux/string.h>
> > #include <linux/module_signature.h>
> > #include <asm/byteorder.h>
> >
> > +/**
> > + * mod_check_sig_marker - check that the given data has signature marker at the end
> > + *
> > + * @data: Data with appended signature
> > + * @len: Length of data. Signature marker length is subtracted on success.
> > + */
> > +static inline int mod_check_sig_marker(const void *data, size_t *len)
>
> I personally don't like it when a function has a "check" in it's name
> as it doesn't describe what the function is checking for. For me
It is consistent with mod_check_sig
> mod_has_sig_marker is much more precise. I would use that instead.
It actually would not because it does more than that.
Thanks
Michal
>
> Thanks
> Philipp
>
> > +{
> > + const unsigned long markerlen = sizeof(MODULE_SIG_STRING) - 1;
> > +
> > + if (markerlen > *len)
> > + return -ENODATA;
> > +
> > + if (memcmp(data + *len - markerlen, MODULE_SIG_STRING,
> > + markerlen))
> > + return -ENODATA;
> > +
> > + *len -= markerlen;
> > + return 0;
> > +}
> > +
> > /**
> > * mod_check_sig - check that the given signature is sane
> > *
> > * @ms: Signature to check.
> > - * @file_len: Size of the file to which @ms is appended.
> > + * @file_len: Size of the file to which @ms is appended (without the marker).
> > * @name: What is being checked. Used for error messages.
> > */
> > int mod_check_sig(const struct module_signature *ms, size_t file_len,
> > @@ -44,3 +66,35 @@ int mod_check_sig(const struct module_signature *ms, size_t file_len,
> >
> > return 0;
> > }
> > +
> > +/**
> > + * mod_parse_sig - check that the given signature is sane and determine signature length
> > + *
> > + * @data: Data with appended signature.
> > + * @len: Length of data. Signature and marker length is subtracted on success.
> > + * @sig_len: Length of signature. Filled on success.
> > + * @name: What is being checked. Used for error messages.
> > + */
> > +int mod_parse_sig(const void *data, size_t *len, size_t *sig_len, const char *name)
> > +{
> > + const struct module_signature *sig;
> > + int rc;
> > +
> > + rc = mod_check_sig_marker(data, len);
> > + if (rc)
> > + return rc;
> > +
> > + if (*len < sizeof(*sig))
> > + return -ENODATA;
> > +
> > + sig = (const struct module_signature *)(data + (*len - sizeof(*sig)));
> > +
> > + rc = mod_check_sig(sig, *len, name);
> > + if (rc)
> > + return rc;
> > +
> > + *sig_len = be32_to_cpu(sig->sig_len);
> > + *len -= *sig_len + sizeof(*sig);
> > +
> > + return 0;
> > +}
> > diff --git a/kernel/module_signing.c b/kernel/module_signing.c
> > index cef72a6f6b5d..02bbca90f467 100644
> > --- a/kernel/module_signing.c
> > +++ b/kernel/module_signing.c
> > @@ -25,35 +25,17 @@ int verify_appended_signature(const void *data, size_t *len,
> > struct key *trusted_keys,
> > enum key_being_used_for purpose)
> > {
> > - const unsigned long markerlen = sizeof(MODULE_SIG_STRING) - 1;
> > struct module_signature ms;
> > - size_t sig_len, modlen = *len;
> > + size_t sig_len;
> > int ret;
> >
> > - pr_devel("==>%s %s(,%zu)\n", __func__, key_being_used_for[purpose], modlen);
> > + pr_devel("==>%s %s(,%zu)\n", __func__, key_being_used_for[purpose], *len);
> >
> > - if (markerlen > modlen)
> > - return -ENODATA;
> > -
> > - if (memcmp(data + modlen - markerlen, MODULE_SIG_STRING,
> > - markerlen))
> > - return -ENODATA;
> > - modlen -= markerlen;
> > -
> > - if (modlen <= sizeof(ms))
> > - return -EBADMSG;
> > -
> > - memcpy(&ms, data + (modlen - sizeof(ms)), sizeof(ms));
> > -
> > - ret = mod_check_sig(&ms, modlen, key_being_used_for[purpose]);
> > + ret = mod_parse_sig(data, len, &sig_len, key_being_used_for[purpose]);
> > if (ret)
> > return ret;
> >
> > - sig_len = be32_to_cpu(ms.sig_len);
> > - modlen -= sig_len + sizeof(ms);
> > - *len = modlen;
> > -
> > - return verify_pkcs7_signature(data, modlen, data + modlen, sig_len,
> > + return verify_pkcs7_signature(data, *len, data + *len, sig_len,
> > trusted_keys,
> > purpose,
> > NULL, NULL);
> > diff --git a/security/integrity/ima/ima_modsig.c b/security/integrity/ima/ima_modsig.c
> > index fb25723c65bc..46917eb37fd8 100644
> > --- a/security/integrity/ima/ima_modsig.c
> > +++ b/security/integrity/ima/ima_modsig.c
> > @@ -37,33 +37,17 @@ struct modsig {
> > *
> > * Return: 0 on success, error code otherwise.
> > */
> > -int ima_read_modsig(enum ima_hooks func, const void *buf, loff_t buf_len,
> > +int ima_read_modsig(enum ima_hooks func, const void *buf, loff_t len,
> > struct modsig **modsig)
> > {
> > - const size_t marker_len = strlen(MODULE_SIG_STRING);
> > - const struct module_signature *sig;
> > struct modsig *hdr;
> > - size_t sig_len;
> > - const void *p;
> > + size_t sig_len, buf_len = len;
> > int rc;
> >
> > - if (buf_len <= marker_len + sizeof(*sig))
> > - return -ENOENT;
> > -
> > - p = buf + buf_len - marker_len;
> > - if (memcmp(p, MODULE_SIG_STRING, marker_len))
> > - return -ENOENT;
> > -
> > - buf_len -= marker_len;
> > - sig = (const struct module_signature *)(p - sizeof(*sig));
> > -
> > - rc = mod_check_sig(sig, buf_len, func_tokens[func]);
> > + rc = mod_parse_sig(buf, &buf_len, &sig_len, func_tokens[func]);
> > if (rc)
> > return rc;
> >
> > - sig_len = be32_to_cpu(sig->sig_len);
> > - buf_len -= sig_len + sizeof(*sig);
> > -
> > /* Allocate sig_len additional bytes to hold the raw PKCS#7 data. */
> > hdr = kzalloc(sizeof(*hdr) + sig_len, GFP_KERNEL);
> > if (!hdr)
>
^ permalink raw reply
* [BUG] mtd: cfi_cmdset_0002: write regression since v4.17-rc1
From: Ahmad Fatoum @ 2021-12-13 13:24 UTC (permalink / raw)
To: linux-mtd, ikegami, Joakim.Tjernlund, miquel.raynal, vigneshr,
richard, ikegami.t
Cc: linuxppc-dev, linux-kernel@vger.kernel.org, marek.vasut,
Chris Packham, Pengutronix Kernel Team, cyrille.pitchen,
Shaohui.Xie, Brian Norris, David Woodhouse
Hi,
I've been investigating a breakage on a PowerPC MPC8313: The SoC is connected
via the "Enhanced Local Bus Controller" to a 8-bit-parallel S29GL064N flash,
which is represented as a memory-mapped cfi-flash.
The regression began in v4.17-rc1 with
dfeae1073583 ("mtd: cfi_cmdset_0002: Change write buffer to check correct value")
and causes all flash write accesses on the hardware to fail. Example output
after v5.1-rc2[1]:
root@host:~# mount -t jffs2 /dev/mtdblock0 /mnt
MTD do_write_buffer_wait(): software timeout, address:0x000c000b.
jffs2: Write clean marker to block at 0x000c0000 failed: -5
This issue still persists with v5.16-rc. Reverting aforementioned patch fixes
it, but I am still looking for a change that keeps both Tokunori's and my
hardware happy.
What Tokunori's patch did is that it strengthened the success condition
for flash writes:
- Prior to the patch, DQ polling was done until bits
stopped toggling. This was taken as an indicator that the write succeeded
and was reported up the stack. i.e. success condition is chip_ready()
- After the patch, polling continues until the just written data is
actually read back, i.e. success condition is chip_good()
This new condition never holds for me, when DQ stabilizes, it reads 0xFF,
never the just written data. The data is still written and can be read back
on subsequent reads, just not at that point of time in the poll loop.
We haven't had write issues for the years predating that patch. As the
regression has been mainline for a while, I am wondering what about my setup
that makes it pop up here, but not elsewhere?
I consulted the data sheet[2] and found Figure 27, which describes DQ polling
during embedded algorithms. DQ switches from status output to "True" (I assume
True == all bits set == 0xFF) until CS# is reasserted.
I compared with another chip's datasheet, and it (Figure 8.4) doesn't describe
such an intermittent "True" state. In any case, the driver polls a few hundred
times, however, before giving up, so there should be enough CS# toggles.
Locally, I'll revert this patch for now. I think accepting 0xFF as a success
condition may be appropriate, but I don't yet have the rationale to back it up.
I am investigating this some more, probably with a logic trace, but I wanted
to report this in case someone has pointers and in case other people run into
the same issue.
Cheers,
Ahmad
[1] Prior to d9b8a67b3b95 ("mtd: cfi: fix deadloop in cfi_cmdset_0002.c do_write_buffer")
first included with v5.1-rc2, failing writes just hung indefinitely in kernel space.
That's fixed, but the writes still fail.
[2]: 001-98525 Rev. *B, https://www.infineon.com/dgdl/Infineon-S29GL064N_S29GL032N_64_Mbit_32_Mbit_3_V_Page_Mode_MirrorBit_Flash-DataSheet-v03_00-EN.pdf?fileId=8ac78c8c7d0d8da4017d0ed556fd548b
[3]: https://www.mouser.com/datasheet/2/268/SST39VF1601C-SST39VF1602C-16-Mbit-x16-Multi-Purpos-709008.pdf
Note that "true data" means valid data here, not all bits one.
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH v1 0/5] Implement livepatch on PPC32
From: Christophe Leroy @ 2021-12-13 17:50 UTC (permalink / raw)
To: Steven Rostedt
Cc: Petr Mladek, Joe Lawrence, linux-s390@vger.kernel.org,
Jiri Kosina, linux-kernel@vger.kernel.org, Ingo Molnar,
Josh Poimboeuf, live-patching@vger.kernel.org, Naveen N . Rao,
Miroslav Benes, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20211213123338.65eda5a0@gandalf.local.home>
Le 13/12/2021 à 18:33, Steven Rostedt a écrit :
> On Mon, 13 Dec 2021 17:30:48 +0000
> Christophe Leroy <christophe.leroy@csgroup.eu> wrote:
>
>> Thanks, I will try that.
>>
>> I can't find ftrace_graph_func() in s390. Does it mean that s390 doesn't
>> have a working function tracer anymore ?
>>
>> I see your commit 0c0593b45c9b4 ("x86/ftrace: Make function graph use
>> ftrace directly") is dated 8 Oct 2021 while 5740a7c71ab6 ("s390/ftrace:
>> add HAVE_DYNAMIC_FTRACE_WITH_ARGS support") is 4 Oct 2021.
>
> Hmm, maybe not. I can't test it.
>
> This needs to be fixed if that's the case.
>
> Thanks for bringing it up!
>
On PPC32, I did your suggested changes, I get an Oops:
[ 8.038441] Testing tracer function_graph:
[ 8.064147] Kernel attempted to read user page (4) - exploit attempt?
(uid: 0)
[ 8.075296] Kernel attempted to read user page (4) - exploit attempt?
(uid: 0)
[ 8.082424] BUG: Kernel NULL pointer dereference on read at 0x00000004
[ 8.088864] Faulting instruction address: 0xc001468c
[ 8.093778] Oops: Kernel access of bad area, sig: 11 [#1]
[ 8.099105] BE PAGE_SIZE=16K PREEMPT CMPC885
[ 8.103329] Modules linked in:
[ 8.106340] CPU: 0 PID: 1 Comm: swapper Not tainted
5.16.0-rc3-s3k-dev-02295-g0bd6d618bcd8-dirty #732
[ 8.115461] NIP: c001468c LR: c00c8414 CTR: c0014674
[ 8.120448] REGS: c902ba00 TRAP: 0300 Not tainted
(5.16.0-rc3-s3k-dev-02295-g0bd6d618bcd8-dirty)
[ 8.129398] MSR: 00001032 <ME,IR,DR,RI> CR: 88022252 XER: 20000000
[ 8.135853] DAR: 00000004 DSISR: c0000000
[ 8.135853] GPR00: c00c8414 c902bac0 c2140000 c0015260 c0003ac4
c122db78 00000000 00000300
[ 8.135853] GPR08: c2140000 c0014674 c0015260 00000000 2802b252
00000000 c0004f38 00000000
[ 8.135853] GPR16: 00000000 00000000 00000000 00000000 00000000
00000010 c1037d1c c12d0000
[ 8.135853] GPR24: c121c440 c12b5380 c12b0000 c0003ac4 c0015260
00000000 00000200 c0015260
[ 8.174493] NIP [c001468c] ftrace_graph_func+0x18/0x74
[ 8.179572] LR [c00c8414] arch_ftrace_ops_list_func+0x118/0x230
[ 8.185430] Call Trace:
[ 8.187837] [c902bac0] [c12b5380] ftrace_list_end+0x0/0x50 (unreliable)
[ 8.194379] [c902bad0] [c00c8414] arch_ftrace_ops_list_func+0x118/0x230
[ 8.200920] [c902bb20] [c001475c] ftrace_call+0x4/0x44
[ 8.205997] [c902bb50] [c0003ac4] DataTLBError_virt+0x114/0x118
[ 8.211848] --- interrupt: 300 at ftrace_graph_func+0x18/0x74
[ 8.217527] NIP: c001468c LR: c00c8414 CTR: c0014674
[ 8.222516] REGS: c902bb60 TRAP: 0300 Not tainted
(5.16.0-rc3-s3k-dev-02295-g0bd6d618bcd8-dirty)
[ 8.231466] MSR: 00001032 <ME,IR,DR,RI> CR: 82002842 XER: 20000000
[ 8.237920] DAR: 00000004 DSISR: c0000000
[ 8.237920] GPR00: c00c8414 c902bc20 c2140000 c001573c c001624c
c122db78 00000000 00000100
[ 8.237920] GPR08: c2140000 c0014674 c001573c 00000000 22004842
00000000 c0004f38 00000000
[ 8.237920] GPR16: 00000000 00000000 00000000 00000000 00000000
00000010 c1037d1c c12d0000
[ 8.237920] GPR24: c121c440 c12b5380 c12b0000 c001624c c001573c
00000000 00000100 c001573c
[ 8.276561] NIP [c001468c] ftrace_graph_func+0x18/0x74
[ 8.281639] LR [c00c8414] arch_ftrace_ops_list_func+0x118/0x230
[ 8.287491] --- interrupt: 300
[ 8.290508] [c902bc20] [00000001] 0x1 (unreliable)
[ 8.295242] [c902bc30] [c00c8414] arch_ftrace_ops_list_func+0x118/0x230
[ 8.301782] [c902bc80] [c001475c] ftrace_call+0x4/0x44
[ 8.306860] [c902bcb0] [c001624c] map_kernel_page+0xc8/0x12c
[ 8.312454] [c902bd00] [c0019cb0] patch_instruction+0xbc/0x278
[ 8.318221] [c902bd30] [c0013964] ftrace_modify_code+0x38/0xc4
[ 8.323986] [c902bd70] [c00c2c0c] ftrace_replace_code+0x78/0xec
[ 8.329838] [c902bd90] [c00c2e30] ftrace_modify_all_code+0xd0/0x148
[ 8.336035] [c902bdb0] [c00c2f38] ftrace_run_update_code+0x28/0x88
[ 8.342145] [c902bdc0] [c00c75dc] ftrace_startup+0x118/0x1e0
[ 8.347739] [c902bde0] [c00e8310] register_ftrace_graph+0x334/0x3c0
[ 8.353935] [c902be20] [c100ccf4]
trace_selftest_startup_function_graph+0x64/0x164
[ 8.361422] [c902be50] [c00debc0] run_tracer_selftest+0x120/0x1b4
[ 8.367447] [c902be70] [c100c74c] register_tracer+0x14c/0x218
[ 8.373126] [c902be90] [c0004a30] do_one_initcall+0x44/0x1e8
[ 8.378720] [c902bef0] [c10011f4] kernel_init_freeable+0x1a8/0x250
[ 8.384831] [c902bf20] [c0004f68] kernel_init+0x30/0x150
[ 8.390081] [c902bf30] [c001322c] ret_from_kernel_thread+0x5c/0x64
[ 8.396193] Instruction dump:
[ 8.399115] 83c10018 83e1001c 3863489c 7c0803a6 38210020 4e800020
9421fff0 7c0802a6
[ 8.407031] 93e1000c 90010014 93c10008 7c7f1b78 <83c60004> 480d343d
2c030000 40820038
[ 8.415154] ---[ end trace 717d695f81a0970d ]---
I also tried with the additional change below, but still the same:
int ftrace_enable_ftrace_graph_caller(void)
{
return 0;
}
int ftrace_disable_ftrace_graph_caller(void)
{
return 0;
}
Anything else to do ?
Full change below:
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index cdac2115eb00..e2b1792b2aae 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -210,6 +210,7 @@ config PPC
select HAVE_DEBUG_KMEMLEAK
select HAVE_DEBUG_STACKOVERFLOW
select HAVE_DYNAMIC_FTRACE
+ select HAVE_DYNAMIC_FTRACE_WITH_ARGS if MPROFILE_KERNEL || PPC32
select HAVE_DYNAMIC_FTRACE_WITH_REGS if MPROFILE_KERNEL || PPC32
select HAVE_EBPF_JIT
select HAVE_EFFICIENT_UNALIGNED_ACCESS if !(CPU_LITTLE_ENDIAN &&
POWER7_CPU)
diff --git a/arch/powerpc/include/asm/ftrace.h
b/arch/powerpc/include/asm/ftrace.h
index debe8c4f7062..68f503294342 100644
--- a/arch/powerpc/include/asm/ftrace.h
+++ b/arch/powerpc/include/asm/ftrace.h
@@ -59,9 +59,24 @@ static inline unsigned long
ftrace_call_adjust(unsigned long addr)
struct dyn_arch_ftrace {
struct module *mod;
};
+
+struct ftrace_regs {
+ struct pt_regs regs;
+};
+
+static __always_inline struct pt_regs *arch_ftrace_get_regs(struct
ftrace_regs *fregs)
+{
+ return &fregs->regs;
+}
+
+struct ftrace_ops;
+
+#define ftrace_graph_func ftrace_graph_func
+void ftrace_graph_func(unsigned long ip, unsigned long parent_ip,
+ struct ftrace_ops *op, struct ftrace_regs *fregs);
#endif /* __ASSEMBLY__ */
-#ifdef CONFIG_DYNAMIC_FTRACE_WITH_REGS
+#if defined(CONFIG_DYNAMIC_FTRACE_WITH_REGS) ||
defined(CONFIG_DYNAMIC_FTRACE_WITH_ARGS)
#define ARCH_SUPPORTS_FTRACE_OPS 1
#endif
#endif /* CONFIG_FUNCTION_TRACER */
diff --git a/arch/powerpc/kernel/trace/ftrace.c
b/arch/powerpc/kernel/trace/ftrace.c
index 80b6285769f2..7662c88c4c0c 100644
--- a/arch/powerpc/kernel/trace/ftrace.c
+++ b/arch/powerpc/kernel/trace/ftrace.c
@@ -912,28 +912,12 @@ extern void ftrace_graph_stub(void);
int ftrace_enable_ftrace_graph_caller(void)
{
- unsigned long ip = (unsigned long)(&ftrace_graph_call);
- unsigned long addr = (unsigned long)(&ftrace_graph_caller);
- unsigned long stub = (unsigned long)(&ftrace_graph_stub);
- ppc_inst_t old, new;
-
- old = ftrace_call_replace(ip, stub, 0);
- new = ftrace_call_replace(ip, addr, 0);
-
- return ftrace_modify_code(ip, old, new);
+ return 0;
}
int ftrace_disable_ftrace_graph_caller(void)
{
- unsigned long ip = (unsigned long)(&ftrace_graph_call);
- unsigned long addr = (unsigned long)(&ftrace_graph_caller);
- unsigned long stub = (unsigned long)(&ftrace_graph_stub);
- ppc_inst_t old, new;
-
- old = ftrace_call_replace(ip, addr, 0);
- new = ftrace_call_replace(ip, stub, 0);
-
- return ftrace_modify_code(ip, old, new);
+ return 0;
}
/*
@@ -958,6 +942,12 @@ unsigned long prepare_ftrace_return(unsigned long
parent, unsigned long ip,
out:
return parent;
}
+
+void ftrace_graph_func(unsigned long ip, unsigned long parent_ip,
+ struct ftrace_ops *op, struct ftrace_regs *fregs)
+{
+ prepare_ftrace_return(ip, kernel_stack_pointer(&fregs->regs), 0);
+}
#endif /* CONFIG_FUNCTION_GRAPH_TRACER */
#ifdef PPC64_ELF_ABI_v1
Christophe
^ permalink raw reply related
* [PATCH] KVM: PPC: Book3S HV P9: Use kvm_arch_vcpu_get_wait() to get rcuwait object
From: Sean Christopherson @ 2021-12-13 17:45 UTC (permalink / raw)
To: Michael Ellerman
Cc: Sachin Sant, Sean Christopherson, linux-kernel, Nicholas Piggin,
Paolo Bonzini, linuxppc-dev
Use kvm_arch_vcpu_get_wait() to get a vCPU's rcuwait object instead of
using vcpu->wait directly in kvmhv_run_single_vcpu(). Functionally, this
is a nop as vcpu->arch.waitp is guaranteed to point at vcpu->wait. But
that is not obvious at first glance, and a future change coming in via
the KVM tree, commit 510958e99721 ("KVM: Force PPC to define its own
rcuwait object"), will hide vcpu->wait from architectures that define
__KVM_HAVE_ARCH_WQP to prevent generic KVM from attepting to wake a vCPU
with the wrong rcuwait object.
Reported-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
Compile tested only. Carrying this in the PPC tree will avoid a build
failure due to a silent merge conflict with a change in the KVM tree.
https://lore.kernel.org/all/496ECBB3-36F3-4F07-83B2-875F683BC446@linux.vnet.ibm.com/
arch/powerpc/kvm/book3s_hv.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index 7986911b873c..f64e45d6c0f4 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -4442,6 +4442,7 @@ static int kvmppc_run_vcpu(struct kvm_vcpu *vcpu)
int kvmhv_run_single_vcpu(struct kvm_vcpu *vcpu, u64 time_limit,
unsigned long lpcr)
{
+ struct rcuwait *wait = kvm_arch_vcpu_get_wait(vcpu);
struct kvm_run *run = vcpu->run;
int trap, r, pcpu;
int srcu_idx;
@@ -4588,7 +4589,7 @@ int kvmhv_run_single_vcpu(struct kvm_vcpu *vcpu, u64 time_limit,
if (is_kvmppc_resume_guest(r) && !kvmppc_vcpu_check_block(vcpu)) {
kvmppc_set_timer(vcpu);
- prepare_to_rcuwait(&vcpu->wait);
+ prepare_to_rcuwait(wait);
for (;;) {
set_current_state(TASK_INTERRUPTIBLE);
if (signal_pending(current)) {
@@ -4605,7 +4606,7 @@ int kvmhv_run_single_vcpu(struct kvm_vcpu *vcpu, u64 time_limit,
schedule();
trace_kvmppc_vcore_blocked(vc, 1);
}
- finish_rcuwait(&vcpu->wait);
+ finish_rcuwait(wait);
}
vcpu->arch.ceded = 0;
--
2.34.1.173.g76aa8bc2d0-goog
^ permalink raw reply related
* Re: [PATCH v1 0/5] Implement livepatch on PPC32
From: Steven Rostedt @ 2021-12-13 17:33 UTC (permalink / raw)
To: Christophe Leroy
Cc: Petr Mladek, Joe Lawrence, linux-s390@vger.kernel.org,
Jiri Kosina, linux-kernel@vger.kernel.org, Ingo Molnar,
Josh Poimboeuf, live-patching@vger.kernel.org, Naveen N . Rao,
Miroslav Benes, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <5511f43c-192a-622b-7c72-52e07f0032c2@csgroup.eu>
On Mon, 13 Dec 2021 17:30:48 +0000
Christophe Leroy <christophe.leroy@csgroup.eu> wrote:
> Thanks, I will try that.
>
> I can't find ftrace_graph_func() in s390. Does it mean that s390 doesn't
> have a working function tracer anymore ?
>
> I see your commit 0c0593b45c9b4 ("x86/ftrace: Make function graph use
> ftrace directly") is dated 8 Oct 2021 while 5740a7c71ab6 ("s390/ftrace:
> add HAVE_DYNAMIC_FTRACE_WITH_ARGS support") is 4 Oct 2021.
Hmm, maybe not. I can't test it.
This needs to be fixed if that's the case.
Thanks for bringing it up!
-- Steve
^ permalink raw reply
* Re: [PATCH v1 0/5] Implement livepatch on PPC32
From: Christophe Leroy @ 2021-12-13 17:30 UTC (permalink / raw)
To: Steven Rostedt
Cc: Petr Mladek, Joe Lawrence, linux-s390@vger.kernel.org,
Jiri Kosina, linux-kernel@vger.kernel.org, Ingo Molnar,
Josh Poimboeuf, live-patching@vger.kernel.org, Naveen N . Rao,
Miroslav Benes, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20211213121536.25e5488d@gandalf.local.home>
Le 13/12/2021 à 18:15, Steven Rostedt a écrit :
> On Mon, 13 Dec 2021 14:39:15 +0000
> Christophe Leroy <christophe.leroy@csgroup.eu> wrote:
>
>>> Note, you can implement this first, (I looked over the patches and they
>>> seem fine) and then update both ppc64 and ppc32 to implement
>>> DYNAMIC_FTRACE_WITH_ARGS.
>>>
>>
>> I tried to activate DYNAMIC_FTRACE_WITH_ARGS on PPC32.
>>
>> I copied into powerpc the changes from 5740a7c71ab6 ("s390/ftrace: add
>> HAVE_DYNAMIC_FTRACE_WITH_ARGS support")
>>
>> Ftrace selftests tell "Testing tracer function_graph: FAILED!".
>>
>> Is there anything else to do ?
>
> Yes. Because BPF is now hooking into the function callbacks, it causes
> issues with function graph tracer. So what we did was to have function
> graph tracing to now use the function tracer callback as well (this allows
> both the BPF direct trampolines to work with function graph tracer).
>
> As it requires DYNAMIC_FTRACE_WITH_ARGS, and x86 was the only one to
> support that for now, I decided to make all the archs change function graph
> tracing when they implement DYNAMIC_FTRACE_WITH_ARGS too. (It is becoming a
> pain to have too many variants of function tracing between the archs).
>
> The change that did this for x86 was:
>
> 0c0593b45c9b4 ("x86/ftrace: Make function graph use ftrace directly")
>
> This actually simplifies the function graph tracer, as you no longer need
> it's own entry trampoline (still need the trampoline for the return of the
> function).
>
> What you need to do is:
>
> In your arch/*/include/asm/ftrace.h add:
>
> struct ftrace_ops;
>
> #define ftrace_graph_func ftrace_graph_func
> void ftrace_graph_func(unsigned long ip, unsigned long parent_ip,
> struct ftrace_ops *op, struct ftrace_regs *fregs);
>
>
> Where ftrace_graph_func() is now what is called for the function graph
> tracer, directly from the ftrace callbacks (no longer a secondary
> trampoline).
>
> Define the ftrace_graph_func() to be something like:
>
> void ftrace_graph_func(unsigned long ip, unsigned long parent_ip,
> struct ftrace_ops *op, struct ftrace_regs *fregs)
> {
> struct pt_regs *regs = &fregs->regs;
> unsigned long *stack = (unsigned long *)kernel_stack_pointer(regs);
>
> prepare_ftrace_return(ip, (unsigned long *)stack, 0);
> }
>
> This is called by the function tracer code. But because with
> DYNAMIC_FTRACE_WITH_ARGS, we have access to the argument register, we should
> also have access to the link register and the stack. Then you can use that
> to modify the stack and or link register to jump to the the return
> trampoline.
>
> This should all work with powerpc (both 64 and 32) but if it does not, let
> me know. I'm happy to help out.
>
Thanks, I will try that.
I can't find ftrace_graph_func() in s390. Does it mean that s390 doesn't
have a working function tracer anymore ?
I see your commit 0c0593b45c9b4 ("x86/ftrace: Make function graph use
ftrace directly") is dated 8 Oct 2021 while 5740a7c71ab6 ("s390/ftrace:
add HAVE_DYNAMIC_FTRACE_WITH_ARGS support") is 4 Oct 2021.
Christophe
^ permalink raw reply
* Re: [next-20211210] Build break powerpc/kvm: unknown member wait
From: Sean Christopherson @ 2021-12-13 17:30 UTC (permalink / raw)
To: Sachin Sant; +Cc: linux-next, linuxppc-dev, kvm
In-Reply-To: <496ECBB3-36F3-4F07-83B2-875F683BC446@linux.vnet.ibm.com>
On Sat, Dec 11, 2021, Sachin Sant wrote:
> next-20211210 ( commit ea922272cbe547) powerpc build fails due to following error:
>
> arch/powerpc/kvm/book3s_hv.c: In function 'kvmhv_run_single_vcpu':
> arch/powerpc/kvm/book3s_hv.c:4591:27: error: 'struct kvm_vcpu' has no member named 'wait'
> prepare_to_rcuwait(&vcpu->wait);
> ^~
> arch/powerpc/kvm/book3s_hv.c:4608:23: error: 'struct kvm_vcpu' has no member named 'wait'
> finish_rcuwait(&vcpu->wait);
> ^~
>
> commit 510958e997217: KVM: Force PPC to define its own rcuwait object
> introduced the error.
This is a silent merge conflict between the above commit in the KVM tree and
commit ecb6a7207f92 ("KVM: PPC: Book3S HV P9: Remove most of the vcore logic")
in the PPC tree.
I'll send a patch for the PPC tree that is resolves the issue and is a standalone
cleanup.
^ permalink raw reply
* Re: ppc64le STRICT_MODULE_RWX and livepatch apply_relocate_add() crashes
From: Joe Lawrence @ 2021-12-13 17:26 UTC (permalink / raw)
To: Christophe Leroy, Russell Currey, live-patching@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
Cc: Peter Zijlstra, Jordan Niethe, Jessica Yu, Josh Poimboeuf
In-Reply-To: <61a5f29c-5123-5f0f-11aa-91cb0ac95a69@csgroup.eu>
On 12/13/21 11:36 AM, Christophe Leroy wrote:
>
>
> Le 13/12/2021 à 15:47, Joe Lawrence a écrit :
>> On 12/13/21 2:42 AM, Christophe Leroy wrote:
>>>
>>> Hello Joe,
>>>
>>> I'm implementing LIVEPATCH on PPC32 and I wanted to test with
>>> STRICT_MODULE_RWX enabled so I took your branch as suggested, but I'm
>>> getting the following errors on build. What shall I do ?
>>>
>>> CALL scripts/checksyscalls.sh
>>> CALL scripts/atomic/check-atomics.sh
>>> CHK include/generated/compile.h
>>> KLP lib/livepatch/test_klp_convert1.ko
>>> klp-convert: section .rela.klp.module_relocs.test_klp_convert_mod length
>>> beyond nr_entries
>>>
>>> klp-convert: Unable to load user-provided sympos
>>> make[2]: *** [scripts/Makefile.modfinal:79:
>>> lib/livepatch/test_klp_convert1.ko] Error 255
>>> KLP lib/livepatch/test_klp_convert2.ko
>>> klp-convert: section .rela.klp.module_relocs.test_klp_convert_mod length
>>> beyond nr_entries
>>>
>>> klp-convert: Unable to load user-provided sympos
>>> make[2]: *** [scripts/Makefile.modfinal:79:
>>> lib/livepatch/test_klp_convert2.ko] Error 255
>>> KLP lib/livepatch/test_klp_convert_sections.ko
>>> klp-convert: section .rela.klp.module_relocs.test_klp_convert_mod length
>>> beyond nr_entries
>>>
>>> klp-convert: Unable to load user-provided sympos
>>> make[2]: *** [scripts/Makefile.modfinal:79:
>>> lib/livepatch/test_klp_convert_sections.ko] Error 255
>>> make[2]: Target '__modfinal' not remade because of errors.
>>> make[1]: *** [scripts/Makefile.modpost:145: __modpost] Error 2
>>> make: *** [Makefile:1770: modules] Error 2
>>>
>>
>> Hi Christophe,
>>
>> Interesting failure mode. That's klp-convert complaining that it found
>> more relocations in a .klp.module_relocs.<objname> section than
>> expected, i.e. nr_entries = sec->size / sizeof(struct klp_module_reloc).
>>
>> A few possibilities: the ELF sec->size was incorrectly set/read by
>> build/libelf (I doubt that). Or maybe the layout/size of struct
>> klp_module_reloc is not consistent between kernel and userspace (I'm
>> more suspicious of this).
>>
>> Can you post a copy of the build's symbols.klp and
>> lib/livepatch/test_klp_convert1.tmp.ko somewhere? I should be able to
>> start debug with those files.
>>
>
> I sent you both files off list.
>
> It looks like klp-convert doesn't use the correct size. It finds a
> struct of size 12 hence 3 entries for a section of size 40.
>
> On PPC32 the struct has size 8 (void * is 4 and int is 4).
>
> But I'm cross-building from x86_64 where the struct is 8 + 4 = 12.
>
> Can it be the reason ?
>
I'm pretty sure that is it. I haven't had much runtime with klp-convert
and cross-building (I've only found one big/little endian bug with
x86_64->s390x) and was going to ask you how you were testing :)
Do you know if there are other kernel build tools that deal with similar
situations? This seems like a tricky job for the userspace build tool
to determine non-native target struct layout.
In the meantime, hacking in:
struct klp_module_reloc {
- void *sym;
+ uint32_t sym;
unsigned int sympos;
} __packed;
gets me generating an output .ko file, but the readelf output doesn't
look right.
I'll add this to the patchset TODO list, but may not get to it for a
while -- is there any chance the above hack works or could you test a
local non-cross build?
Thanks,
--
Joe
^ permalink raw reply
* Re: [PATCH v1 0/5] Implement livepatch on PPC32
From: Steven Rostedt @ 2021-12-13 17:15 UTC (permalink / raw)
To: Christophe Leroy
Cc: Petr Mladek, Joe Lawrence, Jiri Kosina,
linux-kernel@vger.kernel.org, Ingo Molnar, Josh Poimboeuf,
live-patching@vger.kernel.org, Naveen N . Rao, Miroslav Benes,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <6209682d-0caa-b779-8763-376a984d8ed8@csgroup.eu>
On Mon, 13 Dec 2021 14:39:15 +0000
Christophe Leroy <christophe.leroy@csgroup.eu> wrote:
> > Note, you can implement this first, (I looked over the patches and they
> > seem fine) and then update both ppc64 and ppc32 to implement
> > DYNAMIC_FTRACE_WITH_ARGS.
> >
>
> I tried to activate DYNAMIC_FTRACE_WITH_ARGS on PPC32.
>
> I copied into powerpc the changes from 5740a7c71ab6 ("s390/ftrace: add
> HAVE_DYNAMIC_FTRACE_WITH_ARGS support")
>
> Ftrace selftests tell "Testing tracer function_graph: FAILED!".
>
> Is there anything else to do ?
Yes. Because BPF is now hooking into the function callbacks, it causes
issues with function graph tracer. So what we did was to have function
graph tracing to now use the function tracer callback as well (this allows
both the BPF direct trampolines to work with function graph tracer).
As it requires DYNAMIC_FTRACE_WITH_ARGS, and x86 was the only one to
support that for now, I decided to make all the archs change function graph
tracing when they implement DYNAMIC_FTRACE_WITH_ARGS too. (It is becoming a
pain to have too many variants of function tracing between the archs).
The change that did this for x86 was:
0c0593b45c9b4 ("x86/ftrace: Make function graph use ftrace directly")
This actually simplifies the function graph tracer, as you no longer need
it's own entry trampoline (still need the trampoline for the return of the
function).
What you need to do is:
In your arch/*/include/asm/ftrace.h add:
struct ftrace_ops;
#define ftrace_graph_func ftrace_graph_func
void ftrace_graph_func(unsigned long ip, unsigned long parent_ip,
struct ftrace_ops *op, struct ftrace_regs *fregs);
Where ftrace_graph_func() is now what is called for the function graph
tracer, directly from the ftrace callbacks (no longer a secondary
trampoline).
Define the ftrace_graph_func() to be something like:
void ftrace_graph_func(unsigned long ip, unsigned long parent_ip,
struct ftrace_ops *op, struct ftrace_regs *fregs)
{
struct pt_regs *regs = &fregs->regs;
unsigned long *stack = (unsigned long *)kernel_stack_pointer(regs);
prepare_ftrace_return(ip, (unsigned long *)stack, 0);
}
This is called by the function tracer code. But because with
DYNAMIC_FTRACE_WITH_ARGS, we have access to the argument register, we should
also have access to the link register and the stack. Then you can use that
to modify the stack and or link register to jump to the the return
trampoline.
This should all work with powerpc (both 64 and 32) but if it does not, let
me know. I'm happy to help out.
-- Steve
^ permalink raw reply
* [PATCH]selftests/powerpc: skip tests for unavailable mitigations.
From: Sachin Sant @ 2021-12-13 16:42 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Sachin Sant, Nageswara R Sastry
Mitigation patching test iterates over a set of mitigations irrespective
of whether a certain mitigation is supported/available in the kernel.
This causes following messages on a kernel where some mitigations
are unavailable:
Spawned threads enabling/disabling mitigations ...
cat: entry_flush: No such file or directory
cat: uaccess_flush: No such file or directory
Waiting for timeout ...
OK
This patch adds a check for available mitigations in the kernel.
Reported-by: Nageswara R Sastry <rnsastry@linux.ibm.com>
Signed-off-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
---
diff -Naurp aa/tools/testing/selftests/powerpc/security/mitigation-patching.sh bb/tools/testing/selftests/powerpc/security/mitigation-patching.sh
--- aa/tools/testing/selftests/powerpc/security/mitigation-patching.sh 2021-12-13 10:17:05.714127154 -0500
+++ bb/tools/testing/selftests/powerpc/security/mitigation-patching.sh 2021-12-13 10:19:32.575315913 -0500
@@ -44,7 +44,10 @@ mitigations="barrier_nospec stf_barrier
for m in $mitigations
do
- do_one "$m" &
+ if [[ -f /sys/kernel/debug/powerpc/$m ]]
+ then
+ do_one "$m" &
+ fi
done
echo "Spawned threads enabling/disabling mitigations ..."
^ permalink raw reply
* [Bug 215217] Kernel fails to boot at an early stage when built with GCC_PLUGIN_LATENT_ENTROPY=y (PowerMac G4 3,6)
From: bugzilla-daemon @ 2021-12-13 16:39 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-215217-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=215217
--- Comment #9 from Christophe Leroy (christophe.leroy@csgroup.eu) ---
Erhard, were you able to redo the test with DISABLE_LATENT_ENTROPY_PLUGIN also
disabled for early_32.o ?
If you can try with it disabled for both early_32.o and setup_32.o
Then if it works, retry with it disabled only for early_32.o
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* Re: ppc64le STRICT_MODULE_RWX and livepatch apply_relocate_add() crashes
From: Christophe Leroy @ 2021-12-13 16:36 UTC (permalink / raw)
To: Joe Lawrence, Russell Currey, live-patching@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
Cc: Peter Zijlstra, Jordan Niethe, Jessica Yu, Josh Poimboeuf
In-Reply-To: <919a79b8-feff-b0a4-b96a-73f376b7f6dc@redhat.com>
Le 13/12/2021 à 15:47, Joe Lawrence a écrit :
> On 12/13/21 2:42 AM, Christophe Leroy wrote:
>>
>> Hello Joe,
>>
>> I'm implementing LIVEPATCH on PPC32 and I wanted to test with
>> STRICT_MODULE_RWX enabled so I took your branch as suggested, but I'm
>> getting the following errors on build. What shall I do ?
>>
>> CALL scripts/checksyscalls.sh
>> CALL scripts/atomic/check-atomics.sh
>> CHK include/generated/compile.h
>> KLP lib/livepatch/test_klp_convert1.ko
>> klp-convert: section .rela.klp.module_relocs.test_klp_convert_mod length
>> beyond nr_entries
>>
>> klp-convert: Unable to load user-provided sympos
>> make[2]: *** [scripts/Makefile.modfinal:79:
>> lib/livepatch/test_klp_convert1.ko] Error 255
>> KLP lib/livepatch/test_klp_convert2.ko
>> klp-convert: section .rela.klp.module_relocs.test_klp_convert_mod length
>> beyond nr_entries
>>
>> klp-convert: Unable to load user-provided sympos
>> make[2]: *** [scripts/Makefile.modfinal:79:
>> lib/livepatch/test_klp_convert2.ko] Error 255
>> KLP lib/livepatch/test_klp_convert_sections.ko
>> klp-convert: section .rela.klp.module_relocs.test_klp_convert_mod length
>> beyond nr_entries
>>
>> klp-convert: Unable to load user-provided sympos
>> make[2]: *** [scripts/Makefile.modfinal:79:
>> lib/livepatch/test_klp_convert_sections.ko] Error 255
>> make[2]: Target '__modfinal' not remade because of errors.
>> make[1]: *** [scripts/Makefile.modpost:145: __modpost] Error 2
>> make: *** [Makefile:1770: modules] Error 2
>>
>
> Hi Christophe,
>
> Interesting failure mode. That's klp-convert complaining that it found
> more relocations in a .klp.module_relocs.<objname> section than
> expected, i.e. nr_entries = sec->size / sizeof(struct klp_module_reloc).
>
> A few possibilities: the ELF sec->size was incorrectly set/read by
> build/libelf (I doubt that). Or maybe the layout/size of struct
> klp_module_reloc is not consistent between kernel and userspace (I'm
> more suspicious of this).
>
> Can you post a copy of the build's symbols.klp and
> lib/livepatch/test_klp_convert1.tmp.ko somewhere? I should be able to
> start debug with those files.
>
I sent you both files off list.
It looks like klp-convert doesn't use the correct size. It finds a
struct of size 12 hence 3 entries for a section of size 40.
On PPC32 the struct has size 8 (void * is 4 and int is 4).
But I'm cross-building from x86_64 where the struct is 8 + 4 = 12.
Can it be the reason ?
Christophe
^ permalink raw reply
* Re: ppc64le STRICT_MODULE_RWX and livepatch apply_relocate_add() crashes
From: Joe Lawrence @ 2021-12-13 14:47 UTC (permalink / raw)
To: Christophe Leroy, Russell Currey, live-patching@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
Cc: Peter Zijlstra, Jordan Niethe, Jessica Yu, Josh Poimboeuf
In-Reply-To: <bed88ff4-e5d3-4b78-4f28-29fc635c2f97@csgroup.eu>
On 12/13/21 2:42 AM, Christophe Leroy wrote:
>
> Hello Joe,
>
> I'm implementing LIVEPATCH on PPC32 and I wanted to test with
> STRICT_MODULE_RWX enabled so I took your branch as suggested, but I'm
> getting the following errors on build. What shall I do ?
>
> CALL scripts/checksyscalls.sh
> CALL scripts/atomic/check-atomics.sh
> CHK include/generated/compile.h
> KLP lib/livepatch/test_klp_convert1.ko
> klp-convert: section .rela.klp.module_relocs.test_klp_convert_mod length
> beyond nr_entries
>
> klp-convert: Unable to load user-provided sympos
> make[2]: *** [scripts/Makefile.modfinal:79:
> lib/livepatch/test_klp_convert1.ko] Error 255
> KLP lib/livepatch/test_klp_convert2.ko
> klp-convert: section .rela.klp.module_relocs.test_klp_convert_mod length
> beyond nr_entries
>
> klp-convert: Unable to load user-provided sympos
> make[2]: *** [scripts/Makefile.modfinal:79:
> lib/livepatch/test_klp_convert2.ko] Error 255
> KLP lib/livepatch/test_klp_convert_sections.ko
> klp-convert: section .rela.klp.module_relocs.test_klp_convert_mod length
> beyond nr_entries
>
> klp-convert: Unable to load user-provided sympos
> make[2]: *** [scripts/Makefile.modfinal:79:
> lib/livepatch/test_klp_convert_sections.ko] Error 255
> make[2]: Target '__modfinal' not remade because of errors.
> make[1]: *** [scripts/Makefile.modpost:145: __modpost] Error 2
> make: *** [Makefile:1770: modules] Error 2
>
Hi Christophe,
Interesting failure mode. That's klp-convert complaining that it found
more relocations in a .klp.module_relocs.<objname> section than
expected, i.e. nr_entries = sec->size / sizeof(struct klp_module_reloc).
A few possibilities: the ELF sec->size was incorrectly set/read by
build/libelf (I doubt that). Or maybe the layout/size of struct
klp_module_reloc is not consistent between kernel and userspace (I'm
more suspicious of this).
Can you post a copy of the build's symbols.klp and
lib/livepatch/test_klp_convert1.tmp.ko somewhere? I should be able to
start debug with those files.
Thanks,
--
Joe
^ permalink raw reply
* Re: [PATCH v2 0/2] kdump: simplify code
From: Matthew Wilcox @ 2021-12-13 14:43 UTC (permalink / raw)
To: David Laight
Cc: linux-ia64@vger.kernel.org, Baoquan He, linux-sh@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, x86@kernel.org,
kexec@lists.infradead.org, linux-mips@vger.kernel.org,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Xuefeng Li,
linux-fsdevel@vger.kernel.org, Andrew Morton, Dave Young,
'Tiezhu Yang', Vivek Goyal
In-Reply-To: <b7a75ae9253445af81ff2fedd5268af4@AcuMS.aculab.com>
On Mon, Dec 13, 2021 at 08:30:33AM +0000, David Laight wrote:
> From: Matthew Wilcox
> > Sent: 12 December 2021 11:48
> >
> > On Sat, Dec 11, 2021 at 05:53:46PM +0000, David Laight wrote:
> > > From: Tiezhu Yang
> > > > Sent: 11 December 2021 03:33
> > > >
> > > > v2:
> > > > -- add copy_to_user_or_kernel() in lib/usercopy.c
> > > > -- define userbuf as bool type
> > >
> > > Instead of having a flag to indicate whether the buffer is user or kernel,
> > > would it be better to have two separate buffer pointers.
> > > One for a user space buffer, the other for a kernel space buffer.
> > > Exactly one of the buffers should always be NULL.
> >
> > No. You should be using an iov_iter instead. See
> > https://lore.kernel.org/all/Ya4bdB0UBJCZhUSo@casper.infradead.org/
> > for a start on this.
>
> iov_iter gets horribly expensive...
Oh, right. Reading the kcore is a high-performance path, my mistake.
^ permalink raw reply
* Re: [PATCH v1 0/5] Implement livepatch on PPC32
From: Christophe Leroy @ 2021-12-13 14:39 UTC (permalink / raw)
To: Steven Rostedt
Cc: Petr Mladek, Joe Lawrence, Jiri Kosina,
linux-kernel@vger.kernel.org, Ingo Molnar, Josh Poimboeuf,
live-patching@vger.kernel.org, Naveen N . Rao, Miroslav Benes,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20211028093547.48c69dfe@gandalf.local.home>
Le 28/10/2021 à 15:35, Steven Rostedt a écrit :
> On Thu, 28 Oct 2021 14:24:00 +0200
> Christophe Leroy <christophe.leroy@csgroup.eu> wrote:
>
>> This series implements livepatch on PPC32.
>>
>> This is largely copied from what's done on PPC64.
>>
>> Christophe Leroy (5):
>> livepatch: Fix build failure on 32 bits processors
>> powerpc/ftrace: No need to read LR from stack in _mcount()
>> powerpc/ftrace: Add module_trampoline_target() for PPC32
>> powerpc/ftrace: Activate HAVE_DYNAMIC_FTRACE_WITH_REGS on PPC32
>> powerpc/ftrace: Add support for livepatch to PPC32
>>
>> arch/powerpc/Kconfig | 2 +-
>> arch/powerpc/include/asm/livepatch.h | 4 +-
>> arch/powerpc/kernel/module_32.c | 33 +++++
>> arch/powerpc/kernel/trace/ftrace.c | 53 +++-----
>> arch/powerpc/kernel/trace/ftrace_32.S | 187 ++++++++++++++++++++++++--
>> kernel/livepatch/core.c | 4 +-
>> 6 files changed, 230 insertions(+), 53 deletions(-)
>>
>
> This is great that you are doing this, but I wonder if it would even be
> easier, and more efficient, if you could implement
> HAVE_DYNAMIC_FTRACE_WITH_ARGS?
>
> Then you don't need to save all regs for live kernel patching. And I am
> also working on function tracing with arguments with this too.
>
> That is, to call a generic ftrace callback, you need to save all the args
> that are stored in registers to prevent the callback from clobbering them.
> As live kernel patching only needs to have the arguments of the functions,
> you save time from having to save the other regs as well.
>
> The callbacks now have "struct ftrace_regs" instead of pt_regs, because it
> will allow non ftrace_regs_caller functions to access the arguments if it
> is supported.
>
> Look at how x86_64 implements this. It should be possible to do this for
> all other archs as well.
>
> Also note, by doing this, we can then get rid of the ftrace_graph_caller,
> and have function graph tracer be a function tracing callback, as it will
> allow ftrace_graph_caller to have access to the stack and the return as
> well.
>
> If you need any more help or information to do this, I'd be happy to assist
> you.
>
> Note, you can implement this first, (I looked over the patches and they
> seem fine) and then update both ppc64 and ppc32 to implement
> DYNAMIC_FTRACE_WITH_ARGS.
>
I tried to activate DYNAMIC_FTRACE_WITH_ARGS on PPC32.
I copied into powerpc the changes from 5740a7c71ab6 ("s390/ftrace: add
HAVE_DYNAMIC_FTRACE_WITH_ARGS support")
Ftrace selftests tell "Testing tracer function_graph: FAILED!".
Is there anything else to do ?
Thanks for your help
Christophe
^ permalink raw reply
* Re: [patch V3 27/35] PCI/MSI: Use __msi_get_virq() in pci_get_vector()
From: Jason Gunthorpe @ 2021-12-13 14:23 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Nishanth Menon, Mark Rutland, Stuart Yoder, Will Deacon,
Ashok Raj, Joerg Roedel, Jassi Brar, Sinan Kaya, iommu,
Peter Ujfalusi, Bjorn Helgaas, linux-arm-kernel, linux-pci,
xen-devel, Kevin Tian, Arnd Bergmann, Robin Murphy,
Alex Williamson, Cedric Le Goater, Santosh Shilimkar,
Bjorn Helgaas, Megha Dey, Laurentiu Tudor, Juergen Gross,
Tero Kristo, Greg Kroah-Hartman, LKML, Vinod Koul, Marc Zygnier,
dmaengine, linuxppc-dev
In-Reply-To: <20211210221814.841243231@linutronix.de>
On Fri, Dec 10, 2021 at 11:19:25PM +0100, Thomas Gleixner wrote:
> From: Thomas Gleixner <tglx@linutronix.de>
>
> Use msi_get_vector() and handle the return value to be compatible.
>
> No functional change intended.
>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
> V2: Handle the INTx case directly instead of trying to be overly smart - Marc
> ---
> drivers/pci/msi/msi.c | 25 +++++--------------------
> 1 file changed, 5 insertions(+), 20 deletions(-)
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Jason
^ permalink raw reply
* Re: [patch V3 26/35] genirq/msi: Provide interface to retrieve Linux interrupt number
From: Jason Gunthorpe @ 2021-12-13 14:22 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Nishanth Menon, Mark Rutland, Stuart Yoder, Will Deacon,
Ashok Raj, Joerg Roedel, Jassi Brar, Sinan Kaya, iommu,
Peter Ujfalusi, Bjorn Helgaas, linux-arm-kernel, linux-pci,
xen-devel, Kevin Tian, Arnd Bergmann, Robin Murphy,
Alex Williamson, Cedric Le Goater, Santosh Shilimkar,
Bjorn Helgaas, Megha Dey, Laurentiu Tudor, Juergen Gross,
Tero Kristo, Greg Kroah-Hartman, LKML, Vinod Koul, Marc Zygnier,
dmaengine, linuxppc-dev
In-Reply-To: <20211210221814.780824745@linutronix.de>
On Fri, Dec 10, 2021 at 11:19:23PM +0100, Thomas Gleixner wrote:
> From: Thomas Gleixner <tglx@linutronix.de>
>
> This allows drivers to retrieve the Linux interrupt number instead of
> fiddling with MSI descriptors.
>
> msi_get_virq() returns the Linux interrupt number or 0 in case that there
> is no entry for the given MSI index.
>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
> V2: Simplify the implementation and let PCI deal with the PCI specialities - Marc
> ---
> include/linux/msi.h | 2 ++
> kernel/irq/msi.c | 36 ++++++++++++++++++++++++++++++++++++
> 2 files changed, 38 insertions(+)
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Jason
^ permalink raw reply
* Re: [patch V3 25/35] powerpc/pseries/msi: Let core code check for contiguous entries
From: Jason Gunthorpe @ 2021-12-13 14:05 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Nishanth Menon, Mark Rutland, Stuart Yoder, Will Deacon,
Ashok Raj, Joerg Roedel, Jassi Brar, Sinan Kaya, iommu,
Peter Ujfalusi, Bjorn Helgaas, linux-arm-kernel, linux-pci,
xen-devel, Kevin Tian, Arnd Bergmann, Robin Murphy,
Alex Williamson, Cedric Le Goater, Santosh Shilimkar,
Bjorn Helgaas, Megha Dey, Laurentiu Tudor, Juergen Gross,
Tero Kristo, Greg Kroah-Hartman, LKML, Vinod Koul, Marc Zygnier,
dmaengine, linuxppc-dev
In-Reply-To: <20211210221814.720998720@linutronix.de>
On Fri, Dec 10, 2021 at 11:19:22PM +0100, Thomas Gleixner wrote:
> From: Thomas Gleixner <tglx@linutronix.de>
>
> Set the domain info flag and remove the check.
>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: "Cédric Le Goater" <clg@kaod.org>
> Cc: linuxppc-dev@lists.ozlabs.org
>
> ---
> V2: Remove it completely - Cedric
> ---
> arch/powerpc/platforms/pseries/msi.c | 33 ++++++++-------------------------
> 1 file changed, 8 insertions(+), 25 deletions(-)
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Jason
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox