* Re: ppc64le STRICT_MODULE_RWX and livepatch apply_relocate_add() crashes
From: Christophe Leroy @ 2021-12-14 13:35 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: <af1eb0c3-4beb-bbc4-39da-da42f104f6c7@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 5223 bytes --]
Le 14/12/2021 à 14:00, Joe Lawrence a écrit :
> On 12/14/21 7:44 AM, Christophe Leroy wrote:
>>
>>
>> Le 13/12/2021 à 18:26, Joe Lawrence a écrit :
>>> 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?
>>>
>>
>> No I have no way to do a non-cross build. My target is an embedded board
>> with slow CPU and little memory.
>>
>> I tested with your hack, I get:
>>
>> root@vgoip:~# insmod /lib/modules/test_klp_convert1.ko
>> insmod: can't insert '/lib/modules/test_klp_convert1.ko': unknown symbol
>> in module, or unknown parameter
>> root@vgoip:~# insmod /lib/modules/test_klp_livepatch.ko
>> insmod: can't insert '/lib/modules/test_klp_livepatch.ko': unknown
>> symbol in module, or unknown parameter
>>
>>
>> I agree with you readelf shows something went wrong with relocations.
>>
>
> Thanks for trying that. Can you point me to the cross-compiler suite
> that you are using for build and readelf? Kernel .config would be handy
> too and I can try to reproduce locally for debugging.
>
Livepatch on PPC32 is WIP, branch 'livepatch' on
https://github.com/chleroy/linux.git.
You can use branch 'joe' on https://github.com/chleroy/linux.git which
is a merge of your branch klp-convert-v5-expanded-v5.16-rebase1 with my
livepatch branch.
Crosstool:
https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/11.1.0/x86_64-gcc-11.1.0-nolibc-powerpc64-linux.tar.xz
defconfig is attached
Thanks for your help
Christophe
[-- Attachment #2: defconfig --]
[-- Type: text/plain, Size: 1974 bytes --]
# CONFIG_SWAP is not set
CONFIG_SYSVIPC=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_BPF_JIT=y
CONFIG_VIRT_CPU_ACCOUNTING_NATIVE=y
CONFIG_LOG_BUF_SHIFT=14
CONFIG_EXPERT=y
# CONFIG_ELF_CORE is not set
# CONFIG_BASE_FULL is not set
# CONFIG_FUTEX is not set
CONFIG_KALLSYMS_ALL=y
CONFIG_PERF_EVENTS=y
# CONFIG_VM_EVENT_COUNTERS is not set
CONFIG_PPC_8xx=y
CONFIG_8xx_GPIO=y
CONFIG_SMC_UCODE_PATCH=y
CONFIG_PIN_TLB=y
CONFIG_GEN_RTC=y
CONFIG_HZ_100=y
CONFIG_MATH_EMULATION=y
CONFIG_PPC_16K_PAGES=y
CONFIG_ADVANCED_OPTIONS=y
CONFIG_LIVEPATCH=y
# CONFIG_SECCOMP is not set
CONFIG_MODULES=y
CONFIG_PARTITION_ADVANCED=y
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_PNP=y
CONFIG_SYN_COOKIES=y
# CONFIG_FW_LOADER is not set
CONFIG_MTD=y
CONFIG_MTD_BLOCK=y
CONFIG_MTD_JEDECPROBE=y
CONFIG_MTD_CFI_ADV_OPTIONS=y
CONFIG_MTD_CFI_GEOMETRY=y
# CONFIG_MTD_MAP_BANK_WIDTH_1 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_2 is not set
# CONFIG_MTD_CFI_I1 is not set
# CONFIG_MTD_CFI_I2 is not set
CONFIG_MTD_CFI_I4=y
CONFIG_MTD_CFI_AMDSTD=y
CONFIG_MTD_PHYSMAP=y
CONFIG_MTD_PHYSMAP_OF=y
# CONFIG_BLK_DEV is not set
CONFIG_NETDEVICES=y
CONFIG_FS_ENET=y
# CONFIG_FS_ENET_HAS_SCC is not set
CONFIG_DAVICOM_PHY=y
# CONFIG_INPUT is not set
# CONFIG_SERIO is not set
# CONFIG_VT is not set
# CONFIG_LEGACY_PTYS is not set
CONFIG_SERIAL_CPM=y
CONFIG_SERIAL_CPM_CONSOLE=y
CONFIG_SPI=y
CONFIG_SPI_FSL_SPI=y
# CONFIG_HWMON is not set
CONFIG_WATCHDOG=y
CONFIG_8xxx_WDT=y
# CONFIG_USB_SUPPORT is not set
# CONFIG_DNOTIFY is not set
CONFIG_TMPFS=y
CONFIG_CRAMFS=y
CONFIG_NFS_FS=y
CONFIG_ROOT_NFS=y
CONFIG_CRYPTO=y
CONFIG_CRYPTO_DEV_TALITOS=y
CONFIG_CRC32_SLICEBY4=y
CONFIG_DYNAMIC_DEBUG=y
CONFIG_DEBUG_INFO=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_DEBUG_FS=y
CONFIG_DEBUG_VM_PGTABLE=y
CONFIG_DETECT_HUNG_TASK=y
CONFIG_FUNCTION_TRACER=y
CONFIG_FTRACE_STARTUP_TEST=y
# CONFIG_EVENT_TRACE_STARTUP_TEST is not set
CONFIG_BDI_SWITCH=y
CONFIG_PPC_EARLY_DEBUG=y
CONFIG_TEST_LIVEPATCH=m
^ permalink raw reply
* Re: [PATCH v1 0/5] Implement livepatch on PPC32
From: Steven Rostedt @ 2021-12-14 14:01 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: <aac75717-a3ac-c0b4-3e79-dc6eb9c26d8c@csgroup.eu>
On Tue, 14 Dec 2021 08:35:14 +0100
Christophe Leroy <christophe.leroy@csgroup.eu> wrote:
> > Will continue investigating.
> >
>
> trace_selftest_startup_function_graph() calls register_ftrace_direct()
> which returns -ENOSUPP because powerpc doesn't select
> CONFIG_DYNAMIC_FTRACE_WITH_DIRECT_CALLS.
>
> Should TEST_DIRECT_TRAMP depend on CONFIG_DYNAMIC_FTRACE_WITH_DIRECT_CALLS ?
Yes, that should be:
#if defined(CONFIG_DYNAMIC_FTRACE) && \
defined(CONFIG_HAVE_DYNAMIC_FTRACE_WITH_DIRECT_CALLS)
#define TEST_DIRECT_TRAMP
noinline __noclone static void trace_direct_tramp(void) { }
#endif
And make it test it with or without the args.
Thanks for finding this.
-- Steve
^ permalink raw reply
* Re: [PATCH v1 0/5] Implement livepatch on PPC32
From: Heiko Carstens @ 2021-12-14 14:25 UTC (permalink / raw)
To: Christophe Leroy
Cc: Petr Mladek, Joe Lawrence, linux-s390@vger.kernel.org,
Jiri Kosina, linux-kernel@vger.kernel.org, Steven Rostedt,
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, Dec 13, 2021 at 05:50:52PM +0000, Christophe Leroy wrote:
> 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!
It still works, we run the full ftrace/kprobes selftests from the
kernel every day on multiple machines with several kernels (besides
other Linus' tree, but also linux-next). That said, I wanted to change
s390's code follow what x86 is currently doing anyway.
One thing to note: commit 5740a7c71ab6 ("s390/ftrace: add
HAVE_DYNAMIC_FTRACE_WITH_ARGS support") looks only that simple because
ftrace_caller _and_ ftrace_regs_caller used to save all register
contents into the pt_regs structure, which never was a requirement,
but implicitly fulfills the HAVE_DYNAMIC_FTRACE_WITH_ARGS
requirements.
Not sure if powerpc passes enough register contents via pt_regs for
HAVE_DYNAMIC_FTRACE_WITH_ARGS though. Might be something to check?
^ permalink raw reply
* Re: [PATCH v2] of/fdt: Rework early_init_dt_scan_memory() to call directly
From: Rob Herring @ 2021-12-14 14:40 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: <877dc7mo3o.fsf@mpe.ellerman.id.au>
On Tue, Dec 14, 2021 at 5:18 AM Michael Ellerman <mpe@ellerman.id.au> wrote:
>
> Rob Herring <robh@kernel.org> writes:
> > 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;
> >> > }
>
> It's that return that is the problem.
>
> Now that early_init_dt_scan_memory_ppc() is only called once, that
> return causes us to skip scanning regular memory nodes if there is an
> "ibm,dynamic-reconfiguration-memory" property present.
>
> So the fix is just:
>
> diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
> index 1098de3b172f..125661e5fcf3 100644
> --- a/arch/powerpc/kernel/prom.c
> +++ b/arch/powerpc/kernel/prom.c
> @@ -538,10 +538,8 @@ static int __init early_init_dt_scan_memory_ppc(void)
> const void *fdt = initial_boot_params;
> int node = fdt_path_offset(fdt, "/ibm,dynamic-reconfiguration-memory");
>
> - if (node > 0) {
> + if (node > 0)
> walk_drmem_lmbs_early(node, NULL, early_init_drmem_lmb);
> - return 0;
> - }
> #endif
>
> return early_init_dt_scan_memory();
Thanks! I've rolled that in.
> > 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.
>
> I don't know of any machines where that would be a problem. But given
> all the wild and wonderful device trees out there, who really knows :)
>
> Maybe we should continue to allow memory nodes to be anywhere, and print
> a warning for any that aren't at the root. Then if no one reports any
> hits for the warning we could switch to only allowing them at the root?
I really doubt there's any case. I just have the least visibility into
what IBM DTs look like. I checked some old DT files I have and also
u-boot only supports off the root node.
Rob
^ permalink raw reply
* Re: [PATCH v1 0/5] Implement livepatch on PPC32
From: Christophe Leroy @ 2021-12-14 15:12 UTC (permalink / raw)
To: Heiko Carstens
Cc: Petr Mladek, Joe Lawrence, linux-s390@vger.kernel.org,
Jiri Kosina, linux-kernel@vger.kernel.org, Steven Rostedt,
Ingo Molnar, Josh Poimboeuf, live-patching@vger.kernel.org,
Naveen N . Rao, Miroslav Benes, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <YbipdU5X4HNDWIni@osiris>
Le 14/12/2021 à 15:25, Heiko Carstens a écrit :
> On Mon, Dec 13, 2021 at 05:50:52PM +0000, Christophe Leroy wrote:
>> 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!
>
> It still works, we run the full ftrace/kprobes selftests from the
> kernel every day on multiple machines with several kernels (besides
> other Linus' tree, but also linux-next). That said, I wanted to change
> s390's code follow what x86 is currently doing anyway.
>
> One thing to note: commit 5740a7c71ab6 ("s390/ftrace: add
> HAVE_DYNAMIC_FTRACE_WITH_ARGS support") looks only that simple because
> ftrace_caller _and_ ftrace_regs_caller used to save all register
> contents into the pt_regs structure, which never was a requirement,
> but implicitly fulfills the HAVE_DYNAMIC_FTRACE_WITH_ARGS
> requirements.
> Not sure if powerpc passes enough register contents via pt_regs for
> HAVE_DYNAMIC_FTRACE_WITH_ARGS though. Might be something to check?
>
In fact there is no need to rework the function graph logic. It still
works as is with HAVE_DYNAMIC_FTRACE_WITH_ARGS.
The problem was that the sefltests were failing with
CONFIG_DYNAMIC_FTRACE_WITH_DIRECT_CALLS not being selected on powerpc.
As s390 selects CONFIG_DYNAMIC_FTRACE_WITH_DIRECT_CALLS, there is no
problem.
Thanks
Christophe
^ 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-14 15:43 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
Erhard F. (erhard_f@mailbox.org) changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #300015|0 |1
is obsolete| |
--- Comment #12 from Erhard F. (erhard_f@mailbox.org) ---
Created attachment 300027
--> https://bugzilla.kernel.org/attachment.cgi?id=300027&action=edit
kernel vmlinux.xz (5.16-rc5 + CFLAGS_setup_32.o/early_32.o +=... , PowerMac G4
DP)
Ok. I .xz-compressed it afterwards as it would be too big otherwise.
--
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: [patch V3 00/35] genirq/msi, PCI/MSI: Spring cleaning - Part 2
From: Nishanth Menon @ 2021-12-14 16:22 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, Johannes Berg,
Alex Williamson, Cedric Le Goater, Santosh Shilimkar,
Bjorn Helgaas, Megha Dey, Laurentiu Tudor, Juergen Gross,
Tero Kristo, Greg Kroah-Hartman, linux-wireless, LKML, Vinod Koul,
Marc Zygnier, dmaengine, linuxppc-dev
In-Reply-To: <87fsqvttfv.ffs@tglx>
On 10:41-20211214, Thomas Gleixner wrote:
> On Mon, Dec 13 2021 at 12:29, Nishanth Menon wrote:
> > On 23:18-20211210, Thomas Gleixner wrote:
> > Also while testing on TI K3 platforms, I noticed:
> >
> > msi_device_data_release/msi_device_destroy_sysfs in am64xx-evm / j7200
>
> The warning complains about a device being released with MSI descriptors
> still attached to the device. This was added by:
>
> 5b012cede0f7 ("device: Add device::msi_data pointer and struct msi_device_data")
>
> That's not a regression caused by this commit. The warning is just
> exposing an already existing problem in the iwlwifi driver, which seems
> to do:
>
> probe()
> setup_pci_msi[x]_interrupts()
> start_drv()
> if (try_to_load_firmware() == FAIL)
> device_release_driver()
> ...
> msi_device_data_release()
> WARN()
>
Agreed that the warning is fine, the null pointer exception that follows
[1] [2] it however does'nt look right and it can be trivially fixed with the
following fixup for ee90787487bc ("genirq/msi: Provide
msi_device_populate/destroy_sysfs()") below, with that the log looks
like [3] - the warn is good, the null pointer exception and resultant
crash could be avoided (not saying this is the best solution):
diff --git a/kernel/irq/msi.c b/kernel/irq/msi.c
index ab5e83f41188..24edb870c66f 100644
--- a/kernel/irq/msi.c
+++ b/kernel/irq/msi.c
@@ -252,11 +252,14 @@ int msi_device_populate_sysfs(struct device *dev)
*/
void msi_device_destroy_sysfs(struct device *dev)
{
- const struct attribute_group **msi_irq_groups = dev->msi.data->attrs;
+ const struct attribute_group **msi_irq_groups;
struct device_attribute *dev_attr;
struct attribute **msi_attrs;
int count = 0;
+ if (!dev->msi.data)
+ return;
+ msi_irq_groups = dev->msi.data->attrs;
dev->msi.data->attrs = NULL;
if (!msi_irq_groups)
return;
[1] https://gist.github.com/nmenon/36899c7819681026cfe1ef185fb95f33#file-am64xx-evm-txt-L1049
[2] https://gist.github.com/nmenon/36899c7819681026cfe1ef185fb95f33#file-j7200-evm-txt-L1111
[3] https://gist.github.com/nmenon/575afe7d04463026a7e420a76c2c1c5b
https://gist.github.com/nmenon/575afe7d04463026a7e420a76c2c1c5b#file-am64xx-evm-txt-L1018
https://gist.github.com/nmenon/575afe7d04463026a7e420a76c2c1c5b#file-j7200-evm-txt-L1053
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D)/Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
^ permalink raw reply related
* Re: [patch V3 00/35] genirq/msi, PCI/MSI: Spring cleaning - Part 2
From: Thomas Gleixner @ 2021-12-14 16:36 UTC (permalink / raw)
To: Nishanth Menon
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, Johannes Berg,
Alex Williamson, Cedric Le Goater, Santosh Shilimkar,
Bjorn Helgaas, Megha Dey, Laurentiu Tudor, Juergen Gross,
Tero Kristo, Greg Kroah-Hartman, linux-wireless, LKML, Vinod Koul,
Marc Zygnier, dmaengine, linuxppc-dev
In-Reply-To: <20211214162247.ocjm7ihg5oi7uiuv@slider>
On Tue, Dec 14 2021 at 10:22, Nishanth Menon wrote:
> On 10:41-20211214, Thomas Gleixner wrote:
> Agreed that the warning is fine, the null pointer exception that follows
> [1] [2] it however does'nt look right and it can be trivially fixed with the
> following fixup for ee90787487bc ("genirq/msi: Provide
> msi_device_populate/destroy_sysfs()") below, with that the log looks
> like [3] - the warn is good, the null pointer exception and resultant
> crash could be avoided (not saying this is the best solution):
Aaargh.
[ 13.478122] Call trace:
[ 13.509042] msi_device_destroy_sysfs+0x18/0x88
[ 13.509058] msi_domain_free_irqs+0x34/0x58
[ 13.509064] pci_msi_teardown_msi_irqs+0x30/0x3c
[ 13.509072] free_msi_irqs+0x78/0xd4
[ 13.509077] pci_disable_msix+0x138/0x164
[ 13.529930] pcim_release+0x70/0x238
[ 13.529942] devres_release_all+0x9c/0xfc
[ 13.529951] device_release_driver_internal+0x1a0/0x244
[ 13.542725] device_release_driver+0x18/0x24
[ 13.542741] iwl_req_fw_callback+0x1a28/0x1ddc [iwlwifi]
[ 13.552308] request_firmware_work_func+0x50/0x9c
[ 13.552320] process_one_work+0x194/0x25c
That's not a driver problem, that's an ordering issue vs. the devres
muck. Let me go back to the drawing board. Sigh...
Thanks,
tglx
^ permalink raw reply
* Re: [patch V3 00/35] genirq/msi, PCI/MSI: Spring cleaning - Part 2
From: Thomas Gleixner @ 2021-12-14 17:03 UTC (permalink / raw)
To: Nishanth Menon
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, Johannes Berg,
Alex Williamson, Cedric Le Goater, Santosh Shilimkar,
Bjorn Helgaas, Megha Dey, Laurentiu Tudor, Juergen Gross,
Tero Kristo, Greg Kroah-Hartman, linux-wireless, LKML, Vinod Koul,
Marc Zygnier, dmaengine, linuxppc-dev
In-Reply-To: <87wnk7rvnz.ffs@tglx>
On Tue, Dec 14 2021 at 17:36, Thomas Gleixner wrote:
> On Tue, Dec 14 2021 at 10:22, Nishanth Menon wrote:
>> On 10:41-20211214, Thomas Gleixner wrote:
> [ 13.478122] Call trace:
> [ 13.509042] msi_device_destroy_sysfs+0x18/0x88
> [ 13.509058] msi_domain_free_irqs+0x34/0x58
> [ 13.509064] pci_msi_teardown_msi_irqs+0x30/0x3c
> [ 13.509072] free_msi_irqs+0x78/0xd4
> [ 13.509077] pci_disable_msix+0x138/0x164
> [ 13.529930] pcim_release+0x70/0x238
> [ 13.529942] devres_release_all+0x9c/0xfc
> [ 13.529951] device_release_driver_internal+0x1a0/0x244
> [ 13.542725] device_release_driver+0x18/0x24
> [ 13.542741] iwl_req_fw_callback+0x1a28/0x1ddc [iwlwifi]
> [ 13.552308] request_firmware_work_func+0x50/0x9c
> [ 13.552320] process_one_work+0x194/0x25c
>
> That's not a driver problem, that's an ordering issue vs. the devres
> muck. Let me go back to the drawing board. Sigh...
Which is pretty obvious why:
pcim_enable_device()
devres_alloc(pcim_release...);
...
pci_irq_alloc()
msi_setup_device_data()
devres_alloc(msi_device_data_release, ...)
and once the device is released:
msi_device_data_release()
...
pcim_release()
pci_disable_msi[x]()
Groan....
^ permalink raw reply
* Re: linux-next: manual merge of the audit tree with the powerpc tree
From: Christophe Leroy @ 2021-12-14 17:59 UTC (permalink / raw)
To: Paul Moore
Cc: Stephen Rothwell, Richard Guy Briggs, Linux Kernel Mailing List,
Linux Next Mailing List, PowerPC
In-Reply-To: <CAHC9VhRHs8Lx8+v+LHmJByxO_m330sfLWRsGDsFtQxyQ1860eg@mail.gmail.com>
Le 27/10/2021 à 16:18, Paul Moore a écrit :
> On Wed, Oct 27, 2021 at 7:41 AM Christophe Leroy
> <christophe.leroy@csgroup.eu> wrote:
>> Le 27/10/2021 à 13:29, Michael Ellerman a écrit :
>>> Paul Moore <paul@paul-moore.com> writes:
>>>> On Tue, Oct 26, 2021 at 6:55 AM Michael Ellerman <mpe@ellerman.id.au> wrote:
>>>>> Stephen Rothwell <sfr@canb.auug.org.au> writes:
>>>>>> Hi all,
>>>>>>
>>>>>> Today's linux-next merge of the audit tree got conflicts in:
>>>>>>
>>>>>> arch/powerpc/kernel/audit.c
>>>>>> arch/powerpc/kernel/compat_audit.c
>>>>>>
>>>>>> between commit:
>>>>>>
>>>>>> 566af8cda399 ("powerpc/audit: Convert powerpc to AUDIT_ARCH_COMPAT_GENERIC")
>>>>>>
>>>>>> from the powerpc tree and commits:
>>>>>>
>>>>>> 42f355ef59a2 ("audit: replace magic audit syscall class numbers with macros")
>>>>>> 1c30e3af8a79 ("audit: add support for the openat2 syscall")
>>>>>>
>>>>>> from the audit tree.
>>>>>
>>>>> Thanks.
>>>>>
>>>>> I guess this is OK, unless the audit folks disagree. I could revert the
>>>>> powerpc commit and try it again later.
>>>>>
>>>>> If I don't hear anything I'll leave it as-is.
>>>>
>>>> Hi Michael,
>>>>
>>>> Last I recall from the powerpc/audit thread there were still some
>>>> issues with audit working properly in your testing, has that been
>>>> resolved?
>>>
>>> No.
>>>
>>> There's one test failure both before and after the conversion to use the
>>> generic code.
>>>
>>>> If nothing else, -rc7 seems a bit late for this to hit -next for me to
>>>> feel comfortable about this.
>>>
>>> OK. I'll revert the patch in my tree.
>>
>> But it's been in the pipe since end of August and no one reported any
>> issue other issue than the pre-existing one, so what's the new issue
>> that prevents us to merge it two monthes later, and how do we walk
>> forward then ?
>
> We work to resolve the test failure, it's that simple. I haven't seen
> the failure so I haven't been much help to do any sort of root cause
> digging on the problem, it would be helpful if those who are seeing
> the problem could dig into the failure and report back on what they
> find. That is what has been missing and why I never ACK'd or merged
> the powerpc audit code.
>
Hello Paul,
I've been trying to setup your test suite on my powerpc board but it's
based on Perl and on a lot of optional Perl packages. I was able to add
them one by one until some of them require some .so libraries
(Pathtools-Cwd), and it seems nothing is made to allow cross building
those libraries.
Do you have another test suite based on C and not perl ?
If not, what can I do, do you know how I can cross compile those Perl
packages for PPC32 ?
Thanks
Christophe
^ permalink raw reply
* Re: linux-next: manual merge of the audit tree with the powerpc tree
From: Paul Moore @ 2021-12-14 18:23 UTC (permalink / raw)
To: Christophe Leroy
Cc: Stephen Rothwell, Richard Guy Briggs, Linux Kernel Mailing List,
Linux Next Mailing List, PowerPC
In-Reply-To: <dc5705cf-d47a-57b0-65da-2a2af8d71b19@csgroup.eu>
On Tue, Dec 14, 2021 at 12:59 PM Christophe Leroy
<christophe.leroy@csgroup.eu> wrote:
> Hello Paul,
>
> I've been trying to setup your test suite on my powerpc board but it's
> based on Perl and on a lot of optional Perl packages. I was able to add
> them one by one until some of them require some .so libraries
> (Pathtools-Cwd), and it seems nothing is made to allow cross building
> those libraries.
>
> Do you have another test suite based on C and not perl ?
>
> If not, what can I do, do you know how I can cross compile those Perl
> packages for PPC32 ?
Is there no Linux distribution that supports PPC32? I would think
that would be the easiest path forward, but you're the PPC32 expert -
not me - so I'll assume you already tried that or it didn't work for
other reasons.
I'm also not a Perl expert, but it looks like PathTools is part of the
core Perl5 release, have you tried that?
https://github.com/Perl/perl5/tree/blead/dist/PathTools
Finally, no, our only really maintained test suite is the Perl based
one; there have been other efforts over the years but they were never
properly supported and fell out of use (and applicability). At some
point you/someone was able to run the test suite, why isn't that
working now? Or was it a different powerpc ABI?
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: linux-next: manual merge of the audit tree with the powerpc tree
From: Christophe Leroy @ 2021-12-14 19:32 UTC (permalink / raw)
To: Paul Moore
Cc: Stephen Rothwell, Richard Guy Briggs, Linux Kernel Mailing List,
Linux Next Mailing List, PowerPC
In-Reply-To: <CAHC9VhQPizVLkr2+sqRCS0gS4+ZSw-AMkJM5V64-ku8AQe+QQg@mail.gmail.com>
Le 14/12/2021 à 19:23, Paul Moore a écrit :
> On Tue, Dec 14, 2021 at 12:59 PM Christophe Leroy
> <christophe.leroy@csgroup.eu> wrote:
>> Hello Paul,
>>
>> I've been trying to setup your test suite on my powerpc board but it's
>> based on Perl and on a lot of optional Perl packages. I was able to add
>> them one by one until some of them require some .so libraries
>> (Pathtools-Cwd), and it seems nothing is made to allow cross building
>> those libraries.
>>
>> Do you have another test suite based on C and not perl ?
>>
>> If not, what can I do, do you know how I can cross compile those Perl
>> packages for PPC32 ?
>
> Is there no Linux distribution that supports PPC32? I would think
> that would be the easiest path forward, but you're the PPC32 expert -
> not me - so I'll assume you already tried that or it didn't work for
> other reasons.
There hasn't been Linux distribution supporting PPC32 for a few years
now. And regardless, the boards I'm running Linux on are home made
embedded boards, with limited amount of memory and flashdisk space and
no video chip, so they are hardly supported by any distributions, even
older ones.
>
> I'm also not a Perl expert, but it looks like PathTools is part of the
> core Perl5 release, have you tried that?
>
> https://github.com/Perl/perl5/tree/blead/dist/PathTools
I got it from https://metacpan.org/pod/Cwd
I guess it is the same ?
>
> Finally, no, our only really maintained test suite is the Perl based
> one; there have been other efforts over the years but they were never
> properly supported and fell out of use (and applicability). At some
> point you/someone was able to run the test suite, why isn't that
> working now? Or was it a different powerpc ABI?
>
Yes, Michael did on some PPC64 server, for this kind of HW there are
distribution and they are able to run native compilers on it as well, so
that's another story.
Christophe
^ permalink raw reply
* Re: [patch V3 00/35] genirq/msi, PCI/MSI: Spring cleaning - Part 2
From: Thomas Gleixner @ 2021-12-14 20:15 UTC (permalink / raw)
To: Nishanth Menon
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, Johannes Berg,
Alex Williamson, Cedric Le Goater, Santosh Shilimkar,
Bjorn Helgaas, Megha Dey, Laurentiu Tudor, Juergen Gross,
Tero Kristo, Greg Kroah-Hartman, linux-wireless, LKML, Vinod Koul,
Marc Zygnier, dmaengine, linuxppc-dev
In-Reply-To: <87tufbrudl.ffs@tglx>
Nishanth,
On Tue, Dec 14 2021 at 18:03, Thomas Gleixner wrote:
> msi_device_data_release()
> ...
> pcim_release()
> pci_disable_msi[x]()
>
> Groan....
I think I managed to distangle this. Can you please give:
git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git msi-v4-part-2
and/or the full pile:
git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git msi-v4-part-3
a test ride?
Thanks,
tglx
^ permalink raw reply
* [PATCH v3] of/fdt: Rework early_init_dt_scan_memory() to call directly
From: Rob Herring @ 2021-12-14 20:26 UTC (permalink / raw)
To: John Crispin, Thomas Bogendoerfer, Michael Ellerman,
Benjamin Herrenschmidt, Paul Mackerras, Frank Rowand
Cc: devicetree, linuxppc-dev, linux-mips, Frank Rowand, linux-kernel
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.
Cc: John Crispin <john@phrozen.org>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Frank Rowand <frowand.list@gmail.com>
Cc: linux-mips@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Reviewed-by: Frank Rowand <frank.rowand@sony.com>
Signed-off-by: Rob Herring <robh@kernel.org>
---
v3:
- Fix powerpc when /ibm,dynamic-reconfiguration-memory is present
v2:
- ralink: Use 'if' instead of 'else if'
- early_init_dt_scan_memory: continue instead of return on no reg
- Fix indentation
---
arch/mips/ralink/of.c | 19 +++--------
arch/powerpc/kernel/prom.c | 21 ++++++------
drivers/of/fdt.c | 67 +++++++++++++++++++-------------------
include/linux/of_fdt.h | 3 +-
4 files changed, 49 insertions(+), 61 deletions(-)
diff --git a/arch/mips/ralink/of.c b/arch/mips/ralink/of.c
index 0135376c5de5..35a87a2da10b 100644
--- a/arch/mips/ralink/of.c
+++ b/arch/mips/ralink/of.c
@@ -53,17 +53,6 @@ void __init device_tree_init(void)
unflatten_and_copy_device_tree();
}
-static int memory_dtb;
-
-static int __init early_init_dt_find_memory(unsigned long node,
- const char *uname, int depth, void *data)
-{
- if (depth == 1 && !strcmp(uname, "memory@0"))
- memory_dtb = 1;
-
- return 0;
-}
-
void __init plat_mem_setup(void)
{
void *dtb;
@@ -77,10 +66,10 @@ void __init plat_mem_setup(void)
dtb = get_fdt();
__dt_setup_arch(dtb);
- of_scan_flat_dt(early_init_dt_find_memory, NULL);
- if (memory_dtb)
- of_scan_flat_dt(early_init_dt_scan_memory, NULL);
- else if (soc_info.mem_detect)
+ if (!early_init_dt_scan_memory())
+ return;
+
+ if (soc_info.mem_detect)
soc_info.mem_detect();
else if (soc_info.mem_size)
memblock_add(soc_info.mem_base, soc_info.mem_size * SZ_1M);
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index 6e1a106f02eb..ad1230c4f3fe 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -532,19 +532,18 @@ 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 +748,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 +857,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)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 5e216555fe4f..97d7607625ec 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -1078,49 +1078,50 @@ u64 __init dt_mem_next_cell(int s, const __be32 **cellp)
/*
* early_init_dt_scan_memory - Look for and parse memory nodes
*/
-int __init early_init_dt_scan_memory(unsigned long node, const char *uname,
- int depth, void *data)
+int __init early_init_dt_scan_memory(void)
{
- const char *type = of_get_flat_dt_prop(node, "device_type", NULL);
- const __be32 *reg, *endp;
- int l;
- bool hotpluggable;
-
- /* We are scanning "memory" nodes only */
- if (type == NULL || strcmp(type, "memory") != 0)
- return 0;
+ int node;
+ const void *fdt = initial_boot_params;
- reg = of_get_flat_dt_prop(node, "linux,usable-memory", &l);
- if (reg == NULL)
- reg = of_get_flat_dt_prop(node, "reg", &l);
- if (reg == NULL)
- return 0;
+ 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;
+
+ reg = of_get_flat_dt_prop(node, "linux,usable-memory", &l);
+ if (reg == NULL)
+ reg = of_get_flat_dt_prop(node, "reg", &l);
+ if (reg == NULL)
+ continue;
- endp = reg + (l / sizeof(__be32));
- hotpluggable = of_get_flat_dt_prop(node, "hotpluggable", NULL);
+ endp = reg + (l / sizeof(__be32));
+ hotpluggable = of_get_flat_dt_prop(node, "hotpluggable", NULL);
- pr_debug("memory scan node %s, reg size %d,\n", uname, l);
+ pr_debug("memory scan node %s, reg size %d,\n",
+ fdt_get_name(fdt, node, NULL), l);
- while ((endp - reg) >= (dt_root_addr_cells + dt_root_size_cells)) {
- u64 base, size;
+ while ((endp - reg) >= (dt_root_addr_cells + dt_root_size_cells)) {
+ u64 base, size;
- base = dt_mem_next_cell(dt_root_addr_cells, ®);
- size = dt_mem_next_cell(dt_root_size_cells, ®);
+ base = dt_mem_next_cell(dt_root_addr_cells, ®);
+ size = dt_mem_next_cell(dt_root_size_cells, ®);
- if (size == 0)
- continue;
- pr_debug(" - %llx, %llx\n", base, size);
+ if (size == 0)
+ continue;
+ pr_debug(" - %llx, %llx\n", base, size);
- early_init_dt_add_memory_arch(base, size);
+ early_init_dt_add_memory_arch(base, size);
- if (!hotpluggable)
- continue;
+ if (!hotpluggable)
+ continue;
- if (memblock_mark_hotplug(base, size))
- pr_warn("failed to mark hotplug range 0x%llx - 0x%llx\n",
- base, base + size);
+ if (memblock_mark_hotplug(base, size))
+ pr_warn("failed to mark hotplug range 0x%llx - 0x%llx\n",
+ base, base + size);
+ }
}
-
return 0;
}
@@ -1271,7 +1272,7 @@ void __init early_init_dt_scan_nodes(void)
pr_warn("No chosen node found, continuing without\n");
/* Setup memory, calling early_init_dt_add_memory_arch */
- of_scan_flat_dt(early_init_dt_scan_memory, NULL);
+ early_init_dt_scan_memory();
/* Handle linux,usable-memory-range property */
memblock_cap_memory_range(cap_mem_addr, cap_mem_size);
diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
index df3d31926c3c..914739f3c192 100644
--- a/include/linux/of_fdt.h
+++ b/include/linux/of_fdt.h
@@ -59,8 +59,7 @@ extern unsigned long of_get_flat_dt_root(void);
extern uint32_t of_get_flat_dt_phandle(unsigned long node);
extern int early_init_dt_scan_chosen(char *cmdline);
-extern int early_init_dt_scan_memory(unsigned long node, const char *uname,
- int depth, void *data);
+extern int early_init_dt_scan_memory(void);
extern int early_init_dt_scan_chosen_stdout(void);
extern void early_init_fdt_scan_reserved_mem(void);
extern void early_init_fdt_reserve_self(void);
--
2.32.0
^ permalink raw reply related
* Re: linux-next: manual merge of the audit tree with the powerpc tree
From: Cédric Le Goater @ 2021-12-14 20:30 UTC (permalink / raw)
To: Christophe Leroy, Paul Moore
Cc: Richard Guy Briggs, Stephen Rothwell, Linux Next Mailing List,
PowerPC, Linux Kernel Mailing List
In-Reply-To: <1a78709f-162e-0d78-0550-4e9ef213f9c6@csgroup.eu>
On 12/14/21 20:32, Christophe Leroy wrote:
>
>
> Le 14/12/2021 à 19:23, Paul Moore a écrit :
>> On Tue, Dec 14, 2021 at 12:59 PM Christophe Leroy
>> <christophe.leroy@csgroup.eu> wrote:
>>> Hello Paul,
>>>
>>> I've been trying to setup your test suite on my powerpc board but it's
>>> based on Perl and on a lot of optional Perl packages. I was able to add
>>> them one by one until some of them require some .so libraries
>>> (Pathtools-Cwd), and it seems nothing is made to allow cross building
>>> those libraries.
>>>
>>> Do you have another test suite based on C and not perl ?
>>>
>>> If not, what can I do, do you know how I can cross compile those Perl
>>> packages for PPC32 ?
>>
>> Is there no Linux distribution that supports PPC32? I would think
>> that would be the easiest path forward, but you're the PPC32 expert -
>> not me - so I'll assume you already tried that or it didn't work for
>> other reasons.
>
> There hasn't been Linux distribution supporting PPC32 for a few years
> now. And regardless, the boards I'm running Linux on are home made
> embedded boards, with limited amount of memory and flashdisk space and
> no video chip, so they are hardly supported by any distributions, even
> older ones.
We still have debian. you will find images under :
https://cdimage.debian.org/cdimage/ports/snapshots/2021-04-17/
and from there, you can update to unstable, which runs fine under
a mac99 QEMU machine.
Cheers,
C.
^ permalink raw reply
* Re: [patch V3 00/35] genirq/msi, PCI/MSI: Spring cleaning - Part 2
From: Nishanth Menon @ 2021-12-14 20: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,
linux-arm-kernel, Jason Gunthorpe, linux-pci, xen-devel,
Kevin Tian, Arnd Bergmann, Robin Murphy, Johannes Berg,
Alex Williamson, Cedric Le Goater, Santosh Shilimkar,
Bjorn Helgaas, Megha Dey, Laurentiu Tudor, Juergen Gross,
Tero Kristo, Greg Kroah-Hartman, linux-wireless, LKML, Vinod Koul,
Marc Zygnier, dmaengine, linuxppc-dev
In-Reply-To: <87mtl3rli1.ffs@tglx>
On 21:15-20211214, Thomas Gleixner wrote:
> Nishanth,
>
> On Tue, Dec 14 2021 at 18:03, Thomas Gleixner wrote:
> > msi_device_data_release()
> > ...
> > pcim_release()
> > pci_disable_msi[x]()
> >
> > Groan....
>
> I think I managed to distangle this. Can you please give:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git msi-v4-part-2
Umm.. I am not entirely sure what is going on.. but all kinds of weird
corruption seems to occur with msi-v4-part-2 that does'nt seem to be
present in v5.16-rc5. (I use NFS since ethernet in K3 platforms use
inta/intr and dma that is impacted by this series).
I will try and rebase your patches on v5.16-rc4 to be sure as well and
report back later today once i get some time.
[1] https://gist.github.com/nmenon/a66e022926c4c15313c45d44313d860c msi-v4-part-2
[2] https://gist.github.com/nmenon/43085664d69ad846d596e76a06ed0656 v5.16-rc5
--
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: Thomas Gleixner @ 2021-12-14 21:19 UTC (permalink / raw)
To: Nishanth Menon
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, Johannes Berg,
Alex Williamson, Cedric Le Goater, Santosh Shilimkar,
Bjorn Helgaas, Megha Dey, Laurentiu Tudor, Juergen Gross,
Tero Kristo, Greg Kroah-Hartman, linux-wireless, LKML, Vinod Koul,
Marc Zygnier, dmaengine, linuxppc-dev
In-Reply-To: <20211214205626.lrnddha6bd6d6es5@possibly>
Nishanth,
On Tue, Dec 14 2021 at 14:56, Nishanth Menon wrote:
> On 21:15-20211214, Thomas Gleixner wrote:
>> I think I managed to distangle this. Can you please give:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git msi-v4-part-2
>
>
> Umm.. I am not entirely sure what is going on.. but all kinds of weird
> corruption seems to occur with msi-v4-part-2 that does'nt seem to be
> present in v5.16-rc5. (I use NFS since ethernet in K3 platforms use
> inta/intr and dma that is impacted by this series).
>
> I will try and rebase your patches on v5.16-rc4 to be sure as well and
> report back later today once i get some time.
>
> [1] https://gist.github.com/nmenon/a66e022926c4c15313c45d44313d860c msi-v4-part-2
> [2] https://gist.github.com/nmenon/43085664d69ad846d596e76a06ed0656 v5.16-rc5
thanks for trying. I'll have a look again with brain awake tomorrow
morning.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH] selftests/powerpc/spectre_v2: Return skip code when miss_percent is high
From: Michael Ellerman @ 2021-12-15 0:24 UTC (permalink / raw)
To: linuxppc-dev, Thadeu Lima de Souza Cascardo; +Cc: linux-kselftest
In-Reply-To: <20211207130557.40566-1-cascardo@canonical.com>
On Tue, 7 Dec 2021 10:05:57 -0300, Thadeu Lima de Souza Cascardo wrote:
> A mis-match between reported and actual mitigation is not restricted to the
> Vulnerable case. The guest might also report the mitigation as "Software
> count cache flush" and the host will still mitigate with branch cache
> disabled.
>
> So, instead of skipping depending on the detected mitigation, simply skip
> whenever the detected miss_percent is the expected one for a fully
> mitigated system, that is, above 95%.
>
> [...]
Applied to powerpc/next.
[1/1] selftests/powerpc/spectre_v2: Return skip code when miss_percent is high
https://git.kernel.org/powerpc/c/3c42e9542050d49610077e083c7c3f5fd5e26820
cheers
^ permalink raw reply
* Re: [PATCH] powerpc: platforms: cell: pervasive: fix clang -Wimplicit-fallthrough
From: Michael Ellerman @ 2021-12-15 0:24 UTC (permalink / raw)
To: arnd, Anders Roxell
Cc: Naresh Kamboju, llvm, ndesaulniers, linux-kernel, nathan,
linuxppc-dev
In-Reply-To: <20211207110228.698956-1-anders.roxell@linaro.org>
On Tue, 7 Dec 2021 12:02:28 +0100, Anders Roxell wrote:
> Clang warns:
>
> arch/powerpc/platforms/cell/pervasive.c:81:2: error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
> case SRR1_WAKEEE:
> ^
> arch/powerpc/platforms/cell/pervasive.c:81:2: note: insert 'break;' to avoid fall-through
> case SRR1_WAKEEE:
> ^
> break;
> 1 error generated.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc: platforms: cell: pervasive: fix clang -Wimplicit-fallthrough
https://git.kernel.org/powerpc/c/e89257e28e844f5d1d39081bb901d9f1183a7705
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/32s: Allocate one 256k IBAT instead of two consecutives 128k IBATs
From: Michael Ellerman @ 2021-12-15 0:24 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Michael Ellerman, Christophe Leroy,
Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <ab58b296832b0ec650e2203200e060adbcb2677d.1637930421.git.christophe.leroy@csgroup.eu>
On Fri, 26 Nov 2021 13:40:35 +0100, Christophe Leroy wrote:
> Today we have the following IBATs allocated:
>
> ---[ Instruction Block Address Translation ]---
> 0: 0xc0000000-0xc03fffff 0x00000000 4M Kernel x m
> 1: 0xc0400000-0xc05fffff 0x00400000 2M Kernel x m
> 2: 0xc0600000-0xc06fffff 0x00600000 1M Kernel x m
> 3: 0xc0700000-0xc077ffff 0x00700000 512K Kernel x m
> 4: 0xc0780000-0xc079ffff 0x00780000 128K Kernel x m
> 5: 0xc07a0000-0xc07bffff 0x007a0000 128K Kernel x m
> 6: -
> 7: -
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/32s: Allocate one 256k IBAT instead of two consecutives 128k IBATs
https://git.kernel.org/powerpc/c/37eb7ca91b692e8e49e7dd50158349a6c8fb5b09
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/powermac: Add additional missing lockdep_register_key()
From: Michael Ellerman @ 2021-12-15 0:24 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Michael Ellerman, Christophe Leroy,
Paul Mackerras
Cc: Erhard Furtner, linuxppc-dev, linux-kernel
In-Reply-To: <2c7e421874e21b2fb87813d768cf662f630c2ad4.1638984999.git.christophe.leroy@csgroup.eu>
On Wed, 8 Dec 2021 17:36:52 +0000, Christophe Leroy wrote:
> Commit df1f679d19ed ("powerpc/powermac: Add missing
> lockdep_register_key()") fixed a problem that was causing a WARNING.
>
> There are two other places in the same file with the same problem
> originating from commit 9e607f72748d ("i2c_powermac: shut up lockdep
> warning").
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/powermac: Add additional missing lockdep_register_key()
https://git.kernel.org/powerpc/c/b149d5d45ac9171ed699a256f026c8ebef901112
cheers
^ permalink raw reply
* Re: [PATCH v3 00/22] powerpc: Add KUAP support for BOOKE and 40x
From: Michael Ellerman @ 2021-12-15 0:24 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Michael Ellerman, Christophe Leroy,
Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <cover.1634627931.git.christophe.leroy@csgroup.eu>
On Tue, 19 Oct 2021 09:29:11 +0200, Christophe Leroy wrote:
> On booke/40x we don't have segments like book3s/32.
> On booke/40x we don't have access protection groups like 8xx.
>
> Use the PID register to provide user access protection.
> Kernel address space can be accessed with any PID.
> User address space has to be accessed with the PID of the user.
> User PID is always not null.
>
> [...]
Applied to powerpc/next.
[01/22] Revert "powerpc: Inline setup_kup()"
https://git.kernel.org/powerpc/c/6c1fa60d368e6b752e1612eae9bb0970e85392b2
[02/22] powerpc/8xx: Activate KUEP at all time
https://git.kernel.org/powerpc/c/13dac4e31e75ce10b2fcaad4432a24dae6c955f6
[03/22] powerpc/44x: Activate KUEP at all time
https://git.kernel.org/powerpc/c/ee2631603fdbab6f76e86ea87f7a03ebc3a1ef85
[04/22] powerpc/book3e: Activate KUEP at all time
https://git.kernel.org/powerpc/c/dc3a0e5b83a8806d7da1f343a7d2e0be386d16d2
[05/22] powerpc/32s: Remove capability to disable KUEP at boottime
https://git.kernel.org/powerpc/c/df415cd758261bceff27f34a145dd8328bbfb018
[06/22] powerpc/32s: Do kuep_lock() and kuep_unlock() in assembly
https://git.kernel.org/powerpc/c/526d4a4c77aedf1b7df1133e5cced29c70232e6e
[07/22] powerpc/32s: Save content of sr0 to avoid 'mfsr'
https://git.kernel.org/powerpc/c/70428da94c7ad692d306747a04117543827292a7
[08/22] powerpc/kuep: Remove 'nosmep' boot time parameter except for book3s/64
https://git.kernel.org/powerpc/c/6754862249d324b11f1361a5353e234325d805ec
[09/22] powerpc/kuap: Add a generic intermediate layer
https://git.kernel.org/powerpc/c/ba454f9c8e4efcc47c772b7642a5c8c6d1343cbf
[10/22] powerpc/kuap: Check KUAP activation in generic functions
https://git.kernel.org/powerpc/c/c252f3846d3114542c606618995e3cbc11775357
[11/22] powerpc/kuap: Remove __kuap_assert_locked()
https://git.kernel.org/powerpc/c/2341964e27b02b2ca1deef8a18df59d1db7b9085
[12/22] powerpc/kuap: Add kuap_lock()
https://git.kernel.org/powerpc/c/937fb7003ee1f37faed1f1a4ece46e8a14863d92
[13/22] powerpc/nohash: Move setup_kuap out of 8xx.c
https://git.kernel.org/powerpc/c/25ae981fafaa140a12e4c830992b4fe997071124
[14/22] powerpc/config: Add CONFIG_BOOKE_OR_40x
https://git.kernel.org/powerpc/c/047a6fd40199eb55ffd18091f7ceae9743d972bf
[15/22] powerpc/kuap: Prepare for supporting KUAP on BOOK3E/64
https://git.kernel.org/powerpc/c/42e03bc5240b75007682d9941ef672d12828fc70
[16/22] powerpc/kuap: Make PPC_KUAP_DEBUG depend on PPC_KUAP only
https://git.kernel.org/powerpc/c/e3c02f25b4296c48376b8edb6aadcec460e803bc
[17/22] powerpc: Add KUAP support for BOOKE and 40x
https://git.kernel.org/powerpc/c/43afcf8f0101279cf4243bb4f9f9b249ddd8613c
[18/22] powerpc/kuap: Wire-up KUAP on 44x
https://git.kernel.org/powerpc/c/f6fad4fb55936f0d613cea08341d187d691d6440
[19/22] powerpc/kuap: Wire-up KUAP on 40x
https://git.kernel.org/powerpc/c/fcf9bb6d32f8a268bc3daf3281e3beefabec4e7c
[20/22] powerpc/kuap: Wire-up KUAP on 85xx in 32 bits mode.
https://git.kernel.org/powerpc/c/4f6a025201a290316b28a2a0ef9950398bd75088
[21/22] powerpc/kuap: Wire-up KUAP on book3e/64
https://git.kernel.org/powerpc/c/57bc963837f5f1753a1d51fada54a32b8a84fdc3
[22/22] powerpc: Remove CONFIG_PPC_HAVE_KUAP and CONFIG_PPC_HAVE_KUEP
https://git.kernel.org/powerpc/c/dede19be5163cdc5b5d65a2ce7e7f6eedcb666ff
cheers
^ permalink raw reply
* Re: [PATCH v5 1/5] powerpc/inst: Refactor ___get_user_instr()
From: Michael Ellerman @ 2021-12-15 0:24 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Michael Ellerman, Christophe Leroy,
Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1f0ede830ccb33a659119a55cb590820c27004db.1638208156.git.christophe.leroy@csgroup.eu>
On Mon, 29 Nov 2021 18:49:37 +0100, Christophe Leroy wrote:
> PPC64 version of ___get_user_instr() can be used for PPC32 as well,
> by simply disabling the suffix part with IS_ENABLED(CONFIG_PPC64).
>
>
Applied to powerpc/next.
[1/5] powerpc/inst: Refactor ___get_user_instr()
https://git.kernel.org/powerpc/c/3261d99adba269a024d0e55737beeedec5eba00e
[2/5] powerpc/inst: Define ppc_inst_t
https://git.kernel.org/powerpc/c/c545b9f040f341038d5228932140fb17e0c156e2
[3/5] powerpc/inst: Define ppc_inst_t as u32 on PPC32
https://git.kernel.org/powerpc/c/07b863aef5b682a482474b524f3df4957d2862ac
[4/5] powerpc/inst: Move ppc_inst_t definition in asm/reg.h
https://git.kernel.org/powerpc/c/9b307576f37136d37d5e42b1d8713ec34a601a62
[5/5] powerpc/inst: Optimise copy_inst_from_kernel_nofault()
https://git.kernel.org/powerpc/c/0d76914a4c99ab5658f3fb07cdf3799d28e2eab3
cheers
^ permalink raw reply
* Re: [PATCH v2] powerpc/40x: Map 32Mbytes of memory at startup
From: Michael Ellerman @ 2021-12-15 0:24 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Michael Ellerman, Christophe Leroy,
Paul Mackerras
Cc: cp, linuxppc-dev, linux-kernel
In-Reply-To: <89b5f974a7fa5011206682cd092e2c905530ff46.1632755552.git.christophe.leroy@csgroup.eu>
On Mon, 27 Sep 2021 17:12:39 +0200, Christophe Leroy wrote:
> As reported by Carlo, 16Mbytes is not enough with modern kernels
> that tend to be a bit big, so map another 16M page at boot.
>
>
Applied to powerpc/next.
[1/1] powerpc/40x: Map 32Mbytes of memory at startup
https://git.kernel.org/powerpc/c/06e7cbc29e97b4713b4ea6def04ae8501a7d1a59
cheers
^ permalink raw reply
* Re: [PATCH v3 1/2] powerpc: handle kdump appropriately with crash_kexec_post_notifiers option
From: Michael Ellerman @ 2021-12-15 0:24 UTC (permalink / raw)
To: mpe, linuxppc-dev, Hari Bathini, npiggin
Cc: mahesh, sourabhjain, kernel test robot
In-Reply-To: <20211207103719.91117-1-hbathini@linux.ibm.com>
On Tue, 7 Dec 2021 16:07:18 +0530, Hari Bathini wrote:
> Kdump can be triggered after panic_notifers since commit f06e5153f4ae2
> ("kernel/panic.c: add "crash_kexec_post_notifiers" option for kdump
> after panic_notifers") introduced crash_kexec_post_notifiers option.
> But using this option would mean smp_send_stop(), that marks all other
> CPUs as offline, gets called before kdump is triggered. As a result,
> kdump routines fail to save other CPUs' registers. To fix this, kdump
> friendly crash_smp_send_stop() function was introduced with kernel
> commit 0ee59413c967 ("x86/panic: replace smp_send_stop() with kdump
> friendly version in panic path"). Override this kdump friendly weak
> function to handle crash_kexec_post_notifiers option appropriately
> on powerpc.
>
> [...]
Applied to powerpc/next.
[1/2] powerpc: handle kdump appropriately with crash_kexec_post_notifiers option
https://git.kernel.org/powerpc/c/219572d2fc4135b5ce65c735d881787d48b10e71
[2/2] ppc64/fadump: fix inaccurate CPU state info in vmcore generated with panic
https://git.kernel.org/powerpc/c/06e629c25daa519be620a8c17359ae8fc7a2e903
cheers
^ 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