* Re: [PATCH v4 0/3] mm, treewide: Rename kzfree() to kfree_sensitive()
From: Denis Efremov @ 2020-06-17 21:31 UTC (permalink / raw)
To: Joe Perches, Waiman Long, Andrew Morton, David Howells,
Jarkko Sakkinen, James Morris, Serge E. Hallyn, Linus Torvalds,
Matthew Wilcox, David Rientjes
Cc: Jason A . Donenfeld, Michal Hocko, linux-btrfs, linux-kernel,
linux-mm, linux-sctp, target-devel, linux-stm32, devel,
linux-cifs, linux-scsi, kasan-dev, linux-wpan, Dan Carpenter,
linux-pm, ecryptfs, linux-fscrypt, linux-mediatek, linux-amlogic,
virtualization, linux-nfs, netdev, linux-wireless, David Sterba,
linux-bluetooth, linux-security-module, keyrings, tipc-discussion,
linux-crypto, Johannes Weiner, linux-integrity, linuxppc-dev,
wireguard, linux-ppp
In-Reply-To: <fe3b9a437be4aeab3bac68f04193cb6daaa5bee4.camel@perches.com>
On 6/16/20 9:53 PM, Joe Perches wrote:
> On Mon, 2020-06-15 at 21:57 -0400, Waiman Long wrote:
>> v4:
>> - Break out the memzero_explicit() change as suggested by Dan Carpenter
>> so that it can be backported to stable.
>> - Drop the "crypto: Remove unnecessary memzero_explicit()" patch for
>> now as there can be a bit more discussion on what is best. It will be
>> introduced as a separate patch later on after this one is merged.
>
> To this larger audience and last week without reply:
> https://lore.kernel.org/lkml/573b3fbd5927c643920e1364230c296b23e7584d.camel@perches.com/
>
> Are there _any_ fastpath uses of kfree or vfree?
>
> Many patches have been posted recently to fix mispairings
> of specific types of alloc and free functions.
I've prepared a coccinelle script to highlight these mispairings in a function
a couple of days ago: https://lkml.org/lkml/2020/6/5/953
I've listed all the fixes in the commit message.
Not so many mispairings actually, and most of them are harmless like:
kmalloc(E) -> kvfree(E)
However, coccinelle script can't detect cross-functions mispairings, i.e.
allocation in one function, free in another funtion.
Thanks,
Denis
^ permalink raw reply
* Re: [PATCH v4 0/3] mm, treewide: Rename kzfree() to kfree_sensitive()
From: Joe Perches @ 2020-06-17 23:12 UTC (permalink / raw)
To: Denis Efremov, Waiman Long, Andrew Morton, David Howells,
Jarkko Sakkinen, James Morris, Serge E. Hallyn, Linus Torvalds,
Matthew Wilcox, David Rientjes
Cc: Jason A . Donenfeld, Michal Hocko, linux-btrfs, linux-kernel,
linux-mm, linux-sctp, target-devel, linux-stm32, devel,
linux-cifs, linux-scsi, kasan-dev, linux-wpan, Dan Carpenter,
linux-pm, ecryptfs, linux-fscrypt, linux-mediatek, linux-amlogic,
virtualization, linux-nfs, netdev, linux-wireless, David Sterba,
linux-bluetooth, linux-security-module, keyrings, tipc-discussion,
linux-crypto, Johannes Weiner, linux-integrity, linuxppc-dev,
wireguard, linux-ppp
In-Reply-To: <17e4fede-bab0-d93c-6964-69decc889d7d@ispras.ru>
On Thu, 2020-06-18 at 00:31 +0300, Denis Efremov wrote:
>
> On 6/16/20 9:53 PM, Joe Perches wrote:
> > On Mon, 2020-06-15 at 21:57 -0400, Waiman Long wrote:
> > > v4:
> > > - Break out the memzero_explicit() change as suggested by Dan Carpenter
> > > so that it can be backported to stable.
> > > - Drop the "crypto: Remove unnecessary memzero_explicit()" patch for
> > > now as there can be a bit more discussion on what is best. It will be
> > > introduced as a separate patch later on after this one is merged.
> >
> > To this larger audience and last week without reply:
> > https://lore.kernel.org/lkml/573b3fbd5927c643920e1364230c296b23e7584d.camel@perches.com/
> >
> > Are there _any_ fastpath uses of kfree or vfree?
> >
> > Many patches have been posted recently to fix mispairings
> > of specific types of alloc and free functions.
>
> I've prepared a coccinelle script to highlight these mispairings in a function
> a couple of days ago: https://lkml.org/lkml/2020/6/5/953
> I've listed all the fixes in the commit message.
>
> Not so many mispairings actually, and most of them are harmless like:
> kmalloc(E) -> kvfree(E)
>
> However, coccinelle script can't detect cross-functions mispairings, i.e.
> allocation in one function, free in another funtion.
Hey Denis, thanks for those patches.
If possible, it's probably better to not require these pairings
and use a single standard kfree/free function.
Given the existing ifs in kfree in slab/slob/slub, it seems
likely that adding a few more wouldn't have much impact.
^ permalink raw reply
* Re: [v1 PATCH 2/2] Add Documentation regarding the ima-kexec-buffer node in the chosen node documentation
From: Rob Herring @ 2020-06-17 20:43 UTC (permalink / raw)
To: Prakhar Srivastava
Cc: kstewart, mark.rutland, gregkh, bhsharma, tao.li, zohar, paulus,
vincenzo.frascino, will, nramas, frowand.list, masahiroy, jmorris,
takahiro.akashi, linux-arm-kernel, catalin.marinas, serge,
devicetree, pasha.tatashin, hsinyi, tusharsu, tglx, allison,
christophe.leroy, mbrugger, balajib, dmitry.kasatkin,
linux-kernel, linux-security-module, james.morse, linux-integrity,
linuxppc-dev
In-Reply-To: <20200607233323.22375-3-prsriva@linux.microsoft.com>
On Sun, Jun 07, 2020 at 04:33:23PM -0700, Prakhar Srivastava wrote:
> Add Documentation regarding the ima-kexec-buffer node in
> the chosen node documentation
Run 'git log --oneline Documentation/devicetree/bindings/chosen.txt' and
write $subject using the dominate format used.
For the commit message, answer why you need the change, not what the
change is. I can read the diff for that.
>
> Signed-off-by: Prakhar Srivastava <prsriva@linux.microsoft.com>
> ---
> Documentation/devicetree/bindings/chosen.txt | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
This file has moved to a schema here[1]. You need to update it.
>
> diff --git a/Documentation/devicetree/bindings/chosen.txt b/Documentation/devicetree/bindings/chosen.txt
> index 45e79172a646..a15f70c007ef 100644
> --- a/Documentation/devicetree/bindings/chosen.txt
> +++ b/Documentation/devicetree/bindings/chosen.txt
> @@ -135,3 +135,20 @@ e.g.
> linux,initrd-end = <0x82800000>;
> };
> };
> +
> +linux,ima-kexec-buffer
> +----------------------
> +
> +This property(currently used by powerpc, arm64) holds the memory range,
> +the address and the size, of the IMA measurement logs that are being carried
> +over to the kexec session.
What's IMA?
> +
> +/ {
> + chosen {
> + linux,ima-kexec-buffer = <0x9 0x82000000 0x0 0x00008000>;
> + };
> +};
> +
> +This porperty does not represent real hardware, but the memory allocated for
typo
> +carrying the IMA measurement logs. The address and the suze are expressed in
typo
> +#address-cells and #size-cells, respectively of the root node.
> --
> 2.25.1
>
[1] https://github.com/devicetree-org/dt-schema/blob/master/schemas/chosen.yaml
^ permalink raw reply
* Re: [PATCH v5 01/13] powerpc: Remove Xilinx PPC405/PPC440 support
From: Nick Desaulniers @ 2020-06-17 18:16 UTC (permalink / raw)
To: Michael Ellerman
Cc: Arnd Bergmann, Michal Simek, LKML, clang-built-linux,
Paul Mackerras, Nathan Chancellor, linuxppc-dev
In-Reply-To: <878sgmdmcv.fsf@mpe.ellerman.id.au>
On Wed, Jun 17, 2020 at 3:20 AM Michael Ellerman <mpe@ellerman.id.au> wrote:
>
> Michael Ellerman <mpe@ellerman.id.au> writes:
> > Michal Simek <michal.simek@xilinx.com> writes:
> <snip>
>
> >> Or if bamboo requires uImage to be built by default you can do it via
> >> Kconfig.
> >>
> >> diff --git a/arch/powerpc/platforms/44x/Kconfig
> >> b/arch/powerpc/platforms/44x/Kconfig
> >> index 39e93d23fb38..300864d7b8c9 100644
> >> --- a/arch/powerpc/platforms/44x/Kconfig
> >> +++ b/arch/powerpc/platforms/44x/Kconfig
> >> @@ -13,6 +13,7 @@ config BAMBOO
> >> select PPC44x_SIMPLE
> >> select 440EP
> >> select FORCE_PCI
> >> + select DEFAULT_UIMAGE
> >> help
> >> This option enables support for the IBM PPC440EP evaluation board.
> >
> > Who knows what the actual bamboo board used. But I'd be happy to take a
> > SOB'ed patch to do the above, because these days the qemu emulation is
> > much more likely to be used than the actual board.
>
> I just went to see why my CI boot of 44x didn't catch this, and it's
> because I don't use the uImage, I just boot the vmlinux directly:
>
> $ qemu-system-ppc -M bamboo -m 128m -display none -kernel build~/vmlinux -append "console=ttyS0" -display none -nodefaults -serial mon:stdio
> Linux version 5.8.0-rc1-00118-g69119673bd50 (michael@alpine1-p1) (gcc (Ubuntu 9.3.0-10ubuntu2) 9.3.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #4 Wed Jun 17 20:19:22 AEST 2020
> Using PowerPC 44x Platform machine description
> ioremap() called early from find_legacy_serial_ports+0x690/0x770. Use early_ioremap() instead
> printk: bootconsole [udbg0] enabled
>
>
> So that's probably the simplest solution?
If the uImage or zImage self decompresses, I would prefer to test that as well.
> That means previously arch/powerpc/boot/zImage was just a hardlink to
> the uImage:
It sounds like we can just boot the zImage, or is that no longer
created with the uImage?
--
Thanks,
~Nick Desaulniers
^ permalink raw reply
* [PATCH v2 0/2] powerpc/pci: unmap interrupts when a PHB is removed
From: Cédric Le Goater @ 2020-06-17 16:29 UTC (permalink / raw)
To: Michael Ellerman
Cc: linuxppc-dev, Oliver O'Halloran, Cédric Le Goater
Hello,
When a passthrough IO adapter is removed from a pseries machine using
hash MMU and the XIVE interrupt mode, the POWER hypervisor expects the
guest OS to clear all page table entries related to the adapter. If
some are still present, the RTAS call which isolates the PCI slot
returns error 9001 "valid outstanding translations" and the removal of
the IO adapter fails. This is because when the PHBs are scanned, Linux
maps automatically some interrupts in the Linux interrupt number space
but these are never removed.
To solve this problem, we introduce a PPC platform specific
pcibios_remove_bus() routine which clears all interrupt mappings when
the bus is removed. This also clears the associated page table entries
of the ESB pages when using XIVE.
For this purpose, we record the logical interrupt numbers of the
mapped interrupt under the PHB structure and let pcibios_remove_bus()
do the clean up.
Tested on :
- PowerNV with PCI, OpenCAPI, CAPI and GPU adapters. I don't know
how to inject a failure on a PHB but that would be a good test.
- KVM P8+P9 guests with passthrough PCI adapters, but PHBs can not
be removed under QEMU/KVM.
- PowerVM with passthrough PCI adapters (main target)
Thanks,
C.
Changes since v1:
- extended the removal to interrupts other than the legacy INTx.
Cédric Le Goater (2):
powerpc/pci: unmap legacy INTx interrupts when a PHB is removed
powerpc/pci: unmap all interrupts when a PHB is removed
arch/powerpc/include/asm/pci-bridge.h | 6 ++
arch/powerpc/kernel/pci-common.c | 114 ++++++++++++++++++++++++++
2 files changed, 120 insertions(+)
--
2.25.4
^ permalink raw reply
* [PATCH v2 2/2] powerpc/pci: unmap all interrupts when a PHB is removed
From: Cédric Le Goater @ 2020-06-17 16:29 UTC (permalink / raw)
To: Michael Ellerman
Cc: linuxppc-dev, Oliver O'Halloran, Cédric Le Goater
In-Reply-To: <20200617162938.743439-1-clg@kaod.org>
Some PCI adapters, like GPUs, use the "interrupt-map" property to
describe interrupt mappings other than the legacy INTx interrupts.
There can be more than 4 mappings.
To clear all interrupts when a PHB is removed, we need to increase the
'irq_map' array in which mappings are recorded. Compute the number of
interrupt mappings from the "interrupt-map" property and allocate a
bigger 'irq_map' array.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
arch/powerpc/kernel/pci-common.c | 49 +++++++++++++++++++++++++++++++-
1 file changed, 48 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index 515480a4bac6..deb831f0ae13 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -353,9 +353,56 @@ struct pci_controller *pci_find_controller_for_domain(int domain_nr)
return NULL;
}
+/*
+ * Assumption is made on the interrupt parent. All interrupt-map
+ * entries are considered to have the same parent.
+ */
+static int pcibios_irq_map_count(struct pci_controller *phb)
+{
+ const __be32 *imap;
+ int imaplen;
+ struct device_node *parent;
+ u32 intsize, addrsize, parintsize, paraddrsize;
+
+ if (of_property_read_u32(phb->dn, "#interrupt-cells", &intsize))
+ return 0;
+ if (of_property_read_u32(phb->dn, "#address-cells", &addrsize))
+ return 0;
+
+ imap = of_get_property(phb->dn, "interrupt-map", &imaplen);
+ if (!imap) {
+ pr_debug("%pOF : no interrupt-map\n", phb->dn);
+ return 0;
+ }
+ imaplen /= sizeof(u32);
+ pr_debug("%pOF : imaplen=%d\n", phb->dn, imaplen);
+
+ if (imaplen < (addrsize + intsize + 1))
+ return 0;
+
+ imap += intsize + addrsize;
+ parent = of_find_node_by_phandle(be32_to_cpup(imap));
+ if (!parent) {
+ pr_debug("%pOF : no imap parent found !\n", phb->dn);
+ return 0;
+ }
+
+ if (of_property_read_u32(parent, "#interrupt-cells", &parintsize)) {
+ pr_debug("%pOF : parent lacks #interrupt-cells!\n", phb->dn);
+ return 0;
+ }
+
+ if (of_property_read_u32(parent, "#address-cells", ¶ddrsize))
+ paraddrsize = 0;
+
+ return imaplen / (addrsize + intsize + 1 + paraddrsize + parintsize);
+}
+
static void pcibios_irq_map_init(struct pci_controller *phb)
{
- phb->irq_count = PCI_NUM_INTX;
+ phb->irq_count = pcibios_irq_map_count(phb);
+ if (phb->irq_count < PCI_NUM_INTX)
+ phb->irq_count = PCI_NUM_INTX;
pr_debug("%pOF : interrupt map #%d\n", phb->dn, phb->irq_count);
--
2.25.4
^ permalink raw reply related
* [PATCH v2 1/2] powerpc/pci: unmap legacy INTx interrupts when a PHB is removed
From: Cédric Le Goater @ 2020-06-17 16:29 UTC (permalink / raw)
To: Michael Ellerman
Cc: linuxppc-dev, Oliver O'Halloran, Cédric Le Goater
In-Reply-To: <20200617162938.743439-1-clg@kaod.org>
When a passthrough IO adapter is removed from a pseries machine using
hash MMU and the XIVE interrupt mode, the POWER hypervisor expects the
guest OS to clear all page table entries related to the adapter. If
some are still present, the RTAS call which isolates the PCI slot
returns error 9001 "valid outstanding translations" and the removal of
the IO adapter fails. This is because when the PHBs are scanned, Linux
maps automatically the INTx interrupts in the Linux interrupt number
space but these are never removed.
To solve this problem, we introduce a PPC platform specific
pcibios_remove_bus() routine which clears all interrupt mappings when
the bus is removed. This also clears the associated page table entries
of the ESB pages when using XIVE.
For this purpose, we record the logical interrupt numbers of the
mapped interrupt under the PHB structure and let pcibios_remove_bus()
do the clean up.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
arch/powerpc/include/asm/pci-bridge.h | 6 +++
arch/powerpc/kernel/pci-common.c | 67 +++++++++++++++++++++++++++
2 files changed, 73 insertions(+)
diff --git a/arch/powerpc/include/asm/pci-bridge.h b/arch/powerpc/include/asm/pci-bridge.h
index b92e81b256e5..ca75cf264ddf 100644
--- a/arch/powerpc/include/asm/pci-bridge.h
+++ b/arch/powerpc/include/asm/pci-bridge.h
@@ -48,6 +48,9 @@ struct pci_controller_ops {
/*
* Structure of a PCI controller (host bridge)
+ *
+ * @irq_count: number of interrupt mappings
+ * @irq_map: interrupt mappings
*/
struct pci_controller {
struct pci_bus *bus;
@@ -127,6 +130,9 @@ struct pci_controller {
void *private_data;
struct npu *npu;
+
+ unsigned int irq_count;
+ unsigned int *irq_map;
};
/* These are used for config access before all the PCI probing
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index be108616a721..515480a4bac6 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -353,6 +353,68 @@ struct pci_controller *pci_find_controller_for_domain(int domain_nr)
return NULL;
}
+static void pcibios_irq_map_init(struct pci_controller *phb)
+{
+ phb->irq_count = PCI_NUM_INTX;
+
+ pr_debug("%pOF : interrupt map #%d\n", phb->dn, phb->irq_count);
+
+ phb->irq_map = kcalloc(phb->irq_count, sizeof(unsigned int),
+ GFP_KERNEL);
+}
+
+static void pci_irq_map_register(struct pci_dev *pdev, unsigned int virq)
+{
+ struct pci_controller *phb = pci_bus_to_host(pdev->bus);
+ int i;
+
+ if (!phb->irq_map)
+ return;
+
+ for (i = 0; i < phb->irq_count; i++) {
+ /*
+ * Look for an empty or an equivalent slot, as INTx
+ * interrupts can be shared between adapters.
+ */
+ if (phb->irq_map[i] == virq || !phb->irq_map[i]) {
+ phb->irq_map[i] = virq;
+ break;
+ }
+ }
+
+ if (i == phb->irq_count)
+ pr_err("PCI:%s all platform interrupts mapped\n",
+ pci_name(pdev));
+}
+
+/*
+ * Clearing the mapped interrupts will also clear the underlying
+ * mappings of the ESB pages of the interrupts when under XIVE. It is
+ * a requirement of PowerVM to clear all memory mappings before
+ * removing a PHB.
+ */
+static void pci_irq_map_dispose(struct pci_bus *bus)
+{
+ struct pci_controller *phb = pci_bus_to_host(bus);
+ int i;
+
+ if (!phb->irq_map)
+ return;
+
+ pr_debug("PCI: Clearing interrupt mappings for PHB %04x:%02x...\n",
+ pci_domain_nr(bus), bus->number);
+ for (i = 0; i < phb->irq_count; i++)
+ irq_dispose_mapping(phb->irq_map[i]);
+
+ kfree(phb->irq_map);
+}
+
+void pcibios_remove_bus(struct pci_bus *bus)
+{
+ pci_irq_map_dispose(bus);
+}
+EXPORT_SYMBOL_GPL(pcibios_remove_bus);
+
/*
* Reads the interrupt pin to determine if interrupt is use by card.
* If the interrupt is used, then gets the interrupt line from the
@@ -401,6 +463,8 @@ static int pci_read_irq_line(struct pci_dev *pci_dev)
pci_dev->irq = virq;
+ /* Record all interrut mappings for later removal of a PHB */
+ pci_irq_map_register(pci_dev, virq);
return 0;
}
@@ -1554,6 +1618,9 @@ void pcibios_scan_phb(struct pci_controller *hose)
pr_debug("PCI: Scanning PHB %pOF\n", node);
+ /* Allocate interrupt mappings array */
+ pcibios_irq_map_init(hose);
+
/* Get some IO space for the new PHB */
pcibios_setup_phb_io_space(hose);
--
2.25.4
^ permalink raw reply related
* Re: [PATCH 3/3] powerpc/8xx: Provide ptep_get() with 16k pages
From: Christophe Leroy @ 2020-06-17 14:45 UTC (permalink / raw)
To: Peter Zijlstra, Michael Ellerman
Cc: Will Deacon, linux-kernel, linux-mm, Paul Mackerras,
Andrew Morton, linuxppc-dev
In-Reply-To: <20200617143826.GJ2531@hirez.programming.kicks-ass.net>
Le 17/06/2020 à 16:38, Peter Zijlstra a écrit :
> On Thu, Jun 18, 2020 at 12:21:22AM +1000, Michael Ellerman wrote:
>> Peter Zijlstra <peterz@infradead.org> writes:
>>> On Mon, Jun 15, 2020 at 12:57:59PM +0000, Christophe Leroy wrote:
>
>>>> +#if defined(CONFIG_PPC_8xx) && defined(CONFIG_PPC_16K_PAGES)
>>>> +#define __HAVE_ARCH_PTEP_GET
>>>> +static inline pte_t ptep_get(pte_t *ptep)
>>>> +{
>>>> + pte_t pte = {READ_ONCE(ptep->pte), 0, 0, 0};
>>>> +
>>>> + return pte;
>>>> +}
>>>> +#endif
>>>
>>> Would it make sense to have a comment with this magic? The casual reader
>>> might wonder WTH just happened when he stumbles on this :-)
>>
>> I tried writing a helpful comment but it's too late for my brain to form
>> sensible sentences.
>>
>> Christophe can you send a follow-up with a comment explaining it? In
>> particular the zero entries stand out, it's kind of subtle that those
>> entries are only populated with the right value when we write to the
>> page table.
>
> static inline pte_t ptep_get(pte_t *ptep)
> {
> unsigned long val = READ_ONCE(ptep->pte);
> /* 16K pages have 4 identical value 4K entries */
> pte_t pte = {val, val, val, val);
> return pte;
> }
>
> Maybe something like that?
>
This should work as well. Indeed nobody cares about what's in the other
three. They are only there to ensure that ptep++ increases the ptep
pointer by 16 bytes. Only the HW require 4 identical values, that's
taken care of in set_pte_at() and pte_update().
So we should use the most efficient. Thinking once more, maybe what you
propose is the most efficient as there is no need to load another
register with value 0 in order to write it in the stack.
Christophe
^ permalink raw reply
* Re: [PATCH 3/3] powerpc/8xx: Provide ptep_get() with 16k pages
From: Peter Zijlstra @ 2020-06-17 14:38 UTC (permalink / raw)
To: Michael Ellerman
Cc: linuxppc-dev, linux-kernel, linux-mm, Paul Mackerras,
Andrew Morton, Will Deacon
In-Reply-To: <87wo45db8d.fsf@mpe.ellerman.id.au>
On Thu, Jun 18, 2020 at 12:21:22AM +1000, Michael Ellerman wrote:
> Peter Zijlstra <peterz@infradead.org> writes:
> > On Mon, Jun 15, 2020 at 12:57:59PM +0000, Christophe Leroy wrote:
> >> +#if defined(CONFIG_PPC_8xx) && defined(CONFIG_PPC_16K_PAGES)
> >> +#define __HAVE_ARCH_PTEP_GET
> >> +static inline pte_t ptep_get(pte_t *ptep)
> >> +{
> >> + pte_t pte = {READ_ONCE(ptep->pte), 0, 0, 0};
> >> +
> >> + return pte;
> >> +}
> >> +#endif
> >
> > Would it make sense to have a comment with this magic? The casual reader
> > might wonder WTH just happened when he stumbles on this :-)
>
> I tried writing a helpful comment but it's too late for my brain to form
> sensible sentences.
>
> Christophe can you send a follow-up with a comment explaining it? In
> particular the zero entries stand out, it's kind of subtle that those
> entries are only populated with the right value when we write to the
> page table.
static inline pte_t ptep_get(pte_t *ptep)
{
unsigned long val = READ_ONCE(ptep->pte);
/* 16K pages have 4 identical value 4K entries */
pte_t pte = {val, val, val, val);
return pte;
}
Maybe something like that?
^ permalink raw reply
* Re: [PATCH 3/3] powerpc/8xx: Provide ptep_get() with 16k pages
From: Michael Ellerman @ 2020-06-17 14:21 UTC (permalink / raw)
To: Peter Zijlstra, Christophe Leroy
Cc: Will Deacon, linux-kernel, linux-mm, Paul Mackerras,
Andrew Morton, linuxppc-dev
In-Reply-To: <20200615132244.GR2531@hirez.programming.kicks-ass.net>
Peter Zijlstra <peterz@infradead.org> writes:
> On Mon, Jun 15, 2020 at 12:57:59PM +0000, Christophe Leroy wrote:
>> READ_ONCE() now enforces atomic read, which leads to:
>
>> Fixes: 2ab3a0a02905 ("READ_ONCE: Enforce atomicity for {READ,WRITE}_ONCE() memory accesses")
>> Cc: Will Deacon <will@kernel.org>
>> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
>> ---
>> arch/powerpc/include/asm/nohash/32/pgtable.h | 10 ++++++++++
>> 1 file changed, 10 insertions(+)
>>
>> diff --git a/arch/powerpc/include/asm/nohash/32/pgtable.h b/arch/powerpc/include/asm/nohash/32/pgtable.h
>> index b56f14160ae5..77addb599ce7 100644
>> --- a/arch/powerpc/include/asm/nohash/32/pgtable.h
>> +++ b/arch/powerpc/include/asm/nohash/32/pgtable.h
>> @@ -286,6 +286,16 @@ static inline pte_t ptep_get_and_clear(struct mm_struct *mm, unsigned long addr,
>> return __pte(pte_update(mm, addr, ptep, ~0, 0, 0));
>> }
>>
>> +#if defined(CONFIG_PPC_8xx) && defined(CONFIG_PPC_16K_PAGES)
>> +#define __HAVE_ARCH_PTEP_GET
>> +static inline pte_t ptep_get(pte_t *ptep)
>> +{
>> + pte_t pte = {READ_ONCE(ptep->pte), 0, 0, 0};
>> +
>> + return pte;
>> +}
>> +#endif
>
> Would it make sense to have a comment with this magic? The casual reader
> might wonder WTH just happened when he stumbles on this :-)
I tried writing a helpful comment but it's too late for my brain to form
sensible sentences.
Christophe can you send a follow-up with a comment explaining it? In
particular the zero entries stand out, it's kind of subtle that those
entries are only populated with the right value when we write to the
page table.
cheers
^ permalink raw reply
* Re: [PATCH 1/3] mm/gup: Use huge_ptep_get() in gup_hugepte()
From: Michael Ellerman @ 2020-06-17 14:14 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras,
Will Deacon, Andrew Morton, Peter Zijlstra (Intel)
Cc: linux-mm, linuxppc-dev, linux-kernel
In-Reply-To: <ffc3714334c3bfaca6f13788ad039e8759ae413f.1592225558.git.christophe.leroy@csgroup.eu>
Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> gup_hugepte() reads hugepage table entries, it can't read
> them directly, huge_ptep_get() must be used.
>
> Fixes: 2ab3a0a02905 ("READ_ONCE: Enforce atomicity for {READ,WRITE}_ONCE() memory accesses")
I see that commit in older versions of linux-next but not in mainline.
In mainline it seems to be: 9e343b467c70 ("READ_ONCE: Enforce atomicity for {READ,WRITE}_ONCE() memory accesses")
I guess it got rebased somewhere along the way.
I fixed it up when applying, and the other two as well.
cheers
> Cc: Will Deacon <will@kernel.org>
> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> ---
> mm/gup.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/gup.c b/mm/gup.c
> index de9e36262ccb..761df4944ef5 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -2425,7 +2425,7 @@ static int gup_hugepte(pte_t *ptep, unsigned long sz, unsigned long addr,
> if (pte_end < end)
> end = pte_end;
>
> - pte = READ_ONCE(*ptep);
> + pte = huge_ptep_get(ptep);
>
> if (!pte_access_permitted(pte, flags & FOLL_WRITE))
> return 0;
> --
> 2.25.0
^ permalink raw reply
* Re: [PATCH 0/3] Fix build failure with v5.8-rc1
From: Michael Ellerman @ 2020-06-17 14:13 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras,
Will Deacon, Andrew Morton, Peter Zijlstra (Intel)
Cc: linux-mm, linuxppc-dev, linux-kernel
In-Reply-To: <cover.1592225557.git.christophe.leroy@csgroup.eu>
Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> Commit 2ab3a0a02905 ("READ_ONCE: Enforce atomicity for
> {READ,WRITE}_ONCE() memory accesses") leads to following build
> failure on powerpc 8xx.
I've put this in my fixes branch.
cheers
^ permalink raw reply
* Re: [PATCH v2 1/2] ASoC: bindings: fsl-asoc-card: Add compatible string for MQS
From: Mark Brown @ 2020-06-17 13:30 UTC (permalink / raw)
To: Xiubo.Lee, nicoleotsuka, alsa-devel, lgirdwood, robh+dt, tiwai,
Shengjiu Wang, devicetree, festevam, timur, perex
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <2185a3ec866bc59f82d93b73d1a732a896fd8f48.1592369271.git.shengjiu.wang@nxp.com>
On Wed, 17 Jun 2020 12:48:24 +0800, Shengjiu Wang wrote:
> Add compatible string "fsl,imx-audio-mqs" for MQS, and move
> "audio-routing" property to be optional for MQS doesn't need
> such property.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/2] ASoC: bindings: fsl-asoc-card: Add compatible string for MQS
commit: 56d6663d41f982542097775a3a8a6a1b867fe608
[2/2] ASoC: fsl-asoc-card: Add MQS support
commit: 039652a5b965404aee1fa8f61017f822668f41d4
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH v3 1/2] ASoC: bindings: fsl_spdif: Add new compatible string for imx6sx
From: Mark Brown @ 2020-06-17 13:30 UTC (permalink / raw)
To: Xiubo.Lee, nicoleotsuka, alsa-devel, lgirdwood, robh+dt, tiwai,
Shengjiu Wang, devicetree, festevam, timur, perex
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <feda3bb02296455d43aeebb7575918d9b28e1a3f.1592376770.git.shengjiu.wang@nxp.com>
On Wed, 17 Jun 2020 14:58:00 +0800, Shengjiu Wang wrote:
> Add new compatible string "fsl,imx6sx-spdif" in the binding document.
> And add compatible string "fsl,vf610-spdif" which was missed before.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/2] ASoC: bindings: fsl_spdif: Add new compatible string for imx6sx
commit: 632108afda6aa1d380e05f1eaa25463047fd00b3
[2/2] ASoC: fsl_spdif: Add support for imx6sx platform
commit: f61b9273c347980f570d1f9cecb867a7835c613d
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH] powerpc/8xx: use pmd_off() to access a PMD entry in pte_update()
From: Michael Ellerman @ 2020-06-17 13:05 UTC (permalink / raw)
To: Mike Rapoport
Cc: Christophe Leroy, linux-kernel, Mike Rapoport, linux-mm,
Andrew Morton, linuxppc-dev
In-Reply-To: <20200617041617.GA6571@kernel.org>
Mike Rapoport <rppt@kernel.org> writes:
> On Wed, Jun 17, 2020 at 09:21:42AM +1000, Michael Ellerman wrote:
>> Andrew Morton <akpm@linux-foundation.org> writes:
>> > On Mon, 15 Jun 2020 12:22:29 +0300 Mike Rapoport <rppt@kernel.org> wrote:
>> >
>> >> From: Mike Rapoport <rppt@linux.ibm.com>
>> >>
>> >> The pte_update() implementation for PPC_8xx unfolds page table from the PGD
>> >> level to access a PMD entry. Since 8xx has only 2-level page table this can
>> >> be simplified with pmd_off() shortcut.
>> >>
>> >> Replace explicit unfolding with pmd_off() and drop defines of pgd_index()
>> >> and pgd_offset() that are no longer needed.
>> >>
>> >> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
>> >> ---
>> >>
>> >> I think it's powerpc material, but I won't mind if Andrew picks it up :)
>> >
>> > Via the powerpc tree would be better, please.
>>
>> I'll take it into next for v5.9, unless there's a reason it needs to go
>> into v5.8.
>
> I consider it a fixup for 5.8 merge window conflicts. Besides, mering it
> now may avoid new conflicts in 5.9 ;-)
OK, I'll pick it up for v5.8.
cheers
^ permalink raw reply
* Re: [PATCH v4 0/3] mm, treewide: Rename kzfree() to kfree_sensitive()
From: Michal Hocko @ 2020-06-17 12:55 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Jason A . Donenfeld, linux-btrfs, Jarkko Sakkinen, dsterba,
David Howells, linux-mm, linux-sctp, keyrings, linux-stm32, devel,
linux-cifs, linux-scsi, James Morris, kasan-dev, linux-wpan,
David Rientjes, Waiman Long, Dan Carpenter, Serge E. Hallyn,
linux-pm, ecryptfs, linux-fscrypt, linux-mediatek, linux-amlogic,
virtualization, linux-integrity, linux-nfs, Linus Torvalds,
linux-wireless, linux-kernel, linux-bluetooth,
linux-security-module, target-devel, tipc-discussion,
linux-crypto, Johannes Weiner, Joe Perches, Andrew Morton,
linuxppc-dev, netdev, wireguard, linux-ppp
In-Reply-To: <20200617122321.GJ8681@bombadil.infradead.org>
On Wed 17-06-20 05:23:21, Matthew Wilcox wrote:
> On Wed, Jun 17, 2020 at 01:31:57PM +0200, Michal Hocko wrote:
> > On Wed 17-06-20 04:08:20, Matthew Wilcox wrote:
> > > If you call vfree() under
> > > a spinlock, you're in trouble. in_atomic() only knows if we hold a
> > > spinlock for CONFIG_PREEMPT, so it's not safe to check for in_atomic()
> > > in __vfree(). So we need the warning in order that preempt people can
> > > tell those without that there is a bug here.
> >
> > ... Unless I am missing something in_interrupt depends on preempt_count() as
> > well so neither of the two is reliable without PREEMPT_COUNT configured.
>
> preempt_count() always tracks whether we're in interrupt context,
> regardless of CONFIG_PREEMPT. The difference is that CONFIG_PREEMPT
> will track spinlock acquisitions as well.
Right you are! Thanks for the clarification. I find the situation
around preempt_count quite confusing TBH. Looking at existing users
of in_atomic() (e.g. a random one zd_usb_iowrite16v_async which check
in_atomic and then does GFP_KERNEL allocation which would be obviously
broken on !PREEMPT if the function can be called from an atomic
context), I am wondering whether it would make sense to track atomic
context also for !PREEMPT. This check is just terribly error prone.
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [PATCH v4 0/3] mm, treewide: Rename kzfree() to kfree_sensitive()
From: Matthew Wilcox @ 2020-06-17 12:23 UTC (permalink / raw)
To: Michal Hocko
Cc: Jason A . Donenfeld, linux-btrfs, Jarkko Sakkinen, dsterba,
David Howells, linux-mm, linux-sctp, keyrings, linux-stm32, devel,
linux-cifs, linux-scsi, James Morris, kasan-dev, linux-wpan,
David Rientjes, Waiman Long, Dan Carpenter, Serge E. Hallyn,
linux-pm, ecryptfs, linux-fscrypt, linux-mediatek, linux-amlogic,
virtualization, linux-integrity, linux-nfs, Linus Torvalds,
linux-wireless, linux-kernel, linux-bluetooth,
linux-security-module, target-devel, tipc-discussion,
linux-crypto, Johannes Weiner, Joe Perches, Andrew Morton,
linuxppc-dev, netdev, wireguard, linux-ppp
In-Reply-To: <20200617113157.GM9499@dhcp22.suse.cz>
On Wed, Jun 17, 2020 at 01:31:57PM +0200, Michal Hocko wrote:
> On Wed 17-06-20 04:08:20, Matthew Wilcox wrote:
> > If you call vfree() under
> > a spinlock, you're in trouble. in_atomic() only knows if we hold a
> > spinlock for CONFIG_PREEMPT, so it's not safe to check for in_atomic()
> > in __vfree(). So we need the warning in order that preempt people can
> > tell those without that there is a bug here.
>
> ... Unless I am missing something in_interrupt depends on preempt_count() as
> well so neither of the two is reliable without PREEMPT_COUNT configured.
preempt_count() always tracks whether we're in interrupt context,
regardless of CONFIG_PREEMPT. The difference is that CONFIG_PREEMPT
will track spinlock acquisitions as well.
^ permalink raw reply
* Re: [PATCH v4 0/3] mm, treewide: Rename kzfree() to kfree_sensitive()
From: Michal Hocko @ 2020-06-17 11:31 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Jason A . Donenfeld, linux-btrfs, Jarkko Sakkinen, dsterba,
David Howells, linux-mm, linux-sctp, keyrings, linux-stm32, devel,
linux-cifs, linux-scsi, James Morris, kasan-dev, linux-wpan,
David Rientjes, Waiman Long, Dan Carpenter, Serge E. Hallyn,
linux-pm, ecryptfs, linux-fscrypt, linux-mediatek, linux-amlogic,
virtualization, linux-integrity, linux-nfs, Linus Torvalds,
linux-wireless, linux-kernel, linux-bluetooth,
linux-security-module, target-devel, tipc-discussion,
linux-crypto, Johannes Weiner, Joe Perches, Andrew Morton,
linuxppc-dev, netdev, wireguard, linux-ppp
In-Reply-To: <20200617110820.GG8681@bombadil.infradead.org>
On Wed 17-06-20 04:08:20, Matthew Wilcox wrote:
> On Wed, Jun 17, 2020 at 09:12:12AM +0200, Michal Hocko wrote:
> > On Tue 16-06-20 17:37:11, Matthew Wilcox wrote:
> > > Not just performance critical, but correctness critical. Since kvfree()
> > > may allocate from the vmalloc allocator, I really think that kvfree()
> > > should assert that it's !in_atomic(). Otherwise we can get into trouble
> > > if we end up calling vfree() and have to take the mutex.
> >
> > FWIW __vfree already checks for atomic context and put the work into a
> > deferred context. So this should be safe. It should be used as a last
> > resort, though.
>
> Actually, it only checks for in_interrupt().
You are right. I have misremembered. You have made me look (thanks) ...
> If you call vfree() under
> a spinlock, you're in trouble. in_atomic() only knows if we hold a
> spinlock for CONFIG_PREEMPT, so it's not safe to check for in_atomic()
> in __vfree(). So we need the warning in order that preempt people can
> tell those without that there is a bug here.
... Unless I am missing something in_interrupt depends on preempt_count() as
well so neither of the two is reliable without PREEMPT_COUNT configured.
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* [PATCH v5] powerpc/fadump: fix race between pstore write and fadump crash trigger
From: Sourabh Jain @ 2020-06-17 11:17 UTC (permalink / raw)
To: mpe; +Cc: mahesh, linux-kernel, hbathini, linuxppc-dev
When we enter into fadump crash path via system reset we fail to update
the pstore.
On the system reset path we first update the pstore then we go for fadump
crash. But the problem here is when all the CPUs try to get the pstore
lock to initiate the pstore write, only one CPUs will acquire the lock
and proceed with the pstore write. Since it in NMI context CPUs that fail
to get lock do not wait for their turn to write to the pstore and simply
proceed with the next operation which is fadump crash. One of the CPU who
proceeded with fadump crash path triggers the crash and does not wait for
the CPU who gets the pstore lock to complete the pstore update.
Timeline diagram to depicts the sequence of events that leads to an
unsuccessful pstore update when we hit fadump crash path via system reset.
1 2 3 ... n CPU Threads
| | | |
| | | |
Reached to -->|--->|---->| ----------->|
system reset | | | |
path | | | |
| | | |
Try to -->|--->|---->|------------>|
acquire the | | | |
pstore lock | | | |
| | | |
| | | |
Got the -->| +->| | |<-+
pstore lock | | | | | |--> Didn't get the
| --------------------------+ lock and moving
| | | | ahead on fadump
| | | | crash path
| | | |
Begins the -->| | | |
process to | | | |<-- Got the chance to
update the | | | | trigger the crash
pstore | -> | | ... <- |
| | | | | |
| | | | | |<-- Triggers the
| | | | | | crash
| | | | | | ^
| | | | | | |
Writing to -->| | | | | | |
pstore | | | | | | |
| | |
^ |__________________| |
| CPU Relax |
| |
+-----------------------------------------+
|
v
Race: crash triggered before pstore
update completes
To avoid this race condition a barrier is added on crash_fadump path, it
prevents the CPU to trigger the crash until all the online CPUs completes
their task.
A barrier is added to make sure all the secondary CPUs hit the
crash_fadump function before we initiates the crash. A timeout is kept to
ensure the primary CPU (one who initiates the crash) do not wait for
secondary CPUs indefinitely.
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
---
arch/powerpc/kernel/fadump.c | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
---
Chanagelog:
v1 -> v3:
- https://lists.ozlabs.org/pipermail/linuxppc-dev/2020-April/208267.html
v3 -> v4:
- Now the primary CPU (one who triggers dump) waits for all secondary
CPUs to enter and then initiates the crash.
v4 -> v5:
- Fixed a build failure reported by kernel test robot <lkp@intel.com>
Now the cpus_in_crash variable is defined outside CONFIG_CMA
config option.
---
diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index ff0114aeba9b..08dfa9d34096 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -32,10 +32,20 @@
#include <asm/fadump-internal.h>
#include <asm/setup.h>
+/*
+ * The CPU who acquired the lock to trigger the fadump crash should
+ * wait for other CPUs to enter.
+ *
+ * The timeout is in milliseconds.
+ */
+#define CRASH_TIMEOUT 500
+
static struct fw_dump fw_dump;
static void __init fadump_reserve_crash_area(u64 base);
+static atomic_t cpus_in_crash;
+
#ifndef CONFIG_PRESERVE_FA_DUMP
static DEFINE_MUTEX(fadump_mutex);
struct fadump_mrange_info crash_mrange_info = { "crash", NULL, 0, 0, 0 };
@@ -594,8 +604,11 @@ early_param("fadump_reserve_mem", early_fadump_reserve_mem);
void crash_fadump(struct pt_regs *regs, const char *str)
{
+ unsigned int msecs;
struct fadump_crash_info_header *fdh = NULL;
int old_cpu, this_cpu;
+ /* Do not include first CPU */
+ unsigned int ncpus = num_online_cpus() - 1;
if (!should_fadump_crash())
return;
@@ -611,6 +624,8 @@ void crash_fadump(struct pt_regs *regs, const char *str)
old_cpu = cmpxchg(&crashing_cpu, -1, this_cpu);
if (old_cpu != -1) {
+ atomic_inc(&cpus_in_crash);
+
/*
* We can't loop here indefinitely. Wait as long as fadump
* is in force. If we race with fadump un-registration this
@@ -634,6 +649,16 @@ void crash_fadump(struct pt_regs *regs, const char *str)
fdh->online_mask = *cpu_online_mask;
+ /*
+ * If we came in via system reset, wait a while for the secondary
+ * CPUs to enter.
+ */
+ if (TRAP(&(fdh->regs)) == 0x100) {
+ msecs = CRASH_TIMEOUT;
+ while ((atomic_read(&cpus_in_crash) < ncpus) && (--msecs > 0))
+ mdelay(1);
+ }
+
fw_dump.ops->fadump_trigger(fdh, str);
}
--
2.25.4
^ permalink raw reply related
* Re: [PATCH v4 0/3] mm, treewide: Rename kzfree() to kfree_sensitive()
From: Matthew Wilcox @ 2020-06-17 11:08 UTC (permalink / raw)
To: Michal Hocko
Cc: Jason A . Donenfeld, linux-btrfs, Jarkko Sakkinen, dsterba,
David Howells, linux-mm, linux-sctp, keyrings, linux-stm32, devel,
linux-cifs, linux-scsi, James Morris, kasan-dev, linux-wpan,
David Rientjes, Waiman Long, Dan Carpenter, Serge E. Hallyn,
linux-pm, ecryptfs, linux-fscrypt, linux-mediatek, linux-amlogic,
virtualization, linux-integrity, linux-nfs, Linus Torvalds,
linux-wireless, linux-kernel, linux-bluetooth,
linux-security-module, target-devel, tipc-discussion,
linux-crypto, Johannes Weiner, Joe Perches, Andrew Morton,
linuxppc-dev, netdev, wireguard, linux-ppp
In-Reply-To: <20200617071212.GJ9499@dhcp22.suse.cz>
On Wed, Jun 17, 2020 at 09:12:12AM +0200, Michal Hocko wrote:
> On Tue 16-06-20 17:37:11, Matthew Wilcox wrote:
> > Not just performance critical, but correctness critical. Since kvfree()
> > may allocate from the vmalloc allocator, I really think that kvfree()
> > should assert that it's !in_atomic(). Otherwise we can get into trouble
> > if we end up calling vfree() and have to take the mutex.
>
> FWIW __vfree already checks for atomic context and put the work into a
> deferred context. So this should be safe. It should be used as a last
> resort, though.
Actually, it only checks for in_interrupt(). If you call vfree() under
a spinlock, you're in trouble. in_atomic() only knows if we hold a
spinlock for CONFIG_PREEMPT, so it's not safe to check for in_atomic()
in __vfree(). So we need the warning in order that preempt people can
tell those without that there is a bug here.
^ permalink raw reply
* Re: [PATCH v5 01/13] powerpc: Remove Xilinx PPC405/PPC440 support
From: Michal Simek @ 2020-06-17 11:02 UTC (permalink / raw)
To: Michael Ellerman, Michal Simek, Nathan Chancellor
Cc: arnd, linux-kernel, clang-built-linux, Paul Mackerras,
linuxppc-dev
In-Reply-To: <87bllidmk4.fsf@mpe.ellerman.id.au>
<snip>
>> Or if bamboo requires uImage to be built by default you can do it via
>> Kconfig.
>>
>> diff --git a/arch/powerpc/platforms/44x/Kconfig
>> b/arch/powerpc/platforms/44x/Kconfig
>> index 39e93d23fb38..300864d7b8c9 100644
>> --- a/arch/powerpc/platforms/44x/Kconfig
>> +++ b/arch/powerpc/platforms/44x/Kconfig
>> @@ -13,6 +13,7 @@ config BAMBOO
>> select PPC44x_SIMPLE
>> select 440EP
>> select FORCE_PCI
>> + select DEFAULT_UIMAGE
>> help
>> This option enables support for the IBM PPC440EP evaluation board.
>
> Who knows what the actual bamboo board used. But I'd be happy to take a
> SOB'ed patch to do the above, because these days the qemu emulation is
> much more likely to be used than the actual board.
I have no problem to send this as regular patch but someone with more
bamboo experience should tell if this is correct configuration.
But truth is if that symlink was there for quite a long time it should
likely stay there.
Thanks,
Michal
^ permalink raw reply
* Re: [PATCH 0/3] Fix build failure with v5.8-rc1
From: Will Deacon @ 2020-06-17 10:57 UTC (permalink / raw)
To: Christophe Leroy
Cc: arnd, Peter Zijlstra (Intel), linux-kernel, linux-mm,
Paul Mackerras, Andrew Morton, linuxppc-dev
In-Reply-To: <cover.1592225557.git.christophe.leroy@csgroup.eu>
[+Arnd in case he's interested in this series]
On Mon, Jun 15, 2020 at 12:57:55PM +0000, Christophe Leroy wrote:
> Commit 2ab3a0a02905 ("READ_ONCE: Enforce atomicity for
> {READ,WRITE}_ONCE() memory accesses") leads to following build
> failure on powerpc 8xx.
>
> To fix it, this small series introduces a new helper named ptep_get()
> to replace the direct access with READ_ONCE(). This new helper
> can be overriden by architectures.
Thanks for doing this, and sorry for the breakage. For the series:
Acked-by: Will Deacon <will@kernel.org>
Hopefully we can introduce accessors for the other page-table levels too,
but that can obviously happen incrementally.
Will
> Christophe Leroy (3):
> mm/gup: Use huge_ptep_get() in gup_hugepte()
> mm: Allow arches to provide ptep_get()
> powerpc/8xx: Provide ptep_get() with 16k pages
>
> arch/powerpc/include/asm/nohash/32/pgtable.h | 10 ++++++++++
> include/asm-generic/hugetlb.h | 2 +-
> include/linux/pgtable.h | 7 +++++++
> mm/gup.c | 4 ++--
> 4 files changed, 20 insertions(+), 3 deletions(-)
>
> --
> 2.25.0
>
^ permalink raw reply
* Re: [PATCH v5 01/13] powerpc: Remove Xilinx PPC405/PPC440 support
From: Michael Ellerman @ 2020-06-17 10:21 UTC (permalink / raw)
To: Michal Simek, Nathan Chancellor, Michal Simek
Cc: arnd, linux-kernel, clang-built-linux, Paul Mackerras,
linuxppc-dev
In-Reply-To: <87bllidmk4.fsf@mpe.ellerman.id.au>
Michael Ellerman <mpe@ellerman.id.au> writes:
> Michal Simek <michal.simek@xilinx.com> writes:
<snip>
>> Or if bamboo requires uImage to be built by default you can do it via
>> Kconfig.
>>
>> diff --git a/arch/powerpc/platforms/44x/Kconfig
>> b/arch/powerpc/platforms/44x/Kconfig
>> index 39e93d23fb38..300864d7b8c9 100644
>> --- a/arch/powerpc/platforms/44x/Kconfig
>> +++ b/arch/powerpc/platforms/44x/Kconfig
>> @@ -13,6 +13,7 @@ config BAMBOO
>> select PPC44x_SIMPLE
>> select 440EP
>> select FORCE_PCI
>> + select DEFAULT_UIMAGE
>> help
>> This option enables support for the IBM PPC440EP evaluation board.
>
> Who knows what the actual bamboo board used. But I'd be happy to take a
> SOB'ed patch to do the above, because these days the qemu emulation is
> much more likely to be used than the actual board.
I just went to see why my CI boot of 44x didn't catch this, and it's
because I don't use the uImage, I just boot the vmlinux directly:
$ qemu-system-ppc -M bamboo -m 128m -display none -kernel build~/vmlinux -append "console=ttyS0" -display none -nodefaults -serial mon:stdio
Linux version 5.8.0-rc1-00118-g69119673bd50 (michael@alpine1-p1) (gcc (Ubuntu 9.3.0-10ubuntu2) 9.3.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #4 Wed Jun 17 20:19:22 AEST 2020
Using PowerPC 44x Platform machine description
ioremap() called early from find_legacy_serial_ports+0x690/0x770. Use early_ioremap() instead
printk: bootconsole [udbg0] enabled
So that's probably the simplest solution?
cheers
^ permalink raw reply
* Re: [PATCH v5 01/13] powerpc: Remove Xilinx PPC405/PPC440 support
From: Michael Ellerman @ 2020-06-17 10:16 UTC (permalink / raw)
To: Michal Simek, Nathan Chancellor, Michal Simek
Cc: arnd, linux-kernel, clang-built-linux, Paul Mackerras,
linuxppc-dev
In-Reply-To: <50fb2dd6-4e8f-a550-6eda-073beb86f2ff@xilinx.com>
Michal Simek <michal.simek@xilinx.com> writes:
> On 16. 06. 20 20:16, Nathan Chancellor wrote:
>> On Tue, Jun 16, 2020 at 04:45:20PM +0200, Michal Simek wrote:
>>> On 16. 06. 20 2:27, Nathan Chancellor wrote:
>>>> On Thu, May 21, 2020 at 04:55:52PM +0000, Christophe Leroy wrote:
>>>>> From: Michal Simek <michal.simek@xilinx.com>
>>>>>
>>>>> The latest Xilinx design tools called ISE and EDK has been released in
>>>>> October 2013. New tool doesn't support any PPC405/PPC440 new designs.
>>>>> These platforms are no longer supported and tested.
>>>>>
>>>>> PowerPC 405/440 port is orphan from 2013 by
>>>>> commit cdeb89943bfc ("MAINTAINERS: Fix incorrect status tag") and
>>>>> commit 19624236cce1 ("MAINTAINERS: Update Grant's email address and maintainership")
>>>>> that's why it is time to remove the support fot these platforms.
>>>>>
>>>>> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
>>>>> Acked-by: Arnd Bergmann <arnd@arndb.de>
>>>>> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
>>>>
>>>> This patch causes qemu-system-ppc to fail to load ppc44x_defconfig:
<snip>
> I have took a look at it and was able to run qemu and also saw your
> issue. What happened is that when xilinx platforms were removed zImage
> is generated but it is not u-boot legacy image.
> Don't know details about zImage/uImage in ppc world but if you dump
> zImage you should see this.
<snip>
> It means only Xilinx platforms have been asking for uImage format and
> bamboo doesn't require it. It also looks like that qemu expect uImage
> format.
Yeah, prior to the patch the result of make ppc44x_defconfig contains
CONFIG_DEFAULT_UIMAGE, afterward it doesn't.
That means previously arch/powerpc/boot/zImage was just a hardlink to
the uImage:
$ ls -li build~/arch/powerpc/boot/{z,u}Image
7472 -rw-rw-r-- 2 michael michael 3073824 Jun 17 20:02 build~/arch/powerpc/boot/uImage
7472 -rw-rw-r-- 2 michael michael 3073824 Jun 17 20:02 build~/arch/powerpc/boot/zImage
$ file build~/arch/powerpc/boot/zImage
build~/arch/powerpc/boot/zImage: u-boot legacy uImage,
Linux-5.7.0-rc2-00247-g0bdad33d6\037\213\010, Linux/PowerPC, OS Kernel
Image (gzip), 3073760 bytes, Wed Jun 17 10:14:32 2020, Load Address:
0x00000000, Entry Point: 0x00000000, Header CRC: 0xF0283815, Data CRC:
0x5E5A4D98
> You should know what format qemu expects.
> Anyway if you build it by make uImage and then pass it to qemu you
> should boot just fine.
Yep so you can explicitly build the uImage with:
$ make -skj"$(nproc)" ARCH=powerpc CROSS_COMPILE=powerpc-linux- O=out/ppc distclean ppc44x_defconfig uImage
> Or if bamboo requires uImage to be built by default you can do it via
> Kconfig.
>
> diff --git a/arch/powerpc/platforms/44x/Kconfig
> b/arch/powerpc/platforms/44x/Kconfig
> index 39e93d23fb38..300864d7b8c9 100644
> --- a/arch/powerpc/platforms/44x/Kconfig
> +++ b/arch/powerpc/platforms/44x/Kconfig
> @@ -13,6 +13,7 @@ config BAMBOO
> select PPC44x_SIMPLE
> select 440EP
> select FORCE_PCI
> + select DEFAULT_UIMAGE
> help
> This option enables support for the IBM PPC440EP evaluation board.
Who knows what the actual bamboo board used. But I'd be happy to take a
SOB'ed patch to do the above, because these days the qemu emulation is
much more likely to be used than the actual board.
cheers
^ permalink raw reply
* Re: [PATCH V3 4/4] Documentation/mm: Add descriptions for arch page table helpers
From: Mike Rapoport @ 2020-06-17 10:01 UTC (permalink / raw)
To: Anshuman Khandual
Cc: linux-doc, Heiko Carstens, linux-mm, Paul Mackerras,
H. Peter Anvin, linux-riscv, Will Deacon, linux-arch, linux-s390,
Jonathan Corbet, x86, Christian Borntraeger, Ingo Molnar,
linux-arm-kernel, ziy, Catalin Marinas, linux-snps-arc,
Vasily Gorbik, Borislav Petkov, Paul Walmsley,
Kirill A . Shutemov, Thomas Gleixner, gerald.schaefer,
christophe.leroy, Vineet Gupta, linux-kernel, Palmer Dabbelt,
Andrew Morton, linuxppc-dev
In-Reply-To: <1592192277-8421-5-git-send-email-anshuman.khandual@arm.com>
On Mon, Jun 15, 2020 at 09:07:57AM +0530, Anshuman Khandual wrote:
> This adds a specific description file for all arch page table helpers which
> is in sync with the semantics being tested via CONFIG_DEBUG_VM_PGTABLE. All
> future changes either to these descriptions here or the debug test should
> always remain in sync.
>
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Mike Rapoport <rppt@linux.ibm.com>
> Cc: Vineet Gupta <vgupta@synopsys.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
> Cc: Vasily Gorbik <gor@linux.ibm.com>
> Cc: Christian Borntraeger <borntraeger@de.ibm.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: Kirill A. Shutemov <kirill@shutemov.name>
> Cc: Paul Walmsley <paul.walmsley@sifive.com>
> Cc: Palmer Dabbelt <palmer@dabbelt.com>
> Cc: linux-snps-arc@lists.infradead.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-s390@vger.kernel.org
> Cc: linux-riscv@lists.infradead.org
> Cc: x86@kernel.org
> Cc: linux-arch@vger.kernel.org
> Cc: linux-mm@kvack.org
> Cc: linux-doc@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Suggested-by: Mike Rapoport <rppt@kernel.org>
> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
> ---
> Documentation/vm/arch_pgtable_helpers.rst | 258 ++++++++++++++++++++++
> mm/debug_vm_pgtable.c | 6 +
> 2 files changed, 264 insertions(+)
> create mode 100644 Documentation/vm/arch_pgtable_helpers.rst
Acked-by: Mike Rapoport <rppt@linux.ibm.com>
^ 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