* [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
* Re: [PATCH v2 12/12] x86/traps: Fix up invalid PASID
From: Peter Zijlstra @ 2020-06-17 8:31 UTC (permalink / raw)
To: Fenghua Yu
Cc: Dave Hansen, H Peter Anvin, Dave Jiang, Ashok Raj, Joerg Roedel,
x86, amd-gfx, Ingo Molnar, Ravi V Shankar, Yu-cheng Yu,
Andrew Donnellan, Borislav Petkov, Sohil Mehta, Thomas Gleixner,
Tony Luck, linuxppc-dev, Felix Kuehling, linux-kernel, iommu,
Jacob Jun Pan, Frederic Barrat, David Woodhouse, Lu Baolu
In-Reply-To: <20200616232345.GC15763@romley-ivt3.sc.intel.com>
On Tue, Jun 16, 2020 at 04:23:46PM -0700, Fenghua Yu wrote:
> Hi, Peter,
>
> On Mon, Jun 15, 2020 at 09:09:28PM +0200, Peter Zijlstra wrote:
> > On Mon, Jun 15, 2020 at 11:55:29AM -0700, Fenghua Yu wrote:
> >
> > > Or do you suggest to add a random new flag in struct thread_info instead
> > > of a TIF flag?
> >
> > Why thread_info? What's wrong with something simple like the below. It
> > takes a bit from the 'strictly current' flags word.
> >
> >
> > diff --git a/include/linux/sched.h b/include/linux/sched.h
> > index b62e6aaf28f0..fca830b97055 100644
> > --- a/include/linux/sched.h
> > +++ b/include/linux/sched.h
> > @@ -801,6 +801,9 @@ struct task_struct {
> > /* Stalled due to lack of memory */
> > unsigned in_memstall:1;
> > #endif
> > +#ifdef CONFIG_PCI_PASID
> > + unsigned has_valid_pasid:1;
> > +#endif
> >
> > unsigned long atomic_flags; /* Flags requiring atomic access. */
> >
> > diff --git a/kernel/fork.c b/kernel/fork.c
> > index 142b23645d82..10b3891be99e 100644
> > --- a/kernel/fork.c
> > +++ b/kernel/fork.c
> > @@ -955,6 +955,10 @@ static struct task_struct *dup_task_struct(struct task_struct *orig, int node)
> > tsk->use_memdelay = 0;
> > #endif
> >
> > +#ifdef CONFIG_PCI_PASID
> > + tsk->has_valid_pasid = 0;
> > +#endif
> > +
> > #ifdef CONFIG_MEMCG
> > tsk->active_memcg = NULL;
> > #endif
>
> Can I add "Signed-off-by: Peter Zijlstra <peterz@infradead.org>"
> to this patch? I will send this patch in the next version of the series.
Sure, n/p.
^ permalink raw reply
* Re: [PATCH v4 0/3] mm, treewide: Rename kzfree() to kfree_sensitive()
From: Jo -l @ 2020-06-17 8:03 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Jason A. Donenfeld, Michal Hocko, 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, linuxppc-dev, linux-wireless, linux-kernel,
linux-bluetooth, linux-security-module, target-devel,
tipc-discussion, linux-crypto, Johannes Weiner, Joe Perches,
Andrew Morton, Linus Torvalds, netdev, wireguard, linux-ppp
In-Reply-To: <20200617003711.GD8681@bombadil.infradead.org>
Bonjour,
Désolé, aucune traduction possible,
En français pour comprendre!
Merci
slts
> Le 17 06 2020 à 02:37, Matthew Wilcox <willy@infradead.org> a écrit :
>
> On Wed, Jun 17, 2020 at 01:01:30AM +0200, David Sterba wrote:
>> On Tue, Jun 16, 2020 at 11:53:50AM -0700, 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?
>>
>> I'd consider kfree performance critical for cases where it is called
>> under locks. If possible the kfree is moved outside of the critical
>> section, but we have rbtrees or lists that get deleted under locks and
>> restructuring the code to do eg. splice and free it outside of the lock
>> is not always possible.
>
> 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.
Jo-l
joel.voyer@gmail.com
^ permalink raw reply
* Re: [PATCH v5 01/13] powerpc: Remove Xilinx PPC405/PPC440 support
From: Michal Simek @ 2020-06-17 7:56 UTC (permalink / raw)
To: Nathan Chancellor, Michal Simek
Cc: arnd, linux-kernel, clang-built-linux, Paul Mackerras,
linuxppc-dev
In-Reply-To: <20200616181630.GA3403678@ubuntu-n2-xlarge-x86>
Hi Nathan,
On 16. 06. 20 20:16, Nathan Chancellor wrote:
> Hi Michal,
>
> 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:
>>>
>>> $ make -skj"$(nproc)" ARCH=powerpc CROSS_COMPILE=powerpc-linux- O=out/ppc distclean ppc44x_defconfig zImage
>>>
>>> $ timeout --foreground 30s unbuffer \
>>> qemu-system-ppc \
>>> -machine bamboo \
>>
>> Did you bisect it that you found that this patch is causing problem for
>> you on any bamboo machine?
>>
>> Or this was caused by the whole series?
>>
>> Thanks,
>> Michal
>
> Yes, this conclusion was the result of the following bisect:
>
> $ cat test.sh
> #!/usr/bin/env bash
>
> cd "${HOME}"/src/linux || exit 125
>
> set -x
>
> PATH=${HOME}/toolchains/gcc/10.1.0/bin:${PATH} \
> make -skj"$(nproc)" ARCH=powerpc CROSS_COMPILE=powerpc-linux- O=out/ppc32 distclean ppc44x_defconfig zImage || exit 125
>
> "${HOME}"/cbl/github/boot-utils/boot-qemu.sh -a ppc32 -k out/ppc32 -t 30s
>
> $ git bisect start v5.8-rc1 v5.7
> ...
>
> $ git bisect run test.sh
> ...
>
> $ git bisect log
> # bad: [b3a9e3b9622ae10064826dccb4f7a52bd88c7407] Linux 5.8-rc1
> # good: [3d77e6a8804abcc0504c904bd6e5cdf3a5cf8162] Linux 5.7
> git bisect start 'v5.8-rc1' 'v5.7'
> # good: [ee01c4d72adffb7d424535adf630f2955748fa8b] Merge branch 'akpm' (patches from Andrew)
> git bisect good ee01c4d72adffb7d424535adf630f2955748fa8b
> # bad: [6f2dc3d335457d9c815be9f4fd3dc8eff92fcef7] Merge tag 'dma-mapping-5.8-2' of git://git.infradead.org/users/hch/dma-mapping
> git bisect bad 6f2dc3d335457d9c815be9f4fd3dc8eff92fcef7
> # skip: [828f3e18e1cb98c68fc6db4d5113513d4a267775] Merge tag 'arm-drivers-5.8' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
> git bisect skip 828f3e18e1cb98c68fc6db4d5113513d4a267775
> # good: [c46241a370a61f0f264791abb9fc869016e749ce] powerpc/pkeys: Check vma before returning key fault error to the user
> git bisect good c46241a370a61f0f264791abb9fc869016e749ce
> # good: [3f0be4df50a7854a831c80a74d7cf2cfd61f2fde] Merge tag 'versatile-dts-v5.8-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator into arm/dt
> git bisect good 3f0be4df50a7854a831c80a74d7cf2cfd61f2fde
> # bad: [bd55e792de0844631d34487d43eaf3f13294ebfe] powerpc/module_64: Use special stub for _mcount() with -mprofile-kernel
> git bisect bad bd55e792de0844631d34487d43eaf3f13294ebfe
> # good: [303e6a9ddcdc168e92253c78cdb4bbe1e10d78b3] powerpc/watchpoint: Convert thread_struct->hw_brk to an array
> git bisect good 303e6a9ddcdc168e92253c78cdb4bbe1e10d78b3
> # good: [0755e85570a4615ca674ad6489d44d63916f1f3e] powerpc/xive: Do not expose a debugfs file when XIVE is disabled
> git bisect good 0755e85570a4615ca674ad6489d44d63916f1f3e
> # bad: [b4ac18eead28611ff470d0f47a35c4e0ac080d9c] powerpc/perf/hv-24x7: Fix inconsistent output values incase multiple hv-24x7 events run
> git bisect bad b4ac18eead28611ff470d0f47a35c4e0ac080d9c
> # bad: [3aacaa719b7bf135551cabde2480e8f7bfdf7c7d] powerpc/40x: Don't save CR in SPRN_SPRG_SCRATCH6
> git bisect bad 3aacaa719b7bf135551cabde2480e8f7bfdf7c7d
> # bad: [1b5c0967ab8aa9424cdd5108de4e055d8aeaa9d0] powerpc/40x: Remove support for IBM 403GCX
> git bisect bad 1b5c0967ab8aa9424cdd5108de4e055d8aeaa9d0
> # good: [0bdad33d6bd7b80722e2f9e588d3d7c6d6e34978] powerpc/64: Refactor interrupt exit irq disabling sequence
> git bisect good 0bdad33d6bd7b80722e2f9e588d3d7c6d6e34978
> # bad: [2c74e2586bb96012ffc05f1c819b05d9cad86d6e] powerpc/40x: Rework 40x PTE access and TLB miss
> git bisect bad 2c74e2586bb96012ffc05f1c819b05d9cad86d6e
> # bad: [7ade8495dcfd788a76e6877c9ea86f5207369ea4] powerpc: Remove Xilinx PPC405/PPC440 support
> git bisect bad 7ade8495dcfd788a76e6877c9ea86f5207369ea4
> # first bad commit: [7ade8495dcfd788a76e6877c9ea86f5207369ea4] powerpc: Remove Xilinx PPC405/PPC440 support
>
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.
Before this patch:
[qemu](master)$ hexdump -C /mnt/disk/linux/arch/powerpc/boot/zImage |
head -n 20
00000000 27 05 19 56 bc 4d 17 ce 5e e9 cb 0f 00 2c 8d 98
|'..V.M..^....,..|
00000010 00 00 00 00 00 00 00 00 69 04 b6 eb 05 07 02 01
|........i.......|
00000020 4c 69 6e 75 78 2d 35 2e 37 2e 30 2d 72 63 32 2d
|Linux-5.7.0-rc2-|
00000030 30 30 32 34 39 2d 67 32 38 31 65 65 36 66 36 38
|00249-g281ee6f68|
00000040 1f 8b 08 00 00 00 00 00 02 03 ec 5a 7b 70 54 65
|...........Z{pTe|
00000050 96 3f b7 bb d3 34 49 30 8d b6 1a 16 d4 ce 43 4c
|.?...4I0......CL|
00000060 42 84 b8 cb ec de 9e 3c b8 21 c0 dc 24 ac 26 63
|B......<.!..$.&c|
00000070 32 04 74 9c ce 36 28 49 b4 16 04 6a db f5 5e fa
|2.t..6(I...j..^.|
00000080 36 dd b8 49 00 ab 33 60 15 28 8f 46 42 17 a0 56
|6..I..3`.(.FB..V|
00000090 65 5c 58 99 42 a0 2d 20 15 02 6c 31 2b ce 04 70 |e\X.B.-
..l1+..p|
After this patch:
[qemu](master)$ hexdump -C /mnt/disk/linux/arch/powerpc/boot/zImage |
head -n 20
00000000 00 52 50 4f 00 60 00 00 00 00 17 73 00 00 00 00
|.RPO.`.....s....|
00000010 00 60 00 70 a8 22 53 af 00 00 00 00 00 00 00 00
|.`.p."S.........|
00000020 00 01 7e a4 94 21 ff f0 3c 80 08 00 7c 08 02 a6
|..~..!..<...|...|
00000030 42 9f 00 05 38 a0 00 20 38 c0 00 40 93 c1 00 08 |B...8..
8..@....|
00000040 90 01 00 14 7f c8 02 a6 80 1e ff ec 7f c0 f2 14
|................|
00000050 80 7e 80 00 7c 83 20 50 48 00 1b 8d 80 01 00 14 |.~..|.
PH.......|
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.
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.
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.
Hope that this help with resolving your issue.
Thanks,
Michal
^ permalink raw reply related
* Re: [PATCH v4 0/3] mm, treewide: Rename kzfree() to kfree_sensitive()
From: Michal Hocko @ 2020-06-17 7:12 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: <20200617003711.GD8681@bombadil.infradead.org>
On Tue 16-06-20 17:37:11, Matthew Wilcox wrote:
> On Wed, Jun 17, 2020 at 01:01:30AM +0200, David Sterba wrote:
> > On Tue, Jun 16, 2020 at 11:53:50AM -0700, 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?
> >
> > I'd consider kfree performance critical for cases where it is called
> > under locks. If possible the kfree is moved outside of the critical
> > section, but we have rbtrees or lists that get deleted under locks and
> > restructuring the code to do eg. splice and free it outside of the lock
> > is not always possible.
>
> 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.
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* [PATCH v3 2/2] ASoC: fsl_spdif: Add support for imx6sx platform
From: Shengjiu Wang @ 2020-06-17 6:58 UTC (permalink / raw)
To: timur, nicoleotsuka, Xiubo.Lee, festevam, broonie, perex, tiwai,
alsa-devel, lgirdwood, robh+dt, devicetree
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <feda3bb02296455d43aeebb7575918d9b28e1a3f.1592376770.git.shengjiu.wang@nxp.com>
The one difference on imx6sx platform is that the root clock
is shared with ASRC module, so we add a new flags
"shared_root_clock" which means the root clock is not independent,
then we will not do the clk_set_rate and clk_round_rate to avoid
impact ASRC module usage.
As add a new flags, we include the soc specific data struct.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Reviewed-by: Nicolin Chen <nicoleotsuka@gmail.com>
---
changes in v3
- refine some comments
- add Reviewed-by: Nicolin Chen
changes in v2
- use shared_root_clk instead ind_root_clk.
- add fsl_spdif_can_set_clk_rate function.
sound/soc/fsl/fsl_spdif.c | 50 +++++++++++++++++++++++++++++++++++----
1 file changed, 45 insertions(+), 5 deletions(-)
diff --git a/sound/soc/fsl/fsl_spdif.c b/sound/soc/fsl/fsl_spdif.c
index 1b2e516f9162..5bc0e4729341 100644
--- a/sound/soc/fsl/fsl_spdif.c
+++ b/sound/soc/fsl/fsl_spdif.c
@@ -42,6 +42,18 @@ static u8 srpc_dpll_locked[] = { 0x0, 0x1, 0x2, 0x3, 0x4, 0xa, 0xb };
#define DEFAULT_RXCLK_SRC 1
+/**
+ * struct fsl_spdif_soc_data: soc specific data
+ *
+ * @imx: for imx platform
+ * @shared_root_clock: flag of sharing a clock source with others;
+ * so the driver shouldn't set root clock rate
+ */
+struct fsl_spdif_soc_data {
+ bool imx;
+ bool shared_root_clock;
+};
+
/*
* SPDIF control structure
* Defines channel status, subcode and Q sub
@@ -89,6 +101,7 @@ struct spdif_mixer_control {
* @dma_params_rx: DMA parameters for receive channel
*/
struct fsl_spdif_priv {
+ const struct fsl_spdif_soc_data *soc;
struct spdif_mixer_control fsl_spdif_control;
struct snd_soc_dai_driver cpu_dai_drv;
struct platform_device *pdev;
@@ -110,6 +123,27 @@ struct fsl_spdif_priv {
u32 regcache_srpc;
};
+static struct fsl_spdif_soc_data fsl_spdif_vf610 = {
+ .imx = false,
+ .shared_root_clock = false,
+};
+
+static struct fsl_spdif_soc_data fsl_spdif_imx35 = {
+ .imx = true,
+ .shared_root_clock = false,
+};
+
+static struct fsl_spdif_soc_data fsl_spdif_imx6sx = {
+ .imx = true,
+ .shared_root_clock = true,
+};
+
+/* Check if clk is a root clock that does not share clock source with others */
+static inline bool fsl_spdif_can_set_clk_rate(struct fsl_spdif_priv *spdif, int clk)
+{
+ return (clk == STC_TXCLK_SPDIF_ROOT) && !spdif->soc->shared_root_clock;
+}
+
/* DPLL locked and lock loss interrupt handler */
static void spdif_irq_dpll_lock(struct fsl_spdif_priv *spdif_priv)
{
@@ -420,8 +454,7 @@ static int spdif_set_sample_rate(struct snd_pcm_substream *substream,
sysclk_df = spdif_priv->sysclk_df[rate];
- /* Don't mess up the clocks from other modules */
- if (clk != STC_TXCLK_SPDIF_ROOT)
+ if (!fsl_spdif_can_set_clk_rate(spdif_priv, clk))
goto clk_set_bypass;
/* The S/PDIF block needs a clock of 64 * fs * txclk_df */
@@ -1186,7 +1219,7 @@ static int fsl_spdif_probe_txclk(struct fsl_spdif_priv *spdif_priv,
continue;
ret = fsl_spdif_txclk_caldiv(spdif_priv, clk, savesub, index,
- i == STC_TXCLK_SPDIF_ROOT);
+ fsl_spdif_can_set_clk_rate(spdif_priv, i));
if (savesub == ret)
continue;
@@ -1230,6 +1263,12 @@ static int fsl_spdif_probe(struct platform_device *pdev)
spdif_priv->pdev = pdev;
+ spdif_priv->soc = of_device_get_match_data(&pdev->dev);
+ if (!spdif_priv->soc) {
+ dev_err(&pdev->dev, "failed to get soc data\n");
+ return -ENODEV;
+ }
+
/* Initialize this copy of the CPU DAI driver structure */
memcpy(&spdif_priv->cpu_dai_drv, &fsl_spdif_dai, sizeof(fsl_spdif_dai));
spdif_priv->cpu_dai_drv.name = dev_name(&pdev->dev);
@@ -1359,8 +1398,9 @@ static const struct dev_pm_ops fsl_spdif_pm = {
};
static const struct of_device_id fsl_spdif_dt_ids[] = {
- { .compatible = "fsl,imx35-spdif", },
- { .compatible = "fsl,vf610-spdif", },
+ { .compatible = "fsl,imx35-spdif", .data = &fsl_spdif_imx35, },
+ { .compatible = "fsl,vf610-spdif", .data = &fsl_spdif_vf610, },
+ { .compatible = "fsl,imx6sx-spdif", .data = &fsl_spdif_imx6sx, },
{}
};
MODULE_DEVICE_TABLE(of, fsl_spdif_dt_ids);
--
2.21.0
^ permalink raw reply related
* [PATCH v3 1/2] ASoC: bindings: fsl_spdif: Add new compatible string for imx6sx
From: Shengjiu Wang @ 2020-06-17 6:58 UTC (permalink / raw)
To: timur, nicoleotsuka, Xiubo.Lee, festevam, broonie, perex, tiwai,
alsa-devel, lgirdwood, robh+dt, devicetree
Cc: linuxppc-dev, linux-kernel
Add new compatible string "fsl,imx6sx-spdif" in the binding document.
And add compatible string "fsl,vf610-spdif" which was missed before.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
---
Documentation/devicetree/bindings/sound/fsl,spdif.txt | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/sound/fsl,spdif.txt b/Documentation/devicetree/bindings/sound/fsl,spdif.txt
index 8b324f82a782..e1365b0ee1e9 100644
--- a/Documentation/devicetree/bindings/sound/fsl,spdif.txt
+++ b/Documentation/devicetree/bindings/sound/fsl,spdif.txt
@@ -6,7 +6,11 @@ a fibre cable.
Required properties:
- - compatible : Compatible list, must contain "fsl,imx35-spdif".
+ - compatible : Compatible list, should contain one of the following
+ compatibles:
+ "fsl,imx35-spdif",
+ "fsl,vf610-spdif",
+ "fsl,imx6sx-spdif",
- reg : Offset and length of the register set for the device.
--
2.21.0
^ permalink raw reply related
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