Mike Kravetz writes:
> On 07/20/2018 11:37 AM, Alex Ghiti wrote:
>> Does anyone have any suggestion about those patches ?
>
> I only took a quick look. From the hugetlb perspective, I like the
> idea of moving routines to a common file. If any of the arch owners
> (or anyone else) agree, I can
Some of our selftests have only been tested on ppc64le and crash or
behave weirdly on ppc64/ppc32. So add a helper for checking the UTS
machine.
Signed-off-by: Michael Ellerman
---
tools/testing/selftests/powerpc/include/utils.h | 2 ++
tools/testing/selftests/powerpc/utils.c | 17 +
These tests are currently failing on (some) big endian systems. Until
we can fix that, skip them unless we're on ppc64le.
Signed-off-by: Michael Ellerman
---
tools/testing/selftests/powerpc/tm/tm-sigreturn.c | 1 +
tools/testing/selftests/powerpc/tm/tm-tar.c | 1 +
tools/testing/selftests/
Some of these long running tests can time out on heavily loaded
systems, give them longer to run.
Signed-off-by: Michael Ellerman
---
tools/testing/selftests/powerpc/benchmarks/futex_bench.c | 1 +
tools/testing/selftests/powerpc/benchmarks/mmap_bench.c | 2 ++
tools/testing/sel
Because rfi_flush_fallback runs immediately before the return to
userspace it currently runs with the user r1 (stack pointer). This
means if we oops in there we will report a bad kernel stack pointer in
the exception entry path, eg:
Bad kernel stack pointer 77150e40 at c00023b4
Oop
Hi Michael,
On 07/26/2018 09:24 AM, Michael Ellerman wrote:
These tests are currently failing on (some) big endian systems. Until
we can fix that, skip them unless we're on ppc64le.
I can take a look at this.
Is that the same issue related to the gcc version we discussed a month ago?
If not,
On Wed 25-07-18 14:48:13, Baoquan He wrote:
> On 07/23/18 at 04:34pm, Michal Hocko wrote:
> > On Thu 19-07-18 23:17:53, Baoquan He wrote:
> > > Kexec has been a formal feature in our distro, and customers owning
> > > those kind of very large machine can make use of this feature to speed
> > > up t
If we take an SLB miss while MSR[RI]=0 we can't recover and have to
oops. Currently this is reported by faking up a 0x4100 exception, eg:
Unrecoverable exception 4100 at 0
Oops: Unrecoverable exception, sig: 6 [#1]
...
CPU: 0 PID: 1262 Comm: sh Not tainted
4.18.0-rc3-gcc-7.3.1-00098-g7fc2
* Alex Ghiti :
> This is the result of the build for all arches tackled in this series
> rebased on 4.18-rc6:
> ...
> parisc:
> generic-64bit_defconfig: with huge page does not link
> generic-64bit_defconfig: without huge page does not link
> BUT not because of this series,
This finally annoyed me enough to do something about it, I foolishly started
pulling the string and now here I am.
I think the end result is sufficiently more readable to justify the churn. I
particularly like that we now have EXCEPTION_PROLOG_0/1/2.
It will cause some pain for backports, but Nic
EXCEPTION_PROLOG_PSERIES() only has two users, STD_EXCEPTION_PSERIES()
and STD_EXCEPTION_HV() both of which "call" SET_SCRATCH0(), so just
move SET_SCRATCH0() into EXCEPTION_PROLOG_PSERIES().
Signed-off-by: Michael Ellerman
---
arch/powerpc/include/asm/exception-64s.h | 3 +--
1 file changed, 1
EXCEPTION_RELON_PROLOG_PSERIES() only has two users,
STD_RELON_EXCEPTION_PSERIES() and STD_RELON_EXCEPTION_HV() both of
which "call" SET_SCRATCH0(), so just move SET_SCRATCH0() into
EXCEPTION_RELON_PROLOG_PSERIES().
Signed-off-by: Michael Ellerman
---
arch/powerpc/include/asm/exception-64s.h | 3
The "PSERIES" in STD_EXCEPTION_PSERIES is to differentiate the macros
from the legacy iSeries versions, which are called
STD_EXCEPTION_ISERIES. It is not anything to do with pseries vs
powernv or powermac etc.
We removed the legacy iSeries code in 2012, in commit 8ee3e0d69623x
("powerpc: Remove th
Signed-off-by: Michael Ellerman
---
arch/powerpc/include/asm/exception-64s.h | 2 +-
arch/powerpc/include/asm/head-64.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/exception-64s.h
b/arch/powerpc/include/asm/exception-64s.h
index 9aeafb4d4
Signed-off-by: Michael Ellerman
---
arch/powerpc/include/asm/exception-64s.h | 2 +-
arch/powerpc/include/asm/head-64.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/exception-64s.h
b/arch/powerpc/include/asm/exception-64s.h
index db8989d4d
Signed-off-by: Michael Ellerman
---
arch/powerpc/include/asm/exception-64s.h | 2 +-
arch/powerpc/include/asm/head-64.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/exception-64s.h
b/arch/powerpc/include/asm/exception-64s.h
index 5a86173c5
As with the other patches in this series, we are removing the
"PSERIES" from the name as it's no longer meaningful.
In this case it's not simply a case of removing the "PSERIES" as that
would result in a clash with the existing EXCEPTION_PROLOG_1.
Instead we name this one EXCEPTION_PROLOG_2, as i
Signed-off-by: Michael Ellerman
---
arch/powerpc/include/asm/exception-64s.h | 10 +-
arch/powerpc/kernel/exceptions-64s.S | 10 +-
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/include/asm/exception-64s.h
b/arch/powerpc/include/asm/exception-6
The EXCEPTION_RELON_PROLOG_PSERIES_1() macro does the same job as
EXCEPTION_PROLOG_2 (which we just recently created), except for
"RELON" (relocation on) exceptions.
So rename it as such.
Signed-off-by: Michael Ellerman
---
arch/powerpc/include/asm/exception-64s.h | 20 ++--
1 f
To just EXCEPTION_RELON_PROLOG().
Signed-off-by: Michael Ellerman
---
arch/powerpc/include/asm/exception-64s.h | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/exception-64s.h
b/arch/powerpc/include/asm/exception-64s.h
index 3674557d58dc..b1c44
Signed-off-by: Michael Ellerman
---
arch/powerpc/include/asm/exception-64s.h | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/include/asm/exception-64s.h
b/arch/powerpc/include/asm/exception-64s.h
index b1c445d73165..728532c5f585 100644
--- a/arch/p
_MASKABLE_EXCEPTION_PSERIES() does nothing useful, update all callers
to use __MASKABLE_EXCEPTION_PSERIES() directly.
Signed-off-by: Michael Ellerman
---
arch/powerpc/include/asm/exception-64s.h | 11 ---
arch/powerpc/kernel/exceptions-64s.S | 4 ++--
2 files changed, 6 insertions(+
_MASKABLE_RELON_EXCEPTION_PSERIES() does nothing useful, update all
callers to use __MASKABLE_RELON_EXCEPTION_PSERIES() directly.
Signed-off-by: Michael Ellerman
---
arch/powerpc/include/asm/exception-64s.h | 11 ---
arch/powerpc/kernel/exceptions-64s.S | 4 ++--
2 files changed, 6
We pass the "loc" (location) parameter to MASKABLE_EXCEPTION and
friends, but it's not used, so drop it.
Signed-off-by: Michael Ellerman
---
arch/powerpc/include/asm/exception-64s.h | 8
arch/powerpc/include/asm/head-64.h | 4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)
Signed-off-by: Michael Ellerman
---
arch/powerpc/include/asm/exception-64s.h | 24 ++--
arch/powerpc/include/asm/head-64.h | 8
arch/powerpc/kernel/exceptions-64s.S | 8
3 files changed, 18 insertions(+), 22 deletions(-)
diff --git a/arch/powerpc
We only need to use __MASKABLE_EXCEPTION in one of the four cases for
hardware interrupt, so use the helper macros in the other cases.
Signed-off-by: Michael Ellerman
---
arch/powerpc/kernel/exceptions-64s.S | 16 +---
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/ar
On 07/26/18 at 02:59pm, Michal Hocko wrote:
> On Wed 25-07-18 14:48:13, Baoquan He wrote:
> > On 07/23/18 at 04:34pm, Michal Hocko wrote:
> > > On Thu 19-07-18 23:17:53, Baoquan He wrote:
> > > > Kexec has been a formal feature in our distro, and customers owning
> > > > those kind of very large ma
On Thu 26-07-18 21:09:04, Baoquan He wrote:
> On 07/26/18 at 02:59pm, Michal Hocko wrote:
> > On Wed 25-07-18 14:48:13, Baoquan He wrote:
> > > On 07/23/18 at 04:34pm, Michal Hocko wrote:
> > > > On Thu 19-07-18 23:17:53, Baoquan He wrote:
> > > > > Kexec has been a formal feature in our distro, an
On Thu 26-07-18 15:12:42, Michal Hocko wrote:
> On Thu 26-07-18 21:09:04, Baoquan He wrote:
> > On 07/26/18 at 02:59pm, Michal Hocko wrote:
> > > On Wed 25-07-18 14:48:13, Baoquan He wrote:
> > > > On 07/23/18 at 04:34pm, Michal Hocko wrote:
> > > > > On Thu 19-07-18 23:17:53, Baoquan He wrote:
> >
On 07/26/18 at 03:14pm, Michal Hocko wrote:
> On Thu 26-07-18 15:12:42, Michal Hocko wrote:
> > On Thu 26-07-18 21:09:04, Baoquan He wrote:
> > > On 07/26/18 at 02:59pm, Michal Hocko wrote:
> > > > On Wed 25-07-18 14:48:13, Baoquan He wrote:
> > > > > On 07/23/18 at 04:34pm, Michal Hocko wrote:
> >
On Thu 26-07-18 21:37:05, Baoquan He wrote:
> On 07/26/18 at 03:14pm, Michal Hocko wrote:
> > On Thu 26-07-18 15:12:42, Michal Hocko wrote:
> > > On Thu 26-07-18 21:09:04, Baoquan He wrote:
> > > > On 07/26/18 at 02:59pm, Michal Hocko wrote:
> > > > > On Wed 25-07-18 14:48:13, Baoquan He wrote:
> >
On Tue, Jul 24, 2018 at 03:32:47PM +1000, Alexey Kardashevskiy wrote:
> A VM which has:
> - a DMA capable device passed through to it (eg. network card);
> - running a malicious kernel that ignores H_PUT_TCE failure;
> - capability of using IOMMU pages bigger that physical pages
> can create an
On 07/26/18 at 04:01pm, Michal Hocko wrote:
> On Thu 26-07-18 21:37:05, Baoquan He wrote:
> > On 07/26/18 at 03:14pm, Michal Hocko wrote:
> > > On Thu 26-07-18 15:12:42, Michal Hocko wrote:
> > > > On Thu 26-07-18 21:09:04, Baoquan He wrote:
> > > > > On 07/26/18 at 02:59pm, Michal Hocko wrote:
> >
Alex Ghiti a écrit :
Hi everyone,
This is the result of the build for all arches tackled in this
series rebased on 4.18-rc6:
arm:
versatile_defconfig: without huge page OK
keystone_defconfig: with huge page OK
arm64:
defconfig: with huge page OK
ia64:
generi
Hi Christophe,
Sorry, I should have done it already: with and without huge page
activated, the build for mpc885_ads_defconfig is OK.
Thanks,
Alex
On 07/26/2018 03:13 PM, LEROY Christophe wrote:
Alex Ghiti a écrit :
Hi everyone,
This is the result of the build for all arches tackled in t
Hi Helge,
Thanks for your tests.
In case it can help you, this is what I get when I try to build
generic-64bit_defconfig (I truncated the output):
...
LD vmlinux.o
MODPOST vmlinux.o
hppa64-linux-ld: init/main.o(.text+0x98): cannot reach strreplace
init/main.o: In function `initcall_bla
On 07/05/2018 04:07 AM, Alexandre Ghiti wrote:
> asm-generic/hugetlb.h proposes generic implementations of hugetlb
> related functions: use __HAVE_ARCH_HUGE* defines in order to make arch
> specific implementations of hugetlb functions consistent with pgtable.h
> scheme.
>
Reviewed-by: Mike Krave
On 07/05/2018 04:07 AM, Alexandre Ghiti wrote:
> arm, ia64, mips, powerpc, sh, x86 architectures use the
> same version of set_huge_pte_at, so move this generic
> implementation into asm-generic/hugetlb.h.
>
Just one comment below, otherwise:
Reviewed-by: Mike Kravetz
> Signed-off-by: Alexandre
On 07/05/2018 04:07 AM, Alexandre Ghiti wrote:
> arm, ia64, sh, x86 architectures use the
> same version of huge_ptep_get_and_clear, so move this generic
> implementation into asm-generic/hugetlb.h.
>
Reviewed-by: Mike Kravetz
--
Mike Kravetz
> Signed-off-by: Alexandre Ghiti
> ---
> arch/arm
On 07/05/2018 04:07 AM, Alexandre Ghiti wrote:
> arm, x86 architectures use the same version of
> huge_ptep_clear_flush, so move this generic implementation into
> asm-generic/hugetlb.h.
>
Reviewed-by: Mike Kravetz
--
Mike Kravetz
> Signed-off-by: Alexandre Ghiti
> ---
> arch/arm/include/asm
On 07/05/2018 04:07 AM, Alexandre Ghiti wrote:
> arm, arm64, ia64, mips, parisc, powerpc, sh, sparc, x86
> architectures use the same version of huge_pte_wrprotect, so move
> this generic implementation into asm-generic/hugetlb.h.
>
Reviewed-by: Mike Kravetz
--
Mike Kravetz
> Signed-off-by: Al
On 07/05/2018 04:07 AM, Alexandre Ghiti wrote:
> arm, arm64, powerpc, sparc, x86 architectures use the same version of
> prepare_hugepage_range, so move this generic implementation into
> asm-generic/hugetlb.h.
>
Reviewed-by: Mike Kravetz
--
Mike Kravetz
> Signed-off-by: Alexandre Ghiti
> ---
On 07/05/2018 04:07 AM, Alexandre Ghiti wrote:
> arm, arm64, ia64, parisc, powerpc, sh, sparc, x86 architectures
> use the same version of huge_pte_none, so move this generic
> implementation into asm-generic/hugetlb.h.
>
Reviewed-by: Mike Kravetz
--
Mike Kravetz
> Signed-off-by: Alexandre Ghi
On 07/05/2018 04:07 AM, Alexandre Ghiti wrote:
> arm, ia64, mips, sh, x86 architectures use the same version
> of huge_ptep_set_wrprotect, so move this generic implementation into
> asm-generic/hugetlb.h.
> Note: powerpc uses twice for book3s/32 and nohash/32 the same version as
> the above archite
On 07/05/2018 04:07 AM, Alexandre Ghiti wrote:
> arm, ia64, sh, x86 architectures use the same version
> of huge_ptep_set_access_flags, so move this generic implementation
> into asm-generic/hugetlb.h.
>
Reviewed-by: Mike Kravetz
--
Mike Kravetz
> Signed-off-by: Alexandre Ghiti
> ---
> arch/
Actually, I went back to v4.17, and I have the same errors.
I used:
$ make ARCH=parisc O=build_parisc generic-64bit_defconfig
$ PATH=/home/alex/wip/toolchain/gcc-8.1.0-nolibc/hppa64-linux/bin:$PATH
make ARCH=parisc CROSS_COMPILE=hppa64-linux-
I downloaded the crosscompiler here:
https://mirr
On 07/05/2018 04:07 AM, Alexandre Ghiti wrote:
> ia64, mips, parisc, powerpc, sh, sparc, x86 architectures use the
> same version of huge_ptep_get, so move this generic implementation into
> asm-generic/hugetlb.h.
>
Reviewed-by: Mike Kravetz
--
Mike Kravetz
> Signed-off-by: Alexandre Ghiti
>
On 07/26/2018 04:46 AM, Michael Ellerman wrote:
> Mike Kravetz writes:
>
>> On 07/20/2018 11:37 AM, Alex Ghiti wrote:
>>> Does anyone have any suggestion about those patches ?
>>
>> I only took a quick look. From the hugetlb perspective, I like the
>> idea of moving routines to a common file. I
Hi Alex,
On 26.07.2018 21:13, Alex Ghiti wrote:
> $ make ARCH=parisc O=build_parisc generic-64bit_defconfig
> $ PATH=/home/alex/wip/toolchain/gcc-8.1.0-nolibc/hppa64-linux/bin:$PATH make
> ARCH=parisc CROSS_COMPILE=hppa64-linux-
>
>> ...
>> LD vmlinux.o
>> MODPOST vmlinux.o
>> hppa64-linu
On 07/05/2018 04:07 AM, Alexandre Ghiti wrote:
> arm, arm64, mips, parisc, sh, x86 architectures use the
> same version of hugetlb_free_pgd_range, so move this generic
> implementation into asm-generic/hugetlb.h.
>
Just one small issue below. Not absolutely necessary to fix.
Reviewed-by: Mike Kr
mmu_init_secondary function called at initialization sequence
but it misses __init annotation. As result modpost warning is generated.
Some building systems sensitive to such kind of warnings.
Signed-off-by: Alexey Spirkov
---
arch/powerpc/mm/44x_mmu.c | 2 +-
1 file changed, 1 insertion(+), 1 d
On Wed, Jul 25, 2018 at 07:50:30PM +1000, Alexey Kardashevskiy wrote:
> At the moment the kernel does not expect dynamic windows to ever start
> at zero on a PCI bus as PAPR requires the hypervisor to create a 32bit
> default window which starts from zero and the pseries kernel only
> creates addit
When the OF code was originally made common by Grant in commit
51975db0b733 ("of/flattree: merge early_init_dt_scan_memory() common
code") (Feb 2010), the common code inherited a hack to handle
PPC "longtrail" machines, which had a "memory@0" node with no
device_type.
That check was then made to o
Gustavo Romero writes:
> Hi Michael,
>
> On 07/26/2018 09:24 AM, Michael Ellerman wrote:
>> These tests are currently failing on (some) big endian systems. Until
>> we can fix that, skip them unless we're on ppc64le.
>
> I can take a look at this.
Thanks!
> Is that the same issue related to the
Michael Bringmann writes:
> On 07/23/2018 10:54 AM, John Allen wrote:
>> On Fri, Jul 13, 2018 at 03:18:01PM -0500, Michael Bringmann wrote:
>>> @@ -407,6 +413,61 @@ void queue_hotplug_event(struct pseries_hp_errorlog
>>> *hp_errlog,
...
>>> +
>>> +static int dlpar_pmt(struct pseries_hp_errorlog *
Michael Bringmann writes:
> On 07/23/2018 12:51 PM, Nathan Fontenot wrote:
>> On 07/13/2018 03:18 PM, Michael Bringmann wrote:
...
>>> +
>>> +int dlpar_queued_actions_run(void)
>>> +{
>>> + if (!list_empty(&dlpar_delayed_list)) {
>>> + struct pseries_hp_errorlog hp_errlog;
>>> +
>>> +
Hi Mike,
Thanks for your review. I'm going to fix the 2nd patch as you said,
you're right, no need to move the #include at the bottom of the file.
I'm going to post a v5, add -mm in cc and ask for inclusion in their tree.
Thanks again for your time,
Alex
On 07/26/2018 09:16 PM, Mike Kravetz
Adding the list back.
Aneesh Kumar K.V writes:
> Nicholas Piggin writes:
>
>> The page table fragment allocator uses the main page refcount racily
>> with respect to speculative references. A customer observed a BUG due
>> to page table page refcount underflow in the fragment allocator. This
58 matches
Mail list logo