Le 12/09/2022 à 23:16, Pali Rohár a écrit :
> On Monday 12 September 2022 15:48:05 Mike Rapoport wrote:
>> On Sat, Sep 10, 2022 at 09:39:20AM +, Christophe Leroy wrote:
>>> + Adding Mike who might help if the problem is around memblock.
>>>
>>> Le 08/09/2022 à 22:17, Pali Rohár a écrit :
As noted by John Hubbard the original test relied on side effects of the
implementation of migrate_vma_setup() to detect if pages had been
swapped to disk or not. This is subject to change in future so
explicitly check for swap entries via pagemap instead. Fix a spelling
mistake while we're at it.
On Thu, 2022-09-01 at 15:58 +1000, Benjamin Gray wrote:
> So not having a local entry point implies not using a TOC
> pointer, which
> implies r2 is volatile if the trampoline does not guarantee that
> it preserves
> r2. However experimenting with such a trampoline showed the
> caller s
John Hubbard writes:
> On 9/7/22 04:13, Alistair Popple wrote:
+ /*
+ * Attempt to migrate memory to device, which should fail because
+ * hopefully some pages are backed by swap storage.
+ */
+ ASSERT_TRUE(hmm_migrate_sys_to_dev(self->fd, buffer, npages));
>>>
"Nicholas Piggin" writes:
> On Wed Aug 24, 2022 at 12:05 PM AEST, Rohan McLure wrote:
...
>> diff --git a/arch/powerpc/kernel/systbl.S b/arch/powerpc/kernel/systbl.c
>> similarity index 59%
>> rename from arch/powerpc/kernel/systbl.S
>> rename to arch/powerpc/kernel/systbl.c
>> index cb3358886203.
Hey,
On Mon, 12 Sep 2022, Borislav Petkov wrote:
> Micha, any opinions on the below are appreciated.
>
> On Fri, Sep 09, 2022 at 11:07:04AM -0700, Josh Poimboeuf wrote:
> > difficult to ensure correctness. Also, due to kernel live patching, the
> > kernel relies on 100% correctness of unwindin
> On 12 Sep 2022, at 4:11 pm, Christophe Leroy
> wrote:
>
>
>
> Le 12/09/2022 à 03:47, Rohan McLure a écrit :
>> On creation and clearing of a page table mapping, instrument such calls
>> by invoking page_table_check_pte_set and page_table_check_pte_clear
>> respectively. These calls serve
On Fri, Sep 09, 2022 at 02:29:59PM +0800, Gaosheng Cui wrote:
> fs_mii_disconnect and fs_mii_connect have been removed since
> commit 5b4b8454344a ("[PATCH] FS_ENET: use PAL for mii management"),
> so remove them.
>
> Signed-off-by: Gaosheng Cui
Reviewed-by: Andrew Lunn
Andrew
On Monday 12 September 2022 15:48:05 Mike Rapoport wrote:
> On Sat, Sep 10, 2022 at 09:39:20AM +, Christophe Leroy wrote:
> > + Adding Mike who might help if the problem is around memblock.
> >
> > Le 08/09/2022 à 22:17, Pali Rohár a écrit :
> > > On Thursday 08 September 2022 17:35:11 Pali Ro
Leonardo Brás writes:
> On Fri, 2022-09-09 at 09:04 -0500, Nathan Lynch wrote:
>> Leonardo Brás writes:
>> > On Wed, 2022-09-07 at 17:01 -0500, Nathan Lynch wrote:
>> > > At the time this was submitted by Leonardo, I confirmed -- or thought
>> > > I had confirmed -- with PowerVM partition firmwar
On Fri, 02 Sep 2022 17:37:16 -0400, Sean Anderson wrote:
> This adds ids for the Lynx 10g SerDes's internal PLLs. These may be used
> with assigned-clock* to specify a particular frequency to use. For
> example, to set the second PLL (at offset 0x20)'s frequency, use
> LYNX10G_PLLa(1). These are fo
On Fri, Sep 02, 2022 at 05:37:14PM -0400, Sean Anderson wrote:
> This adds some modes necessary for Lynx 10G support. 2500BASE-X, also
> known as 2.5G SGMII, is 1000BASE-X/SGMII overclocked to 3.125 GHz, with
> autonegotiation disabled. 10GBASE-R, also known as XFI, is the protocol
> spoken between
On Fri, Sep 02, 2022 at 05:37:15PM -0400, Sean Anderson wrote:
> This adds a binding for the SerDes module found on QorIQ processors.
> Each phy is a subnode of the top-level device, possibly supporting
> multiple lanes and protocols. This "thick" #phy-cells is used due to
> allow for better organi
Hi Sathvika,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on powerpc/topic/ppc-kvm]
[also build test ERROR on linus/master v6.0-rc5]
[cannot apply to powerpc/next masahiroy-kbuild/for-next next-20220912]
[If your patch is applied to the wrong git tree, kindly drop us
https://bugzilla.kernel.org/show_bug.cgi?id=208197
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Attachment #290191|0 |1
is obsolete|
https://bugzilla.kernel.org/show_bug.cgi?id=208197
--- Comment #11 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 301794
--> https://bugzilla.kernel.org/attachment.cgi?id=301794&action=edit
dmesg (kernel 6.0-rc3, PowerMac G4 DP)
--
You may reply to this email to add a comment.
Y
Le 12/09/2022 à 15:46, Lukas Bulwahn a écrit :
> Hi Joe, hi Ben,
>
> While reviewing some kernel config, I came across
> CONFIG_DCACHE_WORD_ACCESS and tried to understand its purpose.
>
> Then, I discovered this RFC patch from 2014 that seems never to have
> been integrated:
>
> https://lore.k
On Fri, 2022-09-09 at 09:04 -0500, Nathan Lynch wrote:
> Hi Leonardo,
>
> (restoring the list to the cc, hope that's ok)
>
Sure, thanks for doing that.
I probably had some mail composer issue here.
> Leonardo Brás writes:
> > On Wed, 2022-09-07 at 17:01 -0500, Nathan Lynch wrote:
> > > At the
https://bugzilla.kernel.org/show_bug.cgi?id=208197
--- Comment #10 from Erhard F. (erhar...@mailbox.org) ---
*** Bug 216427 has been marked as a duplicate of this bug. ***
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the
https://bugzilla.kernel.org/show_bug.cgi?id=216427
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Status|NEW |RESOLVED
Resol
On Sat, Sep 10, 2022 at 09:39:20AM +, Christophe Leroy wrote:
> + Adding Mike who might help if the problem is around memblock.
>
> Le 08/09/2022 à 22:17, Pali Rohár a écrit :
> > On Thursday 08 September 2022 17:35:11 Pali Rohár wrote:
> >> On Thursday 08 September 2022 15:25:14 Christophe Le
Hi Joe, hi Ben,
While reviewing some kernel config, I came across
CONFIG_DCACHE_WORD_ACCESS and tried to understand its purpose.
Then, I discovered this RFC patch from 2014 that seems never to have
been integrated:
https://lore.kernel.org/all/1393964591.20435.58.camel@joe-AO722/
[RFC] Remove CON
On Wed Aug 24, 2022 at 12:05 PM AEST, Rohan McLure wrote:
> The common interrupt handler prologue macro and the bad_stack
> trampolines include consecutive sequences of register saves, and some
> register clears. Neaten such instances by expanding use of the SAVE_GPRS
> macro and employing the ZERO
On Wed Aug 24, 2022 at 12:05 PM AEST, Rohan McLure wrote:
> Zero GPRS r0, r2-r11, r14-r31, on entry into the kernel for all
> other interrupt sources to limit influence of user-space values
> in potential speculation gadgets. The remaining gprs are overwritten by
> entry macros to interrupt handler
On Wed Aug 24, 2022 at 12:05 PM AEST, Rohan McLure wrote:
> Interrupt handlers on 64s systems will often need to save register state
> from the interrupted process to make space for loading special purpose
> registers or for internal state.
>
> Fix a comment documenting a common code path macro in
On Wed Aug 24, 2022 at 12:05 PM AEST, Rohan McLure wrote:
> Use the convenience macros for saving/clearing/restoring gprs in keeping
> with syscall calling conventions. The plural variants of these macros
> can store a range of registers for concision.
>
> This works well when the user gpr value we
On Wed Aug 24, 2022 at 12:05 PM AEST, Rohan McLure wrote:
> Clear user state in gprs (assign to zero) to reduce the influence of user
> registers on speculation within kernel syscall handlers. Clears occur
> at the very beginning of the sc and scv 0 interrupt handlers, with
> restores occurring fol
Hi!
On Fri, Sep 09, 2022 at 11:07:04AM -0700, Josh Poimboeuf wrote:
> 2) Noreturn functions:
>
>There's no reliable way to determine which functions are designated
>by the compiler to be noreturn (either explictly via function
>attribute, or implicitly via a static function which i
On Wed Aug 24, 2022 at 12:05 PM AEST, Rohan McLure wrote:
> Implement syscall wrapper as per s390, x86, arm64. When enabled
> cause handlers to accept parameters from a stack frame rather than
> from user scratch register state. This allows for user registers to be
> safely cleared in order to redu
On Wed Aug 24, 2022 at 12:05 PM AEST, Rohan McLure wrote:
> This reverts commit 8875f47b7681aa4e4484a9b612577b044725f839.
Can you use short hash and commit title format? Also it's no longer
just reverting that patch, so maybe just come up with a new title
for this patch and reference the two patch
On Wed Aug 24, 2022 at 12:05 PM AEST, Rohan McLure wrote:
> Macros for restoring and saving registers to and from the stack exist.
> Provide macros with the same interface for clearing a range of gprs by
> setting each register's value in that range to zero.
Can I bikeshed this a bit more and ask
On Mon, Sep 12, 2022, at 1:00 PM, Christophe Leroy wrote:
> Le 12/09/2022 à 11:57, Arnd Bergmann a écrit :
>> On Mon, Sep 12, 2022, at 10:38 AM, Nicholas Piggin wrote:
>>
>> The powerpc difference is that in little-endian mode, only
>> the 'len' argument is swapped but the 'offset' argument is
>>
Le 12/09/2022 à 11:57, Arnd Bergmann a écrit :
> On Mon, Sep 12, 2022, at 10:38 AM, Nicholas Piggin wrote:
>> On Wed Aug 24, 2022 at 12:05 PM AEST, Rohan McLure wrote:
>>> The powerpc fallocate compat syscall handler is identical to the
>>> generic implementation provided by commit 59c10c52f573f
On Wed Aug 24, 2022 at 12:05 PM AEST, Rohan McLure wrote:
> Cause syscall handlers to be typed as follows when called indirectly
> throughout the kernel.
>
> typedef long (*syscall_fn)(unsigned long, unsigned long, unsigned long,
>unsigned long, unsigned long, unsigned l
On Wed Aug 24, 2022 at 12:05 PM AEST, Rohan McLure wrote:
> The table of syscall handlers and registered compatibility syscall
> handlers has in past been produced using assembly, with function
> references resolved at link time. This moves link-time errors to
> compile-time, by rewriting systbl.S
On Wed Aug 24, 2022 at 12:05 PM AEST, Rohan McLure wrote:
> Forward declare all syscall handler prototypes where a generic prototype
> is not provided in either linux/syscalls.h or linux/compat.h in
> asm/syscalls.h. This is required for compile-time type-checking for
> syscall handlers, which is i
On Wed Aug 24, 2022 at 12:05 PM AEST, Rohan McLure wrote:
> Arch-specific implementations of syscall handlers are currently used
> over generic implementations for the following reasons:
>
> 1. Semantics unique to powerpc
> 2. Compatibility syscalls require 'argument padding' to comply with
>64
On Mon, Sep 12, 2022, at 10:38 AM, Nicholas Piggin wrote:
> On Wed Aug 24, 2022 at 12:05 PM AEST, Rohan McLure wrote:
>> The powerpc fallocate compat syscall handler is identical to the
>> generic implementation provided by commit 59c10c52f573f ("riscv:
>> compat: syscall: Add compat_sys_call_table
On Wed Aug 24, 2022 at 12:05 PM AEST, Rohan McLure wrote:
> Syscall handlers should not be invoked internally by their symbol names,
> as these symbols defined by the architecture-defined SYSCALL_DEFINE
> macro. Move the compatibility syscall definition for mmap2 to
> syscalls.c, so that all mmap i
On Wed Aug 24, 2022 at 12:05 PM AEST, Rohan McLure wrote:
> Syscall handlers should not be invoked internally by their symbol names,
> as these symbols defined by the architecture-defined SYSCALL_DEFINE
> macro. Fortunately, in the case of ppc64_personality, its call to
> sys_personality can be rep
On Wed Aug 24, 2022 at 12:05 PM AEST, Rohan McLure wrote:
> Avoid duplication in future patch that will define the ppc64_personality
> syscall handler in terms of the SYSCALL_DEFINE and COMPAT_SYSCALL_DEFINE
> macros, by extracting the common body of ppc64_personality into a helper
> function.
>
>
On Wed Aug 24, 2022 at 12:05 PM AEST, Rohan McLure wrote:
> Syscall #82 has been implemented for 32-bit platforms in a unique way on
> powerpc systems. This hack will in effect guess whether the caller is
> expecting new select semantics or old select semantics. It does so via a
> guess, based off
>> +static inline bool pmd_user_accessible_page(pmd_t pmd)
>> +{
>> +return pmd_is_leaf(pmd) && pmd_present(pmd)
>> +&& pte_user(pmd_pte(pmd));
>
> The && goes on previous line.
> By the way, there is a great tool that can help you :
>
> $ ./arch/powerpc/tools/che
On Wed Aug 24, 2022 at 12:05 PM AEST, Rohan McLure wrote:
> The powerpc fallocate compat syscall handler is identical to the
> generic implementation provided by commit 59c10c52f573f ("riscv:
> compat: syscall: Add compat_sys_call_table implementation"), and as
> such can be removed in favour of th
Do not run objtool on VDSO files, by using OBJECT_FILES_NON_STANDARD.
Suggested-by: Christophe Leroy
Reviewed-by: Christophe Leroy
Signed-off-by: Sathvika Vasireddy
---
arch/powerpc/kernel/vdso/Makefile | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/kernel/vdso/Makefile
b/
This patch adds [stub] implementations for required functions, inorder
to enable objtool build on powerpc.
Signed-off-by: Sathvika Vasireddy
[Christophe Leroy: powerpc: Add missing asm/asm.h for objtool,
Use local variables for type and imm in arch_decode_instruction(),
Adapt len for prefixed ins
This patch enables objtool --mcount on powerpc, and adds implementation
specific to powerpc.
Signed-off-by: Sathvika Vasireddy
---
arch/powerpc/Kconfig | 1 +
tools/objtool/arch/powerpc/decode.c | 16
tools/objtool/arch/powerpc/include/arch/el
Make relocation types architecture specific.
Acked-by: Peter Zijlstra (Intel)
Reviewed-by: Christophe Leroy
Signed-off-by: Sathvika Vasireddy
---
tools/objtool/arch/x86/include/arch/elf.h | 2 ++
tools/objtool/check.c | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
Add architecture specific function to look for relocation records
pointing to architecture specific symbols.
Suggested-by: Christophe Leroy
Reviewed-by: Christophe Leroy
Signed-off-by: Sathvika Vasireddy
---
tools/objtool/arch/x86/decode.c | 5 +
tools/objtool/check.c|
Call add_special_section_alts() only when stackval or orc or uaccess or
noinstr options are passed to objtool.
Signed-off-by: Sathvika Vasireddy
---
tools/objtool/check.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
ind
Some architectures (powerpc) may not support ftrace locations being
nop'ed out at build time. Introduce --mnop as an option to objtool for
enabling nop'ing of ftrace locations. Re-purpose CONFIG_HAVE_NOP_MCOUNT
as a means for architectures to indicate support for the same.
Also, make sure that --m
From: Christophe Leroy
Fix several annotations in assembly files on PPC32.
Signed-off-by: Christophe Leroy
[Sathvika Vasireddy: Changed subject line from "objtool/powerpc: Activate
objtool on PPC32" to "powerpc: Fix objtool unannotated intra-function call
warnings on PPC32", and removed Kconfig
From: Christophe Leroy
In order to allow using objtool on cross-built kernels,
determine size of long from elf data instead of using
sizeof(long) at build time.
For the time being this covers only mcount.
Acked-by: Peter Zijlstra (Intel)
Signed-off-by: Christophe Leroy
[Sathvika Vasireddy: Re
From: Christophe Leroy
find_insn() will return NULL in case of failure. Check insn in order
to avoid a kernel Oops for NULL pointer dereference.
Acked-by: Peter Zijlstra (Intel)
Signed-off-by: Christophe Leroy
---
tools/objtool/check.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
di
With objtool enabled, below warnings are seen when trying to build:
drivers/crypto/vmx/aesp8-ppc.o: warning: objtool: aes_p8_set_encrypt_key+0x44:
unannotated intra-function call
drivers/crypto/vmx/aesp8-ppc.o: warning: objtool: .text+0x2448: unannotated
intra-function call
drivers/crypto/vmx/aes
From: Christophe Leroy
Some architectures like powerpc support both endianness, it's
therefore not possible to fix the endianness via arch/endianness.h
because there is no easy way to get the target endianness at
build time.
Use the endianness recorded in the file objtool is working on.
Acked-b
objtool throws the following unannotated intra-function call warnings:
arch/powerpc/kernel/entry_64.o: warning: objtool: .text+0x4: unannotated
intra-function call
arch/powerpc/kvm/book3s_hv_rmhandlers.o: warning: objtool: .text+0xe64:
unannotated intra-function call
arch/powerpc/kvm/book3s_hv_rm
Objtool throws unannotated intra-function call warnings in the following
assembly files:
arch/powerpc/kernel/vector.o: warning: objtool: .text+0x53c: unannotated
intra-function call
arch/powerpc/kvm/book3s_hv_rmhandlers.o: warning: objtool: .text+0x60:
unannotated intra-function call
arch/power
In a subsequent patch, we would want to annotate powerpc assembly functions
with SYM_FUNC_START_LOCAL macro. This macro depends on __ALIGN macro.
The default expansion of __ALIGN macro is:
#define __ALIGN .align 4,0x90
So, override __ALIGN and __ALIGN_STR macros to use the same align
Commit 1e688dd2a3d675 ("powerpc/bug: Provide better flexibility to
WARN_ON/__WARN_FLAGS() with asm goto") updated __WARN_FLAGS() to use asm
goto, and added a call to 'unreachable()' after the asm goto for optimal
code generation. With CONFIG_OBJTOOL enabled, 'annotate_unreachable()'
statement in 'u
This patchset enables and implements objtool --mcount
option on powerpc. This applies atop powerpc/merge branch.
Changelog:
v3:
* Patch 01/16 - Rework patch subject.
- Rework changelog.
- Add Reviewed-by tag from Christophe Leroy.
* Patch 02/16 - Rework changelog to
On Wed Aug 24, 2022 at 12:05 PM AEST, Rohan McLure wrote:
> The asmlinkage macro has no special meaning in powerpc, and prior to
> this patch is used sporadically on some syscall handler definitions. On
> architectures that do not define asmlinkage, it resolves to extern "C"
> for C++ compilers and
62 matches
Mail list logo
