On 2/15/22 04:03, Al Viro wrote:
> On Mon, Feb 14, 2022 at 05:34:52PM +0100, Arnd Bergmann wrote:
>> diff --git a/arch/parisc/include/asm/futex.h
>> b/arch/parisc/include/asm/futex.h
>> index b5835325d44b..2f4a1b1ef387 100644
>> --- a/arch/parisc/include/asm/futex.h
>> +++ b/arch/parisc/include/as
On Tue, Feb 15, 2022 at 07:29:42AM +0100, Christoph Hellwig wrote:
> On Tue, Feb 15, 2022 at 12:37:41AM +, Al Viro wrote:
> > Perhaps simply wrap that sucker into #ifdef CONFIG_CPU_HAS_ADDRESS_SPACES
> > (and trim the comment down to "coldfire and 68000 will pick generic
> > variant")?
>
> I w
On Tue, Feb 15, 2022 at 12:37:41AM +, Al Viro wrote:
> Perhaps simply wrap that sucker into #ifdef CONFIG_CPU_HAS_ADDRESS_SPACES
> (and trim the comment down to "coldfire and 68000 will pick generic
> variant")?
I wonder if we should invert CONFIG_ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE,
select
On Wed, 2 Feb 2022 05:51:23 +, Wedson Almeida Filho wrote:
> Without this patch, module init sections are disabled by patching their
> names in arch-specific code when they're loaded (which prevents code in
> layout_sections from finding init sections). This patch uses the new
> arch-specific m
On Sun, 21 Mar 2021 03:09:32 +0530, Bhaskar Chowdhury wrote:
> s/parmeters/parameters/
>
>
Applied to powerpc/next.
[1/1] powerpc: epapr: A typo fix
https://git.kernel.org/powerpc/c/a1c414093370ed50e5b952d96d4ae775c7a18420
cheers
On Wed, 12 Jan 2022 12:24:59 +0100, Joachim Wiberg wrote:
> From: Tobias Waldekranz
>
> This means an idle guest won't needlessly consume an entire core on
> the host, waiting for work to show up.
>
>
Applied to powerpc/next.
[1/1] powerpc/e500/qemu-e500: allow core to idle without waiting
On Mon, 20 Dec 2021 14:40:36 +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> The unit-address for the Maxim MAX1237 ADCs on XPedite5200 boards don't
> match the value in the "reg" property and cause a DTC warning.
>
>
Applied to powerpc/next.
[1/1] powerpc: dts: Fix some I2C unit addr
On Thu, 06 Jan 2022 16:33:53 +0530, Sachin Sant wrote:
> Cédric pointed out that XIVE IPI information exported via sysfs
> (debug/powerpc/xive) display empty lines for processors which are
> not online.
>
> Switch to using for_each_online_cpu() so that information is
> displayed for online-only pr
On Wed, 27 Nov 2019 23:09:59 +0100, Michal Suchanek wrote:
> The link stack flush status is not visible in debugfs. It can be enabled
> even when count cache flush is disabled. Add separate file for its
> status.
>
>
Applied to powerpc/next.
[1/1] powerpc: add link stack flush mitigation status
On Thu, 24 Sep 2020 10:44:16 +0530, Mamatha Inamdar wrote:
> This patch adds a brief MODULE_DESCRIPTION to rpadlpar_io kernel modules
> (descriptions taken from Kconfig file)
>
>
Applied to powerpc/next.
[1/1] rpadlpar_io:Add MODULE_DESCRIPTION entries to kernel modules
https://git.kernel
On Thu, 6 Jan 2022 17:13:39 +0100, Laurent Dufour wrote:
> The LPAR name may be changed after the LPAR has been started in the HMC.
> In that case lparstat command is not reporting the updated value because it
> reads it from the device tree which is read at boot time.
>
> However this value could
On Fri, 08 May 2020 09:12:56 +, Julia Lawall wrote:
> Other uses of &gang->aff_list_head, eg in spufs_assert_affinity, indicate
> that the list elements have type spu_context, not spu as used here. Change
> the type of tmp accordingly.
>
> This has no impact on the execution, because tmp is n
On Wed, 20 Jan 2021 15:18:47 -0300, Fabiano Rosas wrote:
> When figuring out the number of threads, the debug message prints "1
> thread" for the first iteration of the loop, instead of the actual
> number of threads calculated from the length of the
> "ibm,ppc-interrupt-server#s" property.
>
>
On Tue, 25 Jan 2022 13:54:21 +, Corentin Labbe wrote:
> pci_driver name is const char pointer, so the cast it not necessary.
>
>
Applied to powerpc/next.
[1/1] macintosh: macio_asic: remove useless cast for driver.name
https://git.kernel.org/powerpc/c/ccafe7c20b7de330d9091a114c9985305
On Sun, 30 Jan 2022 18:39:18 +, Christophe Leroy wrote:
> arch/powerpc/mm/ptdump/hashpagetable.c:264:29: warning: restricted __be64
> degrades to integer
> arch/powerpc/mm/ptdump/hashpagetable.c:265:49: warning: restricted __be64
> degrades to integer
> arch/powerpc/mm/ptdump/hashpageta
On Mon, 31 Jan 2022 08:16:48 +, Christophe Leroy wrote:
> arch/powerpc/include/asm/nohash/{32/64}/pgtable.h has
>
> #define __HAVE_ARCH_PTE_SAME
> #define pte_same(A,B) ((pte_val(A) ^ pte_val(B)) == 0)
>
> include/linux/pgtable.h has
>
> [...]
Applied to powerpc/next.
[1/1
On Tue, 1 Feb 2022 13:31:16 +0100, Christophe JAILLET wrote:
> 'xive_irq_bitmap_add()' can return -ENOMEM.
> In this case, we should free the memory already allocated and return
> 'false' to the caller.
>
> Also add an error path which undoes the 'tima = ioremap(...)'
>
>
> [...]
Applied to pow
On Mon, 31 Jan 2022 07:15:12 +, Christophe Leroy wrote:
> Since commit 84de6ab0e904 ("powerpc/603: don't handle PAGE_ACCESSED
> in TLB miss handlers.") page table is not updated anymore by
> TLB miss handlers.
>
> Remove the comment.
>
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/603:
On Mon, 31 Jan 2022 07:17:57 +, Christophe Leroy wrote:
> On book3s/32 MMU, PP bits don't offer kernel RO protection,
> kernel pages are always RW.
>
> However, on the 603 a page fault is always generated when the
> C bit (change bit = dirty bit) is not set.
>
> Enforce kernel RO protection b
On Sun, 30 Jan 2022 10:29:34 +, Christophe Leroy wrote:
> On 603 core, TLB miss handler don't do any change to the
> page tables so pte_update() doesn't need to be atomic.
>
>
Applied to powerpc/next.
[1/1] powerpc/32s: Make pte_update() non atomic on 603 core
https://git.kernel.org/p
On Wed, 29 Dec 2021 11:52:26 +0800, Chen Jingwen wrote:
> The shadow's page table is not updated when PTE_RPN_SHIFT is 24
> and PAGE_SHIFT is 12. It not only causes false positives but
> also false negative as shown the following text.
>
> Fix it by bringing the logic of kasan_early_shadow_page_en
On Fri, 21 Jan 2022 12:14:47 +0300, Maxim Kiselev wrote:
> On board rev A, the network interface labels for the switch ports
> written on the front panel are different than on rev B and later.
>
> This patch fixes network interface names for the switch ports according
> to labels that are written
On Thu, 30 Dec 2021 18:11:21 +0300, Maxim Kiselev wrote:
> T1040RDB has two RTL8211E-VB phys which requires setting
> of internal delays for correct work.
>
> Changing the phy-connection-type property to `rgmii-id`
> will fix this issue.
>
>
> [...]
Applied to powerpc/next.
[1/1] powerpc: dts:
On Wed, 2 Feb 2022 09:48:37 +0530, Athira Rajeev wrote:
> Trace IMC (In-Memory collection counters) in powerpc is
> useful for application level profiling. For trace_imc,
> presently task context (task_ctx_nr) is set to
> perf_hw_context. But perf_hw_context is to be used for
> cpu PMU. So for trac
On Mon, Feb 14, 2022 at 05:34:52PM +0100, Arnd Bergmann wrote:
> diff --git a/arch/parisc/include/asm/futex.h b/arch/parisc/include/asm/futex.h
> index b5835325d44b..2f4a1b1ef387 100644
> --- a/arch/parisc/include/asm/futex.h
> +++ b/arch/parisc/include/asm/futex.h
> @@ -99,7 +99,7 @@ futex_atomic_
On Mon, Feb 14, 2022 at 08:17:07PM +, Al Viro wrote:
> On Mon, Feb 14, 2022 at 12:01:05PM -0800, Linus Torvalds wrote:
> > On Mon, Feb 14, 2022 at 11:46 AM Arnd Bergmann wrote:
> > >
> > > As Al pointed out, they turned out to be necessary on sparc64, but the
> > > only
> > > definitions are
On Mon, Feb 14, 2022 at 05:34:49PM +0100, Arnd Bergmann wrote:
> -/*
> - * Sparc64 is segmented, though more like the M68K than the I386.
> - * We use the secondary ASI to address user memory, which references a
> - * completely different VM map, thus there is zero chance of the user
> - * doing s
On Mon, Feb 14, 2022 at 05:34:47PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> While most m68k platforms use separate address spaces for user
> and kernel space, at least coldfire does not, and the other
> ones have a TASK_SIZE that is less than the entire 4GB address
> range.
>
> Usin
On Mon, Feb 14, 2022 at 05:34:43PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> All architectures that don't provide __{get,put}_kernel_nofault() yet
> can implement this on top of __{get,put}_user.
>
> Add a generic version that lets everything use the normal
> copy_{from,to}_kernel_no
From: Linus Torvalds
> Sent: 14 February 2022 20:24
> >
> > x86-64 has always(*) used TASK_SIZE_MAX for access_ok(), and the
> > get_user() assembler implementation does the same.
>
> Side note: we could just check the sign bit instead, and avoid big
> constants that way.
The cheap test for most
On 2022-02-14 16:34, Arnd Bergmann wrote:
From: Arnd Bergmann
arm64 has an inline asm implementation of access_ok() that is derived from
the 32-bit arm version and optimized for the case that both the limit and
the size are variable. With set_fs() gone, the limit is always constant,
and the siz
On Mon, Feb 14, 2022 at 12:01 PM Linus Torvalds
wrote:
>
> x86-64 has always(*) used TASK_SIZE_MAX for access_ok(), and the
> get_user() assembler implementation does the same.
Side note: we could just check the sign bit instead, and avoid big
constants that way.
Right now we actually have this
On Mon, Feb 14, 2022 at 12:01:05PM -0800, Linus Torvalds wrote:
> On Mon, Feb 14, 2022 at 11:46 AM Arnd Bergmann wrote:
> >
> > As Al pointed out, they turned out to be necessary on sparc64, but the only
> > definitions are on sparc64 and x86, so it's possible that they serve a
> > similar
> > pu
On Mon, Feb 14, 2022 at 11:46 AM Arnd Bergmann wrote:
>
> As Al pointed out, they turned out to be necessary on sparc64, but the only
> definitions are on sparc64 and x86, so it's possible that they serve a similar
> purpose here, in which case changing the limit from TASK_SIZE to
> TASK_SIZE_MAX
On Mon, Feb 14, 2022 at 08:45:52PM +0100, Arnd Bergmann wrote:
> As Al pointed out, they turned out to be necessary on sparc64, but the only
> definitions are on sparc64 and x86, so it's possible that they serve a similar
> purpose here, in which case changing the limit from TASK_SIZE to
> TASK_SIZ
On Mon, Feb 14, 2022 at 6:02 PM Christoph Hellwig wrote:
>
> On Mon, Feb 14, 2022 at 05:34:42PM +0100, Arnd Bergmann wrote:
> > +#define __range_not_ok(addr, size, limit)(!__access_ok(addr, size))
> > +#define __chk_range_not_ok(addr, size, limit)(!__access_ok((void
> > __user *)addr,
On Mon, Feb 14, 2022 at 6:06 PM Christoph Hellwig wrote:
>
> On Mon, Feb 14, 2022 at 05:34:48PM +0100, Arnd Bergmann wrote:
> > From: Arnd Bergmann
> >
> > On almost all architectures, there are no remaining callers
> > of set_fs(), so CONFIG_SET_FS can be disabled, along with
> > removing the th
On Mon, Feb 14, 2022 at 6:15 PM Al Viro wrote:
>
> On Mon, Feb 14, 2022 at 05:34:45PM +0100, Arnd Bergmann wrote:
>
> > diff --git a/arch/csky/kernel/signal.c b/arch/csky/kernel/signal.c
> > index c7b763d2f526..8867ddf3e6c7 100644
> > --- a/arch/csky/kernel/signal.c
> > +++ b/arch/csky/kernel/sign
On Mon, 14 Feb 2022 22:54:23 +0530
"Naveen N. Rao" wrote:
> For x86, commit 0c0593b45c9b4e ("x86/ftrace: Make function graph use
> ftrace directly") also adds recursion check before the call to
> function_graph_enter() in prepare_ftrace_return(). Do we need that on
> powerpc as well?
Yes. The
Hi Ahmad-san,
On 2022/02/15 1:22, Ahmad Fatoum wrote:
Hello Tokunori-san,
On 13.02.22 17:47, Tokunori Ikegami wrote:
Hi Ahmad-san,
Thanks for your confirmations. Sorry for late to reply.
No worries. I appreciate you taking the time.
Could you please try the patch attached to disable the ch
Hi Paul,
On 2/13/22 22:55, Paul Menzel wrote:
> Currently, `git status` lists the file as untracked by git, so tell git
> to ignore it.
Thanks for your contribution.
Acked-by: Geoff Levand
On 14 Feb 2022, at 12:41, David Hildenbrand wrote:
> Some places in the kernel don't really expect pageblock_order >=
> MAX_ORDER, and it looks like this is only possible in corner cases:
>
> 1) CONFIG_DEFERRED_STRUCT_PAGE_INIT we'll end up freeing pageblock_order
>pages via __free_pages_core(
On 14 Feb 2022, at 12:41, David Hildenbrand wrote:
> Let's factor out determining the minimum alignment requirement for CMA
> and add a helpful comment.
>
> No functional change intended.
>
> Signed-off-by: David Hildenbrand
> ---
> arch/powerpc/include/asm/fadump-internal.h | 5 -
> arch/p
Christophe Leroy wrote:
PPC64 mprofile versions and PPC32 are very similar.
Modify PPC64 version so that if can be reused for PPC32.
Signed-off-by: Christophe Leroy
---
.../powerpc/kernel/trace/ftrace_64_mprofile.S | 73 +--
1 file changed, 51 insertions(+), 22 deletions(-)
Some places in the kernel don't really expect pageblock_order >=
MAX_ORDER, and it looks like this is only possible in corner cases:
1) CONFIG_DEFERRED_STRUCT_PAGE_INIT we'll end up freeing pageblock_order
pages via __free_pages_core(), which cannot possibly work.
2) find_zone_movable_pfns_for
Let's factor out determining the minimum alignment requirement for CMA
and add a helpful comment.
No functional change intended.
Signed-off-by: David Hildenbrand
---
arch/powerpc/include/asm/fadump-internal.h | 5 -
arch/powerpc/kernel/fadump.c | 2 +-
drivers/of/of_reserved
Having pageblock_order >= MAX_ORDER seems to be able to happen in corner
cases and some parts of the kernel are not prepared for it.
For example, Aneesh has shown [1] that such kernels can be compiled on
ppc64 with 64k base pages by setting FORCE_MAX_ZONEORDER=8, which will run
into a WARN_ON_ONCE
On Mon, Feb 14, 2022 at 8:35 AM Arnd Bergmann wrote:
>
> I did a patch for microblaze at some point, which turned out to be fairly
> generic, and now ported it to most other architectures, using new generic
> implementations of access_ok() and __{get,put}_kernel_nocheck().
Thanks for doing this.
On Mon, Feb 14, 2022 at 05:34:45PM +0100, Arnd Bergmann wrote:
> diff --git a/arch/csky/kernel/signal.c b/arch/csky/kernel/signal.c
> index c7b763d2f526..8867ddf3e6c7 100644
> --- a/arch/csky/kernel/signal.c
> +++ b/arch/csky/kernel/signal.c
> @@ -136,7 +136,7 @@ static inline void __user *get_sig
Christophe Leroy wrote:
Modify function graph tracer to be handled directly by the standard
ftrace caller.
This is made possible as powerpc now supports
CONFIG_DYNAMIC_FTRACE_WITH_ARGS.
This change simplifies the call of function graph ftrace.
Signed-off-by: Christophe Leroy
---
arch/powerpc
On Mon, 2022-02-14 at 16:55 +0100, Michal Suchánek wrote:
> Hello,
>
> On Mon, Feb 14, 2022 at 10:14:16AM -0500, Mimi Zohar wrote:
> > Hi Michal,
> >
> > On Sun, 2022-02-13 at 21:59 -0500, Mimi Zohar wrote:
> >
> > >
> > > On Tue, 2022-01-11 at 12:37 +0100, Michal Suchanek wrote:
> > > > diff -
From: Christoph Hellwig
> Sent: 14 February 2022 17:01
>
> On Mon, Feb 14, 2022 at 05:34:41PM +0100, Arnd Bergmann wrote:
> > From: Arnd Bergmann
> >
> > The get_user()/put_user() functions are meant to check for
> > access_ok(), while the __get_user()/__put_user() functions
> > don't.
> >
> > Th
> void prom_world(int enter)
> {
> - if (!enter)
> - set_fs(get_fs());
> -
> __asm__ __volatile__("flushw");
> }
The enter argument is now unused.
On Mon, Feb 14, 2022 at 05:34:48PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> On almost all architectures, there are no remaining callers
> of set_fs(), so CONFIG_SET_FS can be disabled, along with
> removing the thread_info field and any references to it.
>
> This turns access_ok() i
Looks good,
Reviewed-by: Christoph Hellwig
Looks good,
Reviewed-by: Christoph Hellwig
On Mon, Feb 14, 2022 at 05:34:42PM +0100, Arnd Bergmann wrote:
> +#define __range_not_ok(addr, size, limit)(!__access_ok(addr, size))
> +#define __chk_range_not_ok(addr, size, limit)(!__access_ok((void
> __user *)addr, size))
Can we just kill these off insted of letting themm obsfucat
On Mon, Feb 14, 2022 at 05:34:41PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The get_user()/put_user() functions are meant to check for
> access_ok(), while the __get_user()/__put_user() functions
> don't.
>
> This broke in 4.19 for nds32, when it gained an extraneous
> check in __ge
Looks good,
Reviewed-by: Christoph Hellwig
From: Arnd Bergmann
There are no more users of CONFIG_SET_FS left, so drop all
remaining references to set_fs()/get_fs(), mm_segment_t
and uaccess_kernel().
Signed-off-by: Arnd Bergmann
---
arch/Kconfig | 3 ---
arch/arm/lib/uaccess_with_memcpy.c | 10 -
arch/nds
From: Arnd Bergmann
ia64 only uses set_fs() in one file to handle unaligned access for
both user space and kernel instructions. Rewrite this to explicitly
pass around a flag about which one it is and drop the feature from
the architecture.
Signed-off-by: Arnd Bergmann
---
arch/ia64/Kconfig
From: Arnd Bergmann
sh uses set_fs/get_fs only in one file, to handle address
errors in both user and kernel memory.
It already has an abstraction to differentiate between I/O
and memory, so adding a third class for kernel memory fits
into the same scheme and lets us kill off CONFIG_SET_FS.
Sig
From: Arnd Bergmann
sparc64 uses address space identifiers to differentiate between kernel
and user space, using ASI_P for kernel threads but ASI_AIUS for normal
user space, with the option of changing between them.
As nothing really changes the ASI any more, just hardcode ASI_AIUS
everywhere. K
From: Arnd Bergmann
On almost all architectures, there are no remaining callers
of set_fs(), so CONFIG_SET_FS can be disabled, along with
removing the thread_info field and any references to it.
This turns access_ok() into a cheaper check against TASK_SIZE_MAX.
Signed-off-by: Arnd Bergmann
---
From: Arnd Bergmann
While most m68k platforms use separate address spaces for user
and kernel space, at least coldfire does not, and the other
ones have a TASK_SIZE that is less than the entire 4GB address
range.
Using the generic implementation of __access_ok() stops coldfire
user space from tr
From: Arnd Bergmann
arm64 has an inline asm implementation of access_ok() that is derived from
the 32-bit arm version and optimized for the case that both the limit and
the size are variable. With set_fs() gone, the limit is always constant,
and the size usually is as well, so just using the defa
From: Arnd Bergmann
There are many different ways that access_ok() is defined across
architectures, but in the end, they all just compare against the
user_addr_max() value or they accept anything.
Provide one definition that works for most architectures, checking
against TASK_SIZE_MAX for user p
From: Arnd Bergmann
Before unifying the mips version of __access_ok() with the generic
code, this converts it to the same algorithm. This is a change in
behavior on mips64, as now address in the user segment, the lower
2^62 bytes, is taken to be valid, relying on a page fault for
addresses that a
From: Arnd Bergmann
All architectures that don't provide __{get,put}_kernel_nofault() yet
can implement this on top of __{get,put}_user.
Add a generic version that lets everything use the normal
copy_{from,to}_kernel_nofault() code based on these, removing the last
use of get_fs()/set_fs() from
From: Arnd Bergmann
The way that access_ok() is defined on x86 is slightly different from
most other architectures, and a bit more complex.
The generic version tends to result in the best output on all
architectures, as it results in single comparison against a constant
limit for calls with a kn
From: Arnd Bergmann
The get_user()/put_user() functions are meant to check for
access_ok(), while the __get_user()/__put_user() functions
don't.
This broke in 4.19 for nds32, when it gained an extraneous
check in __get_user(), but lost the check it needs in
__put_user().
Fixes: 487913ab18c2 ("n
From: Arnd Bergmann
sparc64 is one of the architectures that uses separate address
spaces for kernel and user addresses, so __get_kernel_nofault()
can not just call into the normal __get_user() without the
access_ok() check.
Instead duplicate __get_user() and __put_user() into their
in-kernel ve
From: Arnd Bergmann
Three architectures check the end of a user access against the
address limit without taking a possible overflow into account.
Passing a negative length or another overflow in here returns
success when it should not.
Use the most common correct implementation here, which optim
From: Arnd Bergmann
Christoph Hellwig and a few others spent a huge effort on removing
set_fs() from most of the important architectures, but about half the
other architectures were never completed even though most of them don't
actually use set_fs() at all.
I did a patch for microblaze at some
Hello Tokunori-san,
On 13.02.22 17:47, Tokunori Ikegami wrote:
> Hi Ahmad-san,
>
> Thanks for your confirmations. Sorry for late to reply.
No worries. I appreciate you taking the time.
> Could you please try the patch attached to disable the chip_good() change as
> before?
> I think this shoul
On 14 Feb 2022, at 2:59, Christophe Leroy wrote:
> Le 11/02/2022 à 17:41, Zi Yan a écrit :
>> From: Zi Yan
>>
>> alloc_contig_range() worked at MAX_ORDER-1 granularity to avoid merging
>> pageblocks with different migratetypes. It might unnecessarily convert
>> extra pageblocks at the beginning a
Hello,
On Mon, Feb 14, 2022 at 10:14:16AM -0500, Mimi Zohar wrote:
> Hi Michal,
>
> On Sun, 2022-02-13 at 21:59 -0500, Mimi Zohar wrote:
>
> >
> > On Tue, 2022-01-11 at 12:37 +0100, Michal Suchanek wrote:
> > > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> > > index dea74d7717c0..1
On 14 Feb 2022, at 2:26, Christoph Hellwig wrote:
>> +int
>> +isolate_single_pageblock(unsigned long boundary_pfn, gfp_t gfp_flags, int
>> isolate_before_boundary);
>
> Please avoid the completely unreadably long line. i.e.
>
> int isolate_single_pageblock(unsigned long boundary_pfn, gfp_t gfp_fl
Christophe Leroy wrote:
Implement CONFIG_DYNAMIC_FTRACE_WITH_ARGS. It accelerates the call
of livepatching.
Also note that powerpc being the last one to convert to
CONFIG_DYNAMIC_FTRACE_WITH_ARGS, it will now be possible to remove
klp_arch_set_pc() on all architectures.
Signed-off-by: Christoph
Hi Christophe,
Thanks for your work enabling DYNAMIC_FTRACE_WITH_ARGS on powerpc. Sorry
for the late review on this series, but I have a few comments below.
Christophe Leroy wrote:
In order to implement CONFIG_DYNAMIC_FTRACE_WITH_ARGS, change ftrace_caller()
to handle LIVEPATCH the same way a
Hi Michal,
On Sun, 2022-02-13 at 21:59 -0500, Mimi Zohar wrote:
>
> On Tue, 2022-01-11 at 12:37 +0100, Michal Suchanek wrote:
> > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> > index dea74d7717c0..1cde9b6c5987 100644
> > --- a/arch/powerpc/Kconfig
> > +++ b/arch/powerpc/Kconfig
> >
On Mon, Feb 14, 2022 at 01:33:24PM +0100, Paul Menzel wrote:
> Dear Michal,
>
>
> Thank you for your reply.
>
> Am 14.02.22 um 10:43 schrieb Michal Suchánek:
>
> > On Mon, Feb 14, 2022 at 07:08:07AM +0100, Paul Menzel wrote:
> > > Dear PPC folks,
> > >
> > >
> > > On the POWER8 server IBM S82
Dear Michal,
Thank you for your reply.
Am 14.02.22 um 10:43 schrieb Michal Suchánek:
On Mon, Feb 14, 2022 at 07:08:07AM +0100, Paul Menzel wrote:
Dear PPC folks,
On the POWER8 server IBM S822LC running `ppc64_cpu --smt=off` or `ppc64_cpu
--smt=8`, Linux 5.17-rc4 does not log anything. I wo
Christophe Leroy wrote:
Le 07/02/2022 à 08:07, Naveen N. Rao a écrit :
This is an early RFC series that adds support for BPF Trampolines on
powerpc64. Some of the selftests are passing for me, but this needs more
testing and I've likely missed a few things as well. A review of the
patches and
On Fri, Feb 11, 2022 at 11:41:30AM -0500, Zi Yan wrote:
> From: Zi Yan
>
> has_unmovable_pages() is only used in mm/page_isolation.c. Move it from
> mm/page_alloc.c and make it static.
>
> Signed-off-by: Zi Yan
> Reviewed-by: Oscar Salvador
Reviewed-by: Mike Rapoport
> ---
> include/linux/
Convert bpf_to_ppc() to a macro to help simplify its usage since
codegen_context is available in all places it is used. Adopt it also for
powerpc64 for uniformity and get rid of the global b2p structure.
Signed-off-by: Naveen N. Rao
---
arch/powerpc/net/bpf_jit.h| 11 ++--
arch/powerpc/n
From: Jordan Niethe
In bpf_jit_build_body(), the mapping of TMP_REG_1 and TMP_REG_2's bpf
register to ppc register is evalulated at every use despite not
changing. Instead, determine the ppc register once and store the result.
Signed-off-by: Jordan Niethe
[Rebased, converted additional usage si
There is no need for a separate header anymore. Move the contents of
bpf_jit64.h into bpf_jit_comp64.c
Signed-off-by: Naveen N. Rao
---
arch/powerpc/net/bpf_jit64.h | 69 ---
arch/powerpc/net/bpf_jit_comp64.c | 54 +++-
2 files changed, 53 ins
Use _Rn macros to specify register names to make their usage clear.
Signed-off-by: Naveen N. Rao
---
arch/powerpc/net/bpf_jit_comp32.c | 30 +++---
arch/powerpc/net/bpf_jit_comp64.c | 68 +++
2 files changed, 49 insertions(+), 49 deletions(-)
diff --git a/arc
- PPC_EX32() is only used by ppc32 JIT. Move it to bpf_jit_comp32.c
- PPC_LI64() is only valid in ppc64. #ifdef it
- PPC_FUNC_ADDR() is not used anymore. Remove it.
Signed-off-by: Naveen N. Rao
---
arch/powerpc/net/bpf_jit.h| 10 +-
arch/powerpc/net/bpf_jit_comp32.c | 2 ++
2 fi
All these macros now have a single user. Expand their usage in place.
Signed-off-by: Naveen N. Rao
---
arch/powerpc/net/bpf_jit64.h | 22 --
arch/powerpc/net/bpf_jit_comp64.c | 21 +++--
2 files changed, 15 insertions(+), 28 deletions(-)
diff --git a/arc
In some scenarios, it is possible that the program epilogue is outside
the branch range for a BPF_EXIT instruction. Instead of rejecting such
programs, emit epilogue as an alternate exit point from the program.
Track the location of the same so that subsequent exits can take either
of the two paths
PPC_BPF_[LL|STL] are macros meant for scenarios where we may have to
deal with a non-word aligned offset. Limit their usage to only those
scenarios by converting the rest to just use PPC_BPF_[LD|STD].
Signed-off-by: Naveen N. Rao
---
arch/powerpc/net/bpf_jit_comp64.c | 22 +++---
PPC_BL_ABS() is just doing a relative branch with link. The name
suggests that it is for branching to an absolute address, which is
incorrect. Rename the macro to a more appropriate PPC_BL().
Signed-off-by: Naveen N. Rao
---
arch/powerpc/net/bpf_jit.h| 6 +++---
arch/powerpc/net/bpf_jit_
When calling BPF helpers, we load the function address to call into a
register. This can result in upto 5 instructions. Optimize this by
instead using the kernel toc in r2 and adjusting offset to the BPF
helper. This works since all BPF helpers are part of kernel text, and
all BPF programs/function
BPF helpers always reside in core kernel and all BPF programs use the
kernel TOC. As such, there is no need to load the TOC before calling
helpers or other BPF functions. Drop code to do the same.
Add a check to ensure we don't proceed if this assumption ever changes
in future.
Signed-off-by: Nav
In preparation for using kernel TOC, load the same in r2 on entry. With
elfv1, the kernel TOC is already setup by our caller.
We adjust the number of instructions to skip on a tail call accordingly.
We get rid of the #ifdef in bpf_jit_emit_tail_call() since
FUNCTION_DESCR_SIZE is itself under a #i
Set macros to 1 so that they can be used with __is_defined().
Suggested-by: Christophe Leroy
Signed-off-by: Naveen N. Rao
---
arch/powerpc/include/asm/types.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/types.h b/arch/powerpc/include/asm/type
In preparation for preserving kernel toc in r2, switch BPF_REG_AX from
r2 to r12. r12 is not used by bpf JIT except during external helper/bpf
calls, or with BPF_NOSPEC. These sequences aren't emitted when
BPF_REG_AX is used for constant blinding and other purposes.
Signed-off-by: Naveen N. Rao
-
Instead of saving and restoring LR before each invocation to
bpf_stf_barrier(), set SEEN_FUNC flag so that we save/restore LR in
prologue/epilogue.
Signed-off-by: Naveen N. Rao
---
arch/powerpc/net/bpf_jit_comp64.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/powerp
1 - 100 of 112 matches
Mail list logo