Commit bf904d2762ee ("x86/pti/64: Remove the SYSCALL64 entry trampoline")
removed the sole usage of 'kclist_add_remap()' from
'arch/x86/mm/cpu_entry_area.c', but it did not remove the left-over
definition from the include file.
Fix the same.
Cc: James Morse
Cc: Boris Petkov
Cc: Ingo Molnar
Cc:
Reduce #ifdef mess by defining a helper to print
hash info at startup.
In the meantime, remove the display of hash table address
to reduce leak of non necessary information.
Signed-off-by: Christophe Leroy
---
v2: added header to avoid sparse warning
arch/powerpc/kernel/setup-common.c | 19 +--
Due to %p, (ptrval) is printed in lieu of the hash table address.
showing the hash table address isn't an operationnal need so just
don't print it.
Signed-off-by: Christophe Leroy
---
v2: no change
arch/powerpc/mm/ppc_mmu_32.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --g
Hash_end has never been used, drop it.
Signed-off-by: Christophe Leroy
---
v2: no change
arch/powerpc/mm/mmu_decl.h | 2 +-
arch/powerpc/mm/ppc_mmu_32.c | 4 +---
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/mm/mmu_decl.h b/arch/powerpc/mm/mmu_decl.h
index 74ff6
Le 22/03/2019 à 09:08, Christophe Leroy a écrit :
To avoid ifdefs, define cpu_pvr at all time.
Signed-off-by: Christophe Leroy
This patch introduces a sparse warning.
I guess we can skip it for now and rework more deeply the use of cpu_pvr
versus SPRN_PVR which is re-read in many places
Le 26/03/2019 à 11:29, Peng Hao a écrit :
Could you fix your clock or clock setup ?
This emails appears to have been sent today at 11:29 (Paris Time ie
GMT+1) allthough it is only 7am at the time being.
Christophe
From: Wen Yang
The call to of_find_compatible_node returns a node pointe
Hi Masahiro,
Le 25/03/2019 à 07:44, Masahiro Yamada a écrit :
Hi Christophe,
On Sat, Mar 23, 2019 at 5:27 PM LEROY Christophe
wrote:
Arnd Bergmann a écrit :
On Wed, Mar 20, 2019 at 10:41 AM Arnd Bergmann wrote:
I've added your patch to my randconfig test setup and will let you
know if
Alastair D'Silva's on March 14, 2019 12:31 pm:
> From: Alastair D'Silva
>
> When building an LTO kernel, the existing code generates warnings:
> ./arch/powerpc/include/asm/paca.h:37:30: warning: register of
> ‘local_paca’ used for multiple global register variables
> register str
This adds a flag so that the DAWR can be enabled on P9 via:
echo Y > /sys/kernel/debug/powerpc/dawr_enable_dangerous
The DAWR was previously force disabled on POWER9 in:
9654153158 powerpc: Disable DAWR in the base POWER9 CPU features
Also see Documentation/powerpc/DAWR-POWER9.txt
This is a d
On Tue, Mar 26, 2019 at 1:05 AM Joe Lawrence wrote:
>
> CC_FLAGS_FTRACE may contain trailing whitespace that interferes with
> findstring.
>
> For example, commit 6977f95e63b9 ("powerpc: avoid -mno-sched-epilog on
> GCC 4.9 and newer") introduced a change such that on my ppc64le box,
> CC_FLAGS_FT
From: Wen Yang
The call to of_find_compatible_node returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.
irq_domain_add_linear also calls of_node_get to increase refcount,
so irq_domain will not be affected when it is released.
Detected by
>> The call to of_find_compatible_node returns a node pointer with refcount
>> incremented thus it must be explicitly decremented after the last
>> usage.
>> irq_domain_add_linear also calls of_node_get to increase refcount,
>> so irq_domain will not be affected when it is released.
>>
>> Detected
Joel Stanley writes:
> Segher added some workarounds for GCC 4.2 and bintuils 2.18. We now set
> 4.6 and 2.20 as the minimum, so they can be dropped.
>
> This is mostly a revert of c6995fe4 ("powerpc: Fix build bug with
> binutils < 2.18 and GCC < 4.2").
>
> Signed-off-by: Joel Stanley
> ---
On Mon, 2019-03-25 at 16:35 -0700, Joe Perches wrote:
> A file pattern line in this section of the MAINTAINERS file in linux-next
> does not have a match in the linux source files.
>
> This could occur because a matching filename was never added, was deleted
> or renamed in some other commit.
>
>
A file pattern line in this section of the MAINTAINERS file in linux-next
does not have a match in the linux source files.
This could occur because a matching filename was never added, was deleted
or renamed in some other commit.
The commits that added and if found renamed or removed the file pat
On Mon, Mar 25, 2019 at 03:36:28PM -0700, Dan Williams wrote:
> On Mon, Mar 25, 2019 at 3:22 PM Ira Weiny wrote:
> [..]
> > FWIW this thread is making me think my original patch which simply
> > implemented
> > get_user_pages_fast_longterm() would be more clear. There is some evidence
> > that t
On Mon, Mar 25, 2019 at 3:22 PM Ira Weiny wrote:
[..]
> FWIW this thread is making me think my original patch which simply implemented
> get_user_pages_fast_longterm() would be more clear. There is some evidence
> that the GUP API was trending that way (see get_user_pages_remote). That
> seems
On Mon, Mar 25, 2019 at 02:51:50PM -0300, Jason Gunthorpe wrote:
> On Mon, Mar 25, 2019 at 02:23:15AM -0700, Ira Weiny wrote:
> > > > Unfortunately holding the lock is required to support FOLL_LONGTERM (to
> > > > check
> > > > the VMAs) but we don't want to hold the lock to be optimal
> > > > (s
> -Original Message-
> From: Frederic Barrat
> Sent: Tuesday, 26 March 2019 4:34 AM
> To: Greg Kurz ; Alastair D'Silva
> Cc: alast...@d-silva.org; Arnd Bergmann ; Greg Kroah-
> Hartman ; linux-ker...@vger.kernel.org;
> Andrew Donnellan ; linuxppc-
> d...@lists.ozlabs.org
> Subject: Re: [P
On Mär 25 2019, Michael Ellerman wrote:
> So I'm inclined to just switch to always using SPARSEMEM on 64-bit
> Book3S, because that's what's well tested and we hardly need more code
> paths to test. Unless anyone has a strong objection, I haven't actually
> benchmarked FLATMEM vs SPARSEMEM on a G
On Fri, Mar 22, 2019 at 02:24:40PM -0700, Dan Williams wrote:
> On Sun, Mar 17, 2019 at 7:36 PM wrote:
[snip]
> > + * __gup_longterm_locked() is a wrapper for __get_uer_pages_locked which
>
> s/uer/user/
>
> > + * allows us to process the FOLL_LONGTERM flag if present.
> > + *
> > + * FOLL_LON
On Mon, Mar 25, 2019 at 11:33:56PM +1100, Michael Ellerman wrote:
> Segher Boessenkool writes:
> > On Fri, Mar 22, 2019 at 11:37:24PM +1100, Michael Ellerman wrote:
> >> + clrldi r6,r4,(64-12) // r6 = r4 & 0xfff
> >
> > You can just write
> > rlwinm r6,r4,0,0x0fff
>
> > if that is clearer?
On Mon, Mar 25, 2019 at 02:23:15AM -0700, Ira Weiny wrote:
> > > Unfortunately holding the lock is required to support FOLL_LONGTERM (to
> > > check
> > > the VMAs) but we don't want to hold the lock to be optimal (specifically
> > > allow
> > > FAULT_FOLL_ALLOW_RETRY). So I'm maintaining the op
Hi Arnd,
On Mon, Mar 25, 2019 at 03:47:37PM +0100, Arnd Bergmann wrote:
> Add the io_uring and pidfd_send_signal system calls to all architectures.
>
> These system calls are designed to handle both native and compat tasks,
> so all entries are the same across architectures, only arm-compat and
>
Le 25/03/2019 à 17:49, Greg Kurz a écrit :
Hi Alastair,
I forgot to mention it during v3 but please don't link new version
of a patchset to the previous one with --in-reply-to. This is to
ensure I can see them in my email client without having to scroll
back many days in the past (which likel
On Mon, Mar 25, 2019 at 01:47:13PM -0300, Jason Gunthorpe wrote:
> On Mon, Mar 25, 2019 at 01:42:26AM -0700, Ira Weiny wrote:
> > On Fri, Mar 22, 2019 at 03:12:55PM -0700, Dan Williams wrote:
> > > On Sun, Mar 17, 2019 at 7:36 PM wrote:
> > > >
> > > > From: Ira Weiny
> > > >
> > > > DAX pages we
On Mon, 25 Mar 2019 16:34:55 +1100
"Alastair D'Silva" wrote:
> From: Alastair D'Silva
>
> Remove some unused exported symbols.
>
> Signed-off-by: Alastair D'Silva
> ---
Reviewed-by: Greg Kurz
> drivers/misc/ocxl/config.c| 4 +---
> drivers/misc/ocxl/ocxl_internal.h | 23 +
Hi Alastair,
I forgot to mention it during v3 but please don't link new version
of a patchset to the previous one with --in-reply-to. This is to
ensure I can see them in my email client without having to scroll
back many days in the past (which likely means a fair number of
e-mails on linuxppc-dev
On Mon, 25 Mar 2019 16:34:54 +1100
"Alastair D'Silva" wrote:
> From: Alastair D'Silva
>
> The 'extern' keyword adds no value here.
>
> Signed-off-by: Alastair D'Silva
> ---
Reviewed-by: Greg Kurz
> drivers/misc/ocxl/ocxl_internal.h | 54 +++
> include/misc/ocxl
On Mon, Mar 25, 2019 at 09:45:12AM -0700, Dan Williams wrote:
> On Mon, Mar 25, 2019 at 7:21 AM Ira Weiny wrote:
> [..]
> > > > @@ -1268,10 +1246,14 @@ static long
> > > > check_and_migrate_cma_pages(unsigned long start, long nr_pages,
> > > > putback_movable_pages
On Mon, Mar 25, 2019 at 01:42:26AM -0700, Ira Weiny wrote:
> On Fri, Mar 22, 2019 at 03:12:55PM -0700, Dan Williams wrote:
> > On Sun, Mar 17, 2019 at 7:36 PM wrote:
> > >
> > > From: Ira Weiny
> > >
> > > DAX pages were previously unprotected from longterm pins when users
> > > called get_user_p
On Mon, Mar 25, 2019 at 7:21 AM Ira Weiny wrote:
[..]
> > > @@ -1268,10 +1246,14 @@ static long check_and_migrate_cma_pages(unsigned
> > > long start, long nr_pages,
> > > putback_movable_pages(&cma_page_list);
> > > }
> > > /*
> > >
On Fri, Mar 22, 2019 at 03:14:26PM -0700, Dan Williams wrote:
> On Sun, Mar 17, 2019 at 7:36 PM wrote:
> >
> > From: Ira Weiny
> >
> > Use the new FOLL_LONGTERM to get_user_pages_fast() to protect against
> > FS DAX pages being mapped.
> >
> > Signed-off-by: Ira Weiny
> > ---
> > drivers/infini
On Fri, Mar 22, 2019 at 03:12:55PM -0700, Dan Williams wrote:
> On Sun, Mar 17, 2019 at 7:36 PM wrote:
> >
> > From: Ira Weiny
> >
> > DAX pages were previously unprotected from longterm pins when users
> > called get_user_pages_fast().
> >
> > Use the new FOLL_LONGTERM flag to check for DEVMAP p
On Fri, Mar 22, 2019 at 03:05:53PM -0700, Dan Williams wrote:
> On Sun, Mar 17, 2019 at 7:36 PM wrote:
> >
> > From: Ira Weiny
> >
> > To facilitate additional options to get_user_pages_fast() change the
> > singular write parameter to be gup_flags.
> >
> > This patch does not change any function
On Mon, 25 Mar 2019 12:04:38 -0400
Joe Lawrence wrote:
> CC_FLAGS_FTRACE may contain trailing whitespace that interferes with
> findstring.
>
> For example, commit 6977f95e63b9 ("powerpc: avoid -mno-sched-epilog on
> GCC 4.9 and newer") introduced a change such that on my ppc64le box,
> CC_FLAGS
On 3/25/19 3:46 AM, Christophe Leroy wrote:
Le 25/03/2019 à 01:49, Larry Finger a écrit :
A build of kernel 5.1.0-rc2 resulted in a failure to boot on my PowerBook G4
Aluminum. The bootstrap loads the initial kernel and issues the appropriate
start, but the machine hangs at that point.
The
On 3/25/19 3:43 AM, Christophe Leroy wrote:
Commit 0df977eafc79 ("powerpc/6xx: Don't use SPRN_SPRG2 for storing
stack pointer while in RTAS") changes the code to use a field in
thread struct to store the stack pointer while in RTAS instead of
using SPRN_SPRG2. It therefore converts all places whi
On 3/23/19 1:27 PM, Joe Lawrence wrote:
On 03/23/2019 12:17 PM, Steven Rostedt wrote:
On Sat, 23 Mar 2019 09:19:50 -0400
Joe Lawrence wrote:
Perhaps this is gcc version specific? I didn't see any other reports,
so maybe its specific to my config. If I run make V=1, I can see that
gcc is cal
CC_FLAGS_FTRACE may contain trailing whitespace that interferes with
findstring.
For example, commit 6977f95e63b9 ("powerpc: avoid -mno-sched-epilog on
GCC 4.9 and newer") introduced a change such that on my ppc64le box,
CC_FLAGS_FTRACE="-pg -mprofile-kernel ". (Note the trailing space.)
When cmd
On 3/25/19 1:53 AM, Christophe Leroy wrote:
Le 25/03/2019 à 01:49, Larry Finger a écrit :
A build of kernel 5.1.0-rc2 resulted in a failure to boot on my PowerBook G4
Aluminum. The bootstrap loads the initial kernel and issues the appropriate
start, but the machine hangs at that point.
Can
Le 25/03/2019 à 06:44, Alastair D'Silva a écrit :
From: Alastair D'Silva
External drivers that communicate via OpenCAPI will need to make
MMIO calls to interact with the devices.
Signed-off-by: Alastair D'Silva
Reviewed-by: Greg Kurz
---
Acked-by: Frederic Barrat
drivers/misc/ocx
Le 25/03/2019 à 06:44, Alastair D'Silva a écrit :
From: Alastair D'Silva
Event_fd is only used in the driver frontend, so it does not
need to exist in the backend code. Relocate it to the frontend
and provide an opaque mechanism for consumers instead.
Signed-off-by: Alastair D'Silva
---
Hi,
Could you share the microbenchmark you are using ?
I'd like to test the series on powerpc.
Thanks
Christophe
Le 22/03/2019 à 15:30, Waiman Long a écrit :
Modify __down_read_trylock() to optimize for an unlocked rwsem and make
it generate slightly better code.
Before this patch, down_read
Le 25/03/2019 à 06:44, Alastair D'Silva a écrit :
From: Alastair D'Silva
The use of offsets is required only in the frontend, so alter
the IRQ API to only work with IRQ IDs in the backend.
Signed-off-by: Alastair D'Silva
---
Acked-by: Frederic Barrat
drivers/misc/ocxl/afu_irq.c
Le 25/03/2019 à 06:44, Alastair D'Silva a écrit :
From: Alastair D'Silva
Most OpenCAPI operations require a valid context, so
exposing these functions to external drivers is necessary.
Signed-off-by: Alastair D'Silva
Reviewed-by: Greg Kurz
---
See comment on previous patch regarding mer
This is a huge patch, there are probably ways to split it in smaller
pieces to make the review easier. However, considering how much time
we've already invested discussing and reviewing it, it's with by me to
keep it as is.
The ref-counting and device management look good to me now. A few
detai
Add the io_uring and pidfd_send_signal system calls to all architectures.
These system calls are designed to handle both native and compat tasks,
so all entries are the same across architectures, only arm-compat and
the generic tale still use an old format.
Signed-off-by: Arnd Bergmann
---
arch
On Fri, Mar 22, 2019 at 02:24:40PM -0700, Dan Williams wrote:
> On Sun, Mar 17, 2019 at 7:36 PM wrote:
> >
> > From: Ira Weiny
> >
> > Rather than have a separate get_user_pages_longterm() call,
> > introduce FOLL_LONGTERM and change the longterm callers to use
> > it.
> >
> > This patch does not
Segher Boessenkool writes:
> On Fri, Mar 22, 2019 at 11:37:24PM +1100, Michael Ellerman wrote:
>> .Lcmp_rest_lt8bytes:
>> -/* Here we have only less than 8 bytes to compare with. at least s1
>> - * Address is aligned with 8 bytes.
>> - * The next double words are load and shift right
I was able to activate CONFIG_SPARSEMEM in the kernel configuration. But
does the P.A. Semi Nemo board need this option?
-- Christian
On 25 March 2019 at 12:00PM, Christian Zigotzky wrote:
Hi All,
I wasn't able to compile the RC2 today because of the following error
messages:
CC arc
Le 25/03/2019 à 12:35, Michael Ellerman a écrit :
Ben Hutchings writes:
On Mon, 2019-03-25 at 01:03 +0100, Andreas Schwab wrote:
On Mär 24 2019, Ben Hutchings wrote:
Presumably you have CONFIG_PPC_BOOK3S_64 enabled and
CONFIG_SPARSEMEM
disabled? Was this configuration actually usable?
Ben Hutchings writes:
> On Mon, 2019-03-25 at 01:03 +0100, Andreas Schwab wrote:
>> On Mär 24 2019, Ben Hutchings wrote:
>>
>> > Presumably you have CONFIG_PPC_BOOK3S_64 enabled and
>> > CONFIG_SPARSEMEM
>> > disabled? Was this configuration actually usable?
>>
>> Why not?
>
> I assume that CO
Hi All,
I wasn't able to compile the RC2 today because of the following error
messages:
CC arch/powerpc/mm/slb.o
In file included from ./arch/powerpc/include/asm/book3s/64/mmu.h:39:0,
from ./arch/powerpc/include/asm/mmu.h:360,
from ./arch/powerpc/includ
Peng Hao writes:
> From: Wen Yang
>
> The call to of_find_compatible_node returns a node pointer with refcount
> incremented thus it must be explicitly decremented after the last
> usage.
> irq_domain_add_linear also calls of_node_get to increase refcount,
> so irq_domain will not be affected wh
On Mon, Mar 25, 2019 at 8:55 AM Masahiro Yamada
wrote:
>
> On Mon, Mar 25, 2019 at 4:33 PM Arnd Bergmann wrote:
> >
> > On Mon, Mar 25, 2019 at 7:11 AM Masahiro Yamada
> > wrote:
> > > I do not know why to reproduce it,
> > > but is "__init __noreturn" more sensible than
> > > "__always_inline"
On Wed, Mar 20, 2019 at 2:34 PM Arnd Bergmann wrote:
>
> On Wed, Mar 20, 2019 at 10:41 AM Arnd Bergmann wrote:
> >
> > I've added your patch to my randconfig test setup and will let you
> > know if I see anything noticeable. I'm currently testing clang-arm32,
> > clang-arm64 and gcc-x86.
>
> This
Le 25/03/2019 à 06:44, Alastair D'Silva a écrit :
From: Alastair D'Silva
This data is already available in a struct
Signed-off-by: Alastair D'Silva
---
Acked-by: Frederic Barrat
drivers/misc/ocxl/core.c | 38 +-
1 file changed, 21 insertions(+),
Le 25/03/2019 à 06:44, Alastair D'Silva a écrit :
From: Alastair D'Silva
In preparation for making core code available for external drivers,
move the core code out of pci.c and into core.c
Signed-off-by: Alastair D'Silva
---
Acked-by: Frederic Barrat
drivers/misc/ocxl/Makefile
From: Wen Yang
The call to of_find_compatible_node returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.
irq_domain_add_linear also calls of_node_get to increase refcount,
so irq_domain will not be affected when it is released.
Detected by
Hi, Ben
> Presumably you have CONFIG_PPC_BOOK3S_64 enabled and CONFIG_SPARSEMEM
> disabled?
> Was this configuration actually usable?
I just noticed these build warnings too. FWIW, I've been using
CONFIG_FLATMEM on my Power Mac G5 for about three years, so I guess
the answer is "yes" (for this s
Le 25/03/2019 à 18:11, Peng Hao a écrit :
From: Wen Yang
The call to of_find_compatible_node returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.
irq_domain_add_linear also calls of_node_get to increase refcount,
so irq_domain will not
Le 25/03/2019 à 01:49, Larry Finger a écrit :
A build of kernel 5.1.0-rc2 resulted in a failure to boot on my
PowerBook G4 Aluminum. The bootstrap loads the initial kernel and issues
the appropriate start, but the machine hangs at that point.
The problem does not depend on the choice of PPC
Commit 0df977eafc79 ("powerpc/6xx: Don't use SPRN_SPRG2 for storing
stack pointer while in RTAS") changes the code to use a field in
thread struct to store the stack pointer while in RTAS instead of
using SPRN_SPRG2. It therefore converts all places which were
manipulating SPRN_SPRG2 to use that fi
On Mon, Mar 25, 2019 at 4:33 PM Arnd Bergmann wrote:
>
> On Mon, Mar 25, 2019 at 7:11 AM Masahiro Yamada
> wrote:
> > On Wed, Mar 20, 2019 at 10:34 PM Arnd Bergmann wrote:
> > >
> > > On Wed, Mar 20, 2019 at 10:41 AM Arnd Bergmann wrote:
> > > >
> > > > I've added your patch to my randconfig te
On Mon, Mar 25, 2019 at 7:11 AM Masahiro Yamada
wrote:
> On Wed, Mar 20, 2019 at 10:34 PM Arnd Bergmann wrote:
> >
> > On Wed, Mar 20, 2019 at 10:41 AM Arnd Bergmann wrote:
> > >
> > > I've added your patch to my randconfig test setup and will let you
> > > know if I see anything noticeable. I'm
66 matches
Mail list logo