* Re: [1/1] powerpc/pseries: Enable RAS hotplug events late
From: Michael Ellerman @ 2018-02-14 5:43 UTC (permalink / raw)
To: Sam Bobroff, linuxppc-dev
In-Reply-To: <b3202827b5f22e9a7e8f145f83140698911641f7.1518394650.git.sam.bobroff@au1.ibm.com>
On Mon, 2018-02-12 at 00:19:29 UTC, Sam Bobroff wrote:
> Currently if the kernel receives a memory hot-unplug event early
> enough, it may get stuck in an infinite loop in
> dissolve_free_huge_pages(). This appears as a stall just after:
>
> pseries-hotplug-mem: Attempting to hot-remove XX LMB(s) at YYYYYYYY
>
> It appears to be caused by "minimum_order" being uninitialized, due to
> init_ras_IRQ() executing before hugetlb_init().
>
> To correct this, extract the part of init_ras_IRQ() that enables
> hotplug event processing and place it in the machine_late_initcall
> phase, which is guaranteed to be after hugetlb_init() is called.
>
> Signed-off-by: Sam Bobroff <sam.bobroff@au1.ibm.com>
> Acked-by: Balbir Singh <bsingharora@gmail.com>
Applied to powerpc fixes, thanks.
https://git.kernel.org/powerpc/c/c9dccf1d074a67d36c510845f66398
cheers
^ permalink raw reply
* Re: [V2, 3/4] powerpc/mm/hash64: Store the slot information at the right offset.
From: Michael Ellerman @ 2018-02-14 5:43 UTC (permalink / raw)
To: Aneesh Kumar K.V, benh, paulus, Ram Pai; +Cc: linuxppc-dev, Aneesh Kumar K.V
In-Reply-To: <20180211150009.21297-3-aneesh.kumar@linux.vnet.ibm.com>
On Sun, 2018-02-11 at 15:00:08 UTC, "Aneesh Kumar K.V" wrote:
> The hugetlb pte entries are at the PMD and PUD level. Use the right offset
> for them to get the second half of the table.
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
> Reviewed-by: Ram Pai <linuxram@us.ibm.com>
Applied to powerpc fixes, thanks.
https://git.kernel.org/powerpc/c/ff31e105464d8c8c97301964682702
cheers
^ permalink raw reply
* Re: [kernel, v2] powerpc/mm: Flush radix process translations when setting MMU type
From: Michael Ellerman @ 2018-02-14 5:43 UTC (permalink / raw)
To: Alexey Kardashevskiy, linuxppc-dev; +Cc: Alexey Kardashevskiy
In-Reply-To: <20180201050944.30332-1-aik@ozlabs.ru>
On Thu, 2018-02-01 at 05:09:44 UTC, Alexey Kardashevskiy wrote:
> Radix guests do normally invalidate process-scoped translations when
> a new pid is allocated but migrated guests do not invalidate these so
> migrated guests crash sometime, especially easy to reproduce with
> migration happening within first 10 seconds after the guest boot start on
> the same machine.
>
> This adds the "Invalidate process-scoped translations" flush to fix
> radix guests migration.
>
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> Tested-by: Laurent Vivier <lvivier@redhat.com>
> Tested-by: Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com>
Applied to powerpc fixes, thanks.
https://git.kernel.org/powerpc/c/62e984ddfd6b056d399e24113f5e6a
cheers
^ permalink raw reply
* Re: [V2, 2/4] powerpc/mm/hash64: Allocate larger PMD table if hugetlb config is enabled.
From: Michael Ellerman @ 2018-02-14 5:43 UTC (permalink / raw)
To: Aneesh Kumar K.V, benh, paulus, Ram Pai; +Cc: linuxppc-dev, Aneesh Kumar K.V
In-Reply-To: <20180211150009.21297-2-aneesh.kumar@linux.vnet.ibm.com>
On Sun, 2018-02-11 at 15:00:07 UTC, "Aneesh Kumar K.V" wrote:
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
> Reviewed-by: Ram Pai <linuxram@us.ibm.com>
Applied to powerpc fixes, thanks.
https://git.kernel.org/powerpc/c/4a7aa4fecbbf94b5c6fae8acccc983
cheers
^ permalink raw reply
* Re: [V2,1/4] powerpc/mm: Fix crashes with PUD level hugetlb config
From: Michael Ellerman @ 2018-02-14 5:43 UTC (permalink / raw)
To: Aneesh Kumar K.V, benh, paulus, Ram Pai; +Cc: linuxppc-dev, Aneesh Kumar K.V
In-Reply-To: <20180211150009.21297-1-aneesh.kumar@linux.vnet.ibm.com>
On Sun, 2018-02-11 at 15:00:06 UTC, "Aneesh Kumar K.V" wrote:
> To support memory keys, we moved the hash pte slot information to the second
> half of the page table. This was ok with PTE entries at level 4 and level 3.
> We already allocate larger page table pages at those level to accomodate extra
> details. For level 4 we already have the extra space which was used to track
> 4k hash page table entry details and at pmd level the extra space was allocated
> to track the THP details.
>
> With hugetlbfs PTE, we used this extra space at the PMD level to store the
> slot details. But we also support hugetlbfs PTE at PUD leve and PUD level page
> didn't allocate extra space. This resulted in memory corruption.
>
> Fix this by allocating extra space at PUD level when HUGETLB is enabled. We
> may need further changes to allocate larger space at PMD level when we enable
> HUGETLB. That will be done in next patch.
>
> Fixes:bf9a95f9a6481bc6e(" powerpc: Free up four 64K PTE bits in 64K backed HPTE pages")
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
> Reviewed-by: Ram Pai <linuxram@us.ibm.com>
Applied to powerpc fixes, thanks.
https://git.kernel.org/powerpc/c/fae2211697c9490414e974431051f7
cheers
^ permalink raw reply
* Re: powerpc/vas: do not set uses_vas for kernel windows
From: Michael Ellerman @ 2018-02-14 5:43 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Sukadev Bhattiprolu, Nicholas Piggin
In-Reply-To: <20180208091838.27992-1-npiggin@gmail.com>
On Thu, 2018-02-08 at 09:18:38 UTC, Nicholas Piggin wrote:
> cp_abort is only required or user windows, because kernel context
> must not be preempted between a copy/paste pair.
>
> Without this patch, the init task gets used_vas set when it runs
> the nx842_powernv_init initcall, which opens windows for kernel
> usage.
>
> used_vas is then never cleared anywhere, so it gets propagated
> into all other tasks. It's a property of the address space, so it
> should really be cleared when a new mm is created (or in dup_mmap
> if the mmaps are marked as VM_DONTCOPY). For now we seem to have
> no such driver, so leave that for another patch.
>
> Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> Reviewed-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Applied to powerpc fixes, thanks.
https://git.kernel.org/powerpc/c/b00b62898631b756c3e123542bbb04
cheers
^ permalink raw reply
* Re: 4.16-rc1 virtual machine crash on boot
From: Tyrel Datwyler @ 2018-02-14 5:12 UTC (permalink / raw)
To: Cyril Bur, linuxppc-dev@ozlabs.org, Nathan Fontenot,
Michael Ellerman
In-Reply-To: <1518571241.9595.4.camel@gmail.com>
On 02/13/2018 05:20 PM, Cyril Bur wrote:
> Hello all,
Does reverting commit 02ef6dd8109b581343ebeb1c4c973513682535d6 alleviate the issue?
-Tyrel
>
> I'm seeing this crash trying to boot a KVM virtual machine. This kernel
> was compiled with pseries_le_defconfig and run using the following qemu
> commandline:
>
> qemu-system-ppc64 -enable-kvm -cpu POWER8 -smp 4 -m 4G -M pseries
> -nographic -vga none -drive file=vm.raw,if=virtio,format=raw -drive
> file=mkvmconf2xeO,if=virtio,format=raw -netdev type=user,id=net0
> -device virtio-net-pci,netdev=net0 -kernel vmlinux_tscr -append
> 'root=/dev/vdb1 rw cloud-init=disabled'
>
> qemu-system-ppc64 --version
> QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.16), Copyright
> (c) 2003-2008 Fabrice Bellard
>
>
> Key type dns_resolver registered
> Unable to handle kernel paging request for data at address 0x00000010
> Faulting instruction address: 0xc0000000018f2bbc
> Oops: Kernel access of bad area, sig: 11 [#1]
> LE SMP NR_CPUS=2048 NUMA pSeries
> CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.16.0-rc1v4.16-rc1 #8
> NIP: c0000000018f2bbc LR: c0000000018f2bb4 CTR: 0000000000000000
> REGS: c0000000fea838d0 TRAP: 0380 Not tainted (4.16.0-rc1v4.16-rc1)
> MSR: 8000000002009033 <SF,VEC,EE,ME,IR,DR,RI,LE> CR: 84000248 XER:
> 20000000
> CFAR: c0000000019591a0 SOFTE: 0
> GPR00: c0000000018f2bb4 c0000000fea83b50 c000000001bd8400
> 0000000000000000
> GPR04: c0000000fea83b70 0000000000000000 000000000000002f
> 0000000000000022
> GPR08: 0000000000000000 c0000000022a3e90 0000000000000000
> 0000000000000220
> GPR12: 0000000000000000 c00000000fb40980 c00000000000d698
> 0000000000000000
> GPR16: 0000000000000000 0000000000000000 0000000000000000
> 0000000000000000
> GPR20: 0000000000000000 0000000000000000 0000000000000000
> 0000000000000000
> GPR24: 0000000000000000 c0000000018b9248 c0000000018e36d8
> c0000000019738a8
> GPR28: 0000000000000007 c0000000fffffc68 c0000000fea83bf0
> 0000000000000010
> NIP [c0000000018f2bbc] read_drconf_v1_cell+0x50/0x9c
> LR [c0000000018f2bb4] read_drconf_v1_cell+0x48/0x9c
> Call Trace:
> [c0000000fea83b50] [c0000000018f2bb4] read_drconf_v1_cell+0x48/0x9c
> (unreliable)
> [c0000000fea83b90] [c0000000018f305c] drmem_init+0x13c/0x2ec
> [c0000000fea83c40] [c0000000018e4288] do_one_initcall+0xdc/0x1ac
> [c0000000fea83d00] [c0000000018e45d4] kernel_init_freeable+0x27c/0x358
> [c0000000fea83dc0] [c00000000000d6bc] kernel_init+0x2c/0x160
> [c0000000fea83e30] [c00000000000bc20] ret_from_kernel_thread+0x5c/0xbc
> Instruction dump:
> 7c7f1b78 60000000 60000000 7c240b78 3d22ffdc 3929f0a4 e95e0000
> e8690002
> f9440021 4806657d 60000000 e9210020 <f87f0000> 39090004 39490010
> f9010020
> ---[ end trace bd9f49f482d30e03 ]---
>
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
>
> WARNING: CPU: 1 PID: 1 at drivers/tty/vt/vt.c:3883
> do_unblank_screen+0x1f0/0x270
> CPU: 1 PID: 1 Comm: swapper/0 Tainted: G D 4.16.0-
> rc1v4.16-rc1 #8
> NIP: c0000000009aa800 LR: c0000000009aa63c CTR: c00000000148f5f0
> REGS: c0000000fea832c0 TRAP: 0700 Tainted:
> G D (4.16.0-rc1v4.16-rc1)
> MSR: 8000000002029033 <SF,VEC,EE,ME,IR,DR,RI,LE> CR: 28002222 XER:
> 20000000
> CFAR: c0000000009aa658 SOFTE: 1
> GPR00: c0000000009aa63c c0000000fea83540 c000000001bd8400
> 0000000000000000
> GPR04: 0000000000000001 c0000000fb0c200e 0000000000001dd7
> c0000000fea834d0
> GPR08: 00000000fe430000 0000000000000000 0000000000000000
> 0000000000000001
> GPR12: 0000000028002428 c00000000fb40980 c00000000000d698
> 0000000000000000
> GPR16: 0000000000000000 0000000000000000 0000000000000000
> 0000000000000000
> GPR20: 0000000000000000 0000000000000000 0000000000000000
> 0000000000000000
> GPR24: c0000000fea40000 c0000000feadf910 c000000001a4a7a8
> c000000001cc4ea0
> GPR28: c00000000173f4f0 c000000001cc4ec8 0000000000000000
> 0000000000000000
> NIP [c0000000009aa800] do_unblank_screen+0x1f0/0x270
> LR [c0000000009aa63c] do_unblank_screen+0x2c/0x270
> Call Trace:
> [c0000000fea83540] [c0000000009aa63c] do_unblank_screen+0x2c/0x270
> (unreliable)
> [c0000000fea835b0] [c0000000008a2a70] bust_spinlocks+0x40/0x80
> [c0000000fea835d0] [c0000000000da90c] panic+0x1b8/0x32c
> [c0000000fea83670] [c0000000000e1bd4] do_exit+0xcb4/0xcc0
> [c0000000fea83730] [c0000000000275fc] die+0x29c/0x450
> [c0000000fea837c0] [c000000000053f88] bad_page_fault+0xe8/0x160
> [c0000000fea83830] [c000000000028a90] slb_miss_bad_addr+0x40/0x90
> [c0000000fea83860] [c000000000008b08] bad_addr_slb+0x158/0x160
> --- interrupt: 380 at read_drconf_v1_cell+0x50/0x9c
> LR = read_drconf_v1_cell+0x48/0x9c
> [c0000000fea83b90] [c0000000018f305c] drmem_init+0x13c/0x2ec
> [c0000000fea83c40] [c0000000018e4288] do_one_initcall+0xdc/0x1ac
> [c0000000fea83d00] [c0000000018e45d4] kernel_init_freeable+0x27c/0x358
> [c0000000fea83dc0] [c00000000000d6bc] kernel_init+0x2c/0x160
> [c0000000fea83e30] [c00000000000bc20] ret_from_kernel_thread+0x5c/0xbc
> Instruction dump:
> 3c62ffbf 38840001 7c8407b4 38639ca8 4b7ae0ed 60000000 38210070
> e8010010
> ebc1fff0 ebe1fff8 7c0803a6 4e800020 <0fe00000> 4bfffe58 60000000
> 60420000
> ---[ end trace bd9f49f482d30e04 ]---
> Rebooting in 10 seconds..
>
^ permalink raw reply
* Re: [PATCH] powerpc/npu-dma.c: Fix deadlock in mmio_invalidate
From: Alistair Popple @ 2018-02-14 3:23 UTC (permalink / raw)
To: Balbir Singh; +Cc: mpe, linuxppc-dev, Mark Hairgrove, Javier Cabezas
In-Reply-To: <20180213170620.409daf29@balbir.ozlabs.ibm.com>
> > +struct mmio_atsd_reg {
> > + struct npu *npu;
> > + int reg;
> > +};
> > +
>
> Is it just easier to move reg to inside of struct npu?
I don't think so, struct npu is global to all npu contexts where as this is
specific to the given invalidation. We don't have enough registers to assign
each NPU context it's own dedicated register so I'm not sure it makes sense to
put it there either.
> > +static void acquire_atsd_reg(struct npu_context *npu_context,
> > + struct mmio_atsd_reg mmio_atsd_reg[NV_MAX_NPUS])
> > +{
> > + int i, j;
> > + struct npu *npu;
> > + struct pci_dev *npdev;
> > + struct pnv_phb *nphb;
> >
> > - /*
> > - * The GPU requires two flush ATSDs to ensure all entries have
> > - * been flushed. We use PID 0 as it will never be used for a
> > - * process on the GPU.
> > - */
> > - if (flush)
> > - mmio_invalidate_pid(npu, 0, true);
> > + for (i = 0; i <= max_npu2_index; i++) {
> > + mmio_atsd_reg[i].reg = -1;
> > + for (j = 0; j < NV_MAX_LINKS; j++) {
>
> Is it safe to assume that npu_context->npdev will not change in this
> loop? I guess it would need to be stronger than just this loop.
It is not safe to assume that npu_context->npdev won't change during this loop,
however I don't think it is a problem if it does as we only read each element
once during the invalidation.
There are two possibilities for how this could change. pnv_npu2_init_context()
will add a nvlink to the npdev which will result in the TLB invalidation being
sent to that GPU as well which should not be a problem.
pnv_npu2_destroy_context() will remove the the nvlink from npdev. If it happens
prior to this loop it should not be a problem (as the destruction will have
already invalidated the GPU TLB). If it happens after this loop it shouldn't be
a problem either (it will just result in an extra TLB invalidate being sent to
this GPU).
> > + npdev = npu_context->npdev[i][j];
> > + if (!npdev)
> > + continue;
> > +
> > + nphb = pci_bus_to_host(npdev->bus)->private_data;
> > + npu = &nphb->npu;
> > + mmio_atsd_reg[i].npu = npu;
> > + mmio_atsd_reg[i].reg = get_mmio_atsd_reg(npu);
> > + while (mmio_atsd_reg[i].reg < 0) {
> > + mmio_atsd_reg[i].reg = get_mmio_atsd_reg(npu);
> > + cpu_relax();
>
> A cond_resched() as well if we have too many tries?
I don't think we can as the invalidate_range() function is called under the ptl
spin-lock and is not allowed to sleep (at least according to
include/linux/mmu_notifier.h).
- Alistair
> Balbir
>
^ permalink raw reply
* [PATCH] powerpc: Expose TSCR via sysfs only on powernv
From: Cyril Bur @ 2018-02-14 3:27 UTC (permalink / raw)
To: linuxppc-dev
The TSCR can only be accessed in hypervisor mode.
Fixes: 88b5e12eeb11 ("powerpc: Expose TSCR via sysfs")
Signed-off-by: Cyril Bur <cyrilbur@gmail.com>
---
arch/powerpc/kernel/sysfs.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
index 5a8bfee6e187..04d0bbd7a1dd 100644
--- a/arch/powerpc/kernel/sysfs.c
+++ b/arch/powerpc/kernel/sysfs.c
@@ -788,7 +788,8 @@ static int register_cpu_online(unsigned int cpu)
if (cpu_has_feature(CPU_FTR_PPCAS_ARCH_V2))
device_create_file(s, &dev_attr_pir);
- if (cpu_has_feature(CPU_FTR_ARCH_206))
+ if (cpu_has_feature(CPU_FTR_ARCH_206) &&
+ !firmware_has_feature(FW_FEATURE_LPAR))
device_create_file(s, &dev_attr_tscr);
#endif /* CONFIG_PPC64 */
@@ -873,7 +874,8 @@ static int unregister_cpu_online(unsigned int cpu)
if (cpu_has_feature(CPU_FTR_PPCAS_ARCH_V2))
device_remove_file(s, &dev_attr_pir);
- if (cpu_has_feature(CPU_FTR_ARCH_206))
+ if (cpu_has_feature(CPU_FTR_ARCH_206) &&
+ !firmware_has_feature(FW_FEATURE_LPAR))
device_remove_file(s, &dev_attr_tscr);
#endif /* CONFIG_PPC64 */
--
2.16.1
^ permalink raw reply related
* Re: [PATCH 1/2] powerpc/kdump: Add missing optional dummy functions
From: Balbir Singh @ 2018-02-14 2:32 UTC (permalink / raw)
To: Guenter Roeck
Cc: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
linux-kernel@vger.kernel.org, Nicholas Piggin
In-Reply-To: <20180212232551.GA5199@roeck-us.net>
On Mon, 12 Feb 2018 15:25:51 -0800
Guenter Roeck <linux@roeck-us.net> wrote:
> On Tue, Feb 13, 2018 at 10:01:57AM +1100, Balbir Singh wrote:
> > On Tue, Feb 13, 2018 at 9:34 AM, Guenter Roeck <linux@roeck-us.net> wrote:
> > > If KEXEC_CORE is not enabled, PowerNV builds fail as follows.
> > >
> > > arch/powerpc/platforms/powernv/smp.c: In function 'pnv_smp_cpu_kill_self':
> > > arch/powerpc/platforms/powernv/smp.c:236:4: error:
> > > implicit declaration of function 'crash_ipi_callback'
> > >
> > > Add dummy function calls, similar to kdump_in_progress(), to solve the
> > > problem.
> > >
> > > Fixes: 4145f358644b ("powernv/kdump: Fix cases where the kdump kernel ...")
> > > Cc: Balbir Singh <bsingharora@gmail.com>
> > > Cc: Michael Ellerman <mpe@ellerman.id.au>
> > > Cc: Nicholas Piggin <npiggin@gmail.com>
> > > Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> > > ---
> >
> > Thanks for working on this.
> >
> > You've added two functions, I understand the crash_send_ipi() bits
> > that I broke. Looks like crash_ipi_callback broken without KEXEC_CORE?
> >
>
> If I recall correctly, 4145f358644b introduced the call to crash_ipi_callback().
> After I declared the dummy function for that, I got an error about the missing
> crash_send_ipi(). I didn't spend more time on it but just added another dummy
> function. It may well be that another problem was introduced in the same time
> frame. On the other side, maybe I got it all wrong, and my patch is not worth
> the computer it was written on.
>
The patches worked for me with CONFIG_KEXEC=n and CONFIG_KEXEC_CORE=n
Tested-by: Balbir Singh <bsingharora@gmail.com>
Balbir Singh
^ permalink raw reply
* Re: [PATCH v2] mm: hwpoison: disable memory error handling on 1GB hugepage
From: Mike Kravetz @ 2018-02-13 22:33 UTC (permalink / raw)
To: Michael Ellerman, Andrew Morton, Punit Agrawal
Cc: Naoya Horiguchi, linux-mm@kvack.org, Michal Hocko,
Aneesh Kumar K.V, Anshuman Khandual, linux-kernel@vger.kernel.org,
Benjamin Herrenschmidt, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <87wozhvc49.fsf@concordia.ellerman.id.au>
On 02/12/2018 06:48 PM, Michael Ellerman wrote:
> Andrew Morton <akpm@linux-foundation.org> writes:
>
>> On Thu, 08 Feb 2018 12:30:45 +0000 Punit Agrawal <punit.agrawal@arm.com> wrote:
>>
>>>>
>>>> So I don't think that the above test result means that errors are properly
>>>> handled, and the proposed patch should help for arm64.
>>>
>>> Although, the deviation of pud_huge() avoids a kernel crash the code
>>> would be easier to maintain and reason about if arm64 helpers are
>>> consistent with expectations by core code.
>>>
>>> I'll look to update the arm64 helpers once this patch gets merged. But
>>> it would be helpful if there was a clear expression of semantics for
>>> pud_huge() for various cases. Is there any version that can be used as
>>> reference?
>>
>> Is that an ack or tested-by?
>>
>> Mike keeps plaintively asking the powerpc developers to take a look,
>> but they remain steadfastly in hiding.
>
> Cc'ing linuxppc-dev is always a good idea :)
>
Thanks Michael,
I was mostly concerned about use cases for soft/hard offline of huge pages
larger than PMD_SIZE on powerpc. I know that powerpc supports PGD_SIZE
huge pages, and soft/hard offline support was specifically added for this.
See, 94310cbcaa3c "mm/madvise: enable (soft|hard) offline of HugeTLB pages
at PGD level"
This patch will disable that functionality. So, at a minimum this is a
'heads up'. If there are actual use cases that depend on this, then more
work/discussions will need to happen. From the e-mail thread on PGD_SIZE
support, I can not tell if there is a real use case or this is just a
'nice to have'.
--
Mike Kravetz
>> Folks, this patch fixes a BUG and is marked for -stable. Can we please
>> prioritize it?
>
> It's not crashing for me (on 4.16-rc1):
>
> # ./huge-poison
> Poisoning page...once
> Poisoning page...once again
> madvise: Bad address
>
> And I guess the above is the expected behaviour?
>
> Looking at the function trace it looks like the 2nd madvise is going
> down reasonable code paths, but I don't know for sure:
>
> 8) | SyS_madvise() {
> 8) | capable() {
> 8) | ns_capable_common() {
> 8) 0.094 us | cap_capable();
> 8) 0.516 us | }
> 8) 1.052 us | }
> 8) | get_user_pages_fast() {
> 8) 0.354 us | gup_pgd_range();
> 8) | get_user_pages_unlocked() {
> 8) 0.050 us | down_read();
> 8) | __get_user_pages() {
> 8) | find_extend_vma() {
> 8) | find_vma() {
> 8) 0.148 us | vmacache_find();
> 8) 0.622 us | }
> 8) 1.064 us | }
> 8) 0.028 us | arch_vma_access_permitted();
> 8) | follow_hugetlb_page() {
> 8) | huge_pte_offset() {
> 8) 0.128 us | __find_linux_pte();
> 8) 0.580 us | }
> 8) 0.048 us | _raw_spin_lock();
> 8) | hugetlb_fault() {
> 8) | huge_pte_offset() {
> 8) 0.034 us | __find_linux_pte();
> 8) 0.434 us | }
> 8) 0.028 us | is_hugetlb_entry_migration();
> 8) 0.032 us | is_hugetlb_entry_hwpoisoned();
> 8) 2.118 us | }
> 8) 4.940 us | }
> 8) 7.468 us | }
> 8) 0.056 us | up_read();
> 8) 8.722 us | }
> 8) + 10.264 us | }
> 8) + 12.212 us | }
>
>
> cheers
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
>
^ permalink raw reply
* 4.16-rc1 virtual machine crash on boot
From: Cyril Bur @ 2018-02-14 1:20 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org, Nathan Fontenot, Michael Ellerman
Hello all,
I'm seeing this crash trying to boot a KVM virtual machine. This kernel
was compiled with pseries_le_defconfig and run using the following qemu
commandline:
qemu-system-ppc64 -enable-kvm -cpu POWER8 -smp 4 -m 4G -M pseries
-nographic -vga none -drive file=vm.raw,if=virtio,format=raw -drive
file=mkvmconf2xeO,if=virtio,format=raw -netdev type=user,id=net0
-device virtio-net-pci,netdev=net0 -kernel vmlinux_tscr -append
'root=/dev/vdb1 rw cloud-init=disabled'
qemu-system-ppc64 --version
QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.16), Copyright
(c) 2003-2008 Fabrice Bellard
Key type dns_resolver registered
Unable to handle kernel paging request for data at address 0x00000010
Faulting instruction address: 0xc0000000018f2bbc
Oops: Kernel access of bad area, sig: 11 [#1]
LE SMP NR_CPUS=2048 NUMA pSeries
CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.16.0-rc1v4.16-rc1 #8
NIP: c0000000018f2bbc LR: c0000000018f2bb4 CTR: 0000000000000000
REGS: c0000000fea838d0 TRAP: 0380 Not tainted (4.16.0-rc1v4.16-rc1)
MSR: 8000000002009033 <SF,VEC,EE,ME,IR,DR,RI,LE> CR: 84000248 XER:
20000000
CFAR: c0000000019591a0 SOFTE: 0
GPR00: c0000000018f2bb4 c0000000fea83b50 c000000001bd8400
0000000000000000
GPR04: c0000000fea83b70 0000000000000000 000000000000002f
0000000000000022
GPR08: 0000000000000000 c0000000022a3e90 0000000000000000
0000000000000220
GPR12: 0000000000000000 c00000000fb40980 c00000000000d698
0000000000000000
GPR16: 0000000000000000 0000000000000000 0000000000000000
0000000000000000
GPR20: 0000000000000000 0000000000000000 0000000000000000
0000000000000000
GPR24: 0000000000000000 c0000000018b9248 c0000000018e36d8
c0000000019738a8
GPR28: 0000000000000007 c0000000fffffc68 c0000000fea83bf0
0000000000000010
NIP [c0000000018f2bbc] read_drconf_v1_cell+0x50/0x9c
LR [c0000000018f2bb4] read_drconf_v1_cell+0x48/0x9c
Call Trace:
[c0000000fea83b50] [c0000000018f2bb4] read_drconf_v1_cell+0x48/0x9c
(unreliable)
[c0000000fea83b90] [c0000000018f305c] drmem_init+0x13c/0x2ec
[c0000000fea83c40] [c0000000018e4288] do_one_initcall+0xdc/0x1ac
[c0000000fea83d00] [c0000000018e45d4] kernel_init_freeable+0x27c/0x358
[c0000000fea83dc0] [c00000000000d6bc] kernel_init+0x2c/0x160
[c0000000fea83e30] [c00000000000bc20] ret_from_kernel_thread+0x5c/0xbc
Instruction dump:
7c7f1b78 60000000 60000000 7c240b78 3d22ffdc 3929f0a4 e95e0000
e8690002
f9440021 4806657d 60000000 e9210020 <f87f0000> 39090004 39490010
f9010020
---[ end trace bd9f49f482d30e03 ]---
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
WARNING: CPU: 1 PID: 1 at drivers/tty/vt/vt.c:3883
do_unblank_screen+0x1f0/0x270
CPU: 1 PID: 1 Comm: swapper/0 Tainted: G D 4.16.0-
rc1v4.16-rc1 #8
NIP: c0000000009aa800 LR: c0000000009aa63c CTR: c00000000148f5f0
REGS: c0000000fea832c0 TRAP: 0700 Tainted:
G D (4.16.0-rc1v4.16-rc1)
MSR: 8000000002029033 <SF,VEC,EE,ME,IR,DR,RI,LE> CR: 28002222 XER:
20000000
CFAR: c0000000009aa658 SOFTE: 1
GPR00: c0000000009aa63c c0000000fea83540 c000000001bd8400
0000000000000000
GPR04: 0000000000000001 c0000000fb0c200e 0000000000001dd7
c0000000fea834d0
GPR08: 00000000fe430000 0000000000000000 0000000000000000
0000000000000001
GPR12: 0000000028002428 c00000000fb40980 c00000000000d698
0000000000000000
GPR16: 0000000000000000 0000000000000000 0000000000000000
0000000000000000
GPR20: 0000000000000000 0000000000000000 0000000000000000
0000000000000000
GPR24: c0000000fea40000 c0000000feadf910 c000000001a4a7a8
c000000001cc4ea0
GPR28: c00000000173f4f0 c000000001cc4ec8 0000000000000000
0000000000000000
NIP [c0000000009aa800] do_unblank_screen+0x1f0/0x270
LR [c0000000009aa63c] do_unblank_screen+0x2c/0x270
Call Trace:
[c0000000fea83540] [c0000000009aa63c] do_unblank_screen+0x2c/0x270
(unreliable)
[c0000000fea835b0] [c0000000008a2a70] bust_spinlocks+0x40/0x80
[c0000000fea835d0] [c0000000000da90c] panic+0x1b8/0x32c
[c0000000fea83670] [c0000000000e1bd4] do_exit+0xcb4/0xcc0
[c0000000fea83730] [c0000000000275fc] die+0x29c/0x450
[c0000000fea837c0] [c000000000053f88] bad_page_fault+0xe8/0x160
[c0000000fea83830] [c000000000028a90] slb_miss_bad_addr+0x40/0x90
[c0000000fea83860] [c000000000008b08] bad_addr_slb+0x158/0x160
--- interrupt: 380 at read_drconf_v1_cell+0x50/0x9c
LR = read_drconf_v1_cell+0x48/0x9c
[c0000000fea83b90] [c0000000018f305c] drmem_init+0x13c/0x2ec
[c0000000fea83c40] [c0000000018e4288] do_one_initcall+0xdc/0x1ac
[c0000000fea83d00] [c0000000018e45d4] kernel_init_freeable+0x27c/0x358
[c0000000fea83dc0] [c00000000000d6bc] kernel_init+0x2c/0x160
[c0000000fea83e30] [c00000000000bc20] ret_from_kernel_thread+0x5c/0xbc
Instruction dump:
3c62ffbf 38840001 7c8407b4 38639ca8 4b7ae0ed 60000000 38210070
e8010010
ebc1fff0 ebe1fff8 7c0803a6 4e800020 <0fe00000> 4bfffe58 60000000
60420000
---[ end trace bd9f49f482d30e04 ]---
Rebooting in 10 seconds..
^ permalink raw reply
* Re: [PATCH] headers: untangle kmemleak.h from mm.h
From: Randy Dunlap @ 2018-02-14 0:48 UTC (permalink / raw)
To: Ingo Molnar
Cc: LKML, Linux MM, Andrew Morton, Fengguang Wu, iommu, linuxppc-dev,
linux-s390, sparclinux, X86 ML, netdev@vger.kernel.org,
linux-wireless, virtualization, John Johansen, Greg Kroah-Hartman
In-Reply-To: <20180212072727.saupl35jvwex6hbe@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1830 bytes --]
On 02/11/2018 11:27 PM, Ingo Molnar wrote:
>
> * Randy Dunlap <rdunlap@infradead.org> wrote:
>
>> From: Randy Dunlap <rdunlap@infradead.org>
>>
>> Currently <linux/slab.h> #includes <linux/kmemleak.h> for no obvious
>> reason. It looks like it's only a convenience, so remove kmemleak.h
>> from slab.h and add <linux/kmemleak.h> to any users of kmemleak_*
>> that don't already #include it.
>> Also remove <linux/kmemleak.h> from source files that do not use it.
>>
>> This is tested on i386 allmodconfig and x86_64 allmodconfig. It
>> would be good to run it through the 0day bot for other $ARCHes.
>> I have neither the horsepower nor the storage space for the other
>> $ARCHes.
>>
>> [slab.h is the second most used header file after module.h; kernel.h
>> is right there with slab.h. There could be some minor error in the
>> counting due to some #includes having comments after them and I
>> didn't combine all of those.]
>>
>> This is Lingchi patch #1 (death by a thousand cuts, applied to kernel
>> header files).
>>
>> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
>
> Nice find:
>
> Reviewed-by: Ingo Molnar <mingo@kernel.org>
>
> I agree that it needs to go through 0-day to find any hidden dependencies we might
> have grown due to this.
Andrew,
This patch has mostly survived both 0day and ozlabs multi-arch testing with
2 build errors being reported by both of them. I have posted patches for
those separately. (and are attached here)
other-patch-1:
lkml.kernel.org/r/5664ced1-a0cd-7e4e-71b6-9c3a97d68927@infradead.org
"lib/test_firmware: add header file to prevent build errors"
other-patch-2:
lkml.kernel.org/r/b3b7eebb-0e9f-f175-94a8-379c5ddcaa86@infradead.org
"integrity/security: fix digsig.c build error"
Will you see that these are merged or do you want me to repost them?
thanks,
--
~Randy
[-- Attachment #2: integrity_security_digsig_add_header.patch --]
[-- Type: text/x-patch, Size: 872 bytes --]
From: Randy Dunlap <rdunlap@infradead.org>
security/integrity/digsig.c has build errors on some $ARCH due to a
missing header file, so add it.
security/integrity/digsig.c:146:2: error: implicit declaration of function 'vfree' [-Werror=implicit-function-declaration]
Reported-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Mimi Zohar <zohar@linux.vnet.ibm.com>
Cc: linux-integrity@vger.kernel.org
Link: http://kisskb.ellerman.id.au/kisskb/head/13396/
---
security/integrity/digsig.c | 1 +
1 file changed, 1 insertion(+)
--- lnx-416-rc1.orig/security/integrity/digsig.c
+++ lnx-416-rc1/security/integrity/digsig.c
@@ -18,6 +18,7 @@
#include <linux/cred.h>
#include <linux/key-type.h>
#include <linux/digsig.h>
+#include <linux/vmalloc.h>
#include <crypto/public_key.h>
#include <keys/system_keyring.h>
[-- Attachment #3: lib_test_firmware_add_header_file.patch --]
[-- Type: text/x-patch, Size: 1024 bytes --]
From: Randy Dunlap <rdunlap@infradead.org>
lib/test_firmware.c has build errors on some $ARCH due to a
missing header file, so add it.
lib/test_firmware.c:134:2: error: implicit declaration of function 'vfree' [-Werror=implicit-function-declaration]
lib/test_firmware.c:620:25: error: implicit declaration of function 'vzalloc' [-Werror=implicit-function-declaration]
Reported-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Wei Yongjun <weiyongjun1@huawei.com>
Cc: Luis R. Rodriguez <mcgrof@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: http://kisskb.ellerman.id.au/kisskb/head/13396/
---
lib/test_firmware.c | 1 +
1 file changed, 1 insertion(+)
--- lnx-416-rc1.orig/lib/test_firmware.c
+++ lnx-416-rc1/lib/test_firmware.c
@@ -21,6 +21,7 @@
#include <linux/uaccess.h>
#include <linux/delay.h>
#include <linux/kthread.h>
+#include <linux/vfree.h>
#define TEST_FIRMWARE_NAME "test-firmware.bin"
#define TEST_FIRMWARE_NUM_REQS 4
^ permalink raw reply
* (no subject)
From: Shan Hai @ 2018-02-13 23:05 UTC (permalink / raw)
To: linuxppc-dev
confirm 179e695f420474677205db49a8cbfe950329975c
^ permalink raw reply
* (no subject)
From: Shan Hai @ 2018-02-13 23:03 UTC (permalink / raw)
To: linuxppc-dev
confirm 0da5e6b1343dcc6395ebcc8054c362d930498440
^ permalink raw reply
* Re: [PATCH] powerpc/xmon: Dont register sysrq key when kernel param xmon=off
From: Balbir Singh @ 2018-02-13 22:01 UTC (permalink / raw)
To: Vaibhav Jain
Cc: open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
linux-kernel@vger.kernel.org, Benjamin Herrenschmidt,
Paul Mackerras, Michael Ellerman, Nicholas Piggin, Douglas Miller,
Pan Xinhui
In-Reply-To: <8737264c91.fsf@vajain21.in.ibm.com>
On Mon, Feb 12, 2018 at 11:35 PM, Vaibhav Jain
<vaibhav@linux.vnet.ibm.com> wrote:
> Thanks for reviewing this patch Balbir
>
> Balbir Singh <bsingharora@gmail.com> writes:
>
>> Any specific issue you've run into without this patch?
> Without this patch since xmon is still accessible via sysrq and there is
> no indication/warning on the xmon console mentioning that its is not
> fully functional. Specifically xmon-console would still allow user to
> set instruction/data breakpoint eventhough they wont work and will
> result in a kernel-oops.
>
> Below is command log illustrating this problem on one of my test system
> where I tried setting an instruction breakpoint on cmdline_proc_show()
> with xmon=off:
>
> ~# cat /proc/cmdline
> root=UUID=248ad10e-a272-4187-8672-5b25f701e8b9 ro xmon=off
>
> ~# echo 'x' > /proc/sysrq-trigger
> [ 458.904802] sysrq: SysRq : Entering xmon
>
> [ snip ]
>
> 78:mon> ls cmdline_proc_show
> cmdline_proc_show: c0000000004196e0
> 78:mon> bi c0000000004196e0
> 78:mon> x
>
> ~# cat /proc/cmdline
> [ 505.618702] Oops: Exception in kernel mode, sig: 5 [#1]
> [ snip ]
> [ 505.620082] NIP [c0000000004196e4] cmdline_proc_show+0x4/0x60
> [ 505.620136] LR [c0000000003b1db0] seq_read+0x130/0x5e0
> [ 505.620177] Call Trace:
> [ 505.620202] [c000200e5078fc00] [c0000000003b1d74] seq_read+0xf4/0x5e0 (unreliable)
> [ 505.620267] [c000200e5078fca0] [c00000000040cae0] proc_reg_read+0xb0/0x110
> [ 505.620322] [c000200e5078fcf0] [c00000000037687c] __vfs_read+0x6c/0x1b0
> [ 505.620376] [c000200e5078fd90] [c000000000376a7c] vfs_read+0xbc/0x1b0
> [ 505.620430] [c000200e5078fde0] [c00000000037724c] SyS_read+0x6c/0x110
> [ 505.620485] [c000200e5078fe30] [c00000000000b320] system_call+0x58/0x6c
> [ 505.620536] Instruction dump:
> [ 505.620570] 3c82ff2a 7fe3fb78 38a00000 3884dee0 4bf98c05 60000000 38210030 e8010010
> [ 505.620656] ebe1fff8 7c0803a6 4e800020 3c4c00d6 <38422120> 7c0802a6 f8010010 f821ff91
> [ 505.620728] ---[ end trace eaf583921860b3de ]---
> [ 506.629019]
> Trace/breakpoint trap
> ~#
>
>
>> I presume running xmon=off indicates we don't want xmon to take over in case of
>> panic/die/oops,
> I believe that when xmon console is available it should be fully
> functional rather than partially, otherwise it gets really confusing to
> the user as to why Instruction/Data break points arent working.
>
OK, so kernel breakpoints are broken with xmon=off and lead to oops as
opposed to passing them on to a kprobe handler perhaps?
Balbir Singh.
^ permalink raw reply
* Re: samples/seccomp/ broken when cross compiling s390, ppc allyesconfig
From: Kees Cook @ 2018-02-13 21:27 UTC (permalink / raw)
To: Michal Hocko; +Cc: Michael Ellerman, Will Drewry, linux-s390, PowerPC, LKML
In-Reply-To: <20180213103213.GP3443@dhcp22.suse.cz>
On Tue, Feb 13, 2018 at 2:32 AM, Michal Hocko <mhocko@kernel.org> wrote:
> On Tue 13-02-18 21:16:55, Michael Ellerman wrote:
>> Kees Cook <keescook@chromium.org> writes:
>>
>> > On Mon, Feb 12, 2018 at 7:25 PM, Michael Ellerman <mpe@ellerman.id.au> wrote:
>> >> Michal Hocko <mhocko@kernel.org> writes:
>> >>> Hi,
>> >>> my build test machinery chokes on samples/seccomp when cross compiling
>> >>> s390 and ppc64 allyesconfig. This has been the case for quite some
>> >>> time already but I never found time to look at the problem and report
>> >>> it. It seems this is not new issue and similar thing happend for
>> >>> MIPS e9107f88c985 ("samples/seccomp/Makefile: do not build tests if
>> >>> cross-compiling for MIPS").
>> >>>
>> >>> The build logs are attached.
>> >>>
>> >>> What is the best way around this? Should we simply skip compilation on
>> >>> cross compile or is actually anybody relying on that? Or should I simply
>> >>> disable it for s390 and ppc?
>> >>
>> >> The whole thing seems very confused. It's not building for the target,
>> >> it's building for the host, ie. the Makefile sets hostprogs-m and
>> >> HOSTCFLAGS etc.
>> >>
>> >> So it can't possibly work with cross compiling as it's currently
>> >> written.
>> >>
>> >> Either the Makefile needs some serious work to properly support cross
>> >> compiling or it should just be disabled when cross compiling.
>> >
>> > Hrm, yeah, the goal was to entirely disable cross compiling, but I
>> > guess we didn't hit it with a hard enough hammer. :)
>>
>> Do you know why it is written that way? Why doesn't it just try to cross
>> compile like normal code?
>
> No idea, sorry. All I know about this code is that it breaks my build
> testing.
IIRC, one of the problems is with build ordering problems: the kernel
headers used by the samples aren't available when cross compiling.
I'm happy to kill it entirely with Michal's patch, though. Feel free
to carry in your tree!
Acked-by: Kees Cook <keescook@chromium.org>
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply
* [PATCH] powerpc: Revert support for ibm,drc-info devtree property
From: Michael Bringmann @ 2018-02-13 20:02 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Michael Bringmann, Nathan Fontenot, Michael Ellerman
This reverts commit 02ef6dd8109b581343ebeb1c4c973513682535d6.
The earlier patch tried to enable support for a new property
"ibm,drc-info" on powerpc systems.
Unfortunately, some errors in the associated patch set break things
in some of the DLPAR operations. In particular when attempting to
hot-add a new CPU or set of CPUs, the original patch failed to
properly calculate the available resources, and aborted the operation.
In addition, the original set missed several opportunities to compress
and reuse common code.
As the associated patch set was meant to provide an optimization of
storage and performance of a set of device-tree properties for future
systems with large amounts of resources, reverting just restores
the previous behavior for existing systems. It seems unnecessary
to enable this feature and introduce the consequent problems in the
field that it will cause at this time, so please revert it for now
until testing of the corrections are finished properly.
Signed-off-by: Michael W. Bringmann <mwb@linux.vnet.ibm.com>
---
arch/powerpc/kernel/prom_init.c | 1 +
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index adf044d..d22c41c 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -874,7 +874,7 @@ struct ibm_arch_vec __cacheline_aligned ibm_architecture_vec = {
.mmu = 0,
.hash_ext = 0,
.radix_ext = 0,
- .byte22 = OV5_FEAT(OV5_DRC_INFO),
+ .byte22 = 0,
},
/* option vector 6: IBM PAPR hints */
^ permalink raw reply related
* Re: [PATCH] cxl: Remove function write_timebase_ctrl_psl9() for PSL9
From: Frederic Barrat @ 2018-02-13 19:53 UTC (permalink / raw)
To: Vaibhav Jain, linuxppc-dev
Cc: Philippe Bergheaud, Alastair D'Silva, Andrew Donnellan,
Christophe Lombard
In-Reply-To: <20180209041009.14456-1-vaibhav@linux.vnet.ibm.com>
Le 09/02/2018 à 05:10, Vaibhav Jain a écrit :
> For PSL9 the time-base enable bit has moved from PSL_TB_CTLSTAT
> register to PSL_CONTROL register. Hence we don't need an sl_ops
> implementation for 'write_timebase_ctrl' for PSL9.
>
> Hence this patch removes function write_timebase_ctrl_psl9() and its
> references from the code.
>
> Signed-off-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
> ---
The code change looks ok, but am I the only one to think the commit
message doesn't match? The enable bit has always been in the PSL_CONTROL
register, it was just badly documented on p8. What's been removed is
much of the configuration found in PSL_TB_CTLSTAT.
Fred
> drivers/misc/cxl/pci.c | 10 ++--------
> 1 file changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/misc/cxl/pci.c b/drivers/misc/cxl/pci.c
> index c983f23cc2ed..9bc30c20b66b 100644
> --- a/drivers/misc/cxl/pci.c
> +++ b/drivers/misc/cxl/pci.c
> @@ -572,12 +572,6 @@ static int init_implementation_adapter_regs_xsl(struct cxl *adapter, struct pci_
> /* For the PSL this is a multiple for 0 < n <= 7: */
> #define PSL_2048_250MHZ_CYCLES 1
>
> -static void write_timebase_ctrl_psl9(struct cxl *adapter)
> -{
> - cxl_p1_write(adapter, CXL_PSL9_TB_CTLSTAT,
> - TBSYNC_CNT(2 * PSL_2048_250MHZ_CYCLES));
> -}
> -
> static void write_timebase_ctrl_psl8(struct cxl *adapter)
> {
> cxl_p1_write(adapter, CXL_PSL_TB_CTLSTAT,
> @@ -639,7 +633,8 @@ static void cxl_setup_psl_timebase(struct cxl *adapter, struct pci_dev *dev)
> * Setup PSL Timebase Control and Status register
> * with the recommended Timebase Sync Count value
> */
> - adapter->native->sl_ops->write_timebase_ctrl(adapter);
> + if (adapter->native->sl_ops->write_timebase_ctrl)
> + adapter->native->sl_ops->write_timebase_ctrl(adapter);
>
> /* Enable PSL Timebase */
> cxl_p1_write(adapter, CXL_PSL_Control, 0x0000000000000000);
> @@ -1805,7 +1800,6 @@ static const struct cxl_service_layer_ops psl9_ops = {
> .psl_irq_dump_registers = cxl_native_irq_dump_regs_psl9,
> .err_irq_dump_registers = cxl_native_err_irq_dump_regs_psl9,
> .debugfs_stop_trace = cxl_stop_trace_psl9,
> - .write_timebase_ctrl = write_timebase_ctrl_psl9,
> .timebase_read = timebase_read_psl9,
> .capi_mode = OPAL_PHB_CAPI_MODE_CAPI,
> .needs_reset_before_disable = true,
>
^ permalink raw reply
* [PATCH] Fix cleanup when VAS is not configured
From: Sukadev Bhattiprolu @ 2018-02-13 19:53 UTC (permalink / raw)
To: Michael Ellerman
Cc: Benjamin Herrenschmidt, mikey, hbabu, linuxppc-dev, linux-kernel
From: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Date: Fri, 9 Feb 2018 11:49:06 -0600
Subject: [PATCH 1/1] powerpc/vas: Fix cleanup when VAS is not configured
When VAS is not configured, unregister the platform driver. Also simplify
cleanup by delaying vas debugfs init until we know VAS is configured.
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
---
Changelog[v2]
- [Michael Ellerman] Move vas_init_dbgdir() into a lower level
function to keep vas_init() cleaner.
---
arch/powerpc/platforms/powernv/vas-debug.c | 11 +++++++++++
arch/powerpc/platforms/powernv/vas.c | 6 +++---
2 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/vas-debug.c b/arch/powerpc/platforms/powernv/vas-debug.c
index b4de4c6..4f7276e 100644
--- a/arch/powerpc/platforms/powernv/vas-debug.c
+++ b/arch/powerpc/platforms/powernv/vas-debug.c
@@ -179,6 +179,7 @@ void vas_instance_init_dbgdir(struct vas_instance *vinst)
{
struct dentry *d;
+ vas_init_dbgdir();
if (!vas_debugfs)
return;
@@ -201,8 +202,18 @@ void vas_instance_init_dbgdir(struct vas_instance *vinst)
vinst->dbgdir = NULL;
}
+/*
+ * Set up the "root" VAS debugfs dir. Return if we already set it up
+ * (or failed to) in an earlier instance of VAS.
+ */
void vas_init_dbgdir(void)
{
+ static bool first_time = true;
+
+ if (!first_time)
+ return;
+
+ first_time = false;
vas_debugfs = debugfs_create_dir("vas", NULL);
if (IS_ERR(vas_debugfs))
vas_debugfs = NULL;
diff --git a/arch/powerpc/platforms/powernv/vas.c b/arch/powerpc/platforms/powernv/vas.c
index aebbe95..5a2b24c 100644
--- a/arch/powerpc/platforms/powernv/vas.c
+++ b/arch/powerpc/platforms/powernv/vas.c
@@ -160,8 +160,6 @@ static int __init vas_init(void)
int found = 0;
struct device_node *dn;
- vas_init_dbgdir();
-
platform_driver_register(&vas_driver);
for_each_compatible_node(dn, NULL, "ibm,vas") {
@@ -169,8 +167,10 @@ static int __init vas_init(void)
found++;
}
- if (!found)
+ if (!found) {
+ platform_driver_unregister(&vas_driver);
return -ENODEV;
+ }
pr_devel("Found %d instances\n", found);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH V3] powerpc/mm/hash64: memset the pagetable pages on allocation.
From: Ram Pai @ 2018-02-13 19:51 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: benh, paulus, mpe, linuxppc-dev
In-Reply-To: <20180213110933.5491-1-aneesh.kumar@linux.vnet.ibm.com>
On Tue, Feb 13, 2018 at 04:39:33PM +0530, Aneesh Kumar K.V wrote:
> On powerpc we allocate page table pages from slab cache of different sizes. For
> now we have a constructor that zero out the objects when we allocate then for
> the first time. We expect the objects to be zeroed out when we free the the
> object back to slab cache. This happens in the unmap path. For hugetlb pages
> we call huge_pte_get_and_clear to do that. With the current configuration of
> page table size, both pud and pgd level tables get allocated from the same slab
> cache. At the pud level, we use the second half of the table to store the slot
> information. But never clear that when unmapping. When such an freed object get
> allocated at pgd level, we will have part of the page table page not initlaized
> correctly. This result in kernel crash
>
> Simplify this by calling the object initialization after kmem_cache_alloc
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
> ---
> arch/powerpc/include/asm/book3s/64/pgalloc.h | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/book3s/64/pgalloc.h b/arch/powerpc/include/asm/book3s/64/pgalloc.h
> index 53df86d3cfce..e4d154a4d114 100644
> --- a/arch/powerpc/include/asm/book3s/64/pgalloc.h
> +++ b/arch/powerpc/include/asm/book3s/64/pgalloc.h
> @@ -73,10 +73,13 @@ static inline void radix__pgd_free(struct mm_struct *mm, pgd_t *pgd)
>
> static inline pgd_t *pgd_alloc(struct mm_struct *mm)
> {
> + pgd_t *pgd;
> if (radix_enabled())
> return radix__pgd_alloc(mm);
> - return kmem_cache_alloc(PGT_CACHE(PGD_INDEX_SIZE),
> - pgtable_gfp_flags(mm, GFP_KERNEL));
kmem_cache_zalloc() wont work?
RP
> + pgd = kmem_cache_alloc(PGT_CACHE(PGD_INDEX_SIZE),
> + pgtable_gfp_flags(mm, GFP_KERNEL));
> + memset(pgd, 0, PGD_TABLE_SIZE);
> + return pgd;
> }
>
> static inline void pgd_free(struct mm_struct *mm, pgd_t *pgd)
> --
> 2.14.3
--
Ram Pai
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/pseries: Declare optional dummy function for find_and_online_cpu_nid
From: Tyrel Datwyler @ 2018-02-13 19:49 UTC (permalink / raw)
To: Guenter Roeck, Benjamin Herrenschmidt
Cc: linux-kernel, Michael Bringmann, Paul Mackerras, Nathan Fontenot,
linuxppc-dev
In-Reply-To: <1518474848-3158-2-git-send-email-linux@roeck-us.net>
On 02/12/2018 02:34 PM, Guenter Roeck wrote:
> Commit e67e02a544e9 ("powerpc/pseries: Fix cpu hotplug crash with
> memoryless nodes") adds an unconditional call to find_and_online_cpu_nid(),
> which is only declared if CONFIG_PPC_SPLPAR is enabled. This results in
> the following build error if this is not the case.
>
> arch/powerpc/platforms/pseries/hotplug-cpu.o: In function `dlpar_online_cpu':
> arch/powerpc/platforms/pseries/hotplug-cpu.c:369:
> undefined reference to `.find_and_online_cpu_nid'
>
> Follow the guideline provided by similar functions and provide a dummy
> function if CONFIG_PPC_SPLPAR is not enabled. This also moves the external
> function declaration into an include file where it should be.
>
> Fixes: e67e02a544e9 ("powerpc/pseries: Fix cpu hotplug crash with ...")
> Cc: Michael Bringmann <mwb@linux.vnet.ibm.com>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Nathan Fontenot <nfont@linux.vnet.ibm.com>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Nathan already sent a patch on the 9th for this issue to the list.
-Tyrel
> ---
> arch/powerpc/include/asm/topology.h | 5 +++++
> arch/powerpc/platforms/pseries/hotplug-cpu.c | 2 --
> 2 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/topology.h b/arch/powerpc/include/asm/topology.h
> index 88187c285c70..52815982436f 100644
> --- a/arch/powerpc/include/asm/topology.h
> +++ b/arch/powerpc/include/asm/topology.h
> @@ -82,6 +82,7 @@ static inline int numa_update_cpu_topology(bool cpus_locked)
> extern int start_topology_update(void);
> extern int stop_topology_update(void);
> extern int prrn_is_enabled(void);
> +extern int find_and_online_cpu_nid(int cpu);
> #else
> static inline int start_topology_update(void)
> {
> @@ -95,6 +96,10 @@ static inline int prrn_is_enabled(void)
> {
> return 0;
> }
> +static inline int find_and_online_cpu_nid(int cpu)
> +{
> + return 0;
> +}
> #endif /* CONFIG_NUMA && CONFIG_PPC_SPLPAR */
>
> #if defined(CONFIG_HOTPLUG_CPU) || defined(CONFIG_NEED_MULTIPLE_NODES)
> diff --git a/arch/powerpc/platforms/pseries/hotplug-cpu.c b/arch/powerpc/platforms/pseries/hotplug-cpu.c
> index dceb51454d8d..f5c6a8cd2926 100644
> --- a/arch/powerpc/platforms/pseries/hotplug-cpu.c
> +++ b/arch/powerpc/platforms/pseries/hotplug-cpu.c
> @@ -340,8 +340,6 @@ static void pseries_remove_processor(struct device_node *np)
> cpu_maps_update_done();
> }
>
> -extern int find_and_online_cpu_nid(int cpu);
> -
> static int dlpar_online_cpu(struct device_node *dn)
> {
> int rc = 0;
>
^ permalink raw reply
* Re: [bug report] ocxl: Add AFU interrupt support
From: Frederic Barrat @ 2018-02-13 19:29 UTC (permalink / raw)
To: Dan Carpenter; +Cc: linuxppc-dev
In-Reply-To: <20180213081234.GA19567@mwanda>
Hi,
Thanks for the report. I'll fix the first issue. The 2nd is already on
its way to upstream:
https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?id=dedab7f0d3137441a97fe7cf9b9ca5
(though we still have a useless cast in there; will fix as well).
May I ask what static checker you're using?
Thanks,
Fred
Le 13/02/2018 à 09:12, Dan Carpenter a écrit :
> Hello Frederic Barrat,
>
> The patch aeddad1760ae: "ocxl: Add AFU interrupt support" from Jan
> 23, 2018, leads to the following static checker warning:
>
> drivers/misc/ocxl/file.c:163 afu_ioctl()
> warn: maybe return -EFAULT instead of the bytes remaining?
>
> drivers/misc/ocxl/file.c
> 111 static long afu_ioctl(struct file *file, unsigned int cmd,
> 112 unsigned long args)
> 113 {
> 114 struct ocxl_context *ctx = file->private_data;
> 115 struct ocxl_ioctl_irq_fd irq_fd;
> 116 u64 irq_offset;
> 117 long rc;
> 118
> 119 pr_debug("%s for context %d, command %s\n", __func__, ctx->pasid,
> 120 CMD_STR(cmd));
> 121
> 122 if (ctx->status == CLOSED)
> 123 return -EIO;
> 124
> 125 switch (cmd) {
> 126 case OCXL_IOCTL_ATTACH:
> 127 rc = afu_ioctl_attach(ctx,
> 128 (struct ocxl_ioctl_attach __user *) args);
> 129 break;
> 130
> 131 case OCXL_IOCTL_IRQ_ALLOC:
> 132 rc = ocxl_afu_irq_alloc(ctx, &irq_offset);
> 133 if (!rc) {
> 134 rc = copy_to_user((u64 __user *) args, &irq_offset,
> 135 sizeof(irq_offset));
> 136 if (rc)
> ^^
> copy_to_user() returns the number of bytes remaining but we want to
> return -EFAULT on error.
>
> 137 ocxl_afu_irq_free(ctx, irq_offset);
> 138 }
> 139 break;
> 140
>
> drivers/misc/ocxl/file.c:320 afu_read()
> warn: unsigned 'used' is never less than zero.
>
> drivers/misc/ocxl/file.c
> 279 ssize_t rc;
> 280 size_t used = 0;
> ^^^^^^
> This should be ssize_t
>
> 281 DEFINE_WAIT(event_wait);
> 282
> 283 memset(&header, 0, sizeof(header));
> 284
> 285 /* Require offset to be 0 */
> 286 if (*off != 0)
> 287 return -EINVAL;
> 288
> 289 if (count < (sizeof(struct ocxl_kernel_event_header) +
> 290 AFU_EVENT_BODY_MAX_SIZE))
> 291 return -EINVAL;
> 292
> 293 for (;;) {
> 294 prepare_to_wait(&ctx->events_wq, &event_wait,
> 295 TASK_INTERRUPTIBLE);
> 296
> 297 if (afu_events_pending(ctx))
> 298 break;
> 299
> 300 if (ctx->status == CLOSED)
> 301 break;
> 302
> 303 if (file->f_flags & O_NONBLOCK) {
> 304 finish_wait(&ctx->events_wq, &event_wait);
> 305 return -EAGAIN;
> 306 }
> 307
> 308 if (signal_pending(current)) {
> 309 finish_wait(&ctx->events_wq, &event_wait);
> 310 return -ERESTARTSYS;
> 311 }
> 312
> 313 schedule();
> 314 }
> 315
> 316 finish_wait(&ctx->events_wq, &event_wait);
> 317
> 318 if (has_xsl_error(ctx)) {
> 319 used = append_xsl_error(ctx, &header, buf + sizeof(header));
> 320 if (used < 0)
> ^^^^^^^^
> Impossible.
>
> 321 return used;
> 322 }
> 323
> 324 if (!afu_events_pending(ctx))
> 325 header.flags |= OCXL_KERNEL_EVENT_FLAG_LAST;
> 326
> 327 if (copy_to_user(buf, &header, sizeof(header)))
> 328 return -EFAULT;
> 329
> 330 used += sizeof(header);
> 331
> 332 rc = (ssize_t) used;
> ^^^^^^^^^^^^^^
> You could remove the cast.
>
> 333 return rc;
> 334 }
>
> regards,
> dan carpenter
>
^ permalink raw reply
* [PATCH 1/2] KVM: PPC: Fix compile error that occurs when CONFIG_ALTIVEC=n
From: Christian Zigotzky @ 2018-02-13 19:04 UTC (permalink / raw)
To: Paul Mackerras; +Cc: kvm, kvm-ppc, linuxppc-dev
In-Reply-To: <20180213045130.r35rdy24uokzixho@oak.ozlabs.ibm.com>
I successfully compiled the latest Git kernel with this patch without enable=
d AltiVec for my Freescale P5020 board today. The patch works without any pr=
oblems.
=E2=80=94 Christian
Sent from my iPhone
On 13. Feb 2018, at 05:51, Paul Mackerras <paulus@ozlabs.org> wrote:
Commit accb757d798c ("KVM: Move vcpu_load to arch-specific
kvm_arch_vcpu_ioctl_run", 2017-12-04) added a "goto out"
statement and an "out:" label to kvm_arch_vcpu_ioctl_run().
Since the only "goto out" is inside a CONFIG_VSX block,
compiling with CONFIG_VSX=3Dn gives a warning that label "out"
is defined but not used, and because arch/powerpc is compiled
with -Werror, that becomes a compile error that makes the kernel
build fail.
Merge commit 1ab03c072feb ("Merge tag 'kvm-ppc-next-4.16-2' of
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc",
2018-02-09) added a similar block of code inside a #ifdef
CONFIG_ALTIVEC, with a "goto out" statement.
In order to make the build succeed, this adds a #ifdef around the
"out:" label. This is a minimal, ugly fix, to be replaced later
by a refactoring of the code. Since CONFIG_VSX depends on
CONFIG_ALTIVEC, it is sufficient to use #ifdef CONFIG_ALTIVEC here.
Fixes: accb757d798c ("KVM: Move vcpu_load to arch-specific kvm_arch_vcpu_ioc=
tl_run")
Reported-by: Christian Zigotzky <chzigotzky@xenosoft.de>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
---
arch/powerpc/kvm/powerpc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 403e642c78f5..0083142c2f84 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -1608,7 +1608,9 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, str=
uct kvm_run *run)
kvm_sigset_deactivate(vcpu);
+#ifdef CONFIG_ALTIVEC
out:
+#endif
vcpu_put(vcpu);
return r;
}
--=20
2.11.0
^ permalink raw reply related
* Re: [PATCH] powerpc/via-pmu: Fix section mismatch warning
From: Laurent Vivier @ 2018-02-13 18:54 UTC (permalink / raw)
To: Mathieu Malaterre, Michael Ellerman; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20180207194439.32680-1-malat@debian.org>
On 07/02/2018 20:44, Mathieu Malaterre wrote:
> Remove the __init annotation from pmu_init() to avoid the
> following warning.
>
> WARNING: vmlinux.o(.data+0x4739c): Section mismatch in reference from the variable via_pmu_driver to the function .init.text:pmu_init()
> The variable via_pmu_driver references
> the function __init pmu_init()
> If the reference is valid then annotate the
> variable with __init* or __refdata (see linux/init.h) or name the variable:
> *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console
>
> Signed-off-by: Mathieu Malaterre <malat@debian.org>
> ---
> drivers/macintosh/via-pmu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/macintosh/via-pmu.c b/drivers/macintosh/via-pmu.c
> index 08849e33c567..5f378272d5b2 100644
> --- a/drivers/macintosh/via-pmu.c
> +++ b/drivers/macintosh/via-pmu.c
> @@ -378,7 +378,7 @@ static int pmu_probe(void)
> return vias == NULL? -ENODEV: 0;
> }
>
> -static int __init pmu_init(void)
> +static int pmu_init(void)
> {
> if (vias == NULL)
> return -ENODEV;
>
pmu_init() is really an init function only called by another init
function (adb_init()).
So I think it could be good to let the __init marker.
Did you try:
--- a/drivers/macintosh/via-pmu.c
+++ b/drivers/macintosh/via-pmu.c
@@ -198,7 +198,7 @@ static const struct file_operations
pmu_battery_proc_fops;
static const struct file_operations pmu_options_proc_fops;
#ifdef CONFIG_ADB
-struct adb_driver via_pmu_driver = {
+const struct adb_driver via_pmu_driver = {
"PMU",
pmu_probe,
pmu_init,
Thanks,
Laurent
^ 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