* Re: [PATCH] powerpc/ps3: Set driver coherent_dma_mask
From: Alan Stern @ 2018-07-19 14:33 UTC (permalink / raw)
To: Geoff Levand
Cc: Takashi Iwai, Jaroslav Kysela, Michael Ellerman, linux-usb,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <068ebcfa-7cd0-bd06-42e7-577a4624f0b0@infradead.org>
On Wed, 18 Jul 2018, Geoff Levand wrote:
> Set the coherent_dma_mask for the PS3 ehci, ohci, and snd devices.
>
> Silences WARN_ON_ONCE messages emitted by the dma_alloc_attrs() routine.
>
> Reported-by: Fredrik Noring <noring@nocrew.org>
> Signed-off-by: Geoff Levand <geoff@infradead.org>
> ---
> Hi Michael,
>
> This just silences some warnings. Can you take it through the powerpc
> tree?
>
> -Geoff
>
>
> drivers/usb/host/ehci-ps3.c | 6 ++++--
> drivers/usb/host/ohci-ps3.c | 6 ++++--
> sound/ppc/snd_ps3.c | 5 +++++
> 3 files changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/usb/host/ehci-ps3.c b/drivers/usb/host/ehci-ps3.c
> index 8c733492d8fe..454d8c624a3f 100644
> --- a/drivers/usb/host/ehci-ps3.c
> +++ b/drivers/usb/host/ehci-ps3.c
> @@ -86,7 +86,7 @@ static int ps3_ehci_probe(struct ps3_system_bus_device *dev)
> int result;
> struct usb_hcd *hcd;
> unsigned int virq;
> - static u64 dummy_mask = DMA_BIT_MASK(32);
> + static u64 dummy_mask;
>
> if (usb_disabled()) {
> result = -ENODEV;
> @@ -131,7 +131,9 @@ static int ps3_ehci_probe(struct ps3_system_bus_device *dev)
> goto fail_irq;
> }
>
> - dev->core.dma_mask = &dummy_mask; /* FIXME: for improper usb code */
> + dummy_mask = DMA_BIT_MASK(32);
> + dev->core.dma_mask = &dummy_mask;
> + dma_set_coherent_mask(&dev->core, dummy_mask);
What is the reason for changing a static initialization to a dynamic
one? As far as I can see, the patch touches four lines of code but the
only real difference is addition of a single line (and removal of a
comment).
> diff --git a/drivers/usb/host/ohci-ps3.c b/drivers/usb/host/ohci-ps3.c
> index 20a23d795adf..395f9d3bc849 100644
> --- a/drivers/usb/host/ohci-ps3.c
> +++ b/drivers/usb/host/ohci-ps3.c
> @@ -69,7 +69,7 @@ static int ps3_ohci_probe(struct ps3_system_bus_device *dev)
> int result;
> struct usb_hcd *hcd;
> unsigned int virq;
> - static u64 dummy_mask = DMA_BIT_MASK(32);
> + static u64 dummy_mask;
>
> if (usb_disabled()) {
> result = -ENODEV;
> @@ -115,7 +115,9 @@ static int ps3_ohci_probe(struct ps3_system_bus_device *dev)
> goto fail_irq;
> }
>
> - dev->core.dma_mask = &dummy_mask; /* FIXME: for improper usb code */
> + dummy_mask = DMA_BIT_MASK(32);
> + dev->core.dma_mask = &dummy_mask;
> + dma_set_coherent_mask(&dev->core, dummy_mask);
Same here.
Alan Stern
^ permalink raw reply
* [PATCH] powerpc/mm: Don't report PUDs as memory leaks when using kmemleak
From: Michael Ellerman @ 2018-07-19 14:33 UTC (permalink / raw)
To: linuxppc-dev; +Cc: aneesh.kumar, pmenzel
Paul Menzel reported that kmemleak was producing reports such as:
unreferenced object 0xc0000000f8b80000 (size 16384):
comm "init", pid 1, jiffies 4294937416 (age 312.240s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<00000000d997deb7>] __pud_alloc+0x80/0x190
[<0000000087f2e8a3>] move_page_tables+0xbac/0xdc0
[<00000000091e51c2>] shift_arg_pages+0xc0/0x210
[<00000000ab88670c>] setup_arg_pages+0x22c/0x2a0
[<0000000060871529>] load_elf_binary+0x41c/0x1648
[<00000000ecd9d2d4>] search_binary_handler.part.11+0xbc/0x280
[<0000000034e0cdd7>] __do_execve_file.isra.13+0x73c/0x940
[<000000005f953a6e>] sys_execve+0x58/0x70
[<000000009700a858>] system_call+0x5c/0x70
Indicating that a PUD was being leaked.
However what's really happening is that kmemleak is not able to
recognise the references from the PGD to the PUD, because they are not
fully qualified pointers.
We can confirm that in xmon, eg:
Find the task struct for pid 1 "init":
0:mon> P
task_struct ->thread.ksp PID PPID S P CMD
c0000001fe7c0000 c0000001fe803960 1 0 S 13 systemd
Dump virtual address 0 to find the PGD:
0:mon> dv 0 c0000001fe7c0000
pgd @ 0xc0000000f8b01000
Dump the memory of the PGD:
0:mon> d c0000000f8b01000
c0000000f8b01000 00000000f8b90000 0000000000000000 |................|
c0000000f8b01010 0000000000000000 0000000000000000 |................|
c0000000f8b01020 0000000000000000 0000000000000000 |................|
c0000000f8b01030 0000000000000000 00000000f8b80000 |................|
^^^^^^^^^^^^^^^^
There we can see the reference to our supposedly leaked PUD. But
because it's missing the leading 0xc, kmemleak won't recognise it.
We can confirm it's still in use by translating an address that is
mapped via it:
0:mon> dv 7fff94000000 c0000001fe7c0000
pgd @ 0xc0000000f8b01000
pgdp @ 0xc0000000f8b01038 = 0x00000000f8b80000 <--
pudp @ 0xc0000000f8b81ff8 = 0x00000000037c4000
pmdp @ 0xc0000000037c5ca0 = 0x00000000fbd89000
ptep @ 0xc0000000fbd89000 = 0xc0800001d5ce0386
Maps physical address = 0x00000001d5ce0000
Flags = Accessed Dirty Read Write
The fix is fairly simple. We need to tell kmemleak to ignore PUD
allocations and never report them as leaks. We can also tell it not to
scan the PGD, because it will never find pointers in there. However it
will still notice if we allocate a PGD and then leak it.
Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/include/asm/book3s/64/pgalloc.h | 23 +++++++++++++++++++++--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/book3s/64/pgalloc.h b/arch/powerpc/include/asm/book3s/64/pgalloc.h
index 01ee40f11f3a..76234a14b97d 100644
--- a/arch/powerpc/include/asm/book3s/64/pgalloc.h
+++ b/arch/powerpc/include/asm/book3s/64/pgalloc.h
@@ -9,6 +9,7 @@
#include <linux/slab.h>
#include <linux/cpumask.h>
+#include <linux/kmemleak.h>
#include <linux/percpu.h>
struct vmemmap_backing {
@@ -82,6 +83,13 @@ static inline pgd_t *pgd_alloc(struct mm_struct *mm)
pgd = kmem_cache_alloc(PGT_CACHE(PGD_INDEX_SIZE),
pgtable_gfp_flags(mm, GFP_KERNEL));
+ /*
+ * Don't scan the PGD for pointers, it contains references to PUDs but
+ * those references are not full pointers and so can't be recognised by
+ * kmemleak.
+ */
+ kmemleak_no_scan(pgd);
+
/*
* With hugetlb, we don't clear the second half of the page table.
* If we share the same slab cache with the pmd or pud level table,
@@ -110,8 +118,19 @@ static inline void pgd_populate(struct mm_struct *mm, pgd_t *pgd, pud_t *pud)
static inline pud_t *pud_alloc_one(struct mm_struct *mm, unsigned long addr)
{
- return kmem_cache_alloc(PGT_CACHE(PUD_CACHE_INDEX),
- pgtable_gfp_flags(mm, GFP_KERNEL));
+ pud_t *pud;
+
+ pud = kmem_cache_alloc(PGT_CACHE(PUD_CACHE_INDEX),
+ pgtable_gfp_flags(mm, GFP_KERNEL));
+ /*
+ * Tell kmemleak to ignore the PUD, that means don't scan it for
+ * pointers and don't consider it a leak. PUDs are typically only
+ * referred to by their PGD, but kmemleak is not able to recognise those
+ * as pointers, leading to false leak reports.
+ */
+ kmemleak_ignore(pud);
+
+ return pud;
}
static inline void pud_free(struct mm_struct *mm, pud_t *pud)
--
2.14.1
^ permalink raw reply related
* Re: [PATCH v3] PCI: Data corruption happening due to race condition
From: Hari Vyas @ 2018-07-19 14:04 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Bjorn Helgaas, Bjorn Helgaas, linux-pci, Ray Jui, Paul Mackerras,
Michael Ellerman, linuxppc-dev
In-Reply-To: <65dd986d0b8b2ebe5132b365dabb2dbaaed9177f.camel@kernel.crashing.org>
Hi Bjonr, Ben
On Thu, Jul 19, 2018 at 9:48 AM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Wed, 2018-07-18 at 18:29 -0500, Bjorn Helgaas wrote:
>> [+cc Paul, Michael, linuxppc-dev]
>>
>
> ..../...
>
>> > Debugging revealed a race condition between pcie core driver
>> > enabling is_added bit(pci_bus_add_device()) and nvme driver
>> > reset work-queue enabling is_busmaster bit (by pci_set_master()).
>> > As both fields are not handled in atomic manner and that clears
>> > is_added bit.
>> >
>> > Fix moves device addition is_added bit to separate private flag
>> > variable and use different atomic functions to set and retrieve
>> > device addition state. As is_added shares different memory
>> > location so race condition is avoided.
>>
>> Really nice bit of debugging!
>
> Indeed. However I'm not fan of the solution. Shouldn't we instead have
> some locking for the content of pci_dev ? I've always been wary of us
> having other similar races in there.
>
> As for the powerpc bits, I'm probably the one who wrote them, however,
> I'm on vacation this week and right now, no bandwidth to context switch
> all that back in :-) So give me a few days and/or ping me next week.
>
> The powerpc PCI code contains a lot of cruft coming from the depth of
> history, including rather nasty assumptions. We want to progressively
> clean it up, starting with EEH, but it will take time.
>
> Cheers,
> Ben.
>
Some driver too directly using pci_dev structure flags and may cause similar
type of issues in race condition and should be avoided.
Probably not causing issue currently but some race scenario may affect
and needs to be handled
with some get(),set() api's in atomic manner.
I will suggest to use bit position for all remaining bitfields and use
atomic operation. In that way,
it can be controlled and avoid direct updating fields from outside.
Ex;
enum pci_dev_flags {
IS_BUSMASTER=1,
. NO_MSI=2.
}
void assign_pci_dev_flag(struct pci_dev *dev, int flag, bool val)
{
assign_bit(flag, &dev->flags, val);
}
Proper cleanup is required at so many places but that will certainly
take some time
i.e. good effort but will be future safe.If Bjorn agrees, we can
work on that one.
>> > Signed-off-by: Hari Vyas <hari.vyas@broadcom.com>
>> > ---
>> > arch/powerpc/kernel/pci-common.c | 4 +++-
>> > arch/powerpc/platforms/powernv/pci-ioda.c | 3 ++-
>> > arch/powerpc/platforms/pseries/setup.c | 3 ++-
>> > drivers/pci/bus.c | 6 +++---
>> > drivers/pci/hotplug/acpiphp_glue.c | 2 +-
>> > drivers/pci/pci.h | 11 +++++++++++
>> > drivers/pci/probe.c | 4 ++--
>> > drivers/pci/remove.c | 5 +++--
>> > include/linux/pci.h | 1 -
>> > 9 files changed, 27 insertions(+), 12 deletions(-)
>> >
>> > diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
>> > index fe9733f..471aac3 100644
>> > --- a/arch/powerpc/kernel/pci-common.c
>> > +++ b/arch/powerpc/kernel/pci-common.c
>> > @@ -42,6 +42,8 @@
>> > #include <asm/ppc-pci.h>
>> > #include <asm/eeh.h>
>> >
>> > +#include "../../../drivers/pci/pci.h"
>>
>> I see why you need it, but this include path is really ugly. Outside
>> of bootloaders and tools, there are very few instances of includes
>> like this that reference a different top-level directory, and I'm not
>> very keen about adding more.
>>
>> Obviously powerpc is the only arch that needs dev->is_added. It seems
>> to be because "We can only call pcibios_setup_device() after bus setup
>> is complete, since some of the platform specific DMA setup code
>> depends on it."
>>
>> I don't know powerpc, but it does raise the question in my mind of
>> whether powerpc could be changed to do the DMA setup more like other
>> arches do to remove this ordering dependency and the need to use
>> dev->is_added.
>>
>> That sounds like a lot of work, but it would have the benefit of
>> unifying some code that is probably needlessly arch-specific.
>>
Yes. I also agree, including pci.h with ../ references is really bad.
First patch
was using spin lock for protecting is_added and is_busmaster bits but in final
patch moved is_added to private flags.
>> > /* hose_spinlock protects accesses to the the phb_bitmap. */
>> > static DEFINE_SPINLOCK(hose_spinlock);
>> > LIST_HEAD(hose_list);
>> > @@ -1014,7 +1016,7 @@ void pcibios_setup_bus_devices(struct pci_bus *bus)
>> > /* Cardbus can call us to add new devices to a bus, so ignore
>> > * those who are already fully discovered
>> > */
>> > - if (dev->is_added)
>> > + if (pci_dev_is_added(dev))
>> > continue;
>> >
>> > pcibios_setup_device(dev);
>> > diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
>> > index 5bd0eb6..70b2e1e 100644
>> > --- a/arch/powerpc/platforms/powernv/pci-ioda.c
>> > +++ b/arch/powerpc/platforms/powernv/pci-ioda.c
>> > @@ -46,6 +46,7 @@
>> >
>> > #include "powernv.h"
>> > #include "pci.h"
>> > +#include "../../../../drivers/pci/pci.h"
>> >
>> > #define PNV_IODA1_M64_NUM 16 /* Number of M64 BARs */
>> > #define PNV_IODA1_M64_SEGS 8 /* Segments per M64 BAR */
>> > @@ -3138,7 +3139,7 @@ static void pnv_pci_ioda_fixup_iov_resources(struct pci_dev *pdev)
>> > struct pci_dn *pdn;
>> > int mul, total_vfs;
>> >
>> > - if (!pdev->is_physfn || pdev->is_added)
>> > + if (!pdev->is_physfn || pci_dev_is_added(pdev))
>> > return;
>> >
>> > pdn = pci_get_pdn(pdev);
>> > diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
>> > index 139f0af..8a4868a 100644
>> > --- a/arch/powerpc/platforms/pseries/setup.c
>> > +++ b/arch/powerpc/platforms/pseries/setup.c
>> > @@ -71,6 +71,7 @@
>> > #include <asm/security_features.h>
>> >
>> > #include "pseries.h"
>> > +#include "../../../../drivers/pci/pci.h"
>> >
>> > int CMO_PrPSP = -1;
>> > int CMO_SecPSP = -1;
>> > @@ -664,7 +665,7 @@ static void pseries_pci_fixup_iov_resources(struct pci_dev *pdev)
>> > const int *indexes;
>> > struct device_node *dn = pci_device_to_OF_node(pdev);
>> >
>> > - if (!pdev->is_physfn || pdev->is_added)
>> > + if (!pdev->is_physfn || pci_dev_is_added(pdev))
>> > return;
>> > /*Firmware must support open sriov otherwise dont configure*/
>> > indexes = of_get_property(dn, "ibm,open-sriov-vf-bar-info", NULL);
>> > diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c
>> > index 35b7fc8..5cb40b2 100644
>> > --- a/drivers/pci/bus.c
>> > +++ b/drivers/pci/bus.c
>> > @@ -330,7 +330,7 @@ void pci_bus_add_device(struct pci_dev *dev)
>> > return;
>> > }
>> >
>> > - dev->is_added = 1;
>> > + pci_dev_assign_added(dev, true);
>> > }
>> > EXPORT_SYMBOL_GPL(pci_bus_add_device);
>> >
>> > @@ -347,14 +347,14 @@ void pci_bus_add_devices(const struct pci_bus *bus)
>> >
>> > list_for_each_entry(dev, &bus->devices, bus_list) {
>> > /* Skip already-added devices */
>> > - if (dev->is_added)
>> > + if (pci_dev_is_added(dev))
>> > continue;
>> > pci_bus_add_device(dev);
>> > }
>> >
>> > list_for_each_entry(dev, &bus->devices, bus_list) {
>> > /* Skip if device attach failed */
>> > - if (!dev->is_added)
>> > + if (!pci_dev_is_added(dev))
>> > continue;
>> > child = dev->subordinate;
>> > if (child)
>> > diff --git a/drivers/pci/hotplug/acpiphp_glue.c b/drivers/pci/hotplug/acpiphp_glue.c
>> > index 3a17b29..ef0b1b6 100644
>> > --- a/drivers/pci/hotplug/acpiphp_glue.c
>> > +++ b/drivers/pci/hotplug/acpiphp_glue.c
>> > @@ -509,7 +509,7 @@ static void enable_slot(struct acpiphp_slot *slot)
>> >
>> > list_for_each_entry(dev, &bus->devices, bus_list) {
>> > /* Assume that newly added devices are powered on already. */
>> > - if (!dev->is_added)
>> > + if (!pci_dev_is_added(dev))
>> > dev->current_state = PCI_D0;
>> > }
>> >
>> > diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
>> > index 882f1f9..0881725 100644
>> > --- a/drivers/pci/pci.h
>> > +++ b/drivers/pci/pci.h
>> > @@ -288,6 +288,7 @@ struct pci_sriov {
>> >
>> > /* pci_dev priv_flags */
>> > #define PCI_DEV_DISCONNECTED 0
>> > +#define PCI_DEV_ADDED 1
>> >
>> > static inline int pci_dev_set_disconnected(struct pci_dev *dev, void *unused)
>> > {
>> > @@ -300,6 +301,16 @@ static inline bool pci_dev_is_disconnected(const struct pci_dev *dev)
>> > return test_bit(PCI_DEV_DISCONNECTED, &dev->priv_flags);
>> > }
>> >
>> > +static inline void pci_dev_assign_added(struct pci_dev *dev, bool added)
>> > +{
>> > + assign_bit(PCI_DEV_ADDED, &dev->priv_flags, added);
>> > +}
>> > +
>> > +static inline bool pci_dev_is_added(const struct pci_dev *dev)
>> > +{
>> > + return test_bit(PCI_DEV_ADDED, &dev->priv_flags);
>> > +}
>> > +
>> > #ifdef CONFIG_PCI_ATS
>> > void pci_restore_ats_state(struct pci_dev *dev);
>> > #else
>> > diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
>> > index ac876e3..611adcd 100644
>> > --- a/drivers/pci/probe.c
>> > +++ b/drivers/pci/probe.c
>> > @@ -2433,13 +2433,13 @@ int pci_scan_slot(struct pci_bus *bus, int devfn)
>> > dev = pci_scan_single_device(bus, devfn);
>> > if (!dev)
>> > return 0;
>> > - if (!dev->is_added)
>> > + if (!pci_dev_is_added(dev))
>> > nr++;
>> >
>> > for (fn = next_fn(bus, dev, 0); fn > 0; fn = next_fn(bus, dev, fn)) {
>> > dev = pci_scan_single_device(bus, devfn + fn);
>> > if (dev) {
>> > - if (!dev->is_added)
>> > + if (!pci_dev_is_added(dev))
>> > nr++;
>> > dev->multifunction = 1;
>> > }
>> > diff --git a/drivers/pci/remove.c b/drivers/pci/remove.c
>> > index 6f072ea..5e3d0dc 100644
>> > --- a/drivers/pci/remove.c
>> > +++ b/drivers/pci/remove.c
>> > @@ -19,11 +19,12 @@ static void pci_stop_dev(struct pci_dev *dev)
>> > {
>> > pci_pme_active(dev, false);
>> >
>> > - if (dev->is_added) {
>> > + if (pci_dev_is_added(dev)) {
>> > device_release_driver(&dev->dev);
>> > pci_proc_detach_device(dev);
>> > pci_remove_sysfs_dev_files(dev);
>> > - dev->is_added = 0;
>> > +
>> > + pci_dev_assign_added(dev, false);
>> > }
>> >
>> > if (dev->bus->self)
>> > diff --git a/include/linux/pci.h b/include/linux/pci.h
>> > index 340029b..506125b 100644
>> > --- a/include/linux/pci.h
>> > +++ b/include/linux/pci.h
>> > @@ -368,7 +368,6 @@ struct pci_dev {
>> > unsigned int transparent:1; /* Subtractive decode bridge */
>> > unsigned int multifunction:1; /* Multi-function device */
>> >
>> > - unsigned int is_added:1;
>> > unsigned int is_busmaster:1; /* Is busmaster */
>> > unsigned int no_msi:1; /* May not use MSI */
>> > unsigned int no_64bit_msi:1; /* May only use 32-bit MSIs */
>> > --
>> > 1.9.1
>> >
^ permalink raw reply
* Re: [powerpc/powervm]Oops: Kernel access of bad area, sig: 11 [#1] while running stress-ng
From: Brian Foster @ 2018-07-19 13:33 UTC (permalink / raw)
To: vrbagal1
Cc: Michael Ellerman, Nicholas Piggin, linux-fsdevel, sachinp,
linuxppc-dev, Linuxppc-dev, linux-xfs
In-Reply-To: <fd8a991ffa7420613d4fe8e69e78d611@linux.vnet.ibm.com>
cc linux-xfs
On Thu, Jul 19, 2018 at 11:47:59AM +0530, vrbagal1 wrote:
> On 2018-07-10 19:12, Michael Ellerman wrote:
> > vrbagal1 <vrbagal1@linux.vnet.ibm.com> writes:
> >
> > > On 2018-07-10 13:37, Nicholas Piggin wrote:
> > > > On Tue, 10 Jul 2018 11:58:40 +0530
> > > > vrbagal1 <vrbagal1@linux.vnet.ibm.com> wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > Observing kernel oops on Power9(ZZ) box, running on PowerVM, while
> > > > > running stress-ng.
> > > > >
> > > > >
> > > > > Kernel: 4.18.0-rc4
> > > > > Machine: Power9 ZZ (PowerVM)
> > > > > Test: Stress-ng
> > > > >
> > > > > Attached is .config file
> > > > >
> > > > > Traces:
> > > > >
> > > > > [12251.245209] Oops: Kernel access of bad area, sig: 11 [#1]
> > > >
> > > > Can you post the lines above this? Otherwise we don't know what
> > > > address
> > > > it tried to access (without decoding the instructions and
> > > > reconstructing
> > > > it from registers at least, which the XFS devs wouldn't be
> > > > inclined to
> > > > do).
> > > >
> > >
> > > ah my bad.
> > >
> > > [12251.245179] Unable to handle kernel paging request for data at
> > > address 0x6000000060000000
> > > [12251.245199] Faulting instruction address: 0xc000000000319e2c
> >
> > Which matches the regs & disassembly:
> >
> > r4 = 6000000060000000
> > r9 = 0
> > ldx r9,r4,r9 <- pop
> >
> > So object was 0x6000000060000000.
> >
> > That looks like two nops, ie. we got some code?
> >
> > And there's only one caller of prefetch_freepointer() in
> > slab_alloc_node():
> >
> > prefetch_freepointer(s, next_object);
> >
> >
> > So slab corruption is looking likely.
> >
> > Do you have slub_debug=FZP on the kernel command line?
>
> I tried to reproduce this, but didnt succeed. But instead I got xfs
> assertion.
>
> Kernel: 4.18.0-rc5
> Tree Head: 30b06abfb92bfd5f9b63ea6a2ffb0bd905d1a6da
>
> Traces:
>
> [12290.993612] XFS: Assertion failed: flags & XFS_BMAPI_COWFORK, file:
> fs/xfs/libxfs/xfs_bmap.c, line: 4370
This usually means we have a writeback of a page with delayed allocation
buffers over an extent map that reflects a hole in the file. This should
never happen for normal (non-reflink) data fork writes, hence the assert
failure and -EIO return.
We used to actually (accidentally) allocate a new block in this case,
but more recent kernels generate the error. More interestingly, I think
the pending iomap + writeback rework in XFS may simply drop this error
on the floor because we refer to extent state to process the page rather
than the other way around (and buffer_delay() isn't a state in the iomap
bits). This of course depends on which state is actually valid, the
buffer or extent map, which we don't know for sure.
Can you reliably reproduce this problem? If so, can you describe the
reproducer? Also, what is the filesystem geometry ('xfs_info <mnt>')?
And since this is a power kernel, I'm guessing you have 64k pages as
well..?
Brian
> [12290.993668] ------------[ cut here ]------------
> [12290.993672] kernel BUG at fs/xfs/xfs_message.c:102!
> [12290.993676] Oops: Exception in kernel mode, sig: 5 [#1]
> [12290.993678] LE SMP NR_CPUS=2048 NUMA pSeries
> [12290.993697] Dumping ftrace buffer:
> [12290.993730] (ftrace buffer empty)
> [12290.993735] Modules linked in: camellia_generic(E) cast6_generic(E)
> cast_common(E) ppp_generic(E) serpent_generic(E) slhc(E) kvm_pr(E) kvm(E)
> snd_seq(E) snd_seq_device(E) twofish_generic(E) snd_timer(E) snd(E)
> soundcore(E) twofish_common(E) lrw(E) cuse(E) tgr192(E) hci_vhci(E)
> vhost_net(E) bluetooth(E) ecdh_generic(E) wp512(E) rfkill(E)
> vfio_iommu_spapr_tce(E) vfio_spapr_eeh(E) vfio(E) rmd320(E) uhid(E) tun(E)
> tap(E) rmd256(E) rmd160(E) vhost_vsock(E) rmd128(E)
> vmw_vsock_virtio_transport_common(E) vsock(E) vhost(E) uinput(E) md4(E)
> unix_diag(E) dccp_ipv4(E) dccp(E) sha512_generic(E) binfmt_misc(E) fuse(E)
> vfat(E) fat(E) btrfs(E) xor(E) zstd_decompress(E) zstd_compress(E) xxhash(E)
> raid6_pq(E) ext4(E) mbcache(E) jbd2(E) fscrypto(E) loop(E) ip6t_rpfilter(E)
> ipt_REJECT(E) nf_reject_ipv4(E) ip6t_REJECT(E)
> [12290.993784] nf_reject_ipv6(E) xt_conntrack(E) ip_set(E) nfnetlink(E)
> ebtable_nat(E) ebtable_broute(E) bridge(E) stp(E) llc(E) ip6table_nat(E)
> nf_conntrack_ipv6(E) nf_defrag_ipv6(E) nf_nat_ipv6(E) ip6table_mangle(E)
> ip6table_security(E) ip6table_raw(E) iptable_nat(E) nf_conntrack_ipv4(E)
> nf_defrag_ipv4(E) nf_nat_ipv4(E) nf_nat(E) nf_conntrack(E) iptable_mangle(E)
> iptable_security(E) iptable_raw(E) ebtable_filter(E) ebtables(E)
> ip6table_filter(E) ip6_tables(E) iptable_filter(E) xts(E) sg(E)
> vmx_crypto(E) pseries_rng(E) ip_tables(E) xfs(E) libcrc32c(E) sd_mod(E)
> ibmvscsi(E) scsi_transport_srp(E) ibmveth(E) lpfc(E) mlx5_core(E)
> nvmet_fc(E) nvmet(E) nvme_fc(E) nvme_fabrics(E) nvme_core(E)
> scsi_transport_fc(E) mlxfw(E) devlink(E) dm_mirror(E) dm_region_hash(E)
> dm_log(E) dm_mod(E) [last unloaded: torture]
> [12290.993834] CPU: 2 PID: 433 Comm: kswapd1 Tainted: G E
> 4.18.0-rc5-autotest-autotest #1
> [12290.993838] NIP: d00000000ebcfb8c LR: d00000000ebcfb64 CTR:
> c0000000005260a0
> [12290.993841] REGS: c000000feee7ef40 TRAP: 0700 Tainted: G E
> (4.18.0-rc5-autotest-autotest)
> [12290.993845] MSR: 800000010282b033
> <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE,TM[E]> CR: 22224044 XER: 0000000d
> [12290.993854] CFAR: d00000000ebcfb74 IRQMASK: 0
> [12290.993854] GPR00: d00000000ebcfb64 c000000feee7f1c0 d00000000ec58700
> ffffffffffffffea
> [12290.993854] GPR04: 000000000000000a c000000feee7f0c0 ffffffffffffffc0
> d00000000ec41620
> [12290.993854] GPR08: ffffffffffffffca 0000000000000001 0000000000000000
> 0000000000000000
> [12290.993854] GPR12: c0000000005260a0 c00000001ec9d600 c000000feee7f510
> 0000000040000000
> [12290.993854] GPR16: 0000000020000000 0000000000000000 c000000fc6308000
> c000000feee7f4c0
> [12290.993854] GPR20: c000000feee7f520 c000000feee7f520 000ffffffffe0000
> 0000000000000000
> [12290.993854] GPR24: 00000000001fffff 0000000000000001 c000000f689c8800
> 0000000000000000
> [12290.993854] GPR28: c000000f689c8848 c000000feee7f520 0000000000000001
> 0000000000000400
> [12290.993907] NIP [d00000000ebcfb8c] assfail+0x5c/0x60 [xfs]
> [12290.993921] LR [d00000000ebcfb64] assfail+0x34/0x60 [xfs]
> [12290.993923] Call Trace:
> [12290.993936] [c000000feee7f1c0] [d00000000ebcfb64] assfail+0x34/0x60
> [xfs] (unreliable)
> [12290.993947] [c000000feee7f220] [d00000000eb542f0]
> xfs_bmapi_write+0x10f0/0x1260 [xfs]
> [12290.993961] [c000000feee7f450] [d00000000ebc34e8]
> xfs_iomap_write_allocate+0x1b8/0x430 [xfs]
> [12290.993975] [c000000feee7f5c0] [d00000000eba0de4]
> xfs_map_blocks+0x234/0x470 [xfs]
> [12290.993988] [c000000feee7f630] [d00000000eba2d4c]
> xfs_do_writepage+0x27c/0x880 [xfs]
> [12290.994001] [c000000feee7f710] [d00000000eba3314]
> xfs_do_writepage+0x844/0x880 [xfs]
> [12290.994007] [c000000feee7f780] [c00000000029df24]
> pageout.isra.37+0x294/0x4a0
> [12290.994011] [c000000feee7f860] [c0000000002a0a28]
> shrink_page_list+0x948/0x1090
> [12290.994015] [c000000feee7f980] [c0000000002a1c8c]
> shrink_inactive_list+0x2ec/0x720
> [12290.994019] [c000000feee7fa40] [c0000000002a28d8]
> shrink_node_memcg+0x238/0x7d0
> [12290.994024] [c000000feee7fb40] [c0000000002a2f94]
> shrink_node+0x124/0x610
> [12290.994027] [c000000feee7fc10] [c0000000002a46d0]
> balance_pgdat+0x200/0x460
> [12290.994031] [c000000feee7fcf0] [c0000000002a4afc] kswapd+0x1cc/0x5f0
> [12290.994036] [c000000feee7fdc0] [c00000000012ca6c] kthread+0x15c/0x1a0
> [12290.994040] [c000000feee7fe30] [c00000000000b65c]
> ret_from_kernel_thread+0x5c/0x80
> [12290.994043] Instruction dump:
> [12290.994046] f821ffa1 4bfff8a9 3d220000 e929cb40 89290008 2f890000
> 40de0018 0fe00000
> [12290.994053] 38210060 e8010010 7c0803a6 4e800020 <0fe00000> 3c4c0009
> 38428b70 7c0802a6
> [12290.994061] ---[ end trace 84e4cce770c4d4e2 ]---
> [12290.996233]
> [12291.996258] Kernel panic - not syncing: Fatal exception
> [12292.006592] Dumping ftrace buffer:
> [12292.006637] (ftrace buffer empty)
> [12292.013222] WARNING: CPU: 2 PID: 433 at drivers/tty/vt/vt.c:3885
> do_unblank_screen+0x278/0x280
> [12292.013228] Modules linked in: camellia_generic(E) cast6_generic(E)
> cast_common(E) ppp_generic(E) serpent_generic(E) slhc(E) kvm_pr(E) kvm(E)
> snd_seq(E) snd_seq_device(E) twofish_generic(E) snd_timer(E) snd(E)
> soundcore(E) twofish_common(E) lrw(E) cuse(E) tgr192(E) hci_vhci(E)
> vhost_net(E) bluetooth(E) ecdh_generic(E) wp512(E) rfkill(E)
> vfio_iommu_spapr_tce(E) vfio_spapr_eeh(E) vfio(E) rmd320(E) uhid(E) tun(E)
> tap(E) rmd256(E) rmd160(E) vhost_vsock(E) rmd128(E)
> vmw_vsock_virtio_transport_common(E) vsock(E) vhost(E) uinput(E) md4(E)
> unix_diag(E) dccp_ipv4(E) dccp(E) sha512_generic(E) binfmt_misc(E) fuse(E)
> vfat(E) fat(E) btrfs(E) xor(E) zstd_decompress(E) zstd_compress(E) xxhash(E)
> raid6_pq(E) ext4(E) mbcache(E) jbd2(E) fscrypto(E) loop(E) ip6t_rpfilter(E)
> ipt_REJECT(E) nf_reject_ipv4(E) ip6t_REJECT(E)
> [12292.013315] nf_reject_ipv6(E) xt_conntrack(E) ip_set(E) nfnetlink(E)
> ebtable_nat(E) ebtable_broute(E) bridge(E) stp(E) llc(E) ip6table_nat(E)
> nf_conntrack_ipv6(E) nf_defrag_ipv6(E) nf_nat_ipv6(E) ip6table_mangle(E)
> ip6table_security(E) ip6table_raw(E) iptable_nat(E) nf_conntrack_ipv4(E)
> nf_defrag_ipv4(E) nf_nat_ipv4(E) nf_nat(E) nf_conntrack(E) iptable_mangle(E)
> iptable_security(E) iptable_raw(E) ebtable_filter(E) ebtables(E)
> ip6table_filter(E) ip6_tables(E) iptable_filter(E) xts(E) sg(E)
> vmx_crypto(E) pseries_rng(E) ip_tables(E) xfs(E) libcrc32c(E) sd_mod(E)
> ibmvscsi(E) scsi_transport_srp(E) ibmveth(E) lpfc(E) mlx5_core(E)
> nvmet_fc(E) nvmet(E) nvme_fc(E) nvme_fabrics(E) nvme_core(E)
> scsi_transport_fc(E) mlxfw(E) devlink(E) dm_mirror(E) dm_region_hash(E)
> dm_log(E) dm_mod(E) [last unloaded: torture]
> [12292.013394] CPU: 2 PID: 433 Comm: kswapd1 Tainted: G D E
> 4.18.0-rc5-autotest-autotest #1
> [12292.013400] NIP: c0000000005e9cb8 LR: c0000000005e9a7c CTR:
> c00000000002bcc0
> [12292.013406] REGS: c000000feee7e880 TRAP: 0700 Tainted: G D E
> (4.18.0-rc5-autotest-autotest)
> [12292.013411] MSR: 8000000000021033 <SF,ME,IR,DR,RI,LE> CR: 28222042
> XER: 20040009
> [12292.013422] CFAR: c0000000005e9a90 IRQMASK: 3
> [12292.013422] GPR00: c0000000005e9c74 c000000feee7eb00 c000000001150200
> 0000000000000000
> [12292.013422] GPR04: 0000000000000003 000000000000000b 00000000646f6320
> 3030303020726c20
> [12292.013422] GPR08: 0000000000000000 0000000000000000 0000000000000000
> 3830303031303030
> [12292.013422] GPR12: c00000000002bcc0 c00000001ec9d600 c000000feee7f510
> 0000000040000000
> [12292.013422] GPR16: 0000000020000000 0000000000000000 c000000fc6308000
> c000000feee7f4c0
> [12292.013422] GPR20: c000000feee7f520 c000000feee7f520 000ffffffffe0000
> 0000000000000000
> [12292.013422] GPR24: 00000000001fffff 0000000000000001 c000000000ff9e60
> c0000000013067e8
> [12292.013422] GPR28: c0000000013067c0 0000000000000000 c000000001414f60
> c0000000013067e8
> [12292.013483] NIP [c0000000005e9cb8] do_unblank_screen+0x278/0x280
> [12292.013488] LR [c0000000005e9a7c] do_unblank_screen+0x3c/0x280
> [12292.013492] Call Trace:
> [12292.013496] [c000000feee7eb00] [c0000000005e9c74]
> do_unblank_screen+0x234/0x280 (unreliable)
> [12292.013505] [c000000feee7eb80] [c000000000513300]
> bust_spinlocks+0x40/0x80
> [12292.013511] [c000000feee7eba0] [c0000000001003b0] panic+0x1b8/0x308
> [12292.013518] [c000000feee7ec30] [c000000000023a3c] oops_end+0x1ec/0x1f0
> [12292.013524] [c000000feee7ecb0] [c000000000023f54]
> _exception_pkey+0x1c4/0x1f0
> [12292.013530] [c000000feee7ee50] [c000000000026020]
> program_check_exception+0x2c0/0x3e0
> [12292.013537] [c000000feee7eed0] [c000000000008e94]
> program_check_common+0x134/0x140
> [12292.013579] --- interrupt: 700 at assfail+0x5c/0x60 [xfs]
> [12292.013579] LR = assfail+0x34/0x60 [xfs]
> [12292.013597] [c000000feee7f220] [d00000000eb542f0]
> xfs_bmapi_write+0x10f0/0x1260 [xfs]
> [12292.013619] [c000000feee7f450] [d00000000ebc34e8]
> xfs_iomap_write_allocate+0x1b8/0x430 [xfs]
> [12292.013641] [c000000feee7f5c0] [d00000000eba0de4]
> xfs_map_blocks+0x234/0x470 [xfs]
> [12292.013662] [c000000feee7f630] [d00000000eba2d4c]
> xfs_do_writepage+0x27c/0x880 [xfs]
> [12292.013682] [c000000feee7f710] [d00000000eba3314]
> xfs_do_writepage+0x844/0x880 [xfs]
> [12292.013689] [c000000feee7f780] [c00000000029df24]
> pageout.isra.37+0x294/0x4a0
> [12292.013696] [c000000feee7f860] [c0000000002a0a28]
> shrink_page_list+0x948/0x1090
> [12292.013702] [c000000feee7f980] [c0000000002a1c8c]
> shrink_inactive_list+0x2ec/0x720
> [12292.013708] [c000000feee7fa40] [c0000000002a28d8]
> shrink_node_memcg+0x238/0x7d0
> [12292.013714] [c000000feee7fb40] [c0000000002a2f94]
> shrink_node+0x124/0x610
> [12292.013720] [c000000feee7fc10] [c0000000002a46d0]
> balance_pgdat+0x200/0x460
> [12292.013726] [c000000feee7fcf0] [c0000000002a4afc] kswapd+0x1cc/0x5f0
> [12292.013732] [c000000feee7fdc0] [c00000000012ca6c] kthread+0x15c/0x1a0
> [12292.013738] [c000000feee7fe30] [c00000000000b65c]
> ret_from_kernel_thread+0x5c/0x80
> [12292.013743] Instruction dump:
> [12292.013748] 1d290064 3c62ffef 3863ab50 e94a0000 7d2407b4 7c845214
> 4bbbacc9 60000000
> [12292.013758] 39200001 3d42003e 912adff8 4bfffe68 <0fe00000> 4bfffdd8
> 3c4c00b6 38426540
> [12292.013769] ---[ end trace 84e4cce770c4d4e3 ]---
> [12292.013774] Rebooting in 10 seconds..
>
> Regards,
> Venkat.
> >
> > cheers
>
^ permalink raw reply
* Re: [PATCH v6 2/2] hwmon: ibmpowernv: Add attributes to enable/disable sensor groups
From: Guenter Roeck @ 2018-07-19 13:19 UTC (permalink / raw)
To: Stewart Smith, Shilpasri G Bhat, mpe
Cc: linuxppc-dev, linux-hwmon, linux-kernel, ego
In-Reply-To: <87lga7r9rq.fsf@linux.vnet.ibm.com>
On 07/18/2018 11:59 PM, Stewart Smith wrote:
> Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com> writes:
>> On-Chip-Controller(OCC) is an embedded micro-processor in POWER9 chip
>> which measures various system and chip level sensors. These sensors
>> comprises of environmental sensors (like power, temperature, current
>> and voltage) and performance sensors (like utilization, frequency).
>> All these sensors are copied to main memory at a regular interval of
>> 100ms. OCC provides a way to select a group of sensors that is copied
>> to the main memory to increase the update frequency of selected sensor
>> groups. When a sensor-group is disabled, OCC will not copy it to main
>> memory and those sensors read 0 values.
>
> OCC is an implementation detail rather than a core part of this firmware
> API.
>
> Why not something like this:
>
> OPAL firmware provides the facility for some groups of sensors to be
> enabled/disabled at runtime to give the user the option of using the
> system resources for collecting these sensors or not.
>
> For example, on POWER9 systems, the On Chip Controller (OCC) gathers
> various system and chip level sensors and maintains their values in main
> memory.
>
>
>> +static int init_sensor_group_data(struct platform_device *pdev,
>> + struct platform_data *pdata)
>> +{
>> + struct sensor_group_data *sgrp_data;
>> + struct device_node *groups, *sgrp;
>> + enum sensors type;
>> + int count = 0, ret = 0;
>> +
>> + groups = of_find_node_by_path("/ibm,opal/sensor-groups");
>> + if (!groups)
>> + return ret;
>
> Why not look for the compatible property?
>
>
For both, I don't really care either way. Can you folks get to an agreement
and let me know after you decided ?
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH v5 5/7] powerpc/pseries: flush SLB contents on SLB MCE errors.
From: Michael Ellerman @ 2018-07-19 13:08 UTC (permalink / raw)
To: Michal Suchánek, Nicholas Piggin
Cc: Mahesh J Salgaonkar, Laurent Dufour, Aneesh Kumar K.V,
linuxppc-dev
In-Reply-To: <20180712154113.46845936@kitsune.suse.cz>
Michal Such=C3=A1nek <msuchanek@suse.de> writes:
> On Tue, 3 Jul 2018 08:08:14 +1000
> "Nicholas Piggin" <npiggin@gmail.com> wrote: >> On Mon, 02 Jul 2018 11:17=
:06 +0530
>> Mahesh J Salgaonkar <mahesh@linux.vnet.ibm.com> wrote:
>> > From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
>> > diff --git a/arch/powerpc/kernel/mce.c b/arch/powerpc/kernel/mce.c
>> > index efdd16a79075..221271c96a57 100644
>> > --- a/arch/powerpc/kernel/mce.c
>> > +++ b/arch/powerpc/kernel/mce.c
>> > @@ -488,9 +488,21 @@ long machine_check_early(struct pt_regs *regs)
>> > {
>> > long handled =3D 0;
>> >=20=20
>> > - __this_cpu_inc(irq_stat.mce_exceptions);
>> > + /*
>> > + * For pSeries we count mce when we go into virtual mode
>> > machine
>> > + * check handler. Hence skip it. Also, We can't access per
>> > cpu
>> > + * variables in real mode for LPAR.
>> > + */
>> > + if (early_cpu_has_feature(CPU_FTR_HVMODE))
>> > + __this_cpu_inc(irq_stat.mce_exceptions);
>> >=20=20
>> > - if (cur_cpu_spec && cur_cpu_spec->machine_check_early)
>> > + /*
>> > + * See if platform is capable of handling machine check.
>> > + * Otherwise fallthrough and allow CPU to handle this
>> > machine check.
>> > + */
>> > + if (ppc_md.machine_check_early)
>> > + handled =3D ppc_md.machine_check_early(regs);
>> > + else if (cur_cpu_spec && cur_cpu_spec->machine_check_early)
>> > handled =3D
>> > cur_cpu_spec->machine_check_early(regs);=20=20
>>=20
>> Would be good to add a powernv ppc_md handler which does the
>> cur_cpu_spec->machine_check_early() call now that other platforms are
>> calling this code. Because those aren't valid as a fallback call, but
>> specific to powernv.
>>=20
>
> Something like this (untested)?
>
> Subject: [PATCH] powerpc/powernv: define platform MCE handler.
LGTM.
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/msi: Remove VLA usage
From: Michael Ellerman @ 2018-07-19 12:17 UTC (permalink / raw)
To: Kees Cook
Cc: Benjamin Herrenschmidt, Paul Mackerras, Andrew Morton,
Randy Dunlap, Tyrel Datwyler, Rob Herring, Ingo Molnar, PowerPC,
LKML
In-Reply-To: <CAGXu5jKV-YAQZtN2heFdmiD9EOZ-AqrBc-NjC8fRYLSafovuyQ@mail.gmail.com>
Kees Cook <keescook@chromium.org> writes:
> On Fri, Jun 29, 2018 at 11:52 AM, Kees Cook <keescook@chromium.org> wrote:
>> In the quest to remove all stack VLA usage from the kernel[1], this
>> switches from an unchanging variable to a constant expression to eliminate
>> the VLA generation.
>>
>> [1] https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qPXydAacU1RqZWA@mail.gmail.com
>>
>> Signed-off-by: Kees Cook <keescook@chromium.org>
>
> Friendly ping! Michael, can you take this?
Yep, sorry. I actually applied it weeks ago but hadn't pushed.
cheers
^ permalink raw reply
* Re: [PATCH v4 4/6] powerpc/fsl: Enable cpu vulnerabilities reporting for NXP PPC BOOK3E
From: Michael Ellerman @ 2018-07-19 12:05 UTC (permalink / raw)
To: LEROY Christophe, Diana Madalina Craciun
Cc: oss, Bharat Bhushan, linuxppc-dev, Leo Li
In-Reply-To: <20180718180203.Horde.hNnOtk9Z-nuEx9HefV50JQ1@messagerie.si.c-s.fr>
LEROY Christophe <christophe.leroy@c-s.fr> writes:
> Diana Madalina Craciun <diana.craciun@nxp.com> a =C3=A9crit=C2=A0:
>> On 7/17/2018 7:47 PM, LEROY Christophe wrote:
>>> Diana Craciun <diana.craciun@nxp.com> a =C3=A9crit :
>>>> The NXP PPC Book3E platforms are not vulnerable to meltdown and
>>>> Spectre v4, so make them PPC_BOOK3S_64 specific.
>>>>
>>>> Signed-off-by: Diana Craciun <diana.craciun@nxp.com>
>>>> ---
>>>> History:
>>>>
>>>> v2-->v3
>>>> - used the existing functions for spectre v1/v2
>>>>
>>>> arch/powerpc/Kconfig | 7 ++++++-
>>>> arch/powerpc/kernel/security.c | 2 ++
>>>> 2 files changed, 8 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
>>>> index 9f2b75f..116c953 100644
>>>> --- a/arch/powerpc/Kconfig
>>>> +++ b/arch/powerpc/Kconfig
>>>> @@ -165,7 +165,7 @@ config PPC
>>>> select GENERIC_CLOCKEVENTS_BROADCAST if SMP
>>>> select GENERIC_CMOS_UPDATE
>>>> select GENERIC_CPU_AUTOPROBE
>>>> - select GENERIC_CPU_VULNERABILITIES if PPC_BOOK3S_64
>>>> + select GENERIC_CPU_VULNERABILITIES if PPC_NOSPEC
>>> I don't understand. You say this patch is to make something specific
>>> to book3s64 specific, and you are creating a new config param that
>>> make things less specific
>>>
>>> Christophe
>>
>> In order to enable the vulnerabilities reporting on NXP socs I need to
>> enable them for PPC_FSL_BOOK3E. So they will be enabled for both
>> PPC_FSL_BOOK3E and PPC_BOOK3S_64. This is the reason for adding the
>> Kconfig. However this will enable: spectre v1/v2 and meltdown. NXP socs
>> are not vulnerable to meltdown, so I made the meltdown reporting
>> PPC_BOOK3S_64 specific. I guess I can have the PPC_NOSPEC definition in
>> a separate patch to be more clear.
>
> Yes you can. Or keep it as a single patch and add the details you gave=20=
=20
> me in the patch description.
Yeah I think the patch is fine, but the change log is a bit short on detail.
If you just send me a new change log I can fold it in.
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/prom_init: remove linux,stdout-package property
From: Michael Ellerman @ 2018-07-19 12:03 UTC (permalink / raw)
To: Murilo Opsfelder Araujo
Cc: linux-kernel, Aneesh Kumar K . V, Kees Cook, Mathieu Malaterre,
Bharata B Rao, Nicholas Piggin, Alexey Kardashevskiy,
Michael Bringmann, Paul Mackerras, Cédric Le Goater,
Nathan Fontenot, linuxppc-dev
In-Reply-To: <20180718162116.GA24748@kermit-br-ibm-com>
Murilo Opsfelder Araujo <muriloo@linux.ibm.com> writes:
> On Wed, Jul 18, 2018 at 07:37:37PM +1000, Michael Ellerman wrote:
>> Murilo Opsfelder Araujo <muriloo@linux.ibm.com> writes:
>> > This property was added in 2004 by
>> >
>> > https://github.com/mpe/linux-fullhistory/commit/689fe5072fe9a0dec914bfa4fa60aed1e54563e6
>> >
>> > and the only use of it, which was already inside `#if 0`, was removed a month
>> > later by
>> >
>> > https://github.com/mpe/linux-fullhistory/commit/1fbe5a6d90f6cd4ea610737ef488719d1a875de7
>> >
>> > Fixes: https://github.com/linuxppc/linux/issues/125
>>
>> That is going to confuse some scripts that are expecting that to be a
>> "Fixes: <some commit>" tag :)
>>
>> The proper tag to use there would be "Link:".
>>
>> But, I'd prefer we didn't add github issue links to the history, as I'm
>> not sure they won't bit-rot eventually. Not because I'm a anti-Microsoft
>> conspiracy person but just because it's a repo I set up and manage and
>> there's no long term plan for it necessarily.
>>
>> > ---
>> > arch/powerpc/kernel/prom_init.c | 2 --
>> > 1 file changed, 2 deletions(-)
>>
>> Including the link here would be ideal, as it means it doesn't end up in
>> the commit history, but it does end up in the mail archive. So if we
>> ever really need to find it, it should be there.
>>
>> cheers
>
> Hi, Michael.
>
> Thanks for reviewing it. I've sent v2 with your suggestions:
>
> https://lkml.kernel.org/r/20180718161544.12134-1-muriloo@linux.ibm.com
Thanks.
I had actually already applied the first version, but I didn't say that
in my email did I :}
So I've rebased and applied your v2, thanks.
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/ps3: Set driver coherent_dma_mask
From: Michael Ellerman @ 2018-07-19 11:28 UTC (permalink / raw)
To: Greg KH, Geoff Levand
Cc: Alan Stern, Takashi Iwai, Jaroslav Kysela, linux-usb,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20180719065503.GB21108@kroah.com>
Greg KH <gregkh@linuxfoundation.org> writes:
> On Wed, Jul 18, 2018 at 03:08:33PM -0700, Geoff Levand wrote:
>> Set the coherent_dma_mask for the PS3 ehci, ohci, and snd devices.
>>
>> Silences WARN_ON_ONCE messages emitted by the dma_alloc_attrs() routine.
>>
>> Reported-by: Fredrik Noring <noring@nocrew.org>
>> Signed-off-by: Geoff Levand <geoff@infradead.org>
>> ---
>> Hi Michael,
>>
>> This just silences some warnings. Can you take it through the powerpc
>> tree?
>
> Oops, nevermind, it should go through the ppc tree. Here's my ack:
>
> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
OK thanks, I'll take it.
cheers
^ permalink raw reply
* Re: [RFC PATCH v6 0/4] powerpc/fadump: Improvements and fixes for firmware-assisted dump.
From: Michal Hocko @ 2018-07-19 8:08 UTC (permalink / raw)
To: Mahesh Jagannath Salgaonkar
Cc: linuxppc-dev, Linux Kernel, Hari Bathini,
Ananth N Mavinakayanahalli, Srikar Dronamraju, Aneesh Kumar K.V,
Anshuman Khandual, Andrew Morton, Joonsoo Kim, Ananth Narayan,
kernelfans
In-Reply-To: <b2c316b9-520e-0a31-3ebd-d3ade50c3783@linux.vnet.ibm.com>
On Wed 18-07-18 21:52:17, Mahesh Jagannath Salgaonkar wrote:
> On 07/17/2018 05:22 PM, Michal Hocko wrote:
> > On Tue 17-07-18 16:58:10, Mahesh Jagannath Salgaonkar wrote:
> >> On 07/16/2018 01:56 PM, Michal Hocko wrote:
> >>> On Mon 16-07-18 11:32:56, Mahesh J Salgaonkar wrote:
> >>>> One of the primary issues with Firmware Assisted Dump (fadump) on Power
> >>>> is that it needs a large amount of memory to be reserved. This reserved
> >>>> memory is used for saving the contents of old crashed kernel's memory before
> >>>> fadump capture kernel uses old kernel's memory area to boot. However, This
> >>>> reserved memory area stays unused until system crash and isn't available
> >>>> for production kernel to use.
> >>>
> >>> How much memory are we talking about. Regular kernel dump process needs
> >>> some reserved memory as well. Why that is not a big problem?
> >>
> >> We reserve around 5% of total system RAM. On large systems with
> >> TeraBytes of memory, this reservation can be quite significant.
> >>
> >> The regular kernel dump uses the kexec method to boot into capture
> >> kernel and it can control the parameters that are being passed to
> >> capture kernel. This allows a capability to strip down the parameters
> >> that can help lowering down the memory requirement for capture kernel to
> >> boot. This allows regular kdump to reserve less memory to start with.
> >>
> >> Where as fadump depends on power firmware (pHyp) to load the capture
> >> kernel after full reset and boots like a regular kernel. It needs same
> >> amount of memory to boot as the production kernel. On large systems
> >> production kernel needs significant amount of memory to boot. Hence
> >> fadump needs to reserve enough memory for capture kernel to boot
> >> successfully and execute dump capturing operations. By default fadump
> >> reserves 5% of total system RAM and in most cases this has worked
> >> flawlessly on variety of system configurations. Optionally,
> >> 'crashkernel=X' can also be used to specify more fine-tuned memory size
> >> for reservation.
> >
> > So why do we even care about fadump when regular kexec provides
> > (presumably) same functionality with a smaller memory footprint? Or is
> > there any reason why kexec doesn't work well on ppc?
>
> Kexec based kdump is loaded by crashing kernel. When OS crashes, the
> system is in an inconsistent state, especially the devices. In some
> cases, a rogue DMA or ill-behaving device drivers can cause the kdump
> capture to fail.
>
> On power platform, fadump solves these issues by taking help from power
> firmware, to fully-reset the system, load the fresh copy of same kernel
> to capture the dump with PCI and I/O devices reinitialized, making it
> more reliable.
Thanks for the clarification.
> Fadump does full system reset, booting system through the regular boot
> options i.e the dump capture kernel is booted in the same fashion and
> doesn't have specialized kernel command line option. This implies, we
> need to give more memory for the system boot. Since the new kernel boots
> from the same memory location as crashed kernel, we reserve 5% of memory
> where power firmware moves the crashed kernel's memory content. This
> reserved memory is completely removed from the available memory. For
> large memory systems like 64TB systems, this account to ~ 3TB, which is
> a significant chunk of memory production kernel is deprived of. Hence,
> this patch adds an improvement to exiting fadump feature to make the
> reserved memory available to system for use, using zone movable.
Is the 5% a reasonable estimate or more a ballpark number? I find it a
bit strange to require 3TB of memory to boot a kernel just to dump the
crashed kernel image. Shouldn't you rather look into this estimate than
spreading ZONE_MOVABLE abuse? Larger systems need more memory to dump
even with the regular kexec kdump but I have never seen any to use more
than 1G or something like that.
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: Improvements for the PS3
From: Geert Uytterhoeven @ 2018-07-19 7:45 UTC (permalink / raw)
To: geoff, noring; +Cc: linuxppc-dev
In-Reply-To: <7d6362d7-da99-e57f-40ed-81c7a03ea1a4@infradead.org>
Hi Geoff, Frederik,
On Thu, Jul 19, 2018 at 12:40 AM Geoff Levand <geoff@infradead.org> wrote:
> On 07/14/2018 09:49 AM, Fredrik Noring wrote:
> > so I added a sleep with
> >
> > + msleep(10000);
I can't see where you added the sleep, but 10s seems excessive.
If the real reason is the need to wait for an interrupt for ps3fb_sync_imag=
e(),
then waiting for 40 ms should be sufficient? Or am I missing something?
> > +
> > return 0;
> >
> > et voil=C3=A0, the screen came alive and the kernel panic was revealed!=
It seems
> > the kernel panics so fast that the PS3 frame buffer is unprepared. This=
is,
> > of course, very unfortunate because trying to debug the boot process wi=
thout
> > a screen or any other means of obtaining console text is quite difficul=
t.
>
> We could add a fixed delay there, but I'd like to avoid waiting that
> long on every boot. Why don't you add a kernel module_param named
> something like ps3fb_delay that takes a value in milliseconds and a
> default of zero. See:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree=
/drivers/video/fbdev/ps3fb.c?h=3Dv4.17#n260
>
> > I suppose the problem is that it relies on interrupts for ps3fb_sync_im=
age
> > to regularly copy the image, hence without them the screen isn't update=
d to
> > show kernel panics, etc. Perhaps one way to fix that is to implement th=
e
> > struct fb_tile_ops API, so that the console is synchronously updated? W=
ould
> > that be acceptable?
>
> I'm not sure if that would work or not. Maybe Geert is more familiar wi=
th it.
That sounds like a complex solution, slowing down the console a lot.
What about letting ps3fb register a panic notifier to sync the screen, like
hyperv_fb does?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k=
.org
In personal conversations with technical people, I call myself a hacker. Bu=
t
when I'm talking to journalists I just say "programmer" or something like t=
hat.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v6 2/2] hwmon: ibmpowernv: Add attributes to enable/disable sensor groups
From: Stewart Smith @ 2018-07-19 6:59 UTC (permalink / raw)
To: Shilpasri G Bhat, mpe, linux
Cc: linuxppc-dev, linux-hwmon, linux-kernel, ego, Shilpasri G Bhat
In-Reply-To: <1531937610-6454-3-git-send-email-shilpa.bhat@linux.vnet.ibm.com>
Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com> writes:
> On-Chip-Controller(OCC) is an embedded micro-processor in POWER9 chip
> which measures various system and chip level sensors. These sensors
> comprises of environmental sensors (like power, temperature, current
> and voltage) and performance sensors (like utilization, frequency).
> All these sensors are copied to main memory at a regular interval of
> 100ms. OCC provides a way to select a group of sensors that is copied
> to the main memory to increase the update frequency of selected sensor
> groups. When a sensor-group is disabled, OCC will not copy it to main
> memory and those sensors read 0 values.
OCC is an implementation detail rather than a core part of this firmware
API.
Why not something like this:
OPAL firmware provides the facility for some groups of sensors to be
enabled/disabled at runtime to give the user the option of using the
system resources for collecting these sensors or not.
For example, on POWER9 systems, the On Chip Controller (OCC) gathers
various system and chip level sensors and maintains their values in main
memory.
> +static int init_sensor_group_data(struct platform_device *pdev,
> + struct platform_data *pdata)
> +{
> + struct sensor_group_data *sgrp_data;
> + struct device_node *groups, *sgrp;
> + enum sensors type;
> + int count = 0, ret = 0;
> +
> + groups = of_find_node_by_path("/ibm,opal/sensor-groups");
> + if (!groups)
> + return ret;
Why not look for the compatible property?
--
Stewart Smith
OPAL Architect, IBM.
^ permalink raw reply
* Re: [PATCH] powerpc/ps3: Set driver coherent_dma_mask
From: Greg KH @ 2018-07-19 6:55 UTC (permalink / raw)
To: Geoff Levand
Cc: Alan Stern, Takashi Iwai, Jaroslav Kysela, Michael Ellerman,
linux-usb, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <068ebcfa-7cd0-bd06-42e7-577a4624f0b0@infradead.org>
On Wed, Jul 18, 2018 at 03:08:33PM -0700, Geoff Levand wrote:
> Set the coherent_dma_mask for the PS3 ehci, ohci, and snd devices.
>
> Silences WARN_ON_ONCE messages emitted by the dma_alloc_attrs() routine.
>
> Reported-by: Fredrik Noring <noring@nocrew.org>
> Signed-off-by: Geoff Levand <geoff@infradead.org>
> ---
> Hi Michael,
>
> This just silences some warnings. Can you take it through the powerpc
> tree?
Oops, nevermind, it should go through the ppc tree. Here's my ack:
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* Re: [PATCH] powerpc/ps3: Set driver coherent_dma_mask
From: Greg KH @ 2018-07-19 6:54 UTC (permalink / raw)
To: Takashi Iwai
Cc: Geoff Levand, Michael Ellerman, Jaroslav Kysela, Alan Stern,
linuxppc-dev@lists.ozlabs.org, linux-usb
In-Reply-To: <s5hin5b67u2.wl-tiwai@suse.de>
On Thu, Jul 19, 2018 at 08:46:45AM +0200, Takashi Iwai wrote:
> On Thu, 19 Jul 2018 00:08:33 +0200,
> Geoff Levand wrote:
> >
> > Set the coherent_dma_mask for the PS3 ehci, ohci, and snd devices.
> >
> > Silences WARN_ON_ONCE messages emitted by the dma_alloc_attrs() routine.
> >
> > Reported-by: Fredrik Noring <noring@nocrew.org>
> > Signed-off-by: Geoff Levand <geoff@infradead.org>
>
> For sound bits,
> Reviewed-by: Takashi Iwai <tiwai@suse.de>
Thanks, I'll take this through the USB tree then.
greg k-h
^ permalink raw reply
* Re: [PATCH] powerpc/ps3: Set driver coherent_dma_mask
From: Takashi Iwai @ 2018-07-19 6:46 UTC (permalink / raw)
To: Geoff Levand
Cc: Michael Ellerman, Jaroslav Kysela, Alan Stern,
linuxppc-dev@lists.ozlabs.org, linux-usb
In-Reply-To: <068ebcfa-7cd0-bd06-42e7-577a4624f0b0@infradead.org>
On Thu, 19 Jul 2018 00:08:33 +0200,
Geoff Levand wrote:
>
> Set the coherent_dma_mask for the PS3 ehci, ohci, and snd devices.
>
> Silences WARN_ON_ONCE messages emitted by the dma_alloc_attrs() routine.
>
> Reported-by: Fredrik Noring <noring@nocrew.org>
> Signed-off-by: Geoff Levand <geoff@infradead.org>
For sound bits,
Reviewed-by: Takashi Iwai <tiwai@suse.de>
thanks,
Takashi
> ---
> Hi Michael,
>
> This just silences some warnings. Can you take it through the powerpc
> tree?
>
> -Geoff
>
>
> drivers/usb/host/ehci-ps3.c | 6 ++++--
> drivers/usb/host/ohci-ps3.c | 6 ++++--
> sound/ppc/snd_ps3.c | 5 +++++
> 3 files changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/usb/host/ehci-ps3.c b/drivers/usb/host/ehci-ps3.c
> index 8c733492d8fe..454d8c624a3f 100644
> --- a/drivers/usb/host/ehci-ps3.c
> +++ b/drivers/usb/host/ehci-ps3.c
> @@ -86,7 +86,7 @@ static int ps3_ehci_probe(struct ps3_system_bus_device *dev)
> int result;
> struct usb_hcd *hcd;
> unsigned int virq;
> - static u64 dummy_mask = DMA_BIT_MASK(32);
> + static u64 dummy_mask;
>
> if (usb_disabled()) {
> result = -ENODEV;
> @@ -131,7 +131,9 @@ static int ps3_ehci_probe(struct ps3_system_bus_device *dev)
> goto fail_irq;
> }
>
> - dev->core.dma_mask = &dummy_mask; /* FIXME: for improper usb code */
> + dummy_mask = DMA_BIT_MASK(32);
> + dev->core.dma_mask = &dummy_mask;
> + dma_set_coherent_mask(&dev->core, dummy_mask);
>
> hcd = usb_create_hcd(&ps3_ehci_hc_driver, &dev->core, dev_name(&dev->core));
>
> diff --git a/drivers/usb/host/ohci-ps3.c b/drivers/usb/host/ohci-ps3.c
> index 20a23d795adf..395f9d3bc849 100644
> --- a/drivers/usb/host/ohci-ps3.c
> +++ b/drivers/usb/host/ohci-ps3.c
> @@ -69,7 +69,7 @@ static int ps3_ohci_probe(struct ps3_system_bus_device *dev)
> int result;
> struct usb_hcd *hcd;
> unsigned int virq;
> - static u64 dummy_mask = DMA_BIT_MASK(32);
> + static u64 dummy_mask;
>
> if (usb_disabled()) {
> result = -ENODEV;
> @@ -115,7 +115,9 @@ static int ps3_ohci_probe(struct ps3_system_bus_device *dev)
> goto fail_irq;
> }
>
> - dev->core.dma_mask = &dummy_mask; /* FIXME: for improper usb code */
> + dummy_mask = DMA_BIT_MASK(32);
> + dev->core.dma_mask = &dummy_mask;
> + dma_set_coherent_mask(&dev->core, dummy_mask);
>
> hcd = usb_create_hcd(&ps3_ohci_hc_driver, &dev->core, dev_name(&dev->core));
>
> diff --git a/sound/ppc/snd_ps3.c b/sound/ppc/snd_ps3.c
> index 36f34f434ecb..abe031c9d592 100644
> --- a/sound/ppc/snd_ps3.c
> +++ b/sound/ppc/snd_ps3.c
> @@ -930,6 +930,7 @@ static int snd_ps3_driver_probe(struct ps3_system_bus_device *dev)
> {
> int i, ret;
> u64 lpar_addr, lpar_size;
> + static u64 dummy_mask;
>
> if (WARN_ON(!firmware_has_feature(FW_FEATURE_PS3_LV1)))
> return -ENODEV;
> @@ -970,6 +971,10 @@ static int snd_ps3_driver_probe(struct ps3_system_bus_device *dev)
> goto clean_mmio;
> }
>
> + dummy_mask = DMA_BIT_MASK(32);
> + dev->core.dma_mask = &dummy_mask;
> + dma_set_coherent_mask(&dev->core, dummy_mask);
> +
> snd_ps3_audio_set_base_addr(dev->d_region->bus_addr);
>
> /* CONFIG_SND_PS3_DEFAULT_START_DELAY */
> --
> 2.14.1
>
>
^ permalink raw reply
* Re: [powerpc/powervm]Oops: Kernel access of bad area, sig: 11 [#1] while running stress-ng
From: vrbagal1 @ 2018-07-19 6:17 UTC (permalink / raw)
To: Michael Ellerman
Cc: Nicholas Piggin, linux-fsdevel, sachinp, linuxppc-dev,
Linuxppc-dev
In-Reply-To: <877em3b42f.fsf@concordia.ellerman.id.au>
On 2018-07-10 19:12, Michael Ellerman wrote:
> vrbagal1 <vrbagal1@linux.vnet.ibm.com> writes:
>
>> On 2018-07-10 13:37, Nicholas Piggin wrote:
>>> On Tue, 10 Jul 2018 11:58:40 +0530
>>> vrbagal1 <vrbagal1@linux.vnet.ibm.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> Observing kernel oops on Power9(ZZ) box, running on PowerVM, while
>>>> running stress-ng.
>>>>
>>>>
>>>> Kernel: 4.18.0-rc4
>>>> Machine: Power9 ZZ (PowerVM)
>>>> Test: Stress-ng
>>>>
>>>> Attached is .config file
>>>>
>>>> Traces:
>>>>
>>>> [12251.245209] Oops: Kernel access of bad area, sig: 11 [#1]
>>>
>>> Can you post the lines above this? Otherwise we don't know what
>>> address
>>> it tried to access (without decoding the instructions and
>>> reconstructing
>>> it from registers at least, which the XFS devs wouldn't be inclined
>>> to
>>> do).
>>>
>>
>> ah my bad.
>>
>> [12251.245179] Unable to handle kernel paging request for data at
>> address 0x6000000060000000
>> [12251.245199] Faulting instruction address: 0xc000000000319e2c
>
> Which matches the regs & disassembly:
>
> r4 = 6000000060000000
> r9 = 0
> ldx r9,r4,r9 <- pop
>
> So object was 0x6000000060000000.
>
> That looks like two nops, ie. we got some code?
>
> And there's only one caller of prefetch_freepointer() in
> slab_alloc_node():
>
> prefetch_freepointer(s, next_object);
>
>
> So slab corruption is looking likely.
>
> Do you have slub_debug=FZP on the kernel command line?
I tried to reproduce this, but didnt succeed. But instead I got xfs
assertion.
Kernel: 4.18.0-rc5
Tree Head: 30b06abfb92bfd5f9b63ea6a2ffb0bd905d1a6da
Traces:
[12290.993612] XFS: Assertion failed: flags & XFS_BMAPI_COWFORK, file:
fs/xfs/libxfs/xfs_bmap.c, line: 4370
[12290.993668] ------------[ cut here ]------------
[12290.993672] kernel BUG at fs/xfs/xfs_message.c:102!
[12290.993676] Oops: Exception in kernel mode, sig: 5 [#1]
[12290.993678] LE SMP NR_CPUS=2048 NUMA pSeries
[12290.993697] Dumping ftrace buffer:
[12290.993730] (ftrace buffer empty)
[12290.993735] Modules linked in: camellia_generic(E) cast6_generic(E)
cast_common(E) ppp_generic(E) serpent_generic(E) slhc(E) kvm_pr(E)
kvm(E) snd_seq(E) snd_seq_device(E) twofish_generic(E) snd_timer(E)
snd(E) soundcore(E) twofish_common(E) lrw(E) cuse(E) tgr192(E)
hci_vhci(E) vhost_net(E) bluetooth(E) ecdh_generic(E) wp512(E) rfkill(E)
vfio_iommu_spapr_tce(E) vfio_spapr_eeh(E) vfio(E) rmd320(E) uhid(E)
tun(E) tap(E) rmd256(E) rmd160(E) vhost_vsock(E) rmd128(E)
vmw_vsock_virtio_transport_common(E) vsock(E) vhost(E) uinput(E) md4(E)
unix_diag(E) dccp_ipv4(E) dccp(E) sha512_generic(E) binfmt_misc(E)
fuse(E) vfat(E) fat(E) btrfs(E) xor(E) zstd_decompress(E)
zstd_compress(E) xxhash(E) raid6_pq(E) ext4(E) mbcache(E) jbd2(E)
fscrypto(E) loop(E) ip6t_rpfilter(E) ipt_REJECT(E) nf_reject_ipv4(E)
ip6t_REJECT(E)
[12290.993784] nf_reject_ipv6(E) xt_conntrack(E) ip_set(E)
nfnetlink(E) ebtable_nat(E) ebtable_broute(E) bridge(E) stp(E) llc(E)
ip6table_nat(E) nf_conntrack_ipv6(E) nf_defrag_ipv6(E) nf_nat_ipv6(E)
ip6table_mangle(E) ip6table_security(E) ip6table_raw(E) iptable_nat(E)
nf_conntrack_ipv4(E) nf_defrag_ipv4(E) nf_nat_ipv4(E) nf_nat(E)
nf_conntrack(E) iptable_mangle(E) iptable_security(E) iptable_raw(E)
ebtable_filter(E) ebtables(E) ip6table_filter(E) ip6_tables(E)
iptable_filter(E) xts(E) sg(E) vmx_crypto(E) pseries_rng(E) ip_tables(E)
xfs(E) libcrc32c(E) sd_mod(E) ibmvscsi(E) scsi_transport_srp(E)
ibmveth(E) lpfc(E) mlx5_core(E) nvmet_fc(E) nvmet(E) nvme_fc(E)
nvme_fabrics(E) nvme_core(E) scsi_transport_fc(E) mlxfw(E) devlink(E)
dm_mirror(E) dm_region_hash(E) dm_log(E) dm_mod(E) [last unloaded:
torture]
[12290.993834] CPU: 2 PID: 433 Comm: kswapd1 Tainted: G E
4.18.0-rc5-autotest-autotest #1
[12290.993838] NIP: d00000000ebcfb8c LR: d00000000ebcfb64 CTR:
c0000000005260a0
[12290.993841] REGS: c000000feee7ef40 TRAP: 0700 Tainted: G
E (4.18.0-rc5-autotest-autotest)
[12290.993845] MSR: 800000010282b033
<SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE,TM[E]> CR: 22224044 XER: 0000000d
[12290.993854] CFAR: d00000000ebcfb74 IRQMASK: 0
[12290.993854] GPR00: d00000000ebcfb64 c000000feee7f1c0
d00000000ec58700 ffffffffffffffea
[12290.993854] GPR04: 000000000000000a c000000feee7f0c0
ffffffffffffffc0 d00000000ec41620
[12290.993854] GPR08: ffffffffffffffca 0000000000000001
0000000000000000 0000000000000000
[12290.993854] GPR12: c0000000005260a0 c00000001ec9d600
c000000feee7f510 0000000040000000
[12290.993854] GPR16: 0000000020000000 0000000000000000
c000000fc6308000 c000000feee7f4c0
[12290.993854] GPR20: c000000feee7f520 c000000feee7f520
000ffffffffe0000 0000000000000000
[12290.993854] GPR24: 00000000001fffff 0000000000000001
c000000f689c8800 0000000000000000
[12290.993854] GPR28: c000000f689c8848 c000000feee7f520
0000000000000001 0000000000000400
[12290.993907] NIP [d00000000ebcfb8c] assfail+0x5c/0x60 [xfs]
[12290.993921] LR [d00000000ebcfb64] assfail+0x34/0x60 [xfs]
[12290.993923] Call Trace:
[12290.993936] [c000000feee7f1c0] [d00000000ebcfb64] assfail+0x34/0x60
[xfs] (unreliable)
[12290.993947] [c000000feee7f220] [d00000000eb542f0]
xfs_bmapi_write+0x10f0/0x1260 [xfs]
[12290.993961] [c000000feee7f450] [d00000000ebc34e8]
xfs_iomap_write_allocate+0x1b8/0x430 [xfs]
[12290.993975] [c000000feee7f5c0] [d00000000eba0de4]
xfs_map_blocks+0x234/0x470 [xfs]
[12290.993988] [c000000feee7f630] [d00000000eba2d4c]
xfs_do_writepage+0x27c/0x880 [xfs]
[12290.994001] [c000000feee7f710] [d00000000eba3314]
xfs_do_writepage+0x844/0x880 [xfs]
[12290.994007] [c000000feee7f780] [c00000000029df24]
pageout.isra.37+0x294/0x4a0
[12290.994011] [c000000feee7f860] [c0000000002a0a28]
shrink_page_list+0x948/0x1090
[12290.994015] [c000000feee7f980] [c0000000002a1c8c]
shrink_inactive_list+0x2ec/0x720
[12290.994019] [c000000feee7fa40] [c0000000002a28d8]
shrink_node_memcg+0x238/0x7d0
[12290.994024] [c000000feee7fb40] [c0000000002a2f94]
shrink_node+0x124/0x610
[12290.994027] [c000000feee7fc10] [c0000000002a46d0]
balance_pgdat+0x200/0x460
[12290.994031] [c000000feee7fcf0] [c0000000002a4afc] kswapd+0x1cc/0x5f0
[12290.994036] [c000000feee7fdc0] [c00000000012ca6c]
kthread+0x15c/0x1a0
[12290.994040] [c000000feee7fe30] [c00000000000b65c]
ret_from_kernel_thread+0x5c/0x80
[12290.994043] Instruction dump:
[12290.994046] f821ffa1 4bfff8a9 3d220000 e929cb40 89290008 2f890000
40de0018 0fe00000
[12290.994053] 38210060 e8010010 7c0803a6 4e800020 <0fe00000> 3c4c0009
38428b70 7c0802a6
[12290.994061] ---[ end trace 84e4cce770c4d4e2 ]---
[12290.996233]
[12291.996258] Kernel panic - not syncing: Fatal exception
[12292.006592] Dumping ftrace buffer:
[12292.006637] (ftrace buffer empty)
[12292.013222] WARNING: CPU: 2 PID: 433 at drivers/tty/vt/vt.c:3885
do_unblank_screen+0x278/0x280
[12292.013228] Modules linked in: camellia_generic(E) cast6_generic(E)
cast_common(E) ppp_generic(E) serpent_generic(E) slhc(E) kvm_pr(E)
kvm(E) snd_seq(E) snd_seq_device(E) twofish_generic(E) snd_timer(E)
snd(E) soundcore(E) twofish_common(E) lrw(E) cuse(E) tgr192(E)
hci_vhci(E) vhost_net(E) bluetooth(E) ecdh_generic(E) wp512(E) rfkill(E)
vfio_iommu_spapr_tce(E) vfio_spapr_eeh(E) vfio(E) rmd320(E) uhid(E)
tun(E) tap(E) rmd256(E) rmd160(E) vhost_vsock(E) rmd128(E)
vmw_vsock_virtio_transport_common(E) vsock(E) vhost(E) uinput(E) md4(E)
unix_diag(E) dccp_ipv4(E) dccp(E) sha512_generic(E) binfmt_misc(E)
fuse(E) vfat(E) fat(E) btrfs(E) xor(E) zstd_decompress(E)
zstd_compress(E) xxhash(E) raid6_pq(E) ext4(E) mbcache(E) jbd2(E)
fscrypto(E) loop(E) ip6t_rpfilter(E) ipt_REJECT(E) nf_reject_ipv4(E)
ip6t_REJECT(E)
[12292.013315] nf_reject_ipv6(E) xt_conntrack(E) ip_set(E)
nfnetlink(E) ebtable_nat(E) ebtable_broute(E) bridge(E) stp(E) llc(E)
ip6table_nat(E) nf_conntrack_ipv6(E) nf_defrag_ipv6(E) nf_nat_ipv6(E)
ip6table_mangle(E) ip6table_security(E) ip6table_raw(E) iptable_nat(E)
nf_conntrack_ipv4(E) nf_defrag_ipv4(E) nf_nat_ipv4(E) nf_nat(E)
nf_conntrack(E) iptable_mangle(E) iptable_security(E) iptable_raw(E)
ebtable_filter(E) ebtables(E) ip6table_filter(E) ip6_tables(E)
iptable_filter(E) xts(E) sg(E) vmx_crypto(E) pseries_rng(E) ip_tables(E)
xfs(E) libcrc32c(E) sd_mod(E) ibmvscsi(E) scsi_transport_srp(E)
ibmveth(E) lpfc(E) mlx5_core(E) nvmet_fc(E) nvmet(E) nvme_fc(E)
nvme_fabrics(E) nvme_core(E) scsi_transport_fc(E) mlxfw(E) devlink(E)
dm_mirror(E) dm_region_hash(E) dm_log(E) dm_mod(E) [last unloaded:
torture]
[12292.013394] CPU: 2 PID: 433 Comm: kswapd1 Tainted: G D E
4.18.0-rc5-autotest-autotest #1
[12292.013400] NIP: c0000000005e9cb8 LR: c0000000005e9a7c CTR:
c00000000002bcc0
[12292.013406] REGS: c000000feee7e880 TRAP: 0700 Tainted: G D
E (4.18.0-rc5-autotest-autotest)
[12292.013411] MSR: 8000000000021033 <SF,ME,IR,DR,RI,LE> CR: 28222042
XER: 20040009
[12292.013422] CFAR: c0000000005e9a90 IRQMASK: 3
[12292.013422] GPR00: c0000000005e9c74 c000000feee7eb00
c000000001150200 0000000000000000
[12292.013422] GPR04: 0000000000000003 000000000000000b
00000000646f6320 3030303020726c20
[12292.013422] GPR08: 0000000000000000 0000000000000000
0000000000000000 3830303031303030
[12292.013422] GPR12: c00000000002bcc0 c00000001ec9d600
c000000feee7f510 0000000040000000
[12292.013422] GPR16: 0000000020000000 0000000000000000
c000000fc6308000 c000000feee7f4c0
[12292.013422] GPR20: c000000feee7f520 c000000feee7f520
000ffffffffe0000 0000000000000000
[12292.013422] GPR24: 00000000001fffff 0000000000000001
c000000000ff9e60 c0000000013067e8
[12292.013422] GPR28: c0000000013067c0 0000000000000000
c000000001414f60 c0000000013067e8
[12292.013483] NIP [c0000000005e9cb8] do_unblank_screen+0x278/0x280
[12292.013488] LR [c0000000005e9a7c] do_unblank_screen+0x3c/0x280
[12292.013492] Call Trace:
[12292.013496] [c000000feee7eb00] [c0000000005e9c74]
do_unblank_screen+0x234/0x280 (unreliable)
[12292.013505] [c000000feee7eb80] [c000000000513300]
bust_spinlocks+0x40/0x80
[12292.013511] [c000000feee7eba0] [c0000000001003b0] panic+0x1b8/0x308
[12292.013518] [c000000feee7ec30] [c000000000023a3c]
oops_end+0x1ec/0x1f0
[12292.013524] [c000000feee7ecb0] [c000000000023f54]
_exception_pkey+0x1c4/0x1f0
[12292.013530] [c000000feee7ee50] [c000000000026020]
program_check_exception+0x2c0/0x3e0
[12292.013537] [c000000feee7eed0] [c000000000008e94]
program_check_common+0x134/0x140
[12292.013579] --- interrupt: 700 at assfail+0x5c/0x60 [xfs]
[12292.013579] LR = assfail+0x34/0x60 [xfs]
[12292.013597] [c000000feee7f220] [d00000000eb542f0]
xfs_bmapi_write+0x10f0/0x1260 [xfs]
[12292.013619] [c000000feee7f450] [d00000000ebc34e8]
xfs_iomap_write_allocate+0x1b8/0x430 [xfs]
[12292.013641] [c000000feee7f5c0] [d00000000eba0de4]
xfs_map_blocks+0x234/0x470 [xfs]
[12292.013662] [c000000feee7f630] [d00000000eba2d4c]
xfs_do_writepage+0x27c/0x880 [xfs]
[12292.013682] [c000000feee7f710] [d00000000eba3314]
xfs_do_writepage+0x844/0x880 [xfs]
[12292.013689] [c000000feee7f780] [c00000000029df24]
pageout.isra.37+0x294/0x4a0
[12292.013696] [c000000feee7f860] [c0000000002a0a28]
shrink_page_list+0x948/0x1090
[12292.013702] [c000000feee7f980] [c0000000002a1c8c]
shrink_inactive_list+0x2ec/0x720
[12292.013708] [c000000feee7fa40] [c0000000002a28d8]
shrink_node_memcg+0x238/0x7d0
[12292.013714] [c000000feee7fb40] [c0000000002a2f94]
shrink_node+0x124/0x610
[12292.013720] [c000000feee7fc10] [c0000000002a46d0]
balance_pgdat+0x200/0x460
[12292.013726] [c000000feee7fcf0] [c0000000002a4afc] kswapd+0x1cc/0x5f0
[12292.013732] [c000000feee7fdc0] [c00000000012ca6c]
kthread+0x15c/0x1a0
[12292.013738] [c000000feee7fe30] [c00000000000b65c]
ret_from_kernel_thread+0x5c/0x80
[12292.013743] Instruction dump:
[12292.013748] 1d290064 3c62ffef 3863ab50 e94a0000 7d2407b4 7c845214
4bbbacc9 60000000
[12292.013758] 39200001 3d42003e 912adff8 4bfffe68 <0fe00000> 4bfffdd8
3c4c00b6 38426540
[12292.013769] ---[ end trace 84e4cce770c4d4e3 ]---
[12292.013774] Rebooting in 10 seconds..
Regards,
Venkat.
>
> cheers
^ permalink raw reply
* Re: powerpc: Replaced msleep(x) with msleep(OPAL_BUSY_DELAY_MS)
From: Michael Ellerman @ 2018-07-19 6:07 UTC (permalink / raw)
To: Daniel Klamt, benh
Cc: linux-kernel, linux-kernel, paulus, Daniel Klamt, Bjoern Noetel,
linuxppc-dev
In-Reply-To: <1531346584-9157-1-git-send-email-eleon@ele0n.de>
On Wed, 2018-07-11 at 22:03:04 UTC, Daniel Klamt wrote:
> Replaced msleep(x) with with msleep(OPAL_BUSY_DELAY_MS)
> to diocument these sleep is to wait for opal.
>
> Signed-off-by: Daniel Klamt <eleon@ele0n.de>
> Signed-off-by: Bjoern Noetel <bjoern@br3ak3r.de>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/9c3250a127901c93b23723dc5859c7
cheers
^ permalink raw reply
* Re: [kernel] powerpc/powernv/ioda2: Add 256M IOMMU page size to the default POWER8 case
From: Michael Ellerman @ 2018-07-19 6:07 UTC (permalink / raw)
To: Alexey Kardashevskiy, linuxppc-dev; +Cc: Alexey Kardashevskiy, linux-kernel
In-Reply-To: <20180702074205.12837-1-aik@ozlabs.ru>
On Mon, 2018-07-02 at 07:42:05 UTC, Alexey Kardashevskiy wrote:
> The sketchy bypass uses 256M pages so add this page size as well.
>
> This should cause no behavioral change but will be used later.
>
> Fixes: 477afd6ea6 "powerpc/ioda: Use ibm,supported-tce-sizes for IOMMU page size mask"
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/00c376fdd7ed6cc083da3a3c51a63a
cheers
^ permalink raw reply
* Re: powerpc: Remove Power8 DD1 from cputable
From: Michael Ellerman @ 2018-07-19 6:07 UTC (permalink / raw)
To: Joel Stanley, linuxppc-dev; +Cc: Nicholas Piggin
In-Reply-To: <20180711060258.14448-1-joel@jms.id.au>
On Wed, 2018-07-11 at 06:02:58 UTC, Joel Stanley wrote:
> This was added to support an early version of Power8 that did not have
> working doorbells. These machines were not publicly available, and all of
> the internal users have long since upgraded.
>
> Signed-off-by: Joel Stanley <joel@jms.id.au>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/e11b64b1ef336f8976e5bf194b0eed
cheers
^ permalink raw reply
* Re: powerpc/msi: Remove VLA usage
From: Michael Ellerman @ 2018-07-19 6:07 UTC (permalink / raw)
To: Kees Cook, Benjamin Herrenschmidt
Cc: Rob Herring, Randy Dunlap, linux-kernel, Paul Mackerras,
Tyrel Datwyler, Andrew Morton, linuxppc-dev, Ingo Molnar
In-Reply-To: <20180629185254.GA37557@beast>
On Fri, 2018-06-29 at 18:52:54 UTC, Kees Cook wrote:
> In the quest to remove all stack VLA usage from the kernel[1], this
> switches from an unchanging variable to a constant expression to eliminate
> the VLA generation.
>
> [1] https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qPXydAacU1RqZWA@mail.gmail.com
>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Randy Dunlap <rdunlap@infradead.org>
> Cc: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Ingo Molnar <mingo@kernel.org>
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Kees Cook <keescook@chromium.org>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/1b80ac648483189e45f60d4ddbb54b
cheers
^ permalink raw reply
* Re: powerpc/kdump: handle crashkernel memory reservation failure
From: Michael Ellerman @ 2018-07-19 6:07 UTC (permalink / raw)
To: Hari Bathini; +Cc: linuxppc-dev, Dave Young, Mahesh J Salgaonkar, dgibson
In-Reply-To: <153016319642.8584.7868984232962915832.stgit@hbathini.in.ibm.com>
On Thu, 2018-06-28 at 05:19:56 UTC, Hari Bathini wrote:
> Memory reservation for crashkernel could fail if there are holes around
> kdump kernel offset (128M). Fail gracefully in such cases and print an
> error message.
>
> Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
> Tested-by: David Gibson <dgibson@redhat.com>
> Reviewed-by: Dave Young <dyoung@redhat.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/8950329c4a64c6d3ca0bc34711a1af
cheers
^ permalink raw reply
* Re: [RESEND, 1/3] powerpc: dts: use 'atmel' as at24 anufacturer for pdm360ng
From: Michael Ellerman @ 2018-07-19 6:07 UTC (permalink / raw)
To: Bartosz Golaszewski, Rob Herring, Mark Rutland,
Benjamin Herrenschmidt, Paul Mackerras
Cc: devicetree, Bartosz Golaszewski, linuxppc-dev, linux-kernel
In-Reply-To: <20180621083305.5322-1-brgl@bgdev.pl>
On Thu, 2018-06-21 at 08:33:03 UTC, Bartosz Golaszewski wrote:
> Using 'at' as the <manufacturer> part of the compatible string is now
> deprecated. Use a correct string: 'atmel,<model>'.
>
> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/835b706bab95141e2663b046f2fc59
cheers
^ permalink raw reply
* Re: powerpc: enable kernel XZ compression option on BOOK3S_32
From: Michael Ellerman @ 2018-07-19 6:07 UTC (permalink / raw)
To: Aaro Koskinen, Benjamin Herrenschmidt, Paul Mackerras,
linuxppc-dev
Cc: Aaro Koskinen
In-Reply-To: <20180619205230.19290-1-aaro.koskinen@iki.fi>
On Tue, 2018-06-19 at 20:52:30 UTC, Aaro Koskinen wrote:
> Enable kernel XZ compression option on BOOK3S_32. Tested on G4 PowerBook.
>
> Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/26064848efbca49c643d1237dc1f82
cheers
^ permalink raw reply
* Re: powerpc/64s: Report SLB multi-hit rather than parity error
From: Michael Ellerman @ 2018-07-19 6:07 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev; +Cc: npiggin
In-Reply-To: <20180613132414.32207-1-mpe@ellerman.id.au>
On Wed, 2018-06-13 at 13:24:14 UTC, Michael Ellerman wrote:
> When we take an SLB multi-hit on bare metal, we see both the multi-hit
> and parity error bits set in DSISR. The user manuals indicates this is
> expected to always happen on Power8, whereas on Power9 it says a
> multi-hit will "usually" also cause a parity error.
>
> We decide what to do based on the various error tables in mce_power.c,
> and because we process them in order and only report the first, we
> currently always report a parity error but not the multi-hit, eg:
>
> Severe Machine check interrupt [Recovered]
> Initiator: CPU
> Error type: SLB [Parity]
> Effective address: c000000ffffd4300
>
> Although this is correct, it leaves the user wondering why they got a
> parity error. It would be clearer instead if we reported the
> multi-hit because that is more likely to be simply a software bug,
> whereas a true parity error is possibly an indication of a bad core.
>
> We can do that simply by reordering the error tables so that multi-hit
> appears before parity. That doesn't affect the error recovery at all,
> because we flush the SLB either way.
>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
Applied to powerpc next.
https://git.kernel.org/powerpc/c/54dbcfc211f15586c57d27492f938e
cheers
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox