* Re: [PATCH v4 2/6] printk: honor the max_reason field in kmsg_dumper
From: Kees Cook @ 2020-05-22 17:34 UTC (permalink / raw)
To: Petr Mladek
Cc: devicetree, Tony Luck, Pavel Tatashin, Jonathan Corbet,
Anton Vorontsov, linux-doc, linux-kernel, Steven Rostedt,
Sergey Senozhatsky, Rob Herring, Paul Mackerras, Colin Cross,
Enric Balletbo i Serra, linuxppc-dev, Benson Leung
In-Reply-To: <20200522165120.GL3464@linux-b0ei>
On Fri, May 22, 2020 at 06:51:20PM +0200, Petr Mladek wrote:
> On Fri 2020-05-15 11:44:30, Kees Cook wrote:
> > From: Pavel Tatashin <pasha.tatashin@soleen.com>
> >
> > kmsg_dump() allows to dump kmesg buffer for various system events: oops,
> > panic, reboot, etc. It provides an interface to register a callback call
> > for clients, and in that callback interface there is a field "max_reason"
> > which gets ignored unless always_kmsg_dump is passed as kernel parameter.
>
> Strictly speaking, this is not fully true. "max_reason" field is not
> ignored when set to KMSG_DUMP_PANIC even when always_kmsg_dump was not set.
>
> It should be something like:
>
> "which gets ignored for reason higher than KMSG_DUMP_OOPS unless
> always_kmsg_dump is passed as kernel parameter".
>
> Heh, I wonder if anyone will be able to parse this ;-)
Ah yeah, good point. I've reworded things like this:
kmsg_dump() allows to dump kmesg buffer for various system events: oops,
panic, reboot, etc. It provides an interface to register a callback
call for clients, and in that callback interface there is a field
"max_reason", but it was getting ignored when set to any "reason"
higher than KMSG_DUMP_OOPS unless "always_kmsg_dump" was passed as
kernel parameter.
Allow clients to actually control their "max_reason", and keep the
current behavior when "max_reason" is not set.
> Otherwise, it looks good to me. With the updated commit message:
>
> Reviewed-by: Petr Mladek <pmladek@suse.com>
Thanks!
--
Kees Cook
^ permalink raw reply
* Re: [PATCH v3 0/2] PCI/ERR: Allow Native AER/DPC using _OSC
From: Derrick, Jonathan @ 2020-05-22 17:23 UTC (permalink / raw)
To: helgaas@kernel.org
Cc: sathyanarayanan.kuppuswamy@linux.intel.com, Patel, Mayurkumar,
fred@fredlawl.com, sbobroff@linux.ibm.com,
linuxppc-dev@lists.ozlabs.org, Wysocki, Rafael J,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
andriy.shevchenko@linux.intel.com, bhelgaas@google.com,
alex.williamson@redhat.com, oohall@gmail.com, olof@lixom.net,
rajatja@google.com, mika.westerberg@linux.intel.com
In-Reply-To: <518c3348c4b4a8b5fed6a42ad190771f7f9645f3.camel@intel.com>
On Fri, 2020-05-01 at 11:35 -0600, Jonathan Derrick wrote:
> On Fri, 2020-05-01 at 12:16 -0500, Bjorn Helgaas wrote:
> > On Thu, Apr 30, 2020 at 12:46:07PM -0600, Jon Derrick wrote:
> > > Hi Bjorn & Kuppuswamy,
> > >
> > > I see a problem in the DPC ECN [1] to _OSC in that it doesn't give us a way to
> > > determine if firmware supports _OSC DPC negotation, and therefore how to handle
> > > DPC.
> > >
> > > Here is the wording of the ECN that implies that Firmware without _OSC DPC
> > > negotiation support should have the OSPM rely on _OSC AER negotiation when
> > > determining DPC control:
> > >
> > > PCIe Base Specification suggests that Downstream Port Containment may be
> > > controlled either by the Firmware or the Operating System. It also suggests
> > > that the Firmware retain ownership of Downstream Port Containment if it also
> > > owns AER. When the Firmware owns Downstream Port Containment, it is expected
> > > to use the new "Error Disconnect Recover" notification to alert OSPM of a
> > > Downstream Port Containment event.
> > >
> > > In legacy platforms, as bits in _OSC are reserved prior to implementation, ACPI
> > > Root Bus enumeration will mark these Host Bridges as without Native DPC
> > > support, even though the specification implies it's expected that AER _OSC
> > > negotiation determines DPC control for these platforms. There seems to be a
> > > need for a way to determine if the DPC control bit in _OSC is supported and
> > > fallback on AER otherwise.
> > >
> > >
> > > Currently portdrv assumes DPC control if the port has Native AER services:
> > >
> > > static int get_port_device_capability(struct pci_dev *dev)
> > > ...
> > > if (pci_find_ext_capability(dev, PCI_EXT_CAP_ID_DPC) &&
> > > pci_aer_available() &&
> > > (pcie_ports_dpc_native || (services & PCIE_PORT_SERVICE_AER)))
> > > services |= PCIE_PORT_SERVICE_DPC;
> > >
> > > Newer firmware may not grant OSPM DPC control, if for instance, it expects to
> > > use Error Disconnect Recovery. However it looks like ACPI will use DPC services
> > > via the EDR driver, without binding the full DPC port service driver.
> > >
> > >
> > > If we change portdrv to probe based on host->native_dpc and not AER, then we
> > > break instances with legacy firmware where OSPM will clear host->native_dpc
> > > solely due to _OSC bits being reserved:
> > >
> > > struct pci_bus *acpi_pci_root_create(struct acpi_pci_root *root,
> > > ...
> > > if (!(root->osc_control_set & OSC_PCI_EXPRESS_DPC_CONTROL))
> > > host_bridge->native_dpc = 0;
> > >
> > >
> > >
> > > So my assumption instead is that host->native_dpc can be 0 and expect Native
> > > DPC services if AER is used. In other words, if and only if DPC probe is
> > > invoked from portdrv, then it needs to rely on the AER dependency. Otherwise it
> > > should be assumed that ACPI set up DPC via EDR. This covers legacy firmware.
> > >
> > > However it seems like that could be trouble with newer firmware that might give
> > > OSPM control of AER but not DPC, and would result in both Native DPC and EDR
> > > being in effect.
> > >
> > >
> > > Anyways here are two patches that give control of AER and DPC on the results of
> > > _OSC. They don't mess with the HEST parser as I expect those to be removed at
> > > some point. I need these for VMD support which doesn't even rely on _OSC, but I
> > > suspect this won't be the last effort as we detangle Firmware First.
> > >
> > > [1] https://members.pcisig.com/wg/PCI-SIG/document/12888
> >
> > Hi Jon, I think we need to sort out the _OSC/FIRMWARE_FIRST patches
> > from Alex and Sathy first, then see what needs to be done on top of
> > those, so I'm going to push these off for a few days and they'll
> > probably need a refresh.
> >
> > Bjorn
>
> Agreed, no need to merge now. Just wanted to bring up the DPC
> ambiguity, which I think was first addressed by dpc-native:
>
> commit 35a0b2378c199d4f26e458b2ca38ea56aaf2d9b8
> Author: Olof Johansson <olof@lixom.net>
> Date: Wed Oct 23 12:22:05 2019 -0700
>
> PCI/DPC: Add "pcie_ports=dpc-native" to allow DPC without AER control
>
> Prior to eed85ff4c0da7 ("PCI/DPC: Enable DPC only if AER is available"),
> Linux handled DPC events regardless of whether firmware had granted it
> ownership of AER or DPC, e.g., via _OSC.
>
> PCIe r5.0, sec 6.2.10, recommends that the OS link control of DPC to
> control of AER, so after eed85ff4c0da7, Linux handles DPC events only if it
> has control of AER.
>
> On platforms that do not grant OS control of AER via _OSC, Linux DPC
> handling worked before eed85ff4c0da7 but not after.
>
> To make Linux DPC handling work on those platforms the same way they did
> before, add a "pcie_ports=dpc-native" kernel parameter that makes Linux
> handle DPC events regardless of whether it has control of AER.
>
> [bhelgaas: commit log, move pcie_ports_dpc_native to drivers/pci/]
> Link: https://lore.kernel.org/r/20191023192205.97024-1-olof@lixom.net
> Signed-off-by: Olof Johansson <olof@lixom.net>
> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
>
>
> Thanks,
> Jon
Hi Bjorn,
Are you still thinking about removing the HEST parser?
For VMD we still need the ability to bind DPC if native_dpc==1.
I think if we can do that, this set should still pretty much still
apply with a modification to patch 2 to allow matching
pcie_ports_dpc_native in dpc_probe.
Jon
^ permalink raw reply
* Re: [PATCH v4 2/6] printk: honor the max_reason field in kmsg_dumper
From: Petr Mladek @ 2020-05-22 16:51 UTC (permalink / raw)
To: Kees Cook
Cc: devicetree, Tony Luck, Pavel Tatashin, Jonathan Corbet,
Anton Vorontsov, linux-doc, linux-kernel, Steven Rostedt,
Sergey Senozhatsky, Rob Herring, Paul Mackerras, Colin Cross,
Enric Balletbo i Serra, linuxppc-dev, Benson Leung
In-Reply-To: <20200515184434.8470-3-keescook@chromium.org>
On Fri 2020-05-15 11:44:30, Kees Cook wrote:
> From: Pavel Tatashin <pasha.tatashin@soleen.com>
>
> kmsg_dump() allows to dump kmesg buffer for various system events: oops,
> panic, reboot, etc. It provides an interface to register a callback call
> for clients, and in that callback interface there is a field "max_reason"
> which gets ignored unless always_kmsg_dump is passed as kernel parameter.
Strictly speaking, this is not fully true. "max_reason" field is not
ignored when set to KMSG_DUMP_PANIC even when always_kmsg_dump was not set.
It should be something like:
"which gets ignored for reason higher than KMSG_DUMP_OOPS unless
always_kmsg_dump is passed as kernel parameter".
Heh, I wonder if anyone will be able to parse this ;-)
Otherwise, it looks good to me. With the updated commit message:
Reviewed-by: Petr Mladek <pmladek@suse.com>
Best Regards,
Petr
^ permalink raw reply
* Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.7-5 tag
From: pr-tracker-bot @ 2020-05-22 16:40 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Linus Torvalds, linux-kernel
In-Reply-To: <87sgfsf4hs.fsf@mpe.ellerman.id.au>
The pull request you sent on Sat, 23 May 2020 00:06:55 +1000:
> https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.7-5
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/c8347bbf19f265c1bd254ca148f27caa71e77d61
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
^ permalink raw reply
* Re: [PATCH v4 1/6] printk: Collapse shutdown types into a single dump reason
From: Petr Mladek @ 2020-05-22 16:21 UTC (permalink / raw)
To: Kees Cook
Cc: devicetree, Tony Luck, Pavel Tatashin, Jonathan Corbet,
Anton Vorontsov, linux-doc, linux-kernel, Steven Rostedt,
Sergey Senozhatsky, Rob Herring, Paul Mackerras, Colin Cross,
Enric Balletbo i Serra, linuxppc-dev, Benson Leung
In-Reply-To: <20200515184434.8470-2-keescook@chromium.org>
On Fri 2020-05-15 11:44:29, Kees Cook wrote:
> To turn the KMSG_DUMP_* reasons into a more ordered list, collapse
> the redundant KMSG_DUMP_(RESTART|HALT|POWEROFF) reasons into
> KMSG_DUMP_SHUTDOWN. The current users already don't meaningfully
> distinguish between them, so there's no need to, as discussed here:
> https://lore.kernel.org/lkml/CA+CK2bAPv5u1ih5y9t5FUnTyximtFCtDYXJCpuyjOyHNOkRdqw@mail.gmail.com/
>
> Signed-off-by: Kees Cook <keescook@chromium.org>
Looks good to me:
Reviewed-by: Petr Mladek <pmladek@suse.com>
Best Regards,
Petr
^ permalink raw reply
* Re: [PATCH 09/29] arm64: use asm-generic/cacheflush.h
From: Catalin Marinas @ 2020-05-22 15:54 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-ia64, linux-sh, Roman Zippel, linux-mips, linux-mm,
sparclinux, linux-riscv, linux-arch, linux-c6x-dev, linux-hexagon,
x86, linux-xtensa, Arnd Bergmann, Jessica Yu, linux-um,
linux-m68k, openrisc, linux-arm-kernel, Michal Simek,
linux-kernel, linux-alpha, linux-fsdevel, Andrew Morton,
linuxppc-dev
In-Reply-To: <20200515143646.3857579-10-hch@lst.de>
On Fri, May 15, 2020 at 04:36:26PM +0200, Christoph Hellwig wrote:
> ARM64 needs almost no cache flushing routines of its own. Rely on
> asm-generic/cacheflush.h for the defaults.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* [GIT PULL] Please pull powerpc/linux.git powerpc-5.7-5 tag
From: Michael Ellerman @ 2020-05-22 14:06 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev, linux-kernel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi Linus,
Please pull some more powerpc fixes for 5.7:
The following changes since commit 249c9b0cd193d983c3a0b00f3fd3b92333bfeebe:
powerpc/40x: Make more space for system call exception (2020-05-12 21:22:11 +1000)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.7-5
for you to fetch changes up to 8659a0e0efdd975c73355dbc033f79ba3b31e82c:
powerpc/64s: Disable STRICT_KERNEL_RWX (2020-05-22 00:04:51 +1000)
- ------------------------------------------------------------------
powerpc fixes for 5.7 #5
A revert of a recent change to the PTE bits for 32-bit BookS, which broke swap.
And a "fix" to disable STRICT_KERNEL_RWX for 64-bit in Kconfig, as it's causing
crashes for some people.
Thanks to:
Christophe Leroy, Rui Salvaterra.
- ------------------------------------------------------------------
Christophe Leroy (1):
Revert "powerpc/32s: reorder Linux PTE bits to better match Hash PTE bits."
Michael Ellerman (1):
powerpc/64s: Disable STRICT_KERNEL_RWX
arch/powerpc/Kconfig | 2 +-
arch/powerpc/include/asm/book3s/32/hash.h | 8 ++++----
arch/powerpc/kernel/head_32.S | 9 ++++++---
arch/powerpc/mm/book3s32/hash_low.S | 14 ++++++++------
4 files changed, 19 insertions(+), 14 deletions(-)
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEJFGtCPCthwEv2Y/bUevqPMjhpYAFAl7H3DQACgkQUevqPMjh
pYCc6RAAtxBm0aHlZsitFfLGRVWjXAanWlstF0Gnd/uOT+OLERE7MCD4PQzISKU8
XeHJORzhnfBgcN596vE5EHvTPNkZQdd+VW1Fxp9Pw1wcfZi0XACOdA5YrSN6nDlH
vWUFE0WdcX7MksaviX8AnTmjK9MmHiKySZnTZ5cKlFcJWuawy4mjmK/L1y2DbAId
YdGPJ/Yptda/aZbgi4hV8T1fhgl7odqKhrFf+I5SRojL6M2hnt0mSpUq5shk4Zsw
YZtz86o10CLHpyXdi7zcJb0h7n8JLX3mB+veNVHrQ2o+NeSkwEhQJFYq2CzmTZSK
n79vjG9iCg5KQIQ513cwPjJuo9tIoFULuBPomWiKQ8z/wAyJwzApAJ9y3YWTpQ3e
MBo/rvhMCJvlDt2uAKp8DVMCaXdG8zeE/2iGcnvbQ5l9RwJDEUO8IcUHCdUyZchF
erIjeGLodqB4Vm9+v8gOSjAL4CRrgVRHX6ZDZdOMoHkQBc36mMIu3/X4LfknZ1PT
6TR6AK+DQXY5pguiUeutHPEjzB+f5dgjueTnU4yjOST07xq28dRfeBvRAWdnH5ev
bzQ/VAShdQBLTuwOcYajvYh9HCzcTvuRDOj4LrPRud/qIBECKjB9QlqbsWIPM1Vv
RBX79Fs2ML1Lz3GtVXKUy+9n+KncCEC7H0YkbYiVRZdbYQBbw/U=
=KT4L
-----END PGP SIGNATURE-----
^ permalink raw reply
* [PATCH v2] powerpc: Add ppc_inst_next()
From: Michael Ellerman @ 2020-05-22 13:33 UTC (permalink / raw)
To: linuxppc-dev; +Cc: christophe.leroy, jniethe5
In a few places we want to calculate the address of the next
instruction. Previously that was simple, we just added 4 bytes, or if
using a u32 * we incremented that pointer by 1.
But prefixed instructions make it more complicated, we need to advance
by either 4 or 8 bytes depending on the actual instruction. We also
can't do pointer arithmetic using struct ppc_inst, because it is
always 8 bytes in size on 64-bit, even though we might only need to
advance by 4 bytes.
So add a ppc_inst_next() helper which calculates the location of the
next instruction, if the given instruction was located at the given
address. Note the instruction doesn't need to actually be at the
address in memory.
Although it would seem natural for the value to be passed by value,
that makes it too easy to write a loop that will read off the end of a
page, eg:
for (; src < end; src = ppc_inst_next(src, *src),
dest = ppc_inst_next(dest, *dest))
As noticed by Christophe and Jordan, if end is the exact end of a
page, and the next page is not mapped, this will fault, because *dest
will read 8 bytes, 4 bytes into the next page.
So value is passed by reference, so the helper can be careful to use
ppc_inst_read() on it.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/include/asm/inst.h | 13 +++++++++++++
arch/powerpc/kernel/uprobes.c | 2 +-
arch/powerpc/lib/feature-fixups.c | 15 ++++++++-------
arch/powerpc/xmon/xmon.c | 2 +-
4 files changed, 23 insertions(+), 9 deletions(-)
v2: Pass the value as a pointer and use ppc_inst_read() on it.
diff --git a/arch/powerpc/include/asm/inst.h b/arch/powerpc/include/asm/inst.h
index d82e0c99cfa1..5b756ba77ed2 100644
--- a/arch/powerpc/include/asm/inst.h
+++ b/arch/powerpc/include/asm/inst.h
@@ -100,6 +100,19 @@ static inline int ppc_inst_len(struct ppc_inst x)
return ppc_inst_prefixed(x) ? 8 : 4;
}
+/*
+ * Return the address of the next instruction, if the instruction @value was
+ * located at @location.
+ */
+static inline struct ppc_inst *ppc_inst_next(void *location, struct ppc_inst *value)
+{
+ struct ppc_inst tmp;
+
+ tmp = ppc_inst_read(value);
+
+ return location + ppc_inst_len(tmp);
+}
+
int probe_user_read_inst(struct ppc_inst *inst,
struct ppc_inst __user *nip);
diff --git a/arch/powerpc/kernel/uprobes.c b/arch/powerpc/kernel/uprobes.c
index 83e883e1a42d..d200e7df7167 100644
--- a/arch/powerpc/kernel/uprobes.c
+++ b/arch/powerpc/kernel/uprobes.c
@@ -112,7 +112,7 @@ int arch_uprobe_post_xol(struct arch_uprobe *auprobe, struct pt_regs *regs)
* support doesn't exist and have to fix-up the next instruction
* to be executed.
*/
- regs->nip = utask->vaddr + ppc_inst_len(ppc_inst_read(&auprobe->insn));
+ regs->nip = (unsigned long)ppc_inst_next((void *)utask->vaddr, &auprobe->insn);
user_disable_single_step(current);
return 0;
diff --git a/arch/powerpc/lib/feature-fixups.c b/arch/powerpc/lib/feature-fixups.c
index 80f320c2e189..4c0a7ee9fa00 100644
--- a/arch/powerpc/lib/feature-fixups.c
+++ b/arch/powerpc/lib/feature-fixups.c
@@ -68,7 +68,7 @@ static int patch_alt_instruction(struct ppc_inst *src, struct ppc_inst *dest,
static int patch_feature_section(unsigned long value, struct fixup_entry *fcur)
{
- struct ppc_inst *start, *end, *alt_start, *alt_end, *src, *dest;
+ struct ppc_inst *start, *end, *alt_start, *alt_end, *src, *dest, nop;
start = calc_addr(fcur, fcur->start_off);
end = calc_addr(fcur, fcur->end_off);
@@ -84,14 +84,15 @@ static int patch_feature_section(unsigned long value, struct fixup_entry *fcur)
src = alt_start;
dest = start;
- for (; src < alt_end; src = (void *)src + ppc_inst_len(ppc_inst_read(src)),
- (dest = (void *)dest + ppc_inst_len(ppc_inst_read(dest)))) {
+ for (; src < alt_end; src = ppc_inst_next(src, src),
+ dest = ppc_inst_next(dest, dest)) {
if (patch_alt_instruction(src, dest, alt_start, alt_end))
return 1;
}
- for (; dest < end; dest = (void *)dest + ppc_inst_len(ppc_inst(PPC_INST_NOP)))
- raw_patch_instruction(dest, ppc_inst(PPC_INST_NOP));
+ nop = ppc_inst(PPC_INST_NOP);
+ for (; dest < end; dest = ppc_inst_next(dest, &nop))
+ raw_patch_instruction(dest, nop);
return 0;
}
@@ -405,8 +406,8 @@ static void do_final_fixups(void)
while (src < end) {
inst = ppc_inst_read(src);
raw_patch_instruction(dest, inst);
- src = (void *)src + ppc_inst_len(inst);
- dest = (void *)dest + ppc_inst_len(inst);
+ src = ppc_inst_next(src, src);
+ dest = ppc_inst_next(dest, dest);
}
#endif
}
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index fb135f2cd6b0..65cf853a4d26 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -939,7 +939,7 @@ static void insert_bpts(void)
}
patch_instruction(bp->instr, instr);
- patch_instruction((void *)bp->instr + ppc_inst_len(instr),
+ patch_instruction(ppc_inst_next(bp->instr, &instr),
ppc_inst(bpinstr));
if (bp->enabled & BP_CIABR)
continue;
--
2.25.1
^ permalink raw reply related
* Re: [PATCH] ASoC: fsl: imx-pcm-dma: Don't request dma channel in probe
From: Mark Brown @ 2020-05-22 13:12 UTC (permalink / raw)
To: Shengjiu Wang
Cc: Sumit Semwal, linaro-mm-sig, Linux-ALSA, linuxppc-dev,
linux-kernel, Timur Tabi, Xiubo Li, shawnguo, Shengjiu Wang,
Takashi Iwai, Liam Girdwood, dri-devel, perex, Nicolin Chen,
linux-imx, kernel, linux-media, Fabio Estevam, s.hauer,
linux-arm-kernel, Lucas Stach
In-Reply-To: <CAA+D8AOiVVi3B4dzU8r=rCMz=6w9R=wxBkzAQ=0=RAQLKCWy8Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 851 bytes --]
On Thu, May 21, 2020 at 07:30:04PM +0800, Shengjiu Wang wrote:
> On Wed, May 20, 2020 at 8:38 PM Mark Brown <broonie@kernel.org> wrote:
> > Other drivers having problems means those drivers should be fixed, not
> > that we should copy the problems. In the case of the PXA driver that's
> > very old code which predates deferred probe by I'd guess a decade.
> Thanks.
> For the FE-BE case, do you have any suggestion for how fix it?
> With DMA1->ASRC->DMA2->ESAI case, the DMA1->ASRC->DMA2
> is in FE, ESAI is in BE. When ESAI drvier probe, DMA3 channel is
> created with ESAI's "dma:tx" (DMA3 channel
> is not used in this FE-BE case). When FE-BE startup, DMA2
> channel is created, it needs the ESAI's "dma:tx", so the warning
> comes out.
Not really TBH, this seems like another one of those csaes where DPCM is
creaking at the seams :/
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2 3/5] libnvdimm/nvdimm/flush: Allow architecture to override the flush barrier
From: Mikulas Patocka @ 2020-05-22 13:01 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: Jan Kara, linux-nvdimm, alistair, Jeff Moyer, Dan Williams,
Michal Suchánek, linuxppc-dev
In-Reply-To: <23e57565-be2a-a45c-f4d4-d8eca7262dea@linux.ibm.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3100 bytes --]
On Fri, 22 May 2020, Aneesh Kumar K.V wrote:
> On 5/22/20 3:01 PM, Michal Suchánek wrote:
> > On Thu, May 21, 2020 at 02:52:30PM -0400, Mikulas Patocka wrote:
> > >
> > >
> > > On Thu, 21 May 2020, Dan Williams wrote:
> > >
> > > > On Thu, May 21, 2020 at 10:03 AM Aneesh Kumar K.V
> > > > <aneesh.kumar@linux.ibm.com> wrote:
> > > > >
> > > > > > Moving on to the patch itself--Aneesh, have you audited other
> > > > > > persistent
> > > > > > memory users in the kernel? For example, drivers/md/dm-writecache.c
> > > > > > does
> > > > > > this:
> > > > > >
> > > > > > static void writecache_commit_flushed(struct dm_writecache *wc, bool
> > > > > > wait_for_ios)
> > > > > > {
> > > > > > if (WC_MODE_PMEM(wc))
> > > > > > wmb(); <==========
> > > > > > else
> > > > > > ssd_commit_flushed(wc, wait_for_ios);
> > > > > > }
> > > > > >
> > > > > > I believe you'll need to make modifications there.
> > > > > >
> > > > >
> > > > > Correct. Thanks for catching that.
> > > > >
> > > > >
> > > > > I don't understand dm much, wondering how this will work with
> > > > > non-synchronous DAX device?
> > > >
> > > > That's a good point. DM-writecache needs to be cognizant of things
> > > > like virtio-pmem that violate the rule that persisent memory writes
> > > > can be flushed by CPU functions rather than calling back into the
> > > > driver. It seems we need to always make the flush case a dax_operation
> > > > callback to account for this.
> > >
> > > dm-writecache is normally sitting on the top of dm-linear, so it would
> > > need to pass the wmb() call through the dm core and dm-linear target ...
> > > that would slow it down ... I remember that you already did it this way
> > > some times ago and then removed it.
> > >
> > > What's the exact problem with POWER? Could the POWER system have two types
> > > of persistent memory that need two different ways of flushing?
> >
> > As far as I understand the discussion so far
> >
> > - on POWER $oldhardware uses $oldinstruction to ensure pmem consistency
> > - on POWER $newhardware uses $newinstruction to ensure pmem consistency
> > (compatible with $oldinstruction on $oldhardware)
>
> Correct.
>
> > - on some platforms instead of barrier instruction a callback into the
> > driver is issued to ensure consistency
>
> This is virtio-pmem only at this point IIUC.
>
> -aneesh
And does the virtio-pmem driver track which pages are dirty? Or does it
need to specify the range of pages to flush in the flush function?
> > None of this is reflected by the dm driver.
We could make a new dax method:
void *(dax_get_flush_function)(void);
This would return a pointer to "wmb()" on x86 and something else on Power.
The method "dax_get_flush_function" would be called only once when
initializing the writecache driver (because the call would be slow because
it would have to go through the DM stack) and then, the returned function
would be called each time we need write ordering. The returned function
would do just "sfence; ret".
Mikulas
^ permalink raw reply
* [powerpc:fixes-test] BUILD SUCCESS 8659a0e0efdd975c73355dbc033f79ba3b31e82c
From: kbuild test robot @ 2020-05-22 11:21 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git fixes-test
branch HEAD: 8659a0e0efdd975c73355dbc033f79ba3b31e82c powerpc/64s: Disable STRICT_KERNEL_RWX
elapsed time: 1260m
configs tested: 104
configs skipped: 1
The following configs have been built successfully.
More configs may be tested in the coming days.
arm64 allyesconfig
arm64 defconfig
arm64 allmodconfig
arm64 allnoconfig
arm defconfig
arm allyesconfig
arm allmodconfig
arm allnoconfig
sparc allyesconfig
mips allyesconfig
m68k allyesconfig
i386 allnoconfig
i386 allyesconfig
i386 defconfig
i386 debian-10.3
ia64 allmodconfig
ia64 defconfig
ia64 allnoconfig
ia64 allyesconfig
m68k allmodconfig
m68k allnoconfig
m68k sun3_defconfig
m68k defconfig
nios2 defconfig
nios2 allyesconfig
openrisc defconfig
c6x allyesconfig
c6x allnoconfig
openrisc allyesconfig
nds32 defconfig
nds32 allnoconfig
csky allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa defconfig
xtensa allyesconfig
h8300 allyesconfig
h8300 allmodconfig
arc defconfig
arc allyesconfig
sh allmodconfig
sh allnoconfig
microblaze allnoconfig
mips allnoconfig
mips allmodconfig
parisc allnoconfig
parisc defconfig
parisc allyesconfig
parisc allmodconfig
powerpc defconfig
powerpc allyesconfig
powerpc rhel-kconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a001-20200521
i386 randconfig-a004-20200521
i386 randconfig-a006-20200521
i386 randconfig-a003-20200521
i386 randconfig-a002-20200521
i386 randconfig-a005-20200521
x86_64 randconfig-a013-20200520
x86_64 randconfig-a015-20200520
x86_64 randconfig-a016-20200520
x86_64 randconfig-a012-20200520
x86_64 randconfig-a014-20200520
x86_64 randconfig-a011-20200520
i386 randconfig-a013-20200522
i386 randconfig-a012-20200522
i386 randconfig-a015-20200522
i386 randconfig-a011-20200522
i386 randconfig-a016-20200522
i386 randconfig-a014-20200522
x86_64 randconfig-a002-20200521
x86_64 randconfig-a006-20200521
x86_64 randconfig-a005-20200521
x86_64 randconfig-a004-20200521
x86_64 randconfig-a003-20200521
x86_64 randconfig-a001-20200521
riscv allyesconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
s390 allyesconfig
s390 allnoconfig
s390 allmodconfig
s390 defconfig
x86_64 defconfig
sparc defconfig
sparc64 defconfig
sparc64 allnoconfig
sparc64 allyesconfig
sparc64 allmodconfig
um allnoconfig
um defconfig
um allyesconfig
um allmodconfig
x86_64 rhel
x86_64 rhel-7.6
x86_64 rhel-7.6-kselftests
x86_64 rhel-7.2-clear
x86_64 lkp
x86_64 fedora-25
x86_64 kexec
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: [PATCH v2 3/5] libnvdimm/nvdimm/flush: Allow architecture to override the flush barrier
From: Aneesh Kumar K.V @ 2020-05-22 10:08 UTC (permalink / raw)
To: Michal Suchánek, Mikulas Patocka
Cc: Jan Kara, linux-nvdimm, alistair, Jeff Moyer, Dan Williams,
linuxppc-dev
In-Reply-To: <20200522093127.GY25173@kitsune.suse.cz>
On 5/22/20 3:01 PM, Michal Suchánek wrote:
> On Thu, May 21, 2020 at 02:52:30PM -0400, Mikulas Patocka wrote:
>>
>>
>> On Thu, 21 May 2020, Dan Williams wrote:
>>
>>> On Thu, May 21, 2020 at 10:03 AM Aneesh Kumar K.V
>>> <aneesh.kumar@linux.ibm.com> wrote:
>>>>
>>>>> Moving on to the patch itself--Aneesh, have you audited other persistent
>>>>> memory users in the kernel? For example, drivers/md/dm-writecache.c does
>>>>> this:
>>>>>
>>>>> static void writecache_commit_flushed(struct dm_writecache *wc, bool wait_for_ios)
>>>>> {
>>>>> if (WC_MODE_PMEM(wc))
>>>>> wmb(); <==========
>>>>> else
>>>>> ssd_commit_flushed(wc, wait_for_ios);
>>>>> }
>>>>>
>>>>> I believe you'll need to make modifications there.
>>>>>
>>>>
>>>> Correct. Thanks for catching that.
>>>>
>>>>
>>>> I don't understand dm much, wondering how this will work with
>>>> non-synchronous DAX device?
>>>
>>> That's a good point. DM-writecache needs to be cognizant of things
>>> like virtio-pmem that violate the rule that persisent memory writes
>>> can be flushed by CPU functions rather than calling back into the
>>> driver. It seems we need to always make the flush case a dax_operation
>>> callback to account for this.
>>
>> dm-writecache is normally sitting on the top of dm-linear, so it would
>> need to pass the wmb() call through the dm core and dm-linear target ...
>> that would slow it down ... I remember that you already did it this way
>> some times ago and then removed it.
>>
>> What's the exact problem with POWER? Could the POWER system have two types
>> of persistent memory that need two different ways of flushing?
>
> As far as I understand the discussion so far
>
> - on POWER $oldhardware uses $oldinstruction to ensure pmem consistency
> - on POWER $newhardware uses $newinstruction to ensure pmem consistency
> (compatible with $oldinstruction on $oldhardware)
Correct.
> - on some platforms instead of barrier instruction a callback into the
> driver is issued to ensure consistency
This is virtio-pmem only at this point IIUC.
>
> None of this is reflected by the dm driver.
>
-aneesh
^ permalink raw reply
* [PATCH] ASoC: fsl_asrc: Merge suspend/resume function to runtime_suspend/resume
From: Shengjiu Wang @ 2020-05-22 9:57 UTC (permalink / raw)
To: timur, nicoleotsuka, Xiubo.Lee, festevam, broonie, alsa-devel,
lgirdwood, perex, tiwai
Cc: linuxppc-dev, linux-kernel
With dedicated power domain for asrc, power can be disabled after
probe and pm runtime suspend, then the value of all registers need to
be restored in pm runtime resume. So we can merge suspend/resume function
to runtime_suspend/resume function and enable regcache only in end of
probe.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
---
sound/soc/fsl/fsl_asrc.c | 70 ++++++++++++++++------------------------
1 file changed, 27 insertions(+), 43 deletions(-)
diff --git a/sound/soc/fsl/fsl_asrc.c b/sound/soc/fsl/fsl_asrc.c
index 432936039de4..3ebbe15ac378 100644
--- a/sound/soc/fsl/fsl_asrc.c
+++ b/sound/soc/fsl/fsl_asrc.c
@@ -1100,6 +1100,7 @@ static int fsl_asrc_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, asrc);
pm_runtime_enable(&pdev->dev);
spin_lock_init(&asrc->lock);
+ regcache_cache_only(asrc->regmap, true);
ret = devm_snd_soc_register_component(&pdev->dev, &fsl_asrc_component,
&fsl_asrc_dai, 1);
@@ -1117,6 +1118,7 @@ static int fsl_asrc_runtime_resume(struct device *dev)
struct fsl_asrc *asrc = dev_get_drvdata(dev);
struct fsl_asrc_priv *asrc_priv = asrc->private;
int i, ret;
+ u32 asrctr;
ret = clk_prepare_enable(asrc->mem_clk);
if (ret)
@@ -1135,6 +1137,24 @@ static int fsl_asrc_runtime_resume(struct device *dev)
goto disable_asrck_clk;
}
+ /* Stop all pairs provisionally */
+ regmap_read(asrc->regmap, REG_ASRCTR, &asrctr);
+ regmap_update_bits(asrc->regmap, REG_ASRCTR,
+ ASRCTR_ASRCEi_ALL_MASK, 0);
+
+ /* Restore all registers */
+ regcache_cache_only(asrc->regmap, false);
+ regcache_mark_dirty(asrc->regmap);
+ regcache_sync(asrc->regmap);
+
+ regmap_update_bits(asrc->regmap, REG_ASRCFG,
+ ASRCFG_NDPRi_ALL_MASK | ASRCFG_POSTMODi_ALL_MASK |
+ ASRCFG_PREMODi_ALL_MASK, asrc_priv->regcache_cfg);
+
+ /* Restart enabled pairs */
+ regmap_update_bits(asrc->regmap, REG_ASRCTR,
+ ASRCTR_ASRCEi_ALL_MASK, asrctr);
+
return 0;
disable_asrck_clk:
@@ -1155,6 +1175,11 @@ static int fsl_asrc_runtime_suspend(struct device *dev)
struct fsl_asrc_priv *asrc_priv = asrc->private;
int i;
+ regmap_read(asrc->regmap, REG_ASRCFG,
+ &asrc_priv->regcache_cfg);
+
+ regcache_cache_only(asrc->regmap, true);
+
for (i = 0; i < ASRC_CLK_MAX_NUM; i++)
clk_disable_unprepare(asrc_priv->asrck_clk[i]);
if (!IS_ERR(asrc->spba_clk))
@@ -1166,51 +1191,10 @@ static int fsl_asrc_runtime_suspend(struct device *dev)
}
#endif /* CONFIG_PM */
-#ifdef CONFIG_PM_SLEEP
-static int fsl_asrc_suspend(struct device *dev)
-{
- struct fsl_asrc *asrc = dev_get_drvdata(dev);
- struct fsl_asrc_priv *asrc_priv = asrc->private;
-
- regmap_read(asrc->regmap, REG_ASRCFG,
- &asrc_priv->regcache_cfg);
-
- regcache_cache_only(asrc->regmap, true);
- regcache_mark_dirty(asrc->regmap);
-
- return 0;
-}
-
-static int fsl_asrc_resume(struct device *dev)
-{
- struct fsl_asrc *asrc = dev_get_drvdata(dev);
- struct fsl_asrc_priv *asrc_priv = asrc->private;
- u32 asrctr;
-
- /* Stop all pairs provisionally */
- regmap_read(asrc->regmap, REG_ASRCTR, &asrctr);
- regmap_update_bits(asrc->regmap, REG_ASRCTR,
- ASRCTR_ASRCEi_ALL_MASK, 0);
-
- /* Restore all registers */
- regcache_cache_only(asrc->regmap, false);
- regcache_sync(asrc->regmap);
-
- regmap_update_bits(asrc->regmap, REG_ASRCFG,
- ASRCFG_NDPRi_ALL_MASK | ASRCFG_POSTMODi_ALL_MASK |
- ASRCFG_PREMODi_ALL_MASK, asrc_priv->regcache_cfg);
-
- /* Restart enabled pairs */
- regmap_update_bits(asrc->regmap, REG_ASRCTR,
- ASRCTR_ASRCEi_ALL_MASK, asrctr);
-
- return 0;
-}
-#endif /* CONFIG_PM_SLEEP */
-
static const struct dev_pm_ops fsl_asrc_pm = {
SET_RUNTIME_PM_OPS(fsl_asrc_runtime_suspend, fsl_asrc_runtime_resume, NULL)
- SET_SYSTEM_SLEEP_PM_OPS(fsl_asrc_suspend, fsl_asrc_resume)
+ SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+ pm_runtime_force_resume)
};
static const struct fsl_asrc_soc_data fsl_asrc_imx35_data = {
--
2.21.0
^ permalink raw reply related
* Re: [PATCH v2 3/5] libnvdimm/nvdimm/flush: Allow architecture to override the flush barrier
From: Michal Suchánek @ 2020-05-22 9:31 UTC (permalink / raw)
To: Mikulas Patocka
Cc: Jan Kara, linux-nvdimm, Aneesh Kumar K.V, Jeff Moyer, alistair,
Dan Williams, linuxppc-dev
In-Reply-To: <alpine.LRH.2.02.2005211442290.22894@file01.intranet.prod.int.rdu2.redhat.com>
On Thu, May 21, 2020 at 02:52:30PM -0400, Mikulas Patocka wrote:
>
>
> On Thu, 21 May 2020, Dan Williams wrote:
>
> > On Thu, May 21, 2020 at 10:03 AM Aneesh Kumar K.V
> > <aneesh.kumar@linux.ibm.com> wrote:
> > >
> > > > Moving on to the patch itself--Aneesh, have you audited other persistent
> > > > memory users in the kernel? For example, drivers/md/dm-writecache.c does
> > > > this:
> > > >
> > > > static void writecache_commit_flushed(struct dm_writecache *wc, bool wait_for_ios)
> > > > {
> > > > if (WC_MODE_PMEM(wc))
> > > > wmb(); <==========
> > > > else
> > > > ssd_commit_flushed(wc, wait_for_ios);
> > > > }
> > > >
> > > > I believe you'll need to make modifications there.
> > > >
> > >
> > > Correct. Thanks for catching that.
> > >
> > >
> > > I don't understand dm much, wondering how this will work with
> > > non-synchronous DAX device?
> >
> > That's a good point. DM-writecache needs to be cognizant of things
> > like virtio-pmem that violate the rule that persisent memory writes
> > can be flushed by CPU functions rather than calling back into the
> > driver. It seems we need to always make the flush case a dax_operation
> > callback to account for this.
>
> dm-writecache is normally sitting on the top of dm-linear, so it would
> need to pass the wmb() call through the dm core and dm-linear target ...
> that would slow it down ... I remember that you already did it this way
> some times ago and then removed it.
>
> What's the exact problem with POWER? Could the POWER system have two types
> of persistent memory that need two different ways of flushing?
As far as I understand the discussion so far
- on POWER $oldhardware uses $oldinstruction to ensure pmem consistency
- on POWER $newhardware uses $newinstruction to ensure pmem consistency
(compatible with $oldinstruction on $oldhardware)
- on some platforms instead of barrier instruction a callback into the
driver is issued to ensure consistency
None of this is reflected by the dm driver.
Thanks
Michal
^ permalink raw reply
* Re: [RESEND PATCH v7 4/5] ndctl/papr_scm, uapi: Add support for PAPR nvdimm specific methods
From: Vaibhav Jain @ 2020-05-22 7:38 UTC (permalink / raw)
To: Michael Ellerman, Ira Weiny
Cc: Aneesh Kumar K . V, linuxppc-dev, linux-kernel, Steven Rostedt,
linux-nvdimm
In-Reply-To: <87367t941j.fsf@mpe.ellerman.id.au>
Michael Ellerman <mpe@ellerman.id.au> writes:
> Ira Weiny <ira.weiny@intel.com> writes:
>> On Wed, May 20, 2020 at 12:30:57AM +0530, Vaibhav Jain wrote:
>>> Introduce support for Papr nvDimm Specific Methods (PDSM) in papr_scm
>>> modules and add the command family to the white list of NVDIMM command
>>> sets. Also advertise support for ND_CMD_CALL for the dimm
>>> command mask and implement necessary scaffolding in the module to
>>> handle ND_CMD_CALL ioctl and PDSM requests that we receive.
> ...
>>> + *
>>> + * Payload Version:
>>> + *
>>> + * A 'payload_version' field is present in PDSM header that indicates a specific
>>> + * version of the structure present in PDSM Payload for a given PDSM command.
>>> + * This provides backward compatibility in case the PDSM Payload structure
>>> + * evolves and different structures are supported by 'papr_scm' and 'libndctl'.
>>> + *
>>> + * When sending a PDSM Payload to 'papr_scm', 'libndctl' should send the version
>>> + * of the payload struct it supports via 'payload_version' field. The 'papr_scm'
>>> + * module when servicing the PDSM envelope checks the 'payload_version' and then
>>> + * uses 'payload struct version' == MIN('payload_version field',
>>> + * 'max payload-struct-version supported by papr_scm') to service the PDSM.
>>> + * After servicing the PDSM, 'papr_scm' put the negotiated version of payload
>>> + * struct in returned 'payload_version' field.
>>
>> FWIW many people believe using a size rather than version is more sustainable.
>> It is expected that new payload structures are larger (more features) than the
>> previous payload structure.
>>
>> I can't find references at the moment through.
>
> I think clone_args is a good modern example:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/sched.h#n88
>
> cheers
Thank Ira and Mpe for pointing this out. I looked into how clone3 sycall
handles clone_args and few differences came out:
* Unlike clone_args that are always transferred in one direction from
user-space to kernel, payload contents of pdsms are transferred in both
directions. Having a single version number makes it easier for
user-space and kernel to determine what data will be exchanged.
* For PDSMs, the version number is negotiated between libndctl and
kernel. For example in case kernel only supports an older version of
a structure, its free to send a lower version number back to
libndctl. Such negotiations doesnt happen with clone3 syscall.
--
Cheers
~ Vaibhav
^ permalink raw reply
* Re: [PATCH V3 0/3] arm64: Enable vmemmap mapping from device memory
From: Jia He @ 2020-05-22 3:58 UTC (permalink / raw)
To: Anshuman Khandual, linux-mm
Cc: Mark Rutland, Michal Hocko, Thomas Gleixner, David Hildenbrand,
Peter Zijlstra, Catalin Marinas, Dave Hansen, Paul Mackerras,
linux-ia64, linux-riscv, Will Deacon, jgg, aneesh.kumar, x86,
Matthew Wilcox (Oracle), Mike Rapoport, Kaly Xin, Ingo Molnar,
Fenghua Yu, rcampbell, Pavel Tatashin, jglisse, Andy Lutomirski,
Paul Walmsley, dan.j.williams, linux-arm-kernel, Tony Luck,
linuxppc-dev, linux-kernel, Palmer Dabbelt, Andrew Morton,
robin.murphy, Kirill A. Shutemov
In-Reply-To: <1585631387-18819-1-git-send-email-anshuman.khandual@arm.com>
Hi
On 2020/3/31 13:09, Anshuman Khandual wrote:
> This series enables vmemmap backing memory allocation from device memory
> ranges on arm64. But before that, it enables vmemmap_populate_basepages()
> and vmemmap_alloc_block_buf() to accommodate struct vmem_altmap based
> alocation requests.
I verified no obvious regression after this patch series.
Host: ThunderX2(armv8a server), kernel v5.4
qemu:v3.1, -M virt \
-object
memory-backend-file,id=mem1,share=on,mem-path=/tmp2/nvdimm.img,size=4G,align=2M \
-device nvdimm,id=nvdimm1,memdev=mem1,label-size=2M
Guest: kernel v5.7.0-rc5 with this patch series.
Tested case:
- 4K PAGESIZE, boot, mount w/ -o dax, mount w/o -o dax, basic io
- 64K PAGESIZE,boot, mount w/ -o dax, mount w/o -o dax, basic io
Not tested:
- 16K pagesize due to my hardware limiation(can't run 16K pgsz kernel)
- hot-add/remove nvdimm device from qemu due to no fully support on arm64 qemu yet
- Host nvdimm device hotplug
Hence from above result,
Tested-by: Jia He <justin.he@arm.com>
> This series applies after latest (v14) arm64 memory hot remove series
> (https://lkml.org/lkml/2020/3/3/1746) on Linux 5.6.
>
> Pending Question:
>
> altmap_alloc_block_buf() does not have any other remaining users in the
> tree after this change. Should it be converted into a static function and
> it's declaration be dropped from the header (include/linux/mm.h). Avoided
> doing so because I was not sure if there are any off-tree users or not.
>
> Changes in V3:
>
> - Dropped comment from free_hotplug_page_range() per Robin
> - Modified comment in unmap_hotplug_range() per Robin
> - Enabled altmap support in vmemmap_alloc_block_buf() per Robin
>
> Changes in V2: (https://lkml.org/lkml/2020/3/4/475)
>
> - Rebased on latest hot-remove series (v14) adding P4D page table support
>
> Changes in V1: (https://lkml.org/lkml/2020/1/23/12)
>
> - Added an WARN_ON() in unmap_hotplug_range() when altmap is
> provided without the page table backing memory being freed
>
> Changes in RFC V2: (https://lkml.org/lkml/2019/10/21/11)
>
> - Changed the commit message on 1/2 patch per Will
> - Changed the commit message on 2/2 patch as well
> - Rebased on arm64 memory hot remove series (v10)
>
> RFC V1: (https://lkml.org/lkml/2019/6/28/32)
>
> Cc: Catalin Marinas<catalin.marinas@arm.com>
> Cc: Will Deacon<will@kernel.org>
> Cc: Mark Rutland<mark.rutland@arm.com>
> Cc: Paul Walmsley<paul.walmsley@sifive.com>
> Cc: Palmer Dabbelt<palmer@dabbelt.com>
> Cc: Tony Luck<tony.luck@intel.com>
> Cc: Fenghua Yu<fenghua.yu@intel.com>
> Cc: Dave Hansen<dave.hansen@linux.intel.com>
> Cc: Andy Lutomirski<luto@kernel.org>
> Cc: Peter Zijlstra<peterz@infradead.org>
> Cc: Thomas Gleixner<tglx@linutronix.de>
> Cc: Ingo Molnar<mingo@redhat.com>
> Cc: David Hildenbrand<david@redhat.com>
> Cc: Mike Rapoport<rppt@linux.ibm.com>
> Cc: Michal Hocko<mhocko@suse.com>
> Cc: "Matthew Wilcox (Oracle)"<willy@infradead.org>
> Cc: "Kirill A. Shutemov"<kirill.shutemov@linux.intel.com>
> Cc: Andrew Morton<akpm@linux-foundation.org>
> Cc: Dan Williams<dan.j.williams@intel.com>
> Cc: Pavel Tatashin<pasha.tatashin@soleen.com>
> Cc: Benjamin Herrenschmidt<benh@kernel.crashing.org>
> Cc: Paul Mackerras<paulus@samba.org>
> Cc: Michael Ellerman<mpe@ellerman.id.au>
> Cc:linux-arm-kernel@lists.infradead.org
> Cc:linux-ia64@vger.kernel.org
> Cc:linux-riscv@lists.infradead.org
> Cc:x86@kernel.org
> Cc:linuxppc-dev@lists.ozlabs.org
> Cc:linux-mm@kvack.org
> Cc:linux-kernel@vger.kernel.org
>
> Anshuman Khandual (3):
> mm/sparsemem: Enable vmem_altmap support in vmemmap_populate_basepages()
> mm/sparsemem: Enable vmem_altmap support in vmemmap_alloc_block_buf()
> arm64/mm: Enable vmem_altmap support for vmemmap mappings
>
> arch/arm64/mm/mmu.c | 59 ++++++++++++++++++++++++++-------------
> arch/ia64/mm/discontig.c | 2 +-
> arch/powerpc/mm/init_64.c | 10 +++----
> arch/riscv/mm/init.c | 2 +-
> arch/x86/mm/init_64.c | 12 ++++----
> include/linux/mm.h | 8 ++++--
> mm/sparse-vmemmap.c | 38 ++++++++++++++++++++-----
> 7 files changed, 87 insertions(+), 44 deletions(-)
>
--
---
Cheers,
Justin (Jia He)
^ permalink raw reply
* Re: [PATCH] arch/{mips,sparc,microblaze,powerpc}: Don't enable pagefault/preempt twice
From: Guenter Roeck @ 2020-05-22 2:28 UTC (permalink / raw)
To: Al Viro
Cc: Peter Zijlstra, Dave Hansen, dri-devel, linux-mips,
James E.J. Bottomley, Max Filippov, Paul Mackerras,
H. Peter Anvin, sparclinux, ira.weiny, Dan Williams, Helge Deller,
x86, linux-csky, Christoph Hellwig, Ingo Molnar, linux-snps-arc,
linux-xtensa, Borislav Petkov, Andy Lutomirski, Thomas Gleixner,
linux-arm-kernel, Chris Zankel, Thomas Bogendoerfer, linux-parisc,
linux-kernel, Christian Koenig, Andrew Morton, linuxppc-dev,
David S. Miller
In-Reply-To: <20200522013523.GO23230@ZenIV.linux.org.uk>
On Fri, May 22, 2020 at 02:35:23AM +0100, Al Viro wrote:
> On Fri, May 22, 2020 at 02:29:50AM +0100, Al Viro wrote:
> > On Thu, May 21, 2020 at 06:11:08PM -0700, Guenter Roeck wrote:
> >
> > > Mainline, with:
> > >
> > > qemu-system-sparc -M SS-4 -kernel arch/sparc/boot/zImage -no-reboot \
> > > -snapshot -drive file=rootfs.ext2,format=raw,if=scsi \
> > > -append "panic=-1 slub_debug=FZPUA root=/dev/sda console=ttyS0"
> > > -nographic -monitor none
> > >
> > > The machine doesn't really matter, though.
> >
> > It does, unfortunately - try that with SS-10 and watch what happens ;-/
>
> Ugh... It's actually something in -m handling: -m 256 passes, -m 512
> leads to that panic.
Default seems to be 128M. Anyway, see below log for SS-10.
Guenter
---
Configuration device id QEMU version 1 machine id 64
Probing SBus slot 0 offset 0
Probing SBus slot 1 offset 0
Probing SBus slot 2 offset 0
Probing SBus slot 3 offset 0
Probing SBus slot 15 offset 0
Invalid FCode start byte
CPUs: 1 x TI,TMS390Z55
UUID: 00000000-0000-0000-0000-000000000000
Welcome to OpenBIOS v1.1 built on Oct 28 2019 17:08
Type 'help' for detailed information
[sparc] Kernel already loaded
switching to new context:
PROMLIB: obio_ranges 1
PROMLIB: Sun Boot Prom Version 3 Revision 2
Linux version 5.7.0-rc6-00026-g03fb3acae4be (groeck@server.roeck-us.net) (gcc version 6.5.0 (Buildroot 2018.11-rc2-00071-g4310260), GNU ld (GNU Binutils) 2.31.1) #1 Thu May 21 19:17:48 PDT 2020
printk: bootconsole [earlyprom0] enabled
ARCH: SUN4M
TYPE: Sun4m SparcStation10/20
Ethernet address: 52:54:00:12:34:56
OF stdout device is: /obio/zs@0,100000:a
PROM: Built device tree with 30586 bytes of memory.
Booting Linux...
Power off control detected.
Built 1 zonelists, mobility grouping on. Total pages: 25012
Kernel command line: panic=-1 slub_debug=FZPUA root=/dev/sda console=ttyS0
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes, linear)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes, linear)
Sorting __ex_table...
mem auto-init: stack:off, heap alloc:off, heap free:off
Memory: 103428K/100944K available (5050K kernel code, 178K rwdata, 1212K rodata, 176K init, 158K bss, 4294964812K reserved, 0K cma-reserved, 0K highmem)
NR_IRQS: 64
Console: colour dummy device 80x25
------------------------
| Locking API testsuite:
----------------------------------------------------------------------------
| spin |wlock |rlock |mutex | wsem | rsem |
--------------------------------------------------------------------------
A-A deadlock:failed|failed| ok |failed|failed|failed|failed|
A-B-B-A deadlock:failed|failed| ok |failed|failed|failed|failed|
A-B-B-C-C-A deadlock:failed|failed| ok |failed|failed|failed|failed|
A-B-C-A-B-C deadlock:failed|failed| ok |failed|failed|failed|failed|
A-B-B-C-C-D-D-A deadlock:failed|failed| ok |failed|failed|failed|failed|
A-B-C-D-B-D-D-A deadlock:failed|failed| ok |failed|failed|failed|failed|
A-B-C-D-B-C-D-A deadlock:failed|failed| ok |failed|failed|failed|failed|
double unlock: ok | ok |failed| ok |failed|failed| ok |
initialize held:failed|failed|failed|failed|failed|failed|failed|
--------------------------------------------------------------------------
recursive read-lock: | ok | |failed|
recursive read-lock #2: | ok | |failed|
mixed read-write-lock: |failed| |failed|
mixed write-read-lock: |failed| |failed|
mixed read-lock/lock-write ABBA: |failed| |failed|
mixed read-lock/lock-read ABBA: | ok | |failed|
mixed write-lock/lock-write ABBA: |failed| |failed|
--------------------------------------------------------------------------
hard-irqs-on + irq-safe-A/12:failed|failed| ok |
soft-irqs-on + irq-safe-A/12:failed|failed| ok |
hard-irqs-on + irq-safe-A/21:failed|failed| ok |
soft-irqs-on + irq-safe-A/21:failed|failed| ok |
sirq-safe-A => hirqs-on/12:failed|failed| ok |
sirq-safe-A => hirqs-on/21:failed|failed| ok |
hard-safe-A + irqs-on/12:failed|failed| ok |
soft-safe-A + irqs-on/12:failed|failed| ok |
hard-safe-A + irqs-on/21:failed|failed| ok |
soft-safe-A + irqs-on/21:failed|failed| ok |
hard-safe-A + unsafe-B #1/123:failed|failed| ok |
soft-safe-A + unsafe-B #1/123:failed|failed| ok |
hard-safe-A + unsafe-B #1/132:failed|failed| ok |
soft-safe-A + unsafe-B #1/132:failed|failed| ok |
hard-safe-A + unsafe-B #1/213:failed|failed| ok |
soft-safe-A + unsafe-B #1/213:failed|failed| ok |
hard-safe-A + unsafe-B #1/231:failed|failed| ok |
soft-safe-A + unsafe-B #1/231:failed|failed| ok |
hard-safe-A + unsafe-B #1/312:failed|failed| ok |
soft-safe-A + unsafe-B #1/312:failed|failed| ok |
hard-safe-A + unsafe-B #1/321:failed|failed| ok |
soft-safe-A + unsafe-B #1/321:failed|failed| ok |
hard-safe-A + unsafe-B #2/123:failed|failed| ok |
soft-safe-A + unsafe-B #2/123:failed|failed| ok |
hard-safe-A + unsafe-B #2/132:failed|failed| ok |
soft-safe-A + unsafe-B #2/132:failed|failed| ok |
hard-safe-A + unsafe-B #2/213:failed|failed| ok |
soft-safe-A + unsafe-B #2/213:failed|failed| ok |
hard-safe-A + unsafe-B #2/231:failed|failed| ok |
soft-safe-A + unsafe-B #2/231:failed|failed| ok |
hard-safe-A + unsafe-B #2/312:failed|failed| ok |
soft-safe-A + unsafe-B #2/312:failed|failed| ok |
hard-safe-A + unsafe-B #2/321:failed|failed| ok |
soft-safe-A + unsafe-B #2/321:failed|failed| ok |
hard-irq lock-inversion/123:failed|failed| ok |
soft-irq lock-inversion/123:failed|failed| ok |
hard-irq lock-inversion/132:failed|failed| ok |
soft-irq lock-inversion/132:failed|failed| ok |
hard-irq lock-inversion/213:failed|failed| ok |
soft-irq lock-inversion/213:failed|failed| ok |
hard-irq lock-inversion/231:failed|failed| ok |
soft-irq lock-inversion/231:failed|failed| ok |
hard-irq lock-inversion/312:failed|failed| ok |
soft-irq lock-inversion/312:failed|failed| ok |
hard-irq lock-inversion/321:failed|failed| ok |
soft-irq lock-inversion/321:failed|failed| ok |
hard-irq read-recursion/123: ok |
soft-irq read-recursion/123: ok |
hard-irq read-recursion/132: ok |
soft-irq read-recursion/132: ok |
hard-irq read-recursion/213: ok |
soft-irq read-recursion/213: ok |
hard-irq read-recursion/231: ok |
soft-irq read-recursion/231: ok |
hard-irq read-recursion/312: ok |
soft-irq read-recursion/312: ok |
hard-irq read-recursion/321: ok |
soft-irq read-recursion/321: ok |
--------------------------------------------------------------------------
| Wound/wait tests |
---------------------
ww api failures: ok | ok | ok |
ww contexts mixing:failed| ok |
finishing ww context: ok | ok | ok | ok |
locking mismatches: ok | ok | ok |
EDEADLK handling: ok | ok | ok | ok | ok | ok | ok | ok | ok | ok |
spinlock nest unlocked:failed|
-----------------------------------------------------
|block | try |context|
-----------------------------------------------------
context:failed| ok | ok |
try:failed| ok |failed|
block:failed| ok |failed|
spinlock:failed| ok |failed|
--------------------------------------------------------
164 out of 262 testcases failed, as expected. |
----------------------------------------------------
clocksource: timer_cs: mask: 0xffffffffffffffff max_cycles: 0x1d854df40, max_idle_ns: 1763180808480 ns
Calibrating delay loop... 518.14 BogoMIPS (lpj=1036288)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
devtmpfs: initialized
random: get_random_u32 called from bucket_table_alloc.isra.22+0x50/0x1e4 with crng_init=0
clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
futex hash table entries: 256 (order: 0, 7168 bytes, linear)
NET: Registered protocol family 16
IOMMU: impl 0 vers 3 table 0x(ptrval)[262144 B] map [65536 b]
vgaarb: loaded
SCSI subsystem initialized
clocksource: Switched to clocksource timer_cs
NET: Registered protocol family 2
tcp_listen_portaddr_hash hash table entries: 256 (order: 0, 6144 bytes, linear)
TCP established hash table entries: 1024 (order: 0, 4096 bytes, linear)
TCP bind hash table entries: 1024 (order: 2, 20480 bytes, linear)
TCP: Hash tables configured (established 1024 bind 1024)
UDP hash table entries: 256 (order: 1, 12288 bytes, linear)
UDP-Lite hash table entries: 256 (order: 1, 12288 bytes, linear)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
PCI: CLS 0 bytes, default 32
apc: power management initialized
random: fast init done
workingset: timestamp_bits=30 max_order=15 bucket_order=0
squashfs: version 4.0 (2009/01/31) Phillip Lougher
jitterentropy: Initialization failed with host not compliant with requirements: 2
io scheduler mq-deadline registered
io scheduler kyber registered
String selftests succeeded
test_firmware: interface ready
test passed
test_bitmap: loaded.
test_bitmap: parselist: 14: input is '0-2047:128/256' OK, Time: 2000
test_bitmap: parselist_user: 14: input is '0-2047:128/256' OK, Time: 3000
test_bitmap: all 1663 tests passed
test_uuid: all 18 tests passed
crc32: CRC_LE_BITS = 64, CRC_BE BITS = 64
crc32: self tests passed, processed 225944 bytes in 450500 nsec
crc32c: CRC_LE_BITS = 64
crc32c: self tests passed, processed 225944 bytes in 249000 nsec
crc32_combine: 8373 self tests passed
crc32c_combine: 8373 self tests passed
rbtree testing
-> test 1 (latency of nnodes insert+delete): 0 cycles
-> test 2 (latency of nnodes cached insert+delete): 0 cycles
-> test 3 (latency of inorder traversal): 0 cycles
-> test 4 (latency to fetch first node)
non-cached: 0 cycles
cached: 0 cycles
augmented rbtree testing
-> test 1 (latency of nnodes insert+delete): 0 cycles
-> test 2 (latency of nnodes cached insert+delete): 0 cycles
interval tree insert/remove
-> 0 cycles
interval tree search
-> 0 cycles (2692 results)
ffd374f8: ttyS0 at MMIO 0xf1100000 (irq = 5, base_baud = 307200) is a zs
Console: ttyS0 (SunZilog zs0)
printk: console [ttyS0] enabled
printk: console [ttyS0] enabled
printk: bootconsole [earlyprom0] disabled
printk: bootconsole [earlyprom0] disabled
ffd374f8: ttyS1 at MMIO 0xf1100004 (irq = 5, base_baud = 307200) is a zs
ffd37770: Keyboard at MMIO 0xf1000000 (irq = 5) is a zs
ffd37770: Mouse at MMIO 0xf1000004 (irq = 5) is a zs
brd: module loaded
esp ffd392ec: esp0: regs[(ptrval):(ptrval)] irq[2]
esp ffd392ec: esp0: is a FAS100A, 40 MHz (ccf=0), SCSI ID 7
scsi host0: esp
scsi 0:0:0:0: Direct-Access QEMU QEMU HARDDISK 2.5+ PQ: 0 ANSI: 5
scsi target0:0:0: Beginning Domain Validation
scsi target0:0:0: Domain Validation skipping write tests
scsi target0:0:0: Ending Domain Validation
scsi 0:0:2:0: CD-ROM QEMU QEMU CD-ROM 2.5+ PQ: 0 ANSI: 5
scsi target0:0:2: Beginning Domain Validation
scsi target0:0:2: Domain Validation skipping write tests
scsi target0:0:2: Ending Domain Validation
sr 0:0:2:0: [sr0] scsi3-mmc drive: 16x/50x cd/rw xa/form2 cdda tray
cdrom: Uniform CD-ROM driver Revision: 3.20
sd 0:0:0:0: [sda] 40960 512-byte logical blocks: (21.0 MB/20.0 MiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 0:0:0:0: [sda] Attached SCSI disk
ioremap: done with statics, switching to malloc
SunLance: using auto-carrier-detection.
eth0: LANCE 52:54:00:12:34:56
rtc-m48t59 rtc-m48t59.0: IRQ index 0 not found
rtc-m48t59 rtc-m48t59.0: registered as rtc0
rtc-m48t59 rtc-m48t59.0: setting system clock to 2020-05-22T02:19:50 UTC (1590113990)
sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
NET: Registered protocol family 10
Segment Routing with IPv6
sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
NET: Registered protocol family 17
TAP version 14
# Subtest: sysctl_test
1..10
ok 1 - sysctl_test_api_dointvec_null_tbl_data
ok 2 - sysctl_test_api_dointvec_table_maxlen_unset
ok 3 - sysctl_test_api_dointvec_table_len_is_zero
ok 4 - sysctl_test_api_dointvec_table_read_but_position_set
ok 5 - sysctl_test_dointvec_read_happy_single_positive
ok 6 - sysctl_test_dointvec_read_happy_single_negative
ok 7 - sysctl_test_dointvec_write_happy_single_positive
ok 8 - sysctl_test_dointvec_write_happy_single_negative
ok 9 - sysctl_test_api_dointvec_write_single_less_int_min
ok 10 - sysctl_test_api_dointvec_write_single_greater_int_max
ok 1 - sysctl_test
# Subtest: ext4_inode_test
1..1
ok 1 - inode_test_xtimestamp_decoding
ok 2 - ext4_inode_test
# Subtest: kunit-try-catch-test
1..2
ok 1 - kunit_test_try_catch_successful_try_no_catch
ok 2 - kunit_test_try_catch_unsuccessful_try_does_catch
ok 3 - kunit-try-catch-test
# Subtest: kunit-resource-test
1..5
ok 1 - kunit_resource_test_init_resources
ok 2 - kunit_resource_test_alloc_resource
ok 3 - kunit_resource_test_destroy_resource
ok 4 - kunit_resource_test_cleanup_resources
ok 5 - kunit_resource_test_proper_free_ordering
ok 4 - kunit-resource-test
# Subtest: kunit-log-test
1..1
put this in log.
this too.
add to suite log.
along with this.
ok 1 - kunit_log_test
ok 5 - kunit-log-test
# Subtest: string-stream-test
1..3
ok 1 - string_stream_test_empty_on_creation
ok 2 - string_stream_test_not_empty_after_add
ok 3 - string_stream_test_get_string
ok 6 - string-stream-test
# Subtest: list-kunit-test
1..36
ok 1 - list_test_list_init
ok 2 - list_test_list_add
ok 3 - list_test_list_add_tail
ok 4 - list_test_list_del
ok 5 - list_test_list_replace
ok 6 - list_test_list_replace_init
ok 7 - list_test_list_swap
ok 8 - list_test_list_del_init
ok 9 - list_test_list_move
ok 10 - list_test_list_move_tail
ok 11 - list_test_list_bulk_move_tail
ok 12 - list_test_list_is_first
ok 13 - list_test_list_is_last
ok 14 - list_test_list_empty
ok 15 - list_test_list_empty_careful
ok 16 - list_test_list_rotate_left
ok 17 - list_test_list_rotate_to_front
ok 18 - list_test_list_is_singular
ok 19 - list_test_list_cut_position
ok 20 - list_test_list_cut_before
ok 21 - list_test_list_splice
ok 22 - list_test_list_splice_tail
ok 23 - list_test_list_splice_init
ok 24 - list_test_list_splice_tail_init
ok 25 - list_test_list_entry
ok 26 - list_test_list_first_entry
ok 27 - list_test_list_last_entry
ok 28 - list_test_list_first_entry_or_null
ok 29 - list_test_list_next_entry
ok 30 - list_test_list_prev_entry
ok 31 - list_test_list_for_each
ok 32 - list_test_list_for_each_prev
ok 33 - list_test_list_for_each_safe
ok 34 - list_test_list_for_each_prev_safe
ok 35 - list_test_list_for_each_entry
ok 36 - list_test_list_for_each_entry_reverse
ok 7 - list-kunit-test
# Subtest: qos-kunit-test
1..3
ok 1 - freq_qos_test_min
ok 2 - freq_qos_test_maxdef
ok 3 - freq_qos_test_readd
ok 8 - qos-kunit-test
EXT4-fs (sda): mounted filesystem without journal. Opts: (null)
VFS: Mounted root (ext4 filesystem) readonly on device 8:0.
devtmpfs: mounted
Freeing unused kernel memory: 176K
This architecture does not have kernel memory protection.
Run /sbin/init as init process
EXT4-fs (sda): re-mounted. Opts: (null)
ext4 filesystem being remounted at / supports timestamps until 2038 (0x7fffffff)
Starting syslogd: OK
Starting klogd: OK
Initializing random number generator... random: dd: uninitialized urandom read (512 bytes read)
done.
Starting network: OK
Found console ttyS0
Linux version 5.7.0-rc6-00026-g03fb3acae4be (groeck@server.roeck-us.net) (gcc version 6.5.0 (Buildroot 2018.11-rc2-00071-g4310260), GNU ld (GNU Binutils) 2.31.1) #1 Thu May 21 19:17:48 PDT 2020
Boot successful.
Rebooting
Found console ttyS0
Stopping network: OK
Saving random seed... random: dd: uninitialized urandom read (512 bytes read)
done.
Stopping klogd: OK
Stopping syslogd: OK
umount: devtmpfs busy - remounted read-only
EXT4-fs (sda): re-mounted. Opts: (null)
The system is going down NOW!
Sent SIGTERM to all processes
Sent SIGKILL to all processes
Requesting system reboot
sd 0:0:0:0: [sda] Synchronizing SCSI cache
reboot: Restarting system
^ permalink raw reply
* Re: Endless soft-lockups for compiling workload since next-20200519
From: Qian Cai @ 2020-05-22 2:00 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Paul E. McKenney, Frederic Weisbecker, Linux Kernel Mailing List,
Borislav Petkov, Thomas Gleixner, linuxppc-dev
In-Reply-To: <20200521093938.GG325280@hirez.programming.kicks-ass.net>
On Thu, May 21, 2020 at 11:39:38AM +0200, Peter Zijlstra wrote:
> On Thu, May 21, 2020 at 02:40:36AM +0200, Frederic Weisbecker wrote:
> > On Wed, May 20, 2020 at 02:50:56PM +0200, Peter Zijlstra wrote:
> > > On Tue, May 19, 2020 at 11:58:17PM -0400, Qian Cai wrote:
> > > > Just a head up. Repeatedly compiling kernels for a while would trigger
> > > > endless soft-lockups since next-20200519 on both x86_64 and powerpc.
> > > > .config are in,
> > >
> > > Could be 90b5363acd47 ("sched: Clean up scheduler_ipi()"), although I've
> > > not seen anything like that myself. Let me go have a look.
> > >
> > >
> > > In as far as the logs are readable (they're a wrapped mess, please don't
> > > do that!), they contain very little useful, as is typical with IPIs :/
> > >
> > > > [ 1167.993773][ C1] WARNING: CPU: 1 PID: 0 at kernel/smp.c:127
> > > > flush_smp_call_function_queue+0x1fa/0x2e0
> >
> > So I've tried to think of a race that could produce that and here is
> > the only thing I could come up with. It's a bit complicated unfortunately:
>
> This:
>
> > smp_call_function_single_async() { smp_call_function_single_async() {
> > // verified csd->flags != CSD_LOCK // verified csd->flags != CSD_LOCK
> > csd->flags = CSD_LOCK csd->flags = CSD_LOCK
>
> concurrent smp_call_function_single_async() using the same csd is what
> I'm looking at as well. Now in the ILB case there is an easy cure:
>
> (because there is only a single ilb target)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 01f94cf52783..b6d8a7b991f0 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -10033,7 +10033,7 @@ static void kick_ilb(unsigned int flags)
> * is idle. And the softirq performing nohz idle load balance
> * will be run before returning from the IPI.
> */
> - smp_call_function_single_async(ilb_cpu, &cpu_rq(ilb_cpu)->nohz_csd);
> + smp_call_function_single_async(ilb_cpu, &this_rq()->nohz_csd);
> }
>
> /*
>
> Qian, can you give that a spin?
Running for a few hours now. It works fine.
^ permalink raw reply
* Re: [PATCH] arch/{mips,sparc,microblaze,powerpc}: Don't enable pagefault/preempt twice
From: Al Viro @ 2020-05-22 1:35 UTC (permalink / raw)
To: Guenter Roeck
Cc: Peter Zijlstra, Dave Hansen, dri-devel, linux-mips,
James E.J. Bottomley, Max Filippov, Paul Mackerras,
H. Peter Anvin, sparclinux, ira.weiny, Dan Williams, Helge Deller,
x86, linux-csky, Christoph Hellwig, Ingo Molnar, linux-snps-arc,
linux-xtensa, Borislav Petkov, Andy Lutomirski, Thomas Gleixner,
linux-arm-kernel, Chris Zankel, Thomas Bogendoerfer, linux-parisc,
linux-kernel, Christian Koenig, Andrew Morton, linuxppc-dev,
David S. Miller
In-Reply-To: <20200522012950.GN23230@ZenIV.linux.org.uk>
On Fri, May 22, 2020 at 02:29:50AM +0100, Al Viro wrote:
> On Thu, May 21, 2020 at 06:11:08PM -0700, Guenter Roeck wrote:
>
> > Mainline, with:
> >
> > qemu-system-sparc -M SS-4 -kernel arch/sparc/boot/zImage -no-reboot \
> > -snapshot -drive file=rootfs.ext2,format=raw,if=scsi \
> > -append "panic=-1 slub_debug=FZPUA root=/dev/sda console=ttyS0"
> > -nographic -monitor none
> >
> > The machine doesn't really matter, though.
>
> It does, unfortunately - try that with SS-10 and watch what happens ;-/
Ugh... It's actually something in -m handling: -m 256 passes, -m 512
leads to that panic.
^ permalink raw reply
* Re: [PATCH] arch/{mips,sparc,microblaze,powerpc}: Don't enable pagefault/preempt twice
From: Al Viro @ 2020-05-22 1:29 UTC (permalink / raw)
To: Guenter Roeck
Cc: Peter Zijlstra, Dave Hansen, dri-devel, linux-mips,
James E.J. Bottomley, Max Filippov, Paul Mackerras,
H. Peter Anvin, sparclinux, ira.weiny, Dan Williams, Helge Deller,
x86, linux-csky, Christoph Hellwig, Ingo Molnar, linux-snps-arc,
linux-xtensa, Borislav Petkov, Andy Lutomirski, Thomas Gleixner,
linux-arm-kernel, Chris Zankel, Thomas Bogendoerfer, linux-parisc,
linux-kernel, Christian Koenig, Andrew Morton, linuxppc-dev,
David S. Miller
In-Reply-To: <970857bd-bb56-7b2e-833e-ca74a82fa9b5@roeck-us.net>
On Thu, May 21, 2020 at 06:11:08PM -0700, Guenter Roeck wrote:
> Mainline, with:
>
> qemu-system-sparc -M SS-4 -kernel arch/sparc/boot/zImage -no-reboot \
> -snapshot -drive file=rootfs.ext2,format=raw,if=scsi \
> -append "panic=-1 slub_debug=FZPUA root=/dev/sda console=ttyS0"
> -nographic -monitor none
>
> The machine doesn't really matter, though.
It does, unfortunately - try that with SS-10 and watch what happens ;-/
^ permalink raw reply
* Re: [PATCH] arch/{mips,sparc,microblaze,powerpc}: Don't enable pagefault/preempt twice
From: Guenter Roeck @ 2020-05-22 1:11 UTC (permalink / raw)
To: Al Viro
Cc: Peter Zijlstra, Dave Hansen, dri-devel, linux-mips,
James E.J. Bottomley, Max Filippov, Paul Mackerras,
H. Peter Anvin, sparclinux, ira.weiny, Dan Williams, Helge Deller,
x86, linux-csky, Christoph Hellwig, Ingo Molnar, linux-snps-arc,
linux-xtensa, Borislav Petkov, Andy Lutomirski, Thomas Gleixner,
linux-arm-kernel, Chris Zankel, Thomas Bogendoerfer, linux-parisc,
linux-kernel, Christian Koenig, Andrew Morton, linuxppc-dev,
David S. Miller
In-Reply-To: <20200522004618.GA3151350@ZenIV.linux.org.uk>
On 5/21/20 5:46 PM, Al Viro wrote:
> On Thu, May 21, 2020 at 11:46:12PM +0100, Al Viro wrote:
>> On Thu, May 21, 2020 at 03:20:46PM -0700, Guenter Roeck wrote:
>>> On 5/21/20 10:27 AM, Al Viro wrote:
>>>> On Tue, May 19, 2020 at 09:54:22AM -0700, Guenter Roeck wrote:
>>>>> On Mon, May 18, 2020 at 11:48:43AM -0700, ira.weiny@intel.com wrote:
>>>>>> From: Ira Weiny <ira.weiny@intel.com>
>>>>>>
>>>>>> The kunmap_atomic clean up failed to remove one set of pagefault/preempt
>>>>>> enables when vaddr is not in the fixmap.
>>>>>>
>>>>>> Fixes: bee2128a09e6 ("arch/kunmap_atomic: consolidate duplicate code")
>>>>>> Signed-off-by: Ira Weiny <ira.weiny@intel.com>
>>>>>
>>>>> microblazeel works with this patch, as do the nosmp sparc32 boot tests,
>>>>> but sparc32 boot tests with SMP enabled still fail with lots of messages
>>>>> such as:
>>>>
>>>> BTW, what's your setup for sparc32 boot tests? IOW, how do you manage to
>>>> shrink the damn thing enough to have the loader cope with it? I hadn't
>>>> been able to do that for the current mainline ;-/
>>>>
>>>
>>> defconfig seems to work just fine, even after enabling various debug
>>> and file system options.
>>
>> The hell? How do you manage to get the kernel in? sparc32_defconfig
>> ends up with 5316876 bytes unpacked...
>
> Incidentally, trying to load it via -kernel/-initrd leads to
> Configuration device id QEMU version 1 machine id 64
> Probing SBus slot 0 offset 0
> Probing SBus slot 1 offset 0
> Probing SBus slot 2 offset 0
> Probing SBus slot 3 offset 0
> Probing SBus slot 15 offset 0
> Invalid FCode start byte
> CPUs: 1 x TI,TMS390Z55
> UUID: 00000000-0000-0000-0000-000000000000
> Welcome to OpenBIOS v1.1 built on Dec 27 2018 19:17
> Type 'help' for detailed information
> [sparc] Kernel already loaded
> switching to new context:
> PROMLIB: obio_ranges 1
> PROMLIB: Sun Boot Prom Version 3 Revision 2
> Linux version 5.7.0-rc1-00002-gcf51e129b968 (al@duke) (gcc version 6.3.0 20170516 (Debian 6.3.0-18), GNU ld (GNU Binutils for Debian) 2.28) #32 Thu May 21 18:36:07 EDT 2020
> printk: bootconsole [earlyprom0] enabled
> ARCH: SUN4M
> TYPE: Sun4m SparcStation10/20
> Ethernet address: 52:54:00:12:34:56
> 303MB HIGHMEM available.
> OF stdout device is: /obio/zs@0,100000:a
> PROM: Built device tree with 30051 bytes of memory.
> Booting Linux...
> Power off control detected.
> Kernel panic - not syncing: Failed to allocate memory for percpu areas.
> CPU: 0 PID: 0 Comm: swapper Not tainted 5.7.0-rc1-00002-gcf51e129b968 #32
> [f04f92a8 :
> setup_per_cpu_areas+0x58/0x90 ]
> [f04edbf4 :
> start_kernel+0xc0/0x4a0 ]
> [f04ed43c :
> continue_boot+0x324/0x334 ]
> [00000000 :
> 0x0 ]
>
> Press Stop-A (L1-A) from sun keyboard or send break
> twice on console to return to the boot prom
> ---[ end Kernel panic - not syncing: Failed to allocate memory for percpu areas. ]---
>
> Giving guest more RAM doesn't change the outcome (well, the number HIGHMEM line is
> obviously higher, but that's it).
>
> So which sparc32 kernel have you booted with defconfig and how have you done
> that?
>
Mainline, with:
qemu-system-sparc -M SS-4 -kernel arch/sparc/boot/zImage -no-reboot \
-snapshot -drive file=rootfs.ext2,format=raw,if=scsi \
-append "panic=-1 slub_debug=FZPUA root=/dev/sda console=ttyS0"
-nographic -monitor none
The machine doesn't really matter, though. The root file system is built
with buildroot.
Note that I carry two reverts in my qemu images.
Revert "tcx: switch to load_image_mr() and remove prom_addr hack"
Revert "cg3: switch to load_image_mr() and remove prom-addr hack"
I have been carrying those since ~2017. I didn't check recently
if they are still needed.
If sparc32 is no longer supported in the upstream kernel,
would it possibly make sense remove its support ?
Guenter
^ permalink raw reply
* Re: [PATCH] arch/{mips,sparc,microblaze,powerpc}: Don't enable pagefault/preempt twice
From: Al Viro @ 2020-05-22 0:46 UTC (permalink / raw)
To: Guenter Roeck
Cc: Peter Zijlstra, Dave Hansen, dri-devel, linux-mips,
James E.J. Bottomley, Max Filippov, Paul Mackerras,
H. Peter Anvin, sparclinux, ira.weiny, Dan Williams, Helge Deller,
x86, linux-csky, Christoph Hellwig, Ingo Molnar, linux-snps-arc,
linux-xtensa, Borislav Petkov, Andy Lutomirski, Thomas Gleixner,
linux-arm-kernel, Chris Zankel, Thomas Bogendoerfer, linux-parisc,
linux-kernel, Christian Koenig, Andrew Morton, linuxppc-dev,
David S. Miller
In-Reply-To: <20200521224612.GJ23230@ZenIV.linux.org.uk>
On Thu, May 21, 2020 at 11:46:12PM +0100, Al Viro wrote:
> On Thu, May 21, 2020 at 03:20:46PM -0700, Guenter Roeck wrote:
> > On 5/21/20 10:27 AM, Al Viro wrote:
> > > On Tue, May 19, 2020 at 09:54:22AM -0700, Guenter Roeck wrote:
> > >> On Mon, May 18, 2020 at 11:48:43AM -0700, ira.weiny@intel.com wrote:
> > >>> From: Ira Weiny <ira.weiny@intel.com>
> > >>>
> > >>> The kunmap_atomic clean up failed to remove one set of pagefault/preempt
> > >>> enables when vaddr is not in the fixmap.
> > >>>
> > >>> Fixes: bee2128a09e6 ("arch/kunmap_atomic: consolidate duplicate code")
> > >>> Signed-off-by: Ira Weiny <ira.weiny@intel.com>
> > >>
> > >> microblazeel works with this patch, as do the nosmp sparc32 boot tests,
> > >> but sparc32 boot tests with SMP enabled still fail with lots of messages
> > >> such as:
> > >
> > > BTW, what's your setup for sparc32 boot tests? IOW, how do you manage to
> > > shrink the damn thing enough to have the loader cope with it? I hadn't
> > > been able to do that for the current mainline ;-/
> > >
> >
> > defconfig seems to work just fine, even after enabling various debug
> > and file system options.
>
> The hell? How do you manage to get the kernel in? sparc32_defconfig
> ends up with 5316876 bytes unpacked...
Incidentally, trying to load it via -kernel/-initrd leads to
Configuration device id QEMU version 1 machine id 64
Probing SBus slot 0 offset 0
Probing SBus slot 1 offset 0
Probing SBus slot 2 offset 0
Probing SBus slot 3 offset 0
Probing SBus slot 15 offset 0
Invalid FCode start byte
CPUs: 1 x TI,TMS390Z55
UUID: 00000000-0000-0000-0000-000000000000
Welcome to OpenBIOS v1.1 built on Dec 27 2018 19:17
Type 'help' for detailed information
[sparc] Kernel already loaded
switching to new context:
PROMLIB: obio_ranges 1
PROMLIB: Sun Boot Prom Version 3 Revision 2
Linux version 5.7.0-rc1-00002-gcf51e129b968 (al@duke) (gcc version 6.3.0 20170516 (Debian 6.3.0-18), GNU ld (GNU Binutils for Debian) 2.28) #32 Thu May 21 18:36:07 EDT 2020
printk: bootconsole [earlyprom0] enabled
ARCH: SUN4M
TYPE: Sun4m SparcStation10/20
Ethernet address: 52:54:00:12:34:56
303MB HIGHMEM available.
OF stdout device is: /obio/zs@0,100000:a
PROM: Built device tree with 30051 bytes of memory.
Booting Linux...
Power off control detected.
Kernel panic - not syncing: Failed to allocate memory for percpu areas.
CPU: 0 PID: 0 Comm: swapper Not tainted 5.7.0-rc1-00002-gcf51e129b968 #32
[f04f92a8 :
setup_per_cpu_areas+0x58/0x90 ]
[f04edbf4 :
start_kernel+0xc0/0x4a0 ]
[f04ed43c :
continue_boot+0x324/0x334 ]
[00000000 :
0x0 ]
Press Stop-A (L1-A) from sun keyboard or send break
twice on console to return to the boot prom
---[ end Kernel panic - not syncing: Failed to allocate memory for percpu areas. ]---
Giving guest more RAM doesn't change the outcome (well, the number HIGHMEM line is
obviously higher, but that's it).
So which sparc32 kernel have you booted with defconfig and how have you done
that?
^ permalink raw reply
* Re: [PATCH v2 0/7] padata: parallelize deferred page init
From: Josh Triplett @ 2020-05-21 23:43 UTC (permalink / raw)
To: Daniel Jordan
Cc: David Hildenbrand, Peter Zijlstra, Dave Hansen, Michal Hocko,
linux-mm, Steven Sistare, Pavel Machek, Alexander Duyck,
Steffen Klassert, linux-s390, Herbert Xu, Jonathan Corbet,
Jason Gunthorpe, Zi Yan, Robert Elliott, Pavel Tatashin,
Shile Zhang, Alex Williamson, Kirill Tkhai, Dan Williams,
Randy Dunlap, linux-kernel, linux-crypto, Tejun Heo,
Andrew Morton, linuxppc-dev
In-Reply-To: <20200520182645.1658949-1-daniel.m.jordan@oracle.com>
On Wed, May 20, 2020 at 02:26:38PM -0400, Daniel Jordan wrote:
> Please review and test, and thanks to Alex, Andrew, Josh, and Pavel for
> their feedback in the last version.
I re-tested v2:
Tested-by: Josh Triplett <josh@joshtriplett.org>
[ 0.231435] node 1 initialised, 24189223 pages in 32ms
[ 0.236718] node 0 initialised, 23398907 pages in 36ms
^ permalink raw reply
* Re: [RESEND PATCH v7 3/5] powerpc/papr_scm: Fetch nvdimm health information from PHYP
From: Ira Weiny @ 2020-05-21 23:32 UTC (permalink / raw)
To: Vaibhav Jain
Cc: Aneesh Kumar K . V, linuxppc-dev, linux-kernel, Steven Rostedt,
linux-nvdimm
In-Reply-To: <87tv0awmr5.fsf@linux.ibm.com>
On Wed, May 20, 2020 at 10:45:58PM +0530, Vaibhav Jain wrote:
...
> > On Wed, May 20, 2020 at 12:30:56AM +0530, Vaibhav Jain wrote:
...
> >> @@ -39,6 +78,15 @@ struct papr_scm_priv {
> >> struct resource res;
> >> struct nd_region *region;
> >> struct nd_interleave_set nd_set;
> >> +
> >> + /* Protect dimm health data from concurrent read/writes */
> >> + struct mutex health_mutex;
> >> +
> >> + /* Last time the health information of the dimm was updated */
> >> + unsigned long lasthealth_jiffies;
> >> +
> >> + /* Health information for the dimm */
> >> + u64 health_bitmap;
> >
> > I wonder if this should be typed big endian as you mention that it is in the
> > commit message?
> This was discussed in an earlier review of the patch series at
> https://lore.kernel.org/linux-nvdimm/878sjetcis.fsf@mpe.ellerman.id.au
>
> Even though health bitmap is returned in big endian format (For ex
> value 0xC00000000000000 indicates bits 0,1 set), its value is never
> used. Instead only test for specific bits being set in the register is
> done.
>
> Hence using native cpu type instead of __be64 to store this value.
ok.
>
> >
> >> };
> >>
> >> static int drc_pmem_bind(struct papr_scm_priv *p)
> >> @@ -144,6 +192,62 @@ static int drc_pmem_query_n_bind(struct papr_scm_priv *p)
> >> return drc_pmem_bind(p);
> >> }
> >>
> >> +/*
> >> + * Issue hcall to retrieve dimm health info and populate papr_scm_priv with the
> >> + * health information.
> >> + */
> >> +static int __drc_pmem_query_health(struct papr_scm_priv *p)
> >> +{
> >> + unsigned long ret[PLPAR_HCALL_BUFSIZE];
> >
> > Is this exclusive to 64bit? Why not u64?
> Yes this is specific to 64 bit as the array holds 64 bit register values
> returned from PHYP. Can u64 but here that will be a departure from existing
> practice within arch/powerpc code to use an unsigned long array to fetch
> returned values for PHYP.
>
> >
> >> + s64 rc;
> >
> > plpar_hcall() returns long and this function returns int and rc is declared
> > s64?
> >
> > Why not have them all be long to follow plpar_hcall?
> Yes 'long' type is better suited for variable 'rc' and I will get it fixed.
>
> But the value of variable 'rc' is never directly returned from this
> function, we always return kernel error codes instead. Hence the
> return type of this function is consistent.
Honestly masking the error return of plpar_hcall() seems a problem as well...
but ok.
Ira
>
> >
> >> +
> >> + /* issue the hcall */
> >> + rc = plpar_hcall(H_SCM_HEALTH, ret, p->drc_index);
> >> + if (rc != H_SUCCESS) {
> >> + dev_err(&p->pdev->dev,
> >> + "Failed to query health information, Err:%lld\n", rc);
> >> + rc = -ENXIO;
> >> + goto out;
> >> + }
> >> +
> >> + p->lasthealth_jiffies = jiffies;
> >> + p->health_bitmap = ret[0] & ret[1];
> >> +
> >> + dev_dbg(&p->pdev->dev,
> >> + "Queried dimm health info. Bitmap:0x%016lx Mask:0x%016lx\n",
> >> + ret[0], ret[1]);
> >> +out:
> >> + return rc;
> >> +}
> >> +
> >> +/* Min interval in seconds for assuming stable dimm health */
> >> +#define MIN_HEALTH_QUERY_INTERVAL 60
> >> +
> >> +/* Query cached health info and if needed call drc_pmem_query_health */
> >> +static int drc_pmem_query_health(struct papr_scm_priv *p)
> >> +{
> >> + unsigned long cache_timeout;
> >> + s64 rc;
> >> +
> >> + /* Protect concurrent modifications to papr_scm_priv */
> >> + rc = mutex_lock_interruptible(&p->health_mutex);
> >> + if (rc)
> >> + return rc;
> >> +
> >> + /* Jiffies offset for which the health data is assumed to be same */
> >> + cache_timeout = p->lasthealth_jiffies +
> >> + msecs_to_jiffies(MIN_HEALTH_QUERY_INTERVAL * 1000);
> >> +
> >> + /* Fetch new health info is its older than MIN_HEALTH_QUERY_INTERVAL */
> >> + if (time_after(jiffies, cache_timeout))
> >> + rc = __drc_pmem_query_health(p);
> >
> > And back to s64 after returning int?
> Agree, will change 's64 rc' to 'int rc'.
>
> >
> >> + else
> >> + /* Assume cached health data is valid */
> >> + rc = 0;
> >> +
> >> + mutex_unlock(&p->health_mutex);
> >> + return rc;
> >> +}
> >>
> >> static int papr_scm_meta_get(struct papr_scm_priv *p,
> >> struct nd_cmd_get_config_data_hdr *hdr)
> >> @@ -286,6 +390,64 @@ static int papr_scm_ndctl(struct nvdimm_bus_descriptor *nd_desc,
> >> return 0;
> >> }
> >>
> >> +static ssize_t flags_show(struct device *dev,
> >> + struct device_attribute *attr, char *buf)
> >> +{
> >> + struct nvdimm *dimm = to_nvdimm(dev);
> >> + struct papr_scm_priv *p = nvdimm_provider_data(dimm);
> >> + struct seq_buf s;
> >> + u64 health;
> >> + int rc;
> >> +
> >> + rc = drc_pmem_query_health(p);
> >
> > and back to int...
> >
> drc_pmem_query_health() returns an 'int' so the type of variable 'rc'
> looks correct to me.
>
> > Just make them long all through...
> I think the return type for above all functions is 'int' with
> an issue in drc_pmem_query_health() that you pointed out.
>
> With that fixed the usage of 'int' return type for functions will become
> consistent.
>
> >
> > Ira
> >
> >> + if (rc)
> >> + return rc;
> >> +
> >> + /* Copy health_bitmap locally, check masks & update out buffer */
> >> + health = READ_ONCE(p->health_bitmap);
> >> +
> >> + seq_buf_init(&s, buf, PAGE_SIZE);
> >> + if (health & PAPR_SCM_DIMM_UNARMED_MASK)
> >> + seq_buf_printf(&s, "not_armed ");
> >> +
> >> + if (health & PAPR_SCM_DIMM_BAD_SHUTDOWN_MASK)
> >> + seq_buf_printf(&s, "flush_fail ");
> >> +
> >> + if (health & PAPR_SCM_DIMM_BAD_RESTORE_MASK)
> >> + seq_buf_printf(&s, "restore_fail ");
> >> +
> >> + if (health & PAPR_SCM_DIMM_ENCRYPTED)
> >> + seq_buf_printf(&s, "encrypted ");
> >> +
> >> + if (health & PAPR_SCM_DIMM_SMART_EVENT_MASK)
> >> + seq_buf_printf(&s, "smart_notify ");
> >> +
> >> + if (health & PAPR_SCM_DIMM_SCRUBBED_AND_LOCKED)
> >> + seq_buf_printf(&s, "scrubbed locked ");
> >> +
> >> + if (seq_buf_used(&s))
> >> + seq_buf_printf(&s, "\n");
> >> +
> >> + return seq_buf_used(&s);
> >> +}
> >> +DEVICE_ATTR_RO(flags);
> >> +
> >> +/* papr_scm specific dimm attributes */
> >> +static struct attribute *papr_scm_nd_attributes[] = {
> >> + &dev_attr_flags.attr,
> >> + NULL,
> >> +};
> >> +
> >> +static struct attribute_group papr_scm_nd_attribute_group = {
> >> + .name = "papr",
> >> + .attrs = papr_scm_nd_attributes,
> >> +};
> >> +
> >> +static const struct attribute_group *papr_scm_dimm_attr_groups[] = {
> >> + &papr_scm_nd_attribute_group,
> >> + NULL,
> >> +};
> >> +
> >> static int papr_scm_nvdimm_init(struct papr_scm_priv *p)
> >> {
> >> struct device *dev = &p->pdev->dev;
> >> @@ -312,8 +474,8 @@ static int papr_scm_nvdimm_init(struct papr_scm_priv *p)
> >> dimm_flags = 0;
> >> set_bit(NDD_LABELING, &dimm_flags);
> >>
> >> - p->nvdimm = nvdimm_create(p->bus, p, NULL, dimm_flags,
> >> - PAPR_SCM_DIMM_CMD_MASK, 0, NULL);
> >> + p->nvdimm = nvdimm_create(p->bus, p, papr_scm_dimm_attr_groups,
> >> + dimm_flags, PAPR_SCM_DIMM_CMD_MASK, 0, NULL);
> >> if (!p->nvdimm) {
> >> dev_err(dev, "Error creating DIMM object for %pOF\n", p->dn);
> >> goto err;
> >> @@ -399,6 +561,9 @@ static int papr_scm_probe(struct platform_device *pdev)
> >> if (!p)
> >> return -ENOMEM;
> >>
> >> + /* Initialize the dimm mutex */
> >> + mutex_init(&p->health_mutex);
> >> +
> >> /* optional DT properties */
> >> of_property_read_u32(dn, "ibm,metadata-size", &metadata_size);
> >>
> >> --
> >> 2.26.2
> >> _______________________________________________
> >> Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
> >> To unsubscribe send an email to linux-nvdimm-leave@lists.01.org
>
> --
> Cheers
> ~ Vaibhav
^ permalink raw reply
* Re: Fwd: [CRON] Broken: ClangBuiltLinux/continuous-integration#1432 (master - 0aceafc)
From: Nathan Chancellor @ 2020-05-21 22:59 UTC (permalink / raw)
To: Nick Desaulniers; +Cc: linuxppc-dev, clang-built-linux
In-Reply-To: <CAKwvOdn_rNgPERgUfBgGywbyRBdSoEbQCaBO1o7fgqkMcCYXqQ@mail.gmail.com>
On Thu, May 21, 2020 at 03:23:11PM -0700, Nick Desaulniers wrote:
> On Thu, May 21, 2020 at 6:00 AM Michael Ellerman <mpe@ellerman.id.au> wrote:
> >
> > Nathan Chancellor <natechancellor@gmail.com> writes:
> > > On Tue, May 19, 2020 at 05:56:32PM -0700, 'Nick Desaulniers' via Clang Built Linux wrote:
> > >> Looks like our CI is still red from this:
> > >>
> > >> https://travis-ci.com/github/ClangBuiltLinux/continuous-integration/builds/166854584
> > >>
> > >> Filing a bug to follow up on:
> > >> https://github.com/ClangBuiltLinux/linux/issues/1031
> > >>
> > >> On Thu, May 7, 2020 at 8:29 PM Michael Ellerman <mpe@ellerman.id.au> wrote:
> > >> >
> > >> > Nick Desaulniers <ndesaulniers@google.com> writes:
> > >> > > Looks like ppc64le powernv_defconfig is suddenly failing the locking
> > >> > > torture tests, then locks up?
> > >> > > https://travis-ci.com/github/ClangBuiltLinux/continuous-integration/jobs/329211572#L3111-L3167
> > >> > > Any recent changes related here in -next? I believe this is the first
> > >> > > failure, so I'll report back if we see this again.
> > >> >
> > >> > Thanks for the report.
> > >> >
> > >> > There's nothing newly in next-20200507 that seems related.
> > ...
> > >
> > > This is probably still a manifestation of
> > > https://github.com/ClangBuiltLinux/continuous-integration/issues/262
> > > because rekicking the tests usually fixes it.
>
> I thought we had upgraded our version of QEMU in response to this already?
> https://github.com/ClangBuiltLinux/dockerimage/pull/44
> https://github.com/ClangBuiltLinux/dockerimage/pull/46
That was more of a bandaid than an actual fix. It happens a lot less
often with QEMU 4.2.0 but I could still reproduce that hang very
sparingly with the POWER9 machines on it. My machines are way more
powerful than the ones on Travis, which I am sure factors into that.
the hang with the POWER9 machines very sparingly with QEMU 4.2.0 but
The real solution is to upgrade to QEMU 5.0.0, which we could probably
do via a PPA (or through our Docker image), or wait for QEMU 4.2.1,
which should hopefully have that fix since it was CC'd for QEMU stable.
> >
> > Oh yep.
> >
> > I was looking at the RCU warning, which I still don't understand, but
> > the lockup is presumably the same problem you hit with interrupts being
> > lost.
> >
> > > We should probably just disable the torture tests like we do for x86_64
> > > for CI because we do not have access to QEMU 5.0.0 where this should be
> > > fixed. I believe it is slated for 4.2.1 as well but we still have to
> > > wait for that to be updated and packaged in Ubuntu.
> >
> > You just need to start building Qemu HEAD as part of your CI ;)
>
> LOL
> https://github.com/ClangBuiltLinux/dockerimage/pull/46#pullrequestreview-395639442
> Yeah I think the hard part for all these dependendencies is the risk
> of living on the edge of "top of tree" for all of them, and trying to
> control for some by using stable releases. May not always be
> possible.
Unfortunately, we are at the mercy of a bunch of different parties. If
only we had a ClangBuiltLinux build server that we maintained...
Cheers,
Nathan
^ 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